I will take care of it today. The bot does have vs2019 installed and it should be picking up latest VS (and it was when I updated it), so there is an easy fix (remove 2017) and then I can investigate why it stopped picking up latest.

Thanks, Aaron. I'll check this out.

Looking now.

Yep, thanks. This uncovered an existing error, so rather than reverting the
whole thing I've disabled the assert on windows while I fix
it. f1357264b8e3070bef5bb4ff35ececa4d6c76108

I don’t really have much more to add here except to refer you to the style
guide:

Hi,

Hi Martin,

• msg-7222-125.txt159 BDownload

Lgtm

Understood, The test worked for me because I have both 64 bit and 32 bit libs installed on my default sysroot. Otherwise might fail indeed.

As a possible idea (that may or may not work): the Attr object itself has a SourceRange on it; perhaps a solution is to keep the > attributes in sorted order within DeclBase::addAttr() based on the SourceRanges passed in?

Woops. Submitted that last comment too early. Editing it on Phab.

I think you and Richard agreed that you weren’t going to synthesize a whole
expression tree at every use of the operator, and I agree with that
decision. That’s very different from what I’m asking you to do, which is to
synthesize in isolation a call to the copy-constructor. There are several
places in the compiler that require these implicit copies which aren’t just
normal expressions; this is the common pattern for handling them. The
synthesized expression can be emitted multiple times, and it can be freely
re-synthesized in different translation units instead of being serialized.
You’re already finding and caching a constructor; storing a
CXXConstructExpr is basically thr same thing, but in a nicer form that
handles more cases and doesn’t require as much redundant code in IRGen.

• msg-4647-88.txt159 BDownload

LGTM.

• msg-28891-85.txt159 BDownload

We will add it. Thanks.

We need to benchmark this to see if it still makes a difference.

The returned pointer should point to the same pointee type as the argument. Header file cannot guarantee that.

• msg-22400-127.txt159 BDownload

This would be a great conversation to have at the social, sadly I will
have to miss it this month.

• msg-15757-444.txt159 BDownload

Sure, I'll take a look.
Thanks!

• msg-21051-113.txt159 BDownload

Just wanted to check if there are existing test cases for format::getStyle.
If there is no test for it, I'll add test cases for sure :=)

+Lang, because he was asking me recently about this improvement & thinking
of chipping in

I know that MIPS does that, and an out-of-tree implementation of hexagon
implements 1-byte cmpxchg in terms of the 4-byte version. The emulation
code isn't particularly small, and it seems reasonable to make it a
libcall. The emulation code seems sketchy from a correctness
perspective, as you end up generating unsolicited loads and stores on
adjacent bytes. Take a look at the thread on cfe-dev and llvm-dev named
"the as-if rule / perf vs. security" for some of the ramifications and
concerns surrounding unsolicited loads and stores.

Friendly PING.

Hi Aaron, Hi Juergen,

• msg-30393-176.txt159 BDownload

It's best not to commit things without approval once they've been sent for
review (the assumption being that if you asked for review it's because the
change needed review - time doesn't change that fact) - if approval was
given off-list (eg: on IRC) it's best to mention who gave it & where (&
ideally the person should provide it on-list just for record keeping)

Given your follow-up review, and the behaviour of
match_results::operator[], do you still have reservations?

Thanks for working on this!

I'll upload a new patch in a moment. Replies inline below.

I agree what you said about different code generated with clang and GCC
generates. In this case, we should throw an error (err_late_asm_label).

• msg-516-145.txt159 BDownload

• msg-25712-156.txt159 BDownload

Would citing PR20455 help? It wasn't actually my primary motivation but it's not too far off. Having the template parameters there lets you know what's going on in the DWARF, without having to fetch and parse the name string of every struct you come across. Actually I'm not sure parsing the name string is unambiguous either; each parameter is either a typename, or an expression, but without the parameter DIEs you don't know which, a-priori. (What does <foo> mean? Depends on whether you think it should be a type name or a value; you can't tell, syntactically, you have to do some lookups. Ah, but if you had the parameter DIEs, you would Just Know.)

Hi Sean,

@Aaron: Yes, I'm aware of that. I wanted to show that my check does not
take this into account.

• msg-12340-169.txt159 BDownload

• msg-32543-315.txt159 BDownload

Looks like the initial mail didn't hit the mailing list? Does someone want
to restart this review and/or forward that initial mail with the
patch/description/etc?

• msg-1588-168.txt159 BDownload

I’m not sure how much people actually use these, but the AVX-512 versions of these, at least, can be very useful internally to implement AVX-512 intrinsics.
For AVX-512, we use the same GCC builtin for all 3 versions of the intrinsic (pass-through masked, set to zero masked, and unmasked). This is the same implementation that’s used in GCC, and is fairly clean, since the only difference is in the desired pass-through values (actual value, zero, or undef).