https://sourceware.org/bugzilla/show_bug.cgi?id=32073
Fangrui Song <i at maskray dot me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |i at maskray dot me
--- Comment #23 from Fangrui Song <i at maskray dot me> ---
(In reply to H.J. Lu from comment #0)
> [...]
> failed to build Linux kernel 6.10.4:
> [...]
> make[5]: *** [scripts/Makefile.build:362: arch/x86/crypto/sha256-avx2-asm.o]
> Error 1
I have created a Linux kernel patch to fix arch/x86/crypto/sha256-avx2-asm.S
https://lore.kernel.org/all/20240814044802.1743286-1-mask...@google.com/T/#u
M a + b => M (a + b)
Further investigation reveals that arch/arm64/kvm/hyp/nvhe/../hyp-entry
has the following `(1 << 15) | 1` pattern, which was broken by the scrubber
changes.
(make -skj"$(nproc)" O=/tmp/linux/arm64 ARCH=arm64 LLVM=1 defconfig all)
altinstruction_entry 661f, kvm_patch_vector_branch, (1 << 15) | 1,
662f-661f, 0
I have checked how the LLVM integrated assembler (which doesn't have a
whitespace scrubber) handles x86 `a + b` and arm64 `(1 << 15) | 1`.
After parsing `a`, it checks whether the next token is an operator, and if yes,
parse the next token and merge them into `a`.
https://github.com/llvm/llvm-project/commit/055006475e22014b28a070db1bff41ca15f322f0#diff-e6bafec46d3db78a4169cfe729e3852b72cf7eebe7d5cbab12b1d7e3cb00b6e8R1578
(In reply to Jan Beulich from comment #5)
> (In reply to Andreas Schwab from comment #4)
> > $ cat svml_d_acos2_core-sse2.S
> > #define JUMPTARGET(name) *name##@GOTPCREL(%rip)
> >
> > .macro WRAPPER_IMPL_SSE2 callee
> > call JUMPTARGET(\callee)
> > .endm
> > .text
> > WRAPPER_IMPL_SSE2 acos
>
> Which cpp expands to
>
> .macro WRAPPER_IMPL_SSE2 callee
> call *\ callee@GOTPCREL(%rip)
> .endm
> .text
> WRAPPER_IMPL_SSE2 acos
>
> Wow. Where's the blank coming from? I didn't know the pre-processor may
> insert random whitespace. And the pre-processed result is identical to that
> of the (imo) bogus
>
> call JUMPTARGET(\ callee)
>
> How's the consumer supposed to be telling apart which one it was originally?
>
> Yet then documentation is unclear on whether there may be whitespace between
> the \ and the parameter name. We could of course make macro expansion skip
> whitespace when a valid parameter name follows. Yet I fear there could be
> other anomalies as a result.
In the clang -E expansion, there is no such space...
.macro WRAPPER_IMPL_SSE2 callee
call *\callee@GOTPCREL(%rip)
.endm
.text
WRAPPER_IMPL_SSE2 acos
But I am amused by this behavior (\ callee).
.macro foo a
// clang reports an error while gas currently accepts this
call \ a
.endm
foo ab
(In reply to Maciej W. Rozycki from comment #22)
> (In reply to Michael Matz from comment #20)
> > I don't have a good solution, I see only hacks (e.g. above: fix _this_ very
> > instance of '(1) (2)' being pasted, to not be anymore, or alternatively to
> > continue pasting them, but handle outermost ')' as additional macro argument
> > separator). :-(
> >
> > Or: accept the fact that '(1) (2)' is a single macro argument, even if
> > surprising.
> Fair enough. Would it help and work if we at least only permitted one
> kind of separator per invocation, i.e. if there's an unquoted comma in
> the argument string then it becomes the separator and whitespace is not?
I think this will be useful.
We could explore additional opportunities to restrict space separators to as
few scenarios as possible (as long as not used in the wild)...
--
You are receiving this mail because:
You are on the CC list for the bug.
