--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-26 07:58 ---
MAX_EXPR
:)
Reassiocation produces:
aWidth_29 = MAX_EXPR ;
w_30 = MAX_EXPR ;
From:
aWidth_29 = MAX_EXPR ;
w_30 = MAX_EXPR ;
The testcase you provided is undefined which is why it no longer ICEs in 4.3.0
This testcase shows the problem when compiled with -ffast-math:
double test1(double x)
{
double y1, y2;
y1 = sin(x);
y2 = cos(x);
return y1 / y2;
}
double test2(double x)
{
return sin(x) / cos(x);
}
gcc -O2 -ffast-math:
_.099t.optimized:
;; Function te
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-26 07:43 ---
I get the following ICE on the 4.2 branch:
t.cc:15: internal compiler error: in rs6000_emit_minmax, at
config/rs6000/rs6000.c:12088
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29984
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 07:23 ---
This works for me on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from raj dot khem at gmail dot com 2006-11-26 07:05 ---
It is also reproducible using trunk and arm-none-eabi
--
raj dot khem at gmail dot com changed:
What|Removed |Added
-
The following example is a reduced testcase from icewm. GCC when configured for
ppc-*-linux-gnuspe segfaults.
To reproduce the ICE compile like below
g++ -c -O2 testcase.C
this works fine on gcc configured with powerpc-*-linux
testcase.C
class YRec
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-26 05:58
---
No feedback in 3 months about the -Wno-attributes option and the current
behavior of GCC so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-26 04:42 ---
Subject: Bug 29982
Author: pinskia
Date: Sun Nov 26 04:42:00 2006
New Revision: 119218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119218
Log:
2006-11-25 Andrew Pinski <[EMAIL PROTECTED]>
PR fo
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-26 04:36 ---
I see:
ldrdr2, [r1], #328
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2006-11-26 04:10
---
Patch 9 regression test are OK on x86-64. Just need the RECL= limit checks and
error messages. I will start on some nore complex tests now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-26 04:04 ---
Hmm, with that target I get:
checking target system type... Invalid configuration `armv5tel-linux-gnueabi':
machine `armv5tel' not recognized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-26 03:50 ---
eabi was not added until at least 4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from raj dot khem at gmail dot com 2006-11-26 03:27 ---
Created an attachment (id=12693)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12693&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
GCC 4.2 is generating wrong offset while compiling the attached example. This
only happens when using -mcpu=iwmmxt option. It works ok on 3.4.6
/tmp/cc4oD6OO.s: Assembler messages:
/tmp/cc4oD6OO.s:15151: Error: bad immediate value for half-word offset (328)
/tmp/cc4oD6OO.s:15151: Error: bad immedi
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-26 01:44
---
I am going to test RTH's patch and fix all the fall outs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from steven at gcc dot gnu dot org 2006-11-26 01:04 ---
Created an attachment (id=12692)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12692&action=view)
Magic with hard regs
Paolo Bonzini proably can think of a real fix, but it'll have to look something
like this:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 00:28 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|pinskia at
The following program causes an ICE with gfortran 4.1.2 running with
Ubuntu 6.10 on an i686 laptop (and works with non-gfortran compilers):
program tst
write (6,"(a,es15.8)") "2.0**(-0.0) = ",2.0**(-0.0)
end program tst
[EMAIL PROTECTED]:~/f$ cd ~/f;gfortran -o tst tst.F90
tst.F90: In function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 00:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 00:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 00:21 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 00:20 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 00:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-26 00:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-26 00:10 ---
Since adding -pedantic rejects this and libstdc++ uses extern template and
extern template might become part of the standard, I am going to close this as
invalid.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-26 00:04 ---
Fixed by:
2006-11-16 Mike Stump <[EMAIL PROTECTED]>
* config/darwin.h (LINK_COMMAND_SPEC): Don't do dwarf stuff on
pre-darwin9 system, unless the user asks for it directl
--
pinskia at gcc dot
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-26
00:04 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory faul
> (insn 98 97 99 7 foo.c:27 (set (reg/f:DI 25 %r25 [ cond ])
> -(mem/f/c
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-25 23:52 ---
*** This bug has been marked as a duplicate of 29841 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-25 23:52 ---
*** Bug 29750 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-25 23:52 ---
*** Bug 29301 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-25 23:52 ---
*** This bug has been marked as a duplicate of 29841 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-25 23:36 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-11-25 23:32
---
fwprop says it is r29 invalided by a call:
invalidated by call 0, 1, 2, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
31, 32, 33, 34, 35, 36, 37, 38, 39, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60
I think it mis
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-25 23:26
---
The only three instructions fwprop touches are done into:
Before:
(insn 112 2 7 2 foo.c:13 (set (reg/f:DI 72)
(plus:DI (reg/f:DI 29 %r29)
(const_int -64 [0xffc0]))) -1 (nil)
(nil
--- Comment #12 from steven at gcc dot gnu dot org 2006-11-25 23:23 ---
Re. comment #3, "It's call clobbered, so it must be saved and restored": Why is
reg 29 not in the call clobbered reg list on the call_insns? I see a USE for
reg 29 on every call: (use (reg/f:DI 29 %r29)). But not a
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #11 from steven at gcc dot gnu dot org 2006-11-25 23:19 ---
Note that (reg 29) is the ret1 reg.
Looks more and more like a register allocation problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
--- Comment #10 from steven at gcc dot gnu dot org 2006-11-25 23:17 ---
>From the cse1 dump:
Register 72 used 1 times across 0 insns; set 1 time; dies in 0 places; pointer.
So there is only a single DEF for reg 72. The set for this DEF is:
(insn 112 2 7 2 foo.c:13 (set (reg/f:DI 72)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-25 23:16 ---
You are going to use newlib with h8300-hms, right, if so you should configure
with --with-newlib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29981
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-25 23:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
The root configure.in claims that libstdc++-v3 should be
built on h8300-*-*-* but libstdc++-v3 seems to disagree.
$ ./configure --enable-languages=c,c++ --target=h8300-hms && make
[...]
configure: error: No support for this host/target combination.
make[1]: *** [configure-target-libstdc++-v3] Erro
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-25 23:04 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #20 from tkoenig at gcc dot gnu dot org 2006-11-25 22:58
---
Created an attachment (id=12691)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12691&action=view)
Latest update
Here's the latest update.
This is fairly complete, but still lacks testing on exceeding the
wr
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29980
The following invalid code snippet triggers an ICE on the 4.2 branch
and mainline:
===
struct A { typedef int X; };
struct __attribute__((unused)) A::X;
===
bug.cc:3: error: using typedef-name 'A::X'
The following code snippet triggers an ICE since GCC 3.3:
===
template struct A
{
static const T i = 1;
int __attribute__((vector_size(8))) a[i];
};
===
bug.cc:4: internal compiler error: in fold_c
--- Comment #9 from steven at gcc dot gnu dot org 2006-11-25 22:24 ---
Why is this an fwprop bug? You haven't really shown that AFAICS. Could be a
latent bug elsewhere that fwprop uncovered. Or can you pin-point the specific
insns that fwpwop produces, and which you think is wrong?
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-25
22:14 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
> Simplified test case attached.
This is a bug in fwprop. Attached rt
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-25 21:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-25 21:43 ---
Subject: Bug 29951
Author: pinskia
Date: Sat Nov 25 21:43:48 2006
New Revision: 119211
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119211
Log:
2006-11-25 Andrew Pinski <[EMAIL PROTECTED]>
PR fo
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-25
21:30 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
Simplified test case attached.
Dave
--- Comment #5 from dave at
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-25 21:19 ---
The problem for the trunk is ovbious:
#4 0x080c38c1 in gfc_conv_missing_dummy (se=0xbf926cf4, arg=0x9ea1228, ts=
{type = BT_UNKNOWN, kind = 4, derived = 0x0, cl = 0x0}) at
/src/gcc/fortran/gcc/gcc/fortran/tran
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-25 21:12 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-25 21:12 ---
Subject: Bug 29964
Author: pinskia
Date: Sat Nov 25 21:12:08 2006
New Revision: 119208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119208
Log:
2006-11-25 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #3 from danglin at gcc dot gnu dot org 2006-11-25 20:15 ---
In print_c_condition, we have these two calls:
print_rtx_ptr_loc (cond);
printf ("(%s)", cond);
The generated assembly code is:
0x4000d4d0 : ldd -40(ret1),r26
0x4000d4d4 : ldo -
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-25 19:41
---
Confirmed. You can get rid of a few of those with:
Index: trans-decl.c
===
--- trans-decl.c(revision 119204)
+++ trans-decl.c(workin
--- Comment #9 from tobi at gcc dot gnu dot org 2006-11-25 18:50 ---
The miscompilation appears first with -O -ftree-vrp, i.e. removing -ftree-vrp
from the following command line gives a working executable, with it, we get a
broken compiler.
tobias-schluters-computer:~/src/trunk/build/g
With following testcase gcc 4.1.1 with -Os produces two back-to-back jumps:
"jump to L2 if less; jump to L2 if less-or-equal;" the first one is not needed.
-O2 is worse, but I usually use -Os anyway.
void g();
void f(long long v) {
if (v > 0LL)
g();
g()
--- Comment #8 from tobi at gcc dot gnu dot org 2006-11-25 17:46 ---
I've given up attaching the tree dumps, they can be downloaded from
http://www.cip.physik.uni-muenchen.de/~tobias.schlueter/dumps.tar.gz
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-25 17:30
---
Fixed by revision 119204.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-11-25 17:00
---
Fixed on mainline. I will wait for some time before commiting on 4.2.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-11-25 16:57
---
Subject: Bug 29711
Author: fxcoudert
Date: Sat Nov 25 16:57:25 2006
New Revision: 119203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119203
Log:
PR fortran/29711
* error.c (error_print)
--- Comment #7 from tobi at gcc dot gnu dot org 2006-11-25 16:57 ---
Created an attachment (id=12687)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12687&action=view)
First part of tree dumps redux
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from tobi at gcc dot gnu dot org 2006-11-25 16:49 ---
Created an attachment (id=12686)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12686&action=view)
First part of the tree dumps
At FX' request, I've produced a tarball containing the tree dumps from the
compilatio
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-25 16:45 ---
Subject: Bug 29964
Author: pinskia
Date: Sat Nov 25 16:45:09 2006
New Revision: 119202
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119202
Log:
2006-11-25 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #5 from tobi at gcc dot gnu dot org 2006-11-25 16:20 ---
With the workaround in place, I get a clean -- aside from fallout from another
patch in my tree -- testsuite run on i686-darwin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #4 from tobi at gcc dot gnu dot org 2006-11-25 16:12 ---
The duplicate contains some more analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #3 from tobi at gcc dot gnu dot org 2006-11-25 16:12 ---
*** Bug 29977 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from tobi at gcc dot gnu dot org 2006-11-25 16:12 ---
*** This bug has been marked as a duplicate of 29516 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
The failures in the testcases gfortran.dg/char_transpose_1.f90,
gfortran.dg/matmul_2.f90, gfortran.dg/matmul_3.f90 are apparently due to a
miscompilation of the gfortran FE.
The error can be traced to the following code from trans-arrray.c:775
for (n = 0; n < 2; n++)
{
dest_info->delta
--- Comment #5 from manu at gcc dot gnu dot org 2006-11-25 15:24 ---
Why this is marked as "other" ? This is either a problem on the C/C++
front-ends or it is a problem in the middle-end that doesn't handle the
overflow/underflow correctly during conversion, isn't it?
Also, this happens
--- Comment #2 from patchapp at dberlin dot org 2006-11-25 15:05 ---
Subject: Bug number PR29464
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01705.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #10 from pault at gcc dot gnu dot org 2006-11-25 14:41 ---
(In reply to comment #9)
Sorry, this was a slip of the digits in the ChangeLog
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29387
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-25 14:39 ---
Fixed on trunk and 4.2.
Will backport to 4.1 in coming week.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-25 14:39 ---
Fixed on trunk and 4.2.
Will backport to 4.1 in coming week.
Paul
PS please not error in ChangeLog for trunk - will fix Monday.
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pault at gcc dot gnu dot org 2006-11-25 14:38 ---
Subject: Bug 29837
Author: pault
Date: Sat Nov 25 14:37:56 2006
New Revision: 119198
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119198
Log:
2006-11-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-25 14:38 ---
Subject: Bug 20880
Author: pault
Date: Sat Nov 25 14:37:56 2006
New Revision: 119198
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119198
Log:
2006-11-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-25 14:29
---
Subject: Bug 29973
Author: fxcoudert
Date: Sat Nov 25 14:28:56 2006
New Revision: 119197
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119197
Log:
PR fortran/29973
* gfortran.fortran-tort
--- Comment #2 from jv244 at cam dot ac dot uk 2006-11-25 14:15 ---
(In reply to comment #1)
> Hi Joost,
> I'll look into it. I now regularly build cp2k with gfortran (usually 4.2
> branch) on i686-linux for my work but I haven't see this ICE yet. Just in
> case,
> what's the platform y
The following code:
SUBROUTINE pw_sumup (alpha_im)
REAL, INTENT(in), OPTIONAL :: alpha_im
COMPLEX :: my_alpha_c
IF (PRESENT(alpha_im)) THEN
my_alpha_c = CMPLX(0.,alpha_im)
END IF
END SUBROUTINE pw_sumup
ICEs on both 4.2 and 4.3, but compiles fine on 4.1.2. The ICE for 4.3 is:
foo.f90
--- Comment #2 from manu at gcc dot gnu dot org 2006-11-25 14:06 ---
As far as I can see, the C++ front-end fails to call overflow_warning
(c-common.c) from build_binary_op (cp/typeck.c) in the same way as the C
front-end does in parser_build_binary_op(c-typeck.c).
--
manu at gcc dot
--- Comment #11 from manu at gcc dot gnu dot org 2006-11-25 13:51 ---
I don't get the warning with current mainline (revision 119143).
Still, I would like to keep this bug around since it may be interesting that
Wconversion emits a warning for the int->char conversion. I would like to h
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-25 13:22
---
Hi Joost,
I'll look into it. I now regularly build cp2k with gfortran (usually 4.2
branch) on i686-linux for my work but I haven't see this ICE yet. Just in case,
what's the platform you're building on?
--
fx
I'm trying to compile CP2K with gfortran (yesterday's mainline), but I'm
experiencing ICEs. Since it seems to be happening more often with CP2K I've
added this metabug.
the first one I see is:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90: In function âpw_sumupâ:
all_cp2k_gfortran.f90:1
--- Comment #1 from paolo at gcc dot gnu dot org 2006-11-25 10:36 ---
Subject: Bug 29385
Author: paolo
Date: Sat Nov 25 10:35:52 2006
New Revision: 119190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119190
Log:
2006-11-25 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-25 10:11 ---
symbol_marked_for_renaming is returning false.
Symbols to be put in SSA form
_ZTI13basic_ostream _ZTIN12_GLOBAL__N_111NullostreamE
_ZTSN12_GLOBAL__N_111NullostreamE _ZTVN10__cxxabiv120__si_class_type_infoE
_ZTI8ios_
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-25 09:13 ---
(gdb) p debug_generic_expr (vh)
VH.22
$4 = void
(gdb) p debug_generic_expr (eprime)
strlen (&lineD.1610)
(gdb) p debug_generic_expr (vuse)
lineD.1610_11
We have:
# NONLOCAL.5_14 = PHI ;
# line_11 = PHI ;
:;
#
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2006-11-25 09:09
---
Created an attachment (id=12685)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12685&action=view)
updated patch
> enclosed list if compound literal's and object's types match.
How about this one instead,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-25 08:45 ---
This works for me with 4.0.4, 4.1.2, 4.2.0, and 4.3.0 even with GC settings so
it always runs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29974
89 matches
Mail list logo
