[Bug optimization/12209] New: GCC fails to bootstrap Cygwin with -funit-at-a-time

[Bug optimization/12209] New: GCC fails to bootstrap Cygwin with -funit-at-a-time

[kcook at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: GCC fails to bootstrap Cygwin with -funit-at-a-time
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P2
         Component: optimization
        AssignedTo: hubicka at gcc dot gnu dot org
        ReportedBy: kcook at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin

When -funit-at-a-time is used for bootstrap, as is now the default since has
been added to -O2, Cygwin ICEs when compiling __popcountsi2 for libgcc2 after
the stage2 compiler is built.

The workaround is 

make BOOT_CFLAGS="-O2 -fno-unit-a-time -g" bootstrap

which will work.

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
           Keywords|                            |ice-on-valid-code
            Summary|GCC fails to bootstrap      |[3.4 Regression] GCC fails
                   |Cygwin with -funit-at-a-time|to bootstrap Cygwin with -
                   |                            |funit-at-a-time
   Target Milestone|---                         |3.4


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-09-08 14:23 -------
What is the ICE you get?

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[kcook at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From kcook at gcc dot gnu dot org  2003-09-08 14:32 -------
Created an attachment (id=4717)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4717&action=view)
libgcc preprocessed after -DL_popcountsi2

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[kcook at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From kcook at gcc dot gnu dot org  2003-09-08 14:38 -------
Created an attachment (id=4718)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4718&action=view)
Backtrace of the crash

./xgcc -B./ -B/usr/local/i686-pc-cygwin/bin/ -isystem
/usr/local/i686-pc-cygwin/
include -isystem /usr/local/i686-pc-cygwin/sys-include
-L/home/kcook34/t/gcc/../
ld -O2 -I/home/kcook34//gcc-snapshot/gcc/../winsup/w32api/include
-I/home/kcook3
4//gcc-snapshot/gcc/../winsup/include
-I/home/kcook34//gcc-snapshot/gcc/../winsu
p/cygwin/include -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmiss
ing-prototypes -isystem ./include   -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_
FLOAT_NOT_NEEDED  -I. -I. -I/home/kcook34//gcc-snapshot/gcc
-I/home/kcook34//gcc
-snapshot/gcc/. -I/home/kcook34//gcc-snapshot/gcc/../include   -DL_popcountsi2
-
c /home/kcook34//gcc-snapshot/gcc/libgcc2.c -o libgcc/./_popcountsi2.o
/home/kcook34//gcc-snapshot/gcc/libgcc2.c: In function `__popcountsi2':

/home/kcook34//gcc-snapshot/gcc/libgcc2.c:751: internal compiler error:
Segmenta
tion fault
Please submit a full bug report,
with preprocessed source if appropriate.

---

A Backtrace is attached.

On a whim, I tried to compile with -funit-at-a-time enabled and
-fno-loop-optimize which does work.  So possibly -funit-at-a-time seems to be
poorly interacting with the loop optimizer.

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From pinskia at gcc dot gnu dot org  2003-09-08 14:47 -------
I want to say it is not unit-at-a-time interacting with the loop optimizer but that a misscompiling 
somehow with unit-at-a-time is causing this because stage 2 is compiled with the unit-at-a-time 
already which must of misscompiled it somehow.

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[c dot christian dot joensson at comhem dot se]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


c dot christian dot joensson at comhem dot se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christian at j-son dot org

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-09-17 18:14:49
               date|                            |

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[kcook at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From kcook at gcc dot gnu dot org  2003-09-17 18:02 -------
Created an attachment (id=4776)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4776&action=view)
cgraph dump from loop.c with "-O2 -g -funit-at-a-time -da" specified

Some further investigation reveals that Andrew is correct, the loop-optimzier
is not behaving poorly with UAT, it is actually loop.c that is being
miscompiled when "-funit-at-a-time" is enabled.

I deduced this by make CFLAGS="-O2 -fno-unit-at-a-time -g -da" loop.o moving
off the resulting files and then with make CFLAGS="-O2 -funit-at-a-time -g -da"
loop.o and looking at each.

Note that compiling just loop.c with -fno-unit-at-time allows the rest of the
compiler to be built.

I also compiled loop.c at "-O0" with and without "-funit-at-a-time", both of
these do work fine.

I can get some more attempt to get more details if asked, but the problem I am
having is that even the initial loop.c.00.rtl dumps are completely different
depending on whether "-funit-at-a-time" is on or off.  So I can't easily tell
what is different between the two.

The one thing I did notice, though I profess to having no idea how cgraph works
is that that in the "-O2 -funit-at-a-time dump" of loop.c.00.cgraph, scan_loop
ends up with no callers in the final cgraph dump.  I think this is wrong as it
is still called by loop_optimize even though cgraph decided to inline the
entire thing.  

The inital bug report was that the compiler will ICE basically right when it
attempts to call scan_loops, so my guess is that this is where the problem
happens.

I have attached that cgraph dump file.

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[dannysmith at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-10-08 07:51 -------
This bug appears to be the same as __attribute__((regparm())  vs  the
stack probing code (cygwin.asm)  reported here (with testcase):

http://www.cygwin.com/ml/cygwin/2002-06/msg00122.html

If change regparm(3) to fastcall in  the above testcase, it succeeds.
fastcall use ECX not EAX as the first allocated register.

Danny

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[hubicka at ucw dot cz]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From hubicka at ucw dot cz  2003-10-08 08:30 -------
Subject: Re:  [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12209
> 
> 
> 
> ------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-10-08 07:51 -------
> This bug appears to be the same as __attribute__((regparm())  vs  the
> stack probing code (cygwin.asm)  reported here (with testcase):
> 
> http://www.cygwin.com/ml/cygwin/2002-06/msg00122.html
> 
> If change regparm(3) to fastcall in  the above testcase, it succeeds.
> fastcall use ECX not EAX as the first allocated register.

OK, when exactly stack probing happens?  I think we have two choices.
Either disqualify regparm (at least emit warning on it) and modify
unit-at-a-time code or fix stack probing somehow.  What sounds as better
approach?

Honza
> 
> Danny
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[rmathew at hotmail dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From rmathew at hotmail dot com  2003-10-09 07:09 -------
Honza, this bug is similar to the problem that
Mohan had with -funit-at-a-time and bootstrap
for MinGW and that I sent you a mail some time
back about ("Re: New MingW 3.4 Build").

Win32 compilers emit a call to _chkstk( ) 
as a part of a method prologue whenever 
the local variables' size in the method 
exceeds CHECK_STACK_LIMIT ( == 4K).

This method is defined in "gcc/config/i386/cygwin.asm"
for both CygWin and MinGW and seems to
expect the total size of the locals in
EAX.

The call to _chkstk( ) is emitted as a
part of ix86_expand_prologue( ) in
"gcc/config/i386/i386.c" - see the 
"else condition" with the comment
"/* ??? Is this only valid for Win32?  */".

This worked fine till "-funit-at-a-time"
came along - in particular, AFAICT,
ix86_function_regparm( ) in "gcc/config/i386/i386.c"
has the code (in the third inner "if" block
inside the first outer "if" block) that
converts a local function into a 
regparm(3) function. regparm(3) seems
to use EAX in addition to ECX and EDX
that "fastcall" uses, which conflicts
with _chkstk( ) as described above and
results in clobbered arguments to methods.

IMHO, the fix could be to unconditionally
convert such functions only to regparm(2)
or use a marker in the function's decl
that says that it would require stack
limit to be checked and hence can only be
converted to a regparm(2) function.

Another, possibly better, fix would be
to change ix86_expand_prologue( ) and
_chkstk( ) to use another register to
communicate the allocation size information.

I do not know how feasible this is on
a register starved architecture like
the x86-32 though.

Ranjit.

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[dannysmith at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-10-09 22:41 -------
Hi,

My rather naive attempt to fix for unit-at-a-time optimization is just to mimic 
fastcall.

The following patch seems to work on simple testcase, but I'm sure I missed 
something. Bootstrap in progress.  The building of libgcj will take some time 
(overnight on my machine)

	* config/i386.c (ix86_function_regparm): Return 2 for cgraph
	local function optimization if TARGET_STACK_PROBE.
	(init_cum_args): Set cum->fastcall for cgraph local function
	optimization if TARGET_STACK_PROBE.


Index: i386.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.605
diff -c -3 -p -r1.605 i386.c
*** i386.c	6 Oct 2003 23:18:31 -0000	1.605
--- i386.c	9 Oct 2003 22:11:54 -0000
*************** ix86_function_regparm (tree type, tree d
*** 1699,1706 ****
  	  if (i && i->local)
  	    {
  	      /* We can't use regparm(3) for nested functions as these use
! 		 static chain pointer in third argument.  */
! 	      if (DECL_CONTEXT (decl) && !DECL_NO_STATIC_CHAIN (decl))
  		regparm = 2;
  	      else
  		regparm = 3;
--- 1699,1708 ----
  	  if (i && i->local)
  	    {
  	      /* We can't use regparm(3) for nested functions as these use
! 		 static chain pointer in third argument.
! 		 If maybe probing stack, use fastcall to avoid eax clobber.  */
! 	      if ((DECL_CONTEXT (decl) && !DECL_NO_STATIC_CHAIN (decl))
! 		  || TARGET_STACK_PROBE)
  		regparm = 2;
  	      else
  		regparm = 3;
*************** init_cumulative_args (CUMULATIVE_ARGS *c
*** 1855,1860 ****
--- 1857,1874 ----
        || (fntype && !TYPE_ARG_TYPES (fntype)))
      cum->maybe_vaarg = 1;
  
+   if (TARGET_STACK_PROBE && flag_unit_at_a_time
+       && !cum->fastcall
+       && cum->nregs)
+     {
+       struct cgraph_local_info *i = cgraph_local_info (fndecl);
+       if (i && i->local)
+ 	{
+ 	  cum->nregs = 2;
+ 	  cum->fastcall = 1;
+ 	}
+     }
+ 
    if (TARGET_DEBUG_ARG)
      fprintf (stderr, ", nregs=%d )\n", cum->nregs);

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[rmathew at hotmail dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From rmathew at hotmail dot com  2003-10-10 06:41 -------
Danny, is the assumption that fastcall is
valid for all targets that use TARGET_STACK_PROBE
correct?

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[dannysmith at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


dannysmith at gcc dot gnu dot org changed:

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


------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-10-10 08:11 -------
> Danny, is the assumption that fastcall is
> valid for all targets that use TARGET_STACK_PROBE
> correct?

No, I forgot test for !TARGET_64BIT.  

Danny

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[hubicka at ucw dot cz]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From hubicka at ucw dot cz  2003-10-10 16:37 -------
Subject: Re:  [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12209
> 
> 
> dannysmith at gcc dot gnu dot org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |dannysmith at gcc dot gnu
>                    |                            |dot org
> 
> 
> ------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-10-10 08:11 -------
> > Danny, is the assumption that fastcall is
> > valid for all targets that use TARGET_STACK_PROBE
> > correct?
> 
> No, I forgot test for !TARGET_64BIT.  

I think that you won't get into that code path at all in 64bit mode.
The patch looks fine to me.  Can you please send it to gcc-patches?
(actually I finally found time to write about the same thing :)
Thanks!

Honza
> 
> Danny
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-10-19 17:31 -------
*** Bug 12681 has been marked as a duplicate of this bug. ***

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[giovannibajo at libero dot it]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From giovannibajo at libero dot it  2003-10-19 17:38 -------
In case it helps, the reduced testcase is:

-------------------------------------
extern const int tab[];

int foo (int x)
{
  int i, ret;

  for (i = 0; i < 1; i++)
    ret = tab[x];

  return ret;
}
-------------------------------------

Danny, did you post the patch to gcc-patches@ already?

[Bug optimization/12209] [3.4 Regression] GCC fails to bootstrap Cygwin with -funit-at-a-time

[kcook at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


kcook at gcc dot gnu dot org changed:

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


------- Additional Comments From kcook at gcc dot gnu dot org  2003-10-27 19:26 -------
This issue was fixed with the checkin of following patch:

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2003-10-25 19:42:40

Modified files:
	gcc            : ChangeLog 
	gcc/config/i386: i386.c 

Log message:
	* config/i386/i386.c (ix86_eax_live_at_start_p): New.
	(ix86_expand_prologue): Save and restore eax around stack probe
	if it's live.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.1550&r2=2.1551
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.611&r2=1.612