Brad King wrote: > On 1/2/2012 5:24 PM, Rolf Eike Beer wrote: > > It looks like gcc simply optimizes out any reference to the tested > > symbol. Given the fact that we don't really ever use that symbol > > anywhere it is even correct to do so. Just that this is not what we > > want.
> > I pushed a topic test-symbol-exists to stage that verifies that this is
> > indeed a problem in Check{,CXX}SymbolExists, it iterates through all
> > build configurations (were this problem does _not_ happen) and later
> > explicitely adds a -O3 test if it is gcc/g++ which then _does_ fail.
> >
> > So, there are 3 points that I need advise:
> >
> > -what should happen with this topic? Should I merge it to next? Then we
> > will get a ton of failures on at least everything that is using GNU
> > compilers.
> Certainly we should add tests for these modules. They are critical to
> many projects. However, let's not add a test when we know it will break
> immediately. Please also rebase the topic so it does not depend on your
> FindDoxygen topic. Add a commit prior to the test to fix the behavior
> as discussed below.
Sorry, that was not intentional. I dropped the previous branch and created a
new one, based on current master. It has 2 commits: the first one introducing
the (hopefully) fixed CheckSymbolExists.cmake, the second one adding the
tests. It also adds a positive test: it checks if errno can be found in
errno.h for both C and C++. Hope this will not break on some strange machines.
> > -which other compilers can be tested this way, I mean using -O3? From
> > what I know Clang does understand this and even -O4, what is about the
> > Intel one?
> Let's start with the GNU case and add more later. I suspect that if we can
> convince GCC -O3 to keep the symbol (see below) then no other compiler will
> be able to optimize it out.
I would be interested to know which compilers/flags were previously affected
by this problem. But anyway, let's go down this road for now, research can be
done later.
> > -how to fix this thing at the end? I was thinking about just doing
> >
> > #include<stdio.h>
> > printf("%s is at %p\n", ${SYMBOL},&${SYMBOL}));
> >
> > Is anyone aware of some place where this wouldn't work? Or should I just
> > put this in and try out?
>
> We don't want the test to depend on any symbols other than the one tested,
> even runtime library symbols. Some cross-compilers may not provide
> everything by default. We just need to make the return value depend on the
> symbol. I worked this out in "Modules/CMakeCCompilerId.c.in". Note that
> the return value should also depend on a runtime argument (argc) so the
> optimizer cannot make any assumptions.
>
> I think this will work:
>
> int main(int argc, char* argv[])
> {
> (void)argv;
> return ((int*)(&SYMBOL))[argc];
> }
It looks like, at least it survives my -O3 test.
Pushed updated branch. Please review and merge to next if you like it.
Eike
signature.asc
Description: This is a digitally signed message part.
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
