public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized
@ 2020-11-15 16:14 schwab@linux-m68k.org
  2020-11-15 17:15 ` [Bug middle-end/97840] " hubicka at gcc dot gnu.org
                   ` (17 more replies)
  0 siblings, 18 replies; 22+ messages in thread
From: schwab@linux-m68k.org @ 2020-11-15 16:14 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 97840
           Summary: [11 regression] Bogus -Wmaybe-uninitialized
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schwab@linux-m68k.org
  Target Milestone: ---

Created attachment 49562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49562&action=edit
fs_dir.ii

After commit 520d5ad337e there are many bogus -Wmaybe-uninitialized warnings in
libstdc++ and in the go frontend, the latter causing bootstrap to fail.

$ /opt/gcc/test/Build/./gcc/xgcc -B/opt/gcc/test/Build/./gcc
-Wmaybe-uninitialized -O -S fs_dir.ii  
../../../../../libstdc++-v3/src/c++17/fs_dir.cc: In member function ‘void
std::filesystem::__cxx11::recursive_directory_iterator::pop()’:
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:341:140: warning: ‘<anonymous>’
may be used uninitialized [-Wmaybe-uninitialized]
  341 |     _GLIBCXX_THROW_OR_ABORT(filesystem_error(_M_dirs
      |                                                                        
                                                                   ^
In file included from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/string:55,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/stdexcept:39,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/system_error:41,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/fs_fwd.h:35,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/filesystem:44,
                 from ../../../../../libstdc++-v3/src/c++17/fs_dir.cc:30:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h:525:7:
note: by argument 3 of type ‘const std::allocator<char>&’ to
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with <template-parameter-2-1> = std::allocator<char>;
_CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]’ declared here
  525 |       basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
      |       ^~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:341:140: note: ‘<anonymous>’
declared here
  341 |     _GLIBCXX_THROW_OR_ABORT(filesystem_error(_M_dirs
      |                                                                        
                                                                   ^
../../../../../libstdc++-v3/src/c++17/fs_dir.cc: In member function
‘std::filesystem::__cxx11::directory_iterator&
std::filesystem::__cxx11::directory_iterator::operator++()’:
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:160:123: warning: ‘<anonymous>’
may be used uninitialized [-Wmaybe-uninitialized]
  160 |     _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                                        
                                                  ^
In file included from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/string:55,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/stdexcept:39,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/system_error:41,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/fs_fwd.h:35,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/filesystem:44,
                 from ../../../../../libstdc++-v3/src/c++17/fs_dir.cc:30:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h:525:7:
note: by argument 3 of type ‘const std::allocator<char>&’ to
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with <template-parameter-2-1> = std::allocator<char>;
_CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]’ declared here
  525 |       basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
      |       ^~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:160:123: note: ‘<anonymous>’
declared here
  160 |     _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                                        
                                                  ^
In member function ‘bool std::filesystem::__cxx11::_Dir::advance(bool)’,
    inlined from ‘std::filesystem::__cxx11::directory_iterator&
std::filesystem::__cxx11::directory_iterator::operator++()’ at
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:163:23:
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:92:63: warning: ‘<anonymous>’
may be used uninitialized [-Wmaybe-uninitialized]
   92 |       _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                               ^
In file included from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/string:55,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/stdexcept:39,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/system_error:41,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/fs_fwd.h:35,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/filesystem:44,
                 from ../../../../../libstdc++-v3/src/c++17/fs_dir.cc:30:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h
 In member function ‘std::filesystem::__cxx11::directory_iterator&
std::filesystem::__cxx11::directory_iterator::operator++()’:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h:525:7:
note: by argument 3 of type ‘const std::allocator<char>&’ to
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with <template-parameter-2-1> = std::allocator<char>;
_CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]’ declared here
  525 |       basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
      |       ^~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:92:63: note: ‘<anonymous>’
declared here
   92 |       _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                               ^
In member function ‘bool std::filesystem::__cxx11::_Dir::advance(bool)’,
    inlined from
‘std::filesystem::__cxx11::recursive_directory_iterator::recursive_directory_iterator(const
std::filesystem::__cxx11::path&, std::filesystem::directory_options,
std::error_code*)’ at ../../../../../libstdc++-v3/src/c++17/fs_dir.cc:204:64:
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:92:63: warning: ‘<anonymous>’
may be used uninitialized [-Wmaybe-uninitialized]
   92 |       _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                               ^
In file included from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/string:55,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/stdexcept:39,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/system_error:41,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/fs_fwd.h:35,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/filesystem:44,
                 from ../../../../../libstdc++-v3/src/c++17/fs_dir.cc:30:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h
 In constructor
‘std::filesystem::__cxx11::recursive_directory_iterator::recursive_directory_iterator(const
std::filesystem::__cxx11::path&, std::filesystem::directory_options,
std::error_code*)’:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h:525:7:
note: by argument 3 of type ‘const std::allocator<char>&’ to
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with <template-parameter-2-1> = std::allocator<char>;
_CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]’ declared here
  525 |       basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
      |       ^~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:92:63: note: ‘<anonymous>’
