[Bug bootstrap/101574] New: gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[Bug bootstrap/101574] New: gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[tschwinge at gcc dot gnu.org]

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

            Bug ID: 101574
           Summary: gcc/sparseset.h:215:20: error: suggest parentheses
                    around assignment used as truth value
                    [-Werror=parentheses]
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

This is strange.  In one build of GCC of native x86_64-pc-linux-gnu (standard
bootstrap, no offloading), I'm suddenly (meaning: "it worked yesterday")
running into a bootstrap failure:

    [...]
    In file included from [...]/source-gcc/gcc/lra-lives.c:43:
    [...]/source-gcc/gcc/lra-lives.c: In function ‘void
make_hard_regno_dead(int)’:
    [...]/source-gcc/gcc/sparseset.h:215:20: error: suggest parentheses around
assignment used as truth value [-Werror=parentheses]
      215 |        && (((ITER) = sparseset_iter_elm (SPARSESET)) || 1);        
    \
          |            ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    [...]/source-gcc/gcc/lra-lives.c:304:3: note: in expansion of macro
‘EXECUTE_IF_SET_IN_SPARSESET’
      304 |   EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, i)
          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    [...]
    cc1plus: all warnings being treated as errors
    make[3]: *** [lra-lives.o] Error 1
    make[3]: *** Waiting for unfinished jobs....
    rm fsf-funding.pod lto-dump.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov.pod
