https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #16 from Marek Polacek ---
Author: mpolacek
Date: Tue Sep 5 15:55:04 2017
New Revision: 251717
URL: https://gcc.gnu.org/viewcvs?rev=251717&root=gcc&view=rev
Log:
PR sanitizer/82072
* convert.c (convert_to_integer_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #15 from Marek Polacek ---
I'm not sure if it even makes a difference, but I've added the check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #14 from Jakub Jelinek ---
(In reply to Marek Polacek from comment #13)
> So maybe
>
> --- a/gcc/convert.c
> +++ b/gcc/convert.c
> @@ -886,6 +886,10 @@ convert_to_integer_1 (tree type, tree expr, bool dofold)
> break;
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #13 from Marek Polacek ---
So maybe
--- a/gcc/convert.c
+++ b/gcc/convert.c
@@ -886,6 +886,10 @@ convert_to_integer_1 (tree type, tree expr, bool dofold)
break;
case NEGATE_EXPR:
+ /* Using unsigned arithmetic ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #12 from Marek Polacek ---
(In reply to Vittorio Zecca from comment #10)
> A related issue is the following:
>
> /* UB sanitizer should detect undefined negation of LLONG_MIN */
> /* must be compiled with -fsanitize=undefined and run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #11 from Marek Polacek ---
Author: mpolacek
Date: Mon Sep 4 11:30:26 2017
New Revision: 251651
URL: https://gcc.gnu.org/viewcvs?rev=251651&root=gcc&view=rev
Log:
PR sanitizer/82072
* convert.c (do_narrow): When sanit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #10 from Vittorio Zecca ---
A related issue is the following:
/* UB sanitizer should detect undefined negation of LLONG_MIN */
/* must be compiled with -fsanitize=undefined and run */
#include
int main()
{
long long int llnum=LLONG_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #9 from Vittorio Zecca ---
Applying the proposed fix and compiling the test case with
-fsanitize=undefined I get
testcase.c:8:3: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #8 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Marek Polacek from comment #6)
> > This should fix the two issues above:
> >
> > --- a/gcc/convert.c
> > +++ b/gcc/convert.c
> > @@ -434,6 +434,12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #7 from Jakub Jelinek ---
(In reply to Marek Polacek from comment #6)
> This should fix the two issues above:
>
> --- a/gcc/convert.c
> +++ b/gcc/convert.c
> @@ -434,6 +434,12 @@ do_narrow (location_t loc,
> typex = lang_hooks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #6 from Marek Polacek ---
This should fix the two issues above:
--- a/gcc/convert.c
+++ b/gcc/convert.c
@@ -434,6 +434,12 @@ do_narrow (location_t loc,
typex = lang_hooks.types.type_for_size (TYPE_PRECISION (typex),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #5 from Jakub Jelinek ---
Yeah, one thing is the trunc1: case that uses do_narrow (for
MINUS_EXPR/PLUS_EXPR/MULT_EXPR), another thing is that the LSHIFT/RSHIFT_EXPR
narrowing might be problematic for -fsanitize=shift (needs to be veri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #4 from Marek Polacek ---
But that's only a half of the problem here, for
i = -lmin;
we produce
i = (int) -(unsigned int) lmin;
thus again hiding that overflow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #3 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #2)
> This is the effect of premature optimization in convert.c, perhaps for
> -fsanitize=signed-integer-overflow we should punt in do_narrow if the
> argument type is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #2 from Jakub Jelinek ---
Why do you use LLONG_MIN for long variable?
Better testcase:
int
main ()
{
long long l = -__LONG_LONG_MAX__ - 1;
int i = 0;
i -= l;
i = -l;
return 0;
}
This is the effect of premature optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
18 matches
Mail list logo
