Re: Thoughts on Gengtype and Single Inheritance
Lawrence -
I don't have an opinion from the rest of compiler point of view, but
gengtype implementation-wise, it certainly looks doable. One minor
comment below -
> GRAMMAR
>
> Support adding a second discriminator. This support is not for
> multiple inheritance, but for single inheritance when a second
> discriminator is used to further refine it. Look at struct
> tree_omp_clause. It contains a sub union. We can represent the
> hierarchy like:
>
> struct tree_omp_clause : tree_common {
> location_t locus;
> enum omp_clause_code code;
> };
>
> struct tree_omp_default_clause : tree_omp_clause {
> enum omp_clause_default_kind default_kind;
> };
>
> struct tree_omp_schedule_clause : tree_omp_clause {
> enum omp_clause_schedule_kind schedule_kind;
> };
>
> struct tree_omp_reduction_clause : tree_omp_clause {
> enum tree_code reduction_code;
> };
>
> We use TREE_CODE to understand that we have at least a tree_omp_clause
> and then we use tree_common.code to to distinguish these last three.
>
> Another possible case is tree_type_symtab inside tree_type_common.
>
> The syntax would be something like the following.
>
> enum F { F1, F2, F3, F4, F5 };
>
> class CTYPE GTY ((desc ("%h.kind"), tag ("F1")))
> : GTY ((tag ("EC"))) public BTYPE
> { public: enum F kind; something *pq; ... };
>
> class FTYPE : GTY ((tag ("F2"))) public CTYPE { ... };
I wonder if the second discriminator support is easily generalizable
to enabling any derived class being a root class on it own with its
own subtree? If I understand correctly, the GTY syntax would be the
same.
--
Laurynas
Re: internal compiler error using lambda and this
On 08/26/2012 01:09 AM, Gerald Pfeifer wrote:
On Tue, 29 May 2012, Andreas Karrenbauer wrote:
To whom it may concern:
Please find a small code example which causes an internal compiler error with
g++-4.7 (opensuse):
Thanks for the report, Andreas.
I tried this with a current snapshot of what will become GCC 4.8.0
in several months, and now get this:
$ cat x.cc
auto foo = [&](int a) { return a > this->b; };
$ g++ x.cc
x.cc:1:6: error: 'foo' does not name a type
auto foo = [&](int a) { return a > this->b; };
^
This is just the error message you get when you try to compile a program
which uses type inference in non-C++11 mode. Trunk and 4.7.1 still
crash on this example program.
Andreas, would you please file a bug in Bugzilla?
--
Florian Weimer / Red Hat Product Security Team
Re: internal compiler error using lambda and this
On Sun, 26 Aug 2012, Gerald Pfeifer wrote:
> I tried this with a current snapshot of what will become GCC 4.8.0
> in several months, and now get this:
>
> $ cat x.cc
> auto foo = [&](int a) { return a > this->b; };
>
> $ g++ x.cc
> x.cc:1:6: error: 'foo' does not name a type
>auto foo = [&](int a) { return a > this->b; };
> ^
It has been pointed out to me (Thanks!) that this requires
-std=c++0x to show the internal compiler error.
I reproduced this with current development sources and reported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383
Internal compiler error for lamba function using this-> with -std=c++0x
Thanks,
Gerald
Re: Question on calculating register pressure before ira pass
On 08/20/2012 05:00 AM, Bin.Cheng wrote: Hi, Currently I am working on improving hoist pass by calculating register pressure and using the info to guide hoist process. It works well and I will send a patch once I finish it. Sorry for the delay with the answer. Looking at the bigger picture, I believe (and I already expressed this opinion several times) that we need a general register pressure decreasing pass before 1st scheduler which should include rematerializations (e.g. see Simpson's aproach in his PhD.) and live-range shrinkage. Otherwise, we will have more and more complicated register-pressure aware optimizations (e.g. Bill Schmidt proposed this on last GNU Cauldron for his straight line strength reduction). But this is only my wish. I don't know who (may be me) will implement this and when. So please do not consider this as as discourage for your work moreover when it is already done. Sometimes temporary solutions continue forever as the right big permanent solution is never implemented. In this work I reused codes in loop-invariant and called ira_set_pseudo_classes function to calculate register pressure. The problem is that ira_set_pseudo_classes sets pseudo_classes_defined_p to TRUE, which causes function find_costs_and_classes scans instructions only once to find the best reg class to use for each allocno. In my understanding, these part of codes is introduced for calculating reg pressure in schedulor and loop-invariant. What I do not understand is why we make IRA behave differently when register pressure is calculated before IRA pass? The reg class and costs caluclations are very expensive procedure (O (# insns * # average number alternatives in insns * # reg classes)). Therefore we just try to reuse some cost info calculated in scheduler and RTL loop-invariant opt. for IRA. Of course the code is changed in scheduler, loop invariant opts, and in other intermediate opts but I guess some changes do not affect considerably on choosing costs and classes in IRA. If you found that reusing such approach results in bigger regression, we could use 2 passes in IRA in any case for some targets (for x86/x86-64 I believe it has no sense as I did some measuring long ago) or use 2 cost passes for -O3/-Ofast in anyway. Generally speaking, sometimes 3rd pass of costs could give better cost and class results. The algorithm stabilizes when there are no changes in costs and classes (and in practice it needs at least 3 passes). In the work of hoist, I found bigger regression in code size causes by the changed behavior of IRA. My questions are: 1. could somebody give some explanation on this. I think I gave it. 2. Is it possible to calculate register pressure by reusing existing code while do not change behavior of IRA? Yes, it is possible.
Re: C++ and gather-detailed-mem-stats
Hi,
On Fri, 24 Aug 2012, Diego Novillo wrote:
> > void foo (int bar) __attribute__((add_location_pack));
> >
> > that directs GNU C++ to add a __Gcc_call_location_pack typed
> > argument at each call site (properly constructed of course)?
>
> I really like this idea.
>
> Couldn't we make it even more transparent? If a function is marked with
> __attribute__((add_location_pack)) (or some other attribute name), the
> callers will always pass file, function and line as hidden arguments (in
> the same way that 'this' is passed as a hidden argument).
Note that this is only half of the fix. You also need a way to pass a
given pack transparently to a callee, like in this situation:
void real_worker (int arg, location_pack *p);
void wrapme (location_pack *p)
{
real_worker (1, p);
}
The location passed to the call of real_worker should be the one of the
call to wrapme, not the call _in_ wrapme. I.e. the same distinction that
right now is served by MEM_STAT_INFO vs. PASS_MEM_STAT.
This distinction needs to be doable per call, e.g. if there are other
functions that call real_worker that do want to pass the location of that
call and not of their own callers:
void this_is_not_just_a_wrapper (location_pack *p)
{
if (condition)
real_worker (1 THIS_LOCATION);
else
real_worker (2 THIS_LOCATION);
add_stats_for_me (p);
}
There are a few obvious ways how to make this distinction with various
levels of ease of use. E.g. function that need such location_pack could
just be marked with the attribute (adding a new argument), i.e. as
Richards suggestion, and the callers decide what should be passed, namely
__builtin_location (the location pack of the current source position where
that token is mentioned), or __builtin_caller_location. The latter would
be usable only in functions marked as __attribute__((add_location_pack)),
and would return the passed location pack, not the current source
position.
Ciao,
Michael.
Size difference in base class between GCC releases
I'm doing some checking of data structure layouts in different releases of our code -- which were produced by different releases of GCC (3.3.3 vs. 4.5.4). One difference I'm seeing that is puzzling is in the handling of base classes. Specifically, the case where a base class has padding at the end to fill it out to a multiple of the alignment. In GCC 3.3.3, when such a class is used as a base class, that padding is omitted, and the first derived class data member starts right after the last base class real (not pad) data member. In GCC 4.5.4, the base class is used padding and all, the first derived class data member starts after the padding of the base class. Which is correct? Or are both correct? This sort of thing is a potential cause of trouble if such a class is used as a container for persistent data. paul
Re: Thoughts on Gengtype and Single Inheritance
On 8/27/12, Laurynas Biveinis wrote:
> I don't have an opinion from the rest of compiler point of view, but
> gengtype implementation-wise, it certainly looks doable. One minor
> comment below -
>
>> GRAMMAR
>>
>> Support adding a second discriminator. This support is not for
>> multiple inheritance, but for single inheritance when a second
>> discriminator is used to further refine it. Look at struct
>> tree_omp_clause. It contains a sub union. We can represent the
>> hierarchy like:
>>
>> struct tree_omp_clause : tree_common {
>> location_t locus;
>> enum omp_clause_code code;
>> };
>>
>> struct tree_omp_default_clause : tree_omp_clause {
>> enum omp_clause_default_kind default_kind;
>> };
>>
>> struct tree_omp_schedule_clause : tree_omp_clause {
>> enum omp_clause_schedule_kind schedule_kind;
>> };
>>
>> struct tree_omp_reduction_clause : tree_omp_clause {
>> enum tree_code reduction_code;
>> };
>>
>> We use TREE_CODE to understand that we have at least a tree_omp_clause
>> and then we use tree_common.code to to distinguish these last three.
>>
>> Another possible case is tree_type_symtab inside tree_type_common.
>>
>> The syntax would be something like the following.
>>
>> enum F { F1, F2, F3, F4, F5 };
>>
>> class CTYPE GTY ((desc ("%h.kind"), tag ("F1")))
>> : GTY ((tag ("EC"))) public BTYPE
>> { public: enum F kind; something *pq; ... };
>>
>> class FTYPE : GTY ((tag ("F2"))) public CTYPE { ... };
>
> I wonder if the second discriminator support is easily generalizable
> to enabling any derived class being a root class on it own with its
> own subtree? If I understand correctly, the GTY syntax would be the
> same.
If I understand correctly, you are suggesting multiple inheritance
via enums. I think it is possible, but I think the tag syntax
would need to be changed to more directly associate the tag with
the variable.
--
Lawrence Crowl
Re: Size difference in base class between GCC releases
On 27 August 2012 19:48, Paul_Koningwrote: > I'm doing some checking of data structure layouts in different releases of > our code -- which were produced by different releases of GCC (3.3.3 vs. > 4.5.4). > > One difference I'm seeing that is puzzling is in the handling of base > classes. Specifically, the case where a base class has padding at the end to > fill it out to a multiple of the alignment. > > In GCC 3.3.3, when such a class is used as a base class, that padding is > omitted, and the first derived class data member starts right after the last > base class real (not pad) data member. In GCC 4.5.4, the base class is used > padding and all, the first derived class data member starts after the padding > of the base class. This depends on whether the base class is a POD or not. According to a note in the Itanium C++ ABI "the C++ standard requires that compilers not overlay the tail padding in a POD" (I don't know off the top of my head where that is stated in the standard.) > Which is correct? Or are both correct? This sort of thing is a potential > cause of trouble if such a class is used as a container for persistent data. GCC 3.4 and later conform to the Itanium C++ ABI, which specifies the behaviour you're seeing as required by the C++ standard, so 4.5 is correct.
Re: Size difference in base class between GCC releases
On Aug 27, 2012, at 3:33 PM, Jonathan Wakely wrote: > On 27 August 2012 19:48, Paul_Koningwrote: >> I'm doing some checking of data structure layouts in different releases of >> our code -- which were produced by different releases of GCC (3.3.3 vs. >> 4.5.4). >> >> One difference I'm seeing that is puzzling is in the handling of base >> classes. Specifically, the case where a base class has padding at the end >> to fill it out to a multiple of the alignment. >> >> In GCC 3.3.3, when such a class is used as a base class, that padding is >> omitted, and the first derived class data member starts right after the last >> base class real (not pad) data member. In GCC 4.5.4, the base class is used >> padding and all, the first derived class data member starts after the >> padding of the base class. > > This depends on whether the base class is a POD or not. > > According to a note in the Itanium C++ ABI "the C++ standard requires > that compilers not overlay the tail padding in a POD" (I don't know > off the top of my head where that is stated in the standard.) > >> Which is correct? Or are both correct? This sort of thing is a potential >> cause of trouble if such a class is used as a container for persistent data. > > GCC 3.4 and later conform to the Itanium C++ ABI, which specifies the > behaviour you're seeing as required by the C++ standard, so 4.5 is > correct. Interesting. What if the base class is not a POD? It doesn't seem to be, if I remember the definition of POD correctly. paul
Re: Size difference in base class between GCC releases
On Mon, Aug 27, 2012 at 1:48 PM, wrote: > I'm doing some checking of data structure layouts in different releases of > our code -- which were produced by different releases of GCC (3.3.3 vs. > 4.5.4). > > One difference I'm seeing that is puzzling is in the handling of base > classes. Specifically, the case where a base class has padding at the end to > fill it out to a multiple of the alignment. > > In GCC 3.3.3, when such a class is used as a base class, that padding is > omitted, and the first derived class data member starts right after the last > base class real (not pad) data member. In GCC 4.5.4, the base class is used > padding and all, the first derived class data member starts after the padding > of the base class. > > Which is correct? Or are both correct? This sort of thing is a potential > cause of trouble if such a class is used as a container for persistent data. > > paul > Is this message http://gcc.gnu.org/ml/gcc/2002-08/msg00874.html relevant to your case? -- Gaby
Re: Size difference in base class between GCC releases
On Aug 27, 2012, at 4:05 PM, Gabriel Dos Reis wrote: > On Mon, Aug 27, 2012 at 1:48 PM, wrote: >> I'm doing some checking of data structure layouts in different releases of >> our code -- which were produced by different releases of GCC (3.3.3 vs. >> 4.5.4). >> >> One difference I'm seeing that is puzzling is in the handling of base >> classes. Specifically, the case where a base class has padding at the end >> to fill it out to a multiple of the alignment. >> >> In GCC 3.3.3, when such a class is used as a base class, that padding is >> omitted, and the first derived class data member starts right after the last >> base class real (not pad) data member. In GCC 4.5.4, the base class is used >> padding and all, the first derived class data member starts after the >> padding of the base class. >> >> Which is correct? Or are both correct? This sort of thing is a potential >> cause of trouble if such a class is used as a container for persistent data. >> >>paul >> > > Is this message > > http://gcc.gnu.org/ml/gcc/2002-08/msg00874.html > > relevant to your case? > > -- Gaby Yes, that looks like the exact case. And the mail thread seems to say that the "3.3.3" behavior I'm seeing is what G++ was doing at that time, as was HP -- but not Intel. So now we have it done differently in later compilers. I know this is changing data structure layouts in our code; I don't know yet if that is a problem (i.e., if it applies to layouts used in persistent data or in protocol messages). I assume there isn't some compiler switch I can use to control this behavior? paul
Re: Size difference in base class between GCC releases
On Mon, Aug 27, 2012 at 3:16 PM, wrote: > On Aug 27, 2012, at 4:05 PM, Gabriel Dos Reis wrote: > >> On Mon, Aug 27, 2012 at 1:48 PM, wrote: >>> I'm doing some checking of data structure layouts in different releases of >>> our code -- which were produced by different releases of GCC (3.3.3 vs. >>> 4.5.4). >>> >>> One difference I'm seeing that is puzzling is in the handling of base >>> classes. Specifically, the case where a base class has padding at the end >>> to fill it out to a multiple of the alignment. >>> >>> In GCC 3.3.3, when such a class is used as a base class, that padding is >>> omitted, and the first derived class data member starts right after the >>> last base class real (not pad) data member. In GCC 4.5.4, the base class >>> is used padding and all, the first derived class data member starts after >>> the padding of the base class. >>> >>> Which is correct? Or are both correct? This sort of thing is a potential >>> cause of trouble if such a class is used as a container for persistent data. >>> >>>paul >>> >> >> Is this message >> >> http://gcc.gnu.org/ml/gcc/2002-08/msg00874.html >> >> relevant to your case? >> >> -- Gaby > > Yes, that looks like the exact case. And the mail thread seems to say that > the "3.3.3" behavior I'm seeing is what G++ was doing at that time, as was HP > -- but not Intel. So now we have it done differently in later compilers. Yes. > > I know this is changing data structure layouts in our code; I don't know yet > if that is a problem (i.e., if it applies to layouts used in persistent data > or in protocol messages). I assume there isn't some compiler switch I can > use to control this behavior? > Normally, any changes like this is controlled by -fabi-version; you can also get warnings with -Wabi. See the discussion at http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wabi-168 if it is of any help. -- Gaby
Re: Size difference in base class between GCC releases
On 27 August 2012 20:49 Paul Koning wrote: > > On Aug 27, 2012, at 3:33 PM, Jonathan Wakely wrote: > >> On 27 August 2012 19:48, Paul_Koningwrote: >>> I'm doing some checking of data structure layouts in different releases of >>> our code -- which were produced by different releases of GCC (3.3.3 vs. >>> 4.5.4). >>> >>> One difference I'm seeing that is puzzling is in the handling of base >>> classes. Specifically, the case where a base class has padding at the end >>> to fill it out to a multiple of the alignment. >>> >>> In GCC 3.3.3, when such a class is used as a base class, that padding is >>> omitted, and the first derived class data member starts right after the >>> last base class real (not pad) data member. In GCC 4.5.4, the base class >>> is used padding and all, the first derived class data member starts after >>> the padding of the base class. >> >> This depends on whether the base class is a POD or not. >> >> According to a note in the Itanium C++ ABI "the C++ standard requires >> that compilers not overlay the tail padding in a POD" (I don't know >> off the top of my head where that is stated in the standard.) >> >>> Which is correct? Or are both correct? This sort of thing is a potential >>> cause of trouble if such a class is used as a container for persistent data. >> >> GCC 3.4 and later conform to the Itanium C++ ABI, which specifies the >> behaviour you're seeing as required by the C++ standard, so 4.5 is >> correct. > > Interesting. What if the base class is not a POD? It doesn't seem to be, if > I remember the definition of POD correctly. G++ 3.4 and later can, and will, reuse the tail padding in a non-POD.
Re: Size difference in base class between GCC releases
On 27 August 2012 21:16, Paul Koning wrote:
>
> On Aug 27, 2012, at 4:05 PM, Gabriel Dos Reis wrote:
>>
>> Is this message
>>
>> http://gcc.gnu.org/ml/gcc/2002-08/msg00874.html
>>
>> relevant to your case?
>>
>> -- Gaby
>
> Yes, that looks like the exact case. And the mail thread seems to say that
> the "3.3.3" behavior I'm seeing is what G++ was doing at that time, as was HP
> -- but not Intel. So now we have it done differently in later compilers.
That mail is talking about reusing tail padding in non-PODs, and G++
still does that, i.e. this code compiles:
struct S1 {
virtual void f();
int i;
char c1;
};
struct S2 : public S1 {
char c2;
};
const S2 s2{};
static_assert( (&s2.c2 - &s2.c1) == 1, "Reused tail padding" );
Please check whether the code you're looking at involves a POD base
class, because that would explain why G++ 4.5 doesn't reuse the tail
padding (I have no idea if 3.3 does or doesn't, but using
-fabi-version=1 to request the G++ 3.2 ABI doesn't seem to cause tail
padding in PODs to be reused.)
