[Bug c++/100673] [coroutines] Non-template, UDT await_suspend return-type results in ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100673 --- Comment #1 from John Eivind Helset --- Created attachment 50854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50854=edit Add CLASSTYPE_TEMPLATE_INFO guard and test-case. Tried to guard the the conditional with CLASSTYPE_TEMPLATE_INFO as it seemed like the common approach in the codebase, to verify that the return-type was a template. And a testcase. Remove the guard to observe ICE in the test-case.
[Bug c/100719] missing -Wvla-parameter on a mismatch in second parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100719 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |11.2 Known to fail||11.1.0, 12.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-21 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/100721] New: Warn when assigning to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100721
Bug ID: 100721
Summary: Warn when assigning to temporary
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davidfromonline at gmail dot com
Target Milestone: ---
I would like for there to be a warning that warns for the following code:
```
struct s {};
inline void f() {
s() = s();
}
```
I know that for a given type, I can prevent this from compiling if I give `s`
an lvalue-refererence-qualified assignment operator, but that requires writing
two assignment operators and two (sometimes three) constructors to get the
behavior I get today from not typing anything, and I have to apply it to every
type. It would be much nicer if I could just turn on a warning for this.
The only valid use case is if your assignment operator has a side effect that
you want.
[Bug c++/100720] New: inconsistent return type deduction behavior with user defined conversion function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100720
Bug ID: 100720
Summary: inconsistent return type deduction behavior with user
defined conversion function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickgray0 at brown dot edu
Target Milestone: ---
the following code compiles successfully:
auto f(auto);
template
struct A {
auto g() {
return f(0);
}
};
auto f(auto) {
if (true)
return 42;
else
return A{}.g();
}
auto main()->int {
f(123);
}
however if we rename A::g as a conversion function:
auto f(auto);
template
struct A {
operator auto() {
return f(0);
}
};
auto f(auto) {
if (true)
return 42;
else
return static_cast(A{});
}
auto main()->int {
f(123);
}
it fails with the error: : In instantiation of 'A<
>::operator auto() [with =
int]':
:14:36: required from here
:6:17: error: use of 'auto f(auto:1) [with auto:1 = int]' before
deduction of 'auto'
6 | return f(0);
|~^~~
: In function 'auto f(auto:1)':
:14:16: error: invalid 'static_cast' from type 'A' to type 'int'
14 | return static_cast(A{});
|^
ASM generation compiler returned: 1
[Bug c/100719] New: missing -Wvla-parameter on a mismatch in second parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100719 Bug ID: 100719 Summary: missing -Wvla-parameter on a mismatch in second parameter Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- -Wvla-parameter diagnoses the mismatch in the second argument in the redeclaration of f() but misses the same mismatch in the third argument in g(). $ cat a.c && gcc -S -Wall a.c void f (int n, int[n]); void f (int n, int[n + 1]); // -Wvla-parameter (good) void g (int n, int[n], char[n]); void g (int n, int[n], char[n + 1]); // missing -Wvla-parameter a.c:2:16: warning: argument 2 of type ‘int[n + 1]’ declared with mismatched bound ‘n + 1’ [-Wvla-parameter] 2 | void f (int n, int[n + 1]); // -Wvla-parameter (good) |^~ a.c:1:16: note: previously declared as ‘int[n]’ with bound argument 1 1 | void f (int n, int[n]); | ~ ^~
[Bug c++/100718] New: parameter packs not expanded error with a type member which has the same name as a pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100718
Bug ID: 100718
Summary: parameter packs not expanded error with a type member
which has the same name as a pack
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.poelen at gmail dot com
Target Milestone: ---
template
struct Storage
{
using Args = int;
};
template
void delegate(Args&&... args)
{
using X = typename Storage::Args; // reject this
}
https://godbolt.org/z/TdYrTonM3
[Bug target/99842] MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842 Peter Bergner changed: What|Removed |Added Known to fail||12.0 URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2021-March/5 |il/gcc-patches/2021-May/571 |67496.html |012.html --- Comment #3 from Peter Bergner --- Updated patch submitted.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b5c1c7a96bc8d7062d2c35675f48131667498182 commit r12-991-gb5c1c7a96bc8d7062d2c35675f48131667498182 Author: Jakub Jelinek Date: Fri May 21 21:16:21 2021 +0200 openmp: Fix up firstprivate+lastprivate clause handling [PR99928] The C/C++ clause splitting happens very early during construct parsing, but only the FEs later on handle possible instantiations, non-static member handling and array section lowering. In the OpenMP 5.0/5.1 rules, whether firstprivate is added to combined target depends on whether it isn't also mentioned in lastprivate or map clauses, but unfortunately I think such checks are much better done only when the FEs perform all the above mentioned changes. So, this patch arranges for the firstprivate clause to be copied or moved to combined target construct (as before), but sets flags on that clause, which tell the FE *finish_omp_clauses and the gimplifier it has been added only conditionally and let the FEs and gimplifier DTRT for these. 2021-05-21 Jakub Jelinek PR middle-end/99928 gcc/ * tree.h (OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET): Define. * gimplify.c (enum gimplify_omp_var_data): Fix up GOVD_MAP_HAS_ATTACHMENTS value, add GOVD_FIRSTPRIVATE_IMPLICIT. (omp_lastprivate_for_combined_outer_constructs): If combined target has GOVD_FIRSTPRIVATE_IMPLICIT set for the decl, change it to GOVD_MAP | GOVD_SEEN. (gimplify_scan_omp_clauses): Set GOVD_FIRSTPRIVATE_IMPLICIT for firstprivate clauses with OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT. (gimplify_adjust_omp_clauses): For firstprivate clauses with OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT either clear that bit and OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET too, or remove it and let it be replaced by implicit map clause. gcc/c-family/ * c-omp.c (c_omp_split_clauses): Set OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT on firstprivate clause copy going to target construct, and for target simd set also OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET bit. gcc/c/ * c-typeck.c (c_finish_omp_clauses): Move firstprivate clauses with OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT to the end of the chain. Don't error if a decl is mentioned both in map clause and in such firstprivate clause unless OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET is also set. gcc/cp/ * semantics.c (finish_omp_clauses): Move firstprivate clauses with OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT to the end of the chain. Don't error if a decl is mentioned both in map clause and in such firstprivate clause unless OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET is also set. gcc/testsuite/ * c-c++-common/gomp/pr99928-3.c: Remove all xfails. * c-c++-common/gomp/pr99928-15.c: New test.
[Bug target/100627] missing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100627 --- Comment #2 from g.peterh...@t-online.de --- Hello, i found a better solution here https://stackoverflow.com/questions/41144668/how-to-efficiently-perform-double-int64-conversions-with-sse-avx and ported to "normal" C++-code (no intrinsics) https://godbolt.org/z/scjEdze99. This has these advantages: - constexpr - flexible - can be vectorized (autovectorization) These implementations require C++20 (std::bit_cast and constexpr std::exp2), but can easily be implemented with older C++ versions. Possibly this trick can also be used on s/uint64 -> float32, so that one saves the detour s/uint64 -> float64 -> float32. However, i have stated: - with -march=skylake-avx512 no AVX512 code is generated - only with -march=skylake-avx512 -mprefer-vector-width=512 or -mavx512f -mavx512dq -mavx512vl does that work - for s/uint64 -> float32 no correct AVX512 code is generated either (_mm512_cvtepi64_ps, _mm512_cvtepu64_ps) thx Gero
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0c6e792dd5c96a48c873b73c2d5b1ee4fc4b6b8e commit r12-990-g0c6e792dd5c96a48c873b73c2d5b1ee4fc4b6b8e Author: Jakub Jelinek Date: Fri May 21 21:13:06 2021 +0200 openmp: Fix up handling of implicit lastprivate on outer constructs for implicit linear and lastprivate IVs [PR99928] This patch fixes the handling of lastprivate propagation to outer combined/composite leaf constructs from implicit linear or lastprivate clauses on simd IVs and adds missing testsuite coverage for explicit and implicit lastprivate on simd IVs. 2021-05-21 Jakub Jelinek PR middle-end/99928 * gimplify.c (omp_lastprivate_for_combined_outer_constructs): New function. (gimplify_scan_omp_clauses) : Use it. (gimplify_omp_for): Likewise. * c-c++-common/gomp/pr99928-6.c: Remove all xfails. * c-c++-common/gomp/pr99928-13.c: New test. * c-c++-common/gomp/pr99928-14.c: New test.
[Bug middle-end/100717] New: missing warning for a call to a function with attribute access inlined into caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100717
Bug ID: 100717
Summary: missing warning for a call to a function with
attribute access inlined into caller
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC issues warnings for (likely) out of bounds accesses by calls to functions
declared with attribute access. An example is the call to f0() in f1() below.
But no warning is issued when the called function is inlined, as happens with
g0() in g1(). This is because the attribute on the called function disappears
once it's inlined.
This problem could be solved either by (also) issuing the warning early, just
before inlining, for the subset of calls with constant arguments, or by
preserving the call statements in some data structure even after they have been
inlined and analyzing them much later, after constant and range propagation, if
they're not removed by dead code elimination.
$ cat a.c && gcc -O2 -S -Wall a.c
__attribute__ ((access (write_only, 1, 3), access (read_only, 2, 3)))
__attribute__ ((noinline))
void f0 (int *a, const int *b, unsigned n)
{
for (unsigned i = 0; i != n; ++i)
a[i] += b[i];
}
void f1 (int a[4])
{
f0 (a, (int[]){ 3, 3, 3 }, 4); // warning (good)
}
__attribute__ ((access (write_only, 1, 3), access (read_only, 2, 3)))
void g0 (int *a, const int *b, unsigned n)
{
for (unsigned i = 0; i != n; ++i)
a[i] += b[i];
}
void g1 (int a[4])
{
g0 (a, (int[]){ 3, 3, 3 }, 4); // missing warning
}
a.c: In function ‘f1’:
a.c:11:3: warning: ‘f0’ reading 16 bytes from a region of size 12
[-Wstringop-overread]
11 | f0 (a, (int[]){ 3, 3, 3 }, 4); // warning (good)
| ^
a.c:11:17: note: source object ‘’ of size 12
11 | f0 (a, (int[]){ 3, 3, 3 }, 4); // warning (good)
| ^
a.c:3:6: note: in a call to function ‘f0’ declared with attribute ‘access
(read_only, 2, 3)’
3 | void f0 (int *a, const int *b, unsigned n)
| ^~
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #10 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:325aa13996bafce0c4927876c315d1fa706d9881 commit r12-989-g325aa13996bafce0c4927876c315d1fa706d9881 Author: Thomas Schwinge Date: Fri May 21 08:51:47 2021 +0200 [OpenACC privatization] Reject 'static', 'external' in blocks [PR90115] gcc/ PR middle-end/90115 * omp-low.c (oacc_privatization_candidate_p): Reject 'static', 'external' in blocks. gcc/testsuite/ PR middle-end/90115 * c-c++-common/goacc/privatization-1-compute-loop.c: Update. * c-c++-common/goacc/privatization-1-compute.c: Likewise. * c-c++-common/goacc/privatization-1-routine_gang-loop.c: Likewise. * c-c++-common/goacc/privatization-1-routine_gang.c: Likewise. libgomp/ PR middle-end/90115 * testsuite/libgomp.oacc-c-c++-common/static-variable-1.c: Update. * testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Likewise.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #9 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:11b8286a83289f5b54e813f14ff56d730c3f3185 commit r12-988-g11b8286a83289f5b54e813f14ff56d730c3f3185 Author: Thomas Schwinge Date: Thu May 20 16:11:37 2021 +0200 [OpenACC privatization] Largely extend diagnostics and corresponding testsuite coverage [PR90115] gcc/ PR middle-end/90115 * flag-types.h (enum openacc_privatization): New. * params.opt (-param=openacc-privatization): New. * doc/invoke.texi (openacc-privatization): Document it. * omp-general.h (get_openacc_privatization_dump_flags): New function. * omp-low.c (oacc_privatization_candidate_p): Add diagnostics. * omp-offload.c (execute_oacc_device_lower) : Re-work diagnostics. * target.def (goacc.adjust_private_decl): Add 'location_t' parameter. * doc/tm.texi: Regenerate. * config/gcn/gcn-protos.h (gcn_goacc_adjust_private_decl): Adjust. * config/gcn/gcn-tree.c (gcn_goacc_adjust_private_decl): Likewise. * config/nvptx/nvptx.c (nvptx_goacc_adjust_private_decl): Likewise. Preserve it for... (nvptx_goacc_expand_var_decl): ... use here. gcc/testsuite/ PR middle-end/90115 * c-c++-common/goacc/privatization-1-compute-loop.c: New file. * c-c++-common/goacc/privatization-1-compute.c: Likewise. * c-c++-common/goacc/privatization-1-routine_gang-loop.c: Likewise. * c-c++-common/goacc/privatization-1-routine_gang.c: Likewise. * gfortran.dg/goacc/privatization-1-compute-loop.f90: Likewise. * gfortran.dg/goacc/privatization-1-compute.f90: Likewise. * gfortran.dg/goacc/privatization-1-routine_gang-loop.f90: Likewise. * gfortran.dg/goacc/privatization-1-routine_gang.f90: Likewise. * c-c++-common/goacc-gomp/nesting-1.c: Update. * c-c++-common/goacc/private-reduction-1.c: Likewise. * gfortran.dg/goacc/private-3.f95: Likewise. libgomp/ PR middle-end/90115 * testsuite/libgomp.oacc-fortran/private-atomic-1-vector.f90: New file. * testsuite/libgomp.oacc-c-c++-common/firstprivate-1.c: Update. * testsuite/libgomp.oacc-c-c++-common/host_data-7.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-5.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-5.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-6.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-vector-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-vector-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-5.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-6.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-7.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-g-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-g-2.c: Likewise.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #8 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:5a0fe1f6c4ad0e50bf4684e723ae2ba17d94c9e4 commit r12-986-g5a0fe1f6c4ad0e50bf4684e723ae2ba17d94c9e4 Author: Thomas Schwinge Date: Thu May 20 15:55:18 2021 +0200 [OpenACC privatization] Explain OpenACC privatization candidate selection [PR90115] gcc/ PR middle-end/90115 * omp-low.c (oacc_privatization_candidate_p): New function. (oacc_privatization_scan_clause_chain) (oacc_privatization_scan_decl_chain): Use it. Also 'gcc_checking_assert' that we're not seeing duplicates.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #7 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:ad4612cb048b261f6834e9155e41e40e9252c80b commit r12-985-gad4612cb048b261f6834e9155e41e40e9252c80b Author: Thomas Schwinge Date: Thu May 20 15:45:06 2021 +0200 [OpenACC privatization] Skip processing if no work to be done [PR90115] gcc/ PR middle-end/90115 * omp-offload.c (execute_oacc_device_lower): Skip processing if no work to be done.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #6 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:21803fcaebeab36de0d7b6b8cf6abb9389f5e51f commit r12-984-g21803fcaebeab36de0d7b6b8cf6abb9389f5e51f Author: Thomas Schwinge Date: Thu May 20 15:44:09 2021 +0200 [OpenACC privatization] Explain two different configurations [PR90115] gcc/ PR middle-end/90115 * omp-offload.c (execute_oacc_device_lower): Explain.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #5 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:ff451ea723deb3fe8471eb96ac9381c063ec6533 commit r12-983-gff451ea723deb3fe8471eb96ac9381c063ec6533 Author: Thomas Schwinge Date: Thu May 20 15:37:07 2021 +0200 [OpenACC privatization] Don't let unhandled 'IFN_UNIQUE_OACC_PRIVATE' linger [PR90115] Make sure they're all handled in 'execute_oacc_device_lower'. Why we at all can have 'level == -1' cases is a separate bug to be fixed. gcc/ PR middle-end/90115 * omp-offload.c (execute_oacc_device_lower) : Diagnose and handle for 'level == -1' case, too. * internal-fn.c (expand_UNIQUE): Don't expect 'IFN_UNIQUE_OACC_PRIVATE'.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #4 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:3a285ebd0cf5ab762726018515d23280fa6dd445 commit r12-982-g3a285ebd0cf5ab762726018515d23280fa6dd445 Author: Thomas Schwinge Date: Thu May 20 15:22:24 2021 +0200 [OpenACC privatization] Don't evaluate OpenMP 'for' clauses [PR90115] gcc/ PR middle-end/90115 * omp-low.c (lower_omp_for): Don't evaluate OpenMP 'for' clauses.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #3 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:f6f45309d9fc140006886456b291e4ac24812cea commit r12-981-gf6f45309d9fc140006886456b291e4ac24812cea Author: Thomas Schwinge Date: Thu May 20 15:08:38 2021 +0200 [OpenACC privatization, nvptx] Tighten some aspects [PR90115] No functional change. gcc/ PR middle-end/90115 * config/nvptx/nvptx.c (nvptx_goacc_adjust_private_decl) (nvptx_goacc_expand_var_decl): Tighten.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:29a2f51806c5b30e17a8d0e9ba7915a3c53c34ff commit r12-980-g29a2f51806c5b30e17a8d0e9ba7915a3c53c34ff Author: Julian Brown Date: Fri Feb 26 04:34:49 2021 -0800 openacc: Add support for gang local storage allocation in shared memory [PR90115] This patch implements a method to track the "private-ness" of OpenACC variables declared in offload regions in gang-partitioned, worker-partitioned or vector-partitioned modes. Variables declared implicitly in scoped blocks and those declared "private" on enclosing directives (e.g. "acc parallel") are both handled. Variables that are e.g. gang-private can then be adjusted so they reside in GPU shared memory. The reason for doing this is twofold: correct implementation of OpenACC semantics, and optimisation, since shared memory might be faster than the main memory on a GPU. Handling of private variables is intimately tied to the execution model for gangs/workers/vectors implemented by a particular target: for current targets, we use (or on mainline, will soon use) a broadcasting/neutering scheme. That is sufficient for code that e.g. sets a variable in worker-single mode and expects to use the value in worker-partitioned mode. The difficulty (semantics-wise) comes when the user wants to do something like an atomic operation in worker-partitioned mode and expects a worker-single (gang private) variable to be shared across each partitioned worker. Forcing use of shared memory for such variables makes that work properly. In terms of implementation, the parallelism level of a given loop is not fixed until the oaccdevlow pass in the offload compiler, so the patch delays fixing the parallelism level of variables declared on or within such loops until the same point. This is done by adding a new internal UNIQUE function (OACC_PRIVATE) that lists (the address of) each private variable as an argument, and other arguments set so as to be able to determine the correct parallelism level to use for the listed variables. This new internal function fits into the existing scheme for demarcating OpenACC loops, as described in comments in the patch. Two new target hooks are introduced: TARGET_GOACC_ADJUST_PRIVATE_DECL and TARGET_GOACC_EXPAND_VAR_DECL. The first can tweak a variable declaration at oaccdevlow time, and the second at expand time. The first or both of these target hooks can be used by a given offload target, depending on its strategy for implementing private variables. This patch updates the TARGET_GOACC_ADJUST_PRIVATE_DECL target hook in the AMD GCN backend to the current name and prototype. (An earlier version of the hook was already present, but dormant.) gcc/ PR middle-end/90115 * doc/tm.texi.in (TARGET_GOACC_EXPAND_VAR_DECL) (TARGET_GOACC_ADJUST_PRIVATE_DECL): Add documentation hooks. * doc/tm.texi: Regenerate. * expr.c (expand_expr_real_1): Expand decls using the expand_var_decl OpenACC hook if defined. * internal-fn.c (expand_UNIQUE): Handle IFN_UNIQUE_OACC_PRIVATE. * internal-fn.h (IFN_UNIQUE_CODES): Add OACC_PRIVATE. * omp-low.c (omp_context): Add oacc_privatization_candidates field. (lower_oacc_reductions): Add PRIVATE_MARKER parameter. Insert before fork. (lower_oacc_head_tail): Add PRIVATE_MARKER parameter. Modify private marker's gimple call arguments, and pass it to lower_oacc_reductions. (oacc_privatization_scan_clause_chain) (oacc_privatization_scan_decl_chain, lower_oacc_private_marker): New functions. (lower_omp_for, lower_omp_target, lower_omp_1): Use these. * omp-offload.c (convert.h): Include. (oacc_loop_xform_head_tail): Treat private-variable markers like fork/join when transforming head/tail sequences. (struct var_decl_rewrite_info): Add struct. (oacc_rewrite_var_decl, is_sync_builtin_call): New functions. (execute_oacc_device_lower): Support rewriting gang-private variables using target hook, and fix up addr_expr and var_decl nodes afterwards. * target.def (adjust_private_decl, expand_var_decl): New hooks. * config/gcn/gcn-protos.h (gcn_goacc_adjust_gangprivate_decl): Rename to... (gcn_goacc_adjust_private_decl): ...this. * config/gcn/gcn-tree.c (gcn_goacc_adjust_gangprivate_decl): Rename to... (gcn_goacc_adjust_private_decl): ...this. Add LEVEL parameter. * config/gcn/gcn.c
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #6 from Harald van Dijk ---
If the warning should mention -fstrict-enums, it should only do it in specific
cases:
enum E { A, B, C };
int h(E e) {
switch (e) {
case A: return 0;
case B: return 0;
case C: return 0;
}
}
will still trigger the warning even with -fstrict-enums because now (E)3 is
valid.
[Bug c++/100716] member function template parameter not printed in candidate list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716 --- Comment #1 from Matthias Kretz (Vir) --- With -fno-pretty-templates both test cases do print the template_parms. That's because in dump_function_decl, without flag_pretty_templates, t isn't generalized and thus is not considered a primary template. And dump_template_parms only returns early if primary is true.
[Bug c++/100716] New: member function template parameter not printed in candidate list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716
Bug ID: 100716
Summary: member function template parameter not printed in
candidate list
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
CC: paolo.carlini at oracle dot com
Target Milestone: ---
template
struct A {
template
void f() { }
};
int main() {
A().f(0);
}
With -fpretty-templates this prints:
: In function 'int main()':
:8:6: error: no matching function for call to 'A::f(int)'
:4:12: note: candidate: 'template void A::f() [with U = U;
T = void]'
[...]
>From the diagnostics, it is not apparent what entity U applies to. Also 'with U
= U' is unnecessary noise. It should be:
:4:12: note: candidate: 'template void A::f() [with T =
void]'
However,
template
struct A {
template
void f(U) { }
};
int main() {
A().f();
}
doesn't need to show the function template parameter and should be diagnosed
as:
:4:12: note: candidate: 'template void A::f(U) [with T =
void]'
However, to distinguish the two cases, cp/error.c would need to determine
whether the function template parameters are deducible. Alternatively, it would
have to look at the list of function parameters and check whether all template
parameters are used somehow (even if not deducible). Not sure whether that's
worth the effort. I assume the current behavior was chosen because the majority
of function template parameters are deducible?
FWIW, I believe the fix for PR50828 was incorrect since it removes the ability
to control whether dump_template_parms called from dump_function_decl returns
early for primary templates or not. I think the flags need to be modified for
printing the function's scope, but not for dump_function_decl.
I'll try to come up with a patch.
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 52625, which changed state. Bug 52625 Summary: [9/10 Regression] Incorrect specialization semantics of friend class template declaration https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/52625] [9/10 Regression] Incorrect specialization semantics of friend class template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jason Merrill --- Fixed for 9.4/10.4/11.
[Bug c++/97938] [9/10 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed for 9.4/10.4/11.
[Bug c++/80456] [9/10 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jason Merrill --- Fixed for 9.4/10.4/11.
[Bug c++/97938] [9/10 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7168fb621b4442936d2a9429389a65f15043e5e4 commit r9-9549-g7168fb621b4442936d2a9429389a65f15043e5e4 Author: Jason Merrill Date: Fri Apr 2 11:05:46 2021 -0400 c++: lambda pack init-capture within generic lambda We represent the type of a pack init-capture as auto... with packs from the initializer stuck into PACK_EXPANSION_PARAMETER_PACKS so that expanding it produces the right number of elements. But when partially instantiating the auto..., we were changing PACK_EXPANSION_PARAMETER_PACKS to refer to only the auto itself. Fixed thus. gcc/cp/ChangeLog: PR c++/97938 * cp-tree.h (PACK_EXPANSION_AUTO_P): New. * lambda.c (add_capture): Set it. * pt.c (tsubst_pack_expansion): Handle it. gcc/testsuite/ChangeLog: PR c++/97938 * g++.dg/cpp2a/lambda-pack-init6.C: New test.
[Bug c++/52625] [9/10 Regression] Incorrect specialization semantics of friend class template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5b4cb06374890f2a190c9a989b569a9a15388445 commit r9-9548-g5b4cb06374890f2a190c9a989b569a9a15388445 Author: Jason Merrill Date: Wed Apr 7 15:38:07 2021 -0400 c++: base template friend [PR52625] Here we were mistakenly treating the injected-class-name as a partial specialization. gcc/cp/ChangeLog: PR c++/52625 * pt.c (maybe_process_partial_specialization): Check DECL_SELF_REFERENCE_P. gcc/testsuite/ChangeLog: PR c++/52625 * g++.dg/template/friend70.C: New test.
[Bug c++/80456] [9/10 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0c6b4e661d875410535e17a9d82e6a0d09f28c65 commit r9-9547-g0c6b4e661d875410535e17a9d82e6a0d09f28c65 Author: Jason Merrill Date: Thu Apr 15 15:13:18 2021 -0400 c++: constexpr and volatile member function [PR80456] When calling a static member function we still need to evaluate an explicit object argument. But we don't want to force a load of the entire object if the argument is volatile, so we take its address. If as a result it no longer has any side-effects, we don't need to evaluate it after all. gcc/cp/ChangeLog: PR c++/80456 * call.c (build_new_method_call_1): Check again for side-effects with a volatile object. gcc/testsuite/ChangeLog: PR c++/80456 * g++.dg/cpp0x/constexpr-volatile3.C: New test.
[Bug middle-end/90773] Improve piecewise operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773 --- Comment #8 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:53fb833d635da04f5b44af16bcea1082e7b59e75 commit r12-978-g53fb833d635da04f5b44af16bcea1082e7b59e75 Author: H.J. Lu Date: Fri May 21 05:16:20 2021 -0700 Elide expand_constructor if move by pieces is preferred Elide expand_constructor when the constructor is static storage and not mostly zeros and we can move it by pieces prefer to do so since that's usually more efficient than performing a series of stores from immediates. 2021-05-21 Richard Biener H.J. Lu gcc/ PR middle-end/90773 * expr.c (expand_constructor): Elide expand_constructor if move by pieces is preferred. gcc/testsuite/ * gcc.target/i386/pr90773-24.c: New test. * gcc.target/i386/pr90773-25.c: Likewise.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- Maybe the warning text should mention -fstrict-enums to make more people aware of it?
[Bug analyzer/100705] RFE: warn about dead store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100705 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #2 from Eric Gallager --- I think there's another bug open for this, but I can't find it at the moment...
[Bug fortran/100337] Should be able to pass non-present optional arguments to CO_BROADCAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337 Andre Vehreschild changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Andre Vehreschild --- Waiting for review
[Bug fortran/100337] Should be able to pass non-present optional arguments to CO_BROADCAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337 --- Comment #1 from Andre Vehreschild --- Created attachment 50853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50853=edit Check for unset before assigning to stat.
[Bug c++/88601] We may consider adding __builtin_convertvector and __builtin_shufflevector for better compatibility with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-21 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Mine for __builtin_shufflevector.
[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Tamar Christina --- Fixed on master and all open branches.
[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:2b40941d23b1570cdd90083b58fa0f66aa58c86e commit r9-9546-g2b40941d23b1570cdd90083b58fa0f66aa58c86e Author: Tamar Christina Date: Fri May 21 12:16:56 2021 +0100 libsanitizer: Remove cyclades from libsanitizer The Linux kernel has removed the interface to cyclades from the latest kernel headers[1] due to them being orphaned for the past 13 years. libsanitizer uses this header when compiling against glibc, but glibcs itself doesn't seem to have any references to cyclades. Further more it seems that the driver is broken in the kernel and the firmware doesn't seem to be available anymore. As such since this is breaking the build of libsanitizer (and so the GCC bootstrap[2]) I propose to remove this. [1] https://lkml.org/lkml/2021/3/2/153 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 libsanitizer/ChangeLog: PR sanitizer/100379 * sanitizer_common/sanitizer_common_interceptors_ioctl.inc: Cherry-pick llvm-project revision f7c5351552387bd43f6ca3631016d7f0dfe0f135. * sanitizer_common/sanitizer_platform_limits_posix.cc: Likewise. * sanitizer_common/sanitizer_platform_limits_posix.h: Likewise.
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #5 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:2df9d3c52e6758f6640e7c0ae0b7502c7cc1d430 commit r12-973-g2df9d3c52e6758f6640e7c0ae0b7502c7cc1d430 Author: Uros Bizjak Date: Fri May 21 13:03:04 2021 +0200 i386: Add comparisons for 4-byte vectors [PR100637] 2021-05-21 Uroš Bizjak gcc/ PR target/100637 * config/i386/i386-expand.c (ix86_expand_sse_movcc): Handle V4QI and V2HI modes. (ix86_expand_sse_movcc): Ditto. * config/i386/mmx.md (*3): New instruction pattern. (*eq3): Ditto. (*gt3): Ditto. (*xop_pcmov_): Ditto. (mmx_pblendvb32): Ditto. (mmx_pblendvb64): Rename from mmx_pblendvb. (vec_cmp): New expander. (vec_cmpu): Ditto. (vcond): Ditto. (vcondu): Ditto. (vcond_mask_): Ditto. gcc/testsuite/ PR target/100637 * g++.target/i386/pr100637-1b.C: New test. * g++.target/i386/pr100637-1w.C: Ditto. * gcc.target/i386/pr100637-2b.c: Ditto. * gcc.target/i386/pr100637-2w.c: Ditto.
[Bug testsuite/100713] g++.dg/cpp1y/lambda-generic-90842.C has ambiguous pass and fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100713 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Earnshaw --- I was confused - this was from an branch
[Bug target/100712] The vec_splatid instruction allows the creation of XXSPLTIDP instructions which produces undefined results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100712 --- Comment #1 from Segher Boessenkool --- As background, the ISA has in the xxspltidp description If IMM32 specifies a single-precision denormal value (i.e., bits 1:8 equal to 0 and bits 9:31 not equal to 0), the result is undefined. I see no other warnings in rs6000_expand_binop_builtin btw? There are some errors there, but those are more basic out-of-range errors. Something as specific as this is probably best left where it is now. Why do you think an error is better than a warning here? We allow creating UB everywhere else (but we do warn where possible).
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-21 --- Comment #2 from Segher Boessenkool --- (In reply to Richard Biener from comment #1) > I suppose we're confused about the vec_duplicate. Would generally swapping > the duplicate and the bit_not be profitable? Eventually it's a > simplification > combine could try - I belive it has some cases where it tries variants of the > original instructions when combining. Adding a combine helper pattern > looks like putting too much burden on the backend IMHO. > > We don't have a generic nand optab so handling this in ISEL on gimple > isn't straight-forward. > > But combine and/or forwprop could do this. Combine never tries anything. Combine makes *one* result; if that does not work, it does not do the combination. (This is not completely true, but in essence that is how it works, and it has to to not have exponential complexity). It would be good to define a canonical form for anything vec_duplicate. It probably is a good idea to pull the vec_duplicate as far outside as possible? Canonical forms hugely reduce the amount of work needed. Compare to how "andc" is represented (canonically with the inverted input first), or how "nand" is (we write that as an "orcc", an "or" with both inputs inverted, in canonical RTL). Because only one form is allowed, we only have to check for that one form everywhere. Confirmed.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
stream009 changed:
What|Removed |Added
CC||stream009 at gmail dot com
--- Comment #42 from stream009 ---
I got strange compile error when I use coroutine with UBSAN.
The weird thing is error is reported in compile time not runtime.
The code compile fine without UBSAN.
GCC version: 11.1
compile option: -std=c++20 -Wall -Wextra -pedantic-errors -fcoroutines
-fsanitize=undefined
compiler explorer link: https://godbolt.org/z/Yva6b1YTz
It seems error happen only coroutine that doesn't return value (promise has
return_void() defined). I don't get error with coroutine that return value.
(https://godbolt.org/z/3jcvYPcqa)
Let me know if I should report this as separate bug.
=== begin source ===
#include
struct result
{
struct promise_type
{
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
result get_return_object() { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
result error(int i)
{
if (i == 0) {
co_return;
}
}
=== end source ===
=== begin compile error ===
: In function 'void _Z5errori.actor(error(int)::_Z5errori.frame*)':
:21:9: warning: '' may be used uninitialized
[-Wmaybe-uninitialized]
21 | co_return;
| ^
:21:9: note: '' was declared here
21 | co_return;
| ^
=== end compile error ===
[Bug rtl-optimization/100714] New: -fpatchable-funtion-entry needs some TLC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100714 Bug ID: 100714 Summary: -fpatchable-funtion-entry needs some TLC Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- See https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570728.html (needed to resolve PR99888). We need some new hook(s) and/or refactoring of the generic code, because the spooky-action-at-a-distance thing is not maintainable: it especially will make random changes to generic code to random things on targets that do this.
[Bug testsuite/100713] New: g++.dg/cpp1y/lambda-generic-90842.C has ambiguous pass and fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100713 Bug ID: 100713 Summary: g++.dg/cpp1y/lambda-generic-90842.C has ambiguous pass and fail Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: rearnsha at gcc dot gnu.org Target Milestone: --- On aarch64-none-elf: > Tests that now fail, but worked before: > > aarch64-qemu: g++.dg/cpp1y/lambda-generic-90842.C -std=c++14 (test for > errors, line 4) > > Tests that now work, but didn't before: > > aarch64-qemu: g++.dg/cpp1y/lambda-generic-90842.C -std=c++14 (test for > errors, line 4) Which implies two tests are mapped to the same line but lack an appropriate (or have a malformed) report discriminator.
[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:a7e72b282177fbaa6a852324641c871313d326da commit r10-9862-ga7e72b282177fbaa6a852324641c871313d326da Author: Tamar Christina Date: Fri May 21 10:30:59 2021 +0100 libsanitizer: Remove cyclades from libsanitizer The Linux kernel has removed the interface to cyclades from the latest kernel headers[1] due to them being orphaned for the past 13 years. libsanitizer uses this header when compiling against glibc, but glibcs itself doesn't seem to have any references to cyclades. Further more it seems that the driver is broken in the kernel and the firmware doesn't seem to be available anymore. As such since this is breaking the build of libsanitizer (and so the GCC bootstrap[2]) I propose to remove this. [1] https://lkml.org/lkml/2021/3/2/153 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 libsanitizer/ChangeLog: PR sanitizer/100379 * sanitizer_common/sanitizer_common_interceptors_ioctl.inc: Cherry-pick llvm-project revision f7c5351552387bd43f6ca3631016d7f0dfe0f135. * sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise. * sanitizer_common/sanitizer_platform_limits_posix.h: Likewise. (cherry picked from commit 745dae5923aba02982563481d75a21595df22ff8)
[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:2bf34b9f4e446bf9be7f04458058dd5319fb396e commit r11-8455-g2bf34b9f4e446bf9be7f04458058dd5319fb396e Author: Tamar Christina Date: Fri May 21 10:30:59 2021 +0100 libsanitizer: Remove cyclades from libsanitizer The Linux kernel has removed the interface to cyclades from the latest kernel headers[1] due to them being orphaned for the past 13 years. libsanitizer uses this header when compiling against glibc, but glibcs itself doesn't seem to have any references to cyclades. Further more it seems that the driver is broken in the kernel and the firmware doesn't seem to be available anymore. As such since this is breaking the build of libsanitizer (and so the GCC bootstrap[2]) I propose to remove this. [1] https://lkml.org/lkml/2021/3/2/153 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 libsanitizer/ChangeLog: PR sanitizer/100379 * sanitizer_common/sanitizer_common_interceptors_ioctl.inc: Cherry-pick llvm-project revision f7c5351552387bd43f6ca3631016d7f0dfe0f135. * sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise. * sanitizer_common/sanitizer_platform_limits_posix.h: Likewise. (cherry picked from commit 745dae5923aba02982563481d75a21595df22ff8)
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #20 from Richard Biener --- Created attachment 50852 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50852=edit prototype for __builtin_shufflevector So this is a prototype for __builtin_shufflevector support. Most notably the C++ FE misses support for templates.
[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 --- Comment #5 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:745dae5923aba02982563481d75a21595df22ff8 commit r12-971-g745dae5923aba02982563481d75a21595df22ff8 Author: Tamar Christina Date: Fri May 21 10:30:59 2021 +0100 libsanitizer: Remove cyclades from libsanitizer The Linux kernel has removed the interface to cyclades from the latest kernel headers[1] due to them being orphaned for the past 13 years. libsanitizer uses this header when compiling against glibc, but glibcs itself doesn't seem to have any references to cyclades. Further more it seems that the driver is broken in the kernel and the firmware doesn't seem to be available anymore. As such since this is breaking the build of libsanitizer (and so the GCC bootstrap[2]) I propose to remove this. [1] https://lkml.org/lkml/2021/3/2/153 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 (cherry picked from commit f7c5351552387bd43f6ca3631016d7f0dfe0f135) libsanitizer/ChangeLog: PR sanitizer/100379 * sanitizer_common/sanitizer_common_interceptors_ioctl.inc: Cherry-pick llvm-project revision f7c5351552387bd43f6ca3631016d7f0dfe0f135. * sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise. * sanitizer_common/sanitizer_platform_limits_posix.h: Likewise.
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Closing as fixed.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 --- Comment #25 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f1c777f40aa0b6941efc7440495a8d7e0cc2a1bb commit r12-964-gf1c777f40aa0b6941efc7440495a8d7e0cc2a1bb Author: Jakub Jelinek Date: Fri May 21 10:39:50 2021 +0200 tree-optimization: Improve spaceship_replacement [PR94589] On Wed, May 19, 2021 at 01:30:31PM -0400, Jason Merrill via Gcc-patches wrote: > Here, when genericizing lexicographical_compare_three_way, we haven't yet > walked the operands, so (a == a) still sees ADDR_EXPR , but this is after > we've changed the type of a to REFERENCE_TYPE. When we try to fold (a == a) > by constexpr evaluation, the constexpr code doesn't understand trying to > take the address of a reference, and we end up crashing. > > Fixed by avoiding constexpr evaluation in genericize_spaceship, by using > fold_build2 instead of build_new_op on scalar operands. Class operands > should have been expanded during parsing. Unfortunately this slightly changed the IL and spaceship_replacement no longer pattern matches it. Here are 3 improvements that make it match: 1) as mentioned in the comment above spaceship_replacement, for strong_ordering, we are pattern matching something like: x == y ? 0 : x < y ? -1 : 1; and for partial_ordering x == y ? 0 : x < y ? -1 : x > y ? 1 : 2; but given the == comparison done first and the other comparisons only if == was false, we actually don't care if the other comparisons are < vs. <= (or > vs. >=), provided the operands of the comparison are the same; we know == is false when doing those and < vs. <= or > vs. >= have the same behavior for NaNs too 2) when y is an integral constant, we should treat x < 5 equivalently to x <= 4 etc. 3) the code punted if cond2_phi_edge wasn't a EDGE_TRUE_VALUE edge, but as the new IL shows, that isn't really needed; given 1) that > and >= are equivalent in the code, any of swapping the comparison operands, changing L[TE]_EXPR to G[TE]_EXPR or vice versa or swapping the EDGE_TRUE_VALUE / EDGE_FALSE_VALUE bits on the edges reverses one of the two comparisons 2021-05-21 Jakub Jelinek PR tree-optimization/94589 * tree-ssa-phiopt.c (spaceship_replacement): For integral rhs1 and rhs2, treat x <= 4 equivalently to x < 5 etc. In cmp1 and cmp2 (if not the same as cmp3) treat <= the same as < and >= the same as >. Don't require that cond2_phi_edge is true edge, instead take false/true edges into account based on cmp1/cmp2 comparison kinds.
[Bug fortran/100337] Should be able to pass non-present optional arguments to CO_BROADCAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337 Andre Vehreschild changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org CC||vehre at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-05-21 Status|UNCONFIRMED |ASSIGNED
[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #29 from Jakub Jelinek --- r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e fixed it.
[Bug target/100706] Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706 --- Comment #3 from Alexander Grund --- Ok, tested a few different bintuils versions. Bug occurs with 2.35 and 2.35.1 and seems to be fixed in 2.35.2 So I guess this can be closed
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #19 from Richard Biener --- (In reply to Jakub Jelinek from comment #18) > Also, __builtin_shufflevector allows to say -1 as a don't care element, our > current infrastructure doesn't allow that, but it would be nice even for > internal uses. On the other side, I think __builtin_shufflevector allows > only constant indices, while __builtin_shuffle allows arbitrary runtime > reshuffling. Yes, I think they complement each other. The question would be whether we'd want to represent both with VEC_PERM_EXPR on GIMPLE. And how to present the more flexible cases to the RTL expander and targets. const permutes seem to be handled via the vec_perm_const target hook and not the vec_perm optab, so a possibility would be to create a new hook with relaxed mode requirements - either by passing in three modes or some dummy RTXen. OTOH it should be possible to handle some cases purely in the expander by using paradoxical subregs when sources are of smaller size. With larger size sources the -1 would come in handy allowing for larger results and subregging them.
[Bug target/100706] Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706 --- Comment #2 from Alexander Grund --- Thanks for the reply. Although this was hard to test (need to interfere with TFs build process which must use the gold linker) I managed to link that one library manually with bfd and it did work. Hence yes, that is a gold linker issue. Any suggestions on how to proceed?
[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Richard Biener changed: What|Removed |Added Keywords||needs-bisection --- Comment #28 from Richard Biener --- So let's ask people to bisect what fixed it.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 Richard Biener changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Richard Biener --- 7: r82:SI=~r89:SI REG_DEAD r89:SI 8: r88:V4SI=vec_duplicate(r82:SI) REG_DEAD r82:SI 9: r87:V4SI=r88:V4SI:V4SI REG_DEAD r90:V4SI REG_DEAD r88:V4SI I suppose we're confused about the vec_duplicate. Would generally swapping the duplicate and the bit_not be profitable? Eventually it's a simplification combine could try - I belive it has some cases where it tries variants of the original instructions when combining. Adding a combine helper pattern looks like putting too much burden on the backend IMHO. We don't have a generic nand optab so handling this in ISEL on gimple isn't straight-forward. But combine and/or forwprop could do this.
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #4 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:dcde81134cb24da8e261a4346c806c676297922b commit r12-960-gdcde81134cb24da8e261a4346c806c676297922b Author: Uros Bizjak Date: Fri May 21 08:01:34 2021 +0200 i386: Add minmax and abs patterns for 4-byte vectors [PR100637] 2021-05-21 Uroš Bizjak gcc/ PR target/100637 * config/i386/mmx.md (SMAXMIN_MMXMODEI): New mode iterator. (3): Macroize expander from v4hi3> and 3 using SMAXMIN_MMXMODEI mode iterator. (*v4qi3): New insn pattern. (*v2hi3): Ditto. (SMAXMIN_VI_32): New mode iterator. (mode3): New expander. (UMAXMIN_MMXMODEI): New mode iterator. (3): Macroize expander from v8qi3> and 3 using UMAXMIN_MMXMODEI mode iterator. (*v4qi3): New insn pattern. (*v2hi3): Ditto. (UMAXMIN_VI_32): New mode iterator. (mode3): New expander. (abs2): New insn pattern. (ssse3_abs2, abs2): Move from ... * config/i386/sse.md: ... here.
