--
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
--- Comment #15 from sezeroz at gmail dot com 2010-01-06 08:55 ---
Can we expect a 4.4 backport for this, at least in the ix86/4.4 branch if not
in the main 4.4 branch?
--
sezeroz at gmail dot com changed:
What|Removed |Added
Hi,
When I tried to build the last svn version on ia64 and got this failure.
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cp/name-lookup.o differs
make[2]: ***
--- Comment #1 from burnus at gcc dot gnu dot org 2010-01-06 09:53 ---
I think the function causing the trouble is gfc_conv_structure (with init=1).
The following is simply not true:
/* Skip absent members in default initializers and allocatable
components. Although
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-01-06 10:42
---
The linker error alone doesn't make the root cause obvious, but it's a fairly
well known and well documented problem:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.10
--
--- Comment #14 from ubizjak at gmail dot com 2010-01-06 10:43 ---
This bug can be now reproduced with a crosscompiler to alpha-linux-gnu with
soon to be attached preprocessed source of tree-ssa-loop-im.i (please note
noinline attributes at determine_max_movement and add_dependency).
--- Comment #15 from ubizjak at gmail dot com 2010-01-06 10:45 ---
Created an attachment (id=19483)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19483action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511
--- Comment #4 from Paulo dot Matos at csr dot com 2010-01-06 10:46 ---
Almost four years have gone and nobody was able to document these. It would be
nice to see these in the docs! :-)
I am looking for them since I don't know what they are for at the moment,
otherwise I could give it
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |rtl-optimization
Keywords|
--- Comment #5 from fredrik dot svahn at gmail dot com 2010-01-06 11:36
---
Thanks for the quick patch!
Unfortunately it only works for me with option -march=athlon64? Is this
intentional (-march is not needed for gcc-4.3)?
Am I doing something wrong?
$ gcc-4.3 -v
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-06 11:40 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-06 11:41
---
Done both.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4 regression] ICE during |[4.5 regression] ICE during
|bootstrap when
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-06 11:42
---
Loren, we are not making much progress on this... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10251
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42627
--- Comment #6 from fredrik dot svahn at gmail dot com 2010-01-06 11:44
---
I will try to distclean and rebuild from scratch to confirm my statement above.
--
fredrik dot svahn at gmail dot com changed:
What|Removed |Added
--- Comment #2 from baldrick at free dot fr 2010-01-06 11:46 ---
I've modified dragonegg so it only needs version.h and not except.h or
libfuncs.h.
When I implement exception handling support it will probably need except.h, but
it is unlikely to ever need libfuncs.h.
--
baldrick at
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|-fipa-sra can generate |[4.5
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-06
11:55 ---
Subject: Re: [4.5 regression] ICE building stage 1 libgcc: SEGV in
compare_access_positions
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-01-05 18:46
---
I posted a slightly
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-06 11:57
---
Now the buffer is 128 chars.
On second thought, I don't think checking the return value of strftime and all
the added complexity are worth the trouble: given the semantics of the function
and the actual data
--- Comment #13 from jwakely dot gcc at gmail dot com 2010-01-06 11:58
---
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm which is
part of the current C++ draft
Related to Bug 31397 and Bug 36848 - we don't need three open bugs requesting
similar features. I've
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-06 12:00 ---
Confirmed. We have regno differences.
-(insn# 0 0 t.c:4 (set (reg/v:SI 0 ax [orig:67 k ] [67])
+(insn# 0 0 t.c:4 (set (reg/v:SI 0 ax [orig:68 k ] [68])
works ok with -fno-var-tracking-assignments.
--
rguenth
--- Comment #6 from debian-gcc at lists dot debian dot org 2010-01-06
12:18 ---
The Invalid or incomplete multibyte or wide character messages were generated
due to an incorrect setup of the checking tool (lintian).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-06
12:24 ---
Subject: Re: O32 libgfortran.so fails to link on IRIX 6.5
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-18 14:48 ---
I cannot see any point in retaining this PR against the gfortran
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-06 12:26 ---
Hm, I reduced it to something that is not a regression anymore. The original
testcase though works with 4.4 but fails with 4.5. I guess the real problem
is latent.
static inline __attribute__((always_inline)) int
--- Comment #3 from ramana at gcc dot gnu dot org 2010-01-06 12:26 ---
[I don't see the first build breakage with libiberty but the second problem
with integer overflow in expressions] . I am trying a full checking build on
a board but that's taking some time to complete !
With some
--
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
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-06 12:43 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
there is currently no way to hint gcc that a restricted pointer
doesnt alias with a member of a struct.
quoting Richard Guenther on this:
--
Yes, in this case you can fix it by making ramp static. Otherwise its address
--- Comment #1 from torbenh at gmx dot de 2010-01-06 13:10 ---
Created an attachment (id=19484)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19484action=view)
test case which doesnt optimize properly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42633
--- Comment #2 from torbenh at gmx dot de 2010-01-06 13:19 ---
the generated x86_64 asm: _Z11fill_bufferPfm: .LFB3: testq %rsi, %rsi
je .L4 xorl%eax, %eax movss .LC0(%rip), %xmm2
.p2align 4,,10 .p2align 3 .L3: movss ramp(%rip), %xmm1
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-06 13:32 ---
Actually this bug was fixed by
2010-01-05 Martin Jambor mjam...@suse.cz
PR tree-optimization/42462
* ipa-inline.c (compute_inline_parameters): Pass node-decl instead of
--- Comment #4 from jocke at vmlinux dot org 2010-01-06 13:53 ---
I can confirm this issue while building an armeb-unknown-uclibcgnueabi
(big-endian) cross toolchain on i686 (Ubuntu 9.10 32-bit) using crosstool-NG.
However, I cannot replicate it on any host running x86_64 (Ubuntu 9.04
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-06 13:57 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-06 13:57 ---
The following also looks bogus:
static struct t a = {.i=4};
Though, it seems to work - contrary to the version in comment 0.
program test
implicit none
type t
integer :: i = 4
integer, allocatable ::
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-06 14:04 ---
Hmm, seemingly, comment 0 also works - at least with patch
http://gcc.gnu.org/ml/fortran/2010-01/msg00043.html
Close as WORKSFORME.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-01-06 14:07 ---
(In reply to comment #2)
SRA here again does somthing stupid:
As I have already told richi on IRC, if in.value = value_1(D) was an
assignment of two unions, it would have loaded the chars from the rhs
and thus
cat bug.ii
templatetypename T T declval();
templatetypename T, typename... Args struct is_constructible {
templatetypename T1, typename... Args1
static decltype(T1(declvalArgs1()...), char()) test();
static const bool value = sizeof(testT, Args...()) == 1;
};
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-06 14:16 ---
I think a description does not belong into man gfortran (invoke.texi), but
maybe into the general text of gfortran.texi.
I think .mod files are not obvious; the standard does not say anything about
them, though
--- Comment #16 from hjl dot tools at gmail dot com 2010-01-06 14:59
---
(In reply to comment #15)
Can we expect a 4.4 backport for this, at least in the ix86/4.4 branch if not
in the main 4.4 branch?
It will be backported to 4.3/4.4 in a few days.
--
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.6
Version|4.5.0 |4.3.5
The following two functions are not if-converted at the tree level (the 2nd
example happens a lot from VEC code via VEC_BASE):
int *bar (char *p)
{
int *q;
if (p)
q = (int *)p;
else
q = (int *)0;
return q;
}
struct X { int q; };
int *foo (struct X *p)
{
int *q;
if (p)
q =
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-06 15:17 ---
Created an attachment (id=19485)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19485action=view)
testcase using vec.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42635
--- Comment #16 from ubizjak at gmail dot com 2010-01-06 15:17 ---
The problem turns out to be quite complex interaction between cse1, cprop3 and
cse2 pass.
Let's start with this RTL dump for from:
tree-ssa-loop-im.i.148r.subreg1
;; Function determine_max_movement
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-01-06 16:15 ---
Mine. Patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00267.html
The thread is about bug 42604, but the improvements for the fix for that patch
fixed this one too.
--
aoliva at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-06 16:30 ---
Confirmed. Older releases ICE differently.
Note that I don't see an ICE with -g0 but only with -g.
With plain -g the code is even rejected:
./cc1plus -quiet -std=c++0x t.ii
ok
./cc1plus -quiet -std=c++0x t.ii
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-01-06 16:36 ---
By the same argument, shouldn't we drop the assignment early, and make it a
non-assigning call? The assignment is also supposed to occur after the call,
although it's not denoted in a separate statement, but SSA
--- Comment #24 from paolo dot carlini at oracle dot com 2010-01-06 16:37
---
As I understand the audit trail, this can be closed. If somebody has solid
reasons to disagree, please re-open.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-06 16:48 ---
(In reply to comment #4)
By the same argument, shouldn't we drop the assignment early, and make it a
non-assigning call?
Sure - fixing this during gimplification would be fine with me. I'm not
sure it cannot
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-06 16:39
---
Ok, thanks. Can you summarize the present status, then? Outstanding issues,
maybe more patchlets... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
--- Comment #3 from ljrittle at gcc dot gnu dot org 2010-01-06 17:15
---
Considered and rejected.
--
ljrittle at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
the program below gives a warning with some versions of gcc.
I tried with 4.3.4, 4.4.2 (debian versions) and 4.5.0 (snapshot, compiled
myself today). Some people told me that 4.2.4, 4.2.1 and 3.4.6 don't warn.
4.5.0 outputs:
#ssa_name not supported by pp_c_expression#]kr-1-17.c: In
--- Comment #5 from rwild at gcc dot gnu dot org 2010-01-06 17:33 ---
Created an attachment (id=19486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19486action=view)
patch to add TARGET_LIB_PATH only when bootstrapping
Please try this patch. Thanks.
--
--- Comment #4 from torbenh at gmx dot de 2010-01-06 17:42 ---
Created an attachment (id=19487)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19487action=view)
patch to add the attribute
i am not sure about the decl_req, type_req, fn_type_req values.
maybe its true, false, false
--- Comment #4 from gmorin1 at bloomberg dot net 2010-01-06 17:51 ---
My original tests were done on x86/x86_64. I observed the same problem with
gcc 4.3.2 when compiling for PowerPC on AIX. For some reason, the output is
properly optimized with the same version (different build
--- Comment #5 from tschwinge at gcc dot gnu dot org 2010-01-06 17:57
---
This bug exists, by the way, not only when GCC is emitting CFI statements, but
also when it's emitting .debug_frame directly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
--- Comment #16 from ro at gcc dot gnu dot org 2010-01-06 18:07 ---
Fixed for 4.5.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from ubizjak at gmail dot com 2010-01-06 18:14 ---
This bug is similar (or even a duplicate of) PR21767. ifcvt.c has a fixup code
for cases like this, grep ifcvt.c for:
/* PR 21767: When moving insns above a conditional branch, REG_EQUAL
notes might
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-01-06 18:20 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from rth at gcc dot gnu dot org 2010-01-06 18:22 ---
*** This bug has been marked as a duplicate of 41833 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rth at gcc dot gnu dot org 2010-01-06 18:22 ---
*** Bug 41889 has been marked as a duplicate of this bug. ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rth at gcc dot gnu dot org 2010-01-06 18:23 ---
Oops, wrong duplicate.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rth at gcc dot gnu dot org 2010-01-06 18:23 ---
*** This bug has been marked as a duplicate of 41883 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rth at gcc dot gnu dot org 2010-01-06 18:23 ---
*** Bug 41889 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41883
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #3 from rth at gcc dot gnu dot org 2010-01-06 18:24 ---
*** This bug has been marked as a duplicate of 41883 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rth at gcc dot gnu dot org 2010-01-06 18:24 ---
*** Bug 42396 has been marked as a duplicate of this bug. ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
As mentioned in PR 42334, 200.sixtrack from SPEC CPU2000 started getting wrong
answers on powerpc64-linux with the Graphite merge at r140301 when compiled
with -O2 -floop-interchange -ftree-loop-distribution. The loop that is
miscompiled is:
real*8 rt(6,6),r(6,6),rtt(6,6)
do i=1,6
--- Comment #1 from janis at gcc dot gnu dot org 2010-01-06 18:27 ---
Created an attachment (id=19488)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19488action=view)
executable testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42637
--- Comment #6 from rth at gcc dot gnu dot org 2010-01-06 18:34 ---
Subject: Bug 41883
Author: rth
Date: Wed Jan 6 18:34:31 2010
New Revision: 155680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155680
Log:
PR middle-end/41883
* haifa-sched.c
--- Comment #6 from janis at gcc dot gnu dot org 2010-01-06 18:44 ---
With the patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01209.html the
testcase in the submitter's description no longer fails, but there is other
code in 197.parser that gets the same ICE with the same
--- Comment #7 from rth at gcc dot gnu dot org 2010-01-06 18:48 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from janis at gcc dot gnu dot org 2010-01-06 18:48 ---
The patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01209.html fixes the
testcase in the submitter's description, but there is code in CPU2000 test
200.sixtrack that triggers the same ICE with the same set of
--- Comment #3 from janis at gcc dot gnu dot org 2010-01-06 18:52 ---
I should have mentioned in comment #2 that the ICE for sixtrack only happens
with -m32, not -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42246
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[graphite] wrong code for - |[4.5 Regression][graphite]
|floop-interchange
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-06 19:19 ---
The test in comment #1 fails also with -O2 -floop-block on
x86_64-apple-darwin10. This pr could be a duplicate of pr42479.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42637
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-06 19:20 ---
-O3 -floop-interchange -ftree-loop-distribution gives also a wrong code. This
pr could be a duplicate of pr42637.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42479
--- Comment #15 from jason at gcc dot gnu dot org 2010-01-06 19:40 ---
I believe http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#993 will
be resolved to allow the G++ behavior. Suspending.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from jason at gcc dot gnu dot org 2010-01-06 19:41 ---
Suspending along with 16635.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2010-01-06 19:44 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#225
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#993
--
jason at gcc dot gnu dot org changed:
What|Removed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
--- Comment #6 from denis dot onischenko at gmail dot com 2010-01-06 20:19
---
(In reply to comment #5)
Created an attachment (id=19486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19486action=view) [edit]
patch to add TARGET_LIB_PATH only when bootstrapping
Please try this
When a formal parameter 1 is not stored on stack the location list mark the
life of this parameter in DW_OP_reg0 however it does not consider the function
calls that would be made in the function in question and the fact that eax can
be destroyed down the call chain. Attached example demonstrates
--- Comment #1 from raj dot khem at gmail dot com 2010-01-06 20:27 ---
Created an attachment (id=19489)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19489action=view)
C testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
--- Comment #2 from raj dot khem at gmail dot com 2010-01-06 20:28 ---
Created an attachment (id=19490)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19490action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
--- Comment #7 from jocke at vmlinux dot org 2010-01-06 20:31 ---
Yep, works for me too, using crosstool-NG to build an
armeb-unknown-linux-uclibcgnueabi for i686 host. Thanks Ralf!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-01-06 20:36 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from 3b87w8mt2n at snkmail dot com 2010-01-06 21:01 ---
As a data point, this occurs for me with GCC 4.3.4 (Debian 4.3.4-6) on AMD64
(x86_64), compiling the given test file as C:
$ gcc -c -o test2.o test2.c gcc -shared -o test2.so test2.o
/usr/bin/ld: test2.o:
--- Comment #4 from 3b87w8mt2n at snkmail dot com 2010-01-06 21:27 ---
Er, sorry, that's the message from the wrong run. Here's the right one:
$ gcc -fPIC -c -o test2.o test2.c gcc -shared -o test2.so test2.o
/usr/bin/ld: test2.o: relocation R_X86_64_PC32 against protected symbol
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-06 21:49 ---
Created an attachment (id=19491)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19491action=view)
Draft patch
Not regtested, need to re-check that the patch is correct, but seems to work
otherwise.
--
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #3 from raj dot khem at gmail dot com 2010-01-06 22:34 ---
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01317.html
could be the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
--- Comment #2 from simon at pushface dot org 2010-01-06 22:35 ---
This is a duplicate of bootstrap/41180, see comment #8. It's an Xcode 3.2
linker bug, (radar 6320843) duplicate symbols from static libraries not
properly ignored.
Fixes in 41180 were like my fix suggestion, which works
--- Comment #2 from simon at pushface dot org 2010-01-06 22:38 ---
Having rolled back the change in ipa.c as suggested in 42068, the library
builds successfully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42627
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:43
---
*** This bug has been marked as a duplicate of 42068 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:43
---
*** Bug 42627 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:45
---
ICE on x86_64-apple-darwin10 too.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
From the libstdc++ performance testsuite:
%/mnt/share/bld/gcc/./gcc/g++ -shared-libgcc -B/mnt/share/bld/gcc/./gcc
-nostdinc++ -L/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-01-06 22:47 ---
Created an attachment (id=19492)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19492action=view)
pre-processed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42639
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2010-01-06 22:46:02 |2010-01-06
1 - 100 of 130 matches
Mail list logo
