Dimitry Andric via llvm-dev
2015-Aug-22 16:54 UTC
[llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
The problem seems to be caused by the way the symlinks are setup in test-release.sh, e.g. like so: llvm.src/tools/clang -> ../../cfe.src cfe.src/tools/extra -> ../../clang-tools-extra.src When it then tries to access the path llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, it fails. I tried this on both FreeBSD, OSX and Linux, but it fails everywhere. For example, on Linux: $ ls -l ~/foo/llvm.src/tools/clang lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16 /home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/ $ ls -l ~/foo/cfe.src/tools/extra lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04 /home/dim/foo/cfe.src/tools/extra -> ../../clang-tools-extra.src/ $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling total 16 -rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp -rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include ls: cannot access /home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include: No such file or directory Note that llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. goes back to the top level, where *.src is checked out: $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. total 12 drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/ drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/ drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/ Of course at a level even below that, there is little chance of an include directory existing. How does anybody else manage to build using the test-release.sh script, and having clang-tools-extra? -Dimitry> On 21 Aug 2015, at 14:09, Dimitry Andric via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): > > . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 > tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 > tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 > > I'll investigate, because it would be nice to have those tools. > > -Dimitry > >> On 21 Aug 2015, at 13:42, Nikola Smiljanic <popizdeh at gmail.com> wrote: >> >> Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. >> >> On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: >> Hm, it does not seem to compile at all here? The build ends with: >> >> In file included from /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17: >> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10: fatal error: 'clang/Tooling/Refactoring.h' file not found >> #include "clang/Tooling/Refactoring.h" >> ^ >> 1 error generated. >> >> Any idea? I had no problems at all with -rc2. >> >> -Dimitry >> >>> On 21 Aug 2015, at 02:51, Hans Wennborg <hans at chromium.org> wrote: >>> >>> Hello everyone, >>> >>> 3.7-rc3 has just been tagged. Testers, please test, build binaries, >>> upload to the sftp and report results to this thread. >>> >>> Again, a lot of patches got merged between rc2 and rc3, but hopefully >>> nothing that should upset things. >>> >>> One thing that did change is that the release script now correctly >>> symlinks clang-tools-extra into the build. If this causes problems on >>> your platform, please just remove it. >>> >>> This is a release candidate in the real sense: at this point I have >>> zero release blockers on my radar. I will now only accept fixes for >>> critical regressions, and if nothing comes up, rc3 will be promoted to >>> 3.7.0-final. >>> >>> Documentation and release note patches are still welcome all the way >>> up until the final tag goes in. >>> >>> Issues that were on my radar, but I don't consider blocking: >>> >>> - Sanitizer test failures on various platforms, e.g. PR24222. We never >>> ran these tests in previous releases, so it's not a regression. It >>> would be great if the sanitizer folks could look into the test >>> failures, but it's not blocking 3.7. >>> >>> - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in >>> __cxa_allocate_exception", Renato will exclude libc++ from his build >>> for now. >>> >>> - Lack of key functions in some Instruction classes causing build >>> failures without -fno-rtti >>> (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No >>> patches have been forthcoming, so this will not get fixed for 3.7. At >>> least we correctly report -fno-rtti in llvm-config built with CMake >>> now. >>> >>> - r244221: "[SPARC] Don't compare arch name as a string, use the enum >>> instead", owner is unresponsive. >>> >>> - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return >>> types in SysV-mips [32 bit] ABI", owner is unresponsive. >>> >>> >>> Cheers, >>> Hans >> >> > > _______________________________________________ > lldb-dev mailing list > lldb-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150822/80989b0f/attachment.sig>
Dimitry Andric via llvm-dev
2015-Aug-22 19:23 UTC
[llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
It's building with this patch now, already at Phase3, so it seems to work:
Index: trunk/utils/release/test-release.sh
==================================================================---
trunk/utils/release/test-release.sh (revision 245679)
+++ trunk/utils/release/test-release.sh (working copy)
@@ -266,43 +268,36 @@
check_valid_urls
for proj in $projects ; do
- if [ -d $proj.src ]; then
- echo "# Reusing $proj $Release-$RC sources"
+ case $proj in
+ llvm|openmp)
+ projsrc=$proj.src
+ ;;
+ cfe)
+ projsrc=llvm.src/tools/clang
+ ;;
+ clang-tools-extra)
+ projsrc=llvm.src/tools/clang/tools/extra
+ ;;
+ compiler-rt|libcxx|libcxxabi|libunwind|test-suite)
+ projsrc=llvm.src/projects/$proj
+ ;;
+ *)
+ echo "error: unknown project $proj"
+ exit 1
+ ;;
+ esac
+
+ if [ -d $projsrc ]; then
+ echo "# Reusing $proj $Release-$RC sources in $projsrc"
continue
fi
- echo "# Exporting $proj $Release-$RC sources"
- if ! svn export -q $Base_url/$proj/$ExportBranch $proj.src ; then
+ echo "# Exporting $proj $Release-$RC sources to $projsrc"
+ if ! svn export -q $Base_url/$proj/$ExportBranch $projsrc ; then
echo "error: failed to export $proj project"
exit 1
fi
done
- echo "# Creating symlinks"
- cd $BuildDir/llvm.src/tools
- if [ ! -h clang ]; then
- ln -s ../../cfe.src clang
- fi
- cd $BuildDir/cfe.src/tools
- if [ ! -h extra ]; then
- ln -s ../../clang-tools-extra.src extra
- fi
- cd $BuildDir/llvm.src/projects
- if [ -d $BuildDir/test-suite.src ] && [ ! -h test-suite ]; then
- ln -s ../../test-suite.src test-suite
- fi
- if [ -d $BuildDir/compiler-rt.src ] && [ ! -h compiler-rt ]; then
- ln -s ../../compiler-rt.src compiler-rt
- fi
- if [ -d $BuildDir/libcxx.src ] && [ ! -h libcxx ]; then
- ln -s ../../libcxx.src libcxx
- fi
- if [ -d $BuildDir/libcxxabi.src ] && [ ! -h libcxxabi ]; then
- ln -s ../../libcxxabi.src libcxxabi
- fi
- if [ -d $BuildDir/libunwind.src ] && [ ! -h libunwind ]; then
- ln -s ../../libunwind.src libunwind
- fi
-
cd $BuildDir
}
-Dimitry
> On 22 Aug 2015, at 18:54, Dimitry Andric via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
> The problem seems to be caused by the way the symlinks are setup in
test-release.sh, e.g. like so:
>
> llvm.src/tools/clang -> ../../cfe.src
> cfe.src/tools/extra -> ../../clang-tools-extra.src
>
> When it then tries to access the path
llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include,
it fails. I tried this on both FreeBSD, OSX and Linux, but it fails everywhere.
>
> For example, on Linux:
>
> $ ls -l ~/foo/llvm.src/tools/clang
> lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16
/home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/
> $ ls -l ~/foo/cfe.src/tools/extra
> lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04
/home/dim/foo/cfe.src/tools/extra -> ../../clang-tools-extra.src/
> $ ls -l
~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling
> total 16
> -rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp
> -rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile
> $ ls -l
~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include
> ls: cannot access
/home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include:
No such file or directory
>
> Note that
llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../..
goes back to the top level, where *.src is checked out:
>
> $ ls -l
~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../..
> total 12
> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/
> drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/
> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/
>
> Of course at a level even below that, there is little chance of an include
directory existing. How does anybody else manage to build using the
test-release.sh script, and having clang-tools-extra?
>
> -Dimitry
>
>> On 21 Aug 2015, at 14:09, Dimitry Andric via lldb-dev <lldb-dev at
lists.llvm.org> wrote:
>>
>> Strangely, the clang-tools-extra stuff does build if I manually check
it out like so (without any symlinks):
>>
>> . <--
https://llvm.org/svn/llvm-project/llvm/branches/release_37
>> tools/clang <--
https://llvm.org/svn/llvm-project/cfe/branches/release_37
>> tools/clang/tools/extra <--
https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37
>>
>> I'll investigate, because it would be nice to have those tools.
>>
>> -Dimitry
>>
>>> On 21 Aug 2015, at 13:42, Nikola Smiljanic <popizdeh at
gmail.com> wrote:
>>>
>>> Hi Dmitry, if I understood Hans clang-extra wasn't part of the
build prior to rc3. Just delete it and run script with --no-checkout.
>>>
>>> On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at
andric.com> wrote:
>>> Hm, it does not seem to compile at all here? The build ends with:
>>>
>>> In file included from
/home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17:
>>>
/home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10:
fatal error: 'clang/Tooling/Refactoring.h' file not found
>>> #include "clang/Tooling/Refactoring.h"
>>> ^
>>> 1 error generated.
>>>
>>> Any idea? I had no problems at all with -rc2.
>>>
>>> -Dimitry
>>>
>>>> On 21 Aug 2015, at 02:51, Hans Wennborg <hans at
chromium.org> wrote:
>>>>
>>>> Hello everyone,
>>>>
>>>> 3.7-rc3 has just been tagged. Testers, please test, build
binaries,
>>>> upload to the sftp and report results to this thread.
>>>>
>>>> Again, a lot of patches got merged between rc2 and rc3, but
hopefully
>>>> nothing that should upset things.
>>>>
>>>> One thing that did change is that the release script now
correctly
>>>> symlinks clang-tools-extra into the build. If this causes
problems on
>>>> your platform, please just remove it.
>>>>
>>>> This is a release candidate in the real sense: at this point I
have
>>>> zero release blockers on my radar. I will now only accept fixes
for
>>>> critical regressions, and if nothing comes up, rc3 will be
promoted to
>>>> 3.7.0-final.
>>>>
>>>> Documentation and release note patches are still welcome all
the way
>>>> up until the final tag goes in.
>>>>
>>>> Issues that were on my radar, but I don't consider
blocking:
>>>>
>>>> - Sanitizer test failures on various platforms, e.g. PR24222.
We never
>>>> ran these tests in previous releases, so it's not a
regression. It
>>>> would be great if the sanitizer folks could look into the test
>>>> failures, but it's not blocking 3.7.
>>>>
>>>> - PR24273: "[ARM] Libc++abi built in-tree with libunwind
fails in
>>>> __cxa_allocate_exception", Renato will exclude libc++ from
his build
>>>> for now.
>>>>
>>>> - Lack of key functions in some Instruction classes causing
build
>>>> failures without -fno-rtti
>>>>
(http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No
>>>> patches have been forthcoming, so this will not get fixed for
3.7. At
>>>> least we correctly report -fno-rtti in llvm-config built with
CMake
>>>> now.
>>>>
>>>> - r244221: "[SPARC] Don't compare arch name as a
string, use the enum
>>>> instead", owner is unresponsive.
>>>>
>>>> - "[lldb] r245020 - [MIPS]Handle floating point and
aggregate return
>>>> types in SysV-mips [32 bit] ABI", owner is unresponsive.
>>>>
>>>>
>>>> Cheers,
>>>> Hans
>>>
>>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150822/97f28ef3/attachment.sig>
Dimitry Andric via llvm-dev
2015-Aug-22 23:13 UTC
[llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Still no complete go, doing the tests on i386 failed with some weird sed error: [...] Making Unit/lit.site.cfg for Clang extra tools... sed: lit.tmp: No such file or directory Makefile:61: recipe for target 'Unit/lit.site.cfg' failed gmake[2]: *** [Unit/lit.site.cfg] Error 1 Strangely enough, this does not happen on amd64. Maybe it is some sort of race condition? Did anybody see this too? Back to the investigation again... :( -Dimitry> On 22 Aug 2015, at 21:23, Dimitry Andric via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It's building with this patch now, already at Phase3, so it seems to work: > > Index: trunk/utils/release/test-release.sh > ==================================================================> --- trunk/utils/release/test-release.sh (revision 245679) > +++ trunk/utils/release/test-release.sh (working copy) > @@ -266,43 +268,36 @@ > check_valid_urls > > for proj in $projects ; do > - if [ -d $proj.src ]; then > - echo "# Reusing $proj $Release-$RC sources" > + case $proj in > + llvm|openmp) > + projsrc=$proj.src > + ;; > + cfe) > + projsrc=llvm.src/tools/clang > + ;; > + clang-tools-extra) > + projsrc=llvm.src/tools/clang/tools/extra > + ;; > + compiler-rt|libcxx|libcxxabi|libunwind|test-suite) > + projsrc=llvm.src/projects/$proj > + ;; > + *) > + echo "error: unknown project $proj" > + exit 1 > + ;; > + esac > + > + if [ -d $projsrc ]; then > + echo "# Reusing $proj $Release-$RC sources in $projsrc" > continue > fi > - echo "# Exporting $proj $Release-$RC sources" > - if ! svn export -q $Base_url/$proj/$ExportBranch $proj.src ; then > + echo "# Exporting $proj $Release-$RC sources to $projsrc" > + if ! svn export -q $Base_url/$proj/$ExportBranch $projsrc ; then > echo "error: failed to export $proj project" > exit 1 > fi > done > > - echo "# Creating symlinks" > - cd $BuildDir/llvm.src/tools > - if [ ! -h clang ]; then > - ln -s ../../cfe.src clang > - fi > - cd $BuildDir/cfe.src/tools > - if [ ! -h extra ]; then > - ln -s ../../clang-tools-extra.src extra > - fi > - cd $BuildDir/llvm.src/projects > - if [ -d $BuildDir/test-suite.src ] && [ ! -h test-suite ]; then > - ln -s ../../test-suite.src test-suite > - fi > - if [ -d $BuildDir/compiler-rt.src ] && [ ! -h compiler-rt ]; then > - ln -s ../../compiler-rt.src compiler-rt > - fi > - if [ -d $BuildDir/libcxx.src ] && [ ! -h libcxx ]; then > - ln -s ../../libcxx.src libcxx > - fi > - if [ -d $BuildDir/libcxxabi.src ] && [ ! -h libcxxabi ]; then > - ln -s ../../libcxxabi.src libcxxabi > - fi > - if [ -d $BuildDir/libunwind.src ] && [ ! -h libunwind ]; then > - ln -s ../../libunwind.src libunwind > - fi > - > cd $BuildDir > } > > -Dimitry > >> On 22 Aug 2015, at 18:54, Dimitry Andric via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> The problem seems to be caused by the way the symlinks are setup in test-release.sh, e.g. like so: >> >> llvm.src/tools/clang -> ../../cfe.src >> cfe.src/tools/extra -> ../../clang-tools-extra.src >> >> When it then tries to access the path llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, it fails. I tried this on both FreeBSD, OSX and Linux, but it fails everywhere. >> >> For example, on Linux: >> >> $ ls -l ~/foo/llvm.src/tools/clang >> lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16 /home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/ >> $ ls -l ~/foo/cfe.src/tools/extra >> lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04 /home/dim/foo/cfe.src/tools/extra -> ../../clang-tools-extra.src/ >> $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling >> total 16 >> -rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp >> -rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile >> $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include >> ls: cannot access /home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include: No such file or directory >> >> Note that llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. goes back to the top level, where *.src is checked out: >> >> $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. >> total 12 >> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/ >> drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/ >> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/ >> >> Of course at a level even below that, there is little chance of an include directory existing. How does anybody else manage to build using the test-release.sh script, and having clang-tools-extra? >> >> -Dimitry >> >>> On 21 Aug 2015, at 14:09, Dimitry Andric via lldb-dev <lldb-dev at lists.llvm.org> wrote: >>> >>> Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): >>> >>> . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 >>> tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 >>> tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 >>> >>> I'll investigate, because it would be nice to have those tools. >>> >>> -Dimitry >>> >>>> On 21 Aug 2015, at 13:42, Nikola Smiljanic <popizdeh at gmail.com> wrote: >>>> >>>> Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. >>>> >>>> On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: >>>> Hm, it does not seem to compile at all here? The build ends with: >>>> >>>> In file included from /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17: >>>> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10: fatal error: 'clang/Tooling/Refactoring.h' file not found >>>> #include "clang/Tooling/Refactoring.h" >>>> ^ >>>> 1 error generated. >>>> >>>> Any idea? I had no problems at all with -rc2. >>>> >>>> -Dimitry >>>> >>>>> On 21 Aug 2015, at 02:51, Hans Wennborg <hans at chromium.org> wrote: >>>>> >>>>> Hello everyone, >>>>> >>>>> 3.7-rc3 has just been tagged. Testers, please test, build binaries, >>>>> upload to the sftp and report results to this thread. >>>>> >>>>> Again, a lot of patches got merged between rc2 and rc3, but hopefully >>>>> nothing that should upset things. >>>>> >>>>> One thing that did change is that the release script now correctly >>>>> symlinks clang-tools-extra into the build. If this causes problems on >>>>> your platform, please just remove it. >>>>> >>>>> This is a release candidate in the real sense: at this point I have >>>>> zero release blockers on my radar. I will now only accept fixes for >>>>> critical regressions, and if nothing comes up, rc3 will be promoted to >>>>> 3.7.0-final. >>>>> >>>>> Documentation and release note patches are still welcome all the way >>>>> up until the final tag goes in. >>>>> >>>>> Issues that were on my radar, but I don't consider blocking: >>>>> >>>>> - Sanitizer test failures on various platforms, e.g. PR24222. We never >>>>> ran these tests in previous releases, so it's not a regression. It >>>>> would be great if the sanitizer folks could look into the test >>>>> failures, but it's not blocking 3.7. >>>>> >>>>> - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in >>>>> __cxa_allocate_exception", Renato will exclude libc++ from his build >>>>> for now. >>>>> >>>>> - Lack of key functions in some Instruction classes causing build >>>>> failures without -fno-rtti >>>>> (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No >>>>> patches have been forthcoming, so this will not get fixed for 3.7. At >>>>> least we correctly report -fno-rtti in llvm-config built with CMake >>>>> now. >>>>> >>>>> - r244221: "[SPARC] Don't compare arch name as a string, use the enum >>>>> instead", owner is unresponsive. >>>>> >>>>> - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return >>>>> types in SysV-mips [32 bit] ABI", owner is unresponsive. >>>>> >>>>> >>>>> Cheers, >>>>> Hans >>>> >>>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150823/b803fc94/attachment.sig>
Maybe Matching Threads
- [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
- [3.7 Release] RC3 has been tagged, let's wrap this up
- [3.7 Release] RC3 has been tagged, let's wrap this up
- [3.7 Release] RC3 has been tagged, let's wrap this up
- [LLVMdev] llvm 'gmake check' errors generating lit.site.cfg