LLVM Compiler Social, Towards Lean 4 -- An Optimized Object Model for an Interactive Theorem Prover (Wednesday 12th)
Dear all, WEDNESDAY 12th Dec, 19:00, we will have Sebastian Ullrich presenting on the Zurich LLVM Compiler Social: === Towards Lean 4: An Optimized Object Model for an Interactive Theorem Prover Lean 4, the next version of the Lean theorem prover, will move most of its frontend code from C++ to Lean itself. To ensure that the resulting code is reasonably efficient, Lean 4 will feature a new code generation backend together with a new object and memory management model. In this talk, I will discuss the general and ITP-specific constraints, such as performance, language interoperability, and startup time, that led us to this model and how we are planning to solve them with it. Sebastian Ullrich is a second-year PhD student at Gregor Snelting's programming paradigms group at the Karlsruhe Institute of Technology (KIT). He is working on the Lean theorem prover together with Leonardo de Moura (Microsoft Research). Sebastian's research interests are program verification, the design of interactive theorem proving frontends, and macro expansion. === # Registration https://www.meetup.com/llvm-compiler-and-code-generation-socials-zurich/events/vxmqlqyxqbrb/ # What A social meetup to discuss compilation and code generation questions with a focus on LLVM, clang, Polly and related projects. Our primary focus is to provide a venue (and drinks & snacks) that enables free discussions between interested people without imposing an agenda/program. This is a great opportunity to informally discuss your own projects, get project ideas or just learn about what people at ETH and around Zurich are doing with LLVM. Related technical presentations held by participants are welcome (please contact us). # Who: - Anybody interested - - ETH students and staff - LLVM developers and enthusiasts external to ETH # When: 12.12.2018, 19:00 # Where: CAB E 72, ETH Zurich Best, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Zurich LLVM Compiler Social, Tech-Talks: Compilers meet Isabelle & The Lean Theorem Prover (Thursday 13th)
Dear LLVM and compiler interested people, next Thursday, 19:00, we will have two exciting tech-talks at the LLVM compiler social! # The Lean Theorem Prover Lean is a new theorem prover using dependent type theory (DTT). Lean 3 gained support for meta programming, employing dependent types not only as logic but also as a programming language. Lean as a programming language is used to implement tactics in Lean itself. In this talk I want to give an overview of Lean, its meta programming framework, its (mathematical) library and current projects. Bio: Johannes Hoelzl is since 2018 a postdoc at the VU Amsterdam working on the Matryoshka project and comaintaining Lean's mathematical library. In 2017, he did a postdoc with Jeremy Avigad (CMU). From 2009 to 2016 he was a PhD student and postdoc in Tobias Nipkow's Isabelle group at TU München. His main topic was Isabelle's analysis and probability theory. He, working with theorem provers since 2005. # Compilers meet Isabelle Abstract: Isabelle is an interactive proof assistant. Isabelle assists its users in writing functional programs and proofs about these and meticulously checks the proofs' correctness. This talk will consist of two parts. The first part will be a hands-on introduction to Isabelle, in which we develop an interpreter for a simple, Turing-complete programming language and verify a simple source-code transformation. The second part will outline what it takes to prove a compiler for a more realistic programming language correct. Speakers: Dmitriy Traytel (1st part) and Andreas Lochbihler (2nd part) Bio: Dmitriy Traytel is a senior researcher in David Basin's information security group at ETH Zürich working on runtime verification and monitoring. He completed his PhD in 2015 in Tobias Nipkow's logic and verification group at TU München—the home of the Isabelle proof assistant. Dmitriy is both a developer and a user of Isabelle. Andreas Lochbihler is a formal methods engineer at Digital Asset. From 2013 to 2018, Andreas was a senior researcher in the Information Security Group at ETH Zürich. His research revolved around the theory and tools to formalise protocols and their proofs such that definitions and proofs can be check mechanically. His framework CryptHOL brings to cryptography the expressiveness and rigour of higher-order logic and coalgebraic methods as implemented in the proof assistant Isabelle/HOL. Before joining ETH, he was a member of Programming Paradigms group at the Karlsruhe Institute of Technology and of the Sofware Systems group at the University of Passau. In his thesis, he built a formal model of Java concurrency which formalises source code, bytecode, a virtual machine, the compiler and the Java memory model in Isabelle/HOL. # Registration https://www.meetup.com/llvm-compiler-and-code-generation-socials-zurich/events/cbffknyxlbmb/ # What A social meetup to discuss compilation and code generation questions with a focus on LLVM, clang, Polly and related projects. Our primary focus is to provide a venue (and drinks & snacks) that enables free discussions between interested people without imposing an agenda/program. This is a great opportunity to informally discuss your own projects, get project ideas or just learn about what people at ETH and around Zurich are doing with LLVM. Related technical presentations held by participants are welcome (please contact us). # Who: - Anybody interested - - ETH students and staff - LLVM developers and enthusiasts external to ETH # When: 13.09.2018, 19:00 # Where: CAB E 72, ETH Zurich # What is LLVM ? LLVM (http://www.llvm.org) is an open source project that provides a collection of modular compiler and toolchain technologies. It is centered around a modern SSA-based compiler around which an entire ecosystem of compiler technology was developed. Most well know is the clang C++ compiler, which is e.g. used to deploy iOS. Beyond this a diverse set of projects is developed under the umbrella of LLVM. These include code generators and assemblers for various interesting architectures, a jit compiler, a debugger, run-time libraries (C++ Standard Library, OpenMP, Opencl library), program sanity checkers, and many more. LLVM has itself grown out of a research project more than 10 years ago and is the base of many exciting research projects today: https://scholar.google.ch/scholar?cites=7792455789532680075&as_sdt=2005&sciodt=0,5&hl=de Best, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: This Thursday -> LLVM Compiler Social, Tech-Talk: Deep Learning is the Killer App for Polyhedral Compilation
On Mon, Aug 6, 2018, at 15:42, Tobias Grosser wrote: > Dear LLVM and compiler interested people, > > this Thursday, 19:00, Dr. Oleksandre Zinenko will present Tensor- > Comprehension, a Deep-Learning compiler jointly developed by Facebook, > ENS Paris, and ETH Zurich at the LLVM compiler social. > > Tech-Talk: Deep Learning is the Killer App for Polyhedral Compilation > > Deep learning approaches are successfully applied to an increasingly > large number of real-world problems, such as computer vision, speech or > weather prediction. Their efficiency comes at a high computational and > energy price. While the deep learning kernels are qualified as > “embarrassingly parallel”, their implementations often fall > short of exploiting the full power of modern parallel hardware. We > propose Tensor Comprehensions, a new domain-specific language for deep > learning workloads and a compilation flow combining more (LLVM) or less > (polyhedral, in-process autotuning) conventional techniques. The > language is restricted by design to the computations that can be > effectively analyzed in the polyhedral model, yet it covers the vast > majority of DL layers. Polyhedral transformation happens at a higher > level than in existing tools, directly capturing the relevant > information that otherwise would have to be extracted from a lower-level > intermediate representation. Currently, Tensor Comprehensions targets > NVidia GPUs through NVRTC or LLVM’s PTX backend, and modern CPUs > with vectorization and optional parallelization through the Tapir > extension of the LLVM IR. Initial evaluations show up to 4x speedups > over vendor-provided libraries on computational kernels relevant to deep > learning. > > Oleksandr Zinenko is a research engineer at Inria and École > Normale Supérieure in Paris, France working on usability and > scalability of polyhedral compilation. He obtained his PhD from > University Paris-Saclay for the work on interactive program > restructuring. Oleksandr’s research interests include polyhedral > compilation, program optimization and programming languages, all from a > developer-centric viewpoint. He is a co-author of an interactive toolset > to promote and disseminate polyhedral compilation techniques. > > # Registration > > https://www.meetup.com/llvm-compiler-and-code-generation-socials-zurich/events/245320826/ https://www.meetup.com/llvm-compiler-and-code-generation-socials-zurich/events/cbffknyxlbmb/ > # What > > A social meetup to discuss compilation and code generation questions > with a focus on LLVM, clang, Polly and related projects. > > Our primary focus is to provide a venue (and drinks & snacks) that > enables free discussions between interested people without imposing an > agenda/program. This is a great opportunity to informally discuss your > own projects, get project ideas or just learn about what people at ETH > and around Zurich are doing with LLVM. > > Related technical presentations held by participants are welcome (please > contact us). > > # Who: - Anybody interested - > > - ETH students and staff > - LLVM developers and enthusiasts external to ETH > > # When: 09.08.2018, 19:00 > > # Where: CAB E 72 > > # What is LLVM ? > > LLVM (http://www.llvm.org) is an open source project that provides a > collection of modular compiler and toolchain technologies. It is > centered around a modern SSA-based compiler around which an entire > ecosystem of compiler technology was developed. Most well know is the > clang C++ compiler, which is e.g. used to deploy iOS. Beyond this a > diverse set of projects is developed under the umbrella of LLVM. These > include code generators and assemblers for various interesting > architectures, a jit compiler, a debugger, run-time libraries (C++ > Standard Library, OpenMP, Opencl library), program sanity checkers, and > many more. > > LLVM has itself grown out of a research project more than 10 years ago > and is the base of many exciting research projects today: > > https://scholar.google.ch/scholar?cites=7792455789532680075&as_sdt=2005&sciodt=0,5&hl=de > > Best, > Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
This Thursday -> LLVM Compiler Social, Tech-Talk: Deep Learning is the Killer App for Polyhedral Compilation
Dear LLVM and compiler interested people, this Thursday, 19:00, Dr. Oleksandre Zinenko will present Tensor-Comprehension, a Deep-Learning compiler jointly developed by Facebook, ENS Paris, and ETH Zurich at the LLVM compiler social. Tech-Talk: Deep Learning is the Killer App for Polyhedral Compilation Deep learning approaches are successfully applied to an increasingly large number of real-world problems, such as computer vision, speech or weather prediction. Their efficiency comes at a high computational and energy price. While the deep learning kernels are qualified as “embarrassingly parallel”, their implementations often fall short of exploiting the full power of modern parallel hardware. We propose Tensor Comprehensions, a new domain-specific language for deep learning workloads and a compilation flow combining more (LLVM) or less (polyhedral, in-process autotuning) conventional techniques. The language is restricted by design to the computations that can be effectively analyzed in the polyhedral model, yet it covers the vast majority of DL layers. Polyhedral transformation happens at a higher level than in existing tools, directly capturing the relevant information that otherwise would have to be extracted from a lower-level intermediate representation. Currently, Tensor Comprehensions targets NVidia GPUs through NVRTC or LLVM’s PTX backend, and modern CPUs with vectorization and optional parallelization through the Tapir extension of the LLVM IR. Initial evaluations show up to 4x speedups over vendor-provided libraries on computational kernels relevant to deep learning. Oleksandr Zinenko is a research engineer at Inria and École Normale Supérieure in Paris, France working on usability and scalability of polyhedral compilation. He obtained his PhD from University Paris-Saclay for the work on interactive program restructuring. Oleksandr’s research interests include polyhedral compilation, program optimization and programming languages, all from a developer-centric viewpoint. He is a co-author of an interactive toolset to promote and disseminate polyhedral compilation techniques. # Registration https://www.meetup.com/llvm-compiler-and-code-generation-socials-zurich/events/245320826/ # What A social meetup to discuss compilation and code generation questions with a focus on LLVM, clang, Polly and related projects. Our primary focus is to provide a venue (and drinks & snacks) that enables free discussions between interested people without imposing an agenda/program. This is a great opportunity to informally discuss your own projects, get project ideas or just learn about what people at ETH and around Zurich are doing with LLVM. Related technical presentations held by participants are welcome (please contact us). # Who: - Anybody interested - - ETH students and staff - LLVM developers and enthusiasts external to ETH # When: 09.08.2018, 19:00 # Where: CAB E 72 # What is LLVM ? LLVM (http://www.llvm.org) is an open source project that provides a collection of modular compiler and toolchain technologies. It is centered around a modern SSA-based compiler around which an entire ecosystem of compiler technology was developed. Most well know is the clang C++ compiler, which is e.g. used to deploy iOS. Beyond this a diverse set of projects is developed under the umbrella of LLVM. These include code generators and assemblers for various interesting architectures, a jit compiler, a debugger, run-time libraries (C++ Standard Library, OpenMP, Opencl library), program sanity checkers, and many more. LLVM has itself grown out of a research project more than 10 years ago and is the base of many exciting research projects today: https://scholar.google.ch/scholar?cites=7792455789532680075&as_sdt=2005&sciodt=0,5&hl=de Best, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r290084 - clang-format: Allow "single column" list layout even if that violates the
On Mon, Dec 19, 2016, at 09:07 AM, Daniel Jasper wrote:
> Yeah, I just saw that when fixing polly format. I'll take a look.
You then probably also saw the second issue:
-Type *Params[] = {PointerType::getUnqual(FunctionType::get(
- Builder.getVoidTy(), Builder.getInt8PtrTy(),
false)),
- Builder.getInt8PtrTy(), Builder.getInt32Ty(),
LongType,
- LongType, LongType};
+Type *Params[] = {
+PointerType::getUnqual(FunctionType::get(Builder.getVoidTy(),
Builder.getInt8PtrTy(), false)),
+Builder.getInt8PtrTy(),
+Builder.getInt32Ty(),
+LongType,
+LongType,
+LongType};
The lines are now longer than 80 columns, whereas earlier we managed to
remain within 80 columns.
Btw. thank you for updating Polly.
Best,
Tobias
> On Mon, Dec 19, 2016 at 9:05 AM, Tobias Grosser
> wrote:
>
> > Hi Daniel,
> >
> > this commit introduce an unnecessary string split, which does not seem
> > to be an intended result of the formatting style change this commit
> > introduced:
> >
> > BEFORE:
> >
> > #define SCOP_STAT(NAME, DESC)
> >
> > llvm::Statistic RejectStatistics[] = {
> > SCOP_STAT(CFG, ""),
> > SCOP_STAT(InvalidTerminator, "Unsupported terminator instruction"),
> > SCOP_STAT(IrreducibleRegion, "Irreducible loops"),
> > SCOP_STAT(UndefCond, "Undefined branch condition"),
> > SCOP_STAT(NonSimpleMemoryAccess,
> > "Compilated access semantics (volatile or atomic)"),
> > };
> >
> > AFTER:
> >
> > #define SCOP_STAT(NAME, DESC)
> >
> > llvm::Statistic RejectStatistics[] = {
> > SCOP_STAT(CFG, ""),
> > SCOP_STAT(InvalidTerminator, "Unsupported terminator instruction"),
> > SCOP_STAT(IrreducibleRegion, "Irreducible loops"),
> > SCOP_STAT(UndefCond, "Undefined branch condition"),
> > SCOP_STAT(NonSimpleMemoryAccess, "Compilated access semantics
> > (volatile or "
> > "atomic)"
> >
> > As this worked before, this seems to be a regression.
> >
> > Best,
> > Tobias
> >
> > On Mon, Dec 19, 2016, at 08:26 AM, Daniel Jasper via cfe-commits wrote:
> > > Author: djasper
> > > Date: Mon Dec 19 01:26:11 2016
> > > New Revision: 290084
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=290084&view=rev
> > > Log:
> > > clang-format: Allow "single column" list layout even if that violates the
> > > column limit.
> > >
> > > Single-column layout basically means that we format the list with one
> > > element per line. Not doing that when there is a column limit violation
> > > doesn't change the fact that there is an item that doesn't fit within
> > > the column limit.
> > >
> > > Before (with a column limit of 30):
> > > std::vector a = {
> > > , ,
> > > , ,
> > > aa, ,
> > > aaa};
> > >
> > > After:
> > > std::vector a = {
> > > ,
> > > ,
> > > ,
> > > ,
> > > aa,
> > > ,
> > > aaa};
> > >
> > > (and previously we would have formatted like "After" it wasn't for the
> > > one
> > > item that is too long)
> > >
> > > Modified:
> > > cfe/trunk/lib/Format/FormatToken.cpp
> > > cfe/trunk/unittests/Format/FormatTest.cpp
> > >
> > > Modified: cfe/trunk/lib/Format/FormatToken.cpp
> > > URL:
> > > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/
> > FormatToken.cpp?rev=290084&r1=290083&r2=290084&view=diff
> > >
> > ==
> > > --- cfe/trunk/lib/Format/FormatToken.cpp (original)
> > > +++ cfe/trunk/lib/Format/FormatToken.cpp Mon Dec 19 01:26:11 2016
> > > @@ -273,7 +273,7 @@ void CommaSeparatedList::precomputeForma
> > >continue;
> > >
> > > // Ignore layouts that are bound to violate the column limit.
> > > -if (Format.TotalWidth > Style.ColumnLimit)
> > > +if (Format.TotalWidth > Style.ColumnLimit && Columns > 1)
> > >continue;
> > >
> > > Formats.push_back(Format);
> > > @@ -287,7 +287,7 @@ CommaSeparatedList::getColumnFormat(unsi
> > > I = Formats.rbegin(),
> > > E = Formats.rend();
> > > I != E; ++I) {
> > > -if (I->TotalWidth <= RemainingCharacters) {
> > > +if (I->TotalWidth <= RemainingCharacters || I->Columns == 1) {
> > >if (BestFormat && I->LineCount > BestFormat->LineCount)
> > > break;
> > >BestFormat = &*I;
> > >
> > > Modified: cfe/trunk/unittests/Format/FormatTest.cpp
> > > URL:
> > > http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/
> > Format/FormatTest.cpp?rev=290084&r1=290083&r2=290084&view=diff
> > >
> > ==
> > > --- cfe/trunk/unittests/Format/FormatTest.cpp (original)
> > > +++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Dec 19 01:26:1
Re: r290084 - clang-format: Allow "single column" list layout even if that violates the
Hi Daniel,
this commit introduce an unnecessary string split, which does not seem
to be an intended result of the formatting style change this commit
introduced:
BEFORE:
#define SCOP_STAT(NAME, DESC)
llvm::Statistic RejectStatistics[] = {
SCOP_STAT(CFG, ""),
SCOP_STAT(InvalidTerminator, "Unsupported terminator instruction"),
SCOP_STAT(IrreducibleRegion, "Irreducible loops"),
SCOP_STAT(UndefCond, "Undefined branch condition"),
SCOP_STAT(NonSimpleMemoryAccess,
"Compilated access semantics (volatile or atomic)"),
};
AFTER:
#define SCOP_STAT(NAME, DESC)
llvm::Statistic RejectStatistics[] = {
SCOP_STAT(CFG, ""),
SCOP_STAT(InvalidTerminator, "Unsupported terminator instruction"),
SCOP_STAT(IrreducibleRegion, "Irreducible loops"),
SCOP_STAT(UndefCond, "Undefined branch condition"),
SCOP_STAT(NonSimpleMemoryAccess, "Compilated access semantics
(volatile or "
"atomic)"
As this worked before, this seems to be a regression.
Best,
Tobias
On Mon, Dec 19, 2016, at 08:26 AM, Daniel Jasper via cfe-commits wrote:
> Author: djasper
> Date: Mon Dec 19 01:26:11 2016
> New Revision: 290084
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290084&view=rev
> Log:
> clang-format: Allow "single column" list layout even if that violates the
> column limit.
>
> Single-column layout basically means that we format the list with one
> element per line. Not doing that when there is a column limit violation
> doesn't change the fact that there is an item that doesn't fit within
> the column limit.
>
> Before (with a column limit of 30):
> std::vector a = {
> , ,
> , ,
> aa, ,
> aaa};
>
> After:
> std::vector a = {
> ,
> ,
> ,
> ,
> aa,
> ,
> aaa};
>
> (and previously we would have formatted like "After" it wasn't for the
> one
> item that is too long)
>
> Modified:
> cfe/trunk/lib/Format/FormatToken.cpp
> cfe/trunk/unittests/Format/FormatTest.cpp
>
> Modified: cfe/trunk/lib/Format/FormatToken.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatToken.cpp?rev=290084&r1=290083&r2=290084&view=diff
> ==
> --- cfe/trunk/lib/Format/FormatToken.cpp (original)
> +++ cfe/trunk/lib/Format/FormatToken.cpp Mon Dec 19 01:26:11 2016
> @@ -273,7 +273,7 @@ void CommaSeparatedList::precomputeForma
>continue;
>
> // Ignore layouts that are bound to violate the column limit.
> -if (Format.TotalWidth > Style.ColumnLimit)
> +if (Format.TotalWidth > Style.ColumnLimit && Columns > 1)
>continue;
>
> Formats.push_back(Format);
> @@ -287,7 +287,7 @@ CommaSeparatedList::getColumnFormat(unsi
> I = Formats.rbegin(),
> E = Formats.rend();
> I != E; ++I) {
> -if (I->TotalWidth <= RemainingCharacters) {
> +if (I->TotalWidth <= RemainingCharacters || I->Columns == 1) {
>if (BestFormat && I->LineCount > BestFormat->LineCount)
> break;
>BestFormat = &*I;
>
> Modified: cfe/trunk/unittests/Format/FormatTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=290084&r1=290083&r2=290084&view=diff
> ==
> --- cfe/trunk/unittests/Format/FormatTest.cpp (original)
> +++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Dec 19 01:26:11 2016
> @@ -6779,6 +6779,18 @@ TEST_F(FormatTest, FormatsBracedListsInC
>" 1, 22, 333, , 5, 66,
>777,\n"
>" 1, 22, 333, , 5, 66,
>777,\n"
>" 1, 22, 333, , 5, 66,
>777});");
> +
> + // Allow "single-column" layout even if that violates the column
> limit. There
> + // isn't going to be a better way.
> + verifyFormat("std::vector a = {\n"
> + ",\n"
> + ",\n"
> + ",\n"
> + ",\n"
> + "aa,\n"
> + ",\n"
> + "aaa};",
> + getLLVMStyleWithColumns(30));
> }
>
> TEST_F(FormatTest, PullTrivialFunctionDefinitionsIntoSingleLine) {
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: Buildbot numbers for week of 11/22/2015 - 11/28/2015
On 12/01/2015 02:05 AM, David Blaikie wrote: On Mon, Nov 30, 2015 at 5:00 PM, Galina Kistanova mailto:gkistan...@gmail.com>> wrote: Hi David, Thank you for the useful suggestions, I will work on these. >I guess the entries with no entry in the failed column have zero failures? Yes. perf-x86_64-penryn-O3-polly-before-vectorizer | 31 | 31 | perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 31 | 27 | 05:28:12 These /\ two builders failed most of the time, but they also only ran a handful of times. I guess they're triggering off polly changes only? I wonder if they should trigger off LLVM changes too, but I'm not sure. They build on llvm changes also, but they both build for quite a long time. I think it's the reason why they do not build more. Ah, OK - so the other suggestions might help demonstrate/understand that behavior better. These buildbots run performance tests, meaning they run the LNT test suite 10 times per run to get stable results. They are triggered on any LLVM/clang/Polly test but do not run more often just because we do not have more hardware to run them more often. The relevant buildslave is constantly building something. Tobias - any idea why these builders are /quite/ so slow & whether they could be improved? With large blame lists that come from a small number of slaves on a slow builder task it makes them hard to action. Are they useful to you? These bots do _not_ send out any emails, exactly for this reason. But yes, they are very useful to quickly get an idea of our current compile-time/run-time performance. Thanks for you taking care of the buildbot noise. If my bots cause any issue for you, please let me know. Ensuring low noise is very important. Best, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r252474 - Create install targets for scan-build and scan-view
On 11/10/2015 11:42 PM, Jonathan Roelofs wrote: Fixed for real in r252662. Confirmed. Thank you for addressing this so quickly. Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r252474 - Create install targets for scan-build and scan-view
On 11/10/2015 09:05 PM, Jonathan Roelofs wrote: On 11/10/15 12:48 PM, Tobias Grosser wrote: On 11/09/2015 05:12 PM, Jonathan Roelofs via cfe-commits wrote: Author: jroelofs Date: Mon Nov 9 10:12:56 2015 New Revision: 252474 URL: http://llvm.org/viewvc/llvm-project?rev=252474&view=rev Log: Create install targets for scan-build and scan-view Hi Jonathan, this is probably not the commit that introduced this specific issue, but since updating today my cmake ninja builds always run: "[2/2] Running utility command for scan-view" even without me changing any files. Before ninja would just report that no work needs to be done. I assume this change is related to some of the recent scan-view change and was likely unintended. Can you please try out r252641? I think that should fix what you're seeing. I just updated and see this still. Do you see this with ninja/cmake as well? Best, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r252474 - Create install targets for scan-build and scan-view
On 11/09/2015 05:12 PM, Jonathan Roelofs via cfe-commits wrote: Author: jroelofs Date: Mon Nov 9 10:12:56 2015 New Revision: 252474 URL: http://llvm.org/viewvc/llvm-project?rev=252474&view=rev Log: Create install targets for scan-build and scan-view Hi Jonathan, this is probably not the commit that introduced this specific issue, but since updating today my cmake ninja builds always run: "[2/2] Running utility command for scan-view" even without me changing any files. Before ninja would just report that no work needs to be done. I assume this change is related to some of the recent scan-view change and was likely unintended. Best, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r250824 - Apply modernize-use-default to clang-tools-extra.
On 10/20/2015 11:37 PM, David Blaikie wrote: On Tue, Oct 20, 2015 at 2:24 PM, Tobias Grosser via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: On 10/20/2015 02:56 PM, Angel Garcia Gomez via cfe-commits wrote: Author: angelgarcia Date: Tue Oct 20 07:56:27 2015 New Revision: 250824 URL: http://llvm.org/viewvc/llvm-project?rev=250824&view=rev Log: Apply modernize-use-default to clang-tools-extra. Summary: Replace empty bodies of default constructors and destructors with '= default'. Hi Angel, this breaks http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3. The builder runs gcc 4.7.2. Ah, I was/am seeing this on the GDB 7.5 buildbot too - but figured it might be GCC 4.6, because I couldn't reproduce similar behavior in small samples on GCC 4.7, but it might be that I have GCC 4.7.3 locally, not 4.7.2... I think I have some ideas on how to fix this while keeping the change, but probably best to revert first, then try some things once we've got a reproduction locally to experiment with. (I think maybe Optional and possibly some other types are missing noexcept on their user-defined dtors, and GCC 4.old is assuming user defined dtors are noexcept(false), which is incorrect in C++11) This seems to be the same issue (or at least a similar issue) to what we had seen in the Polly source. It would be interesting to understand what is going on. Best, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r250824 - Apply modernize-use-default to clang-tools-extra.
On 10/20/2015 02:56 PM, Angel Garcia Gomez via cfe-commits wrote: Author: angelgarcia Date: Tue Oct 20 07:56:27 2015 New Revision: 250824 URL: http://llvm.org/viewvc/llvm-project?rev=250824&view=rev Log: Apply modernize-use-default to clang-tools-extra. Summary: Replace empty bodies of default constructors and destructors with '= default'. Hi Angel, this breaks http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3. The builder runs gcc 4.7.2. This version is clearly not the most recent one, but still belongs to the set of gcc versions we currently document as supported: http://llvm.org/docs/GettingStarted.html#software Could you please revert this change. Thank you, Tobias ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
