2.7 Pre-release1 available for testing

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

2.7 Pre-release1 available for testing

Tanya Lattner
The 2.7 binaries are available for testing:

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

Please COMPLETE ALL TESTING BY end of the day on March 24th.
Thanks,
Tanya

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7 Pre-release1 available for testing

Vincent R.
On Wed, 17 Mar 2010 13:12:19 -0700, Tanya Lattner <[hidden email]>
wrote:

> 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 ...


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7 Pre-release1 available for testing

Tanya Lattner

On Mar 17, 2010, at 2:24 PM, Vincent Richomme wrote:

> On Wed, 17 Mar 2010 13:12:19 -0700, Tanya Lattner <[hidden email]>
> wrote:
>> 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

> 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 ...
>
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7 Pre-release1 available for testing

Anton Korobeynikov
In reply to this post by Vincent R.
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?

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7 Pre-release1 available for testing

Chris Lattner

cc'ing evan

On Mar 17, 2010, at 2:45 PM, Anton Korobeynikov wrote:

> 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?
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7 Pre-release1 available for testing

Vincent R.
wrote:

> cc'ing evan
>
> On Mar 17, 2010, at 2:45 PM, Anton Korobeynikov wrote:
>
>> 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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] 2.7 Pre-release1 available for testing

Jeffrey Yasskin
In reply to this post by Tanya Lattner
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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] 2.7 Pre-release1 available for testing

Jeffrey Yasskin
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.

On Fri, Mar 19, 2010 at 9:49 AM, Jeffrey Yasskin <[hidden email]> wrote:

> 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
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] 2.7 Pre-release1 available for testing

Tanya Lattner

On Mar 19, 2010, at 10:02 AM, Jeffrey Yasskin wrote:

> 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

> On Fri, Mar 19, 2010 at 9:49 AM, Jeffrey Yasskin <[hidden email]> wrote:
>> 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
>>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] 2.7 Pre-release1 available for testing

Russell Wallace
In reply to this post by Tanya Lattner
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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7 Pre-release1 available for testing

Tanya Lattner
In reply to this post by Tanya Lattner

On Mar 24, 2010, at 2:47 PM, Török Edwin wrote:

> On 03/17/2010 10:12 PM, Tanya Lattner wrote:
>> 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.
>>
>
> Hi Tanya,
>
> Attached are the nightly test results when run with llvm-gcc
> (report.nightly.txt), and when run with clang (clang-report.nightly.txt).
>

Thanks for testing the release!

> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3,
> 64-bit. I built srcdir == objdir, I have built llvm and clang myself,
> and used the binaries for llvm-gcc.
>
> 1. llvm-gcc 2.7 vs 2.6
> compared to my results from Aug 31 2009, ignoring CBE failures:
>
> new JIT failures:
> MultiSource/Applications/spiff/spiff
> SingleSource/Regression/C/2004-03-15-IndirectGoto
>

Yes, I'm seeing the second regression on darwin too. Please file a bug for the other one if you havent already.

> 2. llvm-gcc 2.7 vs clang 2.7
> When comparing the 2.7 llvm-gcc and clang results I see these
> differences (is llvm-gcc considered baseline for clang?):
> ALL FAIL (pass in llvm-gcc):
> MultiSource/Benchmarks/PAQ8p/paq8p
> MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
> MultiSource/Benchmarks/Prolangs-C/archie-client/archie
> MultiSource/Benchmarks/Prolangs-C/cdecl/cdecl
> SingleSource/Benchmarks/Misc-C++/bigfib
> SingleSource/Regression/C++/EH/ConditionalExpr
> SingleSource/Regression/C++/EH/ctor_dtor_count-2
> SingleSource/Regression/C++/EH/function_try_block
> SingleSource/Regression/C++/EH/simple_throw
> SingleSource/UnitTests/2006-12-04-DynAllocAndRestore
> SingleSource/UnitTests/Vector/SSE/sse.expandfft
> SingleSource/UnitTests/Vector/SSE/sse.stepfft
>
> JIT failures in clang, pass in llvm-gcc:
> MultiSource/Applications/sqlite3/sqlite3
> SingleSource/Regression/C++/ofstream_ctor
>

This isn't part of our release criteria. So, these are not release blockers.

> 3. Some performance regressions GCC/LLC  (2.6 -> 2.7), but keep in mind
> that I wasn't using GCC 4.4.3 as comparison for llvm 2.6!
>
> MultiSource/Applications/hexxagon/hexxagon  1.22 -> 1.14
> MultiSource/Applications/lua/lua  0.91 -> 0.84
> MultiSource/Applications/obsequi/Obsequi  0.93 -> 0.86
> MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/CrystalMk  1.01 -> 0.91
> MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow     0.94 -> 0.75
> MultiSource/Benchmarks/FreeBench/neural/neural   1.0 -> 0.9
> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm   1.06 -> 0.9
> MultiSource/Benchmarks/Olden/treeadd/treeadd  11.44 -> 9.89
> MultiSource/Benchmarks/Olden/tsp/tsp  1.14 -> 1.02
> MultiSource/Benchmarks/Ptrdist/anagram/anagram 1.33 -> 1.23
> SingleSource/Benchmarks/Dhrystone/dry  7.32 -> 5.16
> SingleSource/Benchmarks/Dhrystone/fldry   8.02 -> 6.65
> ....
>

Unfortunately, we just don't have enough man power to have performance be a release criteria at this time. We also need a better infrastructure in place to track this stuff (Daniel is working on it).

> I'll have to write a script to compare the results, its boring and
> inaccurate to do by hand.
>
> Will go through the bugzilla tomorrow and see if I need to open new bugs
> for this stuff.
>
>>
>>  /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)
>
> Surely you meant tools/clang-2.7
>

Yes.

> FYI I pulled the following revisions for ClamAV's llvm on top of 2.7:
> r98349
> r98410
> r98447
> r98508
> r99143
> r99146
> r99147
> r99160
> r99400
>
> I don't know if any of these qualify as regression fixes for 2.7, I'll
> leave it up to you to decide if you want to put them into 2.7 or not.
>

I'll have to discuss with Chris about these. Its technically not a release blocker.

Thanks,
-Tanya


> Best regards,
> --Edwin
> <report.nightly.txt><clang-report.nightly.txt>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7 Pre-release1 available for testing

Török Edwin
On 03/30/2010 09:15 PM, Tanya Lattner wrote:

>
> Thanks for testing the release!
>
>> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3,
>> 64-bit. I built srcdir == objdir, I have built llvm and clang myself,
>> and used the binaries for llvm-gcc.
>>
>> 1. llvm-gcc 2.7 vs 2.6
>> compared to my results from Aug 31 2009, ignoring CBE failures:
>>
>> new JIT failures:
>> MultiSource/Applications/spiff/spiff
>> SingleSource/Regression/C/2004-03-15-IndirectGoto
>>
>
> Yes, I'm seeing the second regression on darwin too. Please file a bug for the other one if you havent already.

I haven't, will do tomorrow.

>
>> 2. llvm-gcc 2.7 vs clang 2.7
>> When comparing the 2.7 llvm-gcc and clang results I see these
>> differences (is llvm-gcc considered baseline for clang?):
>> ALL FAIL (pass in llvm-gcc):
>> MultiSource/Benchmarks/PAQ8p/paq8p
>> MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
>> MultiSource/Benchmarks/Prolangs-C/archie-client/archie
>> MultiSource/Benchmarks/Prolangs-C/cdecl/cdecl
>> SingleSource/Benchmarks/Misc-C++/bigfib
>> SingleSource/Regression/C++/EH/ConditionalExpr
>> SingleSource/Regression/C++/EH/ctor_dtor_count-2
>> SingleSource/Regression/C++/EH/function_try_block
>> SingleSource/Regression/C++/EH/simple_throw
>> SingleSource/UnitTests/2006-12-04-DynAllocAndRestore
>> SingleSource/UnitTests/Vector/SSE/sse.expandfft
>> SingleSource/UnitTests/Vector/SSE/sse.stepfft
>>
>> JIT failures in clang, pass in llvm-gcc:
>> MultiSource/Applications/sqlite3/sqlite3
>> SingleSource/Regression/C++/ofstream_ctor
>>
>
> This isn't part of our release criteria. So, these are not release blockers.

Ok, something to keep in mind for LLVM 2.8 then.

>
>> 3. Some performance regressions GCC/LLC  (2.6 -> 2.7), but keep in mind
>> that I wasn't using GCC 4.4.3 as comparison for llvm 2.6!
>>
>> MultiSource/Applications/hexxagon/hexxagon  1.22 -> 1.14
>> MultiSource/Applications/lua/lua  0.91 -> 0.84
>> MultiSource/Applications/obsequi/Obsequi  0.93 -> 0.86
>> MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/CrystalMk  1.01 -> 0.91
>> MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow     0.94 -> 0.75
>> MultiSource/Benchmarks/FreeBench/neural/neural   1.0 -> 0.9
>> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm   1.06 -> 0.9
>> MultiSource/Benchmarks/Olden/treeadd/treeadd  11.44 -> 9.89
>> MultiSource/Benchmarks/Olden/tsp/tsp  1.14 -> 1.02
>> MultiSource/Benchmarks/Ptrdist/anagram/anagram 1.33 -> 1.23
>> SingleSource/Benchmarks/Dhrystone/dry  7.32 -> 5.16
>> SingleSource/Benchmarks/Dhrystone/fldry   8.02 -> 6.65
>> ....
>>
>
> Unfortunately, we just don't have enough man power to have performance be a release criteria at this time. We also need a better infrastructure in place to track this stuff (Daniel is working on it).

Yes, I understand that.

>
>> I'll have to write a script to compare the results, its boring and
>> inaccurate to do by hand.
>>
>> Will go through the bugzilla tomorrow

I still didn't have time to do this unfortunately.

>> and see if I need to open new bugs
>> for this stuff.
>>
>>>  /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)
>> Surely you meant tools/clang-2.7
>>
>
> Yes.
>
>> FYI I pulled the following revisions for ClamAV's llvm on top of 2.7:
>> r98349
>> r98410
>> r98447
>> r98508
>> r99143
>> r99146
>> r99147
>> r99160
>> r99400
>>
>> I don't know if any of these qualify as regression fixes for 2.7, I'll
>> leave it up to you to decide if you want to put them into 2.7 or not.
>>
>
> I'll have to discuss with Chris about these. Its technically not a release blocker.

Meanwhile I pulled these too:
99762 (Evan approved)
99883 (leakfix, so I don't think it qualifies for release criteria)

Best regards,
--Edwin
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev