https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #49 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #48)
> Clang gets this right, even without the pragma;
The "even without the pragma" part is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #48 from Thomas Koenig ---
Clang gets this right, even without the pragma; the original test case is
compiled to
pushq %r14
pushq %rbx
subq$24, %rsp
movq%rsi, %r14
movq%rdi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Thomas Koenig changed:
What|Removed |Added
Blocks||105105
--- Comment #47 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #46 from Thomas Koenig ---
Fortran gets this right:
$ cat set_rounding_mode.f90
module x
implicit none
integer, parameter :: wp = selected_real_kind(15)
contains
subroutine foo(a,b,c)
use ieee_arithmetic
real(kind=wp),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Andrew Pinski changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #43 from Vincent Lefèvre ---
Note that the effect of changing the rounding mode after a computation, whether
-frounding-math is used or not, is not just that the change of rounding mode
may not be honored. If can yield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #42 from Marc Glisse ---
Created attachment 46502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46502=edit
other hack
Another approach.
* lowering in an optimization pass is idiotic, it only works at -O2+, but it
shows the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #41 from joseph at codesourcery dot com ---
It's likely that caring about exceptions would actually be worse for
optimization than caring about rounding modes (because exceptions mean
that floating-point operations can write global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #40 from Richard Biener ---
(In reply to Jakub Jelinek from comment #39)
> (In reply to Richard Biener from comment #36)
> > Created attachment 46396 [details]
> > poor mans solution^Whack
> How does this work if op is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #38 from Marc Glisse ---
(In reply to Marc Glisse from comment #37)
> If you protect even constants, the current effects of -frounding-math become
> redundant.
Oops, forget that, the hack is too late for this sentence to be true,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #37 from Marc Glisse ---
(In reply to Richard Biener from comment #36)
> Created attachment 46396 [details]
> poor mans solution^Whack
>
> So this is what a hack looks like, basically sprinkling those asm()s
> throughout the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #36 from Richard Biener ---
Created attachment 46396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46396=edit
poor mans solution^Whack
So this is what a hack looks like, basically sprinkling those asm()s throughout
the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #35 from Richard Biener ---
The IFN_ way may be a possibility indeed. I believe a volunteer should first
tackle -ftrapv in this way then to see how painful an exercise this is.
Note that the issue with FENV access is not so much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #34 from Marc Glisse ---
(In reply to Richard Biener from comment #33)
> (In reply to Stefan Vigerske from comment #32)
> > Is there any hope this could actually be improved?
> > Now, 10 years later, the FENV_ACCESS pragma seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #33 from Richard Biener ---
(In reply to Stefan Vigerske from comment #32)
> Is there any hope this could actually be improved?
> Now, 10 years later, the FENV_ACCESS pragma seems to be implemented, but the
> problem here seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #32 from Stefan Vigerske ---
Is there any hope this could actually be improved?
Now, 10 years later, the FENV_ACCESS pragma seems to be implemented, but the
problem here seems to persist.
I run into this with GCC 8.3.0 and code like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Jackie Rosen jackie.rosen at hushmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #25 from Nick Maclaren nmm1 at cam dot ac.uk ---
On Jan 10 2014, vincent-gcc at vinc17 dot net wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #24 from Vincent Lefèvre vincent-gcc at vinc17 dot net -
(In reply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #26 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #25)
3.4.3 says:
undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #27 from Nick Maclaren nmm1 at cam dot ac.uk ---
On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
What explicit definition of behavior is there for the case when
STDC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #28 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #27)
On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
The FENV_ACCESS pragma provides a means to inform the implementation when a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #29 from Nick Maclaren nmm1 at cam dot ac.uk ---
On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
The FENV_ACCESS pragma provides a means to inform the implementation whe
n a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #30 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #29)
It is not an explicit definition of BEHAVIOR (my emphasis),
The pragma is just a directive. It has no additional behavior, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #24 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #23)
If __STDC_IEC_559__ is unset or does not have the value 1, setting
STDC FENV_ACCESS to on is undefined behaviour (see 6.10.8.3,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Nick Maclaren nmm1 at cam dot ac.uk changed:
What|Removed |Added
CC||nmm1 at cam dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #21 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #20)
Richard Biener's approach to the default is the one that matches the C
standard and Vincent Lefèvre is mistaken.
No, I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #22 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Mon, 11 Nov 2013, nmm1 at cam dot ac.uk wrote:
There are also very strong grounds for not wanting IEEE 754 support by
default, anyway, because of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #23 from Nick Maclaren nmm1 at cam dot ac.uk ---
(In reply to Vincent Lefèvre from comment #21)
Richard Biener's approach to the default is the one that matches the C
standard and Vincent Lefèvre is mistaken.
No, I'm correct.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||frederic.riss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||cck0011 at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-10-16 09:44
---
Turning -frounding-math on by default would be a disservice to (most of) our
users which is why the decision was made (long ago) to not enable this by
default.
--
--- Comment #14 from vincent at vinc17 dot org 2008-10-16 14:20 ---
(In reply to comment #12)
Turning -frounding-math on by default would be a disservice to (most of) our
users which is why the decision was made (long ago) to not enable this by
default.
The compiler should generate
--- Comment #13 from merkert at comcast dot net 2008-10-16 11:56 ---
Would it make sense to have a function attribute to indicate that rounding mode
was changed as a side effect? This way, one could keep the default rounding
behavior and not incur a performance penalty, but at the same
--- Comment #15 from joseph at codesourcery dot com 2008-10-16 16:39
---
Subject: Re: Optimization generates incorrect code
with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
On Thu, 16 Oct 2008, vincent at vinc17 dot org wrote:
The compiler should generate
--- Comment #16 from vincent at vinc17 dot org 2008-10-16 17:39 ---
I was suggesting to improve the behavior by having -frounding-math by default
(at least when the user compiles with -std=c99 -- if he does this, then this
means that he shows some interest in a conforming
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-15 15:43 ---
*** Bug 37838 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from vincent at vinc17 dot org 2008-10-15 21:29 ---
What was said in bug 37838 but not here is that -frounding-math sometimes fixes
the problem. So, I was suggesting that -frounding-math should be enabled by
default.
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-10-15 22:14
---
The default of -fno-rounding-math is chosen with the reason that this is what
a compiler can assume if #pragma STDC FENV_ACCESS is not turned on.
What you may request instead is an implementation of FENV_ACCESS
--- Comment #11 from vincent at vinc17 dot org 2008-10-15 22:33 ---
(In reply to comment #10)
The default of -fno-rounding-math is chosen with the reason that this is what
a compiler can assume if #pragma STDC FENV_ACCESS is not turned on.
The C standard doesn't require a compiler to
--- Comment #5 from joseph at codesourcery dot com 2008-01-06 15:12 ---
Subject: Re: Optimization generates incorrect code
with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote:
I wouldn't read the language
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-06 15:57 ---
I see. So basically we need to split all floating point operators into two
variants, one specifying a default rounding mode is used and one specifying the
rounding mode is unknown. I suppose the frontend parts
--- Comment #7 from joseph at codesourcery dot com 2008-01-06 16:28 ---
Subject: Re: Optimization generates incorrect code
with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
On Sun, 6 Jan 2008, rguenth at gcc dot gnu dot org wrote:
I see. So basically we need
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-05 11:19 ---
Sorry, -frounding-math does not help for this case - it assumes the _same_
rounding mode is in effect everywhere, but doesn't assume it is
round-to-nearest.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from merkert at comcast dot net 2008-01-05 15:38 ---
Ok, so how then would one accomplish this in std c without resorting to asm? I
still assume the original code is correct even though the rounding-math doesn't
do what I wanted.
At any rate, I played a little with it
--- Comment #3 from joseph at codesourcery dot com 2008-01-05 17:07 ---
Subject: Re: Optimization generates incorrect code
with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote:
Sorry, -frounding-math does
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-05 18:24 ---
I wouldn't read the language this way. Because that will forcefully disable
all redundancy removing optimizations (which is what happens in this testcase).
What it currently guards is expression rewriting that
49 matches
Mail list logo
