Re: crash fix for unhanded operation

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 9 Sep 2013, Mike Stump wrote:

> On Sep 9, 2013, at 3:48 PM, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> > On Mon, 9 Sep 2013, Mike Stump wrote:
> > 
> >> Presently gcc just dies with a crash for an unhanded operation, the 
> >> below handles it better.
> >> 
> >> I'm torn between sorry and error, error might be better.  Thoughts?
> > 
> > error means there is something wrong with the user's source code,
> 
> Right.  If one has mode X, and there are no instructions for mode X, the 
> thing that is wrong with their source code is wanting to perform an 
> operation in mode X.  The language standard doesn't mandate that the 
> operation for mode X works, so, we are free to just give an error.

Well, your patch was missing the testcase, or explanation for why a 
testcase can't be added to the testsuite, so I don't know what sort of 
source code you have in mind here.  But "mode" is only a source-code 
concept to the extent that the user uses "mode" attributes.

If the user does a division of "int" values, say, that's fully defined by 
ISO C, and so if there's back-end support for it missing, that's a 
back-end bug and an ICE is appropriate; it doesn't reflect anything wrong 
with the user's source code.  If however the user used a "mode" attribute 
for a mode for which the division operation is unsupported, the front end 
should give an error for that operation, just as the front end gives an 
error for dividing two struct values (unless of course that's supported by 
the language, in which case it gets lowered to appropriate GIMPLE); it 
doesn't generate GIMPLE with a struct division because that's invalid 
GIMPLE, and it shouldn't generate GIMPLE with a division on types for 
which the operation isn't supported.  Note that for 32-bit x86, simply 
doing

int x __attribute__((mode(TI)));

gives "error: unable to emulate 'TI'"; you don't even need to try any 
operations on that mode.  For target-specific types with more fine-grained 
restrictions on permitted operations, there are several target hooks such 
as invalid_unary_op, invalid_binary_op and invalid_parameter_type.  That's 
how the errors should be given, so that the invalid GIMPLE is never 
generated.

> > should generally be associated with the location of an erroneous source 
> > code construct.
> 
> Indeed, the ^ points to exactly what is wrong in their source, which is 
> (relatively new and) nice.

My observation has been that errors given by RTL expanders are at bad 
locations because input_location at that point tends to be set to the end 
of the function (at best).  In particular, I've seen that for errors from 
target-specific built-in function expanders.  But maybe this has improved 
since I saw such bad locations.

-- 
Joseph S. Myers
joseph@codesourcery.com