Effects of newly introduced -mpcX 80387 precision flag
Hello! Here are some effects of newly introduced -mpcX flag on a povray-3.6.1 (as kind of representative FP-heavy application to measure FP performance). The code was compiled using: -O3 -march=native -funroll-all-loops -ffast-math -D__NO_MATH_INLINES -malign-double -minline-all-stringops (32bit code) and final binary was linked using -mpc32, -mpc64 or -mpc80. The testfile was abyss.pov in default resolution (320 x 240) and the timings were performed on 'Intel(R) Xeon(TM) CPU 3.60GHz'. Following are averages of 5 runs: -mpc80: average runtime 13.273s (baseline) -mpc64: average runtime 12.977s (2.2 % faster than baseline) -mpc32: average runtime 12.160s (9.2 % faster than baseline) It should be noted, that rendered picture in -mpc32 case developed a strange halo around rendered object (nice special effect ;), and this is clearly the effect of too low FP precision. -mpc64 and -mpc80 rendered pictures were equal, as far as my vision in concerned (well, not quite a scientific approach). It should be noted, that ifort defaults to -pc64 and this brings some 2% better runtimes on FP intensive code. Uros.
Re: Questions/Comments regarding my SoC application
Dennis Weyland wrote: > Hi! > > I've applied for Google's Summer of Code 2007 with GCC as mentor > organization. I want to make GCC working faster on the algorithmic > level. I left out the detailed aims of the project, since i want to > discuss them with gcc developers/mentors first. Do you have any > suggestions what I should do? Are there any slow algorithms that should > be replaced with high priority? Or shall i pick out the goals myself. > But then I cannot estimate the expected time for finishing that project, > I think you have a better overview in this case... We have a collection of testcases with high number of basic blocks or with huge basic blocks; see for example PR28071. These are good candidates for your work. I would pay attention not only to making GCC faster, but also to making it use less memory. I'm not sure you can achieve asymptotic improvements in this case, though. Good luck! Paolo
Re: Effects of newly introduced -mpcX 80387 precision flag
On 4/3/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: Hello! Here are some effects of newly introduced -mpcX flag on a povray-3.6.1 (as kind of representative FP-heavy application to measure FP performance). The code was compiled using: -O3 -march=native -funroll-all-loops -ffast-math -D__NO_MATH_INLINES -malign-double -minline-all-stringops (32bit code) and final binary was linked using -mpc32, -mpc64 or -mpc80. The testfile was abyss.pov in default resolution (320 x 240) and the timings were performed on 'Intel(R) Xeon(TM) CPU 3.60GHz'. Following are averages of 5 runs: -mpc80: average runtime 13.273s (baseline) -mpc64: average runtime 12.977s (2.2 % faster than baseline) -mpc32: average runtime 12.160s (9.2 % faster than baseline) It should be noted, that rendered picture in -mpc32 case developed a strange halo around rendered object (nice special effect ;), and this is clearly the effect of too low FP precision. -mpc64 and -mpc80 rendered pictures were equal, as far as my vision in concerned (well, not quite a scientific approach). It should be noted, that ifort defaults to -pc64 and this brings some 2% better runtimes on FP intensive code. Is ifort able to provide extended precision arithmetic in that case? I think the documentation should mention that 'long double' will no longer work as expected if you pass -mpc64, likewise for 'double' and -mpc32. Richard.
Re: Effects of newly introduced -mpcX 80387 precision flag
On 4/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > It should be noted, that rendered picture in -mpc32 case developed a > strange halo around rendered object (nice special effect ;), and this > is clearly the effect of too low FP precision. -mpc64 and -mpc80 > rendered pictures were equal, as far as my vision in concerned (well, > not quite a scientific approach). > > It should be noted, that ifort defaults to -pc64 and this brings some > 2% better runtimes on FP intensive code. Is ifort able to provide extended precision arithmetic in that case? I think the documentation should mention that 'long double' will no longer work as expected if you pass -mpc64, likewise for 'double' and -mpc32. I have added: ... Note that a change of default precision control may affect the results returned by some of the mathematical functions. to the documentation to warn users about this fact. Uros.
RE: RFC: Enable __declspec for Linux/x86
On 03 April 2007 01:37, Andrew Pinski wrote: > On 4/2/07, H. J. Lu <[EMAIL PROTECTED]> wrote: >> I believe __declspec in Intel C++ compiler comes from: >> >> http://msdn2.microsoft.com/en-us/library/dabb5z75.aspx > > How is Microsoft documentation, the real documentation for Intel C++ > compiler? Presumably this implies that the Intel compiler's 'declspec' compiler extension is defined to match Microsoft's original specification of the feature. > Have you seen the Cell language extension document [1]? We > document everything that is needed to be supported where does > Intel/AMD document those? I have not seen a document like that for > SSE/3DNow programming at all. 1. declspec is only tangentially related to SSE in any case. 2. What is of interest here is not what Intel or AMD have failed to do for their users, but what we should do for ours. 3. It's really no more than a new bit of syntactic sugar for specifying __attribute__s. We probably wouldn't want to support all the declspec types on all platforms, but I don't see why this should be too controversial. cheers, DaveK -- Can't think of a witty .sigline today
DWARF Formats - GCC 4.1.1
Hi all, Can any one suggest a right place to find the differences between the DWARF formats in gcc compiler versions 3.4.6 and 4.1.1? Regards, Rohit
RE: Information regarding -fPIC support for Interix gcc
Hi Ian Thanks for replying. For Movl [EMAIL PROTECTED](%ebx,%eax),%eax > mov 0xbd14(%eax,%ebx,1),%eax I verified that data contained in .rdata section is all wrong in my case with both my gcc3.3 compiler as well gcc4.3 compiler. This is why the jump happens to the wrong code which lies outside the function. Can you point me to the relevant section of gcc code which populates the .rdata section or calculates these values to be populated in there ? Thanks in advance . Mayank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Lance Taylor Sent: Tuesday, April 03, 2007 12:28 AM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc Mayank Kumar <[EMAIL PROTECTED]> writes: > 1: I am keen on understanding how does the offset of L32 from > _GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is > > Movl [EMAIL PROTECTED](%ebx,%eax),%eax then how does is gets converted to mov > 0xbd14(%eax,%ebx,1),%eax. I guessed that L32 is at start of .rodata > section which is the only section of its type. So in my opinion it should > have been > Address of .got section - address of .rodata section. But I am not getting > the generated offset seen in objdump as the same as I calculate from the > above method on a FreeBSD box. Can anyone help here ? On interix, the offset > is being calculated as .got - .rodata only, so is there anything wrong in > this? I am assuming that this is the only thing that could be going wrong. The calculation for the R_386_GOTOFF relocation is specified in the i386 ELF ABI Processor Supplement. It should be the value of the symbol L32 minus the start of the GOT. The start of the GOT is defined by the value of _GLOBAL_OFFSET_TABLE_, and need not be the start of the .got section. The idea is that R_386_GOTOFF gives a position independent offset. It is then added to the address of the global offset table to get the actual offset. > 3: Also, after further investigation, I found that Interix compiled shared > libraries with fPIC flag only cause a crash when there is a jump table being > created for a switch case. I compiled the same shared library which was > crashing with ---fPIC and -fno-jump-table on 4.3 and it worked great. So are > there any jump table experts out there who could help me investigate what is > going wrong in there? I have attached objdump -D output and gcc -S output for > the shared library(repro code which is basically a small dummy library). > --Ass contains objdump -D output > --lib1.s contains gcc -S output > Look at the jump table generated for switch case inside func1_1? This causes > the crash because the control jumps to invalid location thru jmp*%eax. Presumably the values in the table are wrong or the values computed by the relocations are wrong. Step through the code instruction by instruction to see what is happening. There are no secrets here. You have all the information required to figure this out. If you have specific questions we may be able to ansewr them, but it's difficult to answer general questions like why something doesn't work. Ian
Re: Information regarding -fPIC support for Interix gcc
Mayank Kumar <[EMAIL PROTECTED]> writes: > For Movl [EMAIL PROTECTED](%ebx,%eax),%eax > mov > 0xbd14(%eax,%ebx,1),%eax > > I verified that data contained in .rdata section is all wrong in my case with > both my gcc3.3 compiler as well gcc4.3 compiler. > This is why the jump happens to the wrong code which lies outside the > function. > > Can you point me to the relevant section of gcc code which populates the > .rdata section or calculates these values to be populated in there ? gcc emits the code you see in the .s file. In this case it is just code like ".long [EMAIL PROTECTED]", which certainly looks right to me. It is the assembler which determines the value to place in the .o file; for the GNU binutils, this happens in gas/config/tc-i386.h; look for the handling of got_reloc. It is the linker which computes the final value in the executable; for the GNU binutils search for GOTOFF in bfd/elf32-i386.c. Ian
Re: libcc_s.so and libc.so curcular dependency on FreeBSD
Alexander Kabaev <[EMAIL PROTECTED]> writes: > I also noticed that on Linux glibc implements some of the libgcc > symbols, namely _Unwind_Find_FDE and __register_frame_info_bases family > of functions. I wonder why it is done and if I missed something obvious > here. It seems to have to do with some old compatibility issues. There are some e-mail threads here: http://sourceware.org/ml/libc-alpha/2001-09/msg00187.html http://sourceware.org/ml/libc-alpha/2001-10/msg2.html > I wonder if GCC team will be willing to accept gcc part of my changes > into mainstream sources if I submit a patch. What are chances of > something like this to be committed into not only trunk, but also GCC > 4.1, 4.2 and 4.3 branches? FreeBSD 7.0 wants to ship with GCC 4.1, but > newer version is likely to be imported into trunk shortly after CVS is > branched for 7.0 release. Yes. In general gcc will accept target specific changes that do not affect any other targets for release branches. (You do have to have a copyright assignment--I didn't check whether you already have one.) Ian
Re: libcc_s.so and libc.so curcular dependency on FreeBSD
On Apr 2, 2007, at 7:54 PM, Alexander Kabaev wrote: I am working on integrating GCC 4.1.x series into FreeBSD src/ tree. I went ahead and implemented necessary code in FreeBSD's ld-elf.so. 1 and with little changes in gcc crtstuff.c and unwind-dw2-fde- glibc.c I was able to get things working. I wonder if you could confirm that this is a good resolution for the circular dependency issue or is there a better way. I think it's a reasonable way to do it, we do something similar on darwin. I wonder if GCC team will be willing to accept gcc part of my changes into mainstream sources if I submit a patch. To do this, we'd want you to get 4.3 working, submit a patch for that. Then backport it to 4.2, submit that patch, then backport that to 4.1 and submit that patch. Hope you have your paper work done. What are chances of something like this to be committed into not only trunk, but also GCC 4.1, 4.2 and 4.3 branches? Reasonable. FreeBSD 7.0 wants to ship with GCC 4.1, but newer version is likely to be imported into trunk shortly after CVS is branched for 7.0 release. I'd recommend 4.2 at this point.
Re: libcc_s.so and libc.so curcular dependency on FreeBSD
On Mon, Apr 02, 2007 at 10:54:12PM -0400, Alexander Kabaev wrote: > This creates a dependency cycle that I need to break. The simplest way > to go appears to follow Linux's lead and eliminate the need for shared > modules to have explicit frame into registration calls at startup and > allow exception handling code to locate necessary info with the help of > dynamic loader using dl_iterate_phdr call. Yes, this is absolutely the best option, for a number of reasons. I wish more of the free operating systems would use this method. > I also noticed that on Linux glibc implements some of the libgcc > symbols, namely _Unwind_Find_FDE and __register_frame_info_bases family > of functions. I wonder why it is done and if I missed something obvious > here. Someone incorporated these functions into Linux libc.so quite a long time ago, trying to solve the same problem that eventually led us to create the shared libgcc. Unfortunately, this leads to a binary compatibility problem when trying to remove them, so now they're mostly stubs that defer to the libgcc implementation. r~
Re: Effects of newly introduced -mpcX 80387 precision flag
On Tue, Apr 03, 2007 at 10:56:42AM +0200, Uros Bizjak wrote: > ... Note that a change of default precision control may > affect the results returned by some of the mathematical functions. > > to the documentation to warn users about this fact. Eh. It can seriously break some libm implementations that require longer precision. It's one of the reasons I'm not really in favour of global switches like this. r~
Re: Gcc and gfortran installation on MacBook Pro
On Apr 2, 2007, at 2:56 AM, Aurélien Benoit-Lévy wrote: Here is the err_make file. A file attachment for a 1 line text file... Ouch. Cut-n-paste is your friend. Anyway, looks like a rev mismatch between as and gcc, Yup, I'd expect a 4.2 snapshot to solve this problem.
Re: RFC: Enable __declspec for Linux/x86
Joe Buck write: >If the Windows version of GCC has to recognize __declspec to function >as a hosted compiler on Windows, then the work already needs to be done >to implement it. Well, I'm kinda surprised that Windows verision of GCC recognizes __declspec. The implementation is just a simple macro, and could've just as easily been implemented in a runtime header, as the MinGW runtime does. > So what's the harm in allowing it on other platforms? Probably none, but since the macro can be defined on the command line with "-D__declspec(x)=__attribute__((x))" defining it by default on other platforms is only a minor convenience. >If it makes it easier for Windows programmers to move to free compilers >and OSes, isn't that something that should be supported? I suppose that would argue for unconditionally defining the macro regardless of the platform. Ross Ridge
Bootstrap is broken on i[345]86-linux
Bootstrap has been broken since 2007-03-25 on i[345]86-linux. This is a decimal float issue reported as PR31344, and is due to a decimal float patch, probably the following: 2007-03-23 Michael Meissner <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> I've asked a few times already, but nothing seems to be done: can this be fixed? A simple workaround is to disable decimal float for i [345]86-linux, and it would be nice if people who commit patches acted as if they felt responsible for the consequences of their commits. FX
Re: Bootstrap is broken on i[345]86-linux
On 4/4/07, FX Coudert wrote: Bootstrap has been broken since 2007-03-25 on i[345]86-linux. This is a decimal float issue reported as PR31344, and is due to a decimal float patch, probably the following: 2007-03-23 Michael Meissner H.J. Lu I've asked a few times already, but nothing seems to be done: can this be fixed? A simple workaround is to disable decimal float for i [345]86-linux, and it would be nice if people who commit patches acted as if they felt responsible for the consequences of their commits. This would be a good case for the 48 hour rule. Who can start the clock? ;) Gr. Steven
Re: Possible bug in preprocessor
@NullHeart Yes, but this is just a small code snippet reproducing the problem, I don't think that will work when pasting with a macro's argument is required.. @James What do you mean by 16.3.3/3? GCC's version ? Still don't see what the problem whith 2 tokens is... Shame that there doesn't seem to be a consistent preprocessor spec. -- View this message in context: http://www.nabble.com/Possible-bug-in-preprocessor-tf3494353.html#a9827482 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Bootstrap is broken on i[345]86-linux
On Wed, Apr 04, 2007 at 12:17:59AM +0200, Steven Bosscher wrote: > On 4/4/07, FX Coudert wrote: > >Bootstrap has been broken since 2007-03-25 on i[345]86-linux. This is > >a decimal float issue reported as PR31344, and is due to a decimal > >float patch, probably the following: > > > >2007-03-23 Michael Meissner > >H.J. Lu > > > >I've asked a few times already, but nothing seems to be done: can > >this be fixed? A simple workaround is to disable decimal float for i > >[345]86-linux, and it would be nice if people who commit patches > >acted as if they felt responsible for the consequences of their commits. > > This would be a good case for the 48 hour rule. Who can start the clock? ;) A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01764.html H.J.
Test report for gcc 4.1.2 on Cygwin 1.5.24-2
The compiler for 3 languages was bootstrapped and tested using the following configure command: ../gcc-4.1.2/configure --prefix=/usr/local/gcc-4.1.2 --program-suffix=-4.1.2 --enable-threads=win32 --with-cpu=i686 --with-arch=i686 --with-tune=i686 --with-gmp=/usr/local/gmp-4.2.1 --with-mpfr=/usr/local/mpfr-2.2.1 --disable-libssp --enable-languages=c,c++,fortran MPFR and GMP libraries were configured, build and installed before that. LIBSSP couldn't be built due to errors in its Makefile and had to be excluded. Test results (sum files excluding the detailed listing of each individual passed, failed or excluded test): Test Run By Tony on Tue Apr 3 04:29:03 2007 Native configuration is i686-pc-cygwin === gcc tests === Schedule of variations: unix Running target unix Running /usr/src/gcc-4.1.2/gcc/testsuite/gcc.c-torture/compile/compile.exp ... Running /usr/src/gcc-4.1.2/gcc/testsuite/gcc.test-framework/test-framework.exp ... === gcc Summary === # of expected passes 40576 # of unexpected failures 14 # of unexpected successes 2 # of expected failures 98 # of untested testcases 35 # of unsupported tests 301 /usr/src/buildgcc/gcc/xgcc version 4.1.2 Test Run By Tony on Tue Apr 3 11:11:14 2007 Native configuration is i686-pc-cygwin === g++ tests === Schedule of variations: unix Running target unix Running /usr/src/gcc-4.1.2/gcc/testsuite/g++.dg/bprob/bprob.exp ... === g++ Summary === # of expected passes 12605 # of unexpected failures 20 # of unexpected successes 2 # of expected failures 67 # of unsupported tests 127 /usr/src/buildgcc/gcc/testsuite/g++/../../g++ version 4.1.2 Test Run By Tony on Tue Apr 3 13:32:01 2007 Native configuration is i686-pc-cygwin === gfortran tests === Schedule of variations: unix Running target unix Running /usr/src/gcc-4.1.2/gcc/testsuite/gfortran.dg/dg.exp ... === gfortran Summary === # of expected passes 13518 # of expected failures 5 # of unsupported tests 72 /usr/src/buildgcc/gcc/testsuite/gfortran/../../gfortran version 4.1.2 Test Run By Tony on Wed Mar 21 06:36:39 2007 Native configuration is i686-pc-cygwin === libstdc++ tests === Schedule of variations: unix Running target unix Running /usr/src/gcc-4.1.2/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /usr/src/gcc-4.1.2/libstdc++-v3/testsuite/libstdc++-dg/normal.exp ... === libstdc++ Summary === # of expected passes 5710 # of unexpected failures 46 # of expected failures 25 # of unsupported tests 445 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
ANNOUNCEMENT: Workshop on GCC Internals
- AnnouncementWorkshop on GCC Internals - Organized byCFDVS & Dept. of CSE, IIT Bombay - Focus of the workshop Retargetability issues in GCC - Dates 18,19,20 June 2007 - Participation By selection. Please pre-register. - Pre-registration9 April to 1 May 2007 - Notification of selected15 May 2007 participants - Final registration 22 May 2007 - Website http://www.cse.iitb.ac.in/~uday/gcc-workshop Uday Khedker. -- Dr. Uday Khedker Associate Professor Department of Computer Science & Engg. IIT Bombay, Powai, Mumbai 400 076, India. email : [EMAIL PROTECTED] homepage: http://www.cse.iitb.ac.in/~uday phone : Office - 91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. - 91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct) --
