https://sourceware.org/bugzilla/show_bug.cgi?id=30292
--- Comment #3 from Jan Beulich <jbeulich at suse dot com> --- Created attachment 14842 --> https://sourceware.org/bugzilla/attachment.cgi?id=14842&action=edit tentative fix I'm afraid this is a result of a misuse of .eqv, which previously went un-diagnosed by mistake. Both .eqv and .equiv are clearly documented to guard the resulting symbol against re-definition. While plain register names (i.e. ones target specific code may insert in the symbol table) are meant to be excluded from this, it was imo a mistake to also exclude equates of registers from this. The attached draft patch addresses this, but it hasn't been run against a wide set of targets yet, so there may end up being obstacles to going that route. Independent of that, however, .eqv also pretty clearly isn't meant here in the first place: You don't want forward reference equates, but normal ones. And indeed by properly switching to .equ all equates involved in the two macros rotate_Xs and ROTATE_ARGS, things work with both plain gas 2.40 as well as patched 2.40.50 (producing the same code 2.38 did generate). What I can't exclude is that this won't work with gas where .eqv / .equiv weren't known yet (but the code in question won't work there anyway for the lack of those directives), as along with introducing the secondary directives handling of .equ symbols was changed (to take into account the value at the time of use [for already defined symbols], rather than the eventual final value). -- You are receiving this mail because: You are on the CC list for the bug.