[Nasm-bugs] [Bug 3392662] nasm-2.15rc1 breaks firefox build (possibly related to 3392652?)
noreply-nasm at dev.nasm.us
noreply-nasm at dev.nasm.us
Wed Jun 10 20:04:46 PDT 2020
https://bugzilla.nasm.us/show_bug.cgi?id=3392662
H. Peter Anvin <hpa at zytor.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|PENDING |CONFIRMED
Resolution|NEEDINFO |---
--- Comment #15 from H. Peter Anvin <hpa at zytor.com> ---
x264 has similar problems. As you said, legacy NASM played fast and loose, and
could sometimes invoke a macro where %0 doesn't even match the macro
specification!
I think I have something working, just working on factoring it into bisectable.
Indirectly it turns out that there is no way to handle both legacy behavior and
same behavior at 100%, so I'm going to have to have it controlled by a %pragma.
--- Comment #16 from H. Peter Anvin <hpa at zytor.com> ---
I obviously don't want to rip out a bunch of the guts of the preprocessor late
in the -rc cycle, but something that really needs fixing is that NASM actually
parses mmacro arguments *twice*, using different code. Together with outright
bugs in both pieces of code, this is why the macro matching and macro
invocation could mismatch.
--- Comment #17 from H. Peter Anvin <hpa at zytor.com> ---
x264 has similar problems. As you said, legacy NASM played fast and loose, and
could sometimes invoke a macro where %0 doesn't even match the macro
specification!
I think I have something working, just working on factoring it into bisectable.
Indirectly it turns out that there is no way to handle both legacy behavior and
same behavior at 100%, so I'm going to have to have it controlled by a %pragma.
--
You are receiving this mail because:
You are watching all bug changes.
You are on the CC list for the bug.
More information about the Nasm-bugs
mailing list