* [Bug inline-asm/28635] Interaction between different asm statements
2006-08-07 15:45 [Bug inline-asm/28635] New: Interaction between different asm statements Martin dot vGagern at gmx dot net
@ 2006-08-07 15:49 ` Martin dot vGagern at gmx dot net
2006-08-07 15:53 ` [Bug target/28635] " pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Martin dot vGagern at gmx dot net @ 2006-08-07 15:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/28635] Interaction between different asm statements
2006-08-07 15:45 [Bug inline-asm/28635] New: Interaction between different asm statements Martin dot vGagern at gmx dot net
2006-08-07 15:49 ` [Bug inline-asm/28635] " Martin dot vGagern at gmx dot net
@ 2006-08-07 15:53 ` pinskia at gcc dot gnu dot org
2006-08-07 16:02 ` Martin dot vGagern at gmx dot net
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-08-07 15:53 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/28635] Interaction between different asm statements
2006-08-07 15:45 [Bug inline-asm/28635] New: Interaction between different asm statements Martin dot vGagern at gmx dot net
2006-08-07 15:49 ` [Bug inline-asm/28635] " Martin dot vGagern at gmx dot net
2006-08-07 15:53 ` [Bug target/28635] " pinskia at gcc dot gnu dot org
@ 2006-08-07 16:02 ` Martin dot vGagern at gmx dot net
2006-08-07 16:14 ` Martin dot vGagern at gmx dot net
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Martin dot vGagern at gmx dot net @ 2006-08-07 16:02 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/28635] Interaction between different asm statements
2006-08-07 15:45 [Bug inline-asm/28635] New: Interaction between different asm statements Martin dot vGagern at gmx dot net
` (2 preceding siblings ...)
2006-08-07 16:02 ` Martin dot vGagern at gmx dot net
@ 2006-08-07 16:14 ` Martin dot vGagern at gmx dot net
2006-09-22 2:24 ` acahalan at gmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Martin dot vGagern at gmx dot net @ 2006-08-07 16:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/28635] Interaction between different asm statements
2006-08-07 15:45 [Bug inline-asm/28635] New: Interaction between different asm statements Martin dot vGagern at gmx dot net
` (3 preceding siblings ...)
2006-08-07 16:14 ` Martin dot vGagern at gmx dot net
@ 2006-09-22 2:24 ` acahalan at gmail dot com
2006-09-22 7:15 ` Martin dot vGagern at gmx dot net
2009-10-03 22:03 ` [Bug libmudflap/28635] " Martin dot vGagern at gmx dot net
6 siblings, 0 replies; 8+ messages in thread
From: acahalan at gmail dot com @ 2006-09-22 2:24 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/28635] Interaction between different asm statements
2006-08-07 15:45 [Bug inline-asm/28635] New: Interaction between different asm statements Martin dot vGagern at gmx dot net
` (4 preceding siblings ...)
2006-09-22 2:24 ` acahalan at gmail dot com
@ 2006-09-22 7:15 ` Martin dot vGagern at gmx dot net
2009-10-03 22:03 ` [Bug libmudflap/28635] " Martin dot vGagern at gmx dot net
6 siblings, 0 replies; 8+ messages in thread
From: Martin dot vGagern at gmx dot net @ 2006-09-22 7:15 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libmudflap/28635] Interaction between different asm statements
2006-08-07 15:45 [Bug inline-asm/28635] New: Interaction between different asm statements Martin dot vGagern at gmx dot net
` (5 preceding siblings ...)
2006-09-22 7:15 ` Martin dot vGagern at gmx dot net
@ 2009-10-03 22:03 ` Martin dot vGagern at gmx dot net
6 siblings, 0 replies; 8+ messages in thread
From: Martin dot vGagern at gmx dot net @ 2009-10-03 22:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 8+ messages in thread