[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363

Mathieu Malaterre  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Mathieu Malaterre  ---
This is not a regression, I can reproduce the exact same error using gcc-10:

[...]
libkcapi-1.3.1/apps/kcapi-rng.c:302: undefined reference to
`kcapi_rng_generate'
/usr/lib/gcc-cross/hppa-linux-gnu/10/../../../../hppa-linux-gnu/bin/ld:
libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
[...]


Closing as invalid.

[Bug tree-optimization/102466] -O3 -fsanitize=undefined causes warnings (writing 2 bytes into a region of size 0)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102466

Mathieu Malaterre  changed:

   What|Removed |Added

 CC||mathieu.malaterre at gmail dot 
com

--- Comment #3 from Mathieu Malaterre  ---
This is also triggered in libjxl codebase:

* https://github.com/libjxl/libjxl/blob/main/tools/fuzzer_corpus.cc

/usr/include/c++/11/bits/stl_algobase.h:431:30: warning: 'void*
__builtin_memmove(void*, const void*, long unsigned int)' writing 1 or more
bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
  431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~

[Bug tree-optimization/102466] -O3 -fsanitize=undefined causes warnings (writing 2 bytes into a region of size 0)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102466

--- Comment #4 from Mathieu Malaterre  ---
I can reproduce it using -Wall -fsanitize=undefined  -O2

* https://github.com/malaterre/PublicRep/tree/master/gcc/libjxl

[Bug c/104248] New: armel: C11 atomics requires to be linked with libatomic.a explicitly

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248

Bug ID: 104248
   Summary: armel: C11 atomics requires to be linked with
libatomic.a explicitly
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

Consider the following c11 code (lib + executable):

```
::
foo.c
::
_Atomic(long long) ll;

int foo(void)
{
++ll;
return 42;
}
::
prog.c
::
int foo(void);

int main(int argc, char* argv[])
{
  return foo();
}
```

On Debian armel arch, most built system will fail to compile the above. The
error reported is:

```
/usr/bin/ld: libfoo.a(foo.c.o): in function `foo':
foo.c:(.text+0x40): undefined reference to `__atomic_fetch_add_8'
```

One need to carefully pass `atomic` library on the compilation line. So if you
are lucky this is just:

LDFLAGS=-latomic ...

some other time this more complex as in this above case where a static library
is build, thus one needs to:

```
cc -rdynamic prog.o -o prog libfoo.a -Wl,-Bstatic -latomic -Wl,-Bdynamic
```

---

I see that on some other arch (riscv), the spec file for gcc has been updated
to pass automatically (?) the proper flag: `--as-needed -latomic` [1]

Could someone from gcc/arm team please describe what is the reason for not
doing something equivalent for the spec file in armel case ? Thanks for your
time.

[1] https://github.com/riscv-collab/riscv-gcc/issues/12#issuecomment-276587351

[Bug c/104248] armel: C11 atomics requires to be linked with libatomic.a explicitly

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248

--- Comment #1 from Mathieu Malaterre  ---
In case that help, cmake instructions for the test case is:

```
project(p C)
set(CMAKE_C_STANDARD 11)
add_library(foo STATIC foo.c)
add_executable(prog prog.c)
target_link_libraries(prog foo)
```

[Bug driver/104248] armel: C11 atomics requires to be linked with libatomic.a explicitly

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248

--- Comment #3 from Mathieu Malaterre  ---
@Andreas the specific issue I am raising is the difference between the approach
of riscv vs armel. The riscv team is taking the responsability for putting the
missing `-latomic`, while armel expect the user to understand how c11 atomics
are implemented on a particular architecture and fix the link line at the build
system level (eg. cmake / meson ...).

In summary: what is the risk (if any) to update the gcc spec file on armel ?

[Bug c/104363] New: hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363

Bug ID: 104363
   Summary: hppa: __asm__ directive .global and multiple .symver
not supported
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

It looks like there is a regression on gcc/11 branch on hppa.

Steps using gcc-10 (Debian/buster):

% sudo apt-get install g++-hppa-linux-gnu
% wget http://www.chronox.de/libkcapi/libkcapi-1.3.1.tar.xz
% tar xf libkcapi-1.3.1.tar.xz
% cd libkcapi-1.3.1
% autoreconf -i
% ./configure  --host=hppa-linux-gnu  --build=x86_64-linux-gnu 
--enable-kcapi-rngapp
% make -j8

=> success !

Compare now on Debian/sid:

% sudo apt-get install g++-hppa-linux-gnu
% wget http://www.chronox.de/libkcapi/libkcapi-1.3.1.tar.xz
% tar xf libkcapi-1.3.1.tar.xz
% cd libkcapi-1.3.1
% autoreconf -i
% ./configure  --host=hppa-linux-gnu  --build=x86_64-linux-gnu 
--enable-kcapi-rngapp
% make -j8
/bin/bash ./libtool  --tag=CC   --mode=link hppa-linux-gnu-gcc  -g -O2 -fpie
-fPIE -DPIE -Wl,-z,relro,-z,now -pie -o bin/kcapi-rng
apps/bin_kcapi_rng-kcapi-rng.o apps/bin_kcapi_rng-app-internal.o libkcapi.la
libtool: link: hppa-linux-gnu-gcc -g -O2 -fpie -fPIE -DPIE -Wl,-z -Wl,relro
-Wl,-z -Wl,now -pie -o bin/.libs/kcapi-rng apps/bin_kcapi_rng-kcapi-rng.o
apps/bin_kcapi_rng-app-internal.o  ./.libs/libkcapi.so
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
apps/bin_kcapi_rng-kcapi-rng.o: in function `main':
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:302: undefined reference to
`kcapi_rng_generate'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:332: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_init_enc'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_stream_init_enc'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_stream_init_dec'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_encrypt'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_md_final'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_pbkdf'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_stream_op'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_cipher_decrypt'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_op'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_update_last'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_init_dec'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
./.libs/libkcapi.so: undefined reference to `kcapi_md_digest'
collect2: error: ld returned 1 exit status
make: *** [Makefile:953: bin/kcapi-rng] Error 1
make: *** Waiting for unfinished jobs
rm /tmp/tmp.b3eRUtQTiC

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363

--- Comment #2 from Mathieu Malaterre  ---
I've downgraded binutils to version from bullseye, and I am getting the exact
same symptoms:

```
libtool: link: ( cd ".libs" && rm -f "libkcapi.la" && ln -s "../libkcapi.la"
"libkcapi.la" )
/bin/bash ./libtool  --tag=CC   --mode=link hppa-linux-gnu-gcc  -g -O2 -fpie
-fPIE -DPIE -Wl,-z,relro,-z,now -pie -o bin/kcapi-rng
apps/bin_kcapi_rng-kcapi-rng.o apps/bin_kcapi_rng-app-internal.o libkcapi.la
libtool: link: hppa-linux-gnu-gcc -g -O2 -fpie -fPIE -DPIE -Wl,-z -Wl,relro
-Wl,-z -Wl,now -pie -o bin/.libs/kcapi-rng apps/bin_kcapi_rng-kcapi-rng.o
apps/bin_kcapi_rng-app-internal.o  ./.libs/libkcapi.so
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
apps/bin_kcapi_rng-kcapi-rng.o: in function `main':
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:302: undefined reference to
`kcapi_rng_generate'
/usr/lib/gcc-cross/hppa-linux-gnu/11/../../../../hppa-linux-gnu/bin/ld:
/tmp/libkcapi-1.3.1/apps/kcapi-rng.c:328: undefined reference to
`kcapi_memset_secure'
```

 % apt-cache policy binutils-hppa-linux-gnu
binutils-hppa-linux-gnu:
  Installed: 2.35.2-2
  Candidate: 2.37.90.20220130-2
  Version table:
 2.37.90.20220130-2 500
500 http://deb.debian.org/debian sid/main amd64 Packages
 *** 2.35.2-2 100
100 /var/lib/dpkg/status

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363

--- Comment #3 from Mathieu Malaterre  ---
Original description states:

> Steps using gcc-10 (Debian/buster):

This is a typo, it should states:

> Steps using gcc-10 (Debian/bullseye):

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363

--- Comment #8 from Mathieu Malaterre  ---
Dear John,

(In reply to John David Anglin from comment #6)
> For context, see:
> https://github.com/smuellerDD/libkcapi/issues/133#issuecomment-1024349323
> 
> Note that the following commit fixes the symbol issue on hppa with gcc-11:
> https://github.com/smuellerDD/libkcapi/commit/
> 71d80bcffca26373149121e026d612146b4695d5

As mentionned in the commit message, this is an alternate solution (use of
gcc-10 new attribute for `symver`).

> The patch predates the hppa issue and it doesn't have anything to do
> with hppa.  It does mention -flto but this doesn't seem to apply here.

Use of -flto seems to confict with the use of asm .symver directive, which is
solved by using gcc attribute.

> As far as I remember, support for symbol versioning is done in generic code.
> 
> If I was to guess, I suspect the problem is with asm.  Maybe a '\t'
> is needed before .symver on hppa.  The hppa assembler wants white space
> before directives.

That would not explain the regression gcc-10 -> gcc-11 AFAIK.

[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363

--- Comment #9 from Mathieu Malaterre  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Mathieu Malaterre from comment #2)
> > I've downgraded binutils to version from bullseye, and I am getting the
> > exact same symptoms:
> 
> Did you build from scratch or reuse the object files?

Everything was done using a fresh tarball export.

[Bug target/71617] rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits]

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71617

Mathieu Malaterre  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

gcc-bugs@gcc.gnu.org

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68891

--- Comment #1 from Mathieu Malaterre  ---
Here is the output from clang++:

 error: cannot specify any part of a return type in the declaration of a
conversion function; use a typedef to declare a conversion to 'double (&)[3]'

% clang++ --version
Debian clang version 11.0.1-2

[Bug web/103077] New: This flag is enabled by default at -O3 and by -ftree-vectorize

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103077

Bug ID: 103077
   Summary: This flag is enabled by default at -O3 and by
-ftree-vectorize
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

The online documentation for `-ftree-vectorize` is a bit misleading. Reading it
today:

* https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Gives:

[...]
-O2 turns on all optimization flags specified by -O1. It also turns on the
following optimization flags:
[...]
-ftree-loop-vectorize 
[...]
-ftree-slp-vectorize 
[...]

But later in the page:

[...]
-ftree-loop-vectorize
Perform loop vectorization on trees. This flag is enabled by default at -O3 and
by -ftree-vectorize, -fprofile-use, and -fauto-profile.

-ftree-slp-vectorize
Perform basic block vectorization on trees. This flag is enabled by default at
-O3 and by -ftree-vectorize, -fprofile-use, and -fauto-profile.
[...]

Please clarify documentation for -02 if it does turn on: -ftree-loop-vectorize
& -ftree-slp-vectorize. Thanks

[Bug c++/103159] New: -Wuninitialized should not depend on optimization level

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103159

Bug ID: 103159
   Summary: -Wuninitialized should not depend on optimization
level
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

Consider the following:

```
% cat undef.cxx
#include 

class C
{
int I;
public:
int getI() { return I; }
};

int main()
{
C c;
std::cout << c.getI() << std::endl;

return 0;
}
```

It is counter-intuitive to explicitely use -O2 to have a warning reported.
Compare the output of:

```
% g++ -o undef -Wuninitialized undef.cxx && ./undef
0
```

While:

```
% g++ -O2 -o undef -Wuninitialized undef.cxx && ./undef
undef.cxx: In function ‘int main()’:
undef.cxx:7:25: warning: ‘c.C::I’ is used uninitialized in this function
[-Wuninitialized]
7 | int getI() { return I; }
  | ^
0
```

[Bug c++/103159] -Wuninitialized should not depend on optimization level

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103159

--- Comment #1 from Mathieu Malaterre  ---
Just to be sure, here is the actual command I had been starring at for a while:

```
% g++ -o undef -fsanitize=undefined -Wuninitialized undef.cxx && ./undef
21845
```

Maybe I got confused with `-fsanitize=undefined` and (maybe?) g++ behavior at
default -O0 really does initialize all members in the class...

In any case my usual rule of thumb is to remove optimization flag when doing
debug/high warning level compilation.

[Bug c++/103159] -Wuninitialized should not depend on optimization level

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103159

--- Comment #3 from Mathieu Malaterre  ---
Please note that the documentation currently does not detail the need/impact of
optimization for this flag:

* https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wuninitialized

Maybe just updating the documentation would be enough. Thanks for
consideration.

[Bug c++/103159] Some -Wuninitialized warnings still depend on optimization level -

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103159

Mathieu Malaterre  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Mathieu Malaterre  ---
Nevermind, I managed to mis-read the documentation.

```
Because these warnings depend on optimization, the exact variables or elements
for which there are warnings depend on the precise optimization options and
version of GCC used.
```

Sorry for the noise.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 103159, which changed state.

Bug 103159 Summary: Some -Wuninitialized warnings still depend on optimization 
level -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103159

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug c++/103629] New: Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Bug ID: 103629
   Summary: Possible miscompilation triggered by
-fvisibility=hidden
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

Executive summary:
---

```
% LD_LIBRARY_PATH=./openvdb/openvdb ./openvdb/openvdb/cmd/vdb_view
zsh: segmentation fault  LD_LIBRARY_PATH=./openvdb/openvdb
./openvdb/openvdb/cmd/vdb_view
```

Actual bug description:
---

Upon recompilation of openvdb-8.1.0 within a Debian/sid environment, the
initialization logic starts to fails and eventually lead to a segfault.

Inspection of the gdb backtrace does not pinpoint any obvious mistake:

 % LD_LIBRARY_PATH=./openvdb/openvdb gdb ./openvdb/openvdb/cmd/vdb_view
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./openvdb/openvdb/cmd/vdb_view...
(gdb) r --help
Starting program:
/home/malat/openvdb-8.1.0/obj-x86_64-linux-gnu/openvdb/openvdb/cmd/vdb_view
--help
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x76da0640 (LWP 31308)]
[New Thread 0x7659f640 (LWP 31309)]
[New Thread 0x75d9e640 (LWP 31310)]
[New Thread 0x7559d640 (LWP 31311)]

Thread 1 "vdb_view" received signal SIGSEGV, Segmentation fault.
0x778d3228 in std::__cxx11::basic_string,
std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator > const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0  0x778d3228 in std::__cxx11::basic_string, std::allocator
>::basic_string(std::__cxx11::basic_string,
std::allocator > const&)
() from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1  0x77cac65a in
openvdb::v8_1::Grid, 4u>, 5u> > > >::gridType[abi:cxx11]() () at
/usr/include/c++/11/bits/unique_ptr.h:173
No locals.
#2 
openvdb::v8_1::Grid, 4u>, 5u> > > >::registerGrid () at ./openvdb/openvdb/Grid.h:981
No locals.
#3  openvdb::v8_1::initialize () at ./openvdb/openvdb/openvdb.cc:94
lock = {_M_device = @0x77fca760}
#4  0x55574c40 in main (argc=, argv=0x7fffe4f8) at
./openvdb/openvdb/cmd/openvdb_view.cc:67
printInfo = 
viewer = {}
allGrids = std::vector of length 1, capacity -2932030871777 =
{std::shared_ptr (use count 1027951951, weak
count 1836017710) = {get() = 0x7fffe720},
  std::shared_ptr (use count 1831822701,
weak count 1952541792) = {get() = 0x0},
  std::shared_ptr (use count 1869361010,
weak count 795631970) = {get() = 0x7fffe784},
  std::shared_ptr (use count 1330792515,
weak count 1314870350) = {get() = 0x7fffe7b4},
  std::shared_ptr (use count 1027885383,
weak count 808988978) = {get() = 0x7fffe7f1},
  std::shared_ptr (use count 1397966163,
weak count 1598967624) = {get() = 0x7fffe817},
  std::shared_ptr (use count 1380275029,
weak count 1818324284) = {get() = 0x7fffe875},
  std::shared_ptr (use count 841837938,
weak count 1868772916) = {get() = 0x7fffe899},
  std::shared_ptr (use count 1027888976,
weak count 1836017710) = {get() = 0x7fffe8bc},
  std::shared_ptr (use count 1701670760,
weak count 1818324270) = {get() = 0x7fffe8cf},
  std::shared_ptr (use count 1348426066,
weak count 1028150336) = {get() = 0x7fffe938},
  std::shared_ptr (use count 1280262912,
weak count 1397640532) = {get() = 0x7fffef49}, std::shared_ptr (empty) = {
get() = 0x7fffefa0}, std::shared_ptr (expired, weak count 0) = {get() = 0x21}, ,
  ,
,
  std::shared_ptr (use count 64, weak
count -1) = {get() = 0x3}, ,
  ,
std::shared_ptr (expired, weak count 0) = {get()
= 0x7},
  std::shared_ptr (empty) = {get() =
0x8}, std::shared_ptr (use count -461158174,
weak count 1280594159) = {get() = 0x9},
  ,
, ,
  ,
std::shared_ptr (empty) = {get() = 0x17},
  std::shared_ptr (use count 1418260266,
weak count 1475371345) = {get() = 0x19}, std::shared_ptr (empty)

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #3 from Mathieu Malaterre  ---
Steps to reproduce without a full Debian environement:

```
$ wget
http://deb.debian.org/debian/pool/main/o/openvdb/openvdb_8.1.0.orig.tar.xz
$ tar xf openvdb_8.1.0.orig.tar.xz
$ cd openvdb-8.1.0
$ mkdir build
$ cd build
$ export CXXFLAGS=-fvisibility=hidden
$ cmake .. -DOPENVDB_BUILD_VDB_VIEW:BOOL=ON
$ make -j8 vdb_view
$ LD_LIBRARY_PATH=./openvdb/openvdb ./openvdb/openvdb/cmd/vdb_view
```

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #5 from Mathieu Malaterre  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Mathieu Malaterre from comment #3)
> > $ export CXXFLAGS=-fvisibility=hidden
> 
> Yes you can't just use -fvisibility=hidden without the source being ready
> for it.

Andrew, could you please be a bit more specific. I do not see any changes
related to duplicate `typeinfo` or `visibility=hidden` in the changelog:

* https://gcc.gnu.org/gcc-11/changes.html

`-fvisibility=hidden` was added in 2015 in the Debian/OpenVDB package and has
worked quite well for all users so far. It would be nice if gcc/ld would help
track any `type_info` issue, in large portable c++ codebase.

*
https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/3.0.0-1/debian/rules#L14-15

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #7 from Mathieu Malaterre  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Mathieu Malaterre from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > (In reply to Mathieu Malaterre from comment #3)
> > > > $ export CXXFLAGS=-fvisibility=hidden
> > > 
> > > Yes you can't just use -fvisibility=hidden without the source being ready
> > > for it.
> > 
> > Andrew, could you please be a bit more specific. I do not see any changes
> > related to duplicate `typeinfo` or `visibility=hidden` in the changelog:
> > 
> > * https://gcc.gnu.org/gcc-11/changes.html
> 
> right there has been no major changes in this area as far as I Know. 
> 
> > 
> > `-fvisibility=hidden` was added in 2015 in the Debian/OpenVDB package and
> > has worked quite well for all users so far. It would be nice if gcc/ld would
> > help track any `type_info` issue, in large portable c++ codebase.
> 
> It was working by accident before. Do you know why it was added? Has the
> code upstream in OpenVDB been fixed for adding the visibility attribute
> where needed?

OpenVDB is supposed to be /portable/ c++. The dll export mechanism has been
working on windows arch since basically day-one.

The gcc implementation is at:

*
https://github.com/AcademySoftwareFoundation/openvdb/blob/master/openvdb/openvdb/Platform.h#L218-L219

IMHO this is following the wiki from:

* https://gcc.gnu.org/wiki/Visibility

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #8 from Mathieu Malaterre  ---
 % more CMakeLists.txt main.cc Module.cc openvdb.cc Tree.h
::
CMakeLists.txt
::
cmake_minimum_required(VERSION 3.13)
project(p)

# only export limited set of symbols
set(CMAKE_C_VISIBILITY_PRESET hidden)
set(CMAKE_CXX_VISIBILITY_PRESET hidden)
set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)

# important to have pthread at runtime:
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
find_package(Threads REQUIRED)

# important to use SHARED:
add_library(openvdb SHARED openvdb.cc)
target_include_directories(openvdb PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})

add_executable(vdb_view main.cc Module.cc)
target_link_libraries(vdb_view openvdb Threads::Threads)
target_include_directories(vdb_view PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
::
main.cc
::
void initialize();

int main(int , char *[])
{
initialize();
return 0;
}
::
Module.cc
::
#include "Tree.h"

class Module
{
void init();
};

void Module::init() // no-inline
{
   Tree::treeType();
}
::
openvdb.cc
::
#include "Tree.h"

static std::string do_segfault() { return Tree::treeType(); }

 __attribute__((visibility("default")))
void initialize()
{
  do_segfault();
}
::
Tree.h
::
#pragma once

#include 
#include 

class Tree
{
public:
static const std::string treeType() {
  static std::once_flag once;
  std::call_once(once, []() {
sTreeTypeName.reset(new std::string());
  });
  return *sTreeTypeName;
}
private:
static std::unique_ptr sTreeTypeName;
};

std::unique_ptr Tree::sTreeTypeName;

[Bug c++/103629] Possible miscompilation triggered by pthread + exception

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #9 from Mathieu Malaterre  ---
Compiling the reduce test case without pthread lead to some kind of exception:

```
(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
set = {__val = {0 , 8245935278387129975,
5908832823118463008, 0, 0}}
pid = 
tid = 
ret = 
#1  0x77bf9536 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x77d925e0
<_IO_2_1_stderr_>, sa_sigaction = 0x77d925e0 <_IO_2_1_stderr_>}, sa_mask =
{__val = {140737350282933, 140737351591392, 140737351591392,
  140737351591523, 140737351595200, 3432, 140737350279750, 11, 1,
140737351591392, 93824992325712, 140737352586656, 140737488347968, 0,
140737350287193, 140737351591840}}, sa_flags = -135945484,
  sa_restorer = 0x77d927a0 }
