[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
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=205735root=gccview=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
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.
[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
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
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
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
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
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
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
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
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
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
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
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
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
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
