[Bug target/100438] `_serialize` macro clashes with user defined identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438 --- Comment #6 from heinzisoft at web dot de --- Seems the crypto++ library includes x86intrin.h, and that leaks the macro. I assume a library isn't supposed to do that? https://github.com/weidai11/cryptopp/blob/master/misc.h#L83
[Bug libstdc++/100438] `_serialize` macro clashes with user defined identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438 --- Comment #1 from heinzisoft at web dot de --- - https://bugs.gentoo.org/788403
[Bug libstdc++/100438] New: `_serialize` macro clashes with user defined identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438 Bug ID: 100438 Summary: `_serialize` macro clashes with user defined identifiers Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: heinzisoft at web dot de Target Milestone: --- [CryFS](https://github.com/cryfs/cryfs) compiled fine with GCC 10, but it breaks with GCC 11 because the standard library is now defining a `_serialize` macro that leaks into user code. When CryFS is trying to call a local `_serialize` function, the macro is picked instead. It looks like the macro got introduced here: https://patchwork.ozlabs.org/project/gcc/patch/came9rop_dlg55krxw2v75ppeqj-8tdkob5z-+ewppf-l3ou...@mail.gmail.com/ Also, there's reports in other bug trackers about the same issue: - https://github.com/cryfs/cryfs/issues/389 - https://bugs.gentoo.org/786459
[Bug libstdc++/82481] dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 --- Comment #5 from heinzisoft at web dot de --- (In reply to Jonathan Wakely from comment #2) > It is a dangling pointer, but it can't be dereferenced, so it doesn't matter. > > It's only used by std::call_once and will be set to a different local > variable by the next call. We could zero the pointer, but it would be a > waste of cycles. Can we still fix this? It prevents people from doing clang-tidy analysis on their code base because it can't be distinguished from errors in their code. Since it actually is a dangling pointer, I don't think we can push responsibility to clang-tidy. If we don't want to waste the cycle of setting it to zero, we could consider adding something to make clang-tidy ignore this error. I think this can be done with special comments.
[Bug libstdc++/82481] dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 --- Comment #4 from heinzisoft at web dot de --- (In reply to Jonathan Wakely from comment #3) > (In reply to heinzisoft from comment #0) > > Building the following minimal example with libstdc++ 7.0.1 > > And why are you using that unsupported version? I installed it on Ubuntu using ppa:ubuntu-toolchain-r/test
[Bug libstdc++/82481] New: dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481
Bug ID: 82481
Summary: dangling reference in mutex:693
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: heinzisoft at web dot de
Target Milestone: ---
Building the following minimal example with libstdc++ 7.0.1 using clang-tidy
4.0.0 on Ubuntu 17.04:
main.cpp:
#include
int main() {
std::promise p;
p.set_value(3);
}
Build command:
$ clang-tidy main.cpp -extra-arg=-std=c++14
Output:
Running without flags.
1 warning generated.
/usr/lib/gcc/x86_64-linux-gnu/7.0.1/../../../../include/c++/7.0.1/mutex:693:5:
warning: Address of stack memory associated with local variable '__callable' is
still referred to by the global variable '__once_callable' upon returning to
the caller. This will be a dangling reference
[clang-analyzer-core.StackAddressEscape]
}
^
/home/user/main.cpp:5:3: note: Calling 'promise::set_value'
p.set_value(3);
^
/usr/lib/gcc/x86_64-linux-gnu/7.0.1/../../../../include/c++/7.0.1/future:1094:9:
note: Calling '_State_baseV2::_M_set_result'
{ _M_future->_M_set_result(_State::__setter(this, std::move(__r))); }
^
/usr/lib/gcc/x86_64-linux-gnu/7.0.1/../../../../include/c++/7.0.1/future:401:2:
note: Calling 'call_once'
call_once(_M_once, &_State_baseV2::_M_do_set, this,
^
/usr/lib/gcc/x86_64-linux-gnu/7.0.1/../../../../include/c++/7.0.1/mutex:691:11:
note: Assuming '__e' is 0
if (__e)
^
/usr/lib/gcc/x86_64-linux-gnu/7.0.1/../../../../include/c++/7.0.1/mutex:691:7:
note: Taking false branch
if (__e)
^
/usr/lib/gcc/x86_64-linux-gnu/7.0.1/../../../../include/c++/7.0.1/mutex:693:5:
note: Address of stack memory associated with local variable '__callable' is
still referred to by the global variable '__once_callable' upon returning to
the caller. This will be a dangling reference
}
[Bug c++/82159] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82159 --- Comment #1 from heinzisoft at web dot de --- Correction: OS is Ubuntu 17.04, not 17.10
[Bug c++/82159] New: ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82159
Bug ID: 82159
Summary: ICE: in assign_temp, at function.c:961
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: heinzisoft at web dot de
Target Milestone: ---
Seeing the following error on GCC 6.3.0 and GCC 7.2.0, while it builds fine on
GCC 5 and on current Clang. OS is Ubuntu 17.10.
Steps to Repro:
-
$ g++ test.cpp
test.cpp: In function ‘int main()’:
test.cpp:17:35: internal compiler error: in assign_temp, at function.c:961
MyClass<0> taken = data.func<0>();
^
Please submit a full bug report,
with preprocessed source if appropriate.
Source file test.cpp:
-
#include
template
struct MyClass {
public:
~MyClass() {}
template MyClass func() {
return MyClass();
}
unsigned char data[SIZE];
};
int main() {
MyClass<16> data;
MyClass<0> taken = data.func<0>();
}
