public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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).