[Bug inline-asm/22045] New: can't find a register in class 'GENERAL_REGS'

[Bug inline-asm/22045] New: can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

This seems a bit different to the two other bugs in this class, so I'm filing
it separately.  For the attached code (extracted from glibc, with some
modifications), built with:

$ i386-linux-gcc md5-crypt.i -c -O2 -pipe -fPIC -fomit-frame-pointer -o md5-crypt.os

(-fomit-frame-pointer given for illustration only) GCC runs out of registers,
even though the problematic asm insists on having four registers available
only.  That means at least one free register is still available (there would
be two if alloca() didn't consume %ebp) -- how many is GCC meant to require?

 What's interesting, replacing the "=&g" constraint for "__d3" with "=m"
(a patch attached for clarity) makes the failure go away, so it looks like
it is really a wrong one.

-- 
           Summary: can't find a register in class 'GENERAL_REGS'
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: inline-asm
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: macro at linux-mips dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-linux-gnu
  GCC host triplet: i386-linux-gnu
GCC target triplet: i386-linux-gnu


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

------- Additional Comments From macro at linux-mips dot org  2005-06-13 13:32 -------
Created an attachment (id=9078)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9078&action=view)
This is the problematic source


-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

------- Additional Comments From macro at linux-mips dot org  2005-06-13 13:33 -------
Created an attachment (id=9079)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9079&action=view)
This makes the error go away


-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-13 13:45 -------
This is not really a bug in GCC.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|i386-linux-gnu              |
   GCC host triplet|i386-linux-gnu              |


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

------- Additional Comments From macro at linux-mips dot org  2005-06-13 14:14 -------
 There is no other software involved.

