From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libabigail-return-722-listarch-libabigail=sourceware.org@sourceware.org>
Received: (qmail 114423 invoked by alias); 5 Jul 2016 13:04:40 -0000
Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:libabigail@sourceware.org>
List-Help: <mailto:libabigail-help@sourceware.org>
List-Subscribe: <mailto:libabigail-subscribe@sourceware.org>
Sender: libabigail-owner@sourceware.org
Received: (qmail 114276 invoked by uid 48); 5 Jul 2016 13:04:27 -0000
From: "woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/20194] Fail to recognize void type represented by
 DW_TAG_base_type
Date: Fri, 01 Jan 2016 00:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: libabigail
X-Bugzilla-Component: default
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: critical
X-Bugzilla-Who: woodard at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: dodji at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-20194-9487-oMRbcg1nrZ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20194-9487@http.sourceware.org/bugzilla/>
References: <bug-20194-9487@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2016-q3/txt/msg00017.txt.bz2

https://sourceware.org/bugzilla/show_bug.cgi?id=3D20194

--- Comment #8 from Ben Woodard <woodard at redhat dot com> ---
Much improved!!!

But there still seems to be a much rarer corner case with intel.

 13953]    subprogram
             decl_line            (data2) 2594
             decl_column          (data1) 1
             decl_file            (data1) 20
             type                 (ref4) [   505]
             prototyped           (flag)
             name                 (strp) "malloc_usable_size"
             MIPS_linkage_name    (strp) "malloc_usable_size"
             low_pc               (addr) +0x000000000000c1d0
<malloc_usable_size>
             high_pc              (addr) +0x000000000000c340
<jemalloc_constructor>
             external             (flag)
 [ 13976]      formal_parameter
               decl_line            (data2) 2594
               decl_column          (data1) 56
               decl_file            (data1) 20
               type                 (ref4) [   52f]
               name                 (string) "ptr"
               location             (block1)
                [   0] reg5


 [   52f]    pointer_type
             type                 (ref4) [   534]
 [   534]    const_type
             type                 (ref4) [   539]
 [   539]    base_type
             byte_size            (data1) 0
             encoding             (data1) signed (5)
             name                 (strp) "void"

Arguably this is a compiler bug with Intel and that should be considered I
think. There is nothing in the source code that suggests any sort of const-=
ness
and so the fact that the compiler inserts it here in the type for the param=
eter
is incorrect.

However, should we consider that to be an ABI relevant artifact?
I can go either way on that. I will be happy to submit a bug to intel regar=
ding
this.

--=20
You are receiving this mail because:
You are on the CC list for the bug.