Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

GCC testsuite

2010-04-08
2013-06-06
  • Doug Semler
    Doug Semler
    2010-04-08

    Out of curiosity:

      Does anyone have the results of a recent testsuite run of make check for gcc (and libs?) native build (especially the 32 bit side)?

    I would like to know whether I'm introducing regressions  or if the fails I'm getting are expected (since the failures don't exist in the -linux testsuite run (currently 20 in g++, and they look like they are typeid failures in the shared libstdc++) and it seems that I'm the one that is most active on that side :)

    Thanks,
    Doug

     
  • NightStrike
    NightStrike
    2010-04-08

    I've only ever run the testsuite on the cross compiler, and I post all results to the gcc-testresults mailing list.  I never found out how to run the native compiler testsuite.

     
  • Doug Semler
    Doug Semler
    2010-04-08

    Well, that helps :)

    (I'm running the cross compiler testsuite under wine32 (meaning i created a special dejagnu file) which worked surprisingly well as far as successful tests - only 20 failures in the g++ portion and most of those were intrinsics.)

    As long as I have a baseline to compare against I'm good :)

     
  • NightStrike
    NightStrike
    2010-04-09

    When I test the cross compiler, I do it using dejagnu's features to do remote execution.  So I use scp to copy the generated binary to teh remote system, then ssh to run it remotely and capture the output.  I would think that this would give more accurate results than running in wine.

     
  • Doug Semler
    Doug Semler
    2010-04-09

    I'm sure it does.  However I'm not always in a position to have a second box to remotely do the testsuite :>  I had a ssh exp set up at one point but seem to have lost it…

    However, do you think you could put your remote test .exp file into the file area somewhere so that it can be used as a reference?  (taking out any passwords obviously)  It'd be nice to be able to have a working .exp to refer to :)

     
  • Doug Semler
    Doug Semler
    2010-04-17

    Yuck

    has 4.6 regressed that much??

     
  • NightStrike
    NightStrike
    2010-04-17

    Yeah, it's pretty darn bad.  I think we really need to focus on testsuite fixes for a bit.  The problem is that there are very few people who can work on them.  I can triage the problems, making lists and running testsuites.  But I surely can't fix them :(

    I would guess a lot of this applies to 4.5 as well.

    Are you able to work on any?  If so, I can give you the full log which shows what went wrong.  Join the IRC channel and I'll show you what I did / where I put stuff.

     
  • Doug Semler
    Doug Semler
    2010-04-17

    So far: things we've found (and potentially have fixes for) in the gcc testsuite:
      1) Many of the excess warnings can be fixed by correcting the linker warnings.  This can be fixed by passing -Wl,-enable-auto-import to the linker via something like
    set_board_info ldflags        "-Wl,-enable-auto-import"
    in a .exp file (wherever that may be - in a baseboard config, etc).  However, Kai mentioned, and I concur, that the warning is pretty much inappropriate in the the latest linker's fixup code, so a better fix would be to default the warning to be turned off in ld.

    2) Many of the errors are intrinsic header conflicts.  Kai checked in r2243 which should fix this

    3) The avx failures are due to avx instructions being generated in main.  The problem is that xmm6,7,and 8 need to be saved and restored in this abi..and the compiler, when inlining the test functions, inlines them into main.  gcc then properly sees that the regsisters are clobbered, and will then try to save and restore them..  The issue is that the registers are saved prior to the cpuid check to ensure the instructions are available, and are restored even if the cpuid check fails.  The quick fix seems to be to ensure that the test function isn't inlined into main (by attributing the declaration perhaps).  The only other way to solve this would be to somehow prevent gcc from generating avx specific instructions on the register save/restore.

    More to come :)