• Adjust formatting to conform to git-clang-format

In D133376#3961567, @dblaikie wrote:

As one might expect, the section that grew is .debug_line. I see an increases of about 2%. However, the overall size of just the debug info increases by considerably less, about 0.3%. The increase of the overall file size is even less, at about 0,2%.

Under what build configuration/example target? These numbers can vary pretty widely depending on compression, split dwarf, optimized/unoptimized, etc. Might be good to have a few scenarios covered, at least with clang or something similarly large-ish from the LLVM project.

ping for approval

In D133376#3784313, @aprantl wrote:

I think this is a reasonable feature to support. As @MatzeB pointed out, it may not be useful in optimized code. Are you primarily targeting optimized or unoptimized code? How much does the debug info size grow in % if you build, e.g., clang?

In D133376#3773083, @MatzeB wrote:

What is this epilogue information going to be used for?

Generally I find the notion of "epilogue" a bit sketchy, since you can easily imagine the scheduler mixing CSR restore instructions (and whatever else you consider epilogue) with normal computation so you'll have epilogue and non-epilogue code mixed together so a notion of "epilogue starts here" doesn't really mean much...

• Add case to deal with ElaboratedTypes.

In D130123#3700174, @rnk wrote:

In D130123#3698399, @Ariel-Burton wrote:

Just to make sure that we're on the same page, you'd like to see a test that confirms that clang is rejecting the template<typename T> void f(T __ptr32 a) example, and possibly one that checks that my example is accepted. Is that correct?

Yep, exactly that. Sorry for the delay, the code looks good.

Recover original changes, and commit with new C++ __ptr32 test.

Added C++ tests for __ptr32.

In D130123#3696786, @rnk wrote:

In D130123#3696752, @Ariel-Burton wrote:

What is your expectation for your template code fragment? MSVC does not accept it.

Yes, I checked, MSVC rejects it, so clang should have test expectations to confirm that. It seems interesting or surprising, to me at least, that MSVC really only accepts __ptr32 on pointers and typedefs of them.

On the other hand, MSVC does accept this:

template <typename T>
void f(T  a) {
  (*a) += sizeof(a);
}
void g(int *p) {
  f(p);
}
void h(int *__ptr32 p) {
    f(p);
}

Right, this makes sense to me. MSVC's diagnostics say something about the __ptr32 qualifier needing to appear after a *, so this extension must be implemented at a pretty low-level, with some exception for typedefs, just like what you have.

In D130123#3691011, @rnk wrote:

That sounds reasonable to me, I confirmed that MSVC really only lets you apply these attributes directly to pointer types and to typedefs.

Can you add a test for the other most common type sugar node, the template parameter? It looks like this:

template <typename T>
void f(T __ptr32 a) {
    (*a) += 1;
}
void g(int *p) {
    f(p);
}

If there isn't already a C++ test for __ptr32 & co, go ahead and make one.