2.7 Pre-release1 available for testing

The 2.7 binaries are available for testing:
http://llvm.org/pre-releases/2.7/pre-release1/

You will also find the source tarballs there as well.

We rely on the community to help make our releases great, so please help test 2.7 if you can. Please follow these instructions to test 2.7:

To test llvm-gcc:

1) Compile llvm from source and untar the llvm-test in the projects  
directory (name it llvm-test or test-suite). Choose to use a pre- 
compiled llvm-gcc or re-compile it yourself. 
2) Run make check, report any failures (FAIL or unexpected pass). Note  
that you need to reconfigure llvm with llvm-gcc in your path or with -- with-llvmgccdir
3) Run "make TEST=nightly report". Compare these results to a 2.6 llvm-test nightly report or send the results to the list. For supported targets, we'll try to examine the results, but its best if you can do the comparison yourself.

*To test clang:*
1) Compile llvm and clang from source.
2) Run make check for llvm.
3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or  
unexpected passes)
4) Run "make TEST=nightly report". Make sure its using clang instead of llvm-gcc. Compare these results to a 2.6 llvm-test nightly report or send the results to the list. For supported targets, we'll try to examine the results, but its best if you can do the comparison yourself.

When reporting your results, please provide details on what platform (32 or 64 bit, arch, os) 
you compiled on, how you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc, and which version of gcc you use.

For any regressions in llvm-test, failures in make check, or warnings/errors you find, please add as a blocker to the 2.7 master bug:
[http://llvm.org/bugs/show_bug.cgi?id=6586](http://llvm.org/bugs/show_bug.cgi?id=6586)

**Please COMPLETE ALL TESTING BY end of the day on March 24th.**

Thanks,

Tanya

The 2.7 binaries are available for testing:
http://llvm.org/pre-releases/2.7/pre-release1/

Any plans for LLVM binaries and LLVM-GCC front-end binaries for MinGW32 similar to 2.6?

Jon

Yes. Anton will be generating these. He doesn't normally do them for pre-releases though because of the time it takes given his setup.

-Tanya

Hello, Jon

The 2.7 binaries are available for testing:
http://llvm.org/pre-releases/2.7/pre-release1/

Any plans for LLVM binaries and LLVM-GCC front-end binaries for MinGW32 similar to 2.6?

Yes. Sorry, I was pretty busy during last few weeks. They will be
available asap.

The 2.7 binaries are available for testing:
http://llvm.org/pre-releases/2.7/pre-release1/

You will also find the source tarballs there as well.

We rely on the community to help make our releases great, so please help
test 2.7 if you can. Please follow these instructions to test 2.7:

To test llvm-gcc:
1) Compile llvm from source and untar the llvm-test in the projects
directory (name it llvm-test or test-suite). Choose to use a pre-
compiled llvm-gcc or re-compile it yourself.
2) Run make check, report any failures (FAIL or unexpected pass). Note
that you need to reconfigure llvm with llvm-gcc in your path or with --
with-llvmgccdir
3) Run "make TEST=nightly report". Compare these results to a 2.6
llvm-test nightly report or send the results to the list. For supported
targets, we'll try to examine the results, but its best if you can do

the

comparison yourself.

To test clang:
1) Compile llvm and clang from source.
2) Run make check for llvm.
3) Run make -C tools/clang-2.6 test VERBOSE=1 (report any failures or
unexpected passes)
4) Run "make TEST=nightly report". Make sure its using clang instead of
llvm-gcc. Compare these results to a 2.6 llvm-test nightly report or

send

the results to the list. For supported targets, we'll try to examine the
results, but its best if you can do the comparison yourself.

When reporting your results, please provide details on what platform (32
or 64 bit, arch, os)
you compiled on, how you built LLVM (src == obj, or src != obj), clang,
and/or llvm-gcc, and which version of gcc you use.

For any regressions in llvm-test, failures in make check, or
warnings/errors you find, please add as a blocker to the 2.7 master bug:
http://llvm.org/bugs/show_bug.cgi?id=6586

Ok I am ready to test but I think you didn't include mingw fix
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/Makefile?view=log
So I have manually reported it and compiled clang in release mode.

First step with objective-c and libobjc from GNUstep :

$ make CC=clang messages=yes
This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for help.
Making all for clibrary libobjc...
clang archive.c -c \
              -MMD -MP -DIN_GCC -pipe -DSTDC_HEADERS=1 -DHAVE_STDLIB_H
