[Bug c++/99274] [modules] Error compiling some system headers: "wrong number of template arguments (1, should be 2)"

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

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

--- Comment #1 from Alexander Lelyakin  ---
Previously I have seen such message only in connection with ,
but it happends also without it. 
Another header causing such error is :

g++ -std=c++20 -fmodules-ts -x c++-system-header iterator
g++ -std=c++20 -fmodules-ts -x c++-system-header regex

In file included from /usr/local/include/c++/11.0.1/locale:40,
 from /usr/local/include/c++/11.0.1/regex:44:
/usr/local/include/c++/11.0.1/bits/locale_facets.h:121:31: error: wrong number
of template arguments (1, should be 2)
  121 | ostreambuf_iterator<_CharT>
  |   ^
In file included 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/stl_algobase.h:454:11: note: provided for
‘template class std::ostreambuf_iterator’
  454 | class ostreambuf_iterator;
  |   ^~~
In file included from /usr/local/include/c++/11.0.1/locale:40,
 from /usr/local/include/c++/11.0.1/regex:44:
/usr/local/include/c++/11.0.1/bits/locale_facets.h:122:39: error: wrong number
of template arguments (1, should be 2)
  122 | __write(ostreambuf_iterator<_CharT> __s, const _CharT* __ws, int
__len)
  |   ^
In file included 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/stl_algobase.h:454:11: note: provided for
‘template class std::ostreambuf_iterator’
  454 | class ostreambuf_iterator;
  |   ^~~
In file included from /usr/local/include/c++/11.0.1/locale:40,
 from /usr/local/include/c++/11.0.1/regex:44:
/usr/local/include/c++/11.0.1/bits/locale_facets.h: In function ‘int
std::__write(int, const _CharT*, int)’:
/usr/local/include/c++/11.0.1/bits/locale_facets.h:124:11: error: request for
member ‘_M_put’ in ‘__s’, which is of non-class type ‘int’
  124 |   __s._M_put(__ws, __len);
  |   ^~
/usr/local/include/c++/11.0.1/regex: At global scope:
/usr/local/include/c++/11.0.1/regex: warning: not writing module
‘/usr/local/include/c++/11.0.1/regex’ due to errors

g++ (GCC) 11.0.1 20210312 (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++/99558] wrong argument types reported for "no matching function" error message if ctor argument is a variable

[jfhart085 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from J. Hart  ---
Thank you very much for your kind attention and assistance.  I had 
thought it was indicating a reference rather than an lvalue.  Your 
correction is most useful and appreciated.  I deliberately introduced 
the second error to demonstrate the first, so the second one was expected.

Thanks again,

J. Hart

On 03/12/2021 06:30 PM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99558
>
> Jonathan Wakely  changed:
>
> What|Removed |Added
> 
>   Resolution|--- |INVALID
>   Status|UNCONFIRMED |RESOLVED
>
> --- Comment #1 from Jonathan Wakely  ---
> (In reply to J. Hart from comment #0)
>> $ g++ -c -o utl2.o utl2.cc
>> utl2.cc: In function "int main()":
>> utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int&, int)"
>>
>> correct argument type: constant used as argument, first argument is
>> correctly shown as "int"
> GCC is correct. When you use a variable you are passing an lvalue of type int,
> which is what int& means. When you pass a constant it is an rvalue, i.e. int.
>
>> $ g++ -D DBG1 -c -o utl2.o utl2.cc
>> utl2.cc: In function "int main()":
>> utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int, int)"
> Because you're passing two rvalues.
>

