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
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)
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
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=c
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
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 b
+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.
>
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 (210
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.
>>
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 d
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 c
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 w
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.ll
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;
>
> }
>
>
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):
> --
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-user
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
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
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. Yo
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] Simpli
20 matches
Mail list logo
