> handle_pragma_scalar_storage_order does not check c_dialect_cxx, so it
> will not issue a warning for C++ even though the pragma is effectively
> ignored.
Indeed, unlike for the attribute, will fix, thanks.
--
Eric Botcazou
* Eric Botcazou:
>> By the way, what happened to the C++ bits? I think the c-family patch
>> which went in assumes that the C++ bits are there as well.
>
> I don't really understand what you mean by "assume" here,
handle_pragma_scalar_storage_order does not check c_dialect_cxx, so it
will not is
> By the way, what happened to the C++ bits? I think the c-family patch
> which went in assumes that the C++ bits are there as well.
I don't really understand what you mean by "assume" here, but the C++ bits
were incomplete and never got reviewed; I can resurrect them if there is some
interest
* Eric Botcazou:
>> To support applications that assume big-endian memory layout on little-
>> endian systems, I'm considering adding support for reversing the
>> storage order to GCC.
>
> That was also the goal of the scalar_storage_order attribute.
By the way, what happened to the C++ bits? I
On 14/09/17 11:30, Eric Botcazou wrote:
>> I seem to remember it being able to attach a big-endian or little-endian
>> label to any individual variable (rather than a type), which could be a
>> scaler rather than a struct. So it was a bit more flexible than gcc.
>
> Well, the only thing I see in
> I seem to remember it being able to attach a big-endian or little-endian
> label to any individual variable (rather than a type), which could be a
> scaler rather than a struct. So it was a bit more flexible than gcc.
Well, the only thing I see in the documentation for "Byte Ordering" is the
r
On 14/09/17 08:22, Eric Botcazou wrote:
>> And there are lots of other problems, I don't have time to document them
>> all, or even remember them all. Personally, I think you are better off
>> trying to fix the application to make it more portable. Fixing the
>> compiler is not a magic solution t
On 12/09/17 20:56, Michael Meissner wrote:
> On Tue, Sep 12, 2017 at 05:26:29PM +0200, David Brown wrote:
>> On 12/09/17 16:15, paul.kon...@dell.com wrote:
>>>
On Sep 12, 2017, at 5:32 AM, Jürg Billeter
wrote:
Hi,
To support applications that assume big-endian memory
> And there are lots of other problems, I don't have time to document them
> all, or even remember them all. Personally, I think you are better off
> trying to fix the application to make it more portable. Fixing the
> compiler is not a magic solution to the problem that is any easier than
> fixi
Jürg Billeter writes:
>
> I don't. The idea is to reverse scalar storage order for the whole
> userspace process and then add byte swapping to the Linux kernel when
> accessing userspace memory. This keeps userspace memory consistent
> with regards to endianness, which should lead to high compatib
On Wed, 13 Sep 2017, Jim Wilson wrote:
> Intel has support for this in icc. It took about 5 years for a small team to
And allegedly has patents in this area.
--
Joseph S. Myers
jos...@codesourcery.com
On 09/12/2017 02:32 AM, Jürg Billeter wrote:
To support applications that assume big-endian memory layout on little-
endian systems, I'm considering adding support for reversing the
storage order to GCC. In contrast to the existing scalar storage order
support for structs, the goal is to reverse
On Wed, 2017-09-13 at 13:08 +, paul.kon...@dell.com wrote:
> > On Sep 13, 2017, at 5:51 AM, Jürg Billeter
> > wrote:
> > To support existing large code bases, the goal is to reverse storage
> > order for all scalars, not just (selected) structs/unions. Also need to
> > support taking the addr
> Was this considered significantly more complex because of the need to
> discriminate between native and reverse order? Or do you expect similar
> complexity even if this is not required (see my comment below)?
The former.
> I don't. The idea is to reverse scalar storage order for the whole
> us
> On Sep 13, 2017, at 5:51 AM, Jürg Billeter
> wrote:
>
> On Tue, 2017-09-12 at 08:52 -0700, H.J. Lu wrote:
>> Can you use __attribute__ ((scalar_storage_order)) in GCC 7?
>
> To support existing large code bases, the goal is to reverse storage
> order for all scalars, not just (selected) stru
On Tue, 2017-09-12 at 08:52 -0700, H.J. Lu wrote:
> Can you use __attribute__ ((scalar_storage_order)) in GCC 7?
To support existing large code bases, the goal is to reverse storage
order for all scalars, not just (selected) structs/unions. Also need to
support taking the address of a scalar field
On Tue, 2017-09-12 at 21:46 +0200, Eric Botcazou wrote:
> > In contrast to the existing scalar storage order support for structs, the
> > goal is to reverse the storage order for all memory operations to achieve
> > maximum compatibility with the behavior on big-endian systems, as far as
> > observ
> To support applications that assume big-endian memory layout on little-
> endian systems, I'm considering adding support for reversing the
> storage order to GCC.
That was also the goal of the scalar_storage_order attribute.
> In contrast to the existing scalar storage order support for structs
On Tue, Sep 12, 2017 at 05:26:29PM +0200, David Brown wrote:
> On 12/09/17 16:15, paul.kon...@dell.com wrote:
> >
> >> On Sep 12, 2017, at 5:32 AM, Jürg Billeter
> >> wrote:
> >>
> >> Hi,
> >>
> >> To support applications that assume big-endian memory layout on little-
> >> endian systems, I'm c
On Tue, Sep 12, 2017 at 2:32 AM, Jürg Billeter
wrote:
> Hi,
>
> To support applications that assume big-endian memory layout on little-
> endian systems, I'm considering adding support for reversing the
> storage order to GCC. In contrast to the existing scalar storage order
> support for structs,
On 12/09/17 16:15, paul.kon...@dell.com wrote:
>
>> On Sep 12, 2017, at 5:32 AM, Jürg Billeter
>> wrote:
>>
>> Hi,
>>
>> To support applications that assume big-endian memory layout on little-
>> endian systems, I'm considering adding support for reversing the
>> storage order to GCC. In contras
> On Sep 12, 2017, at 5:32 AM, Jürg Billeter
> wrote:
>
> Hi,
>
> To support applications that assume big-endian memory layout on little-
> endian systems, I'm considering adding support for reversing the
> storage order to GCC. In contrast to the existing scalar storage order
> support for st
22 matches
Mail list logo
