This is an archive of the discontinued LLVM Phabricator instance.

Add powerpc64 to compiler-rt build infrastructure.
ClosedPublic

Authored by saugustine on Aug 7 2017, 2:48 PM.

Details

Reviewers
nemanjai
echristo
Summary

Add powerpc64 to compiler-rt build infrastructure.

Now that we have disabled the run-forever tests, and cleaned up the
intel 80-bit float based tests, we should be able to enable testing
compiler-rt for powerpc64.

Event Timeline

saugustine created this revision.Aug 7 2017, 2:48 PM
nemanjai edited edge metadata.Aug 8 2017, 6:36 AM

This patch appears to be perfectly fine. However, it triggers a large number of warnings. Namely, there's a large number of warning: ISO C forbids an empty translation unit [-Wpedantic] warnings produced.
The reason is that all the code in the file is wrapped with an if !_ARCH_PPC macro. I assume that we do not want compiler_rt to expose builtins that assume an 80-bit long double (which is the behaviour we get now). So it seems to me that files that define such builtins should simply be removed from the powerpc64_SOURCES and they should #error on PPC.

Also, I'm getting lots of warnings from compiler-rt/lib/builtins/atomic.c such as warning: implicit declaration of function '__c11_atomic_fetch_or' [-Wimplicit-function-declaration]. It would appear that the __c11_atomic_* family of builtins isn't exposed by the build compiler (and should presumably be declared in a header if file is being built with a compiler that doesn't expose those).

This patch appears to be perfectly fine. However, it triggers a large number of warnings. Namely, there's a large number of warning: ISO C forbids an empty translation unit [-Wpedantic] warnings produced.

What config are the buildbots using? I don't see these warnings in default or RELEASE style builds. I'm happy to fix them though.

The reason is that all the code in the file is wrapped with an if !_ARCH_PPC macro. I assume that we do not want compiler_rt to expose builtins that assume an 80-bit long double (which is the behaviour we get now). So it seems to me that files that define such builtins should simply be removed from the powerpc64_SOURCES and they should #error on PPC.

I think it is better to mark plain powerpc (32) as unsupported in the testsuite, for similar reasons to marking powerpc64 unsupported. Whoever originally #ifdefed these did it in a way that is misleading. See the comments on D36249 for my reasoning.

Also, I'm getting lots of warnings from compiler-rt/lib/builtins/atomic.c such as warning: implicit declaration of function '__c11_atomic_fetch_or' [-Wimplicit-function-declaration]. It would appear that the __c11_atomic_* family of builtins isn't exposed by the build compiler (and should presumably be declared in a header if file is being built with a compiler that doesn't expose those).

What config do the buildbots use? I don't see these errors with DEBUG or RELEASE. I'm happy to fix them regardless, but I'd like to be able to anticipate these problems.

Some buildbots use the distro gcc (looks like 5.4) and at least one uses gcc 7.1. I use gcc 6.2.
I think that with the addition of https://reviews.llvm.org/D36555, the empty source file warnings should go away. However, I imagine that the warnings about atomics will still be around. It seems that the file is written assuming it will be built with Clang (I'm not sure, I haven't looked at the code - just the warnings).

nemanjai accepted this revision.Sep 18 2017, 5:54 AM
nemanjai added subscribers: hfinkel, echristo.

I hope I haven't lost track of the patches that precluded this. If I remember correctly, all the X86 80-bit stuff was sorted out. We now know why those test cases were running forever (i.e. a vaarg function invoked as a non-vaarg function). So this just enables the truly generic builtins along with some PPC builtins. If my understanding is correct, I'd say this is ready to proceed (unless it was subsumed by one of the other patches).

Long story short... LGTM.
You may want to get the green light from @hfinkel or @echristo and/or one of the compiler-rt experts as well.

This revision is now accepted and ready to land.Sep 18 2017, 5:54 AM
echristo accepted this revision.Sep 18 2017, 2:13 PM

This is great with me.

This has been sitting in approved state for more than 2 months. As far as I can tell, it wasn't committed. Do you plan to commit this soon or are you abandoning it for some reason?

This has been sitting in approved state for more than 2 months. As far as I can tell, it wasn't committed. Do you plan to commit this soon or are you abandoning it for some reason?

My apologies. I have gotten distracted by other things and will get this submitted shortly.

saugustine closed this revision.Nov 30 2017, 1:09 PM

Committed as rL319474.