[Bug c/59316] New: gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[Bug c/59316] New: gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

            Bug ID: 59316
           Summary: gcc.dg/atomic/c11-atomic-exec-5.c FAILs on
                    Solaris/SPARC
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: jsm28 at gcc dot gnu.org
              Host: sparc*-sun-solaris2.*
            Target: sparc*-sun-solaris2.*
             Build: sparc*-sun-solaris2.*

The new gcc.dg/atomic/c11-atomic-exec-5.c tests FAILs on Solaris/SPARC:

FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O1  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O2  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O3 -fomit-frame-pointer  execution
test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O3 -g  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O2 -flto -flto-partition=none 
execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  -O2 -flto  execution test

E.g.

float_add_invalid (a) 688 pass, 54 fail; (b) 9258 pass, 0 fail
float_add_invalid_prev (a) 758 pass, 86 fail; (b) 9156 pass, 0 fail
float_add_overflow (a) 851 pass, 0 fail; (b) 3221 pass, 5928 fail
float_add_overflow_prev (a) 1324 pass, 0 fail; (b) 3128 pass, 5548 fail
float_add_overflow_double (a) 842 pass, 0 fail; (b) 2365 pass, 6793 fail
float_add_overflow_long_double (a) 3053 pass, 0 fail; (b) 3673 pass, 3274 fail
float_add_inexact (a) 1508 pass, 0 fail; (b) 3155 pass, 5337 fail
float_add_inexact_int (a) 3865 pass, 0 fail; (b) 4557 pass, 1578 fail
float_preinc_inexact (a) 910 pass, 0 fail; (b) 2989 pass, 6101 fail
float_postinc_inexact (a) 4548 pass, 0 fail; (b) 4315 pass, 1137 fail
long_add_float_inexact (a) 1723 pass, 0 fail; (b) 4987 pass, 3290 fail
float_postinc_inexact (a) 4548 pass, 0 fail; (b) 4315 pass, 1137 fail
long_add_float_inexact (a) 1723 pass, 0 fail; (b) 4987 pass, 3290 fail
complex_float_add_overflow (a) 3787 pass, 0 fail; (b) 3697 pass, 2516 fail
float_sub_invalid (a) 849 pass, 72 fail; (b) 9079 pass, 0 fail
float_sub_overflow (a) 1066 pass, 0 fail; (b) 3317 pass, 5617 fail
float_sub_inexact (a) 1930 pass, 0 fail; (b) 3466 pass, 4604 fail
float_sub_inexact_int (a) 1709 pass, 0 fail; (b) 4165 pass, 4126 fail
float_predec_inexact (a) 1421 pass, 0 fail; (b) 4134 pass, 4445 fail
float_postdec_inexact (a) 1577 pass, 0 fail; (b) 4062 pass, 4361 fail
long_sub_float_inexact (a) 2993 pass, 0 fail; (b) 4758 pass, 2249 fail
complex_float_sub_overflow (a) 4578 pass, 0 fail; (b) 4540 pass, 882 fail
float_mul_invalid (a) 617 pass, 433 fail; (b) 8950 pass, 0 fail
float_mul_overflow (a) 1585 pass, 0 fail; (b) 2798 pass, 5617 fail
float_mul_underflow (a) 952 pass, 0 fail; (b) 4818 pass, 4230 fail
float_mul_inexact (a) 2580 pass, 0 fail; (b) 3755 pass, 3665 fail
float_mul_inexact_int (a) 2901 pass, 0 fail; (b) 4334 pass, 2765 fail
long_mul_float_inexact (a) 4301 pass, 0 fail; (b) 4530 pass, 1169 fail
complex_float_mul_overflow (a) 3442 pass, 0 fail; (b) 3017 pass, 3541 fail
float_div_invalid_divbyzero (a) 2866 pass, 759 fail; (b) 4031 pass, 2344 fail
float_div_overflow (a) 2648 pass, 0 fail; (b) 2935 pass, 4417 fail
float_div_underflow (a) 2759 pass, 0 fail; (b) 3439 pass, 3802 fail
float_div_inexact (a) 2190 pass, 0 fail; (b) 2448 pass, 5362 fail
float_div_inexact_int (a) 2844 pass, 0 fail; (b) 3331 pass, 3825 fail
float_div_inexact (a) 2190 pass, 0 fail; (b) 2448 pass, 5362 fail
float_div_inexact_int (a) 2844 pass, 0 fail; (b) 3331 pass, 3825 fail
int_div_float_inexact (a) 2078 pass, 0 fail; (b) 3967 pass, 3955 fail
complex_float_div_overflow (a) 3532 pass, 0 fail; (b) 2754 pass, 3714 fail
double_add_invalid (a) 2894 pass, 954 fail; (b) 6152 pass, 0 fail
double_add_overflow (a) 3938 pass, 0 fail; (b) 4331 pass, 1731 fail
double_add_overflow_long_double (a) 2723 pass, 0 fail; (b) 2546 pass, 4731 fail
double_add_inexact (a) 4993 pass, 0 fail; (b) 4996 pass, 11 fail
double_add_inexact_int (a) 4917 pass, 0 fail; (b) 4867 pass, 216 fail
double_preinc_inexact (a) 3130 pass, 0 fail; (b) 2941 pass, 3929 fail
double_postinc_inexact (a) 3530 pass, 0 fail; (b) 2498 pass, 3972 fail
long_long_add_double_inexact (a) 3311 pass, 0 fail; (b) 3933 pass, 2756 fail
complex_double_add_overflow (a) 5698 pass, 0 fail; (b) 4288 pass, 14 fail
double_sub_invalid (a) 1965 pass, 1597 fail; (b) 6438 pass, 0 fail
double_sub_overflow (a) 2852 pass, 0 fail; (b) 2972 pass, 4176 fail
double_sub_inexact (a) 3469 pass, 0 fail; (b) 3651 pass, 2880 fail
double_sub_inexact_int (a) 4829 pass, 0 fail; (b) 4679 pass, 492 fail
double_predec_inexact (a) 3221 pass, 0 fail; (b) 3100 pass, 3679 fail
double_postdec_inexact (a) 3908 pass, 0 fail; (b) 3888 pass, 2204 fail
long_long_sub_double_inexact (a) 3775 pass, 0 fail; (b) 4151 pass, 2074 fail
complex_double_sub_overflow (a) 5285 pass, 0 fail; (b) 4676 pass, 39 fail
double_mul_invalid (a) 2760 pass, 1123 fail; (b) 6117 pass, 0 fail
double_mul_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail
double_mul_invalid (a) 2760 pass, 1123 fail; (b) 6117 pass, 0 fail
double_mul_overflow (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail
double_mul_overflow_float (a) 4628 pass, 0 fail; (b) 4670 pass, 702 fail
double_mul_underflow (a) 4003 pass, 0 fail; (b) 4558 pass, 1439 fail
double_mul_inexact (a) 5000 pass, 0 fail; (b) 5000 pass, 0 fail
double_mul_inexact_int (a) 4886 pass, 0 fail; (b) 4863 pass, 251 fail
long_long_mul_double_inexact (a) 3462 pass, 0 fail; (b) 4465 pass, 2073 fail
complex_double_mul_overflow (a) 5547 pass, 0 fail; (b) 4130 pass, 323 fail
double_div_invalid_divbyzero (a) 4145 pass, 472 fail; (b) 4376 pass, 1007 fail
double_div_overflow (a) 4506 pass, 0 fail; (b) 4344 pass, 1150 fail
double_div_underflow (a) 4936 pass, 0 fail; (b) 4905 pass, 159 fail
double_div_inexact (a) 3737 pass, 0 fail; (b) 3169 pass, 3094 fail
double_div_inexact_int (a) 3146 pass, 0 fail; (b) 2499 pass, 4355 fail
int_div_double_inexact (a) 3307 pass, 0 fail; (b) 3551 pass, 3142 fail
complex_double_div_overflow (a) 5567 pass, 0 fail; (b) 4419 pass, 14 fail
long_double_add_invalid (a) 5176 pass, 778 fail; (b) 4046 pass, 0 fail
long_double_add_overflow (a) 5255 pass, 0 fail; (b) 3641 pass, 1104 fail
long_double_add_inexact (a) 5318 pass, 0 fail; (b) 4275 pass, 407 fail
long_double_add_inexact_int (a) 5044 pass, 0 fail; (b) 4851 pass, 105 fail
long_double_preinc_inexact (a) 5037 pass, 0 fail; (b) 4928 pass, 35 fail
long_double_postinc_inexact (a) 4767 pass, 0 fail; (b) 3852 pass, 1381 fail
complex_long_double_add_overflow (a) 4970 pass, 0 fail; (b) 4780 pass, 250 fail
long_double_sub_invalid (a) 5079 pass, 691 fail; (b) 4230 pass, 0 fail
complex_long_double_add_overflow (a) 4970 pass, 0 fail; (b) 4780 pass, 250 fail
long_double_sub_invalid (a) 5079 pass, 691 fail; (b) 4230 pass, 0 fail
long_double_sub_overflow (a) 4091 pass, 0 fail; (b) 4162 pass, 1747 fail
long_double_sub_inexact (a) 4302 pass, 0 fail; (b) 2337 pass, 3361 fail
long_double_sub_inexact_int (a) 4700 pass, 0 fail; (b) 3406 pass, 1894 fail
long_double_predec_inexact (a) 3861 pass, 0 fail; (b) 3569 pass, 2570 fail
long_double_postdec_inexact (a) 5302 pass, 0 fail; (b) 4143 pass, 555 fail
complex_long_double_sub_overflow (a) 5015 pass, 0 fail; (b) 4761 pass, 224 fail
long_double_mul_invalid (a) 5670 pass, 159 fail; (b) 4171 pass, 0 fail
long_double_mul_overflow (a) 2699 pass, 0 fail; (b) 4539 pass, 2762 fail
long_double_mul_overflow_float (a) 4505 pass, 0 fail; (b) 4697 pass, 798 fail
long_double_mul_overflow_double (a) 4948 pass, 0 fail; (b) 4398 pass, 654 fail
long_double_mul_underflow (a) 4871 pass, 0 fail; (b) 4196 pass, 933 fail
long_double_mul_inexact (a) 3898 pass, 0 fail; (b) 4743 pass, 1359 fail
long_double_mul_inexact_int (a) 5027 pass, 0 fail; (b) 4903 pass, 70 fail
complex_long_double_mul_overflow (a) 4820 pass, 0 fail; (b) 3986 pass, 1194
fail
long_double_div_invalid_divbyzero (a) 5326 pass, 328 fail; (b) 3959 pass, 387
fail
long_double_div_overflow (a) 3766 pass, 0 fail; (b) 4248 pass, 1986 fail
long_double_div_underflow (a) 5001 pass, 0 fail; (b) 4999 pass, 0 fail
long_double_div_inexact (a) 4815 pass, 0 fail; (b) 4951 pass, 234 fail
long_double_div_inexact_int (a) 5174 pass, 0 fail; (b) 4379 pass, 447 fail
int_div_long_double_inexact (a) 4186 pass, 0 fail; (b) 4128 pass, 1686 fail
long_double_div_inexact_int (a) 5174 pass, 0 fail; (b) 4379 pass, 447 fail
int_div_long_double_inexact (a) 4186 pass, 0 fail; (b) 4128 pass, 1686 fail
complex_long_double_div_overflow (a) 4264 pass, 0 fail; (b) 4363 pass, 1373
fail

E.g. in the float_add_invalid case, all fails are with 0x10 (FE_INVALID).

  Rainer

[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|sparc*-sun-solaris2.*       |sparc*-sun-solaris2.*,
                   |                            |arm-none-linux-gnueabihf
                 CC|                            |ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Fails on arm linux as well.

[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
See: http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html - the failures 
indicate the architecture maintainers have not yet added this hook (for 
either SPARC, or ARM, or any non-x86 architecture).

[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Feel free to add a comment mentioning the hook targets need to define for 
this test to pass.

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-27
          Component|c                           |target
     Ever confirmed|0                           |1

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, for the release I consider this a testsuite bug (the test should be
disabled/skipped for archs not supporting the feature).

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Btw, for the release I consider this a testsuite bug (the test should be
> disabled/skipped for archs not supporting the feature).

Yes, but only immediately before the release, as that's a good reminder.

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|sparc*-sun-solaris2.*,      |sparc*-sun-solaris2.*
                   |arm-none-linux-gnueabihf    |

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
FWIW it also fails on PowerPC/Linux and IA-64/Linux, so I presume that it fails
everywhere except for 2 platforms?

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
It fails everywhere that (a) supports floating-point exceptions, (b) has 
not had the target hook added and (c) supports pthreads ((c) is a 
requirement for the test to run - the feature in question still won't work 
properly if (a) and (b) apply but pthreads aren't supported, it's just 
that the test won't run in that case).

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Fixing on SPARC.

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Fixing on SPARC.

Ugh.  Linux and Solaris disagree on the values of the FE_* macros so we will
need to have OS-dependent code in the sparc_atomic_assign_expand_fenv hook if
we call __atomic_feraiseexcept (I wonder if the same issue exists for
x86/x86-64).

The feupdateenv implementation for SPARC in glibc calls feraiseexcept at the
end (like the x86 implementation), but it does so only for the "old"
exceptions.  Yet the manpage seems to indicate that "old" and "new" exceptions
play a symmetrical role:

       The feupdateenv() function installs the floating-point environment rep-
       resented  by  the object *envp, except that currently raised exceptions
       are not cleared.  After calling this function,  the  raised  exceptions
       will  be  a bitwise OR of those previously set with those in *envp.  As
       before, the object *envp must be known to be valid.

The implementation for PowerPC does not call feraiseexcept at the end and
instead merges the exceptions in a symmetrical way.

Rainer, can you briefly describe the implementation of feupdateenv in the libm
of OpenSolaris?

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 2 Dec 2013, ebotcazou at gcc dot gnu.org wrote:

> Ugh.  Linux and Solaris disagree on the values of the FE_* macros so we will
> need to have OS-dependent code in the sparc_atomic_assign_expand_fenv hook if
> we call __atomic_feraiseexcept (I wonder if the same issue exists for
> x86/x86-64).

x86/x86-64 now have their own fenv.c file that defines the FE_* macros 
itself and so is immune to that issue.  I was hoping that generally the 
macros would be defined to correspond to the appropriate bits in the 
relevant status register and so the hook could be OS-independent.

> The feupdateenv implementation for SPARC in glibc calls feraiseexcept at the
> end (like the x86 implementation), but it does so only for the "old"
> exceptions.  Yet the manpage seems to indicate that "old" and "new" exceptions
> play a symmetrical role:
> 
>        The feupdateenv() function installs the floating-point environment rep-
>        resented  by  the object *envp, except that currently raised exceptions
>        are not cleared.  After calling this function,  the  raised  exceptions
>        will  be  a bitwise OR of those previously set with those in *envp.  As
>        before, the object *envp must be known to be valid.

They are symmetric as regards which bits are set (would be indicated by 
fetestexcept as being set) after feupdateenv.  They are not symmetric with 
regard to which are raised in the sense of having trap handlers called - 
feupdateenv should cause traps (where enabled in the saved environment) 
for any exceptions that were set at the time feupdateenv was called, but 
not for any that were only set in the saved environment but not in the 
environment active when feupdateenv was called.

(Some architectures, e.g. x86, may not actually allow for setting 
exceptions from a saved environment without taking traps for them.  IEEE 
754-2008 requires operations raiseFlags and restoreFlags that set a 
particular state of flags without causing traps.  If those responsible for 
the definition of architectures where flags can't actually be set without 
causing any enabled traps to be taken are concerned about implementability 
of this aspect of IEEE 754-2008, presumably they'll add new architecture 
features as needed to implement this.  In any case, c11-atomic-exec-5.c 
does not test anything relating to enabled traps, although the 
feholdexcept code sequence from the target hook is intended to disable 
traps and the feupdateenv sequence should then restore the previous state 
of which traps were enabled.)

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
One possibility would be to change libatomic/fenv.c to include a local 
atomic-fenv.h (for example) header instead of <fenv.h> (which would no 
longer need a configure check), so that if the generic file is OK for an 
architecture then that architecture would provide an atomic-fenv.h header 
in libatomic/config, defining the macros to correspond directly with the 
bits from the relevant status register (and any architecture without 
support would get a dummy atomic-fenv.h header not defining any of the 
macros).  That way, the hook doesn't need any OS-dependence.

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> x86/x86-64 now have their own fenv.c file that defines the FE_* macros 
> itself and so is immune to that issue.  I was hoping that generally the 
> macros would be defined to correspond to the appropriate bits in the 
> relevant status register and so the hook could be OS-independent.

That's a reasonable assumption and, to answer my own question, Solaris defines
the same FE_* macros as Linux on x86.  The hitch on the SPARC is that you have
2 sets of flags in the FP status register, the FSR_accrued_exception field and
the FSR_current_exception field; Solaris defines the FE_* macros according to
the latter and Linux according to the former (so you need a shift to convert
between the 2 sets of macros).  Hopefully the other OSes use one of these two
settings.

> They are symmetric as regards which bits are set (would be indicated by 
> fetestexcept as being set) after feupdateenv.  They are not symmetric with 
> regard to which are raised in the sense of having trap handlers called - 
> feupdateenv should cause traps (where enabled in the saved environment) 
> for any exceptions that were set at the time feupdateenv was called, but 
> not for any that were only set in the saved environment but not in the 
> environment active when feupdateenv was called.

OK, that's what I was more or less suspecting, thanks for confirming.

> In any case, c11-atomic-exec-5.c does not test anything relating to enabled
> traps, although the feholdexcept code sequence from the target hook is 
> intended to disable traps and the feupdateenv sequence should then restore 
> the previous state of which traps were enabled.)

The question is: does the UPDATE part of the hook really need to cause traps as
the feupdateenv routine, or could it only set the appropriate bits?

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Hopefully the other OSes use one of these two settings.

At least FreeBSD uses the Linux setting.

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #15 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 3 Dec 2013, ebotcazou at gcc dot gnu.org wrote:

> > In any case, c11-atomic-exec-5.c does not test anything relating to enabled
> > traps, although the feholdexcept code sequence from the target hook is 
> > intended to disable traps and the feupdateenv sequence should then restore 
> > the previous state of which traps were enabled.)
> 
> The question is: does the UPDATE part of the hook really need to cause traps as
> the feupdateenv routine, or could it only set the appropriate bits?

Properly it should cause traps if those are enabled (although enabling 
traps is outside the scope of ISO C, and my guess is that when TS 18661-5 
provides C bindings for IEEE 754-2008 alternate exception handling, they 
will be a lot more complicated than simply enabling / disabling traps, and 
won't be implemented in GCC / glibc any time soon).

The issue of trapping for exact underflow is deliberately ignored (I 
raised it in <http://www.open-std.org/jtc1/sc22/wg14/13103> for 
consideration for TS 18661-5).

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Properly it should cause traps if those are enabled (although enabling 
> traps is outside the scope of ISO C, and my guess is that when TS 18661-5 
> provides C bindings for IEEE 754-2008 alternate exception handling, they 
> will be a lot more complicated than simply enabling / disabling traps, and 
> won't be implemented in GCC / glibc any time soon).

OK, I'll go for the call to __atomic_feraiseexcept like on x86 then, and I'll
define a macro on Solaris to do the required shifting.  Thanks again.

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Fri Dec  6 11:31:56 2013
New Revision: 205735

URL: http://gcc.gnu.org/viewcvs?rev=205735&root=gcc&view=rev
Log:
    PR target/59316
    * config/sparc/sparc.h (SPARC_LOW_FE_EXCEPT_VALUES): Define.
    * config/sparc/sol2.h (SPARC_LOW_FE_EXCEPT_VALUES): Redefine.
    * config/sparc/sparc.c (TARGET_INIT_BUILTINS): Move around.
    (TARGET_BUILTIN_DECL): Define.
    (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): Likewise.
    (sparc32_initialize_trampoline): Adjust call to gen_flush.
    (enum sparc_builtins): New enumeral type.
    (sparc_builtins): New static array.
    (sparc_builtins_icode): Likewise.
    (def_builtin): Accept a separate icode and save the result.
    (def_builtin_const): Likewise.
    (sparc_fpu_init_builtins): New function.
    (sparc_vis_init_builtins): Pass the builtin code.
    (sparc_init_builtins): Call it if TARGET_FPU.
    (sparc_builtin_decl): New function.
    (sparc_expand_builtin): Deal with SPARC_BUILTIN_{LD,ST}FSR.
    (sparc_handle_vis_mul8x16): Use the builtin code.
    (sparc_fold_builtin): Likewise.  Deal with SPARC_BUILTIN_{LD,ST}FSR
    and SPARC_BUILTIN_PDISTN.
    (compound_expr): New helper function.
    (sparc_atomic_assign_expand_fenv): New function.
    * config/sparc/sparc.md (unspecv): Reorder values, add UNSPECV_LDFSR
    and UNSPECV_STFSR.
    (flush, flushdi): Merge into single pattern.
    (ldfsr): New instruction.
    (stfsr): Likewise.

Added:
    trunk/gcc/testsuite/gcc.target/sparc/pdistn-2.c
    trunk/gcc/testsuite/gcc.target/sparc/pdistn.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sparc/sol2.h
    trunk/gcc/config/sparc/sparc.c
    trunk/gcc/config/sparc/sparc.h
    trunk/gcc/config/sparc/sparc.md
    trunk/gcc/testsuite/ChangeLog

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This should pass now.