This is a remainder to not catch you in surprise when we announce
the end of stage 3. Starting Dec 1st the trunk will go into
regression and documentation fixes only mode (thus, same rules
apply as for a release branch). When the release criteria
are fulfilled (mainly zero P1 regressions) we
Toon Moene wrote:
I wrote:
OK, so it is an alignment issue (with -mtune=barcelona):
.L6:
movups 0(%rbp,%rax), %xmm0
movups (%rbx,%rax), %xmm1
incl%ecx
addps %xmm1, %xmm0
movaps %xmm0, (%r8,%rax)
addq$16, %rax
cmpl
Hi everybody,
I am currently starting to work on a new edition of my
C++ Library book and from what I see, you already have
good support of a couple of new feature. Great!
So, I start to try g++ 4.4.2 out now...
However, both
gcc-g++-4.4.2.tar.gz
as well as
gcc-4.4.2.tar.gz
downloaded from
Toon Moene wrote:
Tim Prince wrote:
If you want those, you must request them with -mtune=barcelona.
OK, so it is an alignment issue (with -mtune=barcelona):
.L6:
movups 0(%rbp,%rax), %xmm0
movups (%rbx,%rax), %xmm1
incl%ecx
addps %xmm1, %xmm0
Latest information -
Ok, based on this, I traced it back further:
rtx
gen_rtx_fmt_e0 (code, mode, arg0)
RTX_CODE code;
enum machine_mode mode;
rtx arg0;
{
rtx rt;
rt = ggc_alloc_rtx (2);
memset (rt, 0, sizeof (struct rtx_def) - sizeof (rtunion));
The request for 2 (I guess,
On Sun, Nov 29, 2009 at 3:07 PM, Nicolai Josuttis n...@josuttis.de wrote:
Hi everybody,
I am currently starting to work on a new edition of my
C++ Library book and from what I see, you already have
good support of a couple of new feature. Great!
So, I start to try g++ 4.4.2 out now...
Richard Guenther wrote:
This is a remainder to not catch you in surprise when we announce
the end of stage 3. Starting Dec 1st the trunk will go into
regression and documentation fixes only mode
Is there perhaps a nice, noble, brave, honest, handsome, heroic,
sweetly-smelling driver or
On Sun, 29 Nov 2009, Richard Guenther wrote:
This is a remainder to not catch you in surprise when we announce
the end of stage 3. Starting Dec 1st the trunk will go into
regression and documentation fixes only mode (thus, same rules
apply as for a release branch). When the release
On Sun, 29 Nov 2009, Kaveh R. GHAZI wrote:
On Sun, 29 Nov 2009, Richard Guenther wrote:
This is a remainder to not catch you in surprise when we announce
the end of stage 3. Starting Dec 1st the trunk will go into
regression and documentation fixes only mode (thus, same rules
apply
Ah, interesting.
well the point is that I extracted the files
with WinZip (Version 9.0, build 6028) before I
started the built in a cygwin environment.
So, it's not a cygwin, it's a WinZip bug
(I can confirm that cygwin tar extracts the files
with the correct extension).
Thanks for the fast
Richard Guenther wrote:
We'll be all reasonable folks. Please don't again open another
huge thread with *random whine*, please consider my patch!.
There is a finite amount of time and a finite number of reviewers, and a
random number of outstanding patches. Wouldn't a handy list of them
Toon Moene wrote:
This is where IPA could help. I created the following main program:
real a(10), b(10), c(10)
a = 0.
b = 1.
print '(3(1x,z16))', loc(a), loc(b), loc(c)
call sum(a, b, c, 10)
print *, c(5)
end
So the alignment of a, b and c is known
On Sun, Nov 29, 2009 at 7:12 PM, Toon Moene t...@moene.org wrote:
Toon Moene wrote:
This is where IPA could help. I created the following main program:
real a(10), b(10), c(10)
a = 0.
b = 1.
print '(3(1x,z16))', loc(a), loc(b), loc(c)
call sum(a, b, c, 10)
Hello All,
I believe there are several plugin issues to fix before 4.5 releases:
1. use of libiberty from plugins.
As several patches recently sent demonstrated, the current state of the trunk does not work with plugins calling some
of the libiberty functions is IMHO not acceptable.
we
Snapshot gcc-4.3-20091129 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20091129/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Sun, Nov 29, 2009 at 3:33 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, Nov 29, 2009 at 9:18 PM, Daniel Berlin dber...@dberlin.org wrote:
Such a thing already existed a few years ago (IIRC Haifa had something
that Dan picked up and passed on to me). But it never brought any
The patch which makes the MPC library a hard requirement for GCC
bootstrapping has been approved today. As promised, I'll wait one week
before applying it to give everyone a chance to install MPC on their
systems.
You can download mpc-0.8 from either of these two locations:
On Mon, Nov 30, 2009 at 12:40 AM, Daniel Berlin dber...@dberlin.org wrote:
This pass may even be on the lno branch or something.
It used to be, at least, see http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg00470.html
Happy hacking, Toon :-)
Ciao!
Steven
Thank you! I've known to how to create a *compat* PIC library, firstly using
`-fvisibility=hidden' in compile command line to hidden all symbols, then
using `objcopy -R' to remove .got section totally! However, assemble result is
just like this
call__i686.get_pc_thunk.bx
addl
--- 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
1 - 100 of 114 matches
Mail list logo
