In D80925#2067145, @rjmccall wrote:

In D80925#2066915, @ABataev wrote:

In D80925#2066728, @rjmccall wrote:

Narrowly this seems to fix the immediate problem, but I feel like we're in trouble if tentative parsing is changing the semantic context in ways that persist. In particular, I'm concerned that we could end up tentatively parsing an ODR use as part of an expression and then completely discarding it, causing Sema to think that there's an ODR use later because it never sees an L2R conversion (because the expression is not actually used). Probably the most architectural thing would be for tentative expression parsing to push a possibly-unevaluated context, and then when we claim an expression annotation token we can do the retroactive work necessary to make it an expression in the proper context. We already have most of the logic to support that because of C99 sizeof, which is usually not evaluated but can be in the narrow circumstance of a VLA.

If we do decide to solve this more narrowly, then we should audit our use of the tentative-parsing queries to make sure that we're pushing contexts consistently, and we should leave comments in places like this to make sure that maintainers understand the subtleties.

So, you suggest to not create annot_primary_expr during tentative parsing and revert parsing completely, right?

Not creating the annotation doesn't help if we're still making Sema calls. Also, I assume we're making the annotation token intentionally, probably to avoid re-doing the lookup. But I do think we could recognize that we're doing this, push an unevaluated context in tentative parsing, and then call TransformToPotentiallyEvaluated when we see the token in expression parsing.

In D80925#2066915, @ABataev wrote:

In D80925#2066728, @rjmccall wrote:

Narrowly this seems to fix the immediate problem, but I feel like we're in trouble if tentative parsing is changing the semantic context in ways that persist. In particular, I'm concerned that we could end up tentatively parsing an ODR use as part of an expression and then completely discarding it, causing Sema to think that there's an ODR use later because it never sees an L2R conversion (because the expression is not actually used). Probably the most architectural thing would be for tentative expression parsing to push a possibly-unevaluated context, and then when we claim an expression annotation token we can do the retroactive work necessary to make it an expression in the proper context. We already have most of the logic to support that because of C99 sizeof, which is usually not evaluated but can be in the narrow circumstance of a VLA.

If we do decide to solve this more narrowly, then we should audit our use of the tentative-parsing queries to make sure that we're pushing contexts consistently, and we should leave comments in places like this to make sure that maintainers understand the subtleties.

So, you suggest to not create annot_primary_expr during tentative parsing and revert parsing completely, right?

I don't think this field (debug_line_offset) is optional if the debug_macro.dwo section contains DW_MACRO_start_file: "If a DW_MACRO_start_file entry is present, the header contains a reference to the .debug_line section of the compilation."

In D80870#2065079, @Ayal wrote:

Also added a couple of unrelated comments.

LGTM

In D60620#2064839, @yaxunl wrote:

It means HIP will create two compilation passes: one for gfx908 and one for gfx908:xnack+:sramecc+.

LGTM! Thanks! Please address small documentation nitpick before committing...

LGTM other than the use of uint32_t.

Updated to round down in computeFeasibleMaxVF.

SGTM

Re testing, you could copy clang/test/Driver/at_file_win.c, which has an explicit --rsp-quoting=windows; remove that option and make it REQUIRES: system-windows. That should do it.

(You can change [Clang] to [Driver] as [Clang] may carry less information. [Driver] emphasizes this is related to clangDriver. Nothing in sema/codegen/analyzer/etc is affected.)

LGTM once all other reviewers are happy with this patch.

You don't really need to wait for all of us but you should probably wait for @MaskRay and @atanasyan as they had comments.

In this case you might consider replacing the global reference with null and implementing my proposal in https://bugs.llvm.org/show_bug.cgi?id=41734#c2 to make the section SHF_LINK_ORDER with a zero-length .init_array section.

lgtm

Thanks for taking another look at this, @efriedma!

Use llvm::find_if

• Restricted the illegal types which should be lowered for EXTRACT_SUBVECTOR to those handled in this patch (nxv8i8, nxv4i16 & nxv2i32)
• Removed unnecessary changes in ReplaceExtractSubVectorResults
• Updated the tests with update_llc_test_checks.py
• Added a check on expected types in performSignExtendInRegCombine & PromoteIntRes_EXTRACT_SUBVECTOR

In D80897#2066952, @jdoerfert wrote:

In D80897#2066723, @tra wrote:

Hmm. I'm pretty sure tensorflow is using std::complex for various types. I'm surprised that we haven't seen these functions missing.

Which functions and missing from where? In CUDA-mode we did provide __XXXXc3 already.

It looks like your patch will allow us to remove a private patch that has a similar effect.
Incidentally if I apply this to an upstream checkout on Windows, I see clang/test/Driver/at_file.c fails, so you'd at least need to do something for that.
(UNSUPPORTED: system-windows at a minimum.)

ping - is this refactored version ready for submission? Thanks.