Feature request concerning bitwise operations

[Wen Li]

On x86 processors, I think bitwise operators should be optimized for
individual bit accesses, which should be converted to BT instructions.

For example:

x |= 1<

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Erik Trulsson]

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 (C99 6.5.7).
> > 
> 
>   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 don't alias against the original chars.  Is that an accurate 
> precis?
> 
>   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.

I think you (and several other people) are actually conflating two
separate concepts here.  One is aliasing, which can be described as "when
can two different lvalues actually refer to the same object".
The other is if it is actually allowed to access a particular object
through a given lvalue.
These two concepts partially overlap, but they are not the same.
I would say that aliasing actually is symmetric such that if (A aliases
B) then (B aliases A), but that does not necessarily mean that it is
safe to access the underlying object through both A and B.
(This just depends on how one defines the term "aliasing". Note that
aliasing is only defined indirectly in the C standard, and the term
itself only occurs in non-normative text.)

Take for example the following situation:

 float f=0;
 int main(void)
{
char *cp = (char *)&f;
float *fp = &f;

*cp = 42;

*fp;

return 0;
}

Here the lvalues '*cp' and '*fp' clearly alias each other, in that they
both refer to the object 'f'.  Section 6.5p7 does not disallow access
to 'f' either through '*fp' (which has the same type as the effective
type of the object, i.e. 'float') or through '*cp' (whose type is a
character type.)  (Also note that 6.5p7 is irrelevant when storing a
value into '*cp' since that section only talks about accessing the
stored value of an object, i.e. reading from it.)

However the access to 'f' through the lvalue '*fp' still invokes
undefined behaviour since it may at that point contain a trap
representation.
(If the order of the expressions '*cp = 42' and '*fp' had been
switched around, then no undefined behaviour would have occurred.)



The standard has special language at several places that essentially
says that you can treat any object as an array of unsigned chars both
when reading and writing to the object. (You can mostly treat any
object as an array of char, or array of signed char as well, but since
a signed char can have a trap representation it is not necessarily safe
to read from such an lvalue in all situations.  Unsigned char is the
only type guaranteed to not have any trap representation.)
There is no such special language for any other types.

If one ignores the special case of character types, the rules basically
boil down to:

 If an object has been declared with some specific type (this includes
 all objects with automatic or static storage duration) then you can
 only read from it using an lvalue whose type is compatible with the
 type as the object.  (Possibly with differences in signed/unsigned
 specification and in qualifiers as described in 6.5p7)

 If an object does not have a declared type (such as memory allocated
 through malloc) then if you have stored a value there using an lvalue
 of some specific type, then you can only read the value using an lvalue
 of compatible type. (Again possibly with differences in qualifiers and
 signed/unsigned specifiers.)

(Assuming the object is suitably aligned and large enough, there is not
really any prohibition against storing a value into an object using an
lvalue of a completely different type, but since you cannot read that
value back there is not much point in doing so.)

Note that most sorts of "type punning" (i.e. treating an object as if
it was of a different type than it actually is) is disallowed by the C
standard.

In particular accessing an array of chars as if it was an array of int is
not allowed any more than accessing an array of int as if it was an
array of float.





-- 

Erik Trulsson
ertr1...@student.uu.se

Re: Success with MinGW and AVR and LTO - almost

[Richard Guenther]

On Sun, Jan 10, 2010 at 10:36 PM, Andrew Hutchinson
 wrote:
>
>
> Kai Tietz wrote:
>>
>> Well, open call there aren't that much but point of interest is in
>> 'c-pch.c:  fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses
>> O_BINARY, too. See also for pattern in libiberty mkstemps.c
>>
>> Regards,
>> Kai
>>
>>
>>
>
> It looks like O_BINARY is already defined in system.h, so all it needs is
> the patches to open().
>
> I backed off my shot gun fix and there are just two places that appear to be
> problem:
>
> lto_elf_file_open () in lto-elf.c
> lto_read_section_data() in lto.c
>
> With O_BINARY on read/write remove failures from my simple test.

