Re: [cfe-users] package build fails at r324504 or later on VS2017

2018-02-20 Thread Hans Wennborg via cfe-users
I'm guessing this is a problem with NSIS failing to handle large files
though, and I'm not sure there's much we can do about it.

On Mon, Feb 19, 2018 at 10:54 PM, masaru tsuchiyama  wrote:
> But it failed with -DLLVM_ENABLE_PDB=ON option .
>
> The error message is
> File: "lldELF.lib"
> Internal compiler error #12345: error mmapping datablock to 21869285.
>
> Note: you may have one or two (large) stale temporary file(s) left in your
> temporary directory (Generally this only happens on Windows 9x).
>
>
> 2018-02-19 21:50 GMT+09:00 Hans Wennborg :
>>
>> Ah, great.
>>
>> Reid, seems like you fixed this user's issue.
>>
>> On Mon, Feb 19, 2018 at 1:45 PM, masaru tsuchiyama 
>> wrote:
>> > It seems the change of the commit was disabled by default at r325296.
>> >
>> > Regards.
>> >
>> >
>> > 2018-02-19 19:55 GMT+09:00 Hans Wennborg :
>> >>
>> >> No, I didn't change anything here and I don't think Zach did either.
>> >>
>> >> On Sun, Feb 18, 2018 at 9:39 AM, masaru tsuchiyama 
>> >> wrote:
>> >> > It didn't happen at r325456.
>> >> > Did you fix it?
>> >> >
>> >> > Regards.
>> >> >
>> >> > 2018-02-17 5:57 GMT+09:00 masaru tsuchiyama :
>> >> >>
>> >> >> >  Is that a solution to your problem?
>> >> >>
>> >> >> No.
>> >> >> It could be a workaround, but not a solution.
>> >> >> I think we need to know the reason why the commit  and the option
>> >> >> affect
>> >> >> the result at least.
>> >> >>
>> >> >>
>> >> >> 2018-02-16 19:05 GMT+09:00 Hans Wennborg :
>> >> >>>
>> >> >>> On Thu, Feb 15, 2018 at 11:43 PM, masaru tsuchiyama
>> >> >>> 
>> >> >>> wrote:
>> >> >>> > Hi,
>> >> >>> >
>> >> >>> >>  Is there any info about what went wrong in NSISOutput.log?
>> >> >>> >
>> >> >>> > I attach the log.
>> >> >>> >
>> >> >>> > This is the last part of the log.
>> >> >>> >
>> >> >>> >   File: "clangStaticAnalyzerCheckers.lib"
>> >> >>> >
>> >> >>> >   Internal compiler error #12345: error mmapping file
>> >> >>> > (2106828838,
>> >> >>> > 33554432)
>> >> >>> > is out of range.
>> >> >>> >   Note: you may have one or two (large) stale temporary file(s)
>> >> >>> > left
>> >> >>> > in
>> >> >>> > your
>> >> >>> > temporary directory (Generally this only happens on Windows 9x).
>> >> >>> >
>> >> >>> > I'm using Win10 Pro Japanese and VS2017 Community Japanese.
>> >> >>> > The version of NSIS is 3.02.1.
>> >> >>> >
>> >> >>> >> Maybe you want to add -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON to your
>> >> >>> >> build,
>> >> >>> >> though I'm not sure that should make any difference to the pdb
>> >> >>> >> files.
>> >> >>> >
>> >> >>> > If I added the option, the build succeeded.
>> >> >>>
>> >> >>> Is that a solution to your problem?
>> >> >>>
>> >> >>> > 2018-02-14 23:06 GMT+09:00 Hans Wennborg :
>> >> >>> >>
>> >> >>> >> +Zach for r324504
>> >> >>> >>
>> >> >>> >> On Tue, Feb 13, 2018 at 1:45 PM, masaru tsuchiyama via cfe-users
>> >> >>> >>  wrote:
>> >> >>> >> > Hello
>> >> >>> >> >
>> >> >>> >> > llvm build fails at r324504 or later.
>> >> >>> >> > I used the attached file to build. (renamed to .txt)
>> >> >>> >> >
>> >> >>> >> > example:
>> >> >>> >> >clang-build.bat ninja  x86 update 324806
>> >> >>> >> >
>> >> >>> >> > This is the tail of the failure log.
>> >> >>> >> >
>> >> >>> >> > CPack: Create package using NSIS
>> >> >>> >> > CPack: Install projects
>> >> >>> >> > CPack: - Install project: LLVM
>> >> >>> >> > Creating llvm-ranlib.exe
>> >> >>> >> > Creating llvm-lib.exe
>> >> >>> >> > Creating llvm-dlltool.exe
>> >> >>> >> > Creating clang++.exe
>> >> >>> >> > Creating clang-cl.exe
>> >> >>> >> > Creating clang-cpp.exe
>> >> >>> >> > Creating ../msbuild-bin/cl.exe
>> >> >>> >> > Creating lld-link.exe
>> >> >>> >> > Creating ld.lld.exe
>> >> >>> >> > Creating ld64.lld.exe
>> >> >>> >> > Creating wasm-ld.exe
>> >> >>> >> > Creating llvm-readelf.exe
>> >> >>> >> > CPack: Create package
>> >> >>> >> > CPack Error: Problem running NSIS command: "C:/Program Files
>> >> >>> >> > (x86)/NSIS/makensis.exe"
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> > "C:/Jenkins/workspace/llvm/build/_CPack_Packages/win32/NSIS/project.nsi"
>> >> >>> >> > Please check
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> > C:/Jenkins/workspace/llvm/build/_CPack_Packages/win32/NSIS/NSISOutput.log
>> >> >>> >> > for errors
>> >> >>> >>
>> >> >>> >> Is there any info about what went wrong in NSISOutput.log?
>> >> >>> >>
>> >> >>> >> > CPack Error: Problem compressing the directory
>> >> >>> >> > CPack Error: Error when generating package: LLVM
>> >> >>> >> > FAILED: CMakeFiles/package.util
>> >> >>> >> > cmd.exe /C "cd /D C:\Jenkins\workspace\llvm\build &&
>> >> >>> >> > "C:\Program
>> >> >>> >> > Files\CMake\bin\cpack.exe" --config ./CPackConfig.cmake"
>> >> >>> >> > ninja: build stopped: subcommand failed.
>> >> >>> >> >
>> >> >>> >> > I confirmed that the build succeeded by reverting r324504 at
>> >> >>> >> > r324806.
>> >> >>> >> >
>> >> >>> >> > Index: cmake/modules/HandleLLVMOptions.cmake
>> >> >>> >> >
>> >> >

Re: [cfe-users] package build fails at r324504 or later on VS2017

2018-02-20 Thread Hans Wennborg via cfe-users
The official snapshots and releases still only include the toolchain,
by passing -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON.

On Tue, Feb 20, 2018 at 4:54 PM, Reid Kleckner  wrote:
> I didn't think we included the .lib files in the NSIS package. Do we do that
> now? I know users asked for it, but I thought we stuck with just the
> toolchain.
>
> On Tue, Feb 20, 2018 at 1:13 AM, Hans Wennborg  wrote:
>>
>> I'm guessing this is a problem with NSIS failing to handle large files
>> though, and I'm not sure there's much we can do about it.
>>
>> On Mon, Feb 19, 2018 at 10:54 PM, masaru tsuchiyama 
>> wrote:
>> > But it failed with -DLLVM_ENABLE_PDB=ON option .
>> >
>> > The error message is
>> > File: "lldELF.lib"
>> > Internal compiler error #12345: error mmapping datablock to 21869285.
>> >
>> > Note: you may have one or two (large) stale temporary file(s) left in
>> > your
>> > temporary directory (Generally this only happens on Windows 9x).
>> >
>> >
>> > 2018-02-19 21:50 GMT+09:00 Hans Wennborg :
>> >>
>> >> Ah, great.
>> >>
>> >> Reid, seems like you fixed this user's issue.
>> >>
>> >> On Mon, Feb 19, 2018 at 1:45 PM, masaru tsuchiyama 
>> >> wrote:
>> >> > It seems the change of the commit was disabled by default at r325296.
>> >> >
>> >> > Regards.
>> >> >
>> >> >
>> >> > 2018-02-19 19:55 GMT+09:00 Hans Wennborg :
>> >> >>
>> >> >> No, I didn't change anything here and I don't think Zach did either.
>> >> >>
>> >> >> On Sun, Feb 18, 2018 at 9:39 AM, masaru tsuchiyama
>> >> >> 
>> >> >> wrote:
>> >> >> > It didn't happen at r325456.
>> >> >> > Did you fix it?
>> >> >> >
>> >> >> > Regards.
>> >> >> >
>> >> >> > 2018-02-17 5:57 GMT+09:00 masaru tsuchiyama :
>> >> >> >>
>> >> >> >> >  Is that a solution to your problem?
>> >> >> >>
>> >> >> >> No.
>> >> >> >> It could be a workaround, but not a solution.
>> >> >> >> I think we need to know the reason why the commit  and the option
>> >> >> >> affect
>> >> >> >> the result at least.
>> >> >> >>
>> >> >> >>
>> >> >> >> 2018-02-16 19:05 GMT+09:00 Hans Wennborg :
>> >> >> >>>
>> >> >> >>> On Thu, Feb 15, 2018 at 11:43 PM, masaru tsuchiyama
>> >> >> >>> 
>> >> >> >>> wrote:
>> >> >> >>> > Hi,
>> >> >> >>> >
>> >> >> >>> >>  Is there any info about what went wrong in NSISOutput.log?
>> >> >> >>> >
>> >> >> >>> > I attach the log.
>> >> >> >>> >
>> >> >> >>> > This is the last part of the log.
>> >> >> >>> >
>> >> >> >>> >   File: "clangStaticAnalyzerCheckers.lib"
>> >> >> >>> >
>> >> >> >>> >   Internal compiler error #12345: error mmapping file
>> >> >> >>> > (2106828838,
>> >> >> >>> > 33554432)
>> >> >> >>> > is out of range.
>> >> >> >>> >   Note: you may have one or two (large) stale temporary
>> >> >> >>> > file(s)
>> >> >> >>> > left
>> >> >> >>> > in
>> >> >> >>> > your
>> >> >> >>> > temporary directory (Generally this only happens on Windows
>> >> >> >>> > 9x).
>> >> >> >>> >
>> >> >> >>> > I'm using Win10 Pro Japanese and VS2017 Community Japanese.
>> >> >> >>> > The version of NSIS is 3.02.1.
>> >> >> >>> >
>> >> >> >>> >> Maybe you want to add -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON to
>> >> >> >>> >> your
>> >> >> >>> >> build,
>> >> >> >>> >> though I'm not sure that should make any difference to the
>> >> >> >>> >> pdb
>> >> >> >>> >> files.
>> >> >> >>> >
>> >> >> >>> > If I added the option, the build succeeded.
>> >> >> >>>
>> >> >> >>> Is that a solution to your problem?
>> >> >> >>>
>> >> >> >>> > 2018-02-14 23:06 GMT+09:00 Hans Wennborg :
>> >> >> >>> >>
>> >> >> >>> >> +Zach for r324504
>> >> >> >>> >>
>> >> >> >>> >> On Tue, Feb 13, 2018 at 1:45 PM, masaru tsuchiyama via
>> >> >> >>> >> cfe-users
>> >> >> >>> >>  wrote:
>> >> >> >>> >> > Hello
>> >> >> >>> >> >
>> >> >> >>> >> > llvm build fails at r324504 or later.
>> >> >> >>> >> > I used the attached file to build. (renamed to .txt)
>> >> >> >>> >> >
>> >> >> >>> >> > example:
>> >> >> >>> >> >clang-build.bat ninja  x86 update 324806
>> >> >> >>> >> >
>> >> >> >>> >> > This is the tail of the failure log.
>> >> >> >>> >> >
>> >> >> >>> >> > CPack: Create package using NSIS
>> >> >> >>> >> > CPack: Install projects
>> >> >> >>> >> > CPack: - Install project: LLVM
>> >> >> >>> >> > Creating llvm-ranlib.exe
>> >> >> >>> >> > Creating llvm-lib.exe
>> >> >> >>> >> > Creating llvm-dlltool.exe
>> >> >> >>> >> > Creating clang++.exe
>> >> >> >>> >> > Creating clang-cl.exe
>> >> >> >>> >> > Creating clang-cpp.exe
>> >> >> >>> >> > Creating ../msbuild-bin/cl.exe
>> >> >> >>> >> > Creating lld-link.exe
>> >> >> >>> >> > Creating ld.lld.exe
>> >> >> >>> >> > Creating ld64.lld.exe
>> >> >> >>> >> > Creating wasm-ld.exe
>> >> >> >>> >> > Creating llvm-readelf.exe
>> >> >> >>> >> > CPack: Create package
>> >> >> >>> >> > CPack Error: Problem running NSIS command: "C:/Program
>> >> >> >>> >> > Files
>> >> >> >>> >> > (x86)/NSIS/makensis.exe"
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> > "C:/Jenkins/workspace/llvm/build/_CPack_Packages/win32/NSIS/project.nsi"
>> >> >> >>

[cfe-users] crashing w/sanitizers

2018-02-20 Thread Bill Torpey via cfe-users
Hi All:

I’ve been happily using clang and its various sanitizers for quite a while now, 
but have recently run into a strange problem, and thought I would ask about it 
here before posting a bug report (mostly because I don’t have enough detailed 
information for a bug report as yet). 

Short version: both Address Sanitizer and Thread Sanitizer builds of my 
application are crashing — in the case of ASAN I get “ASAN:DEADLYSIGNAL” and 
that’s all, with TSAN I get a SIGBUS error and an hs_errpid file.  (The 
application is a C++ shared library hosted in a JVM. The JVM is spawned from a 
C++ executable so that ASAN and TSAN can be linked statically).

I’m getting this behavior with clang 5.0.0 and 5.0.1.  

The funny thing is this happens only my home Linux box, which has aCore 
i5-2400, while it does not happen on my work machine, which has two Core 
i7-4770R CPUs.  Both are running Centos 6.9, with 16GB RAM.

Does this ring a bell for anyone?  Any help is much appreciated…

Thanks!






___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users


[cfe-users] Format of AST entries?

2018-02-20 Thread Ray Mitchell via cfe-users
I am attempting to do some basic parsing of the AST using C#.  So far I've had 
success extracting a few things simply by writing some test C++ code, 
generating an AST for it, making some changes, regenerating an AST, and 
observing what changes in the AST entries.  However, this empirical approach is 
pretty brutal and requires a lot of questionable assumptions.  Is there any 
documentation that explicitly explains the possible permutations and field 
meanings of each AST entry type?  If so I'd greatly appreciate a link to it.  
I've done pretty well figuring out the FunctionDecl item and a few others but a 
document describing them would really be helpful.  For example, in the 
following I know that 'ABCDE' represents the name of the function and 'float 
(int, char)' represents its data type, but there are two copies of 'float (int, 
char)' and I'd like to know why and if they both represent the same thing:

|| `-DeclRefExpr 0x862c118  'float (int, char)' lvalue Function 
0x85deae0 'ABCDE' 'float (int, char)'

I have similar questions about most of the entry types.
Thanks,
Ray___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users