This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] i386: Fix GCC running out of registers for bits/string.h
On Monday 13 June 2005 16:52, Maciej W. Rozycki wrote:
> On Fri, 10 Jun 2005, Denis Vlasenko wrote:
> > Hmm. I tried already, works for me.
> > //gcc4 compiles this just fine with:
> > //gcc -O2 -fomit-frame-pointer
> I'm not sure why you chose the non-PIC variation, which works for me as
> is... Anyway, if I substitute your code with the PIC variant, it still
> works -- probably the code involved is too trivial.
My code is a bit different (it explicitly clobbers ebx - see asm outputs),
maybe that avoids triggering GCC misbehavior.
(Also I shaved off one insn using lea, but this ought to be irrelevant)
> This must be a corner
> case in GCC which is not a surprise for me at all; note my changes have
> already fixed the original failure!
> There have been two similar bugs filed against GCC already (#15482 and
> #21291), but I've decided it's different enough to file it separately --
> this is now bug #22045.
Also see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
> > BTW, can I beg for writing asm() statements so that they do not
> > look like Obfuscated C Contest? Why this:
> > ? ? ?"1:\n\t"
> > ? ? ?"lodsb\n\t"
> > ? ? ?"testb ? ? %%al,%%al\n\t"
> > instead of this:
> > "1:\n"
> > ? ? " lodsb\n"
> > " testb %%al,%%al\n"
> Well, I don't think we have rules written somewhere and lacking that I
> actually prefer the former, as well readable
...sans hard to spot 1: label...
> and fitting the output
> appropriately, i.e. no leading tab on the first line and no trailing
> newline on the last; depending on how often you want to read the generated
> assembly it may actually matter for you or not (gas doesn't care). Then
My test program (when compiled with -S) looks okay, no tab damage.
Thus I have both readable C and readable asm.
> some people prefer something like:
> and that I agree starts being unreadable.
This is exactly what I am complaining about.