A patch that adds O_BINARY to those is ok if it passes bootstrap & testing
on a linux platform.

Thanks,
Richard.

> Andy
>
>

gcc-4.3-20100110 is now available

[gccadmin]

Snapshot gcc-4.3-20100110 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 155795

You'll find:

gcc-4.3-20100110.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20100110.tar.bz2 C front end and core compiler

gcc-ada-4.3-20100110.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20100110.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20100110.tar.bz2  C++ front end and runtime

gcc-java-4.3-20100110.tar.bz2 Java front end and runtime

gcc-objc-4.3-20100110.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20100110.tar.bz2The GCC testsuite

Diffs from 4.3-20100103 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Success with MinGW and AVR and LTO - almost

[Andrew Hutchinson]

Kai Tietz wrote:

Well, open call there aren't that much but point of interest is in
'c-pch.c:  fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses
O_BINARY, too. See also for pattern in libiberty mkstemps.c

Regards,
Kai


  


It looks like O_BINARY is already defined in system.h, so all it needs 
is the patches to open().


I backed off my shot gun fix and there are just two places that appear 
to be problem:


lto_elf_file_open () in lto-elf.c
lto_read_section_data() in lto.c

With O_BINARY on read/write remove failures from my simple test.

Andy

Re: Success with MinGW and AVR and LTO - almost

[Kai Tietz]

2010/1/10 Kai Tietz :
> 2010/1/10 Andrew Hutchinson :
>>
>>
>> Kai Tietz wrote:
>>>
>>> Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
>>> handled). For O_BINARY the common approach here is to do the following
>>> condifition before use:
>>>
>>> #ifndef O_BINARY
>>> #define O_BINARY 0
>>> #endif
>>>
>>> This is a pattern pretty often used. To rely here on binmode.o is a
>>> way, too, but it is the most ugly one, too. It affects any file open,
>>> which isn't necessarily wanted.
>>>
>>> Cheers,
>>> Kai
>>>
>>>
>>
>> Is LTO really the only place gcc needs  binary access to files for build of
>> cross compiler?
>
> I am not sure here. But in general gcc uses just text files/streams
> for input and output. AFAIR there was used in the past _O_BINARY in
> gcc's frontend, but well I can be wrong here.
> Binary mode fopen are used at the moment in gcov-io.c, genchecksum.c,
> graphite-sese-to-poly, toplev.c (for asm_out_file) and c-pch.c as here
> binary data is written/red.

Well, open call there aren't that much but point of interest is in
'c-pch.c:  fd = open (name, O_RDONLY | O_BINARY, 0666);' as it uses
O_BINARY, too. See also for pattern in libiberty mkstemps.c

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: Success with MinGW and AVR and LTO - almost

[Kai Tietz]

2010/1/10 Andrew Hutchinson :
>
>
> Kai Tietz wrote:
>>
>> Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
>> handled). For O_BINARY the common approach here is to do the following
>> condifition before use:
>>
>> #ifndef O_BINARY
>> #define O_BINARY 0
>> #endif
>>
>> This is a pattern pretty often used. To rely here on binmode.o is a
>> way, too, but it is the most ugly one, too. It affects any file open,
>> which isn't necessarily wanted.
>>
>> Cheers,
>> Kai
>>
>>
>
> Is LTO really the only place gcc needs  binary access to files for build of
> cross compiler?

I am not sure here. But in general gcc uses just text files/streams
for input and output. AFAIR there was used in the past _O_BINARY in
gcc's frontend, but well I can be wrong here.
Binary mode fopen are used at the moment in gcov-io.c, genchecksum.c,
graphite-sese-to-poly, toplev.c (for asm_out_file) and c-pch.c as here
binary data is written/red.

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: Success with MinGW and AVR and LTO - almost

[Andrew Hutchinson]

Kai Tietz wrote:


Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
handled). For O_BINARY the common approach here is to do the following
condifition before use:

#ifndef O_BINARY
#define O_BINARY 0
#endif

