https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |scox at redhat dot com,
| |wcohen at redhat dot com
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If it can be proven that all gcc versions until now treat "nor" constraint as
ignoring the n in there and pushing all constants into constant pool, I think
it could be changed into "or" for arm32. But it would be IMNSHO unnecessary
pessimization (but it could e.g. be done for GCC < 12 or whenever this would be
fixed).
Another option is to tweak whatever generates those large inline asms.
In the qemu case it is created with
/usr/bin/python3 ../scripts/tracetool.py --backend=dtrace --group=util
--format=h /builddir/build/BUILD/qemu-6.1.0/util/trace-events
trace/trace-util.h
whatever that is (but that means I haven't actually seen what it generates).
Note, apparently several other packages are affected, so not sure what changed
recently in systemtap-sdt-devel or whatever else that adds up to this.
In the preprocessed source I got I see several blocks of
".ascii \"\\x20\""
"\n"
"_SDT_SIGN %n[_SDT_S4]"
"\n"
"_SDT_SIZE %n[_SDT_S4]"
"\n"
"_SDT_TYPE %n[_SDT_S4]"
"\n"
".ascii \"%[_SDT_A4]\""
"\n"
It already uses assembler macros, perhaps adding a macro to do all 3 at once or
perhaps with something extra could bring the number of newlines down...