declared here
   92 |       _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                               ^
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:219:128: warning: ‘<anonymous>’
may be used uninitialized [-Wmaybe-uninitialized]
  219 |         _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                                        
                                                       ^
In file included from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/string:55,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/stdexcept:39,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/system_error:41,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/fs_fwd.h:35,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/filesystem:44,
                 from ../../../../../libstdc++-v3/src/c++17/fs_dir.cc:30:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h:525:7:
note: by argument 3 of type ‘const std::allocator<char>&’ to
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with <template-parameter-2-1> = std::allocator<char>;
_CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]’ declared here
  525 |       basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
      |       ^~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:219:128: note: ‘<anonymous>’
declared here
  219 |         _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                                        
                                                       ^
../../../../../libstdc++-v3/src/c++17/fs_dir.cc: In member function
‘std::filesystem::__cxx11::recursive_directory_iterator&
std::filesystem::__cxx11::recursive_directory_iterator::operator++()’:
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:267:73: warning: ‘<anonymous>’
may be used uninitialized [-Wmaybe-uninitialized]
  267 |     _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                                        
^
In file included from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/string:55,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/stdexcept:39,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/system_error:41,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/fs_fwd.h:35,
                 from
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/filesystem:44,
                 from ../../../../../libstdc++-v3/src/c++17/fs_dir.cc:30:
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/basic_string.h:525:7:
note: by argument 3 of type ‘const std::allocator<char>&’ to
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with <template-parameter-2-1> = std::allocator<char>;
_CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]’ declared here
  525 |       basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
      |       ^~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++17/fs_dir.cc:267:73: note: ‘<anonymous>’
