Re: gprof call counts wrong in multithreaded program

2010-06-08 Thread Nick Clifton
Hi Kalle, It is an improvement, but I think it would be even better to specifically mention glibc. Ok - I have checked in a patch to change the paragraph to read as follows: By contrast, the number-of-calls and basic-block figures are derived by counting, not sampling. They are completel

[Bug binutils/11681] New: windres doesn't recognize several codepages

2010-06-08 Thread rodrigorivascosta at gmail dot com
In the file winduni.c there is an array named "codepages" that maps the number of the codepage given in the "--codepage" option or the "pragma code_page" to a name to be used with iconv_open(). The issue is that several mappings are wrong: MS-ANSI is an alias of 1252, not 850; MS-CYRL is an al

[Bug binutils/11681] windres doesn't recognize several codepages

2010-06-08 Thread rodrigorivascosta at gmail dot com
--- Additional Comments From rodrigorivascosta at gmail dot com 2010-06-08 21:34 --- Created an attachment (id=4834) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4834&action=view) Patch to fix the codepage mappings This is the quick'n'dirty patch. But since the WINDOWS- ma

[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org
--- Additional Comments From dsd at laptop dot org 2010-06-08 21:49 --- Created an attachment (id=4835) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4835&action=view) testcase.s -- http://sourceware.org/bugzilla/show_bug.cgi?id=6957 --- You are receiving this mail beca

[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org
--- Additional Comments From dsd at laptop dot org 2010-06-08 21:53 --- (In reply to comment #8) > I agree. If it is true, assembler is broken. If you can show me > a small testcase, I will fix it. I can confirm the bug and I'd like to take you up on that offer, but I may have fallen sho

[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread hjl dot tools at gmail dot com
--- Additional Comments From hjl dot tools at gmail dot com 2010-06-08 21:58 --- (In reply to comment #12) > Created an attachment (id=4835) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4835&action=view) > testcase.s > Works for me: [...@gnu-6 tmp]$ as -Qy -mtune=i686 -o foo

[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org
--- Additional Comments From dsd at laptop dot org 2010-06-08 22:04 --- Created an attachment (id=4836) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4836&action=view) testcase2.s Duh. The previous testcase.s was generated using "gcc -g" so its naturally huge. Taking off the -g

[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org
--- Additional Comments From dsd at laptop dot org 2010-06-08 22:07 --- Created an attachment (id=4837) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4837&action=view) testcase3.s One more. By deleting (more or less) random lines from testcase2.s I came up with a 9-line test cas

[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org
--- Additional Comments From dsd at laptop dot org 2010-06-08 22:17 --- Oops, sorry for the test case spam. I did not see your comment. I understand now. "as -mtune=i686" basically works out to be "as -march=i686 -mtune=i686" Hence generating i686-specific instructions is acceptable/ex