https://sourceware.org/bugzilla/show_bug.cgi?id=21874
--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jan Beulich from comment #15) > (In reply to H.J. Lu from comment #12) > > (In reply to Jan Beulich from comment #11) > > > (In reply to H.J. Lu from comment #10) > > > > Do you have a real example? > > > > > > No, I don't. But I don't assume you have a real example of someone having > > > used something like fs:foo:[ebx] either, to support your original change. > > > The reporter's example, as he states, did not result in bad code being > > > generated (and for that case accepting the code was the intended > > > behavior). > > > > Someone bothered enough to open a bug report with a testcase. That is > > good enough for me. > > The mere fact that there was a loop that you've eliminated should already > have given enough of a hint to you that at least certain redundant segment > overrides were indeed intended to be permitted. Once again, I'm perfectly > fine with invalid code (gs:foo:[mem]) to be properly rejected. I continue to > consider gs:fs:[mem] valid code, based on MASM accepting it (for whatever, > perhaps historical, reason). MASM compatibility isn't the goal for gas. The primary purpose of gas is to support GCC. Gas should behave the same with or without -asm=intel. If it means that gs:fs:[mem] is invalid, so be it. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
