[Bug c++/98220] New: LTO causes floating point exception

[Bug c++/98220] New: LTO causes floating point exception

[wuz73 at hotmail dot com]

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.

[Bug c++/98220] LTO causes floating point exception

[pinskia at gcc dot gnu.org]

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.

[Bug c++/98220] LTO causes floating point exception

[wuz73 at hotmail dot com]

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.

[Bug c++/98220] LTO causes floating point exception

[marxin at gcc dot gnu.org]

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/

[Bug c++/98220] LTO causes floating point exception

[wuz73 at hotmail dot com]

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)

[Bug c++/98220] LTO causes floating point exception

[marxin at gcc dot gnu.org]

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.

[Bug c++/98220] LTO causes floating point exception

[marxin at gcc dot gnu.org]

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?

[Bug c++/98220] LTO causes floating point exception

[marxin at gcc dot gnu.org]

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).

[Bug c++/98220] LTO causes floating point exception

[redi at gcc dot gnu.org]

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;
    };
};

[Bug c++/98220] LTO causes floating point exception

[wuz73 at hotmail dot com]

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.

[Bug c++/98220] LTO causes floating point exception

[redi at gcc dot gnu.org]

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.

[Bug c++/98220] LTO causes floating point exception

[wuz73 at hotmail dot com]

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?

[Bug c++/98220] LTO causes floating point exception

[redi at gcc dot gnu.org]

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.