[avr-gcc-list] Inline assembler now geenerates an error message

[Ebert, Rolf]

The current gcc-3.3 releases behave differently than the 3.3
prereleases in respect to inline assembler code (actually I only
tested version 3.3.2 20031006 (prerelease) (avr)).  The following
snippet did not cause an error message in the prereleases:

-----------------------------------------

static inline void
set_io (unsigned char port, unsigned char value) {
  __asm__ __volatile__ ("out %0, %1" : /* */ : "r" ((value)), "M" ((port)));
}

int
main() {
  set_io(/* port = */0x20, /* value = */0xAA);
  return 0;
}

address@hidden:~/devel/avr$ avr-gcc -S -Os -mmcu=at90s2313 avr-inline-pb.c
avr-inline-pb.c: In function `main':
avr-inline-pb.c:3: warning: asm operand 1 probably doesn't match constraints
avr-inline-pb.c:3: error: impossible constraint in `asm'
avr-inline-pb.c: In function `set_io':
avr-inline-pb.c:3: warning: asm operand 1 probably doesn't match constraints

-----------------------------------------

The prereleases only emitted the warnings (which I don't understand
neither, but that is another problem).

I could not help myself but by the following patch to gcc:

--- ./gcc/function.c~   2003-04-11 00:26:04.000000000 +0200
+++ ./gcc/function.c    2003-10-28 00:22:06.000000000 +0100
@@ -3767,8 +3767,8 @@
 {
   if (asm_noperands (PATTERN (insn)) >= 0)
     {
-      error_for_asm (insn, "impossible constraint in `asm'");
-      delete_insn (insn);
+/*       error_for_asm (insn, "impossible constraint in `asm'"); */
+/*       delete_insn (insn); */
     }
   else
     abort ();

It then generates the expected correct assembly code.  My
understanding of the success of the patch is that gcc applies some
(wrong?) reasoning when analyzing the code in the backend and emits
this false error message.

Why don't I simply write my code like this:

#include <avr/io.h>
...
  PORTD = 0xAA;


Actually, I still want the Ada front end to get in a reasonable,
i.e. usable, state.  Ada does not have a prepocessor which is used
very cleverly in the above statement.  Thus, my only resort is the
inline assembly.  This used to work (and was used in the old avr-libc
outp/outb macros, too)

I'd like to better understand why gcc generates the error message (and
the warnings, btw) so that I can theach it how to behave better.  I have
the impression that my patch hides the symptom rather than curing the
cause.

Any pointer or help?

thanks

        Rolf