From: "woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/28664] New: misinterpretation of default template instantiation naming idioms.
Date: Tue, 07 Dec 2021 00:50:26 +0000 [thread overview]
Message-ID: <bug-28664-9487@http.sourceware.org/bugzilla/> (raw)
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.
next reply other threads:[~2021-12-07 0:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 0:50 woodard at redhat dot com [this message]
2021-12-07 0:53 ` [Bug default/28664] " woodard at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-28664-9487@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=libabigail@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).