We are starting to move to using llvm/clang x86 as the starting point for mips native compilers. It's important to make sure that gcc cross compilers can do this too but sometimes there are issues there; especially now as c++11 is moving into the foreground. We are working to also make sure this works. As 3.5 llvm is probably around the corner; our use of clang/llvm for this starting point does not work with 3.4 but does work with current tip of tree and going back some amount of time too. It would seem that dot releases would be important for others that want to have clang/llvm be the starting point for the following major releases. In other words, a compiler which can be used to build the next one. Reed
On 03/12/2014 04:09 PM, reed kotler wrote:> We are starting to move to using llvm/clang x86 as the starting point > for mips native compilers. > > It's important to make sure that gcc cross compilers can do this too but > sometimes there are issues there; > especially now as c++11 is moving into the foreground. We are working to > also make sure this works. > > As 3.5 llvm is probably around the corner; our use of clang/llvm for > this starting point does not work with 3.4 > but does work with current tip of tree and going back some amount of > time too. > > It would seem that dot releases would be important for others that want > to have clang/llvm be the starting point > for the following major releases. > > In other words, a compiler which can be used to build the next one. > > ReedWe have an almost identical issue with the other failing test: When I run the test myself from the command line it looks fine. rkotler at mipsswbrd002:~/slave/slavetargetbe/build$ ../install/bin/not --crash ../install/bin/clang -cc1 -analyze -analyzer-checker=debug.ExprInspection /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c 0 clang 0x0385c194 llvm::sys::PrintStackTrace(_IO_FILE*) + 96 Stack dump: 0. Program arguments: ../install/bin/clang -cc1 -analyze -analyzer-checker=debug.ExprInspection /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c 1. /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c:4:2: current parser token 'prag\ ma' Error: Trace/breakpoint trap rkotler at mipsswbrd002:~/slave/slavetargetbe/build$ Whereas in the make check: ******************** FAIL: Clang :: Parser/crash-report.c (3772 of 16980) ******************** TEST 'Clang :: Parser/crash-report.c' FAILED ******************** Script: -- not --crash /home/rkotler/slave/slavetargetbe2/build/Release+Asserts/bin/clang -cc1 -internal-isystem /home/rkotler/slave/slavetargetbe2/build/Release+Asserts/bin/../lib/clang/3.5.0/include /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c 2>&1 | FileCheck /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c -- Exit Code: 1 Command Output (stderr): -- /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c:7:11: error: expected string not found in input // CHECK: prag\ ^ <stdin>:1:1: note: scanning from here 0 Error: Segmentation fault ^ <stdin>:1:3: note: possible intended match here 0 Error: Segmentation fault ^ --
This last post was to the wrong message. Sorry. On 03/12/2014 04:40 PM, Reed Kotler wrote:> We have an almost identical issue with the other failing test: > > When I run the test myself from the command line it looks fine. > > rkotler at mipsswbrd002:~/slave/slavetargetbe/build$ ../install/bin/not > --crash ../install/bin/clang -cc1 -analyze > -analyzer-checker=debug.ExprInspection > /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c > 0 clang 0x0385c194 llvm::sys::PrintStackTrace(_IO_FILE*) + 96 > Stack dump: > 0. Program arguments: ../install/bin/clang -cc1 -analyze > -analyzer-checker=debug.ExprInspection > /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c > 1. > /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c:4:2: > current parser token 'prag\ > ma' > Error: Trace/breakpoint trap > rkotler at mipsswbrd002:~/slave/slavetargetbe/build$ > > Whereas in the make check: > > ******************** > FAIL: Clang :: Parser/crash-report.c (3772 of 16980) > ******************** TEST 'Clang :: Parser/crash-report.c' FAILED > ******************** > Script: > -- > not --crash > /home/rkotler/slave/slavetargetbe2/build/Release+Asserts/bin/clang -cc1 > -internal-isystem > /home/rkotler/slave/slavetargetbe2/build/Release+Asserts/bin/../lib/clang/3.5.0/include > /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c > 2>&1 | FileCheck > /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c > -- > Exit Code: 1 > > Command Output (stderr): > -- > /home/rkotler/workspace/llvmslave/tools/clang/test/Parser/crash-report.c:7:11: > error: expected string not found in input > // CHECK: prag\ > ^ > <stdin>:1:1: note: scanning from here > 0 Error: Segmentation fault > ^ > <stdin>:1:3: note: possible intended match here > 0 Error: Segmentation fault > ^ > > --
This post confused me until I spoke to Reed off-list so just to clarify: Reed isn't talking about us releasing a Clang 3.4.x for MIPS. We currently plan to start releasing a 'Clang for MIPS*' beginning with Clang 3.5. Reed is talking about using a trunk version of Clang as the compiler used to build 'Clang 3.5 for MIPS*'. Beyond that point, we will then be able to use Clang 3.5 to build the Clang 3.6 release and so on.> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Reed Kotler > Sent: 12 March 2014 23:10 > To: LLVMdev at cs.uiuc.edu > Subject: [LLVMdev] dot release for 3.4 > > We are starting to move to using llvm/clang x86 as the starting point for mips > native compilers. > > It's important to make sure that gcc cross compilers can do this too but > sometimes there are issues there; especially now as c++11 is moving into the > foreground. We are working to also make sure this works. > > As 3.5 llvm is probably around the corner; our use of clang/llvm for this > starting point does not work with 3.4 but does work with current tip of tree > and going back some amount of time too. > > It would seem that dot releases would be important for others that want to > have clang/llvm be the starting point for the following major releases. > > In other words, a compiler which can be used to build the next one. > > Reed > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev