bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Probably minor bug


From: Dr . Jürgen Sauermann
Subject: Re: Probably minor bug
Date: Fri, 10 Jul 2020 20:56:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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 <callab5@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.edu@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 <moller@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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]