-DOBJC_WITH_GC=0 -DDEBUG_OBJC_GC=0 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1
-DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1
-DGNUSTEP_WITH_DLL -DBUILD_libobjc_DLL=1 -Wall -DGSWARN -DGSDIAGNOSE
-Wno-import -g -O2 -Wall -Iconfig/ix86/mingw32 -Iconfig/ix86/generic -I.
-I. -I/home/Vincent/GNUstep/Library/Headers
-I/GNUstep/Local/Library/Headers -I/GNUstep/System/Library/Headers \
               -o obj/libobjc.obj/archive.c.o
Assertation failed!

Program: C:\Developer\Mingw-NG\mingw32\bin\clang.exe
File: X86ISelLowering.cpp, Line 2152

Expression: ((Callee.getOpcode() == ISD::Register &&
(cast<RegisterSDNode>(Callee)->getReg() == X86::EAX ||
cast<RegisterSDNode>(Callee)->getReg() == X86::R11)) || Callee.getOpcode()
== ISD::TargetExternalSymbol || Callee.getOpcode() ==
ISD::TargetGlobalAddress) && "Expec

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
clang: error: compiler command failed with exit code 3 (use -v to see
invocation)
make[3]: *** [obj/libobjc.obj/archive.c.o] Error 3
make[2]: *** [internal-library-all_] Error 2
make[1]: *** [libobjc.all.clibrary.variables] Error 2
make: *** [internal-all] Error 2

When I try to enter command line with -v :

clang version 1.1 (branches/release_27)
Target: i686-pc-mingw32
Thread model: posix
"C:/Developer/Mingw-NG/mingw32/bin/clang.exe" -cc1 -triple
i686-pc-mingw32 -S -disable-free -main-file-name archive.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -v -g
-resource-dir C:/Developer/Mingw-NG/mingw32/lib/clang/1.1 -dependency-file
obj/libobjc.obj/archive.c.d -MT obj/libobjc.obj/archive.c.o -MP -DIN_GCC
-DSTDC_HEADERS=1 -DHAVE_STDLIB_H -DOBJC_WITH_GC=0 -DDEBUG_OBJC_GC=0
-DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1
-DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_WITH_DLL -DBUILD_libobjc_DLL=1 -DGSWARN
-DGSDIAGNOSE -Iconfig/ix86/mingw32 -Iconfig/ix86/generic -I. -I.
-IC:/Developer/Mingw-NG/home/Vincent/GNUstep/Library/Headers
-IC:/Developer/Mingw-NG/GNUstep/Local/Library/Headers
-IC:/Developer/Mingw-NG/GNUstep/System/Library/Headers -O2 -Wall
-Wno-import -Wall -fmessage-length 0 -fgnu-runtime
-fdiagnostics-show-option -o C:/DOCUME~1/Vincent/LOCALS~1/Temp/cc-000000.s
-x c archive.c
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on i686-pc-mingw32
ignoring nonexistent directory
"C:/Developer/Mingw-NG/home/Vincent/GNUstep/Library/Headers"
ignoring nonexistent directory
"C:/Developer/Mingw-NG/GNUstep/Local/Library/Headers"
ignoring nonexistent directory
"C:/Developer/Mingw-NG/mingw32/lib/clang/1.1/include"
ignoring nonexistent directory "c:/mingw/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/include"
ignoring duplicate directory "."
#include "..." search starts here:
#include <...> search starts here:
config/ix86/mingw32
config/ix86/generic
.
C:/Developer/Mingw-NG/GNUstep/System/Library/Headers
c:/Developer/Mingw-NG/mingw32/include
c:/Developer/Mingw-NG/mingw32/lib/gcc/i686-w64-mingw32/4.4.4/include

c:/Developer/Mingw-NG/mingw32/lib/gcc/i686-w64-mingw32/4.4.4/include-fixed
c:/Developer/Mingw-NG/mingw32/i686-w64-mingw32/include
End of search list.

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
clang: error: compiler command failed with exit code 3 (use -v to see
invocation)

I am going to recompile in debug mode to see what is going on ...

The 2.7 binaries are available for testing:
http://llvm.org/pre-releases/2.7/pre-release1/

You will also find the source tarballs there as well.

We rely on the community to help make our releases great, so please help
test 2.7 if you can. Please follow these instructions to test 2.7:

To test llvm-gcc:
1) Compile llvm from source and untar the llvm-test in the projects
directory (name it llvm-test or test-suite). Choose to use a pre-
compiled llvm-gcc or re-compile it yourself.
2) Run make check, report any failures (FAIL or unexpected pass). Note
that you need to reconfigure llvm with llvm-gcc in your path or with --
with-llvmgccdir
3) Run "make TEST=nightly report". Compare these results to a 2.6
llvm-test nightly report or send the results to the list. For supported
targets, we'll try to examine the results, but its best if you can do

