[Bug ada/15230] New: Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[Bug ada/15230] New: Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

This is on LAST_UPDATED from HEAD at Fri Apr 30 12:48:41 UTC 2004.

Building everything configured as

  --host=i686-suse9-linux-gnu --target=i686-suse9-linux-gnu \
  --build=i686-suse9-linux-gnu --srcdir=../gcc-20040430 --prefix=/opt/gnu \
  --with-gnu-as --with-gnu-ld --enable-__cxa_atexit --disable-checking \
  --enable-clocale=gnu --enable-interpreter --enable-shared \
  --enable-threads=posix --with-system-zlib --with-local-prefix=/opt/gnu \
  --with-cpu=i686 --enable-nls --verbose \
  --enable-languages=c,ada,c++,f77,java,objc

and

  BOOT_CFLAGS="-O2 -march=i386 -mtune=i686 -fomit-frame-pointer"
  CFLAGS="-O2 -march=i386 -mtune=i686 -fomit-frame-pointer"
  CXXFLAGS="-O2 -march=i386 -mtune=i686 -fomit-frame-pointer -g"
  GCJFLAGS="-O2 -march=i386 -mtune=i686 -fomit-frame-pointer -g"

results in the following when gcc-3.5.0 is used:

  (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -b ../nmake.adb )

  raised STORAGE_ERROR : stack overflow (or erroneous memory access)
  gmake[2]: *** [ada/nmake.adb] Error 1
  gmake[2]: Leaving directory
`/home/gnu/work/GNU/gcc-20040430-i686-suse9-linux-gnu/gcc'

Using gcc-3.4.0 instead does not show this error. It's currently impossible to
build GNAT using a gcc-3.5.0; this is not actually a new issue, but has happened
for quite some time now.

-- 
           Summary: Building xnmake using a 3.5.0 GNAT results in
                    STORAGE_ERROR
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ada
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: manfred dot h at gmx dot net
                CC: gcc-bugs at gcc dot gnu dot org,manfred dot h at gmx dot
                    net
 GCC build triplet: i686-suse9-linux-gnu
  GCC host triplet: i686-suse9-linux-gnu
GCC target triplet: i686-suse9-linux-gnu


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

[Bug optimization/15230] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[charlet at gcc dot gnu dot org]

------- Additional Comments From charlet at gcc dot gnu dot org  2004-05-03 12:37 -------
Looks like a codegen issue of some sort.
Probably using less aggressive optimization flags would avoid this problem.

Does the problem still reproduce with current sources btw ?

Arno

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|ada                         |optimization


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
            Summary|Building xnmake using a     |[3.5 Regression] Building
                   |3.5.0 GNAT results in       |xnmake using a 3.5.0 GNAT
                   |STORAGE_ERROR               |results in STORAGE_ERROR
   Target Milestone|---                         |3.5.0


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-03 13:21 -------
I didn't check with today's sources, but I doubt, that anything has changed
since the copy I used last time (LAST_UPDATED: Fri Apr 30 12:48:41 UTC 2004).

-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-03 14:53 -------
Using "less aggressive optimization flags" is not going to help here, as this
problem happens while the stage1 compiler is built, not after; hence, no
BOOT_CFLAGS are used, only the standard flags are in effect here.

I'm currently testing a checkout as of 2004/05/03 16:08:46 +0200; will update
the status accordingly.

-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[graham dot stott at btinternet dot com]

------- Additional Comments From graham dot stott at btinternet dot com  2004-05-03 14:58 -------
Subject: Re:  [3.5 Regression] Building xnmake using
 a 3.5.0 GNAT results in STORAGE_ERROR

manfred dot h at gmx dot net wrote:
> ------- Additional Comments From manfred dot h at gmx dot net  2004-05-03 14:53 -------
> Using "less aggressive optimization flags" is not going to help here, as this
> problem happens while the stage1 compiler is built, not after; hence, no
> BOOT_CFLAGS are used, only the standard flags are in effect here.
> 
> I'm currently testing a checkout as of 2004/05/03 16:08:46 +0200; will update
> the status accordingly.
> 

On i686-pc-linux-gnu the problem was present upto 2 May but with todays checkout
the problem appears to have gone away.

Cheers
Graham



-- 


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

Re: [Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[Graham Stott]

manfred dot h at gmx dot net wrote:
> ------- Additional Comments From manfred dot h at gmx dot net  2004-05-03 14:53 -------
> Using "less aggressive optimization flags" is not going to help here, as this
> problem happens while the stage1 compiler is built, not after; hence, no
> BOOT_CFLAGS are used, only the standard flags are in effect here.
> 
> I'm currently testing a checkout as of 2004/05/03 16:08:46 +0200; will update
> the status accordingly.
> 

On i686-pc-linux-gnu the problem was present upto 2 May but with todays checkout
the problem appears to have gone away.

Cheers
Graham

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-03 17:43 -------
(In reply to comment #4)
Hmm, I just finished the build, and installed it; using this compiler for the
bootstrap (using the exact same sources) still results in the original behaviour.

Graham, which flags (configure and runtime, ie. BOOT_CFLAGS, CFLAGS, CXXFLAGS)
did you actually use when you built the compiler which you could successfully
use as a bootstrap compiler?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |graham dot stott at
                   |                            |btinternet dot com


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-04 07:24 -------
Created an attachment (id=6219)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6219&action=view)
Debugging session for xnmake


-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-04 07:25 -------
OK, restarting at zero... Built and installed a new tool chain still from the
same sources, but this time using the default flags only, ie.

  BOOT_CFLAGS="-O2"
  CFLAGS="-O2"
  CXXFLAGS="-O2 -g"
  GCJFLAGS="-O2 -g"

Using this tool chain still crashes the same way as before. Running gdb-6.1 on
the crashed executable doesn't show much other than the call chain (see
attachment "gdb.log"). Here's again the excerpt from the build logs:

  mkdir -p ada/bldtools
  cp -p ../../gcc-20040503/gcc/ada/sinfo.ads
../../gcc-20040503/gcc/ada/nmake.adt ../../gcc-20040503/gcc/ada/xnmake.adb
ada/bldtools
  (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -b ../nmake.adb )

  raised STORAGE_ERROR : stack overflow (or erroneous memory access)
  gmake[2]: *** [ada/nmake.adb] Error 1
  gmake[2]: Leaving directory
`/home/gnu/work/GNU/gcc-20040503-i686-suse9-linux-gnu/gcc'
  gmake[1]: *** [stage1_build] Error 2
  gmake[1]: Leaving directory
