Re: libbacktrace and darwin
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 stripped, I would think it should work for >> make check in the build tree since all of the debug code should be present >> in the object files. Or doesn't libbacktrace know to look there for the >> dwarf code? Thanks in advance for any clarifications. > > libbacktrace is functional in GCC trunk. However, it does not yet > support the Mach-O object file format. I hope to work on that at some > point, but it would be great if somebody else tackled it. It's > probably straightforward to implement based on code in > libiberty/simple-object-mach-o.c. I doubt it will, as dwarf info aren't in the executable. I think it will be simpler to support .dsym (separate debug file) at first. Tristan.
Re: Variable DECL_SIZE
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 I need >> to find it's proper SSA_NAME. I thought it may be the default one but >> gimple_default_def returns NULL. What is the right way to obtain >> correct ssa_name in such case? > > There is no way. You have to know that you need it's size at the point of > gimplification. Later there is no way to recover it. Wow. It means I cannot also get an address of subsequent fields in the structure. It looks weird. Is there a way to somehow preserve this information during gimplification and use in later passes? Ilya > > Richard. > >> >> Thanks, >> Ilya
Re: inlined memcpy/memset degradation in gcc 4.6 or later
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 architectures with
>> > SLOW_UNALIGNED_ACCESS set to 1.
>> >
>> > Consider the following program:
>> >
>> > struct foo {
>> > int x;
>> > };
>> >
>> > void copy(struct foo* f0, struct foo* f1)
>> > {
>> > memcpy (f0, f1, sizeof(struct foo));
>> > }
>> >
>> > In gcc 4.4, I get the desired inline memcpy: ...
>> > In gcc 4.7, however, I get inlined byte-by-byte copies: ...
>
> On Thu, Oct 04, 2012 at 01:58:54PM +0200, Richard Guenther wrote:
>> There is no way to fix it. memcpy does not require aligned arguments
>> and the merely presence of a typed pointer contains zero information
>> of alignment for the middle-end. If you want to excercise C's notion
>> of alignemnt requirements then do not use memcpy but
>>
>> *f0 = *f1;
>>
>> which works equally well.
>
> 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 also be forbidden from assuming any alignment. So,
> when compiling "copy", do we lack the information that the memcpy call is
> to the standard ISO memcpy function? If we know that it is the standard
> function we should be able to do the copy assuming everything is properly
> aligned.
If we see the above aggregate copy then we should be able to compile
the function assuming that f0 and f1 are properly aligned for type struct foo.
If we see C source code using memcpy (f0, f1, sizeof (struct foo)) then
we cannot assume anything about the alignment of f0 or f1 based on the
fact that the code uses the ISO memcpy function.
Thus, I do not understand your question. When we compile "copy" how
is memcpy relevant?
Richard.
>
>
>> Btw, the new beavior even fixed bugs.
>
> Could you point to a PR that was fixed by the change? There must be some
> way to distinguish this case from those cases.
Re: Functions that are CSEable but not pure
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 == x)
>> __builtin_abort();
>>int *q = get_me();
>>if (init_count == x)
>> __builtin_abort();
>> }
>>
>> here when get_me is pure we CSE init_count over the _first_ call of
>> get_me.
>
>
> That's OK for C++ thread_local semantics; the initialization is specified to
> happen some time before the first use, so the testcase is making an invalid
> assumption. This might not be desirable for user-written singleton
> functions, though.
Ok, so then let me make another example to try breaking a valid program
with the thread_local wrapper being pure:
int main()
{
int &p = get_me();
*p;
if (init_count == 1)
__builtin_abort();
}
note my using of C++ references (which in this case cannot bind to NULL
and thus *p might not trap(?)). So the C++ source would be something like
thread_local int init_count;
int foo () { init_count = 1; return 0; }
thread_local int i = foo ();
int main()
{
i;
if (init_count != 1)
__builtin_abort ();
}
is that valid? When lowered to the above we would DCE the load of i
and the call to the initialization wrapper (because it is pure). Obviously
then init_count is no longer 1.
Thus my question is - is a valid program allowed to access side-effects
of the dynamic TLS initializer by not going through the TLS variable?
I realize that's somewhat ill-formed if the TLS variable was a class with
a static method doing the access to init_count - using that method
would not keep the class instance life.
Preventing DCE but not CSE for const/pure functions can be for
example done by using the looping-const-or-pure flag (but that
also tells the compiler that this function may not return, so it is
very specific about the kind of possible side-effect to be preserved).
The very specific nature of thread_local TLS init semantics
('somewhen before') is hard to make use of, so if we want to
change looping-const-or-pure to something like const-or-pure-with-side-effects
we should constrain things more.
Richard.
> Jason
>
Re: reverse bitfield patch
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 at all? The hunks seem to be
completely separate of the attribute.
I don't like that you post-process the layout. How does reversal
inter-operate with all the other features we have, like strict volatile
bitfields? I for example see
+ /* If the bitfield-order attribute has been used on this
+structure, the fields might not be in bit-order. In that
+case, we need a separate representative for each
+field. */
+ else if (DECL_FIELD_OFFSET (field) < DECL_FIELD_OFFSET (repr)
+ || (DECL_FIELD_OFFSET (field) == DECL_FIELD_OFFSET (repr)
+ && DECL_FIELD_BIT_OFFSET (field) <
DECL_FIELD_BIT_OFFSET (repr)))
+ {
+ finish_bitfield_representative (repr, prev);
+ repr = start_bitfield_representative (field);
+ }
which will severely pessimize bitfield accesses to structs with the
bitfield-order attribute.
+
+ type_attr_list = tree_cons (get_identifier ("bit_order"),
+ build_tree_list (NULL_TREE,
get_identifier (bit_order)),
+ type_attr_list);
+
+ TYPE_ATTRIBUTES (node) = type_attr_list;
+}
+
+void
+rx_note_pragma_bitorder (char *mode)
+{
+ if (mode == NULL)
so you are supporting this as #pragma. Which ends up tacking bit_order
to each type. Rather than this, why not operate similar to the packed
pragma, thus, adjust a global variable in stor-layout.c.
+static tree
+handle_bitorder_attribute (tree *ARG_UNUSED (node), tree ARG_UNUSED (name),
+ tree ARG_UNUSED (args),
+ int ARG_UNUSED (flags), bool *no_add_attrs)
+{
+ tree bmode;
+ const char *bname;
+
+ /* Allow no arguments to mean "native". */
+ if (args == NULL_TREE)
+return NULL_TREE;
+
+ bmode = TREE_VALUE (args);
+
+ bname = IDENTIFIER_POINTER (bmode);
+ if (strcmp (bname, "msb")
+ && strcmp (bname, "lsb")
+ && strcmp (bname, "swapped")
+ && strcmp (bname, "native"))
+{
+ error ("%qE is not a valid bit_order - use lsb, msb, native, or
swapped", bmode);
+ *no_add_attrs = true;
+}
+
+ return NULL_TREE;
I don't see a value in attaching 'native' or 'msb'/'lsb' if it is
equal to 'native'. You
un-necessarily pessimize code generation (is different code even desired
for a "no-op" bit_order attribute?).
So no, I don't like this post-process layouting thing. It's a layouting mode
so it should have effects at bitfield layout time.
Richard.
Re: libbacktrace and darwin
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 understand it not working on installed >>> binaries of FSF gcc that were stripped, I would think it should work for >>> make check in the build tree since all of the debug code should be present >>> in the object files. Or doesn't libbacktrace know to look there for the >>> dwarf code? Thanks in advance for any clarifications. >> >> libbacktrace is functional in GCC trunk. However, it does not yet >> support the Mach-O object file format. I hope to work on that at some >> point, but it would be great if somebody else tackled it. It's >> probably straightforward to implement based on code in >> libiberty/simple-object-mach-o.c. > > I doubt it will, as dwarf info aren't in the executable. I think it will be > simpler to support .dsym (separate debug file) at first. So I take it that libbacktrace doesn't work with the separate DWARF debuginfo as shipped by all Linux distributions either? Richard. > Tristan. >
Re: Variable DECL_SIZE
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 >>> is not a constant. In such case DECL_SIZE holds a VAR_DECL and I need >>> to find it's proper SSA_NAME. I thought it may be the default one but >>> gimple_default_def returns NULL. What is the right way to obtain >>> correct ssa_name in such case? >> >> There is no way. You have to know that you need it's size at the point of >> gimplification. Later there is no way to recover it. > > Wow. It means I cannot also get an address of subsequent fields in the > structure. It looks weird. Is there a way to somehow preserve this > information during gimplification and use in later passes? By using it ;) See how gimplification of COMPONENT_REF works for example. The offset becomes an explicit operand and its computation get put into explicit statements. There is no 'reverse-mapping' to lookup or even re-construct this information at later time. Richard. > Ilya > >> >> Richard. >> >>> >>> Thanks, >>> Ilya
Re: libbacktrace and darwin
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 is it expected to function on darwin? While I could understand it not working on installed binaries of FSF gcc that were stripped, I would think it should work for make check in the build tree since all of the debug code should be present in the object files. Or doesn't libbacktrace know to look there for the dwarf code? Thanks in advance for any clarifications. >>> >>> libbacktrace is functional in GCC trunk. However, it does not yet >>> support the Mach-O object file format. I hope to work on that at some >>> point, but it would be great if somebody else tackled it. It's >>> probably straightforward to implement based on code in >>> libiberty/simple-object-mach-o.c. >> >> I doubt it will, as dwarf info aren't in the executable. I think it will be >> simpler to support .dsym (separate debug file) at first. > > So I take it that libbacktrace doesn't work with the separate DWARF > debuginfo as shipped by all Linux distributions either? I don't know, but the Mach-O mechanism to get the separate debug file is different from ELF.
Re: Variable DECL_SIZE
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_EXPR. The fail occurs if field's size
is not a constant. In such case DECL_SIZE holds a VAR_DECL and I need
to find it's proper SSA_NAME. I thought it may be the default one but
gimple_default_def returns NULL. What is the right way to obtain
correct ssa_name in such case?
>>>
>>> There is no way. You have to know that you need it's size at the point of
>>> gimplification. Later there is no way to recover it.
>>
>> Wow. It means I cannot also get an address of subsequent fields in the
>> structure. It looks weird. Is there a way to somehow preserve this
>> information during gimplification and use in later passes?
>
> By using it ;) See how gimplification of COMPONENT_REF works
> for example. The offset becomes an explicit operand and its
> computation get put into explicit statements. There is no 'reverse-mapping'
> to lookup or even re-construct this information at later time.
>
I think gimplification pass is too early for me to decide if I want to
use all these offsets and sizes.
Actually when I a look into GIMPLE dumps I see that all these values
are computed and corresponding SSA_NAMEs exist in the code.
I use the following source exapmle:
int foo(int len)
{
struct {
int a;
int buf[len];
int b;
} s;
return foo1(s.buf);
}
In GIMPLE I see a lot of values computed for all sizes, unit sizes and offsets:
saved_stack.2_1 = __builtin_stack_save ();
len.0_3 = len_2(D);
D.2241_4 = (bitsizetype) len.0_3;
D.2242_5 = D.2241_4 * 32;
D.2243_6 = (sizetype) len.0_3;
D.2244_7 = D.2243_6 * 4;
D.2245_8 = (long int) len.0_3;
D.2246_9 = D.2245_8 + -1;
D.2247_10 = (sizetype) D.2246_9;
D.2241_11 = (bitsizetype) len.0_3;
D.2242_12 = D.2241_11 * 32;
D.2243_13 = (sizetype) len.0_3;
D.2244_14 = D.2243_13 * 4;
D.2243_15 = (sizetype) len.0_3;
D.2248_16 = D.2243_15 + 1;
D.2249_17 = D.2248_16 * 4;
D.2243_18 = (sizetype) len.0_3;
D.2250_19 = D.2243_18 + 2;
D.2251_20 = D.2250_19 * 32;
D.2252_21 = D.2251_20;
...
I suppose there is always a sinle SSA_NAME for such vars and therefore
I may associate them, e.g. via default definition. The only problem
them is to not kill them until the very end. Currenty all those unused
SSA_NAMES are killed by early optimizations pass. But even on O0 now
we have all values computed and available for use until expand but
cannot access them.
Ilya
> Richard.
>
>> Ilya
>>
>>>
>>> Richard.
>>>
Thanks,
Ilya
Re: libbacktrace and darwin
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
Re: Variable DECL_SIZE
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 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 I need
> to find it's proper SSA_NAME. I thought it may be the default one but
> gimple_default_def returns NULL. What is the right way to obtain
> correct ssa_name in such case?
There is no way. You have to know that you need it's size at the point of
gimplification. Later there is no way to recover it.
>>>
>>> Wow. It means I cannot also get an address of subsequent fields in the
>>> structure. It looks weird. Is there a way to somehow preserve this
>>> information during gimplification and use in later passes?
>>
>> By using it ;) See how gimplification of COMPONENT_REF works
>> for example. The offset becomes an explicit operand and its
>> computation get put into explicit statements. There is no 'reverse-mapping'
>> to lookup or even re-construct this information at later time.
>>
> I think gimplification pass is too early for me to decide if I want to
> use all these offsets and sizes.
>
> Actually when I a look into GIMPLE dumps I see that all these values
> are computed and corresponding SSA_NAMEs exist in the code.
>
> I use the following source exapmle:
>
> int foo(int len)
> {
> struct {
> int a;
> int buf[len];
> int b;
> } s;
> return foo1(s.buf);
> }
>
> In GIMPLE I see a lot of values computed for all sizes, unit sizes and
> offsets:
>
> saved_stack.2_1 = __builtin_stack_save ();
> len.0_3 = len_2(D);
> D.2241_4 = (bitsizetype) len.0_3;
> D.2242_5 = D.2241_4 * 32;
> D.2243_6 = (sizetype) len.0_3;
> D.2244_7 = D.2243_6 * 4;
> D.2245_8 = (long int) len.0_3;
> D.2246_9 = D.2245_8 + -1;
> D.2247_10 = (sizetype) D.2246_9;
> D.2241_11 = (bitsizetype) len.0_3;
> D.2242_12 = D.2241_11 * 32;
> D.2243_13 = (sizetype) len.0_3;
> D.2244_14 = D.2243_13 * 4;
> D.2243_15 = (sizetype) len.0_3;
> D.2248_16 = D.2243_15 + 1;
> D.2249_17 = D.2248_16 * 4;
> D.2243_18 = (sizetype) len.0_3;
> D.2250_19 = D.2243_18 + 2;
> D.2251_20 = D.2250_19 * 32;
> D.2252_21 = D.2251_20;
> ...
>
> I suppose there is always a sinle SSA_NAME for such vars and therefore
> I may associate them, e.g. via default definition. The only problem
> them is to not kill them until the very end. Currenty all those unused
> SSA_NAMES are killed by early optimizations pass. But even on O0 now
> we have all values computed and available for use until expand but
> cannot access them.
But that's exactly the issue. Nothing keeps them live if they are not used.
And there is no "back-mapping" between DECL_SIZE and the SSA name
holding it's value at a certain point in the program.
Richard.
> Ilya
>
>> Richard.
>>
>>> Ilya
>>>
Richard.
>
> Thanks,
> Ilya
Experimental Address Sanitizer for 4.8 (was Re: How much time left till phase 3?)
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 afraid. :-) Jeff Law writes: > On 10/02/2012 08:30 AM, Diego Novillo wrote: >> Finally, I've been thinking of porting asan/tsan to replace mudflap. >> Dodji, you expressed interest in it recently. > That's further out most likely. Yes, I think a *final* version with feature parity with the asan/tsan of llvm is definitely for after 4.8. Though ... Jakub Jelinek writes: > I think it would be very nice to get at least asan port for 4.8, but > I guess it depends on how much work is on it. Killing mudflap would be > nice. ... I'd like to try and see if we can have something dubbed experimental with very basic functionality into 4.8 first, and then work from there toward feature parity with asan/tsan llvm. What do you think? -- Dodji
Proposing switch -fsmart-pointers
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 belive That automatic cleanup should be provided also for
dynamic data on C/C++ low level language level.
Imagine specially declared ointers being freed when leaving scope.
So normal recovery in case of exception/error without memory leaks or
double deallocations are possible without error prone duplicate
copy-paste cleanup statements.
This will result to simpler and safer but not slower code.
First current state example
void proc() {
Object* object_ptr;
// zillion error/exception handlers zillion ways to messup cleanup
}
Let smart pointer declaration be for example
type *~ variable;
void proc() {
Object*~ object_ptr;
// zillion error/exception handlers but destructor/free is
automatically called when not null and leaving scope just like with
static objects
}
Another important example
struct A {
Object*~ object_ptr;
Object*~ array[1000]; // during creation of array element [500]
exception happens yet resources are properly freed like with static
objects
}
// when stuct is destroyed all non null pointers have free called/
destructors where appropriate
Now those of you sayng that it is too complex to be done. I already
implemented it.
You can test it here.
http://www.codeproject.com/Articles/468126/new-local-for-safer-and-simpler-code-with-no-need
Unfortunately I have no idea how to do it in gcc. Is someone fluid
with gcc or it's plugins willing to hlep me ?
I would be more than thankfull.
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
What you guys think about this? I don't belive in stl solves all
especially in low level land.
Many heap spray exploits live only from improper cleanup from
complicated error handlers.
And there is really no need to have complicated and error prone code
anymore with this switch.
Regards
Ladislav Nevery [Unemployed]
Re: Proposing switch -fsmart-pointers
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 programmers want several different types of smart pointers in practice. I don't see any reason to enshrine a particular variant in the compiler. Particularly when C++ already supports smart pointers. (For example, your variant of smart pointers doesn't seem to help with pointers in struct fields, when those structs are stored in the heap.) Ian
Re: Experimental Address Sanitizer for 4.8 (was Re: How much time left till phase 3?)
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 asan/tsan is not enabled by default and its development won't destablize GCC, is it OK to allow more asan/tsan related changes to be checked in to 4.8 after stage-1 is closed. They can be considered as 'bug' fixes. thanks, David On Fri, Oct 5, 2012 at 8:59 AM, Dodji Seketeli wrote: > 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 afraid. :-) > > > Jeff Law writes: > >> On 10/02/2012 08:30 AM, Diego Novillo wrote: >>> Finally, I've been thinking of porting asan/tsan to replace mudflap. >>> Dodji, you expressed interest in it recently. >> That's further out most likely. > > Yes, I think a *final* version with feature parity with the asan/tsan of > llvm is definitely for after 4.8. Though ... > > > Jakub Jelinek writes: > >> I think it would be very nice to get at least asan port for 4.8, but >> I guess it depends on how much work is on it. Killing mudflap would be >> nice. > > ... I'd like to try and see if we can have something dubbed experimental > with very basic functionality into 4.8 first, and then work from there > toward feature parity with asan/tsan llvm. > > What do you think? > > -- > Dodji
Re: Functions that are CSEable but not pure
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 so; that is an odr-use of i, so it needs to be initialized.
Thus my question is - is a valid program allowed to access side-effects
of the dynamic TLS initializer by not going through the TLS variable?
I think so.
Preventing DCE but not CSE for const/pure functions can be for
example done by using the looping-const-or-pure flag (but that
also tells the compiler that this function may not return, so it is
very specific about the kind of possible side-effect to be preserved).
The very specific nature of thread_local TLS init semantics
('somewhen before') is hard to make use of, so if we want to
change looping-const-or-pure to something like const-or-pure-with-side-effects
we should constrain things more.
That would be fine with me.
Jason
Instability in successive builds of fortran mod files with f951
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 relied on to build bit-identically when given identical source inputs. Automated build processes that insist on full reproducibility will therefore hiccup from time to time when they run into this effect. I've looked at fortran/module.c and at libgomp/omp_lib.mod, and this is not a bug. fortran/module.c builds a tree of pointers to symbols, and then traverses that tree to serialize symbols for the module file. The tree is organized by pointer value because its function is fast pointer lookup. This means, however, that the order nodes are visited in traversal will depend on the relative values of the pointers in it. If the pointer to symbol "A" on the first run is a lower address than the pointer to symbol "B" on the first run of f951, but higher on the second run, these serialized symbols will appear in different orders in the output module files from the two runs. Neither output module file is invalid. The ordering is irrelevant. fortran/module.c clearly indicates it writes symbols in no particular order. This lack of bit-equivalence in module files across f951 invocations could be caused by instability earlier in the compiler, perhaps uninitialized memory (gcc is configured for powerpc 8540). It seems more likely though that these pointers are all allocated by malloc and malloc addresses aren't reproducible. Malloc returns pointers from regions allocated by anonymous mmap. And the kernel is under no constraint to provide "predictable" addresses for mmap (and neither is malloc, for that matter). So every now and again the pattern of allocated symbol pointers leads to a different (yet still valid) output. In a sense, looking for bit-equivalence in module files might be asking for malloc/mmap to be completely deterministic, and they may not be. I've looked at fortran/module.c to try to find any simple way to force a consistent ordering, but there doesn't seem to be anything that wouldn't lead to massive and unnecessarily invasive change here. Is there one that I'm missing? Or any known issues with instability in gcc's front end or powerpc 8540 specific code? Anyone else run across this effect? If not, does anyone have any other ideas for how I might ensure complete determinism in f951? Or is insisting on bit-equivalent files from successive gcc builds just asking too much? Thanks. -- Google UK Limited | Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Re: Proposing switch -fsmart-pointers
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/kernel developers deserve some love too.
> I strongly belive That automatic cleanup should be provided also for
> dynamic data on C/C++ low level language level.
> Imagine specially declared ointers being freed when leaving scope.
> So normal recovery in case of exception/error without memory leaks or
> double deallocations are possible without error prone duplicate
> copy-paste cleanup statements.
> This will result to simpler and safer but not slower code.
>
> First current state example
>
> void proc() {
> Object* object_ptr;
> // zillion error/exception handlers zillion ways to messup cleanup
> }
>
> Let smart pointer declaration be for example
> type *~ variable;
>
> void proc() {
> Object*~ object_ptr;
> // zillion error/exception handlers but destructor/free is
> automatically called when not null and leaving scope just like with
> static objects
> }
>
> Another important example
>
> struct A {
> Object*~ object_ptr;
> Object*~ array[1000]; // during creation of array element [500]
> exception happens yet resources are properly freed like with static
> objects
> }
>
> // when stuct is destroyed all non null pointers have free called/
> destructors where appropriate
>
> Now those of you sayng that it is too complex to be done. I already
> implemented it.
> You can test it here.
> http://www.codeproject.com/Articles/468126/new-local-for-safer-and-simpler-code-with-no-need
>
> Unfortunately I have no idea how to do it in gcc. Is someone fluid
> with gcc or it's plugins willing to hlep me ?
> I would be more than thankfull.
>
> 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
>
>
> What you guys think about this? I don't belive in stl solves all
> especially in low level land.
What's wrong with doing:
void proc() {
Object* object_ptr = 0;
struct cleanup {
~cleanup() { delete p; }
Object*& p;
} c = { object_ptr };
...
}
?
Re: reverse bitfield patch
> 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 C layout order, but the underlying data
needs to be stored in the reversed order.
> which will severely pessimize bitfield accesses to structs with the
> bitfield-order attribute.
The typical use-case for this feature is memory-mapped hardware, where
pessimum access is preferred anyway.
> so you are supporting this as #pragma. Which ends up tacking
> bit_order to each type. Rather than this, why not operate similar
> to the packed pragma, thus, adjust a global variable in
> stor-layout.c.
Because when I first proposed this feature, I was told to do it this
way.
> I don't see a value in attaching 'native' or 'msb'/'lsb' if it is
> equal to 'native'. You un-necessarily pessimize code generation (is
> different code even desired for a "no-op" bit_order attribute?).
If the attribute corresponds to the native mode, it should be a no-op.
The pessimizing only happens when the fields are actually in reverse
order.
> So no, I don't like this post-process layouting thing. It's a
> layouting mode so it should have effects at bitfield layout time.
The actual reversal happens in stor-layout.c. Everything else is
there to compensate for a possible non-linear layout.
Re: Instability in successive builds of fortran mod files with f951
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 values. (Added fort...@gcc.gnu.org). Ian
Re: Instability in successive builds of fortran mod files with f951
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 bug. The compiler should never depend on the > order of pointer values. > > (Added fort...@gcc.gnu.org). > > Ian Also known as PR 51727, FWIW. See also the ML thread referenced in the PR (continued at http://gcc.gnu.org/ml/fortran/2012-01/msg3.html). So yes, it's a known problem, but so far nobody has found the time to fix it. -- Janne Blomqvist
Re: Functions that are CSEable but not pure
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 = ...;
..
}
as well as CSE, PRE, PDE etc.
The bigger problems are
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
2) The runtime overhead of the guard code -- if the guard variable is also tls.
Speaking of 1), given two inline instances of the wrapper,
if (!init_guard)
{
init_guard = 1;
do_init();
}
... some code
if (!init_guard)
{
init_guard =1 ;
do_init();
}
If the compiler is taught that init_guard can not be clobbered by
anything other than the owner TLS variable's wrapper function, then
VRP should should be able to provide init_guard is not zero before the
second check thus can completely eliminate the if-block.
Inter-procedural elimination requires more work though.
so perhaps the solution is just to mark wrapper function always
inline? It will punish the code size for O0 build though as the init
block can not be optimized away.
thanks,
David
On Fri, Oct 5, 2012 at 10:24 AM, Jason Merrill wrote:
> 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 so; that is an odr-use of i, so it needs to be initialized.
>
>
>> Thus my question is - is a valid program allowed to access side-effects
>> of the dynamic TLS initializer by not going through the TLS variable?
>
>
> I think so.
>
>
>> Preventing DCE but not CSE for const/pure functions can be for
>> example done by using the looping-const-or-pure flag (but that
>> also tells the compiler that this function may not return, so it is
>> very specific about the kind of possible side-effect to be preserved).
>> The very specific nature of thread_local TLS init semantics
>> ('somewhen before') is hard to make use of, so if we want to
>> change looping-const-or-pure to something like
>> const-or-pure-with-side-effects
>> we should constrain things more.
>
>
> That would be fine with me.
>
> Jason
>
Re: Functions that are CSEable but not pure
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, which is not inline. Jason
Re: Functions that are CSEable but not pure
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 doesn't actually check the guard; that happens in the init > function, which is not inline. > 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 discussed here. David > Jason >
Re: Functions that are CSEable but not pure
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 discussed here. I think we can leave the wrapper as a normal inline and use the same attribute on the init function; it also has the property of only having side-effects on the first call, it just doesn't return anything. Jason
gcc-4.6-20121005 is now available
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/gcc-4_6-branch revision 192147 You'll find: gcc-4.6-20121005.tar.bz2 Complete GCC MD5=c26833c40d27f1e7de75fd4f2a938e22 SHA1=4400e770508154f64aecfff7471e3fa589d92771 Diffs from 4.6-20120928 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [AVR] Missing avr51-flash1.x in avr target specific tests?
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. >> >> Is that linker script supposed to be checked into source control? Or am >> I missing some configure/build option? > > I found no way to specify a linker script for one single test and supply that > linker script in the testsuite source tree. > > > It's likely that I used the wrong approach just because my limited knowledge > on > DejaGNU and GCC testsuite framework. > > The linker script must be located in a place where the compiler will search > for > it, e.g. some directory that contains the .x and that you added per -L to the > ldflags in your DejaGNU board description. > > Johann > > If the linker will look in the directory containing the source file you can check it in there and use dg-additional-files in the test to copy the file to the host. Janis
Re: inlined memcpy/memset degradation in gcc 4.6 or later
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 also be forbidden from assuming any alignment. So,
> > when compiling "copy", do we lack the information that the memcpy call is
> > to the standard ISO memcpy function? If we know that it is the standard
> > function we should be able to do the copy assuming everything is properly
> > aligned.
>
On Fri, Oct 05, 2012 at 10:32:55AM +0200, Richard Guenther wrote:
> If we see the above aggregate copy then we should be able to compile
> the function assuming that f0 and f1 are properly aligned for type struct foo.
> If we see C source code using memcpy (f0, f1, sizeof (struct foo)) then
> we cannot assume anything about the alignment of f0 or f1 based on the
> fact that the code uses the ISO memcpy function.
Sorry, that makes no sense at all. Let's say that I'm a user of the
function "copy", and I don't know if the implementer of "copy" chose to
write
*f0 = *f1;
or if she used memcpy. What you are telling me is that I need to know
that information, because in one case I am permitted to pass in nonsense
pointers that only claim to point to a (struct foo), and in the other
case I have to use proper struct foo's, aligned according to the rules of
that platform. In fact, if I pass invalid pointers I deserve to lose, and
GCC should not be required to implement pessimistic code to deal with a
possibility that cannot occur. A (struct foo*) has to point either to a
proper structure or be null.
What I am assuming is that memcpy(f0, f1, sizeof(struct foo)) is
equivalent to *f0 = *f1, because that is what it does: it copies the
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.
Re: inlined memcpy/memset degradation in gcc 4.6 or later
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 conversions you can assume the highest alignment of any of the pointer types involved. In practice, optimizations based on that caused problems, such as miscompilations of glibc where various constants (part of the public ABI) use unaligned values such as (int *) -1 and comparisons of pointers against those constants got optimized to 0. -- Joseph S. Myers jos...@codesourcery.com
