public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
@ 2015-05-18  8:49 marxin at gcc dot gnu.org
  2015-05-18 12:45 ` [Bug sanitizer/66190] " rguenth at gcc dot gnu.org
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2015-05-18  8:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

            Bug ID: 66190
           Summary: [5/6 Regression] ICE: tree code ‘call_expr’ is not
                    supported in LTO streams with -fsanitize=null
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

$ cat test.ii
class A {
public:
  void m_fn1(int);
};
class GrAAHairLinePathRenderer {
  ~GrAAHairLinePathRenderer();
  A onStencilPath_drawState;
  virtual void m_fn2() {
    static int a;
    static int &b(a);
    onStencilPath_drawState.m_fn1(b);
  }
};
GrAAHairLinePathRenderer::~GrAAHairLinePathRenderer() {}

$ g++ test.ii -flto -c -fsanitize=null


test.ii:14:56: internal compiler error: tree code ‘call_expr’ is not supported
in LTO streams
 GrAAHairLinePathRenderer::~GrAAHairLinePathRenderer() {}
                                                        ^
0x678d8e lto_write_tree
        ../../gcc/lto-streamer-out.c:415
0x678d8e lto_output_tree_1
        ../../gcc/lto-streamer-out.c:464
0x678d8e DFS::DFS(output_block*, tree_node*, bool, bool, bool)
        ../../gcc/lto-streamer-out.c:654
0xe378ce lto_output_tree(output_block*, tree_node*, bool, bool)
        ../../gcc/lto-streamer-out.c:1609
0xdbf5f5 write_global_stream
        ../../gcc/lto-streamer-out.c:2397
0xdbf5f5 lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
        ../../gcc/lto-streamer-out.c:2444
0xdbf5f5 produce_asm_for_decls()
        ../../gcc/lto-streamer-out.c:2814
0xdb4004 write_lto() [clone .lto_priv.4579]
        ../../gcc/passes.c:2410
0xe22b49 ipa_write_summaries_1
        ../../gcc/passes.c:2471
0xe22b49 ipa_write_summaries()
        ../../gcc/passes.c:2531
0xd41543 ipa_passes
        ../../gcc/cgraphunit.c:2216
0xd41543 symbol_table::compile()
        ../../gcc/cgraphunit.c:2312
0xd50e1d symbol_table::finalize_compilation_unit()
        ../../gcc/cgraphunit.c:2461
0xdd9dc0 cp_write_global_declarations()
        ../../gcc/cp/decl2.c:4755


Breakpoint 1, lto_write_tree (ob=0x1a41670, expr=0x7ffff6c41948, ref_p=false)
at ../../gcc/lto-streamer-out.c:415
415                         get_tree_code_name (TREE_CODE (expr)));
(gdb) p debug_tree(expr)
 <call_expr 0x7ffff6c41948
    type <void_type 0x7ffff6c5d000 void VOID
        align 8 symtab 0 alias set -1 canonical type 0x7ffff6c5d000
        pointer_to_this <pointer_type 0x7ffff6c5d150>>
    side-effects tree_0 tree_3
    arg 0 <addr_expr 0x7ffff6dc4540
        type <pointer_type 0x7ffff6c5d7e0 type <integer_type 0x7ffff6c3b690
int>
            public unsigned DI
            size <integer_cst 0x7ffff6c37e58 constant 64>
            unit size <integer_cst 0x7ffff6c37e70 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff6c5d7e0>
        constant
        arg 0 <var_decl 0x7ffff6c44cf0 a type <integer_type 0x7ffff6c3b690 int>
            addressable used public static weak decl_5 decl_6 SI file test.ii
line 9 col 16
            size <integer_cst 0x7ffff6c590a8 constant 32>
            unit size <integer_cst 0x7ffff6c590c0 constant 4>
            align 32 context <function_decl 0x7ffff6dd7870 m_fn2> chain
<var_decl 0x7ffff6c44d80 b>>>
    arg 1 <integer_cst 0x7ffff6dd6588 type <pointer_type 0x7ffff6c5d7e0>
constant 2>
    arg 2 <integer_cst 0x7ffff6c59288 type <integer_type 0x7ffff6c5d348>
constant 0>>
$1 = void


Thanks,
Martin
>From gcc-bugs-return-486510-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 18 08:51:28 2015
Return-Path: <gcc-bugs-return-486510-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31571 invoked by alias); 18 May 2015 08:51:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31530 invoked by uid 48); 18 May 2015 08:51:23 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/66110] uint8_t memory access not optimized
Date: Mon, 18 May 2015 08:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords: alias, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-66110-4-KAVjQtWsng@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66110-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66110-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg01350.txt.bz2
Content-length: 1602

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf110

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Kevin OConnor from comment #8)
> Thanks!  I can confirm the latest trunk performs the desired optimization.
>
> However, this test case still isn't fully optimized:
>
> void f2(struct s1 *ps1, uint8_t *pi8)
> {
>     ps1->f1 = 3;
>     *pi8 = 8;
>     ps1->f1 += 2;
> }
>
> That is, an "uint8_t*" still aliases with every other type. The "struct"
> optimization is more important for my usage, but it is unfortunate that
> uint8_t*/int8_t* are pessimized.  (In particular, there does not appear to
> be any way to declare a pointer to an 8 bit integer that doesn't alias every
> other type.)
>
> I can open a separate bugzilla entry on the above.

Well, so it ultimiatively boils down to GCC defining

#define __UINT8_TYPE__ unsigned char

and that being a character type.  I'm not sure whether the C or C++ standards
mandate that uint8_t be a 'character type' as far as type-based aliasing goes
but I would expect that user-code may rely on that property.  So yes, there
would be no 1-byte type that doesn't get alias-set zero.  Well - you could
use

struct byte { uint8_t b; };

and make sure to use aggregate assignments everywhere, only ever extracting
the actual value from temporary aggregates...


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
@ 2015-05-18 12:45 ` rguenth at gcc dot gnu.org
  2015-05-18 13:02 ` mpolacek at gcc dot gnu.org
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-05-18 12:45 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.2


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
  2015-05-18 12:45 ` [Bug sanitizer/66190] " rguenth at gcc dot gnu.org
