--- Comment #5 from yimingli0126 at 163 dot com 2009-09-02 06:59 ---
(In reply to comment #4)
> Actually, a library issue, invalid, still library.
Many thanks for your reply.
Yes, it could be a library issue and this problem occurred since v4.3.x.
MSVC 8.0/9.0 doesn't have this proble
--- Comment #6 from drangon dot mail at gmail dot com 2009-09-02 06:54
---
The cross compiler doesn't has problem, but the native compiler has problem.
I will rebuilt the whole cross compiler and native compiler with the newest
source to see the problem still exist or not.
--
http
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #4 from gcc at portuosus dot com 2009-09-02 06:48 ---
redux2.cc (and actual code from which it was derived) works with 3.4.6 and
4.1.2 and 4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41223
--- Comment #3 from gcc at portuosus dot com 2009-09-02 06:44 ---
My bad.
redux2.cc *does* work in the actual code from which it was reduced.
--
gcc at portuosus dot com changed:
What|Removed |Added
--- Comment #2 from gcc at portuosus dot com 2009-09-02 06:15 ---
This works in 4.4.1 and 3.4.6 and 4.1.2:
//redux2.cc
#include
#include
struct C
{
template class Container >
void member_template(Container &contai
--- Comment #4 from kargl at gcc dot gnu dot org 2009-09-02 05:19 ---
(In reply to comment #3)
> Indeed this is a duplicate of bug 39876, sorry for not finding that earlier.
> Thanks!
>
> *** This bug has been marked as a duplicate of 39876 ***
>
Speaking as one of the gfortran hacker
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-02 05:12 ---
This code is invalid. The reason is std::vector is a template that takes two
template arguments (with a default one).
So template class Container does not match std::vector in 4.4.
This was a removed undocument
With the code:
// begin redux.cc
#include
#include
struct C
{
template class Container >
void member_template(Container &container)
{}
};
int main(int,char**)
{
std::vector entries;
C().member_template(entries);
}
//end redux.cc
while compiling with 4.4.1 (host:=x86_64, target:=x86_6
--- Comment #18 from lucier at math dot purdue dot edu 2009-09-02 02:54
---
Vlad:
The patch works great in my tests so far, thanks.
After installing your patch on today's trunk so that -fschedule-insns actually
works, I find it is quite expensive on large files.
For example, with tod
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-09-02 01:19
---
Closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|RE
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-09-02 01:03
---
Subject: Bug 39229
Author: jvdelisle
Date: Wed Sep 2 01:03:34 2009
New Revision: 151309
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151309
Log:
2009-09-01 Jerry DeLisle
PR fortran/39229
--- Comment #7 from pablomme at googlemail dot com 2009-09-02 00:10 ---
*** Bug 41222 has been marked as a duplicate of this bug. ***
--
pablomme at googlemail dot com changed:
What|Removed |Added
---
--- Comment #3 from pablomme at googlemail dot com 2009-09-02 00:10 ---
Indeed this is a duplicate of bug 39876, sorry for not finding that earlier.
Thanks!
*** This bug has been marked as a duplicate of 39876 ***
--
pablomme at googlemail dot com changed:
What|Remov
1.
troutmask:sgk[209] gfc4x --version
GNU Fortran (GCC) 4.5.0 20090901 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
Note, I haven't given any thought to the program
and the options used as what the correct behavior
ought to be.
--
kargl at gcc dot gnu dot org ch
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-01 23:52 ---
The test works on trunk. I think it is a variant (duplicate?) of pr39876 that
has been fixed on trunk. The fix could probably be backported to 4.4.2 without
too much trouble.
--
http://gcc.gnu.org/bugzilla/show_b
This applies to gfortran 4.4.1 as distributed with Ubuntu 9.10 alpha-4. The use
of the "-std=f95" flag causes a spurious error to be raised when the module or
program being compiled USEs a function from another module whose name matches
that of a Fortran 200x intrinsic.
I'll illustrate the bug wit
--- Comment #1 from fedora at matbooth dot co dot uk 2009-09-01 22:59
---
Created an attachment (id=18464)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18464&action=view)
build error
This is the error that is spit into the console during the build of the above
rpm.
--
http:
Hi,
I maintain the eclipse-emf package in Fedora. If I enable gcj-aot compiling on
it, I get an internal compiler error.
The error can be reproduced by building the following source rpm on Fedora 10,
11 or 12 (Rawhide):
http://mbooth.fedorapeople.org/aot_bug/eclipse-emf.spec
http://mbooth.fedora
--- Comment #45 from paolo dot carlini at oracle dot com 2009-09-01 22:26
---
(In reply to comment #44)
> GCC 4.4 came and went. Now what?
Now what what? The issue is fixed for 4.4, and I just double checked myself the
original testcase and the one in Comment #40, both compile fine. C
--- Comment #44 from keith dot g dot erickson at lmco dot com 2009-09-01
22:11 ---
(In reply to comment #41)
> (In reply to comment #40)
> > I read all comments and saw a patch. But I don't know how I can fix my gcc
> > with
> > this patch.
>
> The easiest way is to wait for gcc 4.4.
The summary says it all. For sure it used to work fine and still does in the
4_4-branch. Many spurious failures:
FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
FAIL: 17_intro/headers/c++1998/all_no_exceptions.cc (test for excess errors)
FAIL: 17_intro/headers/c++1998/stdc++.cc (tes
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-01 21:38 ---
I believe libtool wasn't doing the right thing without any sources, but it has
been a while, so I don't remember the details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
--- Comment #3 from kpfleming at digium dot com 2009-09-01 21:11 ---
That talks about using -fpie/-fPIE as a workaround, but according to the gcc
manpage those options are not suitable when the result is going to be used in a
shared library, only as a linked executable.
--
http://gc
Reported by NightStrike in #gfortran - I see the same in my build logs. Some
annotations, see below.
../../../gcc/libgfortran/io/list_read.c: In function nml_read_obj:
../../../gcc/libgfortran/io/list_read.c:2470:31: warning: comparison between
bt and enum
../../../gcc/libgfortran/io/write.
--- Comment #2 from kargl at gcc dot gnu dot org 2009-09-01 20:58 ---
(In reply to comment #1)
> I have just run into this as well; supplying -fPIC (implied in -shared)
> without
> -fwhole-program works fine, but adding -fwhole-program causes functions that
> are called internally to th
http://gcc.gnu.org/ml/fortran/2009-09/msg3.html
g77 - but also openf95, sunf95 or ifort - support the following Fortran 66
vendor extension, which was effectively obsoleted by Fortran 77.
LOGICAL :: L
INTEGER :: I
REAL:: R
DATA L/'abcd'/, I/'Text'/, R/'ZYXW'/ ! Mi
--- Comment #1 from kpfleming at digium dot com 2009-09-01 20:53 ---
I have just run into this as well; supplying -fPIC (implied in -shared) without
-fwhole-program works fine, but adding -fwhole-program causes functions that
are called internally to the program being compiled to end up
--- Comment #4 from paolo dot carlini at oracle dot com 2009-09-01 20:07
---
Actually, a library issue, invalid, still library.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #3 from paolo dot carlini at oracle dot com 2009-09-01 20:06
---
As a matter of fact, this snippet doesn't link:
struct Inner
{
Inner()
: data(0) {}
template
explicit Inner(IStream&);
int data;
};
int f()
{
Inner inner1;
Inner inner2(inner1);
}
Now, as a
$ ./xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c
Thread model: posix
gcc version 4.5.0 20090901 (experimental) [trunk revision 151276] (GCC)
$ ./xgcc -B. -o
Segmentation fault
(gdb) bt
#0 0xb7f43613 in strlen () from /lib/tls/i686
el: win32
> gcc version 4.5.0 20090901 (experimental) [trunk revision 151274] (GCC)
>
Works for me too. Maybe a duplicate of PR/41184
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
--- Comment #16 from ktietz at gcc dot gnu dot org 2009-09-01 18:38 ---
(In reply to comment #15)
> GCC 4.5 [Trunk], SVN Revision 149872. Because Win64 testing is so hard to come
> by, I took the initiative of deleting the entire tree, re-checking it out, and
> building from scratch. I a
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-01 18:26 ---
I can't reproduce this failure. Neither for msys, linux, and linux64, nor for
cygwin. Does it still exists for you?
Which host and build environment you are using?
--
ktietz at gcc dot gnu dot org changed:
--- Comment #4 from ubizjak at gmail dot com 2009-09-01 17:53 ---
Works for me with a crosscompiler from linux to mingw:
Target: x86_64-pc-mingw32
Configured with: ../gcc-svn/trunk/configure --target=x86_64-pc-mingw32
Thread model: win32
gcc version 4.5.0 20090901 (experimental) [trunk
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 ---
*** Bug 39112 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 ---
*** This bug has been marked as a duplicate of 41184 ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-01 17:39 ---
Created an attachment (id=18463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18463&action=view)
Draft patch - first steps but incomplete & will not work
Draft patch (not really work yet).
TODO:
a) Copy attri
--- Comment #3 from ubizjak at gmail dot com 2009-09-01 17:31 ---
Per comment #2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from ubizjak at gmail dot com 2009-09-01 17:26 ---
No testcase -> no analysis -> no solution.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from aph at gcc dot gnu dot org 2009-09-01 17:09 ---
Hmm, I seem to have approved that patch.
I agree with you: I can't see why the specfile change requires ecjx.cc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
--- Comment #2 from paolo dot carlini at oracle dot com 2009-09-01 17:07
---
Seems a problem with the stricter uninitialized_copy we have got since 4.3...
Investigating.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #3 from tromey at gcc dot gnu dot org 2009-09-01 16:58 ---
I think it isn't correct to use "gcc" directly.
You probably have to introduce a new variable.
But, I don't see why we need ecjx.cc at all.
I think it must be to work around some other problem.
Maybe instead we could
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 16:20 ---
As the initial reason of this bug is solved, I close it. In fact is the
__chkstk function here incompatible to VC version, but this should be part of a
feature request.
--
ktietz at gcc dot gnu dot org changed:
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 ---
*** Bug 39356 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #19 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 ---
I verified it by myself and it is a duplicate of 41184
*** This bug has been marked as a duplicate of 41184 ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from yimingli0126 at 163 dot com 2009-09-01 16:16 ---
Created an attachment (id=18462)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18462&action=view)
The source file rising the compilation failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216
Platform£º
WinXP SP3 + Eclipse CDT 6.0 + MinGW 5.1.4 + GCC 4.4.1 (TDM's Build)
Bug description:
GCC failed to correctly resolve the template parameters when nestedly calling
friend function templates of class templates.
Sample codes£º
/* TestMinGW.cpp*/
#include
#include
/* Class Inner */
st
--- Comment #3 from Vikas dot Mehta at roguewave dot com 2009-09-01 15:22
---
Subject: RE: floating point optimization
Thanks for looking into this issue.
Target: x86_64-redhat-linux
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu.org]
S
--- Comment #3 from siarhei dot siamashka at gmail dot com 2009-09-01
15:08 ---
It works fine if '-fno-omit-frame-pointer' is removed. I agree that this is
quite a large and convoluted function. Unfortunately I did not manage to reduce
it to something smaller that would still result in
--- Comment #3 from ramana at gcc dot gnu dot org 2009-09-01 14:56 ---
Does this still occur with trunk ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-09-01 14:51 ---
I'm afraid nothing much can be done without a smaller testcase than this. What
happens if you don't use -fno-omit-frame-pointer ?
--
ramana at gcc dot gnu dot org changed:
What|Removed
There is currently no GCC option that will turn off discarded qualifiers
warnings, which typically arise from const/non-const mismatches. These
warnings look like this:
warning: assignment discards qualifiers from pointer target type
warning: passing argument 1 of foo discards qualifiers fr
--- Comment #2 from aph at gcc dot gnu dot org 2009-09-01 14:06 ---
Assigning to Tom tromey: this is his area.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-09-01 14:01 ---
Indeed. SRA should not trigger here, that would make it too eager in other
cases (thus I'm removing myself from the CC, feel free to add me again if
there's any discussion that might concern me or SRA again).
--
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-09-01 13:54
---
I think the question is whether the use of __optimize__ is in a standard Qt
release. If it is, then I'm quite concerned; it's bad if GCC 4.4.2 can't build
Qt/KDE.
(TBH, I'm concerned anyhow; if __optimize__ is u
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-01 13:37 ---
Confirmed on (powerpc|i686)-apple-darwin9 in 32 bit mode and -O2 or above. This
is a regression: I get 1.21306131891052 with gcc 4.2.4, 4.3.4, and 4.4.1. I
also get 1.21306131891052 with recent revisions of trunk with
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-01 13:29 ---
As fun one can think of supporting also alignment within a TYPE, similarly to
C's:
struct foo { int x[2] __attribute__ ((aligned (8))); };
See http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html for details.
--- Comment #7 from hjl dot tools at gmail dot com 2009-09-01 13:20 ---
Realign the incoming stack for vectorizer has very limited impact
on performance. Here are the differences of -m32 -O3 -msse2
-mfpmath=sse -ffast-math -funroll-loops before and after my patch:
400.perlbench
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-09-01 12:21
---
Let's reopen it as LTO specific. The test still fails on i?86 with the
original multi-file testcase and -flto. There are also other similar pb_ds
fails.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from paolo dot carlini at oracle dot com 2009-09-01 12:21
---
For sure, this isn't a library issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 ---
Sorry about the duplicate...
*** This bug has been marked as a duplicate of 41212 ***
--
jpr at csc dot fi changed:
What|Removed |Added
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 ---
*** Bug 41213 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
GCC 4.5.0 20090827
When I run any program which throws an exception, I get a segfault:
__cxa_throw . libstdc++-v3/libsupc++/eh_throw.cc:78
_Unwind_RaiseException .. gcc/unwind.inc:62
__gxx_personality_v0 libsupc++/eh_personality.cc:706
_Unwind_SetGR ... gcc/unwind-dw2.c:2
--- Comment #30 from paolo dot carlini at oracle dot com 2009-09-01 12:12
---
Even if the bug is fixed, I think it would be nice to have it properly
categorization: I can see only a C++ front-end patch in the trail, thus I'm
changing the category to C++. If I'm wrong, please improve it.
The program below is miscompiled using
gfortran -O2 -o m m.f90; ./m
gives:
y= 0.60653065945526063 2*y= 2.
(the second of the printed numbers should equal twice the first). Using
gfortran -fno-inline -O2 -o m m.f90
works OK.
The compiler is:
Using built-in specs.
Target:
--- Comment #17 from ubizjak at gmail dot com 2009-09-01 12:08 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-09/msg3.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-01 12:03 ---
This sounds correct to me . Adding one of the libjava maintainers to comment on
this. Patches should be submitted to the correct mailing list.
--
ramana at gcc dot gnu dot org changed:
What|Removed
--- Comment #29 from ubizjak at gmail dot com 2009-09-01 12:00 ---
(In reply to comment #28)
> This may be related to PR 37144.
No, it was assembler bug with 2.19.1 in my case.
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-09-01 11:49 ---
> It turns out, that the PRODUCT is already simplified to EXPR_CONST
> before is is checked in expr.c (check_init_expr).
To be more specific, in resolve.c (resolve_unknown_f) the simplification is
implied via intrin
--- Comment #3 from drangon dot mail at gmail dot com 2009-09-01 11:42
---
-O0 doesn't has problem, -O1 -O2 has problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
The program below is miscompiled using
gfortran -O2 -o m m.f90; ./m
gives:
y= 0.60653065945526063 2*y= 2.
(the second of the printed numbers should equal twice the first). Using
gfortran -fno-inline -O2 -o m m.f90
works OK.
The compiler is:
Using built-in specs.
Target:
--- Comment #2 from drangon dot mail at gmail dot com 2009-09-01 11:25
---
Created an attachment (id=18461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18461&action=view)
alter.s, -save-temps output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
--- Comment #1 from drangon dot mail at gmail dot com 2009-09-01 11:22
---
Created an attachment (id=18460)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18460&action=view)
gzip of alter.i, -save-temps output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
I built an x86_64-w64-mingw32 cross compiler under x86_64 linux using latest
gcc SVN code,
then use this cross compiler to build sqlite3
The compile failed with the following message :
E:\code\sqlite3_sep>make
gcc -pipe -Wall -g -O2 -save-temps -c -o alter.o alter.c
gcc: warning: -pipe ignored b
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-01 11:13 ---
Also occurs with trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-01 10:34 ---
Subject: Bug 41199
Author: rguenth
Date: Tue Sep 1 10:34:17 2009
New Revision: 151265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151265
Log:
2009-09-01 Richard Guenther
PR lto/41199
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-01 10:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
gcc.target/powerpc/vsx-builtin-7.c
testcase ICEs with -m32 -fstack-protector or -m64:
./cc1 -I include/ -O2 -m32 -fstack-protector -mcpu=power7 vsx-builtin-7.c
(insn 19 31 22 2 vsx-builtin-7.c:21 (set (reg/i:V2DF 3 3)
(mem/c/i:V2DF (plus:SI (reg:SI 9 9)
(reg:SI 0 0 [135])) [
--- Comment #29 from dominiq at lps dot ens dot fr 2009-09-01 09:37 ---
Does anyone understand why commenting a write can change crtl->maybe_hot_insn_p
from 1 to 0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
gfortran currently supports only STDCALL, FASTCALL and CDECL as attributes
using
!GCC$ ATTRIBUTE :: symbol
The attributes are saved as bit in the attr struct. For full attribute support,
one presumably should save the string and convert it later in trans*.c into a
TREE.
The string should then
--- Comment #11 from jakub at gcc dot gnu dot org 2009-09-01 09:32 ---
Mark, I don't think this should be P1, __optimize__ attribute is new in 4.4 (so
considering it regression is already quite weird, though the attribute is
ignored in older releases, so technically it is a regression, a
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-01 09:28 ---
IMHO either standard options compiled code shouldn't be called from
-mpreferred-stack-boundary=2 code, or it needs to be compiled with
-mincoming-stack-boundary=2. But it should be user's responsibility. Ensuring
by
--- Comment #17 from jv244 at cam dot ac dot uk 2009-09-01 09:17 ---
(In reply to comment #16)
> All numbers with trunk:
with 4.3 there is no difference between -O2 and -O3
-O2 -march=native -funroll-loops -ffast-math: 4.388
-O2 -march=native -funroll-loops -ffast-math -fschedule-insn
--- Comment #16 from jv244 at cam dot ac dot uk 2009-09-01 09:13 ---
(In reply to comment #15)
> Please try -O2 and -O2 -funroll-loops too, since -O3 is not always good for
> speed. (It would be even better if -O2 is not slower and you can find out
> what
> the culprit is at -O3; this
In running applications on e500, we got "illegal instruction" error, finally,
we found it's caused by asm code below:
gcc-4.3.2/boehm-gc/include/private/gc_locks.h
__asm__ __volatile__("lwsync": : : "memory");
lwsync is not supported by e500, even though powerpc claims that. There are
sim
x86_64-w64-mingw32-g++ produce binary will not run.
Runtime : libqt4_plugin.dll' (%1 is not a valid Win32 application. (error 193))
plugins/libqt4_plugin.dll: file format pei-x86-64
Disassembly of section .text:
68e81000 <_pre_c_init>:
68e81000: 53 push
--- Comment #4 from dodji at gcc dot gnu dot org 2009-09-01 08:55 ---
Fixed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #15 from bonzini at gnu dot org 2009-09-01 08:54 ---
Please try -O2 and -O2 -funroll-loops too, since -O3 is not always good for
speed. (It would be even better if -O2 is not slower and you can find out what
the culprit is at -O3; this is not necessarily possible though).
--- Comment #10 from dodji at gcc dot gnu dot org 2009-09-01 08:46 ---
Subject: Bug 30161
Author: dodji
Date: Tue Sep 1 08:45:38 2009
New Revision: 151262
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151262
Log:
Fix bootstrap after patch PR debug/30161
gcc/ChangeLog:
--- Comment #3 from dodji at gcc dot gnu dot org 2009-09-01 08:46 ---
Subject: Bug 41205
Author: dodji
Date: Tue Sep 1 08:45:38 2009
New Revision: 151262
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151262
Log:
Fix bootstrap after patch PR debug/30161
gcc/ChangeLog:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-01 08:16 ---
Works for me on a i686 host with current trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41203
--- Comment #2 from dodji at gcc dot gnu dot org 2009-09-01 07:01 ---
Created an attachment (id=18459)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18459&action=view)
Obvious fix candidate
Could you please test this patch on darwin and see if it fixes bootstrap for
you ?
I am sor
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
94 matches
Mail list logo
