[Bug c/57725] New: conflicting language extensions

[Bug c/57725] New: conflicting language extensions

[jbeulich at novell dot com]

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

            Bug ID: 57725
           Summary: conflicting language extensions
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jbeulich at novell dot com

Created attachment 30369
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30369&action=edit
shared header

Both the "Arrays of Length Zero" and the "Structures With No Members"
extensions conflict with __attribute__((visibility())) (or the respective
pragma) when specifying other than the default visibility: Both of the named
extensions can result in two distinct objects being at the same address, yet
address comparisons for two distinct symbols with non-default visibility
generally get optimized with the assumption that they can't be equal.

The example files I'm going to attach show further problems in this area: The
results here should neither depend on architecture, nor on whether the objects
in question have an initializer. Nevertheless the behavior differs between x86
(both 32-bit and 64-bit) and e.g. ia64 or ARM64 (initialized objects, while
being of zero size, get allocated at distinct addresses for x86 but not for
ia64 and ARM64). Similarly, common data objects (i.e. when there's no
initializer) end up without padding for all architectures I tried this for, but
at least on x86 objects placed in .bss by the compiler get 1-byte padding added
between them.

The example code consists of
- a shared header, empty.h,
- a main source file, empty.c,
- two auxiliary source files, empty-bss.c and empty-comm.c.
The first source file should be compiled together with either of the two
auxiliary files, once with just '-Wall -O2' and another time with '-Wall -O2
-DVISIBILITY="hidden"'. The output will vary between the four executables
created, even though it should be consistent for all of them.

[Bug c/57725] conflicting language extensions

[jbeulich at novell dot com]

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

--- Comment #1 from jbeulich at novell dot com ---
Created attachment 30370
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30370&action=edit
main source

[Bug c/57725] conflicting language extensions

[jbeulich at novell dot com]

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

--- Comment #3 from jbeulich at novell dot com ---
Created attachment 30372
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30372&action=edit
auxiliary source (uninitialized data)

[Bug c/57725] conflicting language extensions

[jbeulich at novell dot com]

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

--- Comment #2 from jbeulich at novell dot com ---
Created attachment 30371
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30371&action=edit
auxiliary source (initialized data)

[Bug c/57725] conflicting language extensions

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I'd say that in the presence of those extensions, it should be considered 
unspecified whether pointers to distinct objects at the same address 
compare equal or not.

[Bug c/57725] conflicting language extensions

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:

> How that? How is code supposed to find out then?

Why does the code want to find out?  If it's using these extensions it's 
saying it's OK with the consequences of objects being at the same address, 
including indeterminate comparisons where one of the objects might be 
zero-size.

If you want to compare symbols without optimization, you should be able to 
use asms to hide from the compiler exactly what's being compared.

[Bug c/57725] conflicting language extensions

[jbeulich at novell dot com]

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

--- Comment #7 from jbeulich at novell dot com ---
That's why I gave the example of where this is coming from - the code obviously
wants to be able to determine whether the data block between the two labels is
empty. And no, using asm()-s for this sort of thing is about the last thing I'd
consider acceptable.

[Bug c/57725] conflicting language extensions

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:

> That's why I gave the example of where this is coming from - the code obviously
> wants to be able to determine whether the data block between the two labels is
> empty. And no, using asm()-s for this sort of thing is about the last thing I'd
> consider acceptable.

But that doesn't explain why it matters whether it's empty - why you 
aren't e.g. just iterating over objects between the labels (with an 
iteration that happens to do nothing if it's empty) or some such operation 
involving the difference between the labels (that happens to do nothing if 
the difference is 0).  It never matters whether __init_array_start and 
__init_array_end are the same, or whether they compare equal or not, for 
example, because code that uses them naturally iterates over an array 
between them.  I suppose such iterations use an ordered comparison with 
the end pointer, and comparing whether one pointer is less than another 
would work for you if you know the order the pointers would go in if 
unequal (but the compiler doesn't).

It's intrinsic to using empty objects that it *doesn't matter to your 
code* when odd things happen about objects at the same address.  If it 
matters whether addresses derived from different objects compare distinct 
(including whether it's determinate whether they compare distinct), don't 
use empty objects.

[Bug c/57725] conflicting language extensions

[jbeulich at novell dot com]

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

--- Comment #9 from jbeulich at novell dot com ---
But that's the point - the compiler takes the liberty to treat "start != end"
as always true, and "start < end" as being replaceable with "start <= end".
Hence a respective for() loop could in the first case become endless, and in
the second case be run through once when the body shouldn't be entered at all.
This is what triggered all this, and I just tried to avoid referring to a
linker script when a C example alone can demonstrate this.

I agree to you saying

> It's intrinsic to using empty objects that it *doesn't matter to your 
> code* when odd things happen about objects at the same address.  If it 
> matters whether addresses derived from different objects compare distinct 
> (including whether it's determinate whether they compare distinct), don't 
> use empty objects.

but you need to carefully distinguish this from the case where the objects just
_may_ be empty, and hence the code relies on being able to detect the
emptiness.

[Bug c/57725] conflicting language extensions

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I agree with Joseph completely, if you do this, you really have to hide the
values from the optimizers.

[Bug c/57725] conflicting language extensions

[matz at gcc dot gnu.org]

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

Michael Matz <matz at gcc dot gnu.org> changed:

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

--- Comment #11 from Michael Matz <matz at gcc dot gnu.org> ---
Maybe with Jans specific example of getting the address of objects.
But IMO he has a point when the compiler itself
introduces an equality comparison that the author didn't write (by e.g.
transforming a from<end into from<=end) because it assumes that objects are
always at different addresses.  It shouldn't so assume for objects that
potentially use the emptyness extensions.  Unfortunately the compiler can't
tell which objects use it and which don't :-/