[Bug analyzer/109580] New: #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

[Bug analyzer/109580] New: #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

[eggert at gnu dot org]

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

            Bug ID: 109580
           Summary: #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is
                    ineffective
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: eggert at gnu dot org
  Target Milestone: ---

Created attachment 54896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54896&action=edit
compressed test program illustrating false positive

This is gcc (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0), and I ran into this
problem when compiling Emacs. This is a regression compared to GCC 12.

Compile the attached compressed program with:

gzip -d emacs1.i.gz
gcc -fanalyzer -O2 -S emacs1.i

GCC will generate output starting with:

In function ‘Fdaemon_initialized’:
cc1: warning: leak of file descriptor ‘dup2(nfd, 0)’ [CWE-775]
[-Wanalyzer-fd-leak]

However, the first line of emacs1.i is:

#pragma GCC diagnostic ignored "-Wanalyzer-fd-leak"

so that diagnostic should not be emitted.

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-04-21
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this bug report.

Here's a reduced version of the reproducer (needs -O2 -fanalyzer):

#pragma GCC diagnostic ignored "-Wanalyzer-fd-leak"
int daemon_type;
static int daemon_pipe[2];
void Fdaemon_initialized(void) {
  _Bool err = 0;
  if (daemon_type == 2) {
    int nfd;
    nfd = emacs_open_noquit("/dev/null", 02, 0);
    err |= nfd < 0;
    err |= dup2(nfd, 0) < 0;
    err |= dup2(nfd, 1) < 0;
    err |= dup2(nfd, 2) < 0;
    err |= emacs_close(nfd) != 0;
    err |= write(daemon_pipe[1], "\n", 1) < 0;
    err |= emacs_close(daemon_pipe[1]) != 0;
  }
  daemon_type = -daemon_type;
  if (err)
    error("I/O error during daemon initialization");
}

https://godbolt.org/z/o6PxhjEvq

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The warning is emitted on this statement:

  _23 = _3 | _5;

within this basic block in the optimized code:

  <bb 3> [local count: 217325344]:
  nfd_26 = emacs_open_noquit ("/dev/null", 2, 0);
  _3 = nfd_26 < 0;
  _4 = dup2 (nfd_26, 0);
  _5 = _4 < 0;
  _23 = _3 | _5;
  _6 = dup2 (nfd_26, 1);
  [...snip...]

where the statement has UNKNOWN_LOCATION for its source location.

So there are several things going on here:

(a) the statement has UNKNOWN_LOCATION, rather than a meaningful source
location

(b) pragmas don't affect statements at UNKNOWN_LOCATION; perhaps they should?

(c) the analyzer has some logic to workaround stmt bad locations (stmt_finder);
perhaps it could use it in this case

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The optimized stmt with UNKNOWN_LOCATION is created from:

(gdb) call inform(stmt->location, "stmt in gimple_simplify")
../../src/pr109580.c:10:9: note: stmt in gimple_simplify
   10 |     err |= dup2(nfd, 0) < 0;
      |         ^~

here:

(gdb) bt
#0  gimple_set_code (g=<gimple_assign 0x7fffea81c7e8>, code=GIMPLE_ASSIGN) at
../../src/gcc/gimple.cc:112
#1  0x00000000010b2d0f in gimple_init (g=<gimple_assign 0x7fffea81c7e8>,
code=GIMPLE_ASSIGN, num_ops=3) at ../../src/gcc/gimple.cc:131
#2  0x00000000010b2d82 in gimple_alloc (code=GIMPLE_ASSIGN, num_ops=3) at
../../src/gcc/gimple.cc:158
#3  0x00000000010b2de8 in gimple_build_with_ops_stat (code=GIMPLE_ASSIGN,
subcode=98, num_ops=3) at ../../src/gcc/gimple.cc:186
#4  0x00000000010b3c83 in gimple_build_assign_1 (lhs=<ssa_name 0x7fffea81d9d8
37>, subcode=BIT_IOR_EXPR, op1=<ssa_name 0x7fffea64ff78 3>, 
    op2=<ssa_name 0x7fffea81d0d8 7>, op3=<tree 0x0>) at
../../src/gcc/gimple.cc:469
#5  0x00000000010b3d64 in gimple_build_assign (lhs=<ssa_name 0x7fffea81d9d8
37>, subcode=BIT_IOR_EXPR, op1=<ssa_name 0x7fffea64ff78 3>, 
    op2=<ssa_name 0x7fffea81d0d8 7>, op3=<tree 0x0>) at
../../src/gcc/gimple.cc:496
#6  0x0000000001c63850 in maybe_push_res_to_seq (res_op=0x7fffffff5980,
seq=0x7fffffffd3d8, res=<ssa_name 0x7fffea81d9d8 37>)
    at ../../src/gcc/gimple-match-head.cc:634
#7  0x0000000001d508c9 in gimple_simplify_189 (res_op=0x7fffffffd200,
seq=0x7fffffffd3d8, valueize=0x175579f <fwprop_ssa_val(tree)>, 
    type=<integer_type 0x7fffea6635e8 int>, captures=0x7fffffff5b30,
bitop=BIT_IOR_EXPR) at gimple-match.cc:52798
#8  0x0000000001e587f2 in gimple_simplify_BIT_IOR_EXPR (res_op=0x7fffffffd200,
seq=0x7fffffffd3d8, valueize=0x175579f <fwprop_ssa_val(tree)>, 
    code=..., type=<integer_type 0x7fffea6635e8 int>, _p0=<ssa_name
