[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 Thomas Schwinge 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 --- 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.)
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 --- Comment #10 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:6c79057fae6bbb36c4a4fd61c5b7107a16b71b17 commit r12-3498-g6c79057fae6bbb36c4a4fd61c5b7107a16b71b17 Author: Thomas Schwinge 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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
--- Comment #9 from Richard Biener ---
Well.
{
&nowarn_map,
1,
sizeof (nowarn_map),
>_ggc_mx_hash_map_xint_hash_t_nowarn_spec_t_,
>_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 * const x =
(hash_map *)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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
--- Comment #8 from Martin Sebor ---
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 even compile).
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 --- Comment #7 from Andrew Pinski --- (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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
Thomas Schwinge changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
||msebor at gcc dot gnu.org
Keywords||GC
--- Comment #6 from Thomas Schwinge ---
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=0x73f10550) 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=0x73f105f0) 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=0x73f14be0) at [...]/source-gcc/gcc/c-family/c-common.c:3635
3635 if (!warning_suppressed_p (expr, OPT_Wparentheses)
(gdb) s
warning_suppressed_p (expr=0x73f14be0, 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=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:92
92const key_type_t key = convert_to_key (expr);
(gdb) call debug_tree(expr)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x765fc690 precision:32 min max
pointer_to_this reference_to_this
>
side-effects
arg:0
tree_2
arg:0
public arg:0
[...]/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
side-effects nothrow
fn
constant arg:0 >
arg:0
public arg:0
[...]/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
94if (!get_no_warning_bit (expr) || !key)
(gdb) print key
$4 = 2147537909
(gdb) print/x key
$5 = 0x8000d3f5
(gdb) s
get_no_warning_bit (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:40
40return expr->base.nowarning_flag;
(gdb) finish
Run till exit from #0 get_no_warning_bit (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:40
0x01d18699 in get_nowarn_spec (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:94
94if (!get_no_warning_bit (expr) || !key)
Value returned is $6 = true
(gdb) n
97return nowarn_map ? nowarn_map->get (key) : NULL;
(gdb) print nowarn_map
$7 = (xint_hash_map_t *) 0x7675ae10
(gdb) finish
Run till exit from #0 get_nowarn_spec (expr=0x73f14be0) at
[...]/source-gcc/gcc/warning-control.cc:97
0x01d18764 in warning_suppressed_p (expr=0x73f14be0,
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 *) 0x765c66d4
(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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 --- Comment #5 from 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 --- > (In reply to rguent...@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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 --- Comment #4 from Thomas Schwinge --- (In reply to rguent...@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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
--- Comment #3 from 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 ---
> 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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
--- Comment #2 from Thomas Schwinge ---
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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 --- Comment #1 from Richard Biener --- 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?
