Re: GCC 4.3 target deprecation proposals

[Jan-Benedict Glaw]

On Mon, 2008-01-21 22:55:26 -0800, Matt Thomas <[EMAIL PROTECTED]> wrote:
> On Jan 21, 2008, at 3:01 PM, Ben Elliston wrote:
> > My understanding is that NetBSD port to the vax is very much alive and
> > maintained.  Thus, I expect that those users (eg Matt Thomas) would  
> > like
> > to see the GCC port retained.
> 
> We would.  I have gcc working with gcc4.3 but gcc's use mpfr/gmp has  
> made
> native test impossible since neither work on vax/elf.  I don't have time
> to make them work.

I do have a crude patch to ELFify the assembly parts. However,
upstream told me that it wouldn't be accepted since it would break
older setups and that M4 magic should be used to sort out the %
story...

I was able to canadian-build a target=host vax-linux-uclibc compiler with
that (plus linux-specific patches) using a i686-linux-gnu build
machine.

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
  Signature of:   Wenn ich wach bin, träume ich.
  the second  :


signature.asc
Description: Digital signature

Re: GCC 4.3 target deprecation proposals

[Jan-Benedict Glaw]

On Tue, 2008-01-22 13:22:51 +, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Jan 2008, Paolo Bonzini wrote:
> > > I work for a company that makes significant use of gcc to target vax.
> > > The people involved are users, not developers, of gcc.  Does any part
> > > of the deprecation requirements take into account user base, or just
> > > developer base?
> > 
> > Neither, actually.  It's tester base that counts the most.
> 
> Indeed, testing is needed to provide evidence that a target works, but in 
> practice some developer work is needed to fix problems that show up in 
> testing (for example, target-specific problems exposed by the df work) and 
> without such work target architectures are unlikely to remain working well 
> between major releases.  However, I only looked to see if there was any 
> development on a platform if I saw there had been no testing at all 
> (posted to gcc-testresults) since the start of 2007.

When I had move time available (and I hope that this'll be the case
again), I ran a vax-linux-uclibc build every 4h to catch breaking
patches early.

For all others who are thinking about stepping up as a maintainer:
You'll loose eons of time if you don't do something similar,
especially for those targets that have virtually no users. It's quite
time consuming to check the last two months of commits for candidates
that broke your build.

Build often, build automatically, and keep the commit emails. For GCC
as well as the binutils and your libc.

I'm quite interested in the VAX target, specifically the Linux bits
I'm having around, but I'm unsure about my current time constraints.
Right now, I wouldn't do promises on that, but I'd be willing to look
into upcoming problems.

Some SIMH instance with a CURRENT NetBSD would probably be helpful and
if somebody helps me to get a NetBSD up'n'running with SIMH, I'd offer
to put my auto-building scripts in there.  NetBSD is at least a
somewhat complete OS, while Linux is still flanky and needs more work,
especially with GNU libc and TLS...

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of: Gib Dein Bestes. Dann übertriff Dich selbst!
the second  :


signature.asc
Description: Digital signature

Re: GCC 4.3 target deprecation proposals

[Jan-Benedict Glaw]

On Tue, 2008-01-22 10:31:35 -0800, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 22, 2008 at 10:49:19AM +0100, Paolo Bonzini wrote:
> > >I work for a company that makes significant use of gcc to target vax.
> > >The people involved are users, not developers, of gcc.  Does any part
> > >of the deprecation requirements take into account user base, or just
> > >developer base?
> > 
> > Neither, actually.  It's tester base that counts the most.
> 
> So if you're a vax user, you can help keep the vax port alive by helping
> to test it, reporting bugs, and testing proposed fixes.  That's no
> guarantee, by the way, as volunteers are still needed to implement
> the fixes.  Your company might want to consider contributing either
> staff time or money to pay a consultant to help with maintaining the
> vax port if it's important to you.

Okay...  So I'll try to get a NetBSD installation in SIMH running
these days. Matt et al, if you have some beforehand tips for me (like
choosing the "best" HDD types etc.) it would be nice if you would drop
me an email.

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of:  Fortschritt bedeutet, einen Schritt so zu machen,
the second  :   daß man den nächsten auch noch machen kann.


signature.asc
Description: Digital signature

Re: GCC 4.3 target deprecation proposals

[Jan-Benedict Glaw]

On Wed, 2008-01-23 12:09:10 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> I do have a crude patch to ELFify the assembly parts. However,

This was ment to be attached...

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of:   Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second  :   Langsam möchte ich mal wieder weiterträumen können.
 -- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de)
--- gmp-4.2.1/mpn/vax/addmul_1.s~	2006-10-24 21:53:39.0 +0200
+++ gmp-4.2.1/mpn/vax/addmul_1.s	2006-10-25 08:25:24.0 +0200
@@ -1,7 +1,7 @@
 # VAX __gmpn_addmul_1 -- Multiply a limb vector with a limb and add
 # the result to a second limb vector.
 
-# Copyright 1992, 1994, 1996, 2000 Free Software Foundation, Inc.
+# Copyright 1992, 1994, 1996, 2000, 2006 Free Software Foundation, Inc.
 
 # This file is part of the GNU MP Library.
 
@@ -29,98 +29,99 @@
 
 .text
 	.align 1
-.globl ___gmpn_addmul_1
-___gmpn_addmul_1:
+.globl __gmpn_addmul_1
+.type __gmpn_addmul_1, @function
+__gmpn_addmul_1:
 	.word	0xfc0
-	movl	12(ap),r4
-	movl	8(ap),r8
-	movl	4(ap),r9
-	movl	16(ap),r6
+	movl	12(%ap),%r4
+	movl	8(%ap),%r8
+	movl	4(%ap),%r9
+	movl	16(%ap),%r6
 	jlss	s2_big
 
-	clrl	r3
-	incl	r4
-	ashl	$-1,r4,r7
-	jlbc	r4,L1
-	clrl	r11
+	clrl	%r3
+	incl	%r4
+	ashl	$-1,%r4,%r7
+	jlbc	%r4,L1
+	clrl	%r11
 
 # Loop for S2_LIMB < 0x8000
-Loop1:	movl	(r8)+,r1
+Loop1:	movl	(%r8)+,%r1
 	jlss	L1n0
-	emul	r1,r6,$0,r2
-	addl2	r11,r2
-	adwc	$0,r3
-	addl2	r2,(r9)+
-	adwc	$0,r3
-L1:	movl	(r8)+,r1
+	emul	%r1,%r6,$0,%r2
+	addl2	%r11,%r2
+	adwc	$0,%r3
+	addl2	%r2,(%r9)+
+	adwc	$0,%r3
+L1:	movl	(%r8)+,%r1
 	jlss	L1n1
-L1p1:	emul	r1,r6,$0,r10
-	addl2	r3,r10
-	adwc	$0,r11
-	addl2	r10,(r9)+
-	adwc	$0,r11
+L1p1:	emul	%r1,%r6,$0,%r10
+	addl2	%r3,%r10
+	adwc	$0,%r11
+	addl2	%r10,(%r9)+
+	adwc	$0,%r11
 
