Compile tst-cleanupx4 test with -fexceptions

  tst-cleanupx4 is linked with tst-cleanupx4.o and tst-cleanup4aux.o.
Since tst-cleanupx4.o is compiled from tst-cleanup4.c with -fexceptions,
tst-cleanupx4.c should also be compiled with -fexceptions.

Tested on x86-64 and i686.  OK for master?


H.J.
--
	[BZ 18645]
	* nptl/Makefile (extra-test-objs): Add tst-cleanupx4aux.o
	(test-extras): Add tst-cleanupx4aux.
	(CFLAGS-tst-cleanupx4aux.c): New.  Set to -fexceptions.
	($(objpfx)tst-cleanupx4): Replace tst-cleanup4aux.o with
	tst-cleanupx4aux.o.
	* nptl/tst-cleanupx4aux.c: New file.
---
 nptl/Makefile           | 8 +++++---
 nptl/tst-cleanupx4aux.c | 1 +
 2 files changed, 6 insertions(+), 3 deletions(-)
 create mode 100644 nptl/tst-cleanupx4aux.c
  

On Wed, Jun 1, 2016 at 2:17 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
> tst-cleanupx4 is linked with tst-cleanupx4.o and tst-cleanup4aux.o.
> Since tst-cleanupx4.o is compiled from tst-cleanup4.c with -fexceptions,
> tst-cleanupx4.c should also be compiled with -fexceptions.
>
> Tested on x86-64 and i686.  OK for master?
>
>
> H.J.
> --
>         [BZ 18645]
>         * nptl/Makefile (extra-test-objs): Add tst-cleanupx4aux.o
>         (test-extras): Add tst-cleanupx4aux.
>         (CFLAGS-tst-cleanupx4aux.c): New.  Set to -fexceptions.
>         ($(objpfx)tst-cleanupx4): Replace tst-cleanup4aux.o with
>         tst-cleanupx4aux.o.
>         * nptl/tst-cleanupx4aux.c: New file.
> ---
>  nptl/Makefile           | 8 +++++---
>  nptl/tst-cleanupx4aux.c | 1 +
>  2 files changed, 6 insertions(+), 3 deletions(-)
>  create mode 100644 nptl/tst-cleanupx4aux.c
>
> diff --git a/nptl/Makefile b/nptl/Makefile
> index eaa6f7f..684c538 100644
> --- a/nptl/Makefile
> +++ b/nptl/Makefile
> @@ -333,8 +333,9 @@ modules-names = tst-atfork2mod tst-tls3mod tst-tls4moda tst-tls4modb \
>                 tst-tls5modd tst-tls5mode tst-tls5modf tst-stack4mod \
>                 tst-_res1mod1 tst-_res1mod2 tst-execstack-mod tst-fini1mod \
>                 tst-join7mod
> -extra-test-objs += $(addsuffix .os,$(strip $(modules-names))) tst-cleanup4aux.o
> -test-extras += $(modules-names) tst-cleanup4aux
> +extra-test-objs += $(addsuffix .os,$(strip $(modules-names))) \
> +                  tst-cleanup4aux.o tst-cleanupx4aux.o
> +test-extras += $(modules-names) tst-cleanup4aux tst-cleanupx4aux
>  test-modules = $(addprefix $(objpfx),$(addsuffix .so,$(modules-names)))
>
>  tst-atfork2mod.so-no-z-defs = yes
> @@ -476,6 +477,7 @@ CFLAGS-tst-cleanupx1.c += -fexceptions -fasynchronous-unwind-tables
>  CFLAGS-tst-cleanupx2.c += -fexceptions
>  CFLAGS-tst-cleanupx3.c += -fexceptions
>  CFLAGS-tst-cleanupx4.c += -fexceptions
> +CFLAGS-tst-cleanupx4aux.c += -fexceptions
>  CFLAGS-tst-oncex3.c += -fexceptions
>  CFLAGS-tst-oncex4.c += -fexceptions
>  CFLAGS-tst-align.c += $(stack-align-test-flags)
> @@ -519,7 +521,7 @@ clean:
>         rm -f $(tst-stack4mod.sos)
>
>  $(objpfx)tst-cleanup4: $(objpfx)tst-cleanup4aux.o $(shared-thread-library)
> -$(objpfx)tst-cleanupx4: $(objpfx)tst-cleanup4aux.o $(shared-thread-library)
> +$(objpfx)tst-cleanupx4: $(objpfx)tst-cleanupx4aux.o $(shared-thread-library)
>
>  $(objpfx)tst-tls3: $(libdl) $(shared-thread-library)
>  LDFLAGS-tst-tls3 = -rdynamic
> diff --git a/nptl/tst-cleanupx4aux.c b/nptl/tst-cleanupx4aux.c
> new file mode 100644
> index 0000000..00bafe4
> --- /dev/null
> +++ b/nptl/tst-cleanupx4aux.c
> @@ -0,0 +1 @@
> +#include "tst-cleanup4aux.c"
> --
> 2.5.5
>

I'd like to check in this patch to fix the last test failure on i686.
Any comments, feedbacks?
  

On 01 Jun 2016 14:17, H.J. Lu wrote:
> tst-cleanupx4 is linked with tst-cleanupx4.o and tst-cleanup4aux.o.
> Since tst-cleanupx4.o is compiled from tst-cleanup4.c with -fexceptions,
> tst-cleanupx4.c should also be compiled with -fexceptions.

