Travis build hits internal compiler error

[dylanmckay]

See the compile log (gcc).

[dylanmckay]

Both clang and g++ fail.

g++ has a kind of useful error message, clang simply says that the linker was killed.

[4ntoine]

https://travis-ci.org/avr-llvm/llvm/jobs/51697028

llvm[2]: Compiling lto.cpp for Debug+Asserts build (PIC)
llvm[2]: Linking Debug+Asserts Shared Library libLTO.so
collect2: error: ld terminated with signal 9 [Killed]
make[2]: *** [/home/travis/build/avr-llvm/llvm/Debug+Asserts/lib/libLTO.so] Error 1
make[2]: Leaving directory `/home/travis/build/avr-llvm/llvm/tools/lto'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/travis/build/avr-llvm/llvm/tools'
make: *** [all] Error 1
The command "make" exited with 2.

Killed externally? Memory usage/cpu time limit exceeded? http://blog.inventic.eu/2012/07/linux-c-linker-ld-terminated-with-signal-9/

[RandomInsano]

Out of memory likely, I’ve had jobs run longer. I’m thinking of a few options here:

1) Run the build with -j1 to run fewer compile jobs, will take longer 2) Drop GCC since Clang seems to build alright 3) Try using CMake instead of Autotools 4) Run the build step a few times 5) Try building specific sections individually after configure

Not sure what the easiest first pass would be. I’m inclined to try #5 first.

On Feb 22, 2015, at 2:02 AM, Anton Smirnov notifications@github.com wrote:

https://travis-ci.org/avr-llvm/llvm/jobs/51697028

llvm[2]: Compiling lto.cpp for Debug+Asserts build (PIC) llvm[2]: Linking Debug+Asserts Shared Library libLTO.so collect2: error: ld terminated with signal 9 [Killed] make[2]: * [/home/travis/build/avr-llvm/llvm/Debug+Asserts/lib/libLTO.so] Error 1 make[2]: Leaving directory `/home/travis/build/avr-llvm/llvm/tools/lto' make[1]: * [all] Error 1 make[1]: Leaving directory`/home/travis/build/avr-llvm/llvm/tools' make: *\ [all] Error 1 The command "make" exited with 2. Killed externally? Memory usage/cpu time limit exceeded? http://blog.inventic.eu/2012/07/linux-c-linker-ld-terminated-with-signal-9/

— Reply to this email directly or view it on GitHub.

[dylanmckay]

I believe it is an out of memory error. Clang tends to be more memory efficient than gcc.

Previously, both clang and gcc would fail. After I merged your patch which only enabled the AVR target, now it is just GCC failing. It is likely that memory was conserved because less jobs were run in parallel.

[dylanmckay]

"On the Linux platform, builds have 3 GB of memory available"

LLVM tends to take about that much for me when using GCC and 3 or 4 parallel jobs, so yeah, that's probably it.

[dylanmckay]

1) Run the build with -j1 to run fewer compile jobs, will take longer

5) Try building specific sections individually after configure

I believe these two options are equivalent, but the first is easier and less hacky to implement. Either way you are simply reducing the amount of work done at once, and compilation will still take the same amount of time for both options.

[dylanmckay]

I added the -j 1 argument to make for both llvm and lld - we'll see how it goes.

[dylanmckay]

clang ran out of memory and gcc exceeded the 50 minute limit.

[RandomInsano]

The only difference between 1 and 5, breaking the sections down into sub section should result in less deep recursion and more memory saved from Make.

I'll run through a few of the options

Edwin (on the move)

On Feb 22, 2015, at 5:58 AM, Dylan McKay notifications@github.com wrote:

1) Run the build with -j1 to run fewer compile jobs, will take longer

5) Try building specific sections individually after configure

I believe these two options are equivalent, but the first is easier and less hacky to implement. Either way you are simply reducing the amount of work done at once, and compilation will still take the same amount of time for both options.

— Reply to this email directly or view it on GitHub.

[RandomInsano]

There's gotta be a way around this. I'll throw it around with the C++ guys at work and see what they think. Overlaying new files over the old builds is the best idea in my head now, but that can lead to some inconsistencies.

Edwin (on the move)

On Feb 22, 2015, at 12:59 PM, Dylan McKay notifications@github.com wrote:

clang ran out of memory and gcc exceeded the 50 minute limit.

— Reply to this email directly or view it on GitHub.

[dylanmckay]

Because the failing builds are making the project look bad (and the fact they are actually caused by out of memory errors), I have removed the build status button from the README's of llvm and lld until we fix this.

[RandomInsano]

I agree. I'm not really sure how we can speed this up either, even after discussing with folks.

I do wish LLVM were a lot more modular at the source level. Building everything in one go is a bit silly.

[dylanmckay]

I'll post to the llvmdev mailing list, ask for suggestions.

[RandomInsano]

I'm also testing with CMake in my fork to see if it's going to be safer for memory usage with GCC. At the very least we have a percentage telling us how long it got in the build before being killed.

[RandomInsano]

Woo! Good news everyone! It looks like even with GCC, we're coming in at about 35 minutes, so we have a ten minute buffer.

Dylan accidentally had to do the same patchwork I put in... I'm a bit embarrassed about my lack of proper branching.

[dylanmckay]

Dylan accidentally had to do the same patchwork I put in... I'm a bit embarrassed about my lack of proper branching.

At least travis is finally working! :D

[RandomInsano]

Setting -j3 made it finish MUCH faster. I'm fighting with git at the moment to get it into a merge request. Will try again tomorrow.

Results here: (build 8 uses -j2, build 9 uses -j3) https://travis-ci.org/RandomInsano/llvm/builds

[dylanmckay]

Are you using the free version of travis?

[RandomInsano]

As far as I'm aware. I haven't given them a credit card or anything.

My current guess is it's late in North America, so probably the build systems are draining so we have more resources?

[RandomInsano]

The pull request looks good for speed too.

[dylanmckay]

Closing as travis builds are now succeeding.