On 06/26/2015 01:56 AM, Richard Biener wrote:
On Thu, Jun 25, 2015 at 7:03 PM, Jeff Law wrote:
On 06/09/2015 10:20 AM, Eric Botcazou wrote:
Because some folks don't want to audit their code to where to add
byteswaps.
I am serious people have legacy big-endian code they want to run little
endi
> Well - they need a full audit anyway to slap those endian attributes on the
> appropriate structures. We are not, after all, introducing a -fbig-endian
> switch.
Sort of though, the Ada compiler has a pragma to tag all record types with an
SSO attribute (although I personally don't like it muc
On Thu, Jun 25, 2015 at 7:03 PM, Jeff Law wrote:
> On 06/09/2015 10:20 AM, Eric Botcazou wrote:
>>>
>>> Because some folks don't want to audit their code to where to add
>>> byteswaps.
>>> I am serious people have legacy big-endian code they want to run little
>>> endian. There is a reason this is
On 06/09/2015 10:20 AM, Eric Botcazou wrote:
Because some folks don't want to audit their code to where to add byteswaps.
I am serious people have legacy big-endian code they want to run little
endian. There is a reason this is around in the first place. Developers are
lazy.
That's a little rou
On 06/09/2015 04:52 AM, Richard Biener wrote:
On Tue, Jun 9, 2015 at 12:39 PM, Eric Botcazou wrote:
What's the reason to not expose the byte swapping operations earlier, like
on GIMPLE? (or even on GENERIC?)
That would be too heavy, every load and store in GENERIC/GIMPLE would have an
associ
On Mon, 2015-06-08 at 16:04 +0200, Andreas Schwab wrote:
> Mark Wielaard writes:
>
> > I am sorry, I normally use the git mirror and this branch doesn't seem
> > to be there and I don't know how to get the svn branch.
>
> http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/remotes/scalar-storage
> Because some folks don't want to audit their code to where to add byteswaps.
> I am serious people have legacy big-endian code they want to run little
> endian. There is a reason this is around in the first place. Developers are
> lazy.
That's a little rough, but essentially correct in our exper
> Why would you want to support this on bitfields ... (/me runs away).
This was the only supported case in the original specification. :-)
--
Eric Botcazou
> On Jun 9, 2015, at 7:53 PM, Richard Biener wrote:
>
> On Tue, Jun 9, 2015 at 1:12 PM, Eric Botcazou wrote:
>>> Yes, but I'd expect them to be optimized away (well, hopefully).
>>
>> OK, but you cannot reasonably expose everything in GENERIC/GIMPLE, for
>> example
>> the mask-and-shift op
On Tue, Jun 9, 2015 at 1:12 PM, Eric Botcazou wrote:
>> Yes, but I'd expect them to be optimized away (well, hopefully).
>
> OK, but you cannot reasonably expose everything in GENERIC/GIMPLE, for example
> the mask-and-shift operations to extract bitfields in reverse SSO, only the
> RTL expander h
> Yes, but I'd expect them to be optimized away (well, hopefully).
OK, but you cannot reasonably expose everything in GENERIC/GIMPLE, for example
the mask-and-shift operations to extract bitfields in reverse SSO, only the
RTL expander has the (quite complex) logic and I doubt you want to teach t
On Tue, Jun 9, 2015 at 12:39 PM, Eric Botcazou wrote:
>> What's the reason to not expose the byte swapping operations earlier, like
>> on GIMPLE? (or even on GENERIC?)
>
> That would be too heavy, every load and store in GENERIC/GIMPLE would have an
> associated byte swapping operation, although
> Anyway, the DWARF standard doesn't forbid using it on other kinds of DIEs
> and I think emitting it on DW_TAG_member would be natural.
Agreed.
> Not sure why you would want it on DW_TAG_array_type, the endianity for
> arrays should be specified on the element type, shouldn't it?
For the C fami
> What's the reason to not expose the byte swapping operations earlier, like
> on GIMPLE? (or even on GENERIC?)
That would be too heavy, every load and store in GENERIC/GIMPLE would have an
associated byte swapping operation, although you don't know if they will be
needed in the end. For examp
On Tue, Jun 9, 2015 at 12:33 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 12:17:49PM +0200, Eric Botcazou wrote:
>> > How is this represented in DWARF?
>>
>> This is not represented on the branch, because this cannot be done in pure
>> DWARF. DW_AT_endianity only applies to base types or st
On Tue, Jun 09, 2015 at 12:17:49PM +0200, Eric Botcazou wrote:
> > How is this represented in DWARF?
>
> This is not represented on the branch, because this cannot be done in pure
> DWARF. DW_AT_endianity only applies to base types or stand-alone objects and
> we would need it for DW_TAG_member
> How is this represented in DWARF?
This is not represented on the branch, because this cannot be done in pure
DWARF. DW_AT_endianity only applies to base types or stand-alone objects and
we would need it for DW_TAG_member (and even DW_TAG_array_type in Ada). But
this could easily be implemen
> Oh and I see a case where we want to remove byteswaps at IPA level. If
> we can see the variable value does not escape.
That should be relatively easily doable, although I'm a little skeptical of
its practical usefulness.
--
Eric Botcazou
Mark Wielaard writes:
> I am sorry, I normally use the git mirror and this branch doesn't seem
> to be there and I don't know how to get the svn branch.
http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/remotes/scalar-storage-order
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG K
On Mon, 2015-06-08 at 10:05 +0200, Eric Botcazou wrote:
> It implements an attribute (C/C++/Ada only) that makes it possible to specify
> the storage order (aka endianness) of scalar components of aggregate types;
> for example, you can declare a structure with big-endian SSO containing only
> sc
On Mon, Jun 8, 2015 at 10:05 AM, Eric Botcazou wrote:
> Hi,
>
> I'd like to propose merging the scalar-storage-order branch that I have been
> maintaining for a couple of years into mainline. Original announcement at:
> https://gcc.gnu.org/ml/gcc/2013-05/msg00249.html
>
> It implements an attri
On Mon, Jun 8, 2015 at 4:19 PM, Andrew Pinski wrote:
> On Mon, Jun 8, 2015 at 4:05 PM, Eric Botcazou wrote:
>> Hi,
>>
>> I'd like to propose merging the scalar-storage-order branch that I have been
>> maintaining for a couple of years into mainline. Original announcement at:
>> https://gcc.gnu
On Mon, Jun 8, 2015 at 4:05 PM, Eric Botcazou wrote:
> Hi,
>
> I'd like to propose merging the scalar-storage-order branch that I have been
> maintaining for a couple of years into mainline. Original announcement at:
> https://gcc.gnu.org/ml/gcc/2013-05/msg00249.html
>
> It implements an attrib
Hi,
I'd like to propose merging the scalar-storage-order branch that I have been
maintaining for a couple of years into mainline. Original announcement at:
https://gcc.gnu.org/ml/gcc/2013-05/msg00249.html
It implements an attribute (C/C++/Ada only) that makes it possible to specify
the stora
24 matches
Mail list logo