-	sobgtr	r7,Loop1
-	movl	r11,r0
+	sobgtr	%r7,Loop1
+	movl	%r11,%r0
 	ret
 
-L1n0:	emul	r1,r6,$0,r2
-	addl2	r11,r2
-	adwc	r6,r3
-	addl2	r2,(r9)+
-	adwc	$0,r3
-	movl	(r8)+,r1
+L1n0:	emul	%r1,%r6,$0,%r2
+	addl2	%r11,%r2
+	adwc	%r6,%r3
+	addl2	%r2,(%r9)+
+	adwc	$0,%r3
+	movl	(%r8)+,%r1
 	jgeq	L1p1
-L1n1:	emul	r1,r6,$0,r10
-	addl2	r3,r10
-	adwc	r6,r11
-	addl2	r10,(r9)+
-	adwc	$0,r11
+L1n1:	emul	%r1,%r6,$0,%r10
+	addl2	%r3,%r10
+	adwc	%r6,%r11
+	addl2	%r10,(%r9)+
+	adwc	$0,%r11
 
-	sobgtr	r7,Loop1
-	movl	r11,r0
+	sobgtr	%r7,Loop1
+	movl	%r11,%r0
 	ret
 
 
-s2_big:	clrl	r3
-	incl	r4
-	ashl	$-1,r4,r7
-	jlbc	r4,L2
-	clrl	r11
+s2_big:	clrl	%r3
+	incl	%r4
+	ashl	$-1,%r4,%r7
+	jlbc	%r4,L2
+	clrl	%r11
 
 # Loop for S2_LIMB >= 0x8000
-Loop2:	movl	(r8)+,r1
+Loop2:	movl	(%r8)+,%r1
 	jlss	L2n0
-	emul	r1,r6,$0,r2
-	addl2	r11,r2
-	adwc	r1,r3
-	addl2	r2,(r9)+
-	adwc	$0,r3
-L2:	movl	(r8)+,r1
+	emul	%r1,%r6,$0,%r2
+	addl2	%r11,%r2
+	adwc	%r1,%r3
+	addl2	%r2,(%r9)+
+	adwc	$0,%r3
+L2:	movl	(%r8)+,%r1
 	jlss	L2n1
-L2p1:	emul	r1,r6,$0,r10
-	addl2	r3,r10
-	adwc	r1,r11
-	addl2	r10,(r9)+
-	adwc	$0,r11
+L2p1:	emul	%r1,%r6,$0,%r10
+	addl2	%r3,%r10
+	adwc	%r1,%r11
+	addl2	%r10,(%r9)+
+	adwc	$0,%r11
 
-	sobgtr	r7,Loop2
-	movl	r11,r0
+	sobgtr	%r7,Loop2
+	movl	%r11,%r0
 	ret
 
-L2n0:	emul	r1,r6,$0,r2
-	addl2	r11,r2
-	adwc	r6,r3
-	addl2	r2,(r9)+
-	adwc	r1,r3
-	movl	(r8)+,r1
+L2n0:	emul	%r1,%r6,$0,%r2
+	addl2	%r11,%r2
+	adwc	%r6,%r3
+	addl2	%r2,(%r9)+
+	adwc	%r1,%r3
+	movl	(%r8)+,%r1
 	jgeq	L2p1
-L2n1:	emul	r1,r6,$0,r10
-	addl2	r3,r10
-	adwc	r6,r11
-	addl2	r10,(r9)+
-	adwc	r1,r11
+L2n1:	emul	%r1,%r6,$0,%r10
+	addl2	%r3,%r10
+	adwc	%r6,%r11
+	addl2	%r10,(%r9)+
+	adwc	%r1,%r11
 
-	sobgtr	r7,Loop2
-	movl	r11,r0
+	sobgtr	%r7,Loop2
+	movl	%r11,%r0
 	ret
--- gmp-4.2.1/mpn/vax/add_n.s~	2006-10-24 21:48:09.0 +0200
+++ gmp-4.2.1/mpn/vax/add_n.s	2006-10-25 08:33:00.0 +0200
@@ -1,7 +1,7 @@
 # VAX __gmpn_add_n -- Add two limb vectors of the same length > 0 and store
 # sum in a third limb vector.
 
-# Copyright 1999, 2000 Free Software Foundation, Inc.
+# Copyright 1999, 2000, 2006 Free Software Foundation, Inc.
 
 # This file is part of the GNU MP Library.
 
@@ -29,33 +29,34 @@
 
 .text
 	.align 1
-.globl ___gmpn_add_n
-___gmpn_add_n:
+.globl __gmpn_add_n
+.type __gmpn_add_n, @function
+__gmpn_add_n:
 	.word	0x0
-	movl	16(ap),r0
-	movl	12(ap),r1
-	movl	8(ap),r2
-	movl	4(ap),r3
-	mnegl	r0,r5
-	addl2	$3,r0
-	ashl	$-2,r0,r0	# unroll loop count
-	bicl2	$-4,r5		# mask out low 2 bits
-	movaq	(r5)[r5],r5	# 9x
-	jmp	Loop(r5)
-
-Loop:	movl	(r2)+,r4
-	adwc	(r1)+,r4
-	movl	r4,(r3)+
-	movl	(r2)+,r4
-	adwc	(r1)+,r4
-	movl	r4,(r3)+
-	movl	(r2)+,r4
-	adwc	(r1)+,r4
-	movl	r4,(r3)+
-	movl	(r2)+,r4
-	adwc	(r1)+,r4
-	movl	r4,(r3)+
-	sobgtr	r0,Loop
+	movl	16(%ap),%r0
+	movl	12(%ap),%r1
+	movl	8(%ap),%r2
+	movl	4(%ap),%r3
+	mnegl	%r0,%r5
+	addl2	$3,%r0
+	ashl	$-2,%r0,%r0	# unroll loop count
+	bicl2	$-4,%r5		# mask out low 2 bits
+	movaq	(%r5)[%r5],%r5	# 9x
+	jmp	Loop(%r5)
+
+Loop:	movl	(%r2)+,%r4
+	adwc	(%r1)+,%r4
+	movl	%r4,(%r3)+
+	movl	(%r2)+,%r4
+	adwc	(%r1)+,%r4
+	movl	%r4,(%

Mainline is now regression and documentation fixes only

[Richard Guenther]

As we now reached the goal of less than 100 open serious regressions
against GCC 4.3, we are as of now in regression and documentation fixes
only mode.  This means that for patches going on the trunk the same
rules as for release branches apply.

The next milestone before the release of GCC 4.3.0 is to get down
the priority one (P1) regressions against GCC 4.3 down to zero.  At
the point we reach that goal, either by fixing all P1 bugs or by
downgrading less important ones to P2, the mainline will be freezed
to prepare for a release candidate.  Around the same time we will
branch and the opening of stage1 for GCC 4.4 development will be
announced.

There are 5 P1 bugs open against GCC 4.3, one of it has patches,
three of them are C++ regressions assigned to Mark and one bug
does not seem likely to be fixed (PR31529), which makes it a likely
candidate for downgrading.

I will update the GCC frontpage with the trunk state asap.

Thanks,
Richard.

Re: GCC 4.3 target deprecation proposals

[Jan-Benedict Glaw]

On Wed, 2008-01-23 12:18:31 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-22 10:31:35 -0800, Joe Buck <[EMAIL PROTECTED]> wrote:
> > So if you're a vax user, you can help keep the vax port alive by helping
> > to test it, reporting bugs, and testing proposed fixes.  That's no
> > guarantee, by the way, as volunteers are still needed to implement
> > the fixes.  Your company might want to consider contributing either
> > staff time or money to pay a consultant to help with maintaining the
> > vax port if it's important to you.
> 
> Okay...  So I'll try to get a NetBSD installation in SIMH running
> these days. Matt et al, if you have some beforehand tips for me (like
> choosing the "best" HDD types etc.) it would be nice if you would drop
> me an email.

Most specific questions:

  - What is the largest HDD SIMH supports? There seems to be RA92
support, but that's only 1.5GB.  With today's software, I guess
the build requirements (checked-out trees of the software incl.
SCM metadata, ...) are way above that :)

