headers
matthew green | 3 Jun 2006 00:27
Picon
Favicon

GCC2 removed, vax port downgraded to static-only for now.


hi folks.

i have removed GCC2 sources from our tree and switched the vax port to
GCC3.  unfortunately the shared library support is missing and so the
vax no longer supports shlibs in -current.  the support for them is
planned to return with the switch to GCC4 on vax.  i do not know when
that will happen.

it is possible i have damaged the tree in other ways, please send-pr
if you notice new build problems.

.mrg.
Permalink | Reply | 0 comments |
headers
Kirk Russell | 11 Jun 2006 04:37

current vax cannot boot and lvalue casts in arch/vax/boot

Hello,

Last week, I tried building a -current VAX CDROM, with the new gcc setup,
and I got about bunch of errors about the "use of cast expressions as
lvalues".  This week, the errors are fixed in -current, but now the
VAX CDROM doesn't boot.  I would guess some of the lvalue cast fixes
might be the root cause of the booting issues.  For example, this
lvalue fix to ra.c doesn't look correct to me?  I have enclosed my
lvalue fixes for reference.  Any ideas?  Thanks!

- could this be the cause of the booting problems?
Index: ra.c
===================================================================
RCS file: /cvsroot/src/sys/arch/vax/boot/boot/ra.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -c -r1.14 -r1.15
*** ra.c	11 Dec 2005 12:19:30 -0000	1.14
--- ra.c	8 Jun 2006 07:03:11 -0000	1.15
[...]
***************
*** 111,117 ****
  			mapregs = (int *)nexaddr + 512;
  			mapregs[494] = PG_V | (((u_int)&uda) >> 9);
  			mapregs[495] = mapregs[494] + 1;
! 			(char *)ubauda = (char *)0x3dc00 +
  			    (((u_int)(&uda))&0x1ff);
  		} else
  			ubauda = &uda;
--- 111,117 ----
(Continue reading)

Permalink | Reply | 576 comments |
headers
Havard Eidnes | 11 Jun 2006 10:30
Picon
Picon

Re: current vax cannot boot and lvalue casts in arch/vax/boot

> This week, the errors are fixed in -current, but now the
> VAX CDROM doesn't boot.  I would guess some of the lvalue cast fixes
> might be the root cause of the booting issues.  For example, this
> lvalue fix to ra.c doesn't look correct to me?

You're absolutely right.  I've mended the fix in boot/ra.c.

I'll take a closer look and compare the other fixes.

Regards,

- Håvard
Permalink | Reply | 0 comments |
headers
A. Wik | 13 Jun 2006 23:32

Re: current vax cannot boot and lvalue casts in arch/vax/boot

On Sat, 10 Jun 2006, Kirk Russell wrote:
> 
> Last week, I tried building a -current VAX CDROM, with the new gcc setup,
> and I got about bunch of errors about the "use of cast expressions as
> lvalues".  This week, the errors are fixed in -current, but now the
> VAX CDROM doesn't boot.  I would guess some of the lvalue cast fixes
> might be the root cause of the booting issues.  For example, this
> lvalue fix to ra.c doesn't look correct to me?  I have enclosed my
> lvalue fixes for reference.  Any ideas?  Thanks!

I recall something about the GCC of NetBSD/vax being upgraded
recently, which would certainly explain the problem you mention -
there was an article regarding the same error message on 
comp.os.msdos.djgpp (Usenet), and the issue was resolved as
an change present in newer versions of GCC.

How come there's such an apparent eagerness about upgrading GCC,
anyway?  Typically the only noticeable change from an older
version is the breakage of features and noticeable increases in
memory consumption and compilation time.

I've found the use of an older compiler (pcc) a more
refreshing experience.

-aw
Permalink | Reply | 574 comments |
headers
Jan-Benedict Glaw | 13 Jun 2006 23:35
Picon
Favicon

Re: current vax cannot boot and lvalue casts in arch/vax/boot

On Tue, 2006-06-13 21:32:05 +0000, A. Wik <aw <at> aw.gs> wrote:
> How come there's such an apparent eagerness about upgrading GCC,
> anyway?  Typically the only noticeable change from an older
> version is the breakage of features and noticeable increases in
> memory consumption and compilation time.

Stricter checking for standards?  Drastically improved emission of
helpful warnings?  OTOH, some newer features (thread local storage
comes to mind) will never be implemented in something like a
gcc-2.95...

MfG, JBG

--

-- 
Jan-Benedict Glaw       jbglaw <at> lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Permalink | Reply | 0 comments |
headers
Jochen Kunz | 14 Jun 2006 09:20
Picon

Re: current vax cannot boot and lvalue casts in arch/vax/boot

On Tue, 13 Jun 2006 21:32:05 +0000 (GMT)
"A. Wik" <aw <at> aw.gs> wrote:

> How come there's such an apparent eagerness about upgrading GCC,
> anyway?
To add some points to the list Jan-Benedict already mentioned:
C99 compliance? Better optimizer? A compiler that is actively
maintained? (2.95 is dead.) One compiler / toolchain for all ports?

AFAIK the problem with the VAX compiler is that shared libs in GCC 3 are
broken. So VAX stuck to 2.95. NetBSD is on the way migrating to GCC 4
and this will solve the shared libs problems of GCC 3.

> I've found the use of an older compiler (pcc) a more
> refreshing experience.
Can it compile ANSI C at all, or is it still K&R C?
What if you need to compile C++?
Does it support all the CPUs that a NetBSD compiler needs?
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Permalink | Reply | 0 comments |
headers
Kirk Russell | 14 Jun 2006 19:50

Re: current vax cannot boot and lvalue casts in arch/vax/boot

On Tue, 13 Jun 2006, A. Wik wrote:

