This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
[forwarded from http://bugs.debian.org/188513] rechecked with CVS 3.3.1 and HEAD CVS 20030531, binutils-2.14.0.90.4 regression compared to gcc-2.95 $ gcc -c -O2 engine.i /tmp/ccVcqHkK.s: Assembler messages: /tmp/ccVcqHkK.s:4532: Warning: source register same as write-back base /tmp/ccVcqHkK.s:3038: Error: bad immediate value for offset (4104) /tmp/ccVcqHkK.s:3056: Error: bad immediate value for offset (4176) /tmp/ccVcqHkK.s:3084: Error: bad immediate value for offset (4288) /tmp/ccVcqHkK.s:3092: Error: bad immediate value for offset (4140) /tmp/ccVcqHkK.s:3103: Error: bad immediate value for offset (4104) /tmp/ccVcqHkK.s:5237: Error: bad immediate value for offset (4132) /tmp/ccVcqHkK.s:5250: Error: bad immediate value for offset (4184) /tmp/ccVcqHkK.s:5264: Error: bad immediate value for offset (4240) /tmp/ccVcqHkK.s:5276: Error: bad immediate value for offset (4108)
Created an attachment (id=4352) [edit] preprocessed source
Confirmed with gcc 3.1, 3.3 branch and mainline (20030708).
Not a bug. Your source code is invalid. You can't put any "asm" in your source code that requires more than 4 bytes per statement. You have ".skip 16" operations which are violating this constraint and consequently gcc gets confused in a way which can only be detected by the assembler. The compiler does not parse the body of asm statements to divine their meaning.
Note for clarity. By "four bytes per statement" I mean between each semicolon in the input string. So asm ("insn1; insn2; insn3 insn4") is ok and (on ARM) will be counted as 16 bytes. But asm (".space 16") is not, it will only be counted as 4 bytes by the compiler.
Subject: Re: [3.3 regression] [arm] invalid assembler on arm "rearnsha at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: > You can't put any "asm" in your source code that requires more than > 4 bytes per statement. You have ".skip 16" operations which are > violating this constraint and consequently gcc gets confused in a > way which can only be detected by the assembler. Is this something ARM specific? I can't find anything in the manual about it. If it's a general statement, we can also close 12108. > The compiler does not parse the body of asm statements to divine > their meaning. But it does count the ;'s?
> Is this something ARM specific? I can't find anything in the manual > about it. If it's a general statement, we can also close 12108. Not specifically. It applies to any port which relies on accurate tracking of the size of instructions generated (sh spings to mind here). In the ARM case we have to do this because of the limited range of a pc-relative load, which means that constants have to split into sub-pools that are reachable by a single instruction. 12108 is similar, but subtly different. In that case (as I understand it from a quick scan) the compiler is trying to suppress an ASM statement by the use of a special instruction which will cause the following instruction to not be executed (or only executed under specific conditions). In this case the compiler must know that the asm body will expand into exactly one target instruction -- so it's not the length of the sequence generated, but the number of instructions. It could be argued that conditional suppression of an ASM should never be attempted by the compiler, but I don't know enough about the processor in question to be sure. The documentation for ASM should probably be updated to make it clear that gcc has to estimate the number of bytes that an ASM will generate and that the estimate is based on the number of statements multiplied by the longest instruction in the target. Use of any ASM statement that produces more bytes than that should be considered "unspecified behaviour" (it might work on some platforms all the time, but on others only some of the time).