On Fri, 5 Oct 2012, Joe Buck wrote:
> structure. The types of the pointers tell me the required alignment.
> If there is language in the standard indicating otherwise then the
> standard is defective, because it prevents an obvious optimization.
In the standard, given a sequence of pointer conve
On Thu, Oct 4, 2012 at 7:44 PM, Joe Buck wrote:
> > Perhaps I'm missing something. While memcpy is not permitted to assume
> > alignment of its arguments, copy is. Otherwise, if I wrote
> >
> > void copy(struct foo* f0, struct foo* f1)
> > {
> > *f0 = *f1;
> > }
> >
> > the compiler would a
On 10/04/2012 07:06 AM, Georg-Johann Lay wrote:
> Senthil Kumar Selvaraj wrote:
>> Some tests in gcc/testsuite/gcc.target/avr/torture (builtins-2.c, for
>> e.g.) have -Tavr51-flash1.x specified in dg-options. The tests currently
>> fail with an unable to open linker script error for that file.
>>
>
Snapshot gcc-4.6-20121005 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121005/
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 10/05/2012 04:20 PM, Xinliang David Li wrote:
So init () will be unconditionally called on entry to the wrapper?
In that case, you should probably go to the other extreme -- mark the
wrapper as noinline and expanded as if they are builtins -- but run
into the tricky issues of 'attributes' as
On Fri, Oct 5, 2012 at 1:12 PM, Jason Merrill wrote:
> On 10/05/2012 03:46 PM, Xinliang David Li wrote:
>>
>> 1) As mentioned in this thread -- when the wrapper is inlined, the
>> pure attribute will be lost. It will give compiler hard time to
>> optimize away the guard code
>
>
> The wrapper does
On 10/05/2012 03:46 PM, Xinliang David Li wrote:
1) As mentioned in this thread -- when the wrapper is inlined, the
pure attribute will be lost. It will give compiler hard time to
optimize away the guard code
The wrapper doesn't actually check the guard; that happens in the init
function, whic
The semantics of the 'first' reference of the TLS variable has
changed, and this change is introduced by the implementation. It is no
longer safe to do DCE as
thread_local int x = ..;
int foo()
{
x;
...
}
but should be safe to do DSE as
int foo()
{
x = ...; // Dead
x = ...;
..
}
On Fri, Oct 5, 2012 at 9:53 PM, Ian Lance Taylor wrote:
> On Fri, Oct 5, 2012 at 10:45 AM, Simon Baldwin wrote:
>>
>> I've looked at fortran/module.c and at libgomp/omp_lib.mod, and this
>> is not a bug.
>
> This isn't particularly helpful, but, based on the rest of your
> description, this is a
On Fri, Oct 5, 2012 at 10:45 AM, Simon Baldwin wrote:
>
> I've looked at fortran/module.c and at libgomp/omp_lib.mod, and this
> is not a bug.
This isn't particularly helpful, but, based on the rest of your
description, this is a bug. The compiler should never depend on the
order of pointer valu
> Why do you need to change varasm.c at all? The hunks seem to be
> completely separate of the attribute.
Because static constructors have fields in the original order, not the
reversed order. Otherwise code like this is miscompiled:
struct foo a = { 1, 2, 3 };
because the 1, 2, 3 are in the
On Oct 5, 2012 5:09 PM, "_" wrote:
>
> Hi Guys
>
> By proposing switch I think no c++ standard is threatened. We allready
> have switch for unsigned char etc.
>
> Looking at most of effort being pushed to STL and all kinds of
> smart-pointer templates to produce more resilient code.
> I think C/ke
I'm seeing an element of "instability" in files written by f951.
About one time in some tens or even hundreds of builds done with a
tight loop, the file libgomp/omp_lib.mod has a different checksum from
others.
This is slightly problematic because it means that binary
distributions of gcc can't be
On 10/05/2012 04:46 AM, Richard Guenther wrote:
Ok, so then let me make another example to try breaking a valid program
with the thread_local wrapper being pure:
There is also my example earlier in the thread.
i;
if (init_count != 1)
__builtin_abort ();
is that valid?
I believe
It would be nice to have a complete tsan/asan implementation for 4.8
-- IMHO it is one of the major missing (popular) features in gcc, so
the earlier gcc has it the better.
Killing mudlap is a completely different goal which does not have to
be tied to this release.
The question is that since asa
On Fri, Oct 5, 2012 at 9:08 AM, _ wrote:
>
> I thing it would be best to implement it as compiller switch -fsmart-pointers
> not requiring scope object and derive statement for objects. ie we
> need equal flexibility and freedom like have today with static objects
Experience shows us that program
Hi Guys
By proposing switch I think no c++ standard is threatened. We allready
have switch for unsigned char etc.
Looking at most of effort being pushed to STL and all kinds of
smart-pointer templates to produce more resilient code.
I think C/kernel developers deserve some love too.
I strongly be
Diego Novillo writes:
> On 2012-10-02 05:45 , Richard Guenther wrote:
>
>> Anybody else with things they want to merge during stage1?
> Finally, I've been thinking of porting asan/tsan to replace
> mudflap. Dodji, you expressed interest in it recently.
Yes I did. A bit too recently, I am afrai
On Fri, Oct 5, 2012 at 2:36 PM, Ilya Enkovich wrote:
> 2012/10/5 Richard Guenther :
>> On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich
>> wrote:
>>> 2012/10/4 Richard Guenther :
On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich
wrote:
> Hi,
>
> I fall into ssa verification fai
On Fri, Oct 5, 2012 at 2:37 AM, Richard Guenther
wrote:
>
> So I take it that libbacktrace doesn't work with the separate DWARF
> debuginfo as shipped by all Linux distributions either?
That does not work at present. I doubt it's difficult.
Ian
2012/10/5 Richard Guenther :
> On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich wrote:
>> 2012/10/4 Richard Guenther :
>>> On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich
>>> wrote:
Hi,
I fall into ssa verification failure when try to pass field's
DECL_SIZE as an operand for CALL
On Oct 5, 2012, at 11:37 AM, Richard Guenther wrote:
> On Fri, Oct 5, 2012 at 9:15 AM, Tristan Gingold wrote:
>>
>> On Oct 4, 2012, at 11:23 PM, Ian Lance Taylor wrote:
>>
>>> On Thu, Oct 4, 2012 at 1:32 PM, Jack Howarth
>>> wrote:
Is libbacktrace currently functional in gcc trunk and
On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich wrote:
> 2012/10/4 Richard Guenther :
>> On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich wrote:
>>> Hi,
>>>
>>> I fall into ssa verification failure when try to pass field's
>>> DECL_SIZE as an operand for CALL_EXPR. The fail occurs if field's size
>>>
On Fri, Oct 5, 2012 at 9:15 AM, Tristan Gingold wrote:
>
> On Oct 4, 2012, at 11:23 PM, Ian Lance Taylor wrote:
>
>> On Thu, Oct 4, 2012 at 1:32 PM, Jack Howarth
>> wrote:
>>> Is libbacktrace currently functional in gcc trunk and is it expected
>>> to function on darwin? While I could understa
On Thu, Oct 4, 2012 at 8:38 PM, DJ Delorie wrote:
>
>> ChangeLog missing, new functions need a toplevel comment documenting
>> function, argument and return value as per coding conventions.
>
> Any review of the patch itself? I know the overhead is not there...
Why do you need to change varasm.c
On Thu, Oct 4, 2012 at 8:02 PM, Jason Merrill wrote:
> On 10/04/2012 01:42 PM, Richard Guenther wrote:
>>
>> So I suppose the testcase that would be "valid" but break with using
>> pure would be instead
>>
>> int main()
>> {
>>int x = init_count;
>>int *p = get_me();
>>if (init_count =
On Thu, Oct 4, 2012 at 7:44 PM, Joe Buck wrote:
>
> On Tue, Oct 2, 2012 at 4:19 PM, Walter Lee wrote:
>> > On TILE-Gx, I'm observing a degradation in inlined memcpy/memset in
>> > gcc 4.6 and later versus gcc 4.4. Though I find the problem on
>> > TILE-Gx, I think this is a problem for any archi
2012/10/4 Richard Guenther :
> On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich wrote:
>> Hi,
>>
>> I fall into ssa verification failure when try to pass field's
>> DECL_SIZE as an operand for CALL_EXPR. The fail occurs if field's size
>> is not a constant. In such case DECL_SIZE holds a VAR_DECL and
On Oct 4, 2012, at 11:23 PM, Ian Lance Taylor wrote:
> On Thu, Oct 4, 2012 at 1:32 PM, Jack Howarth wrote:
>> Is libbacktrace currently functional in gcc trunk and is it expected
>> to function on darwin? While I could understand it not working on installed
>> binaries of FSF gcc that were str
29 matches
Mail list logo