> How come there's such an apparent eagerness about upgrading GCC,
> anyway?  Typically the only noticeable change from an older
> version is the breakage of features and noticeable increases in
> memory consumption and compilation time.

I think it is a shame that gcc has such a monopoly with OSS projects.
Some competition would be good.  It appears others are considering
this -- see "Why haven't we seen an OpenCC":
	http://kerneltrap.org/node/6550

--

-- 
Kirk Russell            <kirk <at> ba23.org>            http://www.ba23.org/
Bridlewood Software Testers Guild                  Ottawa Ontario Canada
Permalink | Reply | 2 comments |
headers
ragge | 15 Jun 2006 10:11
Picon
Picon

Re: current vax cannot boot and lvalue casts in arch/vax/boot

> On Tue, 13 Jun 2006, A. Wik wrote:
> 
> > How come there's such an apparent eagerness about upgrading GCC,
> > anyway?  Typically the only noticeable change from an older
> > version is the breakage of features and noticeable increases in
> > memory consumption and compilation time.
> 
> I think it is a shame that gcc has such a monopoly with OSS projects.
> Some competition would be good.  It appears others are considering
> this -- see "Why haven't we seen an OpenCC":
> 	http://kerneltrap.org/node/6550
> 
Actually, I have hacked the old PCC that became free via Caldera so 
that it is useable.  Initially it was to get a usable compiler for 
the pdp10, but I have rewritten quite much of it now (~40% of the
frontend and 80% of the backend) and made it run on the i386, which
simplifies testing. 

It is supposed to be an ANSI-C compiler with some C99 and GNU 
extensions added.

It can generate decent code for i386 on NetBSD, but there are still
many bugs left.  The major benefit with it is that it is fast, it
runs about 5 times faster than gcc3 even though I have lots of 
internal consistency checks turned on.

I feel quite satisfied with the register allocator in the compiler,
it is probably one of the best multiple-register-class graph-coloring
register allocator that exists today :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan-Benedict Glaw | 15 Jun 2006 10:25
Picon
Favicon

Re: current vax cannot boot and lvalue casts in arch/vax/boot

On Wed, 2006-06-14 13:50:56 -0400, Kirk Russell <kirk <at> ba23.org> wrote:
> On Tue, 13 Jun 2006, A. Wik wrote:
> > How come there's such an apparent eagerness about upgrading GCC,
> > anyway?  Typically the only noticeable change from an older
> > version is the breakage of features and noticeable increases in
> > memory consumption and compilation time.
> 
> I think it is a shame that gcc has such a monopoly with OSS projects.
> Some competition would be good.  It appears others are considering
> this -- see "Why haven't we seen an OpenCC":
> 	http://kerneltrap.org/node/6550

Well, there *are* even commercially supported GCC versions with
specific patches solving specific problems (usually additional CPU
or userland features), but after all, building a well-working compiler
isn't exactly simple.

I recognize other compilers and some of them do a good job for
specific tasks (tcc comes to mind). But to me, the final goal looks
more like "a compiler that is easily portable to a hugh number of
platforms."  GCC fits, except for the "easily" part, very well.

I actually don't care about the very best optimizations. First of all,
I care about correct code generation and easy portability,
optimization comes next. So if there's an alternative to GCC with
isn't a full desaster in terms of resulting binary speed, it's
welcome. Though keep in mind that hacking hours are limited and I'm
nut all that sure if it's actually clever to feed these into more than
one compiler.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kirk Russell | 17 Jun 2006 15:36

current vax build cannot create GENERIC/assym.h

Hello,

Cannot compile the vax kernel with -current.  Any ideas?  TIA.

#    create  GENERIC/assym.h
cat /bstg/current/usr/src/sys/arch/vax/vax/genassym.cf  | 
/bstg/current/vax/tools/bin/nbgenassym -- /bstg/current/vax/tools/bin/vax--netbsdelf-gcc 
-ffreestanding -fno-zero-initialized-in-bss   -O2 -Werror -Wall -Wno-main -Wno-format-zero-length
-Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual
-Wwrite-strings -Wno-sign-compare     -D_VAX_INLINE_ -I. 
-I/bstg/current/usr/src/sys/../common/include -I/bstg/current/usr/src/sys/arch 
-I/bstg/current/usr/src/sys -nostdinc -DLKM -DMAXUSERS=8 -D_KERNEL -D_KERNEL_OPT
-I/bstg/current/usr/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/bstg/current/usr/src/sys/lib/libkern/../../../common/lib/libc/string
-I/bstg/current/usr/src/sys/lib/libkern/../../../common/lib/libc/arch/vax/string 
-I/bstg/current/usr/src/sys/dist/ipf   > assym.h.tmp &&  mv -f assym.h.tmp assym.h
In file included from machine/param.h:171,
                 from /bstg/current/usr/src/sys/sys/param.h:145,
                 from /tmp/genassym.20449/assym.c:2:
machine/macros.h:45: warning: static declaration for `ffs' follows non-static
machine/macros.h:60: warning: static declaration for `_remque' follows non-static
machine/macros.h:69: warning: static declaration for `_insque' follows non-static
machine/macros.h:78: warning: static declaration for `memcpy' follows non-static
machine/macros.h:91: warning: static declaration for `memmove' follows non-static
machine/macros.h:116: warning: static declaration for `memset' follows non-static
machine/macros.h:295: warning: static declaration for `scanc' follows non-static
machine/macros.h:308: warning: static declaration for `skpc' follows non-static

*** Failed target:  assym.h
*** Failed command: cat /bstg/current/usr/src/sys/arch/vax/vax/genassym.cf |
(Continue reading)

Permalink | Reply | 1 comment |

Gmane