Re: SPARC Ada compilation hangs
> I would appreciate it is one of the SPARC/Solaris > users would see if they can duplicate this. I cannot duplicate on SPARC/Solaris, but my tree is not pristine. This is for a --disable--bootstrap compiler built at -O0 -g. -- Eric Botcazou
Re: SPARC Ada compilation hangs
Eric Botcazou wrote: I would appreciate it is one of the SPARC/Solaris users would see if they can duplicate this. I cannot duplicate on SPARC/Solaris, but my tree is not pristine. This is for a --disable--bootstrap compiler built at -O0 -g. The two files in question do compile at -O0 so you wouldn't trip it. Can you compile g-catiio.adb and g-spipat.adb at -O2 by hand and see if the compiler consumes 100% of the CPU until you kill it? --joel
Re: df_insn_refs_record's handling of global_regs[]
On Fri, Oct 19, 2007 at 05:42:58PM -0700, Seongbae Park (박성배, 朴成培) wrote: > On 10/19/07, David Miller <[EMAIL PROTECTED]> wrote: > > From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> > > Date: Fri, 19 Oct 2007 17:25:14 -0700 > > > > > If you're not in a hurry, can you wait > > > till I run the regtest against 4.2 on x86-64 ? > > > I've already discussed the patch with Kenny > > > and we agreed that this is the right approach, > > > but I'd like to see the clean regtest on x86 for both 4.2 and 4.3 > > > before I approve. > > > Thanks, > > > > I am in no rush, please let me know if you want some help > > tracking down the failure you are seeing. > > > > Since you say it is a libgomp failure... I wonder if some of > > the atomic primitives need some side effect markings which > > are missing and thus exposed by not clobbering global regs > > at call sites any more. > > It looks like it's just a flaky test - it randomly fails on my test machine > with or without the patch (for interested, it's omp_parse3.f90 with -O0). See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33275 H.J.
Re: df_insn_refs_record's handling of global_regs[]
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 22:56:49 -0700
> Did you replace the DF_REF_REG_USE with DEF ?
> If so, that's not correct. We need to add DEF as well as USE:
...
> Then, we'll need to change the df_invalidated_by_call loop
> not to add global_regs[] again (with MAY_CLOBBER bits).
Seongbae-ssi, I've done full regstraps of mainline with the
following patch on sparc-linux-gnu and sparc64-linux-gnu.
Do you mind if I check in this fix? I would also like to
pursue getting this installed on the gcc-4.2 branch as well,
as I stated I've already done several regstraps of the 4.2
backport of this fix as well.
Thank you.
2007-10-18 Seongbae Park <[EMAIL PROTECTED]>
David S. Miller <[EMAIL PROTECTED]>
* df-scan.c (df_get_call_refs): Mark global registers as both a
DF_REF_REG_USE and a non-clobber DF_REF_REG_DEF.
--- df-scan.c.ORIG 2007-10-18 16:56:19.0 -0700
+++ df-scan.c 2007-10-18 16:56:50.0 -0700
@@ -3109,18 +3109,22 @@
so they are recorded as used. */
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
if (global_regs[i])
- df_ref_record (collection_rec, regno_reg_rtx[i],
-NULL, bb, insn, DF_REF_REG_USE, flags);
+ {
+ df_ref_record (collection_rec, regno_reg_rtx[i],
+ NULL, bb, insn, DF_REF_REG_USE, flags);
+ df_ref_record (collection_rec, regno_reg_rtx[i],
+ NULL, bb, insn, DF_REF_REG_DEF, flags);
+ }
is_sibling_call = SIBLING_CALL_P (insn);
EXECUTE_IF_SET_IN_BITMAP (df_invalidated_by_call, 0, ui, bi)
{
- if ((!bitmap_bit_p (defs_generated, ui))
+ if (!global_regs[ui]
+ && (!bitmap_bit_p (defs_generated, ui))
&& (!is_sibling_call
|| !bitmap_bit_p (df->exit_block_uses, ui)
|| refers_to_regno_p (ui, ui+1,
current_function_return_rtx, NULL)))
-
df_ref_record (collection_rec, regno_reg_rtx[ui],
NULL, bb, insn, DF_REF_REG_DEF, DF_REF_MAY_CLOBBER |
flags);
}
Re: df_insn_refs_record's handling of global_regs[]
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 17:25:14 -0700 > If you're not in a hurry, can you wait > till I run the regtest against 4.2 on x86-64 ? > I've already discussed the patch with Kenny > and we agreed that this is the right approach, > but I'd like to see the clean regtest on x86 for both 4.2 and 4.3 > before I approve. > Thanks, I am in no rush, please let me know if you want some help tracking down the failure you are seeing. Since you say it is a libgomp failure... I wonder if some of the atomic primitives need some side effect markings which are missing and thus exposed by not clobbering global regs at call sites any more.
Re: df_insn_refs_record's handling of global_regs[]
On 10/19/07, David Miller <[EMAIL PROTECTED]> wrote: > From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> > Date: Fri, 19 Oct 2007 17:25:14 -0700 > > > If you're not in a hurry, can you wait > > till I run the regtest against 4.2 on x86-64 ? > > I've already discussed the patch with Kenny > > and we agreed that this is the right approach, > > but I'd like to see the clean regtest on x86 for both 4.2 and 4.3 > > before I approve. > > Thanks, > > I am in no rush, please let me know if you want some help > tracking down the failure you are seeing. > > Since you say it is a libgomp failure... I wonder if some of > the atomic primitives need some side effect markings which > are missing and thus exposed by not clobbering global regs > at call sites any more. It looks like it's just a flaky test - it randomly fails on my test machine with or without the patch (for interested, it's omp_parse3.f90 with -O0). I haven't started 4.2 testing yet - I'll let you know when I get that done. -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: df_insn_refs_record's handling of global_regs[]
On 10/19/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 22:56:49 -0700
>
> > Did you replace the DF_REF_REG_USE with DEF ?
> > If so, that's not correct. We need to add DEF as well as USE:
> ...
> > Then, we'll need to change the df_invalidated_by_call loop
> > not to add global_regs[] again (with MAY_CLOBBER bits).
>
> Seongbae-ssi, I've done full regstraps of mainline with the
> following patch on sparc-linux-gnu and sparc64-linux-gnu.
I've been testing this on x86-64 on top of 4.3,
and I see one regression in libgomp which I'm trying to find out
whether it's this patch or some other external cause.
> Do you mind if I check in this fix? I would also like to
> pursue getting this installed on the gcc-4.2 branch as well,
> as I stated I've already done several regstraps of the 4.2
> backport of this fix as well.
If you're not in a hurry, can you wait
till I run the regtest against 4.2 on x86-64 ?
I've already discussed the patch with Kenny
and we agreed that this is the right approach,
but I'd like to see the clean regtest on x86 for both 4.2 and 4.3
before I approve.
Thanks,
Seongbae
> Thank you.
>
> 2007-10-18 Seongbae Park <[EMAIL PROTECTED]>
> David S. Miller <[EMAIL PROTECTED]>
>
> * df-scan.c (df_get_call_refs): Mark global registers as both a
> DF_REF_REG_USE and a non-clobber DF_REF_REG_DEF.
>
> --- df-scan.c.ORIG 2007-10-18 16:56:19.0 -0700
> +++ df-scan.c 2007-10-18 16:56:50.0 -0700
> @@ -3109,18 +3109,22 @@
> so they are recorded as used. */
>for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> if (global_regs[i])
> - df_ref_record (collection_rec, regno_reg_rtx[i],
> -NULL, bb, insn, DF_REF_REG_USE, flags);
> + {
> + df_ref_record (collection_rec, regno_reg_rtx[i],
> + NULL, bb, insn, DF_REF_REG_USE, flags);
> + df_ref_record (collection_rec, regno_reg_rtx[i],
> + NULL, bb, insn, DF_REF_REG_DEF, flags);
> + }
>
>is_sibling_call = SIBLING_CALL_P (insn);
>EXECUTE_IF_SET_IN_BITMAP (df_invalidated_by_call, 0, ui, bi)
> {
> - if ((!bitmap_bit_p (defs_generated, ui))
> + if (!global_regs[ui]
> + && (!bitmap_bit_p (defs_generated, ui))
> && (!is_sibling_call
> || !bitmap_bit_p (df->exit_block_uses, ui)
> || refers_to_regno_p (ui, ui+1,
> current_function_return_rtx, NULL)))
> -
> df_ref_record (collection_rec, regno_reg_rtx[ui],
>NULL, bb, insn, DF_REF_REG_DEF, DF_REF_MAY_CLOBBER |
> flags);
> }
gcc-4.3-20071019 is now available
Snapshot gcc-4.3-20071019 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071019/ 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/trunk revision 129496 You'll find: gcc-4.3-20071019.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20071019.tar.bz2 C front end and core compiler gcc-ada-4.3-20071019.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20071019.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20071019.tar.bz2 C++ front end and runtime gcc-java-4.3-20071019.tar.bz2 Java front end and runtime gcc-objc-4.3-20071019.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20071019.tar.bz2The GCC testsuite Diffs from 4.3-20071012 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.
Removal of pre-ISO C++ items from include/backwards
2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]> Removal of pre-ISO C++ items from include/backwards. * include/Makefile.am (backward_headers): Remove all but strstream, backward_warning.h. * include/Makefile.in: Regenerate. * include/backward/new.h: Remove. * include/backward/iterator.h: Same. ... I don't think this is a great idea. What is the benefit of this apart from causing endless pain? (SPEC2000 eon now fails to build for example) *sigh* Richard.
SPARC Ada compilation hangs
Hi, When compiling GNAT/RTEMS to SPARC on the SVN trunk, the compilation of g-catiio.adb and g-spipat.adb hang when using -O2. I kill the compilation and do them by hand with -O0 and the build continues. I would appreciate it is one of the SPARC/Solaris users would see if they can duplicate this. Thanks. --joel sherrill
Ada standard elaboration order
Just an old newbie question. when I look at the elaboration order generated by gnatbind for the standard libraries I get the following: ... system.soft_links (spec) system.soft_links (body) ... ada.exceptions (body) ... but the body of soft_links contains Ada.Exceptions.Save_Occurrence (NT_TSD.Current_Excep, Ada.Exceptions.Null_Occurrence); So how can the body of system.soft_links be elaborated prior to the body of ada.exceptions since it is dependent on it? Is my understanding flawed? chris
Re: SPARC Ada compilation hangs
> The two files in question do compile at -O0 so you wouldn't > trip it. You misunderstood, only the compiler is built at -O0 -g, the runtime is built normally at -O2 -g. -- Eric Botcazou
Re: Ada standard elaboration order
* Christophe Meudec: > So how can the body of system.soft_links be elaborated prior to the > body of ada.exceptions since it is dependent on it? The standard library is not subject to the elaboration rules of the language. It's not written in standard Ada, either.
