diff options
author | David Malcolm <dmalcolm@redhat.com> | 2022-04-25 19:34:33 -0400 |
---|---|---|
committer | David Malcolm <dmalcolm@redhat.com> | 2022-04-25 19:34:33 -0400 |
commit | a5dc2641add6b4f54086d40ae706fda3cdaac7f5 (patch) | |
tree | 36e801da6a4b83821289452f426860c857ef29ac /libphobos/libdruntime/gcc | |
parent | b2202431910e30d8505c94d1cb9341cac7080d10 (diff) | |
download | gcc-a5dc2641add6b4f54086d40ae706fda3cdaac7f5.zip gcc-a5dc2641add6b4f54086d40ae706fda3cdaac7f5.tar.gz gcc-a5dc2641add6b4f54086d40ae706fda3cdaac7f5.tar.bz2 |
gimple-fold: fix further missing stmt locations [PR104308]
PR analyzer/104308 initially reported about a
-Wanalyzer-use-of-uninitialized-value diagnostic using UNKNOWN_LOCATION
when complaining about certain memmove operations where the source
is uninitialized.
In r12-7856-g875342766d4298 I fixed the missing location for
a stmt generated by gimple_fold_builtin_memory_op, but the reporter
then found another way to generate such a stmt with UNKNOWN_LOCATION.
I've now gone through gimple_fold_builtin_memory_op looking at all
statement creation, and found three places in which a new statement
doesn't have a location set on it (either directly via
gimple_set_location, or indirectly via gsi_replace), one of which is
the new reproducer.
This patch adds a gimple_set_location to these three cases, and adds
test coverage for one of them (the third hunk within the patch), fixing
the new reproducer for PR analyzer/104308.
gcc/ChangeLog:
PR analyzer/104308
* gimple-fold.cc (gimple_fold_builtin_memory_op): Explicitly set
the location of new_stmt in all places that don't already set it,
whether explicitly, or via a call to gsi_replace.
gcc/testsuite/ChangeLog:
PR analyzer/104308
* gcc.dg/analyzer/pr104308.c: Add test coverage.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Diffstat (limited to 'libphobos/libdruntime/gcc')
0 files changed, 0 insertions, 0 deletions