updated generate_feature_test_macro_components.py.

In D94511#2698813, @Mordante wrote:

There are still quite some formatting errors, for example () , instead of (),, please use the instructions here to format the patch https://llvm.org/docs/Contributing.html#how-to-submit-a-patch

formatted intcmp.fail.cpp

formatted the tests as per @Quuxplusone comments

incorporated @Quuxplusone comments

fixed a typo.

incorporated comments from @Quuxplusone, @Mordante and @curdeius

Making changes effective only for windows

ping?

Incorporated @Quuxplusone suggestions.

Addressed @curdeius comments.

Making changes effective only for windows

updated patch

clang formatting the patch.

Marked failed tests as unsupported on windows system
Because now clang emits native path for DIFile.

In D99580#2659352, @dblaikie wrote:

@rnk @akhuang - I think we touched on this before maybe in some other thread/patch/discussion?

Ah, @probinson mentioned in the linked thread:

Is this https://bugs.llvm.org/show_bug.cgi?id=44170 which had a tentative patch at https://reviews.llvm.org/D71508 ?
The original complaint wasn't for Windows, but the lack of filepath canonicalization seems like a common symptom.

Might be best, @kamleshbhalui, if you could check if the other (D71508) patch relates to the same issue & if so, continue the discussion over there instead of forking it here.

In D99580#2659858, @amccarth wrote:

Another possible issue is that llvm::sys::path and other functions try to map Windows filesystem concepts to Posix ones. There are many cases where there isn't a perfect mapping. For example: Windows has a current working directory _per drive_, and so it can be hard to resolve paths like D:foo.ext, which are relative to something other than the "current working directory." Details like this can come into play in the immediate vicinity of the code change, so I have some trepidation.

Agree with you but this problem exist with and without this patch.

It looks like the code change is for everyone, but the new test is specific to mingw.

Updated the tests

In D98006#2606717, @curdeius wrote:

This doesn't answer my question unfortunately.
What configuration (platform/OS/compiler, cmake invocation etc.) you used when you found the failures?
What were these failures precisely?

In D98006#2606418, @curdeius wrote:

Can you give some details please about the config on which these tests failed?

Added one fixed test

Fixed more tests

addressed @Mordante comments.

used _LIBCPP_NO_HAS_CHAR8_T and _LIBCPP_HAS_NO_UNICODE_CHARS macro to guard char8_t, and char16_t, char32_t.

addressed @curdeius comments.
added tests, few test snippets taken from the link given by @curdeius.

fixed a nit.

rebased with the main branch. do not see any conflict.
@ldionne or @abdulras can you please have a look at this, this patch is in this state for a long time.
FYI, I have been using this patch in VxWorks.

LGTM!

In D88727#2330286, @mclow.lists wrote:

Is this a problem unique to vector? Do the other containers have the same constructor? Do those constructors have the same issue?
Checking ... list does not seem to have this problem. deque does not either. forward_list does not either.

<deque> has the following code:

template <class _InputIter>
    deque(_InputIter __f, _InputIter __l,
          typename enable_if<__is_cpp17_input_iterator<_InputIter>::value>::type* = 0);
template <class _InputIter>
    deque(_InputIter __f, _InputIter __l, const allocator_type& __a,
          typename enable_if<__is_cpp17_input_iterator<_InputIter>::value>::type* = 0);

I don't think that making vector different from the other containers is the right approach. Then again, I'm not 100% sure why the existing code is failing - so I should look at tha

ping?

Added test suggested by @mclow.lists .

In D88727#2308363, @miscco wrote:

So the actual problem in the bug report is that the first argument cannot be used to deduce the type.

I think it is not correct to remove the type restrictions here, they are there for a reason.

LGTM!

rebased with the master.

addressed @mhorne comments.

@asb and @luismarques do you suggest anything here ?

ping?

ping?

addressed @mhorne and @MaskRay concerns.

rebased and cleaned up the diff.

In D82171#2103042, @tambre wrote:

D77505 broke a bunch of bots. This fixes the regression.

I lack commit privileges. Please land as "Raul Tambre <raul@tambre.ee>"

In D77505#2102613, @tambre wrote:

Please commit this for me in case no one else has objections. I lack commit privileges.

Addressed @efriedma comments.
added test for strictfp.

thanks @mhorne for reviewing.
addressed your comments.

ping?

ping?

Rebased

addressed @luismarques concerns.
This patch extends soft float case .

enhanced and more testcases.

I do not have commit access,
can someone commit this for me?

In D80465#2060164, @luismarques wrote:

LGTM. But please give it some time for other people to chime in before you merge, they may disagree with this .inc approach.
I'm approving this assuming the generic test is actually ran against this implementation. @kamleshbhalui did you verify that was the case?

cleanup

In D80690#2060505, @ldionne wrote:

@kamleshbhalui Just to be clear -- you need libunwind approval before you can submit a patch that touches libunwind. If you just wanted to iterate on this privately it's OK, but you'll need approval from the group before submitting.

restructured the file. so it can be picked by lit test.

defined _LIBUNWIND_CURSOR_SIZE
for all these below variants
ILP32 + "f" : xlen = 32, flen = 32 ===> 39
ILP32 + "fd" : xlen = 32, flen = 64 ===>55
LP64 + "f" : xlen = 64, flen = 32 ====>60
LP64 + "fd" : xlen = 64, flen = 64 ====>76 (was already done.)

addressed @luismarques comments.