Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Till Straumann
Andreas Schwab wrote: Till Straumann <[EMAIL PROTECTED]> writes: asm volatile ("lwz %0, 16(%1)":"=r"(val):"b"(base),"m"(*reg_p)); asm volatile ("lwz%U1%X1 %0, %1":"=r"(val):"m"(*reg_p)); Hmm - that is beyond me. What exactly do %U1 and %X1 mean? I suspect that %U1 means that

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Andreas Schwab
Till Straumann <[EMAIL PROTECTED]> writes: > asm volatile ("lwz %0, 16(%1)":"=r"(val):"b"(base),"m"(*reg_p)); asm volatile ("lwz%U1%X1 %0, %1":"=r"(val):"m"(*reg_p)); Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germa

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Till Straumann
Andreas Schwab wrote: Daniel Jacobowitz <[EMAIL PROTECTED]> writes: On Mon, Mar 31, 2008 at 03:06:24PM +0200, Andreas Schwab wrote: The side effect is carried out by using %U0, which expands to u for a PRE_{INC,DEC,MODIFY} operand. There is no way to encode that in the insn operand it

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Till Straumann
Andreas Schwab wrote: Till Straumann <[EMAIL PROTECTED]> writes: /* Powerpc I/O barrier instruction */ #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); } while (0) Looking closer, your asm statement has a bug. The "m" constraint can match memory addresses with s

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Andreas Schwab
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, Mar 31, 2008 at 03:06:24PM +0200, Andreas Schwab wrote: >> The side effect is carried out by using %U0, which expands to u for a >> PRE_{INC,DEC,MODIFY} operand. There is no way to encode that in the >> insn operand itself, unlike m68k, for

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Daniel Jacobowitz
On Mon, Mar 31, 2008 at 03:06:24PM +0200, Andreas Schwab wrote: > The side effect is carried out by using %U0, which expands to u for a > PRE_{INC,DEC,MODIFY} operand. There is no way to encode that in the > insn operand itself, unlike m68k, for example. The ia64 target has a > similar issue. OK

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Andreas Schwab
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, Mar 31, 2008 at 11:19:29AM +0200, Andreas Schwab wrote: >> Till Straumann <[EMAIL PROTECTED]> writes: >> >> > /* Powerpc I/O barrier instruction */ >> > #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); } >> > while (0)

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Daniel Jacobowitz
On Mon, Mar 31, 2008 at 11:19:29AM +0200, Andreas Schwab wrote: > Till Straumann <[EMAIL PROTECTED]> writes: > > > /* Powerpc I/O barrier instruction */ > > #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); } > > while (0) > > Looking closer, your asm statement has a bug. Th

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-31 Thread Andreas Schwab
Till Straumann <[EMAIL PROTECTED]> writes: > /* Powerpc I/O barrier instruction */ > #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); } > while (0) Looking closer, your asm statement has a bug. The "m" constraint can match memory addresses with side effects (auto inc/dec),

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-27 Thread Andreas Schwab
Till Straumann <[EMAIL PROTECTED]> writes: > In any case, bad code is also produced by gcc-4.3.0 if I omit the > memory output operand and use an example that comes pretty > close to what is in the gcc info page (example illustrating > a memory input in the 'extended asm' section): Would you mind

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-26 Thread Till Straumann
Daniel Jacobowitz wrote: 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'm not yet convinced about that... /* Powerpc I/O barrier instruction */ #define EIEIO(pmem) do { asm volatile("eie

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-26 Thread Andreas Schwab
Daniel Jacobowitz <[EMAIL PROTECTED]> 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 v

Re: gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-26 Thread Daniel Jacobowitz
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. > /* Powerpc I/O barrier instruction */ > #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); } > while (0) An output memory

gcc-4.3.0/ppc32 inline assembly produces bad code

2008-03-26 Thread Till Straumann
As of gcc-4.3.0 one of my drivers stopped working. I distilled the code down to a few lines (see below). The output of gcc-4.3.0 -S -O2 -c tst.c and gcc-4.2.3 -S -O2 -c tst.c is attached. The code generated by gcc-4.2.3 is as expected. However, gcc-4.3.0 does not produce a correct resul