In D126196#3533678, @steakhal wrote:

LGTM;
So you have used this tool. Could you add some notes somewhere on how to get this to work?
What is the workflow?
Is it documented anywhere?

I know that's an unrelated topic, but I might consider using/integrating this stuff into our workflow.

In D126197#3533674, @steakhal wrote:

I'm not using this script file, so I'm not gonna be too picky about this.
However, I would be more confident landing changes if we had tests exercising the changed behavior.
If you plan to land more changes to this file, consider adding some tests.

This patch relates to my previous comment: https://reviews.llvm.org/D124621#3485799

This patch relates to my previous comment: https://reviews.llvm.org/D124621#3485799

In D124621#3486004, @r.stahl wrote:

I can confirm the issue with my patch, so this piece of code needs to be removed.

As long as the following test still succeeds, this looks good to me. Back then, the analyzer was not able to cover that case without that addition.

https://github.com/llvm/llvm-project/blob/main/clang/test/Analysis/globals.cpp#L110

In D124621#3482847, @steakhal wrote:

For the upcoming patches, it would be nice to test the patches on a small set of open-source projects for exactly this reason.
I think there is a clang/utils/analyzer/SATest.py script helping you on this part.
It seems we have quite a few projects on the testset clang/utils/analyzer/projects/projects.json.
We are not using it, because we have a different internal testing infrastructure, but it's definitely better than nothing.

For reference, the modified code was introduced with https://reviews.llvm.org/D80015.

In D124621#3481973, @steakhal wrote:

LGTM

In D124621#3481906, @mantognini wrote:

One thing I'm not sure about and couldn't easily find in the doc is how to reference in the commit message the bug (https://llvm.org/PR48534) this patch fixes. Is it good as is?

AFAIK we should prefer GitHub issue numbers to the old BugZilla numbers.
Could you please update all references of 48534 -> 47878.

In addition, I think Fixes #47878 should work in the commit message, and automatically close the given GitHub issue.

Update commit message and add FIXMEs

In D124462#3480348, @aaron.ballman wrote:

In D124462#3480219, @steakhal wrote:

Thanks for the stats.
@aaron.ballman WDYT, where should we put the LLVM_DUMP_METHOD ?

The documentation for the attribute says function definitions, but I don't think it matters in terms of the semantics of the attributes. I'd probably put it on the definition in this case because the goal is to keep the function around at runtime but it doesn't impact the interface of the call or how users would use it at compile time.

I noticed that we seem to be pretty bad about this advice however:

/// Note that you should also surround dump() functions with
/// `#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)` so they do always
/// get stripped in release builds.

One thing I'm not sure about and couldn't easily find in the doc is how to reference in the commit message the bug (https://llvm.org/PR48534) this patch fixes. Is it good as is?

Remove LLVM_DUMP_METHOD from definition

Ran wrong arc command...

In D124462#3477115, @steakhal wrote:

Although gcc (and probably clang too) allows specifying __attribute__((noinline)) at any declaration (by merging compatible attributes), I would prefer not to repeat ourselves.
The attribute must be present at the header to force all usages not to inline it, hence I would rather drop such attributes from the definition files.

In D124462#3476581, @steakhal wrote:

Could you please elaborate whats the motivation for this change?

I'd appreciate reviews for this small patch. Thanks.

I'd appreciate reviews for this small patch. Thanks.

LGTM, thanks for the update.

This change removes the requirement on pragma when atomic types from the extensions are supported because the behavior is not conformant. With this change, the developers can use atomic types from the extensions if they are supported without enabling the pragma because disabling the pragma doesn't do anything useful but only prevents the use of already available identifiers for types and issues extra diagnostics. This makes semantics consistent with the atomic functions that are also available when the extension is supported without any need for the pragma.

Thanks, I believe this goes in the right direction.

Feels appropriate to remove this indeed.

Reasoning and strategy looks sensible to me. I'm not formally approving the patch because I feel I'm not familiar enough with the code base to do that.

LGTM, thanks for the update.

Some minor comments.

Some relatively minor comments, overall direction seems good to me.

looks appropriate to me.

I feel this would be a valuable addition, indeed. Only a minor question from me.

LGTM, thanks. All the comments seem to be addressed.

Nice refactoring & fix! LGTM. I suppose Stuart's comment about moving typeNameRef can be addressed when pushing.

Right, thanks for the explanations. They make sense.

Looks sensible to me.

LGTM

Looks good overall.

Thanks for the update.

LGTM, except for a minor typo. Otherwise my comments have been addressed. Thanks.

LGTM, just one question: I see in the other review you updated clang/test/SemaOpenCL/extension-version.cl. Do you need to do the same here?

LGTM

Thanks for the update. Looks good overall. A minor question about backticks. I'm no native English speaker, so I would recommend a second review from someone else too.

lgtm, thanks

Looks good, only a few typos and minor comments.

When reading the documentation [1] for -cl-ext (which I've never used so far), I've noticed nothing is said about non-standard configurations (such as disabling cl_khr_depth_images with CL2.0). Quickly testing this shows that options can be specified to produce non-standard behaviour, as shown by https://godbolt.org/z/1Yz1Md.

LGMT as it reduces the divergence in compilation flows. I let @Anastasia, or someone else more familiar with the codebase, give the final approval though.

I've put up https://reviews.llvm.org/D90385 as a fix for this issue.

A follow up on https://reviews.llvm.org/D60193.

I don't want to stop the wider discussion, that being said I think I've addressed the comment regarding the content of this PR. Let me know if the latest version is fine or needs further addressing. Thanks.

Keep cl_khr_byte_addressable_store and cles_khr_int64 out of this PR. Add more details on the extensions being removed in the commit message.

Addressed comments.

In D89372#2329939, @yaxunl wrote:

what if users rely on the predefined macros associated with the extension e.g. cl_khr_srgb_image_writes to enable/disable certain code?

What's the issue with these extensions not removed?

LGTM

Thanks for your clarifications and updates. Just one tiny question about a test file, but otherwise LGTM.

Alright, thanks for the explanation. LGTM then.

Shouldn't this page be referenced from clang/docs/index.rst?

In D67753#1681049, @thakis wrote:

That's mysterious indeed. Looks like the default warnings come from here: https://github.com/python/cpython/blob/88e6447451fb5525e83e802c66c3e51b4a45bf86/Python/initconfig.c#L2064 You don't happen to run python in dev mode, do you? In dev mode, the warnings default to "default"; else they apparently don't.

I don't have PYTHONWARNINGS set in my env. Maybe ninja invoke the script using python -Wignore write_cmake_config.py or something? It's quite worrisome that Python runtime can exhibit different behaviours without apparent reasons. :/

I'm afraid I can't give you the exact log we have, because we have a special integration of LLVM downstream and don't directly rely on the usual cmake/gn/... workflow. I'm sorry about that.

You need Python 3.7.4 or later. The warnings are emitted only starting from this minor release.

Let me know what you think of this patch. Thanks.

I think this looks good. Maybe the tests should be extended to test auto as function return type, and if there's some special handling around decltype(auto), then it should be tested too, but I'm not sure it's actually needed here. What do you think?