Help to download checker-270.tar.bz2

Dear All:
I cannot download checker-270.tar.bz2 from http://clang-analyzer.llvm.org/;
Can you send me the file? Thanks a lot.

BRs

Howard Ling (凌欢)

It works fine for me. What error are you getting? (We definitely want to make sure there’s not an issue with the link.)

The file is 29MB, which is too big an e-mail for the list. If you can confirm you’re not able to access it on https://attache.apple.com/AttacheWeb/dl?id=ATC026bc118ec6a43c5b82969352059e927 (the expanded form of the shortened URL), I’ll forward it to you privately.

Sorry for the trouble!
Jordan

Dear ALL:
When I use the scan-build from Clang checker-272, it gets the following errors:

/Users/mqq/hudson/clang_browser_iphone/Classes/browser/startpage/UIQuickLinkView.m:773:45: error: use of undeclared identifier ‘APP_INSERT_FRONT’
NSInteger action = isInsertBefore ? APP_INSERT_FRONT : APP_INSERT_BEHIND;
^
/Users/mqq/hudson/clang_browser_iphone/Classes/browser/startpage/UIQuickLinkView.m:773:64: error: use of undeclared identifier ‘APP_INSERT_BEHIND’
NSInteger action = isInsertBefore ? APP_INSERT_FRONT : APP_INSERT_BEHIND;

The above file is from Dependent target , so ,is it any wrong config in Xcode Project ?
At the same time , we get no error when we use build and analyze memu from Xcode .
If the xcode project is OK, any other reason cause the scan fail?
btw ,the xcode is 4.5 and the sdk is 6.0
Thanks for you help.

BRs

Howard Ling (凌欢)

Hello, Howard. One issue that might be related is that scan-build can’t use a PCH (precompiled header) file with Xcode 4.5. Are these constants are only declared in your PCH?

The good news: as of checker-271, scan-build takes advantage of new hooks in Xcode 4.6 to use PCH, which should fix your issue. Can you update your Xcode and try again?

Jordan

hi, jordan:
After I switch to checker -271 and xcode 4.6+sdk6.1, the same error still exist,
do you have other ideas?
btw, when I use the following command :

/data/checker/scan-build -o report --use-cc=$clang_path $xcode_path -workspace mtt.xcworkspace -scheme mttlite -configuration $config -sdk $sdk
There is no any error ,but only 10 bugs ,is it valid scan command ?
Thanks for your Follow up and reply.

That seems valid to me. I will note that Xcode currently handles bugs that span files due to function inlining, while scan-build does not (because we haven’t taken the time to come up with a good way of displaying them in HTML). The current behavior is to ignore these bugs, with the idea that the user is at least getting some value out of the analyzer.

It’s worth checking that at least some of the 10 bugs are a subset of the bugs you see in Xcode, though since checker-271 is newer they might be a bit different. (Also, it’s fine to use checker-272 and later with Xcode 4.6 as well; checker-271’s just the first release that took advantage of the extra hooks in Xcode.)

Jordan

Hi all!

I have finally decided to upgrade from my old Core 2 Duo E8500, 6GB DDR2 400 MHz.
Currently the full building+testing of llvm lasts for hours (slightly faster with VS2008, slightly slower with MinGW) and makes everything lag.
Ideally would be happy to perform build+test for about 10-20 minutes, as some fast builders do, and have no lags with other useful applications, such as browsers and Acrobat, during building/testing.
Please can anybody advise me an appropriate hardware? Or just tell, what hardware the fast buildbots are running (specifically clang-native-mingw64-win7, clang-x86_64-ubuntu-gdb-75 and clang-x86_64-debian-fast)?

Hi all!

I have finally decided to upgrade from my old Core 2 Duo E8500, 6GB DDR2 400 MHz.
Currently the full building+testing of llvm lasts for hours (slightly faster with VS2008, slightly slower with MinGW) and makes everything lag.

By "test," do you mean the lit tests in llvm/test or a full run of the test suite in the test-suite project?

Ideally would be happy to perform build+test for about 10-20 minutes, as some fast builders do, and have no lags with other useful applications, such as browsers and Acrobat, during building/testing.
Please can anybody advise me an appropriate hardware? Or just tell, what hardware the fast buildbots are running (specifically clang-native-mingw64-win7, clang-x86_64-ubuntu-gdb-75 and clang-x86_64-debian-fast)?

Just to throw out some rough numbers, we have a 128 GB, 32 core machine. The processors are Intel(R) Xeon(R) CPU E7- 8837 @ 2.67GHz.

Doing a make -j20 on LLVM+Clang from scratch takes about 4 minutes of wall time and about 50 minutes of user+system CPU time. I can't seem to run the tests in llvm/test, so I can't time that.

-- John T.

I run an Intel Core i5-2500 (Sandy Bridge) here, with 8GB 1866MHz RAM and a
128GB SSD. A full rebuild usually takes 10-20min with MSVC2012.

Hi all!

