Re: Help with integrating my test program into dejagnu

[Mike Stump <mikestump at comcast dot net>]

On Dec 31, 2016, at 11:18 AM, Daniel Santos <daniel.santos@pobox.com> wrote:
> 
> The generated sources are 2MiB

Yeah, too big, better to have a generator.

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

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