similar to: Now I really have broken the build

Hey Chris, The following patch removes all global references to a RecordKeeper instance for the tblgen utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files were touched, the main change was to Record.h. The patch takes the simple approach of adding a RecordKeeper reference to TGParser, and any needed emitter helper classes. In addition, since some of

Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation accesses the global Records instance instead of just referencing itself? As far as I can tell from the usage: 1) Records has the linkage as extern RecordKeeper Records in Record.h 2) Is instantiated as a global in TableGen 3) All llvm uses of getAllDerivedDefinitions SEEM to be manifested as a message to this

Hi Chris, Thanks for the review! I believe I caught most of the syntax style issues with the attached patch. It only contains these style changes. On Dec 12, 2010, at 19:30, Chris Lattner wrote: > > On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > >> >> Hey Chris, >> >> The following patch removes all global references to a RecordKeeper instance for the

On Dec 9, 2010, at 4:50 AM, Garrison Venn wrote: > Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation > accesses the global Records instance instead of just referencing itself? > > As far as I can tell from the usage: > > 1) Records has the linkage as extern RecordKeeper Records in Record.h > 2) Is instantiated as a global in TableGen >

On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > > Hey Chris, > > The following patch removes all global references to a RecordKeeper instance for the tblgen > utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files > were touched, the main change was to Record.h. > > The patch takes the simple approach of adding a RecordKeeper

Concerning the RecordKeeper reference in Record. Would you prefer to partially go back to a more limited constrained version of a global. Since we are not threaded anyway, we could turn the reference into a singleton for the duration of an initial parse and use session. The concept would be to instead make the reference a static pointer, make RecordKeeper a friend of Record, and add

On Dec 12, 2010, at 8:12 PM, Garrison Venn wrote: >> I believe I caught most of the syntax style issues with the attached patch. It only contains >> these style changes. Thanks! I applied your followup patch in r121837. > Concerning the RecordKeeper reference in Record. Would you prefer to partially go > back to a more limited constrained version of a global. Since we are not

Attached patch for removing for the first trivial RecordKeeper:: getAllDerivedDefinitions(...) dependency on the global RecordKeeper Records instance. The real work will be removing this dependency from the other Record.h classes/structs, and from TGParser. Thinking this would be implemented as some sort of context structure/class holding a RecordKeeper instance passed to TGParser which in turn

Can you explain how to revert for someone who is a 2 on a git scale of 0 to 10? At 9/22/2020 03:51 PM, Arthur Eubanks wrote: >Yes, push whatever is needed to fix the build if the fix is fairly simple (else revert and get an LGTM with the fix). > >Next time I'd recommend creating and pushing a revert first if you can't quickly figure out the issue.

Sorry, I'm not sure what you mean. When I added the new TableGen reference a couple of weeks ago, I don't recall adding it to any list of documents. It appeared as if every document in the docs/ directories was built.

The attached patch removes Record::createRecord(...) and its uses from trunk, and includes previous code style fixes. On Dec 12, 2010, at 21:52, Garrison Venn wrote: > ... > >> >> Another random question: why is createRecord better than using "new Record"? If createRecord is better, it would be good to make the Record ctor private so the code doesn't evolve

Okay, I've got two patches ready to fix my two problems. Do I simply make another commit and push it?

Hello, today I updated a CentOS 7.6 ppc64le machine to CentOS 7.7. After reboot to the new kernel (4.18.0-80.7.2.el7.ppc64le) dkms could not build the nvidia-module. Error-message from dkms: Compiler version check failed: The major and minor number of the compiler used to compile the kernel: gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC) does not match the compiler used here: cc (GCC)

Seems there were a couple of correlated failures that appear to be flakes on this buildbot recently: green: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/13974 red: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/13975 (target-override.c during stage 1, seems to be missing the directory/symlink it just created) red:

Thanks for the feedback! >> Does anybody have anything else they think should go into TGContext or >> any other responsibilities it should have? Or any feedback about the >> idea in general? > > All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. Sounds good. >> I'm also hoping

Well, I am at my wit's end. I have copied over the script and directories for this test case and run it a few million times. First I was running one at a time, then I switched to kicking off 1000 at a time. All the while, the bots continued to run on the same machine. The script never failed even once. I am not sure if this has something to do with Python as part of llvm-lit or what is going

https://llvm.org/docs/CommandGuide/lit.html already lists %T as "parent directory of %t (not unique, deprecated, do not use)". See also https://reviews.llvm.org/D35396 On Thu, Sep 3, 2020 at 3:37 PM David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I think I'd be up for considering deprecation of %T due to the risk > of race conditions/conflicts between tests. %t

Sure. I didn't use lit or ninja. I simply copied the script produced by lit (/home/buildbots/ppc64le-clang-multistage-test/clang-ppc64le-multistage/stage1/tools/clang/test/Driver/Output/target-override.c.script) into a temporary directory (along with a deep copy of the build directory). I modified the paths in the script to point to the temporary directory. Then I ran the script in a loop. For

I think that was maybe the discussion on https://reviews.llvm.org/D78245 On Thu, Sep 3, 2020 at 6:22 PM Robinson, Paul <paul.robinson at sony.com> wrote: > I have a vague memory that libcxx wanted it for something, and claimed it > would be hard to work around not having it. > > Anyone else remember that? I can’t dredge up the details, sorry… > > In any event, a separate

Hi, v3 of these patches: https://www.redhat.com/archives/libguestfs/2018-April/msg00002.html https://www.redhat.com/archives/libguestfs/2018-April/msg00006.html Thanks, Pino Toscano (3): v2v: OVF: improve get_ostype mappings v2v: OVF: write ovirt:id attribute for the OS in OVirt flavour v2v: OVF: fix ovf:id for VirtualSystem in OVirt flavour v2v/create_ovf.ml | 253