I have finally decided to upgrade from my old Core 2 Duo E8500, 6GB DDR2 400 MHz.
Currently the full building+testing of llvm lasts for hours (slightly faster with VS2008, slightly slower with MinGW) and makes everything lag.

By "test," do you mean the lit tests in llvm/test or a full run of the test suite in the test-suite project?

I mean lit tests.

Ideally would be happy to perform build+test for about 10-20 minutes, as some fast builders do, and have no lags with other useful applications, such as browsers and Acrobat, during building/testing.
Please can anybody advise me an appropriate hardware? Or just tell, what hardware the fast buildbots are running (specifically clang-native-mingw64-win7, clang-x86_64-ubuntu-gdb-75 and clang-x86_64-debian-fast)?

Just to throw out some rough numbers, we have a 128 GB, 32 core machine. The processors are Intel(R) Xeon(R) CPU E7- 8837 @ 2.67GHz.
Doing a make -j20 on LLVM+Clang from scratch takes about 4 minutes of wall time and about 50 minutes of user+system CPU time. I can't seem to run the tests in llvm/test, so I can't time that.

Cool! :slight_smile:
Then I can forget about 10 minutes..
looking at something like Intel Core i7-3770K or Core i7-3930K in the best case.

Thanx for your replay!

Thanks for your replay!
This configuration is closer to what I plan.
Could you please tell, how long check-all takes?

With a Core i7 3.4 GHz SandyBridge, a full LLVM/clang rebuild took me 470s according to time (with make -j9 on OS X and using clang 3.2 as compiler).

-- Jean-Daniel

Hi all!

I have finally decided to upgrade from my old Core 2 Duo E8500, 6GB DDR2 400 MHz.
Currently the full building+testing of llvm lasts for hours (slightly faster with VS2008, slightly slower with MinGW) and makes everything lag.

By "test," do you mean the lit tests in llvm/test or a full run of the test suite in the test-suite project?

I mean lit tests.

Ideally would be happy to perform build+test for about 10-20 minutes, as some fast builders do, and have no lags with other useful applications, such as browsers and Acrobat, during building/testing.
Please can anybody advise me an appropriate hardware? Or just tell, what hardware the fast buildbots are running (specifically clang-native-mingw64-win7, clang-x86_64-ubuntu-gdb-75 and clang-x86_64-debian-fast)?

Just to throw out some rough numbers, we have a 128 GB, 32 core machine. The processors are Intel(R) Xeon(R) CPU E7- 8837 @ 2.67GHz.
Doing a make -j20 on LLVM+Clang from scratch takes about 4 minutes of wall time and about 50 minutes of user+system CPU time. I can't seem to run the tests in llvm/test, so I can't time that.

Cool! :slight_smile:
Then I can forget about 10 minutes..
looking at something like Intel Core i7-3770K or Core i7-3930K in the best case.

With a Core i7 3.4 GHz SandyBridge, a full LLVM/clang rebuild took me 470s according to time (with make -j9 on OS X and using clang 3.2 as compiler).

Much closer to what I am thinking of. Could you, please, also tell, how much test-all takes?
Thanks for your feedback!

Hi all!

I have finally decided to upgrade from my old Core 2 Duo E8500, 6GB DDR2
400 MHz.
Currently the full building+testing of llvm lasts for hours (slightly
faster with VS2008, slightly slower with MinGW) and makes everything lag.

By "test," do you mean the lit tests in llvm/test or a full run of the
test suite in the test-suite project?

I mean lit tests.

Ideally would be happy to perform build+test for about 10-20 minutes, as

some fast builders do, and have no lags with other useful applications,
such as browsers and Acrobat, during building/testing.
Please can anybody advise me an appropriate hardware? Or just tell, what
hardware the fast buildbots are running (specifically
clang-native-mingw64-win7, clang-x86_64-ubuntu-gdb-75 and
clang-x86_64-debian-fast)?

Just to throw out some rough numbers, we have a 128 GB, 32 core machine.
The processors are Intel(R) Xeon(R) CPU E7- 8837 @ 2.67GHz.
Doing a make -j20 on LLVM+Clang from scratch takes about 4 minutes of
wall time and about 50 minutes of user+system CPU time. I can't seem to
run the tests in llvm/test, so I can't time that.

Cool! :slight_smile:
Then I can forget about 10 minutes..
looking at something like Intel Core i7-3770K or Core i7-3930K in the best
case.

Out of curiosity I decided to see how long my home system takes to build,
and I think 10 min shouldn't be too hard to reach with consumer hardware.
On my Core i7-2600K (Sandy Bridge) @ 4.8GHz with 16GB of DDR3-2133 RAM and
Linux running on a 2TB 7200 RPM SATA-III hard drive with 64MB cache, in a
new build directory with the current SVN llvm+clang+compiler-rt configured
by running "cmake -DCMAKE_BUILD_TYPE=Debug -Wno-dev .." and using gcc 4.7.2
as the compiler:

$ time { make -j9 && make -j9 check-all ; }
(lots of build output followed by a successful run of the tests)

