[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From mark at codesourcery dot com 2005-04-14 06:02
---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes
one argument null on entry
Jakub Jelinek wrote:
On Tue, Apr 12, 2005 at 05:54:58PM -, mmitchel at gcc dot gnu dot org
wrote:
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-12
17:54 ---
I like the simpler approach. If someone would test that for 4.0, I'd be
ecstatic.
Here is what I have bootstrapped/regtested on
{i386,x86_64,ia64,ppc,ppc64,s390,s390x}-linux.
Please apply this to the 4.0 branch forthwith. Thanks for taking the
initiative; Alexandre, Roger, thanks for working on this 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 cvs-commit at gcc dot gnu dot org 2005-04-14 06:14 --- Subject: Bug 20126 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-14 06:14:41 Modified files: gcc: ChangeLog loop.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050414-1.c Log message: 2005-04-14 Alexandre Oliva [EMAIL PROTECTED] Roger Sayle [EMAIL PROTECTED] PR target/20126 * loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed, signal that all GIVs couldn't be reduced. * gcc.c-torture/execute/20050414-1.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.151r2=2.7592.2.152 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.522.8.1r2=1.522.8.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.123r2=1.5084.2.124 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050414-1.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug rtl-optimization/21002] RTL prologue and basic-block reordering pessimizes delay-slot filling
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-14 06:27 --- I'm interested too. :-) FWIW, when I did the transition on SPARC, I compared the assembly code generated for all testcases in gcc.c-torture/compile at -O2; IIRC there were a few regressions related to delay-slot filling too, but I think I eliminated them with a couple of patches (probably to reorg.c). -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21002
[Bug c/21018] New: initilizing string litteral data improperly maked frame-relative, should be readonly static const.
The following two literal initializer data should both be considered static
const data references:
char s[5] = abcde;
char t[5] = {'a','b','c','d','e'};
the memory reference to abcde should be marked readonly, not frame-relative
(as it isn't),
as otherwise it's impossible to properly identify static const data memory
references at the
tree/rtl level as may be required for target specific code/data
generation/optimization.
The following shows the problem (as well as a missed optimization associated
with potentially
being able to access the initializer data directly, as opposed to accessesing
the frame-relative
variable data string/array after being copied if never modifed; and an
inappropriate inline of
function foo() which should not have likely been inlined given it's size, and
note that bar being
identical wan't inlined, which is correct):
volatile char v;
void foo ( void )
{
char x[5] = abcde;
v = x[v];
}
void bar ( void )
{
char y[5] = {'a','b','c','d','e'};
v = y[v];
}
int main ( void )
{
char x[5] = abcde; // Initializer string not marked READONLY static const.
char y[5] = {'a','b','c','d','e'}; // Although char arrary is correctly.
v = x[v];
v = y[v];
foo();
bar();
return 0;
}
resulting code:
volatile char v;
void foo ( void )
{
c6: cf 93 pushr28
c8: df 93 pushr29
ca: cd b7 in r28, 0x3d ; 61
cc: de b7 in r29, 0x3e ; 62
ce: 25 97 sbiwr28, 0x05 ; 5
d0: 0f b6 in r0, 0x3f; 63
d2: f8 94 cli
d4: de bf out 0x3e, r29 ; 62
d6: 0f be out 0x3f, r0; 63
d8: cd bf out 0x3d, r28 ; 61
char x[5] = abcde;
da: de 01 movwr26, r28
dc: 11 96 adiwr26, 0x01 ; 1
de: e0 e0 ldi r30, 0x00 ; 0
e0: f1 e0 ldi r31, 0x01 ; 1
e2: 85 e0 ldi r24, 0x05 ; 5
e4: 01 90 ld r0, Z+
e6: 0d 92 st X+, r0
e8: 81 50 subir24, 0x01 ; 1
ea: e1 f7 brne.-8 ; 0xe4 foo+0x1e
v = x[v];
ec: 80 91 10 01 lds r24, 0x0110
f0: fe 01 movwr30, r28
f2: e8 0f add r30, r24
f4: f1 1d adc r31, r1
f6: 81 81 ldd r24, Z+1; 0x01
f8: 80 93 10 01 sts 0x0110, r24
fc: 25 96 adiwr28, 0x05 ; 5
fe: 0f b6 in r0, 0x3f; 63
100: f8 94 cli
102: de bf out 0x3e, r29 ; 62
104: 0f be out 0x3f, r0; 63
106: cd bf out 0x3d, r28 ; 61
108: df 91 pop r29
10a: cf 91 pop r28
10c: 08 95 ret
010e bar:
}
void bar ( void )
{
10e: cf 93 pushr28
110: df 93 pushr29
112: cd b7 in r28, 0x3d ; 61
114: de b7 in r29, 0x3e ; 62
116: 25 97 sbiwr28, 0x05 ; 5
118: 0f b6 in r0, 0x3f; 63
11a: f8 94 cli
11c: de bf out 0x3e, r29 ; 62
11e: 0f be out 0x3f, r0; 63
120: cd bf out 0x3d, r28 ; 61
char y[5] = {'a','b','c','d','e'};
122: de 01 movwr26, r28
124: 11 96 adiwr26, 0x01 ; 1
126: e6 e0 ldi r30, 0x06 ; 6
128: f1 e0 ldi r31, 0x01 ; 1
12a: 85 e0 ldi r24, 0x05 ; 5
12c: 04 90 lpm r0, Z
12e: 0d 92 st X+, r0
130: 81 50 subir24, 0x01 ; 1
132: e1 f7 brne.-8 ; 0x12c bar+0x1e
v = y[v];
134: 80 91 10 01 lds r24, 0x0110
138: fe 01 movwr30, r28
13a: e8 0f add r30, r24
13c: f1 1d adc r31, r1
13e: 81 81 ldd r24, Z+1; 0x01
140: 80 93 10 01 sts 0x0110, r24
144: 25 96 adiwr28, 0x05 ; 5
146: 0f b6 in r0, 0x3f; 63
148: f8 94 cli
14a: de bf out 0x3e, r29 ; 62
14c: 0f be out 0x3f, r0; 63
14e: cd bf out 0x3d, r28 ; 61
150: df 91 pop r29
152: cf 91 pop r28
154: 08 95 ret
0156 main:
}
int main ( void )
{
156: c0 ef ldi r28, 0xF0 ; 240
158: d0 e1 ldi r29, 0x10 ; 16
15a: de bf out 0x3e, r29 ; 62
15c: cd bf out 0x3d, r28 ; 61
char x[5] = abcde; // Initializer string not marked READONLY static const.
15e: de 01 movwr26, r28
160: 11 96
[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] string_cst 0x160b840)) -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) var_decl 0x16791b0 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] string_cst 0x160b840)) -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] var_decl 0x167e438 C.3)) -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=gccr1=2.8283r2=2.8284 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/s390/s390-modes.def.diff?cvsroot=gccr1=1.8r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5344r2=1.5345 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20927.c.diff?cvsroot=gccr1=NONEr2=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=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.152r2=2.7592.2.153 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/s390/s390-modes.def.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.8r2=1.8.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.124r2=1.5084.2.125 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20927.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=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:
==
templateint N 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=8626action=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=8627action=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=8628action=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=8629action=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; No stacktrace available 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 URL: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=8630action=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=gccr1=2.8286r2=2.8287 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gccr1=2.6r2=2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5346r2=1.5347 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20657.c.diff?cvsroot=gccr1=NONEr2=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 URL: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=gccr1=2.8288r2=2.8289 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gccr1=2.74r2=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=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.153r2=2.7592.2.154 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.146.8.1r2=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 L0; else goto L5; 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 r_3, r_3 D.1157_5; 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 r_3, r_3 D.1157_5) 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::GenLinearHierarchyLoki: Typelistf1, Loki::Typelistf2, Loki::NullType , ChainList, i::Functor, ChainFunctors, 0::Stub': 6.cpp:50: instantiated from `ChainWrapperLoki::GenLinearHierarchyLoki::Type istf1, Loki::Typelistf2, Loki::NullType , ChainList, i::Functor, Chai Functors, 0::Stub ' 6.cpp:71: instantiated from `Loki::GenScatterHierarchyLoki::GenLinearHierarc yLoki::Typelistf1, Loki::Typelistf2, Loki::NullType , ChainList, i:: unctor, ChainFunctors, 0::Stub, ChainWrapper' 6.cpp:71: instantiated from `Loki::GenScatterHierarchyLoki::TypelistLoki::G nLinearHierarchyLoki::Typelistf1, Loki::Typelistf2, Loki::NullType , C ainList, i::Functor, ChainFunctors, 0::Stub, Loki::TypelistLoki::GenLinea HierarchyLoki::Typelistf2, Loki::Typelistf1, Loki::NullType , ChainLi t, i::Functor, ChainFunctors, 1::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 URL: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=8631action=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:
templateint N struct X { char x[N]; };
templatetypename T X1 + sizeof(T) - sizeof(T) F(T const );
templateint N 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=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-2.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-3.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-4.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-5.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-6.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-7.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-9.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5349r2=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 T 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 T 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 L38; else goto L10; L38:; ivtmp.19 = 0; L0:; if (__builtin_expect (ivtmp.19 9, 0) != 0) goto L2; else goto L7; L2:; _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); L7:; D.499 = *a[ivtmp.19]; *b[ivtmp.19] = D.499 * D.499; ivtmp.19 = ivtmp.19 + 1; if ((unnamed type) D.474 == ivtmp.19) goto L10; else goto L0; 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=8632action=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 L2; else goto L1;
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 URL: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=8633action=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 L0; else goto L2;
We want to forward-propagate the preceding two statements into the COND_EXPR
and get
if (a_2 != 0) goto L0; else goto L2;
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=8634action=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