i think this last line you meant "tst-cleanupx4aux.c", or at least
generalize it to say "the aux object".

> Tested on x86-64 and i686.  OK for master?
> 
> 
> H.J.
> --
> 	[BZ 18645]

need a # before the bug number

> 	* nptl/Makefile (extra-test-objs): Add tst-cleanupx4aux.o

period at the end

nits aside, patch looks OK
-mike
  

On 2016-06-01 14:17, H.J. Lu wrote:
> tst-cleanupx4 is linked with tst-cleanupx4.o and tst-cleanup4aux.o.
> Since tst-cleanupx4.o is compiled from tst-cleanup4.c with -fexceptions,
> tst-cleanupx4.c should also be compiled with -fexceptions.
> 
> Tested on x86-64 and i686.  OK for master?
> 
> 
> H.J.
> --
> 	[BZ 18645]
> 	* nptl/Makefile (extra-test-objs): Add tst-cleanupx4aux.o
> 	(test-extras): Add tst-cleanupx4aux.
> 	(CFLAGS-tst-cleanupx4aux.c): New.  Set to -fexceptions.
> 	($(objpfx)tst-cleanupx4): Replace tst-cleanup4aux.o with
> 	tst-cleanupx4aux.o.
> 	* nptl/tst-cleanupx4aux.c: New file.
> ---
>  nptl/Makefile           | 8 +++++---
>  nptl/tst-cleanupx4aux.c | 1 +
>  2 files changed, 6 insertions(+), 3 deletions(-)
>  create mode 100644 nptl/tst-cleanupx4aux.c

I am probably a bit late, but I have been pointed in the past there that
the point of tst-cleanupx4 is actually to test unwinding through a
function not compliled with -fexceptions:

https://sourceware.org/ml/libc-alpha/2014-07/msg00299.html

Note that I have identified the GCC change which introduced this
regression:

http://www.sourceware.org/ml/libc-alpha/2015-11/msg00533.html

Aurelien
  

On Thu, Jun 30, 2016 at 3:42 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On 2016-06-01 14:17, H.J. Lu wrote:
>> tst-cleanupx4 is linked with tst-cleanupx4.o and tst-cleanup4aux.o.
>> Since tst-cleanupx4.o is compiled from tst-cleanup4.c with -fexceptions,
>> tst-cleanupx4.c should also be compiled with -fexceptions.
>>
>> Tested on x86-64 and i686.  OK for master?
>>
>>
>> H.J.
>> --
>>       [BZ 18645]
>>       * nptl/Makefile (extra-test-objs): Add tst-cleanupx4aux.o
>>       (test-extras): Add tst-cleanupx4aux.
>>       (CFLAGS-tst-cleanupx4aux.c): New.  Set to -fexceptions.
>>       ($(objpfx)tst-cleanupx4): Replace tst-cleanup4aux.o with
>>       tst-cleanupx4aux.o.
>>       * nptl/tst-cleanupx4aux.c: New file.
>> ---
>>  nptl/Makefile           | 8 +++++---
>>  nptl/tst-cleanupx4aux.c | 1 +
>>  2 files changed, 6 insertions(+), 3 deletions(-)
>>  create mode 100644 nptl/tst-cleanupx4aux.c
>
> I am probably a bit late, but I have been pointed in the past there that
> the point of tst-cleanupx4 is actually to test unwinding through a
> function not compliled with -fexceptions:
>
> https://sourceware.org/ml/libc-alpha/2014-07/msg00299.html
>
> Note that I have identified the GCC change which introduced this
> regression:
>
> http://www.sourceware.org/ml/libc-alpha/2015-11/msg00533.html
>

I can understand it won't be considered as a GCC bug:

'-fexceptions'
     Enable exception handling.  Generates extra code needed to
     propagate exceptions.  For some targets, this implies GCC generates
     frame unwind information for all functions, which can produce
     significant data size overhead, although it does not affect
     execution.  If you do not specify this option, GCC enables it by
     default for languages like C++ that normally require exception
     handling, and disables it for languages like C that do not normally
     require it.  However, you may need to enable this option when
     compiling C code that needs to interoperate properly with exception
     handlers written in C++.  You may also wish to disable this option
     if you are compiling older C++ programs that don't use exception
     handling.

Can we make tst-cleanupx4 to pass on i686 without -fexceptions
using the current GCC?
  

Aurelien Jarno <aurelien@aurel32.net> writes:

> Note that I have identified the GCC change which introduced this
> regression:
>
> http://www.sourceware.org/ml/libc-alpha/2015-11/msg00533.html

Did you create a gcc bug?

Andreas.
  

On 2016-06-30 12:56, Andreas Schwab wrote:
> Aurelien Jarno <aurelien@aurel32.net> writes:
> 
> > Note that I have identified the GCC change which introduced this
> > regression:
> >
> > http://www.sourceware.org/ml/libc-alpha/2015-11/msg00533.html
> 
> Did you create a gcc bug?

As far as I remember I didn't (and can't find anything in bugzilla
either). Now I don't fully understand the GCC change either, so I don't
know if it is a real GCC bug or if we have to changes things on the
GLIBC side.

Aurelien