@ 2015-05-18 13:02 ` mpolacek at gcc dot gnu.org
  2015-05-18 13:06 ` mpolacek at gcc dot gnu.org
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-05-18 13:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-18
     Ever confirmed|0                           |1

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
  2015-05-18 12:45 ` [Bug sanitizer/66190] " rguenth at gcc dot gnu.org
  2015-05-18 13:02 ` mpolacek at gcc dot gnu.org
@ 2015-05-18 13:06 ` mpolacek at gcc dot gnu.org
  2015-05-18 13:40 ` mpolacek at gcc dot gnu.org
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-05-18 13:06 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r213406.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2015-05-18 13:06 ` mpolacek at gcc dot gnu.org
@ 2015-05-18 13:40 ` mpolacek at gcc dot gnu.org
  2015-05-18 16:55 ` mpolacek at gcc dot gnu.org
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-05-18 13:40 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
So
static int & b = (int &) (UBSAN_NULL (&a, 2B, 0);, &a;);
survives it to the expansion.  It appears that we shouldn't instrument statics
like that.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2015-05-18 13:40 ` mpolacek at gcc dot gnu.org
@ 2015-05-18 16:55 ` mpolacek at gcc dot gnu.org
  2015-05-19 13:34 ` marxin at gcc dot gnu.org
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-05-18 16:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
So maybe the following?  Not sure how well it plays with weak vars/fns
though...

