DECL_FIELD_CONTEXT woes

DECL_FIELD_CONTEXT woes

[Gabriele SVELTO]

  Hi all,
I'm going on brutalizing GIMPLE code to make it more suitable for CIL emition in 
the CLI be/fe branch and I've stumbled across something which looks really weird.
  When working with types I always assumed that if 't' is a RECORD_TYPE, 
UNION_TYPE or QUAL_UNION_TYPE then calling DECL_FIELD_CONTEXT () on its fields 
yields 't' itself. Chasing a weird bug I had in the test suite I ended up with a 
case where this wasn't true. This happens in: 
gcc.c-torture/execute/ieee/fp-cmp-4.c. I've pasted only the relevant code:

int
main()
{
   struct try
   {
     FLOAT x, y;
     unsigned unord : 1;
     unsigned lt : 1;
     unsigned le : 1;
     unsigned gt : 1;
     unsigned ge : 1;
     unsigned lg : 1;
   };

   static struct try const data[] =
   {
     { NAN, NAN, 1, 0, 0, 0, 0, 0 },
     { 0.0, NAN, 1, 0, 0, 0, 0, 0 },
     { NAN, 0.0, 1, 0, 0, 0, 0, 0 },
     { 0.0, 0.0, 0, 0, 1, 0, 1, 0 },
     { 1.0, 2.0, 0, 1, 1, 0, 0, 1 },
     { 2.0, 1.0, 0, 0, 0, 1, 1, 1 },
   };

   const int n = sizeof(data) / sizeof(data[0]);
   int i;

   for (i = 0; i < n; ++i)
     {
       test_isunordered (data[i].x, data[i].y, data[i].unord);
       test_isless (data[i].x, data[i].y, data[i].lt);
       test_islessequal (data[i].x, data[i].y, data[i].le);
       test_isgreater (data[i].x, data[i].y, data[i].gt);
       test_isgreaterequal (data[i].x, data[i].y, data[i].ge);
       test_islessgreater (data[i].x, data[i].y, data[i].lg);
     }

   exit (0);
}

Here's the catch, when compiling the main function a RECORD_TYPE is built for 
representing 'struct try' (obviously). Then an helper function is generated 
which seems to be used for initializing the 'data' array (I think it's called 
COBJ?Init). A new type still named 'struct try' is used in the COMPONENT_REFs of 
this function but this type has a different TYPE_UID from the 'struct try' used 
in main. Since the original type was local to main this makes sense. However 
this new type shares the fields with the old one i.e. calling DECL_FIELD_CONTEXT 
() on its fields doesn't yield itself but another type (the old one used in main).
  Is this correct? The documentation in of DECL_FIELD_CONTEXT () in tree.h 
doesn't state anything about it which left me kind of confused...

  Gabriele

RE: DECL_FIELD_CONTEXT woes

[Dave Korn]

On 10 January 2008 16:12, Gabriele SVELTO wrote:

> int
> main()
> {
>    struct try
>    {
>      FLOAT x, y;
>      unsigned unord : 1;
>      unsigned lt : 1;
>      unsigned le : 1;
>      unsigned gt : 1;
>      unsigned ge : 1;
>      unsigned lg : 1;
>    };
> 
>    static struct try const data[] =
>    {
>      { NAN, NAN, 1, 0, 0, 0, 0, 0 },
>      { 0.0, NAN, 1, 0, 0, 0, 0, 0 },
>      { NAN, 0.0, 1, 0, 0, 0, 0, 0 },
>      { 0.0, 0.0, 0, 0, 1, 0, 1, 0 },
>      { 1.0, 2.0, 0, 1, 1, 0, 0, 1 },
>      { 2.0, 1.0, 0, 0, 0, 1, 1, 1 },
>    };


> A new type still named 'struct try' is used in the COMPONENT_REFs of
> this function but this type has a different TYPE_UID from the 'struct try'
> used in main. Since the original type was local to main this makes sense.

  But the array is local to main as well ...

> However this new type shares the fields with the old one i.e. calling
> DECL_FIELD_CONTEXT () on its fields doesn't yield itself but another type
> (the old one used in main).

  Is this possibly because the new type is not "struct try" but "struct try
const"; it adds the const qualifier and refers back to the original "struct
try" for the fields?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: DECL_FIELD_CONTEXT woes

[Gabriele SVELTO]

Dave Korn wrote:
> On 10 January 2008 16:12, Gabriele SVELTO wrote:
> 
 > [snip]
 >
>> A new type still named 'struct try' is used in the COMPONENT_REFs of
>> this function but this type has a different TYPE_UID from the 'struct try'
>> used in main. Since the original type was local to main this makes sense.
> 
>   But the array is local to main as well ...

But it's static so it needs to be initialized once before the function gets 
called AFAIK. gcc seems to be creating an artificial function for this task or 
at least that's how it looks. I've been working on gcc for only ~3 months so I 
might be badly wrong on this one.

>> However this new type shares the fields with the old one i.e. calling
>> DECL_FIELD_CONTEXT () on its fields doesn't yield itself but another type
>> (the old one used in main).
> 
>   Is this possibly because the new type is not "struct try" but "struct try
> const"; it adds the const qualifier and refers back to the original "struct
> try" for the fields?

Yes, TYPE_READONLY () returns 1 on the new type so I guess it's const. So is it 
normal that the two types share the fields so that you can end up with 
DECL_FIELD_CONTEXT (TYPE_FIELDS (type)) != type ? Does this always happen when 
gcc creates a 'derived' const type from another one? Thanks for the help,

  Gabriele

RE: DECL_FIELD_CONTEXT woes

[Dave Korn]

On 10 January 2008 16:40, Gabriele SVELTO wrote:

> Dave Korn wrote:
>> On 10 January 2008 16:12, Gabriele SVELTO wrote:
>> 
>  > [snip]
>  >
>>> A new type still named 'struct try' is used in the COMPONENT_REFs of
>>> this function but this type has a different TYPE_UID from the 'struct try'
>>> used in main. Since the original type was local to main this makes sense.
>> 
>>   But the array is local to main as well ...
> 
> But it's static so it needs to be initialized once before the function gets
> called AFAIK. gcc seems to be creating an artificial function for this task
> or at least that's how it looks. I've been working on gcc for only ~3
> months so I might be badly wrong on this one.

  Yes, you're completely correct about the artificial initialiser function; I
thought the compiler might output it as a nested function, but I don't know
without checking.  (But I've been working on gcc for only ~7 years so I might
be badly wrong on this or indeed any other one..... ;-P it's a big old pile of
code!)

>>   Is this possibly because the new type is not "struct try" but "struct try
>> const"; it adds the const qualifier and refers back to the original "struct
>> try" for the fields?
> 
> Yes, TYPE_READONLY () returns 1 on the new type so I guess it's const. 

  Really you should use CP_TYPE_CONST_P to test this; IIUC, things can be
const without being readonly (and perhaps even vice-versa), depending on which
kind of section (.data/.rdata) they're allocated to.


> So
> is it normal that the two types share the fields so that you can end up with
> DECL_FIELD_CONTEXT (TYPE_FIELDS (type)) != type ? Does this always happen
> when gcc creates a 'derived' const type from another one? Thanks for the
> help, 

  I believe this is indeed gcc's bog-standard way of creating a qualified
variant of an existing type.  Note that you should see in this case that
TYPE_MAIN_VARIANT (type) == DECL_FIELD_CONTEXT (TYPE_FIELDS (type)), I think.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: DECL_FIELD_CONTEXT woes

[Gabriele SVELTO]

Dave Korn wrote:
> On 10 January 2008 16:40, Gabriele SVELTO wrote:
> 
>   Yes, you're completely correct about the artificial initialiser function; I
> thought the compiler might output it as a nested function, but I don't know
> without checking.  (But I've been working on gcc for only ~7 years so I might
> be badly wrong on this or indeed any other one..... ;-P it's a big old pile of
> code!)

I guess so, it redefined my concept of "large, complex project".

>   Really you should use CP_TYPE_CONST_P to test this; IIUC, things can be
> const without being readonly (and perhaps even vice-versa), depending on which
> kind of section (.data/.rdata) they're allocated to.

Thanks for the type, I was completely unaware of the existence of that macro.

>   I believe this is indeed gcc's bog-standard way of creating a qualified
> variant of an existing type.  Note that you should see in this case that
> TYPE_MAIN_VARIANT (type) == DECL_FIELD_CONTEXT (TYPE_FIELDS (type)), I think.

Good to know, TYPE_MAIN_VARIANT () is exactly what I was looking for, 
unfortunately it's description in tree.def isn't exactly crystal clear :P Thank 
you very much

  Gabriele

Re: DECL_FIELD_CONTEXT woes

[Tom Tromey]

>>>>> "Gabriele" == Gabriele SVELTO <gabriele.svelto@st.com> writes:

Gabriele> Good to know, TYPE_MAIN_VARIANT () is exactly what I was
Gabriele> looking for, unfortunately it's description in tree.def
Gabriele> isn't exactly crystal clear :P Thank you very much

This would be a great opportunity to improve the comment...

Tom

Re: DECL_FIELD_CONTEXT woes

[Gabriele SVELTO]

Tom Tromey wrote:
>>>>>> "Gabriele" == Gabriele SVELTO <gabriele.svelto@st.com> writes:
> 
> Gabriele> Good to know, TYPE_MAIN_VARIANT () is exactly what I was
> Gabriele> looking for, unfortunately it's description in tree.def
> Gabriele> isn't exactly crystal clear :P Thank you very much
> 
> This would be a great opportunity to improve the comment...
> 
> Tom

Actually I cross checked into section 9.3 of the gcc internals this morning and 
it's perfectly documented, my bad. On the other hand it turns out that we did 
generate COBJ?init function in our branch, it doesn't happen in plain gcc. 
Yesterday nobody was there so I couldn't ask and I didn't realize it was some of 
our stuff.

  Gabriele