This is the mail archive of the
mailing list for the GCC project.
Re: .size directives and flexible array members
- From: Marcin 'Qrczak' Kowalczyk <qrczak at knm dot org dot pl>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 27 Aug 2006 22:15:42 +0200
- Subject: Re: .size directives and flexible array members
- References: <firstname.lastname@example.org>
> Can this have serious effects (like overlapped or split objects),
> or is .size used only for e.g. debugging?
It seems that .size is used for shared libraries compiled without
-fPIC: linking the same code statically or with -fPIC fixes the wrong
behavior, and -finhibit-size-directive causes linking errors about
zero-sized objects. I don't use -fPIC here because it makes code
1.6 times slower.
I found that the .size bug has been reported in January 2006:
Comments seem to indicate that it has been fixed for 4.1 and 4.2, but
I can see the wrong behavior in both gcc-4.1.0-0.20051206r108118 and
gcc-4.2.0-0.20060806r115974. If it's indeed fixed, in which versions?
* * *
Now I have a problem in my program which uses lots of statically
allocated objects with a fixed header and variable sized payload,
and some inline functions which operate on objects of varying size.
Namely, using flexible array members doesn't work with shared
libraries because of the .size bug, and using explicitly sized arrays
relies on illegal type punning which breaks in 4.2.0 (even casting
a pointer to struct to a pointer to a separately defined struct with
identical contents may cause the compiler to think that they can't
alias each other and generate subtly wrong code in very rare cases).
Workarounds I can see:
- Keep explicitly sized arrays, use -fno-strict-aliasing to make it
working in the presence of type punning.
- Keep explicitly sized arrays, don't inline certain functions
(I suppose only a single function is affected), hoping that gcc
will not optimize too aggressively.
- Use flexible array members, give up shared libraries until gcc
Any other ideas?
__("< Marcin Kowalczyk