declared here
  267 |     _GLIBCXX_THROW_OR_ABORT(filesystem_error(
      |                                                                        
^

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
@ 2020-11-15 17:15 ` hubicka at gcc dot gnu.org
  2020-11-15 17:31 ` hubicka at gcc dot gnu.org
                   ` (16 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at gcc dot gnu.org @ 2020-11-15 17:15 UTC (permalink / raw)
  To: gcc-bugs

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-11-15
             Status|UNCONFIRMED                 |NEW
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Confirmed. Reproduces on aarch64 cross for me, not on x86-64 native.

Warning is on:
#1  0x0000000001343ad5 in maybe_warn_pass_by_reference (stmt=0x7ffff32ec558,
wlims=...) at ../../gcc/tree-ssa-uninit.c:530
530           tree argbase = maybe_warn_operand (ref, stmt, NULL_TREE, arg,
wlims);
(gdb) down
#0  maybe_warn_operand (ref=..., stmt=0x7ffff32ec558, lhs=0x0,
rhs=0x7ffff55b93f0, wlims=...) at ../../gcc/tree-ssa-uninit.c:434
434         warned = warning_at (location, OPT_Wmaybe_uninitialized,
(gdb) p debug_generic_stmt (rhs)
D.89878

std::filesystem::__cxx11::recursive_directory_iterator::pop (struct
recursive_directory_iterator * const this)
{                                                                               
  struct error_code ec;                                                         
  struct allocator D.89878;                                                     
....
  std::__cxx11::basic_string<char>::basic_string<> (&D.89879, iftmp.99_1,
&D.89878);
....
  D.89878 ={v} {CLOBBER};                                                       
....

and is otherwise unused.

Function looks identical with -fno-ipa-modref.

std::__cxx11::basic_string<char>::basic_string<> is defined locally and the
last parameter (__a) is unused.

modref determines flags 

parm 2 flags: direct noclobber noescape unused

That seems all OK to me, so it seems that somehow uninit pass gets more active
because of different alias info.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
  2020-11-15 17:15 ` [Bug middle-end/97840] " hubicka at gcc dot gnu.org
@ 2020-11-15 17:31 ` hubicka at gcc dot gnu.org
  2020-11-15 17:57 ` hubicka at gcc dot gnu.org
                   ` (15 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at gcc dot gnu.org @ 2020-11-15 17:31 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Ok, so the warning is triggering when uninitialized memory is passed to
function argument declared as const.  This happens here but is false positive
since the parameter is not used at all.  This may have become worse with EAF
analysis since we now optimize the dead code initializing unused parameters in
case kill analysis triggers.

Following patch fixes it but I do not understand why this does not trigger on
x86-64 for me.

diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index f23514395e0..1e074793b02 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -443,7 +443,7 @@ maybe_warn_operand (ao_ref &ref, gimple *stmt, tree lhs,
tree rhs,
    access implying read access to those objects.  */

 static void
-maybe_warn_pass_by_reference (gimple *stmt, wlimits &wlims)
+maybe_warn_pass_by_reference (gcall *stmt, wlimits &wlims)
 {
   if (!wlims.wmaybe_uninit)
     return;
@@ -501,6 +501,10 @@ maybe_warn_pass_by_reference (gimple *stmt, wlimits
&wlims)
              && !TYPE_READONLY (TREE_TYPE (argtype)))
            continue;

+         /* Ignore args we are not going to read from.  */
+         if (gimple_call_arg_flags (stmt, argno - 1) & EAF_UNUSED)
+           continue;
+
          if (save_always_executed && access->mode == access_read_only)
            /* Attribute read_only arguments imply read access.  */
            wlims.always_executed = true;
@@ -639,8 +643,8 @@ warn_uninitialized_vars (bool wmaybe_uninit)
          if (gimple_vdef (stmt))
            wlims.vdef_cnt++;

-         if (is_gimple_call (stmt))
-           maybe_warn_pass_by_reference (stmt, wlims);
+         if (gcall *call = dyn_cast <gcall *> (stmt))
+           maybe_warn_pass_by_reference (call, wlims);
          else if (gimple_assign_load_p (stmt)
                   && gimple_has_location (stmt))
            {

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
  2020-11-15 17:15 ` [Bug middle-end/97840] " hubicka at gcc dot gnu.org
  2020-11-15 17:31 ` hubicka at gcc dot gnu.org
@ 2020-11-15 17:57 ` hubicka at gcc dot gnu.org
  2020-11-15 18:03 ` hubicka at gcc dot gnu.org
                   ` (14 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at gcc dot gnu.org @ 2020-11-15 17:57 UTC (permalink / raw)
  To: gcc-bugs

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, on x86_64 the corresponding warning does not trigger since TYPE_EMPTY_P is
true.

x86_64 compiler I get:
(gdb) p debug_tree (rhstype)
 <record_type 0x7ffff7624498 allocator sizes-gimplified addressable
needs-constructing cxx-odr-p type_1 type_4 type_5 type_6 BLK
    size <integer_cst 0x7ffff744af90 type <integer_type 0x7ffff74690a8
bitsizetype> constant 8>
    unit-size <integer_cst 0x7ffff744afa8 type <integer_type 0x7ffff7469000
sizetype> constant 1>
    align:8 warn_if_not_align:0 symtab:0 alias-set 76 canonical-type
0x7ffff7624498
    fields <field_decl 0x7ffff685a1c8 D.14377
        type <record_type 0x7ffff684a888 new_allocator sizes-gimplified
addressable needs-constructing cxx-odr-p type_1 type_4 type_5 type_6 BLK size
<integer_cst 0x7ffff744af90 8> unit-size <integer_cst 0x7ffff744afa8 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set 77 canonical-type
0x7ffff684a888 fields <function_decl 0x7ffff6858500 operator=> context
<namespace_decl 0x7ffff7478b48 __gnu_cxx>
            full-name "class __gnu_cxx::new_allocator<char>"
            needs-constructor needs-destructor X() X(constX&) this=(X&)
n_parents=0 use_template=1 interface-unknown
            pointer_to_this <pointer_type 0x7ffff684f000> reference_to_this
<reference_type 0x7ffff685b738> chain <type_decl 0x7ffff6845c78 new_allocator>>
        ignored decl_6 BLK
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:116:11
        size <integer_cst 0x7ffff744aed0 constant 0> unit-size <integer_cst
0x7ffff744aed0 0>
        align:8 warn_if_not_align:0 offset_align 8 offset <integer_cst
0x7ffff744aed0 0>
        bit-offset <integer_cst 0x7ffff744af18 constant 0> context <record_type
0x7ffff7624498 allocator>
        chain <template_decl 0x7ffff6855b00 rebind type <record_type
0x7ffff6854a80 rebind>
            ignored decl_1 VOID
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:129:9
            align:1 warn_if_not_align:0 context <record_type 0x7ffff7624498
allocator>
            parms <tree_list 0x7ffff6859208 purpose <integer_cst 0x7ffff744afa8
1>
                value <tree_vec 0x7ffff6856980 type <template_decl
0x7ffff6855b00 rebind>
                    length:1
                    elt:0 <tree_list 0x7ffff68591e0 value <type_decl
0x7ffff684de40 _Tp1>>>>
            full-name "template<class _Tp1> struct
std::allocator<char>::rebind" chain <function_decl 0x7ffff6858200 __ct >>>
context <namespace_decl 0x7ffff7466098 std>
    full-name "class std::allocator<char>"
    needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1
use_template=3 interface-only
    pointer_to_this <pointer_type 0x7ffff685b0a8> reference_to_this
<reference_type 0x7ffff685b5e8> chain <type_decl 0x7ffff76238e8 allocator>>
$50 = void
(gdb) p rhstype->type_common.empty_flag
$51 = 1


while on aarch64 I get:

(gdb) p debug_tree (rhstype)
 <record_type 0x7ffff71ff3f0 allocator sizes-gimplified addressable
needs-constructing cxx-odr-p type_1 type_4 type_5 type_6 BLK
    size <integer_cst 0x7ffff7466030 type <integer_type 0x7ffff74640a8
bitsizetype> constant 8>
    unit-size <integer_cst 0x7ffff7466048 type <integer_type 0x7ffff7464000
sizetype> constant 1>
    align:8 warn_if_not_align:0 symtab:0 alias-set 76 canonical-type
0x7ffff71ff3f0
    fields <field_decl 0x7ffff6636688 D.16017
        type <record_type 0x7ffff66297e0 new_allocator sizes-gimplified
addressable needs-constructing cxx-odr-p type_1 type_4 type_5 type_6 BLK size
<integer_cst 0x7ffff7466030 8> unit-size <integer_cst 0x7ffff7466048 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set 77 canonical-type
0x7ffff66297e0 fields <function_decl 0x7ffff6639300 operator=> context
<namespace_decl 0x7ffff7186428 __gnu_cxx>
            full-name "class __gnu_cxx::new_allocator<char>"
            needs-constructor needs-destructor X() X(constX&) this=(X&)
n_parents=0 use_template=1 interface-unknown
            pointer_to_this <pointer_type 0x7ffff6629690> reference_to_this
<reference_type 0x7ffff6638690> chain <type_decl 0x7ffff662a1c8 new_allocator>>
        ignored decl_6 BLK
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:116:11
        size <integer_cst 0x7ffff744af60 constant 0> unit-size <integer_cst
0x7ffff744af60 0>
        align:8 warn_if_not_align:0 offset_align 8 offset <integer_cst
0x7ffff744af60 0>
        bit-offset <integer_cst 0x7ffff744afa8 constant 0> context <record_type
0x7ffff71ff3f0 allocator>
        chain <template_decl 0x7ffff6635b00 rebind type <record_type
0x7ffff6634930 rebind>
            ignored decl_1 VOID
/opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:129:9
            align:1 warn_if_not_align:0 context <record_type 0x7ffff71ff3f0
allocator>
            parms <tree_list 0x7ffff6633898 purpose <integer_cst 0x7ffff7466048
1>
                value <tree_vec 0x7ffff6637020 type <template_decl
0x7ffff6635b00 rebind>
                    length:1
                    elt:0 <tree_list 0x7ffff6633870 value <type_decl
0x7ffff6636390 _Tp1>>>>
            full-name "template<class _Tp1> struct
std::allocator<char>::rebind" chain <function_decl 0x7ffff6639000 __ct >>>
context <namespace_decl 0x7ffff7460098 std>
    full-name "class std::allocator<char>"
    needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1
use_template=3 interface-only
    pointer_to_this <pointer_type 0x7ffff6638000> reference_to_this
<reference_type 0x7ffff6638540> chain <type_decl 0x7ffff72011c8 allocator>>
$21 = void
(gdb) p rhstype->type_common.empty_flag
$22 = 0

that is set by
1972      /* Handle empty records as per the x86-64 psABI.  */
1973      TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type);

So I suppose relying on TYPE_EMPTY_P to silence false positives on empty
structures is not very portable.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (2 preceding siblings ...)
  2020-11-15 17:57 ` hubicka at gcc dot gnu.org
@ 2020-11-15 18:03 ` hubicka at gcc dot gnu.org
  2020-11-16  1:22 ` msebor at gcc dot gnu.org
                   ` (13 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at gcc dot gnu.org @ 2020-11-15 18:03 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
And to explain why warning does not trigger without modref, it is because we
are not able to disambiguate the variable with another function call (since we
think it escapes)

(gdb) p debug_gimple_stmt (def_stmt)
# .MEM_7 = VDEF <.MEM_5>
_8 = __cxa_allocate_exception (48);

Martin, I think this is much more your area than mine.
I will post the patch on silencing warning on unused args, but I think we
shoulid resovle the empty field issue.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (3 preceding siblings ...)
  2020-11-15 18:03 ` hubicka at gcc dot gnu.org
@ 2020-11-16  1:22 ` msebor at gcc dot gnu.org
  2020-11-16  7:27 ` rguenth at gcc dot gnu.org
                   ` (12 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-11-16  1:22 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning code considers more that just TYPE_EMPTY_P():

  /* Avoid warning about empty types such as structs with no members.
     The first_field() test is important for C++ where the predicate
     alone isn't always sufficient.  */
  tree rhstype = TREE_TYPE (rhs);
  if (POINTER_TYPE_P (rhstype))
    rhstype = TREE_TYPE (rhstype);
  if (TYPE_EMPTY_P (rhstype)
      || (RECORD_OR_UNION_TYPE_P (rhstype)
          && (!first_field (rhstype)
              || default_is_empty_record (rhstype))))
    return NULL_TREE;

If the struct has no data members the warning shouldn't trigger even if
TYPE_EMPTY_P() is false.  I don't think std::allocator has data members so we
need to see why the check isn't good enough.  Ah, it looks like the whole
condition is false because default_is_empty_record (rhstype) is false, which is
because TREE_ADDRESSABLE (rhstype) is true.  Is that what has changed with your
patch?  Either way, I do agree that the warning shouldn't be sensitve to ABI
nuances so perhaps default_is_empty_type() (rhstype) would be a better API to
use here (except it's static).  Let me look into that.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (4 preceding siblings ...)
  2020-11-16  1:22 ` msebor at gcc dot gnu.org
@ 2020-11-16  7:27 ` rguenth at gcc dot gnu.org
  2020-11-16  7:34 ` hubicka at gcc dot gnu.org
                   ` (11 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-16  7:27 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |11.0
           Keywords|                            |diagnostic

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (5 preceding siblings ...)
  2020-11-16  7:27 ` rguenth at gcc dot gnu.org
@ 2020-11-16  7:34 ` hubicka at gcc dot gnu.org
  2020-11-16 15:32 ` cvs-commit at gcc dot gnu.org
                   ` (10 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at gcc dot gnu.org @ 2020-11-16  7:34 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I remember that first_field was returning non-NULL (perhaps it is derived from
empty base)?

My patch touched nothing on the condition: it just improved the alias analysis.
 So while previously we tought that the variable can be intialized by the
function call

_8 = __cxa_allocate_exception (48);

now we are able to track and figure out that it is non-escaping and thus can
not be touched by it.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (6 preceding siblings ...)
  2020-11-16  7:34 ` hubicka at gcc dot gnu.org
@ 2020-11-16 15:32 ` cvs-commit at gcc dot gnu.org
  2020-11-16 16:43 ` schwab@linux-m68k.org
                   ` (9 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-16 15:32 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Hubicka <hubicka@gcc.gnu.org>:

https://gcc.gnu.org/g:0c9687d0daa08c33456210b87e4060d6397ff4d8

commit r11-5060-g0c9687d0daa08c33456210b87e4060d6397ff4d8
Author: Jan Hubicka <jh@suse.cz>
Date:   Mon Nov 16 16:31:30 2020 +0100

    Disable some bogus -Wmaybe-uninitialized warnings

    gcc/ChangeLog:
            PR middle-end/97840
            * ipa-modref.c (analyze_ssa_name_flags): Skip clobbers if inlining
            is done.
            * tree-ssa-uninit.c (maybe_warn_pass_by_reference): Make stmt
gcall;
            skip const calls and unused arguments.
            (warn_uninitialized_vars): Update prototype.

    gcc/testsuite/ChangeLog:
            * g++.dg/warn/uninit-1.C: New test.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (7 preceding siblings ...)
  2020-11-16 15:32 ` cvs-commit at gcc dot gnu.org
@ 2020-11-16 16:43 ` schwab@linux-m68k.org
  2020-11-16 18:18 ` hubicka at gcc dot gnu.org
                   ` (8 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: schwab@linux-m68k.org @ 2020-11-16 16:43 UTC (permalink / raw)
  To: gcc-bugs

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

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at gcc dot gnu.org

--- Comment #8 from Andreas Schwab <schwab@linux-m68k.org> ---
*** Bug 97853 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (8 preceding siblings ...)
  2020-11-16 16:43 ` schwab@linux-m68k.org
@ 2020-11-16 18:18 ` hubicka at gcc dot gnu.org
  2020-11-16 20:11 ` jakub at gcc dot gnu.org
                   ` (7 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at gcc dot gnu.org @ 2020-11-16 18:18 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Created attachment 49571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49571&action=edit
Warnings building cc1plus with LTO

This is current set of wranings building cc1plus with LTO. there are 66
maybe-uninitialized.

I always wondered if we want to print warnings exposing GCC internals like:
../gmp/mpz/../../../gmp/mpz/swap.c:38:3: warning: ‘MEM[(struct __mpz_struct
*)&cst]._mp_size’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
../gmp/mpz/../../../gmp/mpz/swap.c:37:3: warning: ‘MEM[(struct __mpz_struct
*)&cst]._mp_alloc’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
../isl/../../isl/isl_tab.c:2940:29: warning: ‘var’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
../gmp/mpz/../../../gmp/mpz/swap.c:39:3: warning: ‘MEM[(struct __mpz_struct
*)&cst]._mp_d’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
../gmp/mpz/../../../gmp/mpz/swap.c:38:3: warning: ‘MEM[(struct __mpz_struct
*)&cst]._mp_size’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
../gmp/mpz/../../../gmp/mpz/swap.c:37:3: warning: ‘MEM[(struct __mpz_struct
*)&cst]._mp_alloc’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
../../gcc/machmode.h:546:49: warning: ‘MEM[(struct scalar_int_mode
*)&int_mode]’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

A lot of warnings are about remainder_len in wide-int.  Tehere is loop
iniitalizeing it and seems we do not work out it has non-0 number of
iteraitons.
../../gcc/analyzer/store.cc:647:13: warning: ‘MEM[(long int *)&sval_bit_size +
8B]’ may be used uninitialized [-Wmaybe-uninitialized]
../../gcc/analyzer/store.cc:647:13: warning: ‘MEM[(long int *)&sval_bit_size +
16B]’ may be used uninitialized [-Wmaybe-uninitialized]

the MEM_REF syntax is not very pretty.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (9 preceding siblings ...)
  2020-11-16 18:18 ` hubicka at gcc dot gnu.org
@ 2020-11-16 20:11 ` jakub at gcc dot gnu.org
  2020-11-16 20:18   ` Jan Hubicka
  2020-11-16 20:18 ` hubicka at ucw dot cz
                   ` (6 subsequent siblings)
  17 siblings, 1 reply; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-16 20:11 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note i686-linux bootstrap is still broken in r11-5062 - the PR97853 error.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-16 20:11 ` jakub at gcc dot gnu.org
@ 2020-11-16 20:18   ` Jan Hubicka
  0 siblings, 0 replies; 22+ messages in thread
From: Jan Hubicka @ 2020-11-16 20:18 UTC (permalink / raw)
  To: jakub at gcc dot gnu.org; +Cc: gcc-bugs, msebor

> Note i686-linux bootstrap is still broken in r11-5062 - the PR97853 error.
Yes, as discussed earlier (but perhaps lost in other coments) we need
fix for the targetm.calls.empty_record_p (type) divergence. It is not
clear to me if simply calling the default implementation instead of the
rather complicated conditional

  if (TYPE_EMPTY_P (rhstype)
      || (RECORD_OR_UNION_TYPE_P (rhstype)
          && (!first_field (rhstype)
              || default_is_empty_record (rhstype))))
    return NULL_TREE;

is desired here, so hope Martin Sebor will know.  Perhaps simply
exporting default_is_empty_type and doing 

  if (default_is_empty_type (rhstype))
    return NULL_TREE;



^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (10 preceding siblings ...)
  2020-11-16 20:11 ` jakub at gcc dot gnu.org
@ 2020-11-16 20:18 ` hubicka at ucw dot cz
  2020-11-16 20:30 ` jakub at gcc dot gnu.org
                   ` (5 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at ucw dot cz @ 2020-11-16 20:18 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
> Note i686-linux bootstrap is still broken in r11-5062 - the PR97853 error.
Yes, as discussed earlier (but perhaps lost in other coments) we need
fix for the targetm.calls.empty_record_p (type) divergence. It is not
clear to me if simply calling the default implementation instead of the
rather complicated conditional

  if (TYPE_EMPTY_P (rhstype)
      || (RECORD_OR_UNION_TYPE_P (rhstype)
          && (!first_field (rhstype)
              || default_is_empty_record (rhstype))))
    return NULL_TREE;

is desired here, so hope Martin Sebor will know.  Perhaps simply
exporting default_is_empty_type and doing 

  if (default_is_empty_type (rhstype))
    return NULL_TREE;

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (11 preceding siblings ...)
  2020-11-16 20:18 ` hubicka at ucw dot cz
@ 2020-11-16 20:30 ` jakub at gcc dot gnu.org
  2020-11-16 20:37   ` Jan Hubicka
  2020-11-16 20:37 ` hubicka at ucw dot cz
                   ` (4 subsequent siblings)
  17 siblings, 1 reply; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-16 20:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I agree we should just rename default_is_empty_type to is_empty_type, export
it, declare in tree.h and use it instead that complicated test.  TYPE_EMPTY_P
isn't something tree-ssa-uninit.c should care about, that is just whether the
backend decided it will not be passed at all.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-16 20:30 ` jakub at gcc dot gnu.org
@ 2020-11-16 20:37   ` Jan Hubicka
  0 siblings, 0 replies; 22+ messages in thread
From: Jan Hubicka @ 2020-11-16 20:37 UTC (permalink / raw)
  To: jakub at gcc dot gnu.org; +Cc: gcc-bugs

> I agree we should just rename default_is_empty_type to is_empty_type, export
> it, declare in tree.h and use it instead that complicated test.  TYPE_EMPTY_P
> isn't something tree-ssa-uninit.c should care about, that is just whether the
> backend decided it will not be passed at all.
OK, perhaps I can realize this plan and commit tonight so we do not keep
boostrap blocked since it is a free day tomorrow (I will be hacking, but
perhaps Martin is not?).

Honza


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (12 preceding siblings ...)
  2020-11-16 20:30 ` jakub at gcc dot gnu.org
@ 2020-11-16 20:37 ` hubicka at ucw dot cz
  2020-11-16 21:54 ` msebor at gcc dot gnu.org
                   ` (3 subsequent siblings)
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at ucw dot cz @ 2020-11-16 20:37 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> ---
> I agree we should just rename default_is_empty_type to is_empty_type, export
> it, declare in tree.h and use it instead that complicated test.  TYPE_EMPTY_P
> isn't something tree-ssa-uninit.c should care about, that is just whether the
> backend decided it will not be passed at all.
OK, perhaps I can realize this plan and commit tonight so we do not keep
boostrap blocked since it is a free day tomorrow (I will be hacking, but
perhaps Martin is not?).

Honza

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (13 preceding siblings ...)
  2020-11-16 20:37 ` hubicka at ucw dot cz
@ 2020-11-16 21:54 ` msebor at gcc dot gnu.org
  2020-11-16 22:01   ` Jan Hubicka
  2020-11-16 22:01 ` hubicka at ucw dot cz
                   ` (2 subsequent siblings)
  17 siblings, 1 reply; 22+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-11-16 21:54 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #14 from Martin Sebor <msebor at gcc dot gnu.org> ---
Created attachment 49572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49572&action=edit
Patch under test.

The attached patch avoids the warning on aarch64.  Let me finish testing it and
submit it later today.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-16 21:54 ` msebor at gcc dot gnu.org
@ 2020-11-16 22:01   ` Jan Hubicka
  0 siblings, 0 replies; 22+ messages in thread
From: Jan Hubicka @ 2020-11-16 22:01 UTC (permalink / raw)
  To: msebor at gcc dot gnu.org; +Cc: gcc-bugs

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
> 
> --- Comment #14 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Created attachment 49572
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49572&action=edit
> Patch under test.
> 
> The attached patch avoids the warning on aarch64.  Let me finish testing it and
> submit it later today.
Great, I was testing identical patch (and seems to work for me), So I
will leave it up to you. Thanks!



^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (14 preceding siblings ...)
  2020-11-16 21:54 ` msebor at gcc dot gnu.org
@ 2020-11-16 22:01 ` hubicka at ucw dot cz
  2020-11-17  3:02 ` cvs-commit at gcc dot gnu.org
  2020-11-24  0:35 ` msebor at gcc dot gnu.org
  17 siblings, 0 replies; 22+ messages in thread
From: hubicka at ucw dot cz @ 2020-11-16 22:01 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
> 
> --- Comment #14 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Created attachment 49572
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49572&action=edit
> Patch under test.
> 
> The attached patch avoids the warning on aarch64.  Let me finish testing it and
> submit it later today.
Great, I was testing identical patch (and seems to work for me), So I
will leave it up to you. Thanks!

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (15 preceding siblings ...)
  2020-11-16 22:01 ` hubicka at ucw dot cz
@ 2020-11-17  3:02 ` cvs-commit at gcc dot gnu.org
  2020-11-24  0:35 ` msebor at gcc dot gnu.org
  17 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-17  3:02 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:3072125a40ccfc139a92d44fb3911a8a7186b025

commit r11-5073-g3072125a40ccfc139a92d44fb3911a8a7186b025
Author: Martin Sebor <msebor@redhat.com>
Date:   Mon Nov 16 20:01:10 2020 -0700

    PR middle-end/97840 - Bogus -Wmaybe-uninitialized passing an empty object
to a function

    gcc/ChangeLog:
            * tree-ssa-uninit.c (maybe_warn_operand): Call is_empty_type.
            * tree.c (default_is_empty_type): Rename...
            (is_empty_type): ...to this.
            * tree.h (is_empty_type): Declare.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
  2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
                   ` (16 preceding siblings ...)
  2020-11-17  3:02 ` cvs-commit at gcc dot gnu.org
@ 2020-11-24  0:35 ` msebor at gcc dot gnu.org
  17 siblings, 0 replies; 22+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-11-24  0:35 UTC (permalink / raw)
  To: gcc-bugs

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #17 from Martin Sebor <msebor at gcc dot gnu.org> ---
With r11-5073 I think this can now be considered fixed (right?)  Resolving as
such.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2020-11-24  0:35 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-15 16:14 [Bug middle-end/97840] New: [11 regression] Bogus -Wmaybe-uninitialized schwab@linux-m68k.org
2020-11-15 17:15 ` [Bug middle-end/97840] " hubicka at gcc dot gnu.org
2020-11-15 17:31 ` hubicka at gcc dot gnu.org
2020-11-15 17:57 ` hubicka at gcc dot gnu.org
2020-11-15 18:03 ` hubicka at gcc dot gnu.org
2020-11-16  1:22 ` msebor at gcc dot gnu.org
2020-11-16  7:27 ` rguenth at gcc dot gnu.org
2020-11-16  7:34 ` hubicka at gcc dot gnu.org
2020-11-16 15:32 ` cvs-commit at gcc dot gnu.org
2020-11-16 16:43 ` schwab@linux-m68k.org
2020-11-16 18:18 ` hubicka at gcc dot gnu.org
2020-11-16 20:11 ` jakub at gcc dot gnu.org
2020-11-16 20:18   ` Jan Hubicka
2020-11-16 20:18 ` hubicka at ucw dot cz
2020-11-16 20:30 ` jakub at gcc dot gnu.org
2020-11-16 20:37   ` Jan Hubicka
2020-11-16 20:37 ` hubicka at ucw dot cz
2020-11-16 21:54 ` msebor at gcc dot gnu.org
2020-11-16 22:01   ` Jan Hubicka
2020-11-16 22:01 ` hubicka at ucw dot cz
2020-11-17  3:02 ` cvs-commit at gcc dot gnu.org
2020-11-24  0:35 ` msebor at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).