[Bug c++/56497] New: comparison is always true due to limited range of data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56497 Bug #: 56497 Summary: comparison is always true due to limited range of data type Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mathieu.malate...@gmail.com Created attachment 29563 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29563 g++ -Wtype-limits test.cxx It would be really nice if -Wtype-limits would catch all occurences in the following test case. Steps: $ g++ -Wtype-limits test.cxx test.cxx: In function 'int main()': test.cxx:25:33: warning: comparison is always true due to limited range of data type [-Wtype-limits]
[Bug c++/56497] comparison is always true due to limited range of data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56497 Mathieu Malaterre changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Mathieu Malaterre 2013-03-01 17:40:15 UTC --- ok. closing then.
[Bug c++/50990] New: vector.tcc:373:5: internal compiler error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50990 Bug #: 50990 Summary: vector.tcc:373:5: internal compiler error: Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mathieu.malate...@gmail.com I am getting an ICE with gcc 4.6.1 on sparc64 architecture: In file included from /usr/include/c++/4.6/vector:70:0, from /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl/iso/vcl_vector.h:6, from /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl/vcl_vector.h:16, from /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vsl/vsl_basic_xml_element.h:10, from /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vsl/vsl_basic_xml_element.cxx:2: /usr/include/c++/4.6/bits/vector.tcc: In member function 'void std::vector<_Tp, _Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, const _Tp&) [with _Tp = std::pair, std::basic_string >, _Alloc = std::allocator, std::basic_string > >, std::vector<_Tp, _Alloc>::iterator = __gnu_cxx::__normal_iterator, std::basic_string >*, std::vector, std::basic_string > > >, typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer = std::pair, std::basic_string >*]': /usr/include/c++/4.6/bits/vector.tcc:373:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. See full log at: http://buildd.debian-ports.org/status/fetch.php?pkg=vxl&arch=sparc64&ver=1.14.0-11&stamp=1320254572
[Bug c++/50990] vector.tcc:373:5: internal compiler error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50990 --- Comment #2 from Mathieu Malaterre 2011-11-04 10:50:30 UTC --- Once I get the -save-temps output, I'll post them ASAP here: http://lists.debian.org/debian-sparc/2011/11/msg8.html I do not have direct access to this box. Thanks.
[Bug c++/50990] vector.tcc:373:5: internal compiler error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50990 Mathieu Malaterre changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Mathieu Malaterre 2011-11-05 13:41:05 UTC --- Quoting one of the sparc64 admin: ... The problem is not GCC, but rather the machine currently used for the sparc64 build daemon, which is slowly dying (likely a memory issue). Most of the ICE appearing when build packages are due to the build daemon. Concerning vxl, I have built it without any problem in another machine and uploaded it to the archive. ... Changing status to resolved/invalid. Sorry for the noise.
[Bug c/52617] New: -Wconversion does not work for strlen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52617
Bug #: 52617
Summary: -Wconversion does not work for strlen
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mathieu.malate...@gmail.com
Hi,
gcc -Wconversion does not work for strlen function. For example:
#include
size_t my_strlen( const char *input )
{
return strlen( input );
}
int main()
{
int s1 = strlen("bla");
int s2 = my_strlen("bla");
return 0;
}
leads to:
$ gcc -Wconversion t.c
t.c: In function ‘main’:
t.c:11: warning: conversion to ‘int’ from ‘size_t’ may alter its value
Clearly one warning is missing (on line 10).
Thanks
[Bug c++/59324] New: C++11: -Wsequence-point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59324
Bug ID: 59324
Summary: C++11: -Wsequence-point
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mathieu.malaterre at gmail dot com
It would be nice to remove the following warning about UB when compiling in
C++11 mode:
$ cat t.cxx
int main()
{
int b = 1;
int m = (b++) + (++b);
(void)m;
return 0;
}
$ g++ -std=c++11 -Wsequence-point t.cxx
t.cxx: In function 'int main()':
t.cxx:4:23: warning: operation on 'b' may be undefined [-Wsequence-point]
int m = (b++) + (++b);
^
$ g++ --version
g++ (Debian 4.8.2-1) 4.8.2
[Bug middle-end/88273] [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
--- Comment #7 from Mathieu Malaterre ---
Here is the new creduced test case:
$ cat bug.c
#include
typedef struct {
int b[4]
} c;
void* d;
unsigned e;
inline int h(void *i, int p2, int j) {
if (j < 0 || e < j) {
int copy = ({
typeof(e) k = j - e;
k;
});
i += e - p2;
memcpy(d, i, copy);
e = copy;
}
}
void a() {
int g = h(&g, 0, sizeof(c));
union {
c f;
} vrsave;
h(&vrsave, 33 * sizeof(c), -1);
}
Compilation:
$ powerpc-linux-gnu-gcc -Warray-bounds -mcpu=powerpc -O2 -c bug.c
Using creduce with:
#!/bin/bash
powerpc-linux-gnu-gcc -Warray-bounds -mcpu=powerpc -O2 -c ptrace2.i >&
output.txt
grep error output.txt && exit 1
grep -F "warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of
object 'vrsave' with type 'union '" output.txt >/dev/null 2>&1
[Bug middle-end/88273] [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
--- Comment #8 from Mathieu Malaterre ---
For reference:
$ cat ptrace2.c
#include
#define CREATE_TRACE_POINTS
#include
void a(int b, int c, void *d) {
void *e = 0;
int g = user_regset_copyout(&b, &c, d, e, g, 0, sizeof(vector128));
union {
elf_vrreg_t f
} vrsave;
user_regset_copyout(&b, &c, d, e, &vrsave, 33 * sizeof(vector128), -1);
}
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #15 from Mathieu Malaterre --- Created attachment 43773 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43773&action=edit valgrind output (not ok)
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 Mathieu Malaterre changed: What|Removed |Added CC||mathieu.malaterre at gmail dot com --- Comment #14 from Mathieu Malaterre --- Created attachment 43772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43772&action=edit valgrind output (ok)
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #17 from Mathieu Malaterre --- Here is what I did over here: # debootstrap --arch amd64 sid /srv/chroot/sid-amd64 http://httpredir.debian.org/debian # mount -t proc proc /srv/chroot/sid-amd64/proc # chroot /srv/chroot/sid-amd64 apt install g++-mingw-w64-i686 Then (https://wiki.debian.org/AutomaticDebugPackages): # apt install g++-mingw-w64-i686-dbgsym And eventually ran valgrind on both: # valgrind --trace-children=yes i686-w64-mingw32-g++ -c -std=c++17 -O2 -Wnonnull -Woverloaded-virtual -v tmp1/16795.cpp -o warn.o >& /tmp/ok # valgrind --trace-children=yes i686-w64-mingw32-g++ -c -std=c++17 -O2 -Wnonnull -Woverloaded-virtual -v 16795.cpp -o warn.o >& /tmp/notok The valgrind output seems rather different, so I suspect the issue is indeed an invalid read/write which should be somewhere in the diff of ok vs notok.
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #18 from Mathieu Malaterre --- The first diff seems to be here: +Use of uninitialised value of size 8 + at 0x98CBD7: sparseset_bit_p (sparseset.h:147) + by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1226) + by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806) + by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564) + by 0x97345C: ira_build() (ira-build.c:3422) + by 0x96ACCB: ira (ira.c:5308) + by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5619) + by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465) + by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554) + by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555) + by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565) + by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042) + by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178) + by 0x7ACFF8: symbol_table::compile() [clone .part.50] (cgraphunit.c:2536) + by 0x7AECE6: compile (cgraphunit.c:2629) + by 0x7AECE6: symbol_table::finalize_compilation_unit() (cgraphunit.c:2626)
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #20 from Mathieu Malaterre --- (In reply to Martin Liška from comment #19) > (In reply to Mathieu Malaterre from comment #18) > > The first diff seems to be here: > > > > +Use of uninitialised value of size 8 > > + at 0x98CBD7: sparseset_bit_p (sparseset.h:147) > > + by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*) > > (ira-lives.c:1226) > > + by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void > > (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806) > > + by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564) > > + by 0x97345C: ira_build() (ira-build.c:3422) > > + by 0x96ACCB: ira (ira.c:5308) > > + by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*) > > (ira.c:5619) > > + by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465) > > + by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554) > > + by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555) > > + by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565) > > + by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042) > > + by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178) > > + by 0x7ACFF8: symbol_table::compile() [clone .part.50] > > (cgraphunit.c:2536) > > + by 0x7AECE6: compile (cgraphunit.c:2629) > > + by 0x7AECE6: symbol_table::finalize_compilation_unit() > > (cgraphunit.c:2626) > > This should be fine, please take a look here: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78454 Ooops :( Sorry false alarm. So I meant to say "This must be somewhere before [insert block quote]".
[Bug c/88273] New: warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
Bug ID: 88273
Summary: warning: 'memcpy' offset [-527, -529] is out of the
bounds [0, 16] of object 'vrsave' with type 'union
' [-Warray-bounds]
Product: gcc
Version: 8.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: ---
Created attachment 45127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45127&action=edit
creduce code
There seems to be a regression in 8.2.0 from the previous release. See original
post at:
* https://lkml.org/lkml/2018/8/16/117
Reduced test case:
$ cat bug.c
typedef struct {
int a[4]
} b, c;
d, e;
inline f(void *g, int h, int p3) {
unsigned *i = 0;
int copy = ({ d ?: p3; });
g += *i - h;
memcpy(e, g, copy);
*i = copy;
}
j() {
f(j, 0, sizeof(c));
union {
b k
} vrsave;
f(&vrsave, 33 * sizeof(c), 1);
}
With:
$ powerpc-linux-gnu-gcc -Warray-bounds -mcpu=powerpc
-fno-delete-null-pointer-checks -O2 -c bug.c
...
bug.c:9:3: warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16]
of object 'vrsave' with type 'union ' [-Warray-bounds]
memcpy(e, g, copy);
For reference:
$ powerpc-linux-gnu-gcc --version
powerpc-linux-gnu-gcc (Debian 8.2.0-9) 8.2.0
[Bug middle-end/88273] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273 --- Comment #5 from Mathieu Malaterre --- Created attachment 45128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45128&action=edit save-temps
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 --- Comment #7 from Mathieu Malaterre --- For anyone reading this. the comment "-latomic is there already." means: replace __sync_val_compare_and_swap(ptr, oldval, newval) in your code with __atomic_compare_exchange(ptr, &oldval, &newval, false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) then link with -latomic
[Bug c++/64631] New: error: ‘lgammal_r’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64631 Bug ID: 64631 Summary: error: ‘lgammal_r’ was not declared in this scope Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mathieu.malaterre at gmail dot com Created attachment 34464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34464&action=edit demo I cannot compile the following pseudo code (see attachment) it fails with: $ g++ -ffast-math foo.cxx In file included from /usr/include/math.h:432:0, from foo.cxx:3: /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘double lgamma(double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:260:41: error: ‘lgamma_r’ was not declared in this scope return lgamma_r (__d, &__local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘float lgammaf(float)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:269:42: error: ‘lgammaf_r’ was not declared in this scope return lgammaf_r (__d, &__local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘long double lgammal(long double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:279:42: error: ‘lgammal_r’ was not declared in this scope return lgammal_r (__d, &__local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘double gamma(double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:293:41: error: ‘lgamma_r’ was not declared in this scope return lgamma_r (__d, &__local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘float gammaf(float)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:302:42: error: ‘lgammaf_r’ was not declared in this scope return lgammaf_r (__d, &__local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘long double gammal(long double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:312:42: error: ‘lgammal_r’ was not declared in this scope return lgammal_r (__d, &__local_signgam);
[Bug c++/62280] New: Symbols visibility not equivalent to class visibility (-fvisibility=hidden)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62280
Bug ID: 62280
Summary: Symbols visibility not equivalent to class visibility
(-fvisibility=hidden)
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mathieu.malaterre at gmail dot com
I am trying to compile a project that is written in portable C++. It does
compile fine with Visual Studio 2010 on Windows 7 and makes uses of symbol
visibilty macros.
However when I compile this project with gcc-4.7/gcc-4.9.1 on linux, I am
getting this linker error:
g++ -fvisibility=hidden -fvisibility-inlines-hidden [...]
/tmp/ccegevbt.o:(.rodata._ZTI12subclass[_ZTI12subclass]+0x10): undefined
reference to `typeinfo for ns::baseclass'
I did read a [previous report][1] and indeed exporting at class level directly
(instead of per symbol) solves the symptoms:
class __attribute__ ((visibility ("default"))) baseclass {
However the code is actually written to export only some member function, so it
should produce identical behavior with Visual Studio C++ compiler, right ?
class baseclass {
public: // Member functions
DLL_EXPORT baseclass();
DLL_EXPORT virtual ~baseclass();
My question: is what slightly different behavior in exporting symbols is
happening in between Visual Studio 2010 and gcc-4.7 ? How do I track which
symbol is actually causing issue ?
For clarification here is a very small toy example which works fine on Visual
Studio 2010
$ cat test.h
#pragma once
#ifdef __GNUC__
#define DLL_EXPORT __attribute__((visibility("default")))
#else
#define DLL_EXPORT __declspec(dllexport)
#endif
struct Base
{
DLL_EXPORT virtual ~Base();
DLL_EXPORT virtual Base* clone() {
return 0;
}
};
#undef DLL_EXPORT
and
$ cat test.cpp
#include "test.h"
Base::~Base()
{
}
and
$ cat main.cpp
#include "test.h"
struct Foo : public Base
{
virtual ~Foo();
virtual Base* clone() {
return new Foo();
}
};
Foo::~Foo()
{
}
int main()
{
Base* f = new Foo();
f->clone();
return 0;
}
using cmake, it is simply:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(bla)
add_library(test SHARED test.cpp)
add_executable(main main.cpp)
target_link_libraries(main test)
>From linux:
$ export CXXFLAGS="-fvisibility=hidden -fvisibility-inlines-hidden"
$ cmake . && make
>From windows:
$ cmake . -G"NMake Makefiles"
$ nmake
For people not using cmake, you could use:
$ cat Makefile
main: main.cpp test.h libtest.so
g++ -fvisibility=hidden -fvisibility-inlines-hidden -L. -ltest main.cpp
-o main
libtest.so: test.cpp test.h
g++ -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -shared
test.cpp -o libtest.so
which leads to:
$ make
g++ -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -shared test.cpp
-o libtest.so
g++ -fvisibility=hidden -fvisibility-inlines-hidden -L. -ltest main.cpp -o
main
/tmp/cc5lGsdn.o: In function `Base::Base()':
main.cpp:(.text._ZN4BaseC2Ev[_ZN4BaseC5Ev]+0xf): undefined reference to
`vtable for Base'
/tmp/cc5lGsdn.o:(.rodata._ZTI3Foo[_ZTI3Foo]+0x10): undefined reference to
`typeinfo for Base'
collect2: error: ld returned 1 exit status
make: *** [main] Error 1
In case this matter, adding `-fno-devirtualize` does not help (as per sug from
[here][2])
Of course the obvious solution of changing:
struct Base
into
struct DLL_EXPORT Base
does solve the symptoms.
ref:
http://stackoverflow.com/questions/2559/tracking-an-issue-with-fvisibility-hidden-that-triggers-a-undefined-reference-t
[Bug c/63368] New: undefined reference to `__sync_val_compare_and_swap_8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
Bug ID: 63368
Summary: undefined reference to `__sync_val_compare_and_swap_8'
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mathieu.malaterre at gmail dot com
If I am reading the online documentation properly:
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins
__sync_val_compare_and_swap on some targets will result in a function call
(where direct code generation is not available or not yet implemented).
It seems to be happening in my testcase, however __sync_val_compare_and_swap_8
does not seems to be defined anywhere else.
Steps:
$ cat t.c
#include
int main()
{
int64_t x = 0, y = 1;
y = __sync_val_compare_and_swap(&x, x, y);
return 0;
}
$ gcc t.c
/tmp/cc6JIpFx.o: In function `main':
t.c:(.text+0x64): undefined reference to `__sync_val_compare_and_swap_8'
collect2: ld returned 1 exit status
$ gcc t.c -lgcc_s
/tmp/ccu3ReMZ.o: In function `main':
t.c:(.text+0x64): undefined reference to `__sync_val_compare_and_swap_8'
collect2: ld returned 1 exit status
$ gcc t.c -lgcc
/tmp/ccO8gyeR.o: In function `main':
t.c:(.text+0x64): undefined reference to `__sync_val_compare_and_swap_8'
collect2: ld returned 1 exit status
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 Mathieu Malaterre changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- Summary|undefined reference to |Provide an implementation |`__sync_val_compare_and_swa |for |p_8'|`__sync_val_compare_and_swa ||p_8' on powerpc (32bits) --- Comment #2 from Mathieu Malaterre --- Thanks for the clarification. I've re-open the bug for a request to support __sync_val_compare_and_swap (64bits) on PowerPC 32bits.
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
--- Comment #4 from Mathieu Malaterre ---
As stated in my original report I am running a PowerPC/32bits machine (not an
ARM based one).
AFAIK gcc 4.9.1 does not provide such implementation [*]. Could you please
clarify what you mean by 'libatomic is there already' ?
[*]
% cat t.c
#include
int main()
{
int64_t x = 0, y = 1;
y = __sync_val_compare_and_swap(&x, x, y);
return 0;
}
% gcc -v t.c -latomic
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnu/4.9/lto-wrapper
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-powerpc/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-powerpc
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-powerpc
--with-arch-directory=ppc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --disable-softfloat --with-cpu=default32
--disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux
--enable-multiarch --with-long-double-128 --enable-multilib
--enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu
--target=powerpc-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)
COLLECT_GCC_OPTIONS='-v'
/usr/lib/gcc/powerpc-linux-gnu/4.9/cc1 -quiet -v -imultiarch powerpc-linux-gnu
-D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux
-Asystem=linux -Asystem=unix -Asystem=posix t.c -msecure-plt -quiet -dumpbase
t.c -auxbase t -version -o /tmp/ccNTY4Ab.s
GNU C (Debian 4.9.1-15) version 4.9.1 (powerpc-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2-p3,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/powerpc-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../../powerpc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/powerpc-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/powerpc-linux-gnu/4.9/include-fixed
/usr/include/powerpc-linux-gnu
/usr/include
End of search list.
GNU C (Debian 4.9.1-15) version 4.9.1 (powerpc-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2-p3,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c43d4b06b119d970361c68b09a8c4f80
COLLECT_GCC_OPTIONS='-v'
as -v -a32 -mppc -many -mbig -o /tmp/cckOC6zg.o /tmp/ccNTY4Ab.s
GNU assembler version 2.24.51 (powerpc-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.24.51.20140918
COMPILER_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.9/:/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../../lib/:/lib/powerpc-linux-gnu/:/lib/../lib/:/usr/lib/powerpc-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v'
/usr/lib/gcc/powerpc-linux-gnu/4.9/collect2 -plugin
/usr/lib/gcc/powerpc-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/powerpc-linux-gnu/4.9/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc3I7gDk.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -V -m elf32ppclinux --hash-style=gnu -dynamic-linker
/lib/ld.so.1
/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu/crt1.o
/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu/crti.o
/usr/lib/gcc/powerpc-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/powerpc-linux-gnu/4.9
-L/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../powerpc-linux-gnu
-L/usr/lib/gcc/powerpc-linux-gnu/4.9/../../../../lib -L/lib/powerpc-linux-gnu
-L/lib/../lib -L/usr/lib/powerpc-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/powerpc-linux-gnu/4.9/../../.. /tmp/cckOC6zg.o -latomic -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/powerpc-linux-gnu/4.9/crtend.o
/usr/lib/gc
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 Mathieu Malaterre changed: What|Removed |Added Status|RESOLVED|VERIFIED Resolution|INVALID |WONTFIX --- Comment #6 from Mathieu Malaterre --- @Jonathan thanks for the clarification. I've moved the issue from resolved/invalid to verified/wontfix. I guess no-one really works on ppc32 these days. regards
[Bug c++/63452] New: Cross class calling (pure virtual)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63452
Bug ID: 63452
Summary: Cross class calling (pure virtual)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mathieu.malaterre at gmail dot com
You'll find a small c++ project I gather to demonstrate how a class A `foo`
function can be called using class B `foo` function.
I believe gcc confuse the two separate implementations instead of producing a
warning about conflicting symbols.
Code is at:
https://github.com/malaterre/gcc-virtual
Main code is:
int main()
{
B b;
b.foo();
}
It produces as output:
$ ./virt
I'm PA Implementation
while implementation is:
https://raw.githubusercontent.com/malaterre/gcc-virtual/master/B.cxx
[...]
struct Impl : public PB
{
void foo()
{
std::cout << "I'm PB Implementation" << std::endl;
}
};
[...]
Thanks for consideration.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68891
Bug ID: 68891
Summary: must use a typedef to declare a conversion to 'double
(&)[3]'
Product: gcc
Version: 5.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: ---
Per my understanding of C++ standard section §12.3.2, the following piece of
code should not compile:
$ cat c.cxx
#include
struct V
{
(&operator double ())[3] {
return v;
}
double v[3];
};
static void Print( const double (&a)[3] )
{
std::cout << a[0] << "," << a[1] << "," << a[2] << std::endl;
}
int main()
{
V v = {0,1,2};
Print( v );
return 0;
}
Seems to be valid c++ for gcc 5.2.1:
$ g++ -Wall -W -pedantic c.cxx && ./a.out
0,1,2
The only accepted syntax should be using a `typedef` keyword:
typedef double (&array_ref)[3];
operator array_ref () { return v; }
[Bug c++/49387] New: t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 Summary: t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mathieu.malate...@gmail.com I am getting this weird compilation error which I am not able to understand what it means: $ g++ t.cxx t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’ See attached cxx file.
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 --- Comment #2 from Mathieu Malaterre 2011-06-13 09:09:15 UTC --- Created attachment 24505 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24505 Test case
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 --- Comment #4 from Mathieu Malaterre 2011-06-13 09:49:41 UTC --- Test was done a on a debian/squeeze system: $ g++ --version g++ (Debian 4.4.5-8) 4.4.5 $ apt-cache policy libboost1.42-dev libboost1.42-dev: Installed: 1.42.0-4 Candidate: 1.42.0-4 Version table: 1.42.0-4+b1 0 200 http://ftp.fr.debian.org/debian/ testing/main amd64 Packages 100 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages *** 1.42.0-4 0 500 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages 100 /var/lib/dpkg/status
[Bug c++/49745] New: error: ‘int truncate’ redeclared as different kind of symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745
Summary: error: ‘int truncate’ redeclared as different kind of
symbol
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mathieu.malate...@gmail.com
Hi,
g++ pollutes the global namespace. The following does not compile with G++
4.4.5:
#include
int truncate = 0;
int main()
{
return 0;
}
If fails with:
t.cxx:2: error: ‘int truncate’ redeclared as different kind of symbol
/usr/include/unistd.h:998: error: previous declaration of ‘int truncate(const
char*, __off_t)’
Thanks !
[Bug c++/49759] New: std::streampos == int should be ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49759
Summary: std::streampos == int should be ambiguous
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mathieu.malate...@gmail.com
I believe the following code should not compile:
#include
int main()
{
std::ofstream f( "bla.txt" );
std::ifstream is( "bla.txt" );
if( is.tellg() == 0 ) {}
return 0;
}
the overload for 'operator==' is ambiguous and should be reported. Eg:
line 7: error: more than one operator "==" matches these operands:
built-in operator "arithmetic == arithmetic"
function "std::operator==(const std::fpos &, const
std::fpos &)"
operand types are: std::streampos == int
if( is.tellg() == 0 ) {}
^
or
error: ambiguous overload for 'operator==' in
'((std::istream*)is)->std::basic_istream<_CharT, _Traits>::tellg [with _CharT =
char, _Traits = std::char_traits]() == 0'
note: candidates are: operator==(std::streamoff, int)
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/postypes.h:138: note:
bool std::fpos<_StateT>::operator==(const std::fpos<_StateT>&)
const [with _StateT = __mbstate_t]
[Bug c/71617] New: rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71617 Bug ID: 71617 Summary: rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits] Product: gcc Version: 6.1.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: --- The following code should be cleaned up: powerpc64-linux-gnu-g++-5 -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o rs6000.o -MT rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo ../../src/gcc/config/rs6000/rs6000.c ../../src/gcc/config/rs6000/rs6000.c: In function 'bool use_toc_relative_ref(rtx, machine_mode)': ../../src/gcc/config/rs6000/rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits] && GET_MODE_SIZE (mode) <= POWERPC64_TOC_POINTER_ALIGNMENT)); ^
[Bug c/71777] New: __builtin_cpu_supports() doesn't work on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71777 Bug ID: 71777 Summary: __builtin_cpu_supports() doesn't work on powerpc Product: gcc Version: 6.1.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: --- Created attachment 38839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38839&action=edit demo code I've been trying to test __builtin_cpu_supports on PowerPC (ppc32 and ppc64), as per documentation: https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/PowerPC-Built-in-Functions.html#PowerPC-Built-in-Functions However the attached code never returns a value of 1, 0 is always returned. No warning/errors were shown when compiling it with: % gcc-6 -O3 -m32 -o cpu32 cpu.c && ./cpu32 or % gcc-6 -O3 -m64 -o cpu64 cpu.c && ./cpu64 ref: % gcc-6 --version gcc-6 (Debian 6.1.1-8) 6.1.1 20160630 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. malat@pizzetti ~ % cat /proc/cpuinfo processor : 0 cpu : POWER8E (raw), altivec supported clock : 3425.00MHz revision: 2.1 (pvr 004b 0201) processor : 1 cpu : POWER8E (raw), altivec supported clock : 3425.00MHz revision: 2.1 (pvr 004b 0201) processor : 2 cpu : POWER8E (raw), altivec supported clock : 3425.00MHz revision: 2.1 (pvr 004b 0201) processor : 3 cpu : POWER8E (raw), altivec supported clock : 3425.00MHz revision: 2.1 (pvr 004b 0201) timebase: 51200 platform: pSeries model : IBM pSeries (emulated by qemu) machine : CHRP IBM pSeries (emulated by qemu) as well as: malat@partch ~ % cat /proc/cpuinfo processor : 0 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) processor : 1 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) processor : 2 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) processor : 3 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) processor : 4 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) processor : 5 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) processor : 6 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) processor : 7 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision: 2.1 (pvr 003f 0201) timebase: 51200 platform: pSeries model : IBM,8231-E2B machine : CHRP IBM,8231-E2B
[Bug target/71777] __builtin_cpu_supports() doesn't work on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71777 Mathieu Malaterre changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Mathieu Malaterre --- Right. I totally missed that from your post. Sorry for the noise, this works for me now (was using glibc 2.22). For reference on POWER7, I get: 2 -- 1 2 3 6 9 10 14 17 20 23 24 25 27 29 30 31 34 37
[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported
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)
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)
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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 -
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
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
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 <http://gnu.org/licenses/gpl.html>
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:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
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},
,
, ,
[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden
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
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
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
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
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
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
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
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
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
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)
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)
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)
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)
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)
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)
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"...
