[Bug c++/99215] New: coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 Bug ID: 99215 Summary: coroutines: debugging with gdb Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nilsgladitz at gmail dot com Target Milestone: --- 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. 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.
[Bug c++/99214] Incorrect template arguments shown in constraint satisfaction failure diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99214 --- Comment #1 from Patrick Palka --- Changed with r11-2774.
[Bug c++/99214] New: Incorrect template arguments shown in constraint satisfaction failure diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99214
Bug ID: 99214
Summary: Incorrect template arguments shown in constraint
satisfaction failure diagnostic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
struct A {
template static void f() requires ([] { return U::fail; }());
template static void f();
};
int main() {
A::f();
}
$ cat testcase.C | g++-11 -std=c++20 -x c++ -
: In substitution of ‘template static void A::f()
requires ()() [with U = int]’:
:8:19: required from here
:3:63: error: ‘fail’ is not a member of ‘char’
In the above diagnostic, the "in substitution of" context line incorrectly
shows "U = int" instead of "U = char".
GCC 10 shows the correct template arguments:
$ cat testcase.C | g++-10 -std=c++20 -x c++ -
: In instantiation of ‘static void A::f() requires ()() [with
U = char; T = int]’:
:8:19: required from here
:3:63: error: ‘fail’ is not a member of ‘char’
[Bug c++/99213] Incorrect pretty printing of local class type when type's context contains a class template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99213 --- Comment #1 from Patrick Palka --- "Started" with r10-7705. Fixing this is necessary for comprehensible diagnostics when using range adaptor objects from , since their partial application and composition operators work by returning local lambdas.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #5 from gcc-user at riseup dot net --- Starting with gcc-10 gentoo is not going to enable --enable-vtable-verify by default anymore. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63c16d8b5e71b5f8e6185965062cf9c836800c29
[Bug c++/99213] New: Incorrect pretty printing of local class type when type's context contains a class template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99213
Bug ID: 99213
Summary: Incorrect pretty printing of local class type when
type's context contains a class template
specialization
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
Consider:
template
struct A {
template
static auto f() {
struct S{};
return S{};
}
};
using type = void;
using type = decltype(A::f()); // A::f()::S
For this testcase, GCC 10/11 outputs:
:11:7: error: conflicting declaration 'using type = struct
A::f::S'
11 | using type = decltype(A::f());
| ^~~~
Note that the nested class type 'S' gets pretty printed as 'A::f::S',
i.e. the argument for the template parameter T is missing in the
nested-name-specifier.
GCC 9 outputs:
:11:7: error: conflicting declaration 'using type = struct A::f()
[with U = char; T = int]::S'
11 | using type = decltype(A::f());
| ^~~~
Which isn't perfect either, but importantly all template arguments are shown in
the type.
[Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Bug ID: 99212 Summary: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- For cris-elf, this test has failed as follows, since some change in the range cd0233527af1..0dc80505562c (usual suspects are several gcc/analyzer changes): Running /x/gcc/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ... XPASS: gcc.dg/analyzer/data-model-1.c desired (test for warnings, line 971) FAIL: gcc.dg/analyzer/data-model-1.c status quo (test for warnings, line 971) similarly for pru-unknown-elf: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652712.html and m68k-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652763.html These targets have a couple of structure layout characteristics in common.
[Bug c/99211] New: gcc fails on program which overrides __builtin_clzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99211
Bug ID: 99211
Summary: gcc fails on program which overrides __builtin_clzll
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
GCC fails to compile the attached code: https://godbolt.org/z/sdqq3M
One interesting thing is that, only when we override __builtin_clzll this issue
will occur. If we replace the __builtin_clzll as any other builtin function
(e.g., __builtin_expect), GCC will accept the program with a conflicting type
warning: https://godbolt.org/z/5c45T6
For other compilers,
Clang rejects such conflicts with built-in functions:
https://godbolt.org/z/9WzTKP
Icc accepts and successfully compiles it (with warnings):
https://godbolt.org/z/W4zK89
$ cat test.c
struct S {
int a;
};
struct S __builtin_clzll(long x) {
if (x == 1) {
struct S y = { .a = 1 };
return y;
} else {
struct S y = { .a = __builtin_clzll(1).a + 1 };
return y;
}
}
int main() {
return __builtin_clzll(10).a;
}
$ gcc test.c
test.c: In function '__builtin_clzll':
test.c:10:16: internal compiler error: in wide_int_to_tree_1, at tree.c:1644
10 | struct S y = { .a = __builtin_clzll(1).a + 1 };
|^
0x1a31d99 internal_error(char const*, ...)
???:0
0x6877ad fancy_abort(char const*, int, char const*)
???:0
0x9bed4a fold_build_call_array_loc(unsigned int, tree_node*, tree_node*, int,
tree_node**)
???:0
0x6e1010 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*)
???:0
0x7322e9 c_parse_file()
???:0
0x7a02c2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Patrick Palka --- Fixed for GCC 10.3/11 by reverting the problematic part of the commit that introduced this regression.
[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Hans-Peter Nilsson changed: What|Removed |Added Last reconfirmed|2015-07-01 00:00:00 |2021-2-23 --- Comment #14 from Hans-Peter Nilsson --- Still there at r11-7328 aka. 8e99b5ba4c19
[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org Status|WAITING |NEW Last reconfirmed|2020-10-16 00:00:00 |2021-2-23 Target|powerpc64*-linux-gnu arm|powerpc64*-linux-gnu, arm, ||cris, mmix, pru, moxie, ||m68k --- Comment #6 from Hans-Peter Nilsson --- I was just about to open a new bug-report with the following observations, some of which are not redundant: Since commit 5acc654e3807 / r11-1517 the test gcc.dg/Wstringop-overflow-25.c has failed for cris-elf as follows, still at 8e99b5ba4c19 / r11-7328: Running /x/gcc/gcc/testsuite/gcc.dg/dg.exp ... ... (elided lines) FAIL: gcc.dg/Wstringop-overflow-25.c pr92814 (test for warnings, line 378) The emitted warnings for the other lines of this tests are the same for cris-elf as for x86_64-pc-linux-gnu (where the test passes). There's no apparent reason for this difference. For example, it doesn't seem to have to do with alignment or structure layout. The same missing error on the same line can be seen for targets with widely different characteristics, like for mmix-knuth-mmixware: https://gcc.gnu.org/pipermail/gcc-testresults/2020-August/583266.html and powerpc64le-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652702.html and pru-unknown-elf: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652712.html and moxie-unknown-elf: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652743.html and m68k-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652763.html but not for i686-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652708.html nor aarch64-none-elf -mabi=ilp32: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652767.html nor arm-none-eabi DEFCPU=cortex-a9: https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652814.html
[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 #10 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:198c56052ea8cce4196e60c0dc3187bf3d67a786 commit r11-7337-g198c56052ea8cce4196e60c0dc3187bf3d67a786 Author: Patrick Palka Date: Mon Feb 22 21:49:25 2021 -0500 libstdc++: Fix endianness issue with IBM long double [PR98384] The code in std::to_chars for extracting the high- and low-order parts of an IBM long double value does the right thing on powerpc64le, but not on powerpc64be. This patch makes the extraction endian-agnostic, which fixes the execution FAIL of to_chars/long_double.cc on powerpc64be. libstdc++-v3/ChangeLog: PR libstdc++/98384 * src/c++17/floating_to_chars.cc (get_ieee_repr): Extract the high- and low-order parts from an IBM long double value in an endian-agnostic way.
[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 --- Comment #4 from Jiangning Liu --- Hi Honza, Do you see any other real case problems if the patch g:1118a3ff9d3ad6a64bba25dc01e7703325e23d92 is not applied? If exchange2 is the only one affected by this patch so far, and because we have observed big performance regression, it sounds we need to provide an IRA fix along with this patch to avoid unexpected performance degradation for gcc11 release vs. gcc10. Thanks, -Jiangning
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Jerry DeLisle changed: What|Removed |Added Last reconfirmed||2021-02-23 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I will take this one. I need to investigate a bit, I can reproduce the results shown.
[Bug fortran/98897] Erroneous procedure attribute for associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897 --- Comment #8 from Damian Rouson --- Thanks, Paul and Tobias!
[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Should be fixed by the above commit
[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5ee4ba031dd9fc60bf2494ca30f46c0acaa34805 commit r11-7333-g5ee4ba031dd9fc60bf2494ca30f46c0acaa34805 Author: David Malcolm Date: Mon Feb 22 18:46:05 2021 -0500 analyzer: handle error/error_at_line [PR99196] PR analyzer/99196 describes a false positive from -fanalyzer due to the analyzer not "knowing" that calls to GNU libc's error(3) with a nonzero status terminate the process and thus don't return. This patch fixes the false positive by special-casing "error" and "error_at_line". gcc/analyzer/ChangeLog: PR analyzer/99196 * engine.cc (exploded_node::on_stmt): Provide terminate_path flag as a way for on_call_pre to terminate the current analysis path. * region-model-impl-calls.cc (call_details::num_args): New. (region_model::impl_call_error): New. * region-model.cc (region_model::on_call_pre): Add param "out_terminate_path". Handle "error" and "error_at_line". * region-model.h (call_details::num_args): New decl. (region_model::on_call_pre): Add param "out_terminate_path". (region_model::impl_call_error): New decl. gcc/testsuite/ChangeLog: PR analyzer/99196 * gcc.dg/analyzer/error-1.c: New test. * gcc.dg/analyzer/error-2.c: New test. * gcc.dg/analyzer/error-3.c: New test.
[Bug testsuite/99173] [11 Regression] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from H.J. Lu --- Fixed.
[Bug bootstrap/98181] Add support for FreeBSD on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98181 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- I should have looked if there was a PR for this, sorry. This was: commit 2a4183234a45ba28db5ce16cf3ccdd70cdef3b7c Author: Piotr Kubaj AuthorDate: Wed Dec 16 22:26:18 2020 + Commit: Segher Boessenkool CommitDate: Wed Dec 16 22:54:51 2020 + rs6000: Add support for powerpc64le-unknown-freebsd This implements support for powerpc64le architecture on FreeBSD. Since we don't have powerpcle (32-bit), I did not add support for powerpcle here. This remains to be changed if there is powerpcle support in the future. 2020-12-15 Piotr Kubaj gcc/ * config.gcc (powerpc*le-*-freebsd*): Add. * configure.ac (powerpc*le-*-freebsd*): Ditto. * configure: Regenerate. * config/rs6000/freebsd64.h (ASM_SPEC_COMMON): Use ENDIAN_SELECT. (DEFAULT_ASM_ENDIAN): Add little endian support. (LINK_OS_FREEBSD_SPEC64): Ditto.
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138 --- Comment #5 from Tobias Burnus --- The following fails the same way: module m interface module function f() class(*), allocatable :: f(:) end end interface contains module function f(x) class(*), allocatable :: f(:) end function end Except that the fail is now in resolve.c, but again when accessing 'CLASS_DATA (sym)->'.
[Bug testsuite/99173] [11 Regression] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 --- Comment #5 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:609204abb889166c17a600121ba8ced18db2567a commit r11-7332-g609204abb889166c17a600121ba8ced18db2567a Author: H.J. Lu Date: Fri Feb 19 15:44:38 2021 -0800 Require SHF_GNU_RETAIN support for retain tests Since retain attribute requires SHF_GNU_RETAIN, run retain tests only if SHF_GNU_RETAIN is supported. PR testsuite/99173 * c-c++-common/attr-retain-5.c: Require R_flag_in_section. * c-c++-common/attr-retain-6.c: Likewise. * c-c++-common/attr-retain-7.c: Likewise. * c-c++-common/attr-retain-8.c: Likewise. * c-c++-common/attr-retain-9.c: Likewise.
[Bug c++/99176] [8/9/10/11 Regression] GCC rejects const_cast of null pointer in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99176 --- Comment #3 from Marek Polacek --- Same problem for: constexpr int* ptr = (int *) (const int *) nullptr;
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Serguei E. Leontiev changed: What|Removed |Added CC||leo at sai dot msu.ru --- Comment #1 from Serguei E. Leontiev --- Created attachment 50239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50239=edit Output and error of example
[Bug libfortran/99210] New: X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Bug ID: 99210 Summary: X editing for reading file with encoding='utf-8' Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: leo at sai dot msu.ru Target Milestone: --- Created attachment 50237 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50237=edit Example bug 1x editing for utf-8 encoding file nX edit must skip n characters. For files encoding='utf-8', skip n ISO/IEC 10646 characters. But now, nX edit is skipping n bytes. And may cause "Fortran runtime error: Invalid UTF-8 encoding" for valid UTF-8 files.
[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-22 --- Comment #6 from David Malcolm --- Thanks for filing this; confirmed. I'm working on a fix.
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
--- Comment #8 from m.cencora at gmail dot com ---
It does not matter whether A constructor is default or empty. If class instance
cannot be constant-initialized then dynamic initialization will take place.
I think gcc just incorrectly performs constant initialization in these
scenarios.
clang reports error as expected:
struct A
{
int value;
};
struct B
{
int value;
B() = default;
};
constinit A a;
constinit B b;
[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
--- Comment #58 from Martin Sebor ---
Jeff's POC also suggests a workaround: changing the type of
_Optional_payload_base::_M_engaged from bool to unsigned char avoids the
VIEW_CONVERT_EXPR and avoids the warning. The difference in the uninit IL is
below but there's no difference in the assembly.
{
- unsigned char maybe_a$4;
+ unsigned char maybe_a$_M_payload$D12141$D11991$_M_engaged;
int maybe_a$m_val;
struct optional maybe_b;
struct optional maybe_a;
- bool _11;
- bool _12;
+ unsigned char _11;
int _29;
- bool _32;
+ unsigned char _32;
[local count: 1073741824]:
maybe_b = {};
@@ -53,7 +52,7 @@
[count: 0]:
# maybe_a$m_val_51 = PHI <_29(6), maybe_a$m_val_38(D)(8)>
- # maybe_a$4_54 = PHI <1(6), 0(8)>
+ # maybe_a$_M_payload$D12141$D11991$_M_engaged_54 = PHI <1(6), 0(8)>
:
_11 = MEM[(struct _Optional_payload_base *)_b]._M_engaged;
if (_11 != 0)
@@ -74,8 +73,7 @@
[count: 0]:
:
- _12 = VIEW_CONVERT_EXPR(maybe_a$4_54);
- if (_12 != 0)
+ if (maybe_a$_M_payload$D12141$D11991$_M_engaged_54 != 0)
goto ; [0.00%]
else
goto ; [0.00%]
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 --- Comment #3 from Mark Wielaard --- So if the compiler would emit the .debug_name index would that make any link/post-processing steps easier or more efficient?
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
--- Comment #7 from kal.conley at dectris dot com ---
There is no fiasco here because the default constructor of `A` does no dynamic
initialization. If the definition of `A` is changed to:
struct A {
int value;
};
then the error goes away. However, in both cases there is the same
implicitly-defined default constructor generated by the compiler. Explicitly
declaring `A() = default` should not change anything in this regard. Generating
an error in this case is not useful.
[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|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-February/055745.html
[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 #4 from Matthias Kretz (Vir) ---
Manual reduction which fails with 8-11 and compiles ok with 7:
template
void
test_values_2arg(F&&... fun_pack)
{
(fun_pack(V(), V()), ...);
}
template
auto
make_tester(const TestF& testfun, const RefF& reffun)
{
return [=](auto... inputs) {
auto totest = reffun(inputs...);
using R = decltype(totest);
auto&& expected = [&](const auto&... vs) {
if constexpr (sizeof(R) > 0)
return [&](auto i) { return reffun(vs[i]...); }(0);
else
return [&](auto i) { return reffun(vs[i]...); }(0);
};
};
}
template T foo(T, T) {
}
int main()
{
test_values_2arg(make_tester(
[](auto... xs) { return foo(xs...); },
[](auto... xs) { return foo(xs...); }));
return 0;
}
[Bug c++/99209] lambdas in function template signatures instantiated with wrong semantic context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99209
--- Comment #1 from Richard Smith ---
Here's a more interesting example: https://godbolt.org/z/83c36q
#include
constexpr char f(...) { return 'g'; }
constexpr decltype(auto) f_adl(auto a) { return f(a); }
namespace A {
constexpr char f(auto) { return 'A'; }
template void g(char FunctionParam =
f_adl([]{})) {
char Local = f_adl([]{});
std::cout << TemplateParam << FunctionParam << Local;
}
}
namespace B {
constexpr char f(auto) { return 'B'; }
void call() { A::g(); }
}
int main() { B::call(); }
This prints 'BgA', but should print 'AAA'. So the three lambdas actually
exhibit three different behaviors, not two.
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185 --- Comment #6 from m.cencora at gmail dot com --- Now that I think about and having read relevant chapters of C++20 spec, observed behavior seems to be expected. A cannot be constant initialized (because it has missing initializer for 'value' member) so at first zero-initialization is performed as part of static initialization, then A constructor is called as part of dynamic initialization.
[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 --- Comment #7 from Iain Sandoe --- patch posted : https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565649.html
[Bug c++/99209] New: lambdas in function template signatures instantiated with wrong semantic context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99209
Bug ID: 99209
Summary: lambdas in function template signatures instantiated
with wrong semantic context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
constexpr decltype(auto) f_adl(auto a) { return f(a); }
namespace A {
constexpr int f(auto) { return 0; }
template void g(int = f_adl([]{})) {
f_adl([]{});
}
}
int main() {
A::g();
}
Here, the f_adl calls for the default template argument and default function
argument incorrectly result in errors, because f can't be found by ADL.
I suspect this is because the lambdas are being created in the wrong semantic
context. (That is also visible in the output of __PRETTY_FUNCTION__ /
std::source_location::current().function_name() in the lambda and in the
mangling of the lambda closure type, but I think both of those are valid
implementation choices -- the function name is implementation-defined and such
instantiated lambdas appear to be numbered after those lambdas for which the
ABI requires a numbering).
[Bug libstdc++/90857] stl::forward_list::erase_after crashes if __pos == __last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90857 --- Comment #4 from Jonathan Wakely --- It was pointed out on IRC that splice_after is affected the same way (if we change anything for erase_after we should do the same for splice_after).
[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 CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Potential fix that sets the string length (not regtested): diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c index 35f267db588..388aca7c38c 100644 --- a/gcc/fortran/simplify.c +++ b/gcc/fortran/simplify.c @@ -6887,6 +6887,8 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shape_exp, >where); if (source->ts.type == BT_DERIVED) result->ts.u.derived = source->ts.u.derived; + if (source->ts.type == BT_CHARACTER && result->ts.u.cl == NULL) +result->ts = source->ts; result->rank = rank; result->shape = gfc_get_shape (rank); for (i = 0; i < rank; i++)
[Bug libfortran/98301] random_init() is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 --- Comment #7 from Steve Kargl --- On Mon, Feb 22, 2021 at 06:57:03PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 > > --- Comment #6 from Steve Kargl --- > On Mon, Feb 22, 2021 at 04:36:50AM +, jvdelisle at gcc dot gnu.org wrote: > > > > --- Comment #5 from Jerry DeLisle --- > > Steve, if you think this does it. I will get it ready to commit for you. > > Does > > it also need to be back ported? > > > > Well, I think it is correct for at least what I've been > able to test! I don't use co-arrays, so do not have > OpenCoarray or the shared-memory WIP installed. For, > -fcoarray=lib or -fcoarray=shared, function calls are > generated. These are currently unimplimented and need > to be implemented in such a manner as the function calls > are aware of the underlying coarray implemention. I > don't remember the details, but I recall that the images > need to communicate about the seeds. > Oh, one last item. This patch will likely break gfortran+opencoarray because _gfortran_caf_random_init is missing, and therefore will prevent linking of the program.
[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 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 50236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50236=edit gcc11-pr99204.patch Untested fix. This does what similar code in expand_expr_real_1 does.
[Bug libfortran/98301] random_init() is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 --- Comment #6 from Steve Kargl --- On Mon, Feb 22, 2021 at 04:36:50AM +, jvdelisle at gcc dot gnu.org wrote: > > --- Comment #5 from Jerry DeLisle --- > Steve, if you think this does it. I will get it ready to commit for you. Does > it also need to be back ported? > Well, I think it is correct for at least what I've been able to test! I don't use co-arrays, so do not have OpenCoarray or the shared-memory WIP installed. For, -fcoarray=lib or -fcoarray=shared, function calls are generated. These are currently unimplimented and need to be implemented in such a manner as the function calls are aware of the underlying coarray implemention. I don't remember the details, but I recall that the images need to communicate about the seeds.
[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 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Summary|ICE in |[8/9/10/11 Regression] ICE |fold_read_from_constant_str |in |ing, at fold-const.c:15441 |fold_read_from_constant_str ||ing, at fold-const.c:15441 Component|fortran |tree-optimization Priority|P3 |P2 Target Milestone|--- |8.5 --- Comment #5 from Jakub Jelinek --- Started between r0-72863-g2b9a33aeea3d49f4e7038ecdc9d96b6220593d15 and r0-72892-g00b79d543df80369bf196b27fbaa55cd197d6f92
[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 #2 from anlauf at gcc dot gnu.org --- As a sidenote: print *, len (reshape (['a'], [0])) end This prints 0 for gcc-11, and the correct value 1 for 10.2.1. Do we screw up things during simplification?
[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 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-22
[Bug c++/99208] New: [modules] ICE with partitions & instantiations of linkage-typedef structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99208
Bug ID: 99208
Summary: [modules] ICE with partitions & instantiations of
linkage-typedef structs
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: ---
Triaging 98718 ran into this:
// b_a.ii
module;
# 3 "b_a.ii" 1
typedef struct {} __mbstate_t;
template class fpos;
# 6 "" 2
export module hello:format;
export void format (const fpos<__mbstate_t> &);
// b_b.ii
export module hello;
export import :format;
zathras:94>./cc1plus -quiet -fmodules-ts b_a.ii && ./cc1plus -quiet
-fmodules-ts b_b.ii
b_b.ii:1:8: internal compiler error: in insert, at cp/module.cc:4904
1 | export module hello;
|^~
0xcb1949 trees_out::insert(tree_node*, walk_kind)
../../../src/gcc/cp/module.cc:4904
0xcbaf8f trees_out::add_indirects(tree_node*)
../../../src/gcc/cp/module.cc:7328
0xcc1f6a trees_out::decl_node(tree_node*, walk_kind)
../../../src/gcc/cp/module.cc:8677
0xcc41c1 trees_out::tree_node(tree_node*)
../../../src/gcc/cp/module.cc:9179
0xcb1e4e trees_out::vec_chained_decls(tree_node*)
../../../src/gcc/cp/module.cc:4992
0xcd17a0 trees_out::write_class_def(tree_node*)
../../../src/gcc/cp/module.cc:11748
0xcd5947 trees_out::write_definition(tree_node*)
../../../src/gcc/cp/module.cc:12356
0xcd9299 depset::hash::find_dependencies(module_state*)
../../../src/gcc/cp/module.cc:13238
0xce60ed module_state::write(elf_out*, cpp_reader*)
../../../src/gcc/cp/module.cc:17611
0xcec92c finish_module_processing(cpp_reader*)
../../../src/gcc/cp/module.cc:19860
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138
--- Comment #4 from Tobias Burnus ---
(In reply to Paul Thomas from comment #3)
> Is the problem not that the parser is not picking up the incorrectly placed
> print statement? It should never be passed to the matcher because it is in
> the contains context.
Ups. I mess up my visual parser ... – Yes, I concur that rvalue matching should
not happen (only some 'end' – or 'subroutine'/'[type-spec|(im)pure|...]
function' is permitted – unless it is 'type; ...; contains' which has some
other permitted values or ...
The current code has:
parse_contained()
st = next_statement ();
switch (st)
{
case ST_NONE:
case ST_FUNCTION:
case ST_SUBROUTINE:
case ST_END_FUNCTION:
case ST_END_MODULE:
case ST_END_SUBMODULE:
case ST_END_PROGRAM:
case ST_END_SUBROUTINE:
...
default:
gfc_error ("Unexpected %s statement in CONTAINS section at %C",
gfc_ascii_statement (st));
It sounds as if you want to have something which only tries to match those –
and then simply stops with an error at the the end, pointing to the line
without trying to parse it. — That would avoid a lot of 'gfc_error' which are
silenced and speeds up parsing (not that it is really the bottle neck).
[Bug target/66171] [8/9/10/11 Regression]: gcc.target/cris/biap.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66171 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|8.5 |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #11 from Hans-Peter Nilsson --- Whoops, forgot about this PR. Anyway, fixed with 6cb68940dcf9d alias r11-7325.
[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 Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||10.2.1 Known to fail||11.0 Ever confirmed|0 |1 Last reconfirmed||2021-02-22 Target Milestone|--- |11.0 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. gcc-10 emits an appropriate error message for z1 and accepts z2.
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185 --- Comment #5 from kal.conley at dectris dot com --- I don't think this has anything to do with C++20. The behavior doesn't change when compiling for C++17. In any case, `g` should be static initialized with zeros and no dynamic initialization in `a.cc` should take place.
[Bug fortran/99204] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > WORKSFORME: > > % gfc pr99204.f90 The issue really depends on optimization. Confirmed for all tested -O greater than -O0: -Og, -O, -Os, -O2, -O3. It disappears when declaring i volatile, as in integer, volatile :: i = -12345678
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138 --- Comment #3 from Paul Thomas --- (In reply to Tobias Burnus from comment #2) > Confirmed – with 'class(*), allocatable :: f(:)' it should be valid (with > prior assignment). > > The problem is in gfc_match_rvalue: > > 3737 if (sym->ts.type == BT_CLASS && sym->attr.class_ok > 3738 && CLASS_DATA (sym)->as) > > without submodules, we have: > sym->ts.u.derived->components->as > which is working (and either NULL in the original example or != NULL with my > modification). > > However, with submodules, > sym->ts.u.derived->components > is NULL, i.e. 'sym->ts.u.derived' (name = "STAR") does not have any > scomponents, but it should have two, _data and _vptr! Hi Tobias, Is the problem not that the parser is not picking up the incorrectly placed print statement? It should never be passed to the matcher because it is in the contains context. It also should said that it has everything to do with module procedures and nothing to do with submodules. This has the same error sequence: module m interface module function f(x) integer, intent(in) :: x class(*), allocatable :: f end end interface contains module function f(x) integer, intent(in) :: x class(*), allocatable :: f end function print *, f(3) end I suspect that the end function is not popping the level. Cheers Paul
[Bug fortran/99204] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 --- Comment #3 from G. Steinmetz --- Strange, for me the ICE is reproducible on different machines and also on https://godbolt.org/ (!) -- always with -O2.
[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196 --- Comment #3 from Richard W.M. Jones --- Note if errcode == 0 then error does NOT exit :-)
[Bug c/99207] #pragma pack(1) and __int128 lead to bad optimization under O2 and higher optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99207 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jakub Jelinek --- That is a user error, don't do that. The fact that d doesn't point to properly aligned object needs to be visible on the pointer dereference location, so you would need to use e.g. aligned(1) attribute on e.g. a typedef to __int128, e.g. typedef __int128 T __attribute__((aligned (1))); T *d = Otherwise it is UB and -fsanitize=undefined would have diagnosed it.
[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 #4 from JoaoBapt --- (In reply to Marek Polacek from comment #2) > Looks like a dup of 93383. No, because it works perfectly when I substitute __PRETTY_FUNCTION__ for any other string literal, even as big as one that would be "returned" by __PRETTY_FUNCTION__ (I tested with, for example, "consteval const char* type_name() [with T = double]" and it did not crash and worked perfectly).
[Bug fortran/99125] [9/10/11 Regression] ICE: gimplification failed (gimplify.c:15068)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125 --- Comment #5 from G. Steinmetz --- I also checked this invalid (probably a known issue) : $ cat za.f90 program p character(:), allocatable :: a(:) character(8) :: c(2) = '12 45 78' a = c print *, a(7:8) end $ gfortran-11-20210221 za.f90 && ./a.out # surprising 12 45 7812 45 78 Detected at runtime : $ gfortran-11-20210221 za.f90 -Wall -fcheck=all && ./a.out za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ Warning: '.a' may be used uninitialized [-Wmaybe-uninitialized] za.f90:4:8: 4 |a = c |^ Warning: 'a.offset' may be used uninitialized [-Wmaybe-uninitialized] za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ note: 'a' declared here za.f90:4:8: 4 |a = c |^ Warning: 'a.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized] za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ note: 'a' declared here za.f90:4:8: 4 |a = c |^ Warning: 'a.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized] za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ note: 'a' declared here za.f90:4:8: 4 |a = c |^ Warning: 'a.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized] za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ note: 'a' declared here za.f90:4:8: 4 |a = c |^ Warning: 'a.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized] za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ note: 'a' declared here za.f90:4:8: 4 |a = c |^ Warning: 'a.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized] za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ note: 'a' declared here za.f90:4:8: 4 |a = c |^ Warning: 'a.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized] za.f90:2:36: 2 |character(:), allocatable :: a(:) |^ note: 'a' declared here At line 5 of file za.f90 Fortran runtime error: Index '7' of dimension 1 of array 'a' outside of expected range (1:2) Error termination. Backtrace: #0 0x4025d1 in ??? #1 0x402738 in ??? #2 0x7fa0f5697f89 in ??? #3 0x4022b9 in ??? at ../sysdeps/x86_64/start.S:120 #4 0x in ??? --- The very basic simplification gives : $ cat zc.f90 program p character(8) :: c(2) = '12 45 78' print *, c(7:8) end $ gfortran-11-20210221 zc.f90 -Wall -fcheck=all && ./a.out zc.f90:3:14: 3 |print *, c(7:8) | 1 Warning: Lower array reference at (1) is out of bounds (7 > 2) in dimension 1 At line 3 of file zc.f90 Fortran runtime error: Index '7' of dimension 1 of array 'c' outside of expected range (1:2) Error termination. Backtrace: #0 0x4023f7 in ??? #1 0x40242b in ??? #2 0x7fc15fc2af89 in ??? #3 0x4022b9 in ??? at ../sysdeps/x86_64/start.S:120 #4 0x in ???
[Bug fortran/99125] [9/10/11 Regression] ICE: gimplification failed (gimplify.c:15068)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125 --- Comment #4 from G. Steinmetz --- > What was the reason for the (7:8) in the testcase? If this question was directed at me, some background : The problem occurred during verification tests, in other code constellation and with other numbers. (7:8) is simply beyond the array extension (1:2). The example in comment #0 was the result of some simplifications in order to get a very simple test case. I wondered about the ICE, and that it could be narrowed down to (well) a time range in the recent past. In the case of a regression, there must be a trigger for the change, and knowing this trigger can be quite helpful. It sometimes happens that there are gray zones where something "works" incorrectly with some numbers, or does not work with other numbers and remains undetected, or is detected with some combinations of options with again other numbers, or leads to an ICE with again other numbers. Cheers, Gerhard
[Bug c/99207] New: #pragma pack(1) and __int128 lead to bad optimization under O2 and higher optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99207
Bug ID: 99207
Summary: #pragma pack(1) and __int128 lead to bad optimization
under O2 and higher optimization
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code behaves differently with different optimizations.
$ cat test.c
#pragma pack(1)
struct {
char a;
__int128 b;
} c;
__int128 *d =
int main() { *d = 0; }
In short, with O2 and higher optimization, gcc tries to use xmm register to
initialize *d. However, as #pragma pack(1) enforces a different alignments, xmm
operation will trigger a segment fault.
O0 (program returns 0): https://godbolt.org/z/nc997z
O1 (program returns 0): https://godbolt.org/z/GqGfnf
O2 (program returns 139): https://godbolt.org/z/4PWKMo
O3 (program returns 139): https://godbolt.org/z/Y81sKK
Os (program returns 139): https://godbolt.org/z/M3KGnh
With asan, we can get: https://godbolt.org/z/34oW7e
AddressSanitizer:DEADLYSIGNAL
=
==1==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x004010ae bp
0x sp 0x7ffd361619b8 T0)
==1==The signal is caused by a READ memory access.
==1==Hint: this fault was caused by a dereference of a high value address (see
register values below). Dissassemble the provided pc to learn which register
was used.
#0 0x4010ae in main example.c:10
#1 0x7f8c4b3b60b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#2 0x40111d in _start (/app/output.s+0x40111d)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV example.c:10 in main
==1==ABORTING
[Bug fortran/99204] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-02-22 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- WORKSFORME: % gfc pr99204.f90 % ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. If I compile with -fcheck=all I get % gfc pr99204.f90 -fcheck=all % ./a.out At line 4 of file pr99204.f90 Fortran runtime error: Substring out of bounds: lower bound (-12345678) is less than one
[Bug fortran/99206] New: [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 Bug ID: 99206 Summary: [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980 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 20200823 and 20201004 : (z1 is invalid, z2 looks valid) $ cat z1.f90 program p character(:), parameter :: a(0) = reshape(['a'], [0]) end $ cat z2.f90 program p character(*), parameter :: a(0) = reshape(['a'], [0]) end $ gfortran-11-20200823 -c z1.f90 z1.f90:2:34: 2 |character(:), parameter :: a(0) = reshape(['a'], [0]) | 1 Error: Entity 'a' at (1) has a deferred type parameter and requires either the POINTER or ALLOCATABLE attribute $ gfortran-11-20210221 -c z1.f90 f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1980 0x66d3e0 add_init_expr_to_sym ../../gcc/fortran/decl.c:1980 0x676f8a variable_decl ../../gcc/fortran/decl.c:2996 0x676f8a gfc_match_data_decl() ../../gcc/fortran/decl.c:6203 0x6db9c3 match_word ../../gcc/fortran/parse.c:65 0x6db9c3 decode_statement ../../gcc/fortran/parse.c:376 0x6dd40c next_free ../../gcc/fortran/parse.c:1316 0x6dd40c next_statement ../../gcc/fortran/parse.c:1548 0x6df7d4 parse_spec ../../gcc/fortran/parse.c:3783 0x6e184c parse_progunit ../../gcc/fortran/parse.c:5896 0x6e2f41 gfc_parse_file() ../../gcc/fortran/parse.c:6437 0x72f98f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
--- Comment #4 from m.cencora at gmail dot com ---
I think it is just that sanitizer didn't caught up to the C++20 standard where
constexpr was relaxed to allow uninitialized variables.
Constant initialization is applied only when class constructor in constexpr,
and only since C++20 'A' class has constexpr constructor.
Proof, following compiles only since C++20:
struct A {
int value;
constexpr A() = default;
};
[Bug fortran/99205] New: [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 Bug ID: 99205 Summary: [10/11 Regression] Out of memory with undefined character length 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: --- This changed between 20190728 and 20190811 : $ cat z1.f90 program p character(l) :: c(2) data c /'a', 'b'/ common c end $ gfortran-11-20210221 -c z1.f90 z1.f90:2:13: 2 |character(l) :: c(2) | 1 Error: Variable 'l' cannot appear in the expression at (1) z1.f90:2:23: 2 |character(l) :: c(2) | 1 Error: 'c' at (1) must have constant character length in this context f951: out of memory allocating 137707388940 bytes after a total of 458752 bytes
[Bug fortran/99204] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Some cases with small numbers : $ cat zz1.f90 program p character :: c = 'c' integer :: i = -1 c = 'abc'(i:i) print *, c end $ cat zz2.f90 program p character :: c = 'c' integer :: i = -123 c = 'abc'(i:i) print *, c end $ gfortran-11-20210221 zz1.f90 -O2 && ./a.out $ gfortran-11-20210221 zz2.f90 -O2 && ./a.out c --- The value at which the switchover from no-ICE to ICE occurs depends on used options, and changes with gfortran versions and environment, e.g. $ cat za.f90 # no-ICE program p character :: c integer :: i = -180 c = 'abc'(i:i) print *, c end $ cat zb.f90 # ICE program p character :: c integer :: i = -190 c = 'abc'(i:i) print *, c end
[Bug fortran/99204] New: ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 Bug ID: 99204 Summary: ICE in fold_read_from_constant_string, at fold-const.c:15441 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: --- Affects versions down to at least r5 at -O1+ : (gives an error with integer, parameter :: ...) $ cat z1.f90 program p character :: c integer :: i = -12345678 c = 'abc'(i:i) print *, c end $ gfortran-11-20210221 -c z1.f90 -O2 during GIMPLE pass: ccp z1.f90:1:9: 1 | program p | ^ internal compiler error: Segmentation fault 0xc060ef crash_signal ../../gcc/toplev.c:327 0x945af6 poly_int<1u, long>::poly_int(char const&) ../../gcc/poly-int.h:670 0x945af6 fold_read_from_constant_string(tree_node*) ../../gcc/fold-const.c:15441 0x979796 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*)) ../../gcc/gimple-fold.c:7981 0x97a9d9 fold_const_aggregate_ref(tree_node*) ../../gcc/gimple-fold.c:8136 0x97a9d9 maybe_fold_reference ../../gcc/gimple-fold.c:334 0x980f84 fold_gimple_assign ../../gcc/gimple-fold.c:366 0x980f84 fold_stmt_1 ../../gcc/gimple-fold.c:6077 0xd709b3 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-propagate.c:1149 0x148d1b4 dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:309 0xd6fdf5 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) ../../gcc/tree-ssa-propagate.c:1283 0xce231b ccp_finalize ../../gcc/tree-ssa-ccp.c:1022 0xce231b do_ssa_ccp ../../gcc/tree-ssa-ccp.c:2579 0xce231b execute ../../gcc/tree-ssa-ccp.c:2622
[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196 David Malcolm changed: What|Removed |Added Last reconfirmed||2021-02-22 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Thanks for filing this; confirmed. I'm working on a fix.
[Bug sanitizer/99106] [9/10 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99106 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |tree_to_poly_int64, at |tree_to_poly_int64, at |tree.c:3091 |tree.c:3091 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-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
--- Comment #2 from Jakub Jelinek ---
Until before pro_and_epilogue we have a bb with just code_label, note and
return reg use which has 65 predecessors.
The pro_and_epilogue pass turns that into 65 simple_return jumps.
The ret insns at the end are there since the bbro pass, before that they are at
various spots in the IL and depending on the branch probabilities could even
make sense.
I guess we'd need some simplified crossjumping either during the bbro pass when
going from cfglayout mode into cfgrtl mode, or afterwards (but not too many
passes are left there) that would be able to cross-jump bbs containing those:
(code_label 1552 999 925 128 147 (nil) [1 uses])
(note 925 1552 1389 128 [bb 128] NOTE_INSN_BASIC_BLOCK)
(insn 1389 925 926 128 (use (reg/i:QI 0 ax)) -1
(nil))
(jump_insn 926 1389 927 128 (simple_return) 837 {simple_return_internal}
(nil)
-> simple_return)
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #5 from Martin Liška --- (In reply to zhan3299 from comment #4) > (In reply to Martin Liška from comment #3) > > Very interesting issue, the failure is caused by IPA ICF that merges 2 > > variables with different alignments. I've got a patch candidate. > > Hi, just curious because I am also studying the source code of GCC. > > Is this issue is about sanitizer or optimization? It's bad optimization done by IPA ICF. The issue is gone with -fno-ipa-icf.
[Bug c++/99186] std::tuple compilation error when elements are specializations of template class declared with template < auto E > syntax with E being a enumerator of a enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99186 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #1 from m.cencora at gmail dot com --- This looks like a variation of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #4 from gcc-user at riseup dot net --- Thanks for the clarification, regardless -lvtv is then passed to the libtool implementation. With GNU libtool it is silently removed hiding the bug, while slibtool actually passes it to ld which fails when its not valid. Ideally -lvtv should never reach the libtool implementation in this case since its not valid. (It is unfortunate that GNU libtool has hidden issues like this among others for so long...) > I don't know why you want to use --enable-vtable-verify but it's not really > maintained as far as I can see. I was not aware of that, it is default in gentoo. Maybe they should change that? I will add that to the gentoo issue.
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #5 from Vittorio Zecca --- Sorry I meant libubsan, but I am building the whole gcc, g++, and gfortran sanitized version.
[Bug fortran/96580] F2018 changes to date_and_time intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96580 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-02-22 --- Comment #2 from Dominique d'Humieres --- AFAICT the testing comment 2 works with integer(2) replaced with integer(4) or integer(8), but not with integer(16).
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #4 from zhan3299 at purdue dot edu --- (In reply to Martin Liška from comment #3) > Very interesting issue, the failure is caused by IPA ICF that merges 2 > variables with different alignments. I've got a patch candidate. Hi, just curious because I am also studying the source code of GCC. Is this issue is about sanitizer or optimization?
[Bug c/99198] when combinating nested function and __builtin_call_with_static_chain, optimization triggers an internal compiler error (verify_gimple)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99198 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 5.5.0, 6.4.0, ||7.2.0, 8.3.0, 9.1.0 CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Bisection points to r217771 (I think that's GCC 5.0) as the first revision to ICE, which is also when __builtin_call_with_static_chain was introduced, so it's not really a regression.
[Bug testsuite/99173] [11 Regression] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The patch might not apply anymore after the AIX changes. In any case, LGTM, please post to gcc-patches though.
[Bug libfortran/99191] sanitizer detects undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-22 Status|UNCONFIRMED |NEW
[Bug libquadmath/99203] New: Undefined behaviour in libquadmath file print_fp.c function __quadmath_printf_fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99203 Bug ID: 99203 Summary: Undefined behaviour in libquadmath file print_fp.c function __quadmath_printf_fp Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- ! from fmt_en.f90 ! must be compiled and run ! gfortran compiler needs not be sanitized ! must load sanitized libquadmath.so.0 ! ldd a.out -> libquadmath.so.0 => /home/vitti/local/gcc-150221-undefined/lib64/libquadmath.so.0 !../../../gcc-150221/libquadmath/printf/printf_fp.c:762:4: runtime error: passing zero to ctz(), which is not a valid argument !../../../gcc-150221/libquadmath/printf/printf_fp.c:762: runtime error: passing zero to ctz(), which is not a valid argument ! printf_fp.c:762 -> "count_trailing_zeros (cnt_l, tmp[0]);" write(*, "(en15.2)") real(-.4,kind=10) write(*, "(en15.2)") real(-.4,kind=16) end
[Bug libquadmath/99202] New: Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99202 Bug ID: 99202 Summary: Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- ! from dec_math.f90 ! must be compiled and run ! gfortran compiler needs not be sanitized ! must load sanitized libquadmath.so.0 as in ldd a.out -> libquadmath.so.0 => /home/vitti/local/gcc-150221-undefined/lib64/libquadmath.so.0 ! ../../../gcc-150221/libquadmath/math/rem_pio2q.c:562:26: runtime error: left shift of 4612846647631955497 by 23 places cannot be represented in type 'long int' ! rem_pio2q.c:562 -> "tx [2] = (double)(((ix << 23) | (lx >> 41)) & 0xff);" real(16) :: q_i1, q_oa q_i1 = 34.3774677078493908766176900826395_16 q_oa = cotan (q_i1) end
[Bug c++/99174] [modules] ICE with recursive inclusion of header-unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99174 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- afed55036b6 2021-02-22 | c++: Recursing header imports and other duplicates [PR 99174]
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #4 from Vittorio Zecca --- To generate a sanitized version of libgfortran I built whole sanitized gcc with the following command: CFLAGS="-g -O0 -fsanitize=undefined -lubsan" LIBS="-lubsan" CXXFLAGS=$CFLAGS ../gcc-150221/configure --prefix=/home/vitti/local/gcc-150221-undefined --enable-languages=c,c++,fortran --disable-multilib --disable-lto --disable-plugin --disable-bootstrap But I remember I had to tweak the build here and there. It is not trivial.
[Bug c++/99174] [modules] ICE with recursive inclusion of header-unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99174 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:afed55036b65526be006d55f003f670ebeadb223 commit r11-7324-gafed55036b65526be006d55f003f670ebeadb223 Author: Nathan Sidwell Date: Mon Feb 22 07:43:56 2021 -0800 c++: Recursing header imports and other duplicates [PR 99174] The fix for 98741 introduced two issues. (a) recursive header units iced because we tried to read the preprocessor state after having failed to read the config. (b) we could have duplicate imports of named modules in our pending queue, and that would lead to duplicate requests for pathnames, which coupled with the use of a null-pathname to indicate we'd asked could lead to desynchronization with the module mapper. Fixed by adding a 'visited' flag to module state, so we ask exactly once. PR c++/99174 gcc/cp * module.cc (struct module_state): Add visited_p flag. (name_pending_imports): Use it to avoid duplicate requests. (preprocess_module): Don't read preprocessor state if we failed to load a module's config. gcc/testsuite/ * g++.dg/modules/pr99174-1_a.C: New. * g++.dg/modules/pr99174-1_b.C: New. * g++.dg/modules/pr99174-1_c.C: New. * g++.dg/modules/pr99174.H: New.
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from John David Anglin --- Fixed on master and gcc-10.
[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718 Nathan Sidwell changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-22
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by John David Anglin : https://gcc.gnu.org/g:89b7f2b821e0a158fee586b3d655f9a7d925b9c3 commit r10-9382-g89b7f2b821e0a158fee586b3d655f9a7d925b9c3 Author: John David Anglin Date: Mon Feb 22 15:37:22 2021 + Add mi_thunk support for vcalls on hppa. gcc/ChangeLog: PR target/85074 * config/pa/pa.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Define as hook_bool_const_tree_hwi_hwi_const_tree_true. (pa_asm_output_mi_thunk): Add support for nonzero vcall_offset.
[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 #3 from Matthias Kretz (Vir) --- I'll try to find a better reduction.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #3 from Jonathan Wakely --- (In reply to gcc-user from comment #2) > Briefly it explained that -lvtv comes from -fvtable-verify=std in a gcc spec > file and is propogated to Makefile.in by gcc/Makefile.def. The -fvtable-verify=std doesn't come from the spec file, it comes from using --enable-vtable-verify to configure gcc. That adds -fvtable-verify=std and the spec file turns that into -lvtv. I don't know why you want to use --enable-vtable-verify but it's not really maintained as far as I can see.
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 --- Comment #3 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:d789cf134b7e04ffd90e9512e3e591bd16dc6655 commit r11-7323-gd789cf134b7e04ffd90e9512e3e591bd16dc6655 Author: John David Anglin Date: Mon Feb 22 15:32:34 2021 + Add mi_thunk support for vcalls on hppa. gcc/ChangeLog: PR target/85074 * config/pa/pa.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Define as hook_bool_const_tree_hwi_hwi_const_tree_true. (pa_asm_output_mi_thunk): Add support for nonzero vcall_offset.
[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 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- If r273943 accepted it, perhaps we need another reduction that will result in no errors with that revision and in that ICE (plus no further errors) with r273944.
[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
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly reduced:
template
struct A
{
constexpr A (const char ()[N]) { for (int i = 0; i < N; i++) v[i] = s[i];
v[N] = 0; }
char v[N + 1];
};
template
struct B
{
constexpr operator const char *() { return s.v; }
};
template
const char *
foo ()
{
return B<__PRETTY_FUNCTION__>{};
}
template
const char *
bar ()
{
return B<__FUNCTION__>{};
}
int
main ()
{
auto a = foo ();
auto b = bar ();
}
[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 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-02-22 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93383 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Looks like a dup of 93383.
[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 Marek Polacek changed: What|Removed |Added Target Milestone|--- |8.5 CC||mpolacek at gcc dot gnu.org Summary|ICE in tsubst_copy, at |[8/9/10/11 Regression] ICE |cp/pt.c:16581 |in tsubst_copy, at ||cp/pt.c:16581 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-02-22 --- Comment #1 from Marek Polacek --- Started with r273944. The reduced test seems to be invalid.
[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Component|c |analyzer Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Reassigning to analyzer.
[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Component|c |analyzer --- Comment #5 from Martin Sebor --- Reassigning to analyzer.
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #3 from Martin Liška --- Interesting, you are searching for UBSAN in libsanitizer. Can you please share details how do you build libubsan with -fsanitize=shift?
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #2 from gcc-user at riseup dot net --- > Note swapping out parts of the build system isn't tested/supported. This is both a gcc and GNU libtool bug, gcc is passing invalid flags and libtool is silently hiding the fact. I understand that slibtool may be untested in gcc, but since its actually doing the right thing here and has several benefits over GNU libtool (Maintained and readable codebase) it would be very appreciated if this can be fixed. > Can you quote where the "invalid" -lvtv is present? Honestly the gcc build system is confusing for me, but see this comment from the gentoo issue. https://bugs.gentoo.org/767706#c7 Briefly it explained that -lvtv comes from -fvtable-verify=std in a gcc spec file and is propogated to Makefile.in by gcc/Makefile.def.
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #3 from Martin Liška --- Very interesting issue, the failure is caused by IPA ICF that merges 2 variables with different alignments. I've got a patch candidate.
[Bug c++/99201] New: ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201
Bug ID: 99201
Summary: ICE in tsubst_copy, at cp/pt.c:16581
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Testcase (reduced with C-Vise from valid code):
template void test_values_2arg(int, int, F... fun_pack) {
[] {}(fun_pack()...);
}
template auto make_tester(TestF, RefF) {
return [](auto...) {
[](auto... vs) {
if constexpr ([&] { reffun(vs...); })
;
};
};
}
void test() {
auto __trans_tmp_1 = make_tester([] {}, [] {});
test_values_2arg({}, {}, __trans_tmp_1);
}
ice.cpp: In instantiation of 'make_tester,
test():: >:: [with auto:1 = {}]':
ice.cpp:2: required from 'void test_values_2arg(int, int, F ...) [with
= int; F = {make_tester,
test():: >::}]'
ice.cpp:14: required from here
ice.cpp:7: internal compiler error: in tsubst_copy, at cp/pt.c:16581
7 | if constexpr ([&] { reffun(vs...); })
| ^~
0x66f262 tsubst_copy
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:16581
0x804fae tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:20719
0x804e6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19497
0x804e6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:20841
0x816cc4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19497
0x816cc4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19107
0x815dec tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x815dec tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:13148
0x806acd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:20148
0x816cc4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19497
0x816cc4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19107
0x817cee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x817cee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18177
0x818893 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x818893 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18147
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18498
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18498
0x81f84b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Nathan Sidwell --- c49fcfddaa4 2021-02-22 | c++: cross-header-unit template definitions [PR 99153] I have verified that iostream, utility and algorithm can be built
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 --- Comment #3 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:c49fcfddaa47f2828fe2af11ae857cd67f53e23f commit r11-7322-gc49fcfddaa47f2828fe2af11ae857cd67f53e23f Author: Nathan Sidwell Date: Mon Feb 22 06:43:32 2021 -0800 c++: cross-header-unit template definitions [PR 99153] A member function can be defined in a different header-file than the one defining the class. In such situations we must unmark the decl as imported. When the entity is a template we failed to unmark the template_decl. Perhaps the duplication of these flags on the template_decl from the underlying decl is an error. I set on the fence about it for a long time during development, but I don't think now is the time to change that (barring catastrophic bugs). PR c++/99153 gcc/cp/ * decl.c (duplicate_decls): Move DECL_MODULE_IMPORT_P propagation to common-path. * module.cc (set_defining_module): Add assert. gcc/testsuite/ * g++.dg/modules/pr99153_a.H: New. * g++.dg/modules/pr99153_b.H: New.
[Bug tree-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 Jakub Jelinek changed: What|Removed |Added CC||glisse at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- So many ret insns started with r8-4600-g611a7c7e3799549b0de94c75ca810ba0d450b804 When looking just about number of lines in assembly, there was a rise in number of lines (452 -> 476) already with r8-4395-ge268a77b59cb788637d6db4829f0fd1ddf63f6f2 and then (479 -> 550) in r8-4579-g0cea1d34f781ba9e08ffa82458f0410b398e9c93. Though I don't see how r8-4579 could have changed something when there is no inlining.
[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 #3 from Jonathan Wakely --- We're in namespace std here so size_t doesn't need to be qualified, but otherwise the patch is fine.
