Dear All,
I've created the LLVM release branch (CVS tag release_16).
Those developers wanting to commit changes to LLVM without having your changes go into LLVM 1.6 can now commit to CVS mainline to your heart's content.
TESTING:
1. I'm still looking for volunteers to test MacOS X and Solaris. If you'd like to volunteer, please email the list to let us know.
I'll do minimal testing on Sparc. I'm not going to look into any regressions though since no one has been really watching Sparc since I graduated and I am sure there are regressions.
2. If you maintain a platform other than those listed above, you will want to test the release branch for regressions. A regression is anything that worked on your platform in LLVM 1.5 that doesn't work in the release branch.
I looked at the llvm-dev archives and it seems the branch was created on May 13th. So we should look at May 14th nightly tester results as a baseline?
I'd prefer not to download the 1.5, compile, and run all tests with that.
We should keep around testing results for each platform for each release in the future. That would make this sorta thing easier.
-Tanya
Tanya Lattner wrote:
1. I'm still looking for volunteers to test MacOS X and Solaris. If you'd like to volunteer, please email the list to let us know.
I'll do minimal testing on Sparc. I'm not going to look into any regressions though since no one has been really watching Sparc since I graduated and I am sure there are regressions.
Thanks!
2. If you maintain a platform other than those listed above, you will want to test the release branch for regressions. A regression is anything that worked on your platform in LLVM 1.5 that doesn't work in the release branch.
I looked at the llvm-dev archives and it seems the branch was created on May 13th. So we should look at May 14th nightly tester results as a baseline?
Yes, looking at the results from May 14 (or thereabouts) is fine. That's what I've done for previous releases.
I'd prefer not to download the 1.5, compile, and run all tests with that.
We should keep around testing results for each platform for each release in the future. That would make this sorta thing easier.
An XFAIL feature for the llvm-test module would be even better, but none of us have been interested enough to add it yet. Maybe someday.
-Tanya
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- John T.
I can try to test on MacOS X.
-bw
Bill Wendling wrote:
1. I'm still looking for volunteers to test MacOS X and Solaris. If you'd
like to volunteer, please email the list to let us know.I can try to test on MacOS X.
Thanks, Bill!
-bw
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- John T.
Everything builds fine on sparc. The configure script needs to be fixed though (see previous email).
Sparc testing results:
make check:
# of expected passes 1189
# of expected failures 34
Regressions Single Source:
None
New Failures Single Source (new tests):
2005-05-12-Int64ToFP: llc,jit
Regressions MultiSource:
Applications/d/make_dparser: llc, cbe, jit
Applications/hexxagon/hexxagon: llc, cbe, jit
Benchmarks/MallocBench/gs/gs: llc, cbe
Benchmarks/Prolangs-C/cdecl/cdecl: llc, cbe, jit
Benchmarks/Prolangs-C/football/football: cbe
Benchmarks/Prolangs-C/gnugo/gnugo: llc, cbe, jit
Benchmarks/Prolangs-C/agrep/agrep: llc
Benchmarks/Prolangs-C/fixoutput/fixoutput: llc, cbe
Benchmarks/Prolangs-C/gnugo/gnugo: llc, cbe, jit (looks like ld hung)
Benchmarks/mediabench/gsm/toast/toast: llc
Benchmarks/mediabench/jpeg/jpeg-6a/cjpeg: jit
Benchmarks/mediabench/mpeg2/mpeg2dec/mpeg2decode: llc, cbe, jit
Regressions External:
SPEC/CFP2000/177.mesa/177.mesa: cbe
SPEC/CINT2000/175.vpr/175.vpr: llc, cbe
-Tanya
Tanya Lattner wrote:
Everything builds fine on sparc. The configure script needs to be fixed though (see previous email).
I'm not getting the error with the configure script (on Kain, anyway). I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my $PATH.
Can you verify that the configure script works for you without the --with-f2c option? If it does, I think we'll just file a bug report and fix it in 1.7.
As for the regressions below, it would be nice to get them fixed before the release, but I'm not sure if anybody has time to look into it. If nobody has time, we'll probably ship it as is.
I've tried out a few programs: hexxagon is an XFAIL (Solaris doesn't have stdint.h), and make_dparser is genuinely broken (even with Chris's llvm-gcc fix). Some of the Prolangs-C tests are working now, probably due to Chris's fix, so Sparc is probaby in better shape than it looks.
If you want to try out the new CFE, just re-download it using the same directions I gave before. The new one is built and ready to go.
-- John T.
Tanya Lattner wrote:
Everything builds fine on sparc. The configure script needs to be fixed though (see previous email).
I'm not getting the error with the configure script (on Kain, anyway). I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my $PATH.
Can you verify that the configure script works for you without the --with-f2c option? If it does, I think we'll just file a bug report and fix it in 1.7.
Did you try with plain old bourne shell? I agree that filing a bug and adding a note about it to the release notes is fine. However, Reid mentioned that it should be trivial to fix for someone with configure experience... 
As for the regressions below, it would be nice to get them fixed before the release, but I'm not sure if anybody has time to look into it. If nobody has time, we'll probably ship it as is.
I think that shipping with them is fine. Unfortunately, until Sparc has a platform maintainer/champion, it will continue to suffer. If people are interested in Sparc, fixing bugs at the beginning of the 1.7 cycle would make sense.
What is left before 1.6 can ship?
Thanks John and Tanya!
-Chris
Everything builds fine on sparc. The configure script needs to be fixed though (see previous email).
I'm not getting the error with the configure script (on Kain, anyway). I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my $PATH.
I get the error with and without the --with-f2c option. I never used the NAG Fotran option. It works fine if I specifically use bash.
Can you verify that the configure script works for you without the --with-f2c option? If it does, I think we'll just file a bug report and fix it in 1.7.
It should have a bug filed. I can do that later or if you want to do it now.. thats fine.
As for the regressions below, it would be nice to get them fixed before the release, but I'm not sure if anybody has time to look into it. If nobody has time, we'll probably ship it as is.
Sorry, I don't have time to do this unless time == a month or more.
I've tried out a few programs: hexxagon is an XFAIL (Solaris doesn't have stdint.h), and make_dparser is genuinely broken (even with Chris's llvm-gcc fix). Some of the Prolangs-C tests are working now, probably due to Chris's fix, so Sparc is probaby in better shape than it looks.
I am pretty sure hexxagon worked at one point.. but it doesnt matter.
If you want to try out the new CFE, just re-download it using the same directions I gave before. The new one is built and ready to go.
Unless someone is going to actively fix these.. then I will, but I dont think anyone has spare cycles. It will take me another day to get the results if you want them.
-Tanya
Chris Lattner wrote:
Tanya Lattner wrote:
Everything builds fine on sparc. The configure script needs to be fixed though (see previous email).
I'm not getting the error with the configure script (on Kain, anyway). I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my $PATH.
Can you verify that the configure script works for you without the --with-f2c option? If it does, I think we'll just file a bug report and fix it in 1.7.
Did you try with plain old bourne shell? I agree that filing a bug and adding a note about it to the release notes is fine. However, Reid mentioned that it should be trivial to fix for someone with configure experience...
Yes, I've tried running it with Borne shell directly, with f2c in and out of my $PATH, and f95 in and out of my $PATH. While I haven't tried all possible combinations, I've tried enough of them that I suspect that either Tanya doesn't have the right tree (unlikely) or that something in her environment variables is causing configure to act differently (more likely).
As for the regressions below, it would be nice to get them fixed before the release, but I'm not sure if anybody has time to look into it. If nobody has time, we'll probably ship it as is.
I think that shipping with them is fine. Unfortunately, until Sparc has a platform maintainer/champion, it will continue to suffer. If people are interested in Sparc, fixing bugs at the beginning of the 1.7 cycle would make sense.
Agreed. No one has time to fix these.
What is left before 1.6 can ship?
The following:
1) Determine if Sparc llvm-test can configure with the f2c problem. If it can, we file a bug. If it can't, we fix it.
2) Any regressions that you want to fix in PPC. If you're done, please let me know.
Otherwise, I think that's everything.
Thanks John and Tanya!
And Bill!
-Chris
-- John T.
The following:
1) Determine if Sparc llvm-test can configure with the f2c problem. If it can, we file a bug. If it can't, we fix it.
Makes sense.
2) Any regressions that you want to fix in PPC. If you're done, please let me know.
PPC is good to go.
Otherwise, I think that's everything.
Great!
Thanks John and Tanya!
And Bill!
Yes, thanks Bill! Also, everyone who contributed doc patches and all the great code that made it into the release!
-Chris
Tanya Lattner wrote:
Everything builds fine on sparc. The configure script needs to be fixed though (see previous email).
I'm not getting the error with the configure script (on Kain, anyway). I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my $PATH.
I get the error with and without the --with-f2c option. I never used the NAG Fotran option. It works fine if I specifically use bash.
Can you do a "cvs status configure" on your llvm-test configure script and make sure the sticky tag is release_16?
Also, does the configure process halt? Or does it just give an error and keep going?
Can you verify that the configure script works for you without the --with-f2c option? If it does, I think we'll just file a bug report and fix it in 1.7.
It should have a bug filed. I can do that later or if you want to do it now.. thats fine.
As for the regressions below, it would be nice to get them fixed before the release, but I'm not sure if anybody has time to look into it. If nobody has time, we'll probably ship it as is.
Sorry, I don't have time to do this unless time == a month or more.
I've tried out a few programs: hexxagon is an XFAIL (Solaris doesn't have stdint.h), and make_dparser is genuinely broken (even with Chris's llvm-gcc fix). Some of the Prolangs-C tests are working now, probably due to Chris's fix, so Sparc is probaby in better shape than it looks.
I am pretty sure hexxagon worked at one point.. but it doesnt matter.
If you want to try out the new CFE, just re-download it using the same directions I gave before. The new one is built and ready to go.
Unless someone is going to actively fix these.. then I will, but I dont think anyone has spare cycles. It will take me another day to get the results if you want them.
No, no more testing is needed at this point. I think we just need to nail down whether the configure bug is going to be a problem if somebody uses 1.6 on Sparc.
-- John T.
I get the error with and without the --with-f2c option. I never used the NAG Fotran option. It works fine if I specifically use bash.
Can you do a "cvs status configure" on your llvm-test configure script and make sure the sticky tag is release_16?
[seraph llvm-test]$ cvs status configure