[Bug sanitizer/66908] New: Uninitialized variable when compiled with UBsan

[Bug sanitizer/66908] New: Uninitialized variable when compiled with UBsan

[m.guseva at samsung dot com]

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

            Bug ID: 66908
           Summary: Uninitialized variable when compiled with UBsan
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: m.guseva at samsung 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: ---

Created attachment 36002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36002&action=edit
Reproducer

When compiled with "-fsanitize=shift,bounds" the gcc reports that "i" variable
maybe uninitialized:
gcc  -O2  -fsanitize=shift,bounds -std=gnu89 -Werror=maybe-uninitialized -c
testcase.c
testcase.c: In function Б─≤fooБ─≥:
testcase.c:21:36: error: Б─≤i.1Б─≥ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
     res[i] = ((data->scale[i] + tab[i]) << mult);

It's not true in original source code however in produced gimple the "i.1" is
initialized in <D.3009> block but may be used in block <D.3010>:
 23   if (mult.0 > 31) goto <D.3009>; else goto <D.3010>;
 24   <D.3009>:
 25   D.3011 = (unsigned long) mult.0;
 26   D.3012 = data->scale[i];
 27   D.3013 = (int) D.3012;
 28   i.1 = i;
 29   UBSAN_BOUNDS (0B, i.1, 21);
 30   D.3015 = tab[i.1];
 31   D.3016 = (int) D.3015;
 32   D.3017 = D.3013 + D.3016;
 33   D.3018 = (unsigned long) D.3017;
 34   __builtin___ubsan_handle_shift_out_of_bounds (&*.Lubsan_data0, D.3018,
D.3011);
 35   goto <D.3019>;
 36   <D.3010>:
 37   <D.3019>:
 38   D.3020 = (long unsigned int) i;
 39   D.3021 = D.3020 * 4;
 40   D.3022 = res + D.3021;
 41   D.3012 = data->scale[i];
 42   D.3013 = (int) D.3012;
 43   UBSAN_BOUNDS (0B, i.1, 21);

Discovered in gcc 4.9.2, reproduced on trunk with "-std=gnu89".
>From gcc-bugs-return-492619-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 17 10:54:57 2015
Return-Path: <gcc-bugs-return-492619-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 79961 invoked by alias); 17 Jul 2015 10:54:56 -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 79905 invoked by uid 48); 17 Jul 2015 10:54:52 -0000
From: "davmac at davmac dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/30527] Use of input/output operands in __asm__ templates not fully documented
Date: Fri, 17 Jul 2015 10:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: inline-asm
X-Bugzilla-Version: 4.1.1
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: normal
X-Bugzilla-Who: davmac at davmac dot org
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-30527-4-dYAffGpE50@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-30527-4@http.gcc.gnu.org/bugzilla/>
References: <bug-30527-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-07/txt/msg01509.txt.bz2
Content-length: 304

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

--- Comment #4 from Davin McCall <davmac at davmac dot org> ---
I recently stumbled across section 6.43.2.7 of the manual, which does in fact
document the operand modifiers for (and only for) x86. Modifiers for other
architectures are not documented.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[y.gribov at samsung dot com]

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.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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 reconfirmed|                            |2015-07-21
     Ever confirmed|0                           |1

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Mine I guess.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[chefmax at gcc dot gnu.org]

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 gcc dot gnu.org

