> BTW in Ada if one uses address clause to overlay a 16 character string
> and a 4 4-byte integer array (both aliased) which is then accessed what
> can we expect GCC-wise? Are we safe from aliasing related optimizations?
Yes, we use a big hammer to make sure 'Address is immune to these issues.
-
On Sun, 2010-01-10 at 15:46 +0100, Eric Botcazou wrote:
> > The aliasing rules treat "char" specially because char is a bit like a
> > "poor main's void".
>
> Not symmetrically though, only for the type of the lvalue expression used to
> access the object (C99 6.5.7).
BTW in Ada if one uses addr
Hi,
On Sun, 10 Jan 2010, Dave Korn wrote:
> Ok. So if I had four ints, and I wanted to cast the pointers to char
> and compare them as 16 chars, that would be OK, because the chars would
> alias the ints; but in this case, where they started as chars and I cast
> them to ints, those ints do
On Sun, Jan 10, 2010 at 06:24:14PM +, Dave Korn wrote:
> Eric Botcazou wrote:
> >> The aliasing rules treat "char" specially because char is a bit like a
> >> "poor main's void".
> >
> > Not symmetrically though, only for the type of the lvalue expression used
> > to
> > access the object (C
Eric Botcazou wrote:
>> Yes, fair enough; but properties can commute just as much as operators
>> can (although it's perhaps less intuitively surprising when they don't).
>
> To be picky, binary operators are commutative (or not), binary relations are
> symmetric (or not).
Ah, I wasn't awar
> Yes, fair enough; but properties can commute just as much as operators
> can (although it's perhaps less intuitively surprising when they don't).
To be picky, binary operators are commutative (or not), binary relations are
symmetric (or not).
--
Eric Botcazou
Andreas Schwab wrote:
> Dave Korn writes:
>
>> Andreas, you wrote: "Aliasing is not symmetric". To be precise, we're
>> saying it's not commutative here; that (A aliases B) does not imply (B
>> aliases
>> A)? I don't think I've ever heard it expressed that explicitly before.
>
> Aliasing is
Dave Korn writes:
> Andreas, you wrote: "Aliasing is not symmetric". To be precise, we're
> saying it's not commutative here; that (A aliases B) does not imply (B aliases
> A)? I don't think I've ever heard it expressed that explicitly before.
Aliasing is not an operator, it's a property of
Eric Botcazou wrote:
>> The aliasing rules treat "char" specially because char is a bit like a
>> "poor main's void".
>
> Not symmetrically though, only for the type of the lvalue expression used to
> access the object (C99 6.5.7).
>
Ok. So if I had four ints, and I wanted to cast the pointe
On Sun, Jan 10, 2010 at 08:58:47AM -0800, Patrick Horgan wrote:
> Andrew Haley wrote:
> > On 01/10/2010 12:39 PM, Andreas Schwab wrote:
> >
> >> Andrew Haley writes:
> >>
> >>
> >>> Why do you say the effective type is different?
> >>>
> >> The object type is uint8_t, but accessed a
Andrew Haley wrote:
> On 01/10/2010 02:39 PM, Paul Koning wrote:
>>> ...
>>> typedef unsigned char uint8_t;
>>> typedef unsigned int uint32_t;
>>>
>>> struct in6_addr
>>> {
>>> uint8_t __s6_addr[16];
>>> };
>>>
>>> static inline int
>>> address_in_use (unsigned char *a, struct in6_addr *in6)
>>>
Patrick Horgan wrote:
> Andrew Haley wrote:
>> On 01/10/2010 12:39 PM, Andreas Schwab wrote:
>>
>>> Andrew Haley writes:
>>>
>>>
Why do you say the effective type is different?
>>> The object type is uint8_t, but accessed as uint32_t. That is
>>> undefined.
>>>
>>
>> U
On Sun, 10 Jan 2010, Patrick Horgan wrote:
> But in the new compilers it's an integer type, not a character type--from the
> spec:
signed char is a signed integer type, and unsigned char is an unsigned
integer type. (char is neither, although it behaves the same as one of
signed char and unsig
On 01/10/2010 04:58 PM, Patrick Horgan wrote:
> Andrew Haley wrote:
>> On 01/10/2010 12:39 PM, Andreas Schwab wrote:
>>
>>> Andrew Haley writes:
>>>
Why do you say the effective type is different?
>>> The object type is uint8_t, but accessed as uint32_t. That is
>>> undefined.
Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I understand it. That
On 01/10/2010 02:39 PM, Paul Koning wrote:
>> ...
>> typedef unsigned char uint8_t;
>> typedef unsigned int uint32_t;
>>
>> struct in6_addr
>> {
>> uint8_t __s6_addr[16];
>> };
>>
>> static inline int
>> address_in_use (unsigned char *a, struct in6_addr *in6)
>> {
>> if const uint32_t *)(a
> The aliasing rules treat "char" specially because char is a bit like a
> "poor main's void".
Not symmetrically though, only for the type of the lvalue expression used to
access the object (C99 6.5.7).
--
Eric Botcazou
> ...
> typedef unsigned char uint8_t;
> typedef unsigned int uint32_t;
>
> struct in6_addr
> {
> uint8_t __s6_addr[16];
> };
>
> static inline int
> address_in_use (unsigned char *a, struct in6_addr *in6)
> {
> if const uint32_t *)(a))[0]
> == ((const uint32_t *)(in6->__
> ...
> >> The object type is uint8_t, but accessed as uint32_t. That is
> >> undefined.
> >
> > Unless uint8_t is a character type, as I understand it.
>
> In which way does it make a difference? For aliasing consideration,
> only the type of access matters.
The aliasing rules treat "char" spe
Andrew Haley writes:
> On 01/10/2010 12:39 PM, Andreas Schwab wrote:
>> Andrew Haley writes:
>>
>>> Why do you say the effective type is different?
>>
>> The object type is uint8_t, but accessed as uint32_t. That is
>> undefined.
>
> Unless uint8_t is a character type, as I understand it.
In
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Why do you say the effective type is different?
>
> The object type is uint8_t, but accessed as uint32_t. That is
> undefined.
Unless uint8_t is a character type, as I understand it. That is
clearly the assumption on wh
Andrew Haley writes:
> Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something co
On 01/10/2010 10:30 AM, Andreas Schwab wrote:
> Dave Korn writes:
>
>> Is that really right? The type of the pointer (in6->__s6_addr) that we're
>> casting is unsigned char *, so shouldn't it already alias everything anyway
>> and dereferencing it be allowed, like it is for the casted (a)? I'
Dave Korn writes:
> Is that really right? The type of the pointer (in6->__s6_addr) that we're
> casting is unsigned char *, so shouldn't it already alias everything anyway
> and dereferencing it be allowed, like it is for the casted (a)? I'll file a
> PR if so. (I can't pretend I find the la
Hello,
I don't want to reopen the long-rumbling discussion about what gcc ought to
/want/ to do; I'd just like to know if warning in this case is indeed what it
wants to do. The standard definition of IN6_ARE_ADDR_EQUAL looks a bit like
this:
#define IN6_ARE_ADDR_EQUAL(a, b) \
((
25 matches
Mail list logo
