similar to: [LLVMdev] gcc's -Wuninitialized

On Thu, Jan 3, 2013 at 11:16 AM, <dag at cray.com> wrote: > David Blaikie <dblaikie at gmail.com> writes: > >> Selfhost clang. Whenever we get a warning from Clang we either fix >> Clang or fix the build quite quickly. > > Not possible, Out of curiosity - why not? (sure, I realize everyone has internal build systems, etc, that they're ultimately

David Blaikie <dblaikie at gmail.com> writes: > Selfhost clang. Whenever we get a warning from Clang we either fix > Clang or fix the build quite quickly. Not possible, > If you want to fix the build such that LLVM can be built -Werror clean > with GCC the right solution is going to be to turn off -Wuninitialized > when the LLVM build system detects that it is using GCC

Chandler Carruth <chandlerc at google.com> writes: > The implementations of -Wuninitialized, -Wreturn-type, and a few other > GCC warnings are extremely aggressive. They have high false positive > rates with few benefits. We regularly keep -Wreturn-type working > despite this (see all of the llvm_unreachable after switch > statements), So why not add -Wno-uninitialized and

On Thu, Jan 3, 2013 at 10:52 AM, <dag at cray.com> wrote: > David Blaikie <dblaikie at gmail.com> writes: > >> The other point Chandler was making, though, was that this sort of fix >> means that other tools (Valgrind/MemSan) won't catch a broader class >> of errors because we will have silenced them too. > > Does buildbot do a valgrind build with the

David Blaikie <dblaikie at gmail.com> writes: >>> Selfhost clang. Whenever we get a warning from Clang we either fix >>> Clang or fix the build quite quickly. >> >> Not possible, > > Out of curiosity - why not? (sure, I realize everyone has internal > build systems, etc, that they're ultimately integrating LLVM into - > but that doesn't mean

"Caldarale, Charles R" <Chuck.Caldarale at unisys.com> writes: >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of greened at obbligato.org >> Subject: Re: [LLVMdev] Build Failure > >> It seems a better option than simply ignoring warnings and then missing >> a real bug in the haystack of warning

On Wed, Apr 24, 2013 at 6:00 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > Hello, > > We've had a high priority feature request from a number of our customers > to > provide per-function optimization in our Clang/LLVM compiler. > I would be interested in working with the community to implement this. > The idea is to allow the optimization level to be overridden >

On Thu, Jan 3, 2013 at 8:22 AM, <dag at cray.com> wrote: > "Caldarale, Charles R" <Chuck.Caldarale at unisys.com> writes: > >>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >>> On Behalf Of greened at obbligato.org >>> Subject: Re: [LLVMdev] Build Failure >> >>> It seems a better option than

Hi all: Does anyone have a similar problem? Any Suggestions? THX! 2019-07-18 11:49:14，"netsurfed" <zhuohaofan@126.com> ： Hi all: Unable to install libvirt v5.5.0 correctly through the source code which clone from git. The error message is shown below. libtool: install: (cd /home/libvirt/src; /bin/sh /home/libvirt/libtool --silent --tag CC --mode=relink gcc

On 1/2/2013 10:37 PM, greened at obbligato.org wrote: > Chandler Carruth <chandlerc at google.com> writes: > >> but the fix to silence GCC's -Wuninitialized false positives actively >> degrades the quality of the code -- it forces dead stores to >> variables. These dead stores are a waste and prevent tools like >> Valgrind from finding very real bugs in the

Especially since we have support for per function code gen attributes now. -eric On Wed, Apr 24, 2013 at 3:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, Apr 24, 2013 at 6:00 AM, <Andrea_DiBiagio at sn.scee.net> wrote: >> >> Hello, >> >> We've had a high priority feature request from a number of our customers >> to >>

On Fri, Sep 25, 2020 at 10:03 AM Wei Wang <weiwangcloud2020@gmail.com> wrote: > On Thu, Sep 24, 2020 at 2:58 PM Ján Tomko <jtomko@redhat.com> wrote: > >> On a Thursday in 2020, Wei Wang wrote: >> >Seems it didn't appear on the mailing list, resent it. >> > >> > Hi folks, >> > >> >I'm trying to build libvirt using meson

On Wed, Aug 08, 2018 at 10:58:50AM +0200, Holger Schranz wrote: > checking for JANSSON... no This is the problem. In 4.6.0 we just switched to using JANSSOn instead of yajl for JSON parsing. Your host doesn't have the development headers installed for jansson.... > configure: > configure: Configuration summary > configure: ===================== > configure: > configure:

Hi all: Unable to install libvirt v5.5.0 correctly through the source code which clone from git. The error message is shown below. libtool: install: (cd /home/libvirt/src; /bin/sh /home/libvirt/libtool --silent --tag CC --mode=relink gcc -std=gnu99 -I/usr/include/libxml2 -fno-common -W -Waddress -Waggressive-loop-optimizations -Wall -Wattributes -Wbad-function-cast -Wbuiltin-macro-redefined

Verifying a report I just got pinged about, building vanilla openssh 7.7p1 on linux configures ok, but fails build around 'retpoline' I've started looking through recent reports; haven't _yet_ found anything similar. While I continue, is any of the following familiar/expected? Either known bug/issue or env conflict? The current env includes supposedly retpoline-ready GCC 8.1.1,

Hello, We've had a high priority feature request from a number of our customers to provide per-function optimization in our Clang/LLVM compiler. I would be interested in working with the community to implement this. The idea is to allow the optimization level to be overridden for specific functions. The rest of this proposal is organized as follows: - Section 1. describes this new feature

This problem actually came up with pdftex-1.40, which now uses the openbsd-compat code. I routinely build pdftex with c99 to reduce reliance on old gcc extensions, in the hope that things will be more consistent across linux and unix. I think the problem is that the way configure checks for strsep leaves things open for a #def'd version to conflict with the replacement version. I'm

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of greened at obbligato.org > Subject: Re: [LLVMdev] Build Failure > It seems a better option than simply ignoring warnings and then missing > a real bug in the haystack of warning messages. Definitely agree with that. Our project coding standards require _zero_ warnings at commit time (but

Hello I apologize in advance for my English. I compiled the new version of libvirt 1.2.8 on an environment Development Linux from Scratch with the following configure: configure: Configuration summary configure: ===================== configure: configure: Drivers configure: configure: Xen: no configure: QEMU: yes configure: UML: yes configure: OpenVZ: no configure: VMware:

> Thanks for the report. That is disabling quite a lot of drivers (what > is still left, lxc?), so it's a combination that has not gotten a lot of > testing. I'll definitely look at fixing it before 1.2.8 is released, > although it may miss release candidate 0. It's no problem of configure options. Simple ./configure result: configure: configure: Configuration summary