[Bug rtl-optimization/99199] [9/10/11 Regression] Very large boolean expression leads to quite a few return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-23 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- x86 needs a conditional return ;) But yeah, special-casing of BBs with only a simple_return in BB-reorder or some cross-jumping might do the trick.
[Bug c++/99201] [8/9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2
[Bug fortran/99205] [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.3 Keywords||memory-hog
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #5 from Martin Liška --- Just for the record, started with r11-2919-g9d463ce7f983f03f.
[Bug c/99211] gcc fails on program which overrides __builtin_clzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99211 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code CC||jsm28 at gcc dot gnu.org --- Comment #1 from Richard Biener --- I wonder if we can reject definitions/declarations of identifiers in GCCs implementation namespace (__builtin_*), even if correctly typed? The C family frontends have been prone to accept random crap as builtin functions.
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug libstdc++/97549] [11 Regression] include/pstl rebase breaking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97549
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7e647d71d556b73e84f4edd0733bcc83bc70ae1e
commit r11-7339-g7e647d71d556b73e84f4edd0733bcc83bc70ae1e
Author: Jakub Jelinek
Date: Tue Feb 23 09:26:23 2021 +0100
libstdc++: Fix up parallel_backend_serial.h [PR97549]
In GCC 10, parallel_backend.h just included parallel_backend_{serial,tbb}.h
and
did nothing beyond that, and parallel_backend_tbb.h provided directly
namespace __pstl { namespace __par_backend { ... } }
and defined everything in there, while parallel_backend_serial.h did:
namespace __pstl { namespace __serial { ... } } and had this
namespace __pstl { namespace __par_backend { using namespace
__pstl::__serial; } }
at the end.
In GCC 11, parallel_backend.h does:
namespace __pstl { namespace __par_backend = __serial_backend; }
after including parallel_backend_serial.h or
namespace __pstl { namespace __par_backend = __tbb_backend; }
after including parallel_backend_tbb.h. The latter then has:
namespace __pstl { namespace __tbb_backend { ... } }
and no using etc. at the end, while parallel_backend_serial.h changed to:
namespace __pstl { namespace __serial_backend { ... } }
but has this leftover block from the GCC 10 times. Even changing that
using namespace __pstl::__serial;
to
using namespace __pstl::__serial_backend;
doesn't work, as it clashes with
namespace __pstl { namespace __par_backend = __serial_backend; }
in parallel_backend.h.
2021-02-23 Jakub Jelinek
PR libstdc++/97549
* include/pstl/parallel_backend_serial.h: Remove
__pstl::__par_backend.
[Bug c++/99201] [8/9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201
--- Comment #5 from Matthias Kretz (Vir) ---
I reduced it some more:
template
auto
make_tester(const RefF& reffun)
{
return [=](auto in) {
auto&& expected = [&](const auto&... vs) {
if constexpr (sizeof(in) > 0)
return [&](auto i) { return reffun(vs[i]...); }(0);
else
return [&](auto i) { return reffun(vs[i]...); }(0);
};
};
}
int main()
{
make_tester([](auto x) { return x; })(0);
return 0;
}
[Bug libstdc++/99181] char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:efa64fcce12074dd542670feb02eaee53e810a30 commit r11-7340-gefa64fcce12074dd542670feb02eaee53e810a30 Author: Jakub Jelinek Date: Tue Feb 23 09:30:18 2021 +0100 libstdc++: Fix up constexpr std::char_traits::compare [PR99181] Because of LWG 467, std::char_traits::lt compares the values cast to unsigned char rather than char, so even when char is signed we get unsigned comparision. std::char_traits::compare uses __builtin_memcmp and that works the same, but during constexpr evaluation we were calling __gnu_cxx::char_traits::compare. As char_traits::lt is not virtual, __gnu_cxx::char_traits::compare used __gnu_cxx::char_traits::lt rather than std::char_traits::lt and thus compared chars as signed if char is signed. This change fixes it by inlining __gnu_cxx::char_traits::compare into std::char_traits::compare by hand, so that it calls the right lt method. 2021-02-23 Jakub Jelinek PR libstdc++/99181 * include/bits/char_traits.h (char_traits::compare): For constexpr evaluation don't call __gnu_cxx::char_traits::compare but do the comparison loop directly. * testsuite/21_strings/char_traits/requirements/char/99181.cc: New test.
[Bug tree-optimization/99204] [8/9/10/11 Regression] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:37b64a3547b91677189c6cbf4c08d7c80770a93a commit r11-7341-g37b64a3547b91677189c6cbf4c08d7c80770a93a Author: Jakub Jelinek Date: Tue Feb 23 09:49:48 2021 +0100 fold-const: Fix ICE in fold_read_from_constant_string on invalid code [PR99204] fold_read_from_constant_string and expand_expr_real_1 have code to optimize constant reads from string (tree vs. rtl). If the STRING_CST array type has zero low bound, index is fold converted to sizetype and so the compare_tree_int works fine, but if it has some other low bound, it calls size_diffop_loc and that function from 2 sizetype operands creates a ssizetype difference. expand_expr_real_1 then uses tree_fits_uhwi_p + compare_tree_int and so works fine, but fold-const.c only checked if index is INTEGER_CST and calls compare_tree_int, which means for negative index it will succeed and result in UB in the compiler. 2021-02-23 Jakub Jelinek PR tree-optimization/99204 * fold-const.c (fold_read_from_constant_string): Check that tree_fits_uhwi_p (index) rather than just that index is INTEGER_CST. * gfortran.dg/pr99204.f90: New test.
[Bug libfortran/99191] sanitizer detects undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191
Martin Liška changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Good, I can confirm that. The code contains a comment about it:
if (n < 0)
{
negative = 1;
t = -n; /*must use unsigned to protect from overflow*/
}
Full back-trace:
/home/marxin/Programming/gcc2/libgfortran/io/write.c:835:7: runtime error:
negation of 0x8000 cannot be represented in type
'__int128'; cast to an unsigned type to negate this value to itself
#0 0x77844eec in write_decimal
/home/marxin/Programming/gcc2/libgfortran/io/write.c:835
#1 0x77846d56 in write_integer
/home/marxin/Programming/gcc2/libgfortran/io/write.c:1369
#2 0x77849b34 in list_formatted_write_scalar
/home/marxin/Programming/gcc2/libgfortran/io/write.c:1894
#3 0x7784a5eb in _gfortrani_list_formatted_write
/home/marxin/Programming/gcc2/libgfortran/io/write.c:1972
#4 0x77812440 in wrap_scalar_transfer
/home/marxin/Programming/gcc2/libgfortran/io/transfer.c:2382
#5 0x77812487 in _gfortran_transfer_integer
/home/marxin/Programming/gcc2/libgfortran/io/transfer.c:2393
#6 0x778124b7 in _gfortran_transfer_integer_write
/home/marxin/Programming/gcc2/libgfortran/io/transfer.c:2399
#7 0x400873 in check.0 (/home/marxin/Programming/testcases/a.out+0x400873)
#8 0x4008b0 in MAIN__ (/home/marxin/Programming/testcases/a.out+0x4008b0)
#9 0x4008e7 in main (/home/marxin/Programming/testcases/a.out+0x4008e7)
#10 0x754edb24 in __libc_start_main (/lib64/libc.so.6+0x27b24)
#11 0x40072d in _start (/home/marxin/Programming/testcases/a.out+0x40072d)
@Janne: Can you please take a look?
[Bug testsuite/44792] data.f90 accesses undefined variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44792 --- Comment #3 from Vittorio Zecca --- Still unmodified, I cannot see the modification of Tobias Burnus. NAG nagfor compiler stll produces run time error message. Runtime Error: gcc/testsuite/gfortran.fortran-torture/execute/data.f90, line 28: Reference to undefined variable TMP2(1)%T1(1)%A
[Bug libquadmath/99203] Undefined behaviour in libquadmath file print_fp.c function __quadmath_printf_fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99203 Martin Liška changed: What|Removed |Added Blocks||63426 Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-23 --- Comment #1 from Martin Liška --- Confirmed, full backtrace: /home/marxin/Programming/gcc2/libquadmath/printf/printf_fp.c:762:4: runtime error: passing zero to ctz(), which is not a valid argument #0 0x7719692b in __quadmath_printf_fp /home/marxin/Programming/gcc2/libquadmath/printf/printf_fp.c:762 #1 0x771d6884 in quadmath_snprintf /home/marxin/Programming/gcc2/libquadmath/printf/quadmath-printf.c:266 #2 0x775ccbab (/usr/lib64/libgfortran.so.5+0x252bab) #3 0x775d07df (/usr/lib64/libgfortran.so.5+0x2567df) #4 0x775c72b4 (/usr/lib64/libgfortran.so.5+0x24d2b4) #5 0x775c7973 (/usr/lib64/libgfortran.so.5+0x24d973) #6 0x400d85 in checkfmt.0 (/home/marxin/Programming/testcases/a.out+0x400d85) #7 0x40160e in MAIN__ (/home/marxin/Programming/testcases/a.out+0x40160e) #8 0x4024e6 in main (/home/marxin/Programming/testcases/a.out+0x4024e6) #9 0x76fc9b24 in __libc_start_main (/lib64/libc.so.6+0x27b24) #10 0x40096d in _start (/home/marxin/Programming/testcases/a.out+0x40096d) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug libquadmath/99202] Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99202 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-23 CC||fxcoudert at gcc dot gnu.org, ||marxin at gcc dot gnu.org Blocks||63426 --- Comment #1 from Martin Liška --- Confirmed, full back-trace: LD_PRELOAD=/dev/shm/objdir2/x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.so.1.0.0 ./a.out /home/marxin/Programming/gcc2/libquadmath/math/rem_pio2q.c:562:26: runtime error: left shift of 4612832830761346066 by 23 places cannot be represented in type 'long int' #0 0x77193736 in __quadmath_rem_pio2q /home/marxin/Programming/gcc2/libquadmath/math/rem_pio2q.c:562 #1 0x771adfde in tanq /home/marxin/Programming/gcc2/libquadmath/math/tanq.c:73 #2 0x403e2d in MAIN__ (/home/marxin/Programming/testcases/a.out+0x403e2d) #3 0x404e50 in main (/home/marxin/Programming/testcases/a.out+0x404e50) #4 0x76fc9b24 in __libc_start_main (/lib64/libc.so.6+0x27b24) #5 0x40174d in _start (/home/marxin/Programming/testcases/a.out+0x40174d) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c/94755] [9/10/11 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c/99211] gcc fails on program which overrides __builtin_clzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99211 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I think we have other PRs like this and it has been discussed. Problem with disabling altogether __builtin_* function declarations/definitions is that code in the wild uses typeof (whatever) __builtin_whatever __attribute__((...)); style declarations.
[Bug libstdc++/97549] [11 Regression] include/pstl rebase breaking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97549 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug libstdc++/99181] char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk, probably needs backporting to 10/9/8 branches.
[Bug tree-optimization/99204] [8/9/10 Regression] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in |fold_read_from_constant_str |fold_read_from_constant_str |ing, at fold-const.c:15441 |ing, at fold-const.c:15441 | --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 Martin Liška changed: What|Removed |Added URL||https://reviews.llvm.org/D9 ||7263 --- Comment #6 from Martin Liška --- I can reproduce it and I've just made an upstream pull request: https://reviews.llvm.org/D97263
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117 Richard Biener changed: What|Removed |Added Keywords|needs-reduction | --- Comment #10 from Richard Biener --- So the issue is definitely the __restrict__ qualification of the valarray::__M_data member. As you noted __valarray_copy is where points-to analysis sees the restrict qualification when accessing _Array<_Tp>::_M_data and that causes it to disambiguate against the accesses via __e. So I see nothing wrong with points-to analysis handling the __restrict qualification. Whether there's a bug in std::valarray (or in std::accumulate) or whether the testcase is invalid remains your choice. I'm keeping it wrong-code classified for now.
[Bug c++/99201] [8/9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:16581 since r8-7613-g1456e764105702a0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[8/9/10/11 Regression] ICE |[8/9/10/11 Regression] ICE |in tsubst_copy, at |in tsubst_copy, at |cp/pt.c:16581 |cp/pt.c:16581 since ||r8-7613-g1456e764105702a0 --- Comment #6 from Martin Liška --- Started with r8-7613-g1456e764105702a0.
[Bug target/99216] New: ICE in aarch64_sve::function_expander::expand() with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99216
Bug ID: 99216
Summary: ICE in aarch64_sve::function_expander::expand() with
LTO
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.cc
#include
bool a;
int main() { a = svaddv(svptrue_b8(), svdup_s8(0)); }
$ aarch64-linux-gnu-gcc -march=armv8.2-a+sve -flto test.cc
during RTL pass: expand
test.cc: In function ‘main’:
test.cc:3:24: internal compiler error: in operator[], at vec.h:890
3 | int main() { a = svaddv(svptrue_b8(), svdup_s8(0)); }
|^
0x11a1562 vec::operator[](unsigned int)
/home/alecop01/toolchain/src/gcc/gcc/vec.h:890
0x11a1562 vec::operator[](unsigned int)
/home/alecop01/toolchain/src/gcc/gcc/vec.h:1461
0x11a1562 expand
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve-builtins-base.cc:237
0x1196101 aarch64_sve::function_expander::expand()
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:3318
0x1197242 aarch64_sve::expand_builtin(unsigned int, tree_node*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:3607
0x10f62eb aarch64_expand_builtin
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:13568
0x74b79a expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/alecop01/toolchain/src/gcc/gcc/builtins.c:9518
0x8c51cc expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:11276
0x8c6779 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:8513
0x8cfc1c store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5886
0x8d1927 expand_assignment(tree_node*, tree_node*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5622
0x780d7c expand_call_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:2838
0x780d7c expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3844
0x780d7c expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:4008
0x78a5a7 expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6045
0x78bc61 execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6729
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/99216] ICE in aarch64_sve::function_expander::expand() with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99216 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.3 Ever confirmed|0 |1 Known to fail||10.2.1 CC||ktkachov at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Last reconfirmed||2021-02-23 Status|UNCONFIRMED |NEW --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. ICEs on GCC 10 as well
[Bug tree-optimization/44976] reductions with short variables do not get vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44976 Richard Biener changed: What|Removed |Added Known to work||10.1.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Richard Biener --- Fixed in GCC 10.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 44976, which changed state. Bug 44976 Summary: reductions with short variables do not get vectorized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44976 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/99216] ICE in aarch64_sve::function_expander::expand() with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99216
--- Comment #2 from Alex Coplan ---
This one ICEs at all optimization levels (not just -O0):
#include
unsigned long long a;
void b(unsigned long long *c, int e) { *c ^= e; }
bool d;
int main() {
d = svaddv(svptrue_pat_b8(SV_VL16), svdup_s8(0));
b(&a, d);
}
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed in master with g:e03e58c1844d04678f95b278f3eff2a5fbaeff75.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 99190, which changed state. Bug 99190 Summary: Undefined behaviour in libubsan https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/99211] gcc fails on program which overrides __builtin_clzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99211 --- Comment #3 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #2) > Problem with disabling altogether __builtin_* function > declarations/definitions > is that code in the wild uses > typeof (whatever) __builtin_whatever __attribute__((...)); > style declarations. It deserves to be broken.
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #11 from Jonathan Wakely ---
So is Jakub wrong in comment 5 when he suggests that this should "lose" the
__restrict__ qualification?
_Tp* __p (__a._M_data);
Is there a better way to drop that qual so that we can assign something to the
elements of __a._M_data that aliases itself?
Presumably this would be guaranteed to work?
_Tp* __p (__a._M_data);
for (size_t __i = 0; __i < __n; ++__i, ++__p)
{
_Tp __tmp = __e[__i];
*__p = __tmp;
}
[Bug libstdc++/99181] char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181 --- Comment #6 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #5) > Fixed on the trunk, probably needs backporting to 10/9/8 branches. Yes, all three branches. It's been wrong since r249137 on trunk, which I backported to gcc-7 (for 7.3.0) as r252030
[Bug c/99211] gcc fails on program which overrides __builtin_clzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99211 --- Comment #4 from Jakub Jelinek --- We have it even in gcc sources, though ifdefed so it won't trigger with recent-ish gcc: libstdc++-v3/include/ext/throw_allocator.h: __typeof__(&std::sprintf) __builtin_sprintf = &std::sprintf; I think this was PR32455, I believe the patch has never been applied, but I don't really remember all the details about it.
[Bug c/32455] [4.5 Regression] ICE with modified va_list, allows declaration of __builtin_*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455 --- Comment #17 from Jakub Jelinek --- The ICE on #c2 stopped with r0-101269-g70f348148c09468b05aa09fcfa91b61611003c27 (I think, r0-101269 doesn't ICE anymore and r0-101265 still ICEs), but the FE patch hasn't been ever applied.
[Bug tree-optimization/79726] Missing optimisation: Type conversion not vectorised in simple additive reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79726
--- Comment #2 from Richard Biener ---
It's also a general -ffast-math missed optimization to demote the double
add to a float one. If you write
double f(double x[]) {
float p = 1.0;
for (int i = 0; i < 16; i++)
p += (float)x[i];
return p;
}
the loop is vectorized in a way you expect.
Note such demotion can result in +-Inf where it didn't appear before for
example when x[0] is less than float -Inf "+ 1." and thus (float)x[0] is
not representable but (float)(x[0] + 1.) is.
Still "correct" vectorization should also be possible but is not yet
implemented.
[Bug libstdc++/90857] stl::forward_list::erase_after crashes if __pos == __last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90857 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #5 from Jonathan Wakely --- One of the MSVC devs agreed with my interpretation and suggested that their impl (which has a check for the position==last case) is paranoid. I think the check in comment 3 is probably worth adding (for GCC 12), as long as we keep the debug assertion to diagnose it when checking is enabled. We could even consider __glibcxx_assert(__pos != __last) so that it's diagnosed more aggressively.
[Bug c++/99200] __PRETTY_FUNCTION__ used as template parameter causes internal compiler error (segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99200 --- Comment #5 from Jonathan Wakely --- (In reply to JoaoBapt from comment #0) > Trying to use the macro __PRETTY_FUNCTION__ as a string-literal converted N.B. "These identifiers are variables, not preprocessor macros" See https://gcc.gnu.org/onlinedocs/gcc/Function-Names.html
[Bug c/99217] New: [MIPS] wrong function entry with -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99217
Bug ID: 99217
Summary: [MIPS] wrong function entry with
-fpatchable-function-entry
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: huangpei at loongson dot cn
Target Milestone: ---
On Debian AMD64 unstable,
-
depaulose@localhost:~$ cat a.c
void f() {}
depaulose@localhost:~$ gcc -fpatchable-function-entry=3 -c a.c
depaulose@localhost:~$ objdump -d a.o
a.o: file format elf64-tradlittlemips
Disassembly of section .text:
:
...
000c :
c: 67bdfff0daddiu sp,sp,-16
10: ffbe0008sd s8,8(sp)
14: 03a0f025moves8,sp
18: nop
1c: 03c0e825movesp,s8
20: dfbe0008ld s8,8(sp)
24: 67bd0010daddiu sp,sp,16
28: 03e8jr ra
2c: nop
depaulose@localhost:~$ readelf -s a.o
Symbol table '.symtab' contains 14 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS a.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 SECTION LOCAL DEFAULT8
6: 0 SECTION LOCAL DEFAULT9
7: 0 SECTION LOCAL DEFAULT 12
8: 0 SECTION LOCAL DEFAULT4
9: 0 SECTION LOCAL DEFAULT5
10: 0 SECTION LOCAL DEFAULT6
11: 0 SECTION LOCAL DEFAULT 11
12: 0 SECTION LOCAL DEFAULT 13
13: 000c36 FUNCGLOBAL DEFAULT1 f
depaulose@localhost:~$ gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
depaulose@localhost:~$ as --version
GNU assembler (GNU Binutils for Debian) 2.35.2
Copyright (C) 2020 Free Software Foundation, Inc.
This assembler was configured for a target of `mips64el-linux-gnuabi64'.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mips64el-linux-gnuabi64'.
--
It turned out that function address is wrong. It is expected that the function
entry is 0 not 0xc
On Debian 10 , for arm64, same file
--
ambrosehua@ambrosehua-HP-xw6600-Workstation:Downloads$ aarch64-linux-gnu-gcc-8
-fpatchable-function-entry=3 -c a.c
ambrosehua@ambrosehua-HP-xw6600-Workstation:Downloads$
aarch64-linux-gnu-objdump -d a.o
a.o: file format elf64-littleaarch64
Disassembly of section .text:
:
0: d503201fnop
4: d503201fnop
8: d503201fnop
c: d503201fnop
10: d65f03c0ret
ambrosehua@ambrosehua-HP-xw6600-Workstation:Downloads$ readelf -s a.o
Symbol table '.symtab' contains 12 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS a.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 NOTYPE LOCAL DEFAULT1 $x
6: 0 SECTION LOCAL DEFAULT4
7: 0 SECTION LOCAL DEFAULT7
8: 0014 0 NOTYPE LOCAL DEFAULT8 $d
9: 0 SECTION LOCAL DEFAULT8
10: 0 SECTION LOCAL DEFAULT6
11: 20 FUNCGLOBAL DEFAULT1 f
--
here function address of f is right
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #12 from rguenther at suse dot de ---
On Tue, 23 Feb 2021, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
>
> --- Comment #11 from Jonathan Wakely ---
> So is Jakub wrong in comment 5 when he suggests that this should "lose" the
> __restrict__ qualification?
>
> _Tp* __p (__a._M_data);
Yes. __p is clearly based on __a._M_data and thus it can be used
to access data pointed to by the restrict qualified __a._M_data
which in turn means we can, if we prove value equivalence, place
the same restrictions on accesses via __p as we can on accesses
via __a._M_data. It would be way more awkward implementation-wise
if we couldn't do that.
> Is there a better way to drop that qual so that we can assign something to the
> elements of __a._M_data that aliases itself?
>
> Presumably this would be guaranteed to work?
>
> _Tp* __p (__a._M_data);
> for (size_t __i = 0; __i < __n; ++__i, ++__p)
> {
> _Tp __tmp = __e[__i];
> *__p = __tmp;
> }
That's no different. There's no way to lose restrict qualification
but to obfuscate the code in a way to make the compiler not see
the "based-on" relation of __a._M_data and the pointer used to
access the data. Passing __a by reference should also run into
limitations of points-to analysis but I guess it would be an ABI
change.
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #6 from Jonathan Wakely --- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2162r2.html says we should support inherited variants.
[Bug tree-optimization/80635] [8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #59 from Jakub Jelinek --- So, can't we combine --- gcc/match.pd.jj 2021-02-18 16:21:01.0 +0100 +++ gcc/match.pd2021-02-23 12:39:32.801064905 +0100 @@ -3316,7 +3316,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (view_convert @0) (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)) && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0))) - && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))) + && (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0)) + || (TREE_CODE (type) == BOOLEAN_TYPE + && TREE_CODE (@0) == SSA_NAME + && TREE_CODE (TREE_TYPE (@0)) != BOOLEAN_TYPE + && TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (@0)) + && type_has_mode_precision_p (TREE_TYPE (@0)) + && ssa_name_has_boolean_range (@0 (convert @0))) /* Strip inner integral conversions that do not change precision or size, or with expander optimization that will optimize away that masking when expanding NOP_EXPR from integral SSA_NAME with ssa_name_has_boolean_range to bool? Note, on this testcase the NOP_EXPR to bool is optimized away, so the expansion change would make zero difference, so I'll need to test that without the above change and doing the VCE -> NOP optimization during TER or so to see it in action. Anyway, when I did it earlier today, while expansion emitted the AND 1, later optimizations optimized that away again.
[Bug rtl-optimization/98782] [11 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug ada/98996] [11 Regression] mips64 ada ftbfs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98996 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/99180] [10/11 Regression] ICE with alias template and empty parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99180 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Keywords|ice-on-valid-code |ice-on-invalid-code Status|WAITING |NEW --- Comment #2 from Richard Biener --- clang rejects it
[Bug rtl-optimization/53533] [8/9/10/11 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 Richard Biener changed: What|Removed |Added Last reconfirmed|2015-05-03 00:00:00 |2021-2-23 --- Comment #41 from Richard Biener --- Re-confirmed.
[Bug testsuite/97699] [11 regression] zero-scratch-regs tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 97680 ***
[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 Richard Biener changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #8 from Richard Biener --- *** Bug 97699 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/80635] [8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Jakub Jelinek changed: What|Removed |Added Assignee|law at redhat dot com |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #60 from Jakub Jelinek --- Created attachment 50240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50240&action=edit gcc11-pr80635.patch Full untested patch.
[Bug target/98746] [11 Regression] memory hog for a lto+pgo build on powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98746 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-02-23 --- Comment #3 from Richard Biener --- Did the situation improve with the recent memory usage improvements?
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #13 from Richard Biener ---
So the valarray behavior boils down to
struct _Array { int * __restrict m_data; };
void foo (struct _Array dest, int *src, int n)
{
for (int i = 0; i < n; ++i)
dest.m_data[i] = src[i];
}
which we treat similarly:
_8 = MEM[(int *)_3 clique 1 base 0];
MEM[(int *)_7 clique 1 base 1] = _8;
and thus we'd vectorize "bogously" for example if src == dest.m_data + 1
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek ---
(In reply to Richard Biener from comment #13)
> So the valarray behavior boils down to
>
> struct _Array { int * __restrict m_data; };
>
> void foo (struct _Array dest, int *src, int n)
> {
> for (int i = 0; i < n; ++i)
> dest.m_data[i] = src[i];
> }
>
> which we treat similarly:
>
> _8 = MEM[(int *)_3 clique 1 base 0];
> MEM[(int *)_7 clique 1 base 1] = _8;
>
> and thus we'd vectorize "bogously" for example if src == dest.m_data + 1
I'd argue that passing such src to the function is invalid (for C, sure, C++
doesn't have restrict).
Because src is not based on dest.m_data in that case.
So, the big question is what passes that pointer that aliases it.
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #15 from Jakub Jelinek ---
So, based on IRC discussion, the problem is that in:
template template
inline valarray<_Tp>&
valarray<_Tp>::operator=(const _Expr<_Dom, _Tp>& __e)
{
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 630. arrays of valarray.
if (_M_size == __e.size())
std::__valarray_copy(__e, _M_size, _Array<_Tp>(_M_data));
the temporary _Array<_Tp>(_M_data) object's _M_data passed to __valarray_copy
doesn't fully own the object and that __e's operator[] aliases with that.
Can't libstdc++ for cases where such aliasing is possible use an _Array-like
class without the __restrict (i.e. something that wouldn't lie to the compiler
that it fully owns it)?
[Bug fortran/99218] New: matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 Bug ID: 99218 Summary: matmul on temporary array accesses invalid memory (segfault) Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rpmcnally at gmail dot com Target Milestone: --- Created attachment 50241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50241&action=edit Source file I traced a segfault in our code back to a matmul() where one of the arguments is the the result of a transpose() call: fTmp(:) = matmul(transpose(G(:,:)), lambda(:)) Modifying the code to store the transpose in an intermediate variable appears to resolve the segfault. I've reproduced the behavior in some standalone code. While the standalone code doesn't segfault, running it under valgrind shows a lot of invalid memory access. I do not see this behavior with my system GCC 4.8.5 or 7.3.0. I do see the memory issues with GCC 8.3.0, 9.3.0, and 10.2.0. The source file is attached. The output from valgrind is below. gfortran -Wall -Wextra -O0 -g -o issue issue.f90 ==13610== Memcheck, a memory error detector ==13610== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13610== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==13610== Command: ./issue ==13610== Testing Real with Transpose Inline ==13610== Invalid write of size 4 ==13610==at 0x4F3C754: matmul_r4_avx2 (matmul_r4.c:965) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== Address 0x5e1f3d0 is 0 bytes after a block of size 2,048 alloc'd ==13610==at 0x4C29F73: malloc (vg_replace_malloc.c:309) ==13610==by 0x4F39602: matmul_r4_avx2 (matmul_r4.c:909) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== ==13610== Invalid write of size 4 ==13610==at 0x4F3C785: matmul_r4_avx2 (matmul_r4.c:965) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== Address 0x5e1f7d0 is 960 bytes inside an unallocated block of size 4,176,848 in arena "client" ==13610== ==13610== Invalid write of size 4 ==13610==at 0x4F3C7B5: matmul_r4_avx2 (matmul_r4.c:965) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== Address 0x5e1fbd0 is 1,984 bytes inside an unallocated block of size 4,176,848 in arena "client" ==13610== ==13610== Invalid write of size 4 ==13610==at 0x4F3C7E6: matmul_r4_avx2 (matmul_r4.c:965) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== Address 0x5e1ffd0 is 3,008 bytes inside an unallocated block of size 4,176,848 in arena "client" ==13610== ==13610== Invalid read of size 4 ==13610==at 0x4F3CE50: matmul_r4_avx2 (matmul_r4.c:1093) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== Address 0x5e1f3d0 is 0 bytes after a block of size 2,048 alloc'd ==13610==at 0x4C29F73: malloc (vg_replace_malloc.c:309) ==13610==by 0x4F39602: matmul_r4_avx2 (matmul_r4.c:909) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== ==13610== Invalid read of size 4 ==13610==at 0x4F3CE5E: matmul_r4_avx2 (matmul_r4.c:1095) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== Address 0x5e1f7d0 is 960 bytes inside an unallocated block of size 4,176,848 in arena "client" ==13610== ==13610== Invalid read of size 4 ==13610==at 0x4F3D1A4: matmul_r4_avx2 (matmul_r4.c:1110) ==13610==by 0x401873: test_real_transposeinline.3 (issue.f90:36) ==13610==by 0x401932: main.4 (issue.f90:14) ==13610==by 0x400D01: MAIN__ (issue.f90:5) ==13610==by 0x401AC3: main (issue.f90:5) ==13610== Address 0x5e1fbd0 is 1,984 bytes inside an u
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #16 from Jakub Jelinek ---
So perhaps (totally untested):
--- libstdc++-v3/include/std/valarray.jj2021-01-04 10:26:02.366967342
+0100
+++ libstdc++-v3/include/std/valarray 2021-02-23 15:16:22.402688841 +0100
@@ -838,7 +838,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 630. arrays of valarray.
if (_M_size == __e.size())
- std::__valarray_copy(__e, _M_size, _Array<_Tp>(_M_data));
+ std::__valarray_copy(__e, _M_size, _M_data);
else
{
if (_M_data)
--- libstdc++-v3/include/bits/valarray_array.tcc.jj 2021-01-04
10:26:03.768951467 +0100
+++ libstdc++-v3/include/bits/valarray_array.tcc2021-02-23
15:15:29.273282041 +0100
@@ -146,6 +146,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*__p = __e[__i];
}
+ // Copy n consecutive elements of e into consecutive elements of p.
+ // I.e. p[i] = e[i]. p can alias what e uses.
+ template
+void
+__valarray_copy(const _Expr<_Dom, _Tp>& __e, size_t __n, _Tp* __p)
+{
+ for (size_t __i = 0; __i < __n; ++__i, ++__p)
+ *__p = __e[__i];
+}
+
// Copy n consecutive elements of e into elements of a using stride
// s. I.e., a[0] = e[0], a[s] = e[1], a[2*s] = e[2].
template
[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117 --- Comment #17 from Jakub Jelinek --- Pedantically speaking if __e in the end reads _M_data of some std::valarray that happens to alias __p it will be still violating aliasing, but at least current GCC won't do anything with that.
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-02-23 --- Comment #1 from Iain Sandoe --- (In reply to Nils Gladitz from comment #0) > I am itching to get into C++20 coroutines (and very grateful for their > implementation) but am somewhat put off by the apparent inability to inspect > them from within a debugger currently. > > While looking for existing related GCC specific issues, discussions or > commits (none of which I found) the following paper [Debugging C++ > coroutines] did come up: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2073r0.pdf > This seems to at least confirm the current state that I was seeing. Indeed you are correct (I was present at the meeting that the paper was reviewed). At that time (a year ago) there was no specific support in either GCC/GDB or clang/LLDB. I guess the debugging I do is mainly on code-gen, so rarely debugging the actual coroutines, more the compiler. > I can not tell if support for this is missing in GCC or GDB or both but I > figured I'd try finding out here first. > Presumably (hopefully) someone here is at least aware of the issue and might > be able to point out if this is maybe already done (and I am just doing it > wrong or using the wrong GCC version), in the works or on some agenda > somewhere. I have some ideas about how the debug experience might be improved (at least w.r.t examining frame content) - but, as with everything else, queued in the long TODO. Can you identify specific key blockers to progress? (I think the paper cited contained a number of desiderata, but it would be good to start from the most important requirements). I'd be interested in some idea of "I tried to fix this, but failed because I couldn't do ". I would expect source location-based breakpoints etc. to be functional (modulo possible bugs in attaching locations to expressions).
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
Martin Liška changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #30 from Martin Liška ---
I still cannot build the affected package:
$ cat exiv.i
int main_argc;
void
foo(char[main_argc + 1]) {}
$ gcc exiv.i -flto -O2 -shared -fPIC
lto1: internal compiler error: Segmentation fault
0xd3de6a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0xbc84f4 stream_read_tree_ref(lto_input_block*, data_in*)
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1830
0xf8a648 lto_input_ts_exp_tree_pointers
/home/marxin/Programming/gcc/gcc/tree-streamer-in.c:905
0xf8a648 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
/home/marxin/Programming/gcc/gcc/tree-streamer-in.c:1087
0xbc7c49 lto_read_tree_1
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1700
0xbc85a1 lto_read_tree
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1741
0xbc85a1 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1882
0xbc8857 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*, bool)
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1770
0xbc88df lto_input_tree(lto_input_block*, data_in*)
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1897
0xbcab0f streamer_read_chain
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1335
0xbcab0f input_function
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1365
0xbcab0f lto_read_body_or_constructor
/home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1621
0x8cfd91 cgraph_node::get_untransformed_body()
/home/marxin/Programming/gcc/gcc/cgraph.c:3940
0x8dbfe1 cgraph_node::expand()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:1798
0x8dd73e expand_all_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:1995
0x8dd73e symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2359
0x8dd73e symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2270
0x8260c4 lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95468 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:5bd7afb71fca3a5a6e9f8586d86903bae1849193 commit r11-7345-g5bd7afb71fca3a5a6e9f8586d86903bae1849193 Author: Patrick Palka Date: Tue Feb 23 09:40:09 2021 -0500 c++: Fix folding of non-dependent BASELINKs [PR95468] Here, the problem ultimately seems to be that tsubst_copy_and_build, when called with empty args as we do during non-dependent expression folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy which then immediately exits early due to the empty args. This means that the CAST_EXPR int(1) in the BASELINK A::condition never gets folded (as part of folding of the overall CALL_EXPR), which later causes us to crash when performing overload resolution of the rebuilt CALL_EXPR (which is still in terms of this templated BASELINK). This doesn't happen when condition() is a namespace-scope function because then condition is represented by a TEMPLATE_ID_EXPR rather than by a BASELINK, which does get handled directly from tsubst_copy_and_build. This patch fixes this issue by having tsubst_copy_and_build handle BASELINK directly rather than delegating to tsubst_copy, so that it processes BASELINKs even when args is empty. gcc/cp/ChangeLog: PR c++/95468 * pt.c (tsubst_copy_and_build) : New case, copied over from tsubst_copy. gcc/testsuite/ChangeLog: PR c++/95468 * g++.dg/template/non-dependent15.C: New test.
[Bug c++/95468] [8/9/10 Regression] ICE in expression sfinae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95468 Patrick Palka changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in expression sfinae|expression sfinae --- Comment #5 from Patrick Palka --- Fixed for GCC 11 so far.
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Hans-Peter Nilsson changed: What|Removed |Added Last reconfirmed||2021-02-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson --- Current observation: 198c56052ea8 / r11-7337
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #31 from Richard Biener --- Looks like DECL_ARGUMENTS of the function refers to SSA names. (gdb) p function->function_decl.arguments $1 = (gdb) p debug_tree ($1) unit-size align:8 warn_if_not_align:0 symtab:0 alias-set 0 canonical-type 0x765833f0 precision:8 min max pointer_to_this > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7658ec78 reference_to_this > unsigned decl_0 DI t.i:4:5 size unit-size align:64 warn_if_not_align:0 context attributes value chain arg:0 nothrow def_stmt version:1 in-free-list> arg:1 t.i:4:20 start: t.i:4:10 finish: t.i:4:22 arg-type > the "arg spec" attribute refers to a released SSA name.
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #2 from Nils Gladitz --- (In reply to Iain Sandoe from comment #1) > Can you identify specific key blockers to progress? > (I think the paper cited contained a number of desiderata, but it would be > good to start from the most important requirements). Thank you for the quick reply. As you and the paper have stated setting breakpoints so far seems to work fine for me. What stands out most for me is being unable to inspect parameters (which for the debugger don't seem to exist) and local variables (their names seem to be known but their values all show as ""). On second look this seems to be only half true as I seem to be able to inspect both local variables and parameters via the debugger visible "frame_ptr" variable. Not straightforward and names seem to be mangled but that might suffice to get started to some degree; won't work with gdb frontends though (which I have been using). I have no idea of how any of this is actually implemented but I am hoping this is just a matter of emitting debug information that tells gdb to look for members and parameters in the corresponding frame_ptr locations?
[Bug go/81183] -gdwarf-5: fatal error: unrecognized DWARF version in .debug_info at 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81183 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed for the current master.
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:3f8384545784696fbd66aaec24a998a819e912c5 commit r11-7346-g3f8384545784696fbd66aaec24a998a819e912c5 Author: Martin Liska Date: Tue Feb 23 09:01:53 2021 +0100 IPA ICF + ASAN: do not merge vars with different alignment gcc/ChangeLog: PR sanitizer/99168 * ipa-icf.c (sem_variable::merge): Do not merge 2 variables with different alignment. That leads to an invalid red zone size allocated in runtime. gcc/testsuite/ChangeLog: PR sanitizer/99168 * c-c++-common/asan/pr99168.c: New test.
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Liška --- Fixed on master.
[Bug c++/99208] [modules] ICE with partitions & instantiations of linkage-typedef structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99208 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:47145e6916f58e1cd4f562c06fa7289da49f690c commit r11-7347-g47145e6916f58e1cd4f562c06fa7289da49f690c Author: Nathan Sidwell Date: Tue Feb 23 07:08:55 2021 -0800 c++: typedef for linkage [PR 99208] Unnamed types with a typedef name for linkage were always troublesome in modules. This is the underlying cause of that trouble -- we were creating incorrect type structures. Classes have an implicit self-reference, and we created that for unnamed classes too. It turns out we make use of this member, so just not generating it turned into a rathole. This member is created using the anonymous name -- because we've not yet met the typedef name. When we retrofit the typedef name we were checking identifier matching and changing all type variants with that identifier. Which meant we ended up with a strange typedef for the self reference. This fixes things to check for DECL identity of the variants, so we don't smash the self-reference -- that continues to have the anonymous name. PR c++/99208 gcc/cp/ * decl.c (name_unnamed_type): Check DECL identity, not IDENTIFIER identity. gcc/testsuite/ * g++.dg/modules/pr99208_a.C: New. * g++.dg/modules/pr99208_b.C: New.
[Bug c++/99208] [modules] ICE with partitions & instantiations of linkage-typedef structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99208 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- 47145e6916f 2021-02-23 | c++: typedef for linkage [PR 99208]
[Bug fortran/99219] New: Possible wrong code for finalizator call with class via trans_scalar_class_assign ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99219 Bug ID: 99219 Summary: Possible wrong code for finalizator call with class via trans_scalar_class_assign ? Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: pault at gcc dot gnu.org Target Milestone: --- [Disclaimer: Not properly checked – but just observed when looking for something else in the code.] class.c has for generate_finalization_wrapper: The generated function has the form _final(assumed-rank array, stride, skip_corarray) But the call in trans-expr.c has in trans_scalar_class_assign: fcn = gfc_vptr_final_get (gfc_class_vptr_get (rse_expr)); ... tmp = build_call_expr_loc (input_location, fcn, 1, class_data); I have not checked more deeply, but it looks as if the second and third arguments are missing? By contrast, trans.c's gfc_add_finalizer_call has: tmp = build_call_expr_loc (input_location, final_fndecl, 3, array, size, fini_coarray ? boolean_true_node : boolean_false_node);
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #3 from Iain Sandoe --- (In reply to Nils Gladitz from comment #2) > (In reply to Iain Sandoe from comment #1) > > Can you identify specific key blockers to progress? > > (I think the paper cited contained a number of desiderata, but it would be > > good to start from the most important requirements). > As you and the paper have stated setting breakpoints so far seems to work > fine for me. great (there could still be room for improvement, so if you see something that doesn't work, worth filing a PR). > What stands out most for me is being unable to inspect parameters (which for > the debugger don't seem to exist) and local variables (their names seem to > be known but their values all show as ""). > > On second look this seems to be only half true as I seem to be able to > inspect both local variables and parameters via the debugger visible > "frame_ptr" variable. That is correct, both parameters and local variables are moved into the coroutine frame, but there is nothing telling the debugger that this happened... (there are also a bunch of artificial vars created in the frame to carry state that must persist across suspension points). The only debugger support I think is for MSVC - and they mentioned that it was useful to know the suspension point index - one of the artificial values, (but I don't think that there's any agreed way to represent that - certainly, nothing formal in DWARF). > Not straightforward and names seem to be mangled but that might suffice to > get started to some degree; won't work with gdb frontends though (which I > have been using). > > I have no idea of how any of this is actually implemented but I am hoping > this is just a matter of emitting debug information that tells gdb to look > for members and parameters in the corresponding frame_ptr locations? ... the essence of the idea [on the mentioned long TODO] is to change the way in which frame vars are referenced; instead of changing the uses to point to the frame version, change the vars to have a DECL_VALUE_EXPR pointing to the frame version. This is a totally theoretical sketch (no experiments done yet). Stated in one sentence, that doesn't sound too tricky .. but maintaining the state of the coroutine *is* quite tricky (and lambdas already use the DECL_VALUE_EXPRs).
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #15 from Jakub Jelinek --- In any case, if the option is totally broken, we should either fix it for GCC 11 or emit sorry message to make it clear to users the option is not supported.
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #16 from Jakub Jelinek --- But the latter (i.e. sorry) only if it always has been broken for that target. #c7 seems to suggest it worked in ELFv1 (does it work on powerpc -m32?) and got broken by H.J's change, then we should fix it rather than stop supporting it. And if it has always been broken on powerpc64le, then sorry might be one of the options.
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #4 from Nils Gladitz --- (In reply to Iain Sandoe from comment #3) > ... the essence of the idea [on the mentioned long TODO] is to change the > way in which frame vars are referenced; instead of changing the uses to > point to the frame version, change the vars to have a DECL_VALUE_EXPR > pointing to the frame version. This is a totally theoretical sketch (no > experiments done yet). > > Stated in one sentence, that doesn't sound too tricky .. but maintaining the > state of the coroutine *is* quite tricky (and lambdas already use the > DECL_VALUE_EXPRs). Alright, thank you! Just knowing that this is thought of, on a todo list and currently not completely inaccessible helps build confidence somewhat; I think for me enough to try some of this in production code. With some luck you still get through your todo list faster than I get to my next corresponding release :)
[Bug libstdc++/82739] [8/9/10/11 Regression] Sort is 30% slower compared to gcc44 on presorted array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82739 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Seems the performance degradation that started with r5-5019-g27d93d2c8a36cea495599e4eb070d3f922aab279 is gone on the trunk with the r11-3300-g83e037364e0d6dd74d595751e8bc8c461b4cb8fa change. Haven't tried 4.4 though.
[Bug libquadmath/99202] Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99202 --- Comment #2 from Vittorio Zecca --- I believe you need LD_PRELOAD if the object program uses the address sanitizer.
[Bug libstdc++/82739] [8/9/10 Regression] Sort is 30% slower compared to gcc44 on presorted array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82739 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] Sort |[8/9/10 Regression] Sort is |is 30% slower compared to |30% slower compared to |gcc44 on presorted array|gcc44 on presorted array --- Comment #6 from Jakub Jelinek --- Tried that now and I don't see any slowdown in between gcc 4.4 branchpoint - tried r145106 in particular - and r217669 when using the 4.4 preprocessed source, so I bet but can't prove easily is that it is the r203035 changes which are essential for the other PR. So marking as fixed in GCC 11.
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #8 from Vittorio Zecca --- I can confirm the new libubsan works on my test case. Keep up the good work!
[Bug tree-optimization/99220] New: [11 Regression] ICE during vectorization when multiple instances do the same calculation but have different num lanes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99220
Bug ID: 99220
Summary: [11 Regression] ICE during vectorization when multiple
instances do the same calculation but have different
num lanes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: tnfchris at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*
The following testcase
class a {
float b;
float c;
public:
a(float d, float e) : b(d), c(e) {}
a operator+(a d) { return a(b + d.b, c + d.c); }
a operator-(a d) { return a(b - d.b, c - d.c); }
a operator*(a d) { return a(b * b - c * c, b * c + c * d.b); }
};
long f;
a *g;
class {
a *h;
long i;
a *j;
public:
void k() {
a l = h[0], m = g[i], n = l * g[1], o = l * j[8];
g[i] = m + n;
g[i + 1] = m - n;
j[f] = o;
}
} p;
main() { p.k(); }
crashes with aarch64-none-elf-g++ -w -march=armv8.3-a -O3 -S main.cpp
because two nodes end up with the same pointer. During the loop that analyzes
all the instances during optimize_load_redistribution_1 we do
if (value)
{
SLP_TREE_REF_COUNT (value)++;
SLP_TREE_CHILDREN (root)[i] = value;
vect_free_slp_tree (node);
}
when doing a replacement. When this is done and the refcount for the node
reaches 0, the node is removed, which allows the libc to return the pointer
again in the next call to new, which it does..
First instance
note: node 0x5325f48 (max_nunits=1, refcnt=2)
note: op: VEC_PERM_EXPR
note: { }
note: lane permutation { 0[0] 1[1] 0[2] 1[3] }
note: children 0x5325db0 0x5325200
Second instance
note: node 0x5325f48 (max_nunits=1, refcnt=1)
note: op: VEC_PERM_EXPR
note: { }
note: lane permutation { 0[0] 1[1] }
note: children 0x53255b8 0x5325530
This will end up with the illegal construction of
note: node 0x53258e8 (max_nunits=2, refcnt=2)
note: op template: slp_patt_57 = .COMPLEX_MUL (_16, _16);
note: stmt 0 _16 = _14 - _15;
note: stmt 1 _23 = _17 + _22;
note: children 0x53257d8 0x5325d28
note: node 0x53257d8 (max_nunits=2, refcnt=3)
note: op template: l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 0 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 1 l$c_5 = MEM[(const struct a &)_3].c;
note: load permutation { 0 1 }
note: node 0x5325d28 (max_nunits=2, refcnt=8)
note: op template: l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 0 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 1 l$c_5 = MEM[(const struct a &)_3].c;
note: stmt 2 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 3 l$c_5 = MEM[(const struct a &)_3].c;
note: load permutation { 0 1 0 1 }
To prevent this we need to add these temporary VEC_PERM_EXPR nodes to the
bst_map cache and increase their refcnt one more.
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 Alexander Lelyakin changed: What|Removed |Added CC||alexander.lelyakin@googlema ||il.com --- Comment #5 from Alexander Lelyakin --- I have found two another sequences of system headers that cannot be compiled: - g++ -std=c++20 -fmodules-ts -x c++-system-header utility g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm g++ -std=c++20 -fmodules-ts -x c++-system-header iostream g++ -std=c++20 -fmodules-ts -x c++-system-header ranges g++ -std=c++20 -fmodules-ts -x c++-system-header vector g++ -std=c++20 -fmodules-ts -x c++-system-header array g++ -std=c++20 -fmodules-ts -x c++-system-header string g++ -std=c++20 -fmodules-ts -x c++-system-header functional -- g++ -std=c++20 -fmodules-ts -x c++-system-header concepts g++ -std=c++20 -fmodules-ts -x c++-system-header functional g++ -std=c++20 -fmodules-ts -x c++-system-header ranges g++ -std=c++20 -fmodules-ts -x c++-system-header vector g++ -std=c++20 -fmodules-ts -x c++-system-header string g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm -- Tried on last version from git: commit e03e58c1844d04678f95b278f3eff2a5fbaeff7 g++ (GCC) 11.0.0 20210223 (experimental)
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #11 from Patrick Palka --- (In reply to Jakub Jelinek from comment #9) > I think glibc %a printing uses 0x1. (for normalized values) at least for > float/double and the IEEE quad long doubles, but uses 0xf. printing etc. > for the 80-bit long doubles. My personal preference would be to always use > 0x1. for normalized numbers and for denormals 0x0., I think it is > less surprising to users, and transforming one form to another is pretty > easy. Yeah, currently to_chars hex output mimics glibc's choice of leading hex digit. But always using 0/1, even for 80-bit long double sounds good to me too. FWIW, I think the shortest hex form for some number is at most 3 characters shorter than any other conforming hex form, e.g. 1.2p+12 vs 9p+9. > And agree on the tests just trying to parse the returned string back to see > if it is the original value. I posted a patch at https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html that does this, but also salvages the verification via printf by first checking if the leading hex digit of the printf output agrees with that of to_chars. Conveniently, the patch sidesteps the question of choosing a consistent representation vs shortest representation :)
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 --- Comment #6 from Alexander Lelyakin --- Another, shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header new g++ -std=c++20 -fmodules-ts -x c++-system-header initializer_list g++ -std=c++20 -fmodules-ts -x c++-system-header typeinfo g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits g++ -std=c++20 -fmodules-ts -x c++-system-header exception /usr/local/include/c++/11.0.0/exception: internal compiler error: in write_cluster, at cp/module.cc:14600 0x6e2d56 module_state::write_cluster(elf_out*, depset**, unsigned int, depset::hash&, unsigned int*, unsigned int*) ../../gcc/gcc/cp/module.cc:14600 0xa62be8 module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17734 0xa638fc finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19860 0x9f72cb c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175
[Bug rtl-optimization/99221] New: copyprop_hardreg_forward_1 deletes insn by mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99221
Bug ID: 99221
Summary: copyprop_hardreg_forward_1 deletes insn by mistake
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Created attachment 50242
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50242&action=edit
a-foo.i.301r.jump2
Consider the following reduced example:
int g = 9, h, i, b;
char j, k;
long m;
char *a = &j;
char n() { return 0; }
void o(short o) {}
short p(short o, short q) { return q; }
long r(long s) { return s; }
long t(long s) { return 0; }
long u(long s) { return 0; }
short v() { return 0; }
void x(int **s, unsigned q) {
short c = 0, d = 0;
int e = 4;
if (g) {
int f = 4;
q = 1;
for (; q <= 4; q++) {
m = q;
d = i = u(d);
if (0 == r(1)) {
if (u(0)) {
h = t(q) != **s;
for (; e; e = f &= 0 <= 0)
;
}
} else {
b = c;
c = v();
o(q);
k = n();
j = p(k || q, q);
}
}
}
}
int main() {
x(0, 0);
printf("%d\n", j);
return 0;
}
Command line: gcc -march=arch11 -w -Og foo.i && ./a.out
Expected output: 4
Actual output: 0
On IBM Z we have prior pass cprop_hardreg the following insns of interest:
(insn 24 23 25 4 (set (reg:DI 24 %f8 [orig:61 _2 ] [61])
(reg/v:DI 12 %r12 [orig:85 q+-4 ] [85])) "./foo.i":19:10 1462
{*movdi_64}
(nil))
...
(insn 80 79 81 10 (set (reg:HI 24 %f8 [orig:74 _15 ] [74])
(reg:HI 12 %r12 [orig:85 q+2 ] [85])) "./foo.i":30:10 1474 {*movhi}
(nil))
...
(insn 155 96 97 15 (set (reg:HI 1 %r1 [orig:74 _15 ] [74])
(reg:HI 24 %f8 [orig:74 _15 ] [74])) "./foo.i":32:14 1474 {*movhi}
(nil))
Register f8 is set to a 64-bit value in insn 24 and to a 16-bit value in insn
80, respectively, while using the same source register r12. During
copyprop_hardreg_forward_1 it is then wrongly detected that insn 80 is a noop
set and is subsequently removed. Due to different alignments of different modes
in FPRs we have that in insn 155 the wrong part of register f8 is then accessed
which results in constant value zero.
In order to decide whether an insn is a noop set or not I gave it a try by
additionally testing whether the prior set and the current are done in
compatible modes by asking the backend:
diff --git a/gcc/regcprop.c b/gcc/regcprop.c
index e1342f56bd1..02753a12510 100644
--- a/gcc/regcprop.c
+++ b/gcc/regcprop.c
@@ -474,7 +474,8 @@ find_oldest_value_reg (enum reg_class cl, rtx reg, struct
value_data *vd)
(set (...) (reg:DI r9))
Replacing r9 with r11 is invalid. */
if (mode != vd->e[regno].mode
- && REG_NREGS (reg) > hard_regno_nregs (regno, vd->e[regno].mode))
+ && (REG_NREGS (reg) > hard_regno_nregs (regno, vd->e[regno].mode)
+ || !REG_CAN_CHANGE_MODE_P (regno, mode, vd->e[regno].mode)))
return NULL_RTX;
for (i = vd->e[regno].oldest_regno; i != regno; i = vd->e[i].next_regno)
Any thoughts about this fix?
[Bug rtl-optimization/99221] copyprop_hardreg_forward_1 deletes insn by mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99221 --- Comment #1 from Stefan Schulze Frielinghaus --- Created attachment 50243 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50243&action=edit a-foo.i.307r.cprop_hardreg
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #32 from Martin Sebor --- The "arg spec" attribute also needs to be removed from the function arguments. Let me take care of that.
[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-23 Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org Ever confirmed|0 |1 CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- Confirmed. The proposed fix works. I sent the patch to the gcc-patches list: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565732.html Hau Hsu, can you confirm your name and email address are OK in the ChangeLog entry? Thanks
[Bug c++/97145] Sanitizer pointer-subtract breaks constexpr functions subtracting pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97145 Paweł Bylica changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paweł Bylica --- This looks to be fixed in trunk. Thanks.
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 --- Comment #7 from Alexander Lelyakin --- I write a shell script to try to compile c++ system headers in random order: Results so far: Shortest sequences up to internal compiler error: - type_traits thread - clocale barrier - Longest sequence is: - stop_token ccomplex version cassert csetjmp condition_variable shared_mutex csignal map cstdalign bitset scoped_allocator codecvt barrier span mutex optional ctgmath cstdio typeindex cctype cwctype cfloat iosfwd iostream Anyway there is no way to compile all system headers :(
[Bug c++/99222] New: [modules] system header-unit ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99222 Bug ID: 99222 Summary: [modules] system header-unit ICEs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Another, shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header new g++ -std=c++20 -fmodules-ts -x c++-system-header initializer_list g++ -std=c++20 -fmodules-ts -x c++-system-header typeinfo g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits g++ -std=c++20 -fmodules-ts -x c++-system-header exception /usr/local/include/c++/11.0.0/exception: internal compiler error: in write_cluster, at cp/module.cc:14600 0x6e2d56 module_state::write_cluster(elf_out*, depset**, unsigned int, depset::hash&, unsigned int*, unsigned int*) ../../gcc/gcc/cp/module.cc:14600 0xa62be8 module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17734 0xa638fc finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19860 0x9f72cb c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175
[Bug target/99083] Big run-time regressions of 519.lbm_r with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083 --- Comment #12 from Martin Jambor --- For the record, I have benchmarked the patches from comment #4 and comment #10 on top of commit 6b1633378b7 (for which I already have unpatched benchmark results) and the regression of 519.lbm_r compiled with -O2 LTO dropped from 62% to 8%. The -Ofast -march=native -flto vs. non-LTO regression also dropped from 8% to about 5% (GCC 10 also has non-LTO 2.5% faster than LTO, but at least both times improved vs. GCC 10). The only notable regression brought about the patch was 538.imagick_r when compiled at -Ofast -march=native without LTO, which was 6% slower with the patch. All of the measurements were done on a Zen2 machine. Thank you for reverting the patch, now we need to look for LNT to pick up the changes.
[Bug c++/99223] New: [modules] stdl header-unit ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99223 Bug ID: 99223 Summary: [modules] stdl header-unit ICE Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- I have found two another sequences of system headers that cannot be compiled: - g++ -std=c++20 -fmodules-ts -x c++-system-header utility g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm g++ -std=c++20 -fmodules-ts -x c++-system-header iostream g++ -std=c++20 -fmodules-ts -x c++-system-header ranges g++ -std=c++20 -fmodules-ts -x c++-system-header vector g++ -std=c++20 -fmodules-ts -x c++-system-header array g++ -std=c++20 -fmodules-ts -x c++-system-header string g++ -std=c++20 -fmodules-ts -x c++-system-header functional -- g++ -std=c++20 -fmodules-ts -x c++-system-header concepts g++ -std=c++20 -fmodules-ts -x c++-system-header functional g++ -std=c++20 -fmodules-ts -x c++-system-header ranges g++ -std=c++20 -fmodules-ts -x c++-system-header vector g++ -std=c++20 -fmodules-ts -x c++-system-header string g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm --
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 --- Comment #8 from Nathan Sidwell --- 99222 and 99223 filed. Please file each case as a separate issue. So far, they've all been different underlying causes. It might make sense to have a meta-bug referring to this class of issue.
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a6c7e0fcffc857e67dffdd7609be663cc3aac7d2 commit r11-7348-ga6c7e0fcffc857e67dffdd7609be663cc3aac7d2 Author: Harald Anlauf Date: Tue Feb 23 19:09:14 2021 +0100 PR fortran/99206 - ICE in add_init_expr_to_sym, at fortran/decl.c:1980 Make sure that the string length is properly set during simplification even when the resulting array is zero-sized. gcc/fortran/ChangeLog: PR fortran/99206 * simplify.c (gfc_simplify_reshape): Set string length for character arguments. gcc/testsuite/ChangeLog: PR fortran/99206 * gfortran.dg/reshape_zerosize_4.f90: New test.
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e111925dbddb63ca1ee9e43412c7e896ba5c1105 commit r10-9385-ge111925dbddb63ca1ee9e43412c7e896ba5c1105 Author: Harald Anlauf Date: Sun Feb 21 21:44:24 2021 +0100 PR fortran/99169 - Do not clobber allocatable intent(out) dummy argument gcc/fortran/ChangeLog: * trans-expr.c (gfc_conv_procedure_call): Do not add clobber to allocatable intent(out) argument. gcc/testsuite/ChangeLog: * gfortran.dg/intent_optimize_3.f90: New test. (cherry picked from commit 2df374b337a5f6cf5528e91718e4e12e4006b7ae)
[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718
--- Comment #2 from Nathan Sidwell ---
reduced testcase:
// b_a.ii
module ;
# 4 "inc_a" 1
#define _GLIBCXX_VISIBILITY(V) __attribute__ ((__visibility__ (#V)))
namespace std _GLIBCXX_VISIBILITY(default)
{
}
# 11 "" 2
export module hello:format;
// b_b.ii
module ;
# 4 "inc_b" 1
#define _GLIBCXX_VISIBILITY(V) __attribute__ ((__visibility__ (#V)))
#define _GLIBCXX_BEGIN_NAMESPACE_VERSION
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
}
# 11 "" 2
export module hello;
export import :format;
zathras:210>./cc1plus -std=c++20 -fmodules-ts -quiet -fpreprocessed
-fdirectives-only b_a.ii && ./cc1plus -std=c++20 -fmodules-ts -quiet
-fpreprocessed -fdirectives-only b_b.ii
b_b.ii:12:9: internal compiler error: in write_macro_maps, at
cp/module.cc:16154
12 | export module hello;
| ^~
0xce1ab0 module_state::write_macro_maps(elf_out*, location_map_info&,
module_state_config*, unsigned int*)
../../../src/gcc/cp/module.cc:16154
0xce662b module_state::write(elf_out*, cpp_reader*)
../../../src/gcc/cp/module.cc:17771
0xcec7d8 finish_module_processing(cpp_reader*)
../../../src/gcc/cp/module.cc:19860
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:baf4c27c8754c1f7bbad3f577a4bd890528c0e75 commit r9-9247-gbaf4c27c8754c1f7bbad3f577a4bd890528c0e75 Author: Harald Anlauf Date: Sun Feb 21 21:44:24 2021 +0100 PR fortran/99169 - Do not clobber allocatable intent(out) dummy argument gcc/fortran/ChangeLog: * trans-expr.c (gfc_conv_procedure_call): Do not add clobber to allocatable intent(out) argument. gcc/testsuite/ChangeLog: * gfortran.dg/intent_optimize_3.f90: New test. (cherry picked from commit 2df374b337a5f6cf5528e91718e4e12e4006b7ae)
[Bug c/99224] New: [9/10/11 Regression] ICE in location_wrapper_p, at tree.h:4052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99224
Bug ID: 99224
Summary: [9/10/11 Regression] ICE in location_wrapper_p, at
tree.h:4052
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r6 :
$ cat z1.c
void f (char *c, ...)
{
__builtin_next_arg (*c);
}
$ gcc-11-20210221 -c z1.c
during RTL pass: expand
z1.c: In function 'f':
z1.c:3:3: internal compiler error: Segmentation fault
3 | __builtin_next_arg (*c);
| ^~~
0xb5eaff crash_signal
../../gcc/toplev.c:327
0xdd3254 location_wrapper_p(tree_node const*)
../../gcc/tree.h:4052
0xdd3254 tree_strip_any_location_wrapper(tree_node*)
../../gcc/tree.h:4064
0xdd3254 integer_zerop(tree_node const*)
../../gcc/tree.c:2664
0x72d9c7 fold_builtin_next_arg(tree_node*, bool)
../../gcc/builtins.c:12606
0x73a149 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.c:9725
0x85d220 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11276
0x75e65a expand_expr
../../gcc/expr.h:282
0x75e65a expand_call_stmt
../../gcc/cfgexpand.c:2840
0x75e65a expand_gimple_stmt_1
../../gcc/cfgexpand.c:3844
0x75e65a expand_gimple_stmt
../../gcc/cfgexpand.c:4008
0x763237 expand_gimple_basic_block
../../gcc/cfgexpand.c:6045
0x76596e execute
../../gcc/cfgexpand.c:6729
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline. Thanks for the report!
[Bug c/99225] New: ICE in wide_int_to_tree_1, at tree.c:1644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99225
Bug ID: 99225
Summary: ICE in wide_int_to_tree_1, at tree.c:1644
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
$ cat z1.c
#define vector __attribute__((vector_size(16)))
int f ()
{
vector int a = {0, 0, 0, 0};
vector int b = {1, 0, 0, 0};
return (a & (1 << b)) != 0;
}
$ gcc-11-20210221 -c z1.c
z1.c: In function 'f':
z1.c:6:3: internal compiler error: in wide_int_to_tree_1, at tree.c:1644
6 | return (a & (1 << b)) != 0;
| ^~
0xde3e1e wide_int_to_tree_1
../../gcc/tree.c:1644
0xde433b wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
../../gcc/tree.c:1756
0xde433b build_int_cst(tree_node*, poly_int<1u, long>)
../../gcc/tree.c:1396
0x8945ea fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12048
0x894caa fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:13715
0x69e80b c_fully_fold_internal
../../gcc/c/c-fold.c:371
0x69e00d c_fully_fold_internal
../../gcc/c/c-fold.c:623
0x69f0a9 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x65c2cd c_finish_return(unsigned int, tree_node*, tree_node*)
../../gcc/c/c-typeck.c:10742
0x6918b6 c_parser_statement_after_labels
../../gcc/c/c-parser.c:6162
0x69339a c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5788
0x693c13 c_parser_compound_statement
../../gcc/c/c-parser.c:5597
0x6954c8 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2539
0x69c337 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x69ce59 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x69ce59 c_parse_file()
../../gcc/c/c-parser.c:21984
0x6eccc2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1218
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on 10- and 9-branches. Thanks for the report!
[Bug fortran/99226] New: [11 Regression] ICE in expand_expr_real_1, at expr.c:10279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99226 Bug ID: 99226 Summary: [11 Regression] ICE in expand_expr_real_1, at expr.c:10279 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20200531 and 20200607, at -O1+ : (compiles with single loop) $ cat z1.f90 subroutine sub (n) integer :: n, i !$omp target !$omp teams distribute dist_schedule (static,n+4) do i = 1, 8 end do !$omp teams distribute dist_schedule (static,n+4) do i = 1, 8 end do !$omp end target end $ gfortran-11-20200531 -c z1.f90 -fopenmp -O2 $ gfortran-11-20210221 -c z1.f90 -fopenmp -O0 $ $ gfortran-11-20210221 -c z1.f90 -fopenmp -O2 during RTL pass: expand z1.f90:3:15: 3 |!$omp target | ^ internal compiler error: in expand_expr_real_1, at expr.c:10279 0x90a988 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10273 0x907ca7 expand_expr ../../gcc/expr.h:282 0x907ca7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10600 0x907528 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10848 0x909312 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10208 0x907ca7 expand_expr ../../gcc/expr.h:282 0x907ca7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10600 0x909312 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10208 0x912dd3 store_expr(tree_node*, rtx_def*, int, bool, bool) ../../gcc/expr.c:5886 0x914265 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5622 0x809060 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3910 0x809060 expand_gimple_stmt ../../gcc/cfgexpand.c:4008 0x80e257 expand_gimple_basic_block ../../gcc/cfgexpand.c:6045 0x81098e execute ../../gcc/cfgexpand.c:6729
[Bug c++/99227] New: [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug ID: 99227 Summary: [meta] [modules] Bugs relating to header-units of STL header files Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Capture bugs related to building the standard library headers as header-units
