In D36899#846598, @compnerd wrote:

Do you think it may be worthwhile to extract the operation into a function?

static unsigned SelectPairHalf(unsigned Elements, ArrayRef<int> Mask, unsigned Index) {
  if (Mask.size() == Elements * 2)
    return Index / Elements;
  return Mask[Index] == 0 ? 0 : 1;
}

After digging in further, I found an even more elegant way of fixing it. And when expanding that fix to isVUZPMask and isVTRNMask, I noticed that the exact same fix as I was trying to provide already was present in isVTRNMask. So expanding that fix to all of them now, with the same code formatting style as in the existing check.

Understood the root cause better, with the hidden assumptions of isVZIPMask where both outputs are used.

In D33880#845576, @martell wrote:

I'm currently testing shared library building(dll's) and adding testcases.
Will be back with an update today/tomorrow once that is ironed out.

Ping @martell - do you have time to update this patch according to Rui's review?

@hans - I guess this should be backport-worthy as well?

Just FWIW, I was about to commit this, but noticed that this test actually depends on D36545, which depends on D36544 (which is yet unapproved). So I'll need to hold off of this one until those patches are merged first.

@compnerd - are you ok with this one as well?

Updated to set the right name type for C++ symbols as well, including a testcase for it.

Thanks for the review! Updated with the changes that Rui requested.

Renamed AArch64MCAsmInfoMicrosoft to AArch64MCAsmInfoMicrosoftCOFF.

In D36366#838985, @martell wrote:

@mstorsjo Shouldn't AArch64MCAsmInfoMicrosoft have the word COFF in it somewhere?

Instead of this patch, we could also update`getNameType` to check for decoration, e.g like this:

if (!Sym.startswith("?") && Sym.find('@', 1) != Sym.npos)
  return IMPORT_NAME_UNDECORATE;

Fixed aliases with stdcall, added a test for that.

In D36548#837871, @martell wrote:

I'm confused to the purpose of the def files created at the time of linking a dll in that case.
Essentially the import library has information that the definition file is missing.
Thus we can not re-create the import library with that definition file, making it useless?

Ping @compnerd, any further comments on this?

Once done, this should hopefully also go into 5.0, since without it, llvm-dlltool doesn't work for mingw-w64 for i386. It's not a regression but a tool that is new for 5.0.

Forgot to say explicitly, that this depends on D36544. This also fixes a regression since 4.0, where linking to import libraries with stdcall creates broken executables. So once done, this and D36544 should be backported to 5.0, ping @hans.

Changed the undecorate action into something that should work for all of cdecl/stdcall/fastcall/vectorcall. Vectorcall doesn't work here yet since the def parser always prepends an underscore though (and fixing that is a separate topic that involves quite a bit of lld as well), but at least this particular line should be mostly fine now.

@martell - to further show the point I'm trying to explain, have a look at the testcase I'm adding in this patch - it shows exactly what should happen. A def file with a decorated name produces an import library with the symbols still decorated, but with the undecorate name type.

In D36548#837373, @martell wrote:

This is related to what we were talking about earlier on the mingw-w64 mailing list about unifying all def files for all 4 platforms. :)
Maybe we can add i386 to the unified version and add a flag when building mingw-w64 to use that along with using a flag to disable MingwDef.
In general though we do not want MingwDef to exist long term and I did not originally add this because .def files should not contain @4 @8 etc in the first place.

Rui, do you want to look more on this and the related references, or shall I go ahead and commit it?

In D36105#834225, @mgrang wrote:

In D36105#834007, @mstorsjo wrote:

Ping @mgrang, can you check the above with MSVC? I'd like to move forward with this in one form or another.

Yes, I checked with MSVC for ARM64 and it compiles without any warnings.

Ping @mgrang, can you check the above with MSVC? I'd like to move forward with this in one form or another.

Added a fixme comment about this being incorrect for WinCE.

Made the GNU case the default. Apparently I didn't have to update the existing test either, because aarch64-windows still triggers isWindowsMSVCEnvironment (but not isKnownWindowsMSVCEnvironment).

I think one important question that needs to be looked into is, does GNU ld align comm symbols at all if we omit this? There's a neat testcase in lld (COFF/common-something iirc) that you might use as base for figuring that out. If it doesn't, I'm afraid we can't do this.

Updated to use a switch, added a mapping of a missed case of thumb while reformatting the if to a switch.

Limited the change to GNU environments.

An example of where this is used is e.g. https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/stdio/scanf2-template.S (with aarch64 support is added in a patch at https://sourceforge.net/p/mingw-w64/mailman/message/35983275/).

In D36304#831621, @ruiu wrote:

This patch looks good, but could you give me a pointer to the documentation for this feature?

In D33880#831661, @martell wrote:

In D33880#831570, @mstorsjo wrote:

If you're still too busy and don't mind, I could also take over trying to get this in a mergeable form.

I can be on this to ensure it gets merged, there were 2 reasons why I left this slide for awhile.
I was having an issue with llvm-dlltool where if I used new to create memory for the strings it would work but if I done it the correct way as rui instructed it was not working correctly.
We now know that was because we were writing the strings beforehand the entry thanks to you :) So the 2 bugs because of the location of the the allocation seemed to nullify each other to some degree.
Which left me a little confused. So I left the lld support slide until llvm-dlltool was merged and also at the time I had started a new job.

In D33880#831161, @martell wrote:

Have been super busy with work, should have got around to this sooner sorry.