Hi, Jürgen,
CXXFLAGS=-Werror=maybe-uninitialized
Way down deep in the gcc code, in tree-ssa-uninit.c, there's a statement:
warn_uninitialized_vars (/*warn_possibly_uninitialized=*/1);
elsewhere in the same file is:
warn_uninitialized_vars (/*warn_possibly_uninitialized=*/!optimize);
The former is what's causing the killer warnings. I don't have any idea
why that one unconditionally looks for uninitialisations while the
latter conditions on the optimisation level, but I expect it would be
pointless trying to get the gcc people to do anything about it.
Fortunately, a more specific version of your
README-11-bogus-compiler-warnings suggestion of
CXXFLAGS=-Werror=maybe-uninitialized
might be what you need: make your Shape.hh pragma
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
instead of
#pragma GCC diagnostic ignored "-Wuninitialized"
Maybe not ideal, but maybe better than nothing.
On 27/06/2020 12:16, Dr. Jürgen Sauermann wrote:
Hi Chris,
this warning is haunting us for quite a while now.
I have written a *README-11-bogus-compiler-warnings* with work-arounds.
Unfortunately the loop below is not entirely bogus (what happens is
that for some r
the uninitialized value *other.rho[r] *is being copied to the
never-used value *rho[r]*).
Unfortunately the obvious fix for the warning has shown to cause
significant perfomance
impacts because it prevents loop unrolling (and there was a separate
trouble report
concerning that performance drop on bug-apl).
At that time I filed a gcc trouble report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
asking to fix this, but I am afraid that this may take some time.
My bug report was merged into a meta-bug which is open since 2005:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Best Regards,
Jürgen
On 6/27/20 5:01 PM, Chris Moller wrote:
Shape.hh: In member function 'Shape Shape::insert_axis(Axis,
ShapeItem) const':
Shape.hh:69:46: error: ''target_mem_ref' not supported by
dump_expr<expression error>' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
69 | loop(r, MAX_RANK) rho[r] = other.rho[r];
| ~~~~~~~~~~~^
Just to finish the build, I patched around the bug by editing out the
Wall and the Werror in the Makefile, so:
[moller@hpbox]~tinkering/gnuapl/trunk% apl -v 10:47:53
BUILDTAG:
---------
Project: GNU APL
Version / SVN: 1.8 / 1210
Build Date: 2019-12-19 17:09:01 UTC
Build OS: Linux 4.19.3-200.fc28.x86_64 x86_64
config.status:
'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/lib/pkgconfig'
Archive SVN: 1161
[moller@hpbox]~tinkering/gnuapl/trunk% gcc --version 10:49:35
gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)
[moller@hpbox]~tinkering/gnuapl/trunk% cat /etc/redhat-release 10:51:45
Fedora release 32 (Thirty Two)
[moller@hpbox]~tinkering/gnuapl/trunk% uname -a 10:52:29
Linux hpbox 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
