Re: fancy x87 ops, SSE and -mfpmath=sse,387 performance
Is there a way to enable such exotic codegen for 32bit environments? With libgcc-math you didn't have exotic instructions, but you had trascendental operations compiled with -mfpmath=sse and with a special ABI. -mfpmath=sse won about 8% over -mfpmath=387 for tramp3d, which does have trascendental operations. Let's see what happens for 4.3. Paolo
Re: How gcov handles untested files, prior and after GCC 3.4
Ok. The reason that I need to know how many lines of source code their is in the untested files is that I want to calculate a avarage for test coverage on "modules" in my source code tree. And untested "module files" contribute to that avarage as well, of course. That I need it to work in a similiar way on different versions of Gcc is that the implementation is done in a general build system, and that I don't really know which Gcc version that is used on the host machine. The main build server is for example 3.2.3 where as most of the workstations use Gcc 4.x.x. The build system though needs to work in both environments. Regards, Fredrik On 8/4/06, Nathan Sidwell <[EMAIL PROTECTED]> wrote: Fredrik Johansson wrote: > Why I ask is because I need to extract the number of lines even in > untested files, and I need it to work both on 3.3.6 and on various > 3.4.x versions. This use case had not occurred to me. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: does gcc support multiple sizes, or not?
However, in s390.c, we have:
static bool
s390_valid_pointer_mode (enum machine_mode mode)
{
return (mode == SImode || (TARGET_64BIT && mode == DImode));
}
Note that more than one mode is supported simultaneously. Thus, it's
legal for the application to specify SI or DI mode for pointer (via
__attribute__((mode))), but cc1plus then aborts.
So... who is right? Are we supposed to support multiple pointer sizes
in the same compilation unit, or not?
Hmm... this worked when I put this in for s390 at one point - for
exactly the reason that you have with the attribute.
-eric
status of IPA in gcc trunk?
Is there a wiki gcc page which accurately describes the current status of IPA in gcc trunk? I have run across a fortran benchmark which exhibits a huge improvement from IPA when compiled on XL Fortran. I would like to attempt to use the current IPA support in gcc trunk with gfortran but it doesn't seem to be well documented. I was under the impression that the gcc IPA would require collection of profiling results which would then be used in a successive compilation to implement the IPA optimizations. However I can't find the process documented clearly anywhere. Thanks in advance for any information. Jack ps Does each front-end have to be modified to use IPA or will they automatically use it once it is added to gcc trunk?
Re: ___divti3 and ___umodti3 missing on Darwin
On 05/08/2006, at 5:19 PM, Jack Howarth wrote: While testing the state of gfortran in gcc trunk at -m64 on MacOS X 10.4 I discovered a huge number of test failures (848 compared to 26 with -m32). Almost all of these failures appear to be due to two undefined symbols in libgfortran's shared library in the ppc64 version... http://gcc.gnu.org/ml/fortran/2006-08/msg00112.html The symbols, ___divti3 and ___umodti3, are not present in darwin- libgcc.10.4.ver or darwin-libgcc.10.5.ver found in gcc/config/rs6000 but they are present in the libgcc-std.ver in the gcc directory. I haven't found anything in bugzilla about this issue, however it really should be addressed before gcc 4.2 is released. I believe this is a problem in libgcc.a and/or optabs.c, it should support __divti3. Apparently TImode is supposed to be supported by generic code, I see this comment in targhooks.c: By default we guess this means that any C type is supported. If we can't map the mode back to a type that would be available in C, then reject it. Special case, here, is the double-word arithmetic supported by optabs.c. */ Here 'double-word' means 128-bits, TImode, since a word is 64 bits on ppc64. smime.p7s Description: S/MIME cryptographic signature
Re: ___divti3 and ___umodti3 missing on Darwin
Geoff, I've asked David Edelsohn at IBM if he sees the same problem on linuxppc64. Unfortunately, I don't have a spare drive handy to try it on linuxppc64 myself. Jack
Re: ___divti3 and ___umodti3 missing on Darwin
Geoff, I tried the modulo.c and division.c test cases with tonight's gcc svn pull and the problem shows some variability. Sometimes building with 'gcc-4 -m64 division.c' or 'gcc-4 -m64 modulo.c' creates a binary that can resolve the symbol and sometimes not. So the symbol resolution process seems to have some instability. Jack
Re: ___divti3 and ___umodti3 missing on Darwin
> Jack Howarth writes: Jack> I've asked David Edelsohn at IBM if he sees the same problem on Jack> linuxppc64. Unfortunately, I don't have a spare drive handy to Jack> try it on linuxppc64 myself. Everything works fine on ppc64 linux. I believe that Andrew Pinski diagnosed the problem as divti3 and modti3 not being listed in the symbol export file for Darwin when 64-bit support was added. David
Re: ___divti3 and ___umodti3 missing on Darwin
David, My understanding was that only libgcc_s.10.4.dylib and libgcc_s.10.5.dylib required the entries in their .ver files for exporting symbols. The -m64 flag on Darwin causes libgcc_s_ppc64.1.dylib to be used for the linked libgcc. There is a very sparse libgcc-ppc64.ver file in the directory gcc/config/rs6000, but I am unclear if this is used in the creation of libgcc_s_ppc64.1.dylib. I'll try a build tomorrow with the TImode symbols added to libgcc-ppc64.ver and see if it helps. The weird part is that the symbol sometimes is found during the link process (as if the linkage process was unstable). Jack ps Have your tried the testcases at all optimizations. On Darwin, I can usually fine one of these will fail... gcc-4 -m64 modulo.c gcc-4 -O1 -m64 modulo.c gcc-4 -O2 -m64 modulo.c gcc-4 -O3 -m64 modulo.c
Re: ___divti3 and ___umodti3 missing on Darwin
David, A few questions. Does linuxppc64 use the libgcc-ppc64.ver in gcc/config/rs6000 or does it use the stock libgcc-std.ver in the gcc directory? I am still unclear which 'owns' libgcc-ppc64.ver since it doesn't have darwin explicitly in its name. Also does nm -D libgcc_s.so | grep __umodti3 show the symbol being present on linuxppc64 like it does on x86_64? Lastly are the *.ver files have any effect on symbol exporting from the static version of libgcc? I ask because it appears that on MacOS X 10.4, the current Xcode 2.3 has the same problem... gcc -m64 modulo.c can't resolve symbols: ___modti3, referenced from: _main in ccNqYmqO.o ld64 failed: symbol(s) not found collect2: ld returned 1 exit status and that compiler uses static libgcc.a for 64-bit (there is no shared lib version). Jack
