User account creation filtered due to spam.

Bug 24332 - asm label declaration may be missing aliasing info
Summary: asm label declaration may be missing aliasing info
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.3.2
: P2 normal
Target Milestone: ---
Assignee: Jan Hubicka
Keywords: accepts-invalid
Depends on: 25140
  Show dependency treegraph
Reported: 2005-10-12 15:33 UTC by Chris Bowler
Modified: 2015-12-09 06:27 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2012-01-11 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Chris Bowler 2005-10-12 15:33:44 UTC
sparky% gcc -v
Reading specs from /.../
Configured with: ../gcc-3.3.2/configure --disable-nls
Thread model: aix
gcc version 3.3.2


int j asm("i");
int i;

int main() {
  i = 5;
  j = 6;
  int k = i;
  j = 7;
  return k;

sparky% gcc t.c
sparky% a.out
sparky% echo $?
sparky% gcc t.c -O
sparky% a.out
sparky% echo $?

In the opt case I expect a result of 6.

The problem, I suspect, is that the compiler is not aliasing 'i' and 'j' to each other for the optimizer.  The write 'j=6' appears dead in this case, and the optimizer is likely to remove it.

You may consider this user error, however, the compiler is able to detect this problem because it knows 'i' and 'j' have the same symbol name.  Consequently I suggest either an error diagnostic be issued, or the symbols should be aliased together for the optimizer.
Comment 1 Andrew Pinski 2005-10-12 16:08:39 UTC
This is a weird case as both are in common space.

If we do the following:
int j asm("i") = 0;
int i = 0;

We cannot assemble the source at all.

I don't know what to say about this case.  Someone else will have to comment on it.

But IIRC asm("xxx"); just renames the variable and gives no other information to GCC.
Comment 2 Jim Wilson 2005-10-12 23:22:00 UTC
It isn't true that variable i and variable j have the same symbol name.  The asm means that the symbol name of j will be "i" always.  However, the symbol name of i will be the string "i" with various target dependent and command line option dependent transformations applied.

The easiest way to see this is to compile with -fleading-underscore and note that we now have two variables "i" and "_i", and there is no aliasing.  -fleading-underscore is the default for some targets.

Since these symbol name string transformations are applied late, when emitting assembly language, it currently isn't possible for the compiler to do anything useful here.

Also, like most GCC extensions, no one probably considered the implications of what should happen with an input like this, so we can't really do much more than say that it is undefined, and that you can't expect any particular behaviour here.

Ideally we should emit an error message, but it is probably not possible with current sources, and probably not worth the trouble to rewrite to make it possible.
Comment 3 Richard Biener 2009-09-26 11:30:41 UTC
Undefined / invalid.

There is no sensible way to deal with aliasing here without pessimizing every
legitimate use.
Comment 4 Richard Biener 2010-05-09 16:51:40 UTC
If we'd have a symbol table we could detect the clash and emit a diagnostic.
Comment 5 Richard Biener 2012-01-11 14:49:16 UTC
Confirmed.  Though

int j asm("i");
int i;

is probably as valid as

int i;
int i;

if we decide so.  With two initializers it gets invalid (same with -fno-common?).
Comment 6 Jan Hubicka 2015-12-09 06:27:11 UTC
With transparent aliases we should be able to handle these cases now.