More FDO related performance numbers
Experiment 1: trunk gcc O2 + FDO vs O2: FDO improves performance
by 5% geomean
Experiment 2: our internal gcc compiler (4.4.3 based with many local
patches) O2 + FDO vs O2 (trunk gcc): FDO improves perf by 6.6%
geomean
Experiment 3: our internal gcc
On Mon, Nov 15, 2010 at 7:19 PM, Jay K jay.kr...@cornell.edu wrote:
I know it is debatable and I could be convinced otherwise, but I would
suggest:
#ifdef __cplusplus
extern C {
#endif
...
#ifdef __cplusplus
} /* extern C */
#endif
be applied liberally in gcc.
Not around
The gthreads portability layer is missing a function for destroying a
__ghtread_recursive_mutex object.
For pthreads-based models the recursive mutex type is the same as the
normal mutex type so __gthread_mutex_destroy handles both, but they're
distinct types for (at least) gthr-win32.h, so we
2010/11/16 Jan Hubicka hubi...@ucw.cz:
On Mon, Nov 15, 2010 at 5:39 PM, Jan Hubicka hubi...@ucw.cz wrote:
Fortunately linker plugin solves the problem here and this is why I
want to
have it by default. GCC then can do effectively -fwhole-program for
binaries
(since linker knows
More FDO related performance numbers
Experiment 1: trunk gcc O2 + FDO vs O2: FDO improves performance
by 5% geomean
Experiment 2: our internal gcc compiler (4.4.3 based with many local
patches) O2 + FDO vs O2 (trunk gcc): FDO improves perf by 6.6%
geomean
Experiment 3: our
The easiest way to deal with the use of LIBGCC2_FLOAT_WORDS_BIG_ENDIAN
in libgcc is to define a preprocessor macro __FLOAT_WORD_ORDER__ similar
to how WORDS_BIG_ENDIAN was converted. That is, cppbuiltin.c will do:
cpp_define_formatted (FOO, __FLOAT_WORD_ORDER__=%s,
Quoting Ian Lance Taylor i...@google.com:
Joern Rennecke amyl...@spamcop.net writes:
Before I go and make all these target changes test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
On Tue, 16 Nov 2010, Nathan Froyd wrote:
The saving grace here is that decimal float is not enabled by default
for arm platforms, so there are likely very few, if any, users of
decimal float on ARM; it might be worthwhile to go ahead and fix things,
ignoring the fallout from earlier versions.
Hi,
I have been investigating a problem I have while building Qt-embedded
with GCC-4.5.0 for ARM/Linux, and managed to produce the reduced test
case as follows.
Consider this shared library (C++):
atomic.cxx
int atomicIncrement(int volatile* addend)
{ return
I spoke with a partner today who suggested that perhaps it would be a
bit easier to follow the voluminous GCC mailing list if we had separate
lists for patches related to particular back-ends (e.g., ARM, MIPS,
Power, SuperH, x86, etc.).
The idea here is that (as with libstdc++), we'd send patches
On Tue, Nov 16, 2010 at 9:29 AM, Mark Mitchell m...@codesourcery.com wrote:
What do people think about this idea?
I think this is really bad idea. A lot of the time, back-end patches
for one target inspires some folks to do patches for another target.
Or for an example, look at how FMA has been
On Tue, Nov 16, 2010 at 6:35 AM, Jan Hubicka hubi...@ucw.cz wrote:
More FDO related performance numbers
Experiment 1: trunk gcc O2 + FDO vs O2: FDO improves performance
by 5% geomean
Experiment 2: our internal gcc compiler (4.4.3 based with many local
patches) O2 + FDO vs O2 (trunk
On 11/16/2010 09:29 AM, Mark Mitchell wrote:
The idea here is that (as with libstdc++), we'd send patches to
gcc-patches@ and gcc-$arch@, but that reviewers for a particular
back-end would find it easier to keep track of things on the
architecture-specific lists, and also that this would make
On 16/11/2010 17:29, Mark Mitchell wrote:
I spoke with a partner today who suggested that perhaps it would be a
bit easier to follow the voluminous GCC mailing list if we had separate
(Do you mean the voluminous gcc-patches mailing list perhaps?)
lists for patches related to particular
Quoting Ian Lance Taylor i...@google.com:
Joern Rennecke amyl...@spamcop.net writes:
Before I go and make all these target changes test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
Quoting Ian Lance Taylor i...@google.com:
Joern Rennecke amyl...@spamcop.net writes:
Before I go and make all these target changes test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
On 11/16/2010 11:24 AM, Dave Korn wrote:
I think it's probably an over-engineered solution to a problem we could
really address best by remembering to use []-tags in the subject lines.
OK, that seems to be as close to consensus as we're probably going to
get. Let's try and do that.
Thank
The gthreads portability layer is missing a function for destroying a
__ghtread_recursive_mutex object.
For pthreads-based models the recursive mutex type is the same as the
normal mutex type so __gthread_mutex_destroy handles both, but they're
distinct types for (at least) gthr-win32.h, so
On 11/16/2010 10:17 PM, Ian Lance Taylor wrote:
I don't know how we want to get there, but it seems to me that the place
we want to end up is with the target hooks defined to take an argument
of type struct cumulative_args * (or a better name if we can think of
one).
Actually, this doesn't
Quoting Paolo Bonzini bonz...@gnu.org:
I think a multi-target executable would be just too ugly in C due to
issues such as this. I don't think it's worthwhile to sacrifice type
safety now, so a struct cumulative_args is preferrable.
I don't see how going to a struct cumulative_args gets us
Joern Rennecke amyl...@spamcop.net writes:
I don't see how going to a struct cumulative_args gets us closer to
a viable solution for a multi-target executable, even if you threw in
C++. Having the target describe a type, and shoe-horning this through
a target
hook interface that is decribed
On 11/17/2010 03:10 AM, Ian Lance Taylor wrote:
Joern Renneckeamyl...@spamcop.net writes:
I don't see how going to a struct cumulative_args gets us closer
to a viable solution for a multi-target executable, even if you
threw in C++. Having the target describe a type, and shoe-horning
this
On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote:
True, but you can hide that cast in a base class. For example you
can use a hierarchy
Target // abstract base
TargetImplBaseTargetI386 // provides strong typing
TargetI386
Quoting Nathan Froyd froy...@codesourcery.com:
I am admittedly a C++ newbie; the first thing I thought of was:
class gcc::cumulative_args {
virtual void advance (...) = 0;
virtual rtx arg (...) = 0;
virtual rtx incoming_arg (...) { return this-arg (...); };
virtual int
Nathan Froyd froy...@codesourcery.com writes:
On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote:
True, but you can hide that cast in a base class. For example you
can use a hierarchy
Target // abstract base
TargetImplBaseTargetI386 //
Quoting Ian Lance Taylor i...@google.com:
The scheme that Paolo describes avoids virtual functions. But for this
usage I personally would prefer virtual functions, since there is no
efficiency cost compared to a target hook.
Well, actually, there is: you first fetch the object pointer, then
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339
--- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-16
08:18:12 UTC ---
(In reply to comment #16)
ipn-offset = -1;
span.9 = 8;
I think we want ipn-span = 8;
While I am sure that we want to have ipn-span, I am not sure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
--- Comment #17 from Zouzou internet at 123gen dot com 2010-11-16 08:37:02
UTC ---
(In reply to comment #16)
Created attachment 22413 [details]
add destructors in ext/concurrence.h
could you try applying this patch to ext/concurrence.h and let
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46496
Summary: Missing strlen check / interop warnings with BIND(C)
and non-C_* kinds
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46493
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46494
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
--- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-16
10:25:40 UTC ---
Jon, sometimes finding a reviewer for those gthr changes takes a bit of time...
and we are already in Stage 3... Thus, I would recommend doing our best
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46483
--- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2010-11-16
10:35:41 UTC ---
The misaligned __builtin_memcpy was fixed for 4.6 by r163189, Richard
Guenther's conservative alignment tracking (2nd try) patch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #5 from John Marino gnugcc at marino dot st 2010-11-16 10:35:54
UTC ---
Hi Eric,
Thanks for you comment, but I don't think that is it for several reasons:
1) I am aware of both those quirks, and my codebase is patched with both of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497
Summary: [C++0x] Defaulted vs declared move constructor vs
is_convertible
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-16
10:56:07 UTC ---
And for the record what I'm doing for the time being in the actual std::pair
is:
// XXX FIXME: should be defaulted per N3140. See c++/46497.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
--- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-16
11:05:44 UTC ---
OK, that will be ugly though. The cast from __gthread_recursive_mutex_t* to
__gthread_mutex_t* is not correct, because the sema member (the actual Win32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
--- Comment #7 from John Marino gnugcc at marino dot st 2010-11-16 11:25:31
UTC ---
Eric,
Actually I believe it is limited to the BSDs, although I can't explain why. I
also ported GNAT to x86 OpenSolaris (SXCE 130) and that one passed all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45172
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45172
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-16
11:42:53 UTC ---
Author: rguenth
Date: Tue Nov 16 11:42:50 2010
New Revision: 166794
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166794
Log:
2010-11-16 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
--- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-16
11:52:20 UTC ---
Argh, I see. I think we should keep the option open, anyway, together with a
huge FIXME in the code, of course. I also think we should try to explain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
--- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-16
12:06:42 UTC ---
Can't reproduce it on current trunk. Looking at it on the branch.
Try -fstack-check=generic on the trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-16
12:16:52 UTC ---
Created attachment 22419
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22419
gcc46-pr45838.patch
Untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46483
--- Comment #9 from Mikael Pettersson mikpe at it dot uu.se 2010-11-16
12:21:20 UTC ---
With gcc-4.5.1, the plain assignment is preserved until 141r.expand, which
expands it to a bitfield assignment due to the misalignment check in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
--- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-16
12:32:36 UTC ---
... and when using gthr-mipssde.h / gthr-posix95.h / gthr-solaris.h:
static inline int
__recursive_mutex_destroy(__gthread_recursive_mutex_t* __rmutex)
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Attachment #22419|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46483
--- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2010-11-16
13:08:53 UTC ---
The test cases also fail with gcc-4.5.1 on sparc64-linux. On that platform
alignment errors are fatal and the program dies with a SIGBUS on the misaligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086
--- Comment #7 from Anton Shterenlikht mexas at bristol dot ac.uk 2010-11-16
13:18:39 UTC ---
As it is hard to downgrade the port versions (it might break port
interdependency), I tried instead to use a more recent gcc to build
the ports in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46040
Laurent GUERBY laurent at guerby dot net changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-16
13:37:28 UTC ---
Created attachment 22421
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22421
gcc46-pr45838.patch
Another, alternate, untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-16
13:38:21 UTC ---
(In reply to comment #7)
configure: error: in
`/usr/ports/lang/gcc45/work/build/sparc64-portbld-freebsd9.0/libgomp':
configure: error: C compiler cannot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46483
--- Comment #11 from Mikael Pettersson mikpe at it dot uu.se 2010-11-16
13:40:32 UTC ---
The test cases work with gcc-4.3.5. For arm it generates the following for the
__builtin_memcpy case:
set_by_memcpy:
@ args = 0, pretend = 0, frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086
--- Comment #9 from Anton Shterenlikht mexas at bristol dot ac.uk 2010-11-16
13:44:48 UTC ---
Created attachment 22422
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22422
config.log showing configure errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086
--- Comment #10 from Anton Shterenlikht mexas at bristol dot ac.uk 2010-11-16
13:46:30 UTC ---
here's the relevant bit, I guess:
configure:3658: checking for C compiler default output file name
configure:3680:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46487
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-16
13:49:58 UTC ---
Well, the problem is actually simple:
program test
implicit none
integer :: b
b = func()
contains
function func ()
integer, allocatable :: func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-16
13:53:53 UTC ---
Author: rguenth
Date: Tue Nov 16 13:53:50 2010
New Revision: 166796
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166796
Log:
2010-11-16 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46366
--- Comment #4 from Andrey Belevantsev abel at gcc dot gnu.org 2010-11-16
14:11:47 UTC ---
Author: abel
Date: Tue Nov 16 14:11:39 2010
New Revision: 166798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166798
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
--- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-16
14:15:59 UTC ---
Author: rguenth
Date: Tue Nov 16 14:15:55 2010
New Revision: 166799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166799
Log:
2010-11-16 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
--- Comment #31 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-16
14:39:50 UTC ---
(In reply to comment #29)
I intended to work on this for GCC 4.6. There are many vectorizer failures
with the v3 patch. My local copy of the patch is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-16
14:44:56 UTC ---
The question is whether the warning should be only printed if the problem
definitely occurs or only if it likely
WRITE (*,'(f12.10)') 1.e0 ! prints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332
--- Comment #17 from Ian Lance Taylor ian at airs dot com 2010-11-16 14:51:44
UTC ---
I have added this patch to the binutils 2.21 release branch, so it will be in
the GNU binutils 2.21 release.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498
Summary: [4.5/4.6 Regression] ICE: in
eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112
with -O -funsafe-math-optimizations
-fno-tree-dominator-opts -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
Dave Korn davek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339
--- Comment #18 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com 2010-11-16 15:04:39 UTC ---
Dear Tobias,
If my understanding is correct, we can either try to extend the 'span' hack to
make it work for more cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46304
--- Comment #8 from Andras Pataki apataki at apataki dot net 2010-11-16
15:11:04 UTC ---
I can confirm that my test case now compiles and runs correctly with the
20101113 snapshot of the 4.6 compiler.
However, I've noticed another strangeness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46499
Summary: gcc.c-torture/execute/20051021-1.c FAILs with
-fno-tree-dominator-opts -fno-tree-ccp
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46499
--- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-11-16 15:45:09
UTC ---
Created attachment 22423
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22423
testcase causing RTL check ICE
While reducing the testcase, I got to this,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46499
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46500
Summary: target.h includes tm.h
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44762
--- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org
2010-11-16 16:12:19 UTC ---
Author: amylaar
Date: Tue Nov 16 16:12:14 2010
New Revision: 166807
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166807
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501
Summary: Relocatable toolchains still search --prefix
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
Dave Korn davek at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502
Summary: collect2 LTO marker detection is fragile wrt. to nm
output format
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46503
Summary: collect2's search for nm makes LTO support fragile
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #2 from Lance Kinley lk0946 at att dot com 2010-11-16 16:37:20
UTC ---
Adding -fno-delayed-branch does not resolve the issue.
I don't know which function is the culprit. I'll try to dig into it more.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #3 from Lance Kinley lk0946 at att dot com 2010-11-16 16:48:11
UTC ---
My apologies, -O -fno-delayed-branch does fix it.
-O3 -fno-delayed-branch does not work, however.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46470
Richard Henderson rth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46490
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Component|ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086
--- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-16
17:16:11 UTC ---
configure:3658: checking for C compiler default output file name
configure:3680: /usr/ports/lang/gcc45/work/build/./gcc/xgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
CC||ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46504
Summary: LTO failed on 483.xalancbmk in SPEC CPU 2006
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46505
Summary: LTO miscompiled 416.gamess in SPEC CPU 2006
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506
Summary: LTO miscompiled 465.tonto in SPEC CPU 2006
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501
--- Comment #2 from nightstrike nightstrike at gmail dot com 2010-11-16
17:48:32 UTC ---
Configure:
../../../build/gcc/src/configure \
--target=i686-w64-mingw32 \
\
--prefix=/buildbot/mingw-w64/linux-x86_64-x86/build/build/root \
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11137
--- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-11-16
17:56:57 UTC ---
Author: hjl
Date: Tue Nov 16 17:56:50 2010
New Revision: 166810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166810
Log:
Properly demangle a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42670
--- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-11-16
17:56:56 UTC ---
Author: hjl
Date: Tue Nov 16 17:56:50 2010
New Revision: 166810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166810
Log:
Properly demangle a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
Summary: std::tuple missed optimization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo:
1 - 100 of 174 matches
Mail list logo
