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
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
<...>/gcc/testsuite/g++.dg/pph/x5dynarray3.h:5:<...>/libstdc++-v3/libsupc++/excepti
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: bits/atomic_lockfree_d
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)
>
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
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
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
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 obviou
Denis Chertykov wrote:
> 2011/11/29 Georg-Johann Lay :
>> Ian Lance Taylor wrote:
>>> Georg-Johann Lay 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 way.
Paul Koning 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 accident rather th
>
> -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:5
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> "Joseph S. Myers" 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
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
jos...@cod
Hi,
"Joseph S. Myers" 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 could do
static boun
On Fri, Dec 2, 2011 at 9:26 AM, Dave Korn 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 reflects the SFRs bit(
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) b
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 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 ca
On 02/12/2011 13:59, Andrew Haley wrote:
On Fri, Dec 2, 2011 at 5:46 AM, 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 thi
On Fri, Dec 2, 2011 at 1:59 PM, Andrew Haley wrote:
> On Fri, Dec 2, 2011 at 5:46 AM, 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
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
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 a écrit :
> Hello,
>
> I suspect a regression in uninitialized value detection, but before opening
> a bug I request your advices on the following
On Fri, Dec 2, 2011 at 5:46 AM, 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 o
On Fri, Dec 2, 2011 at 1:14 PM, Peter Bigot wrote:
> On Fri, Dec 2, 2011 at 5:46 AM, 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
On Fri, Dec 2, 2011 at 5:46 AM, 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 most pas
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.
...
>> 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 repo
[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, th
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
#include
int main( int argc, char **argv )
{
int j;
int
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 wa
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 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 function
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 gues
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) (c
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
>
35 matches
Mail list logo
