[Bug sanitizer/67204] New: documentation for sanitizer missing/incomplete

[Bug sanitizer/67204] New: documentation for sanitizer missing/incomplete

[smagnet at yopmail dot com]

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

            Bug ID: 67204
           Summary: documentation for sanitizer missing/incomplete
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: smagnet at yopmail dot com
                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: ---

The GCC manual contains next to no documentation about the use of the various
-fsanitize options.

At the moment, the best source of information are 3rd party sites like the
google AddressSanitizer wiki
<https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer> which refer
primarily to LLVM/Clang; it's not clear how applicable they are to the current
sanitizer implementations in GCC.

The GCC manual should contain a proper description of the sanitizer
functionality.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options

What exactly are you missing?

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Just for reference this is the documentation that is included in GCC (minus the
formating):
-fsanitize=address
Enable AddressSanitizer, a fast memory error detector. Memory access
instructions are instrumented to detect out-of-bounds and use-after-free bugs.
See http://code.google.com/p/address-sanitizer/ for more details. The run-time
behavior can be influenced using the ASAN_OPTIONS environment variable; see
https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags for a
list of supported options. 
-fsanitize=kernel-address
Enable AddressSanitizer for Linux kernel. See
http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel for
more details. 
-fsanitize=thread
Enable ThreadSanitizer, a fast data race detector. Memory access instructions
are instrumented to detect data race bugs. See
http://code.google.com/p/thread-sanitizer/ for more details. The run-time
behavior can be influenced using the TSAN_OPTIONS environment variable; see
https://code.google.com/p/thread-sanitizer/wiki/Flags for a list of supported
options. 
-fsanitize=leak
Enable LeakSanitizer, a memory leak detector. This option only matters for
linking of executables and if neither -fsanitize=address nor -fsanitize=thread
is used. In that case the executable is linked against a library that overrides
malloc and other allocator functions. See
https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer for more
details. The run-time behavior can be influenced using the LSAN_OPTIONS
environment variable. 
-fsanitize=undefined
Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector. Various
computations are instrumented to detect undefined behavior at runtime. Current
suboptions are:
-fsanitize=shift
This option enables checking that the result of a shift operation is not
undefined. Note that what exactly is considered undefined differs slightly
between C and C++, as well as between ISO C90 and C99, etc. 
-fsanitize=integer-divide-by-zero
Detect integer division by zero as well as INT_MIN / -1 division. 
-fsanitize=unreachable
With this option, the compiler turns the __builtin_unreachable call into a
diagnostics message call instead. When reaching the __builtin_unreachable call,
the behavior is undefined. 
-fsanitize=vla-bound
This option instructs the compiler to check that the size of a variable length
array is positive. 
-fsanitize=null
This option enables pointer checking. Particularly, the application built with
this option turned on will issue an error message when it tries to dereference
a NULL pointer, or if a reference (possibly an rvalue reference) is bound to a
NULL pointer, or if a method is invoked on an object pointed by a NULL pointer. 
-fsanitize=return
This option enables return statement checking. Programs built with this option
turned on will issue an error message when the end of a non-void function is
reached without actually returning a value. This option works in C++ only. 
-fsanitize=signed-integer-overflow
This option enables signed integer overflow checking. We check that the result
of +, *, and both unary and binary - does not overflow in the signed
arithmetics. Note, integer promotion rules must be taken into account. That is,
the following is not an overflow:
               signed char a = SCHAR_MAX;
               a++;

