This looks great! Thanks.

Awesome patch. I'm cool with this as long as Simon's comments are addressed.

Thanks for the patch @Maxpm! Can we close PR42173? Is there anything left for that ticket?

This looks nice! We should probably also have a test for the case where a user specifies an END before a BEGIN tag.

Thanks for the review, I addressed your comments:

• Removed the reference, and pass the AST node as a pointer.
• Made a few decls auto

LGTM, I'll let @jhenderson weigh-in to see what he says.

LGTM, as long as @rupprecht's comment is addressed.

In D53832#1450240, @troyj wrote:

Could you simply rebase the patch, or acknowledge the new LLVM license, as your patch was written prior to the license change.

My organization (Cray Inc) already signed the new license agreement, so I'm not sure what you need here. I can write that I acknowledge the new LLVM license, if that helps.

In D53832#1443179, @troyj wrote:

I do not have commit access. I probably should request it at some point, but I'm fine with someone else merging this for me.

LGTM!

In D53832#1439874, @troyj wrote:

This revision is now accepted and ready to land.Dec 3 2018, 12:55 PM

Been about 3.5 months since accepted. Can this be committed?

Makes sense. LGTM.

Thanks for the reviews everyone. This update addresses the feedback, all of which was incorporated.

LGTM

I like this and think users will find it very helpful. The changes seem sensible to me; however, I had a few nits... mostly stylistic things, no big deals. Anyways, I'll mark this patch as accept, as long as you cover the suggestions made by @lebedev.ri.

• Fixed the test case (removed underscore typo, and extraneous shstrtab test).
• Emit ANDROID_REL ANDROID_RELA instead of section offsets.
• Modified the range check, allowing us to remove some now redundant code for printing the lower-bound section names.

In D58701#1411546, @Bigcheese wrote:

lgtm

Should the +0 be +0x0 so that it's always a hex digit? Or is the +0 what the binutils already output?

• Added a more complicated test.
• Made a few variables 'auto' instead of their iterator type.

LGTM. Thanks for adding these.

In D58416#1403227, @compnerd wrote:

Previously we would have emitted Foo [[:space:]] . right?

In D57149#1388361, @uabelho wrote:

In D57149#1387325, @mattd wrote:

Hi @uabelho

The test case in your patch definitely causes a problem, but that's because the -start-before/-stop-after is used. If I run that same test through llc, the UnreachableBlockElim pass kicks-in and drops the dead code.
I took a look at the code in your Janurary 24th comment. I was unable to get the same dead block to surface, but most likely I had the wrong flag set. How did you build the sample in that comment?

It can be reproduced with the full llc -O1 pipe on current trunk using:

llc -O1 -o - pr40436.ll

pr40436.ll825 BDownload

LGTM. I had a few suggestions but nothing looks wrong to me.

I've updated the patch to replicate GNU's c++filt behavior. This patch now only splits strings that are passed via stdin. It does not split strings that are passed as arguments to llvm-cxxfilt via command line.

The test case in your patch definitely causes a problem, but that's because the -start-before/-stop-after is used. If I run that same test through llc, the UnreachableBlockElim pass kicks-in and drops the dead code.
I took a look at the code in your Janurary 24th comment. I was unable to get the same dead block to surface, but most likely I had the wrong flag set. How did you build the sample in that comment?

In D57700#1384786, @jhenderson wrote:

Hello Davide,
The present format is good enough to convey the information. It is however not sufficient or sometimes difficult for present users of GNU tools (which are quite ubiquitous) to make a
switch as it is complete redesign of the post processing tools they may have based on.

-Hemant

It's not immediately clear from the original introduction of GNU style whether complete output identity was the original goal, or just similarity. Similarly, it's not clear from my previously attempt to gather information as to users expectations. I've subscribed @khemant in case he's got any further comments, since he made the original change. My reading of rL260430 which commits it is that it is intended to be like GNU readelf, but doesn't necessarily have to be identical. I'm open to further discussion on this (and I actually have a BoF on this subject at the next Euro LLVM, but that's still a couple of months away).