[Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
tk changed:
What|Removed |Added
CC||u1049321969 at caramail dot com
--- Comment #1 from tk ---
Hello all,
I would like to report that I hit upon a related issue in GCC 10.0.1. Besides
complaining on "and", the assembly pass also complains if I use a symbol which
happens to be the same as register name, e.g. "bx".
$ gcc-10 --version
gcc-10 (Ubuntu 10-20200411-0ubuntu1) 10.0.1 20200411 (experimental) [master
revision bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566]
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat test.c
int bx[16];
int f(unsigned x)
{
return bx[x];
}
$ gcc-10 -c test.c -O3 -masm=intel
/tmp/ccGtGi2X.s: Assembler messages:
/tmp/ccGtGi2X.s:12: Error: invalid use of register
The offending line in the assembly code says
lea rax, bx[rip]
The problem does _not_ go away even if I quote the symbol name by hand in the
assembly output, e.g.
lea rax, "bx"[rip]
Thank you!
[Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #4 from tk --- I have found that if I manually change lea rax, bx[rip] to something like lea rax, __bx[rip] ... .weakref __bx, bx the assembly pass succeeds, with the correct results. (It seems that the names "bx" and "and" only pose problems when they are used within expressions. If they are used in a context which unequivocally demands a symbol, then gas can parse them.) Thank you!
[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99900 tk changed: What|Removed |Added CC||u1049321969 at caramail dot com --- Comment #5 from tk --- Hello all, > I've no idea whether the (not merged) ia16 port can do this, or whether > the person currently maintaining a version of that port for GCC 6 is > covered by an FSF copyright assignment. I am the maintainer behind the https://github.com/tkchia/gcc-ia16 fork. Yes, I have done the copyright assignments for my IA-16 patches for GCC (in 2017) and also for Binutils (in 2018). I believe that the previous developers, Mr. Lambertsen and Mr. Jenner, have also made the needed copyright assignments. The current gcc-ia16 code can produce code to run on an 8086, 80186, or 80286 machine, and also has support for far pointers --- including far function pointers. The texinfo documentation has been updated to lay out the features that the IA-16 port has. Thank you!
[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99900 --- Comment #6 from tk --- Hello Andrew, > A bug bounty might be useful here since I highly doubt this will be done > otherwise. The gcc-ia16 port is working, but internals-wise, some parts of the IA-16 patches are still rather hacky --- some of the changes affect the machine-independent middle-end in not-so-elegant ways, or depend on undocumented (and unreliable) properties in the middle-end. So I guess it might still be useful to have some sort of bounty(s), if this means someone could help rethink the changes and reduce technical debt. Thank you!
[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99900 --- Comment #7 from tk --- Hello Andrew, Incidentally, the patches for binutils-ia16 (https://github.com/tkchia/binutils-ia16) to support IA-16 relocations (https://github.com/tkchia/build-ia16/blob/master/elf16-writeup.md), could perhaps also benefit from a rethink. Thank you!
[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99900 --- Comment #8 from tk --- Hello Patrick, > Can you or anyone guestimate / speculate how big a bounty in USD value would > be required to get this ticket implemented in gcc as well as getting a patch > merged at VirtualBox starting to use this? Offhand, I would guess that the effort is at least comparable to other efforts to modernize GCC internals, e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 , so a comparable bounty is likely needed. But perhaps someone who is more knowledgeable about GCC internals can provide a better estimate. Thank you!