-fsanitize=bounds
This option enables instrumentation of array bounds. Various out of bounds
accesses are detected. Flexible array members, flexible array member-like
arrays, and initializers of variables with static storage are not instrumented. 
-fsanitize=bounds-strict
This option enables strict instrumentation of array bounds. Most out of bounds
accesses are detected, including flexible array members and flexible array
member-like arrays. Initializers of variables with static storage are not
instrumented. 
-fsanitize=alignment
This option enables checking of alignment of pointers when they are
dereferenced, or when a reference is bound to insufficiently aligned target, or
when a method or constructor is invoked on insufficiently aligned object. 
-fsanitize=object-size
This option enables instrumentation of memory references using the
__builtin_object_size function. Various out of bounds pointer accesses are
detected. 
-fsanitize=float-divide-by-zero
Detect floating-point division by zero. Unlike other similar options,
-fsanitize=float-divide-by-zero is not enabled by -fsanitize=undefined, since
floating-point division by zero can be a legitimate way of obtaining infinities
and NaNs. 
-fsanitize=float-cast-overflow
This option enables floating-point type to integer conversion checking. We
check that the result of the conversion does not overflow. Unlike other similar
options, -fsanitize=float-cast-overflow is not enabled by -fsanitize=undefined.
This option does not work well with FE_INVALID exceptions enabled. 
-fsanitize=nonnull-attribute
This option enables instrumentation of calls, checking whether null values are
not passed to arguments marked as requiring a non-null value by the nonnull
function attribute. 
-fsanitize=returns-nonnull-attribute
This option enables instrumentation of return statements in functions marked
with returns_nonnull function attribute, to detect returning of null values
from such functions. 
-fsanitize=bool
This option enables instrumentation of loads from bool. If a value other than
0/1 is loaded, a run-time error is issued. 
-fsanitize=enum
This option enables instrumentation of loads from an enum type. If a value
outside the range of values for the enum type is loaded, a run-time error is
issued. 
-fsanitize=vptr
This option enables instrumentation of C++ member function calls, member
accesses and some conversions between pointers to base and derived classes, to
verify the referenced object has the correct dynamic type.
While -ftrapv causes traps for signed overflows to be emitted,
-fsanitize=undefined gives a diagnostic message. This currently works only for
the C family of languages.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[smagnet at yopmail dot com]

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

--- Comment #3 from smagnet at yopmail dot com ---
> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options
> What exactly are you missing?

Basically, I think the information from the address sanitizer wiki (and the
other linked pages) should be integrated into the GCC manual, rather than the
manual referring to the wiki, such that the manual is self-contained.

