[Top][All Lists]

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

Re: Probably minor bug

From: Chris Moller
Subject: Re: Probably minor bug
Date: Tue, 30 Jun 2020 15:30:39 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

Hi, Jürgen,

I pulled down your apl-Bif_F12_FORMAT.cc.preprocessed--and with the usual perversity of software, couldn't get a compile of apl-Bif_F12_FORMAT.cc to fail.  But commenting out your "#pragma GCC diagnostic ignored "-Wuninitialized"" makes the build fail (fairly) reliably, so maybe I  can work with that.  (That the failure seems to be intermittent suggests that the uninitialised whatever might be in gcc, not in your code.)

As an experiment, I tried

CC=clang CXX=clang++ ./autogen.s

and rebuilding.  Worked fine, and I got a "!  SUCCESS  !" out of the testcases, but the result refused to load my own libedif2.so, even when I rebuilt it with clang.  A puzzle for another time.

More experimenting, building everything except Shape.cc with c++ and building that with clang++ also works fine, and even loaded edif2.

For the moment, using clang might be a work-around, though I'd have to figure out why edif2 is being uncooperative.


On 2020-06-27 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:


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:


Best Regards,

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
    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

reply via email to

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