sigs = {__val = {32, 0, 0, 0, 17, 9223372036854775922, 140737352422480,
140737350282933, 0, 140737350282933, 140737353353159, 140737351591392,
93824992325672, 140737351595200, 3432, 140737350279750}}
#2  0x77e4f87a in __gnu_cxx::__verbose_terminate_handler () at
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
terminating = true
t = 
#3  0x77e5b04a in __cxxabiv1::__terminate (handler=) at
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:48
No locals.
#4  0x77e5b0b5 in std::terminate () at
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:58
No locals.
#5  0x77e5b349 in __cxxabiv1::__cxa_throw (obj=,
tinfo=0x77fb1530 , dest=0x77e855a0
)
at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95
globals = 
header = 0x5556aeb0
#6  0x77e525fa in std::__throw_system_error(int) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#7  0x77fc740f in
std::call_once(std::once_flag&,
Tree::treeType()::{lambda()#1}&&) (__once=..., __f=...) at
/usr/include/c++/11/mutex:784
__e = -1
__callable = {f = @0x7fffe3ff}
__exec = {}
```

I am not able to reproduce gcc behavior using clang++ (again Debian sid
version).

[Bug c++/106187] New: armhf: Miscompilation with -O2

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

Bug ID: 106187
   Summary: armhf: Miscompilation with -O2
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

I can trigger an assertion in highway unit test suite on armhf when using -O2
(does not happen at -O0).

Symptoms:

% tests/mul_test
"--gtest_filter=HwyMulTestGroup/HwyMulTest.TestAllMulAdd/Emu128"
"--gtest_also_run_disabled_tests"
Running main() from ./googletest/src/gtest_main.cc
Note: Google Test filter = HwyMulTestGroup/HwyMulTest.TestAllMulAdd/Emu128
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from HwyMulTestGroup/HwyMulTest
[ RUN  ] HwyMulTestGroup/HwyMulTest.TestAllMulAdd/Emu128


f32x4 expect [0+ ->]:
  5,11,19,29,
f32x4 actual [0+ ->]:
  -9,11,19,29,
Abort at /home/malat/highway/hwy/tests/mul_test.cc:308: Emu128, f32x4 lane 0
mismatch: expected '5', got '-9'.

zsh: abort  tests/mul_test  "--gtest_also_run_disabled_tests"

[Bug c++/106187] armhf: Miscompilation with -O2

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #1 from Mathieu Malaterre  ---
Ok it seems to be working ok using:

% g++-12 --version
g++-12 (Debian 12.1.0-5) 12.1.0

[Bug c++/106187] armhf: Miscompilation with -O2

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #2 from Mathieu Malaterre  ---
g++-10 seems affected:

% g++-10 --version
g++-10 (Debian 10.4.0-1) 10.4.0

[Bug c++/106187] armhf: Miscompilation at all optimization levels

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #3 from Mathieu Malaterre  ---
> I can trigger an assertion in highway unit test suite on armhf when using -O2 
> (does not happen at -O0).

The above sentence is wrong, I can make the symptoms go away using:

CXXFLAGS=-fsanitize=undefined

[Bug target/106187] armhf: Miscompilation at all optimization levels

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #6 from Mathieu Malaterre  ---
(In reply to Andrew Pinski from comment #5)
> Does it work with -fstrict-aliasing ?

Yes with and without valgrind I can reproduce the assert.

> Does adding -fsanitize=address report anything?

When I use either `-fsanitize=address` or `-fsanitize=undefined` symptoms goes
away.

> Please reduce it down to which file is being miscompiled at least. You can
> compile the objects with -O2 and do a bysection of the ones needing to be
> compiled with -O0.

@jan could you suggest a way to reduce :

...
ForFloatTypes >
...

in a non-brute force approach ? Thanks *very* much.

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #8 from Mathieu Malaterre  ---
(In reply to Jan Wassenberg from comment #7)
> The easiest way to reduce the amount of code in the binary is to comment out
> from mul_test.cc all the HWY_EXPORT_AND_TEST_P except the one with
> TestAllMulEven.
> 
> The actual miscompilation is probably happening within ops/emu128-inl.h.
> 
> You can further reduce instantiations by replacing
> ForFloatTypes(ForPartialVectors());
> with
> TestMulAdd()(float(), FixedTag());
> 
> That gets us down to a fairly minimal single TU (mul_test.cc).

Bingo !

Program received signal SIGABRT, Aborted.
0xb6cafe86 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0  0xb6cafe86 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0xb6cbf0e4 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0xb6cafa16 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#3  0x00416a2c in hwy::Abort (file=file@entry=0x43acf8
"/home/malat/highway/hwy/tests/mul_test.cc", line=line@entry=308,
format=0x43b6ec "%s, %sx%llu lane %llu mismatch: expected '%s', got '%s'.\n")
at /home/malat/highway/hwy/targets.cc:322
#4  0x00416cbc in hwy::detail::PrintMismatchAndAbort (info=...,
expected_ptr=expected_ptr@entry=0x0, actual_ptr=0x467580,
actual_ptr@entry=0x43acf8, target_name=target_name@entry=0x43ad24 "Emu128",
filename=0x43acf8 "/home/malat/highway/hwy/tests/mul_test.cc",
filename@entry=0xb6ff3010 "", line=line@entry=308, lane=0,
num_lanes=num_lanes@entry=4) at /home/malat/highway/hwy/tests/test_util.cc:90
#5  0x00416d54 in hwy::detail::AssertArrayEqual (info=...,
expected_void=expected_void@entry=0x467500,
actual_void=actual_void@entry=0x467580, N=N@entry=4, target_name=0x43ad24
"Emu128",
filename=0x43acf8 "/home/malat/highway/hwy/tests/mul_test.cc", line=308) at
/home/malat/highway/hwy/tests/test_util.cc:113
#6  0x004108ae in hwy::N_EMU128::AssertVecEqual, float, hwy::N_EMU128::Vec128 > (line=308, filename=0x43acf8
"/home/malat/highway/hwy/tests/mul_test.cc",
actual=..., expected=0x467500, d=...) at
/home/malat/highway/hwy/tests/test_util-inl.h:51
#7  hwy::N_EMU128::TestMulAdd::operator() > (d=..., this=) at
/home/malat/highway/hwy/tests/mul_test.cc:308
#8  0x0043a114 in void
testing::internal::HandleExceptionsInMethodIfSupported(testing::Test*, void (testing::Test::*)(), char const*) ()

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #9 from Mathieu Malaterre  ---
Created attachment 53271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53271&action=edit
object files compiled using gcc or gcc12

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #10 from Mathieu Malaterre  ---
I did upload the bad (gcc-11) and the good (gcc-12) object files. Not sure if
this is what was expected. In any case let me know if you want to provide more
info.


% gdb -batch -ex "disassemble/rs _ZN3hwy8N_EMU12813TestAllMulAddEv"
CMakeFiles/mul_test.dir/hwy/tests/mul_test.cc.o
Dump of assembler code for function _ZN3hwy8N_EMU12813TestAllMulAddEv:
/home/malat/highway/hwy/tests/mul_test.cc:
343 HWY_NOINLINE void TestAllMulAdd() {
344   //ForFloatTypes(ForPartialVectors());
345   TestMulAdd()(float(), FixedTag());
   0xead8 <+0>: fa f7 64 bb b.w 0x91a4
<_ZN3hwy8N_EMU12810TestMulAddclIfNS0_4SimdIfLj4ELi0EvT_T0_>
End of assembler dump.

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

Mathieu Malaterre  changed:

   What|Removed |Added

  Attachment #53271|0   |1
is obsolete||

--- Comment #12 from Mathieu Malaterre  ---
Created attachment 53276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53276&action=edit
gcc11 -save-temps

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #13 from Mathieu Malaterre  ---
Created attachment 53277
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53277&action=edit
gcc-12 -save-temps

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[mathieu.malaterre at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187

--- Comment #14 from Mathieu Malaterre  ---
@Richard

I've uploaded the generated *.ii files (-save-temps), as discussed with
upstream:

* https://github.com/google/highway/issues/776#issuecomment-1177864014

I do not know the codebase very well so I cannot provide much help other than
"it fails the test suite on this single arch/opt flag"...