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