On 12/07/16 10:44, Richard Sandiford wrote: > Bernd Edlinger <bernd.edlin...@hotmail.de> writes: >> Hi Eric, >> >> what you got there, looks more or less exactly like what I tried >> to fix with that patch a few months ago, but unfortunately >> we were unable to get a consensus on that approach: >> >> [PATCH] Fix asm X constraint (PR inline-asm/59155) >> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01649.html > > Does your patch also fix Eric's testcase? If so then that approach > looks safer to me FWIW. The problem with allowing arbitrary MEMs > is that it's just not clear: >
Yes. I tried the latest patch from here: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01363.html And built a sparc64-elf cross-compiler with that. It fixes the reported crash and makes the asm argument even printable. > (a) which other parts of the compiler (including target code) needs > to handle these arbitrary MEMs. One instance is the target-specific > code for printing an address, as Jakub says in that thread, but it > could also affect things like cost calculations, etc. > > (b) should a spilled pseudo in the MEM be replaced with a MEM itself, > so that even RISC targets have to support nested MEMs? Or should > pseudo registers be reloaded? If so, into which register classes? > Should they be divided into base and index registers in the normal > way? That's difficult to do if we can't decompose the address. > (c) there is no way how to test these unreasonably complex RTXes. They are created just by random optimizations. > Reload's always been a recurring source of problems, so the fact > that this particular case went through without an ICE doesn't mean > that arbitrary MEMs were actually safe in general. > There are not safe at all. There are lots of different ways how we can ICE with asm X constraints. Jeff, what should we do here? Thanks Bernd.
