Re: btwowc(EOF) hang with gcc 4.4.2

[Alan Curry]

Jim Meyering writes:
> 
> 
> The code in question is calling btowc(EOF), which uses
> this definition from wchar.h:
> 
> extern wint_t __btowc_alias (int __c) __asm ("btowc");
> extern __inline wint_t
> __NTH (btowc (int __c))
> { return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f'
>           ? (wint_t) __c : __btowc_alias (__c)); }
> 
> Since I don't even see any code that might loop there,
> (though I didn't look up what __asm ("btowc") does)
> I'd suspect a compiler problem.

That asm seems to be one of these:
  http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Asm-Labels.html

It's saying that the function __btowc_alias is actually to be named "btowc"
in the generated assembly code. This enables the inline function named btowc
to call an external function also named btowc, by going through that "alias".
Tricky of them!

> 
> > Running gdb on conftest gets a backtrace like this:
> > #0  0x080491d1 in btowc (__c=-1) at /usr/include/wchar.h:331
> > #1  0x08049431 in btowc () at /usr/include/wchar.h:332
> > #2  main () at conftest.c:276
> >
> > Where that line 331 is:
> > 331 { return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f'
> >
> > This does not happen with other versions of gcc.  I can't tell if it's a
> > gcc bug or a system include file bug or something actually in coreutils,
> > but here's the report anyway.  It was pretty unsettling to have
> > configure hang.

To decide whether a compiler bug is the answer, make a copy of the conftest.c
during the hang, run gcc -c -save-temps on it, and publish the resulting .i
and .s files for inspection. The conftest programs are already pretty minimal
so it should be easy to determine whether the assembly code correctly
corresponds to the preprocessed C code.