[Bug objc/47832] New: [4.6 Regression] ObjC errors on structures with flexible data members

[Bug objc/47832] New: [4.6 Regression] ObjC errors on structures with flexible data members

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

           Summary: [4.6 Regression] ObjC errors on structures with
                    flexible data members
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: objc
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: nicola@gcc.gnu.org, iains@gcc.gnu.org


struct S
{
  int s;
  unsigned char *t[];
};
@interface T
{
  struct S *u;
};
@end
@implementation T
{
};
@end

used to compile just fine in 4.5, but 4.6 rejects this
rh678928.m:14:1: error: instance variable has unknown size

I don't know ObjC enough to say whether this is intentional or not (and whether
ObjC standard actually talks about flexible array members at all).  If flexible
array members should be allowed, then it would just need to make sure the
element type is complete, rather than the array type.

This breaks build of raidem, for original testcase see
http://bugzilla.redhat.com/678928

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

--- Comment #1 from Nicola Pero <nicola at gcc dot gnu.org> 2011-02-21 10:37:10 UTC ---
Hi Jakub,

> @interface T
> {
>   struct S *u;
> };
> @end

"struct S *" is a pointer, right ?  So it's always the size of a pointer ?
In that case, I don't see any reason why it shouldn't be possible to use
it as an instance variable - it's a bug in the compiler if this is not
allowed. :-)

I think the new check in GCC 4.6 was supposed to catch the case

struct S
{
  int s;
  unsigned char *t[];
};
@interface T
{
  struct S u;
};
@end
@implementation T
{
};
@end

this shouldn't be allowed.  The reason is easy to understand:

 * the list of instance variables in a class (inside @interface T { ... } @end)
   is compiled into a struct in the end ;-)

 * but, if the class is subclassed, the subclass instance variables are added
   at the end of the superclass's struct

 * so, if the list of instance variables ends with a flexible array member,
   you get in trouble when you subclass the class, because the subclass
instance
   variable struct will have a flexible array member *inside* (not at the end)
   of the struct. ;-)

So, flexible array members should not be allowed as instance variables
anywhere.
This is what GCC 4.6 is trying to prevent.

But, in the testcase you show, the instance variable is not a flexible
array member; it's a pointer to a flexible array member.  You can have
pointers to anything you want as instance variables. ;-)

I hope this helps with the Objective-C side.

Looking at the code, the check in encode_array() is not good enough.  When the
instance variable type is encoded, the compiler will follow the pointer and
encode a description of the struct.  The check in encode_array() will then
abort because the struct contains a flexible array member, without realizing
it is part of the struct pointed to.

I guess the fix should remove the check from encode_array() and move it higher
up when instance variables are added.

I can do the fix myself tonight (ie, in the next 12/24 hours) if you want.

Thanks

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

Nicola Pero <nicola at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.02.21 10:42:14
   Target Milestone|---                         |4.6.0
     Ever Confirmed|0                           |1

--- Comment #2 from Nicola Pero <nicola at gcc dot gnu.org> 2011-02-21 10:42:14 UTC ---
Yes, confirmed.  Good testcase.

Thanks

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-21 12:02:58 UTC ---
As I said, I don't know ObjC, so if you could fix it, I'd appreciate it.

That said, ISO C99 allows:

struct A { int a; char b[]; };

struct A a; // Here sizeof (a) will be offsetof (struct A, b[0])

but doesn't allow:

struct B { struct A a; int i; };

So, for ObjC I guess it depends if in @interface there are variables (then
variables with flexible array members in theory could be treated there like ISO
C99 treats variables), or they are treated as struct fields, in which cases
fields with flex array members should be rejected.  And you're right that it is
weird to reject there pointers to structs with flexible array members, unless
ObjC somehow encodes all the types each pointer points to, transitively.

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

--- Comment #4 from Nicola Pero <nicola at gcc dot gnu.org> 2011-02-21 14:33:14 UTC ---

> for ObjC I guess it depends if in @interface there are variables (then
> variables with flexible array members in theory could be treated there like ISO
> C99 treats variables), or they are treated as struct fields, in which cases
> fields with flex array members should be rejected

I see your point.  They are struct fields.

Thanks

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

Nicola Pero <nicola at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Nicola Pero <nicola at gcc dot gnu.org> 2011-02-22 18:31:43 UTC ---
Resolved in trunk (4.6).

Thanks

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #6 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-03-01 08:09:51 UTC ---
Please be sure to tag the changelog entries with the PR numbers, then the work
will be automatically linked to the PRs.