Hi!
On 2023-04-12 1:18 p.m., Jakub Jelinek wrote:
> On Wed, Apr 12, 2023 at 01:05:14PM +0100, Pedro Alves wrote:
>>> I thought Ben has posted the details.
>>> In memory they look the same as 0 based arrays, but they often have
>>> different calling conventions (argument passing, returning), they s
On 2023-04-06 12:03 p.m., Jakub Jelinek via Dwarf-discuss wrote:
> In GCC, one uses vector_size attribute to define such types, so say
> typedef int V __attribute__((vector_size (64)));
> where 64 is number of bytes the vector has (so for 4 byte int it is 16
> elements).
> I think Clang supports b
On 2023-04-06 1:03 p.m., Jakub Jelinek via Dwarf-discuss wrote:
> On Thu, Apr 06, 2023 at 07:52:32AM -0400, Ron Brender wrote:
>>> And we almost certainly want to allow vectors on DWARF expression stack;
>>
>> What is so special about vector types in this regard. What do you have
>> against values
On 2023-04-06 12:03 p.m., Jakub Jelinek via Dwarf-discuss wrote:
>> define fixed-length vectors as special built-in types or is the goal to
>> support
>> arbitrary vector lengths?
>>
>> It might be good to maintain an upper limit on the size of a stack entry.
> I think it is better if consumers si
On 2023-04-04 11:09 a.m., Pedro Alves wrote:
> On 2023-04-04 12:22 a.m., Kyle Huey wrote:
>> On Mon, Apr 3, 2023 at 12:42 PM Pedro Alves via Dwarf-discuss
>> mailto:dwarf-discuss@lists.dwarfstd.org>>
>> wrote:
>>
>> Hi Ben,
>>
>> On
On 2023-04-04 12:22 a.m., Kyle Huey wrote:
> On Mon, Apr 3, 2023 at 12:42 PM Pedro Alves via Dwarf-discuss
> mailto:dwarf-discuss@lists.dwarfstd.org>>
> wrote:
>
> Hi Ben,
>
> On 2023-03-24 6:19 p.m., Ben Woodard via Dwarf-discuss wrote:
>
> &
Hi Ben,
On 2023-03-24 6:19 p.m., Ben Woodard via Dwarf-discuss wrote:
> I will admit that in its current state it is a work in progress. My original
> intent was to simply
> codify the existing behavior as implemented by GCC and LLVM (and probably
> other compilers) moving it
> from a vendor at
On 2023-03-31 4:29 a.m., Ben Woodard wrote:
>> On Mar 30, 2023, at 1:27 PM, Pedro Alves wrote:
>>
>> On 2023-03-29 8:55 p.m., Ben Woodard via Dwarf-discuss wrote:
>>> *void f( float *a){}**
>>> *[30] pointer_type abbrev: 5
>>>byte_size(implicit_const) 8
>>>typ
On 2023-03-30 9:26 p.m., Pedro Alves wrote:
> So teaching DWARF to specify the location of the return value is actually
> orthogonal
> here -- we need to be able to distinguish regular C array from vector arrays
> for
> other reasons too, specifically, the types are different at the language
> l
On 2023-03-29 8:55 p.m., Ben Woodard via Dwarf-discuss wrote:
>
> On 3/28/23 13:17, David Blaikie wrote:
...
>> What DWARF should be used to describe the type of 'a'? And how does
>> this encoding scale to all the other similar intrinsic types?
>>
> As a person who has spent a crazy amount of time
On 2022-05-06 18:11, Lancelot SIX via Dwarf-Discuss wrote:
> 2 - Unnamed zero sized bitfield
>
> Another case we met is related to unnamed fields with a size of 0 bits.
> Such field is defined in the c++ standard as (in 9.6 Bit-Fields):
>
> > As a special case, an unnamed bit-field with a width
On 2022-05-09 22:41, Robinson, Paul wrote:
>> Pedro Alves wrote:
>> On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote:
>>> So my suggestion is to file a bug report with CLANG, requesting they
>> correct their DWARF output to reflect all details needed
>>> by your language.
>>
>> An issue her
On 2022-05-06 21:08, Todd Allen via Dwarf-Discuss wrote:
> I'm agreeing with Michael that describing the unnamed bitfield seems dubious.
> If it does impact the ABI, I'm wondering if that impact is indirect: that is,
> the presence of this 0-width bit field changes an attribute of the next field,
>
Hi,
(using my subscribed gmail address until my main address, CCed, is approved to
also join the list.)
On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote:
> It seems to me that the problem here is not so much in the DWARF standard, as
> in the DWARF that is produced.
>
> The DWARF repre
Hi there!
On 7/31/20 1:17 AM, Tye, Tony via Dwarf-Discuss wrote:
> For optimized code involving multiple address spaces it is possible to run
> into cases where the location of a source language variable requires multiple
> address spaces. For example, a source variable may be optimized and diff
15 matches
Mail list logo