the

comparison yourself.

To test clang:
1) Compile llvm and clang from source.
2) Run make check for llvm.
3) Run make -C tools/clang-2.6 test VERBOSE=1 (report any failures or
unexpected passes)
4) Run "make TEST=nightly report". Make sure its using clang instead of
llvm-gcc. Compare these results to a 2.6 llvm-test nightly report or

send

the results to the list. For supported targets, we'll try to examine the
results, but its best if you can do the comparison yourself.

When reporting your results, please provide details on what platform (32
or 64 bit, arch, os)
you compiled on, how you built LLVM (src == obj, or src != obj), clang,
and/or llvm-gcc, and which version of gcc you use.

For any regressions in llvm-test, failures in make check, or
warnings/errors you find, please add as a blocker to the 2.7 master bug:
http://llvm.org/bugs/show_bug.cgi?id=6586

Ok I am ready to test but I think you didn't include mingw fix
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/Makefile?view=log
So I have manually reported it and compiled clang in release mode.

That is correct. It is not in pre-release1. It will be in pre-release2 because of when I was sent the patch.

-Tanya

Hello, Vincent

Expression: ((Callee.getOpcode() == ISD::Register &&
(cast<RegisterSDNode>(Callee)->getReg() == X86::EAX ||
cast<RegisterSDNode>(Callee)->getReg() == X86::R11)) || Callee.getOpcode()
== ISD::TargetExternalSymbol || Callee.getOpcode() ==
ISD::TargetGlobalAddress) && "Expec

Smells like sibcall lowering problem. Evan - was there any bugfixes in
this areas past 2.7 branch?

cc'ing evan

wrote:

cc'ing evan

Hello, Vincent

Expression: ((Callee.getOpcode() == ISD::Register &&
(cast<RegisterSDNode>(Callee)->getReg() == X86::EAX ||
cast<RegisterSDNode>(Callee)->getReg() == X86::R11)) ||
Callee.getOpcode()
== ISD::TargetExternalSymbol || Callee.getOpcode() ==
ISD::TargetGlobalAddress) && "Expec

Smells like sibcall lowering problem. Evan - was there any bugfixes in
this areas past 2.7 branch?

--

Actually GNUstep libobjc won't compile with clang because it uses some GNU
extensions.

So I tried to use the current clang's trunk to compile
libgnustep-gui(GNUstep AppKit) :

clang NSClipView.m -c \
        -MMD -MP -DGNUSTEP_TARGET_DIR=\".\" -DGNUSTEP_TARGET_CPU=\"ix86\"
-DGNUSTEP_TARGET_OS=\"mingw32\" -DLIBRARY_COMBO=\"gnu-gnu-gnu\"
-DBACKEND_BUNDLE=1 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_WITH_DLL
-DBUILD_libgnustep_gui_DLL=1 -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2
-fno-strict-aliasing -fgnu-runtime -Wall
-fconstant-string-class=NSConstantString -I../Headers/Additions
-I../Headers -I./. -I. -I/home/Vincent/GNUstep/Library/Headers
-I/GNUstep/Local/Library/Headers -I/GNUstep/System/Library/Headers \
         -o obj/libgnustep-gui.obj/NSClipView.m.o

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
clang: error: compiler command failed with exit code 3 (use -v to see
invocation)

So I tried to invoke -v :

cd Source
clang -v ....
Program: C:\Developer\Mingw-NG\mingw32\bin\clang.exe
File: X86FloatingPoint.cpp, Line 178

Expression: Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"

Don't know if it helps.

Actually I don't really know what is the best way to help.

Hi Tanya,

On darwin9, the binaries in the darwin10 packages give:

$ /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as --help
dyld: unknown required load command 0x80000022
Trace/BPT trap

That could be unavoidable, of course.

Also, could you document what build mode the packages use (or release
both Debug and Release-Asserts packages)? Since +Asserts and -Asserts
have different ABIs, I'd have to write a test to figure out how I
should compile Unladen Swallow.

Thanks,
Jeffrey

Hm, I also note that:

$ file /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as
/opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as: Mach-O 64-bit executable x86_64

Why's the i386 package have an x86_64 binary in it? That could explain
why it doesn't work on darwin9.

Hm, I also note that:

$ file /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as
/opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as: Mach-O 64-bit executable x86_64

Why's the i386 package have an x86_64 binary in it? That could explain
why it doesn't work on darwin9.

