https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #16 from Marek Polacek ---
Author: mpolacek
Date: Tue Aug 11 15:46:56 2015
New Revision: 226782
URL: https://gcc.gnu.org/viewcvs?rev=226782&root=gcc&view=rev
Log:
PR sanitizer/66908
* c-ubsan.c: Include gimplify.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #15 from Maxim Ostapenko ---
(In reply to Marek Polacek from comment #14)
> This particular issue is fixed for GCC 6.
>
> Maxim, could you please open a separate PR for the ARM issue? I'll try to
> fix that one as a follow-up.
Sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #13 from Marek Polacek ---
Author: mpolacek
Date: Thu Jul 23 13:54:06 2015
New Revision: 226110
URL: https://gcc.gnu.org/viewcvs?rev=226110&root=gcc&view=rev
Log:
PR sanitizer/66908
* c-ubsan.c: Include gimplify.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #12 from Maxim Ostapenko ---
(In reply to Marek Polacek from comment #11)
> Hmm, still can't reproduce even with vanilla trunk:
>
> A = A.0;
> D.2679 = get.__pfn;
> D.2680 = (long int) D.2679;
> D.2681 = D.2680 & 1;
> if (D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #11 from Marek Polacek ---
Hmm, still can't reproduce even with vanilla trunk:
A = A.0;
D.2679 = get.__pfn;
D.2680 = (long int) D.2679;
D.2681 = D.2680 & 1;
if (D.2681 == 0) goto ; else goto ;
:
iftmp.1 = get.__pfn;
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #10 from Maxim Ostapenko ---
(In reply to Marek Polacek from comment #9)
> Oh silly me! This should work; Maxim, could you possibly try this patch?
Sorry, Marek, nothing changed for C++ testcase:
D.6137 = get.__delta;
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #9 from Marek Polacek ---
Oh silly me! This should work; Maxim, could you possibly try this patch?
--- gcc/c-family/c-ubsan.c
+++ gcc/c-family/c-ubsan.c
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3. If not see
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #8 from Marek Polacek ---
Not really. We probably shouldn't instrument arguments of __ubsan_*
builtins...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #7 from Marek Polacek ---
I think I have a fix now. The trick was to use unshare_expr. Testing some
more...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #6 from Marek Polacek ---
(In reply to Maxim Ostapenko from comment #5)
> It looks like that -fsanitize=shift may introduce uninitialized variables
> itself, without other checks.
I don't see this on x86_64. But there certainly is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Maxim Ostapenko changed:
What|Removed |Added
CC||chefmax at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #4 from Marek Polacek ---
This is because of
332 *index = save_expr (*index);
333 /* Create a "(T *) 0" tree node to describe the array type. */
that needs to be evaluated sooner I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #1 from Yury Gribov ---
Looks like -fsanitize=bounds may introduce uninitialized variables when run
after shift.
16 matches
Mail list logo
