http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #17 from Eric Botcazou ---
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_VAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #16 from Eric Botcazou ---
> 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 excepti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #15 from 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 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #14 from Eric Botcazou ---
> Hopefully the other OSes use one of these two settings.
At least FreeBSD uses the Linux setting.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #13 from Eric Botcazou ---
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #12 from 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 (which would no
longer need a configure check), so that if the generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #11 from 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_as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #10 from Eric Botcazou ---
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #8 from 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 qu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
Eric Botcazou changed:
What|Removed |Added
Target|sparc*-sun-solaris2.*, |sparc*-sun-solaris2.*
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #6 from Eric Botcazou ---
> 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #5 from Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
15 matches
Mail list logo
