All have the same .log info: ucnid-2.c: Assembler messages: ucnid-2.c:6: Error: unknown opcode: `is' ucnid-2.c:10: Error: unknown opcode: `is' ucnid-2.c:14: Error: unknown opcode: `is' Minimal test-case (in which the first two characters are 0xc3 and 0x80): \303\200 IS @
Hi Hans-Peter, 0x80 and 0xc3 are not ASCII characters, so why would you expect GAS to be able to assemble them if they are not inside a string defintion ? For what it is worth I was able to compile and assemble all of the ucnid-?.c testcases using the latest binutils and gcc with an mmix-knuth-mmixware toolchain and I did not see these errors. Cheers Nick
In response to comment #1, I would expect GAS to assemble it because it's generated by GCC (presumed correct). Since you have a mmix-knuth-mmixware toolchain available, I suggest looking at the generated assembly from gcc.dg/ucnid-2.c. You should see this symbol. I don't know why you had success assembling the test-cases on your system. I'm on FC2.
Perhaps not as obvious as I thought, so I'll mention that the GCC ucnid tests are supposed to test exactly what this PR is about; UCN-coded identifiers.
...except of course that the identifiers aren't UCN-encoded in the GCC-generated assembly.
Subject: Re: UCN problems exposed by GCC tests: gcc.dg/ucnid-2.c, 3, 4 and 6. Hi Hans-Peter, > In response to comment #1, I would expect GAS to assemble it because it's > generated by GCC (presumed correct). My current theory is that it must be a gcc bug. But then I could just be passing the buck... > Since you have a mmix-knuth-mmixware > toolchain available, I suggest looking at the generated assembly from > gcc.dg/ucnid-2.c. You should see this symbol. Hmm, well what I see is: [...] LC:0 IS @ BYTE #e3,#82,#b2,#0 [...] (with no embedded 0x80 or 0xc3 characters) > I don't know why you had success > assembling the test-cases on your system. I'm on FC2. I'm on RedHat Enterprise Linux 3 but I am using a gcc toolchain built from today's sources in the FSF GCC repository (and today's binutils). Cheers Nick
I guess after all it *was* a gcc bug as these tests started to pass with LAST_UPDATED "Wed Apr 13 18:35:48 UTC 2005" (failed with "Wed Apr 13 11:20:46 UTC 2005").