`/home/gnu/work/GNU/gcc-20040503-i686-suse9-linux-gnu/gcc'
  gmake: *** [bootstrap] Error 2
  gmake: Leaving directory `/home/gnu/work/GNU/gcc-20040503-i686-suse9-linux-gnu'

-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[chrisp_42 at bigpond dot com]

------- Additional Comments From chrisp_42 at bigpond dot com  2004-05-04 23:10 -------
(In reply to comment #1)
> Looks like a codegen issue of some sort.
> Probably using less aggressive optimization flags would avoid this problem.
> 
> Does the problem still reproduce with current sources btw ?
> 
> Arno

This problem started occurring with the following patch:

date: 2004/04/17 06:53:41;  author: bonzini;  state: Exp;  lines: +19 -0
2004-04-17  Paolo Bonzini  <bonzini@gnu.org>

        * opts.c (decode_options): Do not enable flag_rename_registers
        and flag_web at -O3.
        * toplev.c (flag_rename_registers): Initialize
        flag_rename_registers and flag_web to
        AUTODETECT_FLAG_VAR_TRACKING.
        (default_debug_hooks): New global.
        (process_options): Initialize default_debug_hooks.  Warn if
        -fvar-tracking specified but not supported by the current
        debug format.  Do not run var tracking at -O0 or if not
        supported by the current debug format, even if
        -fvar-tracking was given.  If -fno-rename-registers
        is not specified, always run register renaming if var
        tracking is supported by the default debugging information
        format for the target, and we are at -O1 or higher; similarly
        for -fweb, but only at -O2 or higher.
        * doc/invoke.texi (Optimize Options): Document this.

This patch did not really change the compiler much - it just enabled the
rename-registers and web optimizations at lower optimization levels.  The
rename-registers had other problems and was disabled later with this patch:

date: 2004/04/20 09:27:25;  author: bonzini;  state: Exp;  lines: +10 -0
2004-04-19  Paolo Bonzini  <bonzini@gnu.org>

        Revert part of 2004-04-17 change that moved -frename-registers
        to -O1.  -frename-registers is buggy.

        * toplev.c (flag_rename_registers): Initialize to 0.
        * doc/invoke.texi (Optimize options): Move -frename-registers
        to "Not triggered by any -O level" section.  Adjust commentary
        accordingly.

The boot problem still remains so it is some miscompilation related to -fweb.
I can confirm that if -fweb is disabled, the compiler that is build can also
bootstrap itself.

If gnat-spitbot and gnat-spitbol-patterns are compiled with -fno-web and linked
with xnmake the error trasnforms to a constraint_error.  The result of all this
is that I still do not know if the problem is that the compiler generates bad
code or whether the ada runtime library is miscompiled.  Anyway more information
for someone that knows what -fweb does.

-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-04 23:14 -------
Honza, you wrote -fweb do you know if this is a bug in -fweb or somewhere else?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-05 16:55 -------
(In reply to comment #9)
> Honza, you wrote -fweb do you know if this is a bug in -fweb or somewhere else?

To further confirm what Chris found out, I finished a build and install of
today's checkout plus a small patch, which initializes flag_web to 0 in
gcc/toplev.c, which then in turn could be used _successfully_ to bootstrap the
same sources. FWIW, I'd suggest that we disable -fweb for now, until it's
clarified, why it influences Ada bootstrap badly. Shall I post a patch?

-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-12 10:21 -------
(In reply to comment #10)
> (In reply to comment #9)
> > Honza, you wrote -fweb do you know if this is a bug in -fweb or somewhere else?
> 
> To further confirm what Chris found out, I finished a build and install of
> today's checkout plus a small patch, which initializes flag_web to 0 in
> gcc/toplev.c, which then in turn could be used _successfully_ to bootstrap the
> same sources. FWIW, I'd suggest that we disable -fweb for now, until it's
> clarified, why it influences Ada bootstrap badly. Shall I post a patch?

Disabling -fweb for all languages actually pessimizes too much. I just tested a
small patch which adds "-fno-web" only to gcc's lang-specs for Ada; the
resulting compiler could bootstrap itself once again without the problems.

I'll attach the patch in a minute and send a message to gcc-patches as well.

-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-05-12 10:22 -------
Created an attachment (id=6264)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6264&action=view)
patch to fix the gnat bootstrap problems


-- 


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

[Bug optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[charlet at gcc dot gnu dot org]

------- Additional Comments From charlet at gcc dot gnu dot org  2004-05-12 14:33 -------
<<Disabling -fweb for all languages actually pessimizes too much>>

Do we have some data on the impact of this option ?
Could Honza have a look at this PR ?

Arno

-- 


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

[Bug rtl-optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-06-29 08:01 -------
If this is a -fweb bug, would someone be so kind to try and see 
if the following patch cures the problem? 
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00251.html 

-- 


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

[Bug rtl-optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-06-30 09:30 -------
(In reply to comment #14)
> If this is a -fweb bug, would someone be so kind to try and see 
> if the following patch cures the problem? 
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00251.html 

Just tried it on a tree checked out from mainline using "cvs -D 'Fri Apr 30
12:48:41 UTC 2004' co", but it didn't help in this case.

-- 


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

[Bug rtl-optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-17 03:58 -------
Well for this to be checked, we have to depend on Ada actually building.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |15416


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

[Bug rtl-optimization/15230] [3.5 Regression] Building xnmake using a 3.5.0 GNAT results in STORAGE_ERROR

[charlet at gcc dot gnu dot org]

-- 
Bug 15230 depends on bug 15416, which changed state.

Bug 15416 Summary: Can't bootstrap the gcc-3.5 Ada compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15416

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

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

[Bug rtl-optimization/15230] [4.0 Regression] Building xnmake using a 4.0.0 GNAT results in STORAGE_ERROR

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-10-07 09:30 -------
-fweb is now disabled on mainline because it is not needed after tree-ssa. 
Would you please check if this problem is fixed now?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug rtl-optimization/15230] [4.0 Regression] Building xnmake using a 4.0.0 GNAT results in STORAGE_ERROR

[manfred dot h at gmx dot net]

------- Additional Comments From manfred dot h at gmx dot net  2004-10-07 09:40 -------
(In reply to comment #17)
> -fweb is now disabled on mainline because it is not needed after tree-ssa. 
> Would you please check if this problem is fixed now?

The last time I checked was with a tree checked out on
"Sun Sep 26 13:10:14 UTC 2004". You can find the results at
<http://gcc.gnu.org/ml/gcc-testresults/2004-09/msg01171.html>;
so, the problem is apparently fixed now.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED


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