[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