What's the best way to get a "real" amount of storage into NetBSD
on SIMH? NFS-mounting something from outside?

  - The NetBSD SIMH HOWTO
(http://www.netbsd.org/ports/vax/emulator-howto.html) refers to
load the ka655.bin eprom image, but upstream SIMH "only" contains
the hacked version (ka655x.bin), which supports more RAM. Is it
okay to assume NetBSD will accept this hacked ROM and give me as
much RAM inside the instance as possible with it?

Thanks, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
 Signature of:Arroganz verkürzt fruchtlose Gespräche.
 the second  :   -- Jan-Benedict Glaw


signature.asc
Description: Digital signature

bootstrap failed for GCC 4.2.3 on x86-unknown-linux-gnu

[Manuel López-Ibáñez]

Hi,

I tried bootstrapping GCC 4.2.3 on x86-unknown-linux-gnu with the
following configure:

 /home/manuel/src/trunk/configure
--prefix=/home/manuel/./131745/install --enable-languages=all
--enable-decimal-float
--with-mpfr=/home/ghazi/gcc-testing/lib/422-230/

But it failed.

The last lines in the output are:

Adding multilib support to Makefile in /home/manuel/src/trunk/libmudflap
multidirs=32
with_multisubdir=
Running configure in multilib subdirs 32
pwd: /home/manuel/131745M/build/x86_64-unknown-linux-gnu/libmudflap
Running configure in multilib subdir 32
pwd: /home/manuel/131745M/build/x86_64-unknown-linux-gnu
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for --enable-version-specific-runtime-libs... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking for x86_64-unknown-linux-gnu-gcc...
/home/manuel/131745M/build/./gcc/xgcc
-B/home/manuel/131745M/build/./gcc/
-B/home/manuel/./131745M/install/x86_64-unknown-l\
inux-gnu/bin/ -B/home/manuel/./131745M/install/x86_64-unknown-linux-gnu/lib/
-isystem /home/manuel/./131745M/install/x86_64-unknown-linux-gnu/include
-isystem /home/man\
uel/./131745M/install/x86_64-unknown-linux-gnu/sys-include  -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run
C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[1]: *** [configure-target-libmudflap] Error 1
make[1]: Leaving directory `/home/manuel/131745M/build'
make: *** [all] Error 2

And the relevant part in config.log is:

configure:2308: checking for C compiler default output file name
configure:2311: /home/manuel/131745M/build/./gcc/xgcc
-B/home/manuel/131745M/build/./gcc/
-B/home/manuel/./131745M/install/x86_64-unknown-linux-gnu/bin/
-B/home/manuel/\
./131745M/install/x86_64-unknown-linux-gnu/lib/ -isystem
/home/manuel/./131745M/install/x86_64-unknown-linux-gnu/include
-isystem /home/manuel/./131745M/install/x86_64-\
unknown-linux-gnu/sys-include  -m32 -O2 -g -O2conftest.c  >&5
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when
searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when
searching for -lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib/../lib/crt1.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib/../lib/crti.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib/../lib/crtn.o' is incompatible with i386 output
configure:2314: $? = 0
configure:2360: result: a.out
configure:2365: checking whether the C compiler works
configure:2371: ./a.out
/home/manuel/src/trunk/libmudflap/configure: line 2372:  3837
Segmentation fault  ./$ac_file
configure:2374: $? = 139
configure:2383: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

GCC 4.3 bootstraps just fine with the same configuration.

I am trying "--disable-multilibs" right now. Any other ideas?

Cheers,

Manuel.

Re: Mainline is now regression and documentation fixes only

[Richard Sandiford]

Richard Guenther <[EMAIL PROTECTED]> writes:
> As we now reached the goal of less than 100 open serious regressions
> against GCC 4.3, we are as of now in regression and documentation fixes
> only mode.  This means that for patches going on the trunk the same
> rules as for release branches apply.
>
> The next milestone before the release of GCC 4.3.0 is to get down
> the priority one (P1) regressions against GCC 4.3 down to zero.  At
> the point we reach that goal, either by fixing all P1 bugs or by
> downgrading less important ones to P2, the mainline will be freezed
> to prepare for a release candidate.  Around the same time we will
> branch and the opening of stage1 for GCC 4.4 development will be
> announced.
>
> There are 5 P1 bugs open against GCC 4.3, one of it has patches,
> three of them are C++ regressions assigned to Mark and one bug
> does not seem likely to be fixed (PR31529), which makes it a likely
> candidate for downgrading.

Please could someone have a look at:

http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00415.html

It fixes a pretty important regression for MIPS GNU/Linux, and if
the patch isn't acceptable, I'd like to know soon so that I have
time to implement whatever alternative we decide on.

Thanks,
Richard

Re: small changes of gdbinit.in

[Daniel Jacobowitz]

On Wed, Jan 23, 2008 at 02:31:11PM +0800, Eric Fisher wrote:
> I guess that the argument of the user defined command in gdbinit.in
> should be $arg0. Also, due to the changes of the structure tree node,
> ptc should be,

No, the use of $ is deliberate.  Print the value you want, then type
ptc by itself.  Whether this is the best way or not is up for
discussion, but it's done on purpose :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC 4.3 target deprecation proposals

[Joseph S. Myers]

Following my proposal for target architecture deprecations in 4.3
, I now propose the
following list of individual targets to deprecate, based on the same
methodology previously described.  The patch to remove c4x and
deprecate the previously discussed target architectures crx, iq2000,
mt, stormy16 will be submitted shortly; the patch for the remaining
deprecations (only touching config.gcc and the release notes) will be
submitted later after any discussion.

* c4x to be removed before 4.3, as previously mentioned.

* Stray ns32k stanzas left in config.gcc after config/ns32k was
  removed to be removed.  Likewise, stray h8300-*-rtemscoff* and
  sh-*-rtemscoff* stanzas since *-*-rtemscoff* is marked as
  unsupported earlier in the file.

The following to be deprecated in 4.3 and removed in 4.4 (some time
after 4.3.0 is released) in the absence of activity to revive them
(which means at least testing from time to time and reporting they
work or sending and chasing up patches to fix them):

* crx, iq2000, mt, stormy16 (all configurations), as previously
  mentioned.

* strongarm*-*-*, ep9312*-*-*, xscale*-*-* (the alternative CPU names
  in target triplets for certain ARM targets).  There has been no
  activity recently using these aliases, and such aliases acted on by
  config.gcc are more problematic than those substituted by config.sub
  (for example, testcases need to include them in their target triplet
  lists).  If someone wishes to revive these targets, I think they
  should move to them being aliases processed by config.sub, with
  config.gcc checking the noncanonical name and selecting --with-cpu
  etc. options on that basis.

* parisc*-*-*, alias for hppa*-*-*.  Also apparently an unused alias
  handled by config.gcc that should move to config.sub if desired.

* m680[012]0-*-* aliases for m68k-*-*.  I see no activity using these
  aliases and they appear fully equivalent to --with-cpu options that
  already exist; anyone wishing the continue to use them can move them
  to config.sub and make config.gcc treat them as --with-cpu based on
  the noncanonical name.

* *-*-beos*

* *-*-kaos*

* *-*-linux*aout*

* *-*-linux*libc1*

* *-*-solaris2.[0-6], *-*-solaris2.[0-6].*, as proposed by Eric
  Botcazou.

* *-*-sysv*

* *-*-windiss*

* alpha*-*-unicosmk*

* hppa1.1-*-pro*

* hppa1.1-*-osf*

* hppa1.1-*-bsd*

* i[34567]86-sequent-ptx4*

* i[34567]86-*-nto-qnx*

* i[34567]86-*-sco3.2v5*

* i[34567]86-*-uwin*

* powerpc-*-chorusos*

* vax-*-bsd*

* vax-*-sysv*

* vax-*-ultrix*

There are many more targets I haven't listed, with a lack of test
results and varying amounts of evidence of use or testing of patches.
OSes needing more coverage in posted results include GNU HURD,
uClinux, OpenBSD, NetBSD (most platforms), *-*-kfreebsd*-gnu,
*-*-knetbsd*-gnu (BSD kernel with GNU libc), RTEMS, VxWorks, VMS,
DJGPP, Interix, WinCE, NetWare, LynxOS and s390x-ibm-tpf*; some people
may wish to propose deprecations of some of these if they feel they
are no longer being used with GCC.  There is good coverage for
bare-metal ELF targets, but none for bare-metal a.out and COFF targets
(perhaps we should consider deprecating all of those, on the
presumption that bare-metal use has moved to ELF and objcopy is likely
to be used in any case to produce a raw binary image; -pe targets are
not being tested either); and good coverage for GNU/Linux on many
platforms.  Darwin and Solaris are being tested on relevant platforms;
HP-UX is only being tested on hppa, not IA64.

One question of interest is whether some targets supporting both GNU
and non-GNU assembler can have use of non-GNU assembler deprecated.
If this could be done for alpha*-dec-osf[45]*, we could remove
mips-tdump and mips-tfile.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

RE: GCC 4.3 target deprecation proposals

[Weddington, Eric]

 

> -Original Message-
> From: Andrew Haley [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 22, 2008 7:19 AM
> To: Manuel López-Ibáñez
> Cc: NightStrike; gcc@gcc.gnu.org
> Subject: Re: GCC 4.3 target deprecation proposals
> 
> > I agree that weighing the user base doesn't make any 
> practical sense.
> > But I can't understand the reason for removing something that works
> > fine because it may rot in the future. I understand that if 
> you don't
> > get test results then you may assume there are no users. But if you
> > get test results and they are fairly clean?
> 
> The interface between gcc and the back-ends changes fairly frequently,
> so it's necessary for a target to be maintained or it will 
> cease to work.
> 
> > Another different matter would be if there were a lot of 
> test failures
> > and open bug reports. Then it will be fair to send all test-results
> > reporters and bug subscribers a message saying:
> > 
> > "If no one steps up to maintain this, the target will be removed in
> > the next release."
> 
> That's what target deprecation is:  we always deprecate in 
> one release cycle
> and delete in a subsequent cycle.
> 

I've been lurking on this list long enough to see the same questions, with the 
same answers, every time the subject of target deprecations comes up.

If it doesn't exist somewhere already, can the criteria that Joseph used be set 
as a recurring policy and documented somewhere? Can we have an FAQ set up 
somewhere for the inevitable questions/concerns that follow the release of a 
proposed target deprecation list?

Eric Weddington

Re: Mainline is now regression and documentation fixes only

[Jack Howarth]

Richard,
   Will gcc 4.3.0's release be held up until all of the major
architectures have fully optimized cost models for vectorization?
I ask because as far as I can tell the powerpc cost model changes
haven't been submitted yet. It certainly would be nice if all
of the major targets could have -fvect-cost-model enabled by
default for -O3.
  Jack

On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote:
> 
> As we now reached the goal of less than 100 open serious regressions
> against GCC 4.3, we are as of now in regression and documentation fixes
> only mode.  This means that for patches going on the trunk the same
> rules as for release branches apply.
> 
> The next milestone before the release of GCC 4.3.0 is to get down
> the priority one (P1) regressions against GCC 4.3 down to zero.  At
> the point we reach that goal, either by fixing all P1 bugs or by
> downgrading less important ones to P2, the mainline will be freezed
> to prepare for a release candidate.  Around the same time we will
> branch and the opening of stage1 for GCC 4.4 development will be
> announced.
> 
> There are 5 P1 bugs open against GCC 4.3, one of it has patches,
> three of them are C++ regressions assigned to Mark and one bug
> does not seem likely to be fixed (PR31529), which makes it a likely
> candidate for downgrading.
> 
> I will update the GCC frontpage with the trunk state asap.
> 
> Thanks,
> Richard.

Re: Mainline is now regression and documentation fixes only

[Richard Guenther]

On Wed, 23 Jan 2008, Jack Howarth wrote:

> Richard,
>Will gcc 4.3.0's release be held up until all of the major
> architectures have fully optimized cost models for vectorization?
> I ask because as far as I can tell the powerpc cost model changes
> haven't been submitted yet. It certainly would be nice if all
> of the major targets could have -fvect-cost-model enabled by
> default for -O3.

No, there was plenty of time to get the cost model in, and the
experience will be not worse than with 4.2 as that didn't have
a cost model.

Sorry,
Richard.

Re: GCC 4.3 target deprecation proposals

[Andreas Schwab]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> * m680[012]0-*-* aliases for m68k-*-*.  I see no activity using these
>   aliases and they appear fully equivalent to --with-cpu options that
>   already exist; anyone wishing the continue to use them can move them
>   to config.sub and make config.gcc treat them as --with-cpu based on
>   the noncanonical name.

I'm not sure what you mean with that.  config.sub already recognizes
m680[012]0 as cpu type.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mainline is now regression and documentation fixes only

[Peter Bergner]

On Wed, 2008-01-23 at 12:06 +0100, Richard Guenther wrote:
> As we now reached the goal of less than 100 open serious regressions
> against GCC 4.3, we are as of now in regression and documentation fixes
> only mode.  This means that for patches going on the trunk the same
> rules as for release branches apply.

Is the following patch to fix PR 34814 which was posted shortly before
your announcement ok?  It has passed bootstrap and regtesting with
no errors and fixes test case gcc.target/powerpc/ppc32-abi-dfp-1.c.

  http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01060.html

It fixes an ABI issue with powerpc-linux and powerpc64-linux regarding
SDmode parameters and return values.  The patch will allow us to mix
and match GCC compiled obj files with XL compiled obj files which is
already following the ABI.

I restricted the changes to the rs6000 port except for a couple of
additional target hooks which are nop's for non ppc targets and a simple
rename of one function to eliminate a symbol collision between
function.c:instantiate_decl and cp/pt.c:instantiate_decl().

Peter

restrict keyword has no effect?

[Bingfeng Mei]

Hello,
We are porting GCC 4.2.1 for our VLIW processor. To improve performance,
support of restrict keyword is imperative. From what I learn from GCC
documentation, "restrict" should be well supported since GCC3. Somehow,
I found it doesn't improve schedule even for simple example.


foo (int * restrict a, int * restrict b, int * restrict c) {
  unsigned i;

  for (i=0; i<256; i++){
a[i] = b[i] + c[i];
  }
}

It is not only problem for our own porting. I also tried to compile for
ARM target. 
arm-elf-gcc vectorize.c -O3 -std=c99 -S -funroll-all-loops
-fdump-tree-all

It just generate sequences of load/load/store as the code's natural
order suggests. The scheduler never tries to move load beyond previous
store instruction in order to reduce cycle.

foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
ldr ip, [r2, #0]
stmfd   sp!, {r4, lr}
mov r4, r1
ldr r1, [r1, #0]
mov lr, r2
add r2, ip, r1
str r2, [r0, #0]
mov ip, #4
ldr r1, [ip, lr]
ldr r3, [ip, r4]
add r2, r1, r3
str r2, [ip, r0]
add r3, ip, #4
ldr r1, [r3, r4]
ldr r2, [r3, lr]
add r2, r2, r1
str r2, [r3, r0]
add r3, r3, #4
ldr r2, [r3, lr]
ldr r1, [r3, r4]
add r2, r2, r1
str r2, [r3, r0]
add ip, ip, #12
.L2:
ldr r1, [ip, lr]
ldr r3, [ip, r4]
add r2, r1, r3
str r2, [ip, r0]
add r3, ip, #4
ldr r1, [r3, r4]
ldr r2, [r3, lr]
add r2, r2, r1
str r2, [r3, r0]
add r3, r3, #4
ldr r1, [r3, r4]
ldr r2, [r3, lr]
add r2, r2, r1
str r2, [r3, r0]
  ...
ldr r3, [r1, lr]
add r3, r3, r2
str r3, [r1, r0]
add r2, ip, #32
ldr r3, [r2, lr]
ldr r1, [r2, r4]
add ip, ip, #36
add r3, r3, r1
cmp ip, #1024
str r3, [r2, r0]
bne .L2
ldmfd   sp!, {r4, pc}
.size   foo, .-foo
.ident  "GCC: (GNU) 4.2.2"

I examine produced tree-SSA files:

In 004t.gimple, the restrict keyword is preserved
foo (a, b, c)
{
  unsigned int D.1352;
  int * D.1353;
  int * D.1354;
  int * D.1355;
  int D.1356;
  int * D.1357;
  int D.1358;
  int D.1359;
  unsigned int i;

  i = 0;
  goto ;
  :;
  D.1352 = i * 4;
  D.1353 = (int * restrict) D.1352;
  D.1354 = D.1353 + a;
  D.1352 = i * 4;
  D.1353 = (int * restrict) D.1352;
  D.1355 = D.1353 + b;
  D.1356 = *D.1355;
  D.1352 = i * 4;
  D.1353 = (int * restrict) D.1352;
  D.1357 = D.1353 + c;
  D.1358 = *D.1357;
  D.1359 = D.1356 + D.1358;
  *D.1354 = D.1359;
  i = i + 1;
  :;
  if (i <= 255)
{
  goto ;
}
  else
{
  goto ;
}
  :;
}

But in .final_cleanup file,  the restrict key word just disppear.
foo (a, b, c)
{
  long unsigned int ivtmp.49;

:
  MEM[base: a] = MEM[base: c] + MEM[base: b];
  ivtmp.49 = 4;

:;
  MEM[base: a, index: ivtmp.49] = MEM[base: c, index: ivtmp.49] +
MEM[base: b, index: ivtmp.49];
  ivtmp.49 = ivtmp.49 + 4;
  if (ivtmp.49 != 1024) goto ; else goto ;

:;
  return;

}

Any hint to produce efficient code with "restrict" keyword?  Thank in
advance.

Cheers,
Bingfeng Mei 
Broadcom UK

Re: GCC 4.3 target deprecation proposals

[Manuel López-Ibáñez]

On 23/01/2008, Weddington, Eric <[EMAIL PROTECTED]> wrote:
>
> I've been lurking on this list long enough to see the same questions, with 
> the same answers, every time the subject of target deprecations comes up.
>
> If it doesn't exist somewhere already, can the criteria that Joseph used be 
> set as a recurring policy and documented somewhere? Can we have an FAQ set up 
> somewhere for the inevitable questions/concerns that follow the release of a 
> proposed target deprecation list?
>

Anybody can edit the wiki: http://gcc.gnu.org/wiki/TargetDeprecationFAQ

;-)

Manuel.

Re: restrict keyword has no effect?

[Andrew Pinski]

On Jan 23, 2008 8:18 AM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
> We are porting GCC 4.2.1 for our VLIW processor. To improve performance,
> support of restrict keyword is imperative. From what I learn from GCC
> documentation, "restrict" should be well supported since GCC3. Somehow,
> I found it doesn't improve schedule even for simple example.

> Any hint to produce efficient code with "restrict" keyword?  Thank in
> advance.

You should try the trunk which has improved restrict support via the
merging of the pointer plus infrastructure.
There is still more to support restrict after the tree-ssa merge but
those are waiting until 4.4.

Thanks,
Andrew Pinski

Re: Mainline is now regression and documentation fixes only

[Jack Howarth]

Richard,
   Just to clarify, does this mean that any architecture
which doesn't have a fully optimized cost-model currently
in gcc trunk will have to wait for gcc 4.4? I ask because
the cost-model bugs wouldn't actually be a regressions
from gcc 4.2. I mainly wanted to make sure that we didn't
have some cost-model changes sitting around unsubmitted
that would have to be postponed until gcc 4.4.
  Jack

On Wed, Jan 23, 2008 at 05:01:07PM +0100, Richard Guenther wrote:
> On Wed, 23 Jan 2008, Jack Howarth wrote:
> 
> > Richard,
> >Will gcc 4.3.0's release be held up until all of the major
> > architectures have fully optimized cost models for vectorization?
> > I ask because as far as I can tell the powerpc cost model changes
> > haven't been submitted yet. It certainly would be nice if all
> > of the major targets could have -fvect-cost-model enabled by
> > default for -O3.
> 
> No, there was plenty of time to get the cost model in, and the
> experience will be not worse than with 4.2 as that didn't have
> a cost model.
> 
> Sorry,
> Richard.

Re: GCC 4.3 target deprecation proposals

[Joseph S. Myers]

On Wed, 23 Jan 2008, Andreas Schwab wrote:

> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> 
> > * m680[012]0-*-* aliases for m68k-*-*.  I see no activity using these
> >   aliases and they appear fully equivalent to --with-cpu options that
> >   already exist; anyone wishing the continue to use them can move them
> >   to config.sub and make config.gcc treat them as --with-cpu based on
> >   the noncanonical name.
> 
> I'm not sure what you mean with that.  config.sub already recognizes
> m680[012]0 as cpu type.

If config.sub already converts them to m68k, so that m680[012]0 never 
appears in a canonical target name, then the code in config.gcc looking 
for m680[012]0 in canonical target names is already dead.  The proposed 
alias deprecations relate only to aliases appearing in canonical names, 
not those that config.sub handles (such as converting pentium-linux to 
i586-pc-linux-gnu).

If config.sub handles a target alias, config.gcc doesn't need to include 
it in the case statements, and testcases do not need to mention that 
alias.  Thus testcases don't need to know about the possibility of 
configuring for target pentium-linux.  If config.sub does not handle a 
target alias, testcases do need to know about it - and testcases checking 
for m68k-*-* fail to check for the other variant target aliases.

There are no test results recently posted for the m680[012]0 target 
aliases.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: GCC 4.3 target deprecation proposals

[DJ Delorie]

> DJGPP,

Please don't deprecate this.  It's actively used, but the test harness
doesn't run under DJGPP so testing it is difficult.  I don't think
we've *ever* run the testsuite for it.

> s390x-ibm-tpf*

Similar.  TPF is cross, and there's no simulators, so no test results,
yet still active.

> -pe targets are not being tested either);

That would be cygwin, for i686 ;-)

Re: GCC 4.3 target deprecation proposals

[Andreas Schwab]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> If config.sub already converts them to m68k, so that m680[012]0 never 
> appears in a canonical target name, then the code in config.gcc looking 
> for m680[012]0 in canonical target names is already dead.  The proposed 
> alias deprecations relate only to aliases appearing in canonical names, 
> not those that config.sub handles (such as converting pentium-linux to 
> i586-pc-linux-gnu).

Thanks, I see your point now.  AFAICS, none of the systems that
config.guess would return something matching m680[012]0-*-* are still
supported by gcc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 4.3 target deprecation proposals

[John David Anglin]

> * parisc*-*-*, alias for hppa*-*-*.  Also apparently an unused alias
>   handled by config.gcc that should move to config.sub if desired.

I'm happy to see this go.  It's not checked for in the testsuite, etc.

> HP-UX is only being tested on hppa, not IA64.

I believe that Steve Ellcey is testing ia64-hpux but he doesn't usually
submit test results.  He has been prohibited from making any contributions
in recent months by HP legal.  They are reviewing the switch to GPL v3.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

MPFR 2.3.1 Release Candidate 2

[Vincent Lefevre]

The release of MPFR 2.3.1 is still imminent. Thanks very much to
those who tested the first release candidate. As there have been
significant changes, a second release candidate is necessary. You
can download it here:

http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc2.tar.bz2
http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc2.tar.gz
http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc2.zip

The MD5's:
ac3abf77a04eda82a5f0929508118629  mpfr-2.3.1-rc2.tar.bz2
bcd739dae4f95baf318012251314b17b  mpfr-2.3.1-rc2.tar.gz
fb5fe9164ce1e980224391c2c9102575  mpfr-2.3.1-rc2.zip

Changes from version 2.3.0 to version 2.3.1:
- Changes in the behavior of mpfr_strtofr and in its documentation
  concerning particular cases where the code and the documentation
  did not match.
- Bug fixes; see .
- Configure test for TLS support.
- Improved MPFR manual.

Please send success and failure reports to <[EMAIL PROTECTED]>.

If no problems are found, MPFR 2.3.1 should be released around
2008-01-29.

Regards,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: GCC 4.3 target deprecation proposals

[Joseph S. Myers]

On Wed, 23 Jan 2008, DJ Delorie wrote:

> > DJGPP,
> 
> Please don't deprecate this.  It's actively used, but the test harness
> doesn't run under DJGPP so testing it is difficult.  I don't think
> we've *ever* run the testsuite for it.
> 
> > s390x-ibm-tpf*
> 
> Similar.  TPF is cross, and there's no simulators, so no test results,
> yet still active.

In that case these targets are something like SymbianOS (where the 
compiler can be used through a Symbian SDK, but the *-*-symbianelf* 
compiler can't be tested directly).  But this was a list of targets I 
suspect are used and am not proposing to deprecate but that lack test 
coverage.

Cross targets can be tested on hardware without simulators (with 
appropriate board files), even if some have particular difficulties in 
testing.  Some of the OSes listed have had patches submitted in the past 
year that have been tested on them (using cross compilers and suitable 
board files for testing on hardware).  Others such as OpenBSD I expect are 
largely used in native configurations.

> > -pe targets are not being tested either);
> 
> That would be cygwin, for i686 ;-)

That's being tested.  WinCE was on the list of those OSes lacking test 
coverage.  I meant generic targets mcore-*-pe* and arm-*-pe* (since I see 
[34567]86-*-pe is really an alias for Cygwin).

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Mainline is now regression and documentation fixes only

[Bernhard Fischer]

On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote:
>
>As we now reached the goal of less than 100 open serious regressions
>against GCC 4.3, we are as of now in regression and documentation fixes
>only mode.  This means that for patches going on the trunk the same
>rules as for release branches apply.

While not strictly a regression, is there any chance that we could get
this reviewed an applied?

http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00995.html

cheers,

Seperate the c front-end from GCC

[Haizhou LING]

Hi all,

I have to use gcc's C parser and the intermediate representation, so that I
can manipulate the basic blocks and CFG. So I need to plug out the parser
and the intermediate code. I would like to know if it is possible to plug
out the parser and the intermediate representation code.

Did someone have any experience on this? Could anyone give some hints on how
to do this?
 
Appreciate your help
Eric
-- 
View this message in context: 
http://www.nabble.com/Seperate-the-c-front-end-from-GCC-tp15048379p15048379.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Mainline is now regression and documentation fixes only

[Dorit Nuzman]

> Richard,
>Will gcc 4.3.0's release be held up until all of the major
> architectures have fully optimized cost models for vectorization?
> I ask because as far as I can tell the powerpc cost model changes
> haven't been submitted yet.

At this point it doesn't look like there will be any cost model changes
submitted for powerpc - experimentation so far on powerpc970 with Spec2006
and Polyhedron benchmark suites didn't bring up any issues that needed to
be fixed (in both suites vectorization either had no impact (on most
benchmarks), or had a significant positive impact (on 1-2 benchmarks); the
cost model had no impact). We are continuing to experiment on power, also
with other benchmarks, in search for cases that do require cost model
tuning, but there are no patches ready at the moment.

There are however a couple of small cost-model changes that were going to
be submitted this week for the Cell SPU - it's unfortunate if these cannot
get into 4.3.

dorit

(P.S. thanks to Razya for powerpc Polyhedron testing)


> It certainly would be nice if all
> of the major targets could have -fvect-cost-model enabled by
> default for -O3.
>   Jack
>
> On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote:
> >
> > As we now reached the goal of less than 100 open serious regressions
> > against GCC 4.3, we are as of now in regression and documentation fixes
> > only mode.  This means that for patches going on the trunk the same
> > rules as for release branches apply.
> >
> > The next milestone before the release of GCC 4.3.0 is to get down
> > the priority one (P1) regressions against GCC 4.3 down to zero.  At
> > the point we reach that goal, either by fixing all P1 bugs or by
> > downgrading less important ones to P2, the mainline will be freezed
> > to prepare for a release candidate.  Around the same time we will
> > branch and the opening of stage1 for GCC 4.4 development will be
> > announced.
> >
> > There are 5 P1 bugs open against GCC 4.3, one of it has patches,
> > three of them are C++ regressions assigned to Mark and one bug
> > does not seem likely to be fixed (PR31529), which makes it a likely
> > candidate for downgrading.
> >
> > I will update the GCC frontpage with the trunk state asap.
> >
> > Thanks,
> > Richard.

RE: GCC 4.3 target deprecation proposals

[Weddington, Eric]

 

> -Original Message-
> From: Manuel López-Ibáñez [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 23, 2008 9:35 AM
> To: Weddington, Eric
> Cc: Andrew Haley; NightStrike; gcc@gcc.gnu.org
> Subject: Re: GCC 4.3 target deprecation proposals
> 
> On 23/01/2008, Weddington, Eric <[EMAIL PROTECTED]> wrote:
> >
> > I've been lurking on this list long enough to see the same 
> questions, with the same answers, every time the subject of 
> target deprecations comes up.
> >
> > If it doesn't exist somewhere already, can the criteria 
> that Joseph used be set as a recurring policy and documented 
> somewhere? Can we have an FAQ set up somewhere for the 
> inevitable questions/concerns that follow the release of a 
> proposed target deprecation list?
> >
> 
> Anybody can edit the wiki: 
> http://gcc.gnu.org/wiki/TargetDeprecationFAQ
> 
> ;-)

Ok, done. That link above.

I borrowed heavily from many people's responses in this thread. Hope that's ok. 
Feel free to edit/adjust as you see fit. :-)

Eric Weddington

Re: GCC 4.3 target deprecation proposals

[Nick Clifton]

Hi Joseph,

  Well the IQ2000 port is still of interest to us, and I am still happy
  to maintain it, so here are some test results:

Test Run By nickc on Wed Jan 23 10:37:48 2008
Target is iq2000-unknown-elf
Host   is i686-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
iq2000-sim
[...]
=== gcc Summary ===

# of expected passes43656
# of unexpected failures186
# of unexpected successes   1
# of expected failures  84
# of unresolved testcases   129
# of untested testcases 35
# of unsupported tests  395
/work/builds/gcc/current/iq2000-elf/gcc/xgcc  version 4.3.0 20080123 
(experimental) [trunk revision 131756] (GCC)

[...]
=== g++ Summary ===

# of expected passes15563
# of unexpected failures295
# of expected failures  81
# of unresolved testcases   121
# of unsupported tests  172
/work/builds/gcc/current/iq2000-elf/gcc/g++  version 4.3.0 20080123 
(experimental) [trunk revision 131756] (GCC)


Cheers
  Nick

Re: Mainline is now regression and documentation fixes only

[Richard Guenther]

On Wed, 23 Jan 2008, Jack Howarth wrote:

> Richard,
>Just to clarify, does this mean that any architecture
> which doesn't have a fully optimized cost-model currently
> in gcc trunk will have to wait for gcc 4.4? I ask because
> the cost-model bugs wouldn't actually be a regressions
> from gcc 4.2. I mainly wanted to make sure that we didn't
> have some cost-model changes sitting around unsubmitted
> that would have to be postponed until gcc 4.4.

I have no idea how these "bugs" will look like, so I cannot
give you a definitive answer on this question.  But as always,
nothing is impossible, especially if it only involves target
specific changes.

Richard.

Re: GCC 4.3 target deprecation proposals

[Joseph S. Myers]

On Wed, 23 Jan 2008, Nick Clifton wrote:

> Hi Joseph,
> 
>   Well the IQ2000 port is still of interest to us, and I am still happy
>   to maintain it, so here are some test results:

On that basis I've removed it from my deprecation list, but results need 
to go to gcc-testresults in the form generated by contrib/test_summary (if 
they are sent but get consistently rejected for being over 400k, that's a 
bad sign for the maintainedness of a target).  I checked the subject lines 
of gcc-testresults messages since the start of 2007 (presuming them to be 
in the standard form generated by contrib/test_summary) and then checked 
for any mention in gcc-patches indicating a patch had been tested on a 
target since the start of 2007; I did not look at gcc list archives at all 
in determining which targets seemed to be actively tested, only 
gcc-testresults and gcc-patches.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

gcc-4.2-20080123 is now available

[gccadmin]

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

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

You'll find:

gcc-4.2-20080123.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080123.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080123.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080123.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080123.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080123.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080123.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080123.tar.bz2The GCC testsuite

Diffs from 4.2-20080116 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
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.

Question about past research in detecting compiler used to create executable binary

[Stephen Torri]

GCC Community,

I am a PhD candidate at Auburn University in Alabama investigating
automated compiler detection for reverse engineering.  The reason I am
contacting this mailing list is to see if anyone knows of research done
to discover the compiler used to create a binary executable.

Sincerely,

Stephen Torri
PhD Candidate
Auburn University
Department of Computer Science and Software Engineering
[EMAIL PROTECTED]

Re: GCC 4.3 target deprecation proposals

[Ben Elliston]

On Wed, 2008-01-23 at 12:02 -0500, DJ Delorie wrote:

> > DJGPP,
> 
> Please don't deprecate this.  It's actively used, but the test harness
> doesn't run under DJGPP so testing it is difficult.  I don't think
> we've *ever* run the testsuite for it.

You can't cross-test, with DejaGnu running elsewhere?

Ben

Re: GCC 4.3 target deprecation proposals

[DJ Delorie]

> You can't cross-test, with DejaGnu running elsewhere?

I've tried.  The problem is communication between the DOS system (or
emulator) and the host system.  DOS isn't kind to networking,
semaphores, or anything else that hints at multiprocessing.

Re: GCC 4.3 target deprecation proposals

[Ben Elliston]

> I've tried.  The problem is communication between the DOS system (or
> emulator) and the host system.  DOS isn't kind to networking,
> semaphores, or anything else that hints at multiprocessing.

If you're trying to at least test code generation, etc., you could treat
the DOS system like a basic target board and cross-compile tests and
transfer them over a serial line to execute them.  That's the way it was
done in the bad old days.

However, it's just occurred to me that you are probably wanting to test
djgpp as a native compiler.  Yeah?

Ben

Re: GCC 4.3 target deprecation proposals

[DJ Delorie]

> If you're trying to at least test code generation, etc., you could
> treat the DOS system like a basic target board and cross-compile
> tests and transfer them over a serial line to execute them.  That's
> the way it was done in the bad old days.

Yeah, I remember those.

> However, it's just occurred to me that you are probably wanting to test
> djgpp as a native compiler.  Yeah?

That too.

Re: GCC 4.3 target deprecation proposals

[Joe Buck]

On Thu, Jan 24, 2008 at 11:34:56AM +1100, Ben Elliston wrote:
> > I've tried.  The problem is communication between the DOS system (or
> > emulator) and the host system.  DOS isn't kind to networking,
> > semaphores, or anything else that hints at multiprocessing.
> 
> If you're trying to at least test code generation, etc., you could treat
> the DOS system like a basic target board and cross-compile tests and
> transfer them over a serial line to execute them.  That's the way it was
> done in the bad old days.
> 
> However, it's just occurred to me that you are probably wanting to test
> djgpp as a native compiler.  Yeah?

What if you had a set of scripts that would fire up the DJGPP compiler
inside a DOS emulator on a Unix/Linux/whatever box and execute that?  Then
if those scripts were named "gcc", "g++" etc. it would seem that you could
test native compilation that way.  I haven't tried to hack dejagnu in
about a decade so I'm probably missing something, but it should be
feasible.

2008 GCC Developers' Summit CFP closing soon

[Ben Elliston]

This is a quick reminder that the Call for Papers for the 2008 GCC
Developers' Summit is closing on Friday, *February 1st*.  Proposals are
being accepted for papers, BOFs and tutorials (one or two hours
duration).

The proposal submission process now requires that you prepare a
proposal, and a personal biography that will be displayed on the website
and in the official event programme.   Please see
http://www.gccsummit.org/2008/cfp.php for more details.

Cheers,

Ben
(and the rest of the organising committee)

Re: GCC 4.3 target deprecation proposals

[Hans-Peter Nilsson]

On Wed, 23 Jan 2008, Joseph S. Myers wrote:
> There is good coverage for
> bare-metal ELF targets, but none for bare-metal a.out and COFF targets
> (perhaps we should consider deprecating all of those, on the
> presumption that bare-metal use has moved to ELF and objcopy is likely
> to be used in any case to produce a raw binary image; -pe targets are
> not being tested either)

FWIW, I'd be fine with (even happy to) deprecate cris-aout.

brgds, H-P

Re: GCC 4.3 target deprecation proposals

[DJ Delorie]

IIRC, the problem was in syncronizing *anything* between the Linux
host and the DOS emulator.  It's like trying to use NFS to syncronize
two Xen instances, except with a flakey NFS and programs that don't
know about concurrency.

With Cygwin and DJGPP you have the problem of long command lines being
incompatibly passed between the two.

Re: 2008 GCC Developers' Summit CFP closing soon

[Joe Buck]

On Thu, Jan 24, 2008 at 11:47:18AM +1100, Ben Elliston wrote:
> This is a quick reminder that the Call for Papers for the 2008 GCC
> Developers' Summit is closing on Friday, *February 1st*.  Proposals are
> being accepted for papers, BOFs and tutorials (one or two hours
> duration).

The web site says only "June 2008".  Does this mean that the dates have
not yet been chosen?

Re: Question about past research in detecting compiler used to create executable binary

[Tim Josling]

On Wed, 2008-01-23 at 16:48 -0600, Stephen Torri wrote:
> GCC Community,
> 
> I am a PhD candidate at Auburn University in Alabama investigating
> automated compiler detection for reverse engineering.  The reason I am
> contacting this mailing list is to see if anyone knows of research done
> to discover the compiler used to create a binary executable.
> 
> Sincerely,
> 
> Stephen Torri
> PhD Candidate
> Auburn University
> Department of Computer Science and Software Engineering
> [EMAIL PROTECTED]
> 
> 

If GCC is any guide, this will often be trivial. GCC embeds lots of data
about the source system and compiler in the executable.

> file temp.x
temp.x: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for
GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped

Also in the same file

GCC: (GNU) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

If this is a reverse engineering project, your adversary will probably
have stripped as much of this kind of thing as possible though.

Tim Josling

Re: Question about past research in detecting compiler used to create executable binary

[Andrew Pinski]

On 1/23/08, Tim Josling <[EMAIL PROTECTED]> wrote:
> Also in the same file
>
> GCC: (GNU) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

You can strip out the comment section so this information does not
have to emitted either.  And sometimes it can contain multiple
versions depending on if you have a static library which is compiled
with a different compiler version.

So I would not dependent on this information at all.

Thanks,
Andrew Pinski

Re: GCC 4.3 target deprecation proposals

[Jan-Benedict Glaw]

On Wed, 2008-01-23 14:39:37 +, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> * vax-*-bsd*
> * vax-*-sysv*
> * vax-*-ultrix*

I'll start looking into the NetBSD target. There are other bits
(OpenBSD and the non-BSD targets) but I won't work on those. It'll
take some time to get the environment right, but I hope to be able to
send some testresult in some days or weeks.

When will 4.3 be branched off?

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of: Alles wird gut! ...und heute wirds schon ein bißchen 
besser.
the second  :


signature.asc
Description: Digital signature

Re: 2008 GCC Developers' Summit CFP closing soon

[Ben Elliston]

> The web site says only "June 2008".  Does this mean that the dates have
> not yet been chosen?

I believe there are candidate dates, but they are yet to be finalised.
Stay tuned.  :-)

Ben