real 10m43.235s
user 69m20.537s
sys 4m7.796s

FYI: Doing all of the above but running "check" instead of "check-all"
reduced wall-time by about 3 1/2 minutes:

$ time { make -j9 && make -j9 check ; }
real 7m15.333s
user 46m33.499s
sys 2m32.316s

Cheers,
Kaelyn

Hi,

Anton, FYI, one of my builders can build clang by 5 to 6 minutes (with
just-built-clang w/o Assertions).
http://bb.pgr.jp/builders/clang-3stage-x86_64-linux/builds/112
It is; AMD FX-8350, 32GB of RAM and Intel X25-M G2 SSD, Linux x86-64.

I know it will be faster with more expensive box. Working in progress...

I strongly suggest you may throw away Windows out of the window :stuck_out_tongue:
Otherwise, I suggest you may take cmake and ninja for (mingw32|msvc).
They work better. Feel free to ask.

...Takumi

Thanks for the tip! Currently upgraded to Core i7-3820 (Sandy Bridge) @ 3.6GHz, 16GB DDR3-1600 RAM. Now LLVM build+test takes about 20 minutes with VS2012. Now playing with MinGW.

Hi,

Hi all!

I have finally decided to upgrade from my old Core 2 Duo E8500, 6GB DDR2
400 MHz.
Currently the full building+testing of llvm lasts for hours (slightly
faster with VS2008, slightly slower with MinGW) and makes everything lag.
Ideally would be happy to perform build+test for about 10-20 minutes, as
some fast builders do, and have no lags with other useful applications,
such as browsers and Acrobat, during building/testing.
Please can anybody advise me an appropriate hardware? Or just tell, what
hardware the fast buildbots are running (specifically
clang-native-mingw64-win7, clang-x86_64-ubuntu-gdb-75 and
clang-x86_64-debian-fast)?

Using a laptop (MacBook with 16GB RAM, quad i7 @2.7 GHz, 512GB SSD) the debug build (just "make -j8") with clang 3.3 is completed in 6m40s (including clang/tools/extra). And after the build, "make check-all -j8" takes another 2m50s.

Thanx!
Right away build+test took 20 minutes with new Core i7-3820 @ 3.6GHz, 16GB DDR3-1600 RAM, VS2012.

Anton, FYI, one of my builders can build clang by 5 to 6 minutes (with
just-built-clang w/o Assertions).
http://bb.pgr.jp/builders/clang-3stage-x86_64-linux/builds/112
It is; AMD FX-8350, 32GB of RAM and Intel X25-M G2 SSD, Linux x86-64.

I know it will be faster with more expensive box. Working in progress...

I strongly suggest you may throw away Windows out of the window :stuck_out_tongue:
Otherwise, I suggest you may take cmake and ninja for (mingw32|msvc).
They work better. Feel free to ask.

I am feeling next to it - no one of 'make' ports I tried (Compiled from the MSYS trunk, Migw32, Migw64, TDM-GCC) handle multiple jobs correctly.
There is likely an old bug causing make to freeze randomly when -jN with

1 is passed to it. (I found reports with similar problem in MinGW

mailing list (http://sourceforge.net/mailarchive/message.php?msg_id=29801391)
the possible reasons, but no workaround; even found a patch from a user that should fix this, but got another errors when used 'make', compiled with this patch).

A good idea, thanx! I'll try to use cmake instead of configure. May it produce makefiles that mingw32-make.exe from MinGW64 accept.
mingw32-make.exe is my last hope on a simple solution, but currently it ends up with (renamed mingw32-make.exe to make.exe) :

make -j8 ONLY_TOOLS="clang" ENABLE_OPTIMIZED=1
Makefile:141: /f/llvm_COMMON/Makefile.rules: No such file or directory
make.EXE: *** No rule to make target `/f/llvm_COMMON/Makefile.rules'. Stop.

, while 'make' from MSYS build without errors (but hangs randomly).

MS2012 builds+tests for 20 minutes, but I want MinGW to also work :slight_smile:
Morover, it produces Clang, that is unable to link files due to unresolved externals.
(the problem is likely related to name mangling issues http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014655.html)

and that's that!

Hi, sorry for the slight delay. Sorta-related to the subject, I had a go doing a full from scratch build a while ago trying to see what components took the time on Linux, using a wrapper around the compiler calls to track the user and system time for each command. I didnt’ get any further than looking at the distribution of the build times, but it was the classic thing of a small fraction of the files taking up to 10 times longer than the median. (These were pretty much files in the clang Sema* hierarchy, which is plausible since C++ et all have so many odd rules I’d expect semantic analysis to be lots of non-optimizable code.) Unfortunately there curve was sufficiently smooth without any noticeable “knee” so it didn’t look like there was much point trying to choose some cut-off for the longest-compile files and try to refactor them.

Anyway, the upshot of that is that I’d expect that raw speed of machine would have more effect than number of cores on an incremental rebuild (at least if the clang subtree has modifications).

Not sure that really helps, but might be interesting info,

Cheers,
Dave