Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Support] Fix utf16 path's index upper bound #226

Closed
wants to merge 1 commit into from

Conversation

danix800
Copy link
Member

@danix800 danix800 commented Jul 7, 2020

Size of paths in utf8 is possibly bigger than in utf16.

@repo-lockdown
Copy link

repo-lockdown bot commented Jul 7, 2020

This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM.

@repo-lockdown repo-lockdown bot closed this Jul 7, 2020
@repo-lockdown repo-lockdown bot locked and limited conversation to collaborators Jul 7, 2020
ghost referenced this pull request Jul 12, 2020
ghost referenced this pull request Jul 12, 2020
If the target has FP64 but not FP16 then we have custom lowering for FP_EXTEND
and STRICT_FP_EXTEND with type f64. However if the extend is from f32 to f64 the
current implementation will cause in infinite loop for STRICT_FP_EXTEND due to
emitting a merge_values of the original node which after replacement becomes a
merge_values of itself.

Fix this by not doing anything for f32 to f64 extend when we have FP64, though
for STRICT_FP_EXTEND we have to do the strict-to-nonstrict mutation as that
doesn't happen automatically for opcodes with custom lowering.

Differential Revision: https://reviews.llvm.org/D74559

(cherry picked from commit 0ec5797)
ghost referenced this pull request Jul 12, 2020
The use of the `&& ...` fold expression in std::array's deduction guides
recursively builds a set of binary operator expressions of depth N where
`N` is the number of elements in the initializer.

This is problematic because arrays may be large, and instantiation
depth is limited.

This patch addresses the issue by flattening the SFINAE using
the existing `__all` type trait.

(cherry picked from commit c6eb584)
@danix800 danix800 deleted the patch-1 branch September 6, 2023 07:43
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant