Re: Should we remove java from the default bootstrap languages?

[David Miller]

From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sat, 21 Jun 2008 22:12:24 +0200

> I'm curious at how many GCC developpers use non x86/_64 as their
> main development machine (and how many non x86/_64 core they use).

I definitely am one.

Or, maybe you are asking the wrong question, which likely
should be how many maintainers of other cpus backends are
in this situation :-)

Re: gcc4.3 configuring problems with mpfr

[pradeep sanchana]

Please check the symbols in the library existing or not.

>>error
>>while configuring the mingw cross compiler for m32c-elf,

As you are saying you are facing problem with mingw.
Make sure you are using the  gmp and mpfr libraries build for mingw
Please build mingw gmp and mpfr libraries use the configuration options
--with-mpfr,--with-gmp,--includedir,
I guess by this you can solve the issue.

Thanks and Regards,
Pradeep Sanchana

Re: Should we remove java from the default bootstrap languages?

[Laurent GUERBY]

On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
> From: Laurent GUERBY <[EMAIL PROTECTED]>
> Date: Sat, 21 Jun 2008 22:12:24 +0200
> 
> > I'm curious at how many GCC developpers use non x86/_64 as their
> > main development machine (and how many non x86/_64 core they use).
> 
> I definitely am one.

How many core does your main development machine have?

> Or, maybe you are asking the wrong question, which likely
> should be how many maintainers of other cpus backends are
> in this situation :-)

:)

Laurent

Re: Should we remove java from the default bootstrap languages?

[David Miller]

From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sun, 22 Jun 2008 09:21:32 +0200

> On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
> > From: Laurent GUERBY <[EMAIL PROTECTED]>
> > Date: Sat, 21 Jun 2008 22:12:24 +0200
> > 
> > > I'm curious at how many GCC developpers use non x86/_64 as their
> > > main development machine (and how many non x86/_64 core they use).
> > 
> > I definitely am one.
> 
> How many core does your main development machine have?

8 cores and 8 cpu threads per core on one, 64 cpus total.
16 cores and 8 cpu threads per core on another, 128 cpus total.

It still takes an hour or so to bootstrap on these machines because
the individual cpu threads are slow and individual expensive
compilations become the bottleneck, especially in the libjava build.

And the way the testsuite works it can't even come close to using
even a significant fraction of those cpus.

Re: Should we remove java from the default bootstrap languages?

[Laurent GUERBY]

On Sun, 2008-06-22 at 00:45 -0700, David Miller wrote:
> > How many core does your main development machine have?
> 
> 8 cores and 8 cpu threads per core on one, 64 cpus total.
> 16 cores and 8 cpu threads per core on another, 128 cpus total.
> 
> It still takes an hour or so to bootstrap on these machines because
> the individual cpu threads are slow and individual expensive
> compilations become the bottleneck, especially in the libjava build.

Did you measure how long insn-attrtab.o generation takes?
See my other email, on a 2.2 GHz barcelona it's about 5mn20s (for each
stage) and it's the main limiting factor (but I assume it's architecture
dependant).

> And the way the testsuite works it can't even come close to using
> even a significant fraction of those cpus.

Ada ACATS testsuite is pretty easy to parallelize, I've never done it
because it's not enabled by default so it doesn't affect many people.
For dejagnu I don't know but since it's never been done I assume it must
be hard to do.

Laurent

Re: Should we remove java from the default bootstrap languages?

[David Miller]

From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sun, 22 Jun 2008 10:05:26 +0200

> On Sun, 2008-06-22 at 00:45 -0700, David Miller wrote:
> > > How many core does your main development machine have?
> > 
> > 8 cores and 8 cpu threads per core on one, 64 cpus total.
> > 16 cores and 8 cpu threads per core on another, 128 cpus total.
> > 
> > It still takes an hour or so to bootstrap on these machines because
> > the individual cpu threads are slow and individual expensive
> > compilations become the bottleneck, especially in the libjava build.
> 
> Did you measure how long insn-attrtab.o generation takes?
> See my other email, on a 2.2 GHz barcelona it's about 5mn20s (for each
> stage) and it's the main limiting factor (but I assume it's architecture
> dependant).

On Sparc, which is what these systems are and the cpu I target with
gcc, insn-attrtab.o compilation is not expensive.

Re: Should we remove java from the default bootstrap languages?

[Andrew Pinski]

