lkml.org 
[lkml]   [1998]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: egcs 1.0.1 miscompiles Linux 2.0.33
Date
From

In message <35063CF6.FA76EB6F@wtal.de>you write:
> Hmmm, this code might be well readable and optimizable by a
> compiler. Any h uman beeing would definitely struggle with the
> set but unused variables. (Note Linus' arguments against the
> readability of this syntactic construction. I agree.
> Though I don't agree that something which has been valid should
> remain valid.)
>
> I would suggest
> :"=a" (__res), "=&c" (void), "=&S" (void)
> : "0" (0), "1" (0xffffffff), "2" (cs),"g" (ct)
> :"dx","di");
I don't know if the (void) thing would actually work, though it is
a neat idea.

However, if we're going to change the asm syntax I want everyone to
be aware of the consequences of that action.

The same goes if we change clobbers to specify register classes
instead of hard registers (something the ppc-linux folks need) or
any

In particular I can not guarantee that gcc2 will ever accept that
change. In fact, I would bet that the head maintainer will strongly
oppose it, and I'm not going to get into another argument with him.

So, if we make the change and you use the new syntax, then you're
stuck with an egcs compiler. That (of course) is fine by me :-), but
I want everyone to be aware of the consequences of this choice.

In contrast, using the dummy variables will work with both compilers,
though gcc2 may not ever have the stricter clobber/input checking
for the same reasons it may not ever get any changes we make to
the asm syntax.


It's also worth noting we're considering allowing clobbers to
specify register classes, mostly for the ppc-linux port. It will
have the same problem that code will not work with gcc2 if it
uses any of the new asm features.

> Thank you for this detailed explanation.Here an fatal error would
> be the best solution. Nobody could disagree on this topic. If
> done fast it would stop this thread.
Unfortunately, I couldn't do it fast :(

I think we do have an agreement that at the very least we should have
an option to enable stricter checking of clobbers overlapping with
other operands. I'll go ahead and implement that.

The stricter clobber checking will also catch cases where the
compiler is running out of registers. This happens because the
compiler will end up trying to use one of the clobbers for its
own purposes, which will trigger the error.

> > I've hesitated installing this change because it's going to cause
> > so many compile time failures for code which currently exists in the
> > Linux sources.
>
> A warning would be nice, a fatal error should be reserved for
> incorrect code.
The code is actually incorrect because it has set up a clobber to
overlap an input register -- thus a fatal is right thing to do.

jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.066 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site