@Hahnfeld Thanks for the explanation!

In D76780#1942144, @bryanpkc wrote:

Why doesn't the KMP_MB after the store to th_next_waiting guarantee that the unblocked thread sees that store?

In D76780#1941764, @Hahnfeld wrote:

Yes, this looks related to memory consistency. As far as I understand the threads synchronize on th_spin_here, so this is guaranteed to be updated. Any other write before this in __kmp_release_queuing_lock is not guaranteed to be synchronized by a weak memory model. This includes th_next_waiting (which triggers the assertion), but also writes by the user application. That's particularly bad because this should be taken care of by the runtime!

Removed unrelated changes from this patch.

Pinging reviewers.

Add tests for -fopenmp-targets=.

In D70804#1763289, @ABataev wrote:

Tests are required

Avoid reading CTR_EL0 on every call to __clear_cache.

I actually read that LKML post before submitting the patch, and I had the same understanding as @ktkachov. I will change the code to cache the result of the MRS instruction as suggested.

Pinging reviewers.

In D53927#1399283, @steleman wrote:

In D53927#1399263, @rengolin wrote:

Thanks Stephan, now looks good.

Did you see the comment on lgamma coming after isoc99? I wonder if that's reproducible in all systems...

Yup I saw it. But I don't get any errors here (Ubuntu 16.04 / Ubuntu 18.something) AArch64.

And it's not clear to me how that sorted alphabetical order is supposed to work. There's a bunch of other functions that come after lgamma/tgamma that aren't sorted.

For example:

/// char * __strtok_r(char *s, const char *delim, char **save_ptr);
TLI_DEFINE_ENUM_INTERNAL(dunder_strtok_r)
TLI_DEFINE_STRING_INTERNAL("__strtok_r")
/// int abs(int j);
TLI_DEFINE_ENUM_INTERNAL(abs)
TLI_DEFINE_STRING_INTERNAL("abs")
/// int access(const char *path, int amode);
TLI_DEFINE_ENUM_INTERNAL(access)
TLI_DEFINE_STRING_INTERNAL("access")

Is there any plan to fix this patch and land it? We use --max-time in our tests and intermittently run into the Python assertion. We can work around the problem by killing lit.py with another timer, but then we lose the report that lit.py produces at the end of the run.

Rebased on trunk.

Removed trailing spaces. NFC.

Pinging reviewers.

Thanks Kristof!

Pinging reviewers....

Added a unit test for lib/Support/Host.cpp and removed some redundant tests.

In D53633#1274621, @t.p.northover wrote:

I think this is reasonable.

Updated the patch to avoid using monorepo path names.

Pinging reviewers...

Removed impossible code path from NormalizeBuildVector.

In D48614#1150452, @craig.topper wrote:

There are actually two selection DAGs for that test. I'm not sure why yet. The final schedule is printed separately for each DAG.

Thanks for the review! I have committed the patch.

Ping?

Re-added test/Driver/Inputs/gcc_version_parsing5/lib/gcc/i386-unknown-linux/4.9.2/crtbegin.o.

Fixed the code to set GoodVersion.MajorStr before returning, and removed an unnecessary file (test/Driver/Inputs/gcc_version_parsing5/lib/gcc/i386-unknown-linux/4.9.2/crtbegin.o).

In D20355#434117, @labath wrote:

Do you have commit access?

Added a unit test in ScalarTest.cpp that catches this particular error.

Thanks for the review. I will try to add some test cases in a future patch.

Thank you for the reviews.

Thanks for the review.

In D18732#391023, @uweigand wrote:

Your change to README.txt implies that LRVH and STRVH still are not generated by the compiler. However, the change to SystemZInstrInfo.td actually installs DAG patterns for the SelectionDAG pass to recognize, so this is somewhat confusing.