gcc-4.6-20110205 is now available
Snapshot gcc-4.6-20110205 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110205/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 169855 You'll find: gcc-4.6-20110205.tar.bz2 Complete GCC (includes all of below) MD5=640f0f3248522735f7b361df52c95a14 SHA1=f318596cea001e189990eeb5ac0fa5d606c0ed2b gcc-core-4.6-20110205.tar.bz2C front end and core compiler MD5=98109df1e4ac9a800484cee801dc3078 SHA1=b66e799bc00338e4ab7dd4d1a59abc44a5f12b15 gcc-ada-4.6-20110205.tar.bz2 Ada front end and runtime MD5=98580ae23b42b48e0f321e1754dbae3c SHA1=3b94e640e5534f1ce85d8f8e8c8144405332de4f gcc-fortran-4.6-20110205.tar.bz2 Fortran front end and runtime MD5=8a86ad6d9ea9670a1613c8c69f54cbd7 SHA1=92a39c6f3fd3c0d8bff7847a41d0499da248e931 gcc-g++-4.6-20110205.tar.bz2 C++ front end and runtime MD5=58f2c791707d005ab991e5aae36d87cc SHA1=3af28e211d12b25c845f1d721e5c7004eed50bc7 gcc-go-4.6-20110205.tar.bz2 Go front end and runtime MD5=b3f18427c5a885a7b0f171b516092f92 SHA1=09becf579072e27a160972790efce6547d223aa8 gcc-java-4.6-20110205.tar.bz2Java front end and runtime MD5=966b1088f2ad7f2c03ee2bc0ba53f08f SHA1=a587bb71b88da675107c200f0514d030540f715e gcc-objc-4.6-20110205.tar.bz2Objective-C front end and runtime MD5=f2b156a7951b786ecbca649c504c7c02 SHA1=7037424d5fd5fa98d9438431c906f7a98f42e182 gcc-testsuite-4.6-20110205.tar.bz2 The GCC testsuite MD5=48996e1dd9f69d73a55da96f9e7041d3 SHA1=94abe42f961bd71705c74c173e3f54480e4fd107 Diffs from 4.6-20110129 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
New libquadmath maintainers: Jakub and Tobias
Jakub, Tobias -- The GCC SC has appointed you as maintainers of libquadmath within GCC. Please update the MAINTAINERS file to reflect your new positions. Congratulations! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Wrong-code bug in execute_update_addresses_taken?
On Sat, Feb 5, 2011 at 7:55 AM, Ulrich Weigand wrote:
> Hello,
>
> the following program seems to be miscompiled at -O or higher:
>
> int
> main (void)
> {
> int data = 1;
>
> struct ptr
> {
> int val;
> } *ptr = (struct ptr *) &data;
>
> ptr->val = 0;
>
> return data;
> }
>
> This program should return 0, but actually returns 1.
>
> [ As far as I can tell, this program does not violate the aliasing
> rules; all memory accesses refer to an object of effective (because
> declared) type "int", and use lvalue references of type "int".
> The pointer cast might depend on implementation-defined behaviour,
> but is not undefined. In any case, there are no warnings, and use
> of -fno-strict-aliasing does not fix the problem. ]
>
> In 024t.forwprop1, we still have (correctly):
>
> # .MEMD.3455_4 = VDEF <.MEMD.3455_3(D)>
> dataD.1975 = 1;
>
> # .MEMD.3455_5 = VDEF <.MEMD.3455_4>
> MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
>
> # VUSE <.MEMD.3455_5>
> D.3453_2 = dataD.1975;
> return D.3453_2;
>
> but then in 025t.ealias, we get:
>
> dataD.1975_4 = 1;
>
> # .MEMD.3455_5 = VDEF <.MEMD.3455_3(D)>
> MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
>
> D.3453_2 = dataD.1975_4;
> return D.3453_2;
>
> This is apparently caused by the "addresses taken" pass,
> which results in those messages:
>
> No longer having address taken: data
>
> Registering new PHI nodes in block #0
> Registering new PHI nodes in block #2
>
> Updating SSA information for statement data = 1;
> Updating SSA information for statement D.3453_2 = data;
>
> It seems that for some reason, the pass claims to be able to
> eliminate all statements that take the address of "data",
> but then leaves the MEM reference unchanged ...
>
> Any suggestions on what might cause this problem?
>
This behavior change of -fno-strict-aliasing is caused by
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00788.html
--
H.J.
Wrong-code bug in execute_update_addresses_taken?
Hello,
the following program seems to be miscompiled at -O or higher:
int
main (void)
{
int data = 1;
struct ptr
{
int val;
} *ptr = (struct ptr *) &data;
ptr->val = 0;
return data;
}
This program should return 0, but actually returns 1.
[ As far as I can tell, this program does not violate the aliasing
rules; all memory accesses refer to an object of effective (because
declared) type "int", and use lvalue references of type "int".
The pointer cast might depend on implementation-defined behaviour,
but is not undefined. In any case, there are no warnings, and use
of -fno-strict-aliasing does not fix the problem. ]
In 024t.forwprop1, we still have (correctly):
# .MEMD.3455_4 = VDEF <.MEMD.3455_3(D)>
dataD.1975 = 1;
# .MEMD.3455_5 = VDEF <.MEMD.3455_4>
MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
# VUSE <.MEMD.3455_5>
D.3453_2 = dataD.1975;
return D.3453_2;
but then in 025t.ealias, we get:
dataD.1975_4 = 1;
# .MEMD.3455_5 = VDEF <.MEMD.3455_3(D)>
MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
D.3453_2 = dataD.1975_4;
return D.3453_2;
This is apparently caused by the "addresses taken" pass,
which results in those messages:
No longer having address taken: data
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Updating SSA information for statement data = 1;
Updating SSA information for statement D.3453_2 = data;
It seems that for some reason, the pass claims to be able to
eliminate all statements that take the address of "data",
but then leaves the MEM reference unchanged ...
Any suggestions on what might cause this problem?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
