--- Comment #10 from paolo dot carlini at oracle dot com 2009-11-29 08:34
---
Stefan is right. The issue, in full generality, isn't trivial at all, there is
now a new discussion on the library reflector. I'm under the impression that
for C++0x we are not going to standardize the
--with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --with-ppl=/sw --with-cloog=/sw --with-libelf=/sw --disable-nls
--disable-bootstrap LDFLAGS=/usr/lib/libiconv.dylib
--enable-languages=c,c++,lto,objc,obj-c++
Thread model: posix
gcc version 4.5.0 20091129 (experimental) (GCC)
Using r154734
--- Comment #1 from astrange at ithinksw dot com 2009-11-29 09:38 ---
Created an attachment (id=19175)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19175action=view)
somewhat-reduced source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42211
Between revisions 154648 and 154667, the following error appeared:
ERROR: tcl error sourcing
/Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp.
ERROR: unmatched open brace in list
(see http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02500.html and
The Win64 version of the libkernel32.a import library defined ___chkstk. This
routine is also defined in i386/cygwin.asm.
The later preserve important registers whereas the Microsoft version probably
does not. Anyway, this has proved to create a breakage into the GNAT compiler.
It seems that
When using -O=1, gcc uses the wrong register for the inline assembly below. In
my actual usecase, it even does
bswap %eax
xorl %eax, %eax
so it instantly threw away the value. When using -m32, it seems to generate
correct code.
== CODE FILES ==
asgard:/tmp$ cat x.c
#include
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-29 12:31 ---
(In reply to comment #2)
On darwin, the errors appear only in 32 bit mode.
Yes, I can confirm this on x86_64-apple-darwin10.2.0. Also, I just ran the
fortran testsuite for the fortran-dev branch on darwin, but saw
Compiler flags: -O2 -ftree-loop-distribution
Tested revisions:
trunk r154706 (20091127) - crash
trunk r153685 (20091028) - crash
4.4 r153668, r154724 - OK
file.c
extern int A[];
extern int B[];
void f(int i)
{
while (i-- 0) {
A[i] = 0;
B[i] = 0;
}
}
=
$
--- Comment #1 from zsojka at seznam dot cz 2009-11-29 12:41 ---
Created an attachment (id=19176)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19176action=view)
source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42215
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 12:54 ---
GCC has to weight code-size and compile-time increase against performance
improvements when deciding on inlining functions. For the call in the loop
GCC assumes it is more beneficial to do the inlining compared to
--
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=42212
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 12:58 ---
Please try to verify if the issue has been addressed in GCC 4.4 or GCC 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2009-11-29 13:01 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02574.html for
powerpc64-unknown-linux-gnu.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 13:03 ---
well,
asm(bswap %0 : =q(i) : q(i));
is wrong. You probably want
asm(bswap %0 : =q(i) : 0(i));
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Target Milestone|---
--- Comment #2 from pascal dot obry at wanadoo dot fr 2009-11-29 13:08
---
Subject: Re: GCC chkstk clash with Microsoft version
Le 29/11/2009 13:58, rguenth at gcc dot gnu dot org a écrit :
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 12:58
---
Please
See http://gcc.opensuse.org/SPEC/CINT/sb-balakirew-head-64-2006/recent.html
First bad rev. is 154713, last good is 154686.
It's quite obvious that either the regrename.c changes have code generation
differences or that removing the vec_interleave_* expanders caused this
regression.
Richard -
--
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=42216
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-11-29 14:35
---
Same on 4.5 Head.
The backend patterns match against MEM AND singlebit.
Combine never considers this.
Incoming RTL and Combine pass dump file extract:
;; Pred edge ENTRY [100.0%] (fallthru)
(note 4 0 2
The following valid code snippet triggers an ICE on trunk:
==
struct A
{
int : 0;
};
A a = A();
==
bug.cc:6:9: internal compiler error: in int_or_pointer_precision, at
tree.c:10593
Please submit a full bug report, [etc.]
--
Summary: [4.5
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42217
A broken diagnostic is issued for the following invalid code snippet on trunk:
templateint struct A
{
templateint struct B;
};
int i = A0::B0::X::Y;
bug.cc:6:21: error: 'A0::B#'tree_vec' not supported by pp_c_expression#,
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42218
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 15:42 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 15:45 ---
Confirmed.
C++ issue. It calls convert_to_integer with
#9 0x082b3dd6 in ocp_convert (type=0xb7d48ba0, expr=0xb7cac5b8, convtype=15,
flags=35) at /home/richard/src/trunk/gcc/cp/cvt.c:700
700 return
--- Comment #6 from reichelt at gcc dot gnu dot org 2009-11-29 15:56
---
The ICE happens since GCC 4.2.0.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet triggers an ICE on trunk:
=
void foo(const void);
void bar()
{
void (*pf)() = foo;
}
=
bug.cc:1:16: error: 'anonymous' has incomplete type
bug.cc:1:20: error: invalid use of 'const void'
bug.cc: In
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
--- Comment #9 from vlad at demoninsight dot com 2009-11-29 16:04 ---
Well, I think my scheme worked: I have succeeded in reverse engineering the
4.4.2 fink scripts into something I could use to build 4.5 trunk against the
prerequisite libs installed via fink.
Indeed, 4.5 trunk does
On at revision 154712 I see the following failures:
FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
[karma] f90/bug% gfc
--- Comment #33 from ghazi at gcc dot gnu dot org 2009-11-29 16:12 ---
The flag -frtl-abstract-sequences was removed and the relevant testcases
deleted. Should we resolve this PR as WONTFIX ?
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01800.html
--
ghazi at gcc dot gnu dot org
--- Comment #14 from ghazi at gcc dot gnu dot org 2009-11-29 16:21 ---
This testcase was fixed here:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01134.html
Can we close this one?
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dominiq at lps dot ens dot fr 2009-11-29 16:21 ---
(In reply to comment #3)
So how do I switch to 64-bit mode?
On x86_64-apple-darwin* it is the default, so I assume you are using
i686-apple-darwin*. In this case you need a multlib build and you compile
with -m64.
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 16:33 ---
So this is a mpc / fink bug, not a gcc one.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-11-29 16:34 ---
Rainer, I believe this bug has been appropriatly analyzed and diagnosed. You
have the affected system and can test, are you working on a fix?
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-11-29 16:34
---
Wontfix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-29 16:35 ---
-frtl-abstract-sequences has been removed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-29 16:35 ---
-frtl-abstract-sequences has been removed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-11-29 16:38
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-29 16:51 ---
-fsee has been removed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27469
--- Comment #2 from dominiq at lps dot ens dot fr 2009-11-29 16:56 ---
So this is a mpc / fink bug, not a gcc one.
I have forgotten to say that the failure occurs only with -funroll*-loops,
-O[1-3], and -m64 options.
Without -funroll*-loops the test pass. BTW I do not see any loop in
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-11-29 17:15
---
I have forgotten to say that the failure occurs only with -funroll*-loops,
-O[1-3], and -m64 options.
Without -funroll*-loops the test pass. BTW I do not see any loop in the code.
Very likely revision 154688:
--with-gmp=/usr/local
--with-ppl=/usr/local --with-cloog=/usr/local --with-mpc=/usr/local
--with-libelf=/usr/local --enable-languages=c,c++ --enable-__cxa_atexit
--enable-targets=all
Thread model: posix
gcc version 4.5.0 20091129 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-B.' '-r' '-nostdlib
--- Comment #1 from b3timmons at speedymail dot org 2009-11-29 17:25
---
Created an attachment (id=19177)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19177action=view)
preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42221
--- Comment #4 from dominiq at lps dot ens dot fr 2009-11-29 17:27 ---
Created an attachment (id=19178)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19178action=view)
ce3 file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #5 from dominiq at lps dot ens dot fr 2009-11-29 17:29 ---
Created an attachment (id=19179)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19179action=view)
rnreg file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #4 from irar at gcc dot gnu dot org 2009-11-29 17:30 ---
Subject: Bug 42193
Author: irar
Date: Sun Nov 29 17:30:20 2009
New Revision: 154738
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154738
Log:
PR tree-optimization/42193
* tree-vect-stmts.c
--- Comment #6 from dominiq at lps dot ens dot fr 2009-11-29 17:30 ---
Can you attach the files generated by -fdump-rtl-ce3 -fdump-rtl-rnreg-details?
I have reduced the test to
module test
implicit none
real(4), parameter :: eps4 = epsilon(0.0_4)*2.0_4
real(8), parameter ::
--- Comment #2 from gb-0001 at xsim dot com 2009-11-29 17:34 ---
[For the call in the loop GCC assumes it is more beneficial]
And in this case it is: the inner loop code is yet simpler than the
prologue/eiplogue code.
[If you are sure it is always beneficial...]
It is not always
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-11-29
17:36 ---
see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c9
and discussion of
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html
I think that patch should go into 4.5
Danny
--
--- Comment #4 from pascal dot obry at wanadoo dot fr 2009-11-29 17:43
---
Subject: Re: GCC chkstk clash with Microsoft version
Le 29/11/2009 18:36, dannysmith at users dot sourceforge dot net a écrit :
--- Comment #3 from dannysmith at users dot sourceforge dot net
--- Comment #1 from rth at gcc dot gnu dot org 2009-11-29 17:58 ---
The vec_interleave_*_optab should still be populated. It's just
that what was once sse2_punpcklwd is now vec_interleave_lowv8hi
directly. If this patch *is* attributable to a regression, then
perhaps there's a typo
I'm trying to build KDE, namely kdelibs directory, which is located at:
svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/
When building the following file:
svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/khtml/svg/SVGNames.cpp,
'cc1plus' process starts eating memory. It can eat 1,5G of memory and
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-29 18:21 ---
With 4.5 it works when the function is declared inline (not always_inline).
It's not possible to annotate call-sites with inline information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Component|c
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-11-29 18:39
---
Shorter testcase (without default parameter):
=
struct A
{
static const int N = 0;
};
templateint struct B {};
templatetypename T, int
struct C
{
typedef T U;
BU::N b;
};
--- Comment #19 from dodji at gcc dot gnu dot org 2009-11-29 19:19 ---
Subject: Bug 36408
Author: dodji
Date: Sun Nov 29 19:19:06 2009
New Revision: 154742
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154742
Log:
Really fix PR c++/36408
gcc/cp/ChangeLog:
PR c++/36408
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-11-29 19:36
---
Created an attachment (id=19180)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19180action=view)
Hopefully final patch
This patch moves the number of elements patch up front so that the error is
given
--- Comment #3 from dodji at gcc dot gnu dot org 2009-11-29 19:42 ---
Mine.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #20 from dodji at gcc dot gnu dot org 2009-11-29 20:43 ---
OK, it should really be fixed in 4.5 now.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
This is my test program named hello.f90
! The standard Hello World demo (f90)
program hello
write (*,*) Hello World!
end program hello
Tried to compile using the Macs terminal utility
Had just installed Wiki MAC PPC Binaries from dmg-20090203
HDWR = PowerBook
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 21:30 ---
We do not distribute binaries and they probably were built with a configuration
incompatible to your CPU.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from dominiq at lps dot ens dot fr 2009-11-29 22:10 ---
With the patch in comment #20, I get several new failures:
gcc/testsuite/gfortran.dg/actual_array_constructor_3.f90
pr20923 and friends
pr34554
IIRC when the constructors are used as initialization or in
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-11-29 22:23
---
Reduced testcase:
templatevoid (*)() struct A {};
templatetypename void foo();
templatetypename T AfooT bar();
void baz()
{
barint();
}
/include --with-mpfr-lib=/usr/local/lib
Thread model: posix
gcc version 4.5.0 20091129 (experimental) (GCC)
--
$ ./cc1 foo.c
to_ptr32 to_int to_ptr32_ptr32
foo.c: In function 'to_ptr32_ptr32':
foo.c:28:3: internal compiler error: in int_or_pointer_precision, at
tree.c:10583
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-11-29 23:04
---
Reduced testcase:
=
struct A
{
char c[17];
void foo();
};
void A::foo()
{
for (int i = 0; i 17; ++i)
c[i] = 0;
}
=
The bug is fixed in
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-29 23:25 ---
It may be related to PR 42202.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #4 from dodji at gcc dot gnu dot org 2009-11-29 23:42 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01630.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42069
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-29 23:50
---
Is this related to PR38600?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-29 23:52
---
Oops, I meant PR38712
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-11-30 00:37
---
Reduced testcase (crashes with -O2 on i686-pc-linux-gnu):
==
void foo(const char*);
templateint* struct A
{
templatetypename T A(const
--- Comment #6 from damian at rouson dot net 2009-11-30 00:51 ---
(In reply to comment #5)
(In reply to comment #3)
So how do I switch to 64-bit mode?
On x86_64-apple-darwin* it is the default, so I assume you are using
i686-apple-darwin*. In this case you need a multlib build
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-30 01:03 ---
lvalue_or_else is C++ front-end function ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from hjl at gcc dot gnu dot org 2009-11-30 01:12 ---
Subject: Bug 41961
Author: hjl
Date: Mon Nov 30 01:11:50 2009
New Revision: 154748
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154748
Log:
2009-11-29 H.J. Lu hongjiu...@intel.com
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-30 01:12 ---
gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) is not an official FSF GCC release,
you should report this directly to redhat unless you can reproduce this in an
official gcc release like 4.4.2. Or even try the trunk of
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-30 01:15 ---
I have seen this also with code like switch_case.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from damian at rouson dot net 2009-11-30 01:16 ---
Janus,
Although the new reduced case compiles fine in 64-bit mode, I run into linking
problems as soon as I add program main; end program to the end of it:
Undefined symbols:
_vtab$bar.1550, referenced from:
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-11-30 01:58 ---
I believe I fixed this issue in Sept 2006 in gcc-4.0.4, see:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01032.html
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01163.html
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-11-30 02:00 ---
Fixed.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from gb-0001 at xsim dot com 2009-11-30 02:14 ---
[It works in 4.5 with inline, always_inline not needed.]
Ah, I misunderstood -- seems good to me. I'd say fixed in 4.5 unless somebody
else cares.
Digression: this suggests an attribute such as inline_if_reduces which
--- Comment #1 from hjl dot tools at gmail dot com 2009-11-30 03:39 ---
It is caused by revision 150519:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00199.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2009-11-30 03:59
---
Ok, if I back up one step and leave the error message in trans-array.c and use
gfc_fatal_error we get a usable patch. One thing this is showing is that the
expansion is being done in the parsing/matching phase
Hi,
I ran into a ICE (segmentation fault) with GCC 4.5 (20091126) when building
some C++ templated code. The platform is GNU/Linux, x86-64.
Please find attached the preprocessed source:
product_small.ii.bz2
I have compressed it because it was really huge (this codes uses a C++ template
--- Comment #1 from jacob dot benoit dot 1 at gmail dot com 2009-11-30
04:17 ---
Created an attachment (id=19181)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19181action=view)
Preprocessed C++ source triggering this ICE
To uncompress do:
bunzip2 product_small.ii.bz2
--
--- Comment #18 from hp at gcc dot gnu dot org 2009-11-30 07:13 ---
Subject: Bug 40086
Author: hp
Date: Mon Nov 30 07:13:21 2009
New Revision: 154751
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154751
Log:
PR rtl-optimization/40086
* reorg.c
--- Comment #19 from hp at gcc dot gnu dot org 2009-11-30 07:19 ---
a comment
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from tkoenig at gcc dot gnu dot org 2009-11-30 07:31
---
Created an attachment (id=19182)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19182action=view)
Patch that works for unrolling
It also passes do_3.F90.
I'll submit just in time for meeting the phase 4
--- Comment #7 from bonzini at gnu dot org 2009-11-30 07:35 ---
Subject: Bug 41812
Author: bonzini
Date: Mon Nov 30 07:34:55 2009
New Revision: 154753
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154753
Log:
2009-11-30 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #1 from rupp at gnat dot com 2009-11-30 07:42 ---
Fails in same manner on s390x-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42224
--- Comment #5 from hjl dot tools at gmail dot com 2009-11-30 07:56 ---
It is caused by revision 139945:
http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00103.html
and fixed by revision 147852:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00829.html
--
hjl dot tools at gmail dot com
95 matches
Mail list logo
