> Yes the following is a decent workaround:
> upal_u32be_t tempb;
> memcpy (&tempb, &u, sizeof(uint32_t));
> asm("":"+m"(tempb));
> uint32_t bu = tempb.val;
OK, let me try to do the same in the compiler then.
--
Eric Botcazou
On Wed, Apr 22, 2020 at 11:41 PM Eric Botcazou wrote:
>
> > What if we had this:
> > uint32_t u = 0x12345678;
> > upal_u32be_t tempb;
> > memcpy (&tempb, &u, sizeof(uint32_t));
> > uint32_t bu = tempb.val;
> >
> > Is that valid? We still run into the wrong code with the above case
> What if we had this:
> uint32_t u = 0x12345678;
> upal_u32be_t tempb;
> memcpy (&tempb, &u, sizeof(uint32_t));
> uint32_t bu = tempb.val;
>
> Is that valid? We still run into the wrong code with the above case.
> memcpy here should be considered a byte-by-byte copy and therefor
On Wed, Apr 22, 2020 at 1:14 PM Eric Botcazou wrote:
>
> > I notice this statement in the documentation:
> > Moreover, the use of type punning or aliasing to toggle the storage
> > order is not supported; that is to say, a given scalar object cannot
> > be accessed through distinct types that assi
> I notice this statement in the documentation:
> Moreover, the use of type punning or aliasing to toggle the storage
> order is not supported; that is to say, a given scalar object cannot
> be accessed through distinct types that assign a different storage
> order to it.
> --- CUT ---
> But I am n
Hi all (and Eric),
I have a question about scalar_storage_order and support of type
punning between types that have different byte order.
Take:
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
#define __big_endian__ scalar_storage_order("big-endian")
#define __little_endian__ scalar