gdc.pod gcov-dump.pod gfortran.pod gcov-tool.pod gccgo.pod
    make[3]: Leaving directory `[...]/build-gcc/gcc'
    make[2]: *** [all-stage2-gcc] Error 2
    make[2]: Leaving directory `[...]/build-gcc'
    make[1]: *** [stage2-bubble] Error 2
    make[1]: Leaving directory `[...]/build-gcc'
    make: *** [all] Error 2

Reproduced twice.

This is using GCC commit a61f6afbee370785cf091fe46e2e022748528307 sources,
clean.  'gcc/lra-lives.c', 'gcc/sparseset.h' have last been modified months
ago.

I'm not seeing this in a corresponding offloading-enabled build.  (That doesn't
make sense -- the GCC bootstrap is the same?)

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It doesn't make sense indeed (FYI I don't see this in a native x86_64
bootstrap).
Just ran one with patches ontop of g:a6291d88d5b6c17d41950e21d7d452f7f0f73020,
I'm using plain ./configure w/o arguments here.

By chance does your build-config differ from the default bootstrap-debug?

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Created attachment 51194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51194&action=edit
Valgrind log

For both the non-working (offloading-disabled) and working (offloading-enabled)
builds I'm using the same flags: '--prefix= --enable-languages=all
--enable-werror --enable-checking=yes,extra,rtl', and 'CC=gcc-4.8 CXX=g++-4.8'
("gcc-4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4"), and some '--with-[...]' for
host libraries.  The offloading-enabled build additionally has
'--enable-offload-targets=[...] --with-cuda-driver[...]' (shouldn't be relevant
here).

The stage 2 command line for 'lra-lives.o' is identical for the working vs.
non-working builds.

I can reliably reproduce the 'lra-lives.o' error by re-running 'make', and also
by manually running the command inside 'build-gcc/gcc/'.

Running the latter with '-wrapper valgrind' ("valgrind-3.10.1", sorry) added, I
see a number of "Conditional jump or move depends on uninitialised value(s)",
"Use of uninitialised value of size [...]"!  First one:

    Conditional jump or move depends on uninitialised value(s)
       at 0x149106D: sparseset_bit_p(sparseset_def*, unsigned int)
(sparseset.h:146)
       by 0x1491B1D: mark_pseudo_regno_live(int) (ira-lives.c:326)
       by 0x1491DD2: mark_pseudo_reg_live(rtx_def*, unsigned int)
(ira-lives.c:410)
       by 0x1491E7F: mark_ref_live(df_ref_d*) (ira-lives.c:424)
       by 0x1495444: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1434)
       by 0x1464EA2: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1801)
       by 0x14962BC: ira_create_allocno_live_ranges() (ira-lives.c:1735)
       by 0x1469B40: ira_build() (ira-build.c:3428)
       by 0x145EEF5: ira(_IO_FILE*) (ira.c:5752)
       by 0x145F984: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:6075)
       by 0x16166AB: execute_one_pass(opt_pass*) (passes.c:2567)
       by 0x16169E1: execute_pass_list_1(opt_pass*) (passes.c:2656)

See log file I'm attaching.

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 22 Jul 2021, tschwinge at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
> 
> --- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> Created attachment 51194
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51194&action=edit
> Valgrind log
> 
> For both the non-working (offloading-disabled) and working (offloading-enabled)
> builds I'm using the same flags: '--prefix= --enable-languages=all
> --enable-werror --enable-checking=yes,extra,rtl', and 'CC=gcc-4.8 CXX=g++-4.8'
> ("gcc-4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4"), and some '--with-[...]' for
> host libraries.  The offloading-enabled build additionally has
> '--enable-offload-targets=[...] --with-cuda-driver[...]' (shouldn't be relevant
> here).
> 
> The stage 2 command line for 'lra-lives.o' is identical for the working vs.
> non-working builds.
> 
> I can reliably reproduce the 'lra-lives.o' error by re-running 'make', and also
> by manually running the command inside 'build-gcc/gcc/'.
> 
> Running the latter with '-wrapper valgrind' ("valgrind-3.10.1", sorry) added, I
> see a number of "Conditional jump or move depends on uninitialised value(s)",
> "Use of uninitialised value of size [...]"!  First one:
> 
>     Conditional jump or move depends on uninitialised value(s)
>        at 0x149106D: sparseset_bit_p(sparseset_def*, unsigned int)
> (sparseset.h:146)
>        by 0x1491B1D: mark_pseudo_regno_live(int) (ira-lives.c:326)
>        by 0x1491DD2: mark_pseudo_reg_live(rtx_def*, unsigned int)
> (ira-lives.c:410)
>        by 0x1491E7F: mark_ref_live(df_ref_d*) (ira-lives.c:424)
>        by 0x1495444: process_bb_node_lives(ira_loop_tree_node*)
> (ira-lives.c:1434)
>        by 0x1464EA2: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
> (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1801)
>        by 0x14962BC: ira_create_allocno_live_ranges() (ira-lives.c:1735)
>        by 0x1469B40: ira_build() (ira-build.c:3428)
>        by 0x145EEF5: ira(_IO_FILE*) (ira.c:5752)
>        by 0x145F984: (anonymous namespace)::pass_ira::execute(function*)
> (ira.c:6075)
>        by 0x16166AB: execute_one_pass(opt_pass*) (passes.c:2567)
>        by 0x16169E1: execute_pass_list_1(opt_pass*) (passes.c:2656)
> 
> See log file I'm attaching.

You want to configure with --enable-valgrind-annotations (the
sparseset one is a false positive)

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #3)
> You want to configure with --enable-valgrind-annotations (the
> sparseset one is a false positive)

Aha, thanks.  Unfortunately: with that added, the problem doesn't reproduce
anymore.  :-| Now, experimenting begins...

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 22 Jul 2021, tschwinge at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
> 
> --- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #3)
> > You want to configure with --enable-valgrind-annotations (the
> > sparseset one is a false positive)
> 
> Aha, thanks.  Unfortunately: with that added, the problem doesn't reproduce
> anymore.  :-| Now, experimenting begins...

I'd say look at where the warning is emitted and how the surrounding
()s should disable it and figure why it doesn't work in this case.

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |msebor at gcc dot gnu.org
           Keywords|                            |GC

--- Comment #6 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Short summary: I ran into an unexpected '0xa5a5a5a5' in
'gcc/warning-control.cc', and a search through email archives pointed me to
PR101292, PR101204, which superficially indeed do look similar.

Anybody got a good suggestion about how to proceed here?

---

    (gdb) break c-common.c:3633
    Breakpoint 3 at 0xea31b5: file [...]/source-gcc/gcc/c-family/c-common.c,
line 3633.
    (gdb) r
    [...]
    Breakpoint 3, c_common_truthvalue_conversion (location=2147537812,
expr=0x7ffff3f10550) at [...]/source-gcc/gcc/c-family/c-common.c:3635
    3635          if (!warning_suppressed_p (expr, OPT_Wparentheses)
    (gdb) c
    Continuing.

    Breakpoint 3, c_common_truthvalue_conversion (location=2147537812,
expr=0x7ffff3f105f0) at [...]/source-gcc/gcc/c-family/c-common.c:3635
    3635          if (!warning_suppressed_p (expr, OPT_Wparentheses)
    (gdb) c
    Continuing.

    Breakpoint 3, c_common_truthvalue_conversion (location=2147537909,
expr=0x7ffff3f14be0) at [...]/source-gcc/gcc/c-family/c-common.c:3635
    3635          if (!warning_suppressed_p (expr, OPT_Wparentheses)
    (gdb) s
    warning_suppressed_p (expr=0x7ffff3f14be0, opt=OPT_Wparentheses) at
[...]/source-gcc/gcc/warning-control.cc:119
    119       const nowarn_spec_t *spec = get_nowarn_spec (expr);
    (gdb) s
    get_nowarn_spec (expr=0x7ffff3f14be0) at
[...]/source-gcc/gcc/warning-control.cc:92
    92        const key_type_t key = convert_to_key (expr);
    (gdb) call debug_tree(expr)
     <modify_expr 0x7ffff3f14be0
        type <integer_type 0x7ffff65fc690 unsigned int public unsigned type_6
SI
            size <integer_cst 0x7ffff65ff120 constant 32>
            unit-size <integer_cst 0x7ffff65ff138 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff65fc690 precision:32 min <integer_cst 0x7ffff65ff150 0> max <integer_cst
0x7ffff65ff108 4294967295>
            pointer_to_this <pointer_type 0x7ffff660c348> reference_to_this
<reference_type 0x7ffff3ce9d20>>
        side-effects
        arg:0 <view_convert_expr 0x7ffff2f46780 type <integer_type
0x7ffff65fc690 unsigned int>
            tree_2
            arg:0 <view_convert_expr 0x7ffff2f467a0 type <integer_type
0x7ffff65fc690 unsigned int>
                public arg:0 <var_decl 0x7ffff608e6c0 i>
                [...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
            [...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
        arg:1 <call_expr 0x7ffff30edd58 type <integer_type 0x7ffff65fc690
unsigned int>
            side-effects nothrow
            fn <addr_expr 0x7ffff2f467c0 type <pointer_type 0x7ffff246bc78>
                constant arg:0 <function_decl 0x7ffff2794c00
sparseset_iter_elm>>
            arg:0 <view_convert_expr 0x7ffff2f467e0 type <pointer_type
0x7ffff278eb28 sparseset>
                public arg:0 <var_decl 0x7ffff60426c0 pseudos_live>
                [...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
            [...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
        [...]/source-gcc/gcc/lra-lives.c:304:3 start:
[...]/source-gcc/gcc/lra-lives.c:304:3 finish:
[...]/source-gcc/gcc/lra-lives.c:304:3>
    (gdb) n
    94        if (!get_no_warning_bit (expr) || !key)
    (gdb) print key
    $4 = 2147537909
    (gdb) print/x key
    $5 = 0x8000d3f5
    (gdb) s
    get_no_warning_bit (expr=0x7ffff3f14be0) at
[...]/source-gcc/gcc/warning-control.cc:40
    40        return expr->base.nowarning_flag;
    (gdb) finish
    Run till exit from #0  get_no_warning_bit (expr=0x7ffff3f14be0) at
[...]/source-gcc/gcc/warning-control.cc:40
    0x0000000001d18699 in get_nowarn_spec (expr=0x7ffff3f14be0) at
[...]/source-gcc/gcc/warning-control.cc:94
    94        if (!get_no_warning_bit (expr) || !key)
    Value returned is $6 = true
    (gdb) n
    97        return nowarn_map ? nowarn_map->get (key) : NULL;
    (gdb) print nowarn_map
    $7 = (xint_hash_map_t *) 0x7ffff675ae10
    (gdb) finish
    Run till exit from #0  get_nowarn_spec (expr=0x7ffff3f14be0) at
[...]/source-gcc/gcc/warning-control.cc:97
    0x0000000001d18764 in warning_suppressed_p (expr=0x7ffff3f14be0,
opt=OPT_Wparentheses) at [...]/source-gcc/gcc/warning-control.cc:119
    119       const nowarn_spec_t *spec = get_nowarn_spec (expr);
    Value returned is $8 = (nowarn_spec_t *) 0x7ffff65c66d4
    (gdb) print/x *$8
    $9 = {m_bits = 0xa5a5a5a5}

(This is what then causes the spurious diagnostic; in a "non-faulting" build,
this is 'm_bits = 2'.)

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thomas Schwinge from comment #6)
> Short summary: I ran into an unexpected '0xa5a5a5a5' in
> 'gcc/warning-control.cc', and a search through email archives pointed me to
> PR101292, PR101204, which superficially indeed do look similar.
> 
> Anybody got a good suggestion about how to proceed here?


0xa5a5a5a5 is written when the GC has reclaimed the memory. So the best way is
to a reduced testcase using --param ggc-min-expand=0 --param ggc-min-heapsize=0
(note start with --param ggc-min-expand=1 --param ggc-min-heapsize=1 otherwise
the compiler will be supper slow).

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
The symptom in comment #6 does look similar to the problem discussed in
pr101292.  I haven't debugged it yet but when developing the warning control
patch I struggled with keeping the garbage collector from collecting the global
hash map between location_t and the nowarn_spec_t struct.  My suspicion is that
either the annotation on the hash_map isn't correct (it's a simple GTY("") so
it's hard to imagine what might be wrong with it), or the integration with the
garbage collector is incomplete (I had to change the hash_map definition itself
to let hash_map<location_t, nowarn_spec_t> even compile).

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well.

  {
    &nowarn_map,
    1,
    sizeof (nowarn_map),
    &gt_ggc_mx_hash_map_xint_hash_t_nowarn_spec_t_,
    &gt_pch_nx_hash_map_xint_hash_t_nowarn_spec_t_
  },

void
gt_ggc_mx_hash_map_xint_hash_t_nowarn_spec_t_ (void *x_p)
{
  hash_map<xint_hash_t,nowarn_spec_t> * const x =
(hash_map<xint_hash_t,nowarn_spec_t> *)x_p;
  if (ggc_test_and_set_mark (x))
    {
      gt_ggc_mx (x);
    }
}

So that's supposed to pick up the hash_map and hash_table overloads of
gt_ggc_mx.  In particular int_hash lacks ggc_* method overloads I think,
see how the various ggc_* hash traits work.

given the layout of the nowarn_spec hash-map I think all data should be
in-line, and thus only the hashtable memory itself needs to be marked
and thus you should see all of the table poisoned?  Breaking at
the above toplevel marker and following what it does might reveal
the error.

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:6c79057fae6bbb36c4a4fd61c5b7107a16b71b17

commit r12-3498-g6c79057fae6bbb36c4a4fd61c5b7107a16b71b17
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Mon Aug 30 22:36:47 2021 +0200

    Don't maintain a warning spec for 'UNKNOWN_LOCATION'/'BUILTINS_LOCATION'
[PR101574]

    This resolves PR101574 "gcc/sparseset.h:215:20: error: suggest parentheses
    around assignment used as truth value [-Werror=parentheses]", as (bogusly)
    reported at commit a61f6afbee370785cf091fe46e2e022748528307:

        In file included from [...]/source-gcc/gcc/lra-lives.c:43:
        [...]/source-gcc/gcc/lra-lives.c: In function âvoid
make_hard_regno_dead(int)â:
        [...]/source-gcc/gcc/sparseset.h:215:20: error: suggest parentheses
around assignment used as truth value [-Werror=parentheses]
          215 |        && (((ITER) = sparseset_iter_elm (SPARSESET)) || 1);    
        \
              |            ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        [...]/source-gcc/gcc/lra-lives.c:304:3: note: in expansion of macro
âEXECUTE_IF_SET_IN_SPARSESETâ
          304 |   EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, i)
              |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~

            gcc/
            PR bootstrap/101574
            * diagnostic-spec.c (warning_suppressed_at, copy_warning): Handle
            'RESERVED_LOCATION_P' locations.
            * warning-control.cc (get_nowarn_spec, suppress_warning)
            (copy_warning): Likewise.

[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |tschwinge at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
This specific issue here has now been fixed -- and in fact was not (or, at
least not directly) related to GCC's garbage collector.  (Regarding that,
PR101292 remains open, however.)