-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-13 14:17 -------
(In reply to comment #4)
>  There is no other software involved.

What I mean is this is a known non-bug in GCC in that running out registers cause things to wrong with 
people's inline-asm on x86.  If people stop writting inline-asm like this we would not have these bug 
reports.  If you notice that this is not an ICE but a normal error.

-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

------- Additional Comments From macro at linux-mips dot org  2005-06-13 14:44 -------
 I haven't written it's an ICE, have I?

 Unfortunately I can't see a way of rewriting the asm such that an appropriate
variant is used depending on whether there are six or five or four (or fewer?)
registers available.  What is the reasonable upper limit for the number of
registers used by an asm for the i386 -- I can't recall it being documented
anywhere (for such a register-starved platform it might be worth doing)?  It
seems four are still too many, sigh...

 BTW, this is old code that used to work just fine with 2.95 and older despite
actually requesting five registers.  I've rewriten it to please GCC 4.0 and it
has fixed the original place of failure elsewhere in glibc, but it still
breaks for this file.  I've now checked it with 3.3.5 and 3.4.4 -- it works
with the former and breaks with the latter.

 I suppose it's hard for people to get code right when a given version of GCC
happens to work (be it intentionally or accidentally) and a later one stops.

-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

------- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua  2005-06-14 07:06 -------
If I understand this correctly, older GCCs were able to
figure out that when there is 5 registers available,
"=&g" (__d3) can olny be matched with memory (on-stack local var)
whereas with 6 regs it can use a register.

But newer GCC cannot and we need to explicitly say "=m".

Isn't it a regression?

-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-19 13:04 -------


*** This bug has been marked as a duplicate of 21291 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

------- Additional Comments From macro at linux-mips dot org  2005-08-08 17:42 -------
Richard,

 Thanks for your work (for bug 21291).  Unfortunately it's not enough for
this case.  It doesn't seem to work for the "g" constraint used there, but
that might probably be considered just a shortcoming -- "=rm" or "rmi" can
be used instead as appropriate.  But more importantly it doesn't work with an
early clobber and that's something that cannot be avoided -- GCC has to be
told that a register, if used, is to be destroyed early.

 To summarize, the case does not work as is -- with "=&g" and "g".  It does
not work with "=&rm" and "g".  It does work with "=rm" and "g", but it's
dangerous as GCC will probably allocate both the same register.  It does
work with "=m" and "g", but it sort of misses the point.  I removed the
"register" keyword from the affected variables for these tests as it is
problematic for the "=m" case (the keyword should be safe to be removed
from glibc now, as it requires at least GCC 3.2 these days).

 Please let me know if that's clear enough.  Or whether I should reopen the
other (duplicate) bug rather than this one.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
                   |dot org                     |
             Status|REOPENED                    |ASSIGNED


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-08-08 18:09 -------
(In reply to comment #9)
> To summarize, the case does not work as is -- with "=&g" and "g".  It does
> not work with "=&rm" and "g".

Of course not!  Have you forgotten what early-clobber means?

> Please let me know if that's clear enough.  Or whether I should reopen the
> other (duplicate) bug rather than this one.

No, it's not clear at all.  If you've got some other test case that runs out
of registers, then its some other problem and wants its own PR.  You'll need
a new test case.  I caution you that using early-clobber insists on new 
registers, and so runs a larger risk of truely exhausting available registers.

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


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-08-08 18:11 -------
I'm sorry, this is Andrew's fault -- it's not a duplicate.

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


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-08-08 22:10 -------
Amusingly, the problem disappears when one translates this:

  salt_len = (((strcspn (salt, "$"))<(8))?(strcspn (salt, "$")):(8));

to

  salt_len = strcspn (salt, "$");
  if (salt_len > 8)
    salt_len = 8;

Note that the strcspn function isn't cse'd, as someone was clearly expecting.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|0000-00-00 00:00:00         |2005-08-08 22:10:26
               date|                            |


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-08-08 22:31 -------
I'm calling this one invalid.  We've got:

  eax     __d0 early clobber
  ebx     pic
  ecx     __d1 early clobber
  edx     __s input
  esi     __res early clobber
  edi     __d2 early clobber
  ebp     frame pointer forced by alloca

The problem with the "=&g"(__d3) operand is that (1) there are no more 
registers, and (2) there is no memory that doesn't conflict with the
(*(struct { char __x[0xfffffff]; } *)__s) input, and thus there is no
memory that can satisfy the early clobber.

I'm not 100% certain why this was accepted before gcc 4, but I'm not
curious enough to go looking.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

------- Additional Comments From macro at linux-mips dot org  2005-08-09 11:38 -------
 Thanks for your insight.  I did some experimenting with the code (including
reducing the source file to a somewhat more readable form -- I can post it
if interested) and I noticed this *(struct { char __x[0xfffffff]; } *) cast
is somehow involved.  I searched the info pages to find out what exactly it
is expected to mean to GCC, but I failed.  Anyway I sense this effectively
tells all the memory (0xfffffff is close to 1/16 of the target's address
space) is potentially to be referred to, forcing any variables cached in
registers to be written back to their corresponding memory locations.  Am I
right?

 But "__d3" is a temporary and if located on the stack, it's not going to
affect "__s" in a well-defined program.  Is there a way to tell GCC about
that?

 Of course it can be worked around by using "=m" as the constraint for
"__d3", but then the opportunity to use a register when one is actually
available is lost.  I've tried to use alternative constraints with an early
clobber for the register variation only (i.e. "=&r,m"), but GCC still
insisted on using a register.

 BTW, thanks for the hint about calling strcspn() -- I've noticed the
problem disappears when one of these calls is removed, too.  I'll prepare a
patch for glibc as a microoptimization here.  But of course <bits/string.h>
is a user header, so we cannot simply cover the problem by changing
md5-crypt.c and praying it won't reappear elsewhere. ;-)

-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-08-09 17:44 -------
Yes, the funny cast is *intended* to alias all memory, and thus force anything
that might potentially alias the string to be written back.  We don't have the
ability to conclude that __d3 won't be affected.

As for <bits/string.h>, the version in current glibc seems to be very different
and should not exhibit the problem shown here.

-- 


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

[Bug inline-asm/22045] can't find a register in class 'GENERAL_REGS'

[macro at linux-mips dot org]

------- Additional Comments From macro at linux-mips dot org  2005-08-09 18:23 -------
 Please make sure you look at the right variant, i.e.
"sysdeps/i386/bits/string.h", as there are different versions for different
i386 submodels.  Still the version in the glibc tree differs a bit indeed,
but it's even worse, absolutely demanding five registers and as a result
breaking a glibc build much earlier.  What has been included in this report
is my attempt to rectify the problem with glibc.  See the discussion starting
at: "http://sourceware.org/ml/libc-alpha/2005-06/msg00026.html" for a
reference.

 Given your explanation I guess the only way to make this code work is to
force "__d3" into memory, which essentially means the code needs to be
rethought.  Unless we find a better way for providing hints to the compiler.

-- 


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