[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
Richard Biener changed:
What|Removed |Added
Target|x86_64 i?86 |x86_64-*-* i?86-*-*
Keywords||missed-optimization
Last reconfirmed||2020-12-07
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener ---
Btw, vector lowering performs this optimization. But then in GIMPLE we have
__m128 f (__m128 a, __m128 b)
{
vector(4) float _3;
vector(4) float _5;
vector(4) float _6;
[local count: 1073741824]:
_3 = __builtin_ia32_shufps (b_2(D), b_2(D), 0);
_5 = __builtin_ia32_shufps (a_4(D), a_4(D), 0);
_6 = _3 * _5;
return _6;
so we don't actually see the operation. To rectify this the backend would
need to GIMPLE-fold those calls once the MAKS argument becomes constant.
Fold it to VEC_PERM_EXPR of VIEW_CONVERTed operands, that is.
Vector lowering doesn't perform generic permute optimizations, the vectorizer
does but it doesn't touch existing code. I guess it could be done in some
new pass similar to backprop (but dataflow is the other way around).
[Bug tree-optimization/98169] New: isnan pattern not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
Bug ID: 98169
Summary: isnan pattern not folded
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The two following functions should produce the same assembly, at least on x86,
but for f1 gcc does not recognize the pattern for f1 and produce not optimal
code.
The problem is the same for all floating types.
bool f1(float a) {
return a == a;
}
bool f2(float a) {
return !__builtin_isnan(a);
}
Furthermore, for __float128, instead of calling __unordtf2 the following code
call __netf2
bool f3(__float128 a) {
return a != a;
}
[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224 --- Comment #12 from Tamar Christina --- @Martin I believe this was re-opened as the patch was reverted on master but was still pending reverts on the release branches. @Mark I assume you committed the reverts to the branches too?
[Bug bootstrap/97314] bootstrap failure on i686-linux-gnu with --enable-checking=yes,extra,rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97314 --- Comment #4 from Matthias Klose --- 8441545d4f2afb9e9342e0dac378eafd03f00462 now builds insn-extract.o without rtl checking unconditionally.
[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:a6a0db7d1bc7ad640bab51769e53f1cb4ad4bb88 commit r11-5811-ga6a0db7d1bc7ad640bab51769e53f1cb4ad4bb88 Author: Martin Jambor Date: Mon Dec 7 09:35:09 2020 +0100 ipa-cp: Avoid unwanted multiple propagations (PR 97816) When looking at the testcase of PR 97816 I realized that the reason why we were hitting overflows in size growth estimates in IPA-CP is not because the chains of how lattices feed values to each other are so long but mainly because we add estimates in callee lattices to caller lattices for each value source, which roughly corresponds to a call graph edge, and therefore if there are multiple calls between two functions passing the same value in a parameter we end up doing it more than once, sometimes actually quite many times. This patch avoids it by using a has_set to remember the source values we have already updated and not increasing their size again. Furhtermore, to improve estimation of times we scale the propagated time benefits with edge frequencies as we accumulate them. This should make any overflows very unlikely but not impossible, so I still included checks for overflows but decided to restructure the code to only need it in the propagate_effects function and modified it so that it does not need to perform the check before each sum. This is because I decided to add local estimates to propagated estimates already in propagate_effects and not at the evaluation time. The function can then do the sums in a wide type and discard them in the unlikely case of an overflow. I also decided to use the opportunity to make propagated effect stats now include stats from other values in the same SCCs. In the dumps I have seen this tended to increase size cost a tiny bit more than the estimated time benefit but both increases were small. Martin gcc/ChangeLog: 2020-11-20 Martin Jambor PR ipa/97816 * ipa-cp.c (safe_add): Removed. (good_cloning_opportunity_p): Remove special handling of INT_MAX. (value_topo_info::propagate_effects): Take care not to propagate from size one value to another through more sources. Scale propagated times with edge frequencies. Include local time and size in propagates ones here. Take care not to overflow size. (decide_about_value): Do not add local and propagated effects when passing them to good_cloning_opportunity_p.
[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #3 from Matthias Klose --- 8441545d4f2afb9e9342e0dac378eafd03f00462 now builds insn-extract.o without rtl checking unconditionally.
[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117
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 ---
Simplified testcase, fails with -O3 -fno-tree-scev-cprop
unsigned char c;
void __attribute__((noipa))
e()
{
do
{
}
while (++c);
}
int main()
{
e();
if (c != 0)
__builtin_abort ();
return 0;
}
It's the first new set_range_info that causes the miscompile.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #41 from CVS Commits --- The master branch has been updated by Matthias Klose : https://gcc.gnu.org/g:ad9c120a019ba4222bb062017da2db9711652dc3 commit r11-5812-gad9c120a019ba4222bb062017da2db9711652dc3 Author: Matthias Klose Date: Mon Dec 7 09:40:53 2020 +0100 Fix PR ada/97504 for mips*-linux 2020-12-07 Matthias Klose PR ada/97504 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use wraplf version of Aux_Long_Long_Float.
[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117 --- Comment #3 from Richard Biener --- [local count: 118111600]: c_lsm.6_7 = c; niters.8_1 = -c_lsm.6_7; if (c_lsm.6_7 > 240) goto ; [10.00%] else goto ; [90.00%] [local count: 106300440]: _18 = niters.8_1 + 240; _19 = _18 >> 4; # RANGE [1, 15] NONZERO 15 bnd.9_17 = _19 + 1; but here c == 0 and thus _19 + 1 is 16. The number of latch invocations is 255 but the number of iterations is that + 1 and thus zero in the IVs type. This is why we have num_itersm1 and so I guess /* Peeling algorithm guarantees that vector loop bound is at least ONE, we set range information to make niters analyzer's life easier. */ if (stmts != NULL && log_vf) set_range_info (niters_vector, VR_RANGE, wi::to_wide (build_int_cst (type, 1)), wi::to_wide (fold_build2 (RSHIFT_EXPR, type, TYPE_MAX_VALUE (type), log_vf))); needs to use TYPE_MAX_VALUE + 1 >> log_vf here to be on the safe side for the "non-representable" niter value.
[Bug fortran/97612] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 --- Comment #2 from martin --- I do not see why it should not be valid. t() is a structure constructor acting much like a function with (in this case) one optional argument. And as an allocatable component has default initialisation, no value needs to be provided, to be valid constructor. Just to be sure I checked Metcalf (2011). Section 15.3 "Structure constructors" and 20.1.4 "Structure constructors" contain an interesting piece of information I did not know about: F03 forgot to allow that for allocatable components a value can be omitted. This was permitted in F08. So it looks like the provided code example is not valid F03 but valid F08. In fact, null() can be provided as default value. Then the code compiles: type(t) :: a = t(null())
[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #4 from Richard Biener --- In fact there is alrady /* Create: niters >> log2(vf) */ /* If it's known that niters == number of latch executions + 1 doesn't overflow, we can generate niters >> log2(vf); otherwise we generate (niters - vf) >> log2(vf) + 1 by using the fact that we know ratio will be at least one. */ so we know about this "defect". The computation method translates easily to the range case (unconditionally). Unfortunately for some 'degenerate' cases where we arrive with const_vf == 1 we'll compute [1, 0] "ranges" this way which ICEs in niter compute. The question is whether we can construct cases we miscompile with such large niter and VF == 1 (full SLP). As noted when I added niter_m1 all uses of 'niter' would have to go away :/ For now I'm testing the "ugly" diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c index 36179188f6d..36f218e7f6e 100644 --- a/gcc/tree-vect-loop-manip.c +++ b/gcc/tree-vect-loop-manip.c @@ -2034,13 +2034,21 @@ vect_gen_vector_loop_niters (loop_vec_info loop_vinfo, tree niters, niters_vector = force_gimple_operand (niters_vector, &stmts, true, var); gsi_insert_seq_on_edge_immediate (pe, stmts); /* Peeling algorithm guarantees that vector loop bound is at least ONE, -we set range information to make niters analyzer's life easier. */ +we set range information to make niters analyzer's life easier. +Note the number of latch iteration value can be TYPE_MAX_VALUE so +we have to represent the vector niter TYPE_MAX_VALUE + 1 >> log_vf. */ if (stmts != NULL && log_vf) set_range_info (niters_vector, VR_RANGE, - wi::to_wide (build_int_cst (type, 1)), - wi::to_wide (fold_build2 (RSHIFT_EXPR, type, - TYPE_MAX_VALUE (type), - log_vf))); + wi::one (TYPE_PRECISION (type)), + /* ??? Avoid creating [1, 0]. */ + const_vf == 1 + ? wi::max_value (TYPE_PRECISION (type), +TYPE_SIGN (type)) + : (wi::rshift (wi::max_value (TYPE_PRECISION (type), + TYPE_SIGN (type)) + - (const_vf - 1), + exact_log2 (const_vf), TYPE_SIGN (type)) + + 1)); } *niters_vector_ptr = niters_vector; *step_vector_ptr = step_vector;
[Bug target/98119] [10/11 Regression] SVE: Wrong code with -O1 -ftree-vectorize -msve-vector-bits=512 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119 Alex Coplan changed: What|Removed |Added Summary|SVE: Wrong code with -O1|[10/11 Regression] SVE: |-ftree-vectorize|Wrong code with -O1 |-msve-vector-bits=512 |-ftree-vectorize |-mtune=thunderx |-msve-vector-bits=512 ||-mtune=thunderx --- Comment #2 from Alex Coplan --- Started with r10-4749-gcc68f7c2dabbf9d90ebe025a11f6d6ed5d49a113, FWIW.
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #8 from ktkachov at gcc dot gnu.org --- (In reply to Haoxin Tu from comment #7) > (In reply to Paul Sokolovsky from comment #0) > > Hi, Paul. May I ask how to reduce compile-time-hog/memory-hog test cases > using CReduce? > I know CReduce can be easily used to reduce crash/wrong-code test cases, but > I don't know how to minimize compile-time/memory ones. I will be very > appreciated if you can give me any tips. Thanks. > > > Best, > Haoxin When I had to do it in the past I've used the 'ulimit' command in linux. That allows you to kill a process if it exceeds a time limit (ulimit -t) or a memory limit (ulimit -m). You can use it in the validation script to check for the pathological behaviour
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #9 from Haoxin Tu --- (In reply to ktkachov from comment #8) > When I had to do it in the past I've used the 'ulimit' command in linux. > That allows you to kill a process if it exceeds a time limit (ulimit -t) or > a memory limit (ulimit -m). You can use it in the validation script to check > for the pathological behaviour Hi. Got you. Thank you so much! Best, Haoxin
[Bug tree-optimization/98155] [11 Regression] ICE during GIMPLE pass: slp, in vect_init_pattern_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98155 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Martin Liška --- (In reply to Richard Biener from comment #5) > Isn't this PR95582? Oh, yes, that must be a duplicate. I have a WIP patch attached to PR95582 in our gcc11 package. *** This bug has been marked as a duplicate of bug 95582 ***
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 Martin Liška changed: What|Removed |Added CC||doko at debian dot org --- Comment #18 from Martin Liška --- *** Bug 98155 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #9 from David Binderman --- No progress for another couple of months. Can I assume that fixing this bug isn't a priority for the next release of gcc ?
[Bug c++/98163] ICE symtab_node::verify failed, auto& NTTP specialized with same entity but different type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98163
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-12-07
Status|UNCONFIRMED |NEW
--- Comment #2 from Martin Liška ---
This one started with r7-4431-g4a826ca6feb3c7ec, it was rejected before that:
pr98163.C:1:17: error: ‘auto’ parameter not permitted in this context
template
^~~
pr98163.C:10:15: note: invalid template non-type parameter
void bar(S s) {
^
pr98163.C:17:15: note: invalid template non-type parameter
void baz(S s) {
^
[Bug c++/98163] ICE symtab_node::verify failed, auto& NTTP specialized with same entity but different type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98163 --- Comment #3 from Martin Liška --- and without the checking one gets an assembler error: $ g++ pr98163.C -c -std=c++17 -pedantic-errors /tmp/cclBTXg2.s: Assembler messages: /tmp/cclBTXg2.s:70: Error: symbol `_Z3fooI1SIL_Z3arrEEEvT_' is already defined so the checking really makes sense.
[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142 --- Comment #9 from Jonathan Wakely --- Right, which is as per [dcl.enum] p8. A type which only allows values corresponding to named enumerators is not possible in standard C++.
[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #10 from Paul Sokolovsky --- Created attachment 49693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49693&action=edit Script for CReduce
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #11 from Paul Sokolovsky --- In my case, I used the "timeout" command from GNU coreutils. I've attached the actual script used for reference (uncleaned dirty stuff, sorry). One thing to keep in mind (and which took me a couple of extra creduce runs) is that when it times out, it's the "interesting case" in CReduce terms. And when compilation succeeds *or* fails (e.g. because CReduce produced broken syntax), it's "not interesting case". So, you literally need to test for the timeout exit code vs anything else (be it 0 or 1), like the script shows.
[Bug tree-optimization/96963] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963 --- Comment #5 from Jonathan Wakely --- (In reply to Gavin from comment #0) > 2) Built from git, configured with: ./configure --prefix=/tmp/gcc-master Nothing to do with the bug, but don't build in the source tree: https://gcc.gnu.org/wiki/FAQ#configure
[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #10 from Martin Liška --- @Marek: The callgraph checking error is correct. If you disable it, you will likely see duplicate assembler names in GAS. And that's the error that 2 symbol names clash.
[Bug tree-optimization/96963] [10/11 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963 Jonathan Wakely changed: What|Removed |Added Known to fail||10.2.0, 11.0 Known to work||9.3.0 Target Milestone|--- |10.3 Summary|-Wstringop-overflow false |[10/11 Regression] |positive on -O3 or -O2 |-Wstringop-overflow false |-ftree-vectorize when |positive on -O3 or -O2 |assigning consecutive char |-ftree-vectorize when |struct members |assigning consecutive char ||struct members --- Comment #6 from Jonathan Wakely --- This produces tons of false positives for correct code that uses std::string and std::vector, due to the empty std::allocator objects used as default arguments of constructors.
Re: [Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed
> @Marek: The callgraph checking error is correct. > If you disable it, you will likely see duplicate assembler names in GAS. And > that's the error that 2 symbol names clash. Indeed, there are two lambdas, but I think C++ FE should assign them different symbol names. Honza
[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241 --- Comment #11 from Jan Hubicka --- > @Marek: The callgraph checking error is correct. > If you disable it, you will likely see duplicate assembler names in GAS. And > that's the error that 2 symbol names clash. Indeed, there are two lambdas, but I think C++ FE should assign them different symbol names. Honza
[Bug go/98170] New: Cannot build libgo on AIX: *.gox does not contain any Go export data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98170 Bug ID: 98170 Summary: Cannot build libgo on AIX: *.gox does not contain any Go export data Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: clement.chigot at atos dot net, cmang at google dot com Target Milestone: --- Host: powerpc-ibm-aix7.2.4.0 Target: powerpc-ibm-aix7.2.4.0 Build: powerpc-ibm-aix7.2.4.0 I've recently tried to build master on AIX 7.2 with --enable-languages=all. Among others, this failed building libgo, all following the same pattern: /home/ro/gcc/src/gcc-master/libgo/go/runtime/internal/math/math.go:7:28: error: ./runtime/internal/sys.gox exists but does not contain any Go export data 7 | import "runtime/internal/sys" |^ All those *.gox files were just 48 bytes long, even with binutils 2.35.1 objcopy. It turns out this is a known issue, explained in https://www.gitmemory.com/issue/golang/go/38043/603687042. There are several issues here: * The version of copycsect referenced there (based on binutils 2.25.1) doesn't compile with current binutils 2.35.1 any longer (bfd_get_section_size has lost its bfd * arg since). * Once this is fixed, the build mostly works (with the exception of the recently reported stab issue https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560857.html) * Unless this functionality can be integrated into binutils, requiring a full binutils just for this seems pretty heavy-handed. I suspect that can way easier be done using libiberty's simple-object interfaces. * Whatever the case, until libgo builds out of the box on AIX, the issue should at the very least be documented (install.texi?) and/or the libgo build disabled so others don't waste time investigating known issues.
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #12 from Haoxin Tu --- (In reply to Paul Sokolovsky from comment #11) Awesome! I got your main idea here. Thank you very much, Paul! Best, Haoxin
[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #12 from Martin Liška --- Btw. it started with r5-960-gd67ff7b75deab58eaac2edccafbc55d32f60ed0d.
[Bug ada/98171] New: adaint.c doesn't compile on AIX 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98171
Bug ID: 98171
Summary: adaint.c doesn't compile on AIX 7.2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: charlet at gcc dot gnu.org, dje at gcc dot gnu.org
Target Milestone: ---
Host: powerpc-ibm-aix7.2.0.0
Target: powerpc-ibm-aix7.2.0.0
Build: powerpc-ibm-aix7.2.0.0
I recently tried building master on AIX 7.2 in the cfarm (gcc119) with
--enable-languages=all and a self-compiled gcc 8.4.0 as bootstrap compiler.
This
already failed in stage 1 compiling adaint.c:
/home/ro/gcc/src/gcc-master/gcc/ada/adaint.c: In function 'int
__gnat_copy_attri
bs(char*, char*, int)':
/home/ro/gcc/src/gcc-master/gcc/ada/adaint.c:3289:21: error: no match for
'opera
tor=' (operand types are 'timespec' and 'st_timespec_t' {aka 'st_timespec'})
tbuf[0] = fbuf.st_atim;
^~~
In file included from /usr/include/sys/resource.h:57,
from
/home/ro/gcc/8/lib/gcc/powerpc-ibm-aix7.2.0.0/8.4.0/includ
e-fixed/sys/wait.h:56,
from
/home/ro/gcc/8/lib/gcc/powerpc-ibm-aix7.2.0.0/8.4.0/includ
e-fixed/stdlib.h:386,
from /home/ro/gcc/8/include/c++/8.4.0/cstdlib:75,
from /home/ro/gcc/8/include/c++/8.4.0/stdlib.h:36,
from /home/ro/gcc/src/gcc-master/gcc/system.h:259,
from /home/ro/gcc/src/gcc-master/gcc/ada/adaint.c:144:
/usr/include/sys/time.h:197:8: note: candidate: 'timespec&
timespec::operator=(c
onst timespec&)'
struct timespec {
^~~~
/usr/include/sys/time.h:197:8: note: no known conversion for argument 1 from
'
st_timespec_t' {aka 'st_timespec'} to 'const timespec&'
/usr/include/sys/time.h:197:8: note: candidate: 'timespec&
timespec::operator=(t
imespec&&)'
/usr/include/sys/time.h:197:8: note: no known conversion for argument 1 from
'
st_timespec_t' {aka 'st_timespec'} to 'timespec&&'
and similarly for tbuf[1]/fbuf.st_mtim.
I managed to avoid this by assigning the members (tv_sec, tv_nsec)
individually. In addition, I enabled the largefile functions in adaint.h given
that gcc/auto-host.h defines _LARGE_FILES 1.
However, I believe that this maze of platform-specific #ifdefs just cries for
proper autoconf tests, as has already been remarked on gcc-patches recently
IIRC.
(I can't attach the actual patch since gcc119 has been unaccessible for more
than
a day now).
While those changes allowed the compilation to finish, gnat1 still doesn't link
due to PR ada/95549.
[Bug tree-optimization/98169] isnan pattern not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-12-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. [local count: 1073741824]: _2 = a_1(D) == a_1(D); return _2; vs. [local count: 1073741824]: _2 = a_1(D) ord a_1(D); return _2;
[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:cdcbef3c3310a14f2994982b44cb1f8e14c77232 commit r11-5820-gcdcbef3c3310a14f2994982b44cb1f8e14c77232 Author: Richard Biener Date: Mon Dec 7 10:29:07 2020 +0100 tree-optimization/98117 - fix range set by vectorization on niter IVs This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration count value causing wrong range info for the vector IV. There's still the case of VF == 1 where if we don't know whether we hit the above case we cannot emit a range. 2020-12-07 Richard Biener PR tree-optimization/98117 * tree-vect-loop-manip.c (vect_gen_vector_loop_niters): Properly handle degenerate niter when setting the vector loop IV range. * gcc.dg/torture/pr98117.c: New testcase.
[Bug tree-optimization/98117] [8/9/10 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117 Richard Biener changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] wrong |wrong code with "-O3|code with "-O3 |-fno-tree-scev-cprop" since |-fno-tree-scev-cprop" since |r8-1163-g7078979b291419f3 |r8-1163-g7078979b291419f3 Known to work||11.0 Known to fail||10.2.0 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238
David Friberg changed:
What|Removed |Added
CC||davveston at gmail dot com
--- Comment #1 from David Friberg ---
This bug is still present in GCC 10.1.0 and GCC trunk (for various C++
versions).
Related SO Q&A (https://stackoverflow.com/questions/65124761) list the
following examples as rejects-valid:
struct A { ~A() = delete; };
A *pa{new A{}};
class B { ~B() = default; };
B *pb{new B{}};
struct E {
~E() = delete;
private:
int x;
};
E *pe{new E{}};
whereas the following are all accepted (accepts-valid):
class C { ~C(); };
C *pc{new C{}}; // OK
class D { ~D() {} };
D *pd{new D{}}; // OK
struct F {
F() = default;
~F() = delete;
};
F *pf{new F{}};
struct G {
G() = default;
~G() = delete;
private:
int x;
};
G *pg{new G{}};
The SO Q&A lists standard passages to motivate that this is a rejects-valid, in
case this is challenged.
[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238 --- Comment #2 from Jonathan Wakely --- (In reply to David Friberg from comment #1) > in case this is challenged. It's already been confirmed as a rejects-valid bug.
[Bug target/98139] varasm.c fails to compile on AIX 7.2: -Werror=unused-variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from David Edelsohn --- > It has nothing to do with the proper way to install GCC on AIX. Why not? Consider some developer trying to build trunk on his own AIX system: he'd run into the same issue, but wouldn't think of (in fact wouldn't even know about) the cfarm wiki. > It was not the only -Werror failure on AIX. That is why I said, if that's the > only problem, we're lucky. The -Werror failures change. FWIW, I've now finished an --enable-languages=all (except ada) build on gcc119 without --disable-werror and there were no further issues (well, there are PRs go/98170 and ada/98171). > The patch is okay, but it doesn't remove the need to recommend > --disable-werror. At least for now that need seems to be gone. Thanks for installing the patch.
[Bug tree-optimization/98113] [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ebdfd1606da6b5aa586b0cd156b69b659235c9c2 commit r11-5821-gebdfd1606da6b5aa586b0cd156b69b659235c9c2 Author: Richard Biener Date: Thu Dec 3 10:25:14 2020 +0100 tree-optimization/98113 - vectorize a sequence of BIT_INSERT_EXPRs This adds the capability to handle a sequence of vector BIT_INSERT_EXPRs to be vectorized similar as to how we vectorize vector constructors. 2020-12-03 Richard Biener PR tree-optimization/98113 * tree-vectorizer.h (struct slp_root): New. (_bb_vec_info::roots): New member. * tree-vect-slp.c (vect_analyze_slp): Also walk BB info roots. (_bb_vec_info::_bb_vec_info): Adjust. (_bb_vec_info::~_bb_vec_info): Likewise. (vld_cmp): New. (vect_slp_is_lane_insert): Likewise. (vect_slp_check_for_constructors): Match a series of BIT_INSERT_EXPRs as vector constructor. (vect_slp_analyze_bb_1): Continue if BB info roots is not empty. (vect_slp_analyze_bb_1): Mark the whole BIT_INSERT_EXPR root sequence as pure_slp. * gcc.dg/vect/bb-slp-70.c: New testcase.
[Bug tree-optimization/98113] [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
I guess the difference is that when type_build_ctor_call (type) is true,
we explicitly say we don't want cleanups:
if (type_build_ctor_call (type) && !explicit_value_init_p)
{
init_expr = build_special_member_call (init_expr,
complete_ctor_identifier,
init, elt_type,
LOOKUP_NORMAL,
complain|tf_no_cleanup);
}
then the explicit_value_init_p doesn't either:
else if (explicit_value_init_p)
{
/* Something like `new int()'. NO_CLEANUP is needed so
we don't try and build a (possibly ill-formed)
destructor. */
tree val = build_value_init (type, complain | tf_no_cleanup);
if (val == error_mark_node)
return error_mark_node;
init_expr = build2 (INIT_EXPR, type, init_expr, val);
}
but the
ie = build_x_compound_expr_from_vec (*init, "new
initializer",
complain);
init_expr = cp_build_modify_expr (input_location,
init_expr,
INIT_EXPR, ie,
complain);
case doesn't do that.
Adding | tf_no_cleanup to those 3 cases seems to fix this, testing it with make
check-c++-all now.
[Bug tree-optimization/96963] [10/11 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- The PR93200 "fix" was incorrect, as you should know in GIMPLE most pointer conversions are useless, so the pointer type of the MEM_REF's first operand is completely arbitrary. If you wanted to exclude vector types from the overflow warnings, you should have punted for MEM_REFs with vector type being TREE_TYPE (memref). It is still just a hack, because the whole relying on &something->field vs. something in addresses stands on sand, in GIMPLE those are all just about address values and nothing else, they don't carry semantic information.
[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Jambor --- Now fixed properly.
[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 97816, which changed state. Bug 97816 Summary: [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 49694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49694&action=edit gcc11-pr59238.patch Fix that passed make check-c++-all.
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 --- Comment #3 from Hongtao.liu --- ;; _3 = __builtin_ia32_shufps (b_2(D), b_2(D), 0); (insn 7 6 8 (set (reg:V4SF 88) (reg/v:V4SF 86 [ b ])) "./gcc/include/xmmintrin.h":746:19 -1 (nil)) (insn 8 7 9 (set (reg:V4SF 89) (reg/v:V4SF 86 [ b ])) "./gcc/include/xmmintrin.h":746:19 -1 (nil)) (insn 9 8 10 (set (reg:V4SF 87) (vec_select:V4SF (vec_concat:V8SF (reg:V4SF 88) (reg:V4SF 89)) (parallel [ (const_int 0 [0]) repeated x2 (const_int 4 [0x4]) repeated x2 ]))) "./gcc/include/xmmintrin.h":746:19 -1 (nil)) ;; _5 = __builtin_ia32_shufps (a_4(D), a_4(D), 0); (insn 11 10 12 (set (reg:V4SF 91) (reg/v:V4SF 85 [ a ])) "./gcc/include/xmmintrin.h":746:19 -1 (nil)) (insn 12 11 13 (set (reg:V4SF 92) (reg/v:V4SF 85 [ a ])) "./gcc/include/xmmintrin.h":746:19 -1 (nil)) (insn 13 12 14 (set (reg:V4SF 90) (vec_select:V4SF (vec_concat:V8SF (reg:V4SF 91) (reg:V4SF 92)) (parallel [ (const_int 0 [0]) repeated x2 (const_int 4 [0x4]) repeated x2 ]))) "./gcc/include/xmmintrin.h":746:19 -1 (nil)) Simplify upper to (vec_duplicate:V4SF (vec_select:SF (reg:V4SF 86) (parallel [(const_int 0)]) then add a combine splitter transform (mult:(vec_dup op1) (vec_dup op2)) to (vec_dup (mult:op1 op2)?
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 --- Comment #4 from Richard Biener --- That works only for single-operation and doesn't really scale. I think we want to expose the permutes at the GIMPLE level via ix86_gimple_fold_builtin. We already handle IX86_BUILTIN_SHUFPD there but not IX86_BUILTIN_SHUFPS for some reason.
[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #10 from Jakub Jelinek --- I can't reproduce it anymore.
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #5 from Richard Biener ---
So
__m128d f(__m128d a, __m128d b) {
return _mm_mul_pd(_mm_shuffle_pd(a, a, 0), _mm_shuffle_pd(b, b, 0));
}
is expanded as
_3 = VEC_PERM_EXPR ;
_5 = VEC_PERM_EXPR ;
_6 = _3 * _5;
return _6;
but vector lowering ssa_uniform_vector_p doesn't yet handle VEC_PERM_EXPRs
with all-zero permute. Hacking that in (not fixing the fallout) produces
[local count: 1073741824]:
_7 = BIT_FIELD_REF ;
_8 = BIT_FIELD_REF ;
_9 = _7 * _8;
_6 = {_9, _9};
and
f:
.LFB534:
.cfi_startproc
mulsd %xmm1, %xmm0
unpcklpd%xmm0, %xmm0
ret
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 --- Comment #6 from Richard Biener --- Created attachment 49695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49695&action=edit vector lowering ssa_uniform_vector_p hack
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 --- Comment #7 from Richard Biener --- The transform with doubles on the [1] element would produce unpckhpd%xmm1, %xmm1 unpckhpd%xmm0, %xmm0 mulsd %xmm1, %xmm0 unpcklpd%xmm0, %xmm0 so that's not profitable. Which vector element is cheap (free) to promote to scalar possibly depends on the target (ppc/arm with BE lane order?).
[Bug libstdc++/93602] [9/10/11 Regression] Missing reference to libiconv in 9.x libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug rtl-optimization/97714] [8/9/10/11 Regression] ICE in notice_source_line, at final.c:3237 since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.5
[Bug c++/97742] [10/11 Regression] endless loop with code reduced by creduce/cvise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97742 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3
[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/98119] [10/11 Regression] SVE: Wrong code with -O1 -ftree-vectorize -msve-vector-bits=512 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3
[Bug fortran/97612] [F08] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|WAITING |NEW Summary|Structure constructor of|[F08] Structure constructor |type with nested|of type with nested |allocatable array |allocatable array |components fails to compile |components fails to compile --- Comment #3 from Dominique d'Humieres --- > So it looks like the provided code example is not valid F03 but valid F08. So my question was not totally stupid!
[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #11 from David Binderman --- (In reply to Jakub Jelinek from comment #10) > I can't reproduce it anymore. The code in comment 7 still fails. $ /home/dcb/gcc/results/bin/gcc -c -w -ffast-math bug634.c 2>&1 | fgrep error: bug634.c:5:44: internal compiler error: in check_bool_attrs, at recog.c:2190 $ /home/dcb/gcc/results/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.20201206/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk.git/configure --prefix=/home/dcb/gcc/results.20201206 --disable-bootstrap --disable-multilib --disable-werror --with-pkgversion=8c23434fdadcf4ca --enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20201206 (experimental) (8c23434fdadcf4ca)
[Bug target/98172] New: Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 Bug ID: 98172 Summary: Update -mtune=generic for the current Intel and AMD processors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com Target Milestone: --- Target: i386,x86-64 -mtune=generic should be updated for the current Intel and AMD processors.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #38 from abebeos at lazaridis dot com --- Can someone please ping gcc-patches (me having troubles setting up email alias on gmail, don't want to use my main email)
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- What kind of updates you propose?
[Bug tree-optimization/97623] [9/10 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 Richard Biener changed: What|Removed |Added Known to work||11.0 Summary|[9/10/11 Regression]|[9/10 Regression] Extremely |Extremely slow O2 compile |slow O2 compile (>>O(n^2)) |(>>O(n^2)) | --- Comment #20 from Richard Biener --- So I think we can say it is fixed for GCC 11.
[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #12 from Martin Liška --- (In reply to Jakub Jelinek from comment #10) > I can't reproduce it anymore. I can still reproduce the original example with g:ebdfd1606da6b5aa586b0cd156b69b659235c9c2. https://godbolt.org/z/Y1jhf9
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #39 from John Paul Adrian Glaubitz --- (In reply to abebeos from comment #38) > Can someone please ping gcc-patches (me having troubles setting up email > alias on gmail, don't want to use my main email) I'm not sure what you are trying to achieve. There are guidelines for submitting patches which include signing the FSF copyright assignment using your full name and a proper email address. It's not possible to merge patches anonymously and it's also not possible to claim a bounty for the work contributed by a third party. An example for the proper process for submission of such a patch can be found here: > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559698.html
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-07 --- Comment #2 from H.J. Lu --- (In reply to Jan Hubicka from comment #1) > What kind of updates you propose? For one thing, memcpy/memset should be expanded to REP MOVSB/STOSB, never MOVSL/MOVSQ.
[Bug middle-end/98173] New: -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173 Bug ID: 98173 Summary: -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- I got curious about overall effect of PTA. This compares -fno-tree-pta to -ftree-pta. There is significant regression on tfft2 (and some with tramp3d) with -march=native on zen. https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14&older_in_days=0&min_percentage_change=0.02&revisions=03f48fb0d37c769661d30aa0f08d91bb7174cd98%2C68ee6d12fe9882223f47f81f93616577ab4e36da&include_user_branches=on https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?younger_in_days=14&older_in_days=0&min_percentage_change=0.02&revisions=03f48fb0d37c769661d30aa0f08d91bb7174cd98%2C68ee6d12fe9882223f47f81f93616577ab4e36da&include_user_branches=on
[Bug c++/98157] [10 Regression] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in add_candidates, at cp/call.c:5803 since r10-6219-g8b91e848130e45b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98157 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Nathan Sidwell --- I'll back port in a short while
[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
--- Comment #13 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #10)
> I can't reproduce it anymore.
For r11-5820,
[hjl@gnu-clx-1 gcc]$ cat 1.c
int b;
double c, d;
void fn1() {
int i;
for (i = 0; i < b; i++)
c += i;
}
int __attribute__((optimize(1))) main() {
double a[0];
int i;
for (i = 0; i < 9; i++)
d += a[i];
}
[hjl@gnu-clx-1 gcc]$ ./xgcc -B./ -mfpmath=sse,387 -fexcess-precision=standard
-Ofast -fno-graphite --param=scev-max-expr-size=0 -m32 1.c
during RTL pass: reload
1.c: In function ??main??:
1.c:13:1: internal compiler error: in check_bool_attrs, at recog.c:2189
13 | }
| ^
0x6d21c1 check_bool_attrs(rtx_insn*)
../../src-master/gcc/recog.c:2189
0xc568e0 lra_update_insn_recog_data(rtx_insn*)
../../src-master/gcc/lra.c:1260
0xc7197b process_insn_for_elimination
../../src-master/gcc/lra-eliminations.c:1304
0xc7197b lra_eliminate(bool, bool)
../../src-master/gcc/lra-eliminations.c:1372
0xc578d9 lra(_IO_FILE*)
../../src-master/gcc/lra.c:2461
0xc13129 do_reload
../../src-master/gcc/ira.c:5802
0xc13129 execute
../../src-master/gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #40 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #39)
> (In reply to abebeos from comment #38)
> > Can someone please ping gcc-patches (me having troubles setting up email
> > alias on gmail, don't want to use my main email)
>
> I'm not sure what you are trying to achieve.
Naturally, at this point, that someone verifies my results (I made this as
simple as a few cli commands).
> There are guidelines for submitting patches which include signing the FSF
> copyright assignment using your full name and a proper email address.
No need for full-name in public (FSF accepts even pseudonyms), no need to sign
anything just to get a technical feedback ("review"). We are now in "review"
state.
> It's not possible to merge patches anonymously and it's also not possible to
> claim a bounty for the work contributed by a third party.
I spend nearly a full-(over)-time month to achieve a result, fighting through
incomplete/inconsistent/missing documentation and "dark land", providing
finally the necessary (mostly) integration work. If I reuse existing code
instead of writing from scratch, well, I think that's the original authors
decision how to handle this.
But please stop talking like I did nothing, that's simply rude.
> An example for the proper process for submission of such a patch can be
> found here:
>
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559698.html
Too much talk for my taste. Test-suites talk better.
And if i need a lawyer to just be able to claim a bounty, well...
The thing is: can someone please verify the test-results?
[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144 Richard Biener changed: What|Removed |Added Attachment #49682|0 |1 is obsolete|| --- Comment #4 from Richard Biener --- Created attachment 49696 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49696&action=edit testcase that GCC 7 to GCC 11 can grok Updated testcase produced with a GCC 7 host compiler. While -fno-ree helps for GCC 7 to GCC 10: > /usr/bin/time g++-10 insn-extract.ii -fno-exceptions -fno-rtti -O2 -S > -fno-ree 19.90user 0.33system 0:20.25elapsed 99%CPU (0avgtext+0avgdata 1290440maxresident)k 0inputs+0outputs (0major+280821minor)pagefaults 0swaps it doesn't for trunk which shows ranger allocating 5GB of memory.
[Bug tree-optimization/98174] New: [11 Regression] Ranger takes too much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174 Bug ID: 98174 Summary: [11 Regression] Ranger takes too much memory Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- The testcase from PR98144 shows ranger eating 5GB memory which is excessive.
[Bug tree-optimization/98174] [11 Regression] Ranger takes too much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Keywords||missed-optimization CC||aldyh at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #1 from Richard Biener --- It removes a workaround for excessive REE memory use during RTL checking bootstrap (-fno-ree). -fno-tree-vrp tames it.
[Bug fortran/98175] New: Problem with gcc front end and ld on vanilla Windows 10 installation (spaces in path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98175 Bug ID: 98175 Summary: Problem with gcc front end and ld on vanilla Windows 10 installation (spaces in path) Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marcoxa at gmail dot com Target Milestone: --- Hi this came up while installing an update for "ps" in the latest R/Rtools/Rstudio combination. This is for 8.3.0 as included in Rtools 4.0.x. I don't know if it affects later versions of the GCC toolchain. I was able to reproduce it on a simpler case. Bottom line: while the GCC compiler frontend does not quote the "ld.exe" invocation. ``` g:\My Drive\Work\Projects\Hacking\elisp\iron-main\tests>"c:\Program Files\R\Rtools40\mingw64\bin\gfortran" hello.f "c:\Program Files\R\Rtools40\mingw64\bin\gfortran" hello.f c:/Program Files/R/Rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find c:/Program: No such file or directory c:/Program Files/R/Rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find Files/R/Rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status ``` Note that Rtools 4.0.x correctly quotes the gfortran (or gcc) command. But then, the inner call to "ld.exe" is not. I know I can work around this by changing the installation path, but people using vanilla W10 are bound to trip on this quite often. All the best Marco Antoniotti
[Bug tree-optimization/98176] New: Loop invariant memory could not be hoisted when nonpure_call in loop body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98176
Bug ID: 98176
Summary: Loop invariant memory could not be hoisted when
nonpure_call in loop body
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wwwhhhyyy333 at gmail dot com
Target Milestone: ---
For testcase
#include
void foo(float *x, float tx, float *ret, int n)
{
#pragma omp simd
for (int i = 0; i < n; i++)
{
float s,c;
sincosf(x[i] * tx, &s, &c);
*ret += s * c;
}
}
It could not be vectorized with -Ofast -fopenmp-simd -std=c++11
https://gcc.godbolt.org/z/ba77az
By manually hoist it could be vectorized with simd clone
void foo(float *x, float tx, float *ret, int n)
{
float tmp = 0.0f;
#pragma omp simd
for (int i = 0; i < n; i++)
{
float s,c;
sincosf(x[i] * tx, &s, &c);
tmp += s*c;
}
*ret += tmp;
}
https://gcc.godbolt.org/z/bea17x
Is it possible for lim to perform store motion on case like this?
[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #14 from Jakub Jelinek --- Ah, -march=x86-64 or -msse2 is needed for me on top of the specified options.
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 --- Comment #3 from Richard Biener --- Hmm, but rep movsb is only fast starting with Zen3 IIRC.
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172
--- Comment #4 from Jan Hubicka ---
> > What kind of updates you propose?
>
> For one thing, memcpy/memset should be expanded to REP MOVSB/STOSB, never
> MOVSL/MOVSQ.
For core cost tables we use:
/* core_cost should produce code tuned for Core familly of CPUs. */
static stringop_algs core_memcpy[2] = {
{libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
{libcall, {{24, loop, true}, {128, rep_prefix_8_byte, true},
{-1, libcall, false;
static stringop_algs core_memset[2] = {
{libcall, {{6, loop_1_byte, true},
{24, loop, true},
{8192, rep_prefix_4_byte, true},
{-1, libcall, false}}},
{libcall, {{24, loop, true}, {512, rep_prefix_8_byte, true},
{-1, libcall, false;
So we use mosl/modsw for blocks up to 8k in some cases.
What is output of contrib/bench-stringop on later cores?
Honza
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug middle-end/98173] -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173 Richard Biener changed: What|Removed |Added Version|unknown |11.0 Keywords||missed-optimization --- Comment #1 from Richard Biener --- PTA certainly can increase register pressure by means of more disambiguations and thus more store-motion or PRE. But you hardly can blame PTA for that ;)
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 --- Comment #5 from Jan Hubicka --- > Hmm, but rep movsb is only fast starting with Zen3 IIRC. Yep, I think we need to support zen1/2 well. I think we can regress buldozers somehwat though. Honza
[Bug middle-end/98173] -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173 --- Comment #2 from Jan Hubicka --- > PTA certainly can increase register pressure by means of more disambiguations > and thus more store-motion or PRE. But you hardly can blame PTA for that ;) It seems microarch specific, so it also can be just enabled vectorization...
[Bug tree-optimization/98176] Loop invariant memory could not be hoisted when nonpure_call in loop body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98176
--- Comment #1 from Richard Biener ---
The issue is that x[i] may alias *ret and that PRE did half of the store-motion
job only so we can't recognize the reduction pattern. I'm not sure whether
#pragma omp simd guarantees there's no forward dependence between x[]
and ret but I guess it's at least valid that x == ret, no?
The vectorizer relies on reductions being "scalar" so something would need to
do the store-motion for us.
I doubt the call is the issue btw. The following fails the same way:
#include
void foo(float *x, float tx, float *ret, int n)
{
#pragma omp simd
for (int i = 0; i < n; i++)
{
float s,c;
s = c = x[i] * tx;
*ret += s * c;
}
}
[Bug middle-end/98173] -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173 Jan Hubicka changed: What|Removed |Added Keywords|missed-optimization | Version|11.0|unknown --- Comment #3 from Jan Hubicka --- Note that also nbench/FP EMULATION regresses on both zens but not on cabylake.
[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Liška --- (In reply to Tamar Christina from comment #12) > @Martin I believe this was re-opened as the patch was reverted on master but > was still pending reverts on the release branches. > > @Mark I assume you committed the reverts to the branches too? I see the reverts in release branches as well: g:20ed049a8d7d5b879129c5550bfcde36a0c170ec g:0676e194c753a1959ea7f7a05761a26466148bda g:b65099a08e257cc9c93060c6299311faaa4b44e9
[Bug ipa/79506] Compile time increase after r245366 (params.def (inline-min-speedup) Change from 10 to 8.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79506 --- Comment #2 from Jan Hubicka --- badness being a very small negative number is actually normal for large functions like this one (perhaps I should print it better though). I can check from where the estimated speedup comes - perhaps we work out some loop invariants and thus anticipate invariant motion?
[Bug driver/98175] Problem with gcc front end and ld on vanilla Windows 10 installation (spaces in path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98175 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-12-07 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This seems target specific.
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #12 from Dominique d'Humieres --- > > Could this PR be closed as INVALID? > > Yes, I think so. So closing.
[Bug ipa/79506] Compile time increase after r245366 (params.def (inline-min-speedup) Change from 10 to 8.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79506 --- Comment #3 from Jan Hubicka --- Actually it is visible from the dump Scaling time by probability:0.00 means that we expect quite few values to be "almost invariant". It may come from busted BB profile of course.
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 --- Comment #6 from H.J. Lu --- (In reply to Richard Biener from comment #3) > Hmm, but rep movsb is only fast starting with Zen3 IIRC. Are MOVSL/MOVSQ faster than MOVSB on Zen1/Zen2?
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 --- Comment #7 from H.J. Lu --- GCC 11 will be system GCC 2 years from now. The current processors in 2020 will be 2 years old.
[Bug target/98177] New: [11 Regression] SVE: ICE in expand_direct_optab_fn, at internal-fn.c:3368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98177
Bug ID: 98177
Summary: [11 Regression] SVE: ICE in expand_direct_optab_fn, at
internal-fn.c:3368
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following C++ testcase:
int a, b;
short c;
void d(long e) {
for (int f = 0; f < b; f += 1)
for (short g = 0; g < c; g += 5)
a = (short)e;
}
we ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=128 since
r11-4912-g46c705e70e078f6a1920d92e49042125d5e18495.
To reproduce:
$ aarch64-elf-gcc -c -S -Ofast -march=armv8.2-a+sve -msve-vector-bits=128
test.cc
during RTL pass: expand
test.cc: In function 'void d(long int)':
test.cc:3:6: internal compiler error: in expand_direct_optab_fn, at
internal-fn.c:3368
3 | void d(long e) {
| ^
0xd63e0f expand_direct_optab_fn
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.c:3368
0xd64978 expand_REDUC_MAX
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.def:209
0xd6631e expand_internal_call(internal_fn, gcall*)
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.c:4089
0xd66338 expand_internal_call(gcall*)
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.c:4097
0xae74ad expand_call_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:2740
0xae74ad expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3835
0xae74ad expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3999
0xaf1827 expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6043
0xaf2ede execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6727
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/98177] [11 Regression] SVE: ICE in expand_direct_optab_fn, at internal-fn.c:3368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98177 Alex Coplan changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target||aarch64 Target Milestone|--- |11.0 Known to fail||11.0 Keywords||ice-on-valid-code
[Bug driver/98175] Problem with gcc front end and ld on vanilla Windows 10 installation (spaces in path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98175 --- Comment #2 from Marco Antoniotti --- In what sense is "target specific"? Windows specific? I am asking because I am not versed in the details of the drivers implementation. All the best Marco
[Bug rtl-optimization/98178] New: Combine splitter does not split to single instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178 Bug ID: 98178 Summary: Combine splitter does not split to single instruction Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Created attachment 49697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49697&action=edit Proof-of-concept target patch to reimplement shift insn splitters The PoC patch is trying to reimplement x86 "Avoid useless masking of count operand" define_insn_and_split shift patterns with a combine splitter approach, similar to PR96226.
[Bug rtl-optimization/98178] Combine splitter does not split to single instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178
--- Comment #1 from Uroš Bizjak ---
The attached patch with the following testcase:
--cut here--
int test (int a, int b)
{
return a << (b & 31);
}
--cut here--
fails to generate a single shift insn, because it does not trigger the call to
combine_split_insns. The reason is the following condition:
/* If we were combining three insns and the result is a simple SET
with no ASM_OPERANDS that wasn't recognized, try to split it into two
insns. There are two ways to do this. It can be split using a
machine-specific method (like when you have an addition of a large
constant) or by combine in the function find_split_point. */
if (i1 && insn_code_number < 0 && GET_CODE (newpat) == SET
&& asm_noperands (newpat) < 0)
where i1 is null.
Please note, that omitting FLAGS_REG is intentional, c.f. PR96226#c2.
[Bug rtl-optimization/98178] Combine splitter does not split to single instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178 --- Comment #2 from Uroš Bizjak --- On a related note, the combine splitter is a very mysterious beast, and does not easily tell, why the particular combination is rejected. Without any debug in debug logs it is very frustrating to figure out the reason.
[Bug c/98168] Optimization that can lead to security vulnerabilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98168 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- CERT Secure Coding Standard rule "INT32-C. Ensure that operations on signed integers do not result in overflow" shows a number of helpful examples of how to detect and prevent signed overflow in integer arithmetic: https://wiki.sei.cmu.edu/confluence/x/UtYxBQ GCC provides a number of efficient intrinsics to do the same: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
[Bug rtl-optimization/98179] New: gcc.dg/pr97954.c fails on (at least) BE powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98179
Bug ID: 98179
Summary: gcc.dg/pr97954.c fails on (at least) BE powerpc
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: ---
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c: In function 'foo':
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c:12:1: error: too many
outgoing branch edges from bb 4
during RTL pass: loop2_invariant
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c:12:1: internal compiler
error: verify_flow_info failed
0x10435cb3 verify_flow_info()
/home/segher/src/gcc/gcc/cfghooks.c:269
0x10876cc7 checking_verify_flow_info
/home/segher/src/gcc/gcc/cfghooks.h:212
0x10876cc7 move_loop_invariants()
/home/segher/src/gcc/gcc/loop-invariant.c:2299
0x1087142f execute
/home/segher/src/gcc/gcc/loop-init.c:530
This happens because this passed moved insn 8 from bb 4 to 2:
(jump_insn 8 2 22 2 (parallel [
(set (reg:SI 118 [ x ])
(asm_operands:SI ("") ("=r") 0 []
[]
[
(label_ref:DI 22)
] pr97954.c:10))
(clobber (reg:SI 98 ca))
]) "pr97954.c":10:3 -1
(expr_list:REG_UNUSED (reg:SI 98 ca)
(nil))
-> 22)
We shouldn't allow such a move at all (not of any jump_insn!)
[Bug tree-optimization/98180] New: [11 regression] ICE at gcc/toplev.c:327 for gcc.target/powerpc/builtins-revb-runnable.c after r11-5821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98180 Bug ID: 98180 Summary: [11 regression] ICE at gcc/toplev.c:327 for gcc.target/powerpc/builtins-revb-runnable.c after r11-5821 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:ebdfd1606da6b5aa586b0cd156b69b659235c9c2, r11-5821 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/builtins-revb-runnable.c" FAIL: gcc.target/powerpc/builtins-revb-runnable.c (internal compiler error) FAIL: gcc.target/powerpc/builtins-revb-runnable.c (test for excess errors) # of unexpected failures2 # of unresolved testcases 1 Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled1172900.cc -fdiagnostics-plain-output -S -o exceptions_enabled1172900.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled1172900.cc -fdiagnostics-plain-output -S -o exceptions_enabled1172900.s FAIL: gcc.target/powerpc/builtins-revb-runnable.c (test for excess errors) Excess errors: during GIMPLE pass: slp /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/builtins-revb-runnable.c:17:1: internal compiler error: Segmentation fault 0x10b56bf3 crash_signal /home/seurer/gcc/git/gcc-test/gcc/toplev.c:327 0x10f51a00 bst_traits::hash(vec<_stmt_vec_info*, va_heap, vl_ptr>) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:1347 0x10f51a00 simple_hashmap_traits::hash(vec<_stmt_vec_info*, va_heap, vl_ptr> const&) /home/seurer/gcc/git/gcc-test/gcc/hash-map-traits.h:50 0x10f51a00 hash_map, _slp_tree*, simple_hashmap_traits >::get(vec<_stmt_vec_info*, va_heap, vl_ptr> const&) /home/seurer/gcc/git/gcc-test/gcc/hash-map.h:185 0x10f51a00 vect_build_slp_tree /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:1379 0x10f55da3 vect_build_slp_instance /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:2238 0x10f57887 vect_analyze_slp(vec_info*, unsigned int) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:2586 0x10f6081b vect_slp_analyze_bb_1 /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4385 0x10f6081b vect_slp_region /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4497 0x10f62603 vect_slp_bbs /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4645 0x10f62c0b vect_slp_function(function*) /home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4731 0x10f64ec3 execute /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1436
[Bug rtl-optimization/98178] Combine splitter does not split to single instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178 --- Comment #3 from Segher Boessenkool --- Yup, this is true in general, we almost never say why we don't combine so far. Patches welcome! (Make sure you use TDF_DETAILS for such prints).
[Bug bootstrap/98181] New: Add support for FreeBSD on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98181 Bug ID: 98181 Summary: Add support for FreeBSD on powerpc64le Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: pkubaj at anongoth dot pl Target Milestone: --- Created attachment 49698 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49698&action=edit patch FreeBSD has recently added support for powerpc64le architecture (ppc64le using Linux naming). FreeBSD and GCC both had previously supported powerpc64 (ppc64 using Linux naming) so this patch is pretty simple, it only adds endianness detection using similar code that Linux code uses. While here, also clear the issue of default tuning. People that still use 32-bit POWER are likely on G4, so tune for that. On 64-bits, tune for POWER8 (similarly to Linux). Also remove the obsolete comment that FreeBSD doesn't support anything newer than PPC970 - it works nice on my POWER9 workstation.
