[Bug target/15896] Strange behaviour for inline assembler input constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15896
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #4 from Eric Gallager ---
(In reply to Eric Gallager from comment #3)
> (In reply to Eric Gallager from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > I don't know Ada that well (in terms of promotions and types) but the
> > > following C code produces the
> > > same ICE so I might assume the issue is that My_Type+constant is being
> > > promoted to unsigned long
> > > long or something along that line:
> > > int f()
> > > {
> > > unsigned long long cu32 = 1;
> > > asm("%0"::"a"(cu32));
> > > }
> >
> > Does this still happen with newer versions of GCC? I can't reproduce with
> > gcc 7, but I'm assuming that's due to target differences; I get different
> > messages depending on 32-bit or 64-bit, but neither of them are an ICE:
> >
> > $ gcc -c -m32 15896.c
> > 15896.c: In function 'f':
> > 15896.c:4:3: error: inconsistent operand constraints in an 'asm'
> >asm("%0"::"a"(cu32));
> >^~~
> > $ gcc -c -m64 15896.c
> > 15896.c:4:Junk character 37 (%).
> > 15896.c:4:Rest of line ignored. 1st junk character valued 114 (r).
> > $
>
> WAITING on a reply
No reply; closing.
[Bug target/15896] Strange behaviour for inline assembler input constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15896
Eric Gallager changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #3 from Eric Gallager ---
(In reply to Eric Gallager from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I don't know Ada that well (in terms of promotions and types) but the
> > following C code produces the
> > same ICE so I might assume the issue is that My_Type+constant is being
> > promoted to unsigned long
> > long or something along that line:
> > int f()
> > {
> > unsigned long long cu32 = 1;
> > asm("%0"::"a"(cu32));
> > }
>
> Does this still happen with newer versions of GCC? I can't reproduce with
> gcc 7, but I'm assuming that's due to target differences; I get different
> messages depending on 32-bit or 64-bit, but neither of them are an ICE:
>
> $ gcc -c -m32 15896.c
> 15896.c: In function 'f':
> 15896.c:4:3: error: inconsistent operand constraints in an 'asm'
>asm("%0"::"a"(cu32));
>^~~
> $ gcc -c -m64 15896.c
> 15896.c:4:Junk character 37 (%).
> 15896.c:4:Rest of line ignored. 1st junk character valued 114 (r).
> $
WAITING on a reply
[Bug target/15896] Strange behaviour for inline assembler input constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15896
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
||pinskia at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
(In reply to Andrew Pinski from comment #1)
> I don't know Ada that well (in terms of promotions and types) but the
> following C code produces the
> same ICE so I might assume the issue is that My_Type+constant is being
> promoted to unsigned long
> long or something along that line:
> int f()
> {
> unsigned long long cu32 = 1;
> asm("%0"::"a"(cu32));
> }
Does this still happen with newer versions of GCC? I can't reproduce with gcc
7, but I'm assuming that's due to target differences; I get different messages
depending on 32-bit or 64-bit, but neither of them are an ICE:
$ gcc -c -m32 15896.c
15896.c: In function 'f':
15896.c:4:3: error: inconsistent operand constraints in an 'asm'
asm("%0"::"a"(cu32));
^~~
$ gcc -c -m64 15896.c
15896.c:4:Junk character 37 (%).
15896.c:4:Rest of line ignored. 1st junk character valued 114 (r).
$