Sent from my iPhone because I no longer have Internet access at home :(.

On Jun 22, 2008, at 0:21, Laurent GUERBY <[EMAIL PROTECTED]> wrote:


On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:

From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sat, 21 Jun 2008 22:12:24 +0200


I'm curious at how many GCC developpers use non x86/_64 as their
main development machine (and how many non x86/_64 core they use).


I definitely am one.


How many core does your main development machine have?



One with only 512megs of memory. It does have two hardware thread  
though.


Thanks,
Andrew Pinski

Re: Should we remove java from the default bootstrap languages?

[Andrew Pinski]

Sent from my iPhone

On Jun 22, 2008, at 2:08, Andrew Pinski <[EMAIL PROTECTED]> wrote:

Sent from my iPhone because I no longer have Internet access at  
home :(.


On Jun 22, 2008, at 0:21, Laurent GUERBY <[EMAIL PROTECTED]> wrote:


On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:

From: Laurent GUERBY <[EMAIL PROTECTED]>
Date: Sat, 21 Jun 2008 22:12:24 +0200


I'm curious at how many GCC developpers use non x86/_64 as their
main development machine (and how many non x86/_64 core they use).


I definitely am one.


How many core does your main development machine have?



One with only 512megs of memory. It does have two hardware thread  
though.


I forgot to mention that this is a multilib target with three  
different multilibs. This makes building libjava more than 50% of the  
time. It takes around 18 hours to do a bootstrap/test on this machine.


-- Pinski




Thanks,
Andrew Pinski

"relocation truncated to fit" error using Coldfire target.

[Luigi 'Comio' Mantellini]

Dear All,

I'm trying to compile the e2fs progs for a coldfire 547x cpu. I'm using the 
gcc4.3.1 compiler. 
I have this error and I don't understand what can be wrong:

make[5]: Entering directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[6]: Entering directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[6]: `lib/ext2fs/ext2_types.h' is up to date.
make[6]: Leaving directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[6]: Entering directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[6]: `lib/blkid/blkid_types.h' is up to date.
make[6]: Leaving directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[6]: Entering directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[6]: `lib/uuid/uuid_types.h' is up to date.
make[6]: Leaving directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
making all in e2fsck
make[6]: Entering directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39/e2fsck'
LD e2fsck.static
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_eqdf2.o):
 In function `__eqdf2':
/mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3895:
 relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
defined in .text section in 
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_nedf2.o):
 In function `__nedf2':
/mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3911:
 relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
defined in .text section in 
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_gedf2.o):
 In function `__gedf2':
/mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3943:
 relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
defined in .text section in 
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_ltdf2.o):
 In function `__ltdf2':
/mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3959:
 relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
defined in .text section in 
/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
collect2: ld returned 1 exit status
make[6]: *** [e2fsck.static] Error 1
make[6]: Leaving directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39/e2fsck'
make[5]: *** [all-progs-recursive] Error 1
make[5]: Leaving directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[4]: *** [all] Error 2
make[4]: Leaving directory 
`/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
make[3]: *** 
[/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39/.built] Error 2
make[3]: Leaving directory `/mnt/devel/openwrt/OpenWRT.git/package/e2fsprogs'
make[2]: *** [package/e2fsprogs/compile] Error 2
make[2]: Leaving directory `/mnt/devel/openwrt/OpenWRT.git'
make[1]: *** 
[/mnt/devel/openwrt/OpenWRT.git/staging_dir/m68k/stamp/.package_compile] Error 2
make[1]: Leaving directory `/mnt/devel/openwrt/OpenWRT.git'
make: *** [world] Error 2

To complete the picture, I'm using an OpenWRT building-environment with some 
patch in order to compile Gcc4.3.1 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559), binutils 2.18 and
uClibc0.9.29. If needed, I can provide any additional information.

Any ideas? What can I check to understand and resolve this issue?

Thanks in advance for any suggestion.


luigi


-- 
 __   Luigi Mantellini
   .'__'. R&D - Software
  (.'  '.)Industrie Dial Face S.p.A.
  ( :==: )Via Canzo, 4
  ('.__.')20068 Peschiera Borromeo (MI), Italy
   '.__.' Tel.: +39 02 5167 2813
  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: [EMAIL PROTECTED]
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
   B003 175F E979 907E 1650

GCC 4.3.2 Status Report (2008-06-22)

[Joseph S. Myers]

Status
==

The GCC 4.3 branch is open for commits under normal release branch
rules.  The 4.3.2 release is expected around 2008-08-06.

Quality Data


Priority  # Change from Last Report
--- ---
P18 +- 0
P2  112 -  2
P32 +- 0
--- ---
Total   122 -  2

Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-06/msg00321.html

The next report for the 4.3 branch will be sent by Richard.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: GCC 4.3.2 Status Report (2008-06-22)

[Paweł Sikora]

On Sunday 22 of June 2008 13:17:38 Joseph S. Myers wrote:
> Status
> ==
>
> The GCC 4.3 branch is open for commits under normal release branch
> rules.  The 4.3.2 release is expected around 2008-08-06.
>
> Quality Data
> 
>
> Priority# Change from Last Report
>   --- ---
> P1  8 +- 0
> P2112 -  2
> P3  2 +- 0
>   --- ---
> Total 122 -  2

there is one more bug reported in RedHat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=451068

Re: GCC 4.3.2 Status Report (2008-06-22)

[Jakub Jelinek]

On Sun, Jun 22, 2008 at 01:30:18PM +0200, Pawe?? Sikora wrote:
> On Sunday 22 of June 2008 13:17:38 Joseph S. Myers wrote:
> > Quality Data
> > 
> >
> > Priority  # Change from Last Report
> > --- ---
> > P18 +- 0
> > P2  112 -  2
> > P32 +- 0
> > --- ---
> > Total   122 -  2
> 
> there is one more bug reported in RedHat bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=451068

That is PR36533, already counted above.  It will be addressed within
a week.  We know what the bug is, just need to agree on where to fix it.

Jakub

Re: Should we remove java from the default bootstrap languages?

[NightStrike]

On 6/22/08, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Jun 22, 2008, at 2:08, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > On Jun 22, 2008, at 0:21, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
> > > > From: Laurent GUERBY <[EMAIL PROTECTED]>
> > > > Date: Sat, 21 Jun 2008 22:12:24 +0200
> > > > > I'm curious at how many GCC developpers use non x86/_64 as their
> > > > > main development machine (and how many non x86/_64 core they use).
> > > > I definitely am one.
> > > How many core does your main development machine have?
> > One with only 512megs of memory. It does have two hardware thread though.
> I forgot to mention that this is a multilib target with three different
> multilibs. This makes building libjava more than 50% of the time. It takes
> around 18 hours to do a bootstrap/test on this machine.


You know, you guys don't realize how easy you have it.  For the Win64
testsuite, all I test is c,c++,fortran, and objc (the library
testsuites don't work at all).  It takes over three days to run!  18
hours would be wonderful in comparison.

Re: Should we remove java from the default bootstrap languages?

[Jakub Jelinek]

On Sat, Jun 21, 2008 at 08:58:05PM +0200, Laurent GUERBY wrote:
> On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
> > On Sat, Jun 21, 2008 at 05:21, Andrew Haley <[EMAIL PROTECTED]> wrote:
> And for make -k check:
> 
> -j1 2h18
> -j2 1h11
> -j4 0h55
> -j6 0h44

For make check, it would perhaps help to split the langest runtest.exp
invocations (primarily check-gcc, maybe check-fortran and check-libstdc++-v3)
into two parts, so that make could schedule them concurrently with higher
make -jN -k check (e.g. for check-gcc run dg.exp in check-gcc-dg goal,
all the ohter *.exp's in check-gcc-other and check-gcc: check-gcc-dg 
check-gcc-other).

Jakub

Re: "relocation truncated to fit" error using Coldfire target.

[Luigi 'Comio' Mantellini]

Hi List,

I think that the problem is the same of this:

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00094.html

Starting form the patch proposed in the post above, I produced (with few
changes) the attached patch for gcc.4.3.1.

ciao

luigi

On dom, 2008-06-22 at 12:24 +0200, Luigi 'Comio' Mantellini wrote:
> Dear All,
> 
> I'm trying to compile the e2fs progs for a coldfire 547x cpu. I'm using the 
> gcc4.3.1 compiler. 
> I have this error and I don't understand what can be wrong:
> 
> make[5]: Entering directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[6]: Entering directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[6]: `lib/ext2fs/ext2_types.h' is up to date.
> make[6]: Leaving directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[6]: Entering directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[6]: `lib/blkid/blkid_types.h' is up to date.
> make[6]: Leaving directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[6]: Entering directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[6]: `lib/uuid/uuid_types.h' is up to date.
> make[6]: Leaving directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> making all in e2fsck
> make[6]: Entering directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39/e2fsck'
>   LD e2fsck.static
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_eqdf2.o):
>  In function `__eqdf2':
> /mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3895:
>  relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
> defined in .text section in 
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_nedf2.o):
>  In function `__nedf2':
> /mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3911:
>  relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
> defined in .text section in 
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_gedf2.o):
>  In function `__gedf2':
> /mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3943:
>  relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
> defined in .text section in 
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_ltdf2.o):
>  In function `__ltdf2':
> /mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/libgcc/../gcc/config/m68k/lb1sf68.asm:3959:
>  relocation truncated to fit: R_68K_PC16 against symbol `__cmpdf2_internal' 
> defined in .text section in 
> /mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1/lib/gcc/m68k-linux-uclibc/4.3.1/libgcc.a(_double.o)
> collect2: ld returned 1 exit status
> make[6]: *** [e2fsck.static] Error 1
> make[6]: Leaving directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39/e2fsck'
> make[5]: *** [all-progs-recursive] Error 1
> make[5]: Leaving directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[4]: *** [all] Error 2
> make[4]: Leaving directory 
> `/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39'
> make[3]: *** 
> [/mnt/devel/openwrt/OpenWRT.git/build_dir/m68k/e2fsprogs-1.39/.built] Error 2
> make[3]: Leaving directory `/mnt/devel/openwrt/OpenWRT.git/package/e2fsprogs'
> make[2]: *** [package/e2fsprogs/compile] Error 2
> make[2]: Leaving directory `/mnt/devel/openwrt/OpenWRT.git'
> make[1]: *** 
> [/mnt/devel/openwrt/OpenWRT.git/staging_dir/m68k/stamp/.package_compile] 
> Error 2
> make[1]: Leaving directory `/mnt/devel/openwrt/OpenWRT.git'
> make: *** [world] Error 2
> 
> To complete the picture, I'm using an OpenWRT building-environment with some 
> patch in order to compile Gcc4.3.1 (
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559), binutils 2.18 and
> uClibc0.9.29. If needed, I can provide any additional information.
> 
> Any ideas? What can I check to understand and resolve this issue?
> 
> Thanks in advance for any suggestion.
> 
> 
> luigi
> 

-- 
 __   Luigi Mantellini
   .'__'. R&D - Software
  (.'  '.)Industrie Dial Face S.p.A.
  ( :==: )Via Canzo, 4
  ('.__.')20068 Peschiera Borromeo (MI), Italy
   '.__.' 

Re: Should we remove java from the default bootstrap languages?

[Richard Guenther]

On Sun, Jun 22, 2008 at 4:04 AM, Richard Kenner
<[EMAIL PROTECTED]> wrote:
>> > An interesting question that I see as relevant here and for which I have no
>> > data is: what percentage of the time does a patch cause an error *only*
>> > in libjava?   I think you have to weigh the cost of the build of that
>> > library against the number of bugs that it finds.
>>
>> Happened to me multiple times.
>
> Is there a way to characterize the kinds of changes that are more likely
> to make this happen?  We see this with Ada, for example: many middle-end
> developers by now know which changes are most likely to potentially affect
> Ada and do an Ada build too for those cases.  Would this sort of approach
> work for Java as well?

libjava adds quite an amount of coverage on the general optimizers.  Most
of the time this was ICEs and miscompiles only happening for libjava but
not in the C/C++ testsuite.

Richard.

RE: Should we remove java from the default bootstrap languages?

[Dave Korn]

NightStrike wrote on 22 June 2008 12:57:

> On 6/22/08, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>> On Jun 22, 2008, at 2:08, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>>> On Jun 22, 2008, at 0:21, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
 On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
> From: Laurent GUERBY <[EMAIL PROTECTED]>
> Date: Sat, 21 Jun 2008 22:12:24 +0200
>> I'm curious at how many GCC developpers use non x86/_64 as their
>> main development machine (and how many non x86/_64 core they use).
> I definitely am one.
 How many core does your main development machine have?
>>> One with only 512megs of memory. It does have two hardware thread
>>> though. 
>> I forgot to mention that this is a multilib target with three different
>> multilibs. This makes building libjava more than 50% of the time. It
>> takes around 18 hours to do a bootstrap/test on this machine.
> 
> 
> You know, you guys don't realize how easy you have it.  For the Win64
> testsuite, all I test is c,c++,fortran, and objc (the library
> testsuites don't work at all).  It takes over three days to run!  18
> hours would be wonderful in comparison.


  Until very recently, my one and only main dev box was an 850MHz athlon
with 384Megs of memory on board.  Running full bootstraps and tests for
Cygwin could take a week.

  [  I've recently moved to a dual core athlon 64 with 4g ram.  It still
takes a couple of days but I haven't been using -j (ran into a build failure
the first time I tried and didn't have time to look into it) nor building
ada or libjava, so it's a lot smaller job.  ]

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Should we remove java from the default bootstrap languages?

[Ian Lance Taylor]

Jakub Jelinek <[EMAIL PROTECTED]> writes:

> On Sat, Jun 21, 2008 at 08:58:05PM +0200, Laurent GUERBY wrote:
>> On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
>> > On Sat, Jun 21, 2008 at 05:21, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> And for make -k check:
>> 
>> -j1 2h18
>> -j2 1h11
>> -j4 0h55
>> -j6 0h44
>
> For make check, it would perhaps help to split the langest runtest.exp
> invocations (primarily check-gcc, maybe check-fortran and check-libstdc++-v3)
> into two parts, so that make could schedule them concurrently with higher
> make -jN -k check (e.g. for check-gcc run dg.exp in check-gcc-dg goal,
> all the ohter *.exp's in check-gcc-other and check-gcc: check-gcc-dg 
> check-gcc-other).

I think it would only be a few days of work for somebody familiar with
Tcl to add -j support to DejaGNU.  I think that would be a very useful
contribution to gcc development.

Ian

Re: Should we remove java from the default bootstrap languages?

[Ian Lance Taylor]

Laurent GUERBY <[EMAIL PROTECTED]> writes:

> I noticed insn-attrtab compilation is about 5mn20s and probably
> explain about all of the not so perfect speedup: when I look at top it
> takes more than 1 minute per stage finishing alone. I've seen it up to 3
> minutes alone. There's a comment in the Makefile about trying to
> compile it earlier but it doesn't seem to work all the time
> (likely reason behind c,fortran faster than =c)

First I'll note that insn-attrtab.c is particularly slow for
x86/x86_64, presumably due to the many processor varieties and complex
scheduling.  It is much faster for other targets.

Compiling it earlier than it would otherwise be does work.  The
problem is that insn-attrtab.o depends on the generated file
insn-attr.h.  GNU make works by making a pass over the targets, and it
builds all the ones whose dependencies are already built.  Then it
makes another pass.  The effect is that all the objects which do not
depend upon insn-attr.h wind up getting built before insn-attrtab.o.

We could game the system to force insn-attrtab.o to be compiler even
earlier by adding false dependencies in the Makefile.

A cleaner approach would be to somehow change genattrtab.c to generate
multiple files.  Or, in general, to somehow invert the sense of the
functions to work as a switch on ix86_tune, rather than testing it in
every single conditional.  I'm guessing, but I think that inverting
the function that way should significantly reduce the number of basic
blocks and speed up compilation.

Ian

How should I disable vectorization test for AVR?

[Andy H]

For AVR I get failures of:

FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect 
"vectorized 1 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect 
"vectorized 1 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect "vectorized 
1 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-25.c scan-tree-dump-times vect 
"vectorized 2 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect 
"vectorized 1 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment 
of access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect 
"vectorized 1 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment 
of access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect 
"vectorized 1 loops" 1




For AVR there are no vectypes so it fails message test.

Q. Should I skip this test with target selector avr-*-* - OR use the 
effective keyword vect_cmdline_needed


Either will work, the latter is easy and more likely to work with future 
additions but as AVR does not have any vectors enabled by command line

or otherwise, the semantics are misleading.


Andy

Re: Should we remove java from the default bootstrap languages?

[NightStrike]

On 6/22/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Jakub Jelinek <[EMAIL PROTECTED]> writes:
>
> > On Sat, Jun 21, 2008 at 08:58:05PM +0200, Laurent GUERBY wrote:
> >> On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
> >> > On Sat, Jun 21, 2008 at 05:21, Andrew Haley <[EMAIL PROTECTED]> wrote:
> >> And for make -k check:
> >>
> >> -j1 2h18
> >> -j2 1h11
> >> -j4 0h55
> >> -j6 0h44
> >
> > For make check, it would perhaps help to split the langest runtest.exp
> > invocations (primarily check-gcc, maybe check-fortran and 
> > check-libstdc++-v3)
> > into two parts, so that make could schedule them concurrently with higher
> > make -jN -k check (e.g. for check-gcc run dg.exp in check-gcc-dg goal,
> > all the ohter *.exp's in check-gcc-other and check-gcc: check-gcc-dg 
> > check-gcc-other).
>
> I think it would only be a few days of work for somebody familiar with
> Tcl to add -j support to DejaGNU.  I think that would be a very useful
> contribution to gcc development.

I had looked into this when I first was confronted with the insane
amount of time required to test on a Windows platform (mostly due to
the overhead of ssh/sftp).  The biggest downside was that each
invocation of expect writes to a separate log file.

So for instance, if you invoke "make check-gcc" from the top level
makefile, this will spawn: check-gcc, check-fortran, check-objc,
check-c++, and check-libstdc++-v3 for the default Win64 target.  Each
make target has its own sum/log file, and make parallelizes at that
level.

If you were to have make break that up, you would have then an
additional set of sum/log files for every check-* make target.  If you
instead try to have expect break things up or parallelize a single
check-* target, you then have to deal with a sum file that is out of
order compared to any other run, and a log file at best that's just as
out-of-order, and at worst that has all of the output from the various
parallel tasks running into each other.


Now what you could do (though I don't know how "hackey" it is) would
be to run each .exp file separately and run a script to combine the
results after the fact and create a new table of results data and new
sum/log files.  I was working on doing that, and was deciding on awk
or perl as the language of choice to do such a thing.  We can already
specify via RUNTESTFLAGS a single exp file (and actually, a single
test in a single exp file) to run.  We could just do (pseudocode
example) expect file1.exp > out1.txt &; expect file2.exp > out2.txt &;
etc...

That would then allow multiple invocations of expect that would each
write to their own sum/logs.  Then at the end, you have to combine
them all so as to not be so untidy as to have tons of sum/log sets.
Combining them isn't a hugely difficult task.  It's just tedious when
you aren't that advanced at scripting.

Re: Should we remove java from the default bootstrap languages?

[Ralf Wildenhues]

* Ian Lance Taylor wrote on Sun, Jun 22, 2008 at 04:42:19PM CEST:
> 
> First I'll note that insn-attrtab.c is particularly slow for
> x86/x86_64, presumably due to the many processor varieties and complex
> scheduling.  It is much faster for other targets.
> 
> Compiling it earlier than it would otherwise be does work.  The
> problem is that insn-attrtab.o depends on the generated file
> insn-attr.h.  GNU make works by making a pass over the targets, and it
> builds all the ones whose dependencies are already built.  Then it
> makes another pass.  The effect is that all the objects which do not
> depend upon insn-attr.h wind up getting built before insn-attrtab.o.
> 
> We could game the system to force insn-attrtab.o to be compiler even
> earlier by adding false dependencies in the Makefile.

I would be surprised if just dependency ordering could improve things
for insn-attrtab on trunk further than this patch (a variant of which
was committed to trunk on 2008-04-03):


> A cleaner approach would be to somehow change genattrtab.c [...]

That sounds like the next logical step to me.

Cheers,
Ralf

Cross-compiler for Alpha architecture

[venetis]

Dear all,

I am trying to build a cross-compiler for an alphaev56-unknown-linux-gnu
system, using crosstool-ng. The host is a i686-unknown-linux-gnu.

After applying several patches (look in [1]), I managed to build a
tool-chain using binutils 2.18/gcc 4.2.3/linux kernel 2.6.24.7 and glibc
2.3.6 (with linuxthreads). However, I would like to use newer versions of
gcc (4.3.x) and glibc(>=2.6). Trying to build these, however, yields some
errors (initially in glibc and now in gcc).

I managed to get as far as described here:

http://sourceware.org/ml/libc-help/2008-06/msg00061.html [1]
http://sourceware.org/ml/libc-help/2008-06/msg00062.html

The errors in [1] are coming from glibc. Ryan Arnold replied with this
message:

http://sourceware.org/ml/libc-help/2008-06/msg00063.html

which solved the first problem described in [1]. However, I now get an
error further down in the build procedure, while trying to build gcc 4.3.1
for the target architecture:

source='/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber/dpd/decimal128.c'
object='decimal128.o' libtool=no i686-pc-linux-gnu-gcc 
-I/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber
-I.  -pipe -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual -pedantic -Wno-long-long 
-I/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber
-I.  -c
/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber/dpd/decimal128.c
[ALL  ]rm -f libdecnumber.a
[ALL  ]ar cru libdecnumber.a decNumber.o decContext.o decimal32.o
decimal64.o decimal128.o
[ALL  ]i686-pc-linux-gnu-ranlib libdecnumber.a
[ALL  ]make[1]: Leaving directory
`/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/libdecnumber'
[ALL  ]make[1]: Entering directory
`/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/gcc'
[ERROR]make[1]: *** No rule to make target `libgcc.mk'.  Stop.
[ALL  ]make[1]: Leaving directory
`/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/gcc'
[ERROR]Build failed in step 'Installing shared core C compiler'

I couldn't find any references to this problem in the mailing list
archives and the Web. Any ideas?

Thanks for your help!

Ioannis

Re: Should we remove java from the default bootstrap languages?

[Ralf Wildenhues]

* NightStrike wrote on Sun, Jun 22, 2008 at 06:14:22PM CEST:
> On 6/22/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >
> > I think it would only be a few days of work for somebody familiar with
> > Tcl to add -j support to DejaGNU.  I think that would be a very useful
> > contribution to gcc development.

> Now what you could do (though I don't know how "hackey" it is) would
> be to run each .exp file separately and run a script to combine the
> results after the fact and create a new table of results data and new
> sum/log files.

Has anybody ever looked at using threading capabilities of tcl directly?
Parallel DejaGNU could benefit other packages too.  There is a thread
pools package (tpool.html, linked from ) but I
have no idea how functional it is in practice; likely the GCC testsuite
would need at least a bit of restructuring, too.

Cheers,
Ralf (who'd love to look into it but I doesn't have time ATM)

Re: Should we remove java from the default bootstrap languages?

[Tom Tromey]

> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

Ralf> Has anybody ever looked at using threading capabilities of tcl directly?

At least Fedora compiles the system Tcl without threading enabled.
This has been attempted a few times over the years but apparently
always reverted due to bugs.

Tom

Re: Should we remove java from the default bootstrap languages?

[Tom Tromey]

> "Richard" == Richard Kenner <[EMAIL PROTECTED]> writes:

>> IME, bugs found during libjava have been also triggered during
>> libstdc++ and/or C.  Though several folks at the summit mentioned that
>> they had found bugs triggered only by libjava.

Richard> To me, as I said, this is the key issue: how often do we have
Richard> such bugs?

I don't know, but one option open to us is to try this approach and
then revert it if we see "too many" regressions.

Tom

Re: Should we remove java from the default bootstrap languages?

[Jeff Law]

Richard Guenther wrote:

On Sat, Jun 21, 2008 at 12:50 AM, Richard Kenner
<[EMAIL PROTECTED]> wrote:

Fundamentally, our philosophy has been to catch errors *before* they get
into the repository.  Sure one day of breaking the trunk isn't so bad, but
when it breaks it affects hundreds of developers and it adds up.  Everyone
separately either stops and waits, or tracks down which patch it was and
reverts it so they can continue working.

An interesting question that I see as relevant here and for which I have no
data is: what percentage of the time does a patch cause an error *only*
in libjava?   I think you have to weigh the cost of the build of that
library against the number of bugs that it finds.


Happened to me multiple times.

Similarly.



The thing to tackle is to make libjava build more parallel.

I think this applies across the board, including the testsuites.

jeff

Re: Should we remove java from the default bootstrap languages?

[Daniel Jacobowitz]

On Sun, Jun 22, 2008 at 07:13:03PM +0200, Ralf Wildenhues wrote:
> Has anybody ever looked at using threading capabilities of tcl directly?
> Parallel DejaGNU could benefit other packages too.  There is a thread
> pools package (tpool.html, linked from ) but I
> have no idea how functional it is in practice; likely the GCC testsuite
> would need at least a bit of restructuring, too.

[Insert QMTest plug here]

I don't know for sure whether the QMTest support in the testsuite is
still good... we use QMTest internally, but not for GCC at the moment.
I'd love to get it working again, at least for native.  That can
parallelize tests as fine-grained as you wish, and present consistent logs.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Should we remove java from the default bootstrap languages?

[Joseph S. Myers]

On Sun, 22 Jun 2008, Daniel Jacobowitz wrote:

> On Sun, Jun 22, 2008 at 07:13:03PM +0200, Ralf Wildenhues wrote:
> > Has anybody ever looked at using threading capabilities of tcl directly?
> > Parallel DejaGNU could benefit other packages too.  There is a thread
> > pools package (tpool.html, linked from ) but I
> > have no idea how functional it is in practice; likely the GCC testsuite
> > would need at least a bit of restructuring, too.
> 
> [Insert QMTest plug here]
> 
> I don't know for sure whether the QMTest support in the testsuite is
> still good... we use QMTest internally, but not for GCC at the moment.
> I'd love to get it working again, at least for native.  That can
> parallelize tests as fine-grained as you wish, and present consistent logs.

I'm pretty sure it's very bitrotten; it depends on an externally 
maintained emulation of testsuite logic (qmtest_gcc), and the testsuite 
has moved on a *long* way since in terms of custom Tcl code to control 
which tests apply on what systems, with what options (target-supports* 
etc.).  Unless people wish to put in the work to make it operational again 
for 4.4, I think the code in GCC should be removed (not deprecated, it's 
too far bitrotten for that).  (If people do wish to use this code long 
term, qmtest_gcc probably needs to be an integrated part of GCC, not a 
separate package.)

A cleanup I'd like to see, regardless of any move to QMTest, is making all 
testing installed testing (via installing in a temporary directory in the 
build tree).  The testsuite should not need to know how to tell the 
compiler to find bits of itself in a build tree, only "make install" 
should need to know how to put such bits together in an install tree so 
the compiler can find them without special options.  (Worse, core DejaGnu 
itself has hardcoded knowledge about how to locate bits of GCC source and 
build trees, some of it long obsolete.  It's unfortunate that qmtest_gcc 
has such logic as well, as needed when emulating the DejaGnu logic, but at 
least QMTest and qmtc don't.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Should we remove java from the default bootstrap languages?

[Andrew Pinski]

On Fri, Jun 20, 2008 at 1:56 PM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> Ugh, I think this is a terrible idea.  It took me all of zero days to find
> an example of libjava breaking when someone didn't test it:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01351.html

Actually that patch caused a bootstrap failure even before libjava was
compiled.  See http://gcc.gnu.org/ml/gcc-regression/2008-06/txt7.txt
for the log.  Though it really depends on memory layout and other
factors when (and if) the build fails since it was an use after a
free.

So in summary that patch is not a good example of breaking libjava at all.

Thanks,
Andrew Pinski

Re: Should we remove java from the default bootstrap languages?

[Andrew Pinski]

On Fri, Jun 20, 2008 at 1:56 PM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> Ugh, I think this is a terrible idea.  It took me all of zero days to find
> an example of libjava breaking when someone didn't test it:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01351.html

This is a bad example for libjava breakage as it is an use after
freeing.  See http://gcc.gnu.org/ml/gcc-regression/2008-06/msg00013.html
and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36596.  The segfault
is very dependent on the version of glibc and kernel you are using,
etc.  It is very dependent on the actual memory layout of the
application.  Just it was failing during compiling for libjava, not
earlier like it was for Geoff's regression tester.

Thanks,
Andrew Pinski

Re: Should we remove java from the default bootstrap languages?

[Ben Elliston]

On Fri, 2008-06-20 at 17:05 -0400, Diego Novillo wrote:

> On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> 
> > That aside, our current policy already allows e.g. not testing java if
> > your change is to a part of the compiler that can't possible affect it.
> 
> I didn't make it completely clear, but my suggestion was mostly to
> help us middle/back-end hackers.

One practice I've started using is to use two build trees.  One I use in
my day-to-day work with only the C and C++ front-ends.  I have another
build tree that has all languages enabled that is built and tested
overnight (before I commit).  This means my changes get tested better,
but without me incurring the build delays.

Ben

Re: gcc-in-cxx branch created

[Bruno Haible]

Dear Ian,

A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer

  "C++ is too complicated!"

with

  "Maintainers will ensure that gcc continues to be maintainable."

C++ has, for example, 12 different ways to represent or invoke a function.
It has no buikt-in typesafe "enum"s. Sooner or later developers will think
more about
  "should this better be a member function or a static inline function?"
  or "how do I make dynamic_cast work with my enum sets?"
than about the algorithm they want to implement.

How can maintainers ensure this does not happen?

You cannot pick a set of C++ features and say "we will only use these
elementary C++ features, not the complex ones". It won't work because

  1) The compiler forces the developers to use more and more advanced features.
 As soon as you want to use classes, you must learn about inline, const,
 constructors and destructors. People will request that you use namespaces.
 Multiple inheritance is not on your wishlist in the beginning, but you
 will likely use it sooner or later. You can be lucky if you avoid virtual
 inheritance...

  2) Year over year, advanced developers will start relying on even more fancy
 features: templates, exceptions, 'explicit' constructors, Koenig lookup,
 etc. Less advanced developers would like to say "no", but their voice
 doesn't count as much as the voice of advanced developers. So year after
 year, the full set of C++ features gets used.

Bruno

Re: Should we remove java from the default bootstrap languages?

[Ben Elliston]

On Sat, 2008-06-21 at 10:58 +0200, Ralf Wildenhues wrote:

> IIRC, then objects in libjava were built from lists of source files as a
> means to avoid per-object overhead of libtool and some other stuff, and
> to produce a bit better code[1].  Now, at least libtool compile mode
> overhead should be a fair bit lower than back then (upstream is a bit
> better, if that turns out to be significant, GCC could sync again).

A few years ago, I hacked the libjava Makefiles to eliminate the use of
libtool of Linux systems.  It cut 20 minutes from the build time on my
(at the time) modern hardware.

Ben

Re: Should we remove java from the default bootstrap languages?

[Ben Elliston]

On Sun, 2008-06-22 at 19:13 +0200, Ralf Wildenhues wrote:

> Has anybody ever looked at using threading capabilities of tcl directly?
> Parallel DejaGNU could benefit other packages too.  There is a thread
> pools package (tpool.html, linked from ) but I
> have no idea how functional it is in practice; likely the GCC testsuite
> would need at least a bit of restructuring, too.

Yes, I tried it about 5 years ago.

I used Tcl safe interpreters to run each .exp script in isolation.  It
immediately raised some problems, namely that you have to decide what
variables and procs should be available to the interpreter.  This is
nice, in that it makes you decide what the public interface between
DejaGnu and a test script should be.  Its failing is that DejaGnu does
not have well-defined interfaces.  ;-)

In principle, it should work.  It was just a lot more work than I
bargained for.  Keep in mind that GCC does not have a huge number
of .exp scripts.  Some (eg. execute.exp) run many individual tests and,
if one wanted to, these scripts could be parallelised.  This just means
that there won't be wins for other scripts or other packages using
DejaGnu.

Ben

Re: Should we remove java from the default bootstrap languages?

[Ben Elliston]

On Sun, 2008-06-22 at 07:32 -0700, Ian Lance Taylor wrote:

> I think it would only be a few days of work for somebody familiar with
> Tcl to add -j support to DejaGNU.  I think that would be a very useful
> contribution to gcc development.

What did you have in mind, Ian?  That DejaGnu would run .exps in
parallel?  Perhaps what I tried is more complicated than what you are
proposing.

Cheers, Ben

Re: Should we remove java from the default bootstrap languages?

[Kaveh R. GHAZI]

On Sat, 21 Jun 2008, Andrew Haley wrote:

> Steven Bosscher wrote:
> > On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> >> Fundamentally, our philosophy has been to catch errors *before* they get
> >> into the repository.  Sure one day of breaking the trunk isn't so bad, but
> >> when it breaks it affects hundreds of developers and it adds up.
> >
> > But, for languages that are not enabled by default, no-one is directly
> > affected except the people who might have caused the breakage, and the
> > people who are working on the broken part of the compiler.
>
> They are directly affected by these errors, but they don't know: the 
> middle-end
> bugs revealed by the libjava build and testing are real bugs in other 
> languages
> too, they're just not detected by bootstrap & test.
> Andrew.

Andrew,

I think you hit the heart of this argument.  The current bootstrap and
testsuite doesn't ensure complete code coverage testing for GCC.  Having
more languages, libraries and their associated testsuites uncovers more
bugs that would otherwise go undetected and remain hidden in the core
middle-end.

These hidden bugs could possible be triggered in C, C++ and/or fortran,
but our current testsuite may not trigger them by chance whereas java or
objc++ or whatever else we include might expose them during bootstrap.

The argument for switching off java (that it takes too long) could be
applied to C++ as well.  The libstdc++ testsuite takes longer for me than
the java one.  But I don't recommend eliminating that either.  How
widespread a language is used is not the determining factor in whether we
should activate it by default.  Many people have vouched for the fact that
java exposes middle-end bugs not uncovered by the other languages.  That
is where the worth of including it is found.

IMHO, having more languages and testsuites in the bootstrap process
enhances the quality of GCC.  I sympathize with the problems of regtest
duration.  I believe some of this could be addressed through making things
run in parallel better.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

PR 36599

[Jack Howarth]

Richard,
 There is a regression in the induct polyhedron benchmark execution
when gfortran compiled with -ffast-math -O3 introduced with gcc 4.3
that isn't present in gcc 4.2.4.

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

According to the SuSe polyhedron benchmark servers, the bottleneck
in the induct benchmark was eliminated between 2008-04-27 and
2008-04-28 in gcc trunk. My guess is that your changes...

r134730 | rguenth | 2008-04-27 12:27:08 -0400 (Sun, 27 Apr 2008) | 42 lines

2008-04-27  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/18754
PR tree-optimization/34223
* tree-pass.h (pass_complete_unrolli): Declare.
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Print
loop size before and after unconditionally of UL_NO_GROWTH in effect.
Rewrite loop into loop closed SSA form if it is not already.
(tree_unroll_loops_completely): Re-structure to iterate over
innermost loops with intermediate CFG cleanups.
Unroll outermost loops only if requested or the code does not grow
doing so.
* tree-ssa-loop.c (gate_tree_vectorize): Don't shortcut if no
loops are available.
(tree_vectorize): Instead do so here.
(tree_complete_unroll): Also unroll outermost loops.
(tree_complete_unroll_inner): New function.
(gate_tree_complete_unroll_inner): Likewise.
(pass_complete_unrolli): New pass.
* tree-ssa-loop-manip.c (find_uses_to_rename_use): Only record
uses outside of the loop.
(tree_duplicate_loop_to_header_edge): Only verify loop-closed SSA
form if it is available.  
* tree-flow.h (tree_unroll_loops_completely): Add extra parameter.
* passes.c (init_optimization_passes): Schedule complete inner
loop unrolling pass before the first CCP pass after final inlining.

* gcc.dg/tree-ssa/loop-36.c: New testcase.
* gcc.dg/tree-ssa/loop-37.c: Likewise.
* gcc.dg/vect/vect-118.c: Likewise.
* gcc.dg/Wunreachable-8.c: XFAIL bogus warning.
* gcc.dg/vect/vect-66.c: Increase loop trip count.
* gcc.dg/vect/no-section-anchors-vect-66.c: Likewise.
* gcc.dg/vect/no-section-anchors-vect-69.c: Likewise.
* gcc.dg/vect/vect-76.c: Likewise.
* gcc.dg/vect/vect-outer-6.c: Likewise.
* gcc.dg/vect/vect-outer-1.c: Likewise.
* gcc.dg/vect/vect-outer-1a.c: Likewise.
* gcc.dg/vect/vect-11a.c: Likewise.
* gcc.dg/vect/vect-shift-1.c: Likewise.
* gcc.target/i386/vectorize1.c: Likewise.


...solved this performance regression. Is it possible that these changes could
be backported to gcc 4.3.2 to eliminate the performance regression in gcc 4.3
compared to gcc 4.2?
 Jack

Re: Should we remove java from the default bootstrap languages?

[NightStrike]

On 6/22/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> IMHO, having more languages and testsuites in the bootstrap process
> enhances the quality of GCC.  I sympathize with the problems of regtest
> duration.  I believe some of this could be addressed through making things
> run in parallel better.

I think it could also be addressed with the gcc compile farm.  I
thought that there was some place where we could put patches, and they
would be automatically picked up and tested by some sort of automatic
scripts  am I dreaming about that?

Re: Should we remove java from the default bootstrap languages?

[Laurent GUERBY]

On Sun, 2008-06-22 at 21:57 -0400, NightStrike wrote:
> On 6/22/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > IMHO, having more languages and testsuites in the bootstrap process
> > enhances the quality of GCC.  I sympathize with the problems of regtest
> > duration.  I believe some of this could be addressed through making things
> > run in parallel better.
> 
> I think it could also be addressed with the gcc compile farm.  I
> thought that there was some place where we could put patches, and they
> would be automatically picked up and tested by some sort of automatic
> scripts  am I dreaming about that?

Sebastian already write a script to do that, see "Automatic bootstrap
and regression testing" on http://gcc.gnu.org/wiki/CompileFarm
(might not be up to date, Sebastian ?)

BTW testsuite timings data on compile farm 8 core barcelona:

-j8 check =c
1679.16user 568.21system 32:10.07elapsed 116%CPU

-j8 =c,ada check
5748.11user 224.91system 16:11.46elapsed 614%CPU

-j8 =c,c++ check
4445.12user 915.01system 33:12.87elapsed 268%CPU

-j8 =c,java (,c++ implied) check
4921.19user 1068.66system 34:20.50elapsed 290%CPU

Laurent

Re: gcc-in-cxx branch created

[Chris Lattner]

On Jun 22, 2008, at 4:24 PM, Bruno Haible wrote:


Dear Ian,

A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer

 "C++ is too complicated!"

with

 "Maintainers will ensure that gcc continues to be maintainable."

C++ has, for example, 12 different ways to represent or invoke a  
function.
It has no buikt-in typesafe "enum"s. Sooner or later developers will  
think

more about
 "should this better be a member function or a static inline  
function?"

 or "how do I make dynamic_cast work with my enum sets?"
than about the algorithm they want to implement.

How can maintainers ensure this does not happen?


What is your suggestion, stay with C?  It doesn't have type safe enums  
either.


-Chris

Re: Should we remove java from the default bootstrap languages?

[Ralf Wildenhues]

* Ben Elliston wrote on Mon, Jun 23, 2008 at 01:58:38AM CEST:
> On Sat, 2008-06-21 at 10:58 +0200, Ralf Wildenhues wrote:
> 
> > IIRC, then objects in libjava were built from lists of source files as a
> > means to avoid per-object overhead of libtool and some other stuff, and
> > to produce a bit better code[1].  Now, at least libtool compile mode
> > overhead should be a fair bit lower than back then (upstream is a bit
> > better, if that turns out to be significant, GCC could sync again).
> 
> A few years ago, I hacked the libjava Makefiles to eliminate the use of
> libtool of Linux systems.  It cut 20 minutes from the build time on my
> (at the time) modern hardware.

Current git Libtool compile mode is a lot faster than 1.5.x was.
Anyway its overhead in libjava is noise ATM, so that's not an issue.

Cheers,
Ralf

Re: Should we remove java from the default bootstrap languages?

[NightStrike]

On 6/23/08, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > I think it could also be addressed with the gcc compile farm.  I
> > thought that there was some place where we could put patches, and they
> > would be automatically picked up and tested by some sort of automatic
> > scripts  am I dreaming about that?
>
> Sebastian already write a script to do that, see "Automatic bootstrap
> and regression testing" on http://gcc.gnu.org/wiki/CompileFarm
> (might not be up to date, Sebastian ?)

Ok, maybe that can at least for the time being alleviate some of the concerns?

Re: gcc-in-cxx branch created

[Arnaud Charlet]

>> How can maintainers ensure this does not happen?
> 
> What is your suggestion, stay with C?  It doesn't have type safe enums 
> either.

One possibility is to do what we do for Ada: have a style/coding checker
built into the compiler (C++ front-end) as a special switch, and enable this
switch during bootstrap, so that any such coding style violation is transformed
into an error (actually a warning, transformed then into an error with -Werror).

Arno