[LLVMdev] Remaining Compiler-RT failures in ARM

Evgeniy Stepanov eugenis at google.com
Fri Oct 10 03:55:38 PDT 2014


On Thu, Oct 9, 2014 at 8:29 PM, Renato Golin <renato.golin at linaro.org> wrote:
> Folks,
>
> As of this run:
>
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/746
>
> There are three classes of failures that need fixing before we get the
> bot green:
>
> 1. AddressSanitizer.BuiltinLongJmpTest Unit Test
>
> Two configurations fail:
>  * Asan-arm-inline-Test
>  * Asan-arm-with-calls-Test
>
> I wonder what's the best way to run it individually and reduce the
> error. I'm not very proficient with the unit tests, and I'd be happy
> with some documentation on how to reduce them.
>
>
> 2. Illegal instruction
>
> * AddressSanitizer-arm-linux :: TestCases/mmap_limit_mb.cc
> * UndefinedBehaviorSanitizer-Standalone :: TestCases/Misc/bounds.cpp
>
> That board doesn't have NEON. It's uncommon for an ARMv7 SoC to not
> have it, but some don't (for example, NVidia Tegra3), so we can't
> assume they all have.
>
> The CMake option clearly had "-mfpu=vfpv3" on both C and C++ flags and
> the tests should honour that. This is a wider problem, and the
> test-suite buildbots also don't honour it and fail on non-NEON ARMv7
> boards.
>
> I'm not an expert in CMake and even less so in Compiler-RT's setup for
> the tests, so pointers on how to fix this would be very welcome.

Are you saying that CMAKE_C_FLAGS from LLVM tree are not used in compiler-rt?

This is way too complicated. We've got
COMPILER_RT_TEST_COMPILER_CFLAGS but they don't seem to be set in
non-standalone build ever. Alexey, do we simply miss an assignment
somewhere, or did you have something else in mind?

>
> 3. UndefinedBehaviorSanitizer-Standalone :: TestCases/Misc/missing_return.cpp
>
> This test fails on Standalone and pass on AddressSanitizer mode,
> making it impossible to mark it as XFAIL. Before making XFAIL more
> powerful, I'd rather find the problem and try to solve it.
>
> The file checks for two copies of missing_return.cpp, one for f() and
> one for main(), but on ARM's stack trace, there's only one:
>
> $ UBSAN_OPTIONS=print_stacktrace=1 ./missing_return.cpp.tmp
> .../compiler-rt/test/ubsan/TestCases/Misc/missing_return.cpp:6:5:
> runtime error: execution reached the end of a value-returning function
> without returning a value
>
>     #0 0x1c7cf in f()
> .../compiler-rt/test/ubsan/TestCases/Misc/missing_return.cpp:6:9
>     #1 0x195cf in __ubsan::ScopedReport::~ScopedReport()
> .../compiler-rt/lib/ubsan/ubsan_diag.cc:341
>     #2 0x1ae79 in handleMissingReturnImpl(__ubsan::UnreachableData*,
> __ubsan::ReportOptions) [clone .constprop.7]
> .../compiler-rt/lib/ubsan/ubsan_handlers.cc:254
>     #3 0x1b31f in __ubsan_handle_missing_return
> .../compiler-rt/lib/ubsan/ubsan_handlers.cc:259
>
> Maybe the stack is not deep enough? Is it really necessary to get for
> main in the stack trace?
>
> cheers,
> --renato



More information about the llvm-dev mailing list