similar to: RFC: Supporting macros in LLVM debug info

> Do we really need to touch the AST? Or would it be reasonable to wire up the CGDebugInfo directly to the PPCallbacks, if it isn't already? (perhaps it is already wired up for other reasons?) This sound as a good idea, I will check that approach. PPCallbacks is only an interface, has nothing connected to it, but we will create a new class, which implement PPCallbacks, for macros. So we can

> Not necessarily, if we kept the macros in order in the list of macros attached to the CU, which I imagine we would. OK, now I understand what you are aiming for. I really do not favor one on the other. But, can you explain what is the advantage of the parent approach over the children approach? If any, the children approach seems to be the one reduces the LLVM IR size, is not it? Regards,

> Right - I was wondering if CGDebugInfo already implemented PPCallbacks or was otherwise being notified of PPCallback related things, possibly through a layer or two of indirection. I checked the approach of skipping representing macros in AST, and communicate them directly from Parser to CGDebugInfo. However, I could not find a way to initialize this communication. The only interface

On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> wrote: > I found a way to skip representing macros in AST and create them directly > in CGDebugInfo through PPCallbacks during preprocessing. > > To do that, I needed to extend ASTConsumer interface with this extra > method: > > > > /// If the consumer is interested in notifications from

On Fri, Nov 13, 2015 at 2:41 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Fri, Nov 13, 2015 at 10:21 AM, David Blaikie via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> >> wrote: >> >>> I found a way to skip representing macros in AST and create them

I'd like to jump in. I do not work on a preprocessor based language, but have the same code expansion problem to encode. Right now, we hack around the problem by appending some prefix after the file name and pretend it is a different file, which is not great. I understand you want to represent expansion by DIFileMacro ? I'm not how this is supposed to be used and it is not in the example.

Hello Everyone, I would like to have your thoughts on this. Overview of the problem =================== While implementing support for the DWARFv5 debug_macro section support in LLVM. I came across these holes: - The macros infrastructure in CLANG/LLVM is inherently tied to a particular version(v4 macinfo). For instance, consider this snippet from CLANG:

Hi I am the maintainer of pygccxml, which uses clang/llvm and CastXML to parse c++ code. A user reported a problem with the current llvm 3.9 trunk version (I tested with r261262). Our problem is that the AST contains some declarations which were not there before. Using "clang -Xclang -ast-dump” on a c++ file, I get the following result: TranslationUnitDecl 0x8e41ab0 <<invalid

http://bugzilla.mindrot.org/show_bug.cgi?id=1273 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX CC|

Hi all, I'm preparing a package which uses .Fortran to interface a Fortran 95 function. This F95 function simply receives the name of a file from R, opens this file and forwards its content to a F95 module, which, in turn, makes the real computation. The F95 module is a pre-existing one and I'm trying to use it in its actual state. Thus, data transfer between R and this F95 module is

Hi, How can i copy a file to another with the same name without being prompted for a confirmation ? I read the cp man page, but nada. Any help would be appreciated. Warm Regards, M?rio Gamito

On Thu, Jun 09, 2011 at 08:47:26PM -0400, Jack Howarth wrote: > Duncan, > Here are the complete benchmarks rerun against gcc 4.5.4 built with... > > Using built-in specs. > COLLECT_GCC=gfortran-fsf-4.5 > COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.4/lto-wrapper > Target: x86_64-apple-darwin11.0.0 > Configured with:

Hello everyone, We are in the process of formalizing the governance model of the GlusterFS project. Historically, the governance of the project has been loosely structured. This is an invitation to all of you to participate in this discussion and provide your feedback and suggestions on how we should evolve a formal model. Feedback from this thread will be considered to the extent possible in

Not sure if this has application for R but Microsoft's new Monad shell is now in public beta. I have not looked at it myself but I wonder if the tools that are required to create Windows R packages could be replaced by this? ---- The Monad team has recently released Monad Beta 3.1 to Microsoft Download Center and we're working diligently towards a release of Monad 1.0! As adoption of

Dear R-Users, Have a question about reading in some data and manipulating dates. I have a data set in excel which looks like this: Date PEG ETN HSP PTC 13/10/2004 41.92 64.75 29.86 9.27 14/10/2004 41.93 61.79 29.98 9.14 15/10/2004 41.69 62.7 30.09 9.04 18/10/2004

I was looking for an R-package that would reduce matrices to row-echelon form, but Google was not my friend; any leads? If not, I wonder if the problem could be expressed in terms of constraint satisfaction...

Cross-posted to the blog (at http://lylejohnson.name/blog/2010/08/04/moving-on/): When Jamis Buck wrote last year about ceasing development on Capistrano, his post really struck a chord with me. If this post reminds you of that one, it''s because I re-read it before sitting down to compose this one. It was the next best thing to having Jamis on hand to give me a pep talk before I had to

In various debug dumps (eg., Clang's -ast-dump), various objects (eg., Stmts and Decls in that -ast-dump) are identified by pointers. It's very reliable in the sense that no two objects would ever have the same pointer at the same time, but it's unpleasant that pointers change across runs. Having deterministic identifiers instead of pointers would aid debugging: imagine a

So Reid came across a case where the current strategy (dropping locations when they move across basic blocks) proves to be at odds with another precept we have: inlinable calls must have locations, so that if/when they are inlined the location can be accurately described (due to the nature of our IR representation of inlining, a location must be given for the call site so that the DIEs for the

This is a great idea! I personally also wouldn't mind going further in debug builds and actually create and store sequential IDs with the objects and take the small memory hit for improved debuggability. The `PersistentId` field in SelectionDAG works that way and has helped make the output more readable IMO. - Matthias > On Aug 28, 2018, at 5:22 PM, George Karpenkov via llvm-dev