[Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[Bug sanitizer/63956] New: [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[burnus at gcc dot gnu.org]

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

            Bug ID: 63956
           Summary: [5 Regression][UBSAN] ICE segfault in
                    cxx_eval_call_expression ../../gcc/cp/constexpr.c
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus 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,
                    mpolacek at gcc dot gnu.org

Created attachment 34035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34035&action=edit
Test case (scan16.ii)

That's a new regression. It was working when I reduce PR63813 (i.e. on
2014-11-11) as that ICE came later. It now ICEs with todays GCC (r217759).

g++ -S -std=c++11 -fsanitize=undefined scan16.ii

scan16.ii:51:28:   in constexpr expansion of
‘std::validator.std::unique_ptr<std::Validator>::unique_ptr()’
scan16.ii:51:28: internal compiler error: Segmentation fault
   unique_ptr < Validator > validator;
                            ^
0xcba72f crash_signal
        ../../gcc/toplev.c:359
0x81ea9a cxx_eval_call_expression
        ../../gcc/cp/constexpr.c:1147
0x820b1c cxx_eval_constant_expression
        ../../gcc/cp/constexpr.c:2864
>From gcc-bugs-return-467373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 19 11:22:53 2014
Return-Path: <gcc-bugs-return-467373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28247 invoked by alias); 19 Nov 2014 11:22:53 -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 28225 invoked by uid 48); 19 Nov 2014 11:22:50 -0000
From: "pab at pabigot dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63954] msp430 multiplication unsafe for use in interrupts
Date: Wed, 19 Nov 2014 11:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pab at pabigot dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-63954-4-JV7cYqhiOl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63954-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63954-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/msg01845.txt.bz2
Content-length: 500

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

Peter A. Bigot <pab at pabigot dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Peter A. Bigot <pab at pabigot dot com> ---
Sorry, bogus: the necessary dint/conditional eint are present in the macro
wrappers.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[jakub at gcc dot gnu.org]

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.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[jason at gcc dot gnu.org]

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

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[jakub at gcc dot gnu.org]

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

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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.  */

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[jakub at gcc dot gnu.org]

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.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[jakub at gcc dot gnu.org]

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

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[jakub at gcc dot gnu.org]

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.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Of course.  Thanks.

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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

[Bug sanitizer/63956] [5 Regression][UBSAN] ICE segfault in cxx_eval_call_expression ../../gcc/cp/constexpr.c

[mpolacek at gcc dot gnu.org]

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.