[Bug c++/99482] [modules] ICE tree check: expected tree_vec, have addr_expr in lookup_template_class_1, at cp/pt.c:9803

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

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

--- Comment #1 from Alexander Lelyakin  ---
Disappeared in version 20210310

[Bug c++/99483] [modules] ICE tree check: expected tree_vec, have bind_expr in lookup_template_class_1, at cp/pt.c:9803

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

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

--- Comment #1 from Alexander Lelyakin  ---
Disappeared in version 20210310.

[Bug ipa/99517] __builtin_convertvector with casts

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> --- gcc/ipa-icf-gimple.c.jj   2021-01-04 10:25:38.752234741 +0100
> +++ gcc/ipa-icf-gimple.c  2021-03-10 15:02:06.287502784 +0100
> @@ -667,7 +667,7 @@ func_checker::compare_gimple_call (gcall
>tree fntype1 = gimple_call_fntype (s1);
>tree fntype2 = gimple_call_fntype (s2);
>  
> -  /* For direct calls we verify that types are comopatible so if we matced
> +  /* For direct calls we verify that types are compatible so if we matched
>   callees, callers must match, too.  For indirect calls however verify
>   function type.  */
>if (!gimple_call_fndecl (s1))
> @@ -703,6 +703,14 @@ func_checker::compare_gimple_call (gcall
>t1 = gimple_get_lhs (s1);
>t2 = gimple_get_lhs (s2);
>  
> +  /* For internal calls, lhs types need to be verified, as neither fntype
> nor
> + callee comparisions can catch that.  */
> +  if (gimple_call_internal_p (s1)
> +  && t1
> +  && t2
> +  && !compatible_types_p (TREE_TYPE (t1), TREE_TYPE (t2)))
> +return return_false_with_msg ("GIMPLE internal call LHS type mismatch");
> +
>return compare_operand (t1, t2, get_operand_access_type (&map, t1));
>  }
>  
> 
> fixes this for me, working on the testcase for testsuite now.
> 
> Anyway, I'm a little bit worried that gimple_call_fntype isn't compared for
> direct calls, gimple_call_fntype doesn't have to match the function type of
> gimple_call_fndecl.

The comment says that we match that the fndecls definitions are equal,
one could argue that it's undefined behavior if the same definition is
invoked via two different gimple_call_fntype signatures and thus it's
OK to just go ahead (I think actual arguments are also compared so it
would collide there, too).

> And also surprised that compare_ssa_name e.g. doesn't compare
> SSA_NAME_OCCURS_IN_ABNORMAL_PHI or SSA_NAME_PTR_INFO or SSA_NAME_RANGE_INFO.
> Maybe for the latter two we are fine if we only optimize away
> __builtin_unreachable calls after IPA, but if we do it before, e.g. some
> function could have if (cond) __builtin_unreachable (); assertions that EVRP
> would stick into SSA_NAME_RANGE_INFO and another function be the same except
> without those assertions.  If ICF merges the latter into the former and
> calls the latter with arguments violating the assertions of the former, it
> might be miscompiled.

Hmm, yeah.  I guess one could try to carefully craft such a testcase.
For example non-null ranges can also be created from dead loads like

foo (int *p)
{
  *p;
  if (p != 0)
...

when you make sure to not run DCE before EVRP.  Not sure if that's enough
of a building-block to create a testcase.

[Bug c++/99484] [modules] ICE same canonical type node for different types ‘void’ and ‘std::__void_t<_Op<_Args ...> >’

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

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

--- Comment #1 from Alexander Lelyakin  ---
In current version 20210310 I have seen another, but very similar error
message:

g++ -std=c++20 -fmodules-ts -x c++-system-header memory_resource
g++ -std=c++20 -fmodules-ts -x c++-system-header thread
g++ -std=c++20 -fmodules-ts -x c++-system-header version
g++ -std=c++20 -fmodules-ts -x c++-system-header array
g++ -std=c++20 -fmodules-ts -x c++-system-header latch
g++ -std=c++20 -fmodules-ts -x c++-system-header syncstream
g++ -std=c++20 -fmodules-ts -x c++-system-header cstddef
g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
g++ -std=c++20 -fmodules-ts -x c++-system-header list
g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map

In module /usr/local/include/c++/11.0.1/type_traits, imported at
/usr/local/include/c++/11.0.1/unordered_map:38:
/usr/local/include/c++/11.0.1/type_traits: In instantiation of ‘struct
std::is_copy_assignable’:
/usr/local/include/c++/11.0.1/type_traits:138:12:   required from ‘struct
std::__and_, std::is_copy_assignable >’
/usr/local/include/c++/11.0.1/bits/stl_pair.h:390:7:   required from ‘struct
std::pair’
/usr/local/include/c++/11.0.1/bits/hashtable_policy.h:577:5:   required from
here
/usr/local/include/c++/11.0.1/type_traits:1057:12: internal compiler error:
same canonical type node for different types ‘void’ and ‘std::__void_t<_Tp&>’
 1057 | struct is_copy_assignable
  |^~
0xb7f8dd comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1554
0xae4bff template_args_equal(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/pt.c:9207
0xae4758 template_args_equal(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/pt.c:9170
0xae4758 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc/gcc/cp/pt.c:9254
0xae4758 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc/gcc/cp/pt.c:9234
0xaee073 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc/gcc/cp/pt.c:1725
0xb3400e hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:981
0xaf101b add_mergeable_specialization(bool, spec_entry*, tree_node*, unsigned
int)
../../gcc/gcc/cp/pt.c:30018
0xa6ef5f trees_in::decl_value()
../../gcc/gcc/cp/module.cc:8068
0xa67017 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9174
0xa6d66b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14858
0xa6db6d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18129
0xa6dc2f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18783
0xa70e67 lazy_load_pendings(tree_node*)
../../gcc/gcc/cp/module.cc:18876
0xb2045f lookup_template_class_1
../../gcc/gcc/cp/pt.c:9799
0xb227f6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:10237
0xb227f6 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:13572
0xaf87ad tsubst_qualified_id
../../gcc/gcc/cp/pt.c:16365
0xafab79 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19865
0xb04508 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:19115
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210310 (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 tree-optimization/99520] Failure to detect bswap pattern

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-11
  Component|middle-end  |tree-optimization
 Status|UNCONFIRMED |NEW

--- Comment #7 from Richard Biener  ---
I think there was a recent duplicate.

[Bug c++/99248] [modules] ICE expected binding_vector, have overload in lookup_elaborated_type_1, at cp/name-lookup.c:8013

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

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

--- Comment #2 from Alexander Lelyakin  ---
There is much shorter sequence in last version 20210310:

g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf
g++ -std=c++20 -fmodules-ts -x c++-system-header istream

In file included from /usr/local/include/c++/11.0.1/bits/locale_facets.h:2682,
 from /usr/local/include/c++/11.0.1/bits/basic_ios.h:37,
 from /usr/local/include/c++/11.0.1/ios:44,
 from /usr/local/include/c++/11.0.1/istream:38:
/usr/local/include/c++/11.0.1/bits/locale_facets.tcc:42:12: internal compiler
error: tree check: expected binding_vector, have overload in
lookup_elaborated_type_1, at cp/name-lookup.c:7943
   42 | struct __use_cache
  |^~~
0x875bfa tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9816
0x6eb804 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3353
0x6eb804 lookup_elaborated_type_1
../../gcc/gcc/cp/name-lookup.c:7943
0x6eb804 lookup_elaborated_type(tree_node*, TAG_how)
../../gcc/gcc/cp/name-lookup.c:8034
0x9c5385 lookup_and_check_tag
../../gcc/gcc/cp/decl.c:15080
0x9c5741 xref_tag_1
../../gcc/gcc/cp/decl.c:15194
0x9c5c90 xref_tag(tag_types, tree_node*, TAG_how, bool)
../../gcc/gcc/cp/decl.c:15327
0xaa75c2 cp_parser_class_head
../../gcc/gcc/cp/parser.c:25586
0xaa75c2 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24803
0xaa7f23 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:25182
0xaa7f23 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18429
0xaa8eb9 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:15051
0xad3a76 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:30412
0xad3df6 cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:30075
0xad45a0 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:30341
0xad6cc9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14057
0xad6299 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14155
0xad6299 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13943
0xad6732 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:20443
0xad6732 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:20421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210310 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus

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

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

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

g++ -std=c++20 -fmodules-ts -x c++-system-header condition_variable
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 20210310 (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 tree-optimization/99523] Declarations for variable names missing in GIMPLE dump

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

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

--- Comment #1 from Richard Biener  ---
They are there, it's the

  sizetype D.3596;
  sizetype D.3597;
  sizetype D.3598;
  void * D.3599;
  int D.3601;

etc. variables, but they are DECL_IGNORED (they have no "name") and so
dumping which does

case SSA_NAME:
  if (SSA_NAME_IDENTIFIER (node))
{
  if ((flags & TDF_NOUID)
  && SSA_NAME_VAR (node)
  && DECL_NAMELESS (SSA_NAME_VAR (node)))
dump_fancy_name (pp, SSA_NAME_IDENTIFIER (node));
  else if (! (flags & TDF_GIMPLE)
   || SSA_NAME_VAR (node))
dump_generic_node (pp, SSA_NAME_IDENTIFIER (node),
   spc, flags, false);
}
  pp_underscore (pp);
  pp_decimal_int (pp, SSA_NAME_VERSION (node));
  if (SSA_NAME_IS_DEFAULT_DEF (node))
pp_string (pp, "(D)");
  if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (node))
pp_string (pp, "(ab)");
  break;

sees a NULL SSA_NAME_IDENTIFIER.

I suppose

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index d04ce212561..4e40b7c0155 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -8155,7 +8155,7 @@ dump_function_to_file (tree fndecl, FILE *file,
dump_flags_t flags)
   if (gimple_in_ssa_p (cfun))
FOR_EACH_SSA_NAME (ix, name, cfun)
  {
-   if (!SSA_NAME_VAR (name))
+   if (!SSA_NAME_IDENTIFIER (name))
  {
fprintf (file, "  ");
print_generic_expr (file, TREE_TYPE (name), flags);

would display them similar to anonymous SSA names (but then the dumped
decls above are redundant and useless).

The testcase shows the same on x86_64 btw.

[Bug target/96879] [11 Regresssion] ICE in native_encode_rtx, at simplify-rtx.c:6482

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

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

--- Comment #7 from Jakub Jelinek  ---
Stage 3 is over.  Any progress on this?

[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings

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

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

--- Comment #2 from Richard Biener  ---
Or make an internal (static) newunit_free_unlocked and make the exported
newunit_free take the lock.

[Bug target/99531] Performance regression since gcc 9 (argument passing / register allocation)

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-11
 Status|UNCONFIRMED |NEW
  Known to work||8.4.0
  Known to fail||11.0, 9.3.1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/99531] [9/10/11 Regression] Performance regression since gcc 9 (argument passing / register allocation)

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Performance regression  |[9/10/11 Regression]
   |since gcc 9 (argument   |Performance regression
   |passing / register  |since gcc 9 (argument
   |allocation) |passing / register
   ||allocation)
   Target Milestone|--- |9.4

[Bug c++/99541] ICE when reading a module

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
   Last reconfirmed||2021-03-11
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||nathan at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Please provide a testcase.

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Richard Biener  ---
Please try updating to a more recent snapshot.

[Bug target/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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |11.0
Summary|[11.0 regression] ICE in|[11 Regression] ICE in
   |gfc_trans_assignment|gfc_trans_assignment
   Keywords||ice-on-valid-code

[Bug c++/99546] New: Weird return value of C++20 requires expression

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99546
   Summary: Weird return value of C++20 requires expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

gcc-trunk accepts following code:

int main() {
  constexpr auto b = requires { []{}; };
  static_assert(b);
  static_assert(!b);
}

(godbolt: https://godbolt.org/z/4K5vq8)

[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #3 from martin  ---
Thanks for looking at the report and providing a patch to test.
For completeness sake, here is the simple test code, which does not fail, but
which shows the data race in helgrind (compile with -fopenmp -g2):

program omp_write_str

use OMP_LIB
implicit none

integer :: i
character(len=16) :: out

!$omp parallel do schedule(static,10) default(shared) private(i, out)
do i=1,10
   write(out,'(i8)') omp_get_thread_num()
end do
!$omp end parallel do

end program omp_write_str


The provided patch indeed removes the data races (there are still data races at
startup and exit, which are false positives, as those occur in a single
threaded region.)

However, with the my real code, it does not help. I will further check with
helgrind (the amount of false positives is staggering, though...)

[Bug c++/99546] Weird return value of C++20 requires expression

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
You can see more weird cases in this: 
https://stackoverflow.com/questions/66578966/weird-return-value-of-c20-requires-expression.

[Bug target/99540] [10/11 Regression] ICE: Segmentation fault in aarch64_add_offset

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.3
  Known to work||9.3.1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-11
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
  Known to fail||10.2.1, 11.0
Summary|ICE: Segmentation fault in  |[10/11 Regression] ICE:
   |aarch64_add_offset  |Segmentation fault in
   ||aarch64_add_offset

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. ICEs with -march=armv8.2-a+sve -O3 -ffloat-store -ftrapv

[Bug testsuite/99371] add_options_for_sqrt_insn is missing options that enable powerpc's fsqrt

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

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

Alexandre Oliva  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2021-March/5 |il/gcc-patches/2021-Februar
   |65995.html  |y/565939.html

--- Comment #1 from Alexandre Oliva  ---
Uhh, sorry, looks like I put the wrong URL in the initial report.

[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #4 from martin  ---
Ok, here is another suspicious data race in unit.c (backtrace from helgrind):

==7831== Possible data race during read of size 4 at 0x5DE4620 by thread #296
==7831== Locks held: 1, at address 0x2EE5D00
==7831==at 0x10067CB: get_gfc_unit (unit.c:336)
==7831==by 0x10071DB: _gfortrani_get_unit (unit.c:556)
==7831==by 0x10050DC: data_transfer_init (transfer.c:2851)
...
==7831== 
==7831== This conflicts with a previous write of size 4 by thread #3
==7831== Locks held: 1, at address 0x5DE4700
==7831==at 0x10069F4: _gfortrani_set_internal_unit (unit.c:459)
==7831==by 0x10071EC: _gfortrani_get_unit (unit.c:557)
==7831==by 0x10050DC: data_transfer_init (transfer.c:2851)

There seems to be a conflicting access to "unit_cache[c]->unit_number",
set_internal_unit does not hold UNIT_LOCK.

I cannot observe this in the simple testcase, but in the real code at the right
place where I suspect the write-caused memory corruption.

(Just in case line numbers have changed:
unit.c:336: if (unit_cache[c] != NULL && unit_cache[c]->unit_number == n)
unit.c:556:  iunit->unit_number = dtp->common.unit;
)

[Bug tree-optimization/96135] [9/10/11 regression] bswap not detected by bswap pass, unexpected results between optimization levels

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

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

--- Comment #2 from Richard Biener  ---
Created attachment 50361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50361&action=edit
WIP

On current trunk at -O3 f() again works via store-merging / vectorizing:

-  _21 = {_3, _4, _5, _6, _7, _8, _9, _10};
+  bswapsrc_22 = (long unsigned int) i_2(D);
+  bswapdst_19 = __builtin_bswap64 (bswapsrc_22);
+  _21 = VIEW_CONVERT_EXPR(bswapdst_19);

but g() does not, because init_symbolic_number doesn't like non-integral types.
Fixing that generates

_Z1gd:
.LFB2:
.cfi_startproc
movq%xmm0, %rax
bswap   %rax
ret

but with -m32 it has the issue that we bswap only the lower part since
vectorizing produced two vector CTORs.  So we'd need to use a BIT_FIELD_REF
to extract the integer representation.

WIP patch attached.

[Bug tree-optimization/99523] Declarations for variable names missing in GIMPLE dump

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Going to test this.

[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings

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

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

--- Comment #5 from Tobias Burnus  ---
(In reply to martin from comment #4)
> Ok, here is another suspicious data race in unit.c (backtrace from helgrind):

It looks as if - for the libgfortran internal use - it first gets the unit
based on that number – and then sets it again. Namely, the call is:

  unit = get_gfc_unit (dtp->common.unit, do_create);
  set_internal_unit (dtp, unit, kind);

Just to make sure, I add an assert - but I think the line can also be removed
for good.

--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -459 +459 @@ set_internal_unit (st_parameter_dt *dtp, gfc_unit *iunit, int
kind)
-  iunit->unit_number = dtp->common.unit;
+  assert (iunit->unit_number == dtp->common.unit);

[Bug target/99531] [9/10/11 Regression] Performance regression since gcc 9 (argument passing / register allocation)

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r9-4310-geeae9314d4449b76:

caller:
.LFB0:
.cfi_startproc
pushq   %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
movl%r8d, %r9d
popq%r12
.cfi_def_cfa_offset 8
movl%ecx, %r8d
movl%edx, %ecx
movl%esi, %edx
movl%edi, %esi
xorl%edi, %edi
jmp func
.cfi_endproc

before the revision:

caller:
.LFB0:
.cfi_startproc
movl%r8d, %r9d
movl%ecx, %r8d
movl%edx, %ecx
movl%esi, %edx
movl%edi, %esi
xorl%edi, %edi
jmp func
.cfi_endproc

[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-03-11
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Please provide a reproducer.

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

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #22 from Vladimir Makarov  ---
> Could you check the patch on the failed bootstraps.  I have no access to

Unfortunately, it didn't help.  I continue to revert the patches for PRs
99378, 99422, and 99454 locally for now.

> solaris machines.

Technically, you have ;-)  There's gcc211 in the cfarm, but
unfortunately the installation is highly nonstandard, doesn't follow
cfarm conventions, and lacks GNAT.  While I do have a local gcc
installation on the box without these issues, I agree it would be quite
tedious to use.  I suspect that the same issue occurs on Linux/sparc64,
too (gcc202), but trying that on a machine that's pretty unreliable
wouldn't be my idea of fun.

[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings

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

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

--- Comment #6 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566596.html

@Martin: Besides helgrind, you could also try building your program with
-fsanitize=thread - this might also help finding some issues (for environment
flags, see https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags )

[Bug c++/99547] New: [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE

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

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

Bug ID: 99547
   Summary: [11 regression] g++.dg/modules/xtreme-header-5_c.C
-std=c++2a ICE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Between r11-7602 and r11-7616, I've noticed a regression:
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (internal compiler error)

on arm-eabi targets, and aarch64-elf (that is, configs using newlib vs glibc
for *linux* targets)

When using -mfloat-abi=hard on arm-eabi, I can see:

/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/gcc/testsuite/g++1/../../xg++
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3
/gcc/testsuite/g++1/../../ /gcc/testsuite/g++.dg/modules/xtreme-header-5_c.C
-mcpu=cortex-a7 -mfloat-abi=hard -march=armv7ve+simd -fdiagnostics-plain-output
-nostdinc++

-I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/arm-none-eabi
-I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/
obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include
-I/libstdc++-v3/libsupc++ -I/libstdc++-v3/include/backward
-I/libstdc++-v3/testsuite/util
 -fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long -fmodules-ts
-fno-module-lazy -S -o xtreme-header-5_c.s
/gcc/testsuite/g++.dg/modules/xtreme-header-5_c.C:3:30: internal compiler
error: same canonical type node for different types 'void' and
'std::__void_t::value,
std::is_volatile<_Tp>::value>::__type& (&)()>()() : declval::value,
std::is_volatile<_Yp>::value>::__type& (&)()>()()))>'
0x97390f comptypes(tree_node*, tree_node*, int)
/gcc/cp/typeck.c:1555
0x899d4c template_args_equal(tree_node*, tree_node*, bool)
/gcc/cp/pt.c:9207
0x8998ed comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
/gcc/cp/pt.c:9254
0x8a6243 spec_hasher::equal(spec_entry*, spec_entry*)
/gcc/cp/pt.c:1725
0x90e5ae hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
/gcc/hash-table.h:981
0x8ad6bb add_mergeable_specialization(bool, spec_entry*, tree_node*, unsigned
int)
/gcc/cp/pt.c:30018
0x80bfb1 trees_in::decl_value()
/gcc/cp/module.cc:8068
0x80dc47 trees_in::tree_node(bool)
/gcc/cp/module.cc:9174
0x816a3b module_state::read_cluster(unsigned int)
/gcc/cp/module.cc:14858
0x816dd4 module_state::load_section(unsigned int, binding_slot*)
/gcc/cp/module.cc:18129
0x817d37 module_state::read_language(bool)
/gcc/cp/module.cc:18058
0x81800a direct_import
/gcc/cp/module.cc:18920
0x88c2b4 cp_parser_translation_unit
/gcc/cp/parser.c:4905
0x88c2b4 c_parse_file()
/gcc/cp/parser.c:45241
0xa0a37c c_common_parse_file()
/gcc/c-family/c-opts.c:1218

[Bug c++/99547] [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE

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

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

--- Comment #1 from Christophe Lyon  ---
I read too quickly, on aarch64 the failing test is xtreme-header-3_c.C.

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

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

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

--- Comment #24 from Eric Botcazou  ---
> Technically, you have ;-)  There's gcc211 in the cfarm, but
> unfortunately the installation is highly nonstandard, doesn't follow
> cfarm conventions, and lacks GNAT.  While I do have a local gcc
> installation on the box without these issues, I agree it would be quite
> tedious to use.  I suspect that the same issue occurs on Linux/sparc64,
> too (gcc202), but trying that on a machine that's pretty unreliable
> wouldn't be my idea of fun.

This can be reproduced with a minimal Ada cross-compiler, i.e. you just need
the gnat1 compiler, the skeleton of libada and the command line:
  $(srcdir)/configure --target=sparc-sun-solaris2.11
--enable-languages=c,c++,ada
  make CFLAGS=-g CXXFLAGS=-g ADAFLAGS="-gnatpga -gnatws"
  cd gcc/ada; make gnatlib
  cd rts; ../../gnat1 -quiet a-lfztio.ads -gnatpg

a-ztflau.adb: In function 'Ada.Long_Float_Wide_Wide_Text_Io.Aux_Float.Put':
a-ztflau.adb:101:8: error: insn does not satisfy its constraints:
(insn 32 31 88 2 (set (mem/c:DF (plus:SI (reg/f:SI 30 %fp)
(const_int -5232 [0xeb90])) [29 %sfp+-5232 S8 A64])
(reg:DF 40 %f8 [orig:109 _1 ] [109])) "a-ztflau.adb":99:7 153
{*movdf_insn_sp32}
 (nil))
during RTL pass: reload
+===GNAT BUG DETECTED==+
| 11.0.1 20210310 (experimental) [master revision
1c3c12b0a6f:f62bd375583:47403a0eefac52636db768dc46c3c88a2cd4b28e]
(sparc-sun-solaris2.11) GCC error:|
| in extract_constrain_insn, at recog.c:2670   |
| Error detected around a-ztflau.adb:101:8

[Bug ipa/99517] __builtin_convertvector with casts

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

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

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

https://gcc.gnu.org/g:070ab283d16d8e8e8bb70f9801aca347f008cbd0

commit r11-7618-g070ab283d16d8e8e8bb70f9801aca347f008cbd0
Author: Jakub Jelinek 
Date:   Thu Mar 11 10:59:18 2021 +0100

icf: Check return type of internal fn calls [PR99517]

The following testcase is miscompiled, because IPA-ICF considers the two
functions identical.  They aren't, the types of the .VEC_CONVERT call
lhs is different.  But for calls to internal functions, there is no
fntype nor callee with a function type to compare, so all we compare
is just the ifn, arguments and some call flags.

The following patch fixes it by checking the internal fn calls like e.g.
gimple
assignments where the type of the lhs is checked too.

2021-03-11  Jakub Jelinek  

PR ipa/99517
* ipa-icf-gimple.c (func_checker::compare_gimple_call): For
internal
function calls with lhs fail if the lhs don't have compatible
types.

* gcc.target/i386/avx2-pr99517-1.c: New test.
* gcc.target/i386/avx2-pr99517-2.c: New test.

[Bug ipa/99517] [10 Regression] __builtin_convertvector with casts

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|__builtin_convertvector |[10 Regression]
   |with casts  |__builtin_convertvector
   ||with casts
   Target Milestone|--- |10.3

--- Comment #8 from Jakub Jelinek  ---
This is actually a regression that started with
r10-4643-ga37f58f506e436bdf8f4f5be4afbf2d246538058
Now fixed on the trunk.

[Bug c++/96078] [10 Regression] flatten attribute on constructor and destructor causes spurious warning

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
FWIW, I've just confirmed a fail of attr-flatten-1.c in gcc-10, targeting
ppc64-vxw7r2.  The expected warning is not issued.  I haven't tried other
targets or branches yet.

[Bug rtl-optimization/99548] New: Help me! Lost the fight against the compiler.

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 99548
   Summary: Help me! Lost the fight against the compiler.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://godbolt.org/z/Kd8q57

The compiler just could not generate as good as assembly as I manually wrote.
Unfortunately, due to the calling convention issues, the inline asm version
would never be portable and hurt other compiler optimizations.


Some patterns like neither GCC nor clang could correctly deal with it.
std::uint64_t v=0;//set 0 to make compiler happy or it is UB.
sub_borrow(carry,v,v,v);


movl$0, %eax
movq%rax, %rdx
sbbq%rax, %rdx

What the code actually want is to
sbb %rdx,%rdx
Which is to set the register to the UINT64_MAX when carry (borrow) flag is 1.

movq(%rdx), %rcx
movq8(%rsi), %r9
addq(%rsi), %rcx
movq16(%rsi), %r8
movq24(%rdx), %rax
adcq8(%rdx), %r9
movq24(%rsi), %rsi
adcq16(%rdx), %r8
adcq%rax, %rsi
movl$0, %eax

Do we have any possibility to fix those optimization issues in the compiler?

[Bug c++/99484] [modules] ICE same canonical type node for different types ‘void’ and ‘std::__void_t<_Op<_Args ...> >’

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

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

--- Comment #2 from Alexander Lelyakin  ---
One more similar, but not the same message;

g++ -std=c++20 -fmodules-ts -x c++-system-header any
g++ -std=c++20 -fmodules-ts -x c++-system-header vector
g++ -std=c++20 -fmodules-ts -x c++-system-header sstream
g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex
g++ -std=c++20 -fmodules-ts -x c++-system-header version
g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_set
g++ -std=c++20 -fmodules-ts -x c++-system-header string_view
g++ -std=c++20 -fmodules-ts -x c++-system-header new
g++ -std=c++20 -fmodules-ts -x c++-system-header complex

In file included from /usr/local/include/c++/11.0.1/istream:39,
 from /usr/local/include/c++/11.0.1/sstream:38,
of module /usr/local/include/c++/11.0.1/sstream, imported at
/usr/local/include/c++/11.0.1/complex:45:
/usr/local/include/c++/11.0.1/ostream: In instantiation of ‘struct
std::__is_convertible_to_basic_ostream&>’:
/usr/local/include/c++/11.0.1/ostream:773:5:   required by substitution of
‘template typename
std::enable_if >,
std::__is_convertible_to_basic_ostream<_Ostream>, std::__is_insertable::__ostream_type, const _Tp&, void>
>::value, typename
std::__is_convertible_to_basic_ostream<_Tp>::__ostream_type>::type
std::operator<<(_Ostream&&, const _Tp&) [with _Ostream =
std::basic_ostream&; _Tp = std::complex]’
/usr/local/include/c++/11.0.1/complex:1539:70:   required from here
/usr/local/include/c++/11.0.1/ostream:732:12: internal compiler error: same
canonical type node for different types ‘void’ and ‘std::__void_t::type*>()))>’
  732 | struct __is_convertible_to_basic_ostream
  |^
0xb7f8dd comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1554
0xae4bff template_args_equal(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/pt.c:9207
0xae4758 template_args_equal(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/pt.c:9170
0xae4758 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc/gcc/cp/pt.c:9254
0xae4758 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc/gcc/cp/pt.c:9234
0xaee073 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc/gcc/cp/pt.c:1725
0xb33b96 hash_table::verify(spec_entry*
const&, unsigned int)
../../gcc/gcc/hash-table.h:1032
0xb3413e hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:968
0xaf101b add_mergeable_specialization(bool, spec_entry*, tree_node*, unsigned
int)
../../gcc/gcc/cp/pt.c:30018
0xa6ef5f trees_in::decl_value()
../../gcc/gcc/cp/module.cc:8068
0xa67017 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9174
0xa6d66b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14858
0xa6db6d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18129
0xa6dc2f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18783
0xa70e67 lazy_load_pendings(tree_node*)
../../gcc/gcc/cp/module.cc:18876
0xb2045f lookup_template_class_1
../../gcc/gcc/cp/pt.c:9799
0xb227f6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:10237
0xb227f6 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:13572
0xb2f505 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:11882
0xb30f32 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:12264
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210310 (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 fortran/99545] [11 Regression] ICE in gfc_trans_assignment

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #3 from Jürgen Reuter  ---
Created attachment 50362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50362&action=edit
First (large) reproducer to play with, reducing atm

[Bug tree-optimization/99523] Declarations for variable names missing in GIMPLE dump

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-7619-gb08c978f2e18507cbd9853305185665edf05c598
Author: Richard Biener 
Date:   Thu Mar 11 10:09:43 2021 +0100

tree-optimization/99523 - missing SSA decls in dumps

This makes sure to dump SSA names without identifier in the
declaration part of a function dump.  While we dump the
anonymous variable decls the SSA names referencing them appear
without a clear reference as to what anonymous variable is used
(_3 vs. D.1234).

2021-03-11  Richard Biener  

PR tree-optimization/99523
* tree-cfg.c (dump_function_to_file): Dump SSA names
w/o identifier to the decls section as well, not only those
without a VAR_DECL.

[Bug tree-optimization/99523] Declarations for variable names missing in GIMPLE dump

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

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

[here.is.a.gcc.bug at gmail dot com via Gcc-bugs]

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

Bug ID: 99549
   Summary: Segfault when scalar argument of elemental function is
both derived type with allocatable component and a
function result
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: here.is.a.gcc.bug at gmail dot com
  Target Milestone: ---

Created attachment 50363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50363&action=edit
A self-contained fortran program which causes the bug.

An elemental function is called where one argument is an array and another
argument is a scalar.

If the scalar argument is both:
  - A derived type with an allocatable component
  - The result of a function call (an rvalue in c++ speak)

Then a segfault happens.

[Bug tree-optimization/99523] Declarations for variable names missing in GIMPLE dump

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

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

--- Comment #5 from Alex Coplan  ---
Thanks for the fix!

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-11
  Known to fail||10.2.1, 7.5.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||wrong-code
  Known to work||11.0

--- Comment #1 from Richard Biener  ---
Confirmed.

Program received signal SIGSEGV, Segmentation fault.
0x00401097 in m::add_t (lhs=..., rhs=...) at t.f90:21
21output%contents = lhs%contents+rhs%contents

it seems to work fine with GCC 11 though.

[Bug c++/99547] [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug debug/99490] -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

--- Comment #15 from Jakub Jelinek  ---
Created attachment 50364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50364&action=edit
gcc11-pr99490.patch

Updated patch that implements what has been discussed on dwarf mailing list.

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

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

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

--- Comment #1 from Erick Ochoa  ---
Hi,

I have an ICE on this assertion as well, but I found it by compiling x264_r
with the following flags

```
   OPTIMIZE = -g -Ofast -funroll-loops -flto
   COPTIMIZE= --param early-inlining-insns=51
   PASS1_FLAGS  = -fprofile-generate
   PASS2_FLAGS  = -fprofile-use
```

I did a bisection and I think it might be related to commit
a11ef53238c8ebaab9a3fbf200cb8b5c997b473b.

Here is my stack trace. Please note that the assertion is in a different line
in the above commit, but it is the same assertion as the snapshot reported by
Arseny.

```
x264_src/encoder/analyse.c: In function 'x264_analyse_update_cache':
x264_src/encoder/analyse.c:3319:13: internal compiler error: in expand_mult, at
expmed.c:3575
 3319 | static void x264_analyse_update_cache( x264_t *h, x264_mb_analysis_t *a
 )
  | ^
0x8797b3 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
/home/eochoa/gcc/gcc/expmed.c:3575
0x8a33db expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/eochoa/gcc/gcc/expr.c:9205
0x75845f expand_gimple_stmt_1
/home/eochoa/gcc/gcc/cfgexpand.c:3947
0x75845f expand_gimple_stmt
/home/eochoa/gcc/gcc/cfgexpand.c:4008
0x75fa13 expand_gimple_basic_block
/home/eochoa/gcc/gcc/cfgexpand.c:6045
0x761bc7 execute
/home/eochoa/gcc/gcc/cfgexpand.c:6729
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/eochoa/gcc-inst/bin/gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake: *** [/home/eochoa/cpu2017-unmodified/benchspec/Makefile.defaults:337:
x264_r] Error 1
```

For me, the error is triggered:
* in the second compilation stage (i.e., when -fprofile-use is used)
* --param early-inlining-insns=51 needs to be set. Otherwise, the error is not
observed. I haven't tried with some lower values
* I haven't had the time to toggle the other flags, nor reduce the test case.

[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:9d4ad8570c3bab2e145aa7b39ce8c66bafbf1945

commit r11-7620-g9d4ad8570c3bab2e145aa7b39ce8c66bafbf1945
Author: Richard Biener 
Date:   Thu Mar 11 13:30:56 2021 +0100

testsuite/97494 - amend gcc.dg/vect/slp-21.c

As reported in the PR all powerpc64 targets fail

FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2

because like on arm we now vectorize 4 opportunities.  This adjusts
the testcase to follow the arm example.

2021-03-11  Richard Biener  

PR testsuite/97494
* gcc.dg/vect/slp-21.c: Adjust for powerpc64*-*-*.

[Bug debug/99490] -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

--- Comment #16 from Jakub Jelinek  ---
Created attachment 50365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50365&action=edit
pr99490-2.tar.xz

And for Jan, assembly for the pr99490.c from the first tarball with the latest
patch.

[Bug target/99381] SVE: ICE with ACLE intrinsics when missing -march=armv8.2-a+sve

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alex Coplan
:

https://gcc.gnu.org/g:6925d4763e469e43b9d06e4a17187215bc03d3c9

commit r10-9436-g6925d4763e469e43b9d06e4a17187215bc03d3c9
Author: Alex Coplan 
Date:   Thu Mar 4 14:36:39 2021 +

aarch64: Add missing error_mark_node check [PR99381]

We were missing a check in function_resolver::require_vector_type to see
if the argument type was already invalid. This was causing us to attempt
to emit a diagnostic and subsequently ICE in print_type. Fixed thusly.

gcc/ChangeLog:

PR target/99381
* config/aarch64/aarch64-sve-builtins.cc
(function_resolver::require_vector_type): Handle error_mark_node.

gcc/testsuite/ChangeLog:

PR target/99381
* gcc.target/aarch64/pr99381.c: New test.

(cherry picked from commit a6bc1680a493de356d6a381718021c6a44401201)

[Bug target/99381] SVE: ICE with ACLE intrinsics when missing -march=armv8.2-a+sve

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #4 from Alex Coplan  ---
Fixed.

[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|WAITING |ASSIGNED

--- Comment #4 from Martin Liška  ---
Good, I can reproduce that now. I'm reducing that right now (starting with 2MB
of .f90 file).

[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
The power7 failure with

FAIL: gcc.dg/vect/vect-complex-5.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2

Shows that alignment checking as done in get_group_load_store_type does not
match what we later code-generate.  The first group, storing into

  c[i].f1 = a1[i] + b1[i];

is said to be aligned while the second

  c[i].f2 = a2[i] + b2[i];

is said to be unaligned and thus unsupported.  In reality both are
VMAT_STRIDED_SLP which can end up with a variety of alignment requirements.
In this case we emit a series of SImode stores to SImode aligned memory
in both cases.

Thus,

static bool
get_group_load_store_type (vec_info *vinfo, stmt_vec_info stmt_info,
...
  if (*memory_access_type == VMAT_GATHER_SCATTER
  || *memory_access_type == VMAT_ELEMENTWISE)
*alignment_support_scheme = dr_unaligned_supported;
  else
*alignment_support_scheme
  = vect_supportable_dr_alignment (vinfo, first_dr_info, false);

is incomplete and misses special-casing of VMAT_STRIDED_SLP.  For
VMAT_ELEMENTWISE we seem to simply assume that element (scalar)
misaligned accesses are OK (ISTR we reject non-element aligned vectorization),
but with VMAT_STRIDED_SLP we eventually use SImode to access two HImode
components which are not necessarily aligned according to SImode.

There's the related bug where the alignment we compute for a vector DR
is biased when the stride is negative and which also results in bogus
alignment to be used for checks.

ISTR I wrote somewhere that vectorizable_load/store analysis & costing
should possibly simply run through a common code path for analysis
and code generation (fending off actual stmt generation for analysis)
to avoid this kind of disconnect between code gen assumptions and
analysis parts.  Thus the classical if (!vec_stmt) return early; approach
isn't good for maintainance.

That said, gcc.dg/vect/vect-complex-5.c is a missed optimization on
!hw-misaligned targets, thus I'm going to XFAIL it for ! vect_hw_misalign.

[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #5 from Jürgen Reuter  ---
I'm also reducing it right now.

[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-7621-gf6c1d026c3a9109de58d1148e3f54b5273ebb86a
Author: Richard Biener 
Date:   Thu Mar 11 14:03:55 2021 +0100

testsuite/97494 - XFAIL gcc.dg/vect/vect-complex-5.c on !vect_hw_misalign

This is a missed optimization due to bogus alignment analysis.

2021-03-11  Richard Biener  

PR testsuite/97494
* gcc.dg/vect/vect-complex-5.c: XFAIL on !vect_hw_misalign.

[Bug c++/99550] New: ICE (segfault) on arm with -std=c++2a

[delleyves at gmx dot ch via Gcc-bugs]

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

Bug ID: 99550
   Summary: ICE (segfault) on arm with -std=c++2a
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: delleyves at gmx dot ch
  Target Milestone: ---

The following code segfaults on "arm-gcc 10.2.1 (none)" (as found on
godbolt.org) when compiled with `-std=c++2a`, but not without that flag.

So does the official ARM GCC release gcc-arm-none-eabi-10-2020-q4-major on
Ubuntu.

On my OSX however, it doesn't segfault. Neither does the x86-64 gcc 10.2 on
godbolt.

```
#include 

template 
struct JoinedRange {
  using value_type = value_type_;
  template 
  struct Iterator {
template 
using maybe_const_t = std::conditional_t;

template 
friend class Iterator;

   public:
using value_type = JoinedRange::value_type;
using reference = maybe_const_t;
using pointer = maybe_const_t*;
  };
  using iterator = Iterator;
  using const_iterator = Iterator;
};

template class JoinedRange;
```

[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Steffen Schuemann from comment #0)
> On POSIX filesystem backend type systems the
> std::filesystem::recursive_directory_iterator throws a filesystem_error
> exception with "operation not permitted" when the opendir/readdir call
> returns EPERM instead of EACCES even if
> std::filesystem::directory_options::skip_permission_denied is set.

POSIX is clear that opendir sets EACCES not EPERM.


> Given the following code:
> 
> #include 
> #include 

N.B. This is missing a "namespace fs = std::filesystem;"

> This fails for example on macOS when called on the user home directory with:
> 
> Error: filesystem error: cannot increment recursive directory iterator:
> Operation not permitted
>
> This is due to System Integrity Protection (since macOS 10.14) on the
> "/Users//Library/Application Support/MobileSync" folder leading to
> EPERM.

That seems to be a MacOS bug.

> On Linux, called with / it stops when hitting for example a
> "/proc/1/task/1/cwd", resulting in EPERM too.

But that happens in your code, not in the library. The error is:

  Error: filesystem error: status: Permission denied [/proc/1/task/1/cwd]

And it comes from this line:

if(de.is_regular_file()) {

I think the code is working correctly on linux.

[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-7622-gaa0d8a3e28cd3365a2910884ce3e7cb67b07f866
Author: Richard Biener 
Date:   Thu Mar 11 14:11:08 2021 +0100

testsuite/97494 - XFAIL gcc.dg/vect/pr97428.c on !vect_hw_misalign

While we could at least vectorize it on targets which support
re-alignment tokens we fail to do this because of imperfections in
alignment analysis.  XFAIL when the HW cannot deal with misaligned
vector accesses for now.

2021-03-11  Richard Biener  

PR testsuite/97494
* gcc.dg/vect/pr97428.c: XFAIL on !vect_hw_misalign.

[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> > On Linux, called with / it stops when hitting for example a
> > "/proc/1/task/1/cwd", resulting in EPERM too.
> 
> But that happens in your code, not in the library. The error is:
> 
>   Error: filesystem error: status: Permission denied [/proc/1/task/1/cwd]

And that's an EACCES error anyway (as POSIX requires for stat(3) permission
errors). The text would be "Operation not permitted" for EPERM.

[Bug libstdc++/99413] internal library headers are not header-unit ready

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #4 from Jonathan Wakely  ---
Fixed for gcc-11.

[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
All cases in the original report have been addressed.  If other cases
persist/pop up, please open a new PR.  If the originally reported FAILs persist
fell free to re-open (I only have limited ppc testing capabilities).

[Bug target/99551] New: aarch64: csel is used for cold scalar computation which affects performance

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

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

Bug ID: 99551
   Summary: aarch64: csel is used for cold scalar computation
which affects performance
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

this is an optimization bug, i don't know which layer it should
be fixed so i report it as target bug.

cold path affects performance of hot code because csel is used:

long foo(long x, int c)
{
if (__builtin_expect(c,0))
x = (x + 15) & ~15;
return x;
}


compiles to

foo:
cmp w1, 0
add x1, x0, 15
and x1, x1, -16
cselx0, x1, x0, ne
ret

i think it would be better to use a branch if the user
explicitly marked the computation cold.
e.g. this is faster if c is always 0:

long foo(long x, int c)
{
if (__builtin_expect(c,0)) {
asm ("");
x = (x + 15) & ~15;
}
return x;
}

foo:
cbnzw1, .L7
ret
.L7:
add x0, x0, 15
and x0, x0, -16
ret

[Bug testsuite/98245] [11 Regression] gcc.dg/vect/bb-slp-46.c FAILs

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

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

--- Comment #3 from Richard Biener  ---
OK, so the issue is sparc has V2SI only and the dump scanning expects V4SI. 
Since the test for the number of + is somewhat redundant I'll simply drop it.

[Bug c++/99535] g++ rejects valid code in constexpr copy ctor and volatile submember

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Yes, I think the special member functions are ill-formed (no diagnostic
required) as per http://eel.is/c++draft/dcl.constexpr#6.sentence-1

[Bug testsuite/98245] [11 Regression] gcc.dg/vect/bb-slp-46.c FAILs

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-7623-g3b938c64f775eafd977f79c4f3038082ae7e0127
Author: Richard Biener 
Date:   Thu Mar 11 14:25:16 2021 +0100

testsuite/98245 - adjust dump scanning of gcc.dg/vect/bb-slp-46.c

Checking the number of pluses is unreliable since the vector size
isn't known.  Instead see that the unwanted scalar compute is not
there.

2021-03-11  Richard Biener  

PR testsuite/98245
* gcc.dg/vect/bb-slp-46.c: Scan for the scalar compute
instead of verifying the total number of adds.

[Bug testsuite/98245] [11 Regression] gcc.dg/vect/bb-slp-46.c FAILs

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug lto/88140] Array simplification for LTO streaming is disabled

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
Summary|[9/10/11 Regression] ICE:   |Array simplification for
   |verify_gimple failed since  |LTO streaming is disabled
   |r266325 |
   Target Milestone|10.3|---
  Known to fail||11.0
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Keywords||lto

--- Comment #17 from Richard Biener  ---
Re-wording and removing regression marker.

[Bug c++/99536] unexplained warning on "uninitialized value" in std::normal_distribution

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

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

--- Comment #1 from Jonathan Wakely  ---
GCC 5 is old and no longer supported.

This is probably a jump threading bug. The _M_saved member is only ever used if
_M_saved_available says it can be used, and that is only the case after it's
been initialized.

We could probably just initialize it on construction to avoid the false
positive warning:

--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -2024,12 +2024,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   explicit
   normal_distribution(result_type __mean,
  result_type __stddev = result_type(1))
-  : _M_param(__mean, __stddev), _M_saved_available(false)
+  : _M_param(__mean, __stddev)
   { }

   explicit
   normal_distribution(const param_type& __p)
-  : _M_param(__p), _M_saved_available(false)
+  : _M_param(__p)
   { }

   /**
@@ -2166,8 +2166,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const param_type& __p);

   param_type  _M_param;
-  result_type _M_saved;
-  bool_M_saved_available;
+  result_type _M_saved = 0;
+  bool_M_saved_available = false;
 };

   /**

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-11
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
It is OK to use indirect branch via GOT in 64-bit. But it isn't OK for 32-bit
since PIC register may not be available at call site.

[Bug lto/87988] Streaming of ABSTRACT_ORIGIN is expensive

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|10.3|---
Summary|[9/10/11 Regression]|Streaming of
   |Streaming of|ABSTRACT_ORIGIN is
   |ABSTRACT_ORIGIN is  |expensive
   |expensive   |
  Known to fail||11.0

--- Comment #14 from Richard Biener  ---
So this isn't really a regression, we just stream what's necessary to emit
correct debug.  And in fact we now stream less since the abstract origins are
now ultimate origins.

This but is about streaming abstract origins as DIE references rather than
as BLOCKs (and in the end also maintain it as such reference, not
re-materializing the abstract BLOCKs).

[Bug libstdc++/99172] Build failure with slibtool and vtv

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

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

--- Comment #12 from Jonathan Wakely  ---
Comment on attachment 50360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50360
Proposed patch to fix issue

The patch looks good but please CC the libstdc++ list for libstdc++ patches,
thanks.

[Bug libstdc++/99537] Wrong memory_order used in stop_token ref-counting

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/99546] Weird return value of C++20 requires expression

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords|wrong-code  |accepts-invalid
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-11

--- Comment #2 from Jonathan Wakely  ---
I think the requires expression should be rejected as ill-formed.

[Bug libgomp/98738] task-detach-6.f90 hangs intermittently

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |kcy at codesourcery dot 
com

--- Comment #13 from Thomas Schwinge  ---
Kwok, it seems -- at least in my testing -- that your latest commit
d656bfda2d8316627d0bbb18b10954e6aaf3c88c "openmp: Fix intermittent hanging of
task-detach-6 libgomp tests [PR98738]" has broken things with nvptx offloading
enabled: because of hanging
'libgomp.c/../libgomp.c-c++-common/task-detach-6.c', I manually terminated
testing after:

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
24507 thomas20   0 9157400 130444 122980 R 100.0  0.4  41:13.59
./task-detach-6.exe

..., and another run after:

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
32365 thomas20   0 9159472 140040 128136 R 100.0  0.4  59:05.48
./task-detach-6.exe

I had 100 % GPU utilization in this state.

Is there something wrong (are you or anyone reproducing that with nvptx
offloading?), or is something wrong on my side?

[Bug libgomp/98738] task-detach-6.f90 hangs intermittently

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

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

--- Comment #14 from Jakub Jelinek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565740.html ?

[Bug libgomp/98738] task-detach-6.f90 hangs intermittently

[kcy at codesourcery dot com via Gcc-bugs]

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

--- Comment #15 from Kwok Yeung  ---
(In reply to Thomas Schwinge from comment #13)
> Kwok, it seems -- at least in my testing -- that your latest commit
> d656bfda2d8316627d0bbb18b10954e6aaf3c88c "openmp: Fix intermittent hanging
> of task-detach-6 libgomp tests [PR98738]" has broken things with nvptx
> offloading enabled: because of hanging
> 'libgomp.c/../libgomp.c-c++-common/task-detach-6.c'

I noted this hang at:

https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565740.html

It does not seem to be an issue with the detach support though, as this trivial
testcase will also hang.

int main (void)
{
#pragma omp target
   #pragma omp parallel
 #pragma omp task
   ;
}

I have confirmed that this behaviour occurs even before my original patch for
implementing the detach clause, and it does not occur with GCN offloading.

[Bug tree-optimization/89049] [8/9/10/11 Regression] Unexpected vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
  Known to fail||11.0
   Last reconfirmed|2019-01-25 00:00:00 |2021-3-11
 Status|ASSIGNED|NEW

--- Comment #13 from Richard Biener  ---
Re-confirmed.  Note the same in-order reduction is profitable with SSE:

0x3704d70 *_3 1 times scalar_load costs 12 in body
0x3704d70 _4 + r_16 1 times scalar_stmt costs 12 in body

0x3825d80 _4 + r_16 4 times vec_to_scalar costs 16 in body
0x3825d80 _4 + r_16 4 times scalar_stmt costs 48 in body
0x3825d80 *_3 1 times unaligned_load (misalign -1) costs 12 in body

t4.c:1:53: note:  Cost model analysis:
  Vector inside of loop cost: 76
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar iteration cost: 24
  Scalar outside cost: 0
  Vector outside cost: 0
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 0


bar:
.LFB0:
.cfi_startproc
leaq4096(%rdi), %rax
pxor%xmm1, %xmm1
.p2align 4,,10
.p2align 3
.L2:
movups  (%rdi), %xmm0
addq$16, %rdi
addss   %xmm0, %xmm1
movaps  %xmm0, %xmm2
shufps  $85, %xmm0, %xmm2
addss   %xmm2, %xmm1
movaps  %xmm0, %xmm2
unpckhps%xmm0, %xmm2
shufps  $255, %xmm0, %xmm0
addss   %xmm2, %xmm1
addss   %xmm0, %xmm1
cmpq%rdi, %rax
jne .L2
cvttss2sil  %xmm1, %eax
ret

iff the code in forwprop that decomposes loads of BLKmode vectors used only
by BIT_FIELD_REFs would be relaxed to cover all modes and TARGET_MEM_REFs
that are simple we'd get

.L2:
addl$1, %eax
addss   (%rdi), %xmm0
addss   4(%rdi), %xmm0
addq$16, %rdi
addss   -8(%rdi), %xmm0
addss   -4(%rdi), %xmm0
cmpl$256, %eax
jne .L2

[Bug tree-optimization/90579] [8/9/10/11 Regression] Huge store forward stall due to vectorizer, missed CSE

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

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

--- Comment #11 from Richard Biener  ---
OK, so push_partial_def could simply record the first non-constant def and upon
the second, if it completes all bits handle some easy cases (VEC_PERM_EXPR,
COMPLEX_EXPR come to my mind, eventually also CONSTRUCTOR) and else fail.

Will look into this tomorrow, it shouldn't be too awkward and removing
STLF when a read is detected to overlap two previous writes is definitely
worth trouble.

[Bug libgomp/98738] task-detach-6.f90 hangs intermittently

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

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

--- Comment #16 from Thomas Schwinge  ---
Ugh.  :-( Where are we tracking this, and is anyone working on this?  It's
clearly not useful to have (nvptx offloading) testing to run into known
TIMEOUTs?

[Bug fortran/93660] Decl mismatch between fndecl TYPE and used arglist / ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993

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

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|ICE in  |Decl mismatch between
   |ipa_simd_modify_function_bo |fndecl TYPE and used
   |dy, at omp-simd-clone.c:993 |arglist / ICE in
   ||ipa_simd_modify_function_bo
   ||dy, at omp-simd-clone.c:993
 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
The bug seems to be that
   gfc_get_function_type ()

does not contain all hidden arguments, which are then later added by
   create_function_arglist

In particular: OPTIONAL + VALUE, coarray -fcoarray=lib (token, offset), ...?

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

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566609.html

[Bug libstdc++/99552] New: FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)

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

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

Bug ID: 99552
   Summary: FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for
excess errors)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/t
est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-11/
hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-11/hppa2.0w-hp-hpux11.11/lib/
-isy
stem /opt/gnu/gcc/gcc-11/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc
-11/hppa2.0w-hp-hpux11.11/sys-include -fchecking=1
-B/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -g
-O2 -DLOCALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib
stdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux1
1.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.cc
-std=gnu++2a -pthread -L../../libatomic/.libs -latomic
-fdiagnostics-plain-output ./libtestc++.a
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/filesystem/.libs
-lm -o ./bool.exe
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.cc:64:
warning: alignment (64) for _ZZNSt8__detail9__waiters6_S_forEPKvE3__w exceeds
maximum alignment for global common data.  Using 32
output is:
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.cc:64:
warning: alignment (64) for _ZZNSt8__detail9__waiters6_S_forEPKvE3__w exceeds
maximum alignment for global common data.  Using 32

FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.cc:64:
warning: alignment (64) for _ZZNSt8__detail9__waiters6_S_forEPKvE3__w exceeds
maximum alignment for global common data.  Using 32

Similar fails:
FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)
FAIL: 29_atomics/atomic/wait_notify/generic.cc (test for excess errors)
FAIL: 29_atomics/atomic/wait_notify/pointers.cc (test for excess errors)
FAIL: 29_atomics/atomic_flag/wait_notify/1.cc (test for excess errors)
FAIL: 29_atomics/atomic_float/wait_notify.cc (test for excess errors)
FAIL: 29_atomics/atomic_integral/wait_notify.cc (test for excess errors)
FAIL: 29_atomics/atomic_ref/wait_notify.cc (test for excess errors)
FAIL: 30_threads/barrier/arrive.cc (test for excess errors)
FAIL: 30_threads/barrier/arrive_and_drop.cc (test for excess errors)
FAIL: 30_threads/barrier/arrive_and_wait.cc (test for excess errors)
FAIL: 30_threads/barrier/completion.cc (test for excess errors)
FAIL: 30_threads/condition_variable_any/stop_token/wait_on.cc (test for excess
errors)
FAIL: 30_threads/jthread/3.cc (test for excess errors)
FAIL: 30_threads/jthread/jthread.cc (test for excess errors)
FAIL: 30_threads/latch/3.cc (test for excess errors)

Usually, I add "-fno-common" to avoid these warnings on hppa*-*-hpux*.

[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #6 from Jürgen Reuter  ---
Voila, here is a short reproducer:
module commands

  implicit none
  private

  type, abstract :: range_t
 integer :: step_mode = 0
 integer :: n_step = 0
  end type range_t

  type, extends (range_t) :: range_int_t
 integer :: i_step = 0
  end type range_int_t

  type, extends (range_t) :: range_real_t
 real :: lr_step = 0
end type range_real_t

  type :: cmd_scan_t
 private
 class(range_t), dimension(:), allocatable :: range
   contains
 procedure :: compile => cmd_scan_compile
  end type cmd_scan_t

contains

  subroutine cmd_scan_compile (cmd)
class(cmd_scan_t), intent(inout) :: cmd
allocate (range_int_t :: cmd%range (3))
allocate (range_real_t :: cmd%range (3))
  end subroutine cmd_scan_compile

end module commands

[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #7 from Jürgen Reuter  ---
It actuallys is the -fcheck=mem part that triggers the ICE.

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 50366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50366&action=edit
A patch

I am testing this.

[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied

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

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

--- Comment #3 from Jonathan Wakely  ---
The standard says that skip_permission_denied means to ignore "an error
indicating that permission to access p is denied" and it's pretty clearly
intended to correspond to std::errc::permission_denied errors, not
std::errc::operation_not_permitted.

But this should solve the issue for MacOS:

--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -207,7 +207,7 @@ recursive_directory_iterator(const path& p,
directory_options options,
   else
 {
   const int err = errno;
-  if (err == EACCES
+  if (fs::is_permission_denied_error(err)
  && is_set(options, fs::directory_options::skip_permission_denied))
{
  if (ecptr)
diff --git a/libstdc++-v3/src/filesystem/dir-common.h
b/libstdc++-v3/src/filesystem/dir-common.h
index 56e279230f4..a49b8304a29 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -141,6 +141,18 @@ struct _Dir_base
   posix::DIR*  dirp;
 };

+inline bool
+is_permission_denied_error(int e)
+{
+  if (e == EACCES)
+return true;
+#ifdef __APPLE__
+  if (e == EPERM) // See PR 99533
+return true;
+#endif
+  return false;
+}
+
 } // namespace filesystem

 // BEGIN/END macros must be defined before including this file.
diff --git a/libstdc++-v3/src/filesystem/dir.cc
b/libstdc++-v3/src/filesystem/dir.cc
index acc62986c68..215a9533f1b 100644
--- a/libstdc++-v3/src/filesystem/dir.cc
+++ b/libstdc++-v3/src/filesystem/dir.cc
@@ -202,7 +202,7 @@ recursive_directory_iterator(const path& p,
directory_options options,
   else
 {
   const int err = errno;
-  if (err == EACCES
+  if (std::filesystem::is_permission_denied_error(err)
  && is_set(options, fs::directory_options::skip_permission_denied))
{

[Bug libstdc++/99552] FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99306

--- Comment #1 from Jonathan Wakely  ---
(In reply to John David Anglin from comment #0)
> FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)
> Excess errors:
> /test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.
> cc:64: warning: alignment (64) for _ZZNSt8__detail9__waiters6_S_forEPKvE3__w
> exceeds maximum alignment for global common data.  Using 32

See also PR 99306

> Usually, I add "-fno-common" to avoid these warnings on hppa*-*-hpux*.

Isn't that redundant for C++, and on by default for C in GCC 11 anyway?

[Bug c++/99536] unexplained warning on "uninitialized value" in std::normal_distribution

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/99550] ICE (segfault) on arm with -std=c++2a

[delleyves at gmx dot ch via Gcc-bugs]

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

--- Comment #1 from Yves Delley  ---
See https://godbolt.org/z/ErEh55 
Bug also submitted at https://bugs.launchpad.net/gcc-arm-embedded/+bug/1918693
Which is the right tracker for this?

[Bug c++/99546] Weird return value of C++20 requires expression

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|accepts-invalid |wrong-code

--- Comment #3 from Jonathan Wakely  ---
My mistake, the requires-expression is valid, so it is just a wrong-code big as
you originally said.

[Bug libstdc++/99552] FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2021-03-11 10:08 a.m., redi at gcc dot gnu.org wrote:
>> Usually, I add "-fno-common" to avoid these warnings on hppa*-*-hpux*.
> Isn't that redundant for C++, and on by default for C in GCC 11 anyway?
You are correct - it doesn't work to suppress warning.  However,
ASM_OUTPUT_ALIGNED_COMMON
is still being used.

[Bug libstdc++/99552] FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2021-03-11 10:08 a.m., redi at gcc dot gnu.org wrote:
>> FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)
>> Excess errors:
>> /test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.
>> cc:64: warning: alignment (64) for _ZZNSt8__detail9__waiters6_S_forEPKvE3__w
>> exceeds maximum alignment for global common data.  Using 32
> See also PR 99306
Cache line alignment is variable on hppa and it can be up to 128.  The maximum
alignment for global common data
is smaller than the cache line alignment on some machines.

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

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 99553
   Summary: libgo/misc/cgo/testcarchive/testdata/main_unix.c:39:
suspicious compare ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dcb314 at hotmail dot com
CC: cmang at google dot com
  Target Milestone: ---

Static analyzer cppcheck says 

trunk.git/libgo/misc/cgo/testcarchive/testdata/main_unix.c:39:22: warning:
String literal compared with variable 'getenv("GCCGO")'. Did you intend to use
strcmp() instead? [literalWithCharPtrCompare]

Source code is

if (getenv("GCCGO") == "" && (osa.sa_flags&SA_ONSTACK) == 0) {

[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section

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

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

--- Comment #3 from Mark Wielaard  ---
So gcc/dwarf2out.c creates it as:

#define DEBUG_STR_SECTION_FLAGS \
  (HAVE_GAS_SHF_MERGE && flag_merge_debug_strings   \
   ? SECTION_DEBUG | SECTION_MERGE | SECTION_STRINGS | 1\
   : SECTION_DEBUG)

debug_line_str_section = get_section (DEBUG_LINE_STR_SECTION,
  DEBUG_STR_SECTION_FLAGS, NULL);

And gas/dwarf2dbg.c sets the flags as:

  bfd_set_section_flags (line_str_seg,
 SEC_READONLY | SEC_DEBUGGING | SEC_OCTETS
 | SEC_MERGE | SEC_STRINGS);

I hope that results in the same section type/flags set. But you should probably
check because MIPS has some special cases.

[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section

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

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

--- Comment #4 from Jakub Jelinek  ---
Guess we can try what happens when using -fno-merge-debug-strings with recent
binutils...

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Macieira  ---
(In reply to H.J. Lu from comment #3)
> Created attachment 50366 [details]
> A patch
> 
> I am testing this.

The same string pattern for loading from the GOT exists elsewhere in the file.
Maybe this is an opportunity to merge them into a common function?

[Bug fortran/99545] [11 Regression] ICE in gfc_trans_assignment since r11-6253-gce8dcc9105cbd404

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11 Regression] ICE in  |[11 Regression] ICE in
   |gfc_trans_assignment|gfc_trans_assignment since
   ||r11-6253-gce8dcc9105cbd404
 CC||pault at gcc dot gnu.org

--- Comment #8 from Martin Liška  ---
Started with r11-6253-gce8dcc9105cbd404.

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #5 from Thiago Macieira  ---
(In reply to Thiago Macieira from comment #1)
> Matching Clang/LLVM bug report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99530

Bad copy & paste. That's https://bugs.llvm.org/show_bug.cgi?id=49525

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #6 from Thiago Macieira  ---
(In reply to H.J. Lu from comment #3)
> Created attachment 50366 [details]
> A patch
> 
> I am testing this.

This has now changed to:

$ ~/dev/gcc/bin/gcc -fPIC -fno-plt -S -o - -O2 test.c | grep call
callf@GOTPCREL(%rip)
call*f@GOTPCREL(%rip)

The * is missing for indirect calls in AT&T syntax. Intel syntax looks correct:

$ ~/dev/gcc/bin/gcc -masm=intel -fPIC -fno-plt -S -o - -O2 test.c | grep call
call[QWORD PTR f@GOTPCREL[rip]]
call[QWORD PTR f@GOTPCREL[rip]]

[Bug libstdc++/99552] FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)

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

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

--- Comment #4 from Jonathan Wakely  ---
That's useful to know, thanks.

The current header-based implementation is experimental and those aligned
objects will be moved into the library at some point, where we can probably
control their placement and alignment more precisely.

In the meantime, I think we want a macro in config/os/*/os_defines.h that says
whether we should try to over-align them. If we don't do it, performance will
suffer because of false sharing, but it won't affect correctness.