Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes gcc trunk (and the 4.7 & 4.8 branches) to hang at -O1
or above. This seems to be different from 57381, but perhaps related.
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
rmal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
With current gcc trunk on x86_64-linux, the following code causes an ICE when
compiled at -O3 (both -m32 and -m64). This is a regression from 4.8.x.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Current gcc trunk (and gcc-4.8) produces wrong code for the following testcase
on x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes. This is a
regression from 4.7.x.
$ gcc-trunk -v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
--- Comment #2 from Zhendong Su ---
Hi Jakub, below are three additional (possibly related) testcases that may help
you folks diagnose the issue; they (including the original testcase) all
manifest differently:
-
test #2: wr
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code (which has a signed integer overflow) doesn't trap when
compiled at -O1 or above with -ftrapv on x86_64-linux. This appli
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O2
and -O3 in 32-bit mode. This is a regression from 4.8.x
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code for the following testcase on
x86_64-linux when compiled at -O3 in 32-bit mode. This is a regression from
4.8.x.
$ gcc-trunk -v
gcc version
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O2 in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -Os in
32-bit mode. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130710
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux (both 32-bit and 64-bit modes). This is a regression from
4.8.x
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in both 32-bit and 64-bit modes. This is a regression from
4.8.x.
$ gcc-trunk -v
gcc version
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux (both 32-bit and 64-bit modes). This is a
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in 32-bit mode only. This is a regression from 4.8.x.
It may be related to 58018
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux (both 32-bit and 64-bit modes). This is a
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk and gcc 4.8 produce wrong code for the following testcase
on x86_64-linux when compiled at -O3 (in both 32-bit and 64-bit modes). This is
a regression from 4.7.x.
$ gcc-trunk -v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #2 from Zhendong Su ---
Andrew, because of short-circuiting, when p >= 0, the expression "-2147483647 -
1 - p" isn't actually evaluated.
Thanks for looking into this so quickly!
Zhendong
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as gcc 4.8) produces wrong code for the
following testcase on x86_64-linux when compiled at -O3 in both 32-bit and
64-bit modes. This is a regression from 4.7.x
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code (that hangs) for the following
testcase on x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes.
This is a regression from 4.8.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227
--- Comment #2 from Zhendong Su ---
But similar to 58143, because of short circuiting (since a == 0), the
expression "0 < -2147483647 - h ? 0 : 1" shouldn't be evaluated at all,
correct? Or maybe I'm mistaken?
Thanks for looking into this Mare
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk, as well as gcc 4.7 and 4.8, produces wrong code for the
following testcase on x86_64-linux when compiled at -O3 in both 32-bit and
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as gcc 4.6, 4.7, and 4.8) produces wrong code
for the following testcase on x86_64-linux when compiled at -O1 and
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in both 32-bit and 64-bit modes. This is a
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code for the following testcase on
x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248
--- Comment #2 from Zhendong Su ---
Jakub, perhaps you used the testcase from 58247, not the one below?
I double checked and still get wrong code on this one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248
--- Comment #3 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #1)
> I get ICE instead, starting with r199048 .
This means that 58247 is probably indeed a dup of 57592, which also started
with r199048 (according to the comment on 575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248
--- Comment #5 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #4)
> No, the only change I've made to this testcase was instead of using
> printf use if (c != 1) __builtin_abort ();.
I checked the modified test case below:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248
--- Comment #8 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #6)
> Are you sure your gcc isn't configured with --enable-checking=release ?
Jakub, below is my gcc configure:
Configured with: ../gcc-trunk/configure
--enable-languag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248
--- Comment #10 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #9)
> For testing bugs against trunk it is better to omit both --disable-checking
> and --enable-checking=release and just use the default.
> Because otherwise the compil
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as gcc 4.7 and 4.8) produces wrong code for the
attached testcase on x86_64-linux when compiled at -O3 in 32-bit mode. It is a
regression from 4.6.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277
--- Comment #1 from Zhendong Su ---
Created attachment 30725
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30725&action=edit
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277
--- Comment #2 from Zhendong Su ---
I'm also attaching a related testcase (small2.c) for both 32-bit and 64-bit
modes.
$ gcc-trunk -m64 -O2 small2.c
$ a.out
$ gcc-4.6 -m64 -O3 small2.c
$ a.out
$ gcc-4.7 -m64 -O3 small2.c
$ a.out
Aborted (core du
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277
--- Comment #3 from Zhendong Su ---
Created attachment 30726
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30726&action=edit
another testcase for both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277
--- Comment #11 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #10)
> Fixed for 4.8+ so far, thanks for reporting it.
Thanks Jakub. Wow, that's quick! You folks are wonderful.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code takes much longer to compile with both -O3 and -g on using
the current gcc trunk on x86_64-linux (in both 32-bit and 64-bit modes).
4.8 is considerably faster
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58326
--- Comment #2 from Zhendong Su ---
For additional info, please find below a variant that fails only at -O3:
-
int a, b, c, d;
void foo ()
{
int e;
lbl:
for (c = 0; c < 2; c++)
{
e = d;
for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58318
--- Comment #2 from Zhendong Su ---
> did you compare trunk with --enable-checking=release?
Richard, you are right. Below is my 4.8 config:
$ gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-4.8
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8/libexec/
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 on x86_64-linux (both 32-bit and 64-bit modes).
This is a
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 with -g on x86_64-linux (both 32-bit and 64-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #4 from Zhendong Su ---
I wasn't able to reproduce the ICE using the given testcase (pt.ii) with trunk
revision 202308, but I encountered an ICE (at -O2 and -O3 with -g) in the same
source location. It's reported as 58342 with the foll
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux (both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux (both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk and
4.8 at -O1 only on x86_64-linux (both 32-bit and 64-bit modes).
This is a
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk, 4.8,
and 4.7 at -O1 and above (at only -O1 for 4.6) on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343
--- Comment #3 from Zhendong Su ---
(In reply to Jeffrey A. Law from comment #2)
...
> I've got a fix for this in testing.
Jeff, thanks very much for your explanation and quick fix.
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code for the attached testcase on
x86_64-linux-gnu when compiled at -Os and above in both 32-bit and 64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #2 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce this, neither with 64-bit nor 32-bit.
Jakub, perhaps fixed in later revisions? I tested it using 202421.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #4 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #3)
> Not even with r202421.
> Content of main with that revision for x86_64 -Os is:
> .cfi_startproc
> pushq %rcx
> .cfi_def_cfa_offset 16
> mov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #6 from Zhendong Su ---
(In reply to Richard Biener from comment #5)
> Cannot reproduce either.
>
> Maybe you got hit by Jeffs bus introducing random bits into your bootstrap?
>
> So I wonder if it reproduces for you if you rebuild G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #36 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #35)
> The #c34 testcase seems to fail starting r199048 till current HEAD.
Besides John's new testcase from #c34, I've also encountered quite a number of
different testc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #12 from Zhendong Su ---
(In reply to Jeffrey A. Law from comment #11)
> I know what's happening here. It's obscure and quite nasty.
>
> We have a jump threading opportunity which requires threading through a
> joiner block. The jum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #15 from Zhendong Su ---
(In reply to Jeffrey A. Law from comment #14)
> It's the action of executing the code with undefined behaviour which is the
> trigger. ie, if you don't execute the code, then it has no effect on the
> defined/
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code for the attached testcase on
x86_64-linux-gnu when compiled at -O2 and -O3 in 32-bit mode.
It appears to be a
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419
--- Comment #2 from Zhendong Su ---
(In reply to H.J. Lu from comment #1)
> It is caused by r202468.
So it may have been a dup of 58418?
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in both 32-bit and 64-bit modes.
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58451
--- Comment #2 from Zhendong Su ---
(In reply to Marek Polacek from comment #1)
> Should be already fixed by richi's r202644.
Verified (for 202680). Thanks.
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code takes much longer to compile at -O1 (and above) with -g
using the current gcc trunk on x86_64-linux (in both 32-bit and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58478
--- Comment #2 from Zhendong Su ---
(In reply to Marek Polacek from comment #1)
> Confirmed.
That's quick; thanks Marek!
Please also take a look at 58479 when you get a chance.
It's related (as well as 58318).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58318
--- Comment #3 from Zhendong Su ---
> A quick check with a non-bootstrapped cc1 but release checking makes the
> slowdown go away.
Richard, there is related testcase that I have just reported (58479). It
manifests also under release checking. Tha
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following testcase takes much longer to compile at -O1 and above using GCC
4.7.3 on x86_64-linux (in both 32-bit and 64-bit modes).
It does not seem to affect
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58522
--- Comment #2 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #1)
> Started with r199048, so sounds like one of the many dups of the reassoc
> scheduling bugs.
Jakub, I think you are right. I somehow forgot to check it against the p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #39 from Zhendong Su ---
*** Bug 58522 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58522
Zhendong Su changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk, 4.8,
and 4.7 at -O3 with -g enabled on x86_64
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -Os
and above in both 32-bit and 64-bit modes.
This is a
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
both 32-bit and 64-bit modes, resulting in a segfault.
This is a regression from 4.8.x.
$ gcc-trunk
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as 4.6, 4.7, and 4.8) mis-compiles the following
code on x86_64-linux at -O3 in 64-bit
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the attached testcase on x86_64-linux-gnu at
-O2 and -O3 in 64-bit mode.
It is a regression from 4.8.x.
$ gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the attached testcase on x86_64-linux at
(only) -O1 in 64-bit mode.
This is a regression from 4.8.x.
This one was quite tough to reduce. The attached testcase is the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58677
--- Comment #3 from Zhendong Su ---
(In reply to Mikael Pettersson from comment #1)
> Started with r202525 (PR58404 missed-optimization fix), stopped with r203315
> (PR58570 wrong-code fix). The cause of PR58570 was not r202525.
>
> Can you chec
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as 4.7 and 4.8) miscompiles the following code
on x86_64-linux at -Os in 64-bit mode.
This is
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code for the following testcase on
x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640
--- Comment #8 from Zhendong Su ---
(In reply to Jeffrey A. Law from comment #7)
> Fixed on trunk.
Verified (also against the original).
Thanks Jeff.
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
GCC 4.8.1 miscompiles the following code on x86_64-linux at -O3 in 64-bit mode,
resulting in a segfault.
It doesn't seem to affect the current trunk and 4.7.x.
It is related to 58653.
$ gcc-4
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux at -Os in
both 32-bit and 64-bit modes.
This is a regression from
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk and gcc 4.8 produce wrong code that hangs for the
following testcase on x86_64-linux when compiled at -O3 (in both 32-bit and
64-bit modes).
This is a regression
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The attached testcase is miscompiled by gcc 4.8.1 on x86_64-linux-gnu at -O3 in
both 32-bit and 64-bit modes.
It does not seem to affect the current gcc trunk, 4.6.x, and 4.7.x.
$ gcc-4.8 -v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58732
--- Comment #1 from Zhendong Su ---
Below is a simpler testcase that should demonstrate the same issue:
--
int printf (const char *, ...);
int a, b[2];
int
main ()
{
for (a = 1; a >= 0; a--)
{
b[1]
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following testcase is miscompiled by 4.8.2 (as well 4.8.0 and 4.8.1) on
x86_64-linux at -O3 in both 32-bit and 64-bit modes.
It
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk and 4.8.x miscompiles the following code on x86_64-linux
at -O2 and -O3 in 64-bit mode.
This is a regression from 4.7.x.
I had
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux at -O2 and
-O3 in 64-bit mode.
This is a regression from 4.8.x and may be related
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux at -Os in
64-bit mode.
This is a regression from 4.8.x.
Perhaps related to 58685 (which also affects 4.7.x and 4.8.x though)?
$ gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58831
--- Comment #16 from Zhendong Su ---
(In reply to Eric Botcazou from comment #15)
> Fixed everywhere (and twice to be really sure :-)
Verified (also against the original tests). Thanks.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following testcase on x86_64-linux-gnu at
-O3 (in both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as gcc 4.6.x, 4.7.x, and 4.8.x) produces wrong
code for the following testcase on x86_64-linux-gnu when compiled at -O1 and
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes gcc 4.8.2 (as well as gcc 4.8.0 and gcc 4.8.1) to
hang at -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58955
--- Comment #2 from Zhendong Su ---
Here is another testcase that seems related (also goes away with
-fno-tree-loop-distribute-patterns.
int printf (const char *, ...);
int a, b[10];
int
main ()
{
for (; a
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk and 4.8.x miscompile the following code on x86_64-linux
at -Os and above in 64-bit mode.
This is a regression from 4.7.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58957
--- Comment #3 from Zhendong Su ---
(In reply to Richard Biener from comment #2)
> I think it's just awfully slow (deep loop nest, possible to unroll
> completely).
> It terminates for me on the branch and for 4.8.2 and 4.8.1.
>
> tree CFG clean
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk and
4.8.2 at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -Os
and above in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following testcase on x86_64-linux-gnu at
-O3 (in both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following testcase on x86_64-linux-gnu at
-O3 (in both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as 4.6, 4.7, and 4.8) miscompiles the following
code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes.
It
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as 4.6, 4.7, and 4.8) produces poor code for the
following testcase on x86_64-linux-gnu at -Os in
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes).
This is a regression from 4.8.x
1 - 100 of 713 matches
Mail list logo
