[Bug tree-optimization/55869] different bit shift/or optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55869 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- This is actually already fixed for GCC 11 by the patch which fixed PR 97690 and is really a dup of it. *** This bug has been marked as a duplicate of bug 97690 ***
[Bug tree-optimization/97690] (cond ? 2 : 0) is not optimized to int(cond) << 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97690 Andrew Pinski changed: What|Removed |Added CC||pawel_sikora at zoho dot com --- Comment #6 from Andrew Pinski --- *** Bug 55869 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195 Andrew Pinski changed: What|Removed |Added Depends on||25290 CC||pinskia at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Andrew Pinski --- Mine, After PR 25290, the below match.pd pattern will just work :). (In reply to Marc Glisse from comment #3) > and something that could be auto-generated from a pattern like: > (cond (ne @0 0) (negate @0) 0) -> (negate @0) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 [Bug 25290] PHI-OPT could be rewritten so that is uses match
[Bug bootstrap/97499] build dos cross compiler ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97499 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- No feedback in over 6 months so closing.
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 Andrew Pinski changed: What|Removed |Added Component|bootstrap |target Summary|/test/gnu/gcc/objdir/gcc/in |[12 Regression] |clude-fixed/stdlib.h:291:8: |/test/gnu/gcc/objdir/gcc/in |internal compiler error: in |clude-fixed/stdlib.h:291:8: |from_mode_char, at |internal compiler error: in |attribs.h:304 |from_mode_char, at ||attribs.h:304 Target Milestone|--- |12.0 Keywords||build, ice-on-valid-code
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734
--- Comment #1 from Andrew Pinski ---
/* The character codes corresponding to all the access modes. */
static constexpr char mode_chars[5] = { '-', 'r', 'w', 'x', '^' };
Is this after building stage 1 or after building stage 2 ?
[Bug tree-optimization/100732] [11/12 Regression] ICE with -Wall: in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.c:824 since r11-959-gb825a22890740f34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100732 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|ICE with -Wall: in |[11/12 Regression] ICE with |ao_ref_init_from_ptr_and_ra |-Wall: in |nge, at |ao_ref_init_from_ptr_and_ra |tree-ssa-alias.c:824|nge, at ||tree-ssa-alias.c:824 since ||r11-959-gb825a22890740f34 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Last reconfirmed||2021-05-24 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r11-959-gb825a22890740f34.
[Bug c++/100737] New: g++ segfaults in template substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100737
Bug ID: 100737
Summary: g++ segfaults in template substitution
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: henrik.nortamo at csc dot fi
Target Milestone: ---
Created attachment 50860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50860&action=edit
version and configuration information for all the gcc versions for which the
issue has been observed.
The following code crashes g++, when compiled with
g++ min.cpp
min.cpp
"""
template using __bool_constant=int;
template
struct duration {
static constexpr int fun()
{
return 0;
}
template
using __is_harmonic
= __bool_constant<(&duration::fun)()>;
template
static constexpr __is_harmonic<_P2> a=55;
};
int main(){
duration g;
return g.a;
}
"""
Error produced is:
"""
min.cpp: In substitution of 'template template using
__is_harmonic = __bool_constant::fun()> [with _Period2 = _P2; R =
R]':
min.cpp:15:43: required from here
min.cpp:13:43: internal compiler error: Segmentation fault
13 | = __bool_constant<(&duration::fun)()>;
| ^~
0xc5e1af crash_signal
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/toplev.c:328
0x783e05 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/semantics.c:2587
0x752672 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:20191
0x763de4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:19274
0x763de4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:18886
0x768926 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:13225
0x7562cd tsubst(tree_node*, tree_node*, int, tree_node*)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:15184
0x761c43 tsubst_decl
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:14641
0x76dff2 instantiate_template_1
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:20947
0x756414 instantiate_template(tree_node*, tree_node*, int)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:21004
0x756414 instantiate_alias_template
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:21042
0x756414 tsubst(tree_node*, tree_node*, int, tree_node*)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:15185
0x76067f lookup_template_class_1
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:9860
0x760d5c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/pt.c:10136
0x783a6d finish_template_type(tree_node*, tree_node*, int)
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/semantics.c:3408
0x72ad1f cp_parser_template_id
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/parser.c:16750
0x72af8c cp_parser_class_name
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/parser.c:23727
0x727c31 cp_parser_qualifying_entity
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/parser.c:6780
0x727c31 cp_parser_nested_name_specifier_opt
/local_scratch/build/spack-stage/nortamoh/spack-stage-gcc-10.3.0-viumsxju75yhxz3ydlpn5vquya47elp7/spack-src/gcc/cp/parser.c:6462
0x716d5a cp_parser_constructor_declarator_p
/local_scratch
[Bug c++/100737] g++ segfaults in template substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100737 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-24 Status|UNCONFIRMED |NEW Keywords||rejects-valid CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Likely started with r7-755-g23cb72663051cd3f, it was rejected before the revision. Note that clang accepts it.
[Bug middle-end/100738] New: Gimple failed to simplify ((v4si) ~a) < 0 ? c : d to ((v4si)a) >= 0 ? c : d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100738
Bug ID: 100738
Summary: Gimple failed to simplify ((v4si) ~a) < 0 ? c : d to
((v4si)a) >= 0 ? c : d
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*
cat test.c
typedef int v4si __attribute__((vector_size (16)));
typedef char v16qi __attribute__((vector_size (16)));
v4si
foo (v16qi a, v4si b, v4si c, v4si d)
{
return ((v4si)~a) < 0 ? c : d;
}
gcc -Ofast -mavx2
foo(char __vector(16), int __vector(4), int __vector(4), int __vector(4)):
vpcmpeqd%xmm1, %xmm1, %xmm1
vpxor %xmm1, %xmm0, %xmm0
vblendvps %xmm0, %xmm2, %xmm3, %xmm0
ret
it can be better with
vblendvps xmm0, xmm3, xmm2, xmm0
gimple failed to simplify ((v4si)~a) < 0 ? c : d to ((v4si)a) >= 0 ? c : d
With https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571056.html, i observe
rtl also won't simplify things like (vec_merge op1 op2 (lt (subreg （not op3) 0)
const0_rtx)) to (vec_merge op2 op1 (lt (subreg op3 0) const0_rtx))
[Bug c++/97938] [9/10 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:ba19b5543d31a76f494e76c32a548d70ac4d3cc1 commit r9-9553-gba19b5543d31a76f494e76c32a548d70ac4d3cc1 Author: Christophe Lyon Date: Mon May 24 07:35:44 2021 + c++: lambda pack init-capture within generic lambda In gcc-9-branch, the testsuite does not support the c++20 target selector: use c++2a instead, to avoid Dejagnu errors when running the testsuite. 2021-05-24 Christophe Lyon PR c++/97938 gcc/testsuite/ * g++.dg/cpp2a/lambda-pack-init6.C: Use c++2a target selector.
[Bug middle-end/100738] Gimple failed to simplify ((v4si) ~a) < 0 ? c : d to ((v4si)a) >= 0 ? c : d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100738 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- One thing is VCE<~A> should be converted to ~VCE which might allow ~B < 0 to be converted to B >= 0. On RTL, it might be useful to still simplify: (subreg （not op3) 0) To: (not (subreg op3 0))
[Bug c++/100739] New: Definition of function template doesn't match declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100739
Bug ID: 100739
Summary: Definition of function template doesn't match
declaration
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raffael at casagrande dot ch
Target Milestone: ---
The following code fails to compile with the newest gcc (gcc 12.0.0 20210523):
-
#include
#include
template
requires std::integral using debug_t = T;
template
struct X {
auto operator()(std::integral auto const& i) const ->
std::array,1>;
};
template
auto X::operator()(std::integral auto const& i) const ->
std::array,1>{
};
--
The error message is:
--
:13:6: error: no declaration matches 'std::array,
1> X::operator()(const auto:4&) const'
13 | auto X::operator()(std::integral auto const& i) const ->
std::array,1>{
| ^~~~
:9:8: note: candidate is: 'template template
requires integral std::array, 1>
X::operator()(const auto:3&) const'
9 | auto operator()(std::integral auto const& i) const ->
std::array,1>;
|^~~~
:8:8: note: 'struct X' defined here
8 | struct X {
|^
--
If we further simplify the code in one of the following ways, the problem
disappears:
1) If we remove the `std::array<...>`
2) If we remove the requires clause in the definition of debug_t
[Bug libstdc++/91383] C++17 should remove some library feature deprecated in C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383 --- Comment #8 from Jonathan Wakely --- Why don't you have CI that builds with other implementations, so that your co-workers are told automatically when they do that? It seems like you're expecting GCC to solve a non-technical problem with your team.
[Bug c++/100739] Definition of function template doesn't match declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100739 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-24 Ever confirmed|0 |1 Keywords||rejects-valid
[Bug bootstrap/100345] gcc 11.1 build "make -n install" fails linking gcov undefined reference to std::__throw_bad_array_new_length()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345 DocMAX changed: What|Removed |Added CC||forum at docmax dot tk --- Comment #6 from DocMAX --- check: https://github.com/xenia-project/xenia/issues/1819
[Bug libstdc++/91383] C++17 should remove some library feature deprecated in C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383 --- Comment #9 from Jonathan Wakely --- Some of the removed features are missing deprecated attributes, which should be fixed.
[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #1 from Bruno Haible --- (In reply to Paul Eggert from comment #0) > it is silently ignored for these languages, and I assume for any language > other than Ada. Confirmed: flag_trampolines matters only for calls with the ECF_BY_DESCRIPTOR bit set or CALL_EXPR_BY_DESCRIPTOR being true. Other than from the Ada backend, such calls are generated only from gimple nodes with subcode bit GF_CALL_BY_DESCRIPTOR set. GF_CALL_BY_DESCRIPTOR gets set through gimple_call_set_by_descriptor with argument true, and such calls exist only as consequence of tree nodes with CALL_EXPR_BY_DESCRIPTOR being true.
[Bug debug/100725] dwarf error with --whole-program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100725 --- Comment #2 from Dave Love --- (In reply to Jakub Jelinek from comment #1) > Those binutils are too old for dwarf5. > When the linker doesn't print any diagnostics, that isn't a big deal, but if > it needs to diagnose something and parse DWARF for that, you need 2.35 or > later. Does that mean you can't reasonably use 11 on most distributions without explicitly using -gdwarf-4? The release notes suggested to me it would still work, just not with full functionality somehow, and there is some adjustment for the binutils version. Is there some way to configure it to default to DWARF 4 other than, I guess, adding specs to treat -g as -gdwarf-4?
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 --- Comment #2 from Dave Love --- The manual says not to use -flto with -fwhole-program. Is that misleading? I checked self-built gfortran 10.2.0 again, and it definitely works for me without -flto on Debian 10, but it fails with Red Hat devtoolset's 10.2.1 on RHEL7. Odd...
[Bug middle-end/100733] -fcompare-debug failure for pr85213.c at -O1 -fdisable-tree-phiopt2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100733
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
I think this is another -gstatement-frontiers issue.
Without -g, during folding we are folding a COND_EXPR with x != 0, 0 and 1
arguments, but with -g it has a STATEMENT_LIST with DEBUG_BEGIN_STMT and x != 0
And that one e.g. in fold_ternary_loc doesn't satisfy truth_value_p, so the
/* Convert A ? 0 : 1 to !A. This prefers the use of NOT_EXPR
over COND_EXPR in cases such as floating point comparisons. */
if (integer_zerop (op1)
&& code == COND_EXPR
&& integer_onep (op2)
&& !VECTOR_TYPE_P (type)
&& truth_value_p (TREE_CODE (arg0)))
return fold_convert_loc (loc, type,
invert_truthvalue_loc (loc, arg0));
folding doesn't happen. In the past, most of the -gstatement-frontiers related
-fdebug-compare bugfixes were about making sure we gimplify it the same (and we
still have some unresolved (almost unresolvable) ones). But this shows whole
new category of bugs, the folders aren't really prepared for it, guess neither
generic-match.c (or its callers) or fold-const.c.
E.g. fold_ternary_loc starts with
if (op0)
{
arg0 = op0;
STRIP_NOPS (arg0);
}
shouldn't we use expr_single in that code somehow? Like after the STRIP_NOPS
add
do
{
tree narg0 = expr_single (arg0);
if (narg0 == arg0)
break;
arg0 = narg0;
STRIP_NOPS (arg0);
}
while (1);
perhaps in some macro/inline fn?
Or reconsider the DEBUG_BEGIN_STMT stuff.
[Bug tree-optimization/100740] New: wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740
Bug ID: 100740
Summary: wrong code at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This seems to be quite long-latent, impacting GCC 9.1 and later.
[636] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210524 (experimental) [master revision
dc084c487e9:bd7ae6b8ef8:9d38e096c5e3b1c2233b28d0e6ff8ee81517af56] (GCC)
[637] %
[637] % gcctk -O0 small.c; ./a.out
[638] %
[638] % gcctk -O1 small.c
[639] % ./a.out
Aborted
[640] %
[640] % cat small.c
unsigned a, b;
int main() {
unsigned c = 0;
for (a = 0; a < 2; a++)
for (b = 0; b < 2; b++)
if (++c < a)
__builtin_abort ();
return 0;
}
[Bug middle-end/100733] [8/9/10/11/12 Regression] -fcompare-debug failure for pr85213.c at -O1 -fdisable-tree-phiopt2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100733 Jakub Jelinek changed: What|Removed |Added Summary|-fcompare-debug failure for |[8/9/10/11/12 Regression] |pr85213.c at -O1|-fcompare-debug failure for |-fdisable-tree-phiopt2 |pr85213.c at -O1 ||-fdisable-tree-phiopt2 Target Milestone|--- |9.4 --- Comment #3 from Jakub Jelinek --- -gstatement-frontiers has been introduced in r8-5241-g8697bf9f46f36168ddba5752db582e673e3cbe8c or so.
[Bug c++/100741] New: [enhancement] Should show better error message if using ‘typedef’ instead of ‘using’.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100741 Bug ID: 100741 Summary: [enhancement] Should show better error message if using ‘typedef’ instead of ‘using’. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: cyp561 at gmail dot com Target Milestone: --- Test code: typedef Rng = std::mt19937_64; Actual error message: error: ‘Rng’ does not name a type Useful error message: error: Used ‘typedef’ with ‘using’ syntax 11 | typedef Rng = std::mt19937_64; ^~~ using
[Bug c++/100741] [enhancement] Should show better error message if using ‘typedef’ instead of ‘using’.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100741 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-24 Ever confirmed|0 |1 Keywords||diagnostic Status|UNCONFIRMED |NEW
[Bug c++/100741] [enhancement] Should show better error message if using ‘typedef’ instead of ‘using’.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100741
--- Comment #1 from Jonathan Wakely ---
Complete testcase:
struct X { };
typedef Rng = X;
[Bug tree-optimization/100740] [9/10/11/12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740 Jakub Jelinek changed: What|Removed |Added Summary|wrong code at -O1 and above |[9/10/11/12 Regression] |on x86_64-linux-gnu |wrong code at -O1 and above ||on x86_64-linux-gnu since ||r9-4145 Last reconfirmed||2021-05-24 Ever confirmed|0 |1 Target Milestone|--- |9.4 Status|UNCONFIRMED |NEW Priority|P3 |P2 CC||amker at gcc dot gnu.org, ||jakub at gcc dot gnu.org Version|unknown |11.1.1 --- Comment #1 from Jakub Jelinek --- Started with r9-4145-ga81e2c6240655f60a49c16e0d8bbfd2ba40bba51
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #2 from dave.anglin at bell dot net --- It's after stage1. I'm bisecting.
[Bug bootstrap/100345] gcc 11.1 build "make -n install" fails linking gcov undefined reference to std::__throw_bad_array_new_length()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345 --- Comment #7 from Jonathan Wakely --- (In reply to DocMAX from comment #6) > check: https://github.com/xenia-project/xenia/issues/1819 I don't think this is related, I think you're just linking wrong.
[Bug tree-optimization/100740] [9/10/11/12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740 bin cheng changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #2 from bin cheng --- mine. Sorry for the breakage.
[Bug c++/100742] New: False positive -Wignored-attributes with std::map and aligned(8) attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100742
Bug ID: 100742
Summary: False positive -Wignored-attributes with std::map and
aligned(8) attribute
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: liavonlida at gmail dot com
Target Milestone: ---
Check following code:
#include
template
class VecBase
{
typedef __attribute__((aligned(8))) Type value_data;
};
typedef std::map test_passed;
struct S1
{
inline void f1(VecBase p1) {}
};
typedef std::map test_failed;
int main()
{
return 0;
}
This leads to -Wignored-attributes warning:
:16:32: warning: ignoring attributes on template argument 'const
double' [-Wignored-attributes]
16 | typedef std::map test_failed;
|
This looks very strange and false positive.
Could be reproduced with GCC from 6 to 10 versions. GCC 11 is ok with this
code. Other compilers are also ok. I tried on https://godbolt.org/.
[Bug target/99960] MVE: Wrong code storing V2DI vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99960 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:32d4fa7d3792566b378ba0de003d50c0301de3a0 commit r11-8460-g32d4fa7d3792566b378ba0de003d50c0301de3a0 Author: Alex Coplan Date: Mon May 10 09:46:45 2021 +0100 arm: Fix wrong code with MVE V2DImode loads and stores [PR99960] As the PR shows, we currently miscompile V2DImode loads and stores for MVE. We're currently using 64-bit loads/stores, but need to be using 128-bit vector loads and stores. Fixed thusly. Some intrinsics tests were checking that we (incorrectly) used the 64-bit loads/stores: these have been updated. gcc/ChangeLog: PR target/99960 * config/arm/mve.md (*mve_mov): Simplify output code. Use vldrw.u32 and vstrw.32 for V2D[IF]mode loads and stores. gcc/testsuite/ChangeLog: PR target/99960 * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_s64.c: Update now that we're (correctly) using full 128-bit vector loads/stores. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_s64.c: Likewise. * gcc.target/arm/mve/intrinsics/vldrdq_gather_base_wb_z_u64.c: Likewise. * gcc.target/arm/mve/intrinsics/vuninitializedq_int.c: Likewise. * gcc.target/arm/mve/intrinsics/vuninitializedq_int1.c: Likewise. (cherry picked from commit 7596c762137f26f495b53ec93471273887832e31)
[Bug fortran/100743] New: Segmentation fault passing a polymorphic as an optional argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100743 Bug ID: 100743 Summary: Segmentation fault passing a polymorphic as an optional argument Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jhaiduce at gmail dot com Target Milestone: --- The following program crashes with a segmentation fault: ``` module my_exceptions implicit none type::error_container end type error_container type, abstract::base_exception end type base_exception type, extends(base_exception)::exception end type exception contains function new_exception() type(exception)::new_exception end function new_exception subroutine throw(status,exc) type(error_container), intent(inout), optional::status class(base_exception)::exc end subroutine throw subroutine test_throw(status) class(error_container), intent(inout), optional::status call throw(status,new_exception()) end subroutine test_throw end module my_exceptions program test use my_exceptions, ONLY: error_container, test_throw implicit none type(error_container)::status call test_throw() end program test ``` It works as expected when compiled with ifort. With gfortran it produces a segmentation fault. The problem occurs with multiple versions of gfortran (have tried 4.9.4, 7.5.0, 10.2.0, 10.3.0, 11.1.0). The segmentation fault does not occur if the optional status argument is declared as non-polymorphic type (i.e. ```type(error_container)``` instead of ```class(error_container)```).
[Bug gcov-profile/100744] New: Undefined symbol __gcov_flush when building with -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100744
Bug ID: 100744
Summary: Undefined symbol __gcov_flush when building with
-fprofile-arcs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: raffael at casagrande dot ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Trying to link the following simple program with `-fprofile-arcs` fails:
--
extern "C" void __gcov_flush();
int main() {
__gcov_flush();
}
--
Command line: `g++ source.cc -fprofile-arcs`
This used to work with gcc-10.3. It seems to be a regression of gcc-11.1/trunk?
[Bug target/100745] New: GCC generates suboptimal assembly from vector extensions on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100745 Bug ID: 100745 Summary: GCC generates suboptimal assembly from vector extensions on AArch64 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ajidala at gmail dot com Target Milestone: --- Created attachment 50861 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50861&action=edit The profile.c file minimal benchmark/test case As part of an attempt to make mpv's scaletempo2 audio filter faster, two vectorised implementations were written: The first one, mine, uses aarch64 intrinsics. It shows a 3.14x speedup on my test system, and is referred to as "new" or "nicolas" in the code. The second one, by haasn, also referred to as "niklas" in the code, uses GCC's vector extensions to automatically generate vectorised code for a wide variety of architectures. It shows a slower speedup on my system and another aarch64 test system (1.45x) but shows a much better speedup on x86_64 (>2x for generic, >10x for -march=native on this zen+ laptop thanks to avx). Clang, on the other hand compiles the vector extension code down to something more efficient than gcc, beating my intrinsics SIMD (even in absolute terms compared to gcc). I believe this is due to a bug in gcc making it produce subpar vector assembly on aarch64 in this case. Since we'd rather not keep platform specific vector code around in mpv, and clang's codegen is overall worse in non-vector code, we'd much appreciate it if someone could look into what gcc is tripping over here. Attached is the minimal microbenchmark profile.c, which needs no special options or includes aside from stdio so no .i file if that's alright. My test system is a cortex-a53 in-order core, though -mtune -march for that does not fix it, and the problem also exhibits itself on a cortex-a55 in-order core. The test was compiled with gcc -O3 -o profile profile.c, though it is worth noting that the pure C implementation performs much better under -O2 (possibly a separate bug) while both SIMD versions are largely unaffected by this. GCC Version: 10.2.0 Distribution: Arch Linux ARM Platform: ROCK64 with a RK3328 (4x Cortex A-53, 2GB RAM) The options used for building gcc can be found here, in build(): https://archlinuxarm.org/packages/aarch64/gcc/files/PKGBUILD I've looked at the disassembly of gcc trunk on godbolt, but it did not look significantly different enough to me to think this has already been fixed in trunk. If required, I can try building gcc trunk from source.
[Bug gcov-profile/100744] Undefined symbol __gcov_flush when building with -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100744 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Martin Liška --- Note that __gcov_flush() is not part of the provided API: https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html We only support __gcov_reset and __gcov_dump.
[Bug gcov-profile/100744] Undefined symbol __gcov_flush when building with -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100744 --- Comment #2 from Raffael Casagrande --- Oh, I didn't notice this change. Thanks for pointing this out!
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 --- Comment #15 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:0e3b3b77e13cac764a135a7118613c47686e0a62 commit r12-1016-g0e3b3b77e13cac764a135a7118613c47686e0a62 Author: Tobias Burnus Date: Mon May 24 16:50:51 2021 +0200 OpenMP/Fortran: Handle polymorphic scalars in data-sharing FIRSTPRIVATE [PR86470] gcc/fortran/ChangeLog: PR fortran/86470 * trans-expr.c (gfc_copy_class_to_class): Add unshare_expr. * trans-openmp.c (gfc_is_polymorphic_nonptr, gfc_is_unlimited_polymorphic_nonptr): New. (gfc_omp_clause_copy_ctor, gfc_omp_clause_dtor): Handle polymorphic scalars. libgomp/ChangeLog: PR fortran/86470 * testsuite/libgomp.fortran/class-firstprivate-1.f90: New test. * testsuite/libgomp.fortran/class-firstprivate-2.f90: New test. * testsuite/libgomp.fortran/class-firstprivate-3.f90: New test. gcc/testsuite/ChangeLog: PR fortran/86470 * gfortran.dg/gomp/class-firstprivate-1.f90: New test. * gfortran.dg/gomp/class-firstprivate-2.f90: New test. * gfortran.dg/gomp/class-firstprivate-3.f90: New test. * gfortran.dg/gomp/class-firstprivate-4.f90: New test.
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 --- Comment #16 from Tobias Burnus --- (In reply to Tobias Burnus from comment #14) > It looks as if the committed patch handles this specific testcase correctly, > however, there are still many issues with PRIVATE and FIRSTPRIVATE with > polymorphic list items. > > See PR99519 for the follow-up PR, which already contains a link to a > FIRSTPRIVATE patch (but not yet for PRIVATE). I forgot to update the PR of the commit of comment 15 to the follow-up PR...
[Bug fortran/99519] [OpenMP] PRIVATE/FIRSTPRIVATE with CLASS / polymorphic list items
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99519 --- Comment #1 from Tobias Burnus --- The patch was now committed as: commit r12-1016-g0e3b3b77e13cac764a135a7118613c47686e0a62 Author: Tobias Burnus Date: Mon May 24 16:50:51 2021 +0200 OpenMP/Fortran: Handle polymorphic scalars in data-sharing FIRSTPRIVATE [PR86470] (The PR is the original PR instead of the one of this follow-up PR.) To be done: Missing: * PRIVATE - which causes still ICEs, even though not for PR86470. → use dynamic type of var, apply default initializers * Polymorphic arrays not supported by FIRSTPRIVATE patch * Check that for TYPE (the patch was for CLASS), the default initializer is applied - and what about the finalizer?
[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537 --- Comment #16 from Ian Lance Taylor --- I have a patch for this.
[Bug c++/100746] New: NRVO should not introduce aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100746
Bug ID: 100746
Summary: NRVO should not introduce aliasing
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
struct NrvoPassed {
NrvoPassed() = default;
NrvoPassed(const NrvoPassed&);
NrvoPassed(NrvoPassed&&);
int i = 0;
};
auto test(int* data) {
NrvoPassed x;
*data = 3;
if (x.i != 0) __builtin_abort();
return x;
}
Resulting assembly contains call to `abort`:
test(int*):
mov DWORD PTR [rdi], 0
mov DWORD PTR [rsi], 3
mov edx, DWORD PTR [rdi]
test edx, edx
jne .L3
mov rax, rdi
ret
test(int*) [clone .cold]:
.L3:
push rax
call abort
Optimizer thinks that the value of `x.i` is aliased by `data`, however `data`
is a local variable and it's address could not leak before the object is
constructed.
Some other compilers already have the proposed optimization:
https://godbolt.org/z/aqdveadnE
Adding `__restrict` to `data` fixes the codegen:
test2(int*):
mov DWORD PTR [rdi], 0
mov rax, rdi
mov DWORD PTR [rsi], 3
ret
Probably `__restrict` should be always added to the storage address passed for
NRVO.
[Bug c++/100368] Missing guaranteed elision in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100368 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/100666] [9/10/11/12 Regression] warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; ...]', declared with at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 50862 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50862&action=edit gcc12-pr100666.patch Untested fix.
[Bug libgcc/61238] Getting Linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61238 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No feedback in almost 5 years and it has been over 7 years since this was filed without enough information on how to reproduce the bug so closing as invalid.
[Bug lto/81612] lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81612 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #7 from Andrew Pinski --- No feedback in almost 4 years and GCC 6.x is no longer supported. Just closing as a dup of bug 79760. *** This bug has been marked as a duplicate of bug 79760 ***
[Bug lto/79760] ICE in type_in_anonymous_namespace_p in ipa-utils.h:219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79760 Andrew Pinski changed: What|Removed |Added CC||vctrex at mailfence dot com --- Comment #8 from Andrew Pinski --- *** Bug 81612 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/81955] corrupted double-linked list (not small)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81955 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug other/78889] GCC fails to build due to graphite-dependences.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78889 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #4 from Andrew Pinski --- Closing as invalid as there has been no feedback in almost 4 years after saying there was a solution.
[Bug c/84187] -O0 fails inline assembly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84187 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug c++/84862] collect2: fatal error: lto-wrapper returned 1 exit status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84862 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Andrew Pinski --- No testcase provided in over 3 years so closing as invalid.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #6 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #5) > I think we want to fix both for-3.c and for-9.c similarly to > r11-2571-g916c7a201a9a1dc94f2c056a773826a26d1daca9 i.e. > #define DO_PRAGMA(x) _Pragma (#x) > #define OMPTEAMS DO_PRAGMA (omp target teams) > #define OMPFROM(v) DO_PRAGMA (omp target update from(v)) > #define OMPTO(v) DO_PRAGMA (omp target update to(v)) > and changing main not to do #pragma omp target teams reduction(|:err) When trying this, it (still) works as host fallback but offloading gives: 219 | OMPTO (a); for-2.h:219:1: error: variable '.omp_data_kinds.116' has been referenced in offloaded code but hasn't been marked to be included in the offloaded code 222 | OMPFROM (a); for-2.h:222:1: error: variable '.omp_data_sizes.118' has been referenced in offloaded code but hasn't been marked to be included in the offloaded code (And likewise for additional OMPTO/OMPFROM.)
[Bug c++/90217] Greater optimization of C++ Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90217 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed in GCC 10.x.
[Bug target/89694] Redundant code with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89694 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Andrew Pinski --- No testcase provided in over 2 years so closing as invalid.
[Bug target/88360] internal compiler error: in extract_insn, at recog.c 2343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88360 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Andrew Pinski --- No feedback in over 2 years so closing as invalid.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #7 from Jakub Jelinek ---
Guess that is because the functions that have #pragma omp target teams
directive in it are marked declare target to.
So, either we'd need to play with macros etc. to make sure that those functions
aren't declare target to but the ones with #pragma omp distribute are, or
better we should fix this. Will have a look tomorrow.
Basically this is about
#pragma omp declare target
void
foo (void)
{
int a = 0;
#pragma omp target map(tofrom:+a)
a++;
}
#pragma omp end declare target
int
main ()
{
foo ();
}
Encountering #pragma omp target (except for reverse-offload) in a target region
is undefined, but if it is never called from there and only from host routines,
we should compile/link it (even when we can just abort or whatever else if
called in the offloaded code).
[Bug libstdc++/100479] range adaptors handle cached iterators incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:46ed811bcb4b86a81ef3d78ea8cfffc6cd043144 commit r12-1018-g46ed811bcb4b86a81ef3d78ea8cfffc6cd043144 Author: Patrick Palka Date: Mon May 24 15:24:44 2021 -0400 libstdc++: Fix iterator caching inside range adaptors [PR100479] This fixes two issues with our iterator caching as described in detail in the PR. Since we recently added the __non_propagating_cache class template as part of r12-336 for P2328, this patch just rewrites the problematic _CachedPosition partial specialization in terms of this class template. For the offset partial specialization, it's safe to propagate the cached offset on copy/move, but we should still invalidate the cached offset in the source object on move. libstdc++-v3/ChangeLog: PR libstdc++/100479 * include/std/ranges (__detail::__non_propagating_cache): Move definition up to before that of _CachedPosition. Make base class _Optional_base protected instead of private. Add const overload for operator*. (__detail::_CachedPosition): Rewrite the partial specialization for forward ranges as a derived class of __non_propagating_cache. Remove the size constraint on the partial specialization for random access ranges. Add copy/move/copy-assignment/move-assignment members to the offset partial specialization for random access ranges that propagate the cached value but additionally invalidate it in the source object on move. * testsuite/std/ranges/adaptors/100479.cc: New test.
[Bug other/100747] New: Possibly Wrong Permissions in "liboffloadmic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747 Bug ID: 100747 Summary: Possibly Wrong Permissions in "liboffloadmic" Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: firasuke at gmail dot com Target Milestone: --- Hey there, I noticed that `liboffloadmic/configure' and `liboffloadmic/plugin/configure' lack execute permissions (`644' instead of `755'), and I was wondering if that was intended. Thanks for your time and effort.
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.3.1, 11.1.0, 12.0, ||8.5.0, 9.3.1 Known to work||9.2.0 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Dave Love from comment #2) > The manual says not to use -flto with -fwhole-program. Is that misleading? I guess the manual entry has a reason, but I do not know why the optimimzations implied by these options should not be combined. > I checked self-built gfortran 10.2.0 again, and it definitely works for me > without -flto on Debian 10, but it fails with Red Hat devtoolset's 10.2.1 on > RHEL7. Odd... I checked against gfortran 9.2.0, which works fine, whereas the current development version 9.3.1 fails too. The change likely happened in a newer developer version and was backported to the release branches.
[Bug c++/95298] [9/10/11/12 Regression] sorry, unimplemented: mangling record_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95298 Patrick Palka changed: What|Removed |Added Last reconfirmed||2021-05-24 Known to fail||10.3.0, 11.1.0, 7.5.0, ||8.5.0, 9.3.0 CC||ppalka at gcc dot gnu.org Target Milestone|--- |9.4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||rejects-valid Summary|sorry, unimplemented: |[9/10/11/12 Regression] |mangling record_type|sorry, unimplemented: ||mangling record_type Known to work||6.4.0 --- Comment #2 from Patrick Palka --- Started with r7-2030.
[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537 --- Comment #17 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:358832c46a378e5a0b8a2fa3c2739125e3e680c7 commit r12-1022-g358832c46a378e5a0b8a2fa3c2739125e3e680c7 Author: Ian Lance Taylor Date: Sat May 22 19:19:13 2021 -0700 compiler: mark global variables whose address is taken To implement this, change the backend to use flag bits for variables. Fixes https://gcc.gnu.org/PR100537 PR go/100537 * go-gcc.cc (class Gcc_backend): Update methods that create variables to take a flags parameter. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/322129
[Bug target/100745] GCC generates suboptimal assembly from vector extensions on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100745 --- Comment #1 from Nicolas F. --- I'll attach a second version of profile.c, with the vector extension code that's actually going to be used in mpv (some cleanup has been done). Performance is unchanged. Some absolute numbers from gcc 11.1.0: $ ./profile old: 811703 nicolas: 262007 (3.10x as fast) niklas: 679524 (1.19x as fast) Some absolute numbers from Clang -O3: $ ./profile old: 1547552 nicolas: 269081 (5.75x as fast) niklas: 246508 (6.28x as fast) As you can see, Clang does significantly worse on the C version (yay GCC!), but significantly, and most importantly, in absolute terms, better on the vector version. Like more than twice as fast than GCC's code. Looking at GCC's assembly output, I can see some odd choices, such as shuffling vectors around on the stack instead of using the other scratch registers (v21-v30), whereas clang does use those scratch registers.
[Bug target/100745] GCC generates suboptimal assembly from vector extensions on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100745 Nicolas F. changed: What|Removed |Added Attachment #50861|0 |1 is obsolete|| --- Comment #2 from Nicolas F. --- Created attachment 50863 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50863&action=edit Updated profile.c with the haasn code that will end up in mpv
[Bug c++/100746] NRVO should not introduce aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100746 --- Comment #1 from Marc Glisse --- PR 80740 ?
[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Ian Lance Taylor --- Should be fixed.
[Bug testsuite/100748] New: [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 Bug ID: 100748 Summary: [12 regression] 30_threads/jthread/95989.cc fails after r12-843 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:60a156ae53e976dfe44689f7c89e607596e7cf67, r12-843 make -k check RUNTESTFLAGS="conformance.exp=30_threads/jthread/95989.cc" FAIL: 30_threads/jthread/95989.cc execution test # of expected passes1 # of unexpected failures1 It looks like this fails on power 7 BE since it was reactivated. Looks OK on LE and power 8 BE. commit 60a156ae53e976dfe44689f7c89e607596e7cf67 Author: Jonathan Wakely Date: Mon May 17 14:55:22 2021 +0100 libstdc++: Fix std::jthread assertion and re-enable skipped test spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xg++ -shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++ -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util /home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/30_threads/jthread/95989.cc -std=gnu++2a -pthread -static -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./95989.exe^M PASS: 30_threads/jthread/95989.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/32::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/32::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...]^M terminate called after throwing an instance of 'std::system_error' what(): Unknown error 4398050832512 FAIL: 30_threads/jthread/95989.cc execution test
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- And apparently even on x86_64-pc-linux-gnu, though I don't see it: https://gcc.gnu.org/pipermail/libstdc++/2021-May/052592.html
[Bug testsuite/100749] New: [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 Bug ID: 100749 Summary: [12 regression] gcc.dg/pch/valid-1.c fails after r12-949 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:459d84e9b6e925922246b6aff76a5202b1d4d4ba, r12-949 make -k check-gcc RUNTESTFLAGS="pch.exp=gcc.dg/pch/valid-1.c" FAIL: gcc.dg/pch/valid-1.c -O0 -g -I. -Dwith_PCH (test for warnings, line 4) FAIL: gcc.dg/pch/valid-1.c -O0 -g -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/valid-1.c -O0 -I. -Dwith_PCH (test for warnings, line 4) FAIL: gcc.dg/pch/valid-1.c -O0 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/valid-1.c -O1 -I. -Dwith_PCH (test for warnings, line 4) FAIL: gcc.dg/pch/valid-1.c -O1 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/valid-1.c -O2 -I. -Dwith_PCH (test for warnings, line 4) FAIL: gcc.dg/pch/valid-1.c -O2 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/valid-1.c -O3 -g -I. -Dwith_PCH (test for warnings, line 4) FAIL: gcc.dg/pch/valid-1.c -O3 -g -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/valid-1.c -Os -I. -Dwith_PCH (test for warnings, line 4) FAIL: gcc.dg/pch/valid-1.c -Os -I. -Dwith_PCH (test for excess errors) # of expected passes24 # of unexpected failures12 Looks like the adjusted error message doesn't match. commit 459d84e9b6e925922246b6aff76a5202b1d4d4ba Author: Indu Bhagat Date: Fri Apr 30 07:52:40 2021 -0700 opts: change write_symbols to support bitmasks * gcc.dg/pch/valid-1.c: Adjust diagnostic message in testcase.
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 --- Comment #2 from seurer at gcc dot gnu.org --- I do see it failing on at least one powerpc64 LE machine. PR97944 said it used to fail randomly.
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #8 from Segher Boessenkool --- (In reply to luoxhu from comment #7) > (In reply to Segher Boessenkool from comment #3) > > The rotates in 6 and 7 are not merged, and neither are the vec_selects in > > 8 and 9. Both should be pretty easy to do, there is no unspec in sight, > > etc. > > Should this be done in pass bswaps or combine or by peephole2? :) It should be done by simplify-rtx.c at least (which will make it work in combine and other places): two rotates that together do nothing should be optimised to that, or generally, two rotates should be optimised to just one (which then can be optimised to nothing). Similar for vec_select. Maybe something in bswaps can help as well, I don't know, I haven't looked closely yet.
[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #7 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571120.html
[Bug c++/74762] [9/10/11/12 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 Martin Sebor changed: What|Removed |Added Keywords||patch Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #17 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571120.html
[Bug testsuite/100750] New: new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 Bug ID: 100750 Summary: new test case gcc.target/powerpc/rop-5.c fails on BE Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:5bd66c6826e5f3a38ba393702923feb88959f845, r12-814 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/rop-5.c" FAIL: gcc.target/powerpc/rop-5.c (test for excess errors) # of unexpected failures1 Fails on both power 7 and power 8 BE. /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/rop-5.c: In function 'foo': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/rop-5.c:12:1: error: '-mrop-protect' requires the ELFv2 ABI (lots more instances of that message) commit 5bd66c6826e5f3a38ba393702923feb88959f845 Author: Bill Schmidt Date: Thu May 13 13:33:35 2021 -0500
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 --- Comment #3 from Jonathan Wakely --- I'd better disable it again until I have time to figure it out.
[Bug target/100310] [AVX512] Missing support for v{,p}expand* instructions that w/o mask operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100310
--- Comment #2 from Hongtao.liu ---
w/o mask operands, v{,p}expand* are equal to mov instructions.
[Bug target/95782] [ppc64le] ICE in _cpp_pop_context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95782 --- Comment #1 from Evan Nemerson --- This seems to also happen on s390x with -mzvector: # s390x-linux-gnu-gcc-10 -march=z14 -mzvector -o test test.c test.c:4:1: internal compiler error: in _cpp_pop_context, at libcpp/macro.c:2644 4 | b(vector double) | ^ 0x11da337 _cpp_pop_context ../../src/libcpp/macro.c:2644 0x11dcd67 expand_arg ../../src/libcpp/macro.c:2601 0x11dc41f replace_args ../../src/libcpp/macro.c:1879 0x11dc41f enter_macro_context ../../src/libcpp/macro.c:1421 0x11dc7e8 cpp_get_token_1 ../../src/libcpp/macro.c:2891 0x6393fe c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ../../src/gcc/c-family/c-lex.c:458 0x5c96a5 c_lex_one_token ../../src/gcc/c/c-parser.c:270 0x5f6517 c_parser_peek_token(c_parser*) ../../src/gcc/c/c-parser.c:474 0x5f6517 c_parse_file() ../../src/gcc/c/c-parser.c:21742 0x64054b c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1190 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 --- Comment #3 from Hongtao.liu --- (In reply to Segher Boessenkool from comment #2) > (In reply to Richard Biener from comment #1) > > I suppose we're confused about the vec_duplicate. Would generally swapping > > the duplicate and the bit_not be profitable? Eventually it's a > > simplification > > combine could try - I belive it has some cases where it tries variants of > > the > > original instructions when combining. Adding a combine helper pattern > > looks like putting too much burden on the backend IMHO. > > > > We don't have a generic nand optab so handling this in ISEL on gimple > > isn't straight-forward. > > > > But combine and/or forwprop could do this. > > Combine never tries anything. Combine makes *one* result; if that does not > work, > it does not do the combination. (This is not completely true, but in essence > that is how it works, and it has to to not have exponential complexity). > > It would be good to define a canonical form for anything vec_duplicate. It > probably is a good idea to pull the vec_duplicate as far outside as possible? > > Canonical forms hugely reduce the amount of work needed. Compare to how > "andc" > is represented (canonically with the inverted input first), or how "nand" is > (we > write that as an "orcc", an "or" with both inputs inverted, in canonical > RTL). > Because only one form is allowed, we only have to check for that one form > everywhere. > > Confirmed. Even w/ canonical RTL, i think a combine splitter is also needed here, the canonical RTL only helps combine/forwprop to match more possibility but won't split patterns by itselies.
[Bug ipa/100513] [10/11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3 since r11-6411-gae99b315ba5b9e1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #25 from David Binderman --- (In reply to Jiu Fu Guo from comment #21) > When build the go on trunk with the patch, an error occur: > In function 'syscall.forkExec': > go1: error: address taken, but ADDRESSABLE bit not set I see this also on a go build on raspberry pi. Interesting.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 --- Comment #4 from Hongtao.liu --- (In reply to Hongtao.liu from comment #3) > > (In reply to Segher Boessenkool from comment #2) > > (In reply to Richard Biener from comment #1) > > > I suppose we're confused about the vec_duplicate. Would generally > Even w/ canonical RTL, i think a combine splitter is also needed here, the > canonical RTL only helps combine/forwprop to match more possibility but > won't split patterns by itselies. I was wrong, i thought combine only support n->1 combining, but actually pass_combine also support 3->2 combining which means a define_split is not needed here.
[Bug gcov-profile/100751] New: __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 Bug ID: 100751 Summary: __gcov_dump and __gcov_reset usage Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: gejoed at rediffmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 50864 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50864&action=edit sample-prog.i which is the preprocessed version of sample-prog.c I did go through the online manual of gcc gcov on __gcov_dump() and __gcov_reset() : https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-Optimization I tried out using the functions in a sample program (sample-prog.c) that is attached here. The steps followed were : (1) gcc -fprofile-arcs -ftest-coverage sample-prog.c (2) ./a.out (3) gcov sample-prog.c While running a.out, when I give character 'g', the __gcov_dump() must be invoked. What I could observe is that first time __gcov_dump() is invoked , the sample-prog.gcda file gets created. For the second time and then onwards, __gcov_dump() invocation (by giving 'g' character during the a.out run) doesn't happen. This is concluded by looking at the time stamp of sample-prog.gcda file in the same folder. It was still having the same time stamp of first time invocation of __gcov_dump(). Another thing is that, __gcov_reset() also doesn't appear to work. I tried giving the character 'r' during the run of the program but couldn't see the counters getting reset to 0 in the sample-prog.gcov file. The previous values of lines covered were there. Let me know if my approach is correct or if I miss any information here. I'm attaching the preprocessed file (sample-prog.i) and the logs of the gcc step used for the preprocessed file.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 Gejoe changed: What|Removed |Added CC||gejoed at rediffmail dot com --- Comment #1 from Gejoe --- Created attachment 50865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50865&action=edit Preprocessing logs giving gcc version