0x7fffea81d120 8>, _p1=<ssa_name 0x7fffea81db88 43>) at gimple-match.cc:115984
#9  0x0000000001fcfaed in gimple_simplify (res_op=0x7fffffffd200,
seq=0x7fffffffd3d8, valueize=0x175579f <fwprop_ssa_val(tree)>, code=..., 
    type=<integer_type 0x7fffea6635e8 int>, _p0=<ssa_name 0x7fffea81d120 8>,
_p1=<ssa_name 0x7fffea81db88 43>) at gimple-match.cc:211249
#10 0x0000000001c62774 in gimple_resimplify2 (seq=0x7fffffffd3d8,
res_op=0x7fffffffd380, valueize=0x175579f <fwprop_ssa_val(tree)>)
    at ../../src/gcc/gimple-match-head.cc:323
#11 0x0000000001c632a2 in gimple_match_op::resimplify (this=0x7fffffffd380,
seq=0x7fffffffd3d8, valueize=0x175579f <fwprop_ssa_val(tree)>)
    at ../../src/gcc/gimple-match-head.cc:516
#12 0x0000000001c648ec in gimple_simplify (stmt=<gimple_assign 0x7fffea81c160>,
res_op=0x7fffffffd380, seq=0x7fffffffd3d8, 
    valueize=0x175579f <fwprop_ssa_val(tree)>, top_valueize=0x175579f
<fwprop_ssa_val(tree)>) at ../../src/gcc/gimple-match-head.cc:1115
#13 0x00000000010dd6dc in fold_stmt_1 (gsi=0x7fffffffd710, inplace=false,
valueize=0x175579f <fwprop_ssa_val(tree)>)
    at ../../src/gcc/gimple-fold.cc:6251
#14 0x00000000010dde07 in fold_stmt (gsi=0x7fffffffd710, valueize=0x175579f
<fwprop_ssa_val(tree)>) at ../../src/gcc/gimple-fold.cc:6417
#15 0x0000000001757984 in (anonymous namespace)::pass_forwprop::execute
(this=0x3f79bb0, fun=0x7fffea816000)
    at ../../src/gcc/tree-ssa-forwprop.cc:3851
#16 0x0000000001431388 in execute_one_pass (pass=<opt_pass* 0x3f79bb0
"forwprop"(40)>) at ../../src/gcc/passes.cc:2651
#17 0x00000000014317a9 in execute_pass_list_1 (pass=<opt_pass* 0x3f79bb0
"forwprop"(40)>) at ../../src/gcc/passes.cc:2760
#18 0x00000000014317da in execute_pass_list_1 (pass=<opt_pass* 0x3f79a20
"early_optimizations"(37)>) at ../../src/gcc/passes.cc:2761
#19 0x0000000001431839 in execute_pass_list (fn=0x7fffea816000, pass=<opt_pass*
0x3f79820 "fixup_cfg"(34)>) at ../../src/gcc/passes.cc:2771
#20 0x000000000142ef7f in do_per_function_toporder (callback=0x14317f5
<execute_pass_list(function*, opt_pass*)>, data=0x3f79820)
    at ../../src/gcc/passes.cc:1780
#21 0x0000000001432567 in execute_ipa_pass_list (pass=<opt_pass* 0x3f797c0
"opt_local_passes"(33)>) at ../../src/gcc/passes.cc:3105
#22 0x0000000000ea7ede in ipa_passes () at ../../src/gcc/cgraphunit.cc:2202
#23 0x0000000000ea8328 in symbol_table::compile (this=0x7fffea648000) at
../../src/gcc/cgraphunit.cc:2323
#24 0x0000000000ea89bb in symbol_table::finalize_compilation_unit
(this=0x7fffea648000) at ../../src/gcc/cgraphunit.cc:2575
#25 0x000000000159fa0f in compile_file () at ../../src/gcc/toplev.cc:471
#26 0x00000000015a33d1 in do_compile (no_backend=false) at
../../src/gcc/toplev.cc:2125
#27 0x00000000015a389b in toplev::main (this=0x7fffffffdd8a, argc=21,
argv=0x7fffffffde98) at ../../src/gcc/toplev.cc:2283
#28 0x0000000002f77c1a in main (argc=21, argv=0x7fffffffde98) at
../../src/gcc/main.cc:39

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

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

--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Richi: what is the mechanism (if any) for freshly-created gimple stmts to get a
location_t within gimple-match.cc?  It seems to me that the stmts ought to
somehow be assigned the location_t of whatever they are simplified from, or
we'll keep running into stmts with UNKNOWN_LOCATION.  Should we be passing a
location_t around in the generated match code, or have a postprocessing phase
where we copy a location_t to all freshly-created stmts?

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #4)
> Richi: what is the mechanism (if any) for freshly-created gimple stmts to
> get a location_t within gimple-match.cc?  It seems to me that the stmts
> ought to somehow be assigned the location_t of whatever they are simplified
> from, or we'll keep running into stmts with UNKNOWN_LOCATION.  Should we be
> passing a location_t around in the generated match code, or have a
> postprocessing phase where we copy a location_t to all freshly-created stmts?

stmts generated from gimple-match.cc are all put into a sequence, the
appropriate place to assign a location is when they are put into the IL.
One place would be for example replace_stmt_with_simplification.
There is for example annotate_all_with_location that could be used
(but it has some odd behavior wrt GF_PLF_1).

Note that when a match pattern combines stmts from different locations
to a new stmt what the appropriate location is for the result is
questionable.  Though indeed assigning the location of the "root"
of the simplification is reasonable.

Note that otherwise UNKNOWN_LOCATION stmts inherit the location from
the surrounding stmts - they leave the location that's active for
debug info purposes unchanged.