https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Tue Aug 11 15:46:56 2015
New Revision: 226782
URL: https://gcc.gnu.org/viewcvs?rev=226782root=gccview=rev
Log:
PR sanitizer/66908
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #15 from Maxim Ostapenko chefmax at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #13 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Thu Jul 23 13:54:06 2015
New Revision: 226110
URL: https://gcc.gnu.org/viewcvs?rev=226110root=gccview=rev
Log:
PR sanitizer/66908
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #10 from Maxim Ostapenko chefmax at gcc dot gnu.org ---
(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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org ---
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 D.2682; else goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #12 from Maxim Ostapenko chefmax at gcc dot gnu.org ---
(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 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Maxim Ostapenko chefmax at gcc dot gnu.org changed:
What|Removed |Added
CC||chefmax at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org ---
Not really. We probably shouldn't instrument arguments of __ubsan_*
builtins...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org ---
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
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
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
--- Comment #1 from Yury Gribov y.gribov at samsung dot com ---
Looks like -fsanitize=bounds may introduce uninitialized variables when run
after shift.
16 matches
Mail list logo