--- a/gcc/c-family/c-ubsan.c
+++ b/gcc/c-family/c-ubsan.c
@@ -433,8 +433,9 @@ ubsan_maybe_instrument_reference_or_call (location_t loc,
tree op, tree ptype,
          int save_flag_delete_null_pointer_checks
            = flag_delete_null_pointer_checks;
          flag_delete_null_pointer_checks = 1;
-         if (!tree_single_nonzero_warnv_p (op, &strict_overflow_p)
-             || strict_overflow_p)
+         if ((!tree_single_nonzero_warnv_p (op, &strict_overflow_p)
+              || strict_overflow_p)
+             && !TREE_STATIC (TREE_OPERAND (op, 0)))
            instrument = true;
          flag_delete_null_pointer_checks
            = save_flag_delete_null_pointer_checks;


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2015-05-18 16:55 ` mpolacek at gcc dot gnu.org
@ 2015-05-19 13:34 ` marxin at gcc dot gnu.org
  2015-05-19 14:18 ` jakub at gcc dot gnu.org
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2015-05-19 13:34 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3933 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #5)
> So maybe the following?  Not sure how well it plays with weak vars/fns
> though...
> 
> --- a/gcc/c-family/c-ubsan.c
> +++ b/gcc/c-family/c-ubsan.c
> @@ -433,8 +433,9 @@ ubsan_maybe_instrument_reference_or_call (location_t
> loc, tree op, tree ptype,
>           int save_flag_delete_null_pointer_checks
>             = flag_delete_null_pointer_checks;
>           flag_delete_null_pointer_checks = 1;
> -         if (!tree_single_nonzero_warnv_p (op, &strict_overflow_p)
> -             || strict_overflow_p)
> +         if ((!tree_single_nonzero_warnv_p (op, &strict_overflow_p)
> +              || strict_overflow_p)
> +             && !TREE_STATIC (TREE_OPERAND (op, 0)))
>             instrument = true;
>           flag_delete_null_pointer_checks
>             = save_flag_delete_null_pointer_checks;

Hi.

Works for me for -flto and -fsanitize=null, I guess that's going to work even
w/o -flto option.

Thanks,
Martin
>From gcc-bugs-return-486671-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 19 13:42:28 2015
Return-Path: <gcc-bugs-return-486671-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 53237 invoked by alias); 19 May 2015 13:42:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 53227 invoked by uid 89); 19 May 2015 13:42:27 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.0 required=5.0 testsºYES_40,MIME_QP_LONG_LINE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: fencepost.gnu.org
Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 19 May 2015 13:42:17 +0000
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45706)	by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)	(Exim 4.71)	id 1Yuhmg-0004Im-JQ	for bug-gcc@gnu.org; Tue, 19 May 2015 09:42:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)	id 1Yuhmb-0001Pd-Kg	for bug-gcc@gnu.org; Tue, 19 May 2015 09:42:14 -0400
Received: from novusi.com ([87.117.226.195]:64617)	by eggs.gnu.org with esmtp (Exim 4.71)	id 1Yuhmb-0001Nm-An	for bug-gcc@gnu.org; Tue, 19 May 2015 09:42:09 -0400
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <A2BB0402-2169-4C9F-9A11-E505935677C5@novusi.com>
Date: Tue, 19 May 2015 13:42:00 -0000
From: mailer-daemon@novusi.com
To: bug-gcc@gnu.org
Subject: Message undeliverable: adjustment reminder
Content-Transfer-Encoding: quoted-printable
X-hMailServer-LoopCount: 2
X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy]
X-Received-From: 87.117.226.195
X-SW-Source: 2015-05/txt/msg01511.txt.bz2
Content-length: 641

Your message did not reach some or all of the intended recipients.

   Sent: Tue, 19 May 2015 14:41:23 +0100
   Subject: adjustment reminder 

The following recipient(s) could not be reached:

justdiguk@gmail.com
   Error Type: SMTP
   Remote server (173.194.78.27) issued an error.
   hMailServer sent: .
   Remote server replied: 552-5.7.0 This message was blocked because its content presents a potential
552-5.7.0 security issue. Please visit
552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to review our
552 5.7.0 message content and attachment content guidelines. t16si8959386wiv.3 - gsmtp



hMailServer


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2015-05-19 13:34 ` marxin at gcc dot gnu.org
@ 2015-05-19 14:18 ` jakub at gcc dot gnu.org
  2015-05-21 11:04 ` mpolacek at gcc dot gnu.org
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-05-19 14:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That looks just wrong. ADDR_EXPR's operand isn't necessarily a decl, testing
TREE_STATIC on random trees can give pretty random answers.
I think what matters is where do we cp_genericize_r the DECL_INITIAL of a
static variable, if that happens, perhaps we should track that case in
cp_genericize_data and not instrument anything in there.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2015-05-19 14:18 ` jakub at gcc dot gnu.org
@ 2015-05-21 11:04 ` mpolacek at gcc dot gnu.org
  2015-06-03 16:55 ` mpolacek at gcc dot gnu.org
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-05-21 11:04 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Ok, then maybe the following could work (only lightly tested so far).  Arguably
static_init_p could be renamed to e.g. no_sanitize_p.

diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
index d5a64fc..a90c8b7 100644
--- gcc/cp/cp-gimplify.c
+++ gcc/cp/cp-gimplify.c
@@ -906,6 +906,7 @@ struct cp_genericize_data
   vec<tree> bind_expr_stack;
   struct cp_genericize_omp_taskreg *omp_ctx;
   tree try_block;
+  bool static_init_p;
 };

 /* Perform any pre-gimplification lowering of C++ front end trees to
@@ -1150,6 +1151,21 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void
*data)
       *stmt_p = build1 (NOP_EXPR, void_type_node, integer_zero_node);
       *walk_subtrees = 0;
     }
+  else if ((flag_sanitize
+           & (SANITIZE_NULL | SANITIZE_ALIGNMENT | SANITIZE_VPTR))
+          && TREE_CODE (stmt) == DECL_EXPR
+          && VAR_P (DECL_EXPR_DECL (stmt))
+          && TREE_STATIC (DECL_EXPR_DECL (stmt))
+          && DECL_INITIAL (DECL_EXPR_DECL (stmt)))
+    {
+      *walk_subtrees = 0;
+      /* The point here is to not sanitize static initializers.  */
+      bool static_init_p = wtd->static_init_p;
+      wtd->static_init_p = true;
+      cp_walk_tree (&DECL_INITIAL (DECL_EXPR_DECL (stmt)), cp_genericize_r,
+                   data, NULL);
+      wtd->static_init_p = static_init_p;
+    }
   else if (TREE_CODE (stmt) == OMP_PARALLEL || TREE_CODE (stmt) == OMP_TASK)
     {
       struct cp_genericize_omp_taskreg omp_ctx;
@@ -1275,9 +1291,10 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void
*data)
       if (*stmt_p == error_mark_node)
        *stmt_p = size_one_node;
       return NULL;
-    }    
-  else if (flag_sanitize
-          & (SANITIZE_NULL | SANITIZE_ALIGNMENT | SANITIZE_VPTR))
+    }
+  else if ((flag_sanitize
+           & (SANITIZE_NULL | SANITIZE_ALIGNMENT | SANITIZE_VPTR))
+          && !wtd->static_init_p)
     {
       if ((flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT))
          && TREE_CODE (stmt) == NOP_EXPR
@@ -1319,6 +1336,7 @@ cp_genericize_tree (tree* t_p)
   wtd.bind_expr_stack.create (0);
   wtd.omp_ctx = NULL;
   wtd.try_block = NULL_TREE;
+  wtd.static_init_p = false;
   cp_walk_tree (t_p, cp_genericize_r, &wtd, NULL);
   delete wtd.p_set;
   wtd.bind_expr_stack.release ();


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (7 preceding siblings ...)
  2015-05-21 11:04 ` mpolacek at gcc dot gnu.org
@ 2015-06-03 16:55 ` mpolacek at gcc dot gnu.org
  2015-06-03 17:00 ` mpolacek at gcc dot gnu.org
  2015-06-04  8:39 ` mpolacek at gcc dot gnu.org
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-06-03 16:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Wed Jun  3 16:54:24 2015
New Revision: 224096

URL: https://gcc.gnu.org/viewcvs?rev=224096&root=gcc&view=rev
Log:
        PR sanitizer/66190
        * cp-gimplify.c (struct cp_genericize_data): Add no_sanitize_p.
        (cp_genericize_r): Don't instrument static initializers.
        (cp_genericize_tree): Initialize wtd.no_sanitize_p.

        * g++.dg/ubsan/static-init-1.C: New test.
        * g++.dg/ubsan/static-init-2.C: New test.
        * g++.dg/ubsan/static-init-3.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/ubsan/static-init-1.C
    trunk/gcc/testsuite/g++.dg/ubsan/static-init-2.C
    trunk/gcc/testsuite/g++.dg/ubsan/static-init-3.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-gimplify.c
    trunk/gcc/testsuite/ChangeLog


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (8 preceding siblings ...)
  2015-06-03 16:55 ` mpolacek at gcc dot gnu.org
@ 2015-06-03 17:00 ` mpolacek at gcc dot gnu.org
  2015-06-04  8:39 ` mpolacek at gcc dot gnu.org
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-06-03 17:00 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
  2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
                   ` (9 preceding siblings ...)
  2015-06-03 17:00 ` mpolacek at gcc dot gnu.org
@ 2015-06-04  8:39 ` mpolacek at gcc dot gnu.org
  10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-06-04  8:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #11 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Thu Jun  4 08:39:01 2015
New Revision: 224117

URL: https://gcc.gnu.org/viewcvs?rev=224117&root=gcc&view=rev
Log:
        PR sanitizer/66190
        * cp-gimplify.c (struct cp_genericize_data): Add no_sanitize_p.
        (cp_genericize_r): Don't instrument static initializers.
        (cp_genericize_tree): Initialize wtd.no_sanitize_p.

        * g++.dg/ubsan/static-init-1.C: New test.
        * g++.dg/ubsan/static-init-2.C: New test.
        * g++.dg/ubsan/static-init-3.C: New test.

Added:
    branches/gcc-5-branch/gcc/testsuite/g++.dg/ubsan/static-init-1.C
    branches/gcc-5-branch/gcc/testsuite/g++.dg/ubsan/static-init-2.C
    branches/gcc-5-branch/gcc/testsuite/g++.dg/ubsan/static-init-3.C
Modified:
    branches/gcc-5-branch/gcc/cp/ChangeLog
    branches/gcc-5-branch/gcc/cp/cp-gimplify.c
    branches/gcc-5-branch/gcc/testsuite/ChangeLog


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2015-06-04  8:39 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-18  8:49 [Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null marxin at gcc dot gnu.org
2015-05-18 12:45 ` [Bug sanitizer/66190] " rguenth at gcc dot gnu.org
2015-05-18 13:02 ` mpolacek at gcc dot gnu.org
2015-05-18 13:06 ` mpolacek at gcc dot gnu.org
2015-05-18 13:40 ` mpolacek at gcc dot gnu.org
2015-05-18 16:55 ` mpolacek at gcc dot gnu.org
2015-05-19 13:34 ` marxin at gcc dot gnu.org
2015-05-19 14:18 ` jakub at gcc dot gnu.org
2015-05-21 11:04 ` mpolacek at gcc dot gnu.org
2015-06-03 16:55 ` mpolacek at gcc dot gnu.org
2015-06-03 17:00 ` mpolacek at gcc dot gnu.org
2015-06-04  8:39 ` mpolacek at gcc dot gnu.org

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).