Hi everybody,
I removed the *-Werror* from the default compile flags for GNU APL, so
that more builds
should succeed out of the box. *SVN 1306*. You can still re-enable
*-Werror* via *./configure*
(or by *make develop*).
I would kindly ask users with platforms other than GNU/Linux to
enable*-Werror* from time
to time as to find (and report) warnings (other than the notorious
-Wmaybe-uninitialized,
please) on their platform. In the meantime I will do the same for
GNU/Linux with gcc.
BestRegards,
Jürgen
On 7/8/20 7:21 PM, Blake McBride wrote:
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 <mailto: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
<mailto:rpi....@gnu.org>] on behalf of Louis Chrétien via Bugs and
suggestions for GNU APL [bug-apl@gnu.org <mailto: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 <http://main.cc>' || echo './'`main.cc
<http://main.cc>
In file included from main.cc:34 <http://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
<mailto: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 <mailto:lchret...@mac.com>
