Bug 9270 - [mac68k] ICE in building blackbox-0.65.0
Summary: [mac68k] ICE in building blackbox-0.65.0
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 2.95.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2003-01-10 18:46 UTC by hhako
Modified: 2003-06-17 15:13 UTC (History)
1 user (show)

See Also:
Host: m68k-netbsd
Target: m68k-netbsd
Build: m68k-netbsd
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Screen.ii.gz (92.07 KB, application/x-gzip )
2003-05-21 15:16 UTC, hhako
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hhako 2003-01-10 18:46:01 UTC
c++ -DHAVE_CONFIG_H -I. -I. -I..   -I/usr/pkg/include -I/usr/X11R6/include -DSHAPE  -DNDEBUG -DNLS -DTIMEDCACHE -DLOCALEPATH=\"/usr/X11R6/share/blackbox/nls\" -DDEFAULTMENU=\"/usr/X11R6/share/blackbox/menu\" -DDEFAULTSTYLE=\"/usr/X11R6/share/blackbox/styles/Results\"  -O2 -I/usr/pkg/include -I/usr/X11R6/include  -I/usr/X11R6/include -Wall -W -pedantic -c Screen.cc
In file included from /usr/include/g++/alloc.h:21,
                 from /usr/include/g++/std/bastring.h:39,
                 from /usr/include/g++/string:6,
                 from Screen.cc:75:
/usr/include/g++/stl_alloc.h:1055: warning: ANSI C++ forbids the use of `extern' on explicit instantiations
/usr/include/g++/stl_alloc.h:1056: warning: ANSI C++ forbids the use of `extern' on explicit instantiations
/usr/include/g++/stl_alloc.h:1056: warning: ANSI C++ forbids the use of `extern' on explicit instantiations
/usr/include/g++/stl_alloc.h:1056: warning: ANSI C++ forbids the use of `extern' on explicit instantiations
Screen.cc: In method `void BScreen::LoadStyle()':
Screen.cc:742: Internal compiler error.
Screen.cc:742: Please submit a full bug report.
Screen.cc:742: See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

Release:
gcc version 2.95.3 20010315 (release) (NetBSD nb3)

Environment:
NetBSD 1.6 (GENERICSBC) #0: 
Macintosh LCIII: 36MB RAM, 33Mhz CPU.

How-To-Repeat:
http://prdownloads.sf.net/blackboxwm/blackbox-0.65.0.tar.gz
Comment 1 Wolfgang Bangerth 2003-03-25 01:13:32 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: This report is against a rather old version of gcc, namely
    2.95. Do you have any idea whether the problem still appears
    with newer versions of gcc, e.g. 3.2.2? The 2.95 branch has
    long since been abandoned.
    
    Thanks
      Wolfgang
Comment 2 Dara Hazeghi 2003-05-09 18:02:59 UTC
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org, hhako@seagreen.ocn.ne.jp
Cc:  
Subject: Re: c++/9270: [mac68k] ICE in building blackbox-0.65.0
Date: Fri, 9 May 2003 18:02:59 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=9270
 
 Hello,
 
 could the submitter please report whether this bug occurs in a more  
 current release (ie gcc 3.2.3) and if so, submit a preprocessed source  
 file from that version? Thanks,
 
 Dara
Comment 3 Dara Hazeghi 2003-06-16 20:20:45 UTC
Just a reminder: this bug is awaiting feedback. Can you check whether this problem occurs with 
gcc 3.3? Thanks,

Dara
Comment 4 hhako 2003-06-17 04:19:30 UTC
Subject: Re:  [mac68k] ICE in building blackbox-0.65.0

> Just a reminder: this bug is awaiting feedback. Can you check whether  
> this problem occurs with
> gcc 3.3? Thanks,
Thank you for your email.
I can not check it now. Because I moved and have to make LAN at home  
again to connect the computer to Internet. Without net, I can not  
install gcc 3.3.

By the way, after sending bug report, I could actually compile blackbox  
by gcc 2.95. I followed

http://mail-index.NetBSD.org/port-mac68k/2003/01/21/0008.html

which is a mail in the port-mac68k mailing list.

Best Regards,

Hiroshi Hakoyama

On 2003.6.17, at 05:20 $B8aA0(B, dhazeghi@yahoo.com wrote:

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT*  
> gcc-bugs@gcc.gnu.org.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9270
>
>
> dhazeghi@yahoo.com changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------- 
> -----
>                  CC|dhazeghi@yahoo.com          |
>   GCC build triplet|                            |m68k-netbsd
>    GCC host triplet|                            |m68k-netbsd
>  GCC target triplet|                            |m68k-netbsd
>
>
> ------- Additional Comments From dhazeghi@yahoo.com  2003-06-16 20:20  
> -------
> Just a reminder: this bug is awaiting feedback. Can you check whether  
> this problem occurs with
> gcc 3.3? Thanks,
>
> Dara
>
>
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
>

Comment 5 Dara Hazeghi 2003-06-17 07:23:57 UTC
Just to clarify, you mean the problem disappeared when you raised the memory limit? If so, I'd not 
call it a gcc bug (though if you want to file request that gcc use less memory, I suppose that's 
possible. Thanks,

Dara
Comment 6 hhako 2003-06-17 08:01:43 UTC
Subject: Re:  [mac68k] ICE in building blackbox-0.65.0

> ------- Additional Comments From dhazeghi@yahoo.com  2003-06-17 07:23 
> -------
> Just to clarify, you mean the problem disappeared when you raised the 
> memory limit?
Yes.

Best Regards,

Hiroshi Hakoyama

Comment 7 Dara Hazeghi 2003-06-17 13:37:37 UTC
Well, in that case, this isn't really a gcc bug. I suppose we could be more graceful about our error 
recovery, but... Anyhow, if you still think this is a problem, send the preprocessed source from a 
newer version of gcc (3.0 or later). If not, we'll consider the issue solved...
Comment 8 Wolfgang Bangerth 2003-06-17 13:56:35 UTC
The problem of being more graceful when we run out of memory has been 
discussed many times and been deemed too hard. The reason is that modern
OSs overcommit memory, so malloc returns something, but once you start writing
to it, you'll get a signal. It was considered too hard to catch the real
cause of the signal.

So, if the cause of this PR is out-of-memory, we should close it.

W.
Comment 9 Dara Hazeghi 2003-06-17 15:13:37 UTC
Yes, the message Hiroshi linked to indicated increasing the shell's memory limits fixed the 
problem. So I'm closing this. Thanks for the feedback Hiroshi, and for the clarification Wolfgang.