This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: statement expressions and extended asm bug?


On Mon, Mar 15, 2004 at 03:54:43PM +0000, Nathan Sidwell wrote:
> Gunther Nikl wrote:
> >On Mon, Mar 15, 2004 at 03:20:08PM +0000, Nathan Sidwell wrote:
> 
> >>If you are asking whether
> >> ({int i; int j __asm__("d0"); volatile asm ("..." : "=r"(j)...); i = j; 
> >> i;})
> >>will DTRT, the answer is no.
> >
> >  I was considering writing it like this:
> >
> >    ({ int i = \
> >       ({int j __asm__("d0"); volatile asm ("..." : "=r"(j)...); j;}); \
> >       i; \
> >    })
> >
> >  This seems to work with 3.3+.
>
> that is equivalent to my example, the code still looks like it is undefined.

  Argh! :-( In that case it "works" now by chanceonly, right?

> Why must you assign j to register d0?

  I tried to give a simplified asm() example. The real asm code has a call
  instruction and the called function expects their arguments in certain
  registers and returns its result in "d0". To avoid the use of a stub
  function, a statement expression+extended asm is used.

  Sometime ago I thought about using a dummy asm instruction that gets all
  inputs and then making the call with a C expression. However, I don't
  think thats safe. Maybe GCC then thinks the asm instruction is dead
  and deletes it together with its inputs or inserts code between the
  asm instruction and the call clobbering inputs. Currently this seems
  to work.

  Gunther


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]