Hi,
I'm looking at a missed optimizations in combine and it is similar to the one
you've fixed in PR18942
(http://thread.gmane.org/gmane.comp.gcc.patches/81504).
I'm trying to make GCC optimize
(leu:SI
(plus:SI (reg:SI) (const_int -1))
(const_int 1))
into
(leu:SI
(reg:SI)
On Fri, Dec 02, 2011 at 03:33:06PM +1300, Maxim Kuvyrkov wrote:
I'm looking at a missed optimizations in combine and it is similar to the
one you've fixed in PR18942
(http://thread.gmane.org/gmane.comp.gcc.patches/81504).
I'm trying to make GCC optimize
(leu:SI
(plus:SI (reg:SI)
On Wed, Nov 30, 2011 at 02:54:26PM -0700, Tom Tromey wrote:
One idea that came up was to redeclare the FE-specific functions as
'weak', then check to see if they are available at runtime before
calling them. It seems like a pain to me, since you have to rewrite the
declarations, but I guess
On Tue, Nov 29, 2011 at 03:53:50PM -0800, Han Shen(沈涵) wrote:
Hi, I propose to add to gcc a new option regarding stack protector -
-fstack-protector-strong, in addition to current gcc's
-fstack-protector-all, which protects ALL functions, and
-fstack-protector, which protects functions that
On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay a...@gjlay.de wrote:
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
If general_operand can be perceived as
(define_predicate general_operand
(ior (match_operand 0 memory_operand)
(match_operand 0 register_operand)
Hello,
Parameters that have an array type (fixed-length or variable-length) are
internally converted to have a pointer type instead (this is with 4.6.)
For example:
static int
bar (int foo[12])
{
return foo[2];
}
is turned into:
bar (unsigned int x, int * foo)
...
Is there a
Hello,
I suspect a regression in uninitialized value detection, but before
opening a bug I request your advices on the following problem:
I build the following code :
#include stdio.h
#include stdlib.h
int main( int argc, char **argv )
{
[I am not on this list, so please cc me.]
On the link below it says that Bronek Kozicki has been working on C++ rvalue
references for *this. What is the progress of this feature?
I am on OS X 10.7.2, and GCC 4.6.2 compiled. Clang 3.0 has this feature, but
not others, like lambda expressions,
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens that GCC doesn't
do this kind of things then this is only because most passes
don't thouch volatile stmts at all (thus the reports
On 12/02/2011 11:17 AM, Hans Aberg wrote:
[I am not on this list, so please cc me.]
On the link below it says that Bronek Kozicki has been working on C++ rvalue
references for *this. What is the progress of this feature?
Let's ask him, seems the obvious thing to do.
Paolo.
On Fri, Dec 2, 2011 at 5:46 AM, paul_kon...@dell.com wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens that GCC doesn't
do this kind of things then this is only because
On Fri, Dec 2, 2011 at 1:14 PM, Peter Bigot big...@acm.org wrote:
On Fri, Dec 2, 2011 at 5:46 AM, paul_kon...@dell.com wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens
On Fri, Dec 2, 2011 at 5:46 AM, paul_kon...@dell.com wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens that GCC doesn't
do this kind of things then this is only
Sorry for the noise, the problem is already tracked here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Le 2 décembre 2011 10:42, Patrice Bouchand pbfwdl...@gmail.com a écrit :
Hello,
I suspect a regression in uninitialized value detection, but before opening
a bug I request your advices
Richard Guenther wrote:
On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay wrote:
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
If general_operand can be perceived as
(define_predicate general_operand
(ior (match_operand 0 memory_operand)
(match_operand 0 register_operand)
On Fri, Dec 2, 2011 at 1:59 PM, Andrew Haley a...@redhat.com wrote:
On Fri, Dec 2, 2011 at 5:46 AM, paul_kon...@dell.com wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it
On 02/12/2011 13:59, Andrew Haley wrote:
On Fri, Dec 2, 2011 at 5:46 AM,paul_kon...@dell.com wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens that GCC doesn't
do this
On 01/12/2011 21:40, Georg-Johann Lay wrote:
It's not unusual because:
* It's not unusual to write down SFRs as violatile memory like
(*((volatile unsigned int*) 0x1234)) or as a cast to a composite
that reflects the SFRs bit(field)s.
* It's not unusual that microcontrollers can
Hello All,
It is my pleasure to announce the MELT plugin 0.9.2 release candidate 1
December XXth, 2011: Release of MELT plugin 0.9.2 for gcc-4.6 ( future gcc-4.7)
dedicated to the memory of John McCarthy
http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)
MELT is a
On Fri, 2 Dec 2011, Ludovic Court�s wrote:
Is there a way array dimension info could be preserved?
Perhaps you could explain the actual problem you are trying to solve? The
value of such a dimension is specified in the C standard to be checked for
constraint violations (such as being = 0)
On Fri, Dec 2, 2011 at 9:26 AM, Dave Korn dave.korn.cyg...@gmail.com wrote:
On 01/12/2011 21:40, Georg-Johann Lay wrote:
It's not unusual because:
* It's not unusual to write down SFRs as violatile memory like
(*((volatile unsigned int*) 0x1234)) or as a cast to a composite
that
Hi,
Joseph S. Myers jos...@codesourcery.com skribis:
On Fri, 2 Dec 2011, Ludovic Courtès wrote:
Is there a way array dimension info could be preserved?
Perhaps you could explain the actual problem you are trying to solve?
I’m just thinking that, if that information were preserved, GCC
On Fri, 2 Dec 2011, Ludovic Court�s wrote:
I'm just thinking that, if that information were preserved, GCC could do
static bound checking and/or generate bound checking code.
As I noted, that would be contrary to the language semantics unless
[static] is used.
--
Joseph S. Myers
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
Joseph S. Myers jos...@codesourcery.com skribis:
On Fri, 2 Dec 2011, Ludovic Courtès wrote:
Is there a way array dimension info could be preserved?
Perhaps you could explain the actual problem you are trying to solve?
I’m just thinking
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Richard Guenther
Sent: Friday, December 02, 2011 9:35 AM
To: Andrew Haley
Cc: gcc@gcc.gnu.org
Subject: Re: volatile correctness: combine vs. target.md
On Fri, Dec 2, 2011 at 1:59 PM,
Paul Koning paulkon...@comcast.net writes:
I see. As we do not explicitely model this dependency we probably get lucky
by the if (gimple_has_volatile_ops ()) bail-out; most passes do.
That sounds scary, if I understood you correctly. It sounds like GCC
conforms to the standard only by
Denis Chertykov wrote:
2011/11/29 Georg-Johann Lay a...@gjlay.de:
Ian Lance Taylor wrote:
Georg-Johann Lay a...@gjlay.de writes:
So if a frontend can define address spaces and it is a generic feature, the
question is how to get the name of an address space in a generic, language
independent
On 02/12/2011 12:11, Paolo Carlini wrote:
On 12/02/2011 11:17 AM, Hans Aberg wrote:
[I am not on this list, so please cc me.]
On the link below it says that Bronek Kozicki has been working on C++
rvalue references for *this. What is the progress of this feature?
Let's ask him, seems the
On 2 Dec 2011, at 19:54, Bronek Kozicki wrote:
On 02/12/2011 12:11, Paolo Carlini wrote:
On 12/02/2011 11:17 AM, Hans Aberg wrote:
[I am not on this list, so please cc me.]
On the link below it says that Bronek Kozicki has been working on C++
rvalue references for *this. What is the
Hi, Jakub, thanks!
The thing is that ssp-buffer-size controls array-size limit, but we
also want to protect attacks via struct/union, and other frame address
casting. One of the places I've wanted to have stack protector was in
routines that fill a structure from some binary input stream. In most
Snapshot gcc-4.6-20111202 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20111202/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 12/02/2011 06:35 AM, Richard Guenther wrote:
I see. As we do not explicitely model this dependency we probably
get lucky by the if (gimple_has_volatile_ops ()) bail-out; most
passes do.
What are you talking about? Of course we do.
int
read_dependence (const_rtx mem, const_rtx x)
{
I just merged from trunk and several of my C++ tests are failing with
the error:
In file included from .../libstdc++-v3/libsupc++/new:42:0,
from
.../gcc/testsuite/g++.dg/pph/x5dynarray3.h:5:.../libstdc++-v3/libsupc++/exception:40:42:
fatal error:
On 12/02/2011 06:59 PM, Diego Novillo wrote:
I just merged from trunk and several of my C++ tests are failing with
the error:
In file included from .../libstdc++-v3/libsupc++/new:42:0,
from
On 2/12/2011, at 9:45 PM, Jakub Jelinek wrote:
On Fri, Dec 02, 2011 at 03:33:06PM +1300, Maxim Kuvyrkov wrote:
I'm looking at a missed optimizations in combine and it is similar to the
one you've fixed in PR18942
(http://thread.gmane.org/gmane.comp.gcc.patches/81504).
I'm trying to make
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #20 from rguenther at suse dot de rguenther at suse dot de
2011-12-02 09:49:39 UTC ---
On Thu, 1 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
Eric Botcazou ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
--- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-02
09:52:27 UTC ---
Probably a better place than phi-opt would be RTL expansion (thus, out-of-SSA
for the PHI nodes) where based on target cost those constants could be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-02
10:12:26 UTC ---
Francois, please take a look asap.
Hans-Peter, can it be a memory issue? The recent changes imply that more memory
is used by these data structures,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382
--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-02
10:13:02 UTC ---
Sure, agreed on that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51180
--- Comment #4 from dodji at seketeli dot org dodji at seketeli dot org
2011-12-02 10:15:06 UTC ---
jason at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org a écrit:
I'm surprised that it doesn't just work already; writing t2B... already
works, doing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-02
10:36:14 UTC ---
Here's a version which isn't a compile-time-hog but demonstrates the
unnecessary instantiation with a static_assert (so needs -std=c++11)
template unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-02
10:47:45 UTC ---
Interestingly G++ is happy to not instantiate the template when it's not
possible to, i.e. making this change and defining -DINCOMPLETE allows it to
compile:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
Dodji Seketeli dodji at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #21 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-02
10:54:45 UTC ---
If the expressions only become invariant after unrolling then the issue
is that without CCP LIM does not see they are invariant I suppose.
No, adding a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51375
--- Comment #2 from pjodrr at gmail dot com 2011-12-02 11:01:31 UTC ---
... and also with 4.7-2026
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386
--- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-12-02
11:07:20 UTC ---
(In reply to comment #1)
Hans-Peter, can it be a memory issue? The recent changes imply that more
memory
is used by these data structures, and that is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-02
11:10:36 UTC ---
(In reply to comment #3)
(In reply to comment #1)
Hans-Peter, can it be a memory issue? The recent changes imply that more
memory
is used by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-02
11:12:20 UTC ---
Note the huge slow down is entirely in the third block, for
max_load_factor(.3), we must do something about it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386
--- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-12-02
11:15:54 UTC ---
(In reply to comment #3)
(My reply probably seems slightly odd due to the mid-air collision with comment
#2.)
Oh, I see floating-point changes, has the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51387
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #22 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-02
11:50:39 UTC ---
One thing I notice (and that's the only difference I can spot at the tree
level) is that we do not CSE the **2s of
a = sqrt((rect_inductor%v2%x -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51371
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622
--- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2011-12-02
12:53:06 UTC ---
Author: jamborm
Date: Fri Dec 2 12:53:03 2011
New Revision: 181908
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181908
Log:
2011-12-02 Martin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31709
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #51 from Michael Matz matz at gcc dot gnu.org 2011-12-02 13:23:57
UTC ---
Nope, I don't have more than a couple hacks to try different approaches
as of right now. I should dust them off for next stage1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
Bug #: 51388
Summary: Configure failure to detect unsupported warning
options for non-bootstrap builds (including cross
builds)
Classification: Unclassified
Product:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51389
Bug #: 51389
Summary: GCC uses up to 75GB of virtual memory
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #24 from rguenther at suse dot de rguenther at suse dot de
2011-12-02 14:31:27 UTC ---
On Fri, 2 Dec 2011, burnus at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
Tobias Burnus burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC|bur...@net-b.de |dominiq at lps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-02
14:52:49 UTC ---
Since 4.4.0 we no longer warn for unrecognized -Wno- forms, thus the configure
check is broken as-is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51381
--- Comment #7 from eric.valette at free dot fr 2011-12-02 14:58:49 UTC ---
The line given in the error correspond to a gcc_unreachable call in the
fp_immediate_constant (rtx x) function???
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #3 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com
2011-12-02 14:59:37 UTC ---
On Fri, Dec 2, 2011 at 3:51 PM, rguenth at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
I see
gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #26 from rguenther at suse dot de rguenther at suse dot de
2011-12-02 15:02:27 UTC ---
On Fri, 2 Dec 2011, burnus at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
Tobias Burnus burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-02
15:49:41 UTC ---
Author: rguenth
Date: Fri Dec 2 15:49:37 2011
New Revision: 181927
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181927
Log:
2011-12-02 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #27 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-02
16:02:45 UTC ---
(In reply to comment #26)
The trivial example is (x + 2**52) - 2**52 which rounds x to
an integer. Without parens we optimize away that rounding effect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51344
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-12-02 16:09:57 UTC ---
On Fri, 2 Dec 2011, rguenth at gcc dot gnu.org wrote:
Still the behavior of warning for -Wno- changed appearantly. Joseph?
The idea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
Jack Howarth howarth at nitro dot med.uc.edu changed:
What|Removed |Added
CC||howarth at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #29 from rguenther at suse dot de rguenther at suse dot de
2011-12-02 16:13:25 UTC ---
On Fri, 2 Dec 2011, burnus at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #27 from Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-02
16:20:56 UTC ---
(In reply to comment #3)
On Fri, Dec 2, 2011 at 3:51 PM, rguenth at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
I see
gcc-4.3 -c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48887
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51313
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #30 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-02
16:29:46 UTC ---
(In reply to comment #29)
And for the sake of completeness the evaluation of sub above and
x = (x + 2.d0**52) - 2.d0**52
should behave consistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #31 from rguenther at suse dot de rguenther at suse dot de
2011-12-02 16:32:52 UTC ---
On Fri, 2 Dec 2011, burnus at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #30 from Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #32 from Dominique d'Humieres dominiq at lps dot ens.fr
2011-12-02 16:37:37 UTC ---
And for the sake of completeness the evaluation of sub above and
subroutine sub2(x)
real*8 x
x = (x + 2.d0**52) - 2.d0**52
end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #33 from Dominique d'Humieres dominiq at lps dot ens.fr
2011-12-02 16:45:24 UTC ---
The failing polyhedron 2005 benchmark is linpk which can be seen with -Ofast
on
x86_64-apple-darwin11...
Value= 25.114499300 Target=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2011-12-02
16:48:45 UTC ---
(In reply to comment #1)
Now, the question is why we don't consistently error in 4.3 ...
I see
gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG
cc1: error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37782
--- Comment #13 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-12-02
16:54:33 UTC ---
Author: jsm28
Date: Fri Dec 2 16:54:27 2011
New Revision: 181929
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181929
Log:
Revert:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451
--- Comment #7 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-12-02
16:54:33 UTC ---
Author: jsm28
Date: Fri Dec 2 16:54:27 2011
New Revision: 181929
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181929
Log:
Revert:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-12-02
16:59:30 UTC ---
(In reply to comment #5)
On Fri, 2 Dec 2011, rguenth at gcc dot gnu.org wrote:
Still the behavior of warning for -Wno- changed appearantly. Joseph?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #34 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-02
17:06:57 UTC ---
(In reply to comment #31)
Ok, which is, I suppose, a bug in both compilers.
Kind of, though, -ffast-math by itself already is on the verge of violating the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390
Bug #: 51390
Summary: Builtin changes on November 29th, broke recip-5.c
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390
--- Comment #1 from Michael Meissner meissner at gcc dot gnu.org 2011-12-02
17:18:55 UTC ---
Author: meissner
Date: Fri Dec 2 17:18:51 2011
New Revision: 181930
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181930
Log:
PR 51390
Modified:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51313
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-02
17:23:24 UTC ---
This badly requires a reduced testcase, I'm going to prepare one. Then the fix
should be pretty simple: just use STRIP_NOPs unconditionally, ie cxx0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390
--- Comment #2 from Michael Meissner meissner at gcc dot gnu.org 2011-12-02
17:26:06 UTC ---
Created attachment 25972
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25972
Patch to fix the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390
Michael Meissner meissner at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51313
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.7.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51344
--- Comment #3 from Nickolay Cherney koliasvskj at gmail dot com 2011-12-02
18:58:05 UTC ---
(In reply to comment #2)
But apparently this issue is very old, I can reproduce with 4.3.x too! Out of
curiosity, which release series worked for you?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-02
19:14:20 UTC ---
Author: gjl
Date: Fri Dec 2 19:14:15 2011
New Revision: 181936
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181936
Log:
PR target/51002
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-02
19:14:20 UTC ---
Author: gjl
Date: Fri Dec 2 19:14:15 2011
New Revision: 181936
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181936
Log:
PR target/51002
PR
1 - 100 of 215 matches
Mail list logo
