[Bug c++/99800] New: ICE Segmentation fault when put lambda in template parameter list

[hewillk at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99800

Bug ID: 99800
   Summary: ICE Segmentation fault when put lambda in template
parameter list
   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/b6cnKo7ej

template  struct A {};
template  struct B {};
template  using b = B<[]{ return a; }()>;



:3:45: internal compiler error: Segmentation fault
3 | template  using b = B<[]{ return a; }()>;
  | ^
0x1cfb7f9 internal_error(char const*, ...)
???:0
0x6c42c5 resolve_args(vec*, int)
???:0
0x909251 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x929663 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x97fb6d finish_template_type(tree_node*, tree_node*, int)
???:0
0x8e12ad c_parse_file()
???:0
0xa600a2 c_common_parse_file()
???:0
Please submit a full bug report,

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[haoxintu at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694

--- Comment #7 from Haoxin Tu  ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r9-7156-g33579b59aaf02eb7.

Hi Martin. I am sorry to bother you, and I just have a question about how to
find a bad commit quickly in GCC.

As far as I know, we can use git bitset to set a bad and good commit to then
apply binary search to find the exact place that caused the error(I usually do
like this). My question is, is this means I should always find a commit (to be
tested), then build the source code and run the given test case to tell a
bad/good result? My concern is that build a GCC from a source code may take a
relatively long time (maybe more than half an hour), so if the number of
commits is much, it will take a long time to find the error commit. Is my
understanding correct or not? 

Also, I am wondering if you are using an automatic tool or other approaches
that can quickly find the bad commit to cause the problem. If I learned how to
do this quickly, I'd like to do the bitset myself and tell the bad commit when
I submit a report next time.

Please correct me if I am wrong and any suggestions are welcome! Thank you very
much!


Best,
Haoxin

[Bug target/85907] AIX: static libstdc++ and exceptions causes abort

[dje at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85907

--- Comment #4 from David Edelsohn  ---
There still are problems because of the manner in which AIX statically links. 
Normally AIX does not create separate archives of object files for static
linking; one statically links by statically linking against the shared object. 
This combination can create multiple EH tables, which prevents GCC EH from
working properly.  To link statically, one much ensure that there is only on
set of EH tables -- not one in the main application and another one in the
statically linked shared library.

[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832

--- Comment #6 from Martin Sebor  ---
In the reduced test cases (in comment #3 and comment #4) d is a global variable
so it's value is zero.  c is assigned in the first iteration of the loop (when
e is zero) and used in subsequent iterations when it has a defined value, so
the warning .seems like a clear false postive to me.  (I didn't look at the big
test case.)

[Bug c++/71484] Class with implicit public constructor triggers `-Wctor-dtor-privacy`

[e.fokken+gnu at posteo dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71484

Eike  changed:

   What|Removed |Added

 CC||e.fokken+gnu at posteo dot de

--- Comment #6 from Eike  ---
The following code also triggers the warning, although it shouldn't in my
opinion.
Here the private static function is used for initializing a public data member.
My g++ --version returns:
g++ (Debian 10.2.1-6) 10.2.1 20210110


  template  struct static_arbitrary_seed {
  private:
static constexpr IntType fnv(IntType hash, const char *pos) {
  return *pos == '\0' ? hash
  : fnv((hash * IntType(16777619U)) ^ *pos, (pos + 1));
}

  public:
static constexpr IntType value = fnv(
IntType(2166136261U ^ sizeof(IntType)), __DATE__ __TIME__ __FILE__);
  };

The warning is:
../pcg-cpp/include/pcg_extras.hpp:578:38: warning: all member functions in
class ‘pcg_extras::static_arbitrary_seed’ are private
[-Wctor-dtor-privacy]

The code is from
https://github.com/imneme/pcg-cpp

in case that is helpful.

[Bug target/85907] AIX: static libstdc++ and exceptions causes abort

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85907

--- Comment #3 from Jonathan Wakely  ---
(In reply to David Edelsohn from comment #2)
> This should be fixed with the recent patch to collect2.c, which will be
> released in GCC 8.2, GCC 7.4, GCC 6.5.

Is it fixed now then?

https://gcc.gnu.org/pipermail/gcc-help/2021-March/139975.html says it's not
working in 9.2.0

[Bug fortran/99798] ICE when compiling a variant of pr87907

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed||2021-03-27
 Status|UNCONFIRMED |NEW

[Bug c++/99737] [modules] malloc(): smallbin double linked list corrupted

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99737

--- Comment #3 from Alexander Lelyakin  ---
And the sequence from comment 1 has changed its error message to:

corrupted double-linked list
corrupted double-linked list
g++: internal compiler error: Aborted signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Probably this bug should be marked as duplicate of 99479.

[Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416

--- Comment #15 from Jonathan Wakely  ---
(In reply to Giuseppe D'Angelo from comment #14)
> This gets evil really quick: the presence of both value_type and
> element_type in an contiguous iterator will make you smash face-first
> against LWG3446, which isn't implemented in GCC 10 AFAICS.

That's right, but it's on my list to backport to the gcc-10 branch, probably in
the next 48 hours.

[Bug c++/99737] [modules] malloc(): smallbin double linked list corrupted

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99737

--- Comment #2 from Alexander Lelyakin  ---
This error is very unstable. 
Each found sequence is not reproducible after few commits.
But some other sequence appears with similar message.

This time such a sequence is:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm
/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 thread
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable
/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 variant
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header functional
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cassert
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cinttypes
/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 locale
/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 cwctype
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header exception
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdlib
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header vector
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdio
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem

malloc(): smallbin double linked list corrupted
In file included from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:53,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/bits/fs_path.h:46,
 from /usr/local/include/c++/11.0.1/filesystem:45:
/usr/local/include/c++/11.0.1/bits/allocated_ptr.h: In destructor
‘std::__allocated_ptr<_Alloc>::~__allocated_ptr()’:
/usr/local/include/c++/11.0.1/bits/allocated_ptr.h:73:32: internal compiler
error: Aborted
   73 |   std::allocator_traits<_Alloc>::deallocate(*_M_alloc, _M_ptr,
1);
  |^
0x110151f crash_signal
../../gcc/gcc/toplev.c:327
0x1d47510 xrealloc
../../gcc/libiberty/xmalloc.c:179
0xa8eb0d void va_heap::reserve(vec*&,
unsigned int, bool)
../../gcc/gcc/vec.h:290
0xa8eb0d vec::reserve(unsigned int, bool)
../../gcc/gcc/vec.h:1778
0xa8eb0d vec::safe_push(cp_token* const&)
../../gcc/gcc/vec.h:1887
0xa8eb0d cp_lexer_save_tokens
../../gcc/gcc/cp/parser.c:1241
0xa8eb0d cp_parser_parse_tentatively
../../gcc/gcc/cp/parser.c:32847
0xabe86d cp_parser_type_name
../../gcc/gcc/cp/parser.c:19219
0xacb256 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:18924
0xaa9e5d cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18516
0xabbc23 cp_parser_type_specifier_seq
../../gcc/gcc/cp/parser.c:23367
0xaba2a4 cp_parser_type_id_1
../../gcc/gcc/cp/parser.c:23170
0xabc893 cp_parser_template_type_arg
../../gcc/gcc/cp/parser.c:23275
0xabc9bf cp_parser_template_argument
../../gcc/gcc/cp/parser.c:17915
0xabc9bf cp_parser_template_argument_list
../../gcc/gcc/cp/parser.c:17826
0xabc9bf cp_parser_enclosed_template_argument_list
../../gcc/gcc/cp/parser.c:30799
0xabdcec cp_parser_template_id
../../gcc/gcc/cp/parser.c:17398
0xabe3eb cp_parser_class_name
../../gcc/gcc/cp/parser.c:24692
0xab595a cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:7002
0xab595a cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6684
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 20210327 (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.


commit 651684b462f979a4e70a668c4c9767a5fd7d223a (HEAD -> master, origin/trunk,
origin/master, origin/HEAD)
Author: GCC Administrator 
Date:   Sat Mar 27 00:16:27 2021 +

Daily bump.

[Bug c/99797] accessing uninitialized automatic variables

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #2 from Andrew Pinski  ---
.

[Bug c/99797] accessing uninitialized automatic variables

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
>Ideally, I think GCC should reject code when it is clearly UB (address not 
>taken).

It can't because it is only undefined at runtime which means if it is never
invoked the undefined behavior will never been seen.

GCC does warn with -Wall which should be good enough for this case:
apinski@xeond:~$ ~/upstream-gcc/bin/gcc  -Wall t77.c -O2 -S
t77.c: In function ‘foo’:
t77.c:9:8: warning: ‘c’ is used uninitialized [-Wuninitialized]
9 | if (!c)
  |^


>Still when taking the address of 'c' the code is not UB
NO it is still undefined.

[Bug c++/99799] New: Explicit instantiation function template with auto deduced return type fails if soft instantiation occurred

[bugzilla at halpernwightsoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99799

Bug ID: 99799
   Summary: Explicit instantiation function template with auto
deduced return type fails if soft instantiation
occurred
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzilla at halpernwightsoftware dot com
  Target Milestone: ---

Source code (4 lines, no preprocessor directives):

template  auto f(T v) { return v; }
extern template auto f(int);
int i = f(0);
template auto f(int);

Compiler command line: g++ -std=c++14 -Wall -c autoreturnbug.cpp

Error produced:

autoreturnbug.cpp:4:15: error: template-id 'f<>' for 'auto f(int)' does not
match any template declaration
4 | template auto f(int);
  |   ^
autoreturnbug.cpp:1:28: note: candidate is: 'template auto f(T)'
1 | template  auto f(T v) { return v; }
  |^

However, if line 3 (int i = f(0)) is removed, the code compiles successfully. 
In the C++14 standard, section [dcl.spec.auto], paragraph 15, it says:

An explicit instantiation declaration (14.7.2) does not cause the instantiation
of an entity declared using a placeholder type, but it also does not prevent
that entity from being instantiated as needed to determine its
type. [ Example:

template  auto f(T t) { return t; }
extern template auto f(int); // does not instantiate f
int (*p)(int) = f; // instantiates f to determine its return type, but an
explicit
// instantiation definition is still required somewhere in the program
— end example ]

I take that to mean that the four lines above should compile.

[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283

--- Comment #13 from Alexander Lelyakin  ---
There is a shorter sequence:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ratio
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ios
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable

In file included from /usr/local/include/c++/11.0.1/bits/unique_ptr.h:42,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:59,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/condition_variable:43:
/usr/local/include/c++/11.0.1/ostream:58:42: internal compiler error: in
assert_definition, at cp/module.cc:4491
   58 | class basic_ostream : virtual public basic_ios<_CharT, _Traits>
  |  ^
0x6e20cf trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4491
0xa5db10 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11321
0xa6d14f trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11401
0xa6f611 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14800
0xa6fc8d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18062
0xa6fe48 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18753
0xa81b8e name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:928
0xa831bb name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.c:1158
0xa85eb4 lookup_name_1
../../gcc/gcc/cp/name-lookup.c:7804
0xa8607a lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.c:7824
0xa94d02 lookup_name(tree_node*, LOOK_want)
../../gcc/gcc/cp/name-lookup.h:401
0xa94d02 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:29375
0xabd64f cp_parser_template_name
../../gcc/gcc/cp/parser.c:17709
0xabdb8f cp_parser_template_id
../../gcc/gcc/cp/parser.c:17324
0xabe3eb cp_parser_class_name
../../gcc/gcc/cp/parser.c:24692
0xab595a cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:7002
0xab595a cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6684
0xaa974c cp_parser_base_specifier
../../gcc/gcc/cp/parser.c:26711
0xaa974c cp_parser_base_clause
../../gcc/gcc/cp/parser.c:26564
0xaa974c cp_parser_class_head
../../gcc/gcc/cp/parser.c:25651
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 20210327 (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 libstdc++/96416] to_address() is broken by static_assert in pointer_traits

[dangelog at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416

--- Comment #14 from Giuseppe D'Angelo  ---
Hello,

(In reply to Glen Joseph Fernandes from comment #11)
> > if it can never be used.
> 
> You're misunderstanding.   to_address(p) requires that pointer_traits is
> valid. It just doesn't need to have a to_address member function.

Thank you for clarifying this. I think the wording in the standard is very
unfortunate, but combined with the realization that pointer_traits isn't
SFINAE-friendly, then it's the only intended meaning.



> If (for contiguous iterators, which came later) you want pointer_traits
> to be valid even when X does not have element_type, that is a design change
> to pointer_traits.

One might claim that pointer_traits should become SFINAE-friendly (like C++17's
iterator_traits), but sure, that's a different design question and not
necessarily needed here.


(In reply to Jonathan Wakely from comment #12)
> (In reply to Giuseppe D'Angelo from comment #10)
> > (By the way, finding this bug is quite hard. Could "address_of" be changed
> > to "to_address" , in the bug description?
> 
> Done.

Thank you!



(In reply to Arthur O'Dwyer from comment #13)
> > And are you recommending that everyone who defines their custom contiguous
> > iterators specializes pointer_traits for them? Call it _quite_ annoying...
> 
> Definitely not! When you define a contiguous iterator type, you should just
> give it a sixth nested typedef alongside the other five (or three in C++20):
> `using element_type = value_type;`. This enables contiguous-iterator
> machinery.
> See
> https://stackoverflow.com/questions/65712091/in-c20-how-do-i-write-a-
> contiguous-iterator/66050521#66050521


This gets evil really quick: the presence of both value_type and element_type
in an contiguous iterator will make you smash face-first against LWG3446, which
isn't implemented in GCC 10 AFAICS.

https://cplusplus.github.io/LWG/issue3446


What's more, the accepted resolution wording for it appears to be wrong:


  template
requires has-member-element-type &&
 same_as,
remove_cv_t>
  struct indirectly_readable_traits
: cond-value-type { };


For const iterators, value_type is actually different from element_type (!).
Thankfully libstdc++ seems to have considered this as a non-standard extension,
https://github.com/gcc-mirror/gcc/commit/186aa6304570e15065f31482e9c27326a3a6679f
 


To summarize:

* should a wording defect be raised against std::to_address(Ptr), to state that
pointer_traits being well-formed is actually a prerequisite?

* should LWG3446's resolution be amended?

* if there's going to be a GCC 10.3, is the commit above solving LWG3446 going
to be cherry-picked into it? Otherwise, either one blacklists GCC 10, or has to
specialize pointer_traits there as a workaround (?).


Thank you all for the insightful comments.

[Bug fortran/99183] Incompatible Runtime types

[dominiq at lps dot ens.fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-27

--- Comment #2 from Dominique d'Humieres  ---
Fortran 7.5.0 gives the error

   v = x
  1
Error: Can't convert CLASS(d1) to CLASS(d2) at (1)

but the code is accepted since GCC8.

So the pr seems a 8/9/10/11 regression.

[Bug fortran/99798] New: ICE when compiling a variant of pr87907

[dominiq at lps dot ens.fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798

Bug ID: 99798
   Summary: ICE when compiling a variant of pr87907
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

Compiling the following variant of pr87907

module m
   interface
  module integer function g(x)
 integer, intent(in) :: x
  end
   end interface
end
submodule(m) m2
contains
   subroutine g(x)  ! { dg-error "mismatch in argument" }
 integer, intent(in) :: x
   end
end

gives

% gfc pr87907_db_2.f90
pr87907_db_2.f90:10:15:

   10 |subroutine g(x)  ! { dg-error "mismatch in argument" }
  |   1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'g' at (1)
pr87907_db_2.f90:11:29:

   11 |  integer, intent(in) :: x
  | 1
Error: Unexpected data declaration statement in CONTAINS section at (1)
f951: internal compiler error: Segmentation fault: 11

The backtrace is

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x106)
  * frame #0: 0x0001000ec2b9 f951`gfc_free_statements(p=0x00f6)
at st.c:295:9
frame #1: 0x0001000f53f7 f951`gfc_free_namespace(ns=0x00014500be00)
at symbol.c:4039:23
frame #2: 0x0001000f5a29 f951`gfc_free_symbol(gfc_symbol*) at
symbol.c:4037:3
frame #3: 0x0001000f59fc f951`gfc_free_symbol(sym=0x000142f0ba50)
frame #4: 0x0001000f53b2
f951`::free_sym_tree(sym_tree=0x000142f0ba20) at symbol.c:3902:22
frame #5: 0x0001000f5400 f951`gfc_free_namespace(ns=0x00014500a200)
at symbol.c:4041:17
frame #6: 0x0001000f7034 f951`gfc_symbol_done_2() at symbol.c:4037:3
frame #7: 0x0001000f7016 f951`gfc_symbol_done_2()
frame #8: 0x000100084689 f951`gfc_done_2() at misc.c:380:21
frame #9: 0x0001000a422a
f951`::clean_up_modules(gsym=0x000142f0b600) at parse.c:6311:14
frame #10: 0x0001000b2e17 f951`gfc_parse_file() at parse.c:6374:20
frame #11: 0x00010010d987 f951`::gfc_be_parse_file() at
f95-lang.c:212:18
frame #12: 0x000100d1a294 f951`::compile_file() at toplev.c:457:25
frame #13: 0x00010120dd9f f951`toplev::main(int, char**) at
toplev.c:2201:24
frame #14: 0x00010120da5e f951`toplev::main(this=0x7ffeefbff09e,
argc=, argv=)
frame #15: 0x00010120ffb1 f951`main(argc=2, argv=0x7ffeefbff0d0) at
main.c:39:22
frame #16: 0x7fff2066d621 libdyld.dylib`start + 1

[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747

[dominiq at lps dot ens.fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013

--- Comment #12 from Dominique d'Humieres  ---
/* Symbol flavors: these are all mutually exclusive.
   12 elements = 4 bits.  */
enum sym_flavor
{
  FL_UNKNOWN = 0, FL_PROGRAM, FL_BLOCK_DATA, FL_MODULE, FL_VARIABLE,
  FL_PARAMETER, FL_LABEL, FL_PROCEDURE, FL_DERIVED, FL_NAMELIST,
  FL_UNION, FL_STRUCT, FL_VOID
};

so code=15 is invalid.

[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747

[dominiq at lps dot ens.fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013

--- Comment #11 from Dominique d'Humieres  ---
With a clean tree at r11-7872 I get

(lldb) b misc.c:309
Breakpoint 1: where = f951`gfc_code2string(mstring const*, int) + 26 at
misc.c:309:22, address = 0x00010008457a
(lldb) run pr96013.f90
Process 14637 launched:
'/opt/gcc/gcc11a/libexec/gcc/x86_64-apple-darwin20.3.0/11.0.1/f951' (x86_64)
Process 14637 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010008457a f951`gfc_code2string(m=0x0001019c00e0,
code=15) at misc.c:309:22
   306m++;
   307  }
   308  
-> 309gfc_internal_error ("gfc_code2string(): Bad code");
   310/* Not reached */
   311  }
   312  
Target 0: (f951) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00010008457a f951`gfc_code2string(m=0x0001019c00e0,
code=15) at misc.c:309:22
frame #1: 0x00010008810c f951`::mio_name(int, const mstring *)
[inlined] mio_name(m=0x0001019bffc0, t=15) at module.c:1800:44
frame #2: 0x000100088102 f951`::mio_name(t=15, m=0x0001019bffc0)
frame #3: 0x00010008816f
f951`::mio_symbol_attribute(attr=0x000142a06520) at module.c:2221:1
frame #4: 0x00010008d633 f951`::mio_symbol(sym=0x000142a064d0) at
module.c:4550:24
frame #5: 0x00010008db98 f951`::write_symbol(n=,
sym=0x000142a064d0) at module.c:5914:14
frame #6: 0x00010008dc42
f951`::write_symbol1_recursion(sp=) at module.c:6117:16
frame #7: 0x000100091baa f951`::dump_module(const char *, int) at
module.c:6150:27
frame #8: 0x000100091b7c f951`::dump_module(const char *, int)
frame #9: 0x000100091b7c f951`::dump_module(name=,
dump_flag=)
frame #10: 0x000100092229 f951`gfc_dump_module(name="m", dump_flag=1)
at module.c:6483:15
frame #11: 0x0001000b2eec f951`gfc_parse_file() at parse.c:6506:23
frame #12: 0x00010010d987 f951`::gfc_be_parse_file() at
f95-lang.c:212:18
frame #13: 0x000100d1a294 f951`::compile_file() at toplev.c:457:25
frame #14: 0x00010120dd9f f951`toplev::main(int, char**) at
toplev.c:2201:24
frame #15: 0x00010120da5e f951`toplev::main(this=0x7ffeefbff09e,
argc=, argv=)
frame #16: 0x00010120ffb1 f951`main(argc=2, argv=0x7ffeefbff0d8) at
main.c:39:22
frame #17: 0x7fff2066d621 libdyld.dylib`start + 1
frame #18: 0x7fff2066d621 libdyld.dylib`start + 1
(lldb) c
Process 14637 resuming
f951: internal compiler error: gfc_code2string(): Bad code

I get the same with the patch in comment 6.

[Bug c/99797] New: accessing uninitialized automatic variables

[muecker at gwdg dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797

Bug ID: 99797
   Summary: accessing uninitialized automatic variables
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

Consider the following example which accesses an uninitialized variable:

static volatile int d = 0;
void bar(int c);
void foo(void)
{
char c;
//
//char *p = 

if (!c)
bar(0);

if (d)
c = 1;

if (c)
bar(1);
}


GCC produces code where 'bar' is called twice. According to the C standard, the
code is UB so this is technically OK. Still I think it is dangerous and I would
prefer a more consistent behavior. 

When taking the address and assigning it to 'p' GCC produces code which
actually checks the variable 'd'. I am not sure why this happens (it is
unnecessary). Still when taking the address of 'c' the code is not UB and the
generated code is OK.

Finally, when taking the address and not assigning it, the code is the same as
for the first case where 'bar' is called twice. This seems incorrect as the
code is not UB (according to my reading of the C standard).

Ideally, I think GCC should reject code when it is clearly UB (address not
taken). If it does not reject the code, I think it should assume an unspecified
yet consistent value is read. Producing code that assumes c == 0 and c != 0 at
different points in time (without intervening write) is really dangerous and
should be avoided.

[Bug c++/99737] [modules] malloc(): smallbin double linked list corrupted

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99737

--- Comment #1 from Alexander Lelyakin  ---
Similar, but somewhat different message:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cwchar
/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 type_traits
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future

corrupted double-linked list
In file included from /usr/local/include/c++/11.0.1/future:43:
/usr/local/include/c++/11.0.1/bits/atomic_futex.h:171:36: internal compiler
error: Aborted
  171 | bool __equal, memory_order __mo,
  |^~~~
0x110151f crash_signal
../../gcc/gcc/toplev.c:327
0x1d474c4 xcalloc
../../gcc/libiberty/xmalloc.c:162
0xc2d30c alloc_page
../../gcc/gcc/ggc-page.c:918
0xc2d30c ggc_internal_alloc(unsigned long, void (*)(void*), unsigned long,
unsigned long)
../../gcc/gcc/ggc-page.c:1294
0xe16c69 ggc_internal_cleared_alloc(unsigned long, void (*)(void*), unsigned
long, unsigned long)
../../gcc/gcc/ggc-common.c:117
0xa25f78 ggc_internal_cleared_alloc(unsigned long)
../../gcc/gcc/ggc.h:143
0xa25f78 maybe_add_lang_decl_raw(tree_node*, bool)
../../gcc/gcc/cp/lex.c:903
0xa2626e retrofit_lang_decl(tree_node*)
../../gcc/gcc/cp/lex.c:972
0xa2626e retrofit_lang_decl(tree_node*)
../../gcc/gcc/cp/lex.c:967
0xac6725 cp_parser_parameter_declaration_list
../../gcc/gcc/cp/parser.c:23607
0xac6ab1 cp_parser_parameter_declaration_clause
../../gcc/gcc/cp/parser.c:23496
0xab7be3 cp_parser_direct_declarator
../../gcc/gcc/cp/parser.c:22145
0xab7be3 cp_parser_declarator
../../gcc/gcc/cp/parser.c:22008
0xacee48 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:21506
0xad5c7b cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:30517
0xad5de6 cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:30089
0xad6590 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:30355
0xaa7998 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:25799
0xaa7998 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24877
0xaa9ec3 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:25193
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 20210327 (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++/92985] missed optimization opportunity for switch linear transformation

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92985

Avi Kivity  changed:

   What|Removed |Added

 CC||a...@cloudius-systems.com

--- Comment #5 from Avi Kivity  ---
Here's another example:


#include 

int strong_ordering_to_int(std::strong_ordering x) {
if (x == std::strong_ordering::equal) {
return 0;
} else if (x == std::strong_ordering::less) {
return -1;
} else if (x == std::strong_ordering::greater) {
return 1;
}
__builtin_unreachable();
}

Used to translate the new std::strong_ordering back to int (in this case for
compatibility with older code, but one can imagine many such translations from
opaque enums to another enum when crossing an API boundary).

gcc generates (-O3)

strong_ordering_to_int(std::strong_ordering):
xorl%eax, %eax
testb   %dil, %dil
je  .L1
xorl%eax, %eax
cmpb$-1, %dil
setne   %al
leal-1(%rax,%rax), %eax
.L1:
ret


Where it could have generated

movsx%dil, %eax
ret

[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU

[manu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832

--- Comment #5 from Manuel López-Ibáñez  ---
Either there is no bug or the reduction is incorrect because the warning in the
testcase is correct since d is uninitialized. Maybe the bug is that it warns
about 'c' and not about 'd', but probably at the time of warning 'd' is long
gone.

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[manu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #6)
> The problem is that when the address of a variable escapes, because GCC
> doesn't track when, when the function from which it escapes calls another
> that might access the escaped variable, the warning (as a result of relying
> on the conservative assumptions the optimizers must make) assumes the called
> function initializes the variable.  Another example of this is function h()
> below.

I don't think these are equivalent testcases. It is OK to assume that the
invisible function initializes the variable. The problem arises when there is a
path that never calls the function but GCC does not see that.

The key here is the logical operator splits the possible paths in two. In one
of the paths, b (comment #5) is never initialized, no matter what you assume
about f(). It also happens with a simple if():

int f (int*);
int g(void);
int foo (void)
{
  int b;
  if (g()) {
f();
  }
  return b;
}

However, a similar construct without  works:

int g(void);
int foo (void)
{
  int b;
  if (g()) {
b = g();
  }
  return b;
}

If you look at the VOPs, there is a chain that goes from the VUSE of b to the
VDEF<(D)> through at least one PHI node.

The "return 0" is problematic because CPP (PR18501) will trigger and mess up
things even more. But the above testcases avoid PR18501 and still show this
bug.

[Bug c++/99427] [modules] in system headers: non-constant condition for static assertion

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99427

--- Comment #2 from Alexander Lelyakin  ---
There is a shorter sequence:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string_view
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ios
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
initializer_list
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header sstream

In file included from /usr/local/include/c++/11.0.1/sstream:38:
/usr/local/include/c++/11.0.1/istream: In function ‘std::basic_istream<_CharT,
_Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT
(&)[_Num])’:
/usr/local/include/c++/11.0.1/istream:840:26: error: non-constant condition for
static assertion
  840 |   static_assert(_Num <=
__gnu_cxx::__numeric_traits::__max);
  |
~^
/usr/local/include/c++/11.0.1/istream:840:26: error: the value of
‘__gnu_cxx::__numeric_traits_integer::__max’ is not usable in a
constant expression
In file included from /usr/local/include/c++/11.0.1/bits/stl_algobase.h:63,
 from /usr/local/include/c++/11.0.1/bits/char_traits.h:39,
 from /usr/local/include/c++/11.0.1/string_view:41,
of module /usr/local/include/c++/11.0.1/string_view, imported at
/usr/local/include/c++/11.0.1/bits/basic_string.h:48,
included from /usr/local/include/c++/11.0.1/string:55,
 from /usr/local/include/c++/11.0.1/bits/locale_classes.h:40,
 from /usr/local/include/c++/11.0.1/bits/ios_base.h:41,
 from /usr/local/include/c++/11.0.1/ios:42,
of module /usr/local/include/c++/11.0.1/ios, imported at
/usr/local/include/c++/11.0.1/istream:38,
included from /usr/local/include/c++/11.0.1/sstream:38:
/usr/local/include/c++/11.0.1/ext/numeric_traits.h:75:27: note:
‘__gnu_cxx::__numeric_traits_integer::__max’ was not initialized with
a constant expression
   75 |   static const _Value __max = __is_signed
  |   ^
/usr/local/include/c++/11.0.1/sstream: At global scope:
/usr/local/include/c++/11.0.1/sstream: warning: not writing module
‘/usr/local/include/c++/11.0.1/sstream’ due to errors

g++ (GCC) 11.0.1 20210326 (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++/99243] [modules] ICE in set_filename, at cp/module.cc:19143

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99243

--- Comment #1 from Alexander Lelyakin  ---
There is a shorter sequence

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header concepts
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header utility
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex

In file included from
/usr/local/include/c++/11.0.1/bits/stl_iterator_base_types.h:71,
 from /usr/local/include/c++/11.0.1/bits/stl_algobase.h:65,
 from /usr/local/include/c++/11.0.1/algorithm:61,
 from /usr/local/include/c++/11.0.1/regex:38:
/usr/local/include/c++/11.0.1/bits/iterator_concepts.h:34: internal compiler
error: in set_filename, at cp/module.cc:19100
   34 | 
  | 
0x6e0cbb module_state::set_filename(Cody::Packet const&)
../../gcc/gcc/cp/module.cc:19100
0xa5a979 maybe_translate_include
../../gcc/gcc/cp/module.cc:19143
0xa5a979 maybe_translate_include
../../gcc/gcc/cp/module.cc:19114
0x1cf5606 _cpp_stack_file
../../gcc/libcpp/files.c:913
0x1ced69e do_include_common
../../gcc/libcpp/directives.c:853
0x1cedbe8 _cpp_handle_directive
../../gcc/libcpp/directives.c:541
0x1cfca60 _cpp_lex_token
../../gcc/libcpp/lex.c:2809
0x1d048c7 cpp_get_token_1
../../gcc/libcpp/macro.c:2839
0xbf070e c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/gcc/c-family/c-lex.c:470
0xa8ee76 cp_lexer_get_preprocessor_token
../../gcc/gcc/cp/parser.c:864
0xad93af cp_lexer_new_main
../../gcc/gcc/cp/parser.c:663
0xad93af c_parse_file()
../../gcc/gcc/cp/parser.c:45253
0xbfd98d c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210326 (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++/99242] [modules] ICE in lookup_mark, at cp/tree.c:2403

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242

--- Comment #1 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 atomic
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header semaphore
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable

In file included from /usr/local/include/c++/11.0.1/condition_variable:47:
/usr/local/include/c++/11.0.1/stop_token:83:29: internal compiler error: in
lookup_mark, at cp/tree.c:2403
   83 | swap(stop_token& __rhs) noexcept
  | ^~~~
0x73cce0 lookup_mark(tree_node*, bool)
../../gcc/gcc/cp/tree.c:2403
0xa81c51 name_lookup::dedup(bool)
../../gcc/gcc/cp/name-lookup.c:482
0xa81c51 name_lookup::dedup(bool)
../../gcc/gcc/cp/name-lookup.c:477
0xa81c51 name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:958
0xa831bb name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.c:1158
0xa85eb4 lookup_name_1
../../gcc/gcc/cp/name-lookup.c:7804
0xa860c4 lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.c:7824
0xa860c4 lookup_name(tree_node*)
../../gcc/gcc/cp/name-lookup.c:7832
0x9f2eca find_last_decl
../../gcc/gcc/cp/decl2.c:1509
0x9f2eca cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1595
0x9d4b8c grokfndecl
../../gcc/gcc/cp/decl.c:10061
0x9dcddd grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:13579
0x9e9be8 grokmethod(cp_decl_specifier_seq*, cp_declarator const*, tree_node*)
../../gcc/gcc/cp/decl.c:17564
0xa9aa68 cp_parser_save_member_function_body
../../gcc/gcc/cp/parser.c:30663
0xad7a8a cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:26326
0xaa7998 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:25799
0xaa7998 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24877
0xaa9ec3 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:25193
0xaa9ec3 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18440
0xaaae59 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:15062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210326 (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++/99479] [modules] ICE Aborted signal terminated program cc1plus

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99479

--- Comment #6 from Alexander Lelyakin  ---
There is a shorter sequence:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cerrno
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header csignal
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future

corrupted double-linked list
corrupted double-linked list
g++: internal compiler error: Aborted signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

g++ (GCC) 11.0.1 20210326 (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++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283

--- Comment #12 from Alexander Lelyakin  ---
Still reproduces:

/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 string_view
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header mutex
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future

In file included from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:53,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/condition_variable:43,
 from /usr/local/include/c++/11.0.1/future:39:
/usr/local/include/c++/11.0.1/bits/allocated_ptr.h:48:32: internal compiler
error: in assert_definition, at cp/module.cc:4491
   48 |   using pointer = typename allocator_traits<_Alloc>::pointer;
  |^~~~
0x6e20cf trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4491
0xa5db10 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11321
0xa6d607 trees_in::read_var_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11509
0xa6f611 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14800
0xa6fc8d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18062
0xa6fd4f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18720
0xa6a000 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9662
0xa6aaa1 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6414
0xa68867 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7058
0xa68867 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8928
0xa68c9f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9146
0xa6aaa1 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6414
0xa68867 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7058
0xa68867 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8928
0xa68c9f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9146
0xa6b1f2 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6622
0xa68867 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7058
0xa68867 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8928
0xa68c9f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9146
0xa6b200 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6623
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210326 (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.

commit 42a21b4cb540be93548a6ff6d4cb4a73ab1665be