[Bug c++/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[Bug c++/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[vanyacpp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

Ivan Sorokin <vanyacpp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vanyacpp at gmail dot com

--- Comment #3 from Ivan Sorokin <vanyacpp at gmail dot com> 2012-04-08 12:11:02 UTC ---
> Really I think this is a not good option.  It adds a huge overhead in some
> cases and does not fix a security issue.  In fact it allows the developer to
> feel more safe when in reality they are not.

I think the rationale for this checking is not a security issue, but the ease
of debugging. When a program is shipped to end user these checks could be
omitted.

[Bug c++/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-08 14:06:31 UTC ---
Indeed.  I think it's meant to be useful for catching some of the problems that
valgrind identifies, and valgrind has even more performance overhead.

That said, although I haven't used it heavily clang's
-fcatch-undefined-behavior has never caught any problems for me. YMMV.

[Bug middle-end/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-08 18:57:51 UTC ---
>  # Subscripting where the static type of one operand is variable which is
decayed from an array type and the other operand is greater than the size of
the array or less than zero.


That sounds like -fbounds-check.

[Bug middle-end/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus at trippelsdorf dot
                   |                            |de

--- Comment #6 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-11-08 12:53:17 UTC ---
Just for fun, today I've build gcc trunk with:
CC="clang -fsanitize=undefined -w" CXX="clang++ -fsanitize=undefined -w"
~/gcc/configure --disable-bootstrap --disable-werror --disable-multilib
--enable-languages=c,c++


It didn't get very far (haven't looked deeper yet):

gcc/libiberty/regex.c:6968:11: fatal error: left shift of negative value -1

gcc/gcc/genattrtab.c:625:27: fatal error: signed integer overflow: 4568797 *
613 cannot be represented in type 'int'

gcc/gcc/genautomata.c:3510:23: fatal error: shift exponent 64 is too large for
64-bit type 'set_el_t' (aka 'unsigned long')

[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|-fcatch-undefined-behavior: |-fsanitize=undefined: Turn
                   |Turn on runtime code        |on runtime code generation
                   |generation to check for     |to check for undefined
                   |undefined behavior          |behavior

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-11-08 13:21:54 UTC ---
> It didn't get very far (haven't looked deeper yet):

This PR is for implementing those checks in GCC. For things broken in GCC, you
should open new PRs.

BTW, Clang now supports all these checks:

    -fsanitize=alignment: Use of a misaligned pointer or creation of a
misaligned reference.
    -fsanitize=divide-by-zero: Division by zero.
    -fsanitize=float-cast-overflow: Conversion to, from, or between
floating-point types which would overflow the destination.
    -fsanitize=null: Use of a null pointer or creation of a null reference.
    -fsanitize=object-size: An attempt to use bytes which the optimizer can
determine are not part of the object being accessed. The sizes of objects are
determined using __builtin_object_size, and consequently may be able to detect
more problems at higher optimization levels.
    -fsanitize=return: In C++, reaching the end of a value-returning function
without returning a value.
    -fsanitize=shift: Shift operators where the amount shifted is greater or
equal to the promoted bit-width of the left hand side or less than zero, or
where the left hand side is negative. For a signed left shift, also checks for
signed overflow in C, and for unsigned overflow in C++.
    -fsanitize=signed-integer-overflow: Signed integer overflow, including all
the checks added by -ftrapv, and checking for overflow in signed division
(INT_MIN / -1).
    -fsanitize=unreachable: If control flow reaches __builtin_unreachable.
    -fsanitize=vla-bound: A variable-length array whose bound does not evaluate
to a positive value.
    -fsanitize=vptr: Use of an object whose vptr indicates that it is of the
wrong dynamic type, or that its lifetime has not begun or has ended.
Incompatible with -fno-rtti.

[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent-gcc at vinc17 dot net

--- Comment #8 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
GCC 4.9, which has just been released, has -fsanitize=undefined (and some other
-fsanitize checks):

http://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html#Debugging-Options

However it only gives a runtime diagnostic message. It basically lacks clang's
-fno-sanitize-recover option to make the program abort (useful for test
suites). After that, I suppose that this enhancement would be complete (it
doesn't check all kinds of undefined behavior, such as the use of uninitialized
variables, but clang doesn't do this either).
>From gcc-bugs-return-449859-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 25 08:23:28 2014
Return-Path: <gcc-bugs-return-449859-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29197 invoked by alias); 25 Apr 2014 08:23: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 28593 invoked by uid 55); 25 Apr 2014 08:23:22 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60156] GCC doesn't warn about variadic main
Date: Fri, 25 Apr 2014 08:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60156-4-MZbNuTyqNP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60156-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60156-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-04/txt/msg01879.txt.bz2
Content-length: 552

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`156

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Fri Apr 25 08:22:47 2014
New Revision: 209787

URL: http://gcc.gnu.org/viewcvs?rev 9787&root=gcc&view=rev
Log:
    PR c/60156
    * c-common.c (check_main_parameter_types): Warn about variadic main.

    * c-c++-common/pr60156.c: New test.


Added:
    trunk/gcc/testsuite/c-c++-common/pr60156.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

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

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

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #8)
> However it only gives a runtime diagnostic message. It basically lacks
> clang's -fno-sanitize-recover option to make the program abort (useful for
> test suites). After that, I suppose that this enhancement would be complete
> (it doesn't check all kinds of undefined behavior, such as the use of
> uninitialized variables, but clang doesn't do this either).

-fno-sanitize-recover is now implemented in the mainline, see PR60275.
>From gcc-bugs-return-449862-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 25 08:55:46 2014
Return-Path: <gcc-bugs-return-449862-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32058 invoked by alias); 25 Apr 2014 08:55:45 -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 31994 invoked by uid 48); 25 Apr 2014 08:55:39 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60896] [4.10 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
Date: Fri, 25 Apr 2014 08:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-60896-4-lu38jD0pO7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60896-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60896-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-04/txt/msg01882.txt.bz2
Content-length: 447

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`896

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #5 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Fixed. Thanks.

[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Okay, closing.

[Bug c++/44786] New: -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[manu at gcc dot gnu dot org]

Clang provides a number of ways to control code generation. The options are
listed below.
-fcatch-undefined-behavior: Turn on runtime code generation to check for
undefined behavior.
    This option, which defaults to off, controls whether or not Clang adds
runtime checks for undefined runtime behavior. If the check fails,
__builtin_trap() is used to indicate failure. The checks are:

  # Subscripting where the static type of one operand is variable which is
decayed from an array type and the other operand is greater than the size of
the array or less than zero.
  # Shift operators where the amount shifted is greater or equal to the
promoted bit-width of the left-hand-side or less than zero.
  # If control flow reaches __builtin_unreachable.


-- 
           Summary: -fcatch-undefined-behavior: Turn on runtime code
                    generation to check for undefined behavior
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

[Bug c++/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2010-07-05 01:21 -------
-ftrapv checks for one undefined behavior which is not mentioned in that list. 
Why isn't that listed?

>  # Shift operators where the amount shifted is greater or equal to the
promoted bit-width of the left-hand-side or less than zero.

I think C90 and C99 say slightly different things here.

Really I think this is a not good option.  It adds a huge overhead in some
cases and does not fix a security issue.  In fact it allows the developer to
feel more safe when in reality they are not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

[Bug c++/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[joseph at codesourcery dot com]

------- Comment #2 from joseph at codesourcery dot com  2010-07-23 20:41 -------
Subject: Re:  -fcatch-undefined-behavior: Turn on runtime code
 generation to check for undefined behavior

On Mon, 5 Jul 2010, pinskia at gcc dot gnu dot org wrote:

> -ftrapv checks for one undefined behavior which is not mentioned in that list. 
> Why isn't that listed?
> 
> >  # Shift operators where the amount shifted is greater or equal to the
> promoted bit-width of the left-hand-side or less than zero.
> 
> I think C90 and C99 say slightly different things here.

You may be thinking of the cases of signed left shift that are undefined 
only in C99 (and implementation-defined in C90).

I think having options to trap on various detectable cases of undefined 
behavior *is* a good idea, but there should be separate options for the 
separate cases.  Thus we already have -ftrapv (which, if made to work 
properly, might have different variants for strict detection of overflow 
and for allowing overflows to be folded away) and could add -ftrapv-shift 
to detect cases of shift counts out of range (similarly, -fwrapv-shift to 
give defined results for such shifts).  You might then consider a 
catch-all option to enable the various separate options.

The C1x drafts have a woefully underdefined Analyzability annex describing 
an option that bounds most kinds of undefined behavior.  If this ever gets 
better specified than it is at present, there would be various 
possibilities for an option to implement that annex, either trapping on 
particular undefined behavior or bounding what effects it has.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786