Re: How to fix: asm output is not an lvalue

[Sam Ravnborg <sam@ravnborg.org>]

On Sat, Apr 26, 2014 at 11:57:34PM -0700, Josh Triplett wrote:
> On Sun, Apr 27, 2014 at 08:48:04AM +0200, Sam Ravnborg wrote:
> > On Sat, Apr 26, 2014 at 04:44:13PM -0700, Linus Torvalds wrote:
> > > On Sat, Apr 26, 2014 at 2:57 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> > > >
> > > > Following code snippet generate these warnings:
> > > > t.c:9:9: warning: asm output is not an lvalue
> > > 
> > > Yeah. That code snippet is pure and utter garbage.
> > > 
> > > Gcc has this totally insane extension that makes casts be lvalues.
> > > It's stupid and horrid, and pointless to boot. So apparently gcc
> > > accepts that crap.
> > > 
> > > But it is very much total crap.
> > > 
> > > Those casts to (USItype) are all pointless to begin with (since the
> > > values are of that type already!) and they mean that the expression
> > > isn't something you can assign to (lvalue). The fact that gcc accepts
> > > code like that is an embarrassment.
> > 
> > Thanks.
> > When I dropped the casts to the output values the warnings were gone.
> > 
> > Now the code is down to ~30 warnings - looks like this.
> > math_32.c:371:17: warning: shift too big (4294967267) for type unsigned long
> 
> That one looks like a bug; that's just below 2**32 (4294967296), which
> makes no sense as a shift.  Perhaps there's a precedence issue?

Deep down in some macro expansion I found the following:

$ cat t.c
void foo(void);
int x;
int y;

static void todo(void)
{

        if (3 < 32)
                foo();
        else
                x = y << (3 - 32);
}


This produces the same warning.
But the if expression is always true so the else part could be ignored.

This is line 52 in include/math/op-2.h in the kernel if someone
wants to take a look...
I have no test-suite for the softfloat stuff, so I am not going to touch this code...

	Sam