--- Comment #5 from Maxim Ostapenko <chefmax at gcc dot gnu.org> ---
(In reply to Yury Gribov from comment #1)
> Looks like -fsanitize=bounds may introduce uninitialized variables when run
> after shift.

It looks like that -fsanitize=shift may introduce uninitialized variables
itself, without other checks.

For arm-linux-gnueabi target:

$ cat test.cpp

class Foo {

private:

  int a_;

public:

  Foo (int a) : a_(a) {};

  inline int get_a () { return a_; };
};

int bar (int (Foo::*get)()) {
  Foo *A = new Foo(1);
  int result = (A->*get)();
  delete (A);
  return result;
}

int main () {
  return bar (&Foo::get_a);
}

$ armv7l-tizen-linux-gnueabi-g++ -S -fsanitize=shift test.cpp
-fdump-tree-gimple

  <D.6138>
.......................
      D.6137 = get.__delta;
      D.6138 = D.6137 & 1;
      if (D.6138 == 0) goto <D.6139>; else goto <D.6140>;
  <D.6139>:
      iftmp.1 = get.__pfn;
      goto <D.6141>;
  <D.6140>:
      A.2 = A;
==>   D.6143 = get.__delta;
      D.6144 = D.6143 >> 1;
      D.6145 = (sizetype) D.6144;
      D.6146 = A.2 + D.6145;
      D.6147 = MEM[(int (*__vtbl_ptr_type) () * *)D.6146];
      D.6148 = get.__pfn; 
      D.6149 = (sizetype) D.6148;
      D.6150 = D.6147 + D.6149;
      iftmp.1 = *D.6150;
  <D.6141>:
      A.3 = A; 
==>   ????????
      D.6152 = D.6143 >> 1;
      D.6153 = (sizetype) D.6152;
      D.6154 = A.3 + D.6153;
      result = iftmp.1 (D.6154);

Here, <D.6138> => <D.6139> => <D.6141> introduces uninitialized D.6153 value
and broken *this parameter for called method.

$ armv7l-tizen-linux-gnueabi-g++ -v
Using built-in specs.
COLLECT_GCC=armv7l-tizen-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/home/max/install/armv7l-tizen/libexec/gcc/armv7l-tizen-linux-gnueabi/6.0.0/lto-wrapper
Target: armv7l-tizen-linux-gnueabi
Configured with: /home/max/src/v6/gcc/configure
--prefix=/home/max/install/armv7l-tizen --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=armv7l-tizen-linux-gnueabi --disable-nls
--enable-poison-system-directories
--with-pkgversion=Tizen.armv7l.GA2.2015-07-15
--with-sysroot=/home/max/install/armv7l-tizen/armv7l-tizen-linux-gnueabi/sys-root
--with-gmp=/home/max/build/v6/fake-root
--with-libelf=/home/max/build/v6/fake-root
--with-mpc=/home/max/build/v6/fake-root
--with-mpfr=/home/max/build/v6/fake-root --without-cloog --without-ppl
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-languages=c,c++,fortran --disable-libstdcxx-pch --enable-__cxa_atexit
--enable-libssp --enable-lto --enable-checking=release
--with-build-time-tools=/home/max/install/armv7l-tizen/bin --with-gnu-as
--with-gnu-ld
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
%{!Werror=unused-local-typedefs:%{!Wno-error=unused-local-typedefs:-Wno-error=unused-local-typedefs}}
%{fuse-linker-plugin|fno-use-linker-plugin|flto|flto=*:;:-fno-use-linker-plugin}'
--disable-multilib --disable-gnu-unique-object --enable-linker-build-id
--with-mode=arm --with-fpu=neon-vfpv4 --with-cpu=cortex-a15.cortex-a7
--with-float=softfp --enable-libgomp --enable-linux-futex

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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.  But there certainly is a bug, so maybe the fix
will help your testcase on ARM as well.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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...

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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...

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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 COPYING3.  If not see
 #include "internal-fn.h"
 #include "stor-layout.h"
 #include "builtins.h"
+#include "gimplify.h"

 /* Instrument division by zero and INT_MIN / -1.  If not instrumenting,
    return NULL_TREE.  */
@@ -54,6 +55,9 @@ ubsan_instrument_division (location_t loc, tree op0, tree
op1)
   gcc_assert (TYPE_MAIN_VARIANT (TREE_TYPE (op0))
              == TYPE_MAIN_VARIANT (TREE_TYPE (op1)));

+  op0 = unshare_expr (op0);
+  op1 = unshare_expr (op1);
+
   if (TREE_CODE (type) == INTEGER_TYPE
       && (flag_sanitize & SANITIZE_DIVIDE))
     t = fold_build2 (EQ_EXPR, boolean_type_node,
@@ -134,6 +138,9 @@ ubsan_instrument_shift (location_t loc, enum tree_code
code,
   HOST_WIDE_INT op0_prec = TYPE_PRECISION (type0);
   tree uprecm1 = build_int_cst (op1_utype, op0_prec - 1);

+  op0 = unshare_expr (op0);
+  op1 = unshare_expr (op1);
+
   t = fold_convert_loc (loc, op1_utype, op1);
   t = fold_build2 (GT_EXPR, boolean_type_node, t, uprecm1);

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[chefmax at gcc dot gnu.org]

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:

      D.6137 = get.__delta;
      D.6138 = D.6137 & 1;
      if (D.6138 == 0) goto <D.6139>; else goto <D.6140>;
  <D.6139>:
      iftmp.1 = get.__pfn;
      goto <D.6141>;
  <D.6140>:
      A.2 = A;
      D.6143 = get.__delta;
      D.6144 = D.6143 >> 1;
      D.6145 = (sizetype) D.6144;
      D.6146 = A.2 + D.6145;
      D.6147 = MEM[(int (*__vtbl_ptr_type) () * *)D.6146];
      D.6148 = get.__pfn;
      D.6149 = (sizetype) D.6148;
      D.6150 = D.6147 + D.6149;
      iftmp.1 = *D.6150;
  <D.6141>:
      A.3 = A;
      D.6152 = D.6143 >> 1;
      D.6153 = (sizetype) D.6152;
      D.6154 = A.3 + D.6153;
      result = iftmp.1 (D.6154);

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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 <D.2683>;
  <D.2682>:
  iftmp.1 = get.__pfn;
  goto <D.2684>;
  <D.2683>:
  D.2685 = get.__delta;
  D.2686 = (sizetype) D.2685;
  D.2687 = A + D.2686;
  D.2688 = MEM[(int (*__vtbl_ptr_type) () * *)D.2687];
  D.2689 = get.__pfn;
  D.2690 = (long int) D.2689;
  D.2691 = D.2690 + -1; 
  D.2692 = (sizetype) D.2691;
  D.2693 = D.2688 + D.2692;
  iftmp.1 = *D.2693;
  <D.2684>:
  D.2694 = get.__delta;
  D.2695 = (sizetype) D.2694;
  D.2696 = A + D.2695;
  result = iftmp.1 (D.2696);
  operator delete (A);
  D.2697 = result;
  return D.2697;

I don't see the shifts at all.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[chefmax at gcc dot gnu.org]

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 = D.2680 & 1;
>   if (D.2681 == 0) goto <D.2682>; else goto <D.2683>;
>   <D.2682>:
>   iftmp.1 = get.__pfn;
>   goto <D.2684>;
>   <D.2683>:
>   D.2685 = get.__delta;
>   D.2686 = (sizetype) D.2685;
>   D.2687 = A + D.2686;
>   D.2688 = MEM[(int (*__vtbl_ptr_type) () * *)D.2687];
>   D.2689 = get.__pfn;
>   D.2690 = (long int) D.2689;
>   D.2691 = D.2690 + -1; 
>   D.2692 = (sizetype) D.2691;
>   D.2693 = D.2688 + D.2692;
>   iftmp.1 = *D.2693;
>   <D.2684>:
>   D.2694 = get.__delta;
>   D.2695 = (sizetype) D.2694;
>   D.2696 = A + D.2695;
>   result = iftmp.1 (D.2696);
>   operator delete (A);
>   D.2697 = result;
>   return D.2697;
> 
> I don't see the shifts at all.

And you should not, this is ARM - specific. From C++ ABI for the ARM
Architecture:

"3.2.1 Representation of pointer to member function
The generic C++ ABI [GC++ABI] specifies that a pointer to member function is a
pair of words <ptr, adj>. The least significant bit of ptr discriminates
between (0) the address of a non-virtual member function and (1) the offset in
the class’s virtual table of the address of a virtual function.

This encoding cannot work for the ARM-Thumb instruction set where code
addresses use all 32 bits of ptr.

This ABI specifies that adj contains twice the this adjustment, plus 1 if the
member function is virtual. The least significant bit of adj then makes exactly
the same discrimination as the least significant bit of ptr does for Itanium.
A pointer to member function is NULL when ptr = 0 and the least significant bit
of adj is zero."

Perhaps I should cook x86 reproducer.
>From gcc-bugs-return-493044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 22 18:02:10 2015
Return-Path: <gcc-bugs-return-493044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 72956 invoked by alias); 22 Jul 2015 18:02:09 -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 72913 invoked by uid 55); 22 Jul 2015 18:02:05 -0000
From: "uros at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66954] function multiversioning fails for target "aes"
Date: Wed, 22 Jul 2015 18:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: uros 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:
Message-ID: <bug-66954-4-PRkKHd2zVI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66954-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66954-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-07/txt/msg01934.txt.bz2
Content-length: 972

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jul 22 18:01:33 2015
New Revision: 226081

URL: https://gcc.gnu.org/viewcvs?rev"6081&root=gcc&view=rev
Log:
libgcc/ChangeLog:

        PR target/66954
        * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_AES.
        (get_available_features): Handle FEATURE_AES.

gcc/ChangeLog:

        PR target/66954
        * config/i386/i386.c (get_builtin_code_for_version): Add P_AES
        to enum feature_priority and feature_list.
        (fold_builtin_cpu): Add F_AES to enum processor_features
        and isa_names_table.

gcc/testsuite/ChangeLog:

        PR target/66954
        * g++.dg/ext/mv24.C: New test.


Added:
    trunk/gcc/testsuite/g++.dg/ext/mv24.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog
    trunk/libgcc/ChangeLog
    trunk/libgcc/config/i386/cpuinfo.c

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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
         Resolution|---                         |FIXED

--- Comment #14 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
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.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[chefmax at gcc dot gnu.org]

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 one as a follow-up.

Sure, thanks.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[mpolacek at gcc dot gnu.org]

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=226782&root=gcc&view=rev
Log:
        PR sanitizer/66908
        * c-ubsan.c: Include gimplify.h.
        (ubsan_instrument_division): Unshare OP0 and OP1.
        (ubsan_instrument_shift): Likewise.

        * c-c++-common/ubsan/pr66908.c: New test.

Added:
    branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr66908.c
Modified:
    branches/gcc-5-branch/gcc/c-family/ChangeLog
    branches/gcc-5-branch/gcc/c-family/c-ubsan.c
    branches/gcc-5-branch/gcc/testsuite/ChangeLog