How to fix: asm output is not an lvalue

How to fix: asm output is not an lvalue

[Sam Ravnborg]

Hi all.

Following code snippet generate these warnings:
t.c:9:9: warning: asm output is not an lvalue
t.c:10:10: warning: asm output is not an lvalue
t.c:9:9: warning: generating address of non-lvalue (11)
t.c:10:10: warning: generating address of non-lvalue (11)

The code snippet is part of the math emu in the kernel.
For sparc32 I get a lot of the "asm output is not an lvalue"
warnings.

For sparc32 I do not get the "generating address of non-lvalue".

Can you help me gettitng rid of these warnings?

Thanks in advance,

	Sam



$ cat t.c
static void todo(void)
{
        typedef unsigned int USItype __attribute__((mode(SI)));
        USItype l1;

        USItype DR_f0, DA_f1, DB_f1, DA_f0, DB_f0;

 __asm__ ("subcc %r4,%5,%1\n\t" "subx %r2,%3,%0\n" :
 "=r" ((USItype)(l1)),
 "=&r" ((USItype)(DR_f0)) :
 "rJ" ((USItype)(DA_f1)),
 "rI" ((USItype)(DB_f1)),
 "rJ" ((USItype)(DA_f0)),
 "rI" ((USItype)(DB_f0)) :
 "cc");
}

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

[Linus Torvalds]

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.

            Linus

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

[Sam Ravnborg]

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
math_32.c:428:21: warning: shift too big (63) for type unsigned long

But this code is so full of macros that it is not funny :-(

	Sam

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

[Josh Triplett]

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?

> math_32.c:428:21: warning: shift too big (63) for type unsigned long

That one probably needs a ULL somewhere.

> But this code is so full of macros that it is not funny :-(

Yeah, ugh.

- Josh Triplett

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

[Sam Ravnborg]

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