* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
@ 2014-11-19 11:27 ` mpolacek at gcc dot gnu.org
2014-11-19 11:34 ` mpolacek at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-11-19 11:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-11-19
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
2014-11-19 11:27 ` [Bug sanitizer/63956] " mpolacek at gcc dot gnu.org
@ 2014-11-19 11:34 ` mpolacek at gcc dot gnu.org
2014-11-19 12:15 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-11-19 11:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
It looks like cxx_eval_call_expression just isn't prepared for internal
functions, with NULL_TREE CALL_EXPR_FN.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
2014-11-19 11:27 ` [Bug sanitizer/63956] " mpolacek at gcc dot gnu.org
2014-11-19 11:34 ` mpolacek at gcc dot gnu.org
@ 2014-11-19 12:15 ` jakub at gcc dot gnu.org
2014-11-19 22:09 ` jason at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-19 12:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Supposedly with the C++14 constexpr changes we need to be prepared to handle
all the ubsan builtins and internal calls we create during genericization.
Already in the still pending -fsanitize=vptr patch I had to deal with handling
the ubsan vptr type cache miss builtin even before the C++14 constexpr changes,
because that is created during static_cast handling, but if we now look at
DECL_SAVED_TREE, it can see all the builtins / internal calls in there.
I hope most of the ubsan stuff can be ignored for constexpr purposes.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2014-11-19 12:15 ` jakub at gcc dot gnu.org
@ 2014-11-19 22:09 ` jason at gcc dot gnu.org
2014-11-19 22:12 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jason at gcc dot gnu.org @ 2014-11-19 22:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Supposedly with the C++14 constexpr changes we need to be prepared to handle
> all the ubsan builtins and internal calls we create during genericization.
Hmm, maybe I should make a copy of the pre-genericization DECL_SAVED_TREE
instead...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2014-11-19 22:09 ` jason at gcc dot gnu.org
@ 2014-11-19 22:12 ` jakub at gcc dot gnu.org
2014-11-19 22:37 ` mpolacek at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-19 22:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If it would be just because of these 3-4 builtins/internal calls, then it is
not worth it IMHO, making a copy would increase compiler memory footprint.
Already from the earlier phases there are some ubsan builtins in there anyway
(shift instrumentation e.g.).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2014-11-19 22:12 ` jakub at gcc dot gnu.org
@ 2014-11-19 22:37 ` mpolacek at gcc dot gnu.org
2014-11-19 22:42 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-11-19 22:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Earlier today I tried the following and it seemed to work, but I don't know
constexpr.c, so it may be totally bogus.
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -1149,6 +1149,10 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
constexpr_call *entry;
bool depth_ok;
+ if (fun == NULL_TREE
+ && CALL_EXPR_IFN (t) == IFN_UBSAN_NULL)
+ return t;
+
if (TREE_CODE (fun) != FUNCTION_DECL)
{
/* Might be a constexpr function pointer. */
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (5 preceding siblings ...)
2014-11-19 22:37 ` mpolacek at gcc dot gnu.org
@ 2014-11-19 22:42 ` jakub at gcc dot gnu.org
2014-11-19 22:54 ` mpolacek at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-19 22:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #6)
> Earlier today I tried the following and it seemed to work, but I don't know
> constexpr.c, so it may be totally bogus.
>
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -1149,6 +1149,10 @@ cxx_eval_call_expression (const constexpr_ctx *ctx,
> tree t,
> constexpr_call *entry;
> bool depth_ok;
>
> + if (fun == NULL_TREE
> + && CALL_EXPR_IFN (t) == IFN_UBSAN_NULL)
> + return t;
> +
> if (TREE_CODE (fun) != FUNCTION_DECL)
> {
> /* Might be a constexpr function pointer. */
The -fsanitize=vptr patch has:
if (is_builtin_fn (fun))
- return cxx_eval_builtin_function_call (old_call, t, allow_non_constant,
- addr, non_constant_p, overflow_p);
+ {
+ /* Ignore -fsanitize=vptr instrumentation. */
+ if ((flag_sanitize & SANITIZE_VPTR)
+ && DECL_BUILT_IN_CLASS (fun) == BUILT_IN_NORMAL
+ && (DECL_FUNCTION_CODE (fun)
+ == ((flag_sanitize_recover & SANITIZE_VPTR)
+ ? BUILT_IN_UBSAN_HANDLE_DYNAMIC_TYPE_CACHE_MISS
+ : BUILT_IN_UBSAN_HANDLE_DYNAMIC_TYPE_CACHE_MISS_ABORT))
+ && call_expr_nargs (t) == 4)
+ return void_node;
+
+ return cxx_eval_builtin_function_call (old_call, t, allow_non_constant,
+ addr, non_constant_p, overflow_p);
+ }
hunk in it to ignore __builtin___ubsan_handle_dynamic_type_cache_miss*.
For fun == NULL_TREE, guess what you want is a switch on the CALL_EXPR_IFN
value and enumerate there all the internal calls and elsewhere builtins that
should be ignored.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (6 preceding siblings ...)
2014-11-19 22:42 ` jakub at gcc dot gnu.org
@ 2014-11-19 22:54 ` mpolacek at gcc dot gnu.org
2014-11-20 7:18 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-11-19 22:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Thanks, will try that tomorrow.
So to ignore the call I should return void_node instead of t, good to know.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2014-11-19 22:54 ` mpolacek at gcc dot gnu.org
@ 2014-11-20 7:18 ` jakub at gcc dot gnu.org
2014-11-20 16:13 ` mpolacek at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-20 7:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In the light of -std=c++14 constexprs, please try to write testcases like
(-std=c++14 -fsanitize=undefined,float-divide-by-zero,float-cast-overflow):
constexpr int
f1 (int a, int b)
{
if (b != 2)
a <<= b;
return a;
}
constexpr int x1 = f1 (5, 3);
constexpr int x2 = f1 (5, -2);
constexpr int
f2 (int a, int b)
{
if (b != 2)
a = a / b;
return a;
}
constexpr int x3 = f2 (5, 3);
constexpr int x4 = f2 (7, 0);
constexpr int x5 = f2 (-__INT_MAX__ - 1, -1);
constexpr float
f3 (float a, float b)
{
if (b != 2.0)
a = a / b;
return a;
}
constexpr float x6 = f3 (5.0, 3.0);
constexpr float x7 = f3 (7.0, 0.0);
constexpr int
f4 (const int *a, int b)
{
if (b != 2)
b = a[b];
return b;
}
constexpr int x8[4] = { 1, 2, 3, 4 };
constexpr int x9 = f4 (x8, 3);
constexpr int x10 = f4 (x8, 4);
constexpr int
f5 (const int &a, int b)
{
if (b != 2)
b = a;
return b;
}
constexpr int
f6 (const int *a, int b)
{
if (b != 3)
return f5 (*a, b);
return 7;
}
constexpr int x12 = 7;
constexpr int x13 = f6 (&x12, 5);
constexpr int x14 = f6 ((const int *) 0, 8);
(and add for all the other stuff we ubsan instrument in the FEs).
For the first snippet we e.g. emit:
m1.C:10:23: in constexpr expansion of ‘f1(5, -2)’
m1.C:5:7: error: ‘<ubsan routine call>’ is not a constant expression
a <<= b;
^
m1.C:10:29: error: constexpr call flows off the end of the function
constexpr int x2 = f1 (5, -2);
^
I'd say we should not, we should just ignore the ubsan routine call.
If C++14 constexprs are supposed to be invalid if there is undefined behavior
in them while being interpreted by the compiler with the given arguments, then
supposedly the FE should regardless of -fsanitize=undefined error out or warn
and say exactly what is invalid in there, talking about <ubsan routine call>
is just too confusing. Don't know if rejecting it is just QoI or a requirement
in C++14.
And on the last snippet we ICE, that is the internal call.
Haven't added all the cases there though, and even e.g. for shift I haven't
tried to call it with all the kinds of arguments that are invalid in C++14.
>From gcc-bugs-return-467670-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 20 07:54:31 2014
Return-Path: <gcc-bugs-return-467670-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13367 invoked by alias); 20 Nov 2014 07:54:30 -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 13326 invoked by uid 48); 20 Nov 2014 07:54:26 -0000
From: "yohei at jp dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/63731] Fallback to netgo does not work
Date: Thu, 20 Nov 2014 07:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: yohei at jp dot ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63731-4-JMMVRPHuwr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63731-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63731-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: 2014-11/txt/msg02142.txt.bz2
Content-length: 1252
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc731
--- Comment #12 from Yohei Ueda <yohei at jp dot ibm.com> ---
"pure-Go goLookupIP" means that goLookupIP is written in Go as usual.
https://code.google.com/p/go/source/browse/src/net/dnsclient_unix.go#364
cgoLookupIP uses getaddrinfo via CGO unless the netgo tag is set.
https://code.google.com/p/go/source/browse/src/net/cgo_unix.go#147
Fallback means that goLookupIP is called when cgoLookup fails with ok == false
in this code.
https://code.google.com/p/go/source/browse/src/net/lookup_unix.go#63
func lookupIP(host string) (addrs []IP, err error) {
addrs, err, ok := cgoLookupIP(host)
if !ok {
addrs, err = goLookupIP(host)
}
return
}
When code that uses LookupHost is compiled with "go build -ldflags '-linkmode
external -extldflags -static' -a -tags netgo", the Go standard library
including cgoLookupIP is rebuilt. In this case, cgoLookupIP always returns ok
== false as defined here.
https://code.google.com/p/go/source/browse/src/net/cgo_stub.go#19
func cgoLookupIP(name string) (addrs []IP, err error, completed bool) {
return nil, nil, false
}
This leads to calling goLookupIP from lookupIP. I called this mechanism
"fallback".
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (8 preceding siblings ...)
2014-11-20 7:18 ` jakub at gcc dot gnu.org
@ 2014-11-20 16:13 ` mpolacek at gcc dot gnu.org
2014-11-20 16:15 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-11-20 16:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
BTW, wouldn't it make sense to not instrument things in constexpr functions?
It is not always possible, but at least in cp/ we could skip instrumentation if
DECL_DECLARED_CONSTEXPR_P (current_function_decl), similarly as we check for
no_sanitize_undefined.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (9 preceding siblings ...)
2014-11-20 16:13 ` mpolacek at gcc dot gnu.org
@ 2014-11-20 16:15 ` jakub at gcc dot gnu.org
2014-11-20 16:22 ` mpolacek at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-20 16:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I thought you can call constexpr functions outside of constexpr contexts with
non-constant arguments and they are executed then as any other function, so not
instrumenting would mean you'd miss undefined behavior diagnostics.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (10 preceding siblings ...)
2014-11-20 16:15 ` jakub at gcc dot gnu.org
@ 2014-11-20 16:22 ` mpolacek at gcc dot gnu.org
2014-12-01 15:30 ` mpolacek at gcc dot gnu.org
2014-12-01 15:31 ` mpolacek at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-11-20 16:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Of course. Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (11 preceding siblings ...)
2014-11-20 16:22 ` mpolacek at gcc dot gnu.org
@ 2014-12-01 15:30 ` mpolacek at gcc dot gnu.org
2014-12-01 15:31 ` mpolacek at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-12-01 15:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Mon Dec 1 15:29:11 2014
New Revision: 218221
URL: https://gcc.gnu.org/viewcvs?rev=218221&root=gcc&view=rev
Log:
PR sanitizer/63956
* ubsan.c (is_ubsan_builtin_p): Check also built-in class.
cp/
* constexpr.c: Include ubsan.h.
(cxx_eval_call_expression): Bail out for IFN_UBSAN_{NULL,BOUNDS}
internal functions and for ubsan builtins.
* error.c: Include internal-fn.h.
(dump_expr): Add printing of internal functions.
testsuite/
* c-c++-common/ubsan/shift-5.c: Add xfails.
* g++.dg/ubsan/div-by-zero-1.C: Don't use -w. Add xfail.
* g++.dg/ubsan/pr63956.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr63956.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/shift-5.c
trunk/gcc/testsuite/g++.dg/ubsan/div-by-zero-1.C
trunk/gcc/ubsan.c
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c
2014-11-19 11:19 [Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c burnus at gcc dot gnu.org
` (12 preceding siblings ...)
2014-12-01 15:30 ` mpolacek at gcc dot gnu.org
@ 2014-12-01 15:31 ` mpolacek at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-12-01 15:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63956
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 15+ messages in thread