This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #9 from Daniel Santos <daniel.santos at pobox dot com> ---
[...]
>> sure, though there's no need at all (except for the .struct part) to do
>> the testing on Solaris.  I believe there are ready-made Solaris/x86
>> VirtualBox images, though.
>
> I've found a few, so going to try them out when I get some time.  Oracle even
> has something on their downloads.  I haven't used Solaris since the early
> aughts.

As I said, you can try that if you're really motivated, but the problems
at hand are mostly not Solaris-related at all.

>> For the multilib problem, you can easily
>> configure gcc for i686-pc-linux-gnu with --enable-targets=all on a
>> Linux/x86_64 box (with a few necessary 32-bit development packages
>> added), so the default multilib is non-x86_64, while the x86_64 multilib
>> is only used with -m64.
>
> Hmm, I seem to be having problems getting this to work.  Would I configure with
> --target=i686-pc-linux-gnu --enable-targets=all --enable-multilib?

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.

>> 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.

> 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.

> 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.

> Calls to remote_exec are not automatically parallelized.  I don't fully
> understand how the gcc/testsuite/lib/compat.exp library works, but I'm guessing
> that calls to compat-execute are parallelized by dejagnu.
>
> The scheme that struct-layout-1 uses builds the generator and creates sources
> for all of the tests in job directory (i.e.,
> gcc/testsuite/gcc{,1,2,3,4,5,6,etc.}/gcc.dg-struct-layout-1).  They take up
> 1.21 MiB per job, so -j48 results in 58 MiB of space usage.  My generator and
> generated sources are larger, and currently take about 11.65 MiB per job, so
> -j48 would eat 559 MiB of disk space, even though there are only 6 tests at the
> moment.  This could be mitigated if there was a way to build and run the
> generator only once and have the output go to a directory shared across jobs,
> but I'm not yet aware of any such existing mechanism.

I can't help but get the the feeling that your doing very much premature
optimization here.  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.

> So if you have some better ideas on how to accomplish this then please do
> present them.  Or maybe I'm misunderstanding something about the way
> dg-runtest, gcc_target_compile, etc. work in relation to parallelism?  My
> understanding is that if I use them in succession for a single test run (i.e.,
> build the generator, run the generator, build & run the test) that they could
> end up being run on different jobs and then fail.

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 very much appreciate hints and guidance about proper PR management, coding
> standards, etiquette, procedures, norms, etc.! I'm still pretty new to this
> project but I find it really enjoyable.  However, I don't seem to have the
> privileges to change those fields.  Do I need to seek advanced privileges from
> somebody?

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]