[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2005-12-19 07:25 --- Fixed in 4.0, not a bug in 4.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2005-12-19 07:23 --- Fixed in 4.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug fortran/25264] write to internal unit from the string itself gives wrong result ?
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-12-19 07:22 --- Fixed in 4.1 and 4,2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
[Bug libfortran/25039] [4.1 only] comma short-circuit field width
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2005-12-19 07:20 --- Fixed in 4.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25039
[Bug libfortran/25463] T edit descriptor and ADVANCE="no"
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-12-19 07:03 --- Commited to 4.2 Will commit to 4.1 in ~24 hours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25463
[Bug libfortran/25463] T edit descriptor and ADVANCE="no"
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-12-19 07:02 --- Subject: Bug 25463 Author: jvdelisle Date: Mon Dec 19 07:02:05 2005 New Revision: 108785 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108785 Log: 2005-12-18 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25463 * gfortran.dg/advance.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/advance.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25463
[Bug libfortran/25463] T edit descriptor and ADVANCE="no"
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-12-19 06:52 --- Subject: Bug 25463 Author: jvdelisle Date: Mon Dec 19 06:52:33 2005 New Revision: 108784 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108784 Log: 2005-12-18 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25463 * io/transfer.c (finalize_transfer): Fix execution order so that next_record is set to zero in all cases. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25463
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-12-19 06:52 --- Confirmed and added Bernard as Cc. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-19 06:52:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #15 from steven at gcc dot gnu dot org 2005-12-19 06:30 --- Could this be a dup of Bug 23585? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #14 from danglin at gcc dot gnu dot org 2005-12-19 04:45
---
I did a checkout as of Sep 12, 2005 00:00:00 UTC and get the same assembly
code as in the initial report using the following compilation options:
"-Os -w -S -mschedule=7100LC". The build was done on hppa2.0w-hp-hpux11.11.
Here's some rtl from 54.barriers and 55.dbr showing the end of the initial
loop in the function testB:
(jump_insn:TI 18 15 186 (set (pc)
(if_then_else (ne (reg/v/f:SI 6 %r6 [orig:98 p___4463 ] [98])
(reg/f:SI 19 %r19 [111]))
(label_ref:SI 11)
(pc))) 25 {*pa.md:1700} (insn_list:REG_DEP_TRUE 17
(insn_list:REG_DE
P_ANTI 13 (insn_list:REG_DEP_TRUE 15 (nil
(expr_list:REG_DEAD (reg/f:SI 19 %r19 [111])
(expr_list:REG_BR_PROB (const_int 8750 [0x222e])
(nil
(note 186 18 20 NOTE_INSN_LOOP_END)
(note 20 186 45 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 45 20 23 NOTE_INSN_DELETED)
(insn:TI 23 45 21 (set (reg:SI 28 %r28 [114])
(mem/s/j/c:SI (plus:SI (reg/v/f:SI 6 %r6 [orig:98 p___4463 ] [98])
(const_int -8 [0xfff8])) [0+0 S4 A32])) 37 {*pa.md:2291}
(ni
l)
(expr_list:REG_EQUAL (mem/s/j/c:SI (plus:SI (reg/v/f:SI 6 %r6 [orig:98
p___4
463 ] [98])
(const_int -8 [0xfff8])) [0+0 S4 A32])
(nil)))
(insn 21 23 196 (set (reg:SI 1 %r1)
(high:SI (symbol_ref:SI ("sB") [flags 0x80] )))
48
{*pa.md:2737} (nil)
(expr_list:REG_EQUIV (high:SI (symbol_ref:SI ("sB") [flags 0x80] ))
(nil)))
(insn 253 15 186 (sequence [
(jump_insn:TI 18 15 23 (set (pc)
(if_then_else (ne (reg/v/f:SI 6 %r6 [orig:98 p___4463 ]
[98]
)
(reg/f:SI 19 %r19 [111]))
(label_ref:SI 11)
(pc))) 25 {*pa.md:1700} (insn_list:REG_DEP_TRUE 17
(insn
_list:REG_DEP_ANTI 13 (insn_list:REG_DEP_TRUE 15 (nil
(expr_list:REG_BR_PRED (const_int 6 [0x6])
(expr_list:REG_DEAD (reg/f:SI 19 %r19 [111])
(expr_list:REG_BR_PROB (const_int 8750 [0x222e])
(nil)
(insn:TI 23 18 186 (set (reg:SI 28 %r28 [114])
(mem/s/j/c:SI (plus:SI (reg/v/f:SI 6 %r6 [orig:98 p___4463
]
[98])
(const_int -8 [0xfff8])) [0+0 S4 A32])) 37
{*pa.
md:2291} (nil)
(expr_list:REG_EQUAL (mem/s/j/c:SI (plus:SI (reg/v/f:SI 6 %r6
[o
rig:98 p___4463 ] [98])
(const_int -8 [0xfff8])) [0+0 S4 A32])
(nil)))
]) -1 (nil)
(nil))
(note 186 253 20 NOTE_INSN_LOOP_END)
(note 20 186 45 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 45 20 21 NOTE_INSN_DELETED)
(insn 21 45 196 (set (reg:SI 1 %r1)
(high:SI (symbol_ref:SI ("sB") [flags 0x80] )))
48
{*pa.md:2737} (nil)
(expr_list:REG_EQUIV (high:SI (symbol_ref:SI ("sB") [flags 0x80] ))
(nil)))
As can be seen, the memory load that causes the segmentation fault was outside
the loop in the 54.barriers pass.
>From an optimisation standpoint, I'm a bit surprised that the memory load
was selected for placement into the delay slot rather than the following set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-19 04:33 --- This regression is caused by "svn update -r 107850" on 4.1 "svn update -r 107745" on trunk. This a patch I committed, but until my hard drive is replaced I won't be able to revert without too much pain. If anyone else wants to revert the patch, please do so. We should also alert blindvt (Bernhard Fischer) to the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug target/21715] [4.0/4.1 regression] code-generation performance regression
--- Comment #6 from kazu at gcc dot gnu dot org 2005-12-19 02:30 --- I just compiled the testcase on x86_64. I got foo: .LFB2: movq%rdi, %rax negq%rax andq%rdi, %rax ret which is as good as the assembly generated by 3.4.3. This is no longer a regression on 4.2. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org Known to work|3.4.3 |3.4.3 4.2.0 Summary|[4.0/4.1/4.2 regression]|[4.0/4.1 regression] code- |code-generation performance |generation performance |regression |regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug c/25491] gcc segfaults compiling very long expressions
--- Comment #1 from geckosenator at gmail dot com 2005-12-19 02:27 --- Created an attachment (id=10531) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10531&action=view) bzip2 compressed file that produces gcc segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25491
[Bug c/25491] New: gcc segfaults compiling very long expressions
I was writing a program that evaluates an operator tree with variables constants and operators. Rather than recursively iterate the tree many times for different variable values to evaluate it.. I printed the tree into a source file, compiled it as a shared library with gcc and dynamically linked it and call the function. In my case this is a much faster solution.. unless the tree is too big: $ /usr/bin/gcc -shared -o libevaleqn.so evaleqn.c evaleqn.c:2:9: warning: null character(s) ignored gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://bugs.gentoo.org/> for instructions. For smaller sizes it compiles fine. I'm guessing this is a limitation on the length of expressions supported by gcc. I tested this on x86_64 (gcc 3.4.4) and i686 (gcc 3.4.4 and 3.3.6) and the results are the same. -- Summary: gcc segfaults compiling very long expressions Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geckosenator at gmail dot com GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25491
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|[4.1 and 4.2 Regression]|[4.1/4.2 Regression] fortran |fortran fixed-form literal |fixed-form literal character |character constant not |constant not padded. |padded. | Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug fortran/25486] [4.1 and 4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #1 from kargl at gcc dot gnu dot org 2005-12-19 01:00 --- I just bootstrapped 4.1 and the regression is also in 4.1! I believe it appeared after 27 Nov 05 in that my older 4.1 gfortran, which wokred correctly, had that timestamp. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Summary|[4.2 Regression] fortran|[4.1 and 4.2 Regression] |fixed-form literal character|fortran fixed-form literal |constant not padded.|character constant not ||padded. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug rtl-optimization/24810] [4.1/4.2 Regression] mov + mov + testl generated instead of testb
--- Comment #7 from kazu at gcc dot gnu dot org 2005-12-19 00:37 --- We are basically talking about narrowing the memory being loaded for testing. Now, can we really optimize this case? We've got const volatile unsigned long *addr I am not sure if "volatile" allows us to change the width of a memory read. I know a chip that expects you to read memory at one address repeatedly to transfer a block of data, and people probably use volatile for this kind of case. If the compiler changes the width of memory access, we may be screwing up something. IMHO, if byte access is really desired, the code should be rewritten that way. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24810
[Bug tree-optimization/25485] VRP misses an "if" with TRUTH_AND_EXPR statement that could be optimized away
--- Comment #3 from kazu at gcc dot gnu dot org 2005-12-19 00:01 --- I've got a preliminary patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25485
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
--- Comment #6 from steven at gcc dot gnu dot org 2005-12-18 23:52 --- Kenny is working on a fix. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-18 23:44 ---
We get to iterative_dataflow from df_analyze_subcfg with this dataflow
argument:
(gdb) p *dataflow
$11 = {repr = SR_BITMAP, gen = 0xf43d90, kill = 0xf439d0, in = 0xf55ac0, out =
0xf57ca0,
dir = DF_FORWARD, conf_op = DF_UNION, n_blocks = 2, order = 0xf35cc0,
transfun = 0x645b5e , data = 0x0}
(gdb)
Then we do in iterative_dataflow:
for (i = 0; i < dataflow->n_blocks - NUM_FIXED_BLOCKS; i++)
i.e. we do nothing at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug target/25402] [4.2 Regression] PCH is broken
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 23:34 --- Fixed by: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01399.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg01399.html Status|NEW |RESOLVED Component|middle-end |target Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25402
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
--- Comment #4 from steven at gcc dot gnu dot org 2005-12-18 23:24 --- Works in r108712. Breaks in r108713. That's the ENTRY/EXIT block renumbering patch. Somehow this seems to have messed up df_analyze_subcfg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug rtl-optimization/24810] [4.1/4.2 Regression] mov + mov + testl generated instead of testb
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2005-12-18 22:57 --- (In reply to comment #5) > Simplified testcase seems to work for me on 4.1 branch: > restore_fpu: > movl4(%esp), %edx > movlboot_cpu_data+12, %eax > testl $16777216, %eax 4.0 still does better, it uses a single "testb" instruction instead of 2 dependent movl + testb instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24810
[Bug tree-optimization/25487] Assertion failure in pointer analysis
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 --- *** Bug 25488 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25487
[Bug tree-optimization/25481] [4.2 Regression] Segfault in tree-ssa-structalias.c
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-18 22:45 --- *** Bug 25487 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dps at simpson dot demon dot ||co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25481
[Bug tree-optimization/25487] Assertion failure in pointer analysis
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-18 22:45 --- *** This bug has been marked as a duplicate of 25481 *** *** This bug has been marked as a duplicate of 25481 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25487
[Bug c/25490] Assertion failure in pointer analysis
--- Comment #2 from dps at simpson dot demon dot co dot uk 2005-12-18 22:43 --- Created an attachment (id=10530) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10530&action=view) Example program that tickles the bug (with -O for n>=1). The example is based on a real example without the obvious infinite loops and a slightly bugger structure (actually a header for a string which starts at p+1). I doubt it is revelent but the processor is an AMD Athlon(tm) XP 3200+. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25490
[Bug tree-optimization/25487] Assertion failure in pointer analysis
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 --- *** Bug 25490 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25487
[Bug c/25490] Assertion failure in pointer analysis
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 --- *** This bug has been marked as a duplicate of 25487 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25490
[Bug c/25488] Assertion failure in pointer analysis
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 22:40 --- *** This bug has been marked as a duplicate of 25487 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25488
[Bug c/25490] New: Assertion failure in pointer analysis
There is a pointer arithmetic related assersion failure, apparently in the logic attempting to deduce what the pointer might be pointing at. If you compile wiht -O0 or chaneg p+1 to p the bug is apparently bypassed. My "screenshot" is [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version gcc (GCC) 4.2.0 20051217 (experimental) 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. [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc -g -O2 -o /tmp/foo.o /tmp/foo.c /tmp/foo.c: In function 'foo': /tmp/foo.c:32: internal compiler error: in handle_ptr_arith, at tree-ssa-structalias.c:3188 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Assertion failure in pointer analysis Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dps at simpson dot demon dot co dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25490
[Bug rtl-optimization/25489] New: Suboptimal code generated for coparisons on Sparc
This code:
typedef struct {
int protected_mode;
int x;
} TScreen;
extern void ClearRight (TScreen *screen, int n);
extern void ClearLeft(TScreen * screen);
extern void ClearLine(TScreen * screen);
void
do_erase_line(TScreen * screen, int param, int mode)
{
int saved_mode = screen->protected_mode;
if (saved_mode == 1
&& saved_mode != mode)
screen->protected_mode = 0;
switch (param) {
case -1:/* DEFAULT */
case 0:
ClearRight(screen, -1);
break;
case 1:
ClearLeft(screen);
break;
case 2:
ClearLine(screen);
break;
}
screen->protected_mode = saved_mode;
}
is compiled to: (when using -O2 -mcpu=ultrasparc using gcc-4.0.2 and gcc-4.2)
do_erase_line:
save%sp, -112, %sp
ld [%i0], %l0
xor %l0, 1, %g1 <- from here
xor %l0, %i2, %i2
subcc %g0, %g1, %g0
subx%g0, -1, %g2
subcc %g0, %i2, %g0
addx%g0, 0, %g1
andcc %g2, %g1, %g0 <- to here
bne,a,pt %icc, .LL2
st %g0, [%i0]
.LL2:
cmp %i1, 1
be,pn %icc, .LL6
nop
[snip]
The code generated for the "if" can be better implemented
as (pseudoassembly):
xor save_mode, 1, tmp1
xnor save_mode, mode, tmp2
orcc tmp1, tmp2
I don't know if this is a Sparc specific problem, or a general problem.
--
Summary: Suboptimal code generated for coparisons on Sparc
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25489
[Bug c/25488] New: Assertion failure in pointer analysis
The source here generates an asserion failure compiled with anything above -O0. Changing p+1 to p seems to avoid the bug. The infinite loops are not a feature of the original code but the uderlying problem appears to be indentical. "screenshot" [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version gcc (GCC) 4.2.0 20051217 (experimental) 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. [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version gcc (GCC) 4.2.0 20051217 (experimental) 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. [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc -g -O2 -o /tmp/foo.o /tmp/foo.c /tmp/foo.c: In function 'foo': /tmp/foo.c:32: internal compiler error: in handle_ptr_arith, at tree-ssa-structalias.c:3188 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Assertion failure in pointer analysis Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dps at simpson dot demon dot co dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25488
[Bug c/25487] New: Assertion failure in pointer analysis
The source here generates an asserion failure compiled with anything above -O0.
Changing p+1 to p seems to avoid the bug. The infinite loops are not a feature
of the original code but the uderlying problem appears to be indentical.
"screenshot"
[EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version
gcc (GCC) 4.2.0 20051217 (experimental)
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.
[EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version
gcc (GCC) 4.2.0 20051217 (experimental)
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.
[EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc -g -O2 -o
/tmp/foo.o
/tmp/foo.c
/tmp/foo.c: In function 'foo':
/tmp/foo.c:32: internal compiler error: in handle_ptr_arith, at
tree-ssa-structalias.c:3188
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
foo.c is the following nonsense
---cut here---
#include
typedef struct
{
int foo;
} s_foo;
static void bar(const s_foo *p,
int (*cmp)(const char *, const char *))
{
const char *pd;
int r;
pd=(const char *) (p+1);/* The p+1 is apparently critical */
while (1)
{
r=(*cmp)(pd, "2");
if (r<=0)
fputc('-', stdout);
else
fputc('+', stdout);
}
return;
}
void foo(int (*cmp)(const char *, const char *))
{
s_foo a;
while(1)
{
bar(&a, cmp);
}
}
---cut here---
--
Summary: Assertion failure in pointer analysis
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25487
[Bug tree-optimization/25481] [4.2 Regression] Segfault in tree-ssa-structalias.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-12-18 22:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25481
[Bug tree-optimization/25481] [4.2 Regression] Segfault in tree-ssa-structalias.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-12-18 22:20 --- Subject: Bug 25481 Author: rguenth Date: Sun Dec 18 22:20:31 2005 New Revision: 108763 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108763 Log: 2005-12-18 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/25481 * tree-ssa-structalias.c (handle_ptr_arith): Handle accesses we don't have a varinfo for. * gcc.dg/torture/pr25481.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr25481.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25481
[Bug rtl-optimization/24810] [4.1/4.2 Regression] mov + mov + testl generated instead of testb
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-12-18 20:53 --- Simplified testcase seems to work for me on 4.1 branch: restore_fpu: movl4(%esp), %edx movlboot_cpu_data+12, %eax testl $16777216, %eax je .L2 jmp foo .L2: movl%edx, 4(%esp) jmp bar "jmp foo" is not elliminated because we don't have pattern for conditional tailcalls. Should not be big issue to add the neccesary patterns however. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24810
[Bug fortran/25486] New: [4.2 Regression] fortan fixed-form literal character constant not padded.
There is a regression in 4.2 from 4.1 with fixed-form literal character constants that are continued to a new line. Consider the following fixed-form code: program a character(len=90) c c A tab is between 9 and 0. c = '1234567 &890' print *, c end The output with 4.1 and trunk are kargl[216] gfc41 -o z a.f kargl[217] ./z 1234567 890 kargl[218] gfc4x -o z a.f kargl[219] ./z 123456789 0 gfortran 4.1 agrees with the output from NAG's compiler and with g77. -- Summary: [4.2 Regression] fortan fixed-form literal character constant not padded. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug c++/11858] Name lookup error ignored when instantiated from expression within sizeof() in template function parameter
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-18 20:14 --- This looks like a case where array decays to a pointer too early problem (PR 24666). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||24666 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11858
[Bug tree-optimization/25485] VRP misses an "if" with TRUTH_AND_EXPR statement that could be optimized away
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 19:19 --- I should note that this only happens for targets whos BRANCH_COST is semi high. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25485
[Bug tree-optimization/25485] VRP misses an "if" with TRUTH_AND_EXPR statement that could be optimized away
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 19:18 --- Confirmed, the problem is that VRP folds a > 63 and then props that into temp && temp1 but does not prop after that. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-18 19:18:37 date|| Summary|VRP misses an "if" statement|VRP misses an "if" with |that could be optimized away|TRUTH_AND_EXPR statement ||that could be optimized away http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25485
[Bug tree-optimization/25485] New: VRP misses an "if" statement that could be optimized away
Consider:
int
foo (int a, int b)
{
if (a > 50)
return 19;
if (a > 63 && b < 50)
return 17;
return 31;
}
VRP does not optimize away the second "if" statement.
Here is the output from VRP.
foo (a, b)
{
_Bool D.1662;
_Bool D.1661;
_Bool D.1660;
int D.1659;
:
if (a_2 > 50) goto ; else goto ;
:;
D.1660_4 = 0;
D.1661_6 = b_5 <= 49;
D.1662_7 = 0;
if (D.1662_7) goto ; else goto ;
:;
# D.1659_1 = PHI <19(2), 17(4), 31(3)>;
:;
return D.1659_1;
}
--
Summary: VRP misses an "if" statement that could be optimized
away
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25485
[Bug rtl-optimization/25484] [4.2 Regression] Fix for PR25456 is wrong
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Summary|Fix for PR25456 is wrong|[4.2 Regression] Fix for ||PR25456 is wrong Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25484
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #13 from steven at gcc dot gnu dot org 2005-12-18 18:39 --- Ugh, I guess that means going back to a checkout of the day of the report if we want to reproduce this :-/ -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-10-16 21:52:38 |2005-12-18 18:39:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug c/25484] Fix for PR25456 is wrong
--- Comment #1 from jbglaw at lug-owl dot de 2005-12-18 18:37 --- Created an attachment (id=10529) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10529&action=view) Correct fix This is the correct fix, see http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01258.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25484
[Bug c/25484] New: Fix for PR25456 is wrong
PR25456 was fixed wrongly. This'll make the compiler ICE later on if eg. used to cross-compile uClibc. -- Summary: Fix for PR25456 is wrong Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbglaw at lug-owl dot de GCC target triplet: vax-dec-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25484
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-18 17:30:29 |2005-12-18 18:26:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-18 18:01 --- Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os > Unable to reproduce with GCC 4.1 without further feedback. Apparently already > fixed or made latent on GCC 4.2. The dumps in comment #1 could use some > comment so that people reading this bug report don't have to analyze those for > themselves. I tried to reproduce it with gcc version 4.1.0 20051212 (prerelease) and the incorrect code is no longer generated. The loop now looks like: L$0318: .CALL bl myrnd,%r2 nop ldo 8(%r7),%r19 stbs,ma %r28,1(%r6) comb,<> %r19,%r6,L$0318 addil LR'sB-$global$,%r27 ldw -8(%r6),%r28 Compare with the code shown in the initial report. The "ldw" isn't in the delay slot of the "comb", so it doesn't get executed in the loop every iteration. The loop is tricky in that it exits with r6 aligned to a four byte boundary. I don't know if the bug has been fixed or is just latent. I would ignore the dumps in comment #1. This is probably a reorg issue. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug tree-optimization/25481] [4.2 Regression] Segfault in tree-ssa-structalias.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-12-18 17:43 --- We're hitting the assert at #1 0x0856ac47 in handle_ptr_arith (lhsc=0x8868880, expr=0x401942d0) at tree-ssa-structalias.c:3188 gcc_assert (first_vi_for_offset (temp, rhsoffset) != NULL); with temp being the array of size 32 and rhsoffset being 32. We're taking the address of a[1] which is valid. We should just ignore this here and continue. I will prepare and test a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25481
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-18 17:41 --- This worked in "4.2.0 20051214" but not in "4.2.0 20051217". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-18 17:38 --- Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os > First, it looks from the command lines in the report that the problematic > compiler is GCC 3.3. But the report is about gcc 4.1.0. No, it wasn't 3.3. Se http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00754.html. > Second, I can't reproduce the problem with > "GNU C version 4.1.0 20051216 (prerelease) (hppa2.0-unknown-linux-gnu)". > > I tried "./xgcc -B. t.c -Os -mschedule=7100LC" but I get warnings: > t.c: In function 'testA': > t.c:90: warning: overflow in implicit constant conversion > t.c: In function 'testK': > t.c:100: warning: overflow in implicit constant conversion The tests are built with "-w". Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-18 17:30 ---
Confirmed, reduced testcase:
static int mdct_win[8][36];
int decode_init(double d)
{
int i = 0, j, k;
for(j=0; j<4; j++)
{
d*= 0.5;
mdct_win[j][i ] = ((int)(((d / (1<<5))) * (1LL<<32) + 0.5));
}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.2.0
Known to work||4.0.2 4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-12-18 17:30:29
date||
Summary|ICE on valid code with -O2 -|[4.2 Regression] ICE on
|fmove-loop-invariants |valid code with -O2 -fmove-
||loop-invariants
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug rtl-optimization/24408] [4.1/4.2 Regression] Invariant code no longer removed from loop when doing FDO.
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 17:17 --- This will *NOT* be fixed for GCC 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
[Bug tree-optimization/16876] [3.4/4.0/4.1/4.2 Regression] ICE on testcase with -O3 in gen_lowpart
--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 17:15 --- rth assigned this to himself: http://gcc.gnu.org/ml/gcc-bugs/2005-11/msg02843.html A progress report would be nice ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug tree-optimization/25481] [4.2 Regression] Segfault in tree-ssa-structalias.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-12-18 17:09 --- Will look at it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-18 17:04:58 |2005-12-18 17:09:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25481
[Bug tree-optimization/25481] [4.2 Regression] Segfault in tree-ssa-structalias.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-18 17:04 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 Known to work||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-12-18 17:04:58 date|| Summary|Segfault in tree-ssa- |[4.2 Regression] Segfault in |structalias.c |tree-ssa-structalias.c Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25481
[Bug c++/20103] [4.0/4.1/4.2 regression] ICE in create_tmp_var with C99 style struct initializer
--- Comment #45 from steven at gcc dot gnu dot org 2005-12-18 16:40 --- Alexandre, what is up with this bug? It's a gcc 4.1 regression assigned to you, could you please at least say whether you're working on this or not? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug rtl-optimization/25483] ICE on valid code with -O2 -fmove-loop-invariants
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2005-12-18 16:39 --- Created an attachment (id=10528) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10528&action=view) Triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug rtl-optimization/25483] New: ICE on valid code with -O2 -fmove-loop-invariants
Attached testcase when compiled by gcc version 4.2.0 20051217 (experimental) on x86 using: - gcc -O2 -fmove-loop-invariants -c -o mpegaudiodec.o mpegaudiodec.c - results in the following - mpegaudiodec.c: In function ‘decode_init’: mpegaudiodec.c:510: error: unrecognizable insn: (insn:HI 1144 718 1309 70 (set (reg:SI 507) (fix:SI (reg:DF 506))) -1 (insn_list:REG_DEP_TRUE 718 (nil)) (expr_list:REG_DEAD (reg:DF 506) (nil))) mpegaudiodec.c:510: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. - Works on x86_64. -- Summary: ICE on valid code with -O2 -fmove-loop-invariants Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drab at kepler dot fjfi dot cvut dot cz GCC target triplet: i?86-pc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug c++/23172] [4.1/4.2 Regression] ICE on integer initialization, GNU extension
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-18 16:36 --- Giovanni, you never assigned this bug to yourself as far as I can tell, but could you give this bug a quick look anyway, or otherwise unassign yourself from this bug? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug tree-optimization/24287] pure functions cause things to be call clobbered still
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-12-18 16:29 --- Subject: Re: pure functions cause things to be call clobbered still On Sun, 2005-12-18 at 15:48 +, kazu at gcc dot gnu dot org wrote: > > --- Comment #5 from kazu at gcc dot gnu dot org 2005-12-18 15:48 --- > Is this PR fixed? Or does it need some follow-up work? > It's fixed on improved-aliasing. I'm merging the required changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24287
[Bug libstdc++/25482] New: Specialize (overload) std::copy/find for streambuf iterators
As per the comment at the beginning of streambuf_iterator.h. -- Summary: Specialize (overload) std::copy/find for streambuf iterators Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25482
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #12 from uweigand at gcc dot gnu dot org 2005-12-18 16:06 --- Subject: Bug 21041 Author: uweigand Date: Sun Dec 18 16:06:55 2005 New Revision: 108760 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108760 Log: PR rtl-optimization/21041 * reload.c (find_reloads_subreg_address): Replace paradoxical subreg of MEM by widened access only if the resulting memory is properly aligned, even on !STRICT_ALIGNMENT targets. PR rtl-optimization/21041 * gcc.dg/pr21041.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr21041.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug c++/24278] [3.4/4.0/4.1/4.2 regression] ICE while trying to print out error
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 16:04 ---
comment #6 says "invalid code". So is this an ICE on valid, or _invalid_ code?
Anyway,
Starting program: /abuild/stevenb/build/gcc/cc1plus t.C
A::A()
Breakpoint 4, expand_member_init (name=0x401c9958) at init.c:950
950 if (!current_class_ref)
(gdb) cont
Continuing.
A::A() [with T = int*]
Breakpoint 4, expand_member_init (name=0x40153c38) at init.c:950
950 if (!current_class_ref)
(gdb) next
953 if (!name)
(gdb) p debug_generic_expr(name)
intD.2 *
$9 = void
(gdb) next
973 else if (TYPE_P (name))
(gdb)
975 basetype = TYPE_MAIN_VARIANT (name);
(gdb)
976 name = TYPE_NAME (name);
(gdb)
983 if (basetype)
(gdb) p debug_generic_expr(name)
$10 = void
(gdb) p debug_generic_expr(basetype)
intD.2 *
$11 = void
(gdb)
So we have nullified name. Then we go on to the error message without a name:
(gdb) b init.c:1025
Breakpoint 5 at 0x815c5fb: file init.c, line 1025.
(gdb) cont
Continuing.
Breakpoint 5, expand_member_init (name=0x0) at init.c:1025
1025error ("type %qD is not a direct base of %qT",
(gdb) l
1020{
1021 if (CLASSTYPE_VBASECLASSES (current_class_type))
1022error ("type %qD is not a direct or virtual base of %qT",
1023 name, current_class_type);
1024 else
1025error ("type %qD is not a direct base of %qT",
1026 name, current_class_type);
1027 return NULL_TREE;
1028}
1029
(gdb) p name
$12 = 0x0
(gdb)
Obviously we ICE when we try to print the NULL name.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24278
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #12 from steven at gcc dot gnu dot org 2005-12-18 15:55 --- Paolo, are you going to ask for approval for GCC 4.1 too? -- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Last reconfirmed|2005-11-30 13:44:11 |2005-12-18 15:55:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 15:51 --- Kazu assigned this to himself on December 17, see http://gcc.gnu.org/ml/gcc-bugs/2005-12/msg01787.html Folks, please add a comment when you assign a bug to yourself. That way, it's easier to see which bugs have had someone looking at them recently. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-11-27 17:45:30 |2005-12-18 15:51:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
[Bug tree-optimization/24287] pure functions cause things to be call clobbered still
--- Comment #5 from kazu at gcc dot gnu dot org 2005-12-18 15:48 --- Is this PR fixed? Or does it need some follow-up work? -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, kazu at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24287
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 15:45 --- Unable to reproduce with GCC 4.1 without further feedback. Apparently already fixed or made latent on GCC 4.2. The dumps in comment #1 could use some comment so that people reading this bug report don't have to analyze those for themselves. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-18 15:45 --- Unable to reproduce with GCC 4.1 without further feedback. Apparently already fixed or made latent on GCC 4.2. The dumps in comment #1 could use some comment so that people reading this bug report don't have to analyze those for themselves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-18 15:42 --- What is one supposed to do with this bug report? First, it looks from the command lines in the report that the problematic compiler is GCC 3.3. But the report is about gcc 4.1.0. Second, I can't reproduce the problem with "GNU C version 4.1.0 20051216 (prerelease) (hppa2.0-unknown-linux-gnu)". I tried "./xgcc -B. t.c -Os -mschedule=7100LC" but I get warnings: t.c: In function 'testA': t.c:90: warning: overflow in implicit constant conversion t.c: In function 'testK': t.c:100: warning: overflow in implicit constant conversion So how am I going to reproduce this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug tree-optimization/25481] New: Segfault in tree-ssa-structalias.c
Compiling the following test case with "./cc1 -O2" ends up causing a segfault.
struct s {
int *blah;
};
static struct s array[] = {
{ 0 }
};
void
foo (struct s *p)
{
unsigned int n = 1;
struct s *q = &array[n];
while (p < q)
p++;
}
--
Summary: Segfault in tree-ssa-structalias.c
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25481
[Bug rtl-optimization/25224] [4.1 Regression] ICE in initialize_original_copy_tables
--- Comment #6 from steven at gcc dot gnu dot org 2005-12-18 14:53 --- fixeth yet -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.0 | Known to work|4.0.3 4.2.0 |4.0.3 4.1.0 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25224
[Bug rtl-optimization/25224] [4.1 Regression] ICE in initialize_original_copy_tables
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-12-18 14:51 --- Subject: Bug 25224 Author: hubicka Date: Sun Dec 18 14:51:53 2005 New Revision: 108754 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108754 Log: PR rtl-optimization/25224 * tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Free copy tables. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-loop-unswitch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25224
[Bug rtl-optimization/25224] [4.1 Regression] ICE in initialize_original_copy_tables
--- Comment #4 from steven at gcc dot gnu dot org 2005-12-18 14:36 --- For historic reference, once this is on the 4.1 branch too. -- steven at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg01216.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25224
[Bug middle-end/24565] [4.1/4.2 Regression] facerec performance regression
--- Comment #3 from steven at gcc dot gnu dot org 2005-12-18 14:32 --- ping! There are too many reports about SPEC performance drops that stay in WAITING for too long. That is not helpful. Uttam, please investigate this bug, you cannot just drop a bug report about SPEC performance regressions and expect others to look into it further -- and not only because not everyone has access to SPEC, but also because that is just your responsibility as a reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug tree-optimization/18048] [4.0/4.1/4.2 Regression] mgrid loop performance regression with ivopts (register pressure)
--- Comment #23 from steven at gcc dot gnu dot org 2005-12-18 14:30 --- This bug was for mgrid, but now we're stuck on a reported mesa performance drop that may or may not be related to this PR. I suggest that if the mesa drop is still there, a new bug report should be opened for it. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug fortran/25018] Segfault with simple expression
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-18 14:01 --- Subject: Bug 25018 Author: pault Date: Sun Dec 18 14:01:00 2005 New Revision: 108753 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108753 Log: 2005-12-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25018 *expr.c(check_inquiry): Return FAILURE if there is no symtree to provide a name. Error/warning for assumed character length argument to LEN for an initialization expression, using GFC_GNU_STD. Add an argument to flag that the expression is not restricted. (check_init_expr): Improve the message for a failing variable. (gfc_match_init_expr): Call check_enquiry again to make sure that unsimplified expressions are not causing unnecessary errors. 2005-12-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25018 *gfortran.dg/initialization_1.f90: New test. *gfortran.dg/enum_5.f90: Change dg-error to new message. *gfortran.dg/g77/980616-0.f: The same. Added: trunk/gcc/testsuite/gfortran.dg/initialization_1.f90 Modified: trunk/gcc/cp/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/enum_5.f90 trunk/gcc/testsuite/gfortran.dg/g77/980616-0.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25018
bug
I found bug in GNU assembler. OS is SUSE9.3 command line is: gcc -v -save-temps -Wall -W -DASM_FILE=1 -nostdinc -fno-builtin -c -o loader_img-loader.o loader.S output is: Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ./configure Thread model: posix gcc version 3.4.3 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -E -lang-asm -quiet -nostdinc -v -DASM_FILE=1 loader.S -mtune=pentiumpro -Wall -W -fno-builtin -o loader.s #include "..." search starts here: #include <...> search starts here: End of search list. as -V -Qy -o loader_img-loader.o loader.s GNU assembler version 2.15.94.0.2.2 (i586-suse-linux) using BFD version 2.15.94.0.2.2 20041220 (SuSE Linux) gcc: Internal error: Segmentation fault (program as) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. That all, that's the problem? #define BOOT_BASE_ADDRESS 0x7C00 /* last usable byte of boot sector */ #define BOOT_SECTOR_PART_END 0x1FE /* boot sector shuold end with such byte */ #define BOOT_SECTOR_END_SIGNATURE 0xAA55 /* boot parameter block start offset */ #define BOOT_SECTOR_BPB_START 0x3 /* boot parameter block end offset */ #define BOOT_SECTOR_BPB_END 0x3E /* boot sector program version for compatibility */ #define BOOT_VERSION_MAJOR 0x0 #define BOOT_VERSION_MINOR 0x1 /* stack bottom offset */ #define BOOT_SEGMENT_STACK 0x2000 /* disk buffer for boot main part, max buffer length is 64K */ #define BOOT_BUFFER_SEGMENT 0x7000 /* maximum boot device count */ #define BOOT_DEVICE_COUNT 0x8 loader.S Description: Binary data
[Bug tree-optimization/24378] [4.1/4.2 Regression] gcc.dg/vect/pr24300.c (test for excess errors) fails
--- Comment #12 from dorit at gcc dot gnu dot org 2005-12-18 11:20 --- Subject: Bug 24378 Author: dorit Date: Sun Dec 18 11:20:17 2005 New Revision: 108750 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108750 Log: PR tree-optimization/24378 * tree-vect-transform.c (vect_transform_loop): Create single-predecessor basic-block after loop-versioning. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24378
[Bug tree-optimization/24378] [4.1/4.2 Regression] gcc.dg/vect/pr24300.c (test for excess errors) fails
--- Comment #11 from dorit at gcc dot gnu dot org 2005-12-18 08:46 --- Subject: Bug 24378 Author: dorit Date: Sun Dec 18 08:46:30 2005 New Revision: 108746 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108746 Log: PR tree-optimization/24378 * tree-vect-transform.c (vect_transform_loop): Create single-predecessor basic-block after loop-versioning. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24378
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:32 --- Subject: Bug 25349 Author: jvdelisle Date: Sun Dec 18 08:32:09 2005 New Revision: 108745 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108745 Log: 2005-12-17 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25264 PR libgfortran/25349 * gfortran.dg/tl_editing.f90: Added additional checks. * gfortran.dg/t_editing.f: New test. * gfortran.dg/write_padding.f90: New test Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/t_editing.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/write_padding.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/tl_editing.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug fortran/25264] write to internal unit from the string itself gives wrong result ?
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:32 --- Subject: Bug 25264 Author: jvdelisle Date: Sun Dec 18 08:32:09 2005 New Revision: 108745 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108745 Log: 2005-12-17 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25264 PR libgfortran/25349 * gfortran.dg/tl_editing.f90: Added additional checks. * gfortran.dg/t_editing.f: New test. * gfortran.dg/write_padding.f90: New test Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/t_editing.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/write_padding.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/tl_editing.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:24 --- Subject: Bug 25349 Author: jvdelisle Date: Sun Dec 18 08:24:04 2005 New Revision: 108744 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108744 Log: 2005-12-17 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25264 PR libgfortran/25349 * io/unit.c (get_unit): Delete code that cleared the string when the unit was opened, which is too soon. * io/transfer.c (next_record_w): Pass done flag in. Change logic for setting max_pos. Add code to position unit and pad record as needed. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c branches/gcc-4_1-branch/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug fortran/25264] write to internal unit from the string itself gives wrong result ?
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-12-18 08:24 --- Subject: Bug 25264 Author: jvdelisle Date: Sun Dec 18 08:24:04 2005 New Revision: 108744 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108744 Log: 2005-12-17 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25264 PR libgfortran/25349 * io/unit.c (get_unit): Delete code that cleared the string when the unit was opened, which is too soon. * io/transfer.c (next_record_w): Pass done flag in. Change logic for setting max_pos. Add code to position unit and pad record as needed. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c branches/gcc-4_1-branch/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #3 from irar at il dot ibm dot com 2005-12-18 08:15 --- I failed to reproduce this ICE on ppc and i686. Vectorizer's dump file can help. -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug libstdc++/25472] --disable-hosted-libstdcxx does not work
--- Comment #1 from bkoz at gcc dot gnu dot org 2005-12-18 08:08 --- Subject: Bug 25472 Author: bkoz Date: Sun Dec 18 08:08:07 2005 New Revision: 108743 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108743 Log: 2005-12-17 Benjamin Kosnik <[EMAIL PROTECTED]> * src/io-inst.cc: Separate instantiations into... * src/ios-inst.cc: .. this. * src/iostream-inst.cc: ... and this. * src/Makefile.am (sources): Update. * src/Makefile.in: Regenerate. 2005-12-17 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/25472 * include/c_std/std_cstdlib.h: Fix for freestanding. 2005-12-17 Benjamin Kosnik <[EMAIL PROTECTED]> * testsuite/libstdc++-dg/normal.exp: Rename to.. * testsuite/libstdc++-dg/conformance.exp: ... this. Added: trunk/libstdc++-v3/src/ios-inst.cc trunk/libstdc++-v3/src/iostream-inst.cc trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp - copied unchanged from r108742, trunk/libstdc++-v3/testsuite/libstdc++-dg/normal.exp Removed: trunk/libstdc++-v3/src/io-inst.cc trunk/libstdc++-v3/testsuite/libstdc++-dg/normal.exp Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/c_std/std_cstdlib.h trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25472