This is a pattern pretty often used. To rely here on binmode.o is a
way, too, but it is the most ugly one, too. It affects any file open,
which isn't necessarily wanted.

Cheers,
Kai

  
Is LTO really the only place gcc needs  binary access to files for build 
of cross compiler?


Andy

Re: Success with MinGW and AVR and LTO - almost

[Kai Tietz]

2010/1/10 Andrew Hutchinson :
> I think  "rb" is nop. However, O_BINARY is less portable.
>
> There is another way. If  MinGW hosted build  is linked with binmode.o - the
> default for files become binary
> Some other methods are here:
>
> http://oldwiki.mingw.org/index.php/binary
>
>
>
>
> Rafael Espindola wrote:
>>>
>>> I hacked fopen/open calls in  lto.c and lto-elf.c to use O_BINARY and
>>> "rb"
>>> and compilation with -flto was then successful!
>>>
>>> I am not sure how this should be fixed properly.
>>>
>>
>> Using O_BINARY and "rb" should be a nop on unix, no? Is it wrong to
>> use them on any arch we care about?
>>
>>
>>>
>>> Andy
>>>
>>
>> Cheers,
>>
>


Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
handled). For O_BINARY the common approach here is to do the following
condifition before use:

#ifndef O_BINARY
#define O_BINARY 0
#endif

This is a pattern pretty often used. To rely here on binmode.o is a
way, too, but it is the most ugly one, too. It affects any file open,
which isn't necessarily wanted.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: Success with MinGW and AVR and LTO - almost

[Andrew Hutchinson]

I think  "rb" is nop. However, O_BINARY is less portable.

There is another way. If  MinGW hosted build  is linked with binmode.o - 
the default for files become binary

Some other methods are here:

http://oldwiki.mingw.org/index.php/binary




Rafael Espindola wrote:

I hacked fopen/open calls in  lto.c and lto-elf.c to use O_BINARY and "rb"
and compilation with -flto was then successful!

I am not sure how this should be fixed properly.



Using O_BINARY and "rb" should be a nop on unix, no? Is it wrong to
use them on any arch we care about?

  

Andy



Cheers,
  

Re: Success with MinGW and AVR and LTO - almost

[Rafael Espindola]

> I hacked fopen/open calls in  lto.c and lto-elf.c to use O_BINARY and "rb"
> and compilation with -flto was then successful!
>
> I am not sure how this should be fixed properly.

Using O_BINARY and "rb" should be a nop on unix, no? Is it wrong to
use them on any arch we care about?

> Andy

Cheers,
-- 
Rafael Ávila de Espíndola

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Dave Korn]

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 aware of the subtleties of the terminology, thanks for pointing
it out.

cheers,
  DaveK

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Eric Botcazou]

>   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

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Dave Korn]

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 not an operator, it's a property of an lvalue expression.

  Yes, fair enough; but properties can commute just as much as operators can
(although it's perhaps less intuitively surprising when they don't).  Anyway I
just mentioned it because I think it would be a useful term to bandy about a
bit more often in aliasing discussions!

cheers,
  DaveK

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andreas Schwab]

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 an lvalue expression.

>> static inline int
>> address_in_use2 (unsigned char *a, struct in6_addr *in6)
>> {
 return memcmp (a, &in6.__s6_addr, sizeof (in6.__s6_addr)) == 0;
>> }

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Dave Korn]

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 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 don't alias against the original chars.  Is that an accurate precis?

  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.


  So, the only way to do this trick nowadays is to use a union, right?

> union u
> {
>   uint8_t  aschars[16];
>   uint32_t aslongs[4];
> };
> 
> static inline int
> address_in_use2 (unsigned char *a, struct in6_addr *in6)
> {
>   union u *u1 = (union u *)in6.__s6_addr;
>   union u *u2 = (union u *)a;
> 
>   if ((u1->aslongs[0] == u2->aslongs[0])
>   && (u1->aslongs[1] == u2->aslongs[1])
>   && (u1->aslongs[2] == u2->aslongs[2])
>   && (u1->aslongs[3] == u2->aslongs[3]))
> return 1;
> 
>   return 0;
> }

