On 8/4/05, Shaun Jackman [EMAIL PROTECTED] wrote:
Are you using an x86 host and an arm target?
Actually no, my major concern at the time was the large quantity of
legacy code with packed structures that we have on an embedded linux
x86 system. I was just testing that we didn't have an issue
On 8/5/05, Carl Whitwell [EMAIL PROTECTED] wrote:
On 8/4/05, Shaun Jackman [EMAIL PROTECTED] wrote:
Are you using an x86 host and an arm target?
Actually no, my major concern at the time was the large quantity of
legacy code with packed structures that we have on an embedded linux
x86
On 8/4/05, Carl Whitwell [EMAIL PROTECTED] wrote:
Hi,
thought I'd drop you a mail, would put it on gcc mailing list but
haven't got time to work out how to send it there at this moment.
The gcc mailing list is [EMAIL PROTECTED]
All testing here is done on x86 processors using gcc
On 8/4/05, Shaun Jackman [EMAIL PROTECTED] wrote:
The gcc mailing list is [EMAIL PROTECTED]
I'd say it's gcc@gcc.gnu.org though...
--
Cheers,
/ChJ
Shaun == Shaun Jackman [EMAIL PROTECTED] writes:
Shaun On 8/2/05, Paul Koning [EMAIL PROTECTED] wrote:
It sounds like the workaround is to avoid memcpy, and just use
variable assignment. Alternatively, cast the pointers to char*,
which should force memcpy to do the right thing. Ugh.
On Wed, Aug 03, 2005 at 12:15:05PM -0600, Shaun Jackman wrote:
I'm not sure I understood the last line. s is a structure, and its
address is aligned. How would you pass it to memcpy, and why would it
generate an unaligned copy?
In the example I was replying to, S is a pointer to a structure,
Richard Henderson [EMAIL PROTECTED] writes:
On Tue, Aug 02, 2005 at 01:45:01PM -0700, Ian Lance Taylor wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
Yes, this is a compiler bug in the expansion of memcpy, please file a
bug report. The solution is for the compiler to notice the
Original Message
From: Shaun Jackman
Sent: 02 August 2005 18:33
In a typical Ethernet/IP ARP header the source IP address is
unaligned. Instead of using...
out-srcIPAddr = in-dstIPAddr;
... I used...
memcpy(out-srcIPAddr, in-dstIPAddr, sizeof(uint32_t));
... to account
Shaun Jackman [EMAIL PROTECTED] writes:
In a typical Ethernet/IP ARP header the source IP address is
unaligned. Instead of using...
out-srcIPAddr = in-dstIPAddr;
... I used...
memcpy(out-srcIPAddr, in-dstIPAddr, sizeof(uint32_t));
... to account for the unaligned destination.
One of the things that continues to baffle me (and my colleagues) is
the bizarre way in which attributes such as packed work when applied
to structs.
It would be natural to assume, as Shaun did, that marking a struct
packed (or, for that matter, packed,aligned(2)) would apply that
attribute to
On 8/2/05, Paul Koning [EMAIL PROTECTED] wrote:
One of the things that continues to baffle me (and my colleagues) is
the bizarre way in which attributes such as packed work when applied
to structs.
It would be natural to assume, as Shaun did, that marking a struct
packed (or, for that
Original Message
From: Shaun Jackman
Sent: 02 August 2005 20:26
On 8/2/05, Paul Koning [EMAIL PROTECTED] wrote:
One of the things that continues to baffle me (and my colleagues) is
the bizarre way in which attributes such as packed work when applied
to structs.
It would be natural
Dave == Dave Korn [EMAIL PROTECTED] writes:
Dave Original Message
From: Shaun Jackman Sent: 02 August 2005 20:26
On 8/2/05, Paul Koning [EMAIL PROTECTED] wrote:
One of the things that continues to baffle me (and my colleagues)
is the bizarre way in which attributes such as
On 8/2/05, Dave Korn [EMAIL PROTECTED] wrote:
There are two separate issues here:
1) Is the base of the struct aligned to the natural alignment, or can the
struct be based at any address
The base of the struct is aligned to the natural alignment, four bytes
in this case.
2) Is there
Shaun == Shaun Jackman [EMAIL PROTECTED] writes:
2) Is there padding between the struct members to maintain their
natural alignments (on the assumption that the struct's base
address is aligned.)
Shaun There is no padding. The structure is defined as
Shaun __attribute__((packed)) to
On Aug 2, 2005, at 1:37 PM, Andrew Pinski wrote:
No it is not,
:-) Ah, yes, the old, we don't have pointers to unaligned types
problem... anyway, we can at least agree that this is a gapping hole
people can drive trucks though in the type system, but I'm still
claiming it isn't a
On Tue, Aug 02, 2005 at 02:29:44PM -0700, Mike Stump wrote:
On Aug 2, 2005, at 1:45 PM, Ian Lance Taylor wrote:
That argument doesn't make sense to me. memcpy takes a void*
argument, which has no presumed alignment.
The memcpy builtin uses the static type of the actual argument
(before
On Tue, Aug 02, 2005 at 04:07:00PM -0600, Shaun Jackman wrote:
On 8/2/05, Joe Buck [EMAIL PROTECTED] wrote:
I suppose we could make on an unaligned project return a void*. That
isn't really right, but it would at least prevent the cases that we know
don't work from compiling.
That
On 8/2/05, Joe Buck [EMAIL PROTECTED] wrote:
I suppose we could make on an unaligned project return a void*. That
isn't really right, but it would at least prevent the cases that we know
don't work from compiling.
That sounds like a dangerous idea only because I'd expect...
int *p =
19 matches
Mail list logo
