[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

["daniel.santos at pobox dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759

--- Comment #18 from Daniel Santos <daniel.santos at pobox dot com> ---
I intended to respond to your comments from 6 days ago sooner, but better late
than never!  Again, sorry for the delay

(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14)
> You need to make certain to have the necessary 32-bit libraries and
> headers.  Apart from that, configure --target=i686-pc-linux-gnu
> --enable-targets=all should be enough, together with CC='gcc -m32'
> CXX='g++ -m32'.  I don't pass --enable-multilib, this happens by default.

I think I'll need to figure this part out soon, as I posted earlier about
strange problems when calling exec.  As it turns out, there are a lot of
variables in the generated script that aren't being populated,
ORIGINAL_AS_FOR_TARGET being one of them.  The "exec: --: invalid option"
problem is occurs because ORIGINAL_AS_FOR_TARGET expands to an empty string and
the first thing after "exec" is the argument "--32" that is intended for the AS
program.

If it turns out that this is because I AM missing some 32-bit library, then we
still have a bug somewhere as some configure script should fail (but it's
failing to fail :).  I build my x86_64 Gentoo systems with ABI_X86="64 32", so
I should have all 32 bit libraries for pretty much everything.

> >> However, I still don't understand why you are jumping through all these
> >> hoops in ms-sysv.exp doing the compilations etc. manually rather than
> >> just relying on dg-runtest or similar.  This would avoid all this
> >> multilib trouble nicely, and massivly reduce ms-sysv.exp.
> >
> > Well quite frankly because dg-runtest, et. al. don't offer support for tests
> > that use code generators.  The generated headers using the default options are
> 
> Why would they need to?  You just generate the headers in advance and
> than invoke dg-runtest to compile and run the ms-sysv.c test proper.

The side-effect of this is that we build the code generator in every -j<job>
and run it prior to every call to dg-runtest on each job.  The building takes a
few seconds and generating the header is almost instant, but it's still a lot
of I/O.  Some of this will likely get mitigated by the I/O scheduler, when a
previously written header hasn't been committed to disk yet and a second write
removes the previous one from the I/O queue, but it's still a lot of waste
IHMO.  And as I mentioned before, if you build with -j48, you'll still end up
wasting a lot of disk space, I think around half a gig of space.

The second problem is that using dg-runtest assigns tests to jobs in bunches of
10.  At current, there are 4 tests and they would all be assigned to a single
CPU, even though each CPU would have to build and run the code generator.

Now I have been digging deeper into gcc-defs.exp, and I may have a clean
solution to this problem and possibly a way to make the entire test harness
perform better job distribution, but I think I should fix the real problems
here first and do this other work as subsequent patches.  If my guess is
correct, with a few changes to gcc-defs.exp, I can use dg-runtest (a la your
patch) AND eliminate all of the parallelization code I've written, while still
eliminating all unnecessary builds and execution of the code generator and
distributing the tests evenly across CPUs.


> > between 4.4 and 6 MiB in size and there are more things that need to be tested
> > (-fsplit-stack to name one) that isn't tested now.  I would also like to add a
> > feature where defining an environment variable generates more comprehensive
> > tests that I wouldn't want to run for every test (as it could take hours with
> > --enable-checking=all,rtl).
> 
> I'd strongly suggest only invoking the basic tests during a regular
> testsuite run and control additional test modes with an environment
> variable as you suggest.

Yes, I agree.  Also, I meant "--enable-checking=yes,rtl" above, not "all"
(yikes!).  I've been building with --enable-checking=yes,rtl because I choose
an ambitious goal for my fist gcc project and I am very paranoid about breaking
something.  I want to do everything I can to detect any flaws in my code.  I am
adding more tests that triggered by GCC_TEST_RUN_EXPENSIVE for now.


> > The most behaviorally similar test currently in the tree is
> > gcc/testsuite/gcc.dg/compat/struct-layout-1.exp, which builds a generator
> > (using remote_exec), runs the generator (remote_exec again) to generate sources
> > for all tests and then builds and runs each test using (using compat-execute). 
> 
> Right, but the test executions proper are done with
> ${tool}_target_compile, which also underly dg-test/dg-runtest.

True, but this test will only use 4-5 CPUs, no matter how many -j<jobs> you
throw at it.  I hope to fix this problem with a later patch (as mentioned
above).


 > I can't help but get the the feeling that your doing very much premature
> optimization here.

lol! Well, I admit that's one of my hang-ups.... 


> If I run the test sequentially on an Opteron 8435,
> it takes less than 3 hours.  Investing very much work and complexity to
> parallelize this (starting with invoking the generator only once instead
> of once per parallel execution, which saves ca. 9 seconds each) doesn't
> seem a good tradeoff to me.

I can't argue that point!  But if I can tune the whole test harness, it might
be worthwhile, especially if I can reduce complexity in my own test.


> I'd forget about the parallelism for the moment (unless I'm missing
> something) and get the basics working sequentially.  The attached patch
> (on top of your last one) switches the whole thing to dg-runtest.  This
> works sequentially, apart from the complilation failure on Solaris I
> reported last. I haven't tried what happens if you try it in parallel,
> but if it causes problems, parallelism can easily be disabled with
> gcc_parallel_test_enable 0/1.

I just discovered that!  And parallelism could then be manually accessed via
gcc_parallel_test_run_p.


> Write privilege in Bugzilla is usually tied to write-after-approval
> rights in svn.  I see you don't have the latter yet.  Sorry for barking
> up the wrong tree.
> 
> 	Rainer

Darn! I thought I might get some more privs out of this. :)

Thank you for all of your assistance, feedback and recommendations!

Daniel