public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c++/98220] New: LTO causes floating point exception @ 2020-12-10 8:14 wuz73 at hotmail dot com 2020-12-10 8:19 ` [Bug c++/98220] " pinskia at gcc dot gnu.org ` (11 more replies) 0 siblings, 12 replies; 13+ messages in thread From: wuz73 at hotmail dot com @ 2020-12-10 8:14 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 Bug ID: 98220 Summary: LTO causes floating point exception Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wuz73 at hotmail dot com Target Milestone: --- Created attachment 49726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49726&action=edit test case for LTO crash In the attached test case, if -flto is turned on then the executable crashes with floating point exception even though I didn't use any floating point. Without -flto everything was fine. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com @ 2020-12-10 8:19 ` pinskia at gcc dot gnu.org 2020-12-10 8:21 ` wuz73 at hotmail dot com ` (10 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: pinskia at gcc dot gnu.org @ 2020-12-10 8:19 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Are you sure this just not a divide by zero? On x86, an integer divide by zero will throw an FPU exception. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com 2020-12-10 8:19 ` [Bug c++/98220] " pinskia at gcc dot gnu.org @ 2020-12-10 8:21 ` wuz73 at hotmail dot com 2020-12-10 8:22 ` marxin at gcc dot gnu.org ` (9 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: wuz73 at hotmail dot com @ 2020-12-10 8:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #2 from wuz73 at hotmail dot com --- There's no division as can be seen in the test case. ________________________________ From: pinskia at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> Sent: Thursday, December 10, 2020 4:19 PM To: wuz73@hotmail.com <wuz73@hotmail.com> Subject: [Bug c++/98220] LTO causes floating point exception https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Are you sure this just not a divide by zero? On x86, an integer divide by zero will throw an FPU exception. -- You are receiving this mail because: You reported the bug. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com 2020-12-10 8:19 ` [Bug c++/98220] " pinskia at gcc dot gnu.org 2020-12-10 8:21 ` wuz73 at hotmail dot com @ 2020-12-10 8:22 ` marxin at gcc dot gnu.org 2020-12-10 8:30 ` wuz73 at hotmail dot com ` (8 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: marxin at gcc dot gnu.org @ 2020-12-10 8:22 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> --- Hello. The attached libraries are not what we can use as a reproducer: https://www.gnu.org/software/gcc/bugs/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (2 preceding siblings ...) 2020-12-10 8:22 ` marxin at gcc dot gnu.org @ 2020-12-10 8:30 ` wuz73 at hotmail dot com 2020-12-10 9:03 ` marxin at gcc dot gnu.org ` (7 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: wuz73 at hotmail dot com @ 2020-12-10 8:30 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #4 from wuz73 at hotmail dot com --- In the attached test case, there is a makefile and source code. Here's the output without -flto: $ make g++ -std=c++11 -Wall -g -O2 -o main.o -c main.cpp g++ -std=c++11 -Wall -g -O2 -o module.o -c module.cpp g++ -std=c++11 -Wall -g -O2 -o moduleA.o -c moduleA.cpp g++ -std=c++11 -Wall -g -O2 -o moduleB.o -c moduleB.cpp g++ -std=c++11 -Wall -g -O2 -o test main.o module.o moduleA.o moduleB.o $ ./test modA a process modB b process With -flto: $ make g++ -std=c++11 -Wall -g -O2 -flto -o main.o -c main.cpp g++ -std=c++11 -Wall -g -O2 -flto -o module.o -c module.cpp g++ -std=c++11 -Wall -g -O2 -flto -o moduleA.o -c moduleA.cpp g++ -std=c++11 -Wall -g -O2 -flto -o moduleB.o -c moduleB.cpp g++ -std=c++11 -Wall -g -O2 -flto -o test main.o module.o moduleA.o moduleB.o $ ./test Floating point exception (core dumped) ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (3 preceding siblings ...) 2020-12-10 8:30 ` wuz73 at hotmail dot com @ 2020-12-10 9:03 ` marxin at gcc dot gnu.org 2020-12-10 9:14 ` marxin at gcc dot gnu.org ` (6 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: marxin at gcc dot gnu.org @ 2020-12-10 9:03 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 Martin Liška <marxin at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Last reconfirmed| |2020-12-10 Status|UNCONFIRMED |NEW CC| |marxin at gcc dot gnu.org --- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> --- Oh, sorry, I copied a bad folder. I'm sorry. I'm going to take a look. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (4 preceding siblings ...) 2020-12-10 9:03 ` marxin at gcc dot gnu.org @ 2020-12-10 9:14 ` marxin at gcc dot gnu.org 2020-12-10 9:16 ` marxin at gcc dot gnu.org ` (5 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: marxin at gcc dot gnu.org @ 2020-12-10 9:14 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 Martin Liška <marxin at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |redi at gcc dot gnu.org --- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> --- Apparently, it also crashes with -O0. The backtrace is: ==20542== Process terminating with default action of signal 8 (SIGFPE): dumping core ==20542== Integer divide by zero at address 0x1002CB899F ==20542== at 0x401391: std::__detail::_Mod_range_hashing::operator()(unsigned long, unsigned long) const (hashtable_policy.h:431) ==20542== by 0x40177A: std::__detail::_Hash_code_base<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Module* (*)(char const*)>, std::__detail::_Select1st, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, true>::_M_bucket_index(unsigned long, unsigned long) const (hashtable_policy.h:1224) ==20542== by 0x40169E: std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Module* (*)(char const*)>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Module* (*)(char const*)> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::_M_bucket_index(unsigned long) const (hashtable.h:735) ==20542== by 0x4015C8: std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Module* (*)(char const*)>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Module* (*)(char const*)> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (hashtable.h:1516) ==20542== by 0x40152C: std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, Module* (*)(char const*), std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Module* (*)(char const*)> > >::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (unordered_map.h:869) ==20542== by 0x4022CC: ModuleFactory::Register(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Module* (*)(char const*)) (module.h:27) ==20542== by 0x402342: RegisterModule::RegisterModule(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Module* (*)(char const*)) (module.h:45) ==20542== by 0x403348: __static_initialization_and_destruction_0(int, int) [clone .lto_priv.2] (moduleB.cpp:8) ==20542== by 0x4033A6: _GLOBAL__sub_I__ZN7ModuleB6CreateEPKc (moduleB.cpp:14) ==20542== by 0x4033B1: _sub_I_65535_0.0 (moduleB.cpp:14) ==20542== by 0x40340C: __libc_csu_init (elf-init.c:89) ==20542== by 0x4BF80DD: (below main) (in /lib64/libc-2.32.so) I bet it's related to the construction of the s_creator and its usage at moduleB.cpp:8 It's likely Static Initialization Order Fiasco: https://en.cppreference.com/w/cpp/language/siof @Jonathan: Can you please judge? ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (5 preceding siblings ...) 2020-12-10 9:14 ` marxin at gcc dot gnu.org @ 2020-12-10 9:16 ` marxin at gcc dot gnu.org 2020-12-10 10:15 ` redi at gcc dot gnu.org ` (4 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: marxin at gcc dot gnu.org @ 2020-12-10 9:16 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 Martin Liška <marxin at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> --- It's the order fiasco, one can see it also without LTO: g++ -std=c++11 -Wall -g -o main.o -c main.cpp g++ -std=c++11 -Wall -g -o module.o -c module.cpp g++ -std=c++11 -Wall -g -o moduleA.o -c moduleA.cpp g++ -std=c++11 -Wall -g -o moduleB.o -c moduleB.cpp g++ -std=c++11 -Wall -g -o test main.o module.o moduleA.o moduleB.o $ g++ -std=c++11 -Wall -g -o test main.o moduleA.o moduleB.o module.o && ./test Floating point exception (core dumped) (I changed the order of linked objects). ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (6 preceding siblings ...) 2020-12-10 9:16 ` marxin at gcc dot gnu.org @ 2020-12-10 10:15 ` redi at gcc dot gnu.org 2020-12-10 14:07 ` wuz73 at hotmail dot com ` (3 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: redi at gcc dot gnu.org @ 2020-12-10 10:15 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Martin Liška from comment #6) > I bet it's related to the construction of the s_creator and its usage at > moduleB.cpp:8 > It's likely Static Initialization Order Fiasco: > https://en.cppreference.com/w/cpp/language/siof > > @Jonathan: Can you please judge? Agreed. Either all the REGISTER_MODULE objects need to be created in the same translation unit, after the definition of s_creator, or you need to initialize s_creator as needed e.g. class ModuleFactory { ... private: static std::unordered_map<std::string, Module::creator_t>& s_creator() { static std::unordered_map<std::string, Module::creator_t> s_map; return s_map; }; }; ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (7 preceding siblings ...) 2020-12-10 10:15 ` redi at gcc dot gnu.org @ 2020-12-10 14:07 ` wuz73 at hotmail dot com 2020-12-10 14:23 ` redi at gcc dot gnu.org ` (2 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: wuz73 at hotmail dot com @ 2020-12-10 14:07 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #9 from wuz73 at hotmail dot com --- Without -flto I can specify link order. So -flto will ignore the order? It is still a bug as in many cases orders do matter. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (8 preceding siblings ...) 2020-12-10 14:07 ` wuz73 at hotmail dot com @ 2020-12-10 14:23 ` redi at gcc dot gnu.org 2020-12-10 15:53 ` wuz73 at hotmail dot com 2020-12-10 16:12 ` redi at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: redi at gcc dot gnu.org @ 2020-12-10 14:23 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- No it's, not a bug, because the C++ standard says the order is unspecified. The compiler is allowed to reorder them, and that's what happens with -flto. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (9 preceding siblings ...) 2020-12-10 14:23 ` redi at gcc dot gnu.org @ 2020-12-10 15:53 ` wuz73 at hotmail dot com 2020-12-10 16:12 ` redi at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: wuz73 at hotmail dot com @ 2020-12-10 15:53 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #11 from wuz73 at hotmail dot com --- (In reply to Jonathan Wakely from comment #10) > No it's, not a bug, because the C++ standard says the order is unspecified. > The compiler is allowed to reorder them, and that's what happens with -flto. So what if I do need certain order (e.g. using libs provided by 3rd party)? Also this floating point exception is really obscure. How can I pinpoint the culprit? ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98220] LTO causes floating point exception 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com ` (10 preceding siblings ...) 2020-12-10 15:53 ` wuz73 at hotmail dot com @ 2020-12-10 16:12 ` redi at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: redi at gcc dot gnu.org @ 2020-12-10 16:12 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to wuz73 from comment #11) > (In reply to Jonathan Wakely from comment #10) > > No it's, not a bug, because the C++ standard says the order is unspecified. > > The compiler is allowed to reorder them, and that's what happens with -flto. > > So what if I do need certain order (e.g. using libs provided by 3rd party)? You fix your code to not depend on initialization order, because the order is unspecified. For example, as I suggested in comment 8. Code that depends on a specific order is broken according to the C++ standard. Or you use non-standard extensions like __attribute__((init_priority(nnn))) to control the relative order of global constructors. > Also this floating point exception is really obscure. How can I pinpoint the > culprit? You look at the stack trace (e.g. in GDB) and see which global variable is being constructed, and which uninitialized global variable it is accessing. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-12-10 16:12 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-10 8:14 [Bug c++/98220] New: LTO causes floating point exception wuz73 at hotmail dot com 2020-12-10 8:19 ` [Bug c++/98220] " pinskia at gcc dot gnu.org 2020-12-10 8:21 ` wuz73 at hotmail dot com 2020-12-10 8:22 ` marxin at gcc dot gnu.org 2020-12-10 8:30 ` wuz73 at hotmail dot com 2020-12-10 9:03 ` marxin at gcc dot gnu.org 2020-12-10 9:14 ` marxin at gcc dot gnu.org 2020-12-10 9:16 ` marxin at gcc dot gnu.org 2020-12-10 10:15 ` redi at gcc dot gnu.org 2020-12-10 14:07 ` wuz73 at hotmail dot com 2020-12-10 14:23 ` redi at gcc dot gnu.org 2020-12-10 15:53 ` wuz73 at hotmail dot com 2020-12-10 16:12 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).