https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102754
Bug ID: 102754 Summary: collisions in double constant template mangling for negative values Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hq.ks at web dot de Target Milestone: --- Created attachment 51601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51601&action=edit reproducer This was a weird one. C++ famously does not allow floating point numbers directly as template parameters for unfathomable reasons (but lambda expressions returning double or string constants are fine, go figure). The common workaround seems to be to have a literal wrapper class which stores a FP number, can be initialized by one and is convertable to one. When using this with negative double numbers, some came out all wrong from the template, causing quite some confusion. Apparently, if two or more template instances depend on a double parameter which is a) negative b) whose mantissa would fit into some 21 bits (possibly causing the 32 less significant bits of the fraction part to be zero?) any instance after the first one would erroneously refer to the first one. On further digging, I think this is somehow related to name mangling. For example, 3.0266874179647485e+267D (Binary 0x7777777777777777) will result in an object named _ZTAXtl4wrapIdELd7777777777777777EEE for me. -1.486039738058660044846e-267 (aka 88 88 88 88 88 88 88 88), however, will result in an object named _ZTAXtl4wrapIdELdffffffff88888888EEE. Note how the upper 32 bits have all been replaced by ones! This means that any doublewrap objects which have their sign bit set will collide if their lower 32 bits are the same. The case I encountered was just the special case of the lower 32 bits being zero. Having concluded that, I can also conclude that this is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216 . (Having spend a day to write up this bug report, I will still submit it and then try to mark it as a duplicate. Hope that is okay.)