[Bug boehm-gc/35012] gcc-4.2.3-RC1's gctest hangs on i686-apple-darwin9
--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-12 08:14 --- Since this PR did not received any attention and seems fixed at least on 4.4 and trunk, if nobody complains in the coming days I'll close it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35012
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #13 from dominiq at lps dot ens dot fr 2009-04-12 08:17 --- Is comment #11 still true? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #4 from css20 at mail dot ru 2009-04-12 08:50 ---
First tests of Win64 compiler.. simple source file test.c was created:
#include "windows.h"
int main(int argc, char **argv)
{
MessageBox(NULL, "test", "test", MB_OK);
}
E:\temp\test>gcc test.c
gcc: CreateProcess: No such file or directory
E:\temp\test>gcc -### test.c
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../src/configure --prefix=/usr/win64 --with-sysroot=/usr/win64
--host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-languages=c,c++
--d
isable-win32-registry --disable-nls --disable-shared --disable-sjlj-exceptions
-
-with-dwarf2 --disable-libssp --enable-libgomp
Thread model: win32
gcc version 4.4.0 20090407 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-mtune=generic'
"e:/mingw64/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/cc1.exe" "-quiet"
"-ipre
fix" "e:\\mingw64\\bin\\../lib/gcc/x86_64-pc-mingw32/4.4.0/" "test.c" "-quiet"
"
-dumpbase" "test.c" "-mtune=generic" "-auxbase" "test" "-o"
"C:\\Users\\X\\AppDa
ta\\Local\\Temp\\cciH4k6g.s"
COLLECT_GCC_OPTIONS='-mtune=generic'
" \"" -->
then compiler drivers segfaults.. gdb output:
Program received signal SIGSEGV, Segmentation fault.
main (argc=3, argv=0x72120) at ../../src/gcc/gcc.c:6848
6848in ../../src/gcc/gcc.c
code from gcc.c(6848):
/* Determine if there are any linker input files. */
num_linker_inputs = 0;
for (i = 0; (int) i < n_infiles; i++)
if (explicit_link_files[i] || outfiles[i] != NULL)
num_linker_inputs++;
(gdb) p outfiles[i]
$12 = 0x72200 "test.c"
(gdb) p explicit_link_files[i]
No symbol "explicit_link_files" in current context - ???
disassembly listing:
0040DB7B cmp byte ptr [rbx+rcx],0 <--- rbx & rcx = 0
0040DB7F jne 0040DB88
0040DB81 cmp qword ptr [rdi+rcx*8],0
0040DB86 je 0040DB8B
What is it, incorrect build or compiler driver bug ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #2 from mikpe at it dot uu dot se 2009-04-12 09:11 --- (In reply to comment #1) > There is no undefined behavior here (increment of a short value converts > to int, increments then converts back to short, none of which are > undefined), so at least the wrong code issue would be the same as bug > 35634. It's not undefined, but the conversion from int back to short provokes implementation-defined behaviour when the int value doesn't fit in a short. That makes this test program not strictly conforming. The lack of a compile-time warning is unfortunate, but I don't think this is a case of wrong-code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug c/39741] Segmentation fault on valid code
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-04-12 09:31 --- Because it overruns the stack (ulimit -s). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|[BUG or NOT?] Segmentation |Segmentation fault on valid |fault on valid code |code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39741
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #3 from edwintorok at gmail dot com 2009-04-12 09:32 --- (In reply to comment #2) > (In reply to comment #1) > > There is no undefined behavior here (increment of a short value converts > > to int, increments then converts back to short, none of which are > > undefined), so at least the wrong code issue would be the same as bug > > 35634. > > It's not undefined, but the conversion from int back to short provokes > implementation-defined behaviour when the int value doesn't fit in a short. > That makes this test program not strictly conforming. But converting from short to int for the argument to printf should behave as if a short value was converted to int, i.e. the int value should be in range -32768 to 32767, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug c/39741] New: [BUG or NOT?] Segmentation fault on valid code
Compile the following code without any optimizations:
#include
int main(int argc, char *argv[])
{
char a[900];
printf("gcc is wonderful\n");
}
like gcc test.c -o test.o
./test
Segmentation fault
Is it a bug? Can anyone give an insight why such a code segfaults?
--
Summary: [BUG or NOT?] Segmentation fault on valid code
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t dot artem at mailcity dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39741
[Bug c++/39742] New: ice in C++ overload resolution
I just tried to compile the following code
void f( int, ...);
struct S
{
};
void
g()
{
void f( int, ...);
S t;
f( 1, t);
}
void
f( int i, ...)
{
}
with GNU C compiler version 4.5 snapshot 20090409
and the compiler said
jul17c.cc: In function 'void g()':
jul17c.cc:15: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
This C++ source code used to work with the 20090402 snapshot.
Here is valgrind helping out with a stack backtrace
Invalid read of size 8
==15025==at 0x40791E: joust (call.c:6802)
==15025==by 0x4080DA: tourney (call.c:6896)
==15025==by 0x40BCF3: perform_overload_resolution (call.c:2979)
==15025==by 0x416AE5: build_new_function_call (call.c:3019)
==15025==by 0x50B4EF: finish_call_expr (semantics.c:1994)
==15025==by 0x4BBEB3: cp_parser_postfix_expression (parser.c:4825)
==15025==by 0x4BC7B3: cp_parser_unary_expression (parser.c:5577)
==15025==by 0x4BD08C: cp_parser_binary_expression (parser.c:6233)
==15025==by 0x4BD473: cp_parser_assignment_expression (parser.c:6421)
==15025==by 0x4BD89F: cp_parser_expression (parser.c:6566)
==15025==by 0x4BDC33: cp_parser_expression_statement (parser.c:7129)
==15025==by 0x4B684A: cp_parser_statement (parser.c:7019)
==15025== Address 0x10 is not stack'd, malloc'd or (recently) free'd
--
Summary: ice in C++ overload resolution
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39742
[Bug target/39740] unrecognizable insn on alpha using -O3 and -std=c99
--- Comment #6 from kurt at roeckx dot be 2009-04-12 13:42 --- Comparing the results between Debian version 4.3.3-5 and 4.3.3-7+patch, I see: === g++ tests === Running target unix +FAIL: g++.dg/ext/cleanup-10.C execution test +FAIL: g++.dg/ext/cleanup-11.C execution test +FAIL: g++.dg/ext/cleanup-8.C execution test +FAIL: g++.dg/ext/cleanup-9.C execution test 4.3.3-7 isn't available for alpha yet. The diff might be the result of other changes that happened between -5 and -7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39740
[Bug c++/39742] ice in C++ overload resolution
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-12 15:41 --- This is caused by revision 145709: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00331.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-12 15:41:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39742
[Bug c++/39742] [4.5 Regression] ice in C++ overload resolution
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-12 15:41:12 |2009-04-12 16:15:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39742
[Bug target/37814] M68k/Coldfire ICE with -O: insn does not satisfy its constraints
--- Comment #2 from schwab at linux-m68k dot org 2009-04-12 16:22 --- No answer in 5 months, assuming fixed. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37814
[Bug target/39740] unrecognizable insn on alpha using -O3 and -std=c99
--- Comment #7 from ubizjak at gmail dot com 2009-04-12 18:22 --- (In reply to comment #6) > Comparing the results between Debian version 4.3.3-5 and 4.3.3-7+patch, I see: > === g++ tests === > > > Running target unix > +FAIL: g++.dg/ext/cleanup-10.C execution test > +FAIL: g++.dg/ext/cleanup-11.C execution test > +FAIL: g++.dg/ext/cleanup-8.C execution test > +FAIL: g++.dg/ext/cleanup-9.C execution test > > 4.3.3-7 isn't available for alpha yet. The diff might be the result of other > changes that happened between -5 and -7. These are due to some strange failure in dejagnu framework on debian alpha, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33263#c7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39740
[Bug middle-end/39744] New: component references with VIEW_CONVERT_EXPR should be canonicalized
VIEW_CONVERT_EXPR (a.b.c.d).e.f.g.h should be canonicalized to strip zero-offset and same size as T component references off the VIEW_CONVERT_EXPR argument. The same should be applied to component references of the VIEW_CONVERT_EXPR result by adjusting the type T the VIEW_CONVERT_EXPR converts to. This missed canonicalization will help folding and value numbering. -- Summary: component references with VIEW_CONVERT_EXPR should be canonicalized Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39744
[Bug bootstrap/39631] f951 seg faults while building libgfortran
--- Comment #6 from danglin at gcc dot gnu dot org 2009-04-12 18:43 --- This is fixed in my builds. Steve, if this is still a problem, you can reopen. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39631
[Bug target/39740] unrecognizable insn on alpha using -O3 and -std=c99
--- Comment #8 from uros at gcc dot gnu dot org 2009-04-12 18:55 --- Subject: Bug 39740 Author: uros Date: Sun Apr 12 18:55:25 2009 New Revision: 145985 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145985 Log: 2009-04-12 Uros Bizjak PR target/39740 * config/alpha/predicates.md (local_symbolic_operand): Return 1 for offseted label references. testsuite/ChangeLog: PR target/39740 * gcc.target/alpha/pr39740.c: New test. Added: trunk/gcc/testsuite/gcc.target/alpha/pr39740.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/predicates.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39740
[Bug target/39740] unrecognizable insn on alpha using -O3 and -std=c99
--- Comment #9 from ubizjak at gmail dot com 2009-04-12 19:00 --- Fixed on mainline for now. -- ubizjak at gmail dot com changed: What|Removed |Added GCC target triplet||alpha-linux-gnu Known to fail|4.3.3 |4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39740
[Bug middle-end/39745] New: Wrong code by >= -O2 for pre-initialized variable and casted access
This test case comes from the gdtoa library. The problem is reduced to a simple test-case. Wrong code is produced for optimization levels higher or equal to 2. -- Summary: Wrong code by >= -O2 for pre-initialized variable and casted access Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: critical Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: i686-*-* x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39745
[Bug middle-end/39745] Wrong code by >= -O2 for pre-initialized variable and casted access
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-04-12 19:20 --- Created an attachment (id=17623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17623&action=view) testcase Reduced testcase for showing the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39745
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #5 from css20 at mail dot ru 2009-04-12 19:35 ---
I see this bug in compiler driver is already known
(http://sourceforge.net/forum/forum.php?thread_id=3091795&forum_id=723797), it
works only with "-O0". I can't found report about this bug in database.. does
it exists ?
> Well, on 4.4 branch there was a patch introducing the winsup link, which got
> necessary for building libstdc++. We solve this by setting up in gcc's source
> tree a symbolic link "winsup" pointing to the sysroot (prefix) directory.
Symbolic link "winsup" to prefix directory with mingw-w64 runtime headers not
works properly with current gcc 4.4.0 snapshot.. for correct build you must
*temporary* remove file "stddef.h" from
${YOUR_PREFIX}/x86_64-pc-mingw32/include because it conflicts with same file in
libstdc++ build directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug middle-end/39651] New cleanup test failures
--- Comment #1 from nemet at gcc dot gnu dot org 2009-04-12 19:37 --- Subject: Bug 39651 Author: nemet Date: Sun Apr 12 19:36:50 2009 New Revision: 145986 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145986 Log: PR middle-end/39651 * except.c (can_throw_external): Look at each insn in a SEQUENCE when deciding whether the whole SEQUENCE can throw. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39651
[Bug libgomp/39746] New: [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/pr34513.C -B/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/./libgomp/ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgo mp -I/test/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O1 -n ostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64 -hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I /test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/includ e/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -B/test/gnu/gcc/objdi r/hppa64-hp-hpux11.11/./libgomp/../libstdc++-v3/src/.libs -L/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/./libgomp/.libs -lgomp -L/test/gnu/gcc/objdir/hppa64-hp-h pux11.11/./libgomp/../libstdc++-v3/src/.libs -lstdc++ -lm -o ./pr34513.exe (timeout = 300) PASS: libgomp.c++/pr34513.C -O1 (test for excess errors) Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/ .libs:/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgom p/../libstdc++-v3/src/.libs:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp /.libs:/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgo mp/../libstdc++-v3/src/.libs FAIL: libgomp.c++/pr34513.C -O1 execution test Program received signal SIGABRT, Aborted. 0x83fffdde230c in kill () from /lib/pa20_64/libc.2 (gdb) bt #0 0x83fffdde230c in kill () from /lib/pa20_64/libc.2 #1 0x83fffdd916ec in raise () from /lib/pa20_64/libc.2 #2 0x83fffddc6960 in abort_C () from /lib/pa20_64/libc.2 #3 0x83fffddc69c4 in abort () from /lib/pa20_64/libc.2 #4 0x40002a88 in main () at /test/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/pr34513.C:31 This regression was introduced between revisions 145635 and 145706. -- Summary: [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39746
[Bug middle-end/39745] Wrong code by >= -O2 for pre-initialized variable and casted access
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-12 19:45 --- You are violating C aliasing rules. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39745
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-12 19:49 ---
(In reply to comment #5)
> I see this bug in compiler driver is already known
> (http://sourceforge.net/forum/forum.php?thread_id=3091795&forum_id=723797), it
> works only with "-O0". I can't found report about this bug in database.. does
> it exists ?
Yes, there is already one. But this bug is work-a-round by a temporary hack in
our crt. So it shouldn't appear anymore.
> > Well, on 4.4 branch there was a patch introducing the winsup link, which
> > got necessary for building libstdc++. We solve this by setting up in gcc's
> > source tree a symbolic link "winsup" pointing to the sysroot (prefix)
> > directory.
>
>
> Symbolic link "winsup" to prefix directory with mingw-w64 runtime headers not
> works properly with current gcc 4.4.0 snapshot.. for correct build you must
> *temporary* remove file "stddef.h" from
> ${YOUR_PREFIX}/x86_64-pc-mingw32/include because it conflicts with same file
> in
> libstdc++ build directory.
>
Hmm, I tested a native build with current 4.4 gcc and I had no issues about it.
Please make sure, that you have in your gcc source root directory the symbolic
link "winsup" pointing to your prefix directory. Secondly, make sure you have
the symbolic link "mingw" in your prefix directory, which has to point to
x86_64-pc-mingw32 directory.
If you need further help you can join #mingw-w64 on irc.oftc.net.
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug middle-end/39745] Wrong code by >= -O2 for pre-initialized variable and casted access
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-12 20:01 --- More to the point: double d = 0.0; /* Reasons the issue. */ ((U*)&d)->iv[1] = b[1]; ((U*)&d)->iv[0] = b[0]; You are accessing a double as an int which violates C/C++ aliasing rules. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39745
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #4 from mikpe at it dot uu dot se 2009-04-12 21:33 --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > There is no undefined behavior here (increment of a short value converts > > > to int, increments then converts back to short, none of which are > > > undefined), so at least the wrong code issue would be the same as bug > > > 35634. > > > > It's not undefined, but the conversion from int back to short provokes > > implementation-defined behaviour when the int value doesn't fit in a short. > > That makes this test program not strictly conforming. > > But converting from short to int for the argument to printf should behave as > if > a short value was converted to int, i.e. the int value should be in range > -32768 to 32767, right? Usually but not here. Since you compiled with -fstrict-overflow (implicitly via -O2) the compiler can assume your short variables will have proper short values. As an optimisation the compiler could decide to store short variables in wider int variables and to perform short arithmetic using int arithmetic. Since you promised not to cause signed overflow those int variables would always be the proper sign-extension of the corresponding short variables. But your test program does cause signed overflow, so this optimisation changes behaviour. It's still not the compiler's fault. If you deliberately cause signed overflow, do not compile with -fstrict-overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug preprocessor/31869] stringifying empty macros
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-04-12 22:20 --- Subject: Bug 31869 Author: jsm28 Date: Sun Apr 12 22:20:02 2009 New Revision: 145989 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145989 Log: libcpp: PR preprocessor/31869 * macro.c (stringify_arg): Handle NULL source token in padding token where previous padding token did not have source token with preceding whitespace. gcc/testsuite: * gcc.dg/cpp/strify5.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/strify5.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
[Bug preprocessor/31869] stringifying empty macros
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-04-12 22:23 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)
--- Comment #13 from steven at gcc dot gnu dot org 2009-04-12 23:46 --- The real bug is that somehow MEM_ATTRS are not shared anymore. We have lots and lots of exactly the same expression in the table, e.g.: Index 3 (hash value 4232) (mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame) (const_int -3828 [0xf10c])) [32 cpy.d+0 S4 A32]) Index 6 (hash value 4232) (mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame) (const_int -3828 [0xf10c])) [32 cpy.d+0 S4 A32]) Index 10 (hash value 4232) (mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame) (const_int -3828 [0xf10c])) [32 cpy.d+0 S4 A32]) but exp_equiv_p() thinks these are not equivalent, because the MEM_ATTRS pointers are not the same. We should have MEM_ATTRS(x)==MEM_ATTRS(y) for two MEMs with the same memory attributes, but here the pointers are not the same. So we're allocating MEM_ATTRS somewhere without going via the table, or we're adjusting MEM_ATTRS somewhere wvia an incorrect interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)
--- Comment #14 from steven at gcc dot gnu dot org 2009-04-12 23:52 ---
Ah, how subtle.
(gdb) p MEM_ATTRS(x)
$25 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(y)
$26 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p MEM_ATTRS(*x)
$27 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(*y)
$28 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p MEM_ATTRS(x)
$29 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(y)
$30 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p *MEM_ATTRS(x)
$31 = {expr = 0x7f20d406cfa0, offset = 0x7f20d9e05450, size = 0x7f20d9e05490,
alias = 32,
align = 32}
(gdb) p *MEM_ATTRS(y)
$32 = {expr = 0x7f20d4093190, offset = 0x7f20d9e05450, size = 0x7f20d9e05490,
alias = 32,
align = 32}
(gdb) p debug_tree(MEM_ATTRS(x)->expr)
unit size
align 32 symtab 0 alias set 87 canonical type 0x7f20d6bd8d80 fields
context
full-name "struct QString::Data"
X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this chain >
sizes-gimplified unsigned SI
size
unit size
align 32 symtab 0 alias set 32 canonical type 0x7f20d6bd96c0
pointer_to_this reference_to_this
>
arg 0 unit size
align 32 symtab 0 alias set -1 canonical type 0x7f20d74f5b40
attributes
local bindings <(nil)>>
value
readonly constant static "default\000">>> fields
full-name "const class QString"
needs-constructor needs-destructor X() X(constX&) this=(X&)
n_parents=0 use_template=0 interface-unknown
pointer_to_this reference_to_this
>
addressable used tree_1 tree_2 tree_3 in_system_header decl_1 decl_5
BLK file /usr/include/QtCore/qlist.h line 420 col 21 size unit size
align 32 context
abstract_origin
(mem/s/c:BLK (plus:SI (reg/f:SI 20 frame)
(const_int -3828 [0xf10c])) [31 cpy+0 S4 A32])>
arg 1
used private unsigned nonlocal decl_3 SI file
/usr/include/QtCore/qstring.h line 574 col 11 size unit size
align 32 offset_align 128
offset
bit offset context
chain
used public private static unsigned external nonlocal
in_system_header decl_3 decl_5 decl_6 SI file /usr/include/QtCore/qstring.h
line 577 col 24 size unit size
align 32 context
chain >>
/usr/include/QtCore/qstring.h:670:58>
$33 = void
(gdb) p debug_tree(MEM_ATTRS(y)->expr)
unit size
align 32 symtab 0 alias set 87 canonical type 0x7f20d6bd8d80 fields
context
full-name "struct QString::Data"
X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this chain >
sizes-gimplified unsigned SI
size
unit size
align 32 symtab 0 alias set 32 canonical type 0x7f20d6bd96c0
pointer_to_this reference_to_this
>
arg 0 unit size
align 32 symtab 0 alias set -1 canonical type 0x7f20d74f5b40
attributes
local bindings <(nil)>>
value
readonly constant static "default\000">>> fields
full-name "const class QString"
needs-constructor needs-destructor X() X(constX&) this=(X&)
n_parents=0 use_template=0 interface-unknown
pointer_to_this reference_to_this
>
addressable used tree_1 tree_2 tree_3 in_system_header decl_1 decl_5
BLK file /usr/include/QtCore/qlist.h line 420 col 21 size unit size
align 32 context
abstract_origin
(mem/s/c:BLK (plus:SI (reg/f:SI 20 frame)
(const_int -3828 [0xf10c])) [31 cpy+0 S4 A32])>
arg 1
used private unsigned nonlocal decl_3 SI file
/usr/include/QtCore/qstring.h line 574 col 11 size unit size
align 32 offset_align 128
offset
bit offset context
chain
used public private static unsigned external nonlocal
in_system_header decl_3 decl_5 decl_6 SI file /usr/include/QtCore/qstring.h
line 577 col 24 size unit size
align 32 context
chain >>
/usr/include/QtCore/qstring.h:670:58>
$34 = void
(gdb)
So the expressions look exactly the same when printed ("cpy.d") but they are
actually not the same variable. OK. False alarm. Pfew...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug c++/39742] [4.5 Regression] ice in C++ overload resolution
--- Comment #2 from jason at gcc dot gnu dot org 2009-04-13 04:05 --- Subject: Bug 39742 Author: jason Date: Mon Apr 13 04:04:58 2009 New Revision: 145994 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145994 Log: PR c++/39742 * call.c (joust): Don't crash on variadic fn. Added: trunk/gcc/testsuite/g++.dg/overload/extern-C-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39742
[Bug c++/39742] [4.5 Regression] ice in C++ overload resolution
--- Comment #3 from jason at gcc dot gnu dot org 2009-04-13 04:20 --- Subject: Bug 39742 Author: jason Date: Mon Apr 13 04:20:32 2009 New Revision: 145995 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145995 Log: PR c++/39742 * call.c (joust): Don't crash on variadic fn. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/overload/extern-C-2.C - copied unchanged from r145994, trunk/gcc/testsuite/g++.dg/overload/extern-C-2.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/call.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39742
[Bug c++/39742] [4.5 Regression] ice in C++ overload resolution
--- Comment #4 from jason at gcc dot gnu dot org 2009-04-13 04:28 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39742
[Bug middle-end/39685] ICE: in copyprop_hardreg_forward_1, at regrename.c:1603
--- Comment #4 from MR dot Swami dot Reddy at nsc dot com 2009-04-13 05:09 --- NOTE-1: This problem seen with "gcc-4.4" and "gcc-4.5" (ie trunk) sources built crx-elf-gcc compiler. NOTE-2: With "-O2 -funroll-all-loops" options also reproduce this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39685
[Bug bootstrap/39747] New: [4.5/4.5 Regression] libjavamath is linking against libgmp
I compiled GMP as a static library only on darwin. So when compiling the trunk or the 4.4 branch on powerpc-darwin, I get: /usr/bin/ld: /usr/local/lib/libgmp.a(popcount.o) has local relocation entries in non-writable section (__TEXT,__text) This started to happen between 134948 and 144367. -- Summary: [4.5/4.5 Regression] libjavamath is linking against libgmp Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
[Bug libgcj/39747] [4.5/4.5 Regression] libjavamath is linking against libgmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-13 05:34 --- So it looks like GMP is needed now as a target library for libgcj to work and this is not documented anywhere I think. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |libgcj Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #5 from edwintorok at gmail dot com 2009-04-13 06:56 --- (In reply to comment #4) > (In reply to comment #3) > > But converting from short to int for the argument to printf should behave > > as if > > a short value was converted to int, i.e. the int value should be in range > > -32768 to 32767, right? > > Usually but not here. Since you compiled with -fstrict-overflow (implicitly > via > -O2) the compiler can assume your short variables will have proper short > values. As an optimisation the compiler could decide to store short variables > in wider int variables and to perform short arithmetic using int arithmetic. > Since you promised not to cause signed overflow those int variables would > always be the proper sign-extension of the corresponding short variables. > > But your test program does cause signed overflow, so this optimisation changes > behaviour. It's still not the compiler's fault. If you deliberately cause > signed overflow, do not compile with -fstrict-overflow. > Understood. Then this is not wrong code, just a missing warning. (In reply to comment #0) > There are 2 bugs here: > - no warning is given with -Wstrict-overflow=5, although -fstrict-overflow > changes the behaviour of the code This is still a bug: "It warns about cases where the compiler optimizes based on the assumption that signed overflow does not occur." > - from is of type short, so when sign extended to an int, it should only take > values allowed for a short: -32768 to 32767, not all values allowed for an int > (like 2253491) This is not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