... and this is allowed because I have cast the char pointers into pointers to
"an aggregate or union type that includes one of the aforementioned types",
and the object in question currently has no effective type because it was
stored into by chars (when it was a char[] array in struct in6_addr) so the
type of the lvalue when I dereference it is just "the type of the lvalue used
for the access"?

  Also, that's getting kinda tricky to write in a macro, isn't it?  I mean
without having to use something highly gcc-specific like expression statements?

cheers,
  DaveK

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Erik Trulsson]

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 as uint32_t.  That is
> >> undefined.
> >> 
> >
> > Unless uint8_t is a character type, as I understand it.  That is
> > clearly the assumption on which the code relies.
> >   
> But in the new compilers it's an integer type, not a character 
> type--from the spec:

A character type is an integer type, so it is quite possible for
uint8_t to qualify both as a character type and as an integer type.



-- 

Erik Trulsson
ertr1...@student.uu.se

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Dave Korn]

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)
>>> {
>>>   if const uint32_t *)(a))[0]
>>> == ((const uint32_t *)(in6->__s6_addr))[0]
>>> && ((const uint32_t *)(a))[1]
>>> == ((const uint32_t *)(in6->__s6_addr))[1]
>>> && ((const uint32_t *)(a))[2]
>>> == ((const uint32_t *)(in6->__s6_addr))[2]
>>> && ((const uint32_t *)(a))[3]
>>> == ((const uint32_t *)(in6->__s6_addr))[3]))
>>> return 1;
>>>
>>>   return 0;
>>> }
>> That code seems to be broken for reasons other than aliasing -- it can
>> easily give alignment errors on platforms that require natural alignment
>> (because an in6_addr object might be allocated at an odd address).
> 
> It that case, the allocator would be broken.  But the breakage isn't
> here, it's in the allocator.  I don't think there's anything wrong
> with this code.

  Yes, and regardless; the compiler doesn't need to worry about that, it just
needs to make the assumption that it /is/ aligned (since it is allowed to
assume I will not invoke undefined behaviour).

cheers,
  DaveK

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Dave Korn]

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.
>>> 
>>
>> Unless uint8_t is a character type, as I understand it.  That is
>> clearly the assumption on which the code relies.
>>   
> But in the new compilers it's an integer type, not a character
> type--from the spec:

  It's a typedef at the top of the sample code:

> typedef unsigned char uint8_t;

  The example doesn't rely on any headers.

cheers,
  DaveK

Re: help on debugging gcc using gdb

[Jonathan Wakely]

2010/1/10 swati raina:
>
> I am tried to debug gcc using the following commands
>
> 1)[sw...@localhost ~]$ gdb --args /usr/bin/gcc

See http://gcc.gnu.org/wiki/DebuggingGCC

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Joseph S. Myers]

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 unsigned char, so char is not a valid choice for any of 
the intN_t and uintN_t typedefs.)  These types are also character types.

Though it might be useful to have extended integer types for int8_t and 
uint8_t that don't have the special aliasing properties of character 
types, as suggested in , 
this has not been implemented.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andrew Haley]

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.
>>
>> Unless uint8_t is a character type, as I understand it.  That is
>> clearly the assumption on which the code relies.
>>   
> But in the new compilers it's an integer type, not a character 
> type--from the spec:

In which case this code is undefined, I agree.

IMO it would be unwise for gcc not to treat uint8_t as a member of
Alias Set 0, since doing so would break existing code (of which this
is an excellent example) for no useful purpose.

Andrew.

help on debugging gcc using gdb

[swati raina]

Hi,
I want to detect simple 'if-else' statements for which i need to understand the 
source code of gcc. I am using version 4.4.0.
So,

I am tried to debug gcc using the following commands

1)[sw...@localhost ~]$ gdb --args /usr/bin/gcc

Missing separate debuginfos, use: debuginfo-install gcc-4.4.0-4.i586


