Re: Large slowdown with gfortran vs f77 (x7)
>>>>> "Jeremy" == Jeremy Sanders writes: Jeremy> You can see the very large speed differences by telling gfortran Jeremy> to always use double precision numbers. Jeremy> This can be replicated with this simple program: Jeremy> Compiled with gfortran -O2: Jeremy> real0m29.921s Jeremy> user0m29.912s Jeremy> sys 0m0.000s Jeremy> Compiled with gfortran -O2 -fdefault-real-8: Jeremy> real0m4.306s Jeremy> user0m4.304s Jeremy> sys 0m0.000s Jeremy> This is with a newly built gcc 4.4.1 on Fedora 10 (glibc 2.9), x86-64. I tried it on my 1Ghz PIII laptop running Gentoo with gcc 4.1.1 and glibc 2.10.1. I added -march=pentium3 to the gcc cmd line; that probably made little difference. (glibc was also compiled with -march=pentium3 -O2). I got nearly identical user times for the two compiles; user time was always within 0.03 of 23.40 over multiple runs. Incidently, while the real-8 compile output 271828665.96115601, the real4 compile output 67108976. This does, then, seem to be an x86-64 issue. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?
Gcc 4.5.1 running on an amd64 box "cross"-compiling for a P3 i8k fails to compile the module since commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 with: CC drivers/char/i8k.o drivers/char/i8k.c: In function ‘i8k_smm’: drivers/char/i8k.c:149:2: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ drivers/char/i8k.c:149:2: error: ‘asm’ operand has impossible constraints -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Wierd manual link and resulting dead link
The What's New in 4.8 document links to the X86 Built-in Functions section of the online manual, but its link is dead. The working link is: http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions Note the >_002d< rather than a >-<. Presumably a side effect of the info->html process, which uses U+2D in place of U+20 when generating the URIs from the info section names. One fix would be to use Builtin rather than Built-in in the secion name. Or update the links in the 4.8 what's new to match the current html. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
gcc-4.8.0: march=amdfam10 vs march=native on a k10
On a box where amdfam10 is the native arch, 4.8 #defines two symbols with march=native which it does not with march=amdfam10: :; gcc-4.8.0 -march=amdfam10 -E -dM - /tmp/amdfam10 :; gcc-4.8.0 -march=native -E -dM - /tmp/native :; diff -U0 /tmp/amdfam10 /tmp/native --- /tmp/amdfam10 2013-04-29 18:07:22.435553711 -0400 +++ /tmp/native 2013-04-29 18:07:14.987605897 -0400 @@ -76,0 +77 @@ +#define __FXSR__ 1 @@ -156,0 +158 @@ +#define __PRFCHW__ 1 Should -march=amdfam10 then also set -mfxsr and -mprfchw? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: The state of glibc libm
>>>>> "VL" == Vincent Lefevre writes: VL> sinf being slower than sin is surprising Some weeks back I wrote a simple app to output a couple of waveforms as float samples (I encased it in a tiny script which piped the output to sox to create a wav). I found that converting it to work on and output doubles improved performance from around 2.2 sec per minute of output to around 0.3 sec per minute for a simple tan(sin(t)) waveform. That is using glibc-2.14.1 on amd64 on a 2800MHz K10, compiled with gcc-4.6.2 with -O2 and the graphite -floop-... options. Some improvements have landed for the float versions of libm since. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: RFC: -Wall by default
>>>>> "GDR" == Gabriel Dos Reis writes: GDR> Exactly. Our bugzilla databases has lot of requests in this spirit. If that is so, then defaulting to -Wall will just generate even more requests to turn that off. I find it hard to image that anyone who does any significant amount of compiling would fail to have their own CFLAGS (et al) with the options which they prefer. Forcing -Wall for those who did not ask for it is <...words.escape...>. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: RFC: -Wall by default
>>>>> "MB" == Miles Bader writes: MB> [Or, perhaps, not "-Wall" perse, but maybe a new option which MB> is a little more conservative, "-Wstandard" or something...] Sure. Making a few more of the -W flags on by default may be OK, depending on the chosen list. It is the idea of turing all possible warning options on by default which is unreasonable. Defaulting to -Wall also fails as a user interface design. -Wall is a nice, short, sweet, easy to type optiong which one readily can add at any time. Forcing one to have to find all of the -Wno-... options to avoid unwanted annoyances, or to the -Wno-all and a set of -Ws which one does want is far more cumbersome. And what if new warning are added. Does anyone really want them *all* on by default as soon as the code lands? If there are some useful warning not already on by default which tend not to false-positive and provide useful, beneficial information when triggered, then it is reasonable to look into starting to default-enable them. Turning *all* of them on willy-nilly is not. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: RFC: -Wall by default
>>>> Maybe -Wstandard isn't the best name though, as "standard" usually... AS> It doesn't have to be short: -Wdefault-warnings. I haven't looked at all of the replies since I posted, and I *had* forgotten about -Wextra (I can't even remember how many years it has been since I last read that section of the manual), but adding a new option to contain the default warnings fits well with my thesis. Something like -Wdefault-warnings is a reasonable choice, for the reasons already mentioned in this sub-thread. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
