Jakub Jelinek <ja...@redhat.com> writes: > Hi! > > On Fri, Dec 08, 2017 at 08:10:08PM +0100, Christophe Lyon wrote: >> >> Can you check? >> > >> > I think that's a separate preexisting problem. Could you file a PR? >> > >> >> Sure, I filed: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 >> >> > Personally I'd just remove the assert, but I'm guessing that wouldn't >> > be acceptable... > > So, I think either we can return false instead of dying on the assertion, > but then it will emit output_addr_const and often just silently emit it > without diagnosing it (first patch), or just call output_operand_lossage > there, which will ICE except for inline asm, where it will error. > It is true there is no code provided, but output_addr_const wouldn't > provide that either: > default: > if (targetm.asm_out.output_addr_const_extra (file, x)) > break; > > output_operand_lossage ("invalid expression as operand"); > in final.c.
I think the testcase is valid even for ILP32, so the first sounds better to me. (It was because I thought the test was valid that I was leaving the fix to someone more familiar with ILP32 -- sorry that you've had to pick it up instead.) Thanks, Richard
