decl_conflicts_with_clobbers_p problem

decl_conflicts_with_clobbers_p problem

[Gunther Nikl]

Hello!

I am using a port (not the repository) that uses asm() statements to
access system functions. This is an example how its done (its for m68k):

--cut--
#define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
({								\
   t1 _##name##_v1 = (v1);					\
   {								\
      register void *const _##name##_bn __asm("a6") = (bn);	\
      register t1 _n1 __asm(#r1) = _##name##_v1;		\
      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : /* no output */						\
      : "r" (_##name##_bn), "rf"(_n1)				\
      : "d0", "d1", "a0", "a1", "fp0", "fp1", "cc", "memory");	\
   }								\
})

#define SendIO(ioRequest) \
	LP1NR(0x1ce, SendIO, struct IORequest *, ioRequest, a1, \
	, EXEC_BASE_NAME)
--cut--

The clobber list contains all registers that can be changed by a system
function as defined by the system ABI. In this example the system function
expects its argument in register "a1". Thus the value for _n1 is bound to
register "a1" and passed as an input to the asm() statement. With GCC 3.3
the asm statement is rejected because of overlapping inputs and clobbers :-(
For me the asm statememt looks fine because I must pass the argument in
register "a1" and its correct that the contents of register "a1" cannot be
relied on after the call anymore.
Is the example asm statement wrong or is decl_conflicts_with_clobbers_p()
wrong?

Regards,
Gunther Nikl

Re: decl_conflicts_with_clobbers_p problem

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

|> The clobber list contains all registers that can be changed by a system
|> function as defined by the system ABI. In this example the system function
|> expects its argument in register "a1". Thus the value for _n1 is bound to
|> register "a1" and passed as an input to the asm() statement. With GCC 3.3
|> the asm statement is rejected because of overlapping inputs and clobbers :-(
|> For me the asm statememt looks fine because I must pass the argument in
|> register "a1" and its correct that the contents of register "a1" cannot be
|> relied on after the call anymore.
|> Is the example asm statement wrong or is decl_conflicts_with_clobbers_p()
|> wrong?

Just list _n1 as an output operand.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: decl_conflicts_with_clobbers_p problem

[Gunther Nikl]

On Thu, Mar 13, 2003 at 11:06:11AM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> |> The clobber list contains all registers that can be changed by a system
> |> function as defined by the system ABI. In this example the system function
> |> expects its argument in register "a1". Thus the value for _n1 is bound to
> |> register "a1" and passed as an input to the asm() statement. With GCC 3.3
> |> the asm statement is rejected because of overlapping inputs and clobbers :-(
> |> For me the asm statememt looks fine because I must pass the argument in
> |> register "a1" and its correct that the contents of register "a1" cannot be
> |> relied on after the call anymore.
> |> Is the example asm statement wrong or is decl_conflicts_with_clobbers_p()
> |> wrong?
> 
> Just list _n1 as an output operand.

Sorry, but I don't understand that suggestion. Why is that supposed to help?
Then, it doesn't look like a generic solution because the register which is
used to pass the argument is an argument to the macro itself and it can be
any register not just the ones in the clobber list. Eg. if its "d[2-7]" or
"a[2-6]" then the value passed is preserved by the system function.

Gunther

Re: decl_conflicts_with_clobbers_p problem

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

|> On Thu, Mar 13, 2003 at 11:06:11AM +0100, Andreas Schwab wrote:
|> > Gunther Nikl <gni@gecko.de> writes:
|> > 
|> > |> The clobber list contains all registers that can be changed by a system
|> > |> function as defined by the system ABI. In this example the system function
|> > |> expects its argument in register "a1". Thus the value for _n1 is bound to
|> > |> register "a1" and passed as an input to the asm() statement. With GCC 3.3
|> > |> the asm statement is rejected because of overlapping inputs and clobbers :-(
|> > |> For me the asm statememt looks fine because I must pass the argument in
|> > |> register "a1" and its correct that the contents of register "a1" cannot be
|> > |> relied on after the call anymore.
|> > |> Is the example asm statement wrong or is decl_conflicts_with_clobbers_p()
|> > |> wrong?
|> > 
|> > Just list _n1 as an output operand.
|> 
|> Sorry, but I don't understand that suggestion. Why is that supposed to
|> help?

To tell the compiler that _n1 is an output operand, which in fact it is.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: decl_conflicts_with_clobbers_p problem

[Gunther Nikl]

On Thu, Mar 13, 2003 at 12:21:36PM +0100, Andreas Schwab wrote:
> To tell the compiler that _n1 is an output operand, which in fact it is.

Would this be legal (the 0x0xDEADBEAF is meant as a test)?

--cut--
#define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
({								\
   t1 _##name##_v1 = (v1);					\
   {								\
      register int _d0 __asm("d0") = 0xDEADBEAF;		\
      register int _d1 __asm("d1") = 0xDEADBEAF;		\
      register int _a0 __asm("a0") = 0xDEADBEAF;		\
      register int _a1 __asm("a1") = 0xDEADBEAF;		\
      register void *const _##name##_bn __asm("a6") = (bn);	\
      register t1 _n1 __asm(#r1) = _##name##_v1;		\
      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : "=r" (_d0), "=r" (_d1), "=r" (_a0), "=r" (_a1)		\
      : "r" (_##name##_bn), "rf"(_n1)				\
      : "fp0", "fp1", "cc", "memory");				\
   }								\
})
#define SendIO(ioRequest) \
	LP1NR(0x1ce, SendIO, void *, ioRequest, a1, \
	, EXEC_BASE_NAME)
--cut--

Gunther Nikl

Re: decl_conflicts_with_clobbers_p problem

[Hans-Peter Nilsson]

> Date: Thu, 13 Mar 2003 10:17:32 +0100
> From: Gunther Nikl <gni@gecko.de>

> I am using a port (not the repository) that uses asm() statements to
> access system functions. This is an example how its done (its for m68k):

> #define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
> ({								\
>    t1 _##name##_v1 = (v1);					\
>    {								\
>       register void *const _##name##_bn __asm("a6") = (bn);	\
>       register t1 _n1 __asm(#r1) = _##name##_v1;		\
>       __asm volatile ("jsr a6@(-"#offs":W)"			\
>       : /* no output */						\
>       : "r" (_##name##_bn), "rf"(_n1)				\
>       : "d0", "d1", "a0", "a1", "fp0", "fp1", "cc", "memory");	\
>    }								\
> })
> 
> #define SendIO(ioRequest) \
> 	LP1NR(0x1ce, SendIO, struct IORequest *, ioRequest, a1, \
> 	, EXEC_BASE_NAME)

If you have control over the system, I suggest consider passing
all parameters in the same register to avoid confusion, for
programmers more than for GCC. ;-)  But I assume you don't.
Still, consider a solution where you do not need to specify
matching register name *and* system call in the macro.  It's a
recipe for bugs.  Instead parametrize the register name on the
syscall name.

> The clobber list contains all registers that can be changed by a system
> function as defined by the system ABI.

The clobber list must not contain inputs nor outputs.

> In this example the system function
> expects its argument in register "a1". Thus the value for _n1 is bound to
> register "a1" and passed as an input to the asm() statement.

With the actual register name *as a parameter*, it seems.  No,
you can't parametrize it simply like that.  Why not use
different macros, since you list the register at the point of
the macro call anyway?  Or without code changes elsewhere than
the macro definition, use a trick like
 #define LP1NR(offs, name, t1, v1, r1, bt, bn) LP1NR_##r1 (offs, name, t1, v1, bt, bn)
and define different
 #define LP1NR_a1(offs, name, t1, v1, r1, bt, bn) ...
 #define LP1NR_d0(offs, name, t1, v1, r1, bt, bn) ...
with contents where each different "r1" is listed as output and
not in the clobber list?  Or just parametrize the clobber list?
See below for examples.

> With GCC 3.3
> the asm statement is rejected because of overlapping inputs and clobbers :-(
> For me the asm statememt looks fine because I must pass the argument in
> register "a1" and its correct that the contents of register "a1" cannot be
> relied on after the call anymore.

The manual (Node "Extended Asm", "Assembler Instructions with C
Expression Operands") says: "you may not write a clobber
description in a way that overlaps with an input or output
operand" and "there is no way for you to specify that an input
operand is modified without also specifying it as an output
operand".  It said this *before* the decl_conflicts_with_clobbers_p
change.

So the asm doesn't look "fine" to me.

> Is the example asm statement wrong

Yes.

> or is decl_conflicts_with_clobbers_p()
> wrong?

No; the declaration *does* conflict with the clobbers, so the
function does its job.

You *have* to list the register that is changed as output.  This
is not really a change; your asm was in error before too, GCC
just didn't notice; it'd silently generated wrong code instead.
See <URL:http://gcc.gnu.org/ml/gcc/2002-09/msg00741.html>.  See
also discussion some years ago about the corresponding i386
construct (where the constraint letters were the cause of the
overlap).


In your later email, you listed your "inputs" *only* as asm
outputs.  That is also wrong.  Here's an example LP1NR_a1, which
I hope is right.  I removed the "name" parameter since it seemed
unnecessary and just confusing:

#define LP1NR_a1(offs, name, t1, v1, bt, bn)			\
({								\
   t1 _v1 = (v1);						\
   {								\
      register void *const _bn __asm("a6") = (bn);		\
      register t1 _n1 __asm("a1") = _v1;			\
      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : "=r" (_n1)						\
      : "r" (_bn), "0" (_n1)					\
      : "d0", "d1", "a0", "fp0", "fp1", "cc", "memory");	\
   }								\
})

Or perhaps it would be sufficient to just change the clobber
list into a macro:

#define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
({								\
   t1 _##name##_v1 = (v1);					\
   {								\
      register void *const _##name##_bn __asm("a6") = (bn);	\
      register t1 _n1 __asm(#r1) = _##name##_v1;		\
      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : /* no output */						\
      : "r" (_##name##_bn), "rf"(_n1)				\
      : CLOBBER_LIST_EXCLUDING_##r1;				\
   }								\
})

with
#define CLOBBER_LIST_EXCLUDING_a1 \
 "d0", "d1", "a0", "fp0", "fp1", "cc", "memory"
etc.

brgds, H-P

Re: decl_conflicts_with_clobbers_p problem

[Gunther Nikl]

On Thu, Mar 13, 2003 at 06:04:53PM +0100, Hans-Peter Nilsson wrote:
> > #define SendIO(ioRequest) \
> > 	LP1NR(0x1ce, SendIO, struct IORequest *, ioRequest, a1, \
> > 	, EXEC_BASE_NAME)
> 
> If you have control over the system, I suggest consider passing
> all parameters in the same register to avoid confusion, for
> programmers more than for GCC. ;-)

  The progammer cannot (hopefully! :) get confused because he includes an
  appropriate header for the system module where all the magic is done.
  That header is generated from a description file listing all module
  functions with their arguments and into which register they belong.

>  But I assume you don't.

  ;-)

> Still, consider a solution where you do not need to specify
> matching register name *and* system call in the macro.  It's a
> recipe for bugs.

  AFAIK, it was done to be able to use these generic LP* macros. There
  are much macros like that taking more arguments.

> Instead parametrize the register name on the syscall name.

  This is tedious because every function has a different requirement.
  The example function used "a1" other might use "d0", "d1" or "d0"
  and "a0" or ... The system ABI defines "d0", "d1", "a0" and "a1" as
  scratch registers, thats why they are listed in the clobber list.

> > The clobber list contains all registers that can be changed by a system
> > function as defined by the system ABI.
> 
> The clobber list must not contain inputs nor outputs.

  I have read the paragraph about extended asm in the manual again.

> > In this example the system function
> > expects its argument in register "a1". Thus the value for _n1 is bound to
> > register "a1" and passed as an input to the asm() statement.
> 
> With the actual register name *as a parameter*, it seems.

  Yes.

> No, you can't parametrize it simply like that.

  Thats unfortunate :-(

> Why not use different macros, since you list the register at the point of
> the macro call anyway?

  Because it was meant to be generic macros.

> Or without code changes elsewhere than
> the macro definition, use a trick like
>  #define LP1NR(offs, name, t1, v1, r1, bt, bn) LP1NR_##r1 (offs, name, t1, v1, bt, bn)
> and define different
>  #define LP1NR_a1(offs, name, t1, v1, r1, bt, bn) ...
>  #define LP1NR_d0(offs, name, t1, v1, r1, bt, bn) ...
> with contents where each different "r1" is listed as output and
> not in the clobber list?  Or just parametrize the clobber list?

  This would result in a lot of macros because the arguments are in a
  "random" order and unpredictable.
  
> The manual (Node "Extended Asm", "Assembler Instructions with C
> Expression Operands") says: "you may not write a clobber
> description in a way that overlaps with an input or output
> operand" and "there is no way for you to specify that an input
> operand is modified without also specifying it as an output
> operand".  It said this *before* the decl_conflicts_with_clobbers_p
> change.

  Yes, you are right. That was in the documentation before. Now I realize
  that the topic is wrong. Actually its a question about "extended asm".
  decl_conflicts_with_clobbers_p() does "only" catch that error now.

> No; the declaration *does* conflict with the clobbers, so the
> function does its job.

  Yes. Regarding the documentation, it does only state overlaps are
  invalid. I understand that for output operands (the system uses "d0"
  to return a result which might be used as an input too). But why is
  this also required for input operands? The registers listed in the
  clobbers are scratch registers in the ABI. I was under the impression
  clobbers mean registers that are undefined *after* the asm. I don't
  understand the conflict with inputs.

> You *have* to list the register that is changed as output.  This
> is not really a change; your asm was in error before too, GCC
> just didn't notice; it'd silently generated wrong code instead.

  Yes, according the (3.x?) documentation the asm is wrong. However, I have
  never seen incorrect code beeing generated (which doesn't prove anything,
  granted) and I have used GCC alot on the system in question where these
  asm statements are required.
  (Well, its posible to use stubs but make the calls "inline" is much morf
   efficient).

> In your later email, you listed your "inputs" *only* as asm
> outputs.  That is also wrong.

  You mean the example with the additional local register variables only
  used in the output line? GCC accepted it. I hoped that this would fulfill
  the constraints of extended asm statements :-(

> Here's an example LP1NR_a1, which I hope is right.  I removed the "name"
> parameter since it seemed unnecessary and just confusing:

  It is meant to make the variable names unique and to not shadow outer
  variables. Using the function name seems to be good idea for that. Maybe
  thats not an issue.

> #define LP1NR_a1(offs, name, t1, v1, bt, bn)			\
> ({								\
>    t1 _v1 = (v1);						\
>    {								\
>       register void *const _bn __asm("a6") = (bn);		\
>       register t1 _n1 __asm("a1") = _v1;			\
>       __asm volatile ("jsr a6@(-"#offs":W)"			\
>       : "=r" (_n1)						\
>       : "r" (_bn), "0" (_n1)					\
>       : "d0", "d1", "a0", "fp0", "fp1", "cc", "memory");	\
>    }								\
> })

  Since I don't know that _n1 is bound to "a1" thats not a solution.

> Or perhaps it would be sufficient to just change the clobber
> list into a macro:
> 
> #define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
> ({								\
>    t1 _##name##_v1 = (v1);					\
>    {								\
>       register void *const _##name##_bn __asm("a6") = (bn);	\
>       register t1 _n1 __asm(#r1) = _##name##_v1;		\
>       __asm volatile ("jsr a6@(-"#offs":W)"			\
>       : /* no output */					\
>       : "r" (_##name##_bn), "rf"(_n1)				\
>       : CLOBBER_LIST_EXCLUDING_##r1;				\
>    }								\
> })
> 
> with
> #define CLOBBER_LIST_EXCLUDING_a1 \
>  "d0", "d1", "a0", "fp0", "fp1", "cc", "memory"

  As already said, this doesn't work either since I have no control over the
  registers passed. There can be non-scratch ones too.

  I guess creating an appropriate macro for every function is the only
  viable solution.

  Gunther

Re: decl_conflicts_with_clobbers_p problem

[Hans-Peter Nilsson]

> Date: Fri, 14 Mar 2003 12:21:18 +0100
> From: Gunther Nikl <gni@gecko.de>

> > Or without code changes elsewhere than
> > the macro definition, use a trick like
> >  #define LP1NR(offs, name, t1, v1, r1, bt, bn) LP1NR_##r1 (offs, name, t1, v1, bt, bn)
> > and define different
> >  #define LP1NR_a1(offs, name, t1, v1, r1, bt, bn) ...
> >  #define LP1NR_d0(offs, name, t1, v1, r1, bt, bn) ...
> > with contents where each different "r1" is listed as output and
> > not in the clobber list?  Or just parametrize the clobber list?
> 
>   This would result in a lot of macros because the arguments are in a
>   "random" order and unpredictable.

So there's not just *one* register, as was in your example?
That information was missing from your email.  Sorry, then I'm
all out of suggestions.

> > You *have* to list the register that is changed as output.  This
> > is not really a change; your asm was in error before too, GCC
> > just didn't notice; it'd silently generated wrong code instead.
> 
>   Yes, according the (3.x?) documentation the asm is wrong.

As I said, the documentation also said that before the error
message was implemented.

> However, I have
>   never seen incorrect code beeing generated (which doesn't prove anything,
>   granted) and I have used GCC alot on the system in question where these
>   asm statements are required.

Well, a programmer here saw it happen.  See the URL I quoted.
That's really enough, isn't it?  Having GCC corrected to work
according to the documentation saves *you* the trouble to trip
over a code-generation compiler bug.  I can't really understand
your argument.

>   I guess creating an appropriate macro for every function is the only
>   viable solution.

Well, good, you found a solution.

brgds, H-P

Re: decl_conflicts_with_clobbers_p problem

[Gunther Nikl]

On Fri, Mar 14, 2003 at 01:14:52PM +0100, Hans-Peter Nilsson wrote:
> > Date: Fri, 14 Mar 2003 12:21:18 +0100
> > From: Gunther Nikl <gni@gecko.de>
> 
> > > Or without code changes elsewhere than
> > > the macro definition, use a trick like
> > >  #define LP1NR(offs, name, t1, v1, r1, bt, bn) LP1NR_##r1 (offs, name, t1, v1, bt, bn)
> > > and define different
> > >  #define LP1NR_a1(offs, name, t1, v1, r1, bt, bn) ...
> > >  #define LP1NR_d0(offs, name, t1, v1, r1, bt, bn) ...
> > > with contents where each different "r1" is listed as output and
> > > not in the clobber list?  Or just parametrize the clobber list?
> > 
> >   This would result in a lot of macros because the arguments are in a
> >   "random" order and unpredictable.
> 
> So there's not just *one* register, as was in your example?

  That was only an example. I thought I made that clear. Sorry, that I
  wasn't.

> >   Yes, according the (3.x?) documentation the asm is wrong.
> 
> As I said, the documentation also said that before the error
> message was implemented.

  I didn't question that.

> > However, I have
> >   never seen incorrect code beeing generated (which doesn't prove anything,
> >   granted) and I have used GCC alot on the system in question where these
> >   asm statements are required.
> 
> Well, a programmer here saw it happen.  See the URL I quoted.

  I have. Its slightly different to my asm statement(s). My asm constructs
  place its arguments in the destination registers before the asm using
  local register variables. The asm (which is a function call only)
  invalidates some input registers (the scratch ones if there are any).
  Note: thats what the asm was _supposed_ to do. I understand that the
  asm statement is invalid according to the documentation.

> That's really enough, isn't it?  Having GCC corrected to work
> according to the documentation saves *you* the trouble to trip
> over a code-generation compiler bug.

  I don't question that either.

> I can't really understand your argument.

  It wasn't meant as an argument. I did only state _my_ experience with
  extended asm statements with overlaps (of clobbers and inputs). Inputs
  for an asm placed in local register variables aren't mentioned in the
  GCC documentation prior to 3.0. GCC catching errors at compile time is
  appreciated.

> >   I guess creating an appropriate macro for every function is the only
> >   viable solution.
> 
> Well, good, you found a solution.

  I am not sure anymore that I have a solution. :-(

  Lets look at you proposed macros again first:

      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : "=r" (_n1)						\
      : "r" (_bn), "0" (_n1)					\
      : "d0", "d1", "a0", "fp0", "fp1", "cc", "memory");	\

  All scratches are marked as clobbered (except the _n1 register). Input
  _n1 has the "0" constraint. Is that necessary (also for other inputs
  if its in an register found in the clobber list) to really invalidate
  the register? What if I have two local register vars assigned to the
  same register with one being (only) input and one being (only) output?

      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : /* no output */						\
      : "r" (_##name##_bn), "rf"(_n1)				\
      : CLOBBER_LIST_EXCLUDING_##r1;				\

  I think the contents of "r1" which is bound to _n1 isn't invalidated
  here but thats what I need or the compiler might use the value in r1
  after the asm which would be wrong.

  You didn't answer my question why having outputs which are not used as
  inputs is wrong. Could you please explain that? I have read the paragraph
  about extended asm multiple times now and I can't find a passage that
  forbids this. I do understand extended asm better than before but I still
  have problems (maybe because english isn't my native tongue). Extended
  asm is a really complicate issue. I wish I could do without.

  Nethertheless, I would really really like to know, why overlaps of
  clobbers with inputs isn't allowed. Yes, its documented but without
  any explanation. It only says:

   "You may not write a clobber description in a way that overlaps with
    an input or output operand. [...] Variables declared to live in specific
    registers (*note Explicit Reg Vars::), and used as asm input or output
    operands must have no part mentioned in the clobber description. There
    is no way for you to specify that an input operand is modified without
    also specifying it as an output operand."

  Overlaps might cause incorrect code to be generated as your example shows.
  Ok, for outputs wich are marked as clobbered. Why do inputs marked as
  clobbered pose problems? All I want to know is why GCC imposes this
  restriction. And ofcourse I am search for a solution for my problem.

  Thank you,
  Gunther Nikl

Re: decl_conflicts_with_clobbers_p problem

[Hans-Peter Nilsson]

> Date: Fri, 14 Mar 2003 15:53:41 +0100
> From: Gunther Nikl <gni@gecko.de>

> > >   I guess creating an appropriate macro for every function is the only
> > >   viable solution.
> > 
> > Well, good, you found a solution.
> 
>   I am not sure anymore that I have a solution. :-(

Why can't you define one different macro for each syscall that
takes a different set of input, output and clobber registers?
What's so hard about that?  For example, that's how the Linux
syscalls are usually implemented (though the parametrization is
expressed as the number of parameters).

>   Lets look at you proposed macros again first:
> 
>       __asm volatile ("jsr a6@(-"#offs":W)"			\
>       : "=r" (_n1)						\
>       : "r" (_bn), "0" (_n1)					\
>       : "d0", "d1", "a0", "fp0", "fp1", "cc", "memory");	\
> 
>   All scratches are marked as clobbered (except the _n1
> register).

The _n1 in the example has to be a register not mentioned in the
clobber list.

> Input
>   _n1 has the "0" constraint. Is that necessary (also for other inputs
>   if its in an register found in the clobber list)

You must not specify it in the clobber list too.  In this
example which you cut down, it's "a1".

> to really invalidate
>   the register?

You mark it as set by the output.  Since the macro does not use
_n1 afterwards, you get the effect you want.

> What if I have two local register vars assigned to the
>   same register with one being (only) input and one being (only) output?

What's unclear?  One will get assigned the output, and the other
will be passing the input value.  No ambiguity, no collision.
If there's a bug, please report.

>       __asm volatile ("jsr a6@(-"#offs":W)"			\
>       : /* no output */						\
>       : "r" (_##name##_bn), "rf"(_n1)				\
>       : CLOBBER_LIST_EXCLUDING_##r1;				\
> 
>   I think the contents of "r1" which is bound to _n1 isn't invalidated
>   here but thats what I need or the compiler might use the value in r1
>   after the asm which would be wrong.

Correct; I forgot to change inputs and outputs in that example.
Sorry about that and good that you found it out by yourself.

>   You didn't answer my question why having outputs which are not used as
>   inputs is wrong. Could you please explain that?

No, that's not wrong.  But IIRC you wanted to specify the inputs
as (only) *outputs* in the code you sent as a follow-up, and
*that* was wrong.

> I have read the paragraph
>   about extended asm multiple times now and I can't find a passage that
>   forbids this. I do understand extended asm better than before but I still
>   have problems (maybe because english isn't my native tongue). Extended
>   asm is a really complicate issue. I wish I could do without.

Then implement the construct as a function attribute or builtin
in your port ;-) (Which you say is not in CVS; but isn't it
actually m68k?)

>   Nethertheless, I would really really like to know, why overlaps of
>   clobbers with inputs isn't allowed. Yes, its documented but without
>   any explanation.

Isn't it enough that it simplifes the rules?  What if it was
allowed?  That'd introduce ambiguities and inconsistency with
the corresponding single-register-class-constraint construct.  I
wrote about that in enough detail in the URL I sent.

Anyway, I'm satisfied with the current implementation and rules.
I've explained to you in enough detail why the code I wrote to
identify erroneous asm use is correct when it reports that your
code is wrong.  I don't have to solve your coding problem.
Still, I've made suggestions that should help you get on the
track.  I'm done.

If you're not happy with the asm semantics, the burden falls on
you to provide argumentation and documentation for what should
happen instead, together with test-cases and patches to
implement that.

brgds, H-P

extended asm (Was: Re: decl_conflicts_with_clobbers_p problem)

[Gunther Nikl]

On Fri, Mar 14, 2003 at 05:32:56PM +0100, Hans-Peter Nilsson wrote:
> Why can't you define one different macro for each syscall that
> takes a different set of input, output and clobber registers?

  Well, thats certainly possible. Before I use that approach I tried to
  find a solution (if possible at all) with the currently used approach.
  I believe thats a normal behaviour.

> > What if I have two local register vars assigned to the
> >   same register with one being (only) input and one being (only) output?
> 
> What's unclear?  One will get assigned the output, and the other
> will be passing the input value.  No ambiguity, no collision.

  Good.

> >   You didn't answer my question why having outputs which are not used
> >   as inputs is wrong. Could you please explain that?
> 
> No, that's not wrong.  But IIRC you wanted to specify the inputs
> as (only) *outputs* in the code you sent as a follow-up, and
> *that* was wrong.

  Now, that confuses me again. Here is the follow-up again:

--cut--
#define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
({								\
   t1 _##name##_v1 = (v1);					\
   {								\
      register int _d0 __asm("d0") = 0xDEADBEAF;		\
      register int _d1 __asm("d1") = 0xDEADBEAF;		\
      register int _a0 __asm("a0") = 0xDEADBEAF;		\
      register int _a1 __asm("a1") = 0xDEADBEAF;		\
      register void *const _##name##_bn __asm("a6") = (bn);	\
      register t1 _n1 __asm(#r1) = _##name##_v1;		\
      __asm volatile ("jsr a6@(-"#offs":W)"			\
      : "=r" (_d0), "=r" (_d1), "=r" (_a0), "=r" (_a1)		\
      : "r" (_##name##_bn), "rf"(_n1)				\
      : "fp0", "fp1", "cc", "memory");				\
   }								\
})
#define SendIO(ioRequest) \
	LP1NR(0x1ce, SendIO, void *, ioRequest, a1, \
	, EXEC_BASE_NAME)
--cut--

The LP macro has all scratch registers as unused outputs and _n1 bound to
"a1" as an input. The above is accepted by 3.3 (20030303) and older GCC
versions I could test (2.7.2.1, 2.95.2 and 3.0, 3.1, 3.2) According to my
reading and understanding of the extended asm documentation its a correct
asm expression because there are no overlaps with clobbers. However, there
is an intended "overlap" between input and output. I intend to change all
the macros in a similiar way.

> >   Extended asm is a really complicate issue. I wish I could do without.
> 
> Then implement the construct as a function attribute or builtin in your
> port ;-)

  Actually, the port has a feature (explicit register arguments) that could
  be used to replace the asm construct. Unfortunately, its C only and C++
  should work too. Furthermore, I believe its better to use generic GCC
  extensions if possible.

> (Which you say is not in CVS; but isn't it actually m68k?)

  Yes, its an m68k port running under AmigaOS.

> >   Nethertheless, I would really really like to know, why overlaps of
> >   clobbers with inputs isn't allowed. Yes, its documented but without
> >   any explanation.
> 
> Isn't it enough that it simplifes the rules?  What if it was
> allowed?  That'd introduce ambiguities and inconsistency with
> the corresponding single-register-class-constraint construct.  I
> wrote about that in enough detail in the URL I sent.

  Having pondered about the input/clobber constraint I think its not allowed
  because GCC might be instructed to _choose_ the input register(s), right?
  Since I am not an expert with GCC, the following is purely theoretical
  and based upon the previous assumption: If GCC shall choose input (and
  output) register(s) then the asm statement would contain placeholders
  like %0, etc. Would it be viable to allow overlaps for clobbers with
  inputs if the asm statement doesn't have any placeholder?

> If you're not happy with the asm semantics, the burden falls on
> you to provide argumentation and documentation for what should
> happen instead, together with test-cases and patches to
> implement that.

  I understand that and I admit that my understandig of extended asm was
  flawed. Isn't that list intended to discuss such issues and to resolve
  them?


  Regards,  
  Gunther Nikl

Re: extended asm (Was: Re: decl_conflicts_with_clobbers_p problem)

[Hans-Peter Nilsson]

> Date: Mon, 17 Mar 2003 14:17:57 +0100
> From: Gunther Nikl <gni@gecko.de>

> On Fri, Mar 14, 2003 at 05:32:56PM +0100, Hans-Peter Nilsson wrote:

> > No, that's not wrong.  But IIRC you wanted to specify the inputs
> > as (only) *outputs* in the code you sent as a follow-up, and
> > *that* was wrong.
> 
>   Now, that confuses me again. Here is the follow-up again:

> #define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
...

At a cursory reading, that seems like it would work, yes.

> > >   Nethertheless, I would really really like to know, why overlaps of
> > >   clobbers with inputs isn't allowed. Yes, its documented but without
> > >   any explanation.
> > 
> > Isn't it enough that it simplifes the rules?  What if it was
> > allowed?  That'd introduce ambiguities and inconsistency with
> > the corresponding single-register-class-constraint construct.  I
> > wrote about that in enough detail in the URL I sent.
> 
>   Having pondered about the input/clobber constraint I think its not allowed
>   because GCC might be instructed to _choose_ the input register(s), right?
>   Since I am not an expert with GCC, the following is purely theoretical
>   and based upon the previous assumption: If GCC shall choose input (and
>   output) register(s) then the asm statement would contain placeholders
>   like %0, etc. Would it be viable to allow overlaps for clobbers with
>   inputs if the asm statement doesn't have any placeholder?

I don't understand what you mean by placeholders.

I insist that the current behavior is best; that it is an error
for an overlap of an asm clobber list with an asm-declared
register operand to the asm.  If there are no asm-declared
register declared operands to the asm, then GCC will not use
registers mentioned in the clobber list for the asm operands.
So, what should happen when you force an input (or output) to be
an asm-declared register mentioned in the clobber list?  If not
have it an error, what should GCC do?  Override the
asm-declaration or the clobber or try to merge them?  If a merge
is possible, how can we make sure the overlap was really
intentional?  When should GCC warn?

> > If you're not happy with the asm semantics, the burden falls on
> > you to provide argumentation and documentation for what should
> > happen instead, together with test-cases and patches to
> > implement that.
> 
>   I understand that and I admit that my understandig of extended asm was
>   flawed. Isn't that list intended to discuss such issues and to resolve
>   them?

Sure, but it really did sound like you want a change in
behavior, and *that* burden falls on the one who wants the
change.

brgds, H-P

Re: extended asm (Was: Re: decl_conflicts_with_clobbers_p problem)

[Gunther Nikl]

On Mon, Mar 17, 2003 at 05:39:09PM +0100, Hans-Peter Nilsson wrote:
> > Date: Mon, 17 Mar 2003 14:17:57 +0100
> > From: Gunther Nikl <gni@gecko.de>
> >
> > #define LP1NR(offs, name, t1, v1, r1, bt, bn)			\
> ...
> 
> At a cursory reading, that seems like it would work, yes.

  Thats what I had hoped to hear. Thank you for taking a look!

> >   Having pondered about the input/clobber constraint I think its not allowed
> >   because GCC might be instructed to _choose_ the input register(s), right?
> >   Since I am not an expert with GCC, the following is purely theoretical
> >   and based upon the previous assumption: If GCC shall choose input (and
> >   output) register(s) then the asm statement would contain placeholders
> >   like %0, etc. Would it be viable to allow overlaps for clobbers with
> >   inputs if the asm statement doesn't have any placeholder?
> 
> I don't understand what you mean by placeholders.

  If GCC shall insert the actual register or a value in the asm then the
  asm statement has "placeholders" like %<N> with N=0,1,etc. which GCC
  will replace with the value or register.

> I insist that the current behavior is best; that it is an error
> for an overlap of an asm clobber list with an asm-declared
> register operand to the asm.  If there are no asm-declared
> register declared operands to the asm, then GCC will not use
> registers mentioned in the clobber list for the asm operands.

  Yes, thats what the clobber list is intended for and what I initially
  got wrong. I had a different understanding for "clobbers": I viewed
  them like scratch registers in an ABI which are dead after a function
  call.

> So, what should happen when you force an input (or output) to be
> an asm-declared register mentioned in the clobber list?

  I was only concerned with _inputs_.  Overlaps with outputs can never
  be allowed since they tell the compiler the register value is dead.

> have it an error, what should GCC do?  Override the
> asm-declaration or the clobber or try to merge them?  If a merge
> is possible, how can we make sure the overlap was really
> intentional?  When should GCC warn?

  As I said, if there are any %<N> in the asm statement, then GCC should
  flag the input/clobber overlap. It should do that always for output
  overlaps.

> it really did sound like you want a change in behavior, and *that* burden
> falls on the one who wants the change.

  Oh, I see what you mean. I did only try to find out if my idea does
  make any sense and nobody had thought about it before.

  Gunther

Re: GCC 3.3 release

[Gunther Nikl]

On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
> It would also be nice if 3.3 could bootstrap itself successfully on 
> m68k; there seem to be a number of frightening bugs preventing 3.2 from 
> doing so, but the m68k experts will have to look at them.

  AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
  "long long". After I disabled "long long" in auto-host.h I could
  build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
  thats is a long standing problem still present since a m68k GCC 3.2.2
  with "long long" enabled in auto-host.h shows the same symtoms as a
  natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).

  Gunther

Re: GCC 3.3 release

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

|> On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
|> > It would also be nice if 3.3 could bootstrap itself successfully on 
|> > m68k; there seem to be a number of frightening bugs preventing 3.2 from 
|> > doing so, but the m68k experts will have to look at them.
|> 
|>   AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
|>   "long long". After I disabled "long long" in auto-host.h I could
|>   build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
|>   thats is a long standing problem still present since a m68k GCC 3.2.2
|>   with "long long" enabled in auto-host.h shows the same symtoms as a
|>   natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).

Have you already tried with current CVS where the iordi3 bug is fixed?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 3.3 release

[Gunther Nikl]

On Mon, Mar 24, 2003 at 12:07:57PM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> |> On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
> |> > It would also be nice if 3.3 could bootstrap itself successfully on 
> |> > m68k; there seem to be a number of frightening bugs preventing 3.2 from 
> |> > doing so, but the m68k experts will have to look at them.
> |> 
> |>   AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
> |>   "long long". After I disabled "long long" in auto-host.h I could
> |>   build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
> |>   thats is a long standing problem still present since a m68k GCC 3.2.2
> |>   with "long long" enabled in auto-host.h shows the same symtoms as a
> |>   natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).
> 
> Have you already tried with current CVS where the iordi3 bug is fixed?

  Not yet. I already fetched that patch, applied it to my 3.3 snapshot and
  compiled cc1. Then I checked the result of the testcase from the pr.
  cc1 without patch trashed "d2", cc1 with that patch didn't. I am going
  to check 3.2.2 and a 3.3 snapshot with that patch on my m68k system.
  It will take some time since I need one hour to build an unoptimized 3.x
  compiler with GCC 2.x. I guess using a 3.x version will increase compile
  time.

  Gunther

Re: GCC 3.3 release

[Gunther Nikl]

On Mon, Mar 24, 2003 at 12:07:57PM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> |> On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
> |> > It would also be nice if 3.3 could bootstrap itself successfully on 
> |> > m68k; there seem to be a number of frightening bugs preventing 3.2 from 
> |> > doing so, but the m68k experts will have to look at them.
> |> 
> |>   AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
> |>   "long long". After I disabled "long long" in auto-host.h I could
> |>   build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
> |>   thats is a long standing problem still present since a m68k GCC 3.2.2
> |>   with "long long" enabled in auto-host.h shows the same symtoms as a
> |>   natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).
> 
> Have you already tried with current CVS where the iordi3 bug is fixed?

I checked 3.2.2 with the iordi3 patch included and a native GCC 3.2.2 is
still broken :-/ I verified that the patch is included in the used 3.2.2
cc1 by compiling the sample testcase from the pr. (BTW, 2.7.2.1 doesn't
have that problem since the generated code for the pr testcase is correct.
egcs 1.0.3 and 1.1 do have that bug).
However, I also tried a native 3.3/20030303 and that version _does_ work.
At least it could compile 3.2.2 with "long long" enabled and the resulting
xgcc didn't barf when compiling libgcc.a as it did when compiled by eg.
2.95.2 and "long long" enabled. I didn't try a bootstrap since that would
need to much time which I currently don't have.
Building a native m68k 3.3/20030303 with a m68k cross-gcc showed a problem
during compilation of ra-colorize.c with -O1. With -O1 the compiler emits
unused and incomplete switch jump-tables eg. in ra-colorize.c/reset_lists.
I guess this happens when inlining put_web(). Specifying -fgcse fixes that.

Gunther

Re: GCC 3.3 release

[Steven Bosscher]

Op za 22-03-2003, om 02:56 schreef Nathanael Nerode:
> 10087 (multidimensional array problem)

Janis hunted this one, see
http://gcc.gnu.org/ml/gcc-bugs/2003-03/msg00942.html.
There was a patch submitted yesterday to fix it.

Greetz
Steven

Re: GCC 3.3 release

[Mark Mitchell]

On Fri, 2003-03-21 at 17:32, Steven Bosscher wrote:
> Op vr 21-03-2003, om 20:25 schreef Mark Mitchell:
> > Overall, I think the 3.3 release is starting to gel nicely.
> 
> There are still some critical PRs, and a few that are "serious" but
> should be "critical" (the inline and compile time issues).  Do you think
> those are show stoppers?

Yes -- if there were no show stoppers, I'd spin the release right now.

We're getting closer, but we definitely need to knock down a bunch of
the remaining ones.

> Do you have a release plan for 3.3.x, and a rough development plan for
> 3.4?

I don't want to worry too much about 3.4 until we get 3.3 out the door;
for example, if 3.3 were to take a lot longer to get done, it would make
sense to let more into 3.4 than it would if 3.3 is done tomorrow (which
it won't be.)

For 3.3, I think all we need to do is to fix the high-priority PRs. 
It's hard for me to say how long that will take, but I would think that
if we all pull together not very long.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3 release

[Nathanael Nerode]

Op vr 21-03-2003, om 20:25 schreef Mark Mitchell:
> Overall, I think the 3.3 release is starting to gel nicely.

Steven Bosscher said:
>There are still some critical PRs, and a few that are "serious" but
>should be "critical" (the inline and compile time issues).  Do you 
>think those are show stoppers?

I nominate the following as show stoppers for 3.3.  They're all silent
wrong code emission bugs, and regressions.

8634 (incorrect inlining of memcpy under -O2)

9745 (loop alias problem)

10021 (another loop alias problem, causes some of the m68k bustage)

10087 (multidimensional array problem)

10171 (the infamous 'lost loop' bug)

10185 (more loop bugs)

8866 (jumptable->jump problem)

Some of these are probably down to the same fundamental bug.

It would also be nice if 3.3 could bootstrap itself successfully on 
m68k; there seem to be a number of frightening bugs preventing 3.2 from 
doing so, but the m68k experts will have to look at them.

That would be more than sufficient for my tastes. :-)

Re: GCC 3.3 release

[Steven Bosscher]

Op vr 21-03-2003, om 20:25 schreef Mark Mitchell:
> Overall, I think the 3.3 release is starting to gel nicely.

There are still some critical PRs, and a few that are "serious" but
should be "critical" (the inline and compile time issues).  Do you think
those are show stoppers?

Do you have a release plan for 3.3.x, and a rough development plan for
3.4?

Greetz
Steven

GCC 3.3 release

[Mark Mitchell]

There are presently 53 outstanding high-priority 3.3 regressions.

Some of these look pretty minor, and we could probably do a release
even with those problems; in particular, there are several reports of
missing or spurious warnings and/or documentation issues.

Nearly half of the bugs are optimization problems, however.  These are
especially serious in that many seem to involve bad behavior on legal
code.  Most of these are still present in 3.4 as well, so we need to
fix these.

Overall, I think the 3.3 release is starting to gel nicely.  If our
skilled middle-end/back-end people will each knock down a few of these
regressions, we'll be there quickly.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com