This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-4.3.0/ppc32 inline assembly produces bad code
- From: Andreas Schwab <schwab at suse dot de>
- To: Till Straumann <strauman at slac dot stanford dot edu>
- Cc: gcc at gcc dot gnu dot org, RTEMS List <rtems-users at rtems dot com>
- Date: Wed, 26 Mar 2008 18:06:55 +0100
- Subject: Re: gcc-4.3.0/ppc32 inline assembly produces bad code
- References: <47EA78E1.2040100@slac.stanford.edu> <20080326164039.GA6747@caradoc.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> On Wed, Mar 26, 2008 at 09:25:05AM -0700, Till Straumann wrote:
>> Is my inline assembly wrong or is this a gcc bug ?
>
> Your inline assembly seems wrong.
I don't think so.
>> /* Powerpc I/O barrier instruction */
>> #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); }
>> while (0)
>
> An output memory doesn't mean what you think.
IMHO the usage here is perfectly correct.
> I suspect GCC gave you an input memory operand as "%r0(%r9)" and an
> output memory operand as "%r9", and expected the asm to do what it
> said it would do with its operands.
The actual operands are 16(%r3) and 16(%r9). But the asm statement
correctly declares to only write to memory, and is not supposed to
change %r9 in any way.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."