[Bug middle-end/94647] [10 Regression] bogus -Warray-bounds on strncpy into a larger member array from a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94647 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #2 from Richard Biener --- I think this is also about trailing arrays not appropriately handled since clearly s->string can be bigger than 256 chars.
[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 Richard Biener changed: What|Removed |Added Target||x86_64-*-* --- Comment #1 from Richard Biener --- It's also an ABI issue when code compiled with -mcx16 and without -mcx16 has to inter-operate. So it might be a deliberate choice and not a missed optimization.
[Bug target/94650] Missed x86-64 peephole optimization: x >= large power of two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94650 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Keywords||missed-optimization Last reconfirmed||2020-04-20 Status|UNCONFIRMED |NEW Target||x86_64-*-* --- Comment #1 from Richard Biener --- Confirmed.
[Bug lto/94659] Missing symbol with LTO and target_clones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-20 --- Comment #1 from Martin Liška --- Confirmed, working on that..
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 Richard Biener changed: What|Removed |Added CC||msebor at gcc dot gnu.org Target Milestone|--- |10.0 Keywords||diagnostic Component|c++ |tree-optimization Summary|Implicit assignment |[10 Regression] Implicit |operator triggers |assignment operator |stringop-overflow warning |triggers stringop-overflow ||warning
[Bug middle-end/94658] Incorrect transformation with -fstrict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94658 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- Yes, it's a duplicate. *** This bug has been marked as a duplicate of bug 57359 ***
[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 Richard Biener changed: What|Removed |Added CC||pascal_cuoq at hotmail dot com --- Comment #21 from Richard Biener --- *** Bug 94658 has been marked as a duplicate of this bug. ***
[Bug ipa/94656] target_clones on alias leads to segfault in the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94656
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-04-20
--- Comment #1 from Richard Biener ---
GCC 10 now rejects this:
> ./cc1 -quiet x.c
x.c:6:52: error: clones for ‘target_clones’ attribute cannot be created
6 | __attribute__((target_clones("default,avx"))) void f2()
__attribute__((alias("f1")));
|^~
x.c:6:52: note: ‘target_clones’ cannot be combined with ‘alias’ attribute
so likely a duplicate bug and a backport is missing.
[Bug target/94666] New: S/390: ICE on vectorized popcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666 Bug ID: 94666 Summary: S/390: ICE on vectorized popcount Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Target Milestone: --- Created attachment 48308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48308&action=edit Testcase Compiling the attached testcase with: cc1plus -O3 -march=z13 t.cc ICEs: t.cc: In function ‘void h()’: t.cc:16:1: error: unrecognizable insn: 16 | } | ^ (insn 94 93 95 7 (set (reg:V16QI 434) (unspec:V16QI [ (subreg:V16QI (subreg:V2DI (reg:V16QI 432) 0) 0) ] UNSPEC_POPCNT)) "t.cc":6:30 -1 (nil)) during RTL pass: vregs t.cc:16:1: internal compiler error: in extract_insn, at recog.c:2294
[Bug lto/94659] [8/9/10 Regression] Missing symbol with LTO and target_clones since r8-1461-g871cc215f7507cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659 Martin Liška changed: What|Removed |Added Keywords|wrong-code | Summary|Missing symbol with LTO and |[8/9/10 Regression] Missing |target_clones |symbol with LTO and ||target_clones since ||r8-1461-g871cc215f7507cbe Target Milestone|--- |10.0 --- Comment #2 from Martin Liška --- Started with r8-1461-g871cc215f7507cbe.
[Bug target/94666] S/390: ICE on vectorized popcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-04-20 Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org --- Comment #1 from Andreas Krebbel --- Created attachment 48309 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48309&action=edit Patch The expander has to simplify the generated subreg in case the incoming operand is already a subreg.
[Bug ipa/94656] target_clones on alias leads to segfault in the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94656 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Martin Liška --- Yes, it's a dup, not planned for backport. *** This bug has been marked as a duplicate of bug 90500 ***
[Bug lto/90500] ICE error in copy_forbiden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500 Martin Liška changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #22 from Martin Liška --- *** Bug 94656 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Last reconfirmed||2020-04-20 CC||marxin at gcc dot gnu.org Known to fail||10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|[10 Regression] Implicit|[10 Regression] Implicit |assignment operator |assignment operator |triggers stringop-overflow |triggers stringop-overflow |warning |warning since ||r10-5451-gef29b12cfbb4979a --- Comment #1 from Martin Liška --- Confirmed, started with r10-5451-gef29b12cfbb4979a.
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #4 from z.zhanghaijian at huawei dot com --- (In reply to Segher Boessenkool from comment #2) > If vara is a NaN, this is not the same; it needs -ffinite-math-only. > And in fact adding that option does the trick (on powerpc that is, I > don't have an aarch64 Fortran handy). > > Could you check this please? Yes, on aarch64, fmaxnm can be generated with -ffinite-math-only and -funsafe-math-optimizations. One question: why is it OK for rtl combine to generate the fminnm here? Anything I missed?
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-20 Status|UNCONFIRMED |WAITING --- Comment #3 from Martin Liška --- Are you sure the reduced test-case can be compiled with gcc 9?
[Bug c/94641] -Wpadded -fsanitize=undefined together cause warning on main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94641 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Last reconfirmed||2020-04-20 --- Comment #1 from Martin Liška --- Confirmed, started with GCC 5.1.0.
[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
--- Comment #8 from Martin Liška ---
(In reply to Nicholas Krause from comment #7)
> After adding this it seems to work for me, Patrick:
>case TYPE_ARGUMENT_PACK:
> if (value_dependent_expression_p(TREE_TYPE(*tp)))
> return *tp;
> if (TEMPLATE_TYPE_PARAMETER_PACK(*tp))
> return *tp;
> return NULL_TREE;
>
> and gives me:
> test.c: In function ‘std::common_type_t (forward(f)(std::integral_constant(),
> (forward)(args)...)), decltype
> (forward(f)(int_constant(), (forward)(args)...))...>
> select(int, F&&, Args&& ...)’:
> test.c:14:12: warning: ‘if constexpr’ only available with ‘-std=c++17’ or
> ‘-std=gnu++17’
>14 | if constexpr(sizeof...(Is)>0)
> |^
> test.c: In function ‘std::common_type_t (forward(f)(std::integral_constant(),
> (forward)(select::args)...)), decltype
> (forward(f)(int_constant(),
> (forward)(select::args)...))...> select(int, F&&,
> Args&& ...) [with int I = 1; int ...Is = {}; F = t(int)::;
> Args = {}]’:
> test.c:17:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>17 | }
> | ^
>
> with no segfault. I'm not sure if this is the correct part to add this test
> for TYPE_ARGUMENT_PACK or if we would prefer it to be lower in the stack.
The suggested change is wrong:
/home/marxin/Programming/gcc2/objdir/./gcc/xgcc -shared-libgcc
-B/home/marxin/Programming/gcc2/objdir/./gcc -nostdinc++
-L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-x c++-header -nostdinc++ -g -O2
-D_GNU_SOURCE
-I/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/marxin/Programming/gcc2/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/home/marxin/Programming/gcc2/libstdc++-v3/include/precompiled/stdc++.h \
-o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/include/cmath:42,
from
/home/marxin/Programming/gcc2/libstdc++-v3/include/precompiled/stdc++.h:41:
/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/cpp_type_traits.h:89:63:
internal compiler error: tree check: expected template_type_parm or
template_template_parm or bound_template_template_parm, have tree_list in
instantiation_dependent_r, at cp/pt.c:26926
89 | enum { __value = bool(_Sp::__value) || bool(_Tp::__value) };
| ^
0x8404c2 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9727
0x69234b tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/tree.h:3327
0x69234b instantiation_dependent_r
../../gcc/cp/pt.c:26926
0x13749b3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:11996
0xb10a88 cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*)
../../gcc/cp/tree.c:5061
0x1374a47 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12019
0x1377c85 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
../../gcc/tree.c:12352
0xa97c87 instantiation_dependent_uneval_expression_p(tree_node*)
../../gcc/cp/pt.c:27033
0xa9e278 instantiation_dependent_expression_p(tree_node*)
../../gcc/cp/pt.c:27043
0x973ba7 is_nondependent_constant_expression(tree_node*)
../../gcc/cp/constexpr.c:8300
0x973fca fold_non_dependent_expr_template
../../gcc/cp/constexpr.c:6970
0xa98147 build_non_dependent_expr(tree_node*)
../../gcc/cp/pt.c:27531
0xb271ef build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
../../gcc/cp/typeck.c:4245
0xa54e71 cp_parser_binary_expression
../../gcc/cp/parser.c:9719
0xa5671e cp_parser_assignment_expression
../../gcc/cp/parser.c:9859
0xa556cd cp_parser_constant_expression
../../gcc/cp/parser.c:10153
0xa62028 cp_parser_enumerator_definition
../../g
[Bug c/94641] -Wpadded -fsanitize=undefined together cause warning on main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94641 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #5 from Segher Boessenkool --- Can you show the -fdump-rtl-combine-all dump where that insn is created? It is fine to generate min or max insns here; but you need to handle the case where vara is NaN: you should return that NaN then. Other than that your function is just the max of vara, varb, varc.
[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623 --- Comment #6 from David Binderman --- I removed the sed lines from my configure script and did a build of D from today's gcc trunk and it's still going wrong: Configure line is now: ../trunk.git/configure --prefix=/home/dcb/gcc/results.20200420.d \ --disable-bootstrap \ --disable-multilib \ --disable-werror \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=d and here is the run: $ ./results.20200420.d/bin/gdc -c trunk.git/gcc/testsuite/gdc.test/compilable/interpret3.d d21: internal compiler error: in chainExceptions, at d/dmd/dinterpret.c:1661 Merely to eliminate the obvious: what happens if you try to run the D compiler directly from the command line, thus not using the gcc test infrastructure ? I'll reduce the checking flags down to "no" and see what happens. I notice that the D source code file is about 7,700 lines of code. I wonder if creduce understands D ?
[Bug c/94641] -Wpadded -fsanitize=undefined together cause warning on main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94641 --- Comment #2 from Jakub Jelinek --- Created attachment 48310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48310&action=edit gcc10-pr94641.patch Untested fix.
[Bug c/94667] New: GCC duplicates prerequisites when generating 'make' rules if headers are not in current directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94667 Bug ID: 94667 Summary: GCC duplicates prerequisites when generating 'make' rules if headers are not in current directory Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: iskustvo at yahoo dot com Target Milestone: --- Invoking GCC with both -I and -M* flags ends up duplicating prerequisites in generated 'make' rule. Small SHELL script which can create minimal environment for reproduction: #!/bin/sh mkdir -p bug/src bug/include touch bug/include/a.h echo '#include "a.h"' > bug/include/b.h printf '%s\n%s\n' '#include "a.h"' '#include "b.h"' > bug/src/main.c gcc -I bug/include -MM bug/src/main.c Output from the above script: -- main.o: bug/src/main.c bug/include/a.h bug/include/b.h bug/include/a.h -- Note that "bug/include/a.h" is duplicated in the prerequisite list. Additional notes: 1) Issue was originally detected in C++ code. 2) Header guards(omitted for simplicity of example) don't solve this issue. 3) After moving headers from 'include' to 'src', GCC gives desired output. 4) Replacing "gcc" with "clang" gives desired output. Issue is reproducible with both system's and latest versions of GCC. System GCC: /usr/bin/gcc -v -- Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pkgversion='Arch Linux 9.3.0-1' --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc Thread model: posix gcc version 9.3.0 (Arch Linux 9.3.0-1) -- Latest manually built GCC: /usr/local/bin/gcc -v -- Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200419 (experimental) [master revision 62f3d4ea899:7def9c6a6f6:fc186077486fb6e5453157ad8507c66d0a34017c] (GCC) --
[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #7 from David Binderman ---
>I wonder if creduce understands D ?
Yes it does. Reduced D code is
void a() {
try
try
try
throw new Exception("");
finally throw new Error("");
finally {}
catch {
}
}
int b() {
a;
return 1;
}
static assert(b);
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665
--- Comment #6 from z.zhanghaijian at huawei dot com ---
(In reply to Segher Boessenkool from comment #5)
> Can you show the -fdump-rtl-combine-all dump where that insn is
> created?
>
> It is fine to generate min or max insns here; but you need to handle the
> case where vara is NaN: you should return that NaN then. Other than that
> your function is just the max of vara, varb, varc.
The dump info：
Trying 39 -> 40:
39: cc:CCFPE=cmp(r94:SF,r93:SF)
40: r94:SF={(cc:CCFPE<0)?r94:SF:r93:SF}
REG_DEAD r93:SF
REG_DEAD cc:CCFPE
Successfully matched this instruction:
(set (reg:SF 94 [ _4 ])
(smin:SF (reg:SF 94 [ _4 ])
(reg:SF 93 [ _2 ])))
allowing combination of insns 39 and 40
original costs 4 + 4 = 8
replacement cost 8
deferring deletion of insn with uid = 39.
modifying insn i340: r94:SF=smin(r94:SF,r93:SF)
REG_DEAD r93:SF
deferring rescan insn with uid = 40.
[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #8 from Iain Buclaw ---
(In reply to David Binderman from comment #7)
> >I wonder if creduce understands D ?
>
> Yes it does. Reduced D code is
>
> void a() {
> try
> try
> try
> throw new Exception("");
> finally throw new Error("");
> finally {}
> catch {
> }
> }
> int b() {
> a;
> return 1;
> }
> static assert(b);
Thanks, alternatively, there is dustmite (which is made specifically for D)
https://github.com/CyberShadow/DustMite
Built using: gdc dustmite.d splitter.d polyhash.d -o dustmite
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #28 from rguenther at suse dot de --- On Fri, 17 Apr 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 > > --- Comment #26 from Jakub Jelinek --- > For debug stmts, it would be best if we could use those > DEBUG D#Y s=> parm > DEBUG var => D#Y > added in if (param_body_adjs && MAY_HAVE_DEBUG_BIND_STMTS). > Though, if we remove already during the copy_bb by not actually creating the > stmt, I'm afraid that will mean the debug info is lost (debug stmts will be > reset), unless we for the lhs of to be dced stmts manually create debug > temporaries and debug stmts when we remap_gimple_stmt those stmts (for > SSA_NAMEs that are directly (or indirectly!) used in debug stmts). > If we do what Martin was proposing instead, i.e. copy the stmts and then DCE > them afterwards, it might work properly (perhaps only if we DCE them in the > right order). It's true that copying everything and then DCEing is easier for debug stmt generation. I didn't consider this. That also argues for not remapping anything to error_mark_node. Of course this leaves us with no automagic verification if we really DCEd everything required (esp. his handling of call arguments looks expensive and odd to me). I'm also not sure how the machinery is helping the __builtin_constant_p inline predication issue.
[Bug target/94663] [missed optimization] _mm512_dpbusds_epi32 generates excess vmovdqa64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94663
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||ra
Last reconfirmed||2020-04-20
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
I bet IRA is confused by the subregs.
The loop has:
(insn 30 26 32 4 (set (reg:V16SI 112)
(unspec:V16SI [
(subreg:V16SI (reg/v:V8DI 92 [ e ]) 0)
(reg:V16SI 89 [ _25 ])
(reg:V16SI 94 [ _63 ])
] UNSPEC_VPMADDUBSWACCSSD)) "include/avx512vnniintrin.h":66:20 5895
{vpdpbusds_v16si}
(expr_list:REG_DEAD (reg/v:V8DI 92 [ e ])
(nil)))
(insn 32 30 36 4 (set (reg/v:V8DI 92 [ e ])
(subreg:V8DI (reg:V16SI 112) 0)) "include/avx512vnniintrin.h":66:10
1327 {movv8di_internal}
(nil))
(insn 36 32 38 4 (set (reg:V16SI 116)
(unspec:V16SI [
(subreg:V16SI (reg/v:V8DI 88 [ f ]) 0)
(reg:V16SI 89 [ _25 ])
(reg:V16SI 93 [ _61 ])
] UNSPEC_VPMADDUBSWACCSSD)) "include/avx512vnniintrin.h":66:20 5895
{vpdpbusds_v16si}
(expr_list:REG_DEAD (reg:V16SI 89 [ _25 ])
(expr_list:REG_DEAD (reg/v:V8DI 88 [ f ])
(nil
(insn 38 36 39 4 (set (reg/v:V8DI 88 [ f ])
(subreg:V8DI (reg:V16SI 116) 0)) "include/avx512vnniintrin.h":66:10
1327 {movv8di_internal}
(nil))
as the only instructions that refer pseudos 112, 92, 116, 88 and the
constraints on the vpdpbusds_v16si
insn are "=v" "0" "v" "vm", so best would be if IRA assigns the same hard
register to pseudos 112 and 92
and another one to 116 and 88. But it actually assigns a different hard
register for each.
[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623 --- Comment #9 from Iain Buclaw --- (In reply to David Binderman from comment #6) > I removed the sed lines from my configure script and did a build of D > from today's gcc trunk and it's still going wrong: > > Configure line is now: > > ../trunk.git/configure --prefix=/home/dcb/gcc/results.20200420.d \ > --disable-bootstrap \ > --disable-multilib \ > --disable-werror \ > --enable-checking=df,extra,fold,rtl,yes \ > --enable-languages=d > > and here is the run: > > $ ./results.20200420.d/bin/gdc -c > trunk.git/gcc/testsuite/gdc.test/compilable/interpret3.d > d21: internal compiler error: in chainExceptions, at d/dmd/dinterpret.c:1661 > > Merely to eliminate the obvious: what happens if you try > to run the D compiler directly from the command line, thus > not using the gcc test infrastructure ? > Yes, still it is elusive on my end. Can you try building with --enable-bootstrap?
[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623 --- Comment #10 from David Binderman --- (In reply to David Binderman from comment #6) > I'll reduce the checking flags down to "no" and see what happens. It works fine. So it looks like one of the checking flags (df,extra,fold,rtl,yes) breaks it. It will take a few hours, but I'll try to find out which one.
[Bug lto/94659] [8/9/10 Regression] Missing symbol with LTO and target_clones since r8-1461-g871cc215f7507cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659 --- Comment #3 from Martin Liška --- I've got a patch candidate, testing right now.
[Bug target/94668] New: [10 Regression] ICE generating float vec_inits since r10-808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668
Bug ID: 94668
Summary: [10 Regression] ICE generating float vec_inits since
r10-808
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following with -O -march=armv8.2-a+sve -msve-vector-bits=512:
typedef float v16sf __attribute__ ((vector_size(64)));
v16sf
foo (float a)
{
return (v16sf) { 0, 0, 0, a, 0, 0, 0, 0, 0, a, 0, 0, 0, 0, 0, 0 };
}
gives:
foo.c:5:10: internal compiler error: in decompose, at rtl.h:2296
5 | return (v16sf) { 0, 0, 0, a, 0, 0, 0, 0, 0, a, 0, 0, 0, 0, 0, 0 };
| ^
0xd8db39 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
src/gcc/gcc/rtl.h:2296
0xd8db39 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&, unsigned int)
src/gcc/gcc/wide-int.h:1034
0xd8db39 generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
src/gcc/gcc/wide-int.h:790
0xd8db39 wi::binary_traits,
std::pair, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::result_type wi::sub, std::pair >(std::pair const&, std::pair const&)
src/gcc/gcc/wide-int.h:2510
0xd8db39 rtx_vector_builder::step(rtx_def*, rtx_def*) const
src/gcc/gcc/rtx-vector-builder.h:122
0xd8db39 vector_builder::elt(unsigned int) const
src/gcc/gcc/vector-builder.h:254
0x1216012 aarch64_sve_expand_vector_init_handle_trailing_constants
src/gcc/gcc/config/aarch64/aarch64.c:18393
0x1218fdc aarch64_sve_expand_vector_init
src/gcc/gcc/config/aarch64/aarch64.c:18517
0x1219248 aarch64_sve_expand_vector_init
src/gcc/gcc/config/aarch64/aarch64.c:18558
0x121926d aarch64_sve_expand_vector_init
src/gcc/gcc/config/aarch64/aarch64.c:18562
0x1219710 aarch64_sve_expand_vector_init(rtx_def*, rtx_def*)
src/gcc/gcc/config/aarch64/aarch64.c:18601
0x163d4eb gen_vec_initvnx16qiqi(rtx_def*, rtx_def*)
src/gcc/gcc/config/aarch64/aarch64-sve.md:2535
0x9c9cde insn_gen_fn::operator()(rtx_def*, rtx_def*) const
src/gcc/gcc/recog.h:317
0x9c9cde store_constructor
src/gcc/gcc/expr.c:6965
0x9cc8fc expand_constructor
src/gcc/gcc/expr.c:8279
0x9b35b9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
src/gcc/gcc/expr.c:10388
0x9b5038 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
src/gcc/gcc/expr.c:10058
0x9c404a store_expr(tree_node*, rtx_def*, int, bool, bool)
src/gcc/gcc/expr.c:5752
0x9c5d67 expand_assignment(tree_node*, tree_node*, bool)
src/gcc/gcc/expr.c:5514
0x852437 expand_gimple_stmt_1
src/gcc/gcc/cfgexpand.c:3749
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/94668] [10 Regression] ICE generating float vec_inits since r10-808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Last reconfirmed||2020-04-20 --- Comment #1 from rsandifo at gcc dot gnu.org --- The problem is that the rtx_vector_builder arguments are the wrong way around. Testing a patch.
[Bug target/94668] [10 Regression] ICE generating float vec_inits since r10-808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668 rsandifo at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- We must have dups for this, the warning relies on something that the IL doesn't provide. fre4 changes: _8 = &MEM[(struct A *)_5 + 8B].strA; std::__cxx11::basic_string::_M_assign (_8, &D.113592.strA); [local count: 1073741824]: _9 = &MEM[(struct A *)_5 + 8B].arr; - _31 = &MEM[(struct A *)_5 + 8B]; - _29 = _31 + 32; - _24 = &D.113592 + 33; - _21 = _29 - _24; + _29 = _8 + 32; + _21 = _29 - &MEM [(void *)&D.113592 + 33B]; ... - vectp.110_64 = &D.113592 + 32; - _69 = &MEM[(struct A *)_5 + 8B]; - vectp.113_68 = _69 + 32; - vect__13.111_67 = MEM [(const char *)vectp.110_64]; - MEM [(char *)vectp.113_68] = vect__13.111_67; - vectp.109_66 = vectp.110_64 + 16; - vectp.112_71 = vectp.113_68 + 16; - ivtmp_74 = 1; + vect__13.111_67 = MEM [(const char *)&D.113592 + 32B]; + MEM [(char *)_29] = vect__13.111_67; + vectp.112_71 = _29 + 16; and the warning warns because it thinks the store uses the strA + 32 pointer to store the 16 bytes (vectorized), but the user code doesn't do that, only the value numbering found that the value is equal to that. Perhaps SCCVN could try to modify the &something.field into &MEM_REF[..., off] if it decides to reuse it in some context that doesn't use the same field base, but not sure how hard would that be.
[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #22 from Richard Biener ---
Created attachment 48311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48311&action=edit
patch
Note that apart from the possible bad impact on optimization when fixing this
bug an actual fix is complicated by the custom "optimized" dependence analysis
code in the loop invariant motion pass.
A conservative "simple" patch would be the attached but that doesn't preserve
store-motion for the following (because the LIM data dependence code doesn't
care about stmt order):
typedef int A;
typedef float B;
void __attribute__((noinline,noclone))
foo(A *p, B *q, long unk)
{
for (long i = 0; i < unk; ++i) {
q[i] = 42;
*p = 1;
}
}
usually this bug doesn't manifest itself but of course the fix will be
experienced everywhere. Benchmarking the simple patch might reveal
it's not an issue (but I doubt that...).
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 --- Comment #4 from Avi Kivity --- Yes (at least mine, don't know about Rafael's)
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #29 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #28) > On Fri, 17 Apr 2020, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 > > > > --- Comment #26 from Jakub Jelinek --- > > For debug stmts, it would be best if we could use those > > DEBUG D#Y s=> parm > > DEBUG var => D#Y > > added in if (param_body_adjs && MAY_HAVE_DEBUG_BIND_STMTS). > > Though, if we remove already during the copy_bb by not actually creating the > > stmt, I'm afraid that will mean the debug info is lost (debug stmts will be > > reset), unless we for the lhs of to be dced stmts manually create debug > > temporaries and debug stmts when we remap_gimple_stmt those stmts (for > > SSA_NAMEs that are directly (or indirectly!) used in debug stmts). > > If we do what Martin was proposing instead, i.e. copy the stmts and then DCE > > them afterwards, it might work properly (perhaps only if we DCE them in the > > right order). > > It's true that copying everything and then DCEing is easier for debug > stmt generation. I didn't consider this. That also argues for not > remapping anything to error_mark_node. Of course this leaves us with > no automagic verification if we really DCEd everything required > (esp. his handling of call arguments looks expensive and odd to me). We could remap those to error_mark_node for -g0 and for -g to the DEBUG_EXPR_DECLs we'd create and then just during verification make sure we diagnose DEBUG_EXPR_DECLs in non-debug stmts (and error_mark_node). Though, I think even right now the debug side of things even without the DCE is not perfect, we do create a bind to cover the optimized out parameters at the start of the function, but don't do this remapping of the SSA_NAME to that DEBUG_EXPR_DECL, which means that e.g. debug stmts that used to use that SSA_NAME in some expressions are reset. So, I think if Martin comes up with something that just doesn't handle the debug stmts for GCC10, I can try to improve the debug side later.
[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623 --- Comment #11 from David Binderman --- (In reply to David Binderman from comment #10) > (In reply to David Binderman from comment #6) > > I'll reduce the checking flags down to "no" and see what happens. > > It works fine. So it looks like one of the checking flags > (df,extra,fold,rtl,yes) breaks it. > > It will take a few hours, but I'll try to find out which one. Checking flag "extra" is the one.
[Bug preprocessor/94667] GCC duplicates prerequisites when generating 'make' rules if headers are not in current directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94667 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why is that a problem? make handles multiple dependencies on the same file just fine.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org Known to work||9.3.0 Known to fail||10.0 Summary|[10 Regression][concepts] |[10 Regression][concepts] |incorrect concept |incorrect concept |evaluation with decltype, |evaluation with decltype, |plus internal error |plus internal error since ||r10-7554-gf1ad7bac76b66257 --- Comment #5 from Martin Liška --- Sorry, you are right. Reproduced now, the error started with r10-7554-gf1ad7bac76b66257.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 Martin Liška changed: What|Removed |Added Status|WAITING |NEW
[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #15 from Jonathan Wakely ---
Reopening. Modified version of g++.dg/eh/return1.C showing the remaining bug,
in the new i() function:
// PR c++/33799
// { dg-do run }
extern "C" void abort();
int c, d;
#if __cplusplus >= 201103L
#define THROWS noexcept(false)
#else
#define THROWS
#endif
struct X
{
X(bool throws) : throws_(throws) { ++c; }
X(const X& x) : throws_(x.throws_) { ++c; }
~X() THROWS
{
++d;
if (throws_) { throw 1; }
}
private:
bool throws_;
};
X f()
{
X x(true);
return X(false);
}
X g()
{
return X(true),X(false);
}
void h()
{
#if __cplusplus >= 201103L
[]{ return X(true),X(false); }();
#endif
}
X i()
{
try {
X x(true);
return X(false);
} catch(...) {}
return X(false);
}
int main()
{
try { f(); }
catch (...) {}
try { g(); }
catch (...) {}
try { h(); }
catch (...) {}
try { i(); }
catch (...) {}
if (c != d)
throw;
}
[Bug gcov-profile/94570] -fprofile-dir is broken on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Known to work||9.3.1 Status|ASSIGNED|RESOLVED Known to fail|9.3.0 | --- Comment #15 from Martin Liška --- Fixed now.
[Bug gcov-profile/94570] -fprofile-dir is broken on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Martin Liska : https://gcc.gnu.org/g:5c09a1b71bb96d1fd6488d040b65001807fd16c2 commit r9-8513-g5c09a1b71bb96d1fd6488d040b65001807fd16c2 Author: Martin Liska Date: Mon Apr 20 11:26:58 2020 +0200 Backport e9f799d25973fc38022c5ea71ed5a2bca58a847f Backport from mainline 2020-04-17 Martin Liska Jonathan Yong <10wa...@gmail.com> PR gcov-profile/94570 * ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM for CYGWIN. Backport from mainline 2020-04-17 Martin Liska Jonathan Yong <10wa...@gmail.com> PR gcov-profile/94570 * coverage.c (coverage_init): Use separator properly. Backport from mainline 2020-04-17 Martin Liska Jonathan Yong <10wa...@gmail.com> PR gcov-profile/94570 * filenames.h (defined): Do not define HAVE_DOS_BASED_FILE_SYSTEM for CYGWIN. Co-Authored-By: Jonathan Yong <10wa...@gmail.com>
[Bug tree-optimization/93674] [8/9 Regression] GCC eliminates conditions it should not, when strict-enums is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674 Richard Earnshaw changed: What|Removed |Added Resolution|FIXED |--- Summary|[8/9/10 Regression] GCC |[8/9 Regression] GCC |eliminates conditions it|eliminates conditions it |should not, when|should not, when |strict-enums is on |strict-enums is on Status|RESOLVED|REOPENED --- Comment #17 from Richard Earnshaw --- Has not been backported yet.
[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307 --- Comment #8 from Martin Liška --- @Kees: Any update on kernel side?
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #18 from Martin Liška --- The code in ipa_polymorphic_call_context::set_by_invariant seems fishy. It's there since the beginning: r5-3634-g6f8091fc3ed9d3cfa7a6dee7e9f9a34eb4308b2a. @Honza: Can you please take a look?
[Bug preprocessor/94667] GCC duplicates prerequisites when generating 'make' rules if headers are not in current directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94667 --- Comment #2 from Ivan Balevic --- Yes, you are correct, this issue doesn't affect the execution of 'make'. Nevertheless, I don't see a reason for GCC to duplicate prerequisites. Furthermore, it should at least be consistent regardless of involved -I flag.
[Bug middle-end/94120] [OpenACC] ICE in gimplify_adjust_omp_clauses_1 for 'declare' for variable outside scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94120 --- Comment #9 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:85d8c05a02bf7d1b256f806582a11e3fd8970a32 commit r10-7810-g85d8c05a02bf7d1b256f806582a11e3fd8970a32 Author: Tobias Burnus Date: Mon Apr 20 12:38:50 2020 +0200 Fix declare copyout in libgomp.oacc-c++/declare-pr94120.C Testing on the host does not make sense for 'declare copyout' for a same-scope stack-allocated variable. Once the copyout is done, the variable is gone. Hence, test the variable on the device. This can be revisit after the OpenACC semantic has been fixed; but with that fix, the test PASSes again with devices. PR middle-end/94120 * testsuite/libgomp.oacc-c++/declare-pr94120.C: Fix 'declare copy(out)' test case.
[Bug target/94396] [8/9/10 Regression] fp16 feature bits not passed on to assembler from Armv8.4-a and up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94396 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:910c610dcc220ed04123e4da59296457254d85d4 commit r9-8514-g910c610dcc220ed04123e4da59296457254d85d4 Author: Tamar Christina Date: Mon Apr 20 11:43:43 2020 +0100 AArch64: Fix options canonicanization for assembler It is currently impossible to use fp16 on any architecture higher than Armv8.3-a due to a bug in options canonization. This bug results in the fp16 flag not being emitted in the assembly when it should have been. This is caused by a complicated architectural requirement at Armv8.4-a. On Armv8.2-a and Armv8.3-a fp16fml is an optional extension and turning it on turns on both fp and fp16. However starting with Armv8.4-a fp16fml is mandatory if fp16 is available, otherwise it's optional. In short this means that to enable fp16fml the smallest option that needs to passed to the assembler is Armv8.4-a+fp16. The fix in this patch takes into account that an option may be on by default in an architecture, but that not all the bits required to use it are on by default in an architecture. In such cases the difference between the two are still emitted to the assembler. gcc/ChangeLog: PR target/94396 * common/config/aarch64/aarch64-common.c (aarch64_get_extension_string_for_isa_flags): Handle default flags. gcc/testsuite/ChangeLog: PR target/94396 * gcc.target/aarch64/options_set_11.c: New test. * gcc.target/aarch64/options_set_12.c: New test. * gcc.target/aarch64/options_set_13.c: New test. * gcc.target/aarch64/options_set_14.c: New test. * gcc.target/aarch64/options_set_15.c: New test. * gcc.target/aarch64/options_set_16.c: New test. * gcc.target/aarch64/options_set_17.c: New test. * gcc.target/aarch64/options_set_18.c: New test. * gcc.target/aarch64/options_set_19.c: New test. * gcc.target/aarch64/options_set_20.c: New test. * gcc.target/aarch64/options_set_21.c: New test. * gcc.target/aarch64/options_set_22.c: New test. * gcc.target/aarch64/options_set_23.c: New test. * gcc.target/aarch64/options_set_24.c: New test. * gcc.target/aarch64/options_set_25.c: New test. * gcc.target/aarch64/options_set_26.c: New test.
[Bug target/94396] [8/9/10 Regression] fp16 feature bits not passed on to assembler from Armv8.4-a and up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94396 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:b262ef0ed1628d88aa7a899fb3f93bcf3e51998e commit r8-10191-gb262ef0ed1628d88aa7a899fb3f93bcf3e51998e Author: Tamar Christina Date: Mon Apr 20 11:46:38 2020 +0100 AArch64: Fix options canonicanization for assembler It is currently impossible to use fp16 on any architecture higher than Armv8.3-a due to a bug in options canonization. This bug results in the fp16 flag not being emitted in the assembly when it should have been. This is caused by a complicated architectural requirement at Armv8.4-a. On Armv8.2-a and Armv8.3-a fp16fml is an optional extension and turning it on turns on both fp and fp16. However starting with Armv8.4-a fp16fml is mandatory if fp16 is available, otherwise it's optional. In short this means that to enable fp16fml the smallest option that needs to passed to the assembler is Armv8.4-a+fp16. The fix in this patch takes into account that an option may be on by default in an architecture, but that not all the bits required to use it are on by default in an architecture. In such cases the difference between the two are still emitted to the assembler. gcc/ChangeLog: PR target/94396 * common/config/aarch64/aarch64-common.c (aarch64_get_extension_string_for_isa_flags): Handle default flags. gcc/testsuite/ChangeLog: PR target/94396 * gcc.target/aarch64/options_set_11.c: New test. * gcc.target/aarch64/options_set_12.c: New test. * gcc.target/aarch64/options_set_13.c: New test. * gcc.target/aarch64/options_set_14.c: New test. * gcc.target/aarch64/options_set_15.c: New test. * gcc.target/aarch64/options_set_16.c: New test. * gcc.target/aarch64/options_set_17.c: New test. * gcc.target/aarch64/options_set_18.c: New test. * gcc.target/aarch64/options_set_19.c: New test. * gcc.target/aarch64/options_set_20.c: New test. * gcc.target/aarch64/options_set_21.c: New test. * gcc.target/aarch64/options_set_22.c: New test. * gcc.target/aarch64/options_set_23.c: New test. * gcc.target/aarch64/options_set_24.c: New test. * gcc.target/aarch64/options_set_25.c: New test. * gcc.target/aarch64/options_set_26.c: New test.
[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48311 [details]
> patch
>
> Note that apart from the possible bad impact on optimization when fixing this
> bug an actual fix is complicated by the custom "optimized" dependence
> analysis
> code in the loop invariant motion pass.
>
> A conservative "simple" patch would be the attached but that doesn't preserve
> store-motion for the following (because the LIM data dependence code doesn't
> care about stmt order):
>
> typedef int A;
> typedef float B;
>
> void __attribute__((noinline,noclone))
> foo(A *p, B *q, long unk)
> {
> for (long i = 0; i < unk; ++i) {
> q[i] = 42;
> *p = 1;
> }
> }
>
> usually this bug doesn't manifest itself but of course the fix will be
> experienced everywhere. Benchmarking the simple patch might reveal
> it's not an issue (but I doubt that...).
Which means a better approach might be to, in addition to the existing
dependence testing, verify we can sink the stores through all exits
(IIRC there is/was a similar bug involving ordering of stores sunk where we'd
have to preserve the order). There's again the difficult cases like
for ()
{
*p = 1;
q[i] = 42;
if (test)
*p = 2;
}
which we currently sink as
for ()
{
p_1 = 1;
q[i] = 42;
if (test)
p_1 = 2;
}
*p = p_1;
if we want to preserve all sinking we'd have to replay all [possibly
aliased] stores - again more difficult when the store we sink is
in the latch (or when multiple exits are involved). For the above
example do
for ()
{
p_1 = 1;
q[i] = 42;
if (test)
p_1 = 2;
}
*p = p_1;
q[i] = 42;
if (test)
*p = p_1;
with scanning for valid re-orderings starting from all exits we want
to consider sinking two stores that cannot be reordered.
Or we want to re-think the whole store-motion data dependence code.
[Bug c++/94140] [OpenACC] declare directive in class currently rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94140 --- Comment #2 from Tobias Burnus --- PR 94120 also needs to be revisited once the semantic of same-scope has been clarified at OpenACC. See also: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543709.html It looks as if the current check is fine for 'device_resident' and 'link' but wrong for all others, but that has to be clarified at OpenACC spec level.
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #7 from Segher Boessenkool --- Can r94 or r93 be NaN there? (I should build an aarch64 compiler... takes almost a day though :-) )
[Bug tree-optimization/93674] [8/9 Regression] GCC eliminates conditions it should not, when strict-enums is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674 --- Comment #18 from bin cheng --- (In reply to Richard Earnshaw from comment #17) > Has not been backported yet. Will do it. Thanks
[Bug fortran/91800] ICE in gfc_code2string(): Bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91800 --- Comment #4 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:38acc41d6d761b635123eefa93743b9139debbae commit r10-7811-g38acc41d6d761b635123eefa93743b9139debbae Author: Steve Kargl Date: Mon Apr 20 13:21:38 2020 +0200 PR 91800 - reject Hollerith constants as type initializer. 2020-04-20 Steve Kargl Thomas Koenig PR fortran/91800 * decl.c (variable_decl): Reject Hollerith constants as type initializer. 2020-04-20 Steve Kargl Thomas Koenig PR fortran/91800 * gfortran.dg/hollerith_9.f90: New test.
[Bug fortran/91800] ICE in gfc_code2string(): Bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91800 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Koenig --- Patch committed. Thanks for the bug report and for the patch!
[Bug c/94669] New: libcc1/libcc1.cc; 2 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 Bug ID: 94669 Summary: libcc1/libcc1.cc; 2 * minor performance problem Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- cppcheck says: 1. trunk.git/libcc1/libcc1.cc:112:57: performance: Function parameter 'driver_filename' should be passed by const reference. [passedByValue] Source code is compiler_driver_filename (libcc1 *self, std::string driver_filename) Maybe better code compiler_driver_filename (libcc1 *self, const std::string & driver_filename) 2. trunk.git/libcc1/libcc1.cc:96:56: performance: Function parameter 'triplet_regexp' should be passed by const reference. [passedByValue] compiler_driver_filename (libcc1 *self, std::string driver_filename) Duplicate. In a similar position: trunk.git/libcc1/libcp1.cc:114:57: performance: Function parameter 'driver_filename' should be passed by const reference. [passedByValue] and trunk.git/libcc1/libcp1.cc:98:56: performance: Function parameter 'triplet_regexp' should be passed by const reference. [passedByValue]
[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 --- Comment #2 from Avi Kivity --- Maybe we can have a new flag -mcx16all that assumes that all code using 16-byte CAS is compiled with the flag.
[Bug rtl-optimization/94665] missed minmax optimization opportunity for if/else structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94665 --- Comment #8 from z.zhanghaijian at huawei dot com --- (In reply to Segher Boessenkool from comment #7) > Can r94 or r93 be NaN there? > > (I should build an aarch64 compiler... takes almost a day though :-) ) Yes, r94 and r93 are function arguments, there is no limit in the example, it may be NaN. -funsafe-math-optimizations allow optimization assume that arguments are not NaNs like -ffinite-math-only？
[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #24 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48311 [details]
> patch
>
> Note that apart from the possible bad impact on optimization when fixing this
> bug an actual fix is complicated by the custom "optimized" dependence
> analysis
> code in the loop invariant motion pass.
>
> A conservative "simple" patch would be the attached but that doesn't preserve
> store-motion for the following (because the LIM data dependence code doesn't
> care about stmt order):
>
> typedef int A;
> typedef float B;
>
> void __attribute__((noinline,noclone))
> foo(A *p, B *q, long unk)
> {
> for (long i = 0; i < unk; ++i) {
> q[i] = 42;
> *p = 1;
> }
> }
>
> usually this bug doesn't manifest itself but of course the fix will be
> experienced everywhere. Benchmarking the simple patch might reveal
> it's not an issue (but I doubt that...).
One case like this is gcc.dg/tree-ssa/pr81744.c which fails after the patch
because we do not SM the global induction variable update which is already
last before exit. Similarly gcc.dg/graphite/pr80906.c and
gcc.target/i386/pr64110.c - that's all of the GCC testsuite fallout on x86_64.
I do not
think those regressions are acceptable on its own but I'll throw the patch
on SPEC CPU 2006 to get more data (I fear even a solution preserving the
cited regressions will regress actual code too much).
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 David Binderman changed: What|Removed |Added CC||jan.kratochvil at redhat dot com --- Comment #1 from David Binderman --- >From git blame, adding original author.
[Bug fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93364 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:aeb430aadc3c91af50095be924365981d85f8b8a commit r10-7813-gaeb430aadc3c91af50095be924365981d85f8b8a Author: Harald Anlauf Date: Mon Apr 20 14:20:19 2020 +0200 PR fortran/93364 - ICE in gfc_set_array_spec, at fortran/array.c:879 Add missing check in gfc_set_array_spec for sum of rank and corank to not exceed GFC_MAX_DIMENSIONS. 2020-04-20 Harald Anlauf PR fortran/93364 * array.c (gfc_set_array_spec): Check for sum of rank and corank not exceeding GFC_MAX_DIMENSIONS. 2020-04-20 Harald Anlauf PR fortran/93364 * gfortran.dg/pr93364.f90: New test.
[Bug target/94530] [9/10 Regression] ICE: SIGSEGV in rhs_regno (rtl.h:1924) with -Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:5e022e3b3f7b2109f47fefffd6368fe3d378bdaa commit r9-8515-g5e022e3b3f7b2109f47fefffd6368fe3d378bdaa Author: Andrea Corallo Date: Thu Apr 16 09:55:51 2020 +0200 aarch64: backport fix for PR target/94530 gcc/ChangeLog 2020-04-16 Andrea Corallo Backport from mainline. 2020-04-15 Andrea Corallo Backport from mainline. 2020-04-09 Andrea Corallo PR target/94530 * gcc.target/aarch64/pr94530.c: New test.
[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 --- Comment #25 from Pascal Cuoq --- Would it be reasonable to have three settings for -fstrict-aliasing, rather then the current two? - off - strict - assume-no-reuse (I would let you find a better name for the third one.) It seems to me that the wrong transformation corresponds to code patterns that a C developers familiar with the compiled code would be able to tell are used or not in the compiled code: repurposing of dynamically allocated memory and access to a union through pointers. (Note: in https://trust-in-soft.com/wp-content/uploads/2017/01/vmcai.pdf we remarked that GCC is particularly user-friendly in both documenting what uses of unions are compatible with -fstrict-aliasing and in sticking to the documented behavior. The place in the GCC documentation where this is documented would already explain a lot of the context for explaining the difference between the strict and assume-no-reuse settings.) Even if you set -fstrict-aliasing=assume-no-reuse as implied by -O2, this would still be a much welcome improvement compared to the current situation. GCC would continue to be compared fairly in benchmarks to other compilers that have the same approximation, most programs would continue to work fine because they do not rely on the dangerous patterns, and those that rely on the dangerous pattern would have a way out. It would be vaguely comparable to -ffast-math. One possible psychological drawback may be that if the “strict” option exists, some users may ask why GCC does not stick to it in the -On settings.
[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 --- Comment #26 from rguenther at suse dot de --- On Mon, 20 Apr 2020, pascal_cuoq at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 > > --- Comment #25 from Pascal Cuoq --- > Would it be reasonable to have three settings for -fstrict-aliasing, rather > then the current two? > > - off > - strict > - assume-no-reuse > > (I would let you find a better name for the third one.) I think it's clearly a GCC bug we need to fix, for users we might want to give more control in telling the compiler about loop dependences. So no, I don't like another -f[no-]strict-* option.
[Bug fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93364 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f32d02e223d49a5d9db295969da9d2c04dc9d086 commit r9-8516-gf32d02e223d49a5d9db295969da9d2c04dc9d086 Author: Harald Anlauf Date: Mon Apr 20 14:45:10 2020 +0200 PR fortran/93364 - ICE in gfc_set_array_spec, at fortran/array.c:879 Backport from mainline. 2020-04-20 Harald Anlauf Add missing check in gfc_set_array_spec for sum of rank and corank to not exceed GFC_MAX_DIMENSIONS. PR fortran/93364 * array.c (gfc_set_array_spec): Check for sum of rank and corank not exceeding GFC_MAX_DIMENSIONS. PR fortran/93364 * gfortran.dg/pr93364.f90: New test.
[Bug fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93364 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed for gcc-10 and backported to 9-branch. Thanks for the report.
[Bug rtl-optimization/94670] New: ICE in extract_insn, at recog.c:2310 on s390x-linux-gnu with -march=z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670
Bug ID: 94670
Summary: ICE in extract_insn, at recog.c:2310 on
s390x-linux-gnu with -march=z13
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
Seen on the gcc-8, gcc-9 branches and trunk, worked around with -O2.
$ cat hb-set.ii
struct f {
long operator[](int i) { return c.d[i]; }
struct {
long d[sizeof 0];
} c;
};
template struct o {
int g;
e h;
e &operator[](int i) {
e *j;
unsigned b = i;
j = &h;
return j[b];
}
};
int k, m;
unsigned l;
struct n {
struct C {
int t() {
int p = l = sizeof(d);
for (unsigned b = 0; b < l; b++) {
long q = d[b], d = q;
k = __builtin_popcountl(d);
p += k;
}
return p;
}
f d;
};
o pages;
int m_fn1() {
unsigned a = pages.g;
for (unsigned b = 0; b < a; b++)
m += pages[b].t();
return m;
}
} r;
void s() { r.m_fn1(); }
$ s390x-linux-gnu-g++ -c -mbackchain -march=z13 -mzarch -O3 -Wall
-Wno-strict-aliasing -std=gnu++98 -fno-stack-protector hb-set.ii
hb-set.ii: In function ‘void s()’:
hb-set.ii:40:23: error: unrecognizable insn:
40 | void s() { r.m_fn1(); }
| ^
(insn 109 108 110 7 (set (reg:V16QI 1302)
(unspec:V16QI [
(subreg:V16QI (subreg:V2DI (reg:V16QI 1300) 0) 0)
] UNSPEC_POPCNT)) "hb-set.ii":25:32 -1
(nil))
during RTL pass: vregs
hb-set.ii:40:23: internal compiler error: in extract_insn, at recog.c:2310
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug rtl-optimization/94670] ICE in extract_insn, at recog.c:2310 on s390x-linux-gnu with -march=z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670 --- Comment #1 from Matthias Klose --- and works with -march=zEC12
[Bug c++/94671] New: Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
Bug ID: 94671
Summary: Wrong behavior with operator new overloading when
using O2 for optimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@odd-e.com
Target Milestone: ---
This bug is a similar bug as an earlier reported in clang:
https://bugs.llvm.org/show_bug.cgi?id=15541
When having the overloaded new operator defined in other cpp or in a lib, g++
with O2 optimizes a new operation without assignment (or assignment to local or
static), and it will not call the overloaded new at all.
The following code will reproduce the problem.
---
test.cpp:
---
#include
#define CHECK(expect, actual) std::cout << "EXPECT:" << expect <<
"\tACTUAL:"<
#include
#include
extern bool newCalled;
bool newCalled = false;
void* operator new (size_t size) throw (std::bad_alloc)
{
newCalled = true;
return malloc(size);
}
---
I know this is an optimization (it doesn't happen with -O0)... but it does
break the C++ standard.
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 --- Comment #14 from Jakub Jelinek --- Created attachment 48312 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48312&action=edit gcc10-pr94516.patch Untested patch for the missed-optimization part, with this we get the same assembly like gcc 9 back for -O2 -fpie.
[Bug target/94556] FAIL: nptl/tst-thread-exit-clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94556 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:47ea8616d4f5fee875e0849e393575e00def5894 commit r9-8517-g47ea8616d4f5fee875e0849e393575e00def5894 Author: H.J. Lu Date: Mon Apr 20 05:51:29 2020 -0700 x86: Restore the frame pointer in word_mode We must restore the frame pointer in word_mode for eh_return epilogues since the upper 32 bits of RBP register can have any values. Tested on Linux/x32 and Linux/x86-64. Backport from master PR target/94556 * config/i386/i386.c (ix86_expand_epilogue): Restore the frame pointer in word_mode for eh_return epilogues. (cherry picked from commit efc1f3577f38bb213b313661c025ac965baee953)
[Bug target/94556] FAIL: nptl/tst-thread-exit-clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94556 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:472c004fcd13e429dad7d1b829d21e26d24e39a4 commit r8-10192-g472c004fcd13e429dad7d1b829d21e26d24e39a4 Author: H.J. Lu Date: Mon Apr 20 05:51:29 2020 -0700 x86: Restore the frame pointer in word_mode We must restore the frame pointer in word_mode for eh_return epilogues since the upper 32 bits of RBP register can have any values. Tested on Linux/x32 and Linux/x86-64. Backport from master PR target/94556 * config/i386/i386.c (ix86_expand_epilogue): Restore the frame pointer in word_mode for eh_return epilogues. (cherry picked from commit efc1f3577f38bb213b313661c025ac965baee953)
[Bug rtl-optimization/94670] ICE in extract_insn, at recog.c:2310 on s390x-linux-gnu with -march=z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670 Andreas Krebbel changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-04-20 Status|UNCONFIRMED |NEW --- Comment #2 from Andreas Krebbel --- GCC BZ: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666 LTC BZ: https://bugzilla.linux.ibm.com/show_bug.cgi?id=185158
[Bug target/94556] FAIL: nptl/tst-thread-exit-clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94556 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.5 --- Comment #11 from H.J. Lu --- Fixed for GCC 10, GCC 9.4 and GCC 8.5.
[Bug target/94666] S/390: ICE on vectorized popcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666 Andreas Krebbel changed: What|Removed |Added CC||doko at debian dot org --- Comment #2 from Andreas Krebbel --- *** Bug 94670 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/94670] ICE in extract_insn, at recog.c:2310 on s390x-linux-gnu with -march=z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670 Andreas Krebbel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andreas Krebbel --- Mark as duplicate *** This bug has been marked as a duplicate of bug 94666 ***
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #1 from Jonathan Wakely --- No, this conforms to the standard. See [expr.new] > An implementation is allowed to omit a call to a replaceable global allocation > function (17.6.2.1, 17.6.2.2). When it does so, the storage is instead > provided by the implementation or provided by extending the allocation > of another new-expression.
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #2 from Bas Vodde --- Oh wow, does this mean that it is the choice of the compiler to actually call an overloaded operator new ? That is interesting. Thanks. I'd still consider it highly surprising behavior, at least it was for me...
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #3 from Richard Biener --- The question is whether the standard allows eliding of the side-effect setting newCalled to true.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #19 from Leo Yuriev --- (In reply to CVS Commits from comment #4) > The master branch has been updated by Richard Biener : > > https://gcc.gnu.org/g:a64468a3034dd8e2d0794a5be84b8da544ffe2c3 > > commit r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3 > Author: Richard Biener > Date: Fri Apr 17 09:19:32 2020 +0200 > > fix PVS studio reported bugs > > 2020-04-17 Richard Biener [...] > * dwarf2out.c (dw_val_equal_p): Fix pasto in > dw_val_class_vms_delta comparison. > * optabs.c (expand_binop_directly): Fix pasto in commutation [...] Seems the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051 should be closed as fixed.
[Bug other/80051] gcc/dwarf2out.c: PVS-Studio: V501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Fixed with r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 80051, which changed state. Bug 80051 Summary: gcc/dwarf2out.c: PVS-Studio: V501 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #4 from Bas Vodde --- The newCalled to true in the example was the simplest way to show the behavior. This bug came up in a open source project called CppuTest. This has the functionality to detect memory leaks and does so by overloading the operator new. For each operator new, it keeps accounting information. When an operator new gets optimized by the compiler, the framework can't keep track of the accounting information and the delete call will report that non-allocated memory was deleted. I assume this is an useful and perfectly legit way of overloading operator new/delete. This behavior was caught when running the automated test of the framework, which failed in the debian build when updating to gcc10: https://people.debian.org/~doko/logs/gcc10-20200225/cpputest_3.8-7_unstable_gcc10.log
[Bug ipa/94582] [10 Regression] ICE: verify_cgraph_node failed (error: invalid calls_comdat_local flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94582 --- Comment #2 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:48c82310947355665d628d4d1c8e736df9987574 commit r10-7814-g48c82310947355665d628d4d1c8e736df9987574 Author: Jan Hubicka Date: Mon Apr 20 15:25:50 2020 +0200 Fix ICE on invalid calls_comdat_local flag [pr94582] PR ipa/94582 * tree-inline.c (optimize_inline_calls): Recompute calls_comdat_local flag. * g++.dg/torture/pr94582.C: New test.
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #5 from Bas Vodde ---
In the case we found this, it mostly uses the overload for accounting and thus
it doesn't cause a serious problem ('just' a test failure).
If you use the overloaded new/delete for providing your own memory management,
then this would potentially cause a serious problems.
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #6 from Jakub Jelinek --- Well, the compiler shouldn't optimize away the allocation and not the deallocation or vice versa, it needs to either optimize away allocation and all corresponding deallocations, or none of that. There were some bugs on the GCC side, but 20200225 snapshot is very old, you should try something newer, last related fix is from 4 days ago.
[Bug c++/94546] [10 Regression] unimplemented: unexpected AST of kind nontype_argument_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94546 Richard Biener changed: What|Removed |Added Known to work||9.3.0 --- Comment #3 from Richard Biener --- Works with GCC 9.3 with -std=c++2a -fconcepts (w/o -fconcepts it warns)
[Bug c++/94549] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549 Richard Biener changed: What|Removed |Added Known to work||9.3.0 --- Comment #2 from Richard Biener --- Works with GCC 9.3 but only with additionally specifying -fconcepts
[Bug ipa/94582] [10 Regression] ICE: verify_cgraph_node failed (error: invalid calls_comdat_local flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94582 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Assuming fixed.
[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583 Richard Biener changed: What|Removed |Added Priority|P1 |P2 --- Comment #3 from Richard Biener --- While it is a regression on the development "branch" it is a rejects-valid (not implemented in GCC 9) -> ice-on-valid "regression" only as far as the GCC 10 release is concerned. So definitely not release critical.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #13 from Nathan Sidwell --- Created attachment 48313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48313&action=edit testing shim
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #7 from Jonathan Wakely --- (In reply to Richard Biener from comment #3) > The question is whether the standard allows eliding of the side-effect > setting newCalled to true. It does. That side effect happens inside a replaceable global allocation function. The compiler is allowed to optimise away calls to replaceable global allocation functions.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Nathan Sidwell --- Fixed: * a6f400239d7 2020-04-20 | c++: tpl-tpl-parms are not canonicalizable types [pr94454] (HEAD -> master, origin/master, origin/HEAD) [Nathan Sidwell] * 7fcb93431ef 2020-04-20 | c++: Expr pack expansion equality [pr94454] [Nathan Sidwell] * aa576f2a860 2020-04-20 | c++: Template argument hashing [pr94454] [Nathan Sidwell]
[Bug c++/94592] [10 Regression] ICE in non-type template parameter with constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592 Richard Biener changed: What|Removed |Added Known to work||9.3.0 --- Comment #9 from Richard Biener --- Indeed works with GCC 9.
[Bug fortran/94672] New: gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672 Bug ID: 94672 Summary: gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’ Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gcc at abeckmann dot de Target Milestone: --- Created attachment 48314 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48314&action=edit failing testcase This is a regression in gfortran-10 (reproduced in GNU Fortran (GCC) 10.0.1 20200420 (experimental) built from git master): gfortran-master -Wall -fopenmp -c gf10bug.f90 gf10bug.f90:10:0: 10 |IF (PRESENT(array)) THEN | Error: ‘array’ not specified in enclosing ‘parallel’ gf10bug.f90:10:0: Error: enclosing ‘parallel’ But 'array' *is* 'shared': !$OMP PARALLEL DO DEFAULT(none) SHARED(array,n) PRIVATE(i) DO i = 1,n IF (PRESENT(array)) THEN That code is accepted by gfortran <= 9, Flang, Intel, PGI.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #48 from ktkachov at gcc dot gnu.org ---
(In reply to CVS Commits from comment #45)
> The master branch has been updated by Fritz Reese :
>
> https://gcc.gnu.org/g:57391ddaf39f7cb85825c32e83feb1435889da51
>
> commit r10-7603-g57391ddaf39f7cb85825c32e83feb1435889da51
> Author: Fritz Reese
> Date: Tue Apr 7 11:59:36 2020 -0400
>
> Fix PR fortran/93871 and re-implement degree-valued trigonometric
> intrinsics.
>
> 2020-04-01 Fritz Reese
> Steven G. Kargl
>
> gcc/fortran/ChangeLog
>
> PR fortran/93871
> * gfortran.h (GFC_ISYM_ACOSD, GFC_ISYM_ASIND, GFC_ISYM_ATAN2D,
> GFC_ISYM_ATAND, GFC_ISYM_COSD, GFC_ISYM_COTAND, GFC_ISYM_SIND,
> GFC_ISYM_TAND): New.
> * intrinsic.c (add_functions): Remove check for flag_dec_math.
> Give degree trig functions simplification and name resolution
> functions (e.g, gfc_simplify_atrigd () and gfc_resolve_atrigd
> ()).
> (do_simplify): Remove special casing of degree trig functions.
> * intrinsic.h (gfc_simplify_acosd, gfc_simplify_asind,
> gfc_simplify_atand, gfc_simplify_cosd, gfc_simplify_cotand,
> gfc_simplify_sind, gfc_simplify_tand, gfc_resolve_trigd2): Add
> new
> prototypes.
> (gfc_simplify_atrigd, gfc_simplify_trigd, gfc_resolve_cotan,
> resolve_atrigd): Remove prototypes of deleted functions.
> * iresolve.c (is_trig_resolved, copy_replace_function_shallow,
> gfc_resolve_cotan, get_radians, get_degrees, resolve_trig_call,
> gfc_resolve_atrigd, gfc_resolve_atan2d): Delete functions.
> (gfc_resolve_trigd, gfc_resolve_trigd2): Resolve to library
> functions.
> * simplify.c (rad2deg, deg2rad, gfc_simplify_acosd,
> gfc_simplify_asind,
> gfc_simplify_atand, gfc_simplify_atan2d, gfc_simplify_cosd,
> gfc_simplify_sind, gfc_simplify_tand, gfc_simplify_cotand): New
> functions.
> (gfc_simplify_atan2): Fix error message.
> (simplify_trig_call, gfc_simplify_trigd, gfc_simplify_atrigd,
> radians_f): Delete functions.
> * trans-intrinsic.c: Add LIB_FUNCTION decls for sind, cosd, tand.
> (rad2deg, gfc_conv_intrinsic_atrigd, gfc_conv_intrinsic_cotan,
> gfc_conv_intrinsic_cotand, gfc_conv_intrinsic_atan2d): New
> functions.
> (gfc_conv_intrinsic_function): Handle ACOSD, ASIND, ATAND, COTAN,
> COTAND, ATAN2D.
> * trigd_fe.inc: New file. Included by simplify.c to implement
> simplify_sind, simplify_cosd, simplify_tand with code common to
> the
> libgfortran implementation.
>
> gcc/testsuite/ChangeLog
>
> PR fortran/93871
> * gfortran.dg/dec_math.f90: Extend coverage to real(10) and
> real(16).
> * gfortran.dg/dec_math_2.f90: New test.
> * gfortran.dg/dec_math_3.f90: Likewise.
> * gfortran.dg/dec_math_4.f90: Likewise.
> * gfortran.dg/dec_math_5.f90: Likewise.
>
> libgfortran/ChangeLog
>
> PR fortran/93871
> * Makefile.am, Makefile.in: New make rule for intrinsics/trigd.c.
> * gfortran.map: New routines for {sind, cosd, tand}X{r4, r8,
> r10, r16}.
> * intrinsics/trigd.c, intrinsics/trigd_lib.inc,
> intrinsics/trigd.inc:
> New files. Defines native degree-valued trig functions.
I think this broke the build for bare-metal (newlib) targets like
aarch64-none-elf:
libgfortran/intrinsics/trigd_lib.inc:55:56: error: implicit declaration of
function 'copysignl' [-Werror=implicit-function-declaration]
55 | #define mpfr_copysign(rop, op1, op2, rnd) rop = SUFFIX(copysign)((op1),
(op2))
|^~~~
I think newlib doesn't support long double functions well so likely doesn't
have copysignl. Is there some way this use can be conditionalised on library
support?
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Jonathan Wakely --- (In reply to Bas Vodde from comment #4) > When an operator new gets optimized by the compiler, the framework can't > keep track of the accounting information and the delete call will report > that non-allocated memory was deleted. Obviously memory that wasn't returned from your replacement operator new can't be passed to your replacement operator delete. If calls to operator new are combined into fewer calls, or elided completely, then the compiler is also responsible for combining/eliding the corresponding calls to operator delete. Read the proposal referenced in the Clang bug you linked to: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.html I don't see any bug with current GCC 10.0.1 snapshots. If I provide a replacement operator delete then it is only called once, with a pointer that was returned by the single call to operator new.
