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
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 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
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 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 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 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 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
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 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
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
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
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
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
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 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
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 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
> 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 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
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
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 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
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 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
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/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.
>>
>
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 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
29 matches
Mail list logo
