[Bug c/48649] New: cannot find space to spill in GENERAL REGISTERS

[Bug c/48649] New: cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

           Summary: cannot find space to spill in GENERAL REGISTERS
           Product: gcc
           Version: 4.3.5
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vasco@icpnet.pl


Created attachment 24018
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24018
error message during compilation

1)Operating system Coherent 4.2.x, 32 bit, coff binary format
2)stage 1 compiler gcc-4.3.5 built with gcc-3.2.3.
3)Compiling any program with optimization turned on (-O2 etc) brings the
message about spilling GENERAL registers in sreal at line 503
4)Compiling and linking of simple programs like "hallo world" works fine , when
any optimization is turned off. The above means , that I could not build
libgcc.a, I am using libgcc.a from gcc-3.2.3
5) I am attaching output of compilation of a test program with optimization
turned off , which produces this "spill" error message.
6) gas 2.14 is used
7) ThinkCentre with Pentium 4 2.8 GHZ is used

The similar behaviour is observed with gcc-4.2.2 and gcc-3.4.3, also built with
gcc-3.2.3.

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #1 from Popielewicz <vasco at icpnet dot pl> 2011-04-17 11:17:51 UTC ---
Created attachment 24019
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24019
test program

This is the test program , which produced the mentioned error message.

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #2 from Popielewicz <vasco at icpnet dot pl> 2011-04-17 11:42:30 UTC ---
Created attachment 24020
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24020
error meesages during compilation with optimization turned on

Error messages produced during compilation of the attached test program when
optimization is turned on. The messages are identical for all types of
optimization : -O2, -Os, -O3, -O4 etc.

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #3 from Popielewicz <vasco at icpnet dot pl> 2011-04-17 12:28:52 UTC ---
Created attachment 24021
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24021
error messages when an extra patch applied

After applying the following patch in sreal.h

#ifndef COHERENT
#define SREAL_MAX_EXP (INT_MAX /4)
#endif

#ifdef COHERENT
#define coh_int_max 0x7f000000
#define SREAL_MAX_EXP (coh_int_max/4)
#endif

the error now occurs in cfgrtl.c 
Notice , that optimization is turned on.Without optimization , as before one
observes "spill" messages.

BTW , the similar patch as above but for gcc-4.2.2 moves the error to reload1.c
at line 19xx, which is similar to some known bug in the past.It was mentioned
there that this bug was fixed in 4.3.4 and above, but probably (?) not quite.

[Bug c/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #4 from Popielewicz <vasco at icpnet dot pl> 2011-04-17 16:17:21 UTC ---
It seems that in this specific case the gcc 4.3.5 has problems with modulo
operation. Even more simpler program using modulo alone produces spill message
.

If in the supplied program one removes modulo, for example replaces it with
addition ,then program compiles and links OK,
but of course aborts at free call.
Of course all the time optimizations are switched off.

BTW I could compile about 50% of functions in libgcc. 

So the compiler is not absolutely useless but rather not usable.

[Bug target/48649] cannot find space to spill in GENERAL REGISTERS

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i386-*-coff
          Component|c                           |target

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-18 10:29:31 UTC ---
The generic i?86-coff targets have been deprecated in GCC 4.4 and were removed
in GCC 4.5.  It is likely this target didn't work properly for a long time.
The issue you are describing sounds like a target configuration issue.

I would say don't hold your breath and instead try using a still supported
target triplet, like for example i?86-cygwin or i?86-mingw.

[Bug target/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

--- Comment #6 from Popielewicz <vasco at icpnet dot pl> 2011-10-18 07:25:24 UTC ---
OK.
Because I suspected, that IRA could help I have decided to port 4.4.6, the last
with coff.
Another motivation was tree-vectorizer.

I have discovered immediately , that purge-dead-edges bug appears. I have found
in one bug description for higher releases the solution for something similar
and it solved the problem for a while . Namely I have copied the function
sel_bb_empty_or_nop_p from release 4.6 , added a line of code(EDGE_COUNT etc) ,
and then commented out one gcc_assert in basic_block.h. The problem seems to be
related with single succesors etc.

As a result the optimizition flag -O2/-O3 etc works, at least for simpler
programs. What is more important even ftree-vectorize(enabled also by -O3)
works(shown by ftree-vectorizer-verbose=n) , but for small programs.
For bigger programs remove-insn at emit-rtl.c bug appears.

usable solution is to compile small functions with tree loops with gcc-4.4.6
and the rest of the programs with stable gcc-3.2.3.

[Bug target/48649] cannot find space to spill in GENERAL REGISTERS

[vasco at icpnet dot pl]

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

Popielewicz <vasco at icpnet dot pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.3.5                       |4.3.6

--- Comment #7 from Popielewicz <vasco at icpnet dot pl> 2012-03-25 15:37:46 UTC ---
(In reply to comment #6)
> OK.
> Because I suspected, that IRA could help I have decided to port 4.4.6, the last
> with coff.
> Another motivation was tree-vectorizer.
> 
>

In the meantime I have fixed gmp lib and values of limits as those met in
limits.h or glimits.h etc.  Now it seems gcc-4.4.6 compiles and links correctly
even big packages. It is too soon to say it is rock stable but it is usable.
The conclusion is coff support in gcc was probably to the end in good shape.
It is a pity it was obsoleted.

I think the case can be closed.

Andrzej

[Bug target/48649] cannot find space to spill in GENERAL REGISTERS

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48649

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
           Keywords|                            |ice-on-valid-code

[Bug target/48649] cannot find space to spill in GENERAL REGISTERS

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48649

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |4.5.0
         Resolution|---                         |WONTFIX

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
i386-*-coff target support was removed in GCC 4.5.0 (r0-92131) so closing as
won't fix.