[Bug inline-asm/28635] New: Interaction between different asm statements

[Bug inline-asm/28635] New: Interaction between different asm statements

[Martin dot vGagern at gmx dot net]

I was experimenting with the way gcc does register allocation depending on
different flags. I encountered one strange test file where adding a second asm
statement made a first one fail which did work before. Even stranger, when I
have both parts as separate functions before, the combined version compiles as
well. This interdependence between asm statements seems extremely
counterintuitive to me, and might cause difficult to find bugs in larger
projects.

The fact that omitting optimization causes my code to fail even for the version
including the single asm statements makes this bug seem related to bug 11203.
But the behaviour that some code does not compile even with optimizations, and
that adding some functions makes those parts compile as well, are strange
things not mentioned in that bug, so don't be hasty about marking this a
duplicate.

My compiler is a Gentoo build. I know you would love to make me reproduce this
with a plain vanilla compiler, but I beg you to simply compile my attached test
case with your version. If you can't reproduce the bug, I'll happily take this
to the gentoo bugzilla. But I expect the cause rather deep inside the sources,
nothing likely to be changed by some distribution patch set.


-- 
           Summary: Interaction between different asm statements
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Martin dot vGagern at gmx dot net
 GCC build triplet: i686-pc-linux-gnu-gcc
  GCC host triplet: i686-pc-linux-gnu-gcc
GCC target triplet: i686-pc-linux-gnu-gcc


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

[Bug inline-asm/28635] Interaction between different asm statements

[Martin dot vGagern at gmx dot net]

------- Comment #1 from Martin dot vGagern at gmx dot net  2006-08-07 15:49 -------
Created an attachment (id=12038)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12038&action=view)
Testcase demonstrating interference between assembler statements

This test case exhibits the following behaviour on 4.1.1 as well as 3.4.6:

-O1 -fPIC -fomit-frame-pointer -DDO_SINGLE
 X    -            -                -      works
 X    X            -                -      expected errors
 X    -            X                -      works
 X    X            X                X      works
 X    X            X                -      fails: error in both:54
 -    X            X                X      fails: error in f1:25

In the two cases marked failures, the error message is the following:
can't find a register in class `GENERAL_REGS' while reloading `asm'


-- 


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

[Bug target/28635] Interaction between different asm statements

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-07 15:53 -------
I bet this is not a bug.  x86 is known to be very register starved.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|inline-asm                  |target


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

[Bug target/28635] Interaction between different asm statements

[Martin dot vGagern at gmx dot net]

------- Comment #3 from Martin dot vGagern at gmx dot net  2006-08-07 16:02 -------
One more observation: I tried adding the flags corresponding to -O1 according
to the info page:

-fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers
-floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -fmerge-constants

The effect for my example is the same as -O0, not -O1, so the cause for the
different behaviour must be some optimization included in -O1 and not
corresponding to one of the mentioned flags.


-- 


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

[Bug target/28635] Interaction between different asm statements

[Martin dot vGagern at gmx dot net]

------- Comment #4 from Martin dot vGagern at gmx dot net  2006-08-07 16:14 -------
(In reply to comment #2)
> I bet this is not a bug.  x86 is known to be very register starved.

Yes, I know that. But this situation does not explain, why adding two more
functions containing the asm statements separately suddenly causes the combined
version to work as expected. It's not like including those functions suddenly
caused my x86 to grow additional registers, after all... :-)

I still don't see why my code should not compile even for register starved x86.
Including the -fomit-frame-pointer optimization should allow using the ebp
register at least for leaf functions. So I should have six registers at hand to
use as I please, and gcc should know about this and allow using them all,
especially since the constraints are all the same, so that any mapping between
variables and registers should work equally well.

I forgot to mention, the combination without optimization and with neither
-fPIC nor -fomit-frame-pointer works well enough. So why is ebp handled so
different from ebx if the frame pointer can be omitted for the function in
question?
And I know I repeat myself, but why does adding the single functions help?


-- 


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

[Bug target/28635] Interaction between different asm statements

[acahalan at gmail dot com]

------- Comment #5 from acahalan at gmail dot com  2006-09-22 02:24 -------
(In reply to comment #4)
> I still don't see why my code should not compile even for register starved x86.
> Including the -fomit-frame-pointer optimization should allow using the ebp
> register at least for leaf functions. So I should have six registers at hand to
> use as I please, and gcc should know about this and allow using them all,
> especially since the constraints are all the same, so that any mapping between
> variables and registers should work equally well.

IMHO you should have at least 7 registers available. Both ebp and ebx can be
saved to the stack.

In many cases, the use of esp should also work. Obviously the user would be
responsible for ensuring that signals/exceptions/interrupts are not a problem,
perhaps simply by ensuring that esp points to an area with some free space
below it. If there is some other free register with which gcc can do an xchg
instruction, the problem is solvable. If there are two free MMX or XMM
registers, the problem is solvable. Non-threaded code can simply store esp in a
memory location. Threaded code can be handled via xchg with a user-specified
memory location in the fs or gs segment; the default should be suitable for the
normal pthreads library if possible.

Probably esp should never be automatically allocated. It's better to make the
user specify esp because that is the only way to ensure that
signals/exceptions/interrupts won't corrupt anything. There is no reason to
restrict ebx and ebp in this way, although ebp without -fomit-frame-pointer
should be the least-desirable choice.

It is entirely legit to use registers this way. On a UNIX-like system,
sigaltstack() can be used to ensure that signals do not arrive on the normal
stack. The user could also just mask all signals. Win32 doesn't muck with the
stack unless you do something that is like a SIGSEGV. Using the push/pop
instructions to deal with an array can be a useful hack. If the user accepts
the restrictions of an active stack, then they can even leave the
signals/exceptions/interrupts as normal.


-- 


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

[Bug target/28635] Interaction between different asm statements

[Martin dot vGagern at gmx dot net]

------- Comment #6 from Martin dot vGagern at gmx dot net  2006-09-22 07:14 -------
Comparing this issue here with bug 28686 I noticed that the code of the
functions before the one containing both assembly blocks is completely
irrelevant. So even if you only have one empty function in the DO_SINGLE block,
enabling that part still makes things compile whereas disabling it causes the
described error.

So there probably is no interaction between assembly statements in different
functions. However inline assembly compiles differently if there is another
function preceding the one with the assembly code. An empty function following
the one with the asm statement does not have this effect.

And there is still some interference between the two asm statements in function
both(), as this function containing both of them fails while in the original
test case, the function f1() containing only the one where the error is
reported, again without preceding function, compiles cleanly. So two asm
statements in one function still do interact in some nonintuitive way.

(In reply to comment #5)
> IMHO you should have at least 7 registers available.

Some of this is discussed in bug 11807. I'd agree it would be nice to have all
registers. But I'd not want this problem report here turn into yet another
discussion of which registers should be usable by asm and which not.

I'd rather stick to the point, that allocating a given number of registers
sometimes works and sometimes does not, for exactly the same asm statement and
even the same optimization flags, depending on bizarre outer circumstances like
a preceding function or a following second asm statement.


-- 


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

[Bug libmudflap/28635] Interaction between different asm statements

[Martin dot vGagern at gmx dot net]

------- Comment #7 from Martin dot vGagern at gmx dot net  2009-10-03 22:03 -------
Seems gcc 4.1.1 no longer has this kind of problems: all cases except for the
one with the expected failure do compile, and generated assembler looks sane at
first glance.


-- 

Martin dot vGagern at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |libmudflap


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