* [Bug default/28664] New: misinterpretation of default template instantiation naming idioms.
@ 2021-12-07 0:50 woodard at redhat dot com
2021-12-07 0:53 ` [Bug default/28664] " woodard at redhat dot com
0 siblings, 1 reply; 2+ messages in thread
From: woodard at redhat dot com @ 2021-12-07 0:50 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=28664
Bug ID: 28664
Summary: misinterpretation of default template instantiation
naming idioms.
Product: libabigail
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: default
Assignee: dodji at redhat dot com
Reporter: woodard at redhat dot com
CC: libabigail at sourceware dot org
Target Milestone: ---
When comparing gcc compiled libabigail.so.0.0.0 to to the clang compiled
version one commonly reported error is something like this:
[C] 'function void
abigail::comparison::apply_filters(abigail::comparison::corpus_diff_sptr)' has
some indirect sub-type changes:
parameter 1 of type 'typedef abigail::comparison::corpus_diff_sptr' has
sub-type changes:
underlying type 'class std::shared_ptr<abigail::comparison::corpus_diff>'
at shared_ptr.h:122:1 changed:
type size hasn't changed
1 base class deletion:
class std::__shared_ptr<abigail::comparison::corpus_diff,
(__gnu_cxx::_Lock_policy)2> at shared_ptr_base.h:1052:1
1 base class insertion:
class std::__shared_ptr<abigail::comparison::corpus_diff,
__gnu_cxx::_S_atomic> at shared_ptr_base.h:1052:1
$ abidiff g5/lib/libabigail.so.0.0.0 l5/lib/libabigail.so.0.0.0
the gcc object can be found:
http://ssh.bencoyote.net/~ben/libabigail.so.0.0.0.gcc.bz2 while the clang
object can be found: https://sourceware.org/bugzilla/attachment.cgi?id=13812
This seems to be a case where libabigail is optimizing the comparison a bit too
much by using the textual representative of the template value parameter rather
than following down into the type.
In the GCC DWARF you see:
[5673ec] class_type abbrev: 75
name (strp)
"__shared_ptr<abigail::comparison::corpus_diff, (__gnu_cxx::_Lock_policy)2>"
byte_size (data1) 16
decl_file (data1) shared_ptr_base.h (3)
decl_line (data2) 1052
decl_column (data1) 11
sibling (ref4) [567686]
[5673fa] inheritance abbrev: 56
type (ref4) [567333]
data_member_location (implicit_const) 0
accessibility (data1) public (1)
...
[56767b] template_value_parameter abbrev: 58
name (string) "_Lp"
type (ref4) [5ca886]
const_value (data1) 2
[5ca886] enumeration_type abbrev: 239
name (strp) "_Lock_policy"
encoding (data1) unsigned (7)
byte_size (implicit_const) 4
type (ref4) [51049d]
decl_file (data1) concurrence.h (83)
decl_line (data1) 49
decl_column (implicit_const) 8
sibling (ref4) [5ca8aa]
[5ca897] enumerator abbrev: 108
name (strp) "_S_single"
const_value (data1) 0
[5ca89d] enumerator abbrev: 108
name (strp) "_S_mutex"
const_value (data1) 1
[5ca8a3] enumerator abbrev: 108
name (strp) "_S_atomic"
const_value (data1) 2
While clang emits:
[3037c0] class_type abbrev: 14
calling_convention (data1) pass_by_reference (4)
name (strx2)
"__shared_ptr<abigail::comparison::corpus_diff, __gnu_cxx::_S_atomic>"
byte_size (data1) 16
decl_file (data1) shared_ptr_base.h (28)
decl_line (data2) 1052
[3037c8] template_type_parameter abbrev: 15
type (ref4) [384ce8]
name (strx1) "_Tp"
[3037ce] template_value_parameter abbrev: 92
type (ref4) [37737f]
name (strx2) "_Lp"
default_value (flag_present) yes
const_value (sdata) 2 (2)
...
[37737f] enumeration_type abbrev: 175
type (ref4) [384331]
name (strx1) "_Lock_policy"
byte_size (data1) 4
decl_file (data1) concurrence.h (3)
decl_line (data1) 49
[377389] enumerator abbrev: 176
name (strx1) "_S_single"
const_value (udata) 0
[37738d] enumerator abbrev: 176
name (strx1) "_S_mutex"
const_value (udata) 1
[377391] enumerator abbrev: 176
name (strx1) "_S_atomic"
const_value (udata) 2
It looks to me like libabigail is relying on the class name when comparing the
template instantiation rather than actually comparing the template value
parameters. This confuses libabigail into believing the template instantiation
is difference when it is in fact the same.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug default/28664] misinterpretation of default template instantiation naming idioms.
2021-12-07 0:50 [Bug default/28664] New: misinterpretation of default template instantiation naming idioms woodard at redhat dot com
@ 2021-12-07 0:53 ` woodard at redhat dot com
0 siblings, 0 replies; 2+ messages in thread
From: woodard at redhat dot com @ 2021-12-07 0:53 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=28664
Ben Woodard <woodard at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |27019
Referenced Bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=27019
[Bug 27019] BUILD metabug
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-12-07 0:53 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-07 0:50 [Bug default/28664] New: misinterpretation of default template instantiation naming idioms woodard at redhat dot com
2021-12-07 0:53 ` [Bug default/28664] " woodard at redhat dot com
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).