Trying to make GNU APL compile with zero warnings in all conditions is a never-ending task. I recommend making an effort to minimize the number of warnings but don't set it up to not allow any. It's not worth the effort.
Blake On Wed, Jul 8, 2020 at 12:15 PM Callahan, Brian Robert <call...@rpi.edu> wrote: > -Wmaybe-uninitialized came about in gcc-4.7. > > ~Brian > > ------------------------------ > Brian Robert Callahan, Ph.D. > Lecturer, ITWS@RPI > Office: Amos Eaton 132 > ------------------------------ > *From:* Bug-apl [bug-apl-bounces+callab5=rpi....@gnu.org] on behalf of > Louis Chrétien via Bugs and suggestions for GNU APL [bug-apl@gnu.org] > *Sent:* Wednesday, July 08, 2020 1:04 PM > *To:* bug-apl > *Subject:* Re: Probably minor bug > > As well you should… 😉 > > The latest SVN (1304) does not compile anymore on Mac OS 10.4: > > g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I sql -Werror -g -O2 -MT > apl-main.o -MD -MP -MF .deps/apl-main.Tpo -c -o apl-main.o `test -f ' > main.cc' || echo './'`main.cc > In file included from main.cc:34: > In file included from ./Command.hh:28: > In file included from ./Value.hh:24: > In file included from ./CharCell.hh:24: > In file included from ./Cell.hh:30: > In file included from ./PrintBuffer.hh:30: > ./Shape.hh:75:32: error: unknown warning group '-Wmaybe-uninitialized', > ignored [-Werror,-Wunknown-warning-option] > #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" > ^ > 1 error generated. > make[3]: *** [apl-main.o] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > > On Jul 1, 2020, at 22:25, Chris Moller <mol...@mollerware.com> wrote: > > Hi Chris, > > thanks for looking into this. I have added your #pragma in *SVN 1303.* > > I am not particular fond of #pragmas for a number of reasons, but since > other > contributors to GNU APL have used them already earlier I suppose this one > should do no harm. > > Best Regards, > Jürgen > > > On 7/2/20 4:25 AM, Chris Moller wrote: > > 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 > > > > > > > --- > Louis Chrétien > lchret...@mac.com > > > > >
