* [PR debug/77773] segfault when compiling __simd64_float16_t with -g
@ 2016-10-26 19:18 Aldy Hernandez
2016-10-27 7:35 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Aldy Hernandez @ 2016-10-26 19:18 UTC (permalink / raw)
To: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
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?
[-- Attachment #2: curr --]
[-- Type: text/plain, Size: 1074 bytes --]
commit 10c5a54cb1bf4684864b01cb965d83f3fe474797
Author: Aldy Hernandez <aldyh@redhat.com>
Date: Wed Oct 26 12:06:09 2016 -0700
PR debug/77773
* c-pretty-print.c (simple_type_specifier): Do not dereference `t'
if NULL.
diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index 90428ca..6bb38a9 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -348,7 +348,7 @@ c_pretty_printer::simple_type_specifier (tree 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))
+ if (t && TYPE_NAME (t))
{
simple_type_specifier (t);
if (TYPE_PRECISION (t) != prec)
@@ -362,6 +362,7 @@ c_pretty_printer::simple_type_specifier (tree t)
switch (code)
{
case INTEGER_TYPE:
+ gcc_assert (t != NULL);
translate_string (TYPE_UNSIGNED (t)
? "<unnamed-unsigned:"
: "<unnamed-signed:");
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PR debug/77773] segfault when compiling __simd64_float16_t with -g
2016-10-26 19:18 [PR debug/77773] segfault when compiling __simd64_float16_t with -g Aldy Hernandez
@ 2016-10-27 7:35 ` Richard Biener
2016-10-27 16:14 ` Aldy Hernandez
0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2016-10-27 7:35 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: gcc-patches
On Wed, Oct 26, 2016 at 9:17 PM, Aldy Hernandez <aldyh@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.
Richard.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PR debug/77773] segfault when compiling __simd64_float16_t with -g
2016-10-27 7:35 ` Richard Biener
@ 2016-10-27 16:14 ` Aldy Hernandez
2016-10-28 8:40 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Aldy Hernandez @ 2016-10-27 16:14 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
On 10/27/2016 12:35 AM, Richard Biener wrote:
> On Wed, Oct 26, 2016 at 9:17 PM, Aldy Hernandez <aldyh@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?
Aldy
[-- Attachment #2: curr --]
[-- Type: text/plain, Size: 1230 bytes --]
commit 1b914820aca7fa82079622b7ba1f7b01b1e79344
Author: Aldy Hernandez <aldyh@redhat.com>
Date: Wed Oct 26 12:06:09 2016 -0700
PR debug/77773
* c-pretty-print.c (simple_type_specifier): Do not dereference `t'
if NULL.
diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index 90428ca..7ad5900 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -344,14 +344,17 @@ c_pretty_printer::simple_type_specifier (tree t)
else
{
int prec = TYPE_PRECISION (t);
+ tree common_t;
if (ALL_FIXED_POINT_MODE_P (TYPE_MODE (t)))
- t = c_common_type_for_mode (TYPE_MODE (t), TYPE_SATURATING (t));
+ common_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))
+ common_t = c_common_type_for_mode (TYPE_MODE (t),
+ TYPE_UNSIGNED (t));
+ if (common_t && TYPE_NAME (common_t))
{
- simple_type_specifier (t);
- if (TYPE_PRECISION (t) != prec)
+ simple_type_specifier (common_t);
+ if (TYPE_PRECISION (common_t) != prec)
{
pp_colon (this);
pp_decimal_int (this, prec);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PR debug/77773] segfault when compiling __simd64_float16_t with -g
2016-10-27 16:14 ` Aldy Hernandez
@ 2016-10-28 8:40 ` Richard Biener
2016-10-28 16:46 ` Aldy Hernandez
0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2016-10-28 8:40 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: gcc-patches
On Thu, Oct 27, 2016 at 6:14 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> On 10/27/2016 12:35 AM, Richard Biener wrote:
>>
>> On Wed, Oct 26, 2016 at 9:17 PM, Aldy Hernandez <aldyh@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,
Richard.
> Aldy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PR debug/77773] segfault when compiling __simd64_float16_t with -g
2016-10-28 8:40 ` Richard Biener
@ 2016-10-28 16:46 ` Aldy Hernandez
2016-10-28 17:40 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Aldy Hernandez @ 2016-10-28 16:46 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
On 10/28/2016 01:40 AM, Richard Biener wrote:
> On Thu, Oct 27, 2016 at 6:14 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
>> On 10/27/2016 12:35 AM, Richard Biener wrote:
>>>
>>> On Wed, Oct 26, 2016 at 9:17 PM, Aldy Hernandez <aldyh@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PR debug/77773] segfault when compiling __simd64_float16_t with -g
2016-10-28 16:46 ` Aldy Hernandez
@ 2016-10-28 17:40 ` Richard Biener
0 siblings, 0 replies; 6+ messages in thread
From: Richard Biener @ 2016-10-28 17:40 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: gcc-patches
On October 28, 2016 6:46:07 PM GMT+02:00, Aldy Hernandez <aldyh@redhat.com> wrote:
>On 10/28/2016 01:40 AM, Richard Biener wrote:
>> On Thu, Oct 27, 2016 at 6:14 PM, Aldy Hernandez <aldyh@redhat.com>
>wrote:
>>> On 10/27/2016 12:35 AM, Richard Biener wrote:
>>>>
>>>> On Wed, Oct 26, 2016 at 9:17 PM, Aldy Hernandez <aldyh@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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-28 17:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-26 19:18 [PR debug/77773] segfault when compiling __simd64_float16_t with -g Aldy Hernandez
2016-10-27 7:35 ` Richard Biener
2016-10-27 16:14 ` Aldy Hernandez
2016-10-28 8:40 ` Richard Biener
2016-10-28 16:46 ` Aldy Hernandez
2016-10-28 17:40 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).