[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 #5 from Alexander Lelyakin  ---
In several previous version this message was not seen, but after last commits:

g++ -std=c++20 -fmodules-ts -x c++-system-header syncstream
g++ -std=c++20 -fmodules-ts -x c++-system-header vector
g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem
g++ -std=c++20 -fmodules-ts -x c++-system-header string_view
g++ -std=c++20 -fmodules-ts -x c++-system-header numbers
g++ -std=c++20 -fmodules-ts -x c++-system-header mutex
g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_set
g++ -std=c++20 -fmodules-ts -x c++-system-header stack
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:4489
   48 |   using pointer = typename allocator_traits<_Alloc>::pointer;
  |^~~~
0x6e1aff trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4489
0xa5ca00 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11351
0xa6c637 trees_in::read_var_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11543
0xa6e641 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14842
0xa6ecbd module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18104
0xa6ed7f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18758
0xa68fc0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9681
0xa69a61 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6412
0xa67827 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7056
0xa67827 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8947
0xa67c5f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9165
0xa69a61 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6412
0xa67827 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7056
0xa67827 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8947
0xa67c5f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9165
0xa6a1b2 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6620
0xa67827 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7056
0xa67827 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8947
0xa67c5f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9165
0xa6a1c0 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6621
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 20210312 (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++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
Bug 99227 depends on bug 99238, which changed state.

Bug 99238 Summary: [modules] internal compiler error: segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99238

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug c++/99238] [modules] internal compiler error: segmentation fault

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

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

Alexander Lelyakin  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Alexander Lelyakin  ---
g++ -std=c++20 -fmodules-ts -x c++-system-header condition_variable
g++ -std=c++20 -fmodules-ts -x c++-system-header numbers
g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
g++ -std=c++20 -fmodules-ts -x c++-system-header future

In file included from /usr/local/include/c++/11.0.1/future:43:
/usr/local/include/c++/11.0.1/bits/atomic_futex.h:82:7: internal compiler
error: Segmentation fault
   82 | { }
  |   ^
0x10ffe0f crash_signal
../../gcc/gcc/toplev.c:327
0xc2bb99 clear_marks
../../gcc/gcc/ggc-page.c:1895
0xc2d16c ggc_collect()
../../gcc/gcc/ggc-page.c:2219
0xacd901 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:30020
0xacddac cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:30914
0xaa80a3 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:25158
0xaa8fb3 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:25182
0xaa8fb3 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18429
0xaa9f49 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:15051
0xad4b06 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:30412
0xad4e86 cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:30075
0xad5630 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:30341
0xad7d59 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14057
0xad7329 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14155
0xad7329 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13943
0xad77c2 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:20443
0xad77c2 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:20421
0xad7f18 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14106
0xad876c cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14155
0xad876c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4940
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 20210312 (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 other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

[ian at airs dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 99553, which changed state.

Bug 99553 Summary: libgo/misc/cgo/testcarchive/testdata/main_unix.c:39: 
suspicious compare ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99553

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug go/99553] libgo/misc/cgo/testcarchive/testdata/main_unix.c:39: suspicious compare ?

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Ian Lance Taylor  ---
Thanks, fixed.

[Bug c++/99571] New: ICE for NTTP with pointer to array of union

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 99571
   Summary: ICE for NTTP with pointer to array of union
   Product: gcc
   Version: 11.0
   URL: https://godbolt.org/z/rsc6fs
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/rsc6fs.
```C++
struct I{
  union { int a[1]{}; };
  int*i=a;
};
constexpr I i;
templatestruct C{};
[[maybe_unused]]Cc;
```

[Bug go/99553] libgo/misc/cgo/testcarchive/testdata/main_unix.c:39: suspicious compare ?

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:3972574f11e5d49f12ad88faf2346f77ffc6e523

commit r11-7655-g3972574f11e5d49f12ad88faf2346f77ffc6e523
Author: Ian Lance Taylor 
Date:   Fri Mar 12 19:17:09 2021 -0800

misc/cgo/testcarchive: don't use == for string equality in C code

Backport of https://golang.org/cl/300993.

For PR go/99553

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/301458

[Bug target/99570] New: internal error in extract_constrain_insn

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 99570
   Summary: internal error in extract_constrain_insn
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

This happens in a couple of files when building the linux kernel with -Os,
reduced a test case to:

$ cat compaction.i
typedef struct {
  long a
} b;
enum c { d } e[];
af, ah;
f(b *g) { asm("" : "=m"(g->a)); }
struct h {
  _Bool ab
} static i(struct h *g, long j) {
  long k = 0, l = j;
  for (; j;) {
enum c ad = m();
n();
f([ad]);
k += o();
if (g && g->ab)
  ++j;
p();
  }
  q(l, k);
}
r() {
  for (;;)
i(af, ah);
}

$ x86_64-linux-gnu-gcc-11 -Os -c compaction.i
compaction.i: In function ‘r’:
compaction.i:25:1: error: unrecognizable insn:
   25 | }
  | ^
(insn 22 20 23 4 (parallel [
(set (mem:DI (plus:DI (mult:DI (reg:DI 3 bx [orig:99 _9 ] [99])
(const_int 4 [0x4]))
(symbol_ref:DI ("e") [flags 0x2] )) [2 MEM[(struct b *)_11].a+0 S8 A64])
(asm_operands:DI ("") ("=m") 0 []
 []
 [] compaction.i:6))
(clobber (reg:CC 17 flags))
]) "compaction.i":6:11 -1
 (nil))
during RTL pass: reload
compaction.i:25:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0xce2eb1 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0xce3057 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2670
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2666
0x95f537 check_rtl
../../src/gcc/lra.c:2087
0x17962bc lra(_IO_FILE*)
../../src/gcc/lra.c:2505
0x1794579 do_reload
../../src/gcc/ira.c:5827
0x1794579 execute
../../src/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-linux-gnu-gcc-11 --version
x86_64-linux-gnu-gcc-11 (Ubuntu 11-20210306-1ubuntu1) 11.0.1 20210306
(experimental) [master revision
574e7601829:6b84c9062bc:84185598dc7470bad4e7f8c22b64e3c944efb670]

[Bug c++/99569] New: segfault when running a module

[ryan.burn at gmail dot com via Gcc-bugs]

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

Bug ID: 99569
   Summary: segfault when running a module
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Here's how to reproduce

// a-m.cc
module;

#include 

export module a;

export std::string do_a() {
return "abc";
}

// main.cc
#include 

import a;

int main() {
std::cout << do_a() << "\n";
return 0;
}

If I then run

g++ -fmodules-ts -std=c++20 -c a-m.cc
g++ -fmodules-ts -std=c++20 -c main.cc
g++ *.o
./a.out

the program prints

abc
Segmentation fault

This is the version of gcc I used

root@15a43977d8e1:/t/strfunc# g++ --version
g++ (GCC) 11.0.1 20210311 (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++/99543] ICE module compilation ../../gcc/toplev.c:327

[ryan.burn at gmail dot com via Gcc-bugs]

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

ryan.burn at gmail dot com changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

[Bug c++/99543] ICE module compilation ../../gcc/toplev.c:327

[ryan.burn at gmail dot com via Gcc-bugs]

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

--- Comment #2 from ryan.burn at gmail dot com ---
it worked with 

root@15a43977d8e1:/t/hdr-mod# g++ --version
g++ (GCC) 11.0.1 20210311 (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++/99568] New: ICE when compiling basic module: internal compiler error: in module_may_redeclare, at cp/module.cc:18453

[ryan.burn at gmail dot com via Gcc-bugs]

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

Bug ID: 99568
   Summary: ICE when compiling basic module: internal compiler
error: in module_may_redeclare, at cp/module.cc:18453
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Here's how to reproduce

/// say_hello.cc
module;
#include 
#include 
export module Hello;
// the module purview starts here
// provide a function to users by exporting it
export void SayHello
  (std::string_view const )
{
  std::cout << "Hello " << name << "!\n";
}

/// main.cc
import Hello;

#include 

int main() {
  SayHello("world");
  return 0;
}

If I compile with
g++ -fmodules-ts -std=c++20 -c say_hello.cc
g++ -fmodules-ts -std=c++20 -c main.cc

I get the ICE below.

This is my gcc version

root@15a43977d8e1:/hello-world# g++ --version
g++ (GCC) 11.0.1 20210311 (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.



root@15a43977d8e1:/hello-world# g++ -fmodules-ts -std=c++20 -c main.cc
In file included from /usr/local/include/c++/11.0.1/bits/stl_algobase.h:61,
 from /usr/local/include/c++/11.0.1/bits/char_traits.h:39,
 from /usr/local/include/c++/11.0.1/string_view:41,
 from main.cc:4:
/usr/local/include/c++/11.0.1/bits/cpp_type_traits.h:429:7: error: template
definition of non-template 'enum
std::__is_nonvolatile_trivially_copyable<_Tp>::'
  429 |   enum { __value = __is_trivially_copyable(_Tp) };
  |   ^~~~
/usr/local/include/c++/11.0.1/bits/cpp_type_traits.h:436:12: error:
redefinition of 'struct std::__is_nonvolatile_trivially_copyable'
  436 | struct __is_nonvolatile_trivially_copyable
  |^
In file included from /usr/local/include/c++/11.0.1/bits/stl_algobase.h:61,
 from /usr/local/include/c++/11.0.1/bits/char_traits.h:39,
 from /usr/local/include/c++/11.0.1/ios:40,
 from /usr/local/include/c++/11.0.1/ostream:38,
 from /usr/local/include/c++/11.0.1/iostream:39,
 from say_hello.cc:4,
of module Hello, imported at main.cc:2:
/usr/local/include/c++/11.0.1/bits/cpp_type_traits.h:436:12: note: previous
definition of 'struct std::__is_nonvolatile_trivially_copyable'
  436 | struct __is_nonvolatile_trivially_copyable
  |^
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,
 from main.cc:4:
/usr/local/include/c++/11.0.1/ext/numeric_traits.h:159:41: error: template
definition of non-template 'const int
__gnu_cxx::__numeric_traits_floating<_Value>::__max_digits10'
  159 |   static const int __max_digits10 = __glibcxx_max_digits10(_Value);
  | ^~
/usr/local/include/c++/11.0.1/ext/numeric_traits.h:162:39: error: template
definition of non-template 'const bool
__gnu_cxx::__numeric_traits_floating<_Value>::__is_signed'
  162 |   static const bool __is_signed = true;
  |   ^~~~
/usr/local/include/c++/11.0.1/ext/numeric_traits.h:163:37: error: template
definition of non-template 'const int
__gnu_cxx::__numeric_traits_floating<_Value>::__digits10'
  163 |   static const int __digits10 = __glibcxx_digits10(_Value);
  | ^~
/usr/local/include/c++/11.0.1/ext/numeric_traits.h:164:43: error: template
definition of non-template 'const int
__gnu_cxx::__numeric_traits_floating<_Value>::__max_exponent10'
  164 |   static const int __max_exponent10 =
__glibcxx_max_exponent10(_Value);
  |   ^~~~
In file included from /usr/local/include/c++/11.0.1/bits/move.h:57,
 from /usr/local/include/c++/11.0.1/bits/nested_exception.h:40,
 from /usr/local/include/c++/11.0.1/exception:148,
 from /usr/local/include/c++/11.0.1/ios:39,
 from /usr/local/include/c++/11.0.1/ostream:38,
 from /usr/local/include/c++/11.0.1/iostream:39,
 from say_hello.cc:4,
of module Hello, imported at main.cc:2:
/usr/local/include/c++/11.0.1/type_traits:231:11: error: conflicting global
module declaration 'template using __remove_cv_t = typename
std::remove_cv@Hello::type'
  231 | using __remove_cv_t = typename 

[Bug fortran/93762] Truncation of deferred-length string when passing as optional

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Neil Carlson  ---
It would be great if somebody possessing the necessary skills could invest the
time to fix this. For me this is bug breaks a common usage pattern of including
optional stat, errmsg arguments to procedure interfaces.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

David Malcolm  changed:

   What|Removed |Added

 Blocks||99390

--- Comment #13 from David Malcolm  ---
At least some of the state explosion appears to be due to malfunctioning call
summaries, e.g.:
  function ‘fileExists’, with call string: [(SN: 422 -> SN: 163 in main), (SN:
599 -> SN: 334 in uncompress)]
probably should have been summarized, but wasn't.

Adding this to the call summaries tracker bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390
[Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer

[Bug analyzer/96894] State explosion on gdb's fibheap.c

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

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

David Malcolm  changed:

   What|Removed |Added

 Blocks||99390

--- Comment #4 from David Malcolm  ---
The warnings from -Wanalyzer-too-complex show some deeply nested callstrings
e.g.:

./xgcc -B. -S -fanalyzer ../../src/pr96894.c   -Wanalyzer-too-complex --param
analyzer-bb-explosion-factor=50
../../src/pr96894.c: In function ‘fibheap_consolidate’:
../../src/pr96894.c:3011:23: warning: terminating analysis for this program
point: callstring: [(SN: 89 -> SN: 97 in fibheap_delete), (SN: 59 -> SN: 86 in
fibheap_extr_min_node)] before (SN: 56 stmt: 0):  i_34 = i_16 + 1;EN: 2004, EN:
2014, EN: 2143, EN: 2157, EN: 2275, EN: 2363, EN: 2424, EN: 2697
[-Wanalyzer-too-complex]
 3011 |   for (i = 0; i < D; i++)
  |  ~^~
../../src/pr96894.c:3011:23: warning: terminating analysis for this program
point: callstring: [(SN: 89 -> SN: 97 in fibheap_delete), (SN: 59 -> SN: 86 in
fibheap_extr_min_node)] before (SN: 56 stmt: 0):  i_34 = i_16 + 1;EN: 2004, EN:
2014, EN: 2143, EN: 2157, EN: 2275, EN: 2363, EN: 2424, EN: 2697
[-Wanalyzer-too-complex]
../../src/pr96894.c:3011:23: warning: terminating analysis for this program
point: callstring: [(SN: 144 -> SN: 106 in fibheap_delete_node), (SN: 89 -> SN:
141 in fibheap_extract_min), (SN: 59 -> SN: 86 in fibheap_extr_min_node)]
before (SN: 56 stmt: 0):  i_34 = i_16 + 1;EN: 4777, EN: 4787, EN: 4916, EN:
4930, EN: 5048, EN: 5136, EN: 5197, EN: 6058 [-Wanalyzer-too-complex]
../../src/pr96894.c:3011:23: warning: terminating analysis for this program
point: callstring: [(SN: 144 -> SN: 106 in fibheap_delete_node), (SN: 89 -> SN:
141 in fibheap_extract_min), (SN: 59 -> SN: 86 in fibheap_extr_min_node)]
before (SN: 56 stmt: 0):  i_34 = i_16 + 1;EN: 4777, EN: 4787, EN: 4916, EN:
4930, EN: 5048, EN: 5136, EN: 5197, EN: 6058 [-Wanalyzer-too-complex]

so this is likely an issue with call summarization failing.  Adding to call
summaries tracker.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390
[Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer

[Bug analyzer/95758] Various issues when compiling glibc regex.c

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

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

David Malcolm  changed:

   What|Removed |Added

 Blocks||99390
Summary|-Wanalyzer-use-after-free   |Various issues when
   |false positive when |compiling glibc regex.c
   |compiling glibc regex.c |

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

I tried again with GCC 11 HEAD and I don't see the use-after-free.  If there
are use-after-free bugs, the above looks likely to be another dup of bug 93695.

Adding -Wanalyzer-too-complex shows that the analyzer is hitting complexity
limits and giving up at numerous places in the code (it takes a *long* time on
the attachment) - which could be masking the use-after-free false positive.  It
looks like the call summarization logic is failing, leading to blog-up of the
analysis when all of the various nested function calls are expanded.

I also see many -Wanalyzer-malloc-leak reports, which may or may not be false
positives; difficult to tell without diving into the code.

Updating "Summary" accordingly, and adding to the call summarization tracker.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390
[Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer

[Bug fortran/99112] [11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2646

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
A simple one-liner on top of Paul's patch fixes it:

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 9cf3642f694..5e53d1162fa 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8006,8 +8006,10 @@ gfc_conv_intrinsic_size (gfc_se * se, gfc_expr * expr)
 {
   symbol_attribute attr;
   char *msg;
+  tree temp;
+  tree cond;

-  attr = gfc_expr_attr (e);
+  attr = sym ? sym->attr : gfc_expr_attr (e);
   if (attr.allocatable)
msg = xasprintf ("Allocatable argument '%s' is not allocated",
 e->symtree->n.sym->name);


Submitted: https://gcc.gnu.org/pipermail/fortran/2021-March/055809.html

[Bug rtl-optimization/99567] New: internal error in extract_constrain_insn with asan-stack

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 99567
   Summary: internal error in extract_constrain_insn  with
asan-stack
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

I ran into an internal compiler error while building linux kernels with the
kernel address sanitizer. Reduced it to this test case:

$ gcc-11 --version
gcc-11 (Ubuntu 11-20210306-1ubuntu1) 11.0.1 20210306 (experimental) [master
revision 574e7601829:6b84c9062bc:84185598dc7470bad4e7f8c22b64e3c944efb670]

$ cat tcp_ipv4.i

enum { a };
struct b {
  short c;
};
int d(void);
void e(int, _Bool *);
void f(struct b *, int *);
void g(struct b *h) {
  int i, l;
  volatile char j;
  struct b k = *h;
  void *m = h + k.c;
  l = *(int *)m;
  asm("" : : "g"(l));
lookup:
  i = j;
  int n = d();
  _Bool o = a;
  if (i)
f(h, m);
  e(n, );
  goto lookup;
}

$ gcc-11 -fno-omit-frame-pointer  -fsanitize=address  --param
asan-instrumentation-with-call-threshold=1  --param asan-stack=1 -c -O2
-Wall tcp_ipv4.i 
tcp_ipv4.i: In function ‘g’:
tcp_ipv4.i:23:1: error: unrecognizable insn:
   23 | }
  | ^
(insn 84 83 160 10 (parallel [
(asm_operands/v ("") ("") 0 [
(mem:SI (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -192 [0xff40])) [9
%sfp+-144 S8 A64]) [1 MEM[(int *)m_8]+0 S4 A32])
]
 [
(asm_input:SI ("g") tcp_ipv4.i:14)
]
 [] tcp_ipv4.i:14)
(clobber (reg:CC 17 flags))
]) "tcp_ipv4.i":14:3 -1
 (nil))
during RTL pass: reload
tcp_ipv4.i:23:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0xce2eb1 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0xce3057 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2670
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2666
0x95f537 check_rtl
../../src/gcc/lra.c:2087
0x17962bc lra(_IO_FILE*)
../../src/gcc/lra.c:2505
0x1794579 do_reload
../../src/gcc/ira.c:5827
0x1794579 execute
../../src/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

So far this only happened on x86 targets.

[Bug c++/99566] New: designated initialization rejects explicit constructor

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 99566
   Summary: designated initialization rejects explicit constructor
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced from StackOverflow (https://stackoverflow.com/q/66606143/2069064):

struct A {
explicit A(int);
};

struct B {
A a;
};

A a{10}; // ok
B b{.a{10}}; // error: converting from initializer list
 // would use explicit constructor

But the initialization of the "a" subobject of B should work the same was as
the initialization of the complete object "a".

[Bug analyzer/93355] Analyzer -Wanalysis-too-complex on intl/localealias.c due to poor call summarization

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

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

David Malcolm  changed:

   What|Removed |Added

Summary|Missing diagnostic for  |Analyzer
   |missing fclose in   |-Wanalysis-too-complex on
   |intl/localealias.c  |intl/localealias.c due to
   ||poor call summarization
 Blocks||99390

--- Comment #12 from David Malcolm  ---
(In reply to David Malcolm from comment #11)
> The only remaining issue is (a) (see comment #9 above).

Updating Summary accordingly, and adding to call summaries tracker


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390
[Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer

[Bug c++/99565] New: Bogus identical branches warning when returning references to union members

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 99565
   Summary: Bogus identical branches warning when returning
references to union members
   Product: gcc
   Version: 11.0
   URL: https://godbolt.org/z/9qaz9W
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/9qaz9W.
```C++
struct A {
  union {
int a;
int b;
  };
  int& x() { return 0 ? a : b; }
};
```

[Bug other/99496] [11 regression] g++.dg/modules/xtreme-header-3_c.C ICEs after r11-7557

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-03-12
 Ever confirmed|0   |1

--- Comment #11 from Nathan Sidwell  ---
With the spec hasher returning a constant zero:

// pr99496_a.H
template using __void_t = void;

template
struct __is_referenceable
{ };

template
struct __is_referenceable<_Tp, __void_t<_Tp&>>
{ };

template::value>
struct __is_copy_constructible_impl;

// pr99496_b.C
import "pr99496_a.H";


zathras:180>./cc1plus -quiet -fmodule-header pr99496_a.H && ./cc1plus -quiet
-fmodules-ts pr99496_b.C -fno-module-lazy
pr99496_b.C:3:22: internal compiler error: same canonical type node for
different types 'void' and '__void_t<_Tp&>'
3 | import "pr99496_a.H";
  |  ^
0xeb18c7 comptypes(tree_node*, tree_node*, int)
../../../src/gcc/cp/typeck.c:1554
0xdd03a8 template_args_equal(tree_node*, tree_node*, bool)
../../../src/gcc/cp/pt.c:9211
0xdd05ce comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../../src/gcc/cp/pt.c:9258
0xdb023c spec_hasher::equal(spec_entry*, spec_entry*)
../../../src/gcc/cp/pt.c:1725
0xe37e23 hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../../src/gcc/hash-table.h:981
0xe35749 add_mergeable_specialization(bool, spec_entry*, tree_node*, unsigned
int)
../../../src/gcc/cp/pt.c:30022
0xcce825 trees_in::decl_value()
../../../src/gcc/cp/module.cc:8064
0xcd3f61 trees_in::tree_node(bool)
../../../src/gcc/cp/module.cc:9170

[Bug fortran/99561] gfortran reports an error for a truncation that is permitted by the standard

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Fri, Mar 12, 2021 at 06:39:49PM +, kargl at gcc dot gnu.org wrote:
> --- Comment #1 from kargl at gcc dot gnu.org ---
> (In reply to Michal Paszta from comment #0)
> > In this line of code:
> > 
> > INTEGER(KIND=1) :: var8 = 257_2
> > 
> > we try to cast an integer of kind 2 (16 bits) onto an integer of kind 1 (8
> > bits, value up to 256). This will result in a truncation of the value and is
> > allowed by the Fortran 2018 Standard, see Table 10.9, Fortran 2018 Standard.
> > 
> 
> The sentence preceding Table 10.9 and the table tell you 
> what conversions are allowed and how the conversion is
> done via a built-in intrinsic subprogram.
> 
> It does tell you anything about an out-of-range value.

It does NOT tell

> In fact, an INTEGER(KIND=1) entity has a range of
> [-128,127], so the value of 256 is still out-of-range.

Sigh, "not" was a rather important omission. :(

[Bug fortran/99561] gfortran reports an error for a truncation that is permitted by the standard

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

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> (In reply to Michal Paszta from comment #0)
> > In this line of code:
> > 
> > INTEGER(KIND=1) :: var8 = 257_2
> > 
> > we try to cast an integer of kind 2 (16 bits) onto an integer of kind 1 (8
> > bits, value up to 256). This will result in a truncation of the value and is
> > allowed by the Fortran 2018 Standard, see Table 10.9, Fortran 2018 Standard.
> > 
> 
> The sentence preceding Table 10.9 and the table tell you 
> what conversions are allowed and how the conversion is
> done via a built-in intrinsic subprogram.
> 
> It does tell you anything about an out-of-range value.
> In fact, an INTEGER(KIND=1) entity has a range of
> [-128,127], so the value of 256 is still out-of-range.
> 
> As you have found, gfortran offers a programmer a bullet
> to shoot their foot (i.e, the -fno-range-check option).
> On most (all?) targets supported by gfortran, you'll get 
> two's complement wrap-around semantics.  You do not get
> truncation, where I assume you mean that an out-of-range 
> value is truncated to -128 or 127 as the situation would
> merit (e.g., var8 = 257_2 <-- huge(var8) = 127).
> 
> As to the "no warning problem", you did not ask gfortran
> to generate warnings.  You can use either the -Wall option
> or the -Wconversion option to get a warning when using
> the -fno-range-check option.
> 
> %gfcx -o z -fno-range-check -Wall a.f90
> a.f90:2:33:
> 
> 2 |   integer(1), parameter :: var8 = 257_2
>   | 1
> Warning: Conversion from 'INTEGER(2)' to 'INTEGER(1)' at (1) [-Wconversion]

I should probably not continue with this issue, but I found the
other text in the Standard.  The intrinsic assignment of

var8 = 257_2

with regards to Table 10.9 is then

var8 = int(257_2, kind=1)

But, the Fortran standard contains (18-007r1, p.339)

  A program shall not invoke an intrinsic procedure under circumstances
  where a value to be assigned to a subroutine argument or returned as
  a function result is not representable by objects of the specified
  type and type parameters.

So, int(257_2, 1) is technically not permitted by the Fortran standard,
and gfortran dutifully issues an error if you write such a conversion.

[Bug fortran/99561] gfortran reports an error for a truncation that is permitted by the standard

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Michal Paszta from comment #0)
> In this line of code:
> 
> INTEGER(KIND=1) :: var8 = 257_2
> 
> we try to cast an integer of kind 2 (16 bits) onto an integer of kind 1 (8
> bits, value up to 256). This will result in a truncation of the value and is
> allowed by the Fortran 2018 Standard, see Table 10.9, Fortran 2018 Standard.
> 

The sentence preceding Table 10.9 and the table tell you 
what conversions are allowed and how the conversion is
done via a built-in intrinsic subprogram.

It does tell you anything about an out-of-range value.
In fact, an INTEGER(KIND=1) entity has a range of
[-128,127], so the value of 256 is still out-of-range.

As you have found, gfortran offers a programmer a bullet
to shoot their foot (i.e, the -fno-range-check option).
On most (all?) targets supported by gfortran, you'll get 
two's complement wrap-around semantics.  You do not get
truncation, where I assume you mean that an out-of-range 
value is truncated to -128 or 127 as the situation would
merit (e.g., var8 = 257_2 <-- huge(var8) = 127).

As to the "no warning problem", you did not ask gfortran
to generate warnings.  You can use either the -Wall option
or the -Wconversion option to get a warning when using
the -fno-range-check option.

%gfcx -o z -fno-range-check -Wall a.f90
a.f90:2:33:

2 |   integer(1), parameter :: var8 = 257_2
  | 1
Warning: Conversion from 'INTEGER(2)' to 'INTEGER(1)' at (1) [-Wconversion]

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
Bug 99227 depends on bug 99238, which changed state.

Bug 99238 Summary: [modules] internal compiler error: segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99238

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/99238] [modules] internal compiler error: segmentation fault

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Nathan Sidwell  ---
* 6e885ad3287 2021-03-12 | c++: ICE with using-decl [PR 99238]

[Bug c++/99238] [modules] internal compiler error: segmentation fault

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:6e885ad3287388192e52e9b524dbaa408507c0a4

commit r11-7651-g6e885ad3287388192e52e9b524dbaa408507c0a4
Author: Nathan Sidwell 
Date:   Fri Mar 12 09:02:41 2021 -0800

c++: ICE with using-decl [PR 99238]

This ICE was caused by a stray TREE_VISITED marker.  The lookup
machinery was leaving it there due to the way I'd arranged for it to
be cleared.  That was presuming the name_lookup::value field didn't
change, and that wasn't always true in the using-decl processing.  I
took the opportunity to break out a helper, and then call it
immediately after lookups, rather than wait until destructor time.
Added some asserts the module machinery to catch further cases of
this.

PR c++/99238
gcc/cp/
* module.cc (depset::hash::add_binding_entity): Assert not
visited.
(depset::add::add_specializations): Likewise.
* name-lookup.c (name_lookup::dedup): New.
(name_lookup::~name_lookup): Assert not deduping.
(name_lookup::restore_state): Likewise.
(name_lookup::add_overload): Replace outlined code with dedup
call.
(name_lookup::add_value): Likewise.
(name_lookup::search_namespace_only): Likewise.
(name_lookup::adl_namespace_fns): Likewise.
(name_lookup::adl_class_fns): Likewise.
(name_lookup::search_adl): Likewise.  Add clearing dedup call.
(name_lookup::search_qualified): Likewise.
(name_lookup::search_unqualified): Likewise.
gcc/testsuite/
* g++.dg/modules/pr99238.h: New.
* g++.dg/modules/pr99238_a.H: New.
* g++.dg/modules/pr99238_b.H: New.

[Bug lto/58203] memset/memcpy are discarded with -flto

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kabel at blackhole dot sk

--- Comment #3 from Andrew Pinski  ---
*** Bug 99559 has been marked as a duplicate of this bug. ***

[Bug lto/99559] LTO with -Os -ffreestanding -nodefaultlibs may generate call to memcpy, but fail linking even though memcpy is defined

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
This is a dup of bug 58203.

*** This bug has been marked as a duplicate of bug 58203 ***

[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create

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

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

--- Comment #28 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:d8b84e2771fc2495493d0c66c3cba714484757d7

commit r11-7650-gd8b84e2771fc2495493d0c66c3cba714484757d7
Author: Eric Botcazou 
Date:   Fri Mar 12 17:07:20 2021 +0100

Fix memory constraint bug in SPARC back-end

It's a bug exposed by the recent LRA changes, whereby the T constraint
fails to behave properly when LRA is enabled (unlike when reload is
enabled).  The patch also gets rid of the awkward W constraint, which
is strictly equivalent to m in 64-bit mode and, as a result, renames
the w constraint into W.

gcc/
PR target/99422
* config/sparc/constraints.md (w): Rename to...
(W): ... this and ditch previous implementation.
* config/sparc/sparc.md (*movdi_insn_sp64): Replace W with m.
(*movdf_insn_sp64): Likewise.
(*mov_insn_sp64): Likewise.
* config/sparc/sync.md (*atomic_compare_and_swap_1): Replace
w with W.
(atomic_compare_and_swap_leon3_1): Likewise.
(*atomic_compare_and_swapdi_v8plus): Likewise.
* config/sparc/sparc.c (memory_ok_for_ldd): Remove useless test on
architecture and add missing address validity check during LRA.

[Bug target/99563] [10/11 Regression] Code miscompilation caused by _mm256_zeroupper()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P3  |P2
Summary|Code miscompilation caused  |[10/11 Regression] Code
   |by _mm256_zeroupper()   |miscompilation caused by
   ||_mm256_zeroupper()
   Target Milestone|--- |10.3

--- Comment #1 from Jakub Jelinek  ---
Started with my r10-6451-gb7b3378f91c0641f2ef4d88db22af62a571c9359 change, will
have a look next week.

[Bug target/99564] New: [nvptx] FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O0 (test for excess errors)

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

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

Bug ID: 99564
   Summary: [nvptx] FAIL:
libgomp.oacc-fortran/derivedtypes-arrays-1.f90
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0
-foffload=nvptx-none  -O0  (test for excess errors)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  (test for excess errors)
FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O3 -g  (test for excess errors)
FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -Os  (test for excess errors)
...

In more detail:
...
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90:
In function 'MAIN__._omp_fn.0':^M
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90:90:40:
warning: using vector_length (32), ignoring 1^M
FAIL: libgomp.oacc-fortran/derivedtypes-arrays-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)
...

[Bug sanitizer/96307] [10 Regression] ICE in sanopt on riscv64 since r11-2283-g2ca1b6d009b194286c3ec91f9c51cc6b0a475458

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #11 from Andreas Schwab  ---
Also, the warning text doesn't make sense:

$ gcc -fsanitize=kernel-address -S -xc /dev/null -o /dev/null
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection is not
supported without ‘-fasan-shadow-offset=’ for this target

[Bug other/99496] [11 regression] g++.dg/modules/xtreme-header-3_c.C ICEs after r11-7557

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

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

--- Comment #10 from Nathan Sidwell  ---
thanks, sadly even that's not triggering it for me on a ppc system.  I think
I'm going to have to make the specialization hasher really stupid

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50378=edit
gcc11-pr99562.patch

Untested fix.

[Bug target/99563] New: Code miscompilation caused by _mm256_zeroupper()

[andysem at mail dot ru via Gcc-bugs]

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

Bug ID: 99563
   Summary: Code miscompilation caused by _mm256_zeroupper()
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Consider the following code:

#include 

constexpr unsigned int block_size = 8u;

float compute_generic(const double* data, unsigned int width, unsigned int
height);

inline __attribute__((always_inline))
float compute_avx(const double* data, unsigned int width, unsigned int height)
{
__m128d mm_res = _mm_setzero_pd();
unsigned long block_count = static_cast< unsigned long >((width +
block_size - 1) / block_size)
* static_cast< unsigned long >((height + block_size - 1) / block_size);

float res = static_cast< float >(_mm_cvtsd_f64(mm_res) / static_cast<
double >(block_count));

_mm256_zeroupper();

return res;
}

float compute(const double* data, unsigned int width, unsigned int height)
{
if (width >= 16 && height >= block_size)
{
return compute_avx(data, width, height);
}
else
{
return compute_generic(data, width, height);
}
}

$ g++ -O2 -march=sandybridge -mno-vzeroupper -o test.o test.cpp

https://gcc.godbolt.org/z/dhr7an

The code compiles to:

compute(double const*, unsigned int, unsigned int):
cmp esi, 15
jbe .L2
cmp edx, 7
jbe .L2
vzeroupper
ret
.L2:
jmp compute_generic(double const*, unsigned int, unsigned int)

which leaves the result of compute() uninitialized if AVX path is taken. The
problem disappears if one of the following is done:

- -O2 is replaced with -O1
- -mno-vzeroupper is removed
- _mm256_zeroupper(); call is removed (the upper bits of vector registers is
left dirty, though)

This is a regression in gcc 10 branch and later, gcc 9.x compiles this
correctly.

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

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

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

--- Comment #2 from Jakub Jelinek  ---
Caused by the (IMHO incorrect) PR66728 changes.
We have 2 spots that fill in dw_loc_oprnd?.v.val_wide:
  mem_loc_result = new_loc_descr (dwarf_OP (DW_OP_const_type), 0, 0);
  mem_loc_result->dw_loc_oprnd1.val_class = dw_val_class_die_ref;
  mem_loc_result->dw_loc_oprnd1.v.val_die_ref.die = type_die;
  mem_loc_result->dw_loc_oprnd1.v.val_die_ref.external = 0;
  mem_loc_result->dw_loc_oprnd2.val_class
= dw_val_class_wide_int;
  mem_loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc ();
  *mem_loc_result->dw_loc_oprnd2.v.val_wide = rtx_mode_t (rtl, mode);
and
  loc_result = new_loc_descr (DW_OP_implicit_value,
  GET_MODE_SIZE (int_mode), 0);
  loc_result->dw_loc_oprnd2.val_class = dw_val_class_wide_int;
  loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc ();
  *loc_result->dw_loc_oprnd2.v.val_wide = rtx_mode_t (rtl, int_mode);
and 3 callers of add_AT_wide:
case CONST_WIDE_INT:
  {
wide_int w1 = rtx_mode_t (rtl, MAX_MODE_INT);
unsigned int prec = MIN (wi::min_precision (w1, UNSIGNED),
 (unsigned int)CONST_WIDE_INT_NUNITS (rtl) *
HOST_BITS_PER_WIDE_INT);
wide_int w = wi::zext (w1, prec);
add_AT_wide (die, DW_AT_const_value, w);
  }
and
  else if (dwarf_version >= 5
   && TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (value))) == 128)
/* Otherwise represent the bound as an unsigned value with
   the precision of its type.  The precision and signedness
   of the type will be necessary to re-interpret it
   unambiguously.  */
add_AT_wide (die, attr, wi::to_wide (value));
and
  else
/* Enumeration constants may be wider than HOST_WIDE_INT.  Handle
   that here.  TODO: This should be re-worked to use correct
   signed/unsigned double tags for all cases.  */
add_AT_wide (enum_die, DW_AT_const_value, wi::to_wide (value));

Now, I think the PR66728 changes fixed the first add_AT_wide case (iff GET_MODE
(rtl) is VOIDmode only) but at the same time broke all the other 4 cases, which
really expect that the constants in the debug info will have the expected
length.  Some cases like the DW_OP_implicit_value we're hitting here explicitly
on the producer size, as it fills in the size of the constant.

[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs

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

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

--- Comment #1 from Tom de Vries  ---
I see this as well:
...
PASS: libgomp.c/../libgomp.c-c++-common/task-detach-6.c (test for excess
errors)
WARNING: program timed out.
...

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

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

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

--- Comment #1 from Jakub Jelinek  ---
Indeed:
.LLST40:
.quad   .LVL14  # Location list begin address (*.LLST40)
.quad   .LVL24  # Location list end address (*.LLST40)
.value  0x12# Location expression size
.byte   0x9e# DW_OP_implicit_value
.uleb128 0x10
.quad   0x
.quad   .LVL46  # Location list begin address (*.LLST40)
.quad   .LFE14  # Location list end address (*.LLST40)
We say that the implicit value is 16 byte but only supply 8-byte value.
Looking.

[Bug debug/99562] Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-12
 Status|UNCONFIRMED |NEW

[Bug debug/99562] New: Invalid debug info: objdump: Warning: Location list starting at offset 0x9c3 is not terminated.

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

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

Bug ID: 99562
   Summary: Invalid debug info: objdump: Warning: Location list
starting at offset 0x9c3 is not terminated.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, mark at gcc dot gnu.org
  Target Milestone: ---

The following produces an invalid debug info:

cat fsize.ii
template < class, class, class, class = void, class = void > struct expression;
template < class tag, class Arg1, class Arg2 >
struct expression< tag, Arg1, Arg2 > {};
template < class Backend > class number {
public:
  template < class tag, class Arg1, class Arg2, class Arg3, class Arg4 >
  void operator=(expression< tag, Arg1, Arg2, Arg3, Arg4 > e) {
do_assign(e, int());
  }
  template < class tag, class Arg1, class Arg2, class Arg3, class Arg4 >
  number(expression< tag, Arg1, Arg2, Arg3, Arg4 > e) {
*this = e;
  }
  template < class tag, class Arg1, class Arg2, class Arg3, class Arg4 >
  void do_assign(expression< tag, Arg1, Arg2, Arg3, Arg4 > e, int) {
Backend __trans_tmp_3 ;
eval_multiply(m_backend, __trans_tmp_3, canonical_value(e));
  }
  Backend m_backend;
  Backend canonical_value(number);
};
enum cpp_integer_type { signed_magnitude };
enum cpp_int_check_type { unchecked };
template < unsigned = 0, unsigned = 0, cpp_integer_type = signed_magnitude,
   cpp_int_check_type = unchecked, class = int >
struct Trans_NS_backends_cpp_int_backend;
struct cpp_int_base {
  bool m_alias;
  void allocator();
  cpp_int_base() {
{
  if (m_alias)
allocator();
}
  }
};
template < unsigned, unsigned, cpp_integer_type, cpp_int_check_type, class >
struct Trans_NS_backends_cpp_int_backend : cpp_int_base {};
template < unsigned MinBits1, unsigned MaxBits1, cpp_integer_type SignType1,
   cpp_int_check_type Checked1, class Allocator1, unsigned MinBits2,
   unsigned MaxBits2, cpp_integer_type SignType2,
   cpp_int_check_type Checked2, class Allocator2, unsigned MinBits3,
   unsigned MaxBits3, cpp_integer_type SignType3,
   cpp_int_check_type Checked3, class Allocator3 >
void
eval_multiply(Trans_NS_backends_cpp_int_backend< MinBits1, MaxBits1, SignType1,
 Checked1, Allocator1 >,
  Trans_NS_backends_cpp_int_backend< MinBits2, MaxBits2, SignType2,
 Checked2, Allocator2 >,
  Trans_NS_backends_cpp_int_backend< MinBits3, MaxBits3, SignType3,
 Checked3, Allocator3 >) {
  Trans_NS_backends_cpp_int_backend<> t0;
  __int128 limb_max = ~static_cast< unsigned long >(0);
}
class FSize {
  number< Trans_NS_backends_cpp_int_backend<> > _size;
  FSize();
};
expression< int, int, int > __trans_tmp_13;
FSize::FSize() : _size(__trans_tmp_13) {}

$ g++ -gdwarf-4 fsize.ii -c -g -O && objdump -g fsize.o >/dev/null
objdump: Warning: Location list starting at offset 0x9c3 is not terminated.
objdump: Warning: There is a hole [0x9f9 - 0xa0f] in .debug_loc section.
objdump: Warning: Location list starting at offset 0xa8b is not terminated.
objdump: Warning: There is a hole [0xac1 - 0xad7] in .debug_loc section.
objdump: Warning: Location list starting at offset 0xb53 is not terminated.
objdump: Warning: There is a hole [0xb89 - 0xb9f] in .debug_loc section.
objdump: Warning: Location list starting at offset 0xc1b is not terminated.
objdump: Warning: There is a hole [0xc51 - 0xc67] in .debug_loc section.

[Bug c++/96749] [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

--- Comment #4 from Iain Sandoe  ---
Created attachment 50377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50377=edit
Patch under test

thanks for the reports.

Even though user code cannot, the compiler can generate things like:

(make some temporary, use that temporary)

So a compound statement that builds a temporary that we then use in the second
part.

When this idiom was encountered, the transforms applied to split await
expressions out were producing something like

{
 build temporary
 temporary
 use the temporary
}

so the middle statement was harmless, but also has no effect (hence the
warning).

the patch under test accounts for this idiom.

[Bug fortran/99514] incorrect Error: Threadprivate at (1) isn't SAVEd ( implicit save via DATA initialization )

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:d0655763483008a421608d059cf26c93077621a9

commit r11-7649-gd0655763483008a421608d059cf26c93077621a9
Author: Tobias Burnus 
Date:   Fri Mar 12 16:34:10 2021 +0100

Fortran/OpenMP: Accept implicit-save DATA vars for threadprivate [PR99514]

gcc/fortran/ChangeLog:

PR fortran/99514
* resolve.c (resolve_symbol): Accept vars which are in DATA
and hence (either) implicit SAVE (or in common).

gcc/testsuite/ChangeLog:

PR fortran/99514
* gfortran.dg/gomp/threadprivate-1.f90: New test.

[Bug fortran/98858] OpenMP offload target data ICE at use_device_ptr

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:0b5437510c13dc0879349a4f259c800d2ce02eb2

commit r11-7648-g0b5437510c13dc0879349a4f259c800d2ce02eb2
Author: Tobias Burnus 
Date:   Fri Mar 12 16:33:02 2021 +0100

Fortran/OpenMP: Fix use_device_{ptr,addr} with assumed-size array [PR98858]

gcc/ChangeLog:

PR fortran/98858
* gimplify.c (omp_add_variable): Handle NULL_TREE as size
occuring for assumed-size arrays in use_device_{ptr,addr}.

libgomp/ChangeLog:

PR fortran/98858
* testsuite/libgomp.fortran/use_device_ptr-3.f90: New test.

[Bug c++/98704] coroutine_handle::done() == false after promise's unhandled_exception() has thrown

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Last reconfirmed||2021-03-12

--- Comment #2 from Iain Sandoe  ---
Created attachment 50376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50376=edit
Patch under test

Thanks for the report, and suggested fix.

This is the subject of CWG 2541 (about the wording, which is potentially
misleading).

Your possible fix doesn't do quite the right thing (because of said misleading
wording, I suspect) - it's necessary to ensure that the destroy() entry does
the correct thing when called.

===

When promise.unhandled_exception () is entered, the coroutine is
considered to be still running - returning from the method will
cause the final await expression to be evaluated.

If the method throws, that action is considered to make the
coroutine suspend (since, otherwise, it would be impossible to
reclaim its resources, since one cannot destroy a running coro).

The wording issue is to do with how to represent the place at
which the coroutine should be considered suspended.

For the implementation here, that place is immediately before the
promise life-time ends. A handler for the rethrown exception, can
thus call .destroy() which will run DTORs for the promise and
any parameter copies [as needed] then the coroutine frame will be
deallocated.

At present, we also set "done=true" in this case (for compatibility
with other current implementations). One might consider 'done()'
to be misleading in the case of an abnormal termination - that is
also part of the CGW 2451 discussion.

I modified the reproducer into a test case that also checks that
the resources are properly cleaned up on an exceptional termination.

[Bug fortran/88899] Derived type IO in conjunction with openmp fails with invalid memory read

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
   Keywords||wrong-code

--- Comment #4 from Tobias Burnus  ---
The problem seems to be due to finalization.

integer(kind=4) __final_mod_T (...)
{
  static struct t * ptr2;
...
}

Calling this function concurrently fails as ptr2 is "static".


The reason for 'static' is:

#0  gfc_finish_var_decl (decl=0x771ac090, sym=0x2914580) at
../../repos/gcc/gcc/fortran/trans-decl.c:727

722   if (!sym->attr.use_assoc
723   && ((sym->ts.type == BT_DERIVED
724&& sym->ts.u.derived->attr.has_dtio_procs)
725   || (sym->ts.type == BT_CLASS
726   && CLASS_DATA (sym)->ts.u.derived->attr.has_dtio_procs)))
727 TREE_STATIC (decl) = 1;


"ptr2" itself seems to come from class.c's finalizer_insert_packed_call.

 * * *

That change was part of the huge commit
https://gcc.gnu.org/g:e73d3ca6d1caf9c1187eeb1236dffd42f15ec043 for PR
fortran/48298 (DTIO).

The changelog states for this change:

* trans-decl.c (gfc_finish_var_decl): If a derived-type/class
object is associated with DTIO procedures, make it TREE_STATIC.

[Bug c++/98480] [coroutines] ICE on co_await in for-loop end condition.

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Last reconfirmed||2021-03-12
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Iain Sandoe  ---
Created attachment 50375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50375=edit
Patch under test

I seem to have had a brainstorm when applying the changes needed for do {}
while; and while () {} and omitted the ones for for.

[Bug sanitizer/96307] [10 Regression] ICE in sanopt on riscv64 since r11-2283-g2ca1b6d009b194286c3ec91f9c51cc6b0a475458

[schwab--- via Gcc-bugs]

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

--- Comment #10 from Andreas Schwab  ---
This disables the CC_HAS_KASAN_GENERIC config of the kernel, making KASAN
unavailable.

[Bug c++/99238] [modules] internal compiler error: segmentation fault

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-03-12

--- Comment #4 from Nathan Sidwell  ---
// pr99238.h
struct tm;

// pr99238_a.H
#include "pr99238.h"

// pr99238_b.H
#include "pr99238.h"
import "pr99238_a.H";
namespace std
{
  using ::tm;
}

zathras:116>./cc1plus -quiet -fmodule-header pr99238_a.H && ./cc1plus -quiet
-fmodule-header pr99238_b.H
pr99238_b.H: internal compiler error: Segmentation fault
0x16c420a crash_signal
../../../src/gcc/toplev.c:327
0xcb70b2 trees_out::get_tag(tree_node*)
../../../src/gcc/cp/module.cc:4779
0xcc01d2 trees_out::ref_node(tree_node*)
../../../src/gcc/cp/module.cc:7086
0xcc93ab trees_out::tree_node(tree_node*)
../../../src/gcc/cp/module.cc:8974
0xcde8cf depset::hash::find_dependencies(module_state*)
../../../src/gcc/cp/module.cc:13114
0xceb673 module_state::write(elf_out*, cpp_reader*)
../../../src/gcc/cp/module.cc:17618

[Bug rtl-optimization/99560] aarch64: ICE (segfault) in LRA with SVE intrinsics

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Component|target  |rtl-optimization
   Last reconfirmed||2021-03-12
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed. Not sure if it's a target bug. Looking through gdb the recog failure
is on insn:
(insn 207 206 208 4 (set (reg:DI 264)
(nil)) "ice.c":5:17 -1
 (expr_list:REG_EQUAL (const_poly_int:DI [76, 76])
(nil)))

That (nil) looks very bogus

[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Jakub Jelinek  ---
Fixed now.

[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:3bb345c9313ad8f6a6c24abd7d5eaa11413bbe22

commit r11-7646-g3bb345c9313ad8f6a6c24abd7d5eaa11413bbe22
Author: Jakub Jelinek 
Date:   Fri Mar 12 14:34:32 2021 +0100

i386: Hopefully last set of -mavx512vl -mno-avx512bw fixes [PR99321]

This is the final patch of the series started with
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566139.html
and continued with
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566356.html
This time, I went through all the remaining instructions marked
by gas as requiring both AVX512BW and AVX512VL and for each checked
tmp-mddump.md, figure out if it ever could be a problem (e.g. instructions
that require AVX512BW+AVX512VL, but didn't exist before AVX512F are usually
fine, the patterns have the right conditions, the bugs are typically on
pre-AVX512F patterns where we have just blindly added v while they actually
can't access those unless AVX512BW+AVX512VL), added test where possible
(the test doesn't cover MMX though)and fixed md bugs.

For mmx pextr[bw]/pinsr[bw] patterns it introduces per discussions
a new YW constraint that only requires AVX512BW and not AVX512VL, because
those instructions only require the former and not latter when using EVEX
encoding.

There are some other interesting details, e.g. most of the 8 interleave
patterns (vpunck[hl]{bw,wd}) had correctly
&&  && 
in the conditions because for masking it needs to be always EVEX encoded
and then it needs both VL+BW, but 2 of those 8 had just
&& 
and so again would run into the -mavx512vl -mno-avx512bw problems.

Another problem different from others was mmx eq/gt comparisons, that was
using Yv constraints, so would happily accept %xmm16+ registers for
-mavx512vl, but there actually are no such EVEX encoded instructions,
as AVX512 comparisons work with %k* registers instead.

The newly added testcase without the patch fails with:
/tmp/ccVROLo2.s: Assembler messages:
/tmp/ccVROLo2.s:9: Error: unsupported instruction `vpabsb'
/tmp/ccVROLo2.s:20: Error: unsupported instruction `vpabsb'
/tmp/ccVROLo2.s:31: Error: unsupported instruction `vpabsw'
/tmp/ccVROLo2.s:42: Error: unsupported instruction `vpabsw'
/tmp/ccVROLo2.s:53: Error: unsupported instruction `vpaddsb'
/tmp/ccVROLo2.s:64: Error: unsupported instruction `vpaddsb'
/tmp/ccVROLo2.s:75: Error: unsupported instruction `vpaddsw'
/tmp/ccVROLo2.s:86: Error: unsupported instruction `vpaddsw'
/tmp/ccVROLo2.s:97: Error: unsupported instruction `vpsubsb'
/tmp/ccVROLo2.s:108: Error: unsupported instruction `vpsubsb'
/tmp/ccVROLo2.s:119: Error: unsupported instruction `vpsubsw'
/tmp/ccVROLo2.s:130: Error: unsupported instruction `vpsubsw'
/tmp/ccVROLo2.s:141: Error: unsupported instruction `vpaddusb'
/tmp/ccVROLo2.s:152: Error: unsupported instruction `vpaddusb'
/tmp/ccVROLo2.s:163: Error: unsupported instruction `vpaddusw'
/tmp/ccVROLo2.s:174: Error: unsupported instruction `vpaddusw'
/tmp/ccVROLo2.s:185: Error: unsupported instruction `vpsubusb'
/tmp/ccVROLo2.s:196: Error: unsupported instruction `vpsubusb'
/tmp/ccVROLo2.s:207: Error: unsupported instruction `vpsubusw'
/tmp/ccVROLo2.s:218: Error: unsupported instruction `vpsubusw'
/tmp/ccVROLo2.s:258: Error: unsupported instruction `vpaddusw'
/tmp/ccVROLo2.s:269: Error: unsupported instruction `vpavgb'
/tmp/ccVROLo2.s:280: Error: unsupported instruction `vpavgb'
/tmp/ccVROLo2.s:291: Error: unsupported instruction `vpavgw'
/tmp/ccVROLo2.s:302: Error: unsupported instruction `vpavgw'
/tmp/ccVROLo2.s:475: Error: unsupported instruction `vpmovsxbw'
/tmp/ccVROLo2.s:486: Error: unsupported instruction `vpmovsxbw'
/tmp/ccVROLo2.s:497: Error: unsupported instruction `vpmovzxbw'
/tmp/ccVROLo2.s:508: Error: unsupported instruction `vpmovzxbw'
/tmp/ccVROLo2.s:548: Error: unsupported instruction `vpmulhuw'
/tmp/ccVROLo2.s:559: Error: unsupported instruction `vpmulhuw'
/tmp/ccVROLo2.s:570: Error: unsupported instruction `vpmulhw'
/tmp/ccVROLo2.s:581: Error: unsupported instruction `vpmulhw'
/tmp/ccVROLo2.s:592: Error: unsupported instruction `vpsadbw'
/tmp/ccVROLo2.s:603: Error: unsupported instruction `vpsadbw'
/tmp/ccVROLo2.s:643: Error: unsupported instruction `vpshufhw'
/tmp/ccVROLo2.s:654: Error: unsupported instruction `vpshufhw'
/tmp/ccVROLo2.s:665: Error: unsupported instruction `vpshuflw'
/tmp/ccVROLo2.s:676: Error: unsupported instruction `vpshuflw'
/tmp/ccVROLo2.s:687: Error: unsupported instruction `vpslldq'
/tmp/ccVROLo2.s:698: Error: unsupported instruction `vpslldq'
/tmp/ccVROLo2.s:709: Error: unsupported instruction `vpsrldq'
/tmp/ccVROLo2.s:720: Error: 

[Bug fortran/99561] New: gfortran reports an error for a truncation that is permitted by the standard

[michal.paszta at mobica dot com via Gcc-bugs]

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

Bug ID: 99561
   Summary: gfortran reports an error for a truncation that is
permitted by the standard
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michal.paszta at mobica dot com
  Target Milestone: ---

In this line of code:

INTEGER(KIND=1) :: var8 = 257_2

we try to cast an integer of kind 2 (16 bits) onto an integer of kind 1 (8
bits, value up to 256). This will result in a truncation of the value and is
allowed by the Fortran 2018 Standard, see Table 10.9, Fortran 2018 Standard.

$ ~/gcc/trunk/bin/gfortran issue.f90 
issue.f90:17:27:

   17 |   INTEGER(KIND=1) :: var8 = 257_2
  |   1
Error: Arithmetic overflow converting INTEGER(2) to INTEGER(1) at (1). This
check can be disabled with the option ‘-fno-range-check’

We believe the operation should be allowed. It could warn the programmer about
the truncation, but should not prevent a successful compilation.

The obvious workaround is to follow the suggestion for the error message and
add '-fno-range-check' - in that case I got no warning or error.

The report originates from a flang github issue:
https://github.com/flang-compiler/flang/issues/992 and was pointed out by Bryan
Chan.

I tried gfortran 7.5.0 and 10.2.0 and both acted the same.

[Bug lto/99559] LTO with -Os -ffreestanding -nodefaultlibs may generate call to memcpy, but fail linking even though memcpy is defined

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Yeah, we do remove unused (as in unused from the source) memcpy implementations
early but then introduce uses ourselves.

I suppose we should avoid doing that with -ffreestanding, thus basically add
the used attribute on a select number of definitions automatically with this
option.

I wonder for example whether a static definition of memcpy would need to be
preserved since I think this isn't really special to LTO.

Joseph?  Honza?

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
Bug 99227 depends on bug 99240, which changed state.

Bug 99240 Summary: [modules] ICE in get_merge_kind, at cp/module.cc:10169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99240

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/99240] [modules] ICE in get_merge_kind, at cp/module.cc:10169

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Nathan Sidwell  ---
thanks, closing as a duplicate.

[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

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

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

--- Comment #40 from Martin Jambor  ---
I have adjusted the patches a little and re-posted them as
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566681.html and
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566682.html .

[Bug c++/99240] [modules] ICE in get_merge_kind, at cp/module.cc:10169

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

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

--- Comment #2 from Alexander Lelyakin  ---
Not seen anymore  in version 20210311.

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||here.is.a.gcc.bug at gmail dot 
com

--- Comment #8 from Martin Liška  ---
*** Bug 99549 has been marked as a duplicate of this bug. ***

[Bug fortran/99549] Segfault when scalar argument of elemental function is both derived type with allocatable component and a function result

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Fixed with r11-3430-ge86a02f87d8a1148.
Dup.

*** This bug has been marked as a duplicate of bug 96495 ***

[Bug target/99542] [9/10/11 Regression] ICE in exact_div, at poly-int.h:2219

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50374=edit
gcc11-pr99542.patch

Untested fix.  There is another difference from i386, for !TREE_PUBLIC
(node->decl) the i386 version never returns > 1, but instead just provides the
version which is the best for the current TU.  Wouldn't it make sense on
aarch64 too?  Or does it hope that the unused entrypoints will be optimized
away?
I'm not sure it happens, because simd cloning is fairly late IPA pass.

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 12 Mar 2021, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 50373
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50373=edit
> gcc11-pr99544.patch
> 
> Patch that implements the *.pd part but not the expansion part (perhaps that
> can be done in stage1).

LGTM

[Bug target/99542] [9/10/11 Regression] ICE in exact_div, at poly-int.h:2219

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

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

--- Comment #2 from Jakub Jelinek  ---
(In reply to Arseny Solokha from comment #0)
> (Is it the exact reason the testcase has /* { dg-options "-O0 -fno-openmp
> -fno-openmp-simd" } */?)

No, the reason for that is that it is the auxiliary source of another test that
already compiles it with -fopenmp-simd -O2.

[Bug target/99542] [9/10/11 Regression] ICE in exact_div, at poly-int.h:2219

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is aarch64 backend bug in aarch64_simd_clone_compute_vecsize_and_simdlen.
If you look at the i386 counterpart, for argument checking it does:
  tree type_arg_types = TYPE_ARG_TYPES (TREE_TYPE (node->decl));
  bool decl_arg_p = (node->definition || type_arg_types == NULL_TREE);

  for (t = (decl_arg_p ? DECL_ARGUMENTS (node->decl) : type_arg_types), i = 0;
   t && t != void_list_node; t = TREE_CHAIN (t), i++)
{
  tree arg_type = decl_arg_p ? TREE_TYPE (t) : TREE_VALUE (t);
but aarch64 doesn't bother and instead it does just:
  for (t = DECL_ARGUMENTS (node->decl); t; t = DECL_CHAIN (t))
{
  arg_type = TREE_TYPE (t);
The problem with that is that it doesn't check the arguments at all for
function declarations that aren't definitions.

[Bug target/99560] aarch64: ICE (segfault) in LRA with SVE intrinsics

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

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

Alex Coplan  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
   Keywords||ice-on-valid-code
  Known to fail||10.2.1, 11.0
 Target||aarch64

--- Comment #1 from Alex Coplan  ---
Also ICEs on the 10 branch.

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 50373
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50373=edit
gcc11-pr99544.patch

Patch that implements the *.pd part but not the expansion part (perhaps that
can be done in stage1).

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> I think this is another case that the PR98287 proposed patch would fix,
> again after vec lowering some pass (seems vrp2 in this case), this time it
> is the
> /* Canonicalize X + (X << C) into X * (1 + (1 << C)) and
>(X << C1) + (X << C2) into X * ((1 << C1) + (1 << C2)).  */
> match.pd rule, where the target apparently supports V2DImode left shift by
> scalar constant and addition, but doesn't support V2DImode multiplication.
> Maybe in this particular case it would be worth guarding the pattern on
> existing optab for vector multiplication or disable it for vectors
> altogether (apparently it was myself who has added that), because at least
> if the target doesn't have particular vector multiplications, I'd say doing
> the additions and shifts must be better than scalarizing it.  If
> multiplications are supported, I guess best would be to let the expansion
> decide what is better, it has code to turn scalar multiplications by
> constant into additions and shifts, so perhaps could use that also for
> vector by uniform constants?

I think in general we should be careful with patterns for vector operations
since vector expressions tend to be "optimized" (by the user or by the
compiler).

In particular even before lvec in case the source expression is supported
by the target it's not good to turn it into sth unsupported.

Basic +- arithmetic and bitwise ops are usually fine since target support is
wide-spread but I'd argue against enabling more fancy cases (integer
mult/division, shifts) without vector support checks.

What is clear is that there's no convenient helper like
direct_internal_fn_supported_p for tree codes, we should aim at providing that
(see vectorizable_shift on how awkward this can be).

So in this particular case I suggest to disable the patter for vectors
(with a comment) and work on a way to guard it appropriately without
too much boiler-plate.

[Bug target/99560] New: aarch64: ICE (segfault) in LRA with SVE intrinsics

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

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

Bug ID: 99560
   Summary: aarch64: ICE (segfault) in LRA with SVE intrinsics
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following testcase on AArch64:

#include 
int foo(int x, int y);
void bar(int f, int g, int h, int i, int *j, int k[3][8][7]) {
  while (1) {
int p = i ? foo(g, f) : 0;
while (p) {
  j[p] = svaddv(svptrue_b8(),
  svadd_z(
svmov_z(svnot_z(svptrue_b8(),
svptrue_pat_b16(SV_VL5)),
svptrue_pat_b8(SV_VL7)),
svdup_u8(0),
8));
   p += svaddv(
   svptrue_b8(),
   svadd_z(
   svptrue_b8(),
   svadd_z(svptrue_b8(), svdup_s64(j[f]), h - 4),
   svadd_z(
   svptrue_b8(),
   svadd_z(
   svptrue_b8(),
   svadd_z(svptrue_b8(),
   svadd_z(svptrue_b8(), svdup_s64(0), 0),
   svadd_z(svptrue_pat_b8(SV_VL16),
   svdup_s64(k[f][g][p]),
   svadd_z(svptrue_pat_b16(SV_VL5),
 svdup_s64(0), 0))
   ),
   f),
   0)));
}
  }
}

we ICE in LRA with:

$ aarch64-linux-gnu-gcc -c test.c -march=armv8.2-a+sve -O -ftrapv
during RTL pass: reload
test.c: In function ‘bar’:
test.c:34:1: internal compiler error: Segmentation fault
   34 | }
  | ^
0xdf33db crash_signal
/home/alecop01/toolchain/src/gcc/gcc/toplev.c:327
0x198d63f recog_485
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.md:7305
0x198d63f recog(rtx_def*, rtx_insn*, int*)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/iterators.md:441
0xc0d47a recog_memoized
/home/alecop01/toolchain/src/gcc/gcc/recog.h:273
0xc0d47a lra_set_insn_recog_data(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:964
0xc0e987 lra_get_insn_recog_data
/home/alecop01/toolchain/src/gcc/gcc/lra-int.h:487
0xc0e987 lra_update_insn_regno_info(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:1625
0xc0ed4f lra_push_insn_1
/home/alecop01/toolchain/src/gcc/gcc/lra.c:1780
0xc0ed4f lra_push_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:1788
0xc0ef67 push_insns
/home/alecop01/toolchain/src/gcc/gcc/lra.c:1831
0xc0f3df lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:1871
0xc27f21 curr_insn_transform
/home/alecop01/toolchain/src/gcc/gcc/lra-constraints.c:4664
0xc297a0 lra_constraints(bool)
/home/alecop01/toolchain/src/gcc/gcc/lra-constraints.c:5158
0xc10443 lra(_IO_FILE*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2336
0xbc275a do_reload
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5834
0xbc275a execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:6020
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-12
 Status|UNCONFIRMED |ASSIGNED
  Component|target  |tree-optimization

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

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

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

--- Comment #7 from Dominique d'Humieres  ---
The patch works for me. Thanks!

[Bug target/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think this is another case that the PR98287 proposed patch would fix, again
after vec lowering some pass (seems vrp2 in this case), this time it is the
/* Canonicalize X + (X << C) into X * (1 + (1 << C)) and
   (X << C1) + (X << C2) into X * ((1 << C1) + (1 << C2)).  */
match.pd rule, where the target apparently supports V2DImode left shift by
scalar constant and addition, but doesn't support V2DImode multiplication.
Maybe in this particular case it would be worth guarding the pattern on
existing optab for vector multiplication or disable it for vectors altogether
(apparently it was myself who has added that), because at least if the target
doesn't have particular vector multiplications, I'd say doing the additions and
shifts must be better than scalarizing it.  If multiplications are supported, I
guess best would be to let the expansion decide what is better, it has code to
turn scalar multiplications by constant into additions and shifts, so perhaps
could use that also for vector by uniform constants?

[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 #2 from Alexander Lelyakin  ---
There is a shorter sequence:

g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map
g++ -std=c++20 -fmodules-ts -x c++-system-header deque
g++ -std=c++20 -fmodules-ts -x c++-system-header condition_variable
g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf
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 20210311 (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 lto/99559] New: LTO with -Os -ffreestanding -nodefaultlibs may generate call to memcpy, but fail linking even though memcpy is defined

[kabel at blackhole dot sk via Gcc-bugs]

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

Bug ID: 99559
   Summary: LTO with -Os -ffreestanding -nodefaultlibs may
generate call to memcpy, but fail linking even though
memcpy is defined
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kabel at blackhole dot sk
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 50372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50372=edit
test.c

When compiling for target where the assignment operator

  *dst = *src;

will generate a call to memcpy (for example aarch64), and when also using
compile flags

  -ffreestanding -Os -flto

and link flags

  -nodefaultlibs -nostartfiles

the linking will fail with

  undefined reference to `memcpy'

even if memcpy is defined in the source.

The memcpy is optimized away, even though it is used by the = operator. It
needs to be declared with __attribute__((used)) to not be optimized away.

What is interesting is that if the memcpy function is used explicitly, the
compilation may still fail with -Os, because the code will be inlined.

If memcpy is used explicitly multiple times, it may be generated with symbol
name
  memcpy.constprop.0.isra.0
or
  memcpy.isra.0
depending on whether the arguments passed are the same or different.

But the linking fill still fail, because the assignment operator will generate
a call to memcpy, and this symbol is not defined, only memcpy.isra.0 or
memcpy.constprop.0.isra.0 is.

I discovered this recently while trying to make U-Boot compile with LTO. We
have solved it by declaring "memcmp", "memset", "memcpy" and "memmove" with
attribute used, since according to GCC man page, calls to this functions may
still be done when -nodefaultlibs is used.

[Bug c++/99558] wrong argument types reported for "no matching function" error message if ctor argument is a variable

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
(In reply to J. Hart from comment #0)
> $ g++ -c -o utl2.o utl2.cc
> utl2.cc: In function "int main()":
> utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int&, int)"
> 
> correct argument type: constant used as argument, first argument is
> correctly shown as "int"

GCC is correct. When you use a variable you are passing an lvalue of type int,
which is what int& means. When you pass a constant it is an rvalue, i.e. int.

> 
> $ g++ -D DBG1 -c -o utl2.o utl2.cc
> utl2.cc: In function "int main()":
> utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int, int)"

Because you're passing two rvalues.

[Bug debug/99490] [11 Regression] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Summary|-gdwarf-5 -gsplit-dwarf |[11 Regression] -gdwarf-5
   |puts .debug_rnglists to |-gsplit-dwarf puts
   |main file, not .dwo file|.debug_rnglists to main
   ||file, not .dwo file

--- Comment #18 from Jakub Jelinek  ---
Marking this as a regression because we've switched the default from -gdwarf-4
to -gdwarf-5, so code compiled with -g -gsplit-dwarf used to produce something
valid that consumers could handle and now it doesn't, even when they have
DWARF5 support.

[Bug c++/99507] Can't return static address from immediate function

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

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

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.  Should be backported to 10 later.

[Bug c++/99507] Can't return static address from immediate function

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:425afe1f0c907e6469cef1672160c9c95177e71a

commit r11-7645-g425afe1f0c907e6469cef1672160c9c95177e71a
Author: Jakub Jelinek 
Date:   Fri Mar 12 10:11:24 2021 +0100

c++: Fix up calls to immediate functions returning reference [PR99507]

build_cxx_call calls convert_from_reference at the end, so if an immediate
function returns a reference, we were constant evaluating not just that
call, but that call wrapped in an INDIRECT_REF.  That unfortunately means
it can constant evaluate to something non-addressable, so if code later
needs to take its address it will fail.

The following patch fixes that by undoing the convert_from_reference
wrapping for the cxx_constant_value evaluation and readdding it ad the end.

2021-03-12  Jakub Jelinek  

PR c++/99507
* call.c (build_over_call): For immediate evaluation of functions
that return references, undo convert_from_reference effects before
calling cxx_constant_value and call convert_from_reference
afterwards.

* g++.dg/cpp2a/consteval19.C: New test.

[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file

[jan.kratochvil at redhat dot com via Gcc-bugs]

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

--- Comment #17 from Jan Kratochvil  ---
Yes, the testcase TestTypeCompletion.py category 'dwo' is now fixed with the
patch from Comment 15.

[Bug c++/99558] New: wrong argument types reported for "no matching function" error message if ctor argument is a variable

[jfhart085 at gmail dot com via Gcc-bugs]

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

Bug ID: 99558
   Summary: wrong argument types reported for "no matching
function" error message if ctor argument is a variable
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jfhart085 at gmail dot com
  Target Milestone: ---

Created attachment 50371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50371=edit
utl2.cc - demonstrates using deliberate error message from compile

Wrong argument types are reported for "no matching function" error message for
a ctor if a ctor argument is a variable. The argument is reported as being a
reference when it is not.  An error message is deliberately generated to
demonstrate the problem as follows:

wrong argument type: variable used as argument, first argument is shown as
   "int &" but is actually "int" :

$ g++ -c -o utl2.o utl2.cc
utl2.cc: In function "int main()":
utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int&, int)"

correct argument type: constant used as argument, first argument is correctly
shown as "int"

$ g++ -D DBG1 -c -o utl2.o utl2.cc
utl2.cc: In function "int main()":
utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int, int)"

from gcc -v :
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/jhart/temp1/gcc-10.2.0/configure --prefix=/usr
--disable-multilib --with-system-zlib --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)