[Bug c/99913] New: GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 Bug ID: 99913 Summary: GCC11 fails to build for MinGW-w64 for Windows 32-bit Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- Created attachment 50509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50509&action=edit i686-w64-mingw32/libgomp/config.log When building GCC 11 (including latest snapshot 20210404) against MinGW-w64 for Windows 32-bit using an existing MinGW-w64 Windows 32-bit gcc configure stops with the following error: configure: error: unsupported system, cannot find sizeof (omp_lock_t) This error is logged to file i686-w64-mingw32/libgomp/config.log which I have attached. At first glance it seems like it's not finding symbols that require -lwinpthread Note that there are no issues building GCC 11 against MinGW-w64 for Windows 64-bit.
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 --- Comment #1 from Andrew Pinski --- I Noticed: --enable-threads=posix and the error message is: D:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\bin\ld.exe: R:/winlibs32_stage/gcc-11-20210404/build_mingw/gcc/libgcc_eh.a(unwind-dw2.o): in function `_gthread_once': R:\winlibs32_stage\gcc-11-20210404\build_mingw\i686-w64-mingw32\libgcc/./gthr-default.h:700: undefined reference to `pthread_once' More undefined references to pthread_* Either pthreads-win32 is not installed correctly or is not being linked correctly here.
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 --- Comment #2 from Brecht Sanders --- By the time I get to that error the build process already generated these files: - mingw-w64/mingw/lib/libwinpthread.a - mingw-w64/mingw/lib/libwinpthread.dll.a - mingw-w64/mingw/lib/libwinpthread.la However I couldn't find a matching DLL, which I assume should be here: - mingw-w64/mingw/bin/libwinpthread-1.dll
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 --- Comment #3 from Brecht Sanders --- Just to clarify: libwinpthread is built as part of the GCC build against MinGW-w64. MinGW-w64 also already has a libwinpthread (including libwinpthread-1.dll which can be found in the PATH).
[Bug d/99914] New: d: Template symbols not overridable by normal symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
Bug ID: 99914
Summary: d: Template symbols not overridable by normal symbols
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Currently, the following does not link:
extern(C) __gshared bool rt_cmdline_enabled = false;
Because the symbol conflicts with a template symbol of the same name in the D
runtime library.
template rt_cmdline_enabled()
{
pragma(mangle, "rt_cmdline_enabled")
__gshared bool rt_cmdline_enabled = true;
}
Template symbols are made DECL_ONE_ONLY, which ends up in the gnu.linkonce
section as a unique global symbol. However, the linker only considers other
symbols in gnu.linkonce as being candidates for discarding duplicates.
The expected and correct behaviour is for all instantiations to be declared
weak.
[Bug c++/99915] New: [modules] ICE in write_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99915 Bug ID: 99915 Summary: [modules] ICE in write_location Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexander.lelyakin at googlemail dot com Target Milestone: --- This ICE is very similar to 99246, but it is closed as fixed. So I assume that it is a new bug with similar symptoms. /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bit /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header istream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bitset /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header new /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ciso646 /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header thread /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex In module imported at /usr/local/include/c++/11.0.1/sstream:38:1, included from /usr/local/include/c++/11.0.1/regex:46: /usr/local/include/c++/11.0.1/istream: note: unable to represent further imported source locations /usr/local/include/c++/11.0.1/regex: internal compiler error: in write_location, at cp/module.cc:15607 0x6de279 module_state::write_location(bytes_out&, unsigned int) ../../gcc/gcc/cp/module.cc:15607 0xa67153 trees_out::core_vals(tree_node*) ../../gcc/gcc/cp/module.cc:5904 0xa6a5c4 trees_out::tree_node_vals(tree_node*) ../../gcc/gcc/cp/module.cc:7054 0xa6a5c4 trees_out::tree_value(tree_node*) ../../gcc/gcc/cp/module.cc:8890 0xa66654 trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9088 0xa6a9aa trees_out::write_var_def(tree_node*) ../../gcc/gcc/cp/module.cc:11475 0xa6bc45 module_state::write_cluster(elf_out*, depset**, unsigned int, depset::hash&, unsigned int*, unsigned int*) ../../gcc/gcc/cp/module.cc:14662 0xa6d5ce module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17734 0xa6e338 finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19845 0xa014cb c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210405 (experimental) Copyright (C) 2021 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.
[Bug c++/99861] [modules] ICE in hashtab_chk_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99861
--- Comment #2 from Alexander Lelyakin ---
There is a shorter sequence:
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from /usr/local/include/c++/11.0.1/vector:66,
from /usr/local/include/c++/11.0.1/functional:62,
from
/usr/local/include/c++/11.0.1/pstl/glue_algorithm_defs.h:13,
from /usr/local/include/c++/11.0.1/algorithm:74:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h: In static member
function ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator)’:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h:110:23: internal
compiler error: in hashtab_chk_error, at hash-table.c:137
110 | { return std::copy(__first, __last, __result); }
| ^~~~
0x92db09 hashtab_chk_error()
../../gcc/gcc/hash-table.c:137
0xb3c135 hash_table::verify(spec_entry*
const&, unsigned int)
../../gcc/gcc/hash-table.h:1033
0xb3c6be hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:968
0xaf957b match_mergeable_specialization(bool, spec_entry*)
../../gcc/gcc/cp/pt.c:29908
0xa72a58 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
../../gcc/gcc/cp/module.cc:10670
0xa76654 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7903
0xa6f4b7 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9153
0xa75adb module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14811
0xa75fdd module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7609f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa70320 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa757db module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa75fdd module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7609f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa70320 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa757db module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa75fdd module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7609f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa70320 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa757db module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
g++ (GCC) 11.0.1 20210405 (experimental)
Copyright (C) 2021 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.
[Bug d/99914] d: Template symbols not overridable by normal symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:76a7e7e706ac4c01cead3c6514322aaad88f9a63
commit r11-7983-g76a7e7e706ac4c01cead3c6514322aaad88f9a63
Author: Iain Buclaw
Date: Sun Mar 14 22:51:56 2021 +0100
d: Use weak linkage for template symbols instead of gnu.linkonce (PR99914)
The default linkage of templates in the D language is now DECL_WEAK
instead of DECL_ONE_ONLY, if supported. This better matches the
expected override semantics of template symbols compiled to object code.
For example:
module rt.config;
template rt_flag()
{
pragma(mangle, "rt_flag") __gshared bool rt_flag = true;
}
module main;
extern(C) __gshared bool rt_flag = false;
The above currently does not succeed in linking due to there being
multiple definitions of `rt_flag' in different sections that aren't
considered mergeable.
The compiler flag enabling toggling of this has been given a clearer
named `-fweak-templates', which distinguishes itself from G++ `-fweak',
which is intended only for testing.
gcc/d/ChangeLog:
PR d/99914
* d-lang.cc (d_init): Disable flag_weak_templates if no support for
weak or one-only symbols.
* d-tree.h (VAR_OR_FUNCTION_DECL_CHECK): New macro.
(DECL_INSTANTIATED): New macro.
(d_comdat_linkage): Remove declaration.
(d_linkonce_linkage): Remove declaration.
(set_linkage_for_decl): New declaration.
* decl.cc (DeclVisitor::visit (StructDeclaration *)): Replace call
to
d_linkonce_linkage with setting DECL_INSTANTIATED.
(DeclVisitor::visit (ClassDeclaration *)): Likewise.
(DeclVisitor::visit (EnumDeclaration *)): Likewise.
(DeclVisitor::visit (InterfaceDeclaration *)): Remove call to
d_linkonce_linkage.
(get_symbol_decl): Call set_linkage_for_decl instead of
d_linkonce_linkage.
(d_finish_decl): Call set_linkage_for_decl.
(d_comdat_linkage): Made function static. Only set DECL_COMDAT for
DECL_INSTANTIATED decls.
(d_linkonce_linkage): Remove function.
(d_weak_linkage): New function.
(set_linkage_for_decl): New function.
* gdc.texi (Runtime Options): Rename -fno-weak to
-fno-weak-templates,
update documentation of option.
* lang.opt (fweak): Rename option to ...
(fweak-templates): ... this. Update help string.
* modules.cc (get_internal_fn): Add Prot parameter. Set generated
function flag.
(build_internal_fn): Update call to get_internal_fn.
(build_dso_cdtor_fn): Likewise.
(register_moduleinfo): Call d_finish_decl on dso_slot_node and
dso_initialized_node.
* typeinfo.cc (TypeInfoVisitor::internal_reference): Call
set_linkage_for_decl instead of d_comdat_linkage.
(TypeInfoDeclVisitor::visit (TypeInfoDeclaration *)): Remove calls
to
d_linkonce_linkage and d_comdat_linkage.
(get_cpp_typeinfo_decl): Likewise.
gcc/testsuite/ChangeLog:
PR d/99914
* gdc.dg/pr99914.d: New test.
[Bug d/99914] d: Template symbols not overridable by normal symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Fix committed.
[Bug c++/99916] New: ICE Segmentation fault when erroneous structured bindings appears in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99916
Bug ID: 99916
Summary: ICE Segmentation fault when erroneous structured
bindings appears in requires-clause
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/cW8367TTr
struct S {} s;
template concept C = requires { [a] = s; };
static_assert(C);
:2:41: internal compiler error: Segmentation fault
2 | template concept C = requires { [a] = s; };
| ^~~
0x1cfcba9 internal_error(char const*, ...)
???:0
0x7779e3 pp_cxx_parameter_mapping(cxx_pretty_printer*, tree_node*)
???:0
0x7e2a68 maybe_print_single_constraint_context(diagnostic_context*, tree_node*)
???:0
0x1cfb736 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x1cfc13d inform(unsigned int, char const*, ...)
???:0
0x73f30f diagnose_constraints(unsigned int, tree_node*, tree_node*)
???:0
0x98aba3 finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
???:0
0x8e14fd c_parse_file()
???:0
0xa60102 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[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 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a99a7b0afe9a1f6f866e25b8572856ae8c1d3f8d commit r11-7985-ga99a7b0afe9a1f6f866e25b8572856ae8c1d3f8d Author: Jason Merrill Date: Sun Apr 4 01:01:56 2021 -0400 c++: constexpr if and nested generic lambda [PR99201] When building up *_EXTRA_ARGS for a constexpr if or pack expansion, we need to walk into the body of a lambda to find all the local_specializations that we need to remember, like we do in find_parameter_packs_r. gcc/cp/ChangeLog: PR c++/99201 * pt.c (class el_data): Add visited field. (extract_local_specs): Pass it to cp_walk_tree. (extract_locals_r): Walk into the body of a lambda. gcc/testsuite/ChangeLog: PR c++/99201 * g++.dg/cpp1z/constexpr-if-lambda4.C: New test.
[Bug c++/99066] [8/9/10/11 Regression] non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066 --- Comment #3 from Jason Merrill --- (In reply to Jakub Jelinek from comment #2) > Perhaps caused by PR23691 changes? r104041, yes. Bizarre that this went unnoticed for over 15 years.
[Bug c++/99066] [8/9/10/11 Regression] non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bd89b8fe9efbdf0a95d827553d1a84fd3cefaa16 commit r11-7986-gbd89b8fe9efbdf0a95d827553d1a84fd3cefaa16 Author: Jason Merrill Date: Sun Apr 4 23:32:32 2021 -0400 c++: extern template and static data member [PR99066] 'extern template' should mean that the relevant symbols are never emitted. But in this case we were assuming that DECL_EXTERNAL was already set on the variable, so we just needed to clear DECL_NOT_REALLY_EXTERN. Since DECL_EXTERNAL was not set, we emitted a definition of npos. gcc/cp/ChangeLog: PR c++/99066 * pt.c (mark_decl_instantiated): Set DECL_EXTERNAL. gcc/testsuite/ChangeLog: PR c++/99066 * g++.dg/cpp0x/extern_template-6.C: New test.
[Bug c++/99066] [8/9/10 Regression] non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |non-weak definition emitted |non-weak definition emitted |for explicit instantiation |for explicit instantiation |declaration |declaration --- Comment #5 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/99201] [8/9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16581 since r8-7613-g1456e764105702a0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in tsubst_copy, at |tsubst_copy, at |cp/pt.c:16581 since |cp/pt.c:16581 since |r8-7613-g1456e764105702a0 |r8-7613-g1456e764105702a0 --- Comment #8 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed.
[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870 --- Comment #7 from Viktor Rosendahl --- Thanks for your message. I am on vacation. I will be working again on 6th of April 2021.
[Bug analyzer/99886] Delay loop in -fanalyzer seen on gcc.dg/analyzer/malloc-1.c with -fanalyzer-verbosity=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99886 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:69b66ff02353a87585329bb3cf4ac20d6dee1b16 commit r11-7987-g69b66ff02353a87585329bb3cf4ac20d6dee1b16 Author: David Malcolm Date: Mon Apr 5 10:48:01 2021 -0400 analyzer: fix apparent hang with -fanalyzer-verbosity=0 [PR analyzer/99886] The analyzer appeared to enter an infinite loop on malloc-1.c when -fanalyzer-verbosity=0 was used. In fact, it was slowly counting from 0 to 0x. Root cause is looping up to effectively ((unsigned)0) - 1 in diagnostic_manager::consolidate_conditions when there are no events in the path. Fixed by the following, which uses signed integers when subtracting from path->num_events () when simplifying checker_paths. gcc/analyzer/ChangeLog: PR analyzer/99886 * diagnostic-manager.cc (diagnostic_manager::prune_interproc_events): Use signed integers when subtracting one from path->num_events (). (diagnostic_manager::consolidate_conditions): Likewise. Convert next_idx to a signed int. gcc/testsuite/ChangeLog: PR analyzer/99886 * gcc.dg/analyzer/pr99886.c: New test.
[Bug analyzer/99906] [11 Regression] ICE: SIGSEGV in maybe_reconstruct_from_def_stmt with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99906 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb commit r11-7988-g7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb Author: David Malcolm Date: Mon Apr 5 10:51:46 2021 -0400 analyzer: fix ICE on zero-arg calls passed to __attribute__((nonnull)) [PR 99906] gcc/analyzer/ChangeLog: PR analyzer/99906 * analyzer.cc (maybe_reconstruct_from_def_stmt): Fix NULL dereference on calls with zero arguments. * sm-malloc.cc (malloc_state_machine::on_stmt): When handling __attribute__((nonnull)), only call get_diagnostic_tree if the result will be used. gcc/testsuite/ChangeLog: PR analyzer/99906 * gcc.dg/analyzer/pr99906.c: New test.
[Bug analyzer/99886] Delay loop in -fanalyzer seen on gcc.dg/analyzer/malloc-1.c with -fanalyzer-verbosity=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99886 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/99906] [11 Regression] ICE: SIGSEGV in maybe_reconstruct_from_def_stmt with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99906 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by the above patch.
[Bug c++/99380] [modules] Unexpected MODULE-EXPORT request when partially preprocessing header unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99380 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:dd6f588a7b8878d677af51ff4d1c1e3f9f6f40db commit r11-7989-gdd6f588a7b8878d677af51ff4d1c1e3f9f6f40db Author: Nathan Sidwell Date: Mon Apr 5 07:51:28 2021 -0700 c++: Unneeded export query [PR 99380] This problem got introduced fixing a module numbering problem. When preprocessing a header unit, we don't need to send an EXPORT query unless we're also determining dependencies, or the mapper asked us to. Sadly the testsuite isn't set up to test this kind of subtlety. I manually did that with stdin/stdout. PR c++/99380 gcc/cp/ * module.cc (name_pending_imports): Drop 'atend' parm. Don't query export when not needed. (preprocess_module, preprocessed_module): Adjust.
[Bug c++/99380] [modules] Unexpected MODULE-EXPORT request when partially preprocessing header unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99380 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Nathan Sidwell --- * dd6f588a7b8 2021-04-05 | c++: Unneeded export query [PR 99380]
[Bug c++/99899] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99899 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE: in do_auto_deduction, |[11 Regression] ICE: in |at cp/pt.c:29630|do_auto_deduction, at ||cp/pt.c:29630 Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Last reconfirmed||2021-04-05 --- Comment #1 from Patrick Palka --- Confirmed, started with r11-7540.
[Bug middle-end/84078] false positive for -Wmaybe-uninitialized with __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.0, 4.1.0, 4.8.4,
||4.9.4, 5.5.0, 6.4.0, 7.2.0,
||8.3.0, 9.1.0
Keywords||missed-optimization
Last reconfirmed|2018-01-29 00:00:00 |2021-4-5
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
Reconfirmed with GCC 11 and -O1/-O2 and the slightly reduced test case below.
I don't see anything in the IL that could be used to prove the uninitialized
variable isn't used: a_3 is uninitialized when b_6 != 0 || x == 0, and a_3 is
used when b_2 == 0 && c_9 == 0. The two predicates aren't mutually exclusive
so the warning triggers.
$ cat pr84078.c && gcc -O2 -S -Wall -fdump-tree-uninit=/dev/stdout pr84078.c
int x, z;
int f (void);
void g (int b)
{
int a;
if (!b)
{
if (x)
a = x;
else
b = 1;
}
{
int c;
__asm __volatile("" : "=r" (c));
if (c)
f ();
}
if (b)
return;
z = a;
}
;; Function g (g, funcdef_no=0, decl_uid=1947, cgraph_uid=1, symbol_order=2)
[AFTER NORMALIZATION -- [DEF]:
(.NOT.) b_6(D) == 0
[AFTER NORMALIZATION -- [DEF]:
a_3 = PHI
is guarded by :
x.0_1 != 0 (.AND.) b_6(D) == 0
[AFTER NORMALIZATION -- [USE]:
z = a_3;
is guarded by :
(.NOT.) b_2 != 0
pr84078.c: In function ‘g’:
pr84078.c:27:5: warning: ‘a’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
27 | z = a;
| ~~^~~
pr84078.c:7:7: note: ‘a’ was declared here
7 | int a;
| ^
void g (int b)
{
int c;
int a;
int x.0_1;
[local count: 1073741824]:
if (b_6(D) == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
goto ; [100.00%]
[local count: 536870913]:
x.0_1 = x;
if (x.0_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 268435457]:
goto ; [100.00%]
[local count: 268435457]:
[local count: 1073741824]:
# b_2 = PHI
# a_3 = PHI
__asm__ __volatile__("" : "=r" c_9);
if (c_9 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 719407024]:
goto ; [100.00%]
[local count: 354334800]:
f ();
[local count: 1073741824]:
if (b_2 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 365072224]:
goto ; [100.00%]
[local count: 708669601]:
z = a_3;
[local count: 1073741824]:
return;
}
[Bug ipa/85233] Incorrect -Wmaybe-uninitialized with -fpartial-inlining -finline-small-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85233 Martin Sebor changed: What|Removed |Added Known to fail||7.3.0, 8.3.0, 9.2.0 Status|NEW |RESOLVED Target Milestone|--- |10.0 Keywords||missed-optimization Resolution|--- |FIXED CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- The warning disappeared with r276416 (10.0.0 20191001) so this can be resolved as fixed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 85233, which changed state. Bug 85233 Summary: Incorrect -Wmaybe-uninitialized with -fpartial-inlining -finline-small-functions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85233 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug d/99917] New: gcc/d/dmd/mtype.c:5223: missing call to va_end ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99917 Bug ID: 99917 Summary: gcc/d/dmd/mtype.c:5223: missing call to va_end ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk.git/gcc/d/dmd/mtype.c:5223:30: error: va_list 'ap' was opened but not closed by va_end(). [va_end_missing] Source code is va_list ap; va_start(ap, format); buf.vprintf(format, ap); return buf.extractChars();
[Bug c++/99066] [8/9/10 Regression] non-weak definition emitted for explicit instantiation declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066 --- Comment #6 from Jonathan Wakely --- (In reply to Jason Merrill from comment #3) > r104041, yes. Bizarre that this went unnoticed for over 15 years. Very surprising, isn't it!
[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:62d60246e53778db6ee613377dd013ba4b264968 commit r11-7992-g62d60246e53778db6ee613377dd013ba4b264968 Author: Jason Merrill Date: Mon Apr 5 11:34:48 2021 -0400 c++: lambda in DMI in class template [PR95870] Here enclosing_instantiation_of was failing to find a match because otctx is struct S and current_function_decl is S::S(), so the latter has more function contexts, and we end up trying to compare S() to NULL_TREE. After spending a bit of time working on establishing the correspondence in this case (class <=> constructor), it occurred to me that we could just use DECL_SOURCE_LOCATION, which is unique for lambdas, since they cannot be redeclared. Since we're so close to release, for now I'm only doing this for the case that was failing before. gcc/cp/ChangeLog: PR c++/95870 * pt.c (enclosing_instantiation_of): Compare DECL_SOURCE_LOCATION if there is no enclosing non-lambda function. gcc/testsuite/ChangeLog: PR c++/95870 * g++.dg/cpp0x/lambda/lambda-nsdmi10.C: New test.
[Bug c++/95317] [8/9/10/11 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9f4c41147a41d08a74990eafe69a1064a3c13435 commit r11-7993-g9f4c41147a41d08a74990eafe69a1064a3c13435 Author: Jason Merrill Date: Mon Apr 5 14:26:03 2021 -0400 c++: enum in generic lambda in template [PR95317] Here we weren't instantiating the enumerators because the arglist still had the template parameter for the generic lambda, so looking one up failed. We need to instantiate if the non-lambda enclosing scope is non-dependent. gcc/cp/ChangeLog: PR c++/95317 * pt.c (lookup_template_class_1): Do tsubst_enum when tsubsting a generic lambda. gcc/testsuite/ChangeLog: PR c++/95317 * g++.dg/cpp1y/lambda-generic-enum1.C: New test.
[Bug c++/95317] [8/9/10 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE on |on valid C++14 code, in |valid C++14 code, in |tsubst_copy, at |tsubst_copy, at |cp/pt.c:15649 |cp/pt.c:15649 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/98440] [9/10/11 Regression] Accepts ill-formed reinterpret_cast(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #4 from the_gamester28 at msn dot com ---
(In reply to Jason Merrill from comment #2)
> (In reply to the_gamester28 from comment #0)
> > It seems that the template requirements of invoke_tag(bar_tag, int) are
> > considered while evaluating line marked "here". Requirements of irrelevant
> > overloads should not be considered, as it can potentially lead to falsely
> > reporting a cyclic dependency.
>
> This is as specified by http://wg21.link/cwg2369
>
> I think it would be reasonable to allow a compiler to accept the testcase
> under a generalization of 13.9.1/9: "If the function selected by overload
> resolution (12.4) can be determined without instantiating a class template
> definition, it is unspecified whether that instantiation actually takes
> place."
>
> But that does not require a compiler to accept it.
>
> It might make sense to check non-dependent conversions that don't require
> template instantiation, then constraints, then non-dependent conversions
> that do require template instantiation. But that's a matter for the
> committee; G++ is conforming to the current working paper.
Perhaps I was too quick to assert what I expected the implementation details to
be.
The fooable concept should be satisfied for any (T it) for which
invoke_tag(foo_tag{}, it) is unambiguously applicable. The fact that the
invoke_tag(bar_tag, T) overload exists should not preclude that. It is not up
to me how the compiler comes to that end, but that is the desired outcome.
It is still possible to ban recursive constraints, keep the new GCC 11
implementation, and still have this particular code compile with a small
alteration in behaviour:
The compiler does not immediately bail out as soon as it sees recursion in an
overload candidate, but marks that particular candidate as invalid.
If there are no applicable overloads (because they are all recursive, or they
are invalid for some other reason), then the compiler can reject the code and
list all of the reasons why all of the candidates are invalid.
In this case, it would mark invoke_tag(bar_tag, int) as not-applicable due to
the constraint recursion, and carry on checking the rest of the overloads for
applicability, until it is sure that there is one and only one applicable
overload: invoke_tag(foo_tag, int).
[Bug d/99917] gcc/d/dmd/mtype.c:5223: missing call to va_end ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99917 --- Comment #1 from Iain Buclaw --- (In reply to David Binderman from comment #0) > trunk.git/gcc/d/dmd/mtype.c:5223:30: error: va_list 'ap' was opened but not > closed by va_end(). [va_end_missing] > > Source code is > > va_list ap; > va_start(ap, format); > buf.vprintf(format, ap); > return buf.extractChars(); Had a look and confirmed, raised a change in upstream dmd and awaiting for it to be reviewed.
[Bug c++/96311] [8/9/10/11 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/99918] New: suboptimal code for bool bitfield tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
Bug ID: 99918
Summary: suboptimal code for bool bitfield tests
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC does a better job folding operations involving plain Booleans than it does
with bool bit-fields. The example below shows that in f() the return statement
is folded to zero while in g() it's not. This is behind a class of
-Wmaybe-uninitialized warnings.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
struct A { _Bool i, j; };
_Bool f (struct A a)
{
if (a.i)
a.j = 0;
else
a.j = a.i;
return a.j;// folded to 0
}
struct B { _Bool i: 1, j: 1; };
_Bool g (struct B b)
{
if (b.i)
b.j = 0;
else
b.j = b.i;
return b.j;// not folded
}
;; Function f (f, funcdef_no=0, decl_uid=1946, cgraph_uid=1, symbol_order=0)
_Bool f (struct A a)
{
[local count: 1073741824]:
return 0;
}
;; Function g (g, funcdef_no=1, decl_uid=1953, cgraph_uid=2, symbol_order=1)
Removing basic block 5
_Bool g (struct B b)
{
_Bool b$j;
unsigned char _1;
unsigned char _2;
_Bool _3;
[local count: 1073741824]:
_1 = VIEW_CONVERT_EXPR(b);
_2 = _1 & 1;
if (_2 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_3 = b.i;
[local count: 1073741824]:
# b$j_5 = PHI <0(2), _3(3)>
return b$j_5;
}
[Bug tree-optimization/99918] suboptimal code for bool bitfield tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- This comes down to lowering bitfields too soon. my bet it will happen even integer bitfields will have a problem.
[Bug tree-optimization/99918] [9/10/11 Regression] suboptimal code for bool bitfield tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1, ||8.3.0, 9.3.0 Summary|suboptimal code for bool|[9/10/11 Regression] |bitfield tests |suboptimal code for bool ||bitfield tests --- Comment #2 from Martin Sebor --- Bisection points to r225825 as the revision where GCC started to fail to fold the code in g().
[Bug tree-optimization/99918] [9/10/11 Regression] suboptimal code for bool bitfield tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918 --- Comment #3 from Martin Sebor --- This only seems to affect C _Bool bit-fields and not C++ bool.
[Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Bug ID: 99919
Summary: [9/10/11 Regression] bogus -Wmaybe-uninitialized with
a _Bool bit-field
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is the -Wmaybe-uninitialized subset of pr99918 showing how the failure to
fail _Bool bit-field expressions can cause bogus warnings. (Like pr99918, this
was most likely caused by r225825.)
$ cat z.c && gcc -O2 -S -Wall z.c
struct B { _Bool i: 1; _Bool j: 1; };
_Bool z;
void g (struct B b)
{
_Bool x;
if (b.i)
b.j = 0;
else
{
b.j = b.i;
x = b.i;
}
if (b.j)
z = x;
}
z.c: In function ‘g’:
z.c:18:7: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
18 | z = x;
| ~~^~~
z.c:7:9: note: ‘x’ was declared here
7 | _Bool x;
| ^
[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2018-04-09 00:00:00 |2021-4-5
Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=99919
CC||msebor at gcc dot gnu.org
--- Comment #8 from Martin Sebor ---
Reconfirmed with GCC 11 with the ever-so-slightly slightly simplified program
below and enhanced output. The warning has been issued since at least GCC 4.1
and so is not a regression.
$ cat pr85301.c && gcc -O2 -S -Wall -DUSE_BITFIELD pr85301.c
struct A
{
#ifdef USE_BITFIELD
unsigned i : 1;
unsigned j : 1;
#else
unsigned i;
unsigned j;
#endif
};
int z, f (void);
struct A a;
void h (void)
{
int y;
if (a.j || a.i)
y = f ();
if (a.i)
z = y;
}
pr85301.c: In function ‘h’:
pr85301.c:24:7: warning: ‘y’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
24 | z = y;
| ~~^~~
pr85301.c:18:7: note: when ‘!(((unsigned char*)&a)[0] & 3)’
18 | int y;
| ^
pr85301.c:18:7: note: used when ‘prephitmp_15 = PHI <_1(7), pretmp_14(3)> & 1’
pr85301.c:18:7: note: ‘y’ was declared here
Jump threading and other optimization opportunities aside (I have raised
pr99918 for one of those), there does also seem to be a limitation in the
warning code in that it doesn't understand BIT_FIELD_REF expressions. The
warning sees the IL below from which it should be able to determine that y's
use is conditional on its definition (i.e., the use predicate a strict subset
of the predicate controlling the definition).
void h ()
{
int y;
unsigned char _1;
unsigned char _2;
unsigned char _4;
unsigned char pretmp_14;
unsigned char prephitmp_15;
[local count: 1073741824]:
# VUSE <.MEM_8(D)>
_1 = BIT_FIELD_REF ;
_2 = _1 & 3;
if (_2 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 719407024]:
goto ; [100.00%]
[local count: 354334800]:
# .MEM_10 = VDEF <.MEM_8(D)>
y_11 = f ();
# VUSE <.MEM_10>
pretmp_14 = BIT_FIELD_REF ;
[local count: 1073741824]:
# y_5 = PHI
# .MEM_6 = PHI <.MEM_8(D)(7), .MEM_10(3)>
# prephitmp_15 = PHI <_1(7), pretmp_14(3)>
_4 = prephitmp_15 & 1;
if (_4 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
goto ; [100.00%]
[local count: 536870913]:
## y_5 = PHI
## uninit when: _2 == 0
##: BIT_FIELD_REF & 3 == 0
##
## used when: prephitmp_15 & != 0
## : PHI <_1(7), pretmp_14(3)>
## : _1(7) != 0 || pretmp_14 != 0
## : BIT_FIELD_REF != 0 || BIT_FIELD_REF != 0
## : BIT_FIELD_REF != 0
# .MEM_12 = VDEF <.MEM_6>
z = y_5;
[local count: 1073741824]:
# .MEM_7 = PHI <.MEM_6(8), .MEM_12(5)>
# VUSE <.MEM_7>
return;
}
[Bug tree-optimization/99918] [9/10/11 Regression] suboptimal code for bool bitfield tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918 --- Comment #4 from Martin Sebor --- (In reply to Andrew Pinski from comment #1) > This comes down to lowering bitfields too soon. > my bet it will happen even integer bitfields will have a problem. Yes, unsigned bit-fields suffer the same problem but unlike for _Bool, GCC never emitted optimal code for those for this test case.
[Bug rtl-optimization/12754] Faulty register allocation under certain circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12754 Stafford Horne changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |shorne at gcc dot gnu.org Status|NEW |SUSPENDED --- Comment #6 from Stafford Horne --- Suspending as this is on the old re-written port.
[Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Martin Sebor changed:
What|Removed |Added
Blocks||99918
--- Comment #1 from Martin Sebor ---
The IL below shows there is enough information in the IL for the warning to
determine that x_5 is never read from.
void g (struct B b)
{
_Bool b$j;
_Bool b$i;
_Bool x;
unsigned char _1;
unsigned char _2;
unsigned char _3;
unsigned char _4;
[local count: 1073741824]:
b$i_11 = b.i;
_1 = VIEW_CONVERT_EXPR(b);
_2 = _1 & 1;
if (_2 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
[local count: 1073741824]:
# x_5 = PHI
# b$j_10 = PHI <0(2), b$i_11(3)>
b.j = b$j_10;
_3 = VIEW_CONVERT_EXPR(b);
_4 = _3 & 2;
if (_4 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
z = x_5;
[local count: 1073741824]:
return;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
[Bug 99918] [9/10/11 Regression] suboptimal code for bool bitfield tests
[Bug rtl-optimization/12754] Faulty register allocation under certain circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12754 Stafford Horne changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/12754] Faulty register allocation under certain circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12754 Stafford Horne changed: What|Removed |Added Resolution|FIXED |WONTFIX
[Bug c++/98440] [9/10/11 Regression] Accepts ill-formed reinterpret_cast(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:07f56824fd4da14a48030e698c8eb58de951c741 commit r11-7994-g07f56824fd4da14a48030e698c8eb58de951c741 Author: Jason Merrill Date: Mon Apr 5 15:50:48 2021 -0400 c++: reinterpret_cast from prvalue to rvalue ref [PR98440] In r260622 I allowed this under the general principle that [basic.lval] "Whenever a prvalue appears as an operand of an operator that expects a glvalue for that operand, the temporary materialization conversion (7.3.4) is applied to convert the expression to an xvalue." But [expr.reinterpret.cast] specifically excludes creating a temporary in this case. gcc/cp/ChangeLog: PR c++/98440 * typeck.c (build_reinterpret_cast_1): Don't perform temporary materialization. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/rv-cast6.C: Expect reinterpret_cast error. * g++.dg/cpp0x/reinterpret_cast2.C: Adjust message. * g++.old-deja/g++.jason/rvalue3.C: Likewise.
[Bug c++/96311] [8/9/10/11 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b07dd9b0d0e501a0083da79e2bca17041c007ec8 commit r11-7995-gb07dd9b0d0e501a0083da79e2bca17041c007ec8 Author: Jason Merrill Date: Mon Apr 5 16:22:51 2021 -0400 c++: -Wunused, constant, and generic lambda [PR96311] We never called mark_use for a return value in a function with dependent return type. In that situation we don't know if the use is as an rvalue or lvalue, but we can use mark_exp_read instead. gcc/cp/ChangeLog: PR c++/96311 * typeck.c (check_return_expr): Call mark_exp_read in dependent case. gcc/testsuite/ChangeLog: PR c++/96311 * g++.dg/cpp1y/lambda-generic-Wunused.C: New test.
[Bug c++/96311] [8/9/10 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] false |false positive for |positive for |-Wunused-but-set-variable |-Wunused-but-set-variable |(const/constexpr identifier |(const/constexpr identifier |used in generic lambda) |used in generic lambda) --- Comment #7 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/98440] [9/10 Regression] Accepts ill-formed reinterpret_cast(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440 Jason Merrill changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] Accepts |Accepts ill-formed |ill-formed |reinterpret_cast(1) |reinterpret_cast(1) Known to fail|11.0| Known to work||11.0 --- Comment #3 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/95870] [8/9/10 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE |(segmentation fault) in |(segmentation fault) in |most_general_template(), in |most_general_template(), in |gcc/cp/pt.c |gcc/cp/pt.c --- Comment #9 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/98481] [10 Regression] std::vector::size_type as return type gets tagged with abi:cxx11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98481 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed in 10.3 with explicit -fabi-version=0 or =15. Fixed in 11 by default.
[Bug c++/98810] [9/10 Regression] [C++20] ICE in tsubst_copy, at cp/pt.c:16771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98810 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jason Merrill --- Fixed for 9.4/10.3/11.
[Bug c++/99795] [8/9/10/11 Regression] -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug sanitizer/85777] [8/9/10/11 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Martin Sebor --- Based on comment #14 it sounds like the originally reported problem has been resolved. The test case in that comment doesn't trigger a warning in GCC 11 one way or the other, but also doesn't seem related to the original problem report (if what you see is not what you expect please open a separate bug for just that problem.)
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 85777, which changed state. Bug 85777 Summary: [8/9/10/11 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/99883] A couple of minor misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99883 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-04-05 Component|other |middle-end CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Confirmed. Let me fix them.
[Bug bootstrap/99920] New: [10 regression] ICE building gcc 10 on power 7 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99920 Bug ID: 99920 Summary: [10 regression] ICE building gcc 10 on power 7 BE Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:6aa75d3740c309aeead9c430a6779f4a347f4403, r10-9659 This occurs at this commit but it is not the source of it (I am still looking). Configure used: /home/seurer/gcc/git/gcc-10-test/configure --enable-languages=c,fortran,c++ --with-cpu=power7 --enable-bootstrap --enable-multilib A whole bunch of ICEs like the following occur when building gcc on power 7 BE. It does not occurs on power 8 BE. /home/seurer/gcc/git/build/gcc-10-test/./gcc/xgcc -B/home/seurer/gcc/git/build/gcc-10-test/./gcc/ -B/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/sys-include -fno-checking -g -O2 -m32 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../../.././gcc -I/home/seurer/gcc/git/gcc-10-test/libgcc -I/home/seurer/gcc/git/gcc-10-test/libgcc/. -I/home/seurer/gcc/git/gcc-10-test/libgcc/../gcc -I/home/seurer/gcc/git/gcc-10-test/libgcc/../include -I/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/dpd -I/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS during GIMPLE pass: store-merging In file included from /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:56: /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c: In function '__muldi3': /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.h:219:20: internal compiler error: Segmentation fault 219 | #define __NDW(a,b) __ ## a ## di ## b |^~ /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.h:273:18: note: in expansion of macro '__NDW' 273 | #define __muldi3 __NDW(mul,3) | ^ /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:548:1: note: in expansion of macro '__muldi3' 548 | __muldi3 (DWtype u, DWtype v) | ^~~~ 0x111d588f crash_signal /home/seurer/gcc/git/gcc-10-test/gcc/toplev.c:328 0x125d1930 trim_filename(char const*) /home/seurer/gcc/git/gcc-10-test/gcc/diagnostic.c:1223 0x125d4273 fancy_abort(char const*, int, char const*) /home/seurer/gcc/git/gcc-10-test/gcc/diagnostic.c:1778 0x10a76dab operand_compare::hash_operand(tree_node const*, inchash::hash&, unsigned int) /home/seurer/gcc/git/gcc-10-test/gcc/fold-const.c:3768 0x10a7766b inchash::add_expr(tree_node const*, inchash::hash&, unsigned int) /home/seurer/gcc/git/gcc-10-test/gcc/fold-const.c:3919 0x1122c2af iterative_hash_expr /home/seurer/gcc/git/gcc-10-test/gcc/tree.h:5207 0x11232c77 tree_operand_hash::hash(tree_node* const&) /home/seurer/gcc/git/gcc-10-test/gcc/tree-hash-traits.h:34 0x1231a2af hash /home/seurer/gcc/git/gcc-10-test/gcc/hash-map-traits.h:50 0x1231b97b get /home/seurer/gcc/git/gcc-10-test/gcc/hash-map.h:184 0x1232fbaf process_store /home/seurer/gcc/git/gcc-10-test/gcc/gimple-ssa-store-merging.c:4883 0x123304a7 execute /home/seurer/gcc/git/gcc-10-test/gcc/gimple-ssa-store-merging.c:5040
[Bug target/99921] New: PowerPC xxeval has the wrong predicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99921 Bug ID: 99921 Summary: PowerPC xxeval has the wrong predicates Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- I noticed that the insn that supports the PowerPC xxeval instruction uses the predicate "altivec_register_operand". It should use the predicate "vsx_register_operand" (or "gpc_reg_operand") to allow the register allocator to chose traditional floating point registers along with traditional Altivec registers.
[Bug fortran/99922] New: Bind(C) with assumed length character should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922
Bug ID: 99922
Summary: Bind(C) with assumed length character should work
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: everythingfunctional at protonmail dot com
Target Milestone: ---
As of (at least) Fortran 2018, bind(C) should be allowed for procedures with
assumed length character variables, as one can pass CFI_cdesc_t* from the C
side and it's supposed to work.
MWE below
! main.f90
program main
implicit none
interface
subroutine say_hello_c() bind(C)
end subroutine
end interface
call say_hello_c()
end program
! say_hello_fortran.f90
subroutine say_hello_fortran(name) bind(C)
use iso_c_binding, only: c_char
implicit none
character(len=*, kind=c_char), intent(in) :: name
print *, "Hello from Fortran, " // name // "!"
end subroutine
! say_hello_c.c
#include
#include
extern void say_hello_fortran(CFI_cdesc_t * name_descriptor);
void say_hello_c() {
char * name = "World";
CFI_cdesc_t name_descriptor;
int error_code = CFI_establish(
&name_descriptor,
name,
CFI_attribute_other,
CFI_type_char,
strlen(name),
0,
NULL);
say_hello_fortran(&name_descriptor);
}
Compiling say_hello_fortran.f90 gives the error
say_hello_fortran.f90:1:33:
1 | subroutine say_hello_fortran(name) bind(C)
| 1
Error: Character argument ‘name’ at (1) must be length 1 because procedure
‘say_hello_fortran’ is BIND(C)
But the relevant text from the standard says (from section 18.3.6):
any dummy argument without the VALUE attribute corresponds to a formal
parameter of the prototype that is of a pointer type, and either
the dummy argument is a nonallocatable nonpointer variable of type CHARACTER
with assumed character length and the formal parameter is a pointer to
CFI_cdesc_t,
So this is supposed to be allowed, and I can confirm that I can compile and
execute the above example and obtain the expected result with Intel (ifort and
icc).
output of gfortran --version:
GNU Fortran (Ubuntu 10.2.0-13ubuntu1) 10.2.0
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.
[Bug middle-end/85872] False positive for -Wmaybe-unitialized (compile-time limit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85872 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to fail|7.2.1, 8.1.0|10.2.0, 11.0, 5.5.0, 7.2.0, ||8.3.0, 9.1.0 Last reconfirmed|2018-09-10 00:00:00 |2021-4-5 --- Comment #4 from Martin Sebor --- Confirmed with GCC 11 and that bumping up the conservative MAX_CHAIN_LEN limit avoids the false positive.
[Bug c++/86485] [8 Regression] "anonymous" maybe-uninitialized false positive with ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485 Martin Sebor changed: What|Removed |Added Known to fail|9.0 | Known to work||9.1.0 CC||msebor at gcc dot gnu.org Last reconfirmed|2018-07-11 00:00:00 |2021-4-5 --- Comment #10 from Martin Sebor --- Confirming this is fixed in GCC 9 but still present in GCC 8.
[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/99922] Bind(C) with assumed length character should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-04-06
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Brad Richardson from comment #0)
>
> So this is supposed to be allowed, and I can confirm that I can compile and
> execute the above example and obtain the expected result with Intel (ifort
> and icc).
>
What result did Intel produce?
This patch suppresses the error message, which allows the code
to compile. gfortran may produces wrong code. Someone else can
investigate that issue
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 9039c9dca2a..b10a92ca234 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1549,19 +1549,21 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
sym->ns->proc_name->name);
}
- /* Character strings are only C interoperable if they have a
- length of 1. */
- if (sym->ts.type == BT_CHARACTER && !sym->attr.dimension)
+ /* In F2008 (and earlier?) a character string is only C
+interoperable if it has a length of 1. With F2018, if the
+string is a dummy argument, it can have an assumed length if
+the formal argument is CFI_cdesc_t. */
+ if (sym->ts.type == BT_CHARACTER && !sym->attr.dimension
+ && !((gfc_option.allow_std & GFC_STD_F2018) && sym->attr.dummy))
{
gfc_charlen *cl = sym->ts.u.cl;
+
if (!cl || !cl->length || cl->length->expr_type != EXPR_CONSTANT
|| mpz_cmp_si (cl->length->value.integer, 1) != 0)
{
- gfc_error ("Character argument %qs at %L "
-"must be length 1 because "
-"procedure %qs is BIND(C)",
-sym->name, &sym->declared_at,
-sym->ns->proc_name->name);
+ gfc_error ("Character argument %qs at %L must be length 1 "
+"because procedure %qs is BIND(C)", sym->name,
+&sym->declared_at, sym->ns->proc_name->name);
retval = false;
}
}
[Bug c++/99923] New: Rejects valid if statement with default argument concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99923
Bug ID: 99923
Summary: Rejects valid if statement with default argument
concept
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/zPPMEaa33
template concept C = true;
void foo() { if (C<>) return; }
gcc rejects this valid grammar with:
: In function 'void foo()':
:2:18: error: expected 'auto' or 'decltype(auto)' after 'C<>'
2 | void foo() { if (C<>) return; }
| ^~~
[Bug c++/99901] [8/9/10/11 Regression] static const class var implemented with constexpr doesn't emit symbols in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99901 Patrick Palka changed: What|Removed |Added Target Milestone|--- |8.5 Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Last reconfirmed||2021-04-06 Summary|static const class var |[8/9/10/11 Regression] |implemented with constexpr |static const class var |doesn't emit symbols in |implemented with constexpr |C++17 mode |doesn't emit symbols in ||C++17 mode --- Comment #1 from Patrick Palka --- Confirmed. Seems to have started with r7-3808.
[Bug c++/99899] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99899 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:66de517b1c1dd22df7914f8e9a083cd5a73adbe2 commit r11-7997-g66de517b1c1dd22df7914f8e9a083cd5a73adbe2 Author: Patrick Palka Date: Mon Apr 5 23:35:56 2021 -0400 c++: placeholder type constraint in structured binding [PR99899] In this PR, we're crashing because the constraint handling inside do_auto_deduction doesn't expect to see an adc_decomp_type context. This patch fixes this by treating adc_decomp_type like adc_variable_type or adc_return_type during placeholder type constraint checking. Meanwhile, I noticed we weren't checking constraints at all when binding an array via a structured binding, since do_auto_deduction would exit early and bypass the constraint check. This patch fixes this by replacing the early exit with an appropriate setup of the 'targs' vector. gcc/cp/ChangeLog: PR c++/99899 * pt.c (do_auto_deduction): Don't exit early when deducing the array type of a structured binding. Also handle adc_decomp_type during constraint checking. gcc/testsuite/ChangeLog: PR c++/99899 * g++.dg/cpp2a/concepts-placeholder7.C: New test. * g++.dg/cpp2a/concepts-placeholder8.C: New test.
[Bug c++/99899] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99899 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/91241] [8/9/10/11 Regression] internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241 --- Comment #14 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:55f40d968b0bd3be4478a9481e829a99ee0fa04f commit r11-7998-g55f40d968b0bd3be4478a9481e829a99ee0fa04f Author: Jason Merrill Date: Mon Apr 5 22:50:44 2021 -0400 c++: mangling of lambdas in default args [PR91241] In this testcase, the parms remembered in LAMBDA_EXPR_EXTRA_SCOPE are no longer the parms of the FUNCTION_DECL they have as their DECL_CONTEXT, so we were mangling both lambdas as parm #0. But since the parms are numbered from right to left we don't need to need to find them in the FUNCTION_DECL, we can measure their own DECL_CHAIN. gcc/cp/ChangeLog: PR c++/91241 * mangle.c (write_compact_number): Add sanity check. (write_local_name): Use list_length for parm number. gcc/testsuite/ChangeLog: PR c++/91241 * g++.dg/abi/lambda-defarg1.C: New test.
[Bug target/99924] New: ICE in vect_schedule_slp_node, at tree-vect-slp.c:6040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99924 Bug ID: 99924 Summary: ICE in vect_schedule_slp_node, at tree-vect-slp.c:6040 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: aarch64-linux-gnu gfortran-11.0.1-alpha20210404 snapshot (g:c3d3bb0f03dbd02512ab46979088ee8e22520c24) ICEs when compiling the following testcase w/ -march=armv8.3-a -O1 -ftree-slp-vectorize -fvect-cost-model=unlimited: subroutine cunhj (tfn, asum, bsum) implicit none complex :: up, tfn, asum, bsum real :: ar up = tfn * ar bsum = up + ar asum = up + asum return end subroutine cunhj % aarch64-linux-gnu-gfortran-11.0.1 -march=armv8.3-a -O1 -ftree-slp-vectorize -fvect-cost-model=unlimited -c ufhzvqzb.f90 during GIMPLE pass: slp ufhzvqzb.f90:1:16: 1 | subroutine cunhj (tfn, asum, bsum) |^ internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.c:6040 0x7c377c vect_schedule_slp_node /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6040 0x123a4fc vect_schedule_scc /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6355 0x123a26f vect_schedule_scc /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336 0x123a26f vect_schedule_scc /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336 0x123a26f vect_schedule_scc /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336 0x123a26f vect_schedule_scc /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6336 0x123ab5f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:6471 0x123c4db vect_slp_region /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:4985 0x123c4db vect_slp_bbs /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:5095 0x123db1c vect_slp_function(function*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vect-slp.c:5181 0x12444fa execute /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/tree-vectorizer.c:1450
[Bug c++/91241] [8/9/10 Regression] internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |internal compiler error:|internal compiler error: |symtab_node::verify failed |symtab_node::verify failed --- Comment #15 from Jason Merrill --- Fixed for GCC 11 so far.
[Bug tree-optimization/88975] ICE: Segmentation fault (in dominated_by_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88975 --- Comment #3 from Arseny Solokha --- gcc-11.0.1-alpha20210404 snapshot (g:c3d3bb0f03dbd02512ab46979088ee8e22520c24) accepts all three testcases w/o ICE. Is it a duplicate of PR99007?
[Bug c++/99901] [8/9/10/11 Regression] static const class var implemented with constexpr doesn't emit symbols in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99901 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99898 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-06 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Martin Liška --- @honza, @richi: Do we know about any format breakage in between 10.2 release and the current tip?
[Bug target/99905] wrong code with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99905 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-04-06 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- > Probably present since -mgeneral-regs-only introduction. Confirmed that, it's since r7-928-gce3a16ff1f59e6db.
[Bug c++/99925] New: Missing 'inconsistent deduction for ‘auto’' error when using type-constraint placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99925 Bug ID: 99925 Summary: Missing 'inconsistent deduction for ‘auto’' error when using type-constraint placeholder Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Maybe dup of PR 79009. https://godbolt.org/z/sGacxEj31 template concept C = true; C auto i = 0, j = 0.5, k = "";
[Bug target/99905] wrong code with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99905 --- Comment #2 from Zdenek Sojka --- (In reply to Martin Liška from comment #1) > > Probably present since -mgeneral-regs-only introduction. > > Confirmed that, it's since r7-928-gce3a16ff1f59e6db. Thank you for the bisection. If -mgeneral-regs-only is not used, the flag can be replaced by -mno-mmx -mno-sse: $ x86_64-pc-linux-gnu-gcc -Os -mno-mmx -mno-sse testcase.c $ ./a.out Aborted
[Bug target/99905] [8/9/10/11 Regression] wrong code with -mno-mmx -mno-sse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99905 Zdenek Sojka changed: What|Removed |Added Summary|wrong code with |[8/9/10/11 Regression] |-mgeneral-regs-only |wrong code with -mno-mmx ||-mno-sse --- Comment #3 from Zdenek Sojka --- (In reply to Zdenek Sojka from comment #2) > (In reply to Martin Liška from comment #1) > > > Probably present since -mgeneral-regs-only introduction. > > > > Confirmed that, it's since r7-928-gce3a16ff1f59e6db. > > Thank you for the bisection. > If -mgeneral-regs-only is not used, the flag can be replaced by -mno-mmx > -mno-sse: > > $ x86_64-pc-linux-gnu-gcc -Os -mno-mmx -mno-sse testcase.c > $ ./a.out > Aborted ... which seems a regression from gcc-6.5.0
[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99898 --- Comment #4 from Richard Biener --- The LTO minor saw a bump around Sep 10 last year already so the object files must be younger or LTO should complain. The specific assert that triggers isn't a sign of format divergence (it would be a very odd one to trigger) but instead there's an unexpected out-of-band tree object in the stream. Can you maybe reproduce the issue without re-using old objects? I'm not aware of any specific change where we forgot the bumping but there were a lot of changes and since we did already bump bumping again shouldn't cause any harm. Still I'd like to be sure we're not seeing a genuine streaming bug here.
