search for: trieu

...{} }; A getA() { return A(1); } B run1() { A a = getA(); return std::move(a); } B run2() { A a = getA(); return a; } int main() { std::cout << "with move:\n"; run1(); std::cout << "no move:\n"; run2(); } On Tue, Sep 18, 2018 at 4:07 PM Richard Trieu <rtrieu at google.com> wrote: > I'll look into the pessimizing move warning, then after that, the > deprecated copy warning. > > On Sun, Sep 16, 2018 at 10:41 AM Richard Smith <richard at metafoo.co.uk> > wrote: > >> Yes, we should produce this warning in C+...

Krzysztof, lib/Target/Hexagon/HexagonDepDecoders.h is marked as generated code and I should consult you, as code owner, before changing. As this file is not a stand-alone header (does not compile alone, no header guards, is included in the middle of other files) it should not have the .h extension. I propose that this file be renamed to have .inc extension to be consistent with the coding

...Guillaume Papin <guillaume.papin at epitech.eu>, Matt Arsenault < Matthew.Arsenault at amd.com>, Matthias Braun <matze at braunis.de>, Philip Reames <listmail at philipreames.com>, Piotr Padlewski <prazek at google.com>, Reid Kleckner <rnk at google.com>, Richard Trieu <rtrieu at google.com>, Sanjay Patel <spatel at rotateright.com>, Sanjoy Das <sanjoy at playingwithpointers.com>, Sean Silva <chisophugis at gmail.com>, Weiming Zhao <weimingz at codeaurora.org> Cc: gkistanova at gmail.com The Buildbot has detected a new failure on b...

...>, > > Matt Arsenault < Matthew.Arsenault at amd.com >, Matthias Braun < > > matze at braunis.de >, Philip Reames < listmail at philipreames.com >, > > Piotr Padlewski < prazek at google.com >, Reid Kleckner < > > rnk at google.com >, Richard Trieu < rtrieu at google.com >, Sanjay Patel > > < spatel at rotateright.com >, Sanjoy Das < > > sanjoy at playingwithpointers.com >, Sean Silva < chisophugis at gmail.com > > >, Weiming Zhao < weimingz at codeaurora.org > > > Cc: gkistanova at gmail....

I think I found the problem: https://opia.illinois.edu/content/targeted-attack-protection-tuning UIUC is apparently rewriting HTML links in emails to redirect through urldefense.proofpoint.com. This is visible in my version of Rui's email. On Wed, May 27, 2015 at 9:36 AM, Rui Ueyama <ruiu at google.com> wrote: > I sent the mail from Gmail. I checked the source using the Gmail

Yes, we should produce this warning in C++11 mode too. (I could be misrecalling, but I think the rationale for the current behaviour is based on historical GCC behaviour.) On Sun, 16 Sep 2018, 10:04 David Blaikie via cfe-dev, < cfe-dev at lists.llvm.org> wrote: > Fair point made on that thread - that this is a DR, so technically the > std::move is pessimizing even in C++11 mode.

I see that the following test fails if reverse iteration of SmallPtrSet is enabled: /clang/test/SemaCXX/warn-loop-analysis.cpp/ This is because in SemaStmt.cpp we iterate SmallPtrSet and output warnings about the variables not used in the loop. Expected output: /warning: variables 'i', 'j', and 'k' used in loop condition not modified/ Output with reverse iteration:

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

...g on WRT ODR checking & >> how this feature integrates or doesn't with their work? I imagine they >> might be working on something more like a Clang Tooling style approach, but >> I'm not sure. >> > > I'm not aware of any work like that, only of Richard Trieu's efforts for > modules that I'm piggybacking on. > +Djasper - perhaps you could provide some context on other odr detection efforts? > Peter > >> >> - Dave >> >> >>> >>> Peter >>> >>>> >>>> >>&g...

...this feature integrates or doesn't with their work? I imagine they >>>> might be working on something more like a Clang Tooling style approach, but >>>> I'm not sure. >>>> >>> >>> I'm not aware of any work like that, only of Richard Trieu's efforts for >>> modules that I'm piggybacking on. >>> >> >> +Djasper - perhaps you could provide some context on other odr detection >> efforts? >> >> >>> Peter >>> >>>> >>>> - Dave >>>>...

...this feature integrates or doesn't with their work? I imagine they >>>> might be working on something more like a Clang Tooling style approach, but >>>> I'm not sure. >>>> >>> >>> I'm not aware of any work like that, only of Richard Trieu's efforts for >>> modules that I'm piggybacking on. >>> >> >> +Djasper - perhaps you could provide some context on other odr detection >> efforts? >> >> >>> Peter >>> >>>> >>>> - Dave >>>>...

...with their work? I imagine they >>>>>> might be working on something more like a Clang Tooling style approach, but >>>>>> I'm not sure. >>>>>> >>>>> >>>>> I'm not aware of any work like that, only of Richard Trieu's efforts >>>>> for modules that I'm piggybacking on. >>>>> >>>> >>>> +Djasper - perhaps you could provide some context on other odr >>>> detection efforts? >>>> >>>> >>>>> Peter >&gt...

...gt;>> imagine they might be working on something more like a Clang Tooling style >>>>>>>> approach, but I'm not sure. >>>>>>>> >>>>>>> >>>>>>> I'm not aware of any work like that, only of Richard Trieu's efforts >>>>>>> for modules that I'm piggybacking on. >>>>>>> >>>>>> >>>>>> +Djasper - perhaps you could provide some context on other odr >>>>>> detection efforts? >>>>>> &gt...

On Tue, Jun 13, 2017 at 10:05 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Jun 13, 2017 at 8:48 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Tue, Jun 13, 2017 at 8:43 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Jun 13, 2017 at 7:54 PM, David Blaikie <dblaikie at

Hi all, I'd like to propose an ODR checker feature for Clang and LLD. The feature would be similar to gold's --detect-odr-violations feature, but better: we can rely on integration with clang to avoid relying on debug info and to perform more precise matching. The basic idea is that we use clang's ability to create ODR hashes for declarations. ODR hashes are computed using all