2)(gdb) run gcc
Starting program: /usr/bin/gcc gcc

//The error is as follows:

gcc: gcc: No such file or directory
gcc: no input files

Program exited with code 01.
(gdb)q

// i tried next , the exec command  but still faced same error

(gdb) exec gcc
(gdb) run
Starting program: /usr/lib/ccache/gcc gcc
Executing new program: /usr/bin/gcc
Missing separate debuginfos, use: debuginfo-install ccache-2.4-14.fc11.i586
gcc: gcc: No such file or directory
gcc: no input files

Program exited with code 01.
Missing separate debuginfos, use: debuginfo-install gcc-4.4.0-4.i586
(gdb)q


S Raina




  Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com. 
http://mail.promotions.yahoo.com/newdomains/aa/

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Patrick Horgan]

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 is
clearly the assumption on which the code relies.
  
But in the new compilers it's an integer type, not a character 
type--from the spec:


7.18.1.1 Exact-width integer types
1 The typedef name intN_t designates a signed integer type with width N 
, no padding
bits, and a two’s complement representation. Thus, int8_t denotes a 
signed integer

type with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type with 
width N . Thus,

uint24_t denotes an unsigned integer type with a width of exactly 24 bits.
3 These types are optional. However, if an implementation provides 
integer types with
widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed 
types) that have a
two’s complement representation, it shall define the corresponding 
typedef names.


Patrick

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andrew Haley]

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))[0]
>> == ((const uint32_t *)(in6->__s6_addr))[0]
>> && ((const uint32_t *)(a))[1]
>> == ((const uint32_t *)(in6->__s6_addr))[1]
>> && ((const uint32_t *)(a))[2]
>> == ((const uint32_t *)(in6->__s6_addr))[2]
>> && ((const uint32_t *)(a))[3]
>> == ((const uint32_t *)(in6->__s6_addr))[3]))
>> return 1;
>>
>>   return 0;
>> }
> 
> That code seems to be broken for reasons other than aliasing -- it can
> easily give alignment errors on platforms that require natural alignment
> (because an in6_addr object might be allocated at an odd address).

It that case, the allocator would be broken.  But the breakage isn't
here, it's in the allocator.  I don't think there's anything wrong
with this code.

Andrew.

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Eric Botcazou]

> 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

RE: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Paul Koning]

> ... 
> 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->__s6_addr))[0]
> && ((const uint32_t *)(a))[1]
> == ((const uint32_t *)(in6->__s6_addr))[1]
> && ((const uint32_t *)(a))[2]
> == ((const uint32_t *)(in6->__s6_addr))[2]
> && ((const uint32_t *)(a))[3]
> == ((const uint32_t *)(in6->__s6_addr))[3]))
> return 1;
> 
>   return 0;
> }

That code seems to be broken for reasons other than aliasing -- it can
easily give alignment errors on platforms that require natural alignment
(because an in6_addr object might be allocated at an odd address).

paul

RE: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Paul Koning]

> ...
> >> 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" specially because char is a bit like a
"poor main's void".

paul

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andreas Schwab]

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 which way does it make a difference?  For aliasing consideration,
only the type of access matters.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Success with MinGW and AVR and LTO - almost

[Andrew Hutchinson]

I have just succeed in building last snapshot version 4.5.0 20100107 for 
AVR target with working LTO  on both LINUX and MinGW hosts!


As noted before #define LINKER_NAME has to be deleted from target avr.h 
(I will raise patch for this)


I also built avr target for MINGW under MSYS and this has no obvious 
issues for either build or use with normal (non-lto) compilation

However, LTO use failed completely.

LTO using libelf needs to handle files as BINARY with Windows. This 
would seem to  apply to any target on MinGW


I hacked fopen/open calls in  lto.c and lto-elf.c to use O_BINARY and 
"rb" and compilation with -flto was then successful!


I am not sure how this should be fixed properly.

Andy

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andrew Haley]

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 which the code relies.