The google code wiki only refers to LLVM, and it's not clear to the reader (to
me at least) if it is still being maintained (given that "Google Code will be
turning read-only") and to what extent it applies to GCC.

Moreover, the undefined behavior sanitizer runtime options (UBSAN_OPTIONS, as
described here
<https://www.chromium.org/developers/testing/undefinedbehaviorsanitizer>)
aren't documented at all in the manual.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[trippels at gcc dot gnu.org]

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

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

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

--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
LLVM is were all new Sanitizer development happens.
gcc's libsanitizer just merges from upstream from time to time.

I don't think that duplicating all documentation is necessary.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to smagnet from comment #3)
> Moreover, the undefined behavior sanitizer runtime options (UBSAN_OPTIONS,
> as described here
> <https://www.chromium.org/developers/testing/undefinedbehaviorsanitizer>)
> aren't documented at all in the manual.

UBSAN_OPTIONS isn't currently supported by GCC.

(In reply to Markus Trippelsdorf from comment #4)
> LLVM is were all new Sanitizer development happens.
> gcc's libsanitizer just merges from upstream from time to time.
> 
> I don't think that duplicating all documentation is necessary.

Agreed.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[y.gribov at samsung dot com]

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

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |y.gribov at samsung dot com

--- Comment #6 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Markus Trippelsdorf from comment #4)
> LLVM is were all new Sanitizer development happens.
> gcc's libsanitizer just merges from upstream from time to time.
> 
> I don't think that duplicating all documentation is necessary.

Perhaps we could at least mention upstream site in GCC docs?

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[manu at gcc dot gnu.org]

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

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

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #5)
> (In reply to smagnet from comment #3)
> > Moreover, the undefined behavior sanitizer runtime options (UBSAN_OPTIONS,
> > as described here
> > <https://www.chromium.org/developers/testing/undefinedbehaviorsanitizer>)
> > aren't documented at all in the manual.
> 
> UBSAN_OPTIONS isn't currently supported by GCC.

These kind of divergences give reason to think that the sanitizers should be
further documented in the GCC manual. Another example is the range of supported
platforms: GCC's sanitizer could in principle support different ones (more?
fewer?) than Clang's.

I'm not saying that anyone should stop working on what they are doing to
implement this, but if a volunteer appears (Smagnet?) and wants to work on
this, why not allow them? Perhaps they can create better documentation than the
official one.
>From gcc-bugs-return-494973-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 17 10:24:51 2015
Return-Path: <gcc-bugs-return-494973-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 118508 invoked by alias); 17 Aug 2015 10:24:51 -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 116872 invoked by uid 48); 17 Aug 2015 10:24:46 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67244] [5/6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801
Date: Mon, 17 Aug 2015 10:24: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: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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 cf_reconfirmed_on cf_known_to_work cf_gcchost short_desc everconfirmed cf_known_to_fail bug_severity
Message-ID: <bug-67244-4-u3TeluihVE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67244-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67244-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-08/txt/msg01115.txt.bz2
Content-length: 4278

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-17
      Known to work|                            |4.9.3
               Host|OS X 10.10.2                |
            Summary|internal compiler error: in |[5/6 Regression] internal
                   |gimplify_var_or_parm_decl,  |compiler error: in
                   |at gimplify.c:1801          |gimplify_var_or_parm_decl,
                   |                            |at gimplify.c:1801
     Ever confirmed|0                           |1
      Known to fail|                            |5.1.1, 6.0
           Severity|major                       |normal

--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Creduce came up with:

markus@x4 tmp % cat Uni.ii
class A {
public:
  int operator*();
};
template <typename T, typename Predicate>
void searchGen(int, int, T, Predicate p4) {
  p4(0);
}
template <typename...> struct B;
template <typename MetaFunction, typename Type, typename... Types>
struct B<MetaFunction, Type, Types...> {
  static void exec() { MetaFunction::template exec<Type>; }
};
template <typename MetaFunction, typename... Types> void forEachType() {
  B<MetaFunction, Types...>::exec;
}
namespace {
struct C {
  template <typename T> void exec() {
    A __trans_tmp_1;
    const auto target = *__trans_tmp_1;
    searchGen(0, 0, 0, [=](T) { [=] { target; }; });
  }
};
}
void ____C_A_T_C_H____T_E_S_T____75() { forEachType<C, int>; }

markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -std=c++11 -c Uni.ii
markus@x4 tmp % g++ -c Uni.ii
Uni.ii: In lambda function:
Uni.ii:22:33: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1776
     searchGen(0, 0, 0, [=](T) { [=] { target; }; });
                                 ^
0xa653e1 gimplify_var_or_parm_decl
        ../../gcc/gcc/gimplify.c:1776
0xa6c827 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8500
0xa794f6 gimplify_modify_expr
        ../../gcc/gcc/gimplify.c:4625
0xa6cd94 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8069
0xa70ec6 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../gcc/gcc/gimplify.c:5525
0xa710ac gimplify_and_add(tree_node*, gimple_statement_base**)
        ../../gcc/gcc/gimplify.c:398
0xa710ac gimplify_init_ctor_eval
        ../../gcc/gcc/gimplify.c:3637
0xa78156 gimplify_init_constructor
        ../../gcc/gcc/gimplify.c:3997
0xa78f97 gimplify_modify_expr_rhs
        ../../gcc/gcc/gimplify.c:4254
0xa7936d gimplify_modify_expr
        ../../gcc/gcc/gimplify.c:4584
0xa6cd94 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8069
0xa6cebd gimplify_target_expr
        ../../gcc/gcc/gimplify.c:5456
0xa6cebd gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8436
0xa70ec6 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../gcc/gcc/gimplify.c:5525
0xa6d1b3 gimplify_cleanup_point_expr
        ../../gcc/gcc/gimplify.c:5301
0xa6d1b3 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8432
0xa70ec6 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../gcc/gcc/gimplify.c:5525
0xa727bd gimplify_bind_expr
        ../../gcc/gcc/gimplify.c:1111
0xa6d0ec gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8266
0xa70ec6 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../gcc/gcc/gimplify.c:5525
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[dvyukov at google dot com]

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

Dmitry Vyukov <dvyukov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dvyukov at google dot com

--- Comment #8 from Dmitry Vyukov <dvyukov at google dot com> ---
(In reply to Manuel López-Ibáñez from comment #7)
> I'm not saying that anyone should stop working on what they are doing to
> implement this, but if a volunteer appears (Smagnet?) and wants to work on
> this, why not allow them? Perhaps they can create better documentation than
> the official one.


Hi,

It can make sense to create _some_ sanitizer-related docs in gcc. For example
clang has one:
http://clang.llvm.org/docs/AddressSanitizer.html
Such page can give a "quick start" guide and also thoroughly document
gcc-specifics (e.g. attributes, macros, features, etc). But I don't think it is
a good idea to duplicate everything. Some people will look at the "official"
documentation and be confused, gcc-hosted docs will get outdated in some ways
as well.
And we are interested in improving the "official" docs. Maybe we need to think
about a clear way to document gcc- and clang-specific aspects, and actually do
that throughout the docs.
Sanitizers will move to github soon:
https://github.com/google/sanitizers
Then it will be easier to accept pull requests for docs changes.
>From gcc-bugs-return-494981-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 17 12:43:01 2015
Return-Path: <gcc-bugs-return-494981-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 110773 invoked by alias); 17 Aug 2015 12:43:00 -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 109021 invoked by uid 48); 17 Aug 2015 12:42:55 -0000
From: "y.gribov at samsung dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/67204] documentation for sanitizer missing/incomplete
Date: Mon, 17 Aug 2015 12:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: y.gribov at samsung dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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:
Message-ID: <bug-67204-4-EanCjqIjsr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67204-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67204-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg01123.txt.bz2
Content-length: 1511

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

--- Comment #9 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Dmitry Vyukov from comment #8)
> (In reply to Manuel López-Ibáñez from comment #7)
> > I'm not saying that anyone should stop working on what they are doing to
> > implement this, but if a volunteer appears (Smagnet?) and wants to work on
> > this, why not allow them? Perhaps they can create better documentation than
> > the official one.
> It can make sense to create _some_ sanitizer-related docs in gcc. For
> example clang has one:
> http://clang.llvm.org/docs/AddressSanitizer.html
> Such page can give a "quick start" guide and also thoroughly document
> gcc-specifics (e.g. attributes, macros, features, etc). But I don't think it
> is a good idea to duplicate everything. Some people will look at the
> "official" documentation and be confused, gcc-hosted docs will get outdated
> in some ways as well.

FYI this has already led to mismatches and user confusion several times.

> And we are interested in improving the "official" docs. Maybe we need to
> think about a clear way to document gcc- and clang-specific aspects, and
> actually do that throughout the docs.
> Sanitizers will move to github soon:
> https://github.com/google/sanitizers
> Then it will be easier to accept pull requests for docs changes.

Perhaps GCC docs could be hosted on github as well and then (automatically)
copied to GCC trunk during regular ASan merge process?
>From gcc-bugs-return-494982-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 17 12:44:30 2015
Return-Path: <gcc-bugs-return-494982-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 127212 invoked by alias); 17 Aug 2015 12:44: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 127146 invoked by uid 48); 17 Aug 2015 12:44:27 -0000
From: "y.gribov at samsung dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/67204] documentation for sanitizer missing/incomplete
Date: Mon, 17 Aug 2015 12:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: y.gribov at samsung dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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:
Message-ID: <bug-67204-4-7MDDwUXGAx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67204-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67204-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-08/txt/msg01124.txt.bz2
Content-length: 544

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

--- Comment #10 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Marek Polacek from comment #5)
> (In reply to smagnet from comment #3)
> > Moreover, the undefined behavior sanitizer runtime options (UBSAN_OPTIONS,
> > as described here
> > <https://www.chromium.org/developers/testing/undefinedbehaviorsanitizer>)
> > aren't documented at all in the manual.
>
> UBSAN_OPTIONS isn't currently supported by GCC.

Are you sure? I've been using it with libubsan in GCC trunk...

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Yury Gribov from comment #10)
> Are you sure? I've been using it with libubsan in GCC trunk...

Ah, ok, it seems to work:

$ UBSAN_OPTIONS=print_stacktrace=1 ./a.out 
r.c:6:10: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
    #0 0x400712 in foo (/home/marek/x/trunk/gcc/a.out+0x400712)
    #1 0x400729 in main (/home/marek/x/trunk/gcc/a.out+0x400729)
    #2 0x3a498206ff in __libc_start_main (/lib64/libc.so.6+0x3a498206ff)
    #3 0x400618 in _start (/home/marek/x/trunk/gcc/a.out+0x400618)