Ah, crap.. I forgot to update my script to change the name. I'll fix that now.

I don't believe that binary will work on leopard because of how I built it.

-Tanya

With Microsoft C++ (Windows Vista, 32-bit):

LLVM 2.7 compiles (via cmake) without a hitch.

I can't test it with my own code yet, will need to port from 2.6 to 2.7 first.

I was going to try running Kaleidoscope as a test case, but it doesn't
get built by default the way it did in 2.6, and running nmake in the
Kaleidoscope directory performs no operation. Am I missing something
here?

cmake doesn't recognize llvm-gcc, are there instructions for compiling
it with Microsoft C++? If so, I can try that next.

llvm-gcc only builds with gcc.

Aaron

Ah, okay, thanks. Is the same true of Clang?

Clang builds with MSVC, though to build something you have to have a
'gcc' in your path to build the assembly that is produced.

Okay; it doesn't seem to build with cmake, though?

C:\d\clang>\cmake-2.8.0-win32-x86\bin\cmake.exe c:\d\clang-2.7
-- Building for: NMake Makefiles
-- The C compiler identification is MSVC
-- The CXX compiler identification is MSVC
-- Check for CL compiler version
-- Check for CL compiler version - 1500
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - no
-- Check CL platform
-- Check CL platform - 32 bit
-- Check for working C compiler: C:/Program Files/Microsoft Visual
Studio 9.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files/Microsoft Visual
Studio 9.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual
Studio 9.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual
Studio 9.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Clang version: 1.1
CMake Error at include/clang/Basic/CMakeLists.txt:2 (tablegen):
  Unknown CMake command "tablegen".
Call Stack (most recent call first):
  include/clang/Basic/CMakeLists.txt:9 (clang_diag_gen)

CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present. A line of code such as

    cmake_minimum_required(VERSION 2.8)

  should be added at the top of the file. The version specified may be lower
  if you wish to support older CMake versions for this project. For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers. Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!

C:\d\clang>\cmake-2.8.0-win32-x86\bin\cmake.exe -Wno-dev c:\d\clang-2.7
-- Clang version: 1.1
CMake Error at include/clang/Basic/CMakeLists.txt:2 (tablegen):
  Unknown CMake command "tablegen".
Call Stack (most recent call first):
  include/clang/Basic/CMakeLists.txt:9 (clang_diag_gen)

-- Configuring incomplete, errors occurred!

Russell Wallace <russell.wallace@gmail.com> writes:

Okay; it doesn't seem to build with cmake, though?

C:\d\clang>\cmake-2.8.0-win32-x86\bin\cmake.exe c:\d\clang-2.7
-- Building for: NMake Makefiles

Follow the instructions for building clang:

http://clang.llvm.org/get_started.html

[snip]

Ah, thanks... curious, that set of instructions recommends running
make in place (in the combined llvm directory), instead of in a
separate directory as when building llvm without clang.

Anyway, following those instructions (substituting unpacking the tar
files for the svn checkout) gets me a .sln file (the resulting
makefile doesn't work, but the .sln does), in which the build all
command appears to work, and reports complete success.

However, while it does generate a bunch of the usual ll*.exe's,
clang.exe is still not there. Am I still missing something?

Russell Wallace <russell.wallace@gmail.com> writes:

Ah, thanks... curious, that set of instructions recommends running
make in place (in the combined llvm directory), instead of in a
separate directory as when building llvm without clang.

It doesn't *recommend* running cmake in-source. It is just that the
instructions are written that way. When generating VS solution files,
building in-source is not a problem. It is when generating makefiles, as
the generated makefiles will overwrite those provided with LLVM's
sources.

Anyway, following those instructions (substituting unpacking the tar
files for the svn checkout) gets me a .sln file (the resulting
makefile doesn't work, but the .sln does), in which the build all
command appears to work, and reports complete success.

cmake will generate makefiles if you wish. Just use this command:

cmake -G "NMake Makefiles"

but then you should use a different directory for the build.

However, while it does generate a bunch of the usual ll*.exe's,
clang.exe is still not there. Am I still missing something?

Suppossing that you have the LLVM source code in c:/llvm, do you have

c:/llvm/tools/clang/CMakeLists.txt

?

If that is not present, most likely your clang setup is wrong. The LLVM
cmake build test for the presence of the above file and, if found,
automatically builds clang. If the test fails, clang is ignored.

Once you have clang on the right place, reinvoke cmake from the top LLVM
source directory again so it notices the presence of clang. Use the same
command line you used for the first cmake invocation.