Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
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 :)
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.
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 :)
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.
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 :)
I can, yes. In the meantime, I've uploaded this:
has 4.6 regressed that much??
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.
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 :)