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