* [PATCH] Fix asan/ubsan bitfield handling in VL structures (PR sanitizer/80168)
@ 2017-03-24 19:36 Jakub Jelinek
2017-03-27 8:06 ` Richard Biener
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2017-03-24 19:36 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
Hi!
We ICE on the following testcase, because we attempt to use
DECL_BIT_FIELD_REPRESENTATIVE instead of original FIELD_DECL
in a COMPONENT_REF in a VL structure, but DECL_BIT_FIELD_REPRESENTATIVE's
DECL_FIELD_OFFSET is not really gimplified and even if it was,
it wouldn't be current. From the expr.c and stor-layout.c comments,
seems DECL_BIT_FIELD_REPRESENTATIVE's DECL_FIELD_OFFSET is guaranteed
to be the same as the corresponding field's by construction if it is not
constant, all the differences if any are in DECL_FIELD_BIT_OFFSET.
Therefore, it should be safe to reuse 3rd COMPONENT_REF operand.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-03-24 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/80168
* asan.c (instrument_derefs): Copy over last operand from
original COMPONENT_REF to the new COMPONENT_REF with
DECL_BIT_FIELD_REPRESENTATIVE.
* ubsan.c (instrument_object_size): Likewise.
* gcc.dg/asan/pr80168.c: New test.
--- gcc/asan.c.jj 2017-03-21 07:57:00.000000000 +0100
+++ gcc/asan.c 2017-03-24 17:02:35.451865004 +0100
@@ -1868,7 +1868,8 @@ instrument_derefs (gimple_stmt_iterator
tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1));
instrument_derefs (iter, build3 (COMPONENT_REF, TREE_TYPE (repr),
TREE_OPERAND (t, 0), repr,
- NULL_TREE), location, is_store);
+ TREE_OPERAND (t, 2)),
+ location, is_store);
return;
}
--- gcc/ubsan.c.jj 2017-03-07 07:10:00.000000000 +0100
+++ gcc/ubsan.c 2017-03-24 17:02:58.439568314 +0100
@@ -1772,7 +1772,7 @@ instrument_object_size (gimple_stmt_iter
{
tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1));
t = build3 (COMPONENT_REF, TREE_TYPE (repr), TREE_OPERAND (t, 0),
- repr, NULL_TREE);
+ repr, TREE_OPERAND (t, 2));
}
break;
case ARRAY_REF:
--- gcc/testsuite/gcc.dg/asan/pr80168.c.jj 2017-03-24 17:08:14.440489868 +0100
+++ gcc/testsuite/gcc.dg/asan/pr80168.c 2017-03-24 17:09:08.567791277 +0100
@@ -0,0 +1,12 @@
+/* PR sanitizer/80168 */
+/* { dg-do compile } */
+
+int a;
+
+int
+foo (void)
+{
+ struct S { int c[a]; int q : 8; int e : 4; } f;
+ f.e = 4;
+ return f.e;
+}
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Fix asan/ubsan bitfield handling in VL structures (PR sanitizer/80168)
2017-03-24 19:36 [PATCH] Fix asan/ubsan bitfield handling in VL structures (PR sanitizer/80168) Jakub Jelinek
@ 2017-03-27 8:06 ` Richard Biener
0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2017-03-27 8:06 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Fri, 24 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> We ICE on the following testcase, because we attempt to use
> DECL_BIT_FIELD_REPRESENTATIVE instead of original FIELD_DECL
> in a COMPONENT_REF in a VL structure, but DECL_BIT_FIELD_REPRESENTATIVE's
> DECL_FIELD_OFFSET is not really gimplified and even if it was,
> it wouldn't be current. From the expr.c and stor-layout.c comments,
> seems DECL_BIT_FIELD_REPRESENTATIVE's DECL_FIELD_OFFSET is guaranteed
> to be the same as the corresponding field's by construction if it is not
> constant, all the differences if any are in DECL_FIELD_BIT_OFFSET.
Yes.
> Therefore, it should be safe to reuse 3rd COMPONENT_REF operand.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Richard.
> 2017-03-24 Jakub Jelinek <jakub@redhat.com>
>
> PR sanitizer/80168
> * asan.c (instrument_derefs): Copy over last operand from
> original COMPONENT_REF to the new COMPONENT_REF with
> DECL_BIT_FIELD_REPRESENTATIVE.
> * ubsan.c (instrument_object_size): Likewise.
>
> * gcc.dg/asan/pr80168.c: New test.
>
> --- gcc/asan.c.jj 2017-03-21 07:57:00.000000000 +0100
> +++ gcc/asan.c 2017-03-24 17:02:35.451865004 +0100
> @@ -1868,7 +1868,8 @@ instrument_derefs (gimple_stmt_iterator
> tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1));
> instrument_derefs (iter, build3 (COMPONENT_REF, TREE_TYPE (repr),
> TREE_OPERAND (t, 0), repr,
> - NULL_TREE), location, is_store);
> + TREE_OPERAND (t, 2)),
> + location, is_store);
> return;
> }
>
> --- gcc/ubsan.c.jj 2017-03-07 07:10:00.000000000 +0100
> +++ gcc/ubsan.c 2017-03-24 17:02:58.439568314 +0100
> @@ -1772,7 +1772,7 @@ instrument_object_size (gimple_stmt_iter
> {
> tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1));
> t = build3 (COMPONENT_REF, TREE_TYPE (repr), TREE_OPERAND (t, 0),
> - repr, NULL_TREE);
> + repr, TREE_OPERAND (t, 2));
> }
> break;
> case ARRAY_REF:
> --- gcc/testsuite/gcc.dg/asan/pr80168.c.jj 2017-03-24 17:08:14.440489868 +0100
> +++ gcc/testsuite/gcc.dg/asan/pr80168.c 2017-03-24 17:09:08.567791277 +0100
> @@ -0,0 +1,12 @@
> +/* PR sanitizer/80168 */
> +/* { dg-do compile } */
> +
> +int a;
> +
> +int
> +foo (void)
> +{
> + struct S { int c[a]; int q : 8; int e : 4; } f;
> + f.e = 4;
> + return f.e;
> +}
>
> Jakub
>
>
--
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-03-27 8:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-24 19:36 [PATCH] Fix asan/ubsan bitfield handling in VL structures (PR sanitizer/80168) Jakub Jelinek
2017-03-27 8:06 ` 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).