https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #8 from Armin Rigo ---
I'd like to point out that the problem only shows up with all the extra lines
of code that appear unrelated: everything before the loop, and the first half
of the loop itself (the switch-with-goto with cases 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #7 from Armin Rigo ---
Created attachment 47056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47056=edit
made the example runnable
Here is a main(). Compare:
* gcc -Og foomin3.c foomin3main.c && a.out
* gcc -O1 foomin3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #2 from Armin Rigo ---
Created attachment 47054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47054=edit
slightly different version, with comments showing the expected values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #1 from Armin Rigo ---
Comment on attachment 47053
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47053
creduce'd C source that miscompiles in -O>=1
BTW I just noticed that the reduced code is highly self-recursive, but that's
P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arigo at tunes dot org
Target Milestone: ---
Created attachment 47053
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47053=edit
creduce'd C source that miscompiles in -O>=1
The attache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79973
--- Comment #3 from Armin Rigo ---
Indeed, thanks for the feedback.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arigo at tunes dot org
Target Milestone: ---
Created attachment 40930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40930=edit
reproducer, linux x86-64, gcc -lm
atanh(x), wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70734
--- Comment #4 from Armin Rigo ---
Ah, sorry about that; I only checked the 5.x branch. My mistake.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arigo at tunes dot org
Target Milestone: ---
Tested on gcc_5_branch:
extern void abort(void);
void f(int a, int b, int *r)
{
if (__builtin_add_overflow(a, b, r))
abort
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arigo at tunes dot org
Target Milestone: ---
The following occurs in `gcc_5_branch` but not in the 5.3.0 release tag.
The C front-end misinterprets arrays of constants which are passed as function
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arigo at tunes dot org
Target Milestone: ---
Created attachment 35913
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35913action=edit
Input incorrectly compiled with gcc-5.1.0-patched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
--- Comment #1 from Armin Rigo arigo at tunes dot org ---
Update: found out that the %gs prefix is correctly present when I compile with
gcc -O1 -fno-ivopts bug1.c -S. So ivopts might be the place to look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
--- Comment #2 from Armin Rigo arigo at tunes dot org ---
Actually gcc -O1 -fno-tree-loop-optimize bug1.c -S also restores the %gs
prefix. I suspect however that this flag implies -fno-ivopts, or something.
I found no other -fno-xxx that, when
13 matches
Mail list logo
