On October 28, 2016 6:46:07 PM GMT+02:00, Aldy Hernandez <al...@redhat.com> wrote: >On 10/28/2016 01:40 AM, Richard Biener wrote: >> On Thu, Oct 27, 2016 at 6:14 PM, Aldy Hernandez <al...@redhat.com> >wrote: >>> On 10/27/2016 12:35 AM, Richard Biener wrote: >>>> >>>> On Wed, Oct 26, 2016 at 9:17 PM, Aldy Hernandez <al...@redhat.com> >wrote: >>>>> >>>>> The following one-liner segfaults on arm-eabi when compiled with >>>>> -mfloat-abi=hard -g: >>>>> >>>>> __simd64_float16_t usingit; >>>>> >>>>> The problem is that the pretty printer (in >simple_type_specificer()) is >>>>> dereferencing a NULL result from c_common_type_for_mode: >>>>> >>>>> int prec = TYPE_PRECISION (t); >>>>> if (ALL_FIXED_POINT_MODE_P (TYPE_MODE (t))) >>>>> t = c_common_type_for_mode (TYPE_MODE (t), >TYPE_SATURATING >>>>> (t)); >>>>> else >>>>> t = c_common_type_for_mode (TYPE_MODE (t), >TYPE_UNSIGNED >>>>> (t)); >>>>> if (TYPE_NAME (t)) >>>>> >>>>> The type in question is: >>>>> >>>>> <real_type 0x7fffefdeb150 HF ...> >>>>> >>>>> which corresponds to HFmode and which AFAICT, does not have a type >by >>>>> design. >>>>> >>>>> I see that other uses of *type_for_node() throughout the compiler >check >>>>> the >>>>> result for NULL, so perhaps we should do the same here. >>>>> >>>>> The attached patch fixes the problem. >>>>> >>>>> OK for trunk? >>>> >>>> >>>> Your added assert shows another possible issue - can you fix this >by >>>> assigning >>>> the result of c_common_type_for_mode to a new variable, like >common_t and >>>> use that for the TYPE_NAME (...) case? I think this was what was >>>> intended. >>> >>> >>> Certainly. >>> >>> OK pending tests? >> >> Ok. >> > >Thanks. > >I just noticed this is also a GCC 6 regression. Assuming the GCC 6 >branch is open for regression bugfixes, is this OK for the branch?
Yes. Richard. >Aldy
