Re: Probably minor bug

[Chris Moller]

    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.
    
    Later,
    --cm

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:

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