[Webkit-unassigned] [Bug 216893] [MIPS] Broken build after r267371

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 24 07:32:52 PDT 2020


https://bugs.webkit.org/show_bug.cgi?id=216893

Angelos Oikonomopoulos <angelos at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |angelos at igalia.com

--- Comment #2 from Angelos Oikonomopoulos <angelos at igalia.com> ---
OK this should fix it. While the bug in LabelReference.mapChildren is obvious (it just eats up the offset when returning a new LabelReference, essentially setting it to zero), it wasn't clear to us why this bug didn't affect any of the other architectures.

I've only compared with X86_64 but suspect the same explanation applies to archs other than MIPS.

What happens is that the AST from the parser only contains

LabelReference(label, 0) + AddImmediates

and AddImmediates.fold correctly constructs a LabelReference with an offset by calling LabelReference.plusOffset.

We do call mapChildren on those on X86_64, however only in the context of a call to isASTErroneous which (somewhat ironically) simply checks the existence of Error nodes and discards the rest of the transformed AST, which would have the erroneous LabelReference nodes.

However, on MIPS, mapChildren gets called in the lowering stage too, specifically:

getModifiedListMIPS -> assignRegistersToTemporaries -> replaceTemporariesWithRegisters -> mapChildren

and there the (erroneous) result is getting used, resulting in all LabelReference nodes having an offset of zero.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200924/e30bc192/attachment-0001.htm>


More information about the webkit-unassigned mailing list