[3.7 Release] RC3 has been tagged, let's wrap this up

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

[3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
On Friday, August 21, 2015 08:51 AM, Hans Wennborg 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.
>

lnt looks fine, uploaded:
clang+llvm-3.7.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz

test-release output:

Testing Time: 158.19s
********************
Failing Tests (17):
     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
     MemorySanitizer :: Linux/tcgetattr.cc
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
     MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent
     MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r
     MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
     MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
     SanitizerCommon-asan :: Linux/getpass.cc
     SanitizerCommon-asan :: Posix/decorate_proc_maps.cc
     SanitizerCommon-lsan :: Linux/getpass.cc
     SanitizerCommon-msan :: Linux/getpass.cc
     SanitizerCommon-msan :: Posix/decorate_proc_maps.cc
     SanitizerCommon-tsan :: Linux/getpass.cc
     SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc

   Expected Passes    : 24253
   Expected Failures  : 138
   Unsupported Tests  : 377
   Unexpected Failures: 17
make[3]: *** [CMakeFiles/check-all] Error 1
make[3]: Target `CMakeFiles/check-all.dir/build' not remade because of
errors.
make[2]: *** [CMakeFiles/check-all.dir/all] Error 2
make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2
make[1]: Target `check-all' not remade because of errors.
make: *** [check-all] Error 2
[Release Phase3] check-all failed

# Comparing Phase 2 and Phase 3 files
### Testing Finished ###
### Package: clang+llvm-3.7.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz
### Logs: /home/development/llvm/3.7.0/rc3/logs
### Errors:
[Release Phase3] check-all failed

Ben
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
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 <[hidden email]> 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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
On Thu, Aug 20, 2015 at 5:51 PM, Hans Wennborg <[hidden email]> 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.

Windows binaries uploaded. sha1 sums:

1f0ad138830146aa3ea93561772b82e0b93c855d  LLVM-3.7.0-rc3-win32.exe
afb014481a46a6d354bb3c2fc2cac9c18b7a6776  LLVM-3.7.0-rc3-win64.exe

Attaching the batch file I used for building.

Thanks,
Hans

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

build_llvm_370._bat_ (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
AArch64 up. All green.

On 21 August 2015 at 01:51, Hans Wennborg <[hidden email]> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
Fedora and openSUSE uploaded.

On Sat, Aug 22, 2015 at 6:59 AM, Renato Golin <[hidden email]> wrote:
AArch64 up. All green.

On 21 August 2015 at 01:51, Hans Wennborg <[hidden email]> 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
On 21 August 2015 at 21:59, Renato Golin <[hidden email]> wrote:
> AArch64 up. All green.

ARM up. All green.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
Le 21/08/2015 02:51, Hans Wennborg a écrit :
> Hello everyone,
>
> 3.7-rc3 has just been tagged. Testers, please test, build binaries,
> upload to the sftp and report results to this thread.
>
Uploaded in Debian.
Works fine on the major archs
However, lldb fails to build on some archs. I reported bug:
https://llvm.org/bugs/show_bug.cgi?id=24548

Cheers,
Sylvestre


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
Right, I found out the problem.  It's because clang-tools-extra's test Makefile uses the temporary filename "lit.tmp" for both its main lit.site.cfg, and for Unit/lit.site.cfg.  If these make jobs get run simultaneously, one or the other temp file can unexpectedly disappear.

The following fixes it, similar to what is done in clang's own test Makefile.  Hans, are you OK with me checking this in to clang-tools-extra trunk (not sure who owns that), then merging it to the release_37 branch?  Then it is at least fixed for the final build.

Index: tools/clang/tools/extra/test/Makefile
===================================================================
--- tools/clang/tools/extra/test/Makefile       (revision 245796)
+++ tools/clang/tools/extra/test/Makefile       (working copy)
@@ -60,12 +60,12 @@
 Unit/lit.site.cfg: FORCE
        @echo "Making Unit/lit.site.cfg for Clang extra tools..."
        @$(MKDIR) $(dir $@)
-       @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> lit.tmp
-       @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> lit.tmp
-       @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> lit.tmp
-       @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> lit.tmp
-       @sed -f lit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
-       @-rm -f lit.tmp
+       @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> unit.tmp
+       @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> unit.tmp
+       @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> unit.tmp
+       @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> unit.tmp
+       @sed -f unit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
+       @-rm -f unit.tmp

 clean::
        @ find . -name Output | xargs rm -fr

-Dimitry

> On 23 Aug 2015, at 01:13, Dimitry Andric <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
Finally, all building and testing succeeded, even with clang-tools-extra now (the tarballs became ~15% bigger). :)

Uploaded:

SHA256 (clang+llvm-3.7.0-rc3-i386-unknown-freebsd10.tar.xz) = 319a7d6758bad7976dab2774309504432a69705c5662b38e05062018b71f655f
SHA256 (clang+llvm-3.7.0-rc3-amd64-unknown-freebsd10.tar.xz) = 91997accc86379f7b2334ca9444a1fe017210871774153b87f4b1723125807fc

-Dimitry

> On 23 Aug 2015, at 01:33, Dimitry Andric via llvm-dev <[hidden email]> wrote:
>
> Right, I found out the problem.  It's because clang-tools-extra's test Makefile uses the temporary filename "lit.tmp" for both its main lit.site.cfg, and for Unit/lit.site.cfg.  If these make jobs get run simultaneously, one or the other temp file can unexpectedly disappear.
>
> The following fixes it, similar to what is done in clang's own test Makefile.  Hans, are you OK with me checking this in to clang-tools-extra trunk (not sure who owns that), then merging it to the release_37 branch?  Then it is at least fixed for the final build.
>
> Index: tools/clang/tools/extra/test/Makefile
> ===================================================================
> --- tools/clang/tools/extra/test/Makefile       (revision 245796)
> +++ tools/clang/tools/extra/test/Makefile       (working copy)
> @@ -60,12 +60,12 @@
> Unit/lit.site.cfg: FORCE
>        @echo "Making Unit/lit.site.cfg for Clang extra tools..."
>        @$(MKDIR) $(dir $@)
> -       @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> lit.tmp
> -       @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> lit.tmp
> -       @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> lit.tmp
> -       @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> lit.tmp
> -       @sed -f lit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
> -       @-rm -f lit.tmp
> +       @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> unit.tmp
> +       @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> unit.tmp
> +       @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> unit.tmp
> +       @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> unit.tmp
> +       @sed -f unit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
> +       @-rm -f unit.tmp
>
> clean::
>        @ find . -name Output | xargs rm -fr
>
> -Dimitry
>
>> On 23 Aug 2015, at 01:13, Dimitry Andric <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> [hidden email]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
It seems this is a cmake vs autoconf thing. With cmake, it builds
correctly, but with autoconf I get the same error as you.

I probably shouldn't have made this change while we were in the
release process as it was potentially risky :-/ I've reverted it now,
so hopefully the next build should be problem free.

Thanks,
Hans

On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>
>>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
clang+llvm-3.7.0-rc3-mips-linux-gnu.tar.xz
        All ok.
       
clang+llvm-3.7.0-rc3-mipsel-linux-gnu.tar.xz
        All ok.

clang+llvm-3.7.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling for Mips)
        Still running the last few test-suite runs but no unexpected problems so far.
        I say 'unexpected' because I updated to a new GCC cross-compilation toolchain which no longer contains certain multilibs. The three runs that depend on these removed multilibs (mips32r1 and mips64r1 n32/n64) failed as expected.

