Compile performance of Linux kernels in mainline gcc
Daniel Berlin
dberlin@dberlin.org
Sat Oct 30 19:27:00 GMT 2004
On Oct 30, 2004, at 10:11 AM, Andi Kleen wrote:
> On Sat, Oct 30, 2004 at 10:09:29AM -0400, Andrew Pinski wrote:
>>
>> On Oct 30, 2004, at 10:07 AM, Andi Kleen wrote:
>>
>>> On Sat, Oct 30, 2004 at 09:48:53AM -0400, Andrew Pinski wrote:
>>>>
>>>> Yes the problem is that his terminal does not support UTF8 and his
>>>> LC_* are set to UTF8, a non bug.
>>>
>>> Huh? While that's possible why does gcc need UTF-8 to print
>>> standard C
>>> identifiers?
>>
>> It is printing quotes, not the identifier itself.
>
> Quotes? You mean >>"<< ? That is 7 bit ASCII too.
On most planets, yes.
However, in UTF-8 world, we apparently print nice quotes, not >>>"<<<<.
(I'd put them here, but they would obviously display as garbage to you,
as we've determined ;P)
I discovered this running the testsuite once without LANG=C, and seeing
tons of failures because the quotes look different than the strings we
were expecting.
>
>
> -Andi
On Oct 30, 2004, at 10:11 AM, Andi Kleen wrote:
On Sat, Oct 30, 2004 at 10:09:29AM -0400, Andrew Pinski wrote:
On Oct 30, 2004, at 10:07 AM, Andi Kleen wrote:
On Sat, Oct 30, 2004 at 09:48:53AM -0400, Andrew Pinski wrote:
Yes the problem is that his terminal does not support UTF8 and his
LC_* are set to UTF8, a non bug.
Huh? While that's possible why does gcc need UTF-8 to print standard C
identifiers?
It is printing quotes, not the identifier itself.
Quotes? You mean >>"<< ? That is 7 bit ASCII too.
On most planets, yes.
However, in UTF-8 world, we apparently print nice quotes, not >>>"<<<<.
(I'd put them here, but they would obviously display as garbage to you,
as we've determined ;P)
I discovered this running the testsuite once without LANG=C, and seeing
tons of failures because the quotes look different than the strings we
were expecting.
-Andi
More information about the Gcc
mailing list