[Bug target/64364] New: gcc ICE on min() on Intel Sandy Bridge CPU if compiler built on Haswell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64364
Bug ID: 64364
Summary: gcc ICE on min() on Intel Sandy Bridge CPU if compiler
built on Haswell
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
Created attachment 34302
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34302action=edit
failing pre-processed source
I have a freshly bootstrapped gcc 4.9.2 that I built on CentOS 5.8 on an Intel
Haswell processor (4th gen Core i5). I transferred the build over to an older
machine - same OS but running a Sandy Bridge processor (2nd gen Core i5).
Compiler crashes compiling 'min()' in limits on the SB machine, but of course
compiles fine on the Haswell one.
$ cat foo.cc
#include limits
$ g++ -c ~/foo.cc
In file included from /auto/home.nas02/dhazeghi/foo.cc:1:0:
/usr/local/gcc-4.9/include/c++/4.9.2/limits:1558:7: internal compiler error:
Illegal instruction
min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
^
0x9918ff crash_signal
../../gcc-4.9.2/gcc/toplev.c:337
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure --enable-languages=c,c++ --enable-lto
--prefix=/usr/local/gcc-4.9 --with-gmp=/usr/local/gcc-4.9
--with-mpfr=/usr/local/gcc-4.9 --with-mpc=/usr/local/gcc-4.9
--with-isl=/usr/local/gcc-4.9 --with-cloog=/usr/local/gcc-4.9
Thread model: posix
gcc version 4.9.2 (GCC)
[Bug target/64364] gcc ICE on min() on Intel Sandy Bridge CPU if compiler built on Haswell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64364 --- Comment #1 from Dara Hazeghi dhazeghi at yahoo dot com --- Appears to be the same issue as bug 59463
[Bug target/57608] New: wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608
Bug ID: 57608
Summary: wrong code for expression at -O3 on x86_64-linux-gnu
with -m32
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
Current gcc trunk and 4.8.x 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.7.x.
$ gcc-trunk -v
gcc version 4.9.0 20130613 (experimental) [trunk revision 200065] (GCC)
$ gcc-trunk -O2 -m32 wrong.c
$ ./a.out
2
$ gcc-4.7 -O3 -m32 wrong.c
$ ./a.out
2
$ gcc-trunk -O3 -m32 wrong.c
$ ./a.out
3
$
--
int printf(const char *, ...);
int a, b, d, e, *f = b;
long long l, *pl = l;
char c, *pc = c;
int bar(int r, long long s) {
b++;
a = 0;
if (b) {
b = r + s;
b++;
return c;
}
{
int arr[] = {};
return 0;
}
}
void foo(int j) {
int k;
for (; j != 5; ++j) {
*pc = *f;
for (; e != 1; e++) {
*pl = 0;
{
int i = 0;
for (; i 1; i++)
a = 0;
}
k = bar(d, 1);
d = bar(1, k);
}
}
}
void baz() { foo(0); }
int main() {
foo(0);
printf(%d\n, c);
return 0;
}
[Bug tree-optimization/57592] New: ICE in tree_unroll_loops_completely at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57592
Bug ID: 57592
Summary: ICE in tree_unroll_loops_completely at -O3
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
With current gcc trunk on x86_64-linux, the following code causes an ICE when
compiled at -O3. This is a regression from 4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130611 (experimental) [trunk revision 199947] (GCC)
$ gcc-trunk -m32 -O2 -c ice.c
$ gcc-4.8 -m32 -O3 -c ice.c
$ gcc-trunk -m32 -O3 -c ice.c
ice.c: In function ‘f’:
ice.c:4:1: internal compiler error: Segmentation fault
f ()
^
0x7d419f crash_signal
../../gcc-trunk/gcc/toplev.c:333
0x7fc29b ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:314
0x7fc560 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:362
0x81585a get_reaching_def
../../gcc-trunk/gcc/tree-into-ssa.c:1184
0x81b9db maybe_replace_use
../../gcc-trunk/gcc/tree-into-ssa.c:1784
0x81b9db rewrite_update_stmt
../../gcc-trunk/gcc/tree-into-ssa.c:1967
0x81b9db rewrite_update_enter_block
../../gcc-trunk/gcc/tree-into-ssa.c:2136
0xb3561a walk_dominator_tree(dom_walk_data*, basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:210
0x814563 rewrite_blocks
../../gcc-trunk/gcc/tree-into-ssa.c:2216
0x81ac8e update_ssa(unsigned int)
../../gcc-trunk/gcc/tree-into-ssa.c:3303
0xb99fe4 tree_unroll_loops_completely(bool, bool)
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.c:1207
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
-
int a, b, c;
void
f ()
{
int d, e;
a = 0;
for (; a = 1; a++)
{
e = 4;
for (; e; e--)
{
d |= c b++;
c = 0;
}
}
g (d);
}
[Bug rtl-optimization/57568] [4.8/4.9 Regression] wrong code for assignment in conditional at -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57568 --- Comment #4 from Dara Hazeghi dhazeghi at yahoo dot com --- Wow, that was fast! Confirmed fixed, thanks.
[Bug rtl-optimization/57568] New: wrong code for assignment in conditional at -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57568
Bug ID: 57568
Summary: wrong code for assignment in conditional at -Os
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled by gcc trunk and 4.8 on x86_64-linux at -Os
and above optimization levels in 32-bit mode (should print nothing). This is a
regression from 4.7.x.
$ gcc-trunk -v
gcc version 4.9.0 20130608 (experimental) [trunk revision 199849] (GCC)
$ gcc-trunk -O1 -m32 reduced.c
$ ./a.out
$ gcc-4.7 -Os -m32 reduced.c
$ ./a.out
$ gcc-trunk -Os -m32 reduced.c
$ ./a.out
1
$
---
int printf (const char *, ...);
int a[6][9] = {};
int b = 1;
int *c = a[3][5];
int main ()
{
if (b)
if (*c = *c + *c)
printf (%d\n, a[3][5]);
return 0;
}
[Bug rtl-optimization/57569] New: wrong code for struct copy at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57569
Bug ID: 57569
Summary: wrong code for struct copy at -O3 on x86_64-linux
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled with current gcc-trunk on x86_64-linux at -O3
optimization level in 32-bit mode, outputting garbage (rather than 0). This is
a regression from 4.7.
$ gcc-trunk -v
gcc version 4.9.0 20130608 (experimental) [trunk revision 199849] (GCC)
$ gcc-trunk -O2 -m32 reduced.c
$ ./a.out
0
$ gcc-4.7 -O3 -m32 reduced.c
$ ./a.out
0
$ gcc-trunk -O3 -m32 reduced.c
$ ./a.out
134519796
int printf (const char *, ...);
struct S { int f0; } a;
int b, e, *d = b, f;
void
fn1 ()
{
int **g[9][6];
int ***h = g[6][3];
for (; e 9; e++) {
f = 0;
for (; f 6; f++)
g[e][f] = d;
}
***h = 0;
}
void
fn2 ()
{
fn1 ();
struct S c[4][10] = {};
a = c[3][9];
}
int
main ()
{
fn2 ();
printf (%d\n, a.f0);
return 0;
}
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 Dara Hazeghi dhazeghi at yahoo dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Dara Hazeghi dhazeghi at yahoo dot com --- I think I've managed to wrap my head around the discussion of DR 236, and I agree that the code submitted is indeed undefined. Thanks for the discussion and explanations.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #17 from Dara Hazeghi dhazeghi at yahoo dot com --- (In reply to m...@gcc.gnu.org from comment #16) Yes please. If you can run: dwarfdump --eh-frame --verify file.o on all the .o files and see if there are any more lurking in there. Any that fail verification will need to be fixed, one way, or another. From gcc/ I see the following: 1 errors found in EH frame for dfp.o (x86_64). 1 errors found in EH frame for gengtype-state.o (x86_64). 1 errors found in EH frame for hooks.o (x86_64). 3 errors found in EH frame for i386.o (x86_64). 3 errors found in EH frame for insn-output.o (x86_64). 2 errors found in EH frame for langhooks.o (x86_64). 1 errors found in EH frame for sched-deps.o (x86_64). 9 errors found in EH frame for targhooks.o (x86_64). 1 errors found in EH frame for tree-profile.o (x86_64). 1 errors found in EH frame for tree-ssa-loop-im.o (x86_64). 2 errors found in EH frame for tree.o (x86_64). 1 errors found in EH frame for var-tracking.o (x86_64). Shall I upload the object code or the assembly code?
[Bug tree-optimization/57521] New: wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521
Bug ID: 57521
Summary: wrong code for expressions in loop at -O3
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled with current gcc trunk at -O3 optimization on
x86_64-linux. I've tried to reduce it somewhat from the original form. Note
that 'e' is only touched in one place. This also fails on 4.7 and 4.8 and is a
regression from gcc 4.6.
$ gcc-trunk -v
gcc version 4.9.0 20130603 (experimental) [trunk revision 199601] (GCC)
$ gcc-trunk -O2 wrong.c
$ ./a.out
1
$ gcc-4.6 -O3 wrong.c
$ ./a.out
1
$ gcc-trunk -O3 wrong.c
$ ./a.out
0
$
--
int printf (const char *, ...);
int a, b, c, d, o = 1, p;
short e;
int
fn1 (int * p1)
{
int f, g, h, j = 0, k = 0, l = 0;
unsigned int i;
int *m[1] = { l };
for (; b = 0; b--)
{
if (*p1)
if (j = 0)
{
int n = 1;
e = 1;
h = a ? a : 1 % n;
g = h 0 ? 0 : h + 1;
k = c + g;
}
else
continue;
else
{
f = d 0 ? 0 : d + 1;
i = f;
j = 1 + i;
}
l++;
}
return k;
}
int
main ()
{
for (;; p++)
{
fn1 (o);
break;
}
printf (%d\n, e);
return 0;
}
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #8 from Dara Hazeghi dhazeghi at yahoo dot com ---
Okay, here is I think a more clear example. However, from what Jakub says
above, this is probably undefined.
int printf(const char *, ...);
union
{
int i;
long long ll;
} u;
long long *pll = u.ll;
int *pi = u.i;
int a = 1, *pa = a;
void
foo ()
{
int i = 0;
for (; i = 1; i++)
{
*pll = a;
*pi = 0;
a = *pa;
}
}
int
main ()
{
foo ();
printf (%d\n, u.i);
return 0;
}
[Bug tree-optimization/57488] New: [4.9 regression] loop terminates early at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57488
Bug ID: 57488
Summary: [4.9 regression] loop terminates early at -O3
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled with current gcc trunk at -O3 on x86_64-linux
in both 32 and 64-bit modes. The innermost loop in foo should execute 48
times, but at -O3 it does not (note the only place 'v' is touched is in that
loop). I've tried reducing the testcase further, but any perturabation seems
to hide the bug.
$ gcc-trunk -v
gcc version 4.9.0 20130531 (experimental) [trunk revision 199531] (GCC)
$ gcc-trunk -O2 wrong.c
$ ./a.out
0
$ gcc-4.8 -O3 wrong.c
$ ./a.out
0
$ gcc-trunk -O3 wrong.c
$ ./a.out
24
$
---
int printf(const char *, ...);
int i, j, *pj = j, **ppj = pj;
int x, *px = x;
short s, *ps = s, k;
unsigned short u, *pu = u, **ppu = pu;
char c, *pc = c;
unsigned char v = 48;
int
bar (int p)
{
p = k;
*px = **ppu = i;
*ppj = p;
if (**ppj)
*pj = p;
return p;
}
void
foo ()
{
for (; i = 3; i++)
for (; j; j--);
u ^= bar (*pj);
for (k = 1; k = 0; k--)
{
int l;
bar (0);
for (l = 1; l 5; l++)
{
int m;
for (m = 6; m; m--)
{
v--;
*ps = *pc;
}
}
}
}
int
main ()
{
foo ();
printf (%d\n, v);
return 0;
}
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #13 from Dara Hazeghi dhazeghi at yahoo dot com --- (In reply to m...@gcc.gnu.org from comment #12) Ok, new theory. Does this patch fix it for you: Thanks for the patch. Just tried bootstrapping with it and checking disabled, and the same assertion still triggers.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #15 from Dara Hazeghi dhazeghi at yahoo dot com --- (In reply to m...@gcc.gnu.org from comment #14) Thanks, how about this one? Seems to be the same - assert in the same spot. Shall I upload the varasm.s produced with the second patch?
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 --- Comment #5 from Dara Hazeghi dhazeghi at yahoo dot com --- Sorry to ask again on this, but after re-reading, I'm not sure I understand the type-punning argument here: **ppll = ll; // write to u.ll *k = 0; // write to u.i j = *ppa; // u not touched ia[0][0] = *j; // u not touched printf(%d\n, u.i); // read from u.i From what I can tell, this is in fact reading the last member written to (so not falling under the unspecified behaviors listed in annex J / 6.2.6.1). Perhaps there is an additional restriction I am missing?
[Bug tree-optimization/57441] New: ICE in gimple-ssa-strength-reduction.c:3447 at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441
Bug ID: 57441
Summary: ICE in gimple-ssa-strength-reduction.c:3447 at -O3
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code causes current gcc trunk to ICE when built at -O3 on
x86_64-linux. This is a regression from gcc 4.8 which compiles successfully.
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130528 (experimental) [trunk revision 199374] (GCC)
$ gcc-trunk -O2 -c crash.c
$ gcc-4.8 -O3 -c crash.c
$ gcc-trunk -O3 -c crash.c
*** glibc detected ***
/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1: free():
invalid next size (fast): 0x01ecd450 ***
crash.c: In function ‘func_1’:
crash.c:11:1: internal compiler error: Aborted
func_1 ()
^
0x7cbaef crash_signal
../../gcc-trunk/gcc/toplev.c:333
0xb3246c analyze_candidates_and_replace
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:3398
0xb3246c execute_strength_reduction
../../gcc-trunk/gcc/gimple-ssa-strength-reduction.c:3447
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
-
int a, c, d, *e;
unsigned char b;
char
baz (char p1)
{
return p1 * a;
}
void func_65 ();
func_1 ()
{
func_65 ();
func_65 ();
}
void
func_65 ()
{
d = baz (b--);
if (*e)
b--;
c = 0;
}
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #4 from Dara Hazeghi dhazeghi at yahoo dot com --- Aha! I will try using plain make and leaving checking alone. I don't suppose this is documented anywhere? As to reporting the bug to Apple, is this in fact a linker bug, as opposed to a bad-code-generation bug?
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #5 from Dara Hazeghi dhazeghi at yahoo dot com --- (In reply to Dara Hazeghi from comment #4) Aha! I will try using plain make and leaving checking alone. I don't suppose this is documented anywhere? make (not bootstrap) with --enable-checking=release does work. I'll try again with bootstrap-lean to verify whether checking is the sole cause of the failure.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #7 from Dara Hazeghi dhazeghi at yahoo dot com --- (In reply to Jack Howarth from comment #6) I've opened radar://14005298, linker crash when building FSF gcc with --disable-checking with a standalone test case of the failing linkage of cc1. Thanks a bunch! make bootstrap-lean works fine with --enable-checking=release, so the checking is definitely the cause here.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #10 from Dara Hazeghi dhazeghi at yahoo dot com --- Created attachment 30211 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30211action=edit varasm.s.gz varasm.s resulting in the crash
[Bug bootstrap/57438] New: bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 Bug ID: 57438 Summary: bootstrap fails on x86_64 darwin in stage2 linking cc1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dhazeghi at yahoo dot com Created attachment 30206 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30206action=edit config.log.gz As mentioned on gcc-help (http://gcc.gnu.org/ml/gcc-help/2013-05/msg00120.html), bootstrap of gcc trunk (and 4.8 as well) has been failing for me on x86_64-darwin. System is running OS X 10.8.3, with newest XCode 4.6.1 and associated tools. I've run into the problem on two different machines. $ ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking --prefix=/usr/local/gcc-trunk $ make bootstrap-lean ... /Users/dara/Downloads/objdir/./prev-gcc/xg++ -B/Users/dara/Downloads/objdir/./prev-gcc/ -B/usr/local/gcc-trunk/x86_64-apple-darwin12.3.0/bin/ -nostdinc++ -B/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/src/.libs -B/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/libsupc++/.libs -I/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/include/x86_64-apple-darwin12.3.0 -I/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/include -I/Users/dara/Downloads/gcc-trunk/libstdc++-v3/libsupc++ -L/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/src/.libs -L/Users/dara/Downloads/objdir/prev-x86_64-apple-darwin12.3.0/libstdc++-v3/libsupc++/.libs -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o tree-mudflap.o i386-c.o darwin-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/local/gcc-trunk/lib -lcloog-isl -L/usr/local/gcc-trunk/lib -lisl -L/usr/local/gcc-trunk/lib -L/usr/local/gcc-trunk/lib -L/usr/local/gcc-trunk/lib -lmpc -lmpfr -lgmp -L../zlib -lz 0 0x102b49098 __assert_rtn + 144 1 0x102b60334 mach_o::relocatable::Parserx86_64::parse(mach_o::relocatable::ParserOptions const) + 1044 2 0x102b4ff4b mach_o::relocatable::Parserx86_64::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const) + 313 3 0x102b4dadc mach_o::relocatable::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const) + 208 4 0x102b6f74c archive::Filex86_64::makeObjectFileForMember(archive::Filex86_64::Entry const*) const + 794 5 0x102b6f261 archive::Filex86_64::justInTimeforEachAtom(char const*, ld::File::AtomHandler) const + 139 6 0x102b7fb06 ld::tool::InputFiles::searchLibraries(char const*, bool, bool, bool, ld::File::AtomHandler) const + 210 7 0x102b86978 ld::tool::Resolver::resolveUndefines() + 200 8 0x102b888a3 ld::tool::Resolver::resolve() + 75 9 0x102b49380 main + 370 A linker snapshot was created at: /tmp/cc1-2013-04-27-193733.ld-snapshot ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse, file /SourceCache/ld64/ld64-136/src/ld/parsers/macho_relocatable_file.cpp, line 1555. collect2: error: ld returned 1 exit status make[3]: *** [cc1] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [bootstrap-lean] Error 2
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 --- Comment #3 from Dara Hazeghi dhazeghi at yahoo dot com --- My apologies for the invalid report and thank you for the clear explanation. I've been using frama-c to check validity of the testcases, but clearly in this case it's not sufficient.
[Bug rtl-optimization/57381] New: array of volatile pointers hangs gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57381
Bug ID: 57381
Summary: array of volatile pointers hangs gcc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code causes gcc trunk and 4.8 branch to hang at -O1 or above due
to it consuming all available memory (well over 2GB after 10 seconds).
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 20130522 (experimental) [trunk revision 199191] (GCC)
$ time gcc-trunk -O0 -c small.c
real0m0.023s
user0m0.008s
sys0m0.008s
$ time gcc-4.7 -O1 -c small.c
real0m0.028s
user0m0.004s
sys0m0.016s
$ time timeout 10 gcc-trunk -O1 -c small.c
real0m10.002s
user0m0.000s
sys0m0.004s
$ echo $?
124
--
struct S0 { int f0, f1, f2; };
struct S1 {
int f0;
volatile struct S0 f2;
};
static struct S1 s = {0x47BED265,{0x06D4EB3E,5,0U}};
int foo(struct S0 p)
{
for (s.f2.f2 = 0; (s.f2.f2 = 12); s.f2.f2++)
{
volatile int *l_61[5][2][2] =
{{{s.f2.f0,s.f2.f0},{s.f2.f0,s.f2.f0}},{{s.f2.f0,s.f2.f0},{s.f2.f0,s.f2.f0}},{{s.f2.f0,(void*)0},{s.f2.f0,s.f2.f0}},{{s.f2.f0,s.f2.f0},{s.f2.f0,s.f2.f0}},{{s.f2.f0,s.f2.f0},{(void*)0,s.f2.f0}}};
volatile int **l_68 = l_61[0][0][1];
volatile int *l_76 = s.f2.f0;
(*l_68) = l_61[0][0][0];
if ((*l_76 = (p.f2 % 5))) ;
}
return p.f0;
}
[Bug rtl-optimization/57359] New: wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug ID: 57359
Summary: wrong code for union access at -O3 on x86_64-linux
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled with current gcc 4.8 branch and trunk at -O3
on x86_64-linux. The last write to the union appears to be getting removed (*k
= 0), so that the program outputs '1' instead of '0'. This behavior does not
occur on 4.7.
$ gcc-trunk -v
gcc version 4.9.0 20130521 (experimental) [trunk revision 199148] (GCC)
$ gcc-trunk -O2 wrong.c
$ ./a.out
0
$ gcc-4.7 -O3 wrong.c
$ ./a.out
0
$ gcc-trunk -O3 wrong.c
$ ./a.out
1
$
---
int printf(const char *, ...);
union
{
int i;
long long ll;
} u;
unsigned int i;
int a;
int *pa = a;
int **ppa = pa;
int ia[1][1];
long long *la[][1][1] = { {}, {}, {}, {}, 0, u.ll };
long long **ppll = la[4][1][0];
long long ll = 1;
void
foo ()
{
for (; i = 1; i++)
{
int *j;
int *k = u.i;
**ppll = ll;
*k = 0;
j = *ppa;
ia[0][0] = *j;
}
}
int
main ()
{
foo ();
printf (%d\n, u.i);
return 0;
}
[Bug target/57341] New: wrong code on x86_64-linux at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
Bug ID: 57341
Summary: wrong code on x86_64-linux at -O3 in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled on gcc trunk and 4.8 branch on
x86_64-linux-gnu, at -O3 optimization level, in 32-bit mode, resulting in
output of 0 rather than 1. It is compiled correctly at all optimization levels
with gcc 4.7.
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O2 -m32 wrong.c
$ ./a.out
1
$ gcc-trunk -O3 -m64 wrong.c
$ ./a.out
1
$ gcc-4.7 -O3 -m32 wrong.c
$ ./a.out
1
$ gcc-trunk -O3 -m32 wrong.c
$ ./a.out
0
---
int printf(const char *, ...);
int a, d;
int *b = a, **c;
int main ()
{
int e;
{
int f[4];
for (d = 0; d 4; d++)
f[d] = 1;
e = f[1];
}
int *g[28] = { };
*b = e;
c = g[0];
printf (%d\n, a);
return 0;
}
[Bug rtl-optimization/57343] New: wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
Bug ID: 57343
Summary: wrong code on x86_64-linux at -Os and above
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled on x86_64-linux at -Os and above with gcc
trunk and at -O2 and above with gcc 4.8. It outputs 0 rather than 4 as it
should. It works correctly with gcc 4.7.
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O1 wrong.c
$ ./a.out
4
$ gcc-4.7 -Os wrong.c
$ ./a.out
4
$ gcc-trunk -Os wrong.c
$ ./a.out
0
$
--
int printf (const char *, ...);
int a[6];
int b, c, d, e;
int f[10] = { 0, 0, 0, 0, 0, 1075L };
int *g = f[5];
char h;
unsigned i;
void
fn1 (int p1)
{
b = a[p1];
}
int
main ()
{
for (; e 6; e++)
a[e] = e;
i = -14;
for (; i = 8; i++)
{
d = --c;
h = d * 100L;
if (h);
else
{
*g = 0;
break;
}
}
fn1 (f[5] 8 15);
printf (%d\n, b);
return 0;
}
[Bug target/57344] New: wrong code with pragma pack(1) and -O1 on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57344
Bug ID: 57344
Summary: wrong code with pragma pack(1) and -O1 on x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code produces wrong output on x86_64-linux-gnu in 32-bit mode,
when compiled at -O1 or higher optimizations. It appears that the behavior
changed between gcc 4.6 which works at all optimization levels, and 4.7 which
does not.
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O0 -m32 wrong.c
$ ./a.out
-3161
$ gcc-trunk -O1 -m64 wrong.c
$ ./a.out
-3161
$ gcc-4.6 -O1 -m32 wrong.c
$ ./a.out
-3161
$ gcc-trunk -O1 -m32 wrong.c
$ ./a.out
2093991
$
--
int printf(const char *, ...);
#pragma pack(1)
struct S0
{
int f0:11;
int f1:22;
char f2;
int:0;
}
s[2];
int i;
int
main ()
{
struct S0 tmp = { 0, -3161L };
s[1] = tmp;
for (; i 1; i++)
printf (%d\n, s[1].f1);
return 0;
}
[Bug rtl-optimization/57347] New: wrong code for bitfield on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347
Bug ID: 57347
Summary: wrong code for bitfield on x86_64-linux at -Os and
above
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled on x86_64-linux with gcc trunk and 4.8 at -Os
and above optimization level. It works correctly with gcc 4.7 (outputs 1).
$ gcc-trunk -v
gcc version 4.9.0 20130520 (experimental) [trunk revision 199099] (GCC)
$ gcc-trunk -O1 wrong.c
$ ./a.out
1
$ gcc-4.7 -Os wrong.c
$ ./a.out
1
$ gcc-trunk -Os wrong.c
$ ./a.out
0
$
-
int printf(const char *, ...);
struct S1 {
int f0;
int f1 : 10;
int f2 : 13;
};
int i;
int *j = i;
static void foo(struct S1 s) {
int *p;
int l[88];
int **pp = p;
*pp = l[1];
l[0] = 1;
*j = 1 s.f2;
}
int main(void) {
struct S1 s = { 0, 0, 1 };
foo(s);
printf(%d\n, i);
return 0;
}
[Bug tree-optimization/57318] New: optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318
Bug ID: 57318
Summary: optimizer takes several seconds on nested loops
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
Current gcc trunk takes 5 seconds to compile this testcase at -O2 or higher
optimization level on x86_64-linux-gnu (2.8GHZ Intel i7). This was distilled
from larger program which appears to hang gcc, although I suspect it is
actually just extremely slow.
This behavior is not present in 4.8 and older versions.
$ gcc-trunk -v
gcc version 4.9.0 20130517 (experimental) [trunk revision 199006] (GCC)
$ gcc-trunk -Os hang.c
$ time gcc-4.8 -O2 hang.c
real0m0.101s
user0m0.072s
sys0m0.016s
$ time gcc-trunk -O2 hang.c
real0m5.289s
user0m5.232s
sys0m0.024s
---
struct S0
{
volatile int f0;
short f1;
} u;
int a, b;
static struct S0 v;
int main ()
{
for (a = 0; a = 9; a++)
{
for (b = 0; b = 9; b++)
for (u.f1 = 0; u.f1 = 9; u.f1++)
v.f0;
}
}
[Bug rtl-optimization/57321] New: static function call miscompiled at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57321
Bug ID: 57321
Summary: static function call miscompiled at -Os and above
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The testcase below is miscompiled by gcc 4.8 on x86_64-linux, resulting in a
segfault when built with -Os or higher optimization levels. This does not
occur with gcc 4.7 or current trunk. The segfault appears on line 8, where p
is dereferenced and compared.
$ gcc-4.8 -v
gcc version 4.8.0 (GCC)
$ gcc-4.8 -O1 small.c
$ ./a.out
$ gcc-4.7 -Os small.c
$ ./a.out
$ gcc-4.8 -Os small.c
$ ./a.out
Segmentation fault (core dumped)
int a = 1;
int *b;
int **c;
static int
bar(int *p)
{
if (*p == a)
{
int *i[7][1][9] = {{{ 0 }}};
int **j[1][1][1];
j[0][0][0] = i[0][0][0] ;
*b = p != c;
}
return 0;
}
void
foo(int p, int q)
{
int i = 0;
if (bar (i))
;
}
int
main()
{
foo (0, 0);
return 0;
}
[Bug rtl-optimization/57303] New: struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
Bug ID: 57303
Summary: struct miscompiled at -O1 and above
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
With current gcc trunk, the code below is miscompiled at -O1 and higher
optimization levels on x86_64-linux-gnu, outputting '1' instead of '0' as
expected. This behavior appears in gcc 4.8.x and 4.7.x as well, but not in
4.6.x or earlier. It occurs in both 32-bit and 64-bit compiles.
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130516 (experimental) [trunk revision 198967] (GCC)
$ gcc-trunk -O0 small.c
$ ./a.out
0
$ gcc-4.6 -O1 small.c
$ ./a.out
0
$ gcc-trunk -O1 small.c
$ ./a.out
1
$
-
int printf(const char *, ...);
struct S0
{
int f0;
};
struct S1
{
struct S0 f0;
};
struct S1 x = { {0} };
struct S1 y = { {1} };
static void
foo (struct S0 p)
{
struct S0 *l = y.f0;
*l = x.f0;
if (p.f0)
*l = *l;
}
int
main ()
{
foo(y.f0);
printf(%d\n, y.f0.f0);
return 0;
}
[Bug rtl-optimization/57300] New: statement in expression miscompiled at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57300
Bug ID: 57300
Summary: statement in expression miscompiled at -O3 in 32-bit
mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following testcase appears to be miscompiled with gcc 4.8 and trunk on
x86_64-linux-gnu at -O3 optimization level in 32-bit mode. In 64-bit mode, at
lower optimization, or with gcc 4.7 and earlier it works correctly.
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
...
gcc version 4.9.0 20130515 (experimental) [trunk revision 198926] (GCC)
$ gcc-trunk -O2 -m32 small.c
$ ./a.out
1
$ gcc-trunk -O3 -m64 small.c
$ ./a.out
1
$ gcc-4.7 -O3 -m32 small.c
$ ./a.out
1
$ gcc-trunk -O3 -m32 small.c
$ ./a.out
0
$
--
int printf (const char *, ...);
int a, b, e;
long long c;
int d[10];
int
main ()
{
int *f = a;
e = 0;
for (; e 10; e++)
d[e] = 1;
if (d[0])
c = (
{
int g = *f = (
{
b == 0 || 1 % b;
});
g;
}
);
printf (%d\n, a);
return 0;
}
[Bug target/57281] New: x86_64-linux loop fails to terminate at -O3 -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
Bug ID: 57281
Summary: x86_64-linux loop fails to terminate at -O3 -m32
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The testcase below is miscompiled with current gcc trunk at -O3 optimization
level in 32-bit mode on x86_64-linux-gnu, and fails to terminate. With other
optimizations levels in 64-bit mode, it executes successfully. This is a
regression from 4.8, where the code works at all optimizations levels.
$ gcc-trunk -v
...
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 20130514 (experimental) [trunk revision 198875] (GCC)
$ gcc-trunk -O2 -m32 test.c
$ ./a.out
$ gcc-4.8 -O3 -m32 test.c
$ ./a.out
$ gcc-trunk -O3 -m32 test
$ ./a.out
hangs
--
int a = 1, b = 0, d;
long long c;
int *e = d;
volatile long long f;
long long *g = c;
int foo(int h)
{
int j = *g = b;
return h == 0 ? j : 0;
}
int
main ()
{
int h = a;
for (; b != -20; b--)
{
int i = f;
*e = 0;
*e = foo(h);
}
return 0;
}
[Bug tree-optimization/57268] New: c nested loops hang compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268 Bug ID: 57268 Summary: c nested loops hang compiler Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dhazeghi at yahoo dot com Created attachment 30106 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30106action=edit testcase The attached testcase causes current gcc trunk to hang on x86_64-unknown-linux-gnu, when compiled at -O2 or higher optimization levels. It compiles successfully with gcc 4.8. I have not succeeded in reducing the testcase to a manageable size. $ gcc-trunk -v gcc-trunk (GCC) 4.9.0 20130513 (experimental) [trunk revision 198822] ... $ gcc-trunk -Os -w test.c $ gcc-4.8 -O2 -w test.c $ gcc-trunk -O2 -w test.c hangs
[Bug tree-optimization/56576] New: wrong code for aliased union at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56576
Bug #: 56576
Summary: wrong code for aliased union at -O3
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following code behaves differently at -O3 than at -O2 or below on 4.7 and
mainline on x86_64-linux. At -O3 it returns 1, whereas at -O2 and below it
returns 0, for both -m32 and -m64 targets.
It behaves as expected on gcc 4.6 at all optimization levels (returns 0).
$ gcc-trunk --version
gcc-trunk (GCC) 4.8.0 20130308 (experimental) [trunk revision 196555]
$ gcc-trunk -O2 trans-reduced.c
$ ./a.out
$ echo $?
0
$ gcc-trunk -O3 trans-reduced.c
$ ./a.out
$ echo $?
1
$ gcc-4.6 -O3 trans-reduced.c
$ ./a.out
$ echo $?
0
$ cat trans-reduced.c
/* gcc-4.7/gcc-trunk -O3 -m32/-m64 */
union
{
int f0;
int f1;
long f2;
}
a, b;
int c, h;
int *d, *e = a.f0;
long *f = b.f2;
int **g = d;
void fn1 ()
{
c = 0;
for (; c = 3; c++)
{
int *i = b.f1;
*f = 1;
*i = 0;
*g = 0;
h = *e;
}
}
int main ()
{
fn1 ();
return b.f0;
}
[Bug tree-optimization/56577] New: wrong code for aliased union on gcc 4.7 only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56577
Bug #: 56577
Summary: wrong code for aliased union on gcc 4.7 only
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following code behaves differently at -O3 than at -O2 or below on 4.7 on
x86_64-linux. At -O3 it returns 1, whereas at -O2 and below it
returns 0, for both -m32 and -m64 targets.
It behaves consistently on gcc 4.6 at all optimization levels (returns 0). It
may be related to 56576 (derived from a similar testcase) but that bug is also
present on mainline.
$ gcc-4.7 --version
gcc-4.7 (GCC) 4.7.2
$ gcc-4.7 -O2 orig-reduced.c
$ ./a.out
$ echo $?
0
$ gcc-4.7 -O3 orig-reduced.c
$ ./a.out
$ echo $?
1
$ gcc-4.6 -O3 orig-reduced.c
$ ./a.out
$ echo $?
0
$ cat orig-reduced.c
/* gcc-4.7 -O3 -m32/-m64 (works with trunk or at -O2) */
union
{
int f0;
int f1;
long f2;
}
b, *g, **i = g;
int a, m;
int *c = (int *)b.f2, *e, *f = a;
int d;
int h;
long **j = (long **)c;
int k;
int **l = e;
void fn1 ()
{
d = 0;
for (; d = 3; d++)
{
k = 0;
for (; k = 3; k++)
{
int *n = b.f1;
*i = 0;
**j = 1;
*n = 0;
*l = 0;
}
m = *f;
a = 1;
for (; a = 0; a--)
h = 1;
}
}
int main ()
{
fn1 ();
return b.f0;
}
[Bug tree-optimization/56486] [4.6/4.7 Regression] infinite loop in cc1 at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56486 Dara Hazeghi dhazeghi at yahoo dot com changed: What|Removed |Added Summary|[4.6/4.7 Regression]|[4.6/4.7 Regression] |infinite loop in cc1 at -O1 |infinite loop in cc1 at -O1 |and above | --- Comment #4 from Dara Hazeghi dhazeghi at yahoo dot com 2013-03-04 20:59:27 UTC --- (In reply to comment #3) I suppose hangs == just takes very long. You're correct - 285 seconds on a 2.8GHZ i7. It's also only at -O1.
[Bug tree-optimization/56501] New: gcc 4.6 ICE on noreturn function at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56501
Bug #: 56501
Summary: gcc 4.6 ICE on noreturn function at -Os and above
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following testcase (derived from gzip) triggers an internal compiler error
with gcc 4.6, 4.5 and 4.4 when compiled at -Os or higher on x86_64-linux. The
problem does not occur with 4.7 or newer, or with 4.3 or older.
$ gcc-4.6 --version
gcc-4.6 (GCC) 4.6.3
$ gcc-4.6 -O1 -w small.c
$ gcc-4.6 -Os -w small.c
small.c: In function ‘main’:
small.c:24:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ cat small.c
int a;
void try_help () __attribute__ ((__noreturn__));
void try_help ()
{
}
int main ()
{
switch (a)
{
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
case '8':
case '9':
break;
default:
try_help ();
}
}
[Bug tree-optimization/56486] New: infinite loop in cc1 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56486 Bug #: 56486 Summary: infinite loop in cc1 at -O1 and above Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dhaze...@yahoo.com The following code (generated by csmith) causes gcc 4.6.3 and 4.7.2 to go into an infinite loop when compiled at -O1 or higher. This does not occur with current trunk or gcc 4.5.4 (although 4.5.4 does take about 10 seconds to compile it), so technically this is a regression on 4.6 and 4.7. An attempt to use creduce to reduce it failed as end-result no longer hangs (it does take 10 seconds to compile though). $ gcc-4.7 --version gcc-4.7 (GCC) 4.7.2 $ gcc-4.5 -O1 crash.i $ gcc-trunk -O1 crash.i $ gcc-4.7 -O1 crash.i hangs
[Bug tree-optimization/56486] infinite loop in cc1 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56486 --- Comment #1 from Dara Hazeghi dhazeghi at yahoo dot com 2013-02-28 22:37:44 UTC --- Created attachment 29556 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29556 hanging testcase
[Bug target/56487] New: SSE2 code crashes when compiled at -O0 -m32 -msse2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56487
Bug #: 56487
Summary: SSE2 code crashes when compiled at -O0 -m32 -msse2
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following code (simplified from an SSE testcase0 crashes when compiled with
-m32 -msse2 -O0 on all gcc 4.x versions including mainline. With optimization
enabled, or with gcc 3.x, it executes successfully. Host/target is
x86_64-unknown-linux-gnu.
$ gcc-trunk --version
gcc-trunk (GCC) 4.8.0 20130228 (experimental) [trunk revision 196339]
$ gcc-trunk -m32 -msse2 -O1 sse-isamax.c
$ ./a.out
$ gcc-trunk -m32 -msse2 -O0 sse-isamax.c
$ ./a.out
Segmentation fault (core dumped)
$ cat sse-isamax.c
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_load_ps (float const *__P)
{
return (__m128) *(__v4sf *)__P;
}
void exit(int);
int isamax0(float *x)
{
__m128 V0;
V0 = _mm_load_ps(x);
exit(0);
return (int)(*x + 4);
}
int main()
{
float x[4];
int i;
for(i=0;i4;i++)
x[i] = -2.0 + (float) i;
return isamax0(x);
}
[Bug tree-optimization/56488] New: wrong code for loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56488
Bug #: 56488
Summary: wrong code for loop at -O3
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following code (reduced from a larger testcase) when compiled at -O3 with
gcc 4.7.2 produces an executable that does not terminate. Compiling with lower
optimizations, current gcc trunk or the older 4.6.3 release at -O3, the
executable terminates as expected.
$ gcc-4.7 --version
gcc-4.7 (GCC) 4.7.2
$ gcc-4.7 -O2 loop.c
$ ./a.out
$ gcc-4.6 -O3 loop.c
$ ./a.out
$ gcc-4.7 -O3 loop.c
$ ./a.out
hangs ^C
$ cat loop.c
int a, c, d = 1;
struct
{
int f0;
} b, f;
short e;
void fn1 (p1)
{
int g[] = { };
e = 0;
for (; e != 1; e = e + 5)
{
int *h[] = {[0] g[0] };
if (p1);
else
return;
f = b;
}
}
int main ()
{
int i, j;
i = 0;
for (; i 6; i++)
{
j = 8;
for (; j; j--)
a = 0;
}
fn1 (d);
for (; c;);
}
[Bug tree-optimization/56478] New: Regression: ICE: Floating point exception in tree_estimate_probability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56478
Bug #: 56478
Summary: Regression: ICE: Floating point exception in
tree_estimate_probability
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following snippet (generated by csmith) causes top-of-trunk to generate an
ICE at -O2 and above. This is a regression from 4.7 which compiles the code
fine.
$ gcc-trunk --version
gcc-trunk (GCC) 4.8.0 20130227 (experimental) [trunk revision 196310]
$ cat crash2.c
/* gcc-trunk -O2+ */
int a;
void fn1 ()
{
int b;
b = 0;
for (;; b++)
a = 0 -9223372036854775807LL - 1 - b ? : 0;
}
$ gcc-trunk -O -c crash2.c
$ gcc-4.7 -O2 -c crash2.c
$ gcc-trunk -O2 -c crash2.c
crash2.c: In function ‘fn1’:
crash2.c:9:1: internal compiler error: Floating point exception
}
^
0x7a32df crash_signal
../../gcc-trunk/gcc/toplev.c:332
0x7274ce predict_iv_comparison
../../gcc-trunk/gcc/predict.c:1231
0x7274ce predict_loops
../../gcc-trunk/gcc/predict.c:1552
0x7274ce tree_estimate_probability()
../../gcc-trunk/gcc/predict.c:2276
0x7277c0 tree_estimate_probability_driver
../../gcc-trunk/gcc/predict.c:2313
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$
[Bug tree-optimization/56448] [4.8 Regression] cc1 hangs on volatile array with -O or above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56448 --- Comment #5 from Dara Hazeghi dhazeghi at yahoo dot com 2013-02-26 17:47:04 UTC --- Thanks! That was a very quick fix.
[Bug tree-optimization/56448] New: cc1 hangs on volatile array with -O or above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56448
Bug #: 56448
Summary: cc1 hangs on volatile array with -O or above
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following snippet (reduced from a larger test case) causes top-of-trunk cc1
to hang (infinite loop) on x86_64-linux using -O or above. This is a
regression from 4.7.2 which does not have this issue.
$ cat volatile.c
volatile int a[1];
int b;
void fn1 ()
{
for (;;)
{
int *c[3][6] =
{ 0, 0, 0, b, 0, 0, 0, 0, b, 0, 0, 0, 0, 0, 0, 0, b, (int *)a[0] };
b = *c[2][5];
}
}
$ gcc-trunk --version
gcc-trunk (GCC) 4.8.0 20130225 (experimental) [trunk revision 196255]
$ gcc-4.7 -O -c volatile.c
$ gcc-trunk -c volatile.c
$ gcc-trunk -O -c volatile.c
hangs
[Bug libstdc++/17755] Can't compile djgpp cross-compiler
-- What|Removed |Added CC|dhazeghi at yahoo dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17755
[Bug java/12005] TimeZone.getID() produces NPE
-- What|Removed |Added Target Milestone|--- |3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12005
[Bug c++/12498] Internal compiler error in schedule_insns
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12498 --- Additional Comments From dhazeghi at yahoo dot com 2003-10-24 17:15 --- Reminder that we're still waiting for the preprocessed source for this report. All that's needed is to compile with gcc -save-temps, and send us gdkwindow-x11.i . If you can't check with a newer version of gcc than 3.0, that's okay too, since compiler crashes can be checked easily via cross- compiler.
[Bug preprocessor/12095] segfault when processing a .S file that contains a #include stmt
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12095 --- Additional Comments From dhazeghi at yahoo dot com 2003-10-24 23:47 --- You didn't explain why you cannot provide preprocessed source. Does it crash with -save-temps before you get a .i file? Anyhow, I downloaded everything, and tried to compile, but it looks like you forgot another file. I get: /usr/pubsw/bin/gcc -D__ASSEMBLY__ -D__KERNEL__ -I ../../../include/ -traditional -c dynreplace_asm.S In file included from dynreplace_asm.S:20: ../../../include/linux/dynreplace.h:4: linux/dynreplace_version_table.h: No such file or directory Can you please attach this file? Thanks.
[Bug target/11983] ICE in dwarf-2 on code using altivec
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11983 --- Additional Comments From dhazeghi at yahoo dot com 2003-08-25 14:43 --- I'm reducing this one.
[Bug target/8407] [IA-64] ICE in simplify_gen_subreg, at simplify-rtx.c:2711 with very simple code
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8407 dhazeghi at yahoo dot com changed: What|Removed |Added Last reconfirmed|2003-05-08 00:00:00 |2003-07-09 19:13:34 date|| --- Additional Comments From dhazeghi at yahoo dot com 2003-07-09 19:13 --- Still present on mainline and branch (20030708).
[Bug fortran/5900] Lapack regressions for g77 3.1
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900 dhazeghi at yahoo dot com changed: What|Removed |Added Keywords||wrong-code --- Additional Comments From dhazeghi at yahoo dot com 2003-07-05 16:57 --- Reminder that this bug is still in waiting. Can anyone confirm whether this still occurs with gcc 3.3? Thanks, Dara
[Bug optimization/7571] BitchX fails with a segmentation fault when compiled with -O3
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7571 dhazeghi at yahoo dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Additional Comments From dhazeghi at yahoo dot com 2003-06-20 23:02 --- No testcase for 3+ months. Closing. Will reopen if submitter sends test case.
