I don't have a good idea of the intent of this patch. It seems to me that this could do some pretty nasty damage to C code, right?

Does anyone have issues with this? Can I commit it?

Unfortunately, this ends up adding a warning or two to the build if you enable this, since we have a couple of things built in "C" (flag not used...). In the 'clang' test I did, ./bin/count was the only one. Unfortunately, we don't have separate C vs C++ linking flags, so I think this is just something that someone using this flag needs to deal with.

Committed, 9.0 release request here: https://bugs.llvm.org/show_bug.cgi?id=42774

Casting implementation had to happen in SemaStmt, because other 'warn unused result' stuff depends on them being the way they are.

Disregard that last commit... i ended up breaking stuff apparently.

Ugg... well conversion functions are an interesting bit, as well as Type{}; with no constructors. It ends up being a function style cast to an init-list-expr, so its going to require a bit more work. Stay tuned :)

Rebased and did all the comments (including the www_status). @aaron.ballman : Wasn't positive what you meant about the conversion functions, but I think I got one? I would also love some bikeshedding on the documentation.

I'll need to rebase this on another patch soon anyway, so I'll hold off until next week to update this particularly since we have some open questions. The additional TableGen work is tempting to do, though I'm not completely sure it'll get more than just this use.

Removes pure/const, limits change to just CXX11 spelling, and changes docs/FeatureTestMacro.

In D64914#1591744, @aaron.ballman wrote:

There seems to be some separable concerns in this patch. I'd rather real with warn_unused_result, const, and pure attributes separately only because those are under the gnu attribute namespace and I'd prefer to match GNU's semantics for those attributes (or at least understand better where the inconsistencies are).

This is also missing documentation changes and the updated feature test macro value.

The change itself doesn't really bother me at all, however the test will fail if we build without preserving names. In order to validate this you'll have to do fno-discard-value-names on a test.

I think the function names are awkward, but otherwise I think this should be acceptable. I'll accept, but give 24 hrs for the other reviewers to get through their mondays.

I don't know of any problems that the shared mangle context would cause, though I'm not sure about using the shared_ptr. It seems to me that SOMEONE should own this, and the other should use a reference. IMO, the SharedMangleContexts should be a unique_ptr and CGCXXABI/CGCUDANV should have a reference to the proper implementation.

In D63507#1552849, @sdesmalen wrote:

In D63507#1551968, @erichkeane wrote:

Can someone take a look at this?
@sdesmalen in particular, I'd love it if you could take a look since you're the author of this code.

Thanks, I definitely want to take a look but I’m currently traveling without access to my laptop, so I won’t be able to properly review it until Wednesday.

Can someone take a look at this?
@sdesmalen in particular, I'd love it if you could take a look since you're the author of this code.

Update the comment as requested by @rjmccall

In D56571#1523895, @nickdesaulniers wrote:

Was this committed accidentally?

Today in master I see:

• r362106: Revert "clang support gnu asm goto." Erich Keane <erich.keane@intel.com>
• r362059: Mark CodeGen/asm-goto.c as x86 specific after r362045 Fangrui Song <maskray@google.com>
• r362045: clang support gnu asm goto. Jennifer Yu <jennifer.yu@intel.com>
  
  and yet this Phabricator review is still open.
  
  It may be easier to rebase this into a monorepo checkout, then commit with git llvm push. https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-changes-from-git
  
  As @kees noted, for new test files that contain x86 assembly, they need a -triple that specifies an x86 target, otherwise the implicit target is based on the host, which may not be x86. We still want to verify that non-x86 host can cross compile to x86 correctly. Sorry we did not catch this earlier in code review.

In D62435#1524824, @mstorsjo wrote:

This change broke compiling Qt on MinGW, see https://bugs.llvm.org/show_bug.cgi?id=42089. Trivially reproducible by trying to compile a snippet that looks like this:

class Foo {
public:
        __attribute__((nothrow)) void __attribute__((__stdcall__)) Bar();
};

void Foo::Bar() {
}

Reproducible by compiling the same snippet for a windows-msvc target as well.