Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org
Dennis Clarke-2 wrote: > > >> On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote: >>> >> This was built against ppl 0.10.2 and cloog 0.15.10. > > Have you tried a bootstrap with neither ppl nor cloog ? I have yet to see > their value and I generally exclude them. This results ( thus far ) in > nice clean bootstrap builds. > i sucessfully bootstraped on powerpc64-unknown-linux-gnu and powerpc-unknown-linux-gnu but as i've ppl-0.11 i still need this configure hack: sed -i "/ppl_minor_version=/s#10#11#" $name-$version/configure thanks, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ -- View this message in context: http://old.nabble.com/GCC-4.5.2-Release-Candidate-available-from-gcc.gnu.org-tp30405453p30432287.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Tree checking failure in jc1
On 10/12/2010 20:49, Dave Korn wrote: > I found a couple of new FAILs in my latest libjava testrun: > >> FAIL: newarray_overflow -O3 compilation from source >> FAIL: newarray_overflow -O3 -findirect-dispatch compilation from source > > These turn out to be tree checking failures: > >> In file included from :3:0: >> newarray_overflow.java:20:0: internal compiler error: tree check: expected >> class >> 'type', have 'declaration' (function_decl) in put_decl_node, at >> java/lang.c:405 This turned out to be a second bug, triggered by -fdump-tree-all attempting to output some line of mangled gimple. Without that flag, or ... > put_decl_node (TREE_CODE (DECL_CONTEXT (node)) == FUNCTION_DECL >? DECL_CONTEXT (node) >: TYPE_NAME (DECL_CONTEXT (node)), >verbosity); ... with the suggested fix, compilation proceeds to the site of the actual crash that occurred in the testsuite run: a segfault in gimple.c#walk_gimple_op(): > Program received signal SIGSEGV, Segmentation fault. > 0x007cfdbe in walk_gimple_op (stmt=0x7fe106e0, callback_op=0x4a0ef0 > .265801>, wi=0x326c554) at /gnu/gcc/gcc/gcc/gimple.c:2841 > 2841 return !AGGREGATE_TYPE_P (type); > (gdb) call debug_gimple_stmt (stmt) > newarray_overflow.int_check.__builtin_prefetch (D.1284_85, 0, ); > > (gdb) I think this is the same as PR29710(*) "gnat ICEs on -fprefetch-loop-arrays -O1", so I'll put the rest of my findings there. Note that weird missing third argument: it turns out that integer_three_node hasn't been initialised at the time that issue_prefetch_ref() attempts to pass it to gimple_build_call(). cheers, DaveK -- (*) - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710
Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org
> > > Dennis Clarke-2 wrote: >> >> >>> On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote: >>> This was built against ppl 0.10.2 and cloog 0.15.10. >> >> Have you tried a bootstrap with neither ppl nor cloog ? I have yet to >> see >> their value and I generally exclude them. This results ( thus far ) in >> nice clean bootstrap builds. >> > > i sucessfully bootstraped on powerpc64-unknown-linux-gnu and > powerpc-unknown-linux-gnu but > as i've ppl-0.11 i still need this configure hack: > sed -i "/ppl_minor_version=/s#10#11#" $name-$version/configure > excellent. I love PowerPC. :-) On other fronts I have been working for days to get ppl to compile and pass its own basic testsuite on Solaris ( i386 and Sparc ) and thus far all attempts have failed. I have been in contact with Roberto Bagnara and I have his next release candidate on my systems ( at Blastwave.org Inc. ) and I am sure we will work it out and then get GCC 4.5.2 ( RC or otherwise ) up and running. This will be a week of work at least however. :-\ -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
GNU Modula-2 version 1.0
Hi, GNU Modula-2 1.0 has been released. Full details on how to download gm2 can be found on the homepage www.nongnu.org/gm2. It successfully passes all regression tests on both the x86_32 and x86_64 Debian GNU/Linux platforms, for details about other ports please also see the homepage. A huge thanks to all the numerous people that have supported this project over the last decade. regards, Gaius
gcc-4.6-20101211 is now available
Snapshot gcc-4.6-20101211 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101211/ 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 167715 You'll find: gcc-4.6-20101211.tar.bz2 Complete GCC (includes all of below) MD5=93d2fd229589cdffe6bf28666c02d12f SHA1=c113e28a19e00e9f59c8f516c8586b3696475b2f gcc-core-4.6-20101211.tar.bz2C front end and core compiler MD5=5be8c1ffccd4d80880397a6f2162ae08 SHA1=e06e10432dceb3b8f02dda1eca962f68ec0573c4 gcc-ada-4.6-20101211.tar.bz2 Ada front end and runtime MD5=b92b88c18e7fe27f19dfbbd3fc70c997 SHA1=25e5309792ef979532b5dacbe66afcfcd29e1195 gcc-fortran-4.6-20101211.tar.bz2 Fortran front end and runtime MD5=a095a019a97e1337eac2cdc89c6d120d SHA1=2233c1ff84bcad458f330cafeb8b0ac83ce9b632 gcc-g++-4.6-20101211.tar.bz2 C++ front end and runtime MD5=d8feb506fda676fa01b39282ea7fc1a5 SHA1=aaa3573d1bf974e251a3a59f1236e0ccec6b6a07 gcc-java-4.6-20101211.tar.bz2Java front end and runtime MD5=8ecbc24d1e126e258d75549eadc715dc SHA1=05abbeab9128afc84b980da3016bb226f087c90d gcc-objc-4.6-20101211.tar.bz2Objective-C front end and runtime MD5=91c9fdafb105658be8fdc10d9df1e792 SHA1=0f5af39fbf464e4ff33dad068af11c7fc81865bf gcc-testsuite-4.6-20101211.tar.bz2 The GCC testsuite MD5=b4ec63c6d97a18ad4902350951e9aa24 SHA1=68891058c84a0c170ca0cd205f54ee34999ff8eb Diffs from 4.6-20101204 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.
Is init_priority file scope or global scope?
Hi, Using .init_array section on Linux/x86 raised a question on init_priority. GCC manual says `init_priority (PRIORITY)' In Standard C++, objects defined at namespace scope are guaranteed to be initialized in an order in strict accordance with that of their definitions _in a given translation unit_. No guarantee is made for initializations across translation units. However, GNU C++ allows users to control the order of initialization of objects defined at namespace scope with the `init_priority' attribute by specifying a relative PRIORITY, a constant integral expression currently bounded between 101 and 65535 inclusive. Lower numbers indicate a higher priority. In the following example, `A' would normally be created before `B', but the `init_priority' attribute has reversed that order: Some_Class A __attribute__ ((init_priority (2000))); Some_Class B __attribute__ ((init_priority (543))); Note that the particular values of PRIORITY do not matter; only their relative ordering. Is init_priority file scope or global scope? I consider init_priority is file scope. Is that a correct assumption? -- H.J.
GCC 4.5.2 Release Candidate : WARNING: program timed out.
While running the testsuite I see a number of warnings related to timeouts. Is there some way to avoid these annoyances? Thus : === gcc tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /export/medusa/dclarke/build/GCC/4.5.2-RC/RC-20101208/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /export/medusa/dclarke/build/GCC/4.5.2-RC/RC-20101208/gcc/testsuite/gcc.c-torture/compile/compile.exp ... WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O1 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O2 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O3 -fomit-frame-pointer (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O3 -g (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -Os (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O2 -flto (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O2 -fwhopr (test for excess errors) . . . -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: Is init_priority file scope or global scope?
On 12/12/2010 06:54, H.J. Lu wrote:
[ off-list, but it's not personal, so let's Cc the list back in, someone might
find this explanation of the mechanism useful in the archives. ]
> Can you check the assembly output? Since
>
>
> Note that the particular values of PRIORITY do not matter; only
> their relative ordering.
> ---
>
> on Linux, the numeric string in section name isn't the same as
> PRIORITY in source file. That means on Linux, the order
> of .ctors sections in 2 files isn't the relative ordering of PRIORITY
> of those 2 files.
Well, at least on PE-COFF, the numeric string is (65536-priority). It is
zero padded to five digits, so that the linker's alphabetical sort effectively
becomes a numeric sort, and the reason for the inverting the numeric order of
priorities is because .ctors gets read backwards at startup.
I did actually check the assembly somewhere between writing "IIRC" and
finishing my email as it happens. For a testcase based on your example:
class Some_Class {
int x;
public:
Some_Class();
~Some_Class();
};
Some_Class A __attribute__ ((init_priority (2000)));
Some_Class B __attribute__ ((init_priority (543)));
... what we get is a static_initialization_and_destruction function that takes
the init priority level as an argument and constructs or destroys (per a
second argument) everything at that level only:
.file "clas.c"
.globl _A
.bss
.align 4
_A:
.space 4
.globl _B
.align 4
_B:
.space 4
.text
.def__Z41__static_initialization_and_destruction_0ii; .scl
3; .type 32; .endef
__Z41__static_initialization_and_destruction_0ii:
LFB0:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$24, %esp
cmpl$1, 8(%ebp)
jne L2
cmpl$2000, 12(%ebp)
^^^
jne L3
^^
movl$_A, (%esp)
call__ZN10Some_ClassC1Ev
L3:
cmpl$543, 12(%ebp)
^^
jne L2
^^
movl$_B, (%esp)
call__ZN10Some_ClassC1Ev
L2:
cmpl$0, 8(%ebp)
jne L1
cmpl$543, 12(%ebp)
^^
jne L5
^^
movl$_B, (%esp)
call__ZN10Some_ClassD1Ev
L5:
cmpl$2000, 12(%ebp)
^^^
jne L1
^^
movl$_A, (%esp)
call__ZN10Some_ClassD1Ev
L1:
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
LFE0:
Then we have __GLOBAL__[I/D] functions for each priority level, which load
the appropriate priority and construct/destruct argument and call that:
.def__GLOBAL__I.00543_A;.scl3; .type 32; .endef
__GLOBAL__I.00543_A:
LFB1:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$24, %esp
movl$543, 4(%esp)
^
movl$1, (%esp)
^^
call__Z41__static_initialization_and_destruction_0ii
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
LFE1:
.def__GLOBAL__D.00543_A;.scl3; .type 32; .endef
__GLOBAL__D.00543_A:
LFB2:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$24, %esp
movl$543, 4(%esp)
^
movl$0, (%esp)
^^
call__Z41__static_initialization_and_destruction_0ii
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
LFE2:
.def__GLOBAL__I.02000_A;.scl3; .type 32; .endef
__GLOBAL__I.02000_A:
LFB3:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$24, %esp
movl$2000, 4(%esp)
^^
movl$1, (%esp)
^^
call__Z41__static_initialization_and_destruction_0ii
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
LFE3:
.def__GLOBAL__D.02000_A;.scl3; .type 32; .endef
__GLOBAL__D.02000_A:
LFB4:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$24, %esp
movl$2000, 4(%esp)
^^
Re: Is init_priority file scope or global scope?
On 12/12/2010 00:47, H.J. Lu wrote: > Hi, > > Using .init_array section on Linux/x86 raised a question on > init_priority. GCC manual says > > `init_priority (PRIORITY)' > In Standard C++, objects defined at namespace scope are guaranteed > to be initialized in an order in strict accordance with that of > their definitions _in a given translation unit_. No guarantee is > made for initializations across translation units. However, GNU > C++ allows users to control the order of initialization of objects > defined at namespace scope with the `init_priority' attribute by > specifying a relative PRIORITY, a constant integral expression > currently bounded between 101 and 65535 inclusive. Lower numbers > indicate a higher priority. > > In the following example, `A' would normally be created before > `B', but the `init_priority' attribute has reversed that order: > > Some_Class A __attribute__ ((init_priority (2000))); > Some_Class B __attribute__ ((init_priority (543))); > > Note that the particular values of PRIORITY do not matter; only > their relative ordering. > > Is init_priority file scope or global scope? I consider init_priority is > file scope. Is that a correct assumption? > At least on PE-COFF, it's implemented by appending a numeric string to the .ctor/.dtor section name for the object's __GLOBAL__[CD] entries and letting them all get sorted by the linker into numeric order in the final output .ctors/.dtors table, so it ought to be global. cheers, DaveK
