Re: [cfe-users] Standard headers cannot be found when compiling with Clang
On Fri, Jan 15, 2016 at 7:06 AM, Qiuping Yi via cfe-users
wrote:
> Hello All,
>
> I am a beginner of clang. I installed clang 3.6 with llvm 3.6, but I found
> my clang cannot work as expected.
> For the next simple program test.c:
>
> #include
> int main() {return 0;}
>
> $ clang -c test.c
>
> I got the next information:
>
> fatal error: 'stdio.h' file not found
> #include
> ^
> 1 error generated.
>
> what's wrong? I found other standard headers are also cannot be found.
> Any suggestion is OK. Thank you in advance.
What operating system are you using?
What's the output of "clang -v -c test.c"?
From where did you install clang?
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] RELEASE_380/rc3 clang failed tests
Hi Dave, On Thu, Feb 25, 2016 at 2:32 PM, Dave Ryan via cfe-users wrote: > Scanning dependencies of target check-all > [100%] Running all regression tests > lit.py: lit.cfg:195: note: using clang: '/home/dave/llvm_build/./bin/clang' > FAIL: Clang :: CodeGen/constructor-attribute.c (1627 of 24255) > TEST 'Clang :: CodeGen/constructor-attribute.c' FAILED > > Script: > -- > /home/dave/llvm_build/./bin/clang -cc1 -internal-isystem > /home/dave/llvm_build/bin/../lib/clang/3.8.0/include -nostdsysteminc -emit- > llvm -o /home/dave/llvm_build/tools/clang/test/CodeGen/Output/constructor- > attribute.c.tmp /home/dave/llvm/tools/clang/test/CodeGen/constructor- > attribute.c > grep -e "global_ctors.*@A" > /home/dave/llvm_build/tools/clang/test/CodeGen/Output/constructor- > attribute.c.tmp > grep -e "global_dtors.*@B" > /home/dave/llvm_build/tools/clang/test/CodeGen/Output/constructor- > attribute.c.tmp > grep -e "global_ctors.*@C" > /home/dave/llvm_build/tools/clang/test/CodeGen/Output/constructor- > attribute.c.tmp > grep -e "global_dtors.*@D" > /home/dave/llvm_build/tools/clang/test/CodeGen/Output/constructor- > attribute.c.tmp > -- > Exit Code: 2 > > Command Output (stderr): > -- > grep: illegal option -- e > Usage: grep [-c|-l|-q] -bhinsvw pattern file . . . On what system is this? I think grep -e and -F are both specified by POSIX. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Full MS Windows support?
On Tue, Aug 9, 2016 at 9:12 AM, Mayuresh Kathe via cfe-users wrote: > Does LLVM/Clang now support development under MS Windows without having to > rely on any extra external components, like SDKs, etc.? No, only the compiler (and linker with lld) is provided. You still need an SDK to get all the headers, libraries, etc. Cheers, Hans ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] complie clang with clang
I think this should do it: $ CXX=clang++ CC=clang cmake -G "Unix Makefiles" ../llvm $ VERBOSE=1 make -j8 On Wed, Mar 22, 2017 at 5:19 AM, Masaru Tsuchiyama via cfe-users wrote: > Hi. > > Thank you for the replay. > > I could show the command lines with the following steps. > > $ CXX=clang++ CC=clang cmake -G Ninja ../llvm > $ ninja-build -v > > But I want to do this with make. > > Could you tell me how? > > Rest Regards. > > > Duncan P. N. Exon Smith wrote: >> >> >>> On 2017-Mar-21, at 06:51, Masaru Tsuchiyama via cfe-users >>> wrote: >>> >>> Hi. >>> >>> I'm trying to complie clang with clang. >> >> >> This should be fairly well documented. Try these: >>http://clang.llvm.org/get_started.html >>http://llvm.org/docs/CMake.html >>http://llvm.org/docs/AdvancedBuilds.html >> >> It sounds like you're looking for "bootstrap" builds, which is the first >> thing in the third link. >> >>> Then I found the site. >>> http://stackoverflow.com/questions/12479458/how-to-build-clang-with-clang >>> >>> I want to know whether clang is surely used when compiling clang. >>> I want it to display command line of clang compilation. >>> >>> Is there any method to show the exact command line when compiling it. >> >> >> This depends on your build system. If you're using Ninja, you can add >> "-v" to the command-line to see what commands are being called. >> >>> Best Regards. >>> >>> -- >>> Masaru Tsuchiyama >>> ___ >>> cfe-users mailing list >>> cfe-users@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >> >> >> > > > -- > Masaru Tsuchiyama > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang prebuilt binary for CentOS 7
No, there was no CentOS tester/packager for the 4.0.0 release. The prebuilt binaries are really mostly for testing though. Distributions should provide proper packages; I don't know if CentOS has a clang package available, though. - Hans On Thu, Mar 23, 2017 at 6:58 PM, Alex Chen via cfe-users wrote: > Hi, > >The latest clang prebuilt binary for CentOS is 3.8.0 for CentOS 6. Is > there any plan to provide clang 4.0.0 for CentOS 7? > > > > Thanks > > > > Alex Chen ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang/LLVM detection on Windows
I don't believe Clang defines _MSC_VER when targeting MinGW. For MinGW, I belive it also defines __MINGW32__ or __MINGW64__ depending on target architecture. Cheers, Hans On Wed, Oct 25, 2017 at 8:00 AM, degski via cfe-users wrote: > Is there a macro defined by Clang that helps to distinguish between > Clang/LLVM is called under MinGW/Cygwin and Clang/LLVM with/from MSVC? > > Have a good day, > > degski > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] package build fails at r324504 or later on VS2017
+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
> ===
> --- cmake/modules/HandleLLVMOptions.cmake (revision 324806)
> +++ cmake/modules/HandleLLVMOptions.cmake (working copy)
> @@ -353,12 +353,6 @@
>
>append("/Zc:inline" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
>
> - # Generate PDB even in release for profiling.
> - if (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
> -append("/Zi" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
> -append("/DEBUG" CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS
> CMAKE_SHARED_LINKER_FLAGS)
> - endif (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
> -
This is surprising. I wouldn't expect the PDB files to end up in the
package or otherwise affect it. In fact, I tried building a package
with the script in utils/release/build_llvm_package.bat at r324504 and
it worked fine for me. And I verified there were no pdbs in the
package.
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.
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] package build fails at r324504 or later on VS2017
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
>> > ===
>> > --- cmake/modules/HandleLLVMOptions.cmake (revision 324806)
>> > +++ cmake/modules/HandleLLVMOptions.cmake (working copy)
>> > @@ -353,12 +353,6 @@
>> >
>> >append("/Zc:inline" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
>> >
>> > - # Generate PDB even in release for profiling.
>> > - if (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
>> > -append("/Zi" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
>> > -append("/DEBUG" CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS
>> > CMAKE_SHARED_LINKER_FLAGS)
>> > - endif (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
>> > -
>>
>> This is surprising. I wouldn't expect the PDB files to end up in the
>> package or otherwise affect it. In fact, I tried building a package
>> with the script in utils/release/build_llvm_package.bat at r324504 and
>> it worked fine for me. And I verified there were no pdbs in the
>> package.
>>
>> 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.
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] package build fails at r324504 or later on VS2017
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
>>> >> > ===
>>> >> > --- cmake/modules/HandleLLVMOptions.cmake (revision 324806)
>>> >> > +++ cmake/modules/HandleLLVMOptions.cmake (working copy)
>>> >> > @@ -353,12 +353,6 @@
>>> >> >
>>> >> >append("/Zc:inline" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
>>> >> >
>>> >> > - # Generate PDB even in release for profiling.
>>> >> > - if (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
>>> >> > -append("/Zi" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
>>> >> > -append("/DEBUG" CMAKE_EXE_LINKER_FLAGS
>>> >> > CMAKE_MODULE_LINKER_FLAGS
>>> >> > CMAKE_SHARED_LINKER_FLAGS)
>>> >> > - endif (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
>>> >> > -
>>> >>
>>> >> This is surprising. I wouldn't expect the PDB files to end up in the
>>> >> package or otherwise affect it. In fact, I tried building a package
>>> >> with the script in utils/release/build_llvm_package.bat at r324504 and
>>> >> it worked fine for me. And I verified there were no pdbs in the
>>> >> package.
>>> >>
>>> >> 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.
>>> >
>>> >
>>
>>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] package build fails at r324504 or later on VS2017
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
>> >>> >> >
>> >>> >> > ===
>> >>> >> > --- cmake/modules/HandleLLVMOptions.cmake (revision 324806)
>> >>> >> > +++ cmake/modules/HandleLLVMOptions.cmake (working copy)
>> >>> >> > @@ -353,12 +353,6 @@
>> >>> >> >
>> >>> >> >append("/Zc:inline" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
>> >>> >> >
>> >>> >> > - # Generate PDB even in release for profiling.
>> >>> >> > - if (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
>> >>> >> > -append("/Zi" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
>> >>> >> > -append("/DEBUG" CMAKE_EXE_LINKER_FLAGS
>> >>> >> > CMAKE_MODULE_LINKER_FLAGS
>> >>> >> > CMAKE_SHARED_LINKER_FLAGS)
>> >>> >> > - endif (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
>> >>> >> > -
>> >>> >>
>> >>> >> This is surprising. I wouldn't expect the PDB files to end up in
>> >>> >> the
>> >>> >> package or otherwise affect it. In fact, I tried building a package
>> >>> >> with the script in utils/release/build_llvm_package.bat at r32
Re: [cfe-users] package build fails at r324504 or later on VS2017
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
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" >> >> >> >>
Re: [cfe-users] Regressions in clang-6 need to be resolved
On Sun, May 6, 2018 at 7:15 PM, Yuri via cfe-users wrote: > There are two FreeBSD ports that fail to compile with clang-6 with errors > that don't look like genuine C++ errors. > > Here are the bug reports with attached testcases: > > https://bugs.llvm.org/show_bug.cgi?id=36915 > > https://bugs.llvm.org/show_bug.cgi?id=36916 > > I suspect these are regressions. > > > Is it possible to get an estimated time when these will be fixed? I've marked them as 6.0.1 blocker to get the bugs some more visibility. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] how clang merge strings in .rodata section
On Thu, Jul 5, 2018 at 3:18 AM, Jian, Xu via cfe-users
wrote:
> Hi,
>
> The following c source code abc.c:
>
> #include
>
> int g_val=10;
>
> const char *g_str="abc";
>
> const char *g_str1="c";
>
> int main(void)
>
> {
>
> printf("%s %s: %d\n",g_str,g_str1,g_val);
>
> return 0;
>
> }
>
>
>
> When compile with “clang abc.c -o abc” then dump .rodata section:
>
> # readelf -p .rodata abc
>
>
>
> String dump of section '.rodata':
>
> [ 0] abc
>
> [ 4] %s %s: %d
>
>
>
> When compile with “gcc abc.c -o abc” then dump .rodata section:
>
> $ readelf -p .rodata abc
>
>
>
> String dump of section '.rodata':
>
> [10] abc
>
> [14] c
>
> [16] %s %s: %d^J
>
>
>
> clang is able to merge short string (“c”) into the tail of a long string
> (“abc”), while gcc will not.
>
> Does anybody know how to disable this behavior (make it similar to gcc) ?
I don't think there is a way to disable it.
Why do you want to disable this behaviour?
- Hans
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] how clang merge strings in .rodata section
On Fri, Jul 6, 2018 at 10:22 AM, Jian, Xu wrote:
> Hi Hans,
> We need to compare whether ELF files of two builds are identical.
> Because of string merge, the comparison has some trouble.
>
> For example in case following code lines (may be in different files):
> ---
> const char* s_array[1]="s";
> const char *first_s="this first bigger s";
> const char *second_s="this second bigger s";
> ---
>
> After clang build ELF out, sometimes the s_array[1] contail the position of
> the tail of first_s in .rodata second, while sometimes second_s.
> This lead to .data section diff since s_array is in it.
> The ELF diffs, while nothing changed from functionality point of view.
Did the inputs change? If Clang is sometimes using the tail of first_s
and sometimes second_s, for the same input, that's a bug. The
compilation should be deterministic.
Can you provide sample input files and command lines that show this problem?
Thanks,
Hans
> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> Sent: Friday, July 6, 2018 3:54 PM
> To: Jian, Xu
> Cc: cfe-users@lists.llvm.org
> Subject: Re: [cfe-users] how clang merge strings in .rodata section
>
> On Thu, Jul 5, 2018 at 3:18 AM, Jian, Xu via cfe-users
> wrote:
>> Hi,
>>
>> The following c source code abc.c:
>>
>> #include
>>
>> int g_val=10;
>>
>> const char *g_str="abc";
>>
>> const char *g_str1="c";
>>
>> int main(void)
>>
>> {
>>
>> printf("%s %s: %d\n",g_str,g_str1,g_val);
>>
>> return 0;
>>
>> }
>>
>>
>>
>> When compile with “clang abc.c -o abc” then dump .rodata section:
>>
>> # readelf -p .rodata abc
>>
>>
>>
>> String dump of section '.rodata':
>>
>> [ 0] abc
>>
>> [ 4] %s %s: %d
>>
>>
>>
>> When compile with “gcc abc.c -o abc” then dump .rodata section:
>>
>> $ readelf -p .rodata abc
>>
>>
>>
>> String dump of section '.rodata':
>>
>> [10] abc
>>
>> [14] c
>>
>> [16] %s %s: %d^J
>>
>>
>>
>> clang is able to merge short string (“c”) into the tail of a long
>> string (“abc”), while gcc will not.
>>
>> Does anybody know how to disable this behavior (make it similar to gcc) ?
>
> I don't think there is a way to disable it.
>
> Why do you want to disable this behaviour?
>
> - Hans
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] MSVC always trying to rebuild project while using clang-cl (LLVM-vs2014 toolset)
This is the problem described in https://bugs.llvm.org/show_bug.cgi?id=36140 Have you tried using the new VS extension? https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain It should not have this problem. - Hans On Mon, Sep 3, 2018 at 12:34 PM, Aleksei via cfe-users wrote: > Hello everyone, > > > > I don’t know if I’ve found a bug in clang-cl using Visual Studio 2015, or > it’s a quite normal behavior… It would be nice if someone clarify it and > (better) fix something in clang-cl, because the current behavior is IMHO > very confusing. > > > > Background: Visual Studio 2015, version 14.0.25431.01 Update 3, LLVM version > 6.0.1 for win64 > > > > So, the problem is MSVC (under some condition) would always require to > rebuild a project that has to be built with LLVM-vs2014 toolset, even if > it’d just finished last rebuild. > > > > The root cause of it in the absence of a file, that is specified under > “Configuration Properties / C/C++ / Output Files / Program Database File > Name” (typically, it’s filled with macro > “$(IntDir)vc$(PlatformToolsetVersion).pdb” that expands to something similar > to “x64\Debug\vc140.pdb”). I might be wrong in general case, but in my case > this file is not generated by clang-cl at all during build process, it’s > generated only by VC’s native compiler. So, should one delete it > intentionally during manual cleanup or by an accident, MSVC would start to > always require a full project rebuild before each run/debug. > > > > It’s very easy to reproduce the problem: create a new Win32 console project > in MSVC, then immediately change the toolset used to build the project to > LLVM-vs2015 and then build the project (don’t build the project with native > compiler before this step). Then run it and notice that MSVC would require > the project to be rebuild. > > Now, if one to switch back the toolset to VC’s native, build the project (to > produce corresponding .pdb file), then switch the toolset to LLVM again and > then build it and after that run it – MSVC would start the program > immediately. > > > > If the .pdb file is not required to run/debug a project, I guess it would be > much better if clang-cl to emit some kind of warning/information during > compilation about that fact. I’ve just wasted about 3-4 hours to find out > why VC requires project rebuilding all the time… > > > > Thanks. > > > > Sincerely, > > Aleksei > > > > > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Using clang windows installer from command line
The installer is built using NSIS, and that claims that it's possible to run the installer silently from the command line: LLVM-7.0.0-rc2-win32.exe /S /D=\src\llvminstall (See 3.2.1 here: http://nsis.sourceforge.net/Docs/Chapter3.html#installerusagecommon) I've never gotten that to work myself though. If you just need a zip file to deploy, I'd suggest doing a local install with the official installer and ziping up the install directory. If you don't need the official releases but just need a clang, you can get the tarballs used by Chrome here: http://is.gd/chromeclang - Hans On Thu, Sep 6, 2018 at 3:59 PM, Korshunov Nikolay via cfe-users wrote: > Is there a way to install clang on windows using official binary > distribution (installer) via command line? Or is there windows distribution > inside an archive? > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Snapshot Updates
Thanks :-D On Mon, Nov 12, 2018 at 3:06 PM, degski via cfe-users wrote: > Thumbs up to the person updating the Windows LLVM Snapshot Builds. > > degski > -- > “If something cannot go on forever, it will stop" - Herbert Stein > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang-cl choosing VC++ backend on Windows
On Mon, Jul 22, 2019 at 3:29 PM Edward Diener via cfe-users wrote: > > Given multiple installations installed of Visual Studio/VC++ on Windows, > with none of them normally in the PATH, how does clang-cl choose which > one to use at compile/link time as the clang backend ? It's a bit involved. You can find the code here: http://llvm-cs.pcc.me.uk/tools/clang/lib/Driver/ToolChains/MSVC.cpp#709 Clang first looks for environment variables VCToolsInstallDir or VCINSTALLDIR which are usually set by vcvarsall.bat (or if you launch a Visual Studio Native Tools Command Prompt). If those aren't set, it looks on PATH. After that, it queries the "Visual Studio Setup Configuration Server", and after that it checks the registry. If you want to point Clang to use a specific Visual Studio install, the best way is to set the environment variables the way vcvarsall.bat sets them. Hope that helps, Hans ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang9 UBSan and GMP
I'm a fan of GMP, so I'll jump :-) Regardless of whether this is a bug
in LLVM or GMP, it would be satisfying to get to the root of the
problem.
Bisecting over LLVM shows that GMP's mpn test t-sqrlo starts failing
on my x86_64 Linux machine after this commit
at 8ee477a2ab6 "[InstSimplify] SimplifyICmpInst - icmp eq/ne %X,
undef -> undef"
(My bisection command was
ninja -C build.release -j900 clang && ( cd /tmp/gmp-6.1.2/build &&
make clean && CC=/work/llvm.monorepo/build.release/bin/clang
../configure && make -j50 && make check )
)
Comparing the object files of GMP builds using that LLVM version and
the one right before, shows a diff in ./tests/mpn/t-sqrlo.o
Looking at LLVM's -print-after-all shows a diff after GVN which seems
to come from this if-statement in tests/mpn/t-sqrlo.c:
if (pp[-1] != p_before || pp[n] != p_after
|| scratch[-1] != s_before || scratch[itch] != s_after
|| mpn_cmp (refp, pp, n) != 0)
{
It looks like the "scratch[-1] != s_before" expression was previously
folded to false, but now it's folded to undef (and the branch ends up
going the other way). That matches the commit message from the
bisection.
It seems the memory pointed to by scratch is never initialized, so the
code is reading uninitialized memory. I'm not a language lawyer, but
it smells like Undefined Behaviour.
The source has a commented out block that I guess would initialize
scratch. Maybe the fix is to reinstate that code, or also comment out
or remove the code that accesses scratch?
Thanks,
Hans
On Sat, Oct 26, 2019 at 12:14 AM David Blaikie via cfe-users
wrote:
>
> Yeah, coming across compiler bugs does happen - but more often it's bugs in
> input programs. (one of the reasons compiler engineers aren't likely to jump
> on reproducing and reducing misbehaving programs, because on the odds, it's
> not a bug in the compiler)
>
> On Fri, Oct 25, 2019 at 3:12 PM Hans Åberg wrote:
>>
>> The sources are available at [1]; it is written in C, not C++. I was was
>> hoping that that something like UBSan would shed light on it, but the
>> original question is answered: it changes optimization. The GMP developers
>> say that they have caught some compiler bugs, but that is hard to do and
>> time consuming.
>>
>> 1. https://gmplib.org
>>
>>
>> > On 25 Oct 2019, at 23:38, David Blaikie wrote:
>> >
>> > It's hard to know if it's the compiler's fault without a test case - due
>> > to the nature of undefined behavior and other things (implementation
>> > defined behavior and unspecified behavior) in C++, that the program
>> > behaves as expected with another compiler or another set of flags doesn't
>> > give a strong indication as to where the problem is (in the code, in one
>> > of the compilers, etc).
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
