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
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/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
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 g
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
>> > No it is not, once you take the address (which should be
>> rejected), it > is of type "unsigned int *" and not unaligned
>> variable, passing it to > memcpy assumes the type alignment is the
>> natural alignment.
>>
>> T
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
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,
Original Message
>From: Shaun Jackman
>Sent: 03 August 2005 19:15
> On 8/3/05, Richard Henderson <[EMAIL PROTECTED]> wrote:
>> It is nevertheless correct. Examine all of the parts of the expression.
>>
>> In particular, "&s->b". What type does it have? In an ideal world, it
>> would be
On 8/3/05, Richard Henderson <[EMAIL PROTECTED]> wrote:
> It is nevertheless correct. Examine all of the parts of the expression.
>
> In particular, "&s->b". What type does it have? In an ideal world, it
> would be "pointer to unaligned integer". But we have no such type in
> our type system,
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 memory
> > > alignment of the destinatio
> "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
On 8/2/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> operator. None of these examples produce an unaligned load:
I should clarify the wording I'm using here. By "an unaligned load" I
mean code to safely load from an unaligned pointer.
Cheers,
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.
Casting to void* does not work either. gcc keeps the alignm
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.
I swear originally, back in the gcc 2.95 days, I used memcp
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
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.
>
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
> (b
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 conversion to void*), to gain hints about the alignments of
the
On Tue, Aug 02, 2005 at 02:04:16PM -0700, Mike Stump wrote:
> Shaun, want to do up an entry in the manual describing this? We have
> known about this for years and years, but, we don't do a good job
> communicating it to users. Essentially, & doesn't work as one would
> expect on unaligned
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 featur
> "Andrew" == 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
>> memory alignment of the destination and `do-the-right-thing' when
>> it isn't aligned.
Andrew
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 memory
> > alignment of the destination and `do-the-right-thing' when it isn't
> > aligned.
>
> No it is not, o
>
> On Aug 2, 2005, at 1:15 PM, Shaun Jackman wrote:
> > There is no padding. The structure is defined as
> > __attribute__((packed)) to explicitly remove the padding. The result
> > is that gcc knows the unaligned four byte member is at an offset of
> > two bytes from the base of the struct, but
On Aug 2, 2005, at 1:15 PM, Shaun Jackman wrote:
There is no padding. The structure is defined as
__attribute__((packed)) to explicitly remove the padding. The result
is that gcc knows the unaligned four byte member is at an offset of
two bytes from the base of the struct, but uses a four byte lo
> "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__(
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 t
> "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 at
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
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
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
On 8/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> In order for anyone to answer your questions about the alignment of
> various types in a struct, don't you think you should perhaps have told us a
> little about what those types actually are and how the struct is laid out?
Of course, my apologie
On Aug 2, 2005, at 10:32 AM, Shaun Jackman wrote:
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 destinati
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 de
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));
> ...
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. This worked until gcc 4,
which now gener
35 matches
Mail list logo
