diff options
author | Jakub Jelinek <jakub@redhat.com> | 2022-02-16 09:27:11 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2022-02-16 09:27:11 +0100 |
commit | 023327643969d5469902a9ecfa6738a315f9e362 (patch) | |
tree | 4f03b57aff29dd67916c27f2cb74e9d5ab4b6507 /gcc/d/dmd/target.d | |
parent | 6e74122f0de6748b3fd0ed9183090cd7c61fb53e (diff) | |
download | gcc-023327643969d5469902a9ecfa6738a315f9e362.zip gcc-023327643969d5469902a9ecfa6738a315f9e362.tar.gz gcc-023327643969d5469902a9ecfa6738a315f9e362.tar.bz2 |
openmp: For min/max omp atomic compare forms verify arg types with build_binary_op [PR104531]
The MIN_EXPR/MAX_EXPR handling in *build_binary_op is minimal (especially
for C FE), because min/max aren't expressions the languages contain directly.
I'm using those for the
#pragma omp atomic
x = x < y ? y : x;
forms, but e.g. for the attached testcase we normally reject _Complex int vs. int
comparisons, in C++ due to MIN/MAX_EXPR we were diagnosing it as invalid types
for <unknown> while in C we accept it and ICEd later on.
The following patch will try build_binary_op with LT_EXPR on the operands first
to get needed diagnostics and fail if it returns error_mark_node.
2022-02-16 Jakub Jelinek <jakub@redhat.com>
PR c/104531
* c-omp.cc (c_finish_omp_atomic): For MIN_EXPR/MAX_EXPR, try first
build_binary_op with LT_EXPR and only if that doesn't return
error_mark_node call build_modify_expr.
* c-c++-common/gomp/atomic-31.c: New test.
Diffstat (limited to 'gcc/d/dmd/target.d')
0 files changed, 0 insertions, 0 deletions