@xbolva00 I could, but to me this is not trivial (I'm not familiar with the code and I'm not sure what I would break). If it's easy for you, then please do (otherwise I can send a patch for review).
I have already worked around this issue in a different way (by running the compiler invocation in a separate process).

Ping?
I'm not sure who to add as a reviewer.

I have the same issue as @wenju. The second time I call ExecuteCompilerInvocation it will give the error above, leading me to believe some memory isn't properly cleared.

Thank you for the fix for AVR! It's unfamiliar code to me but it seems reasonable.

See my inline comment. I only checked rol8 on AVR but I think the same applies to ror8. Basically it seems like the transformation is correct but will make the operation unacceptably slower.

In D76181#1923176, @MaskRay wrote:

The GCC side commits can be found on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
So it seems that we will have both -mlong-double-{64,80,128} (80 is used by x86 fp80) and -mlong-double={32,64}... (I actually prefer = to -)

Fixed nits.

@whitequark can you take a look?

In D75099#1902339, @dylanmckay wrote:

Hi Dylan - on the mailing list thread for this I raised a concern about disassembler support based on comments I'd seen in a recent patch. Can you please clarify the current status there?

@aykevl perhaps you might have a more up-to-date answer than me here given the recent DWARF-dumping fixes you've made?

Adding myself as reviewer so I don't lose this patch. I hope to test this out soon.

In D74255#1871958, @labath wrote:

However, if we look at this locally, if the AVR architecture has a trap opcode (maybe to implement __builtin_debugbreak() -- I am assuming that's what 0x98 0x95 is), then I don't see a problem with this function returning it.

Thanks for the review!

Closing this one. Maybe there is something useful in this patch but if there is, I'll submit that in a standalone (more focused) patch. The majority of it has been merged in D73969.

Great! I've been looking forward to this.

In D73969#1860696, @labath wrote:

I agree only one of those two places should be enough. My idea was to make the constructors delegate to one another (if necessary by creating a private uber-constructor that everybody can delegate to). Then we could have only one assert.

But if that's hard for some reason, your proposal seems fine too.

Rebase on master (after GetPointer was removed).

I don't think this is relevant anymore with the move to git.

I found a way to test at least the case where the value should not be shifted. If it is shifted, the instruction becomes something other than a nop.
For the other case (when the value should be shifted), the AVR backend needs to be able to disassemble branch instructions.

Merged: https://github.com/llvm/llvm-project/commit/2a7a989c3edc33ad3042052ed50fee37ab254c7d (but Phabricator won't show a second merge)

Rebased on master.

I forgot to include the Differential Revision line but this has been committed here:
https://github.com/llvm/llvm-project/commit/00570c2f18872ce0a1f68cc73e7e259ad67aa60d

@appcs Do you perhaps have access to the ISA documentation so you can review these patches?

After some investigation, it appears that "temporary labels" can be constructed like this:

@jhenderson thanks!
It took me a while but finally I figured out that the problem is with the AVR backend - at least the first bug I was dealing with. For some reason it adjusted absolute relocations, breaking references between DWARF sections.

Right now there are asserts both when constructing/copying(?) the object (5 asserts) and at the place where m_addr_size is used (3 asserts). I would propose picking one place, such as where it is used. That would reduce the number of asserts to 3 and keep them close together. What do you think?

I agree only one of those two places should be enough. My idea was to make the constructors delegate to one another (if necessary by creating a private uber-constructor that everybody can delegate to). Then we could have only one assert.

I just noticed this patch from D73961. I am not yet familiar with the DWARF support in LLVM but just wanted to say two things:

How do you normally generate the binaries with these kinds of addresses? Can they be produced with clang? Can they be produced with llvm-mc? Linked with lld ?

I do have one question though. Will the DataExtractor actually do something reasonable for non-power-of-2 sizes (5,6,7) ? If yes, then great -- if not, we should keep the assert as 2 || 4 || 8.

Added comments, as requested.

See D73969.

Added a unit test.

Ok, I've updated the title and the commit message (text until the separator). Does that look good?

It's worth noting that I haven't managed to get a line table from a binary produced by LLVM (with my own compiler frontend) and linked by avr-gcc. But I believe that is a bug in the AVR backend of LLVM as a binary built entirely by avr-gcc works just fine.

@labath Thank you for the quick review!

@whitequark can you take another look at this patch? (I can rebase it if needed).

For what it's worth, RISC-V implements semantics close to but not exactly like ARM, with NaN being treated as if it was +Infinity.
Source: https://content.riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf#page=63

Ping?
This would be super useful to have: it avoids copying most of cc1as.

So far nobody has mentioned that the reduced struct (struct Foo { unsigned myBit : 1; char myByte; };) is 8 bytes with MSVC. It's highly possible that GCC is aligning their ABI with MSVC for better compatibility.

I ran the same code as above on MinGW 7.3.0, and with that version the struct size is 4 bytes. So it looks like GCC/MinGW changed how they lay out a struct in memory (breaking ABI compatibility?).

Another test. I compiled the following code: https://godbolt.org/z/hVCAUB

I ran the following commands in CI:

I wrote a patch, see: https://reviews.llvm.org/D70266

I did some monkey-patching of Symbol.h:

Just a note after the fact: this change broke linking in TinyGo. It used to manually build an archive (without index) with object files from compiler-rt and that worked just fine in LLVM 8 - it did read symbols from those archives even without a symbol table. In LLVM 9, ld.lld refuses to link those libraries. We'll work around it by manually building a symbol table for lld.

Sorry, that was probably https://reviews.llvm.org/D64077 instead.