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?
Aldy