Andrew.

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andreas Schwab]

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 completely different."

Regression in GCC4.5.0 m68k-elf with r146817 (Author: matz)

[Bernd Roesch]

Hi, 

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html

This do the problem when compile ffmpeg.all gcc Versions that contain the
Patch fail 

-m68020 -m68881 -O1 ("Abort trap")

but work when do 

-m68020 -m68881 -O1 -fno-tree-ccp -fno-tree-dominator-opts (works ok).

.See here for more about the Problem.(the testprogram that show what code is
execute is also add)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311

In a testprogram i cant reproduce the Problem, seem only happen on special
register usage.It seem have nothing to do with the backend.

But whats the line that fail i cant find out, because there are too many
changes at once in the Patch.

maybe somebody can help me so i can reproduce the problem better or add log
output for GCC in this special functions ?

Here is the changelog of the Patch

"""
2009-04-26  Michael Matz  

Expand from SSA.
* builtins.c (fold_builtin_next_arg): Handle SSA names.
* tree-ssa-copyrename.c (rename_ssa_copies): Use ssa_name() directly.
* tree-ssa-coalesce.c (create_outofssa_var_map): Mark only useful
SSA names. 
(compare_pairs): Swap cost comparison.
(coalesce_ssa_name): Don't use change_partition_var.
* tree-nrv.c (struct nrv_data): Add modified member.
(finalize_nrv_r): Set it.
(tree_nrv): Use it to update statements.
(pass_nrv): Require PROP_ssa.
* tree-mudflap.c (mf_decl_cache_locals,
mf_build_check_statement_for): Use make_rename_temp.
(pass_mudflap_2): Require PROP_ssa, run ssa update at finish.
* alias.c (find_base_decl): Handle SSA names.
* emit-rtl (set_reg_attrs_for_parm): Make non-static.
(component_ref_for_mem_expr): Don't leak SSA names into RTL.
* rtl.h (set_reg_attrs_for_parm): Declare.
* tree-optimize.c (pass_cleanup_cfg_post_optimizing): Rename
to "optimized", remove unused locals at finish.
(execute_free_datastructures): Make global, call
delete_tree_cfg_annotations.
(execute_free_cfg_annotations): Don't call
delete_tree_cfg_annotations.

* ssaexpand.h: New file.
* expr.c (toplevel): Include ssaexpand.h.
(expand_assignment): Handle SSA names the same as register
variables.
(expand_expr_real_1): Expand SSA names.
* cfgexpand.c (toplevel): Include ssaexpand.h.
(SA): New global variable.
(gimple_cond_pred_to_tree): Fold TERed comparisons into predicates.
(SSAVAR): New macro.
(set_rtl): New helper function.
(add_stack_var): Deal with SSA names, use set_rtl.
(expand_one_stack_var_at): Likewise.
(expand_one_stack_var): Deal with SSA names.
(stack_var_size_cmp): Use code (SSA_NAME / DECL) as tie breaker
before unique numbers.
(expand_stack_vars): Use set_rtl.
(expand_one_var): Accept SSA names, add asserts for them, feed them
to above subroutines.
(expand_used_vars): Expand all partitions (without default defs),
then only the local decls (ignoring those expanded already).
(expand_gimple_cond): Remove edges when jumpif() expands an
unconditional jump.
(expand_gimple_basic_block): Don't clear EDGE_EXECUTABLE here,
or remove abnormal edges.  Ignore insns setting the LHS of a TERed
SSA name.
(gimple_expand_cfg): Call into rewrite_out_of_ssa, initialize
members of SA; deal with PARM_DECL partitions here; expand
all PHI nodes, free tree datastructures and SA.  Commit instructions
on edges, clear EDGE_EXECUTABLE and remove abnormal edges here.
(pass_expand): Require and destroy PROP_ssa, verify SSA form, flow
info and statements at start, collect garbage at finish.
* tree-ssa-live.h (struct _var_map): Remove partition_to_var member.
(VAR_ANN_PARTITION) Remove.
(change_partition_var): Don't declare.
(partition_to_var): Always return SSA names.
(var_to_partition): Only accept SSA names.
(register_ssa_partition): Only check argument.
* tree-ssa-live.c (init_var_map): Don't allocate partition_to_var
member.
(delete_var_map): Don't free it.
(var_union): Only accept SSA names, simplify.
(partition_view_init): Mark only useful SSA names as used.
(partition_view_fini): Only deal with SSA names.
(change_partition_var): Remove.
(dump_var_map): Use ssa_name instead of partition_to_var member.
* tree-ssa.c (delete_tree_ssa): Don't remove PHI nodes on RTL
basic blocks.
* tree-outof-ssa.c (toplevel): Include ssaexpand.h and expr.h.
(struct _elim_graph): New member const_dests; nodes member vector of
ints.
(set_location_for_edge): New static helper.
(create_temp): Remove.
(insert_partition_copy_on_edge, insert_part_to_rtx_on_edge,
insert_value_copy_on_edge, insert_rtx_to_part_on_edge): New
functions.
(new_elim_graph): Allocate const_dests member.
(clean_elim_graph): Truncate const_dests member.
(delete_elim_graph): Free const_dests member.
(elim_graph_size): Adapt to new type of nodes member.
(elim_graph_add_node): Likewise.
(eliminate_name

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andrew Haley]

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'll file a
>> PR if so.  (I can't pretend I find the language in the spec easy to follow.)
> 
> IIUC both accesses are actually wrong, but in the case of a there is no
> information about the actual target type, so the compiler cannot
> optimize.  In both cases an object is accessed as type uint32_t, but the
> effective type is different.

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->__s6_addr))[0]
&& ((const uint32_t *)(a))[1]
== ((const uint32_t *)(in6->__s6_addr))[1]
&& ((const uint32_t *)(a))[2]
== ((const uint32_t *)(in6->__s6_addr))[2]
&& ((const uint32_t *)(a))[3]
== ((const uint32_t *)(in6->__s6_addr))[3]))
return 1;

  return 0;
}


Why do you say the effective type is different?  As long as uint8_t is
a character type and both *a and *in6->__s6_addr have been written as
uint32_t, this looks legal.

Andrew.

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Andreas Schwab]

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 language in the spec easy to follow.)

IIUC both accesses are actually wrong, but in the case of a there is no
information about the actual target type, so the compiler cannot
optimize.  In both cases an object is accessed as type uint32_t, but the
effective type is different.  Aliasing is not symmetric, the aliasing
exception only applies to the case of accessing through a character
type, the effective type of the object does not matter.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: dwarf2 - multiple DW_TAG_variable for global variable

[Jan Kratochvil]

On Sun, 10 Jan 2010 00:31:56 +0100, Nenad Vukicevic wrote:
...
> <1><54>: Abbrev Number: 4 (DW_TAG_variable)
> <55>   DW_AT_name: (indirect string, offset: 0x38): x
> <59>   DW_AT_decl_file   : 1
> <5a>   DW_AT_decl_line   : 1
> <5b>   DW_AT_type: <0x4d>
> <5f>   DW_AT_external: 1
> <60>   DW_AT_declaration : 1
> <1><61>: Abbrev Number: 5 (DW_TAG_variable)
> <62>   DW_AT_name: (indirect string, offset: 0x38): x
> <66>   DW_AT_decl_file   : 1
> <67>   DW_AT_decl_line   : 1
> <68>   DW_AT_type: <0x4d>
> <6c>   DW_AT_external: 1
> <6d>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
> 
> in 4.4.1 and 4.5 releases.
> 
> Any idea if this is a correct dwarf? Or must be treated as a
> duplicate somehow?

It does not hurt much GDB - if the debugger ignores the second definition it
looks as a declaration of external symbol and it gets correctly looked up
through the ELF (not DWARF) .symtab symbol without using DW_AT_location.

PR 39524 mentions a special scope case which gets broken by it but in common
cases it works fine.


Regards,
Jan