https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #15 from GCC Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:0a339746e7646bacf2c8aa5512268d23660f26f9
commit r16-454-g0a339746e7646bacf2c8aa5512268d23660f26f9
Author: Richard Earnshaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #14 from Christophe Lyon ---
Patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #13 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2023-07-26
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #10 from Thiago Jung Bauermann
---
(In reply to Francois-Xavier Coudert from comment #8)
> (In reply to Richard Earnshaw from comment #6)
> > Is the exception status supposed to be in a defined state when the test
> > runs? Shouldn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #9 from Richard Earnshaw ---
proc add_options_for_ieee { flags } {
if { [istarget alpha*-*-*]
|| [istarget sh*-*-*] } {
return "$flags -mieee"
}
if { [istarget rx-*-*] } {
return "$flags -mnofpu"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #8 from Francois-Xavier Coudert ---
(In reply to Richard Earnshaw from comment #6)
> Is the exception status supposed to be in a defined state when the test
> runs? Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #7 from Thiago Jung Bauermann
---
(In reply to Francois-Xavier Coudert from comment #5)
> OK, so it signals FE_INVALID on the first test. Can you run this with the
> same options, and see what happens?
It ran normally:
thiago.baue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #6 from Richard Earnshaw ---
Is the exception status supposed to be in a defined state when the test runs?
Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the start of the
test?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #5 from Francois-Xavier Coudert ---
OK, so it signals FE_INVALID on the first test. Can you run this with the same
options, and see what happens?
---
#include
#include
void
ftrue (float x, float y)
{
if (!__builtin_iseqsig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #4 from Thiago Jung Bauermann
---
Thanks for looking into this.
(In reply to Francois-Xavier Coudert from comment #3)
> Do the failure only occur at -Os?
Only at -Os. The FAILs I mentioned in the bug report are the only ones that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #3 from Francois-Xavier Coudert ---
Do the failure only occur at -Os? Does it pass at -O0, -O1, -O2?
And could you possibly run builtin-iseqsig-1.c under gdb and obtain a
backtrace?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #2 from Thiago Jung Bauermann
---
Thanks for the quick response!
(In reply to Andrew Pinski from comment #1)
> Does pr91323.c fail on arm?
No, all its tests pass:
PASS: gcc.dg/torture/pr91323.c -O0 (test for excess errors)
PAS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #1 from Andrew Pinski ---
Does pr91323.c fail on arm?
15 matches
Mail list logo
