On Mon, 9 Sep 2013, Mike Stump wrote: > On Sep 9, 2013, at 3:48 PM, "Joseph S. Myers" <jos...@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 jos...@codesourcery.com
