gcc -Wp,-MD no longer working in svn build
Hi Joseph, I hit the following problem when trying to build a ppc64 Linux kernel from svn today: # gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c cc1: error: unrecognized command line option ‘-MD’ Backing this out fixed it: | jsm28 | 2010-08-13 08:52:49 +1000 (Fri, 13 Aug 2010) | 11 lines * gcc.c (cpp_unique_options): Generate -MDX and -MMDX from -MD and -MMD. c-family: * c.opt (MD, MMD): Change to MDX and MMDX. * c-opts.c (c_common_handle_option): Use OPT_MMD and OPT_MMDX. fortran: * lang.opt (MD, MMD): Change to MDX and MMDX. * cpp.c (gfc_cpp_handle_option): Use OPT_MMD and OPT_MMDX. Anton
Re: food for optimizer developers
On Aug 12 2010, Steve Kargl wrote: Your observation re-enforces the notion that doing benchmarks properly is difficult. I forgot about the lapack inquiry routines. One would think that some 20+ year after F90, that Dongarra and colleagues would use the intrinsic numeric inquiry functions. Although the accumulated time is small, DLAMCH() is called 2642428 times during execution. Everything returned by DLAMCH() can be reduced to a compile time constant. Part of that is deliberate - to enable the compiled code to be used from languages like C++ - but I agree that this is a case that SHOULD not cause trouble. Whether it does, under some compilers, I don't know. A project that would be useful (but not very interesting) would be to rewrite the LAPACK reference implementation in proper Fortran 90+. A variant would be to do that, but update the interfaces, too. Both of these would be good benchmarks for compilers - especially the latter - and would encourage good code generation of array operations. This would be a LOT shorter - I did the latter for the Cholesky solver as a course example to show how modern Fortran is a transliteration of the actual algorithm that is published everywhere. Unfortunately, that's scarcely even a start to the whole library :-( I believe that some other people have done a bit more, but not accumulating to most of a conversion, though I might be out of date (it is some time since I looked). I can't think of how to encourage such work, and am not going to do it myself. Regards, Nick Maclaren.
Re: gcc -Wp,-MD no longer working in svn build
On Fri, 13 Aug 2010, Anton Blanchard wrote: > Hi Joseph, > > I hit the following problem when trying to build a ppc64 Linux kernel > from svn today: > > # gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes > -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep > scripts/basic/fixdep.c The options passed to internal binaries such as cc1 are not a documented public interface to GCC, so if you pass such options via -Wp you must expect to need to change your makefiles when the GCC-internal interfaces change. Instead, you should use the various public interfaces documented in cppopts.texi, which *are* stable interfaces. I think what you want here is "-MD -MF scripts/basic/.fixdep.d" with no -Wp. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc -Wp,-MD no longer working in svn build
> > I hit the following problem when trying to build a ppc64 Linux kernel > > from svn today: > > > > # gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes > > -Wstrict-prototypes -O2 -fomit-frame-pointer -o > > scripts/basic/fixdep scripts/basic/fixdep.c > > The options passed to internal binaries such as cc1 are not a documented > public interface to GCC, so if you pass such options via -Wp you must > expect to need to change your makefiles when the GCC-internal interfaces > change. Instead, you should use the various public interfaces documented > in cppopts.texi, which *are* stable interfaces. I think what you want > here is "-MD -MF scripts/basic/.fixdep.d" with no -Wp. Well, I know of several projects that rely on -Wp,-MD or -Wp,-MMD, so this change will certainly affect lots of people I suspect. Can't we be friendlier to these projects and keep backward compatibility? Arno
Re: gcc -Wp,-MD no longer working in svn build
On Fri, 13 Aug 2010, Arnaud Charlet wrote: > > The options passed to internal binaries such as cc1 are not a documented > > public interface to GCC, so if you pass such options via -Wp you must > > expect to need to change your makefiles when the GCC-internal interfaces > > change. Instead, you should use the various public interfaces documented > > in cppopts.texi, which *are* stable interfaces. I think what you want > > here is "-MD -MF scripts/basic/.fixdep.d" with no -Wp. > > Well, I know of several projects that rely on -Wp,-MD or -Wp,-MMD, so this > change will certainly affect lots of people I suspect. > > Can't we be friendlier to these projects and keep backward compatibility? Allowing the same option to behave differently in the driver and in cc1 regarding whether it takes operands seems like error-prone complexity; every piece of code that now or in the future looks at CL_SEPARATE will need also to check whether it is in the driver or in cc1. Why is this code not using -MF? -- Joseph S. Myers jos...@codesourcery.com
Re: gcc -Wp,-MD no longer working in svn build
> Allowing the same option to behave differently in the driver and in cc1 > regarding whether it takes operands seems like error-prone complexity; > every piece of code that now or in the future looks at CL_SEPARATE will > need also to check whether it is in the driver or in cc1. Why is this > code not using -MF? I don't know, was -MF always available, or was -Wp,-MD the only available option at some point? Arno
Re: Performance optimizations for Intel Core 2 and Core i7 processors
On Mon, May 17, 2010 at 10:44:57AM +0400, Maxim Kuvyrkov wrote: > CodeSourcery is working on improving performance for Intel's Core 2 and > Core i7 families of processors. > > CodeSourcery plans to add support for unaligned vector instructions, to > provide fine-tuned scheduling support and to update instruction > selection and instruction cost models for Core i7 and Core 2 families of > processors. > > As usual, CodeSourcery will be contributing its work to GCC. Currently, > our target is the end of GCC 4.6 Stage1. > > If your favorite benchmark significantly under-performs on Core 2 or > Core i7 CPUs, don't hesitate asking us to take a l...@it. > > We appreciate Intel sponsoring this project. Maxim, Do you have any updates on the progress of this project? Since it has been proposed to default intel darwin to -mtune=core2, it would be very helpful to be able to test (benchmark) any proposed changes on x86_64-apple-darwin10 with gcc trunk. Thanks in advance. Jack > > > Thank you, > > -- > Maxim Kuvyrkov > CodeSourcery > ma...@codesourcery.com > (650) 331-3385 x724
Re: food for optimizer developers
Ralf W. Grosse-Kunstleve wrote: Without knowing the compiler options, the results of any benchmark are meaningless. I used gfortran -o dsyev_test_gfortran -O3 -ffast-math dsyev_test.f If you work on a 32bit x86 system, you really should use -march=native and possibly -mfpmath=sse - otherwise you might generate code which also works with very old versions of x86 processors. (On x86-64 -march=native is also useful albeit the effect is not as large; ifort's equivalent option is -xHost. By default, ifort uses SSE and more modern processors on 32bit.) A possibly negligible effect is that ifort ignores parentheses by default - to be standard conform, use ifort's -assume protect_parens. (Or gfortran's -fno-protect-parens, though your gfortran might be too old.) An interesting test could be to use Intel's libimf with gfortran-compiled binaries by setting the LD_PRELOAD=/opt/intel/Compiler/.../lib/.../libimf.so environmental variable (complete the path!) before running the binary of your program. Another check could be to compile with the -mveclibabi=svml and link then Intel's short vactor math library. That way you make sure you compare the compiler itself and not the compiler + libraries. In terms of options, I think -funroll-loops should also be used as it usually improves performance (it is not enabled by any -O... option). GCC 4.5/4.6: You could also try "-flto -fwhole-file". (Best to use 4.6 for LTO/-fwhole-file.) Tobias
building nss-3.12.7 with 4.6.0 20100731
hello,
I seem to be stuck with this error(below) when building nss
../dist/public/dbm pkix_pl_ldaptemplates.c
{standard input}: Assembler messages:
{standard input}:954: Error: junk at end of line, first unrecognized
character is `6'
{standard input}:954: Error: junk at end of line, first unrecognized
character is `"'
make[4]: *** [Linux2.6_x86_64_glibc_PTH_64_OPT.OBJ/pkix_pl_ldaptemplates.o]
Error 1
is this a problem with gcc or is this a problem with nss?
--
Justin P. Mattock
Re: food for optimizer developers
On Sat, Aug 14, 2010 at 12:08:21AM +0200, Tobias Burnus wrote: > > In terms of options, I think -funroll-loops should also be used as it > usually improves performance (it is not enabled by any -O... option). > I wonder if gfortran should check if -O and -O2 is given, and then add -funroll-loops. In my tests, I've rarely seen a performance issue with -O and -O2. I have seen problems in the past with -O3 and -funroll-loops. -- Steve
Re: building nss-3.12.7 with 4.6.0 20100731
Justin Mattock writes:
> I seem to be stuck with this error(below) when building nss
>
> ../dist/public/dbm pkix_pl_ldaptemplates.c
> {standard input}: Assembler messages:
> {standard input}:954: Error: junk at end of line, first unrecognized
> character is `6'
> {standard input}:954: Error: junk at end of line, first unrecognized
> character is `"'
> make[4]: *** [Linux2.6_x86_64_glibc_PTH_64_OPT.OBJ/pkix_pl_ldaptemplates.o]
> Error 1
>
> is this a problem with gcc or is this a problem with nss?
This question is not appropriate for the mailing list g...@gcc.gnu.org.
It would be appropriate for gcc-h...@gcc.gnu.org. Please take any
followups to gcc-help. Thanks.
This error message means that there is some discrepancy between what the
compiler generates and what the assembler accepts. It may be possible
to fix this by simply updating your assembler. Otherwise, you will need
to identify the specific failing command, run it with the --save-temps
option, and look at line 954 of the generated .s file. Send that to
gcc-help if you need more help.
Ian
