On Sep 10, 2013, at 3:43 PM, Joseph S. Myers wrote:
> 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 th
On Mon, 9 Sep 2013, Mike Stump wrote:
> On Sep 9, 2013, at 3:48 PM, "Joseph S. Myers" 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 mi
On Sep 9, 2013, at 4:49 PM, Mike Stump wrote:
>> I don't see how it can be appropriate here; my impression
>> is that this code should never fail for any compiler input,
Oh, I might have missed what you meant by this… If so, sorry… The nicest of
options would be to generate a libcall for the
On Sep 9, 2013, at 3:48 PM, "Joseph S. Myers" 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 s
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, and
should generally
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?
Ok?
diff --git a/gcc/expmed.c b/gcc/expmed.c
index a83d549..127085f 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -4954,6 +4954,12 @
