similar to: Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang

I'm building LLVM with Clang, LLD, compiler-rt, libunwind, libcxx and libcxxabi. I'm using GCC 7.1.1 and binutils 2.28.0 to build. The compilation is aborted during libunwind build due to gcc not being able to parse libcxx's __config: /usr/bin/cc -DLLVM_BUILD_GLOBAL_ISEL -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/libunwind/src

Jay Freeman (saurik) wrote: > gcc is correct. According to the ISO specification, the for-init-statement > is supposed to inject any variable names into the same declarative scope as > the condition of an equivalent restructuring of the loop in the form of a > while statement, which in turn fronts the declaration to an extra scope that > surrounds the /entire/ loop construct.

It already shipped AFAIK: http://releases.llvm.org/download.html — Mehdi > On Dec 27, 2016, at 9:55 AM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Can we still check patches into 3.9.1? > >> On Dec 24, 2016, at 1:47 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote: >> >> >>> On Dec 23, 2016, at 11:17,

3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind: #define COMPILE_TIME_ASSERT( expr ) \ extern int compile_time_assert_failed[ ( expr ) ? 1 : -1 ] __attribute__( ( unused ) ); I notice that the issue is fixed on current trunk. Does anyone know what revision introduced the fix? Can we get it

> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind: > > #define COMPILE_TIME_ASSERT( expr ) \ > extern int compile_time_assert_failed[ ( expr ) ? 1 : -1 ] __attribute__( (

+Tom : is there a plan for a 3.9.2? — Mehdi > On Dec 27, 2016, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > It already shipped AFAIK: http://releases.llvm.org/download.html > > — > Mehdi > >> On Dec 27, 2016, at 9:55 AM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Can we still check patches into

> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com> wrote: > > >> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind: >> >> #define

Can we still check patches into 3.9.1? > On Dec 24, 2016, at 1:47 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote: > > >> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com> wrote: >> >> >>> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>

For example, I execute the following command sequences: H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s #.globl _sqrt .global sqrt #.type sqrt, at function #_sqrt: sqrt: fldl 4(%esp) fsqrt fstsw %ax sub $12,%esp fld %st(0) fstpt (%esp) mov (%esp),%ecx and $0x7ff,%ecx cmp $0x400,%ecx jnz 1f and $0x200,%eax

There's a regression in AMDGPU which would be nice to get resolved, see: https://bugs.freedesktop.org/show_bug.cgi?id=99078 https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.9/+bug/1656620?comments=all I think it's reasonably low-risk to back-port AMDGPU: Reduce the duration of whole-quad-mode AMDGPU: Do not clobber SCC in SIWholeQuadMode since they've been in trunk and

I don't think we should attempt to mangle symbols declared in assembly source files. If you're writing assembly, you will need to handle ABI portability, including the _ prefix on win32 x86. clang will run the C preprocessor for you if you use the .S file suffix (case matters). On Tue, Oct 22, 2013 at 7:08 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > For example, I

The last line gets duplicated when a file is read like this: a <- scan(file=filename, what="", sep="\n", strip.white=c(TRUE), quiet=TRUE) (This error does not occur on Linux, the only other platform I tested.) Version: platform = hppa2.0-hp-hpux10.20 arch = hppa2.0 os = hpux10.20 system = hppa2.0, hpux10.20 Actually, all binaries are

I just installed Centos 5.5 x86_64 on a new Toshiba Satellite L1500D. Everything seems to work (so far) other than the wireless networking; lscpi tells me: 0e:00.0 Network controller: Realtek Semiconductor Co., Ltd. Unknown device 8172 (rev 10) I discovered that I need the realtek driver, so I found and downloaded these: rtl8192se_linux_2.6.0010.1012.2009_64bit.tar.gz

Ah, interesting, have not ran across that before (as I always strive to never use the same name as any scope previously), but rather interesting that GCC gets it wrong while VC++ gets it right, kind of a switch. And yes, that switch I mentioned is for VC6 style in VC7.1 (what I use), you have to switch it to make it conformant, nice to hear VC8 does it correctly by default now. On Thu, Oct 2,

From: Gene Cumm <gene.cumm at gmail.com> CORE/writedec: Fix overflow and redeclaration; If EDX is greater than or equal to 10, div can cause an overflow. Comment out declaration of writechr. Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- Against current head. hpa: If there's a preferred way to do what this function provides, let me know. Was the writechr in there on

I've started the process of bringing LLVM's libunwind into the FreeBSD base system[1]. As part of that process we've tested building the approximately 25,000 third party software packages in the FreeBSD ports collection against a modified FreeBSD with libunwind included[2]. Of course, I wouldn't expect much in the way of build failures -- I'd expect any issues to be largely

Hi Eric,   Thanks for patch information. I have checked the patch with my code and I see that it works. But when I extract the variable and check the metadata information to retrieve the scope information, I do not get exact scope, after optimization. As you said that this is a work in progress, so can we expect full version on this in llvm3.3 release ?   Regards, Pankaj  

gcc is correct. According to the ISO specification, the for-init-statement is supposed to inject any variable names into the same declarative scope as the condition of an equivalent restructuring of the loop in the form of a while statement, which in turn fronts the declaration to an extra scope that surrounds the /entire/ loop construct. VC++ seems to be scoping the variables as if they were

Those rules only apply to if and switch statements. (Yes, this is insane, but true.) The entire section you are quoting from, 6.4, is titled "Selection statements [stmt.select]", which specifically covers these two cases. A for is an iteration statement, not a selection statement. So, if you read 6.5.3p1 (which is actually about for statements) it states that a for loop is rewritten

On Oct 30, 2012, at 3:15 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 10/30/2012 4:10 PM, Ashwin kumar wrote: >> >> Assertion failed: (PI && "Expected required passes to be initialized"), >> function schedulePass, file PassManager.cpp, line 597. >> >> >> I register the passes using RegisterPass function call.