similar to: [LLVMdev] Unreachable code in Mutex.cpp

On Fri, Jan 13, 2012 at 10:24 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 13, 2012, at 4:43 PM, David Blaikie wrote: > >> It looks like for a while now (5 years) some code that was meant to do >> smart things in Mutex.cpp hasn't been doing such smart things: >> >>

On Jan 13, 2012, at 4:43 PM, David Blaikie wrote: > It looks like for a while now (5 years) some code that was meant to do > smart things in Mutex.cpp hasn't been doing such smart things: > > https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/Mutex.cpp?r1=29287&r2=29932&diff_format=h > > I don't know if this change was even deliberate since it came in

On Jan 13, 2012, at 11:17 PM, David Blaikie wrote: >> On some (linux?) implementations, various pthread APIs are defined as "weak extern" symbols in libc and strong definitions in libpthreads. The idea of this check is thus to detect if pthreads is linked into the app and enable threads if so. > > Sorry, right - I should've been more clear. I understand that that's

On Fri, Jan 13, 2012 at 11:58 PM, Chris Lattner <clattner at apple.com> wrote: > On Jan 13, 2012, at 11:17 PM, David Blaikie wrote: > >>> On some (linux?) implementations, various pthread APIs are defined as "weak extern" symbols in libc and strong definitions in libpthreads.  The idea of this check is thus to detect if pthreads is linked into the app and enable

On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh at linuxfoundation.org> wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > > From: Tom Rix <trix at redhat.com> > > > > This is a upcoming change to clean up a new warning treewide. > > I am wondering if the change could be one mega patch (see below) or > > normal patch

Hi, I'm confused by the comment and the source code of lib/Support/Mutex.cpp and lib/Support/RWMutex.cpp. In these files there are: // This variable is useful for situations where the pthread library has been // compiled with weak linkage for its interface symbols. This allows the // threading support to be turned off by simply *not linking against -lpthread*. // In that situation, the

Hi Yaron, Not sure I understand your question. Wasn't <mutex> one of the more important C++11 features that LLVM would like to use? On Thu, Sep 25, 2014 at 1:24 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Vadim, > > Thanks for the feedback on the -win32. A dependency on a small DLL with > BSD license does not sound too bad, but performance regression is

Hi, I think I can at least answer why the Rust project prefers to use mingw-w64-win32threads: 1. It does not inject dependency on libwinpthread.dll, which is nice. 2. Those who tried building LLVM with mingw-w64-pthreads, had reported significant slowdown of the resulting Rust compiler (as compared to one linked to LLVM compiled with the win32threads flavor). Profiling seemed to point towards

When LLVM's configure finds a usable <pthread.h>, it prefers to use that rather than the home-grown stuff. However if LLVM is configured with --disable-pthreads, both mingw flavors produce the same results. BTW, I've tried to quantify the slowdown: a quick test indicates that LLVM build that uses pthreads is about 10% slower than the one which doesn't. This is less that I

Martijn van Beurden wrote: > op 25-07-14 19:32, Scott Brown schreef: > > ./configure -enable-static -disable-shared CFLAGS=" -isysroot > > /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" > > make > > Well, the use of CFLAGS 'disables' the -O3 and unroll-loops > optimisation. I'm quite sure that's the culprit. Add -O3 to your

AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) back. We need to stop supporting this host platform. I'm aware of essentially 2 reasonably important use cases for supporting MinGW + win32threads: 1) Sane host toolchain on Windows that doesn't require downloading MSVC. (I'm dubious about the value of this one...) 2) Cross-compiling a Windows clang.exe (and

Hello, hopefully this is the correct place to ask this... We use distcc with clang++ and I have recently added -Wunreachable-code to our set of warnings.  The problem I am seeing is the compile fails with (valid) unreachable code warnings on the slave, but passes (no warning) locally.  All machines have the same compiler version clang version 8.0.1-svn369350-1~exp1~20190820121219.79

On Sat, 17 Oct 2020, Joe Perches wrote: > On Sat, 2020-10-17 at 09:09 -0700, trix at redhat.com wrote: > > From: Tom Rix <trix at redhat.com> > > > > This is a upcoming change to clean up a new warning treewide. > > I am wondering if the change could be one mega patch (see below) or > > normal patch per file about 100 patches or somewhere half way by

On Sat, 17 Oct 2020, Joe Perches wrote: > On Sat, 2020-10-17 at 09:09 -0700, trix at redhat.com wrote: > > From: Tom Rix <trix at redhat.com> > > > > This is a upcoming change to clean up a new warning treewide. > > I am wondering if the change could be one mega patch (see below) or > > normal patch per file about 100 patches or somewhere half way by

lvqcl wrote: > I just built FLAC and noticed that the size of flac.exe is noticeably bigger, > so I compared the generated Makefiles before ang after this change. > > The difference is: "-g -O2" options were added to CFLAGS. > > before: > CFLAGS = -O3 -funroll-loops -Wall -W -Winline -Wall -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Waggregate-return

Hi 4.1.11 no longer includes the idmap_ad module in a default ./configure. This has caught out at least two list users recently. We think it is important enough to reinstate as default. Anyone with us? Especially those whose task it will be to have to tell users via the list of the change. . . Cheers, Steve

Indeed, mingw and pthreads have C++11 atomics, so building clang (with atomics) should be possible even in cross compilation. I have no idea what is the win from *not* using winpthreads, it is one small DLL file with BSD license. For context (does not matter to mingw as host for buiilding clang but matters for clang running with mingw environment), clang TLS implementation is not same as mingw so

> On Apr 3, 2020, at 11:06 AM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > >> >> >> Is it worth it? I think it is. But I am not sure I see the whole picture - >> are there low-memory systems that need to run LLVM on? >> >> I am not sure what needs to be done to approve such a fundamental change; >> especially when we

Hi all, The AsmPrinter class supports functions like EmitInt8, EmitInt16, and EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these calls the MCStreamer::EmitIntValue method with the corresponding size. For some reason, there is no EmitInt64, and I was wondering if there was a fundamental reason why? The EmitIntValue function appears to support 8-byte inputs. I dug into

Ok, I give up. I tried, really hard, before asking but I must be the most stupid shorewall user on the planet :( My laptop runs a single eth0 interface and knows Net and Firewall as zones and the default "inbound" policies are Net->Any DROP and >ny->Any REJECT. Now at home I have my trusted 192.168.174.240/29 subnet which hosts my very trusted 192.168.174.242 host and I