[Bug tree-optimization/102827] New: [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102827
Bug ID: 102827
Summary: [12 Regression] ICE: verify_ssa failed (error:
definition in block 20 does not dominate use in block
19)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc-12.0.0-alpha20211017 snapshot (g:5d4d64faa71a6389bfb76bfb3334b63360cf62c0)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/aarch64/sve/vcond_4_run.c, w/ -mavx -O1
-ftree-parallelize-loops=2 -ftree-vectorize --param ssa-name-def-chain-limit=2:
void
test_double_double_nugt_var (double *restrict dest, double *restrict src,
int b, int i)
{
while (i < 1)
{
dest[i] = b ? src[i] : 0.0;
++i;
}
}
% x86_64-pc-linux-gnu-gcc-12.0.0 -mavx -O1 -ftree-parallelize-loops=2
-ftree-vectorize --param ssa-name-def-chain-limit=2 -c e4ykrgkb.c
e4ykrgkb.c: In function 'test_double_double_nugt_var._loopfn.0':
e4ykrgkb.c:5:12: error: definition in block 20 does not dominate use in block
19
5 | while (i < 1)
|^
for SSA_NAME: _46 in statement:
_71 = _46 + _70;
during GIMPLE pass: vect
e4ykrgkb.c:5:12: internal compiler error: verify_ssa failed
0x10d79e3 verify_ssa(bool, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/tree-ssa.c:1214
0xdaa655 execute_function_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/passes.c:2049
0xdaaf6c execute_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/passes.c:2096
[Bug classpath/39747] Installation documentation should suggest building libgmp as PIC for building with libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Mark Wielaard --- (In reply to Eric Gallager from comment #8) > Is this still relevant now that gcc no longer ships with java? No, not really.
[Bug libgcj/44415] [5/6/7 regression] gmp multilib support broke bootstrap with static libgmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415 Bug 44415 depends on bug 39747, which changed state. Bug 39747 Summary: Installation documentation should suggest building libgmp as PIC for building with libjava https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
--- Comment #1 from Aldy Hernandez ---
(In reply to Dmitry G. Dyachenko from comment #0)
> r12-4256 FAST
> r12- SLOW
>
> g++ -fpreprocessed -std=c++98 -O2 --param
> max-jump-thread-duplication-stmts=NNN -c x.ii
Well, you are basically eliding the fail safe we put in specifically for this
code explosion:
/* Threading through an empty latch would cause code to be added to
the latch. This could alter the loop form sufficiently to cause
loop optimizations to fail. Disable these threads until after
loop optimizations have run. */
if ((threaded_through_latch
|| (taken_edge && taken_edge->dest == loop->latch))
&& !(cfun->curr_properties & PROP_loop_opts_done)
&& empty_block_p (loop->latch))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
" FAIL: Thread through latch before loop opts would create
non-empty latch\n");
return false;
The default is 15, and you're pushing it to > 180. Nothing good can come of
that.
That being said, in this very specific case, thread3 is creating some monster
PHIs which then thread4 further explodes. Luckily this combination is
disallowed by the pending threading restrictions in the presence of loops here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581894.html
But really, bad things can happen when you disable the fail-safe mechanisms
we've put in place.
Question to the larger audience... do we support bug reports against internal
--param constructs?
[Bug bootstrap/102828] New: [12 Regression] ODR violation in gimple-predicate-analysis.h since g:94c12ffac234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102828 Bug ID: 102828 Summary: [12 Regression] ODR violation in gimple-predicate-analysis.h since g:94c12ffac234 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- I noticed that during bootstrap and I think we should not introduce new ODR violations, it may break LTO bootstrap. [ 1689s] ../../gcc/ipa-predicate.h:114:7: warning: type 'struct predicate' violates the C++ One Definition Rule [-Wodr] [ 1689s] 114 | class predicate [ 1689s] | ^ [ 1689s] ../../gcc/gimple-predicate-analysis.h:48: note: a different type is defined in another translation unit [ 1689s]48 | class predicate
[Bug bootstrap/102828] [12 Regression] ODR violation in gimple-predicate-analysis.h since g:94c12ffac234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102828 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-19 Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 Known to fail||12.0 Known to work||11.2.0 Ever confirmed|0 |1
[Bug c++/102786] [c++20] virtual pmf sometimes rejected as not a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102786 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f45610a45236e97616726ca042898d6ac46a082e commit r12-4491-gf45610a45236e97616726ca042898d6ac46a082e Author: Jakub Jelinek Date: Tue Oct 19 09:24:57 2021 +0200 c++: Don't reject calls through PMF during constant evaluation [PR102786] The following testcase incorrectly rejects the c initializer, while in the s.*a case cxx_eval_* sees .__pfn reads etc., in the s.*&S::foo case get_member_function_from_ptrfunc creates expressions which use INTEGER_CSTs with type of pointer to METHOD_TYPE. And cxx_eval_constant_expression rejects any INTEGER_CSTs with pointer type if they aren't 0. Either we'd need to make sure we defer such folding till cp_fold but the function and pfn_from_ptrmemfunc is used from lots of places, or the following patch just tries to reject only non-zero INTEGER_CSTs with pointer types if they don't point to METHOD_TYPE in the hope that all such INTEGER_CSTs with POINTER_TYPE to METHOD_TYPE are result of folding valid pointer-to-member function expressions. I don't immediately see how one could create such INTEGER_CSTs otherwise, cast of integers to PMF is rejected and would have the PMF RECORD_TYPE anyway, etc. 2021-10-19 Jakub Jelinek PR c++/102786 * constexpr.c (cxx_eval_constant_expression): Don't reject INTEGER_CSTs with type POINTER_TYPE to METHOD_TYPE. * g++.dg/cpp2a/constexpr-virtual19.C: New test.
[Bug fortran/102816] [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 since r12-4452-g1e819bd95ebeefc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102816 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-19 Summary|[12 Regression] ICE in |[12 Regression] ICE in |resolve_structure_cons, at |resolve_structure_cons, at |fortran/resolve.c:1467 |fortran/resolve.c:1467 ||since ||r12-4452-g1e819bd95ebeefc1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-4452-g1e819bd95ebeefc1.
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 Martin Liška changed: What|Removed |Added Summary|[12 Regression] ICE in |[12 Regression] ICE in |gfc_clear_shape, at |gfc_clear_shape, at |fortran/expr.c:422 |fortran/expr.c:422 since ||r12-4278-g74ccca380cde5e79 Last reconfirmed||2021-10-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r12-4278-g74ccca380cde5e79 with: $ valgrind --trace-children=yes gfortran pr102817.f90 -c ==19067== Memcheck, a memory error detector ==19067== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==19067== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info ==19067== Command: gfortran pr102817.f90 -c ==19067== ==19074== Memcheck, a memory error detector ==19074== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==19074== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info ==19074== Command: /home/marxin/bin/gcc/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/f951 pr102817.f90 -quiet -dumpbase pr102817.f90 -dumpbase-ext .f90 -mtune=generic -march=x86-64 -fintrinsic-modules-path /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/12.0.0/finclude -fpre-include=/usr/include/finclude/math-vector-fortran.h -o /tmp/ccfJ3EKQ.s ==19074== ==19074== Invalid read of size 4 ==19074==at 0x4B52590: __gmpz_clear (clear.c:38) ==19074==by 0x8F92DB: gfc_clear_shape(__mpz_struct (*) [1], int) (expr.c:422) ==19074==by 0x8F9314: gfc_free_shape(__mpz_struct (**) [1], int) (expr.c:432) ==19074==by 0x8F9417: free_expr0(gfc_expr*) (expr.c:513) ==19074==by 0x8F95E4: gfc_replace_expr(gfc_expr*, gfc_expr*) (expr.c:626) ==19074==by 0x8FE3F2: remove_subobject_ref (expr.c:1483) ==19074==by 0x8FE3F2: simplify_const_ref(gfc_expr*) (expr.c:2001) ==19074==by 0x8FEE71: gfc_simplify_expr(gfc_expr*, int) (expr.c:2314) ==19074==by 0x8FF267: simplify_parameter_variable(gfc_expr*, int) [clone .part.0] (expr.c:2143) ==19074==by 0x8FF0D0: simplify_parameter_variable (expr.c:2086) ==19074==by 0x8FF0D0: gfc_simplify_expr(gfc_expr*, int) (expr.c:2281) ==19074==by 0x8FEBE6: simplify_intrinsic_op (expr.c:1190) ==19074==by 0x8FEBE6: gfc_simplify_expr(gfc_expr*, int) (expr.c:2270) ==19074==by 0x97EFD1: resolve_operator(gfc_expr*) (resolve.c:4470) ==19074==by 0x97B777: gfc_resolve_expr (resolve.c:7136) ==19074==by 0x97B777: gfc_resolve_expr(gfc_expr*) (resolve.c:7105) ==19074== Address 0x51a4450 is 0 bytes after a block of size 16 alloc'd ==19074==at 0x484315C: calloc (vg_replace_malloc.c:1117) ==19074==by 0x1EA2BD4: xcalloc (xmalloc.c:164) ==19074==by 0x8F9A35: gfc_copy_shape(__mpz_struct (*) [1], int) (expr.c:814) ==19074==by 0x8F9BC3: gfc_copy_expr(gfc_expr*) (expr.c:405) ==19074==by 0x8FF2C8: simplify_parameter_variable(gfc_expr*, int) [clone .part.0] (expr.c:2127) ==19074==by 0x8FF0D0: simplify_parameter_variable (expr.c:2086) ==19074==by 0x8FF0D0: gfc_simplify_expr(gfc_expr*, int) (expr.c:2281) ==19074==by 0x8FEBE6: simplify_intrinsic_op (expr.c:1190) ==19074==by 0x8FEBE6: gfc_simplify_expr(gfc_expr*, int) (expr.c:2270) ==19074==by 0x97EFD1: resolve_operator(gfc_expr*) (resolve.c:4470) ==19074==by 0x97B777: gfc_resolve_expr (resolve.c:7136) ==19074==by 0x97B777: gfc_resolve_expr(gfc_expr*) (resolve.c:7105) ==19074==by 0x986732: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.c:11908) ==19074==by 0x98ADA1: resolve_codes(gfc_namespace*) (resolve.c:17512) ==19074==by 0x975E38: gfc_resolve (resolve.c:17547) ==19074==by 0x975E38: gfc_resolve(gfc_namespace*) (resolve.c:17526)
[Bug tree-optimization/102827] [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19) since r12-4398-g9b2ad21ab3ebc21a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102827 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[12 Regression] ICE:|[12 Regression] ICE: |verify_ssa failed (error: |verify_ssa failed (error: |definition in block 20 does |definition in block 20 does |not dominate use in block |not dominate use in block |19) |19) since ||r12-4398-g9b2ad21ab3ebc21a Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-19 Target Milestone|--- |12.0 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r12-4398-g9b2ad21ab3ebc21a.
[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814 --- Comment #2 from Richard Biener --- (In reply to Aldy Hernandez from comment #1) > Question to the larger audience... do we support bug reports against > internal --param constructs? Yes. Generally 'max-jump-thread-duplication-stmts' would suggest this is a parameter limiting code size growth and one that might affect compile-time in a linear fashion - exponential growth here is unexpected. The reporter states a 180 -> 181 parameter change trips this over unexpectedly which is a case worth investigating (it suggests a limit elsewhere is missing). For example the alias walking code counts the amount of "work" it does and has a limit on that, allowing linear growth parametrization. Not sure if there's sth in the threader and/or ranger that would support accumulating a work budget and stop after it is exhausted, but something like that would be very useful (not sure if that's the problem at hand in this case).
[Bug fortran/102816] [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 since r12-4452-g1e819bd95ebeefc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102816 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |12.0
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |12.0
[Bug tree-optimization/102819] [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |11.3 --- Comment #2 from Richard Biener --- Note the correctness fix also needs backporting.
[Bug tree-optimization/102827] [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19) since r12-4398-g9b2ad21ab3ebc21a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102827 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug bootstrap/102828] [12 Regression] ODR violation in gimple-predicate-analysis.h since g:94c12ffac234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102828 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #1 from Richard Biener --- Yes, we should rename one instance.
[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org CC||amacleod at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2021-10-19 Status|UNCONFIRMED |NEW --- Comment #3 from Aldy Hernandez --- (In reply to Richard Biener from comment #2) > (In reply to Aldy Hernandez from comment #1) > > Question to the larger audience... do we support bug reports against > > internal --param constructs? > > Yes. Generally 'max-jump-thread-duplication-stmts' would suggest this is > a parameter limiting code size growth and one that might affect compile-time > in a linear fashion - exponential growth here is unexpected. The reporter > states a 180 -> 181 parameter change trips this over unexpectedly which is > a case worth investigating (it suggests a limit elsewhere is missing). > > For example the alias walking code counts the amount of "work" it does and > has a limit on that, allowing linear growth parametrization. Not sure if > there's sth in the threader and/or ranger that would support accumulating > a work budget and stop after it is exhausted, but something like that would > be very useful (not sure if that's the problem at hand in this case). ISTR Andrew had some patches to stop solving for some combination of extremely large PHIs. Not sure whether this is the issue at hand, but perhaps it's worth looking at. I'll put this in the back burner for now, since the loop threading restrictions make this a non-issue, but I'll come back to it later. Thanks.
[Bug middle-end/102823] [11/12 Regression] glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 --- Comment #2 from Richard Biener --- Yeah, I think I've seen this exact bug before. Note while 'int' and 'unsigned' inter-operate wrt TBAA two structure types differing only in the signedness of a _member_ do not.
[Bug middle-end/102823] [11/12 Regression] glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 98594 ***
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 Richard Biener changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #7 from Richard Biener --- *** Bug 102823 has been marked as a duplicate of this bug. ***
[Bug sanitizer/64888] ubsan doesn't work with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888 Claudio Kozický changed: What|Removed |Added CC||claudiokozicky at gmail dot com --- Comment #5 from Claudio Kozický --- Created attachment 51627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51627&action=edit A minimal testcase to reproduce the bug.
[Bug libstdc++/102825] std::move_only_function's implementation breaking existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102825 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2021-10-19 --- Comment #2 from Jonathan Wakely --- Oh dear, I need to run my clang tests with -std=gnu++2b not -std=gnu++2a
[Bug sanitizer/64888] ubsan doesn't work with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888 --- Comment #6 from Claudio Kozický --- Created attachment 51628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51628&action=edit GCC version This is the version of GCC with which I have reproduced the bug with.
[Bug middle-end/102829] New: Redundant null check after atomic load from that address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102829
Bug ID: 102829
Summary: Redundant null check after atomic load from that
address
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: laurynas.biveinis at gmail dot com
Target Milestone: ---
The following source code
struct d {
long b;
d *e() {
__atomic_load_n(&b, 0);
return this;
}
};
d *j;
void i();
void k() {
auto l = j->e();
if (l)
i();
}
produces the following bit of assembly with -O3 on x86_64
(https://godbolt.org/z/G1ThvnMWP):
...
mov rdx, QWORD PTR [rax]
testrax, rax
je .L1
...
It first dereferences the address at RAX, and later checks whether RAX == 0.
Since we already tried accessing memory at that address, the nullptr check
seems redundant. Moreover, since the address happens to be of 'this' of
variable j, it being equal to nullptr is UB anyway and may be assumed to be !=
nullptr?
Clang tests show the redundant test being present up to version 11 inclusive
(https://godbolt.org/z/rT3ha4enb) and absent from version 12 onwards
(https://godbolt.org/z/Gfb9EWMfq)
[Bug target/93183] SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183 --- Comment #5 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:6b4c18b98127087d7f14062b81bc678f0589cd36 commit r12-4493-g6b4c18b98127087d7f14062b81bc678f0589cd36 Author: prathamesh.kulkarni Date: Tue Oct 19 13:51:51 2021 +0530 [sve] PR93183 - Add support for conditional neg. gcc/testsuite/ChangeLog: PR target/93183 * gcc.target/aarch64/sve/pr93183.c: Remove -mcpu=generic+sve from dg-options.
[Bug tree-optimization/102827] [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19) since r12-4398-g9b2ad21ab3ebc21a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102827
--- Comment #3 from Richard Biener ---
The following reproduces the issue with -O -mavx -ftree-vectorize --param
ssa-name-def-chain-limit=0
The issue is that split_constant_offset doesn't see through the conversion
in that case and the vectorizer inserts the alias test before where
if-conversion
inserted the invariant stmt. Basically the vectorizer assumes there's
no defs (that end up being used) between the .LOOP_VECTORIZED test and the loop
header.
Now the --param is somewhat of a red herring and if-conversion only requires
an _extra_ length of the chain of 1 (but we might be close to the limit from
in-loop uses).
void
test_double_double_nugt_var (double *dest, double *src, int b, int i)
{
while (i < 1)
{
dest[i] = b ? src[i] : 0.0;
++i;
}
}
[Bug sanitizer/64888] ubsan doesn't work with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888 Claudio Kozický changed: What|Removed |Added Attachment #51628|0 |1 is obsolete|| --- Comment #7 from Claudio Kozický --- Created attachment 51629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51629&action=edit GCC 11.1.0 compilation log on Arch Linux executed command: gcc -v -save-temps -fsanitize=undefined -fopenmp minimal_example.c
[Bug sanitizer/64888] ubsan doesn't work with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888 --- Comment #8 from Claudio Kozický --- Created attachment 51630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51630&action=edit GCC 11.1.0 preprocessed source executed command: gcc -v -save-temps -fsanitize=undefined -fopenmp minimal_example.c
[Bug tree-optimization/102829] Redundant null check after atomic load from that address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102829 Richard Biener changed: What|Removed |Added Component|middle-end |tree-optimization Ever confirmed|0 |1 Blocks||85316 Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2021-10-19 --- Comment #1 from Richard Biener --- We don't derive non-nullness for the pointer dereferenced by the atomic builtins yet. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug tree-optimization/102830] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102830
Bug ID: 102830
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a regression from GCC 8.* and affect GCC 9.* and later.
At -O3, the generated code segfaults, while at -Os and -O2, it hangs.
[655] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211019 (experimental) [master r12-4491-gf45610a4523] (GCC)
[656] %
[656] % gcctk -O0 small.c; ./a.out
[657] %
[657] % gcctk -O3 small.c
[658] % ./a.out
Segmentation fault
[659] %
[659] % cat small.c
int main() {
unsigned a = 0, b;
for (; a < 2; a++) {
b = ~(~a - 1 - a);
if (a > b)
break;
}
return 0;
}
[Bug c++/91118] ubsan does not work with openmp default (none) directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91118 Claudio Kozický changed: What|Removed |Added CC||claudiokozicky at gmail dot com --- Comment #5 from Claudio Kozický --- I can confirm this bug is no longer present in GCC 11.1.0.
[Bug tree-optimization/102830] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102830 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 100740 ***
[Bug tree-optimization/100740] [9/10/11/12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740 --- Comment #7 from Martin Liška --- *** Bug 102830 has been marked as a duplicate of this bug. ***
[Bug fortran/102745] CLASS → TYPE check fails after RESHAPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102745 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:3de82c6c36fea8fad7145b62ccb3a7c06d1f3c51 commit r11-9173-g3de82c6c36fea8fad7145b62ccb3a7c06d1f3c51 Author: Tobias Burnus Date: Mon Oct 18 09:49:05 2021 +0200 Fortran: Fix CLASS conversion check [PR102745] PR fortran/102745 gcc/fortran/ChangeLog * intrinsic.c (gfc_convert_type_warn): Fix checks by checking CLASS and do typcheck in correct order for type extension. * misc.c (gfc_typename): Print proper not internal CLASS type name. gcc/testsuite/ChangeLog * gfortran.dg/class_72.f90: New. (cherry picked from commit 017665f63047ce47b087b0b283548a60e5abf3d2)
[Bug middle-end/102823] [11/12 Regression] glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 --- Comment #4 from Sergei Trofimovich --- Thank you! Added a link to upstream issue report: https://github.com/g-truc/glm/pull/1087
[Bug target/102625] [meta-bug] -mcmodel=large can't link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102625 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Florian Weimer --- libc_nonshared.a and crt1.o from glibc need build changes even for dynamic linking.
[Bug c++/31573] -Wall-all to enable all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #9 from Gabriel Ravier --- I would also quite like to note myself that numerous people I know have found Clang's `-Weverything` very useful, especially for finding new warnings. The only way I've been able to find some of GCC's most useful flags was by manually making a full list off GCC's manual (which took a long while !), and I have to say this is a particularly annoying process to go through, especially when such a list has to be updated on every new GCC version.
[Bug bootstrap/102831] New: [12 regression] Spurious -Wparentheses etc. warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102831
Bug ID: 102831
Summary: [12 regression] Spurious -Wparentheses etc. warnings
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: *-*-solaris2.11
Recently, Solaris bootstrap has repeatedly been broken in very confusing ways:
*
/vol/gcc/src/hg/master/local/gcc/lra-constraints.c: In function 'bool
curr_insn_transform(bool)':
/vol/gcc/src/hg/master/local/gcc/lra-constraints.c:4367:21: error: suggest
parentheses around assignment used as truth value [-Werror=parentheses]
4367 | (c = *constraint) && c != ',' && c != '#';
| ~~~^~
Solaris 11.4/SPARC, once 20211006, again 20211018
*
/vol/gcc/src/hg/master/local/libgomp/oacc-init.c:876:1: error: optimization
attribute on ‘acc_on_device’ follows definition but the attribute doesn’t match
[-Werror=attributes]
876 | {
| ^
/vol/gcc/src/hg/master/local/libgomp/oacc-init.c:875:1: note: previous
definition of ‘acc_on_device’ with type ‘int(acc_device_t)’
875 | acc_on_device (acc_device_t dev)
| ^
/vol/gcc/src/hg/master/local/libgomp/oacc-init.c:954:1: internal compiler
error: in dwarf2out_register_main_translation_unit, at dwarf2out.c:28329
954 | }
| ^
0x109240f dwarf2out_register_main_translation_unit
/vol/gcc/src/hg/master/local/gcc/dwarf2out.c:28328
0xc184b3 pop_scope()
/vol/gcc/src/hg/master/local/gcc/c/c-decl.c:1217
0xc19963 pop_file_scope()
/vol/gcc/src/hg/master/local/gcc/c/c-decl.c:1465
0xdf4be7 c_common_parse_file()
/vol/gcc/src/hg/master/local/gcc/c-family/c-opts.c:1238
Solaris 11.4/SPARC, 32 and 64-bit, 20211003
*
In file included from /vol/gcc/src/hg/master/local/gcc/sparseset.c:23:
/vol/gcc/src/hg/master/local/gcc/sparseset.c: In function 'void
sparseset_ior(sparseset, sparseset, sparseset)':
/vol/gcc/src/hg/master/local/gcc/sparseset.h:215:20: error: suggest parentheses
around assignment used as truth value [-Werror=parentheses]
215 |&& (((ITER) = sparseset_iter_elm (SPARSESET)) || 1);
\
|^
/vol/gcc/src/hg/master/local/gcc/sparseset.c:214:7: note: in expansion of macro
'EXECUTE_IF_SET_IN_SPARSESET'
214 | EXECUTE_IF_SET_IN_SPARSESET (b, e)
| ^~~
Solaris 11.3, first SPARC, 20210924, then x86, 20211001, 20211015, probably
more
reghunts on sparc and x86 converged, but the results made no sense:
sparc as of 20210924 identified
commit 4e7a92c0ff3871d955ca8fb133f869b216d7224d
Author: Richard Earnshaw
Date: Tue Sep 21 11:14:46 2021 +0100
arm: pass architecture extensions to assembler if supported
x86 as of 20211001 identified
commit a11052d98db2f2a61841f0c5ee84de4ca1b3e296
Author: Jonathan Wakely
Date: Tue Sep 28 12:35:29 2021 +0100
libstdc++: Improve std::forward static assert message
This seems like some sort of memory corruption to me, but I'm a bit at a loss
on how to proceed.
When continuing the builds with adding -Wno-error=parentheses to the affected
files, the test results showed nothing unexpected.
[Bug bootstrap/102831] [12 regression] Spurious -Wparentheses etc. warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102831 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/102785] [12 Regression] {smul,umul}_highpart changes break bfin-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102785 --- Comment #3 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:f98359ba9d3775319fb3181009be7d3dafe9ba15 commit r12-4497-gf98359ba9d3775319fb3181009be7d3dafe9ba15 Author: Roger Sayle Date: Tue Oct 19 11:00:10 2021 +0100 PR target/102785: Correct addsub/subadd patterns on bfin. This patch resolves PR target/102785 where my recent patch to constant fold saturating addition/subtraction exposed a latent bug in the bfin backend. The patterns used for blackfin's V2HI ssaddsub and sssubadd instructions had the indices/operations swapped. This was harmless until we started evaluating these expressions at compile-time, when the mismatch was caught by the testsuite. 2021-10-19 Roger Sayle gcc/ChangeLog PR target/102785 * config/bfin/bfin.md (addsubv2hi3, subaddv2hi3, ssaddsubv2hi3, sssubaddv2hi3): Swap the order of operators in vec_concat.
[Bug fortran/102815] gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org CC||burnus at gcc dot gnu.org Last reconfirmed||2021-10-19 --- Comment #1 from Tobias Burnus --- Created attachment 51631 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51631&action=edit Patch I don't have a big endian system at hand. Can you check whether the attached patch fixes it? Thanks - and sorry for not taking big endian into account.
[Bug c++/31573] -Wall-all to enable all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 --- Comment #10 from Jonathan Wakely --- You're doing it wrong. gcc -Q --help=warnings
[Bug fortran/101635] FAIL: gfortran.dg/PR93963.f90 – alias-handling issue with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101635 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Tobias Burnus --- FIXED in GCC 12. If new issues are found, please open an new PR and CC me. (Like: PR 102815 - which exposes a big-endian issue with a testcase.)
[Bug c++/31573] -Wall-all to enable all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 --- Comment #11 from Gabriel Ravier --- Well, that does help, although it is still a significant annoyance that would take more than its fair share of time to handle. (Also, is it still really that much of a concern anymore that users would think -Weverything is a normal flag to set in compilations ? I've basically never seen this happen with Clang's flag, so it seems like an unreasonable concern, especially considering the amount of warning flags that have been added since 2007+the amount of warning flags that are rather specialized and obviously result in an extremely large amount of false positives on a lot of code)
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Tobias Burnus --- Close as FIXED. * * * Now that my big patch has been applied, I tried the example from comment 0 (Fortran part) and comment 1 (C part) and the stand-alone testcases PR93308.f90 PR93963.f90 PR94327.c PR94327.f90 PR94331.c PR94331.f90 PR97046.f90 of the patch in comment 12. All pass with -O0 and -Ofast. (Well, I had to change the expected version number to 1 (not 0) of comment 1 - as GCC uses "#define CFI_VERSION 1".) I am not sure whether it makes sense to add any of those testcases or not. Given that there is already quite some coverage, I have not – but can be easily convinced to do so. Thanks, José for the testcases - and the patches, which weren't reviewed. (Tip: please ping them after a while; otherwise, they might end up unreviewed.) (I think at the end doing the full inlining of the conversion code made more sense, but was also a huge effort.)
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Tobias Burnus --- Close as FIXED. Except for the version == 0 which should be version == 1, as #define CFI_VERSION 1, the testcase of comment 0 (Fortran part) and comment 1 (C part) do pass now. Thanks for bug reports José and your patch(es)!
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus --- FIXED (in GCC 12). Thanks Igor for the testcase!
[Bug fortran/102086] [F2008][TS29113] Accepts invalid scalar TYPE(*) as actual argument to assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102086 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Tobias Burnus --- FIXED (GCC 12) Now reports: 7 | call foo(x)! WRONG foo's is assumed-rank/needs an array descriptor | 1 Error: Assumed-type actual argument at (1) corresponding to assumed-rank dummy argument ‘y’ must be assumed-shape or assumed-rank (But I think that was fixed not by this patch but by Sandra's patch a few commits earlier.)
[Bug fortran/92189] Fortran-written bind(C) function with allocatable argument does not update C descriptor on exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92189 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Tobias Burnus --- Close as FIXED (in GCC 12)
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 Bug 92284 depends on bug 92189, which changed state. Bug 92189 Summary: Fortran-written bind(C) function with allocatable argument does not update C descriptor on exit https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92189 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 --- Comment #7 from Segher Boessenkool --- (In reply to Richard Biener from comment #5) > Even out-of-line does not help if there are visible CSE/association > opportunities across such call. Yeah, good point. > A workaround is to make the out-of-line > function __attribute__((returns_twice)) which should insert artificial > control flow > preventing such transforms. Is there anything that guarantees that to work (other than our actual current implementation)? It is much more stringent / expensive than we would want, but if it is the best we can do...
[Bug tree-optimization/102827] [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19) since r12-4398-g9b2ad21ab3ebc21a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102827 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d996799a507f9f4c379b55b004233be92fa63380 commit r12-4498-gd996799a507f9f4c379b55b004233be92fa63380 Author: Richard Biener Date: Tue Oct 19 10:19:12 2021 +0200 tree-optimization/102827 - avoid stmts in preheader The PR shows that when carefully crafting the runtime alias condition in the vectorizer we might end up using defs from the loop preheader but will end up inserting the condition before the .LOOP_VECTORIZED call. So the following makes sure to insert invariants before that when we versioned the loop, preserving the invariant the vectorizer relies on. 2021-10-19 Richard Biener PR tree-optimization/102827 * tree-if-conv.c (predicate_statements): Add pe parameter and use that edge to insert invariant stmts on. (combine_blocks): Pass through pe. (tree_if_conversion): Compute the edge to insert invariant stmts on and pass it along. * gcc.dg/pr102827.c: New testcase.
[Bug tree-optimization/102827] [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19) since r12-4398-g9b2ad21ab3ebc21a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102827 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug fortran/101308] Bind(C): gfortran does not create C descriptors for scalar pointer/allocatable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101308
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Tobias Burnus ---
FIXED (in GCC 12)
The committed c-interop / TS29113 testsuite now passes – and the testcase from
comment 0 gives:
{
integer(kind=4) * p;
p = 0B;
{
struct CFI_cdesc_t00 cfi.0;
cfi.0.version = 1;
cfi.0.rank = 0;
cfi.0.type = 1025;
cfi.0.attribute = 0;
cfi.0.base_addr = (void *) p;
cfi.0.elem_len = 4;
ctest (&cfi.0);
p = (integer(kind=4) *) cfi.0.base_addr;
}
}
[Bug fortran/101309] Bind(C): gfortran creates invalid C descriptor for result of TRANSPOSE intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101309 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED (in GCC 12) Note: TRANSPOSE now yields an descriptor where the dimension are swapped, i.e. dim[0].sm > dim[1].sm, unless the dummy argument has to be contiguous. Otherwise, the testsuite passes now. (For SHAPE and polymorphism with RESHAPE and nested TRANSPOSE, other PRs exists.)
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #8 from Tobias Burnus ---
The BIND(C) issue is fixed - but I keep this PR open as there is still an issue
with the non-bind(C) part. Namely:
testsuite/gfortran.dg/bind-c-char-descr.f90
fails for:
...
subroutine strg_print_2(this, xfail)
if(associated(strn))then
if (len (strn) /= 3) stop 31
if (strn /= "abc") then
if (present (xfail)) then
print *, 'INVALID STRING - EXPECTED "abc" / PR47225' ! <<< PR is
wrong :-/
else
stop 32
end if
The call has:
scalar.4 = 97; // that's 'a' -> expected: "abc".
desc.3.dtype = {.elem_len=1, .rank=0, .type=1}; // not the elem_len=1;
should be len*kind
desc.3.data = (void *) &scalar.4;
desc.3.span = (integer(kind=8)) desc.3.dtype.elem_len;
[Bug fortran/102745] CLASS → TYPE check fails after RESHAPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102745 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tobias Burnus --- FIXED (for GCC 11 + 12).
[Bug tree-optimization/102832] New: [12 Regression] ICE in vect_create_partial_epilog with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102832
Bug ID: 102832
Summary: [12 Regression] ICE in vect_create_partial_epilog with
-O3 -msve-vector-bits=128
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat t.c
int a, b;
char c;
signed char d(int e, int f) { return e - f; }
void g() {
a = 0;
for (; a >= -17; a = d(a, 1))
c ^= b;
}
$ aarch64-linux-gnu-gcc -c t.c -march=armv8.2-a+sve -O3 -msve-vector-bits=128
during GIMPLE pass: vect
t.c: In function ‘g’:
t.c:4:6: internal compiler error: in vect_create_partial_epilog, at
tree-vect-loop.c:5038
4 | void g() {
| ^
0x1156110 vect_create_partial_epilog
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:5035
0x1164be3 vect_transform_cycle_phi(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, _slp_instance*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:7772
0x1150a1c vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.c:11107
0x1174723 vect_transform_loop(_loop_vec_info*, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:9731
0x11b0f44 try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:
0x11b1662 try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1148
0x11b170b try_vectorize_loop
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1168
0x11b19e9 vectorize_loops()
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1249
0x1030ef3 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-loop.c:413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 --- Comment #8 from Segher Boessenkool --- (In reply to jos...@codesourcery.com from comment #6) > Generically (and if the command-line options are such that floating-point > control / status bits are to be respected by optimizations), *any* > function call might access or modify floating-point control and status > bits, subject to e.g. const functions not being able to access them, pure > functions not being able to modify them, functions whose body is known > having properties based on analysis of that body, built-in functions > having semantics based on what the compiler knows about those functions. If FENV_ACCESS is OFF most of those things can be ignored as well. But FENV_ACCESS is much too blunt a hammer for most of our uses. > And then a subset of asms may similarly access or modify them (based on > inputs / outputs / clobbers, but maybe on some architectures existing > practice doesn't provide a register name that inputs / outputs / clobbers > can use to refer to floating-point state). Like PowerPC. But we *do* model vscr (vector status and control register). It won't be hard to add fpscr. > Then you'd need something like Marc Glisse's -ffenv-access patches (August > 2020) to represent the other side of things, how floating-point operations > also access / modify such bits. Yeah, we need something for normal computational FP insns to clobber (on PowerPC load/store insns never change the fpscr / fenv, but I bet that is different on other archs). Thanks for the pointer, I'll find Marc's work.
[Bug libstdc++/102825] std::move_only_function's implementation breaking existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102825 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9890b12c72c02828c691f22198c3e0afd8678991 commit r12-4500-g9890b12c72c02828c691f22198c3e0afd8678991 Author: Jonathan Wakely Date: Tue Oct 19 09:16:56 2021 +0100 libstdc++: Fix mem-initializer in std::move_only_function [PR102825] libstdc++-v3/ChangeLog: PR libstdc++/102825 * include/bits/mofunc_impl.h (move_only_function): Remove invalid base initializer. * testsuite/20_util/move_only_function/cons.cc: Instantiate constructors to check bodies.
[Bug libstdc++/102825] std::move_only_function's implementation breaking existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102825 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed now, thanks for the report.
[Bug tree-optimization/102833] New: [12 regression] gcc.dg/vect/bb-slp-17.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102833 Bug ID: 102833 Summary: [12 regression] gcc.dg/vect/bb-slp-17.c FAILs Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i?86-*-*, x86_64-*-*, mips*-mti-elf Between 20210925 (9a4293ed9bdd029dd44d19b412b1cdf12372801e) and 20210927 (dd11aab6463880c35d942c4a4fd346fdaeeb8e72), gcc.dg/vect/bb-slp-17.c regressed on 32-bit x86 and mips: FAIL: gcc.dg/vect/bb-slp-17.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-17.c scan-tree-dump-times slp2 "optimized: basic block" 1
[Bug tree-optimization/102833] [12 regression] gcc.dg/vect/bb-slp-17.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102833 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/102834] New: gcc.target/i386/avx512f-pr96891-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102834 Bug ID: 102834 Summary: gcc.target/i386/avx512f-pr96891-3.c FAILs Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: crazylht at gmail dot com Target Milestone: --- Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11 The gcc.target/i386/avx512f-pr96891-3.c test has been FAILing on 32-bit Solaris/x86 since it was installed: FAIL: gcc.target/i386/avx512f-pr96891-3.c scan-assembler-times (?n)vpcmp[bwdq][ t]*\$7 4 The pattern only occurs 3 times instead of the expected 4. Attaching the assembler output for reference.
[Bug target/102834] gcc.target/i386/avx512f-pr96891-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102834 --- Comment #1 from Rainer Orth --- Created attachment 51632 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51632&action=edit 32-bit avx512f-pr96891-3.s
[Bug target/102834] gcc.target/i386/avx512f-pr96891-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102834 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/102835] New: gcc.target/i386/avx512fp16-trunchf.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102835
Bug ID: 102835
Summary: gcc.target/i386/avx512fp16-trunchf.c FAILs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: wwwhhhyyy333 at gmail dot com
Target Milestone: ---
Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11
The gcc.target/i386/avx512fp16-trunchf.c test has been FAILing on 32-bit
Solaris/x86
since it was installed:
FAIL: gcc.target/i386/avx512fp16-trunchf.c scan-assembler-times vcvttsh2si[
t]+[^{\\n]*(?:%xmm[0-9]|(%esp))+, %eax(?:\\n|[ t]+#) 3
FAIL: gcc.target/i386/avx512fp16-trunchf.c scan-assembler-times vcvttsh2usi[
t]+[^{\\n]*(?:%xmm[0-9]|(%esp))+, %eax(?:\\n|[ t]+#) 2
On Solaris, the assembler output contains
vcvttsh2si 8(%ebp), %eax
vcvttsh2si 8(%ebp), %eax
vcvttsh2si 8(%ebp), %eax
vcvttsh2usi 8(%ebp), %eax
vcvttsh2usi 8(%ebp), %eax
while Linux has
vcvttsh2si 4(%esp), %eax
vcvttsh2si 4(%esp), %eax
vcvttsh2si 4(%esp), %eax
vcvttsh2usi 4(%esp), %eax
vcvttsh2usi 4(%esp), %eax
As it turns out, the difference occurs because Solaris/x86 default to
-fno-omit-frame-pointer. With -fomit-frame-pointer added, the output matches.
I wonder what's the best way to handle the difference? Just add
-fomit-frame-pointer
to the testcase or allow for the %ebp vs. %esp difference?
[Bug target/102835] gcc.target/i386/avx512fp16-trunchf.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102835 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/102836] New: gcc.target/i386/pieces-memset-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102836 Bug ID: 102836 Summary: gcc.target/i386/pieces-memset-1.c etc. FAIL Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hjl.tools at gmail dot com Target Milestone: --- Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11 Some gcc.target/i386/pieces-memset-*.c tests have been FAILing on 32-bit Solaris/x86 since they were installed: FAIL: gcc.target/i386/pieces-memset-1.c scan-assembler-not %[re]bp FAIL: gcc.target/i386/pieces-memset-4.c scan-assembler-not %[re]bp FAIL: gcc.target/i386/pieces-memset-41.c scan-assembler-not %[re]bp FAIL: gcc.target/i386/pieces-memset-7.c scan-assembler-not %[re]bp FAIL: gcc.target/i386/pieces-memset-8.c scan-assembler-not %[re]bp It turns out that this happens because 32-bit Solaris/x86 only guarantees 4-byte stack alignment following the i386 psABI, so defaults to -mstackrealign. Adding -mno-stackrealign to one test lets the output match what I get on Linux/x86. I suspect that's the best option?
[Bug target/102836] gcc.target/i386/pieces-memset-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102836 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/102836] gcc.target/i386/pieces-memset-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102836 --- Comment #1 from H.J. Lu --- (In reply to Rainer Orth from comment #0) > It turns out that this happens because 32-bit Solaris/x86 only guarantees > 4-byte stack alignment following the i386 psABI, so defaults to > -mstackrealign. > > Adding -mno-stackrealign to one test lets the output match what I get on > Linux/x86. I suspect that's the best option? Yes, I agree.
[Bug d/102837] New: [12 regression] Many 32-bit gdc tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837 Bug ID: 102837 Summary: [12 regression] Many 32-bit gdc tests FAIL Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11 Between 20210930 (ef37ddf477ac4b21ec4d1be9260cfd3b431fd4a9) and 20211001 (701075864ac4d1c6cec936d10f9cfc2aeb8c1699), a large number of testsuite regressions occured on 32-bit Solaris/x86: FAIL: gdc.test/runnable/closure.d -shared-libphobos execution test FAIL: gdc.test/runnable/eh.d -O2 -fPIC -shared-libphobos execution test FAIL: gdc.test/runnable/eh.d -O2 -shared-libphobos execution test FAIL: gdc.test/runnable/eh.d -fPIC -shared-libphobos execution test FAIL: gdc.test/runnable/eh.d -shared-libphobos execution test FAIL: gdc.test/runnable/eh2.d -fPIC -shared-libphobos execution test FAIL: gdc.test/runnable/eh2.d -shared-libphobos execution test FAIL: gdc.test/runnable/foreach5.d -shared-libphobos execution test FAIL: gdc.test/runnable/opover2.d -O2 -finline-functions -shared-libphobos execution test FAIL: gdc.test/runnable/opover2.d -O2 -shared-libphobos execution test FAIL: gdc.test/runnable/opover2.d -finline-functions -shared-libphobos execution test FAIL: gdc.test/runnable/opover2.d -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -O2 -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease -funittest -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease -funittest -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease -g -shared-libphobos execution test FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease -sha
[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:6b34f5c5ec75823d656b6882f12d46248402a2aa commit r12-4503-g6b34f5c5ec75823d656b6882f12d46248402a2aa Author: Martin Liska Date: Tue Oct 19 11:11:16 2021 +0200 target: Support whitespaces in target attr/pragma. PR target/102375 gcc/ChangeLog: * config/aarch64/aarch64.c (aarch64_process_one_target_attr): Strip whitespaces. gcc/testsuite/ChangeLog: * gcc.target/aarch64/pr102375.c: New test.
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Implemented.
[Bug tree-optimization/102832] [12 Regression] ICE in vect_create_partial_epilog with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102832 Alex Coplan changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from Alex Coplan --- Started with r12-2739-g5a1017dc, FWIW: commit 5a1017dc305c49c59129d45536630d02dbc01c45 Author: Richard Sandiford Date: Wed Aug 4 16:52:09 2021 vect: Tweak comparisons with existing epilogue loops
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #10 from Martin Liška --- (In reply to Илья Шипицин from comment #9) > ok, so we'll migrate to gcc-12 :) Yes, but please wait for the release of 12.1 that will happen at the end of April 2022. In the meantime, you can port to GCC 11.2 and cherry-pick the patch.
[Bug libgomp/102838] New: [12 regression] Several tests SEGV in gomp_loop_ull_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838 Bug ID: 102838 Summary: [12 regression] Several tests SEGV in gomp_loop_ull_init Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11 Between 20211007 (5c1838c01652a403498e27024cb0e5ea66376353) and 20211008 (db3d7270b42fe27fb05664c4fdf524ab7ad13a75), quite a number of libgomp testcases began to FAIl on 32-bit Solaris/x86 only: FAIL: libgomp.c++/../libgomp.c-c++-common/for-1.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-11.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-12.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-14.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-15.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-2.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-6.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-7.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/for-8.c execution test FAIL: libgomp.c++/../libgomp.c-c++-common/task-reduction-11.c execution test FAIL: libgomp.c++/loop-11.C execution test FAIL: libgomp.c++/loop-8.C execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-1.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-16.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-2.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-3.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-7.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-8.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/for-9.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-1.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-5.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/monotonic-2.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/nonmonotonic-2.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/task-reduction-11.c execution test FAIL: libgomp.c/loop-12.c execution test FAIL: libgomp.c/loop-6.c execution test FAIL: libgomp.fortran/pointer2.f90 -O2 execution test I manually built the C version of for-1.c. Running it works, but when I add OMP_NUM_THREADS=8 as happens during a regular make check, the test SEGVs: Thread 9 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfe5d7fc8 in gomp_loop_ull_init (chunk_size=32, sched=GFS_GUIDED, incr=2, end=2147486647, start=2147483647, up=true, ws=0x80774b8) at /vol/gcc/src/hg/master/local/libgomp/loop_ull.c:48 48ws->end_ull = ((up && start > end) || (!up && start < end)) => 0xfe5d7fc8 : movaps %xmm0,0x10(%esi) (gdb) p/x $esi $1 = 0x80774b8 (gdb) where #0 0xfe5d7fc8 in gomp_loop_ull_init (chunk_size=32, sched=GFS_GUIDED, incr=2, end=2147486647, start=2147483647, up=true, ws=0x80774b8) at /vol/gcc/src/hg/master/local/libgomp/loop_ull.c:48 #1 gomp_loop_ull_guided_start (up=true, start=2147483647, end=2147486647, incr=2, chunk_size=32, istart=0xfeffd910, iend=0xfeffd918) at /vol/gcc/src/hg/master/local/libgomp/loop_ull.c:157 #2 0x080600bd in f1_f_guided32 () #3 0x08061105 in test_f_guided32 () #4 0xfeffda80 in ?? () #5 0x08062c63 in main () Obviously %esi isn't properly aligned, which lets me suspect this is an i386 bug and not libgomp proper.
[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libstdc++/102839] New: filesystem::path::wstring runs in C locale / practically always throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102839
Bug ID: 102839
Summary: filesystem::path::wstring runs in C locale /
practically always throws
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
► cat x.cpp
#include
#include
#include
namespace fs = std::filesystem;
int main()
{
const char localeName[] = "ja_JP.UTF-8";
std::setlocale(LC_ALL, localeName);
std::locale::global(std::locale(localeName));
fs::path p(u8"壊した");
std::wcout << p.wstring() << L'\n';
}
g++ -v x.cpp
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/11/defaults.spec
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux)
► ./a.out
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: Cannot convert character sequence: Invalid or
incomplete multibyte or wide character
Aborted (core dumped)
Single-stepping through a -ggdb3 build reveals these code fragments in
libstdc++ which suggest that codecvt<> always operates in C locale:
(x.cpp)
step into
<< p.wstring() <<
leads to
#0 0x77e58f09 in std::codecvt::codecvt
(this=0x7fffdb30, __refs=0) at
../../../../../libstdc++-v3/src/c++98/codecvt.cc:118
116 #ifdef _GLIBCXX_USE_WCHAR_T
117 // codecvt required specialization
118 codecvt::
119 codecvt(size_t __refs)
120 : __codecvt_abstract_base(__refs),
*121 _M_c_locale_codecvt(_S_get_c_locale())
122 { }
std::codecvt::do_max_length (this=0x7fffdb50)
at codecvt_members.cc:220
217 int
218 codecvt::
219 do_max_length() const throw()
220 {
221 #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
*222 __c_locale __old = __uselocale(_M_c_locale_codecvt);
223 #endif
224 // XXX Probably wrong for stateful encodings.
225 int __ret = MB_CUR_MAX;
226 #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
227 __uselocale(__old);
228 #endif
229 return __ret;
230 }
[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838 --- Comment #1 from Jakub Jelinek --- Possibly triggered by enabling vectorization at -O2? long long should for ia32 inside of structures (at least on linux but I think it is the same for solaris too) have just 32-bit alignment and nothing else in struct gomp_work_share should result in 64-bit alignment of the structure, so if the vectorizer (slp?) decides to use aligned 128-bit store, something is wrong...
[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102839 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-19 CC||marxin at gcc dot gnu.org, ||redi at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Are you sure it's a valid testcase? Apparently, clang also throws an exception.
[Bug target/102835] gcc.target/i386/avx512fp16-trunchf.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102835 --- Comment #1 from Hongyu Wang --- (In reply to Rainer Orth from comment #0) > > I wonder what's the best way to handle the difference? Just add > -fomit-frame-pointer > to the testcase or allow for the %ebp vs. %esp difference? For this test we just want to check mnemonics are properly generated, so I think we can allow either esp/ebp output for different system.
[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102839 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Jonathan Wakely --- Martin, did you use -stdlib=libc++ with Clang? Otherwise you're just testing libstdc++ again with a different compiler. Libc++ does not throw on this testcase for me. (The test is invalid though, it needs to include to use std::setlocale, but that's not the problem)
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482 --- Comment #9 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:6920d5a1a2834e9c62d441b8f4c6186b01107d13 commit r12-4505-g6920d5a1a2834e9c62d441b8f4c6186b01107d13 Author: Tobias Burnus Date: Tue Oct 19 15:16:01 2021 +0200 Fortran: Fix "str" to scalar descriptor conversion [PR92482] PR fortran/92482 gcc/fortran/ChangeLog: * trans-expr.c (gfc_conv_procedure_call): Use TREE_OPERAND not build_fold_indirect_ref_loc to undo an ADDR_EXPR. gcc/testsuite/ChangeLog: * gfortran.dg/bind-c-char-descr.f90: Remove xfail; extend a bit.
[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102839 --- Comment #3 from Jonathan Wakely --- This is the same issue as PR 95048 comment 3 describes.
[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102839 --- Comment #4 from Martin Liška --- (In reply to Jonathan Wakely from comment #2) > Martin, did you use -stdlib=libc++ with Clang? Otherwise you're just testing > libstdc++ again with a different compiler. I didn't, my bad. Will do it next time. Thanks.
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Tobias Burnus --- Close as FIXED (in GCC 12) now that also the remaining issue is solved :-) Thanks again for the report!
[Bug libstdc++/95048] [9/10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #12 from Jonathan Wakely --- (In reply to Christian Fersch from comment #9) > But is it possible to query the value of -fwide-exec-charset? I had quick > look and couldn't find anything. It's possible now: __GNUC_WIDE_EXECUTION_CHARSET_NAME https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||burnus at gcc dot gnu.org --- Comment #9 from Tobias Burnus --- Close as FIXED (in GCC 12) by the big patch. I tried the full testcases of the submitted patch (PR93308.f90 PR93963.f90 PR94327.c PR94327.f90 PR94331.c PR94331.f90 PR97046.f90) and also Thanks José for report and testcases - and again sorry for no prompt review of your patches. (It helps to ping them regularly.)
[Bug rtl-optimization/102840] New: [12 Regression] gcc.target/i386/pr22076.c by r12-4475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102840
Bug ID: 102840
Summary: [12 Regression] gcc.target/i386/pr22076.c by r12-4475
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: roger at nextmovesoftware dot com
Target Milestone: ---
On Linux/x86-64, r12-4475 caused:
$ make check-gcc RUNTESTFLAGS="--target_board='unix{-m32}' i386.exp=pr22076.c"
...
FAIL: gcc.target/i386/pr22076.c scan-assembler-not movl
FAIL: gcc.target/i386/pr22076.c scan-assembler-times movq 2
[Bug target/93183] SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 93183, which changed state. Bug 93183 Summary: SVE does not use neg as conditional https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 93183, which changed state. Bug 93183 Summary: SVE does not use neg as conditional https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838 --- Comment #2 from Jakub Jelinek --- Actually no, I'm wrong, there is gomp_mutex_t lock __attribute__((aligned (64))); in the middle of the structure, so the start of the structure is 64-byte aligned.
[Bug tree-optimization/102829] Redundant null check after atomic load from that address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102829 --- Comment #2 from Laurynas Biveinis --- FWIW adding "if (this == nullptr) __builtin_unreachable();" between __atomic_load_n and return fails to workaround this issue
[Bug libgomp/102841] New: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102841 Bug ID: 102841 Summary: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_dat a-7.c FAILs Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org Target Milestone: --- Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11, i?86-apple-darwin*, x86_64-apple-darwin* The libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c has been FAILing on Solaris and Darwin since it was installed. FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/host_data-7.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) On Solaris, the excess errors are Excess errors: /vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9: note: variable 'iftmp.3' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:26:9: note: variable 'iftmp.6' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9: note: variable 'iftmp.9' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:44:9: note: variable 'iftmp.12' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:55:9: note: variable 'iftmp.15' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable while Darwin shows Excess errors: /vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9: note: variable 'D.3648' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9: note: variable 'D.3649' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9: note: variable 'D.3650' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9: note: variable 'D.3662' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9: note: variable 'D.3663' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable /vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9: note: variable 'D.3664' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable [...]
[Bug libgomp/102841] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102841 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102840 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Target||x86_64-*-* i?86-*-*
[Bug testsuite/102833] [12 regression] gcc.dg/vect/bb-slp-17.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102833 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-10-19 CC||rguenth at gcc dot gnu.org Component|tree-optimization |testsuite Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. I think i386 misses V2SImode vectorization (there's a duplicate bug somewhere I think). We need to somehow capture this in a dg-effective-target
