[Bug c/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
-- What|Removed |Added Summary| initilizing string litteral|Initializing string literal |data improperly maked frame-|data improperly marked |relative, should be readonly|frame-relative?, should be |static const. |readonly static const. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From jason at redhat dot com 2005-04-14 07:38 --- Subject: Re: local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads DCL with explicit memory barriers is safe. That's what I'm using. But don't take my word for it, see the "DCL is Broken" Declaration: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html Scroll down to "Making it work with explicit memory barriers". The fast path does not use a lock. There, the only overhead compared to the old code is a function call and a read/read hoist memory barrier on targets where the memory barrier is necessary; targets that do not reorder loads have no overhead at all. It is impossible for users to implement this protection as efficiently as the compiler can. The C++ committee is working on improving thread support in C++; when this particular topic came up the other day, there was general support for having the compiler guarantee that the initialization be threadsafe, though possibly with a keyword to either enable or disable this guarantee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[Bug c/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Additional Comments From schlie at comcast dot net 2005-04-14 07:43
---
(In reply to comment #0)
> resulting tree/rtl:
>
> showing frame-relative reference to "abcde" initializing data which is wrong:
>
> (insn 12 11 13 1 (set (reg:HI 44)
> (symbol_ref/f:HI ("*.LC0") [flags 0x2] )) -1
> (nil)
> (nil))
>
> showing readonly reference to {'a','b','c','d','e') initializing data which
> is correct:
>
> (insn 23 36 24 3 (set (reg:QI 42 [ v.0 ])
> (mem/v/i:QI (symbol_ref:HI ("v") ) [0 v+0 S1
> A8])) -1 (nil)
> (nil))
Sorry more accurately:
Showing frame-relative/non-readonly reference to "abcde" initializing tree/rtl
type which is wrong:
(insn 12 11 13 1 (set (reg:HI 44)
(symbol_ref/f:HI ("*.LC0") [flags 0x2] )) -1 (nil)
(nil))
(insn 15 35 16 2 (set (reg:QI 0 r0)
(mem/s:QI (reg:HI 44) [1 S5 A8])) -1 (nil)
(nil))
Showing readonly reference to {'a','b','c','d','e') initializing data which is
correct:
(insn 21 20 22 3 (set (reg:HI 52)
(symbol_ref:HI ("C.3.1150") [flags 0x2] )) -1
(nil)
(nil))
(insn 24 81 25 4 (set (reg:QI 0 r0)
(mem/s/u:QI (reg:HI 52) [2 C.3+0 S5 A8])) -1 (nil)
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug fortran/20990] Segmentation fault
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-14 07:49 --- Minimal test case is: integer i character*4 c(1) read (c,fmt='(A4)') i end This is a duplicate of 15966. *** This bug has been marked as a duplicate of 15966 *** -- What|Removed |Added Status|NEW |RESOLVED GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20990
[Bug fortran/15966] ICE and segmentation fault on internal write
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-14 07:49 --- *** Bug 20990 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||antoine dot letellier at ||free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15966
[Bug fortran/15966] ICE and segmentation fault on internal write
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-14 07:50 --- Same thing happens with read: integer i character*4 c(1) read (c,fmt='(A4)') i end Program received signal SIGSEGV, Segmentation fault. 0x080a760b in gfc_conv_scalarized_array_ref (se=0xb740, ar=0x87b48bc) at ../../../gcc/gcc/fortran/trans-array.c:1578 1576 info = &se->ss->data.info; 1577 if (ar) 1578n = se->loop->order[0]; 1579 else 1580n = 0; Seeing the number of duplicates for this one, I'm sure we want to get it on our Ten Most Wanted list. -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-03-17 02:16:37 |2005-04-14 07:50:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15966
[Bug rtl-optimization/21015] [3.3/3.4 Regression] Bad loop optimization with -O2
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-14 08:19 --- The compiler fails since gcc 3.0. Looks very similar to PR 17860. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org BugsThisDependsOn||17860 Keywords||monitored Known to fail|3.3.3 3.4.0 |3.3.3 3.4.0 3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21015
[Bug target/20927] [4.0/4.1 Regression] ICE in smallest_mode_for_size, at stor-layout.c:221 (s390x)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 08:25 --- Subject: Bug 20927 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-14 08:25:00 Modified files: gcc: ChangeLog gcc/config/s390: s390-modes.def gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr20927.c Log message: ChangeLog: PR target/20927 * config/s390/s390-modes.def: Define TFmode. testsuite/ChangeLog: PR target/20927 * gcc.dg/pr20927.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8283&r2=2.8284 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/s390/s390-modes.def.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5344&r2=1.5345 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20927.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20927
[Bug target/20927] [4.0/4.1 Regression] ICE in smallest_mode_for_size, at stor-layout.c:221 (s390x)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 08:28 --- Subject: Bug 20927 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-14 08:28:21 Modified files: gcc: ChangeLog gcc/config/s390: s390-modes.def gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr20927.c Log message: ChangeLog: PR target/20927 * config/s390/s390-modes.def: Define TFmode. testsuite/ChangeLog: PR target/20927 * gcc.dg/pr20927.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.152&r2=2.7592.2.153 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/s390/s390-modes.def.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.124&r2=1.5084.2.125 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20927.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20927
[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-14
08:39 ---
Shorter testcase:
==
template void foo()
{
double d = (N ? 0.0 : 0) + 1;
}
==
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20995
[Bug rtl-optimization/21015] [3.3/3.4 Regression] Bad loop optimization with -O2
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-04-14 08:44 --- Does the patch there fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21015
[Bug fortran/18082] Infinite loop with automatic length character objects
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-14 08:58 --- *** Bug 20821 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jvdelisle at verizon dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18082
[Bug fortran/20821] gfortran hangs indefinitely
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-14 08:58 --- *** This bug has been marked as a duplicate of 18082 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20821
[Bug rtl-optimization/21015] [3.3/3.4 Regression] Bad loop optimization with -O2
--- Additional Comments From reichelt at igpm dot rwth-aachen dot de 2005-04-14 09:25 --- Subject: Re: [3.3/3.4 Regression] Bad loop optimization with -O2 On 14 Apr, bonzini at gcc dot gnu dot org wrote: > Does the patch there fix it? Alas not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21015
[Bug c++/21019] New: fails to identify template function overload
The attached code is doing metaprogramming where a "showNode" template function recurses up a linked list of "attrNode" templates (with different argument types) until it hits an "attrBottom" type at the end of the list. That identifies a different overload of "showNode" and stops the recursion. As the error shows, it has successfully recursed to the end, but at the last node it is identifying the generic recursive "showNode" overload rather than the specific overload for "attrBottom". The actual problem is the indentification; once the wrong identification was made the resulting errors are correct, and there would be no errors had the right overload been identified. The misidentification appears fragile; the same recursion works fine elsewhere in the code, and relatively minor twiddles of the code get the compiler to identify correctly, which is why I don't have a reduced case for you. -- Summary: fails to identify template function overload Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21019
[Bug c++/21019] fails to identify template function overload
--- Additional Comments From igodard at pacbell dot net 2005-04-14 11:09 --- Created an attachment (id=8626) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8626&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21019
[Bug c++/21019] fails to identify template function overload
--- Additional Comments From igodard at pacbell dot net 2005-04-14 11:10 --- Created an attachment (id=8627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8627&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21019
[Bug c++/21019] fails to identify template function overload
--- Additional Comments From igodard at pacbell dot net 2005-04-14 11:20 --- Never mind; I found it :-( -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21019
[Bug libgcj/21020] New: java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
java.lang.NoSuchFieldError at .__gxx_personality_v0 (/home/caolan/java/a.out) at .__gxx_personality_v0 (/home/caolan/java/a.out) at .__gxx_personality_v0 (/home/caolan/java/a.out) at .__libc_start_main (/lib/libc-2.3.4.so) at .__gxx_personality_v0 (/home/caolan/java/a.out) -- Summary: java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: caolanm at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From caolanm at redhat dot com 2005-04-14 12:07 --- Created an attachment (id=8628) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8628&action=view) sample source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From caolanm at redhat dot com 2005-04-14 12:07 --- Created an attachment (id=8629) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8629&action=view) sample jar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From caolanm at redhat dot com 2005-04-14 12:09 --- version of failing gcj gcc (GCC) 4.0.0 20050412 (Red Hat 4.0.0-0.42) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From caolanm at redhat dot com 2005-04-14 12:09 --- version of successful gcj gcc (GCC) 4.0.0 20050405 (Red Hat 4.0.0-0.40) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From caolanm at redhat dot com 2005-04-14 12:11 --- affects db-4.2 as well for what it's worth -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From commie1 at gmx dot net 2005-04-14 12:35 --- Your simplified testcase only causes an ICE when I use the C++ headers from gcc 3.4.3 with gcc 4.0.0, otherwise it works fine. ICE: /opt/gcc40/bin/g++ -O -finline-functions test.cc -c -o test.o -isystem /usr/include/c++/3.4.3 No ICE: /opt/gcc40/bin/g++ -O -finline-functions test.cc -c -o test.o So you should be able to build Octave without problems... -- What|Removed |Added CC||commie1 at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug tree-optimization/21004] [4.1 Regression] gcc.dg/builtins-53.c fails
--- Additional Comments From uros at kss-loka dot si 2005-04-14 12:37 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01568.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21004
[Bug tree-optimization/20657] [tcb] VRP does not get rid of a redundant "if" statement.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 13:07 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01577.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20657
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From mark at gcc dot gnu dot org 2005-04-14 13:20 --- With 4.1 (20050412) I get: g++ -g -lgcj java.cxx ./a.out java.lang.ClassNotFoundException: Lcom.sun.star.uno.Type; <> 4.0 (20050413) indeed throws java.lang.NoSuchFieldError -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 13:20:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-14 13:28 --- See https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=113145. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug tree-optimization/21021] New: ICE in tree-vrp building glibc
cc1 options for the attached testcase are: -w -fpreprocessed dl-iteratephdr.i -quiet -O2 -std=gnu99 The ICE is: dl-iteratephdr.c: In function '__dl_iterate_phdr': dl-iteratephdr.c:36: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or char_type or real_type, have pointer_type in compare_values, at tree-vrp.c:307 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This is with a clean HEAD tree from half an hour ago, plus a workaround from bug 20126 (which is an RTL loop optimizer bug, so presumably irrelevant). -- Summary: ICE in tree-vrp building glibc Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: mips64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21021] ICE in tree-vrp building glibc
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-14 13:32 --- Created an attachment (id=8630) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8630&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug tree-optimization/20657] [tcb] VRP does not get rid of a redundant "if" statement.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 13:35 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20657
[Bug tree-optimization/20657] [tcb] VRP does not get rid of a redundant "if" statement.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 13:36 --- Subject: Bug 20657 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-14 13:34:59 Modified files: gcc: ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr20657.c Log message: gcc/ PR tree-optimization/20657 * tree-vrp.c (extract_range_from_expr): Notice INTEGER_CST to create an appropriate range from it. testsuite/ PR tree-optimization/20657 * gcc.dg/tree-ssa/pr20657.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8286&r2=2.8287 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.6&r2=2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5346&r2=1.5347 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20657.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20657
[Bug tree-optimization/21021] ICE in tree-vrp building glibc
-- What|Removed |Added CC||kazu at cs dot umass dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug java/21022] New: bootstrap error compiling libgcj with awt support on darwin-ppc
I get the following bus error when I compile libgcj with awt support on darwin: gnu/java/awt/peer/gtk/GdkFontMetrics.java: In class 'gnu.java.awt.peer.gtk.GdkFontMetrics': gnu/java/awt/peer/gtk/GdkFontMetrics.java: In constructor '(java.awt.Font)': gnu/java/awt/peer/gtk/GdkFontMetrics.java:0: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The backtrace of in gdb of the error looks like this: Program received signal EXC_BAD_ACCESS, Could not access memory. fold_convert (type=0x4160c380, arg=0x0) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/fold-const.c:1885 1885 tree orig = TREE_TYPE (arg); (gdb) bt #0 fold_convert (type=0x4160c380, arg=0x0) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/fold-const.c:1885 #1 0x002636dc in bit_from_pos (offset=0x2636dc, bitpos=0x1f5d18) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/stor-layout.c:538 #2 0x002636dc in bit_from_pos (offset=0x2636dc, bitpos=0x1f5d18) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/stor-layout.c:538 #3 0x000f0d0c in dbxout_type (type=0x41640c00, full=0) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/dbxout.c:1406 #4 0x000f033c in dbxout_type (type=0x41640e00, full=1) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/dbxout.c:2102 #5 0x000f2f68 in dbxout_symbol (decl=0x41640f00, local=0) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/dbxout.c:2570 #6 0x00144a84 in debug_flush_symbol_queue () at /Volumes/src/gcc/gcc-cvs/gcc/gcc/final.c:3825 #7 0x000f3d1c in dbxout_function_decl (decl=0x41643980) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/dbxout.c:3391 #8 0x0028af98 in rest_of_compilation () at /Volumes/src/gcc/gcc-cvs/gcc/gcc/passes.c:330 #9 0x0005dc7c in execute_pass_list (pass=0x48efd8) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/tree-optimize.c:552 #10 0x0005dff4 in tree_rest_of_compilation (fndecl=0x0) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/tree-optimize.c:695 #11 0x002b85e0 in cgraph_expand_function (node=0x41657a00) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/cgraphunit.c:931 #12 0x002b86d4 in cgraph_assemble_pending_functions () at /Volumes/src/gcc/gcc-cvs/gcc/gcc/cgraphunit.c:364 #13 0x002b8e44 in cgraph_finalize_function (decl=0x41643980, nested=0 '\0') at /Volumes/src/gcc/gcc-cvs/gcc/gcc/cgraphunit.c:456 #14 0x00031c90 in end_java_method () at /Volumes/src/gcc/gcc-cvs/gcc/gcc/java/decl.c:2025 #15 0x0004a8c8 in parse_class_file () at /Volumes/src/gcc/gcc-cvs/gcc/gcc/java/jcf-parse.c:935 #16 0x0004d14c in java_parse_file (set_yydebug=1096860544) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/java/jcf-parse.c:1288 #17 0x0026a60c in toplev_main (argc=1078961420, argv=0xba40) at /Volumes/src/gcc/gcc-cvs/gcc/gcc/toplev.c:1000 #18 0x2754 in _start (argc=25, argv=0xb924, envp=0xb98c) at /SourceCache/Csu/Csu-47/crt.c:267 #19 0x8fe1a558 in __dyld__dyld_start () (gdb) I can reproduce this on 4.0.x branch too. Unfortunately the error is not as easy to reproduce for others. It requires that you have a gtk installation with shared libgcc. All in all about half a day or more of compilation work. Anyway. The error appears since Tom Tromey checked in findirect-dispatch compilation for the awt-peer sources around 2005-04-05. The error does also happen on tiger. Further analysis has showed, if I remove the debug switch -g from the compilation command, I do not get the bus error. Note, darwin still uses stabs as preferred dbg format. I was not able to build a gcc on darwin with dwarf2 as default. Neither was I able to reproduce the failure on linuxppc -with-stabs. Andrew Pinski noted on IRC that it might be a java fe bug. For me the question is now, how can I continue to debug this error? The sooner or later (29 of April) the libgcj awt issue will come since then the new darwin release can really run gtk-awt java based apps. -- Summary: bootstrap error compiling libgcj with awt support on darwin-ppc Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreast at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.8.0 GCC host triplet: powerpc-apple-darwin7.8.0 GCC target triplet: powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug tree-optimization/21021] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 14:00 --- Daniel, I have tough time reproducing this. I get In file included from dl-iteratephdr.c:22: ../include/errno.h:31: error: thread-local storage not supported for this target Am I missing some options? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21021] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 14:11 --- OK, I enabled HAVE_AS_TLS by hand. Now I can reproduce the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug target/21017] ppc 64bit target not using rlwinm
-- What|Removed |Added Component|c |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21017
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug target/20927] [4.0/4.1 Regression] ICE in smallest_mode_for_size, at stor-layout.c:221 (s390x)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 14:25 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20927
[Bug tree-optimization/21021] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 14:42
---
Reduced down to:
struct link_map {
struct link_map *next;
unsigned int start, end;
};
void
foo (struct link_map **array, long int cnt)
{
struct link_map *l;
const void *caller = __builtin_extract_return_addr (__builtin_return_address
(0));
long int ns = 0;
for (l = array[cnt]; l; l = l->next)
{
if (caller >= (const void *) l->start
&& caller < (const void *) l->end)
ns = cnt;
}
for (l = array[ns]; l != 0; l = l->next)
;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 14:52 --- Confirmed, with Kazu's reduced testcase on i686-pc-linux. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-04-14 14:52:15 date|| Summary|ICE in tree-vrp building|[4.1 Regression] ICE in |glibc |tree-vrp building glibc Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
14:54 ---
Here is a testcase which does not use builtins:
struct link_map {
struct link_map *next;
unsigned int start, end;
};
void *f();
void
foo (struct link_map **array, long int cnt)
{
struct link_map *l;
const void *caller =f();
long int ns = 0;
for (l = array[cnt]; l; l = l->next)
{
if (caller >= (const void *) l->start
&& caller < (const void *) l->end)
ns = cnt;
}
for (l = array[ns]; l != 0; l = l->next)
;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 14:56
---
Reduced down to:
extern void *bar (void);
int
foo (unsigned int *p, unsigned int *q)
{
const void *r = bar ();
if (r >= (const void *) *p
&& r < (const void *) *q)
return 1;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/20947] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 15:14 ---
// reduced testcase, compile with -O2 -fpeel-loops -ftree-vectorize :
void foo (double *d)
{
unsigned int a, i;
double t[2];
for (i = 0; i < 2; i++)
{
for (a = 0; a < 2; a++)
t[a] = d[a];
while (i)
for (a = 0; a < 2; a++)
d[a] = t[a];
}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-14 15:14:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
[Bug tree-optimization/20963] [4.1 Regression] ICE tree check: expected value_handle, have addr_expr in value_exists_in_set_bitmap, at tree-ssa-pre.c:437
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 15:25 --- Subject: Bug 20963 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-14 15:25:02 Modified files: gcc: ChangeLog tree-ssa-pre.c Log message: 2005-04-14 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/20963 * tree-ssa-pre.c (compute_avail): Remove special case for TREE_INVARIANT. (create_expression_by_pieces): Add value numbers for forced out statements. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8288&r2=2.8289 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.74&r2=2.75 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20963
[Bug target/20924] [4.0 regression] inline float divide does not set correct fpu status flags
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 15:43 --- Subject: Bug 20924 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-14 15:43:07 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.md Log message: PR target/20924 * config/ia64/ia64.md (divsf3_internal_lat): Generate frcpa with fpsr 0 instead of fpsr 1. (divsf3_internal_thr): Ditto. (divdf3_internal_lat): Ditto. (divdf3_internal_thr): Ditto. (divxf3_internal_lat): Ditto. (divxf3_internal_thr): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.153&r2=2.7592.2.154 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.146.8.1&r2=1.146.8.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20924
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 15:51 --- Before VRP (even before ASSERT_EXPR insertion), we have const void * r; unsigned int D.1157; void * D.1156; : : if (r_3 >= D.1157_5) goto ; else goto ; Note that we already have a type-mismatched comparison - an integer v.s. a pointer. tree-vrp.c:maybe_add_assert_expr inserts the following ASSERT_EXPR in the "else" branch of the "if" statement. r_14 = ASSERT_EXPR ; Eventually the propagation engine visits this ASSERT_EXPR with a call tree like so. simulate_stmt vrp_visit_stmt vrp_visit_assignment extract_range_from_expr extract_range_from_assert (ASSERT_EXPR ) value_ranges_intersect_p ([D.1156_2, D.1156_2], [0, D.1157_5 - 1]) value_inside_range (D.1157_5 - 1, [D.1156_2, D.1156_2]) compare_values (D.1157_5 - 1, D.1156_2) compare_values does some limited symbolic comparisons. In this case, it checks whether D.1156_2 == INF so that if that's the case, we can deduce that D.1157_5 - 1 < D.1156_2 But we cannot compute TYPE_MAX_VALUE (TREE_TYPE (D.1156_2)) because D.1156_2 is of a pointer type, causing the ICE. The root cause of the problem is that we have a type-mismatched comparison. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug target/20924] [4.0 regression] inline float divide does not set correct fpu status flags
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 15:53 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20924
Bug: Segmentation fault
I wrote a program that is fine compiling by MS VC 7.1 or higher and works correctly. It also is compiling by CodeWarior 8.0. Unfortunately gcc says subj. :( Source code you can find in attach. gcc --version gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) Copyright (C) 2003 Free Software Foundation, Inc. bash-2.05b$ uname -a Linux ziggurat 2.6.10-gentoo-r6with_mppe #6 Tue Mar 15 17:39:51 EET 2005 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux dcc was compiled by command emerge gcc program was compiled by command gcc 6.cpp compiler output is bash-2.05b$ gcc 6.cpp loki/HierarchyGenerators.h: In instantiation of `Loki::GenLinearHierarchy, Loki::Typelist, Loki::NullType> >, Chain::Functor, Chain::Stub>': 6.cpp:50: instantiated from `ChainWrapper, Loki::Typelist, Loki::NullType> >, Chain::Functor, Chai ::Stub> >' 6.cpp:71: instantiated from `Loki::GenScatterHierarchy, Loki::Typelist, Loki::NullType> >, Chain:: unctor, Chain::Stub>, ChainWrapper>' 6.cpp:71: instantiated from `Loki::GenScatterHierarchy, Loki::Typelist, Loki::NullType> >, C ain::Functor, Chain::Stub>, Loki::Typelist, Loki::Typelist, Loki::NullType> >, Chain::Functor, Chain::Stub>, Loki::NullType> >, ChainWrapper>' 6.cpp:71: instantiated from here loki/HierarchyGenerators.h:222: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /tmp/ccW13tKm.out file, please attach this to y ur bugreport. -- Best Regards, Antonio code.tar.bz2 Description: BZip2 compressed data
[Bug libmudflap/21023] New: mudflap reports errors
Yesterday I upgraded my fedora core 3 instalation and got gcc4 installed.
I tested the mudflap code and found a problem. The reduced test case is
below.
when I have two programs a.c and b.c
-- a.c --
typedef struct { char *name; } dummy;
dummy d[] = { {"a"}, {0} };
-- b.c --
typedef struct { char *name; } dummy;
extern dummy d[];
int
main (void)
{
dummy *pd = d;
while (pd->name)
{
printf ("%s\n", pd->name);
pd++;
}
}
and compile this with:
gcc4 -fmudflap a.c b.c -o a -lmudflap
when I run the program I get:
a
***
mudflap violation 1 (check/read): time=1113495140.046642 ptr=0x8049a00 size=4
pc=0xb7eff322 location=`b.c:9 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x44) [0xb7eff322]
./a(main+0x8b) [0x8048787]
/usr/lib/libmudflap.so.0(__wrap_main+0x1d8) [0xb7f0004e]
Nearby object 1: checked region begins 8B before and ends 5B before
mudflap object 0x80ca090: name=`__mf_lc_mask'
bounds=[0x8049a08,0x8049a0b] size=4 area=no-access check=0r/0w liveness=0
alloc time=1113495140.046375 pc=0xb7effe0a
Nearby object 2: checked region begins 16B before and ends 13B before
mudflap object 0x80ca028: name=`__mf_lookup_cache'
bounds=[0x8049a10,0x80c9a0f] size=524288 area=no-access check=0r/0w liveness=0
alloc time=1113495140.046371 pc=0xb7effe0a
number of nearby objects: 2
There should be no error.
I think the problem is in tree-mudflap.c in function mudflap_finish_file.
Here is a check for TREE_STATIC. I think this should be !TREE_PUBLIC ???
I assigned this to 4.0.1 because I probably can not assign this to 4.0.0
anymore?
--
Summary: mudflap reports errors
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hermantenbrugge at home dot nl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21023
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
-- What|Removed |Added BugsThisDependsOn||21024 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug c/21024] New: Type mismatch in a comparison.
Consider:
extern void *bar (void);
int
foo (unsigned int *p)
{
const void *r = bar ();
if (r >= (const void *) *p)
return 1;
return 0;
}
t03.generic looks like so.
foo (p)
{
void * D.1155;
unsigned int D.1156;
int D.1157;
const void * r;
D.1155 = bar ();
r = D.1155;
D.1156 = *p;
if (D.1156 <= r)
{
D.1157 = 1;
return D.1157;
}
else
{
}
D.1157 = 0;
return D.1157;
}
Note that "if (D.1156 <= r)" has a type mismatch, namely an integer type
v.s. a pointer type.
This PR is the real cause of PR 21021.
--
Summary: Type mismatch in a comparison.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
OtherBugsDependingO 21021
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug target/21017] ppc 64bit target not using rlwinm
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21017
[Bug tree-optimization/20773] ICE: SEGV building jar file
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-14 16:33 --- Created an attachment (id=8631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8631&action=view) smaller testcase (4749 bytes) confirmed on amd64 with both 4.0.0 and mainline. -- What|Removed |Added Attachment #8539 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug c++/21025] New: ICE on template
3.4.3 seg faults on this:
template struct X { char x[N]; };
template X<1 + sizeof(T) - sizeof(T)> F(T const &);
template struct S { int d() { F(1); } };
Appears to be quite dependent on the fact that the template argument
involves "sizeof(T) - sizeof(T)" - if the - is changed to a +, it works.
Ok in 3.3.2, and ok if S is not a template.
--
Summary: ICE on template
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug c/21024] Type mismatch in a comparison.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 16:48 --- Confirmed. This has been wrong since "3.5.0 20040909". -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 16:48:13 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug middle-end/20965] [4.1 Regression] GCC can no longer build itself on ppc-darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 16:49 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 16:49:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20965
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 16:52 --- Confirmed. It also worked with "3.4.0 20040116" which means it was broken after the branch of 3.4.0. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-04-14 16:52:50 date|| Summary|ICE on template |[3.4/4.0/4.1 Regression] ICE ||on template Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug middle-end/20739] [4.0/4.1 regression] ICE in gimplify_addr_expr
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
17:03 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> If the operands of a cond-expr used as an lvalue differ in cv
> qualification, the front-end adds nop_exprs to add cv qualifiers that
> the gimplifier drops when simplifying &(T const)*v. The `&' was added
> by gimplify_cond_expr.
> The problem is that gimplify_addr_expr gimplifies its operand in such
> a way that the nop_expr is dropped, and nothing puts it back in, so
> when we test that, in the indirect_ref case in gimplify_addr_expr, the
> types are compatible, the test fails because of the missing
> cv-qualifier in the pointed-to type. This patch fixes this.
> Ok to install if bootstrap and regtest on amd64-linux-gnu pass?
Bootstrap and regtest pased on amd64-linux-gnu, at least for mainline.
I'm retesting on the branch, since I'm not entirely sure I actually
tested it there.
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR middle-end/20739
* gimplify.c (gimplify_addr_expr): Compensate for removal of
e.g. cv-qualification conversions.
Index: gcc/gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.122
diff -u -p -r2.122 gimplify.c
--- gcc/gimplify.c 1 Apr 2005 03:42:41 - 2.122
+++ gcc/gimplify.c 4 Apr 2005 11:28:04 -
@@ -3229,6 +3232,9 @@ gimplify_addr_expr (tree *expr_p, tree *
builtins like __builtin_va_end). */
/* Caution: the silent array decomposition semantics we allow for
ADDR_EXPR means we can't always discard the pair. */
+ /* Gimplification of the ADDR_EXPR operand may drop
+cv-qualification conversions, so make sure we add them if
+needed. */
{
tree op00 = TREE_OPERAND (op0, 0);
tree t_expr = TREE_TYPE (expr);
@@ -3238,9 +3244,9 @@ gimplify_addr_expr (tree *expr_p, tree *
{
#ifdef ENABLE_CHECKING
tree t_op0 = TREE_TYPE (op0);
- gcc_assert (TREE_CODE (t_op0) == ARRAY_TYPE
- && POINTER_TYPE_P (t_expr)
- && cpt_same_type (TREE_TYPE (t_op0),
+ gcc_assert (POINTER_TYPE_P (t_expr)
+ && cpt_same_type (TREE_CODE (t_op0) == ARRAY_TYPE
+ ? TREE_TYPE (t_op0) : t_op0,
TREE_TYPE (t_expr))
&& POINTER_TYPE_P (t_op00)
&& cpt_same_type (t_op0, TREE_TYPE (t_op00)));
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR middle-end/20739
* gcc.dg/tree-ssa/pr20739.c: New test.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr20739.c
===
RCS file: gcc/testsuite/gcc.dg/tree-ssa/pr20739.c
diff -N gcc/testsuite/gcc.dg/tree-ssa/pr20739.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/tree-ssa/pr20739.c 4 Apr 2005 11:28:20 -
@@ -0,0 +1,24 @@
+/* PR middle-end/20739 */
+
+/* dg-do compile */
+/* dg-options "-O" */
+
+/* We used to fail to compile this because gimplification dropped the
+ conversion that added the const qualifier to the sub-expression
+ involving baz, and then immediately noticed and reported its
+ absence. */
+
+typedef struct
+{
+char chars[5];
+}
+baz_t;
+
+extern baz_t * baz;
+
+extern void foo (baz_t);
+int
+bar (const baz_t * ls)
+{
+foo (ls == 0 ? *(&baz[0]) : *ls);
+}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug middle-end/20739] [4.0/4.1 regression] ICE in gimplify_addr_expr
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:19 --- Thanks Alex! This is OK for mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14 17:21 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > ! v->ignore = 1; What's the point of the statement above? If we actually know the giv reg has the right value, why not use it for other purposes as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:37 --- You'll notice in loop.c that everywhere that we currently set all_reduced to zero, we also set ignore to true. This change is to avoid wasting CPU cycles, if we know that an IV can't be eliminated, there's no point in trying to modify any more instructions that use it. At best, this incurs wasted CPU cycles, at worst we'll end up substituting in some places and not others, which will result in requiring both the original IV *and* the replacement IV which will increase register pressure in the loop. As your (Alex's) testing showed, I'm not sure that its strictly required for correctness, it's mainly to preserve consistency with the exisiting all_reduced invariants by using the same idiom as used elsewhere, but also as a potential compile-time/run-time micro-optimization. However for 4.0, I thought it best to reuse/copy the existing idiom, rather than risk clearing all_reduced without setting ignore (which may have potentially exposed code paths not seen before). We still need the 4.1 variant to be tested/committed to mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug testsuite/21010] New gcc.dg/vect tests fail
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14 18:02 --- Subject: Bug 21010 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-14 18:02:37 Modified files: gcc/testsuite/gcc.dg/vect: vect-ifcvt-1.c vect-ifcvt-2.c vect-ifcvt-3.c vect-ifcvt-4.c vect-ifcvt-5.c vect-ifcvt-6.c vect-ifcvt-7.c vect-ifcvt-9.c gcc/testsuite : ChangeLog Log message: PR testsuite/21010 * gcc.dg/vect/vect-ifcvt-1.c: Remove dg-do, add cleanup. * gcc.dg/vect/vect-ifcvt-2.c: Ditto. * gcc.dg/vect/vect-ifcvt-3.c: Ditto. * gcc.dg/vect/vect-ifcvt-4.c: Ditto. * gcc.dg/vect/vect-ifcvt-5.c: Ditto. * gcc.dg/vect/vect-ifcvt-6.c: Ditto. * gcc.dg/vect/vect-ifcvt-7.c: Ditto. * gcc.dg/vect/vect-ifcvt-9.c: Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-1.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-2.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-3.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-4.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-5.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-6.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-7.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-9.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5349&r2=1.5350 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21010
[Bug target/20634] code fails to compile/code generation issue with -funit-at-a-time
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 18:02 ---
reduced testcase, compile with '-O1 -fschedule-insns -funit-at-a-time',
fails with 3.3-hammer, 3.4, 4.0 and mainline, introduced in 2003:
: Search converges between 2003-07-11-trunk (#291) and 2003-07-12-trunk (#292).
--
unsigned int strlen (const char *);
static void append (char *p0, char **pp, int *j, char *p1)
{
int k = strlen (p0);
if (p1 && pp)
k += strlen (p1);
if (*j + k)
while (*j);
}
int yyparse (int foo)
{
if (foo)
append (0, 0, 0, 0);
else
append (0, 0, 0, 0);
}
--
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-14 18:02:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20634
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-14 18:05 --- For 4.0, my recent system class loader patch works around this problem. The attached patch should go in the trunk asap. I looked at all other users of _Jv_FindClassFromSignature, and this was the only problem caller. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 18:18
---
Here's a minimized test case that fails on powerpc64-linux with -m64 -O2:
extern void bar (void *);
extern double x;
void
foo (void)
{
char buf2 [32][1024];
bar (buf2 [(int) x]);
}
On IRC pinskia pointed out that powerpc64-linux supports older CPUs by
default than does powerpc-darwin. The ICE doesn't happen with -mcpu=power3;
I didn't try earlier cpus.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813
[Bug testsuite/21010] New gcc.dg/vect tests fail
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 18:22 --- Fixed with the patch. Today the tests pass on powerpc64-linux. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21010
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-14 18:47 --- Do you want me to post the patch, then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-14 19:02 ---
// reduced testcase
template class C
{
void f ()
{
typedef int U;
typedef typeof(*this) U;
}
};
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||3.4.4
Known to work|4.0.0 4.1.0 |4.0.0 4.1.0 3.3.5
Last reconfirmed|-00-00 00:00:00 |2005-04-14 19:02:49
date||
Summary|ICE on invalid code |[3.4 Regression] ICE in
||write_type, at
||cp/mangle.c:1579
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c++/20552] [3.3/3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:10 --- Fixed on the mainline: : Search converges between 2004-03-01-trunk (#446) and 2004-04-01-trunk (#447). Broke: : Search converges between 2001-03-18-trunk (#11) and 2001-03-25-trunk (#12). -- What|Removed |Added Summary|[3.4 Regression] ICE in |[3.3/3.4 Regression] ICE in |write_type, at |write_type, at |cp/mangle.c:1579|cp/mangle.c:1579 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c++/21026] New: ICE in check_tag_decl, at cp/decl.c:3516
// compile with -O0
template class C
{
void f ()
{
typedef typeof(*this) int;
}
};
// not a regression, fixed in 4.0 and above:
// Search converges between 2004-06-24-trunk (#471) and 2004-06-26-trunk (#472).
--
Summary: ICE in check_tag_decl, at cp/decl.c:3516
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21026
[Bug c++/21026] ICE in check_tag_decl, at cp/decl.c:3516
-- What|Removed |Added Known to fail||3.4.4 3.3.5 Known to work||4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21026
[Bug libgcj/21020] java.lang.NoSuchFieldError regression from earlier 4.0.0 snapshot
--- Additional Comments From mark at gcc dot gnu dot org 2005-04-14 19:14 --- This was "fixed" by the following patch on the 4.0 branch (20050414): 2005-04-14 Tom Tromey <[EMAIL PROTECTED]> * java/lang/natClassLoader.cc (_Jv_FindClass): Use system loader, not boot loader. (_Jv_RegisterInitiatingLoader): Likewise. (_Jv_UnregisterInitiatingLoader): Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21020
[Bug fortran/21027] New: Triple call to _gfortran_runtime_error with -fbounds-check
$ cat bounds-check.f90
program main
integer, parameter :: n=10
integer :: m,i
integer a(n), b(n)
call foo(a,m)
do i=1,m
b(i) = a(i)*a(i)
end do
print *,b(1:m)
end program main
subroutine foo(a)
integer a(10)
a = 2
m = 12
end subroutine foo
$ gfortran -fbounds-check -fdump-tree-optimized -O2 -S bounds-check.f90
gets me (from the .t71.optimized file):
bb 0>:
foo (&a, &m);
D.474 = m;
if (D.474 > 0) goto ; else goto ;
:;
ivtmp.19 = 0;
:;
if (__builtin_expect (ivtmp.19 > 9, 0) != 0) goto ; else goto ;
:;
_gfortran_runtime_error ("Array reference out of bounds", "bounds-check.f90",
5);
_gfortran_runtime_error ("Array reference out of bounds", "bounds-check.f90",
5);
_gfortran_runtime_error ("Array reference out of bounds", "bounds-check.f90",
5);
:;
D.499 = *&a[ivtmp.19];
*&b[ivtmp.19] = D.499 * D.499;
ivtmp.19 = ivtmp.19 + 1;
if (() D.474 == ivtmp.19) goto ; else goto ;
which is still present in the assembly code:
.L16:
movl$5, %ecx
movl$.LC0, %edx
movl%ecx, 8(%esp)
movl%edx, 4(%esp)
movl$.LC1, (%esp)
call_gfortran_runtime_error
movl$5, %eax
movl%eax, 8(%esp)
movl$.LC0, %eax
movl%eax, 4(%esp)
movl$.LC1, (%esp)
call_gfortran_runtime_error
movl$5, %eax
movl%eax, 8(%esp)
movl$.LC0, %eax
movl%eax, 4(%esp)
movl$.LC1, (%esp)
call_gfortran_runtime_error
jmp .L5
Maybe it would help if _gfortran_runtime_error was marked
as non-returning.
--
Summary: Triple call to _gfortran_runtime_error with -fbounds-
check
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21027
[Bug fortran/21027] Triple call to _gfortran_runtime_error with -fbounds-check
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:22 --- This is a dup of bug 17758, which I reported when I was looking into a tree-optimizator ICE long time ago. I also noticed just recently when I was about to work on PR 17758, that _gfortran_runtime_error needed to be marked as noreturn also. *** This bug has been marked as a duplicate of 17758 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21027
[Bug fortran/17758] gfortran_abort and some others should be marked as noreturn
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:22 --- *** Bug 21027 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17758
[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:30 --- (In reply to comment #2) > Here's a minimized test case that fails on powerpc64-linux with -m64 -O2: > On IRC pinskia pointed out that powerpc64-linux supports older CPUs by > default than does powerpc-darwin. The ICE doesn't happen with -mcpu=power3; > I didn't try earlier cpus. The only 64bit PPC CPU that does not support these optional instruction is the rs64a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813
[Bug ada/21028] New: Cross build failure from i686-linux to powerpc-aix5.2
I tried to build a gcc-3.4-20050408 cross compiler for a powerpc-aix5.2 system, and I got the following: gcc -O9 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H gcov-dump.o version.o ../libiberty/libiberty.a -o gcov-dump gcc -c -O9 -mminimal-toc -gnatpg -gnata -I- -I. -Iada -I/home/ltg/software/src/work/gcc-3.4-20050408/gcc/ada /home/ltg/software/src/work/gcc-3.4-20050408/gcc/ada/ada.ads -o ada/ada.o gnat1: error: invalid option `minimal-toc' make[1]: *** [ada/ada.o] Error 1 make[1]: Leaving directory `/home/ltg/software/src/work/objdir/gcc' make: *** [all-gcc] Error 2 Lothar -- Summary: Cross build failure from i686-linux to powerpc-aix5.2 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ltg at zes dot uni-bremen dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21028
[Bug ada/21028] Cross build failure from i686-linux to powerpc-aix5.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:35 --- *** This bug has been marked as a duplicate of 6872 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21028
[Bug ada/6872] can't build cross including ada to powerpc-ibm-aix4.3.3.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:35 --- *** Bug 21028 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ltg at zes dot uni-bremen ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6872
[Bug target/21017] ppc 64bit target not using rlwinm
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 19:40 --- Looks like subregs are getting in the way. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 19:40:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21017
[Bug tree-optimization/21029] New: vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
csets___elabb gets miscompiled in stage2, such that stage3 enters and endless loop compiling ada.ads. Unfortunately, vrp seldom kicks in, so it's a bit difficult to duplicate the problem. Perhaps it would make sense to add a command-line option to force vrp on, and add that to torture, just to see how it goes? -- Summary: vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: aoliva at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21029] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From dnovillo at redhat dot com 2005-04-14 20:18 --- Subject: Re: New: vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances On Thu, Apr 14, 2005 at 08:16:09PM -, aoliva at gcc dot gnu dot org wrote: > Unfortunately, vrp seldom kicks in, so it's a bit difficult to > duplicate the problem. > Hmm? VRP is automatically enabled at -O2 and higher. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21029] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
20:19 ---
Created an attachment (id=8632)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8632&action=view)
C testcase that triggers the bug
The problem is that (from the vrp dump):
Simulating statement (from ssa_edges): jD.1487_6 = (intD.0) iD.1486_1;
Visiting statement:
jD.1487_6 = (intD.0) iD.1486_1;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = j_6)
(get_scalar_evolution
(scalar = j_6)
(scalar_evolution = {123, +, 1}_1))
(set_scalar_evolution
(scalar = j_6)
(scalar_evolution = {123, +, 1}_1))
)
Found new range [123, 2147483647] for j_6
[...]
Visiting statement:
if (jD.1487_6 < 0) goto ; else goto ;
Visiting conditional with predicate: j_6 < 0
With known ranges
j_6: [123, 2147483647]
Predicate evaluates to: 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:25 --- The other thing is that signed integer wrapping is defined if we add -fwrapv which means we now miss compile some java programs too. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-04-14 20:25:02 date|| Summary|vrp miscompiles Ada front- |[4.1 Regression] vrp |end, drops loop exit test in|miscompiles Ada front-end, |well-defined wrap-around|drops loop exit test in |circumstances |well-defined wrap-around ||circumstances Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21030] New: ICE in set_value_range building 176.gcc with -O2
Mainline GCC for powerpc-linux gets an ICE compiling 176.gcc from SPEC CPU2000 with -O2, as shown with this minimized test case: elm3b149% /home/janis/tools/gcc-mline-20050414/bin/gcc -O2 -c bug.c bug.c: In function ‘schedule_unit’: bug.c:5: internal compiler error: in set_value_range, at tree-vrp.c:124 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. That abort is in checking code added on 2005-04-09 by dnovillo. -- Summary: ICE in set_value_range building 176.gcc with -O2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:42 --- (In reply to comment #3) > The other thing is that signed integer wrapping is defined if we add -fwrapv > which means we now miss > compile some java programs too. Actually I tried basically the same program with the casts removed and it worked, it has to do with the casts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21030] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-14 20:43 --- Created an attachment (id=8633) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8633&action=view) minimized test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21031] New: Another missed forward propagation opportunity
Consider:
int
foo (int a)
{
int b = a != 0;
unsigned char c = b;
if (c)
return 1;
else
return 0;
}
We end up with code like this:
b_3 = a_2 != 0;
c_4 = (unsigned char) b_3;
if (c_4 != 0) goto ; else goto ;
We want to forward-propagate the preceding two statements into the COND_EXPR
and get
if (a_2 != 0) goto ; else goto ;
Unlike forward propagation opportunities noted in PR 14754 or PR15558,
this kind of opportunity occurs often in practice.
--
Summary: Another missed forward propagation opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: kazu at cs dot umass dot edu
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:44 --- Confirmed, also happens on i686-pc-linux-gnu. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-04-14 20:44:19 date|| Summary|ICE in set_value_range |[4.1 Regression] ICE in |building 176.gcc with -O2 |set_value_range building ||176.gcc with -O2 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21031] Another missed forward propagation opportunity
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 20:50 --- Confirmed, I thought I saw a bug like before. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-14 20:50:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Additional Comments From schlie at comcast dot net 2005-04-14 21:28 --- (In reply to comment #0) I guess I misunderstand the problem, as given: const double ggPi = 3.14159265358979323846; double const divPi = 1 / ggPi; It would seem that neither ggPi or divPI should be designated "unchanging" at the tree/rtl level, as neither are global static const objects, although: 3.14159265358979323846 is, if stored as a value; as opposed to being inlined in the code as an immediate. ggPi and divPi are simply variables which are initialized with values at runtime; where the fact that they're "const" has prevented an assignment (other than an initializing one) being accepted as valid during semantic analysis. Where post semantic analysis, they're just variables just like any others which happen to have no assignments specified post initialization (as enforced by the front end); so should not be marked READONLY/unchanging to begin with, it would seem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-14 21:49 --- Created an attachment (id=8634) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8634&action=view) Proposed fix for PR 18495. This appears to fix the benchmark in question. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug c/21032] New: GCC 3.4.3 wrongly reorders floating-point operations
If you compile the function
void assign2(float* a, double b) {
volatile float v = -b;
*a = -v;
}
you will see that GCC 3.4.3, e.g., at -O2, produces
fldl12(%ebp)
fstps -20(%ebp)
movl8(%ebp), %eax
flds-20(%ebp)
fchs
fstps -4(%ebp)
flds-4(%ebp)
fchs
fstps (%eax)
where the first sign change is performed /after/ reducing the
precision and not /before/, as I believe it should (according
to ISO/IEC 9899, 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
The produced code seems also very badly optimized, considering
that something like
fldl12(%ebp)
fchs
fstps -4(%ebp)
flds-4(%ebp)
fchs
fstps (%eax)
would be significantly more efficient (besides being correct).
The same problem can be seen with gcc-4.0.0 20050406 (Fedora Core 3).
Roberto Bagnara
--
Summary: GCC 3.4.3 wrongly reorders floating-point operations
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14 22:01 --- Note neg just flips a bit so it is correct anyways and there is no loss of precession. This also happens on ppc darwin, I don't know what to make of this. A C person has to comment to say something about this. -- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c/21033] New: Erroneous "excess elements in array initializer" warning
gcc erroneously reports "excess elements in array initializer" under certain
circumstances (sample code attached). I'm using gcc 3.3.3 under Fedora Core 2,
but I've seen the same problem on 3.4 and 4.0 experimental.
begin self-contained test program bug.c
/* I know you don't want #includes, but this is here just for the
* sake of printf(). It can probably be safely removed. */
#include
/
* This array is okay.
/
int *a[] =
{
(int []) { 1, 2, 3, 4, 0 },
(int []) { 5, 6, 0 },
(int []) { 7, 8, 9, 10, 11, 12, 13, 0 },
(int []) { 14, 0 }
};
/
* This array should be identical. It contains all the same
* elements as a[], but this time the size (4) is specified.
* Gcc generates "excess element" warnings for each sub-array
* with more than 4 elements, even though the length of these
* arrays has NOT been specified.
/
int *b[4] =
{
(int []) { 1, 2, 3, 4, 0 }, /*
WARNING: excess elements in array initializer */
(int []) { 5, 6, 0 },
(int []) { 7, 8, 9, 10, 11, 12, 13, 0 },/* WARNING: excess
elements in array initializer */
(int []) { 14, 0 }
};
/
* This array is the same as b[], except the size of each sub-
* array is specified. It compiles without warnings and looks
* the same as a[] when passed to print_array().
/
int *c[4] =
{
(int [5]) { 1, 2, 3, 4, 0 },
(int [3]) { 5, 6, 0 },
(int [8]) { 7, 8, 9, 10, 11, 12, 13, 0 },
(int [2]) { 14, 0 }
};
/
* Not only does the compiler throw warnings, it also produces
* different code. On my machine, print_array() produces the
* same output from a[] and c[], but not from b[].
/
void
print_array (int **ptr, int count)
{
int i, j;
for (i=0; i < count; i++)
for (j=0; ptr[i][j]; j++)
printf ("%d ", ptr[i][j]);
printf ("\n");
}
int main (int argc, char **argv)
{
print_array (a, sizeof (a) / sizeof (*a));
print_array (b, sizeof (b) / sizeof (*b));
print_array (c, sizeof (c) / sizeof (*c));
return 0;
}
end self-contained test program bug.c
Here is the gcc command line. Where should I attach the -save-temps
output files?
# gcc -v -save-temps bug.c
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/cc1 -E -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 bug.c bug.i
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.c -auxbase bug -version -o bug.s
GNU C version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) (i386-redhat-linux)
compiled by GNU C version 3.3.3 20040412 (Red Hat Linux 3.3.3-7).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129392
bug.c:23: warning: excess elements in array initializer
bug.c:23: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
bug.c:25: warning: excess elements in array initializer
bug.c:25: warning: (near initialization for `(anonymous)')
as -V -Qy -o bug.o bug.s
GNU assembler version 2.15.90.0.3 (i386-redhat-linux) using BFD version
2.15.90.0.3 20040415
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crt1.o
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crti.o
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtbegin.o
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../.. bug.o -lgcc --as-needed
-lg
[Bug c/21033] Erroneous "excess elements in array initializer" warning
--- Additional Comments From acct4290 at dedion dot com 2005-04-14 22:12 --- Created an attachment (id=8635) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8635&action=view) Source file for self-contained test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 22:14
---
Reduced down to:
void
foo (int unit)
{
int i;
for (i = 0; unit; i++, unit--)
{
if (i >= 0)
{
int j = i;
while (j)
j--;
}
}
}
--
What|Removed |Added
CC||kazu at cs dot umass dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