> -----Original Message-----
> From: llvm-dev [mailto:[hidden email]] On Behalf Of Hans
> Wennborg via llvm-dev
> Sent: 21 August 2015 01:52
> To: llvm-dev; [hidden email]; [hidden email]; openmp-
> [hidden email]
> Cc: Ben Pope; Pavel Labath; Nikola Smiljanić
> Subject: [llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
In reply to this post by Bakhvalov, Denis via cfe-dev
Hans,

Note that the patches I posted solved the problems, at least for me. :)

-Dimitry

> On 25 Aug 2015, at 01:40, Hans Wennborg <[hidden email]> wrote:
>
> It seems this is a cmake vs autoconf thing. With cmake, it builds
> correctly, but with autoconf I get the same error as you.
>
> I probably shouldn't have made this change while we were in the
> release process as it was potentially risky :-/ I've reverted it now,
> so hopefully the next build should be problem free.
>
> Thanks,
> Hans
>
> On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>>
>>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC3 has been tagged, let's wrap this up

Bakhvalov, Denis via cfe-dev
Thanks, we should probably do something like that after this release,
but for now I think it's best to revert to safety.

On Tue, Aug 25, 2015 at 2:44 PM, Dimitry Andric <[hidden email]> wrote:

> Hans,
>
> Note that the patches I posted solved the problems, at least for me. :)
>
> -Dimitry
>
>> On 25 Aug 2015, at 01:40, Hans Wennborg <[hidden email]> wrote:
>>
>> It seems this is a cmake vs autoconf thing. With cmake, it builds
>> correctly, but with autoconf I get the same error as you.
>>
>> I probably shouldn't have made this change while we were in the
>> release process as it was potentially risky :-/ I've reverted it now,
>> so hopefully the next build should be problem free.
>>
>> Thanks,
>> Hans
>>
>> On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>>
>>>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev