NetBSD Problem Report #51923

From www@NetBSD.org  Sat Jan 28 22:33:25 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 355F47A2A4
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 28 Jan 2017 22:33:25 +0000 (UTC)
Message-Id: <20170128223323.EC6237A2C7@mollari.NetBSD.org>
Date: Sat, 28 Jan 2017 22:33:23 +0000 (UTC)
From: bbraun@synack.net
Reply-To: bbraun@synack.net
To: gnats-bugs@NetBSD.org
Subject: /usr/libexec/cc1: Cannot allocate memory
X-Send-Pr-Version: www-1.0

>Number:         51923
>Category:       port-mac68k
>Synopsis:       /usr/libexec/cc1: Cannot allocate memory
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-mac68k-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 28 22:35:00 +0000 2017
>Closed-Date:    Sun Feb 05 00:09:22 +0000 2017
>Last-Modified:  Sun Feb 05 14:20:01 +0000 2017
>Originator:     Rob Braun
>Release:        current (as of 1/27/2017)
>Organization:
>Environment:
NetBSD q800.home 7.99.59 NetBSD 7.99.59 (BBRAUN) #0: Sat Jan 28 02:10:13 UTC 2017  bbraun@netbsd.home:/mnt/current/src/sys/arch/mac68k/compile/BBRAUN mac68k
>Description:
After crosscompiling -current on amd64, then upgrading a Quadra 800 w/136MB RAM using the built release tarballs and sysinst, the compiler no longer works natively.

Compiling any C file with cc/gcc produces:
q800 17:54:35 ~> gcc -o foo foo.c
gcc: error trying to exec '/usr/libexec/cc1': execv: Cannot allocate memory
q800 17:48:55 ~> /usr/libexec/cc1
-bash: /usr/libexec/cc1: Cannot allocate memory
q800 17:54:41 ~> file /usr/libexec/cc1
/usr/libexec/cc1: ELF 32-bit MSB shared object, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 7.99.59, not stripped

This worked fine with a stock 7.0.2 install, so this seems new to -current.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 29 Jan 2017 17:40:53 +0900

 This is probably because text size of GCC (~ 9MB) is larger than
 MAXTSIZE (= 8MB), c.f., the following thread in port-m68k:

    http://mail-index.netbsd.org/port-m68k/2016/11/15/msg000665.html

 Could you please add

    options MAXTSIZ (16*1024*1024)

 to your kernel configuration file, and retry self-compiling?

 Thanks,
 Rin

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: gnats-bugs@NetBSD.org, bbraun@synack.net
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 29 Jan 2017 18:30:38 +0900

 On 2017/01/29 17:45, Rin Okuyama wrote:
 >  Could you please add
 >
 >     options MAXTSIZ (16*1024*1024)
 >
 >  to your kernel configuration file, and retry self-compiling?

 Sorry for confusing you. It should be:

    options MAXTSIZ="(16*1024*1024)"

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, port-mac68k-maintainer@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 29 Jan 2017 10:21:43 -0500

 On Jan 28, 10:35pm, bbraun@synack.net (bbraun@synack.net) wrote:
 -- Subject: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory

 | gcc: error trying to exec '/usr/libexec/cc1': execv: Cannot allocate memory
 | q800 17:48:55 ~> /usr/libexec/cc1
 | -bash: /usr/libexec/cc1: Cannot allocate memory
 | q800 17:54:41 ~> file /usr/libexec/cc1
 | /usr/libexec/cc1: ELF 32-bit MSB shared object, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 7.99.59, not stripped
 | 
 | This worked fine with a stock 7.0.2 install, so this seems new to -current.
 | >How-To-Repeat:

 What does "size /usr/libexec/cc1" say?

 christos

From: Rob Braun <bbraun@synack.net>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 29 Jan 2017 09:25:44 -0800

 On Sun, Jan 29, 2017 at 03:25:00PM +0000, Christos Zoulas wrote:
 >  
 >  What does "size /usr/libexec/cc1" say?

 q800# size /usr/libexec/cc1
    text    data     bss     dec     hex filename
 9359296  856508  244092 10459896         9f9af8 /usr/libexec/cc1

  On 2017/01/29 17:45, Rin Okuyama wrote:
 > >  Could you please add
 > >
 > >     options MAXTSIZ (16*1024*1024)
 > >
 > >  to your kernel configuration file, and retry self-compiling?
 > 
 > Sorry for confusing you. It should be:
 > 
 >    options MAXTSIZ="(16*1024*1024)"

 That worked, thanks!  Would it make sense to increase this by default?

 Rob

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, bbraun@synack.net
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 29 Jan 2017 21:21:29 +0100

 On Sun, Jan 29, 2017 at 09:35:01AM +0000, Rin Okuyama wrote:
 > The following reply was made to PR port-mac68k/51923; it has been noted by GNATS.
 > 
 > From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
 > To: gnats-bugs@NetBSD.org, bbraun@synack.net
 > Cc: 
 > Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
 > Date: Sun, 29 Jan 2017 18:30:38 +0900
 > 
 >  On 2017/01/29 17:45, Rin Okuyama wrote:
 >  >  Could you please add
 >  >
 >  >     options MAXTSIZ (16*1024*1024)
 >  >
 >  >  to your kernel configuration file, and retry self-compiling?
 >  
 >  Sorry for confusing you. It should be:
 >  
 >     options MAXTSIZ="(16*1024*1024)"

 Are there any inherent platform reasons for not using the same limits as
 i386 by default? E.g. 256MB for MAXTSIZ, 3GB for data size and 64MB for
 stack?

 Joerg

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: Joerg Sonnenberger <joerg@bec.de>
Cc: gnats-bugs@NetBSD.org, port-mac68k-maintainer@NetBSD.org,
        gnats-admin@NetBSD.org, bbraun@synack.net
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 29 Jan 2017 21:25:33 +0100

 On Sun, 29 Jan 2017 21:21:29 +0100, Joerg Sonnenberger wrote:
 > Are there any inherent platform reasons for not using the same limits as
 > i386 by default? E.g. 256MB for MAXTSIZ, 3GB for data size and 64MB for
 > stack?

 <http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=9725>?

 hauke

From: Joerg Sonnenberger <joerg@bec.de>
To: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Cc: Joerg Sonnenberger <joerg@bec.de>, gnats-bugs@NetBSD.org,
	port-mac68k-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
	bbraun@synack.net
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 29 Jan 2017 22:09:06 +0100

 On Sun, Jan 29, 2017 at 09:25:33PM +0100, Hauke Fath wrote:
 > On Sun, 29 Jan 2017 21:21:29 +0100, Joerg Sonnenberger wrote:
 > > Are there any inherent platform reasons for not using the same limits as
 > > i386 by default? E.g. 256MB for MAXTSIZ, 3GB for data size and 64MB for
 > > stack?
 > 
 > <http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=9725>?

 That's a pmap bug, but not necessarily a platform limitation. Compare
 with acorn26 and the 32MB (?) total VA limit.

 Joerg

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Mon, 30 Jan 2017 14:52:07 +0000 (UTC)

 joerg@bec.de (Joerg Sonnenberger) writes:

 >Are there any inherent platform reasons for not using the same limits as
 >i386 by default? E.g. 256MB for MAXTSIZ, 3GB for data size and 64MB for
 >stack?

 Wouldn't that be silly? 256MB text with 128MB total address space?

 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Tue, 31 Jan 2017 00:25:15 +0900

 On 2017/01/30 23:55, Michael van Elst wrote:
 >  joerg@bec.de (Joerg Sonnenberger) writes:
 >
 >  >Are there any inherent platform reasons for not using the same limits as
 >  >i386 by default? E.g. 256MB for MAXTSIZ, 3GB for data size and 64MB for
 >  >stack?
 >
 >  Wouldn't that be silly? 256MB text with 128MB total address space?

 Well, but it is too inconvenient that just using GCC requires a customized
 kernel. Couldn't we increase MAXTSIZ to at least 16MB, for example, on all
 m68k ports? I think it better to make some action before branching netbsd-8.

 Thanks,
 rin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Mon, 30 Jan 2017 16:39:34 +0100

 On Mon, Jan 30, 2017 at 03:30:01PM +0000, Rin Okuyama wrote:
 >  Well, but it is too inconvenient that just using GCC requires a customized
 >  kernel. Couldn't we increase MAXTSIZ to at least 16MB, for example, on all
 >  m68k ports? I think it better to make some action before branching netbsd-8.

 Yes, please do that. We can bump it further up when the new pmap finally
 arrives in-tree. Mike, are you listening?

 Martin

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Mon, 30 Jan 2017 17:48:30 +0000 (UTC)

 rokuyama@rk.phys.keio.ac.jp (Rin Okuyama) writes:

 > >  Wouldn't that be silly? 256MB text with 128MB total address space?
 > 
 > Well, but it is too inconvenient that just using GCC requires a customized
 > kernel. Couldn't we increase MAXTSIZ to at least 16MB, for example, on all
 > m68k ports?

 atari and hp300 have 16MB for quite some time. amiga was bumped to 32MB
 when gcc failed this way.

 I'm all for using a common 32MB MAXTSIZ for m68k, but some archs may
 require additional adjustments.

 sun2 will probably never run gcc natively again.

 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, bbraun@synack.net
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Mon, 30 Jan 2017 21:17:18 +0100

 On Mon, Jan 30, 2017 at 02:55:01PM +0000, Michael van Elst wrote:
 > The following reply was made to PR port-mac68k/51923; it has been noted by GNATS.
 > 
 > From: mlelstv@serpens.de (Michael van Elst)
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
 > Date: Mon, 30 Jan 2017 14:52:07 +0000 (UTC)
 > 
 >  joerg@bec.de (Joerg Sonnenberger) writes:
 >  
 >  >Are there any inherent platform reasons for not using the same limits as
 >  >i386 by default? E.g. 256MB for MAXTSIZ, 3GB for data size and 64MB for
 >  >stack?
 >  
 >  Wouldn't that be silly? 256MB text with 128MB total address space?

 Total address space or maximum physical memory? That's why I asked
 whether there are platforms reasons for very tight limits.

 Joerg

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Tue, 31 Jan 2017 06:39:24 +0900

 On 2017/01/31 2:50, Michael van Elst wrote:
 >  I'm all for using a common 32MB MAXTSIZ for m68k, but some archs may
 >  require additional adjustments.

 The followings are vmparam's on m68k ports. What would you mean by
 adjustments specifically?

 +--------------+---------+---------+---------+---------+---------+
 |              | MAXTSIZ | DFLDSIZ | MAXDSIZ | DFLSSIZ | MAXSSIZ |
 +--------------+---------+---------+---------+---------+---------+
 | amiga        |   32m   |   64m   |  224m   |     2m  |   32m   |
 | atari, hp300 |   16m   |   32m   |  256m   |     2m  |  256m   |
 | cesfic       |    8m   |   32m   |   64m   |   512k  |   64m   |
 | mac68k       |    8m   |   32m   |   64m   |     2m  |   32m   |
 | sun3         |    8m   |   16m   |   32m   |   512k  |   32m   |
 | sun3x        |    8m   |   16m   |   32m   |   512k  |   32m   |
 | others (*)   |    8m   |   16m   |   64m   |   512k  |   64m   |
 +--------------+---------+---------+---------+---------+---------+
 | MAX          |   32m   |   64m   |  256m   |     2m  |  256m   |
 | MIN          |    8m   |   16m   |   32m   |   512k  |   32m   |
 +--------------+---------+---------+---------+---------+---------+

 (*) luna68k, news68k, next68k, and x68k

 Thanks,
 rin

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Tue, 31 Jan 2017 21:28:57 +0000 (UTC)

 rokuyama@rk.phys.keio.ac.jp (Rin Okuyama) writes:

 > The followings are vmparam's on m68k ports. What would you mean by
 > adjustments specifically?

 Something like SYSPTSIZE. There might be other hardcoded values that
 don't work anymore if you increase the address space (and not just the
 text size limit).

 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Wed, 1 Feb 2017 07:46:56 +0900

 On 2017/02/01 6:30, Michael van Elst wrote:
 >  Something like SYSPTSIZE. There might be other hardcoded values that
 >  don't work anymore if you increase the address space (and not just the
 >  text size limit).

 I guess that SYSPTSIZE has already been obsoleted:

    % find sys common -type f | xargs grep SYSPTSIZE | grep -v vmparam.h
    sys/arch/mac68k/mac68k/genassym.cf:define       SYSPTSIZE               SYSPTSIZE
    sys/arch/vax/vax/pmap.c:        printf("SYSPTSIZE %x usrptsize %lx\n",

 Probably we can remove it as well as USRPTSIZE.

 VM_{MIN,MAX} stuff seems OK to me. Do we have other hardcoded constants?

 Thanks,
 Rin

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Fri, 3 Feb 2017 05:08:44 +0900

 Ping? I'd like to

 - remove unused SYSPTSIZE and USRPTSIZE
 - bump default MAXTSIZ to 32MB

 for m68k ports if there's no objection.

 Thanks,
 rin

From: John Klos <john@ziaspace.com>
To: gnats-bugs@NetBSD.org
Cc: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Thu, 2 Feb 2017 21:14:45 +0000 (UTC)

 > Ping? I'd like to
 >
 > - remove unused SYSPTSIZE and USRPTSIZE
 > - bump default MAXTSIZ to 32MB
 >
 > for m68k ports if there's no objection.

 Please do.

 John

From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/51923 CVS commit: src/sys/arch
Date: Thu, 2 Feb 2017 21:50:23 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Thu Feb  2 21:50:23 UTC 2017

 Modified Files:
 	src/sys/arch/atari/include: vmparam.h
 	src/sys/arch/cesfic/include: vmparam.h
 	src/sys/arch/hp300/include: vmparam.h
 	src/sys/arch/luna68k/include: vmparam.h
 	src/sys/arch/mac68k/include: vmparam.h
 	src/sys/arch/mac68k/mac68k: genassym.cf
 	src/sys/arch/mvme68k/include: vmparam.h
 	src/sys/arch/news68k/include: vmparam.h
 	src/sys/arch/next68k/include: vmparam.h
 	src/sys/arch/x68k/include: vmparam.h

 Log Message:
 PR port-mac68k/51923
 Remove unused SYSPTSIZE and USRPTSIZE from m68k ports.
 Ok jklos


 To generate a diff of this commit:
 cvs rdiff -u -r1.29 -r1.30 src/sys/arch/atari/include/vmparam.h
 cvs rdiff -u -r1.15 -r1.16 src/sys/arch/cesfic/include/vmparam.h
 cvs rdiff -u -r1.37 -r1.38 src/sys/arch/hp300/include/vmparam.h
 cvs rdiff -u -r1.19 -r1.20 src/sys/arch/luna68k/include/vmparam.h
 cvs rdiff -u -r1.42 -r1.43 src/sys/arch/mac68k/include/vmparam.h
 cvs rdiff -u -r1.37 -r1.38 src/sys/arch/mac68k/mac68k/genassym.cf
 cvs rdiff -u -r1.34 -r1.35 src/sys/arch/mvme68k/include/vmparam.h
 cvs rdiff -u -r1.19 -r1.20 src/sys/arch/news68k/include/vmparam.h
 cvs rdiff -u -r1.23 -r1.24 src/sys/arch/next68k/include/vmparam.h
 cvs rdiff -u -r1.36 -r1.37 src/sys/arch/x68k/include/vmparam.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/51923 CVS commit: src/sys/arch
Date: Thu, 2 Feb 2017 21:53:55 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Thu Feb  2 21:53:55 UTC 2017

 Modified Files:
 	src/sys/arch/atari/include: vmparam.h
 	src/sys/arch/cesfic/include: vmparam.h
 	src/sys/arch/hp300/include: vmparam.h
 	src/sys/arch/luna68k/include: vmparam.h
 	src/sys/arch/mac68k/include: vmparam.h
 	src/sys/arch/mvme68k/include: vmparam.h
 	src/sys/arch/news68k/include: vmparam.h
 	src/sys/arch/next68k/include: vmparam.h
 	src/sys/arch/sun3/include: vmparam3.h vmparam3x.h
 	src/sys/arch/x68k/include: vmparam.h

 Log Message:
 PR port-mac68k/51923
 Bump default MAXTSIZ to 32MB for m68k ports, which allos us to use GCC 5.4 on
 GENERIC kernels.
 Ok jklos


 To generate a diff of this commit:
 cvs rdiff -u -r1.30 -r1.31 src/sys/arch/atari/include/vmparam.h
 cvs rdiff -u -r1.16 -r1.17 src/sys/arch/cesfic/include/vmparam.h
 cvs rdiff -u -r1.38 -r1.39 src/sys/arch/hp300/include/vmparam.h
 cvs rdiff -u -r1.20 -r1.21 src/sys/arch/luna68k/include/vmparam.h
 cvs rdiff -u -r1.43 -r1.44 src/sys/arch/mac68k/include/vmparam.h
 cvs rdiff -u -r1.35 -r1.36 src/sys/arch/mvme68k/include/vmparam.h
 cvs rdiff -u -r1.20 -r1.21 src/sys/arch/news68k/include/vmparam.h
 cvs rdiff -u -r1.24 -r1.25 src/sys/arch/next68k/include/vmparam.h
 cvs rdiff -u -r1.37 -r1.38 src/sys/arch/sun3/include/vmparam3.h
 cvs rdiff -u -r1.22 -r1.23 src/sys/arch/sun3/include/vmparam3x.h
 cvs rdiff -u -r1.37 -r1.38 src/sys/arch/x68k/include/vmparam.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: John Klos <john@ziaspace.com>, gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Fri, 3 Feb 2017 06:59:23 +0900

 On 2017/02/03 6:14, John Klos wrote:
 > Please do.

 Thank you, I committed them.

 Rob, could you please check kernel from -current without MAXTSIZ option?

 rin

From: Rob Braun <bbraun@synack.net>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Thu, 2 Feb 2017 20:32:20 -0800

 On Thu, Feb 02, 2017 at 10:00:00PM +0000, Rin Okuyama wrote:
 >  
 >  Rob, could you please check kernel from -current without MAXTSIZ option?

 That did it, thanks!

 Rob

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: Rob Braun <bbraun@synack.net>, gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Fri, 3 Feb 2017 17:54:44 +0900

 On 2017/02/03 13:32, Rob Braun wrote:
 > That did it, thanks!

 Thank you so much for your quick response!

 I will close the PR if no complaints arise for a while.

 rin

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sat, 4 Feb 2017 23:48:23 +0000

 On Mon, Jan 30, 2017 at 05:50:00PM +0000, Michael van Elst wrote:
  >  atari and hp300 have 16MB for quite some time. amiga was bumped to 32MB
  >  when gcc failed this way.
  >  
  >  I'm all for using a common 32MB MAXTSIZ for m68k, but some archs may
  >  require additional adjustments.

 Trying to run gcc natively on m68k is increasingly hopeless... what is
 the state of m68k pcc?

  >  sun2 will probably never run gcc natively again.

 overlays!

 -- 
 David A. Holland
 dholland@netbsd.org

From: Rin Okuyama <rokuyama@rk.phys.keio.ac.jp>
To: gnats-bugs@NetBSD.org, dholland-bugs@netbsd.org
Cc: 
Subject: Re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Sun, 5 Feb 2017 09:03:47 +0900

 On 2017/02/05 8:50, David Holland wrote:
 >  Trying to run gcc natively on m68k is increasingly hopeless... what is
 >  the state of m68k pcc?

 No. That's a misunderstanding. GCC *does* natively run on m68k. The problem
 arises just because the default value of MAXTSIZ is too small for GCC, but
 it has already been resolved.

 >   >  sun2 will probably never run gcc natively again.
 >
 >  overlays!

 Yep, we set MKGCCCMDS=no on m68010. I don't know the status of PCC on it...

 Thanks,
 rin

State-Changed-From-To: open->closed
State-Changed-By: rin@NetBSD.org
State-Changed-When: Sun, 05 Feb 2017 00:09:22 +0000
State-Changed-Why:
Fix confirmed at least on mac68k and x68k. Leaving the PR open turned out
to confuse people. Thus I decided to close it. If you find any problem,
please feel free to open it!


From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, bbraun@synack.net
Subject: re: port-mac68k/51923: /usr/libexec/cc1: Cannot allocate memory
Date: Mon, 06 Feb 2017 01:17:59 +1100

 >  sun2 will probably never run gcc natively again.

 that pretty much died with gmp gcc.  we don't actually
 build native gcc for sun2 anymore... 


 .mrg.

>Unformatted:

Home	PR Database Search