On Fri, Aug 30, 2013 at 02:23:44PM +0200, Marek Polacek wrote:
> I see. For the record, here are the new ChangeLog entries I'm going
> to use when doing the merge.
Ok for trunk, thanks.
> config/ChangeLog
> 2013-08-30 Marek Polacek
>
> * bootstrap-ubsan.mk: New.
>
> gcc/c-family/Chang
On Fri, Aug 30, 2013 at 10:42:57AM +0200, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 10:38:51AM +0200, Marek Polacek wrote:
> > On Fri, Aug 30, 2013 at 10:15:44AM +0200, Jakub Jelinek wrote:
> > > So, can you please post a new final patch for the merge (with the new
> > > directories
> > > or
On Fri, Aug 30, 2013 at 10:38:51AM +0200, Marek Polacek wrote:
> On Fri, Aug 30, 2013 at 10:15:44AM +0200, Jakub Jelinek wrote:
> > So, can you please post a new final patch for the merge (with the new
> > directories
> > or files in libsanitizer/ just listed in the ChangeLog entries, but not
> >
On Fri, Aug 30, 2013 at 10:13:06AM +0200, Marek Polacek wrote:
> On Tue, Aug 27, 2013 at 04:30:40PM +0200, Marek Polacek wrote:
> > On Thu, Aug 22, 2013 at 09:01:57PM +0200, Marek Polacek wrote:
> > > On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> > > > Ping.
> > >
> > > I'm with
On Tue, Aug 27, 2013 at 04:30:40PM +0200, Marek Polacek wrote:
> On Thu, Aug 22, 2013 at 09:01:57PM +0200, Marek Polacek wrote:
> > On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> > > Ping.
> >
> > I'm withdrawing the ping for now. I'll have to deal with some bootstrap
> > compar
On Thu, Aug 22, 2013 at 09:01:57PM +0200, Marek Polacek wrote:
> On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> > Ping.
>
> I'm withdrawing the ping for now. I'll have to deal with some bootstrap
> comparison failures first (ugh!).
Fixed with this patch:
http://gcc.gnu.org/ml/g
On Thu, 8 Aug 2013, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Marc Glisse wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
(that is using llvm's sanitizer)
and for a first patch (unreviewed):
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01466.html
(started at http://gcc.gnu.org/ml/
On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> Ping.
I'm withdrawing the ping for now. I'll have to deal with some bootstrap
comparison failures first (ugh!).
Marek
Ping.
On Thu, Aug 15, 2013 at 05:08:48PM +0200, Marek Polacek wrote:
> I've fixed a few unpleasant bugs; mainly the bug that introduced
> various uninitialized variable warnings was bothersome.
> Now it is possible to do bootstrap with -fsanitize=undefined,
> even though there are some comparison
On Thu, Aug 15, 2013 at 05:08:48PM +0200, Marek Polacek wrote:
> One patch is not in yet, but that isn't anything important:
>http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00376.html
I've now commited this patch:
diff --git a/gcc/ChangeLog.ubsan b/gcc/ChangeLog.ubsan
index 9040b68..695522e 100
On 08/15/2013 07:04 AM, Marek Polacek wrote:
if any of the operands is wrapped in SAVE_EXPR, we get an
-Wuninitialized warning. So, what I did is to evaluate
the op0 always in the condition, like "if (op0, )",
which is safe and all the uninitialized warnings are gone,
That sounds fine.
now t
OK.
Jason
On Wed, Aug 07, 2013 at 04:58:03PM +0200, Marek Polacek wrote:
> I actually don't know what I prefer more, but if you like this version
> more, I'll go with it. Maybe this is better because we don't have to
> create SAVE_EXPR and also we avoid one fold_build call. Thanks,
Not creating the SAVE_E
Ping.
On Wed, Aug 07, 2013 at 06:12:58PM +0200, Marek Polacek wrote:
> On Wed, Aug 07, 2013 at 10:24:59AM -0400, Jason Merrill wrote:
> > On 08/07/2013 06:06 AM, Marek Polacek wrote:
> > >I might've misunderstood what you mean. If we drop the hunk above,
> > >then we'll call
> > > error ("%q+
On Fri, 26 Jul 2013, Marc Glisse wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
> (that is using llvm's sanitizer)
>
> and for a first patch (unreviewed):
>
> http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01466.html
> (started at http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01402.html
On Wed, Aug 07, 2013 at 10:24:59AM -0400, Jason Merrill wrote:
> On 08/07/2013 06:06 AM, Marek Polacek wrote:
> >I might've misunderstood what you mean. If we drop the hunk above,
> >then we'll call
> > error ("%q+E is not a constant expression", t);
> >so, we'll print "is not a constant expre
On Tue, Aug 06, 2013 at 05:24:08PM -0400, Jason Merrill wrote:
> On 08/05/2013 07:24 AM, Marek Polacek wrote:
> >On Sat, Aug 03, 2013 at 12:24:32PM -0400, Jason Merrill wrote:
> >>Where are the SAVE_EXPRs coming from? It doesn't seem to me that x
> >>needs to be wrapped in a SAVE_EXPR at all in th
On 08/07/2013 06:06 AM, Marek Polacek wrote:
I might've misunderstood what you mean. If we drop the hunk above,
then we'll call
error ("%q+E is not a constant expression", t);
so, we'll print "is not a constant expression" no matter what
Yes, that's fine; 1/0 is not a constant expression,
On Tue, Aug 06, 2013 at 07:07:27PM -0400, Jason Merrill wrote:
> >I think, what we could do, is to tweak verify_constant like this:
> >
> >+ /* This is to handle e.g. the goofy 'case 0 * (1 / 0)' case. */
> >+ if (flag_sanitize & SANITIZE_UNDEFINED
> >+ && TREE_CODE (t) == CALL_EXPR
> >+
On 08/06/2013 10:42 AM, Marek Polacek wrote:
Hm, actually, we can't easily fold the call to the sanitize function
away, I'm afraid, if we want to do it for the 'case '
case. When we hit the DIV_EXPR in 'case 0 * (1 / 0)',
the ubsan_instrument_division gets 1 as a first argument and 0 as
a second
On 08/05/2013 07:24 AM, Marek Polacek wrote:
On Sat, Aug 03, 2013 at 12:24:32PM -0400, Jason Merrill wrote:
Where are the SAVE_EXPRs coming from? It doesn't seem to me that x
needs to be wrapped in a SAVE_EXPR at all in this case. For cases
where the SAVE_EXPR is needed and not used in the tes
On Wed, Jul 31, 2013 at 02:52:39PM -0400, Jason Merrill wrote:
> >http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01536.html
>
> Here, the C++ compiler is wrong to fold away the division by zero,
> but given that bug the folding ought to also eliminate the call to
> the sanitize function. Seems like
On Sat, Aug 03, 2013 at 12:24:32PM -0400, Jason Merrill wrote:
> Where are the SAVE_EXPRs coming from? It doesn't seem to me that x
> needs to be wrapped in a SAVE_EXPR at all in this case. For cases
> where the SAVE_EXPR is needed and not used in the test, you could
> add the SAVE_EXPR before th
On 08/01/2013 02:06 PM, Marek Polacek wrote:
SAVE_EXPRs are evaluated only once;
in that COMPOUND_EXPR, when we first encounter SAVE_EXPR and
call get_initialized_tmp_var, we get temporary value for it, x.2.
Then, in the second part of the COMPOUND_EXPR, we meet SAVE_EXPR
again, but it already
On Wed, Jul 31, 2013 at 02:52:39PM -0400, Jason Merrill wrote:
> On 07/31/2013 01:33 PM, Marek Polacek wrote:
> >There are still at least two issues though, which is why
> >bootstrap with -fsanitize=undefined fails:
> >
> >http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01480.html
>
> This looks like
On 07/31/2013 01:33 PM, Marek Polacek wrote:
There are still at least two issues though, which is why
bootstrap with -fsanitize=undefined fails:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01480.html
This looks like a serious bug, properly caught by -Wuninitialized.
When sanitizing,
in .uni
On Thu, Jul 25, 2013 at 04:13:29PM -0400, Jason Merrill wrote:
> Otherwise, looks fine. If nobody else has comments, go ahead and
> check it in next week.
I had to make a few changes since, particularly:
- [ubsan] Add -static-libubsan
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01467.html
On Thu, Jul 25, 2013 at 10:43:30PM +, Joseph S. Myers wrote:
> On Thu, 25 Jul 2013, Marek Polacek wrote:
>
> > +@item -fsanitize=undefined
> > +Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector
> > +Various computations will be instrumented to detect
> > +undefined behavior
On Thu, Jul 25, 2013 at 10:40:22PM +, Joseph S. Myers wrote:
> What happens if you bootstrap with this enabled - do whatever failures
> appear look like genuine bugs? Running the testsuite with a compiler
> built with this option? Running the testsuite with this option used when
> compilin
On Thu, Jul 25, 2013 at 10:50:14PM -0600, Jeff Law wrote:
> On 07/25/2013 04:40 PM, Joseph S. Myers wrote:
> >On Thu, 25 Jul 2013, Marek Polacek wrote:
> >
> >>So far it sanitizes division-by-zeros, shifts and
> >>__builtin_unreachable calls. This is of course far from being
> >>complete; I intend
On 07/26/2013 04:00 PM, Marc Glisse wrote:
C11 also says:
"A computation involving unsigned operands can never overflow, because a
result that cannot be represented by the resulting unsigned integer type
is reduced modulo the number that is one greater than the largest value
that can be represen
On Fri, 26 Jul 2013, Jason Merrill wrote:
On 07/26/2013 01:33 AM, Andrew Pinski wrote:
What does it mean by "unsigned-integer-overflow"? Unsigned integers
never overflow.
This is a common misconception. Conversion to an unsigned integer type never
has undefined behavior, but unsigned intege
On 07/26/2013 01:33 AM, Andrew Pinski wrote:
What does it mean by "unsigned-integer-overflow"? Unsigned integers
never overflow.
This is a common misconception. Conversion to an unsigned integer type
never has undefined behavior, but unsigned integer arithmetic does. C11
says,
If an excep
On Thu, Jul 25, 2013 at 10:33:46PM -0700, Andrew Pinski wrote:
> What does it mean by "unsigned-integer-overflow"? Unsigned integers
> never overflow.
> Or maybe I misread the documentation here.
Well, clang can sanitize even when unsigned int wraps. But this
feature seems doubtful, I don't think
On Thu, 25 Jul 2013, Joseph S. Myers wrote:
On Thu, 25 Jul 2013, Marek Polacek wrote:
So far it sanitizes division-by-zeros, shifts and
__builtin_unreachable calls. This is of course far from being
complete; I intend to write more features during this 4.9 stage.
Such as everything needed fo
On Thu, Jul 25, 2013 at 9:50 PM, Jeff Law wrote:
> On 07/25/2013 04:40 PM, Joseph S. Myers wrote:
>>
>> On Thu, 25 Jul 2013, Marek Polacek wrote:
>>
>>> So far it sanitizes division-by-zeros, shifts and
>>> __builtin_unreachable calls. This is of course far from being
>>> complete; I intend to wr
On 07/25/2013 04:40 PM, Joseph S. Myers wrote:
On Thu, 25 Jul 2013, Marek Polacek wrote:
So far it sanitizes division-by-zeros, shifts and
__builtin_unreachable calls. This is of course far from being
complete; I intend to write more features during this 4.9 stage.
Such as everything needed
On Thu, 25 Jul 2013, Marek Polacek wrote:
> +@item -fsanitize=undefined
> +Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector
> +Various computations will be instrumented to detect
> +undefined behavior, e.g.@: division by zero or various overflows.
The same issues applies as f
On Thu, 25 Jul 2013, Marek Polacek wrote:
> So far it sanitizes division-by-zeros, shifts and
> __builtin_unreachable calls. This is of course far from being
> complete; I intend to write more features during this 4.9 stage.
Such as everything needed for it to replace -ftrapv (for -ftrapv to bec
On Thu, Jul 25, 2013 at 04:13:29PM -0400, Jason Merrill wrote:
> On 07/25/2013 11:32 AM, Marek Polacek wrote:
> >+ vec_alloc (v, 3);
> >+ tree ctor = build_constructor (dtype, v);
>
> You might use build_constructor_va instead of managing a vector directly.
Thanks, will give it a try.
> Otherw
On 07/25/2013 11:32 AM, Marek Polacek wrote:
+ vec_alloc (v, 3);
+ tree ctor = build_constructor (dtype, v);
You might use build_constructor_va instead of managing a vector directly.
Otherwise, looks fine. If nobody else has comments, go ahead and check
it in next week.
Jason
41 matches
Mail list logo
