middle-end/5099: m68k-aout/3.0.2/cc1 aborts on asm("movw sr,%0":"=hd"(a));

[lindsayd@cisco.com]

>Number:         5099
>Category:       middle-end
>Synopsis:       m68k-aout/3.0.2/cc1 aborts on asm("movw sr,%0":"=hd"(a));
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-illegal-code
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 12 19:56:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Don Lindsay
>Release:        3.0.2
>Organization:
>Environment:
sparc-sun-solaris2.6 x m68k-aout
Configuration options were:
--with-gnu-as --with-gnu-ld --with-newlib
--enable-languages=c++ --disable-shared
--with-headers=$MERGE/newlib/libc/include
--target m68k-aout



>Description:
Internal compiler error in instantiate_virtual_regs_1, at function.c:3904
>How-To-Repeat:
gcc.68k -S foo.c where foo.c is:

typedef unsigned short ushort;
ushort set_ipl()
{
    ushort retval;
    asm ("movw     sr,%0" : "=hd" (retval));
    return retval;
}
The killer being the illegal "h" constraint. 

>Fix:
Not sure. The "h" constraint is illegal on the 68k, 
and should be ignored or complained about. GCC 2.95.3
ignored it, in the sense that the "h" didn't affect the
generated .s file for the original guilty program.
GDB showed GCC 3.0.2 hit expand_asm_operands, who called
parse_output_constraint, and both go through the default
case arm when they switch on 'h'. But something caught
up with the compiler later on: presumably a consequence of
something done by the default case arm.
I'd vote for an error message about "unknown constraint".
Which would of course have to be coded in a macro supplied
by the back ends, like EXTRA_CONSTRAINT, since the backends
know what extended contraints they do and don't add.
>Release-Note:
>Audit-Trail:
>Unformatted: