First, thanks for testing this!> Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) > > HIGH LEVEL COMMENTS > * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't > that be llvm-1.9?We have always labeled the dir just llvm which is fine. If you build llvm it will know its version 1.9.> * LLVM was built in Release mode in all casesThats the default, so thats good.> * I don't think this is ready for release. In particular the llvm-gcc4 > binary > seg faults on FC 5 for most of llvm-test programs. > * I'm going to re-try without using the binaries and building > everything from scratch.Does llvm-gcc4 seg fault for make check? I've done extensive testing with llvm-gcc4 on x86 and did not have any problems with llvm-gcc4... so I am curious as to whats going on. If you could look into this, that would be great. Please triple check that you are using a clean llvm-test directory (ie. did not use llvm-gcc3 previously) and that the correct llvm-gcc is being used.> BUILD LLVM WITH GCC 4.1.1 20060525 (FAIL) > * DwarfWriter.cpp:2400: warning: overflow in implicit constant > conversion > Line looks like: EmitInt32(DW_CIE_ID); EOL("CIE Identifier > Tag"); > I don't know the code well enough to make a suggestion. > > The run of llvm-test failed about 50%, some didn't even compile. I > didn't bother > running the whole thing as it was clear that GCC 4.1.1 (still) > mis-compiles LLVM.We have noted in the Getting started guide that LLVM won't compile with gcc 4.1.1, so this is not a show stopper.> BUILD LLVM WITH GCC 3.4.6 WITH LLVM-GCC3 CONFIGURED (PASS) > * PASS: make, except these innocuous warnings from GCC 3.4.6 linker > (known 3.4.6 bug) > /proj/install/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' referenced in section `.rodata' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o): defined in discarded section `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o) >Right, thats fine.> * PASS: make install, except these doc linkage errors: > /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<ar(1)> in > paragraph 51. > /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<nm(1)> in > paragraph 51. > /usr/bin/pod2html: llvm-ar.pod: cannot resolve L<ar(1)> in > paragraph 114.Please file a bug for this. This isn't a show stopper though.> * PASS: make check, except: > > XPASS: /proj/llvm/rel1.9/llvm/test/Regression/CFrontend/2006-07-31-PR854.c > # of expected passes 1542 > # of unexpected successes 1 > # of expected failures 41 > > LLVM-TEST NIGHTLY WITH LLVM-GCC3 (FAIL)This all looks pretty normal for llvm-gcc3. There are no plans to fix llvm-gcc3 problems/regressions with llvm-test. So not a show stopper.> BUILD LLVM WITH LLVM-GCC4 CONFIGURED (PASS/FAIL) > * Configure failed to find llvm-gcc4 when the directory provided to > --with-llvmgccdir > was the llvm-gcc4-1.9-x86-linux directory unpacked from the tarball. > The 5-line > warning message at the end of configure run was produced. I don't > know what configure > is looking for, but its not finding it.Interesting. This must be a bug in the configure script. This probably should be fixed.> * FAIL: 'make' failed in runtime library. Althought the runtime > library isn't needed > with llvm-gcc4, it shouldn't fail to compile it: > make[3]: Entering directory > `/proj/llvm/rel1.9/llvm/runtime/GCCLibraries/crtend' > llvm[3]: Compiling crtend.c for Release build (bytecode) > crtend.c:16: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://llvm.org/bugs> for instructions. > * PASS: 'make tools-only'I'll have to defer to Chris on this and if its a show stopper. -Tanya> RUN LLVM-TEST WITH LLVM-GCC4 (FAIL) > * Most of the test (90%) fail compile with seg fault. > > PATH="/proj/llvm/rel1.9/llvm/Release/bin:/proj/install/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/reid/bin:/opt/j2sdk_1.4.2/j2sdk1.4.2/bin:/opt/oracle/bin" /proj/llvm/rel1.9/llvm-gcc4-1.9-x86-linux/bin/llvm-gcc -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm/include -I/proj/llvm/rel1.9/llvm-test/include -I../../../../include -I/proj/llvm/rel1.9/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__NO_MATH_INLINES -O2 -msse2 -msse2 -O0 -S sse.expandfft.c -o Output/sse.expandfft.ll -emit-llvm > sse.expandfft.c:268: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://llvm.org/bugs> for instructions. > make[5]: [Output/sse.expandfft.ll] Error 1 (ignored) > cp -f Output/sse.expandfft.ll Output/sse.expandfft.linked.rll > cp: cannot stat `Output/sse.expandfft.ll': No such file or directory > > > On Tue, 2006-11-14 at 09:49 -0800, Tanya M. Lattner wrote: >> LLVMers, >> >> The LLVM 1.9 Prerelease is available for testing: >> http://llvm.org/prereleases/1.9/ >> >> If anyone can spare some time, please download the appropriate tarballs >> for your platform and test the release (at least with make check). I'd >> also appreciate any documentation reviews. >> >> Please note that llvm-gcc3 on x86 may not have a clean dejagnu run. You >> should see one XPASS for Regression/CFrontend/2006-07-31-PR854.c. If you >> are getting different failures or unexpected passes, please let me know. >> All other platforms should be clean. >> >> If you find any problems, please email the list. I would appreciate this >> testing and documentation review to be completed by Friday, November 17th >> at 5:00PM PST. >> >> If you plan to contribute llvm-gcc4 binaries for another platform, please >> complete them by the deadline above as well or send me an email with your >> status. >> >> Thanks, >> Tanya Lattner >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Tanya, You asked some questions below. I don't know the answer. I'm in the middle of trying a compiler upgrade to 4.0.3 so I can't answer the questions right now. I'll try to get this all recompiled with 4.0.3 by COB tomorrow. Reid. On Thu, 2006-11-16 at 12:12 -0800, Tanya M. Lattner wrote:> First, thanks for testing this! > > > Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) > > > > HIGH LEVEL COMMENTS > > * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't > > that be llvm-1.9? > > We have always labeled the dir just llvm which is fine. If you build llvm > it will know its version 1.9. > > > * LLVM was built in Release mode in all cases > > Thats the default, so thats good. > > > * I don't think this is ready for release. In particular the llvm-gcc4 > > binary > > seg faults on FC 5 for most of llvm-test programs. > > * I'm going to re-try without using the binaries and building > > everything from scratch. > > Does llvm-gcc4 seg fault for make check? I've done extensive testing with > llvm-gcc4 on x86 and did not have any problems with llvm-gcc4... so I am > curious as to whats going on. If you could look into this, that would be > great. Please triple check that you are using a clean llvm-test directory > (ie. did not use llvm-gcc3 previously) and that the correct llvm-gcc is > being used. > > > BUILD LLVM WITH GCC 4.1.1 20060525 (FAIL) > > * DwarfWriter.cpp:2400: warning: overflow in implicit constant > > conversion > > Line looks like: EmitInt32(DW_CIE_ID); EOL("CIE Identifier > > Tag"); > > I don't know the code well enough to make a suggestion. > > > > The run of llvm-test failed about 50%, some didn't even compile. I > > didn't bother > > running the whole thing as it was clear that GCC 4.1.1 (still) > > mis-compiles LLVM. > > We have noted in the Getting started guide that LLVM won't compile with > gcc 4.1.1, so this is not a show stopper. > > > BUILD LLVM WITH GCC 3.4.6 WITH LLVM-GCC3 CONFIGURED (PASS) > > * PASS: make, except these innocuous warnings from GCC 3.4.6 linker > > (known 3.4.6 bug) > > /proj/install/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' referenced in section `.rodata' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o): defined in discarded section `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o) > > > > Right, thats fine. > > > * PASS: make install, except these doc linkage errors: > > /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<ar(1)> in > > paragraph 51. > > /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<nm(1)> in > > paragraph 51. > > /usr/bin/pod2html: llvm-ar.pod: cannot resolve L<ar(1)> in > > paragraph 114. > > Please file a bug for this. This isn't a show stopper though. > > > * PASS: make check, except: > > > > XPASS: /proj/llvm/rel1.9/llvm/test/Regression/CFrontend/2006-07-31-PR854.c > > # of expected passes 1542 > > # of unexpected successes 1 > > # of expected failures 41 > > > > LLVM-TEST NIGHTLY WITH LLVM-GCC3 (FAIL) > > This all looks pretty normal for llvm-gcc3. There are no plans to fix > llvm-gcc3 problems/regressions with llvm-test. So not a show stopper. > > > BUILD LLVM WITH LLVM-GCC4 CONFIGURED (PASS/FAIL) > > * Configure failed to find llvm-gcc4 when the directory provided to > > --with-llvmgccdir > > was the llvm-gcc4-1.9-x86-linux directory unpacked from the tarball. > > The 5-line > > warning message at the end of configure run was produced. I don't > > know what configure > > is looking for, but its not finding it. > > Interesting. This must be a bug in the configure script. This probably > should be fixed. > > > * FAIL: 'make' failed in runtime library. Althought the runtime > > library isn't needed > > with llvm-gcc4, it shouldn't fail to compile it: > > make[3]: Entering directory > > `/proj/llvm/rel1.9/llvm/runtime/GCCLibraries/crtend' > > llvm[3]: Compiling crtend.c for Release build (bytecode) > > crtend.c:16: internal compiler error: Segmentation fault > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See <URL:http://llvm.org/bugs> for instructions. > > * PASS: 'make tools-only' > > I'll have to defer to Chris on this and if its a show stopper. > > -Tanya > > > RUN LLVM-TEST WITH LLVM-GCC4 (FAIL) > > * Most of the test (90%) fail compile with seg fault. > > > > PATH="/proj/llvm/rel1.9/llvm/Release/bin:/proj/install/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/reid/bin:/opt/j2sdk_1.4.2/j2sdk1.4.2/bin:/opt/oracle/bin" /proj/llvm/rel1.9/llvm-gcc4-1.9-x86-linux/bin/llvm-gcc -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm/include -I/proj/llvm/rel1.9/llvm-test/include -I../../../../include -I/proj/llvm/rel1.9/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__NO_MATH_INLINES -O2 -msse2 -msse2 -O0 -S sse.expandfft.c -o Output/sse.expandfft.ll -emit-llvm > > sse.expandfft.c:268: internal compiler error: Segmentation fault > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See <URL:http://llvm.org/bugs> for instructions. > > make[5]: [Output/sse.expandfft.ll] Error 1 (ignored) > > cp -f Output/sse.expandfft.ll Output/sse.expandfft.linked.rll > > cp: cannot stat `Output/sse.expandfft.ll': No such file or directory > > > > > > On Tue, 2006-11-14 at 09:49 -0800, Tanya M. Lattner wrote: > >> LLVMers, > >> > >> The LLVM 1.9 Prerelease is available for testing: > >> http://llvm.org/prereleases/1.9/ > >> > >> If anyone can spare some time, please download the appropriate tarballs > >> for your platform and test the release (at least with make check). I'd > >> also appreciate any documentation reviews. > >> > >> Please note that llvm-gcc3 on x86 may not have a clean dejagnu run. You > >> should see one XPASS for Regression/CFrontend/2006-07-31-PR854.c. If you > >> are getting different failures or unexpected passes, please let me know. > >> All other platforms should be clean. > >> > >> If you find any problems, please email the list. I would appreciate this > >> testing and documentation review to be completed by Friday, November 17th > >> at 5:00PM PST. > >> > >> If you plan to contribute llvm-gcc4 binaries for another platform, please > >> complete them by the deadline above as well or send me an email with your > >> status. > >> > >> Thanks, > >> Tanya Lattner > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, 16 Nov 2006, Tanya M. Lattner wrote:>> * I don't think this is ready for release. In particular the llvm-gcc4 >> binary >> seg faults on FC 5 for most of llvm-test programs. >> * I'm going to re-try without using the binaries and building >> everything from scratch. > > Does llvm-gcc4 seg fault for make check? I've done extensive testing with > llvm-gcc4 on x86 and did not have any problems with llvm-gcc4... so I am > curious as to whats going on. If you could look into this, that would be > great. Please triple check that you are using a clean llvm-test directory > (ie. did not use llvm-gcc3 previously) and that the correct llvm-gcc is > being used.This is also quite possibly a problem with llvm-gcc being built on a non-FC5 machine and pulling in different libraries. This is why binary distros on linux doesn't usually work very well. If so, there really isn't anything we can do about this, other than labeling the binary with the linux version it was built on.>> BUILD LLVM WITH LLVM-GCC4 CONFIGURED (PASS/FAIL) >> * Configure failed to find llvm-gcc4 when the directory provided to >> --with-llvmgccdir >> was the llvm-gcc4-1.9-x86-linux directory unpacked from the tarball. >> The 5-line >> warning message at the end of configure run was produced. I don't >> know what configure >> is looking for, but its not finding it. > > Interesting. This must be a bug in the configure script. This probably > should be fixed.Reid, are you sure you passed the current directory to the configure script?>> * FAIL: 'make' failed in runtime library. Althought the runtime >> library isn't needed >> with llvm-gcc4, it shouldn't fail to compile it: >> make[3]: Entering directory >> `/proj/llvm/rel1.9/llvm/runtime/GCCLibraries/crtend' >> llvm[3]: Compiling crtend.c for Release build (bytecode) >> crtend.c:16: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See <URL:http://llvm.org/bugs> for instructions. >> * PASS: 'make tools-only' > > I'll have to defer to Chris on this and if its a show stopper.Something is wrong with your configuration, probably related to not finding llvmgcc4 right. You should get this message: llvm[0]: Warning: These runtime libraries only need to be built with llvm[0]: Warning: llvm-gcc version 3. They are automatically included llvm[0]: Warning: with llvm-gcc version 4 and beyond if you try to build in llvm/runtime.>> * Most of the test (90%) fail compile with seg fault. >> >> PATH="/proj/llvm/rel1.9/llvm/Release/bin:/proj/install/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/reid/bin:/opt/j2sdk_1.4.2/j2sdk1.4.2/bin:/opt/oracle/bin" /proj/llvm/rel1.9/llvm-gcc4-1.9-x86-linux/bin/llvm-gcc -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm/include -I/proj/llvm/rel1.9/llvm-test/include -I../../../../include -I/proj/llvm/rel1.9/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__NO_MATH_INLINES -O2 -msse2 -msse2 -O0 -S sse.expandfft.c -o Output/sse.expandfft.ll -emit-llvm >> sse.expandfft.c:268: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate.It's not clear to me if this is with the binary distro of llvm-gcc4 (which is apparently incompatible with your system) or with one you built yourself... -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Thu, 2006-11-16 at 13:49 -0800, Chris Lattner wrote:> On Thu, 16 Nov 2006, Tanya M. Lattner wrote: > >> * I don't think this is ready for release. In particular the llvm-gcc4 > >> binary > >> seg faults on FC 5 for most of llvm-test programs. > >> * I'm going to re-try without using the binaries and building > >> everything from scratch. > > > > Does llvm-gcc4 seg fault for make check? I've done extensive testing with > > llvm-gcc4 on x86 and did not have any problems with llvm-gcc4... so I am > > curious as to whats going on. If you could look into this, that would be > > great. Please triple check that you are using a clean llvm-test directory > > (ie. did not use llvm-gcc3 previously) and that the correct llvm-gcc is > > being used. > > This is also quite possibly a problem with llvm-gcc being built on a > non-FC5 machine and pulling in different libraries. This is why binary > distros on linux doesn't usually work very well. If so, there really > isn't anything we can do about this, other than labeling the binary with > the linux version it was built on.Perhaps. That's why I'm going to build llvm-gcc from the sources.> > >> BUILD LLVM WITH LLVM-GCC4 CONFIGURED (PASS/FAIL) > >> * Configure failed to find llvm-gcc4 when the directory provided to > >> --with-llvmgccdir > >> was the llvm-gcc4-1.9-x86-linux directory unpacked from the tarball. > >> The 5-line > >> warning message at the end of configure run was produced. I don't > >> know what configure > >> is looking for, but its not finding it. > > > > Interesting. This must be a bug in the configure script. This probably > > should be fixed. > > Reid, are you sure you passed the current directory to the configure > script?Yup. Did it several times. Same result.> > >> * FAIL: 'make' failed in runtime library. Althought the runtime > >> library isn't needed > >> with llvm-gcc4, it shouldn't fail to compile it: > >> make[3]: Entering directory > >> `/proj/llvm/rel1.9/llvm/runtime/GCCLibraries/crtend' > >> llvm[3]: Compiling crtend.c for Release build (bytecode) > >> crtend.c:16: internal compiler error: Segmentation fault > >> Please submit a full bug report, > >> with preprocessed source if appropriate. > >> See <URL:http://llvm.org/bugs> for instructions. > >> * PASS: 'make tools-only' > > > > I'll have to defer to Chris on this and if its a show stopper. > > Something is wrong with your configuration, probably related to not > finding llvmgcc4 right. You should get this message: > > llvm[0]: Warning: These runtime libraries only need to be built with > llvm[0]: Warning: llvm-gcc version 3. They are automatically included > llvm[0]: Warning: with llvm-gcc version 4 and beyondRight.> > if you try to build in llvm/runtime. > > >> * Most of the test (90%) fail compile with seg fault. > >> > >> PATH="/proj/llvm/rel1.9/llvm/Release/bin:/proj/install/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/reid/bin:/opt/j2sdk_1.4.2/j2sdk1.4.2/bin:/opt/oracle/bin" /proj/llvm/rel1.9/llvm-gcc4-1.9-x86-linux/bin/llvm-gcc -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm/include -I/proj/llvm/rel1.9/llvm-test/include -I../../../../include -I/proj/llvm/rel1.9/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__NO_MATH_INLINES -O2 -msse2 -msse2 -O0 -S sse.expandfft.c -o Output/sse.expandfft.ll -emit-llvm > >> sse.expandfft.c:268: internal compiler error: Segmentation fault > >> Please submit a full bug report, > >> with preprocessed source if appropriate. > > It's not clear to me if this is with the binary distro of llvm-gcc4 (which > is apparently incompatible with your system) or with one you built > yourself...Binary distro. As I said, I'm going to rebuild from source, possibly with 4.0.3 and retry everything.> > -Chris >
Hi Tanya,> > * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't > > that be llvm-1.9? > > We have always labeled the dir just llvm which is fine. If you build > llvm it will know its version 1.9.I think that's missing the point. Convention is the foo-4.2.tar unpacks to a directory called foo-4.2. It's a unwelcome surprise when it doesn't, e.g. unpacking foo-4.1.tar and foo-4.2.tar in the same directory for comparision, or worse unpacking foo-4.1.tar alongside your llvm work directory. Sure, it can be worked around, but even the Linux kernel followed this convention in the end. Please consider it for the future. Cheers, Ralph.
>>> * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't >>> that be llvm-1.9? >> >> We have always labeled the dir just llvm which is fine. If you build >> llvm it will know its version 1.9. > > I think that's missing the point. Convention is the foo-4.2.tar unpacks > to a directory called foo-4.2. It's a unwelcome surprise when it > doesn't, e.g. unpacking foo-4.1.tar and foo-4.2.tar in the same > directory for comparision, or worse unpacking foo-4.1.tar alongside your > llvm work directory.No its not. While this may be convention for other projects it has not been for llvm. Therefore, people expect llvm to untar into an llvm directory. All the docs are also written as such.> Sure, it can be worked around, but even the Linux kernel followed this > convention in the end. Please consider it for the future.Since there seems to be a moving opinion towards renaming it and I personally don't care. It will be done. -Tanya