This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Unexpected compiler twist of the wcscoll issue


On Tue, Mar 12, 2002 at 01:49:16PM +0100, Paolo Carlini wrote:
> Hi,
> 
> as probably many of you already know, we are experiencing some problems making
> use of glibc2.2's wcscoll in implementing v3 collate::compare.
> 
> Very unexpectedly, on my system (i686-pc-linux-gnu, glibc2.2.5) at least, this
> turns out to have to do with the compiler!
> 
> Consider this simple testcase, provided by Peter (Schmid).
> 
> #include <wchar.h>
> #include <locale.h>
> #include <stdio.h>
> 
> int main()
> {
>   int i;
>   setlocale(LC_ALL, "de_DE");
>   i = wcscoll (L"Äuglein", L"Augment");
>   printf("result of the wide string comparison: %i\n", i);
>   i = strcoll ("Äuglein", "Augment");
>   printf("result of the string comparison: %i\n", i);
>   return 0;
> }
> 
> This is what I get:
> 
> 3.0.4, 3.1 pre, 3.2 exp:
> ------------------------
> result of the wide string comparison: 20
> result of the string comparison: -1
> 
> 2.95.3 + patches, 2.96 RH, Intel 5.0.1 :
> ----------------------------------------
> result of the wide string comparison: -1
> result of the string comparison: -1
> 
> Is anyone able to reproduce/explain this, on different architectures perhaps?

Yes, it is a gcc bug, just watch the assembler it generates.
Debugging...

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]