ICEs in print_operand() of the rs6000 backend with invalid input assembly

Arseny Solokha asolokha@gmx.com
Mon Nov 26 05:10:00 GMT 2018


> Hi Arseny,
> 
> On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote:
>> I've found recently that rs6000 and powerpcspe backends can easily trip over
>> various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
>> print_operand() when provided with some invalid assembly (i.e. assembly written
>> for other architectures).
> 
> Yup.  They should use output_operand_lossage instead.

Isn't it something that should be mentioned in the Internals manual?


>> I have a hunch that this kind of invalid input should have been rejected way
>> earlier, before getting to the printing out the resulting assembly, and that
>> i386 backend actually does exactly that. Still, I'm not convinced that the
>> current behavior is really unintended. Is it worthwhile at all to report ICEs of
>> this kind?
> 
> Please report them, yes! 

So I've filed PR88188 with three issues I've found so far. Though they might be
of different nature.


> Bonus points if you can find some way to test
> this in the testsuite (preferably for all targets), testing many kinds
> of input args (reg, imm, memory) and all output modifiers.

For now I use a trivial script that simply tries to compile everything it finds,
each file with a new set of -mcpu value, optimization options and --param
options. Maybe enhancing the testsuite to facilitate some kind of fuzzing out of
the box could be a proper task for the GSoC?



More information about the Gcc mailing list