This is the mail archive of the 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]

Re: Help with integrating my test program into dejagnu

On 12/31/2016 02:53 PM, Mike Stump wrote:
Also, I can't have the two generated .c files in the same translation unit (at least in their current form) because gcc's too smart with optimizations. :)
You can inform the optimizer to stop doing that.  volatile is but one way.  This informs it that it doesn't get to know what is really going on.

void foo(int, float) { }

void (* volatile foo_noinfo) (int, float) = foo;

   foo_noinfo (1, 3.4);

mean call foo, and inform the optimizer it doesn't get to know what is going on.

   foo (1, 3.4);

means call foo, and inform the optimizer that it knows everything.  This is more complete than noinline.

That is interesting. That means that I can cram all of this into a single translation unit, so I can just generate a single header instead (I had originally started this way). Very nice! :)

You might need to conditionalize the test to only run on those systems that can compile and run the code, to do that you might need [istarget "triplet"], where triplet is a system where you know it will work.  I didn't check the code to see how portable it was.
Other than being x86_64-specific and making heavy use of gcc extensions, the C & C++ code is platform portable.
There need be no gcc or g++ on the build system, nor the host system.  The only thing you get is a C++ compiler on the build system.  It is important that the generator program not use anything that isn't in the language standard (no gcc extensions here).  In the under test code, you can use gcc extensions, but, if you do that, the cost is that you can't then test binary compatibility with Microsoft's compiler (if it doesn't support the extensions you use) a la the struct-layout-1 methodology.

Well I'm learning all sorts of new things; I wasn't aware that the testsuite was designed to run with other compilers! Does the Microsoft compiler support building functions using the System V ABI? I had presumed that they would just never do such a thing because it would make it would easier to use FOSS on Windows, which is just anti-monopolistic. Anyway, the test name "msabi" may be misleading; it's goal is to test 64-bit Microsoft ABI functions that call System V functions. So for the test to be meaningful, I would still need to be able to at least declare a function as System V (even if I use an assembler implementation) and for the compiler to properly call it.

I'm also testing gcc's force_align_arg_pointer attribute in this program, and calling such ms_abi functions both normally and with an intentionally mis-aligned stack using inline asm -- that test would probably be useless on msvc. So I guess I will have to investigate to find out if it's even possible to build this test on msvc. I suppose one advantage of having part of the code generated is that some of the tests can be skipped by just passing a parameter to the generator. I made a bitmask for each test variation, so just passing -m 0x7b would prevent generation of forced re-alignment tests.


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