[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC

[i at maskray dot me via Gcc-bugs]

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

--- Comment #5 from Fangrui Song  ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Fangrui Song from comment #3)
> > Are you happy with the option name -f[no-]direct-access-external-data ?
> 
> Not at all, no :-(
> 
> The name does not explain its purpose at all, and the whole concept only
> makes sense for a fraction of all targets.

> A -mcopy-relocs ("generate copy
> relocations if that is a good idea"), defined *per target*, would be a lot
> better, or a -mpic-use-copy-relocs (since you say it is *not* just for pie),
> or something like that.

Please read my first comment why copy relocs is a bad name. The compiler
behavior is whether the external data symbol is accessed directly/indirectly.
Copy relocs is just the inferred ELF linker behavior (in -no-pie/-pie link
mode) when the symbol is external. The option name should mention the direct
behavior, instead of the inferred behavior at the linking stage.

-fdirect-access-external-data makes sense on other binary formats, though I
won't ask GCC to
implement relevant behaviors for other binary formats.

* For example, on COFF, the behavior is like always
-fdirect-access-external-data.  __declspec(dllimport) is needed to use indirect
access.
* On Mach-O, the behavior is like -fdirect-access-external-data for -fno-pic
(only available on arm) and the opposite for -fpic.

If you don't want to think of non-ELF, feel free to make the option specific to
ELF.
Also feel free to make it specific to -fno-pic/-fpie (disallowed for -fpic).
I have no plan to implement Clang -fdirect-access-external-data for -fpic as
well.

> You want to have this a generic option, while it is
> not clear at all what it would mean, what it would *do*, which is especially
> important if you want this to be an option used by multiple compilers: if it
> is not clear to every user what simple, sensible thing a flag is the knob
> for, that flag simply cannot be used at all -- or worse, some users *will*
> use it, but then their intentions are not clear to humans, and different
> compilers can (and will!) think the user wanted something else!

To be clear, GCC botched things with the inappropriate HAVE_LD_PIE_COPYRELOC
and I made the proposal to (1) let non-x86-64 leverage the missing optimization
for -pie (2) eventually fix the x86-64 STV_PROTECTED story.
I have considered all the potential simplification of internal representations
for Clang this option will enable.
(llvm/lib/Target/TargetMachine.cpp shouldAssumeDSOLocal can be further
simplified with this option)

[Bug fortran/98454] Apparent wrong initialization in function result

[mscfd at gmx dot net via Gcc-bugs]

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

martin  changed:

   What|Removed |Added

 CC||mscfd at gmx dot net

--- Comment #9 from martin  ---
Problems with default initialisation of function result were fixed with
PR45489. The relevant testcase added by this PR is initialization_27.f90 which
looks very similar to the reported problem (minus the non-initialised
components).

After playing around a little bit I think the reason why initialization_27.f90
does not fail in contrast to the reported case (with only unit=-1 as component
so as to get valid fortran) is that it has a pointer component. Change t_test
to something like

type :: t_test
  integer :: unit = -1
  integer, pointer :: p => null()
end type

and unit gets properly initialised. Without the pointer component I get bogus
results.

[Bug fortran/98454] Apparent wrong initialization in function result

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to martin from comment #9)
> Problems with default initialisation of function result were fixed with
> PR45489. The relevant testcase added by this PR is initialization_27.f90
> which looks very similar to the reported problem (minus the non-initialised
> components).

Maybe they were addressed, but not fixed.

A further reduced testcase for the present problem:

program p
  implicit none
  type t
integer :: unit = -1
  end type t
  type(t) :: x
  x = g()
  if (x% unit /= -1) stop 2
  x = f()
  if (x% unit /= -1) stop 3
contains
  function f()
type(t) :: f
  end function f
  function g()
type(t) :: g
if (g% unit /= -1) stop 1
  end function g
end

The program fails with

STOP 3

Looking into the tree-dump shows that g() is fine, f() is not.

Thanks for the pointer to PR45489, which may provide a starting point.

[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC

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

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

--- Comment #6 from Segher Boessenkool  ---
(In reply to Fangrui Song from comment #5)
> Please read my first comment why copy relocs is a bad name.

Since I reply to some of that (namely, your argument 1)), you could assume I
have read your comment already ;-)

> The compiler
> behavior is whether the external data symbol is accessed
> directly/indirectly.

Not really, no.  It isn't clear at all what "directly" even means!

> Copy relocs is just the inferred ELF linker behavior
> (in -no-pie/-pie link mode) when the symbol is external. The option name
> should mention the direct behavior, instead of the inferred behavior at the
> linking stage.

Yes.  But your proposed solution just makes this worse :-(

> -fdirect-access-external-data makes sense on other binary formats, though I
> won't ask GCC to
> implement relevant behaviors for other binary formats.

But what does that *mean*?  "direct access"?  (And, "external data", for that
matter!  This isn't as obvious as it was thirty years ago.)

> * For example, on COFF, the behavior is like always
> -fdirect-access-external-data.  __declspec(dllimport) is needed to use
> indirect access.

I don't know what "declspec" is.  Something something mswindows?

> * On Mach-O, the behavior is like -fdirect-access-external-data for -fno-pic
> (only available on arm) and the opposite for -fpic.

So what you want is that object that are globally visible will be implemented
as-is?  For if you do not do whole-program optimisation, for example?  So that
a) those objects will actually *exist*, and b) they will be laid out in the way
the program expects?

> If you don't want to think of non-ELF, feel free to make the option specific
> to ELF.

The problem is not that I don't want to think about it, but that the way it
seems to be defined only applies to ELF (and to some specific (sub-)targets
using ELF, even).

> > You want to have this a generic option, while it is
> > not clear at all what it would mean, what it would *do*, which is especially
> > important if you want this to be an option used by multiple compilers: if it
> > is not clear to every user what simple, sensible thing a flag is the knob
> > for, that flag simply cannot be used at all -- or worse, some users *will*
> > use it, but then their intentions are not clear to humans, and different
> > compilers can (and will!) think the user wanted something else!
> 
> To be clear, GCC botched things with the inappropriate HAVE_LD_PIE_COPYRELOC

Huh?  That isn't a user-visible thing at all, it's an implementation detail.
It is a quite straight-forward auto thing, defined to true if the loader
passes some specific test.

- o - o -

So, what you want is to attach the attribute ((used)) variable attribute to all
data (or at least the data not explicitly made static) automatically?

[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11

[doko at debian dot org via Gcc-bugs]

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

--- Comment #14 from Matthias Klose  ---
[...]
/tmp/ccQFzQVM.s:1082:2: error: changed section flags for .rodata.cst8,
expected:
0x12
.section.rodata.cst8
^
/tmp/ccQFzQVM.s:1082:2: error: changed section entsize for .rodata.cst8,
expected: 8
.section.rodata.cst8
^
make[10]: *** [Makefile:980: lib_a-wcstod.o] Error 1

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #1 from martin  ---
Created attachment 49846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49846&action=edit
corrected patch

Comparison with c was wrong.

[Bug c++/98451] Re-exporting iostream

[patrick.kox at commandoregel dot be via Gcc-bugs]

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

Patrick Kox  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Kox  ---
I just tested this again with the new snapshot (20201227) and the iostream
module compiled correctly with this version.

[Bug c/98460] New: _builtin_cpu_supports("sha") missing

[felix-gcc at fefe dot de via Gcc-bugs]

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

Bug ID: 98460
   Summary: _builtin_cpu_supports("sha") missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

gcc offers a useful builtin around the cpuid instruction on x86 and x86_64,
which can be used to check for specific instruction set extensions, e.g.

  if (_builtin_cpu_supports("avx2"))

I need to check for the SHA-NI extension, which does not appear to be
supported.
However, checking for AES-NI is supported with the string "aes".

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #2 from martin  ---
I further tried to find out what the call to find_symbol (this is the call
which consumed the compilation time) is achieving in read_modules(). Even with
the accidentially wrong patch everything just seems to work (and I have lots of
generic interfaces and submodules etc., for which there are checks in
read_modules following the call to find_symbol).

With some printf's I at least checked the the corrected patch definitely finds
the symbols it is looking for. But I cannot come up with some testcase showing
that find_symbol returns the expected result in read_modules().

[Bug fortran/92976] [8 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
It is too late for 8-branch - sorry.

Closing.

Paul

[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

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

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

--- Comment #9 from Paul Thomas  ---
(In reply to markeggleston from comment #8)
> As noted by Tobias:
> 
>   Patch was submitted
> at https://gcc.gnu.org/pipermail/fortran/2020-March/054072.html
>   but the new mailing had stripped off the 'text/x-patch' MIME type back
> then.
> 
> Is the patch going to be resubmitted?

Mark & Tobias,

Yes, it will be resubmitted today.

Paul

[Bug rtl-optimization/98439] [11 Regression] ICE in final_scan_insn_1, at final.c:3096

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
I don't think this is a backend bug. The position of split pass in the pass
sequence assumes that no split candidates will be emitted after regstack, as
can be seen from the gate function of the pass_split_for_shorten_branches (aka
split5) pass:

  /* The placement of the splitting that we do for shorten_branches
 depends on whether regstack is used by the target or not.  */
#if HAVE_ATTR_length && !defined (STACK_REGS)
  return true;
#else
  return false;
#endif

However, with INSN_SCHEDULING, the pass_split_before_regstack (aka split4) pass
gets moved before sched2 pass as the pass_data_split_before_sched2 (aka
split3). The assumption here is that sched2 pass won't emit split candidates,
which is apparently not true with -fselective-scheduling2.

Without STACK_REGS, these insns will be split in split5, but it looks to me
that for STACK_REGS targets, split4 pass has to be run when
flag_selective_scheduling2 is in effect.

[Bug c++/98423] The defaulted default constructor defined as deleted when one of variant member has a default member initializer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think it isn't solely about the process_subob_fn
  if (TREE_CODE (arg) == FIELD_DECL
  && TREE_CODE (DECL_CONTEXT (arg)) == UNION_TYPE)
{
  if (deleted_p)
*deleted_p = true;
  if (diag)
error ("union member %q+D with non-trivial %qD", arg, fn);
}
diagnostics that probably shouldn't be performed if the union type has nsdmi on
any member, isn't it also the:
  if (constexpr_p && !DECL_DECLARED_CONSTEXPR_P (fn))
{
  *constexpr_p = false;
  if (diag)
{
  inform (DECL_SOURCE_LOCATION (fn),
  SFK_DTOR_P (sfk)
  ? G_("defaulted destructor calls non-% %qD")
  : G_("defaulted constructor calls non-% %qD"),
  fn);
  explain_invalid_constexpr_fn (fn);
}
}
diagnostics (why would a default constructor of a union be non-constexpr just
because some variant member without nsdmi has non-constexpr default
constructor), perhaps the spec_p stuff too.
So for UNION_TYPE we probably want to search for nsdmis in another loop at the
start of walk_field_subobs and punt some tests for some special members if
there are any nsdmis.

[Bug c++/98423] The defaulted default constructor defined as deleted when one of variant member has a default member initializer

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

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

--- Comment #2 from Jakub Jelinek  ---
It is CWG2084 btw.

[Bug fortran/96102] ICE in check_host_association, at fortran/resolve.c:5994

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

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

Paul Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Paul Thomas  ---
I should have closed this one. I have too much of a backlog to be backporting
non-regressions.

Thanks for the report.

Paul

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org
  Known to fail||10.2.1, 11.0, 7.5.0, 8.4.1,
   ||9.3.1
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-12-28
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

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

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

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

Paul Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Paul Thomas  ---
Since this is not a regression, I am closing.

Thanks for the report

Paul

[Bug c++/98461] New: Suboptimal codegen for negating a movemask

[denis.yaroshevskij at gmail dot com via Gcc-bugs]

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

Bug ID: 98461
   Summary: Suboptimal codegen for negating a movemask
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.yaroshevskij at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/vK85Ma

GCC fails to see that `not` can be generated instead of vector instructions.
This comes up in generic simd code.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

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

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

--- Comment #2 from Dominique d'Humieres  ---
The test compiles if I replace

  print *, tmp

with

  print *, tmp(3,1) ! or (6,1)

but it prints

   1   2   2   3   3   4

instead of 2 or 4.

[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786

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

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

--- Comment #7 from Paul Thomas  ---
(In reply to Martin Liška from comment #6)
> (In reply to Paul Thomas from comment #5)
> > (In reply to CVS Commits from comment #4)
> > > The master branch has been updated by David Malcolm 
> > > :
> > > 
> > > https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25
> > > 
> > > commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25
> > > Author: David Malcolm 
> > > Date:   Wed Mar 4 12:10:34 2020 -0500
> > > 
> > > analyzer: add regression test for fixed ICE [PR94028]
> > > 
> > > The C++ reproducer for PR analyzer/94028 generates a similar ICE
> > > to that of the Fortran reproducer for PR analyzer/93993 and, like
> > > it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa.
> > > 
> > > This patch adds the C++ reproducer as a regression test.
> > > 
> > > gcc/testsuite/ChangeLog:
> > >   PR analyzer/94028
> > >   * g++.dg/analyzer/pr94028.C: New test.
> > 
> > FAIL: gfortran.dg/analyzer/pr93993.f90   -O  (test for excess errors)
> > Excess errors:
> > /home/pault/gitsources/gcc/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:21:
> > 0: Warning: leak of 'tm' [CWE-401] [-Wanalyzer-malloc-leak]
> > 
> > On current 10-branch. FC31/x86_64
> > 
> > Paul
> 
> @David: The test-case is still failing. Are you planning to fix it or may I
> mark it as xfail?

Hi All,

It is still failing on 10-branch.

Cheers

Paul

[Bug c++/98462] New: ICE when making iomanip module and all modules after it

[patrick.kox at commandoregel dot be via Gcc-bugs]

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

Bug ID: 98462
   Summary: ICE when making iomanip module and all modules after
it
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.kox at commandoregel dot be
  Target Milestone: ---

With the previous snapshot of gcc-11-20201220 the following command failed: g++
-fmodules-ts -std=c++20 -c -x c++-system-header iostream.

This is solved by the current version (gcc-11-20201227) but now running this
command on iomanip fails. And when it does, iostream (and other also fail).

So for example when I do it in the following order only iomanip fails:
g++ -fmodules-ts -std=c++20 -c -x c++-system-header cmath
g++ -fmodules-ts -std=c++20 -c -x c++-system-header cwchar
g++ -fmodules-ts -std=c++20 -c -x c++-system-header iostream
g++ -fmodules-ts -std=c++20 -c -x c++-system-header string
g++ -fmodules-ts -std=c++20 -c -x c++-system-header string_view
g++ -fmodules-ts -std=c++20 -c -x c++-system-header iomanip

but when I execute the command with iomanip before the others they also fail
and deleting the entire gcm.cache directory seems to solve this.

The output of the error message is:
$ Modules $ g++ -fmodules-ts -std=c++20 -c -x c++-system-header iomanip 
In file included from /opt/gcc-11/include/c++/11.0.0/bits/functexcept.h:40,
 from /opt/gcc-11/include/c++/11.0.0/bits/stl_algobase.h:60,
 from /opt/gcc-11/include/c++/11.0.0/bits/char_traits.h:39,
 from /opt/gcc-11/include/c++/11.0.0/string:40,
of module /opt/gcc-11/include/c++/11.0.0/string, imported at
/opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:40,
included from /opt/gcc-11/include/c++/11.0.0/bits/ios_base.h:41,
 from /opt/gcc-11/include/c++/11.0.0/iomanip:40:
/opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:461:11: internal compiler
error: in duplicate_decls, at cp/decl.c:2022
  461 |   __catch(...)
  |   ^~~
0x66a2ba duplicate_decls(tree_node*, tree_node*, bool, bool)
../../gcc/cp/decl.c:2022
0xa38d2e check_module_override
../../gcc/cp/name-lookup.c:3651
0xa38d2e do_pushdecl
../../gcc/cp/name-lookup.c:3774
0xa39a21 do_pushdecl
../../gcc/cp/name-lookup.c:4881
0xa39a21 do_pushdecl_with_scope
../../gcc/cp/name-lookup.c:4881
0xa39c85 pushdecl_namespace_level(tree_node*, bool)
../../gcc/cp/name-lookup.c:6245
0xa3ae94 pushdecl_top_level(tree_node*)
../../gcc/cp/name-lookup.c:8717
0x9bce22 declare_library_fn
../../gcc/cp/except.c:172
0x9bda0d do_end_catch
../../gcc/cp/except.c:254
0x9bda0d push_eh_cleanup
../../gcc/cp/except.c:270
0x9bda0d expand_start_catch_block(tree_node*)
../../gcc/cp/except.c:408
0xaf66d4 finish_handler_parms(tree_node*, tree_node*)
../../gcc/cp/semantics.c:1492
0xa7e443 cp_parser_handler
../../gcc/cp/parser.c:27086
0xa5ece7 cp_parser_handler_seq
../../gcc/cp/parser.c:27061
0xa5ece7 cp_parser_try_block
../../gcc/cp/parser.c:27015
0xa5ece7 cp_parser_statement
../../gcc/cp/parser.c:11654
0xa5ff9d cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12112
0xa60078 cp_parser_compound_statement
../../gcc/cp/parser.c:12062
0xa7fe6d cp_parser_implicitly_scoped_statement
../../gcc/cp/parser.c:13577
0xa5f754 cp_parser_selection_statement
../../gcc/cp/parser.c:12293
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

and this is the error I get when I (for example) execute the command with
iostream:
$ Modules $ g++ -fmodules-ts -std=c++20 -c -x c++-system-header iostream
In file included from /opt/gcc-11/include/c++/11.0.0/bits/functexcept.h:40,
 from /opt/gcc-11/include/c++/11.0.0/bits/stl_algobase.h:60,
 from /opt/gcc-11/include/c++/11.0.0/bits/char_traits.h:39,
 from /opt/gcc-11/include/c++/11.0.0/string:40,
of module /opt/gcc-11/include/c++/11.0.0/string, imported at
/opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:40,
included from /opt/gcc-11/include/c++/11.0.0/bits/ios_base.h:41,
 from /opt/gcc-11/include/c++/11.0.0/ios:42,
 from /opt/gcc-11/include/c++/11.0.0/ostream:38,
 from /opt/gcc-11/include/c++/11.0.0/iostream:39:
/opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:461:11: internal compiler
error: in duplicate_decls, at cp/decl.c:2022
  461 |   __catch(...)
  |   ^~~
0x66a2ba duplicate_decls(tree_node*, tree_node*, bool, bool)
../../gcc/cp/decl.c:2022
0xa38d2e check_module_override
../../gcc/cp/name-lookup.c:3651
0xa38d2e do_pushdecl
  

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

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

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Paul Thomas :

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

commit r10-9180-gc2840cf16aaa665aaac4f51345104c5766fb2406
Author: Paul Thomas 
Date:   Sun Aug 2 10:57:59 2020 +0100

This patch fixes PR96320. See the explanatory comment in the testcase.

2020-08-01  Paul Thomas  

gcc/fortran
PR target/96320
* interface.c (gfc_check_dummy_characteristics): If a module
procedure arrives with assumed shape in the interface and
deferred shape in the procedure itself, update the latter and
copy the lower bounds.

gcc/testsuite/
PR target/96320
* gfortran.dg/module_procedure_4.f90 : New test.

(cherry picked from commit a5baf71b0a5bd79923c095cf81218b8194008f60)

[Bug fortran/96100] [9/10/11 Regression] ICE in gimplify_expr, at gimplify.c:14638

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:47c1d976146913fad43688d45727d0038de174c7

commit r10-9181-g47c1d976146913fad43688d45727d0038de174c7
Author: Paul Thomas 
Date:   Thu Aug 20 18:17:59 2020 +0100

This patch fixes PRs 96100 and 96101.

2020-08-20  Paul Thomas  

gcc/fortran
PR fortran/96100
PR fortran/96101
* trans-array.c (get_array_charlen): Tidy up the evaluation of
the string length for array constructors. Avoid trailing array
references. Ensure string lengths of deferred length components
are set. For parentheses operator apply string  length to both
the primary expression and the enclosed expression.

gcc/testsuite/
PR fortran/96100
PR fortran/96101
* gfortran.dg/char_length_23.f90: New test.

(cherry picked from commit 300ef2fcc10e98359d14654be23bbb84a5d141e1)

[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:47c1d976146913fad43688d45727d0038de174c7

commit r10-9181-g47c1d976146913fad43688d45727d0038de174c7
Author: Paul Thomas 
Date:   Thu Aug 20 18:17:59 2020 +0100

This patch fixes PRs 96100 and 96101.

2020-08-20  Paul Thomas  

gcc/fortran
PR fortran/96100
PR fortran/96101
* trans-array.c (get_array_charlen): Tidy up the evaluation of
the string length for array constructors. Avoid trailing array
references. Ensure string lengths of deferred length components
are set. For parentheses operator apply string  length to both
the primary expression and the enclosed expression.

gcc/testsuite/
PR fortran/96100
PR fortran/96101
* gfortran.dg/char_length_23.f90: New test.

(cherry picked from commit 300ef2fcc10e98359d14654be23bbb84a5d141e1)

[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Paul Thomas :

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

commit r9-9136-g9db58db5b3986531475968dd383f13a3f925d7ae
Author: Paul Thomas 
Date:   Thu Aug 20 18:17:59 2020 +0100

This patch fixes PRs 96100 and 96101.

2020-08-20  Paul Thomas  

gcc/fortran
PR fortran/96100
PR fortran/96101
* trans-array.c (get_array_charlen): Tidy up the evaluation of
the string length for array constructors. Avoid trailing array
references. Ensure string lengths of deferred length components
are set. For parentheses operator apply string  length to both
the primary expression and the enclosed expression.

gcc/testsuite/
PR fortran/96100
PR fortran/96101
* gfortran.dg/char_length_23.f90: New test.

(cherry picked from commit 300ef2fcc10e98359d14654be23bbb84a5d141e1)

[Bug fortran/96100] [9/10/11 Regression] ICE in gimplify_expr, at gimplify.c:14638

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Paul Thomas :

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

commit r9-9136-g9db58db5b3986531475968dd383f13a3f925d7ae
Author: Paul Thomas 
Date:   Thu Aug 20 18:17:59 2020 +0100

This patch fixes PRs 96100 and 96101.

2020-08-20  Paul Thomas  

gcc/fortran
PR fortran/96100
PR fortran/96101
* trans-array.c (get_array_charlen): Tidy up the evaluation of
the string length for array constructors. Avoid trailing array
references. Ensure string lengths of deferred length components
are set. For parentheses operator apply string  length to both
the primary expression and the enclosed expression.

gcc/testsuite/
PR fortran/96100
PR fortran/96101
* gfortran.dg/char_length_23.f90: New test.

(cherry picked from commit 300ef2fcc10e98359d14654be23bbb84a5d141e1)

[Bug c++/98463] New: [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Bug ID: 98463
   Summary: [11 Regression] internal compiler error: in
output_constructor_regular_field, at varasm.c:5491
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

The following C++ code fails to compile with gcc trunk but works on gcc 9 and
10 (tested on compiler explorer):


#include 

struct A
{
std::unique_ptr _member;

virtual ~A(){}
};

A a;


Compiled without any CXXFLAGS on x64 Linux. Compiler explorer shows:

:10:4: internal compiler error: in output_constructor_regular_field, at
varasm.c:5491
   10 | A a;
  |^
0x1cba449 internal_error(char const*, ...)
???:0
0x6b0031 fancy_abort(char const*, int, char const*)
???:0
0x13ceaf3 assemble_variable(tree_node*, int, int, int)
???:0
0xb4207f symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

Cheers,
Romain

[Bug fortran/98454] Apparent wrong initialization in function result

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
The following hack fixes the testcase in comment#10,
but not the testcase in comment#2:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 249f402b8d9..2c9570d4641 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -16046,6 +16046,9 @@ resolve_symbol (gfc_symbol *sym)
/* Mark the result symbol to be referenced, when it has allocatable
   components.  */
sym->result->attr.referenced = 1;
+
+  if (a->function && sym->result && sym->result->attr.referenced)
+   apply_default_init (sym);
 }

   if (sym->ts.type == BT_CLASS && sym->ns == gfc_current_ns


The logic in resolve_symbol checking for the necessity of
default initialization is hard to parse.  Could need some guidance...

[Bug c++/98450] Inconsistent Wunused-variable warning for std::array

[maic23 at live dot de via Gcc-bugs]

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

--- Comment #1 from maic  ---
As a temporary workaround to suppress the erroneous warning, `auto` can be
used:

$ cat /tmp/c.cpp
#include 
static constexpr auto bay = std::array{9};
static constexpr std::array bax{9};

[Bug target/98460] _builtin_cpu_supports("sha") missing

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

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

H.J. Lu  changed:

   What|Removed |Added

Version|unknown |10.2.1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from H.J. Lu  ---
Fixed in GCC 11 by r11-1629:


[hjl@gnu-tgl-2 tmp]$ cat x.c

#include 

int
main ()
{
  if (__builtin_cpu_supports("sha"))
printf ("SHA\n");
  return 0;
}
[hjl@gnu-tgl-2 tmp]$ gcc x.c
x.c: In function ‘main’:
x.c:6:3: error: parameter to builtin not valid: sha
6 |   if (__builtin_cpu_supports("sha"))
  |   ^~
[hjl@gnu-tgl-2 tmp]$ /usr/gcc-11.0.0-x32/bin/gcc x.c
[hjl@gnu-tgl-2 tmp]$ ./a.out 
SHA
[hjl@gnu-tgl-2 tmp]$

[Bug c++/98461] Suboptimal codegen for negating a movemask

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Version|unknown |10.2.0
 Target||i386,x86-64
 CC||crazylht at gmail dot com,
   ||hjl.tools at gmail dot com
   Last reconfirmed||2020-12-28

[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #8 from Paul Thomas  ---
Fixed on 9-11 branches.

Thanks for the report

Paul

[Bug fortran/96100] [9/10/11 Regression] ICE in gimplify_expr, at gimplify.c:14638

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

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

Paul Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Paul Thomas  ---
Fixed on 9-11 branches.

Thanks for the report

Paul

[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC

[i at maskray dot me via Gcc-bugs]

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

--- Comment #7 from Fangrui Song  ---
(In reply to Segher Boessenkool from comment #6)
> (In reply to Fangrui Song from comment #5)
> > Please read my first comment why copy relocs is a bad name.
> 
> Since I reply to some of that (namely, your argument 1)), you could assume I
> have read your comment already ;-)
> 
> > The compiler
> > behavior is whether the external data symbol is accessed
> > directly/indirectly.
> 
> Not really, no.  It isn't clear at all what "directly" even means!

> > Copy relocs is just the inferred ELF linker behavior
> > (in -no-pie/-pie link mode) when the symbol is external. The option name
> > should mention the direct behavior, instead of the inferred behavior at the
> > linking stage.
> 
> Yes.  But your proposed solution just makes this worse :-(

I try to use one term to describe absolute/PC-relative relocation types (e.g.
R_X86_64_64, R_X86_64_PC32)...
"Indirect" means GOT-generating relocation types and (PowerPC64) TOC-generating
relocation types.

"direct/indirect" are more descriptive and more accurate than "copy relocs"
(which is not the case if the symbol turns out to be defined locally; this term
does not apply to other binary formats).

> > -fdirect-access-external-data makes sense on other binary formats, though I
> > won't ask GCC to
> > implement relevant behaviors for other binary formats.
> 
> But what does that *mean*?  "direct access"?  (And, "external data", for that
> matter!  This isn't as obvious as it was thirty years ago.)

In PowerPC64 ELF v2, the term "GOT-indirect addressing" is used,
In x86-64 psABI, there is a section "Indirect Call via the GOT Slot".
Indirect calls/jumps are pretty common - so it is understood that GOT
relocation types generally mean "indirect".

"external data" is the best term I find for things like `extern int var;`
It means the data symbol is undefined in the current translation unit but may
be defined
in another translation unit or another linked unit.

> > * For example, on COFF, the behavior is like always
> > -fdirect-access-external-data.  __declspec(dllimport) is needed to use
> > indirect access.
> 
> I don't know what "declspec" is.  Something something mswindows?

Yes. `extern int var; int foo() { return var; }` compiles to `movl var(%rip),
%eax` (a "direct access" (PC-relative) relocation type).
Its behavior is like always -fdirect-access-external-data.
__declspec(dllimport) annotation can override the command line option.

> > * On Mach-O, the behavior is like -fdirect-access-external-data for -fno-pic
> > (only available on arm) and the opposite for -fpic.
> 
> So what you want is that object that are globally visible will be implemented
> as-is?  For if you do not do whole-program optimisation, for example?  So
> that
> a) those objects will actually *exist*, and b) they will be laid out in the
> way
> the program expects?

Undefined global objects and address-taken functions in the current translation
unit are affected.
A function taken address is very like a data symbol:

```
// gcc -fno-pic generates an absolute relocation type. If foo is defined in a
DSO,
// it will require a "canonical PLT entry" (st_shndx=0, st_value!=0) - a hack
agreed by the linker and ld.so
extern void foo();
void *addr() { return foo; }
```

The default ELF behavior on most architectures is: -fno-pic uses an absolute
relocation type while (non-x86-64) -fpie uses a GOT-generating relocation type
(x86-64) -fpie uses PC-relative.

If -fno-direct-access-external-data is specified, -fno-pic/-fpie will use
GOT-generating relocation types
to prevent
* copy relocations if the symbol turns out to be undefined in the module.
* canonical PLT entry for an address-taken function.

The proposed option is local to a translation unit (like most options).
However, if this information is recorded in LTO IR files, the optimizer can
assume the variable can be referenced via a direct relocation type in the
combined IR file.

> > If you don't want to think of non-ELF, feel free to make the option specific
> > to ELF.
> 
> The problem is not that I don't want to think about it, but that the way it
> seems to be defined only applies to ELF (and to some specific (sub-)targets
> using ELF, even).

As I mentioned earlier, this applies to other binary formats.  I'll just show
you evidence by pointing you directly to the code ;-)

In LLVM, generally speaking, a dso_local undefined global object is accessed
directly while a non-dso_local undefined global object is accessed via GOT
indirection.

In Clang, dso_local annotation is added in
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenModule.cpp#L913-L988
(The internal abstraction is currently a bit unfortunate. LLVM IR has another
set of rules (many are duplicated)
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/TargetMachine.cpp#L94-L178
I intend to eventually clean up the LLVM IR side rules)
(Attributes generally supersede 

[Bug tree-optimization/98464] New: [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nop_conversion_p, at tree.c:12825

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 98464
   Summary: [11 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
tree_nop_conversion_p, at tree.c:12825
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 49847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49847&action=edit
Testcase

gcc-11.0.0-alpha20201220 snapshot (g:18e86fae2a14f78e70aae06afce6bb9853068bb1)
ICEs when compiling the attached testcase, partially reduced from
test/std/containers/sequences/vector/vector.modifiers/insert_iter_rvalue.pass.cpp
from the libcxx 11.0.0 testsuite, w/ -O3 -fno-tree-dce:

% g++-11.0.0 -O3 -fno-tree-dce -c w93faca0.cpp
during GIMPLE pass: fre
w93faca0.cpp: In function 'int main()':
w93faca0.cpp:144:10: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in tree_nop_conversion_p, at
tree.c:12825
  144 |  int main() {
  |  ^~~~
0x807515 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree.c:9860
0x80c768 tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree.h:3717
0x80c768 tree_nop_conversion_p(tree_node const*, tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree.c:12825
0x16bfdf3 tree_nop_convert(tree_node*, tree_node**)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/build/gcc/generic-match.c:20
0x16dded3 generic_simplify_MINUS_EXPR
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/build/gcc/generic-match.c:29343
0xd7e350 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/fold-const.c:10756
0xd9f504 fold(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/fold-const.c:13327
0x122116f simplify_replace_tree(tree_node*, tree_node*, tree_node*, tree_node*
(*)(tree_node*, void*), void*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-ssa-loop-niter.c:1970
0x122116f simplify_replace_tree(tree_node*, tree_node*, tree_node*, tree_node*
(*)(tree_node*, void*), void*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-ssa-loop-niter.c:1970
0x1222167 substitute_in_loop_info(loop*, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-ssa-loop-niter.c:4997
0x10fb8b8 replace_uses_by(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-cfg.c:2028
0x10fbc0f gimple_merge_blocks
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-cfg.c:2095
0xc26b1f merge_blocks(basic_block_def*, basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cfghooks.c:803
0x110c691 cleanup_tree_cfg_bb
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-cfgcleanup.c:774
0x110cd58 cleanup_tree_cfg_noloop
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-cfgcleanup.c:1103
0x110cd58 cleanup_tree_cfg(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/tree-cfgcleanup.c:1187
0xfe0534 execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/passes.c:2008
0xfe0e6b execute_todo
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/passes.c:2096

[Bug middle-end/98465] New: Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Bug ID: 98465
   Summary: Bogus warning stringop-overread wuth -std=gnu++20 -O2
and std::string::insert
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

The following C++ code compiled with -std=gnu++20 -O2 -Werror=stringop-overread
emits a bogus warning/error with gcc trunk, while it works without problem when
using gnu++17 instead. Tested on compiler explorer on x64 Linux:

#include 

const char constantString[] = {42, 53};

void f(std::string& s)
{
s.insert(0, static_cast(constantString), 2);
}



In file included from
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/string:40,
 from :1:
In static member function 'static constexpr std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*, const
char_type*, std::size_t)',
inlined from 'static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:351:21,
inlined from 'static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:346:7,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_replace(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, const _CharT*, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.tcc:481:20,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::replace(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, const _CharT*, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:1946:19,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/basic_string.h:1693:29,
inlined from 'void f(std::string&)' at :7:60:
/opt/compiler-explorer/gcc-trunk-20201228/include/c++/11.0.0/bits/char_traits.h:402:56:
error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' reading
2 bytes from a region of size 0 [-Werror=stringop-overread]
  402 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
  |   
^
: In function 'void f(std::string&)':
:3:12: note: at offset 2 into source object 'constantString' of size 2
3 | const char constantString[] = {42, 53};
  |^~
cc1plus: some warnings being treated as errors
Compiler returned: 1


Note that gcc 10 doesn't issue any warning even with -Wall -Wextra with
gnu++20.

Cheers,
Romain

[Bug tree-optimization/98464] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nop_conversion_p, at tree.c:12825 by r11-4637

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

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[11 Regression] ICE: tree   |[11 Regression] ICE: tree
   |check: expected class   |check: expected class
   |'type', have 'exceptional'  |'type', have 'exceptional'
   |(error_mark) in |(error_mark) in
   |tree_nop_conversion_p, at   |tree_nop_conversion_p, at
   |tree.c:12825|tree.c:12825 by r11-4637
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org
   Last reconfirmed||2020-12-28

--- Comment #1 from H.J. Lu  ---
It is caused by r11-4637.

[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-12-28
 Status|UNCONFIRMED |NEW
Summary|[11 Regression] internal|[11 Regression] internal
   |compiler error: in  |compiler error: in
   |output_constructor_regular_ |output_constructor_regular_
   |field, at varasm.c:5491 |field, at varasm.c:5491 by
   ||r11-2720
 CC||jwakely.gcc at gmail dot com

--- Comment #1 from H.J. Lu  ---
This is triggered by r11-2720.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c  (revision 1050250)
+++ gcc/fortran/simplify.c  (working copy)
@@ -6728,13 +6731,18 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shap
   bool zerosize = false;

   /* Check that argument expression types are OK.  */
-  if (!is_constant_array_expr (source)
-  || !is_constant_array_expr (shape_exp)
-  || !is_constant_array_expr (pad)
-  || !is_constant_array_expr (order_exp))
-return NULL;
+  if (!is_constant_array_expr (source))
+{
+  if (gfc_init_expr_flag && !gfc_reduce_init_expr (source))
+ return NULL;
+}

   if (source->shape == NULL)
+return NULL;
+
+  if (!is_constant_array_expr (shape_exp)
+  || !is_constant_array_expr (pad)
+  || !is_constant_array_expr (order_exp))
 return NULL;

   /* Proceed with simplification, unpacking the array.  */

[Bug libstdc++/98456] Use of std::get instead of get

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
  Component|c++ |libstdc++

--- Comment #1 from Jonathan Wakely  ---
(In reply to moub.ahmed from comment #0)
> This uses std::get :
> 
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/
> ranges#L3050
> 
> Whereas the standard uses get:
> 
> https://eel.is/c++draft/range.elements#view

But when it says "get" it means "::std::get", see
https://eel.is/c++draft/contents#3

std::get is not a customization point.

[Bug libstdc++/98466] New: Iterators for unordered containers do not

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

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

Bug ID: 98466
   Summary: Iterators for unordered containers do not
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#define _GLIBCXX_DEBUG 1
#include 

int main()
{
  std::unordered_set::iterator it{};
  it == it;
}

This aborts at runtime:

/home/jwakely/gcc/11/include/c++/11.0.0/debug/safe_iterator.h:461:
In function:
bool __gnu_debug::operator==(const _Self&, const _Self&)

Error: attempt to compare a singular iterator to a singular iterator.

Objects involved in the operation:
iterator "__lhs" @ 0x0x7ffc0e6d5940 {
  type = std::__detail::_Node_iterator (mutable
iterator);
  state = singular;
}
iterator "__rhs" @ 0x0x7ffc0e6d5940 {
  type = std::__detail::_Node_iterator (mutable
iterator);
  state = singular;
}
Aborted (core dumped)


It seems that https://wg21.link/n3644 was not implemented for the debug mode
iterators.

[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720

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

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

--- Comment #2 from Jonathan Wakely  ---
That just exposes a latent compiler bug though.

Slightly reduced:

#include 

struct empty { };

struct A
{
std::tuple _member;

virtual ~A(){}
};

A a;

[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Keywords||diagnostic,
   ||missed-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Blocks||97048
   Last reconfirmed||2020-12-28
  Known to fail||10.2.0, 11.0

--- Comment #1 from Martin Sebor  ---
I'm not sure why I don't see the warning for the test case in my build but I
can reproduce it (as well as a -Warray-bounds) by compiling the translation
unit obtained from the test case and with system header markers removed with
either GCC 10 or 11:

$ g++ -O2 -S -Wall -std=gnu++20 pr98465.C
pr98465.C: In function ‘void f(std::string&)’:
pr98465.C:22316:20: warning: offset ‘2’ outside bounds of constant string
[-Warray-bounds]
22316 |   this->_S_copy(__p, __s + __len2 - __len1, __len2);
  |   ~^~~~
pr98465.C:22843:12: note: ‘constantString’ declared here
22843 | const char constantString[] = {42, 53};
  |^~
In static member function ‘static constexpr std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*, const
char_type*, std::size_t)’,
inlined from ‘void f(std::string&)’ at pr98465.C:19983:21:
pr98465.C:9051:49: warning: ‘void* __builtin_memcpy(void*, const void*, long
unsigned int)’ reading 2 bytes from a region of size 0 [-Wstringop-overread]
 9051 |  return static_cast(__builtin_memcpy(__s1, __s2, __n));
  | ^
pr98465.C: In function ‘void f(std::string&)’:
pr98465.C:22843:12: note: at offset 2 into source object ‘constantString’ of
size 2
22843 | const char constantString[] = {42, 53};
  |^~

The -Warray-bounds instance comes from a call to c_strlen() made during the
ccp2 pass for the following IL:

void f (struct string & s)
{
  _14 = MEM[(const struct basic_string *)s_2(D)]._M_dataplus._M_p;
  ...
   [local count: 179779816]:
  if (_14 >= &MEM  [(void *)&constantString + 2B])
goto ; [50.00%]
  else
goto ; [50.00%]
  ...
   [local count: 44944954]:
  if (_14 <= &constantString)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 22472477]:
  __builtin_memcpy (_14, &MEM  [(void *)&constantString + 2B],
2);   <<< -Warray-bounds
  goto ; [100.00%]
  ...
}

The warning is correct: the call is invalid.  It results from the following
transformations:

Folding statement: _45 = 2 - _6;
Queued stmt for removal.  Folds to: 2
Folding statement: _46 = &constantString + _45;
Queued stmt for removal.  Folds to: &MEM  [(void
*)&constantString + 2B]
Folding statement: __builtin_memcpy (__p_18, _46, 2);
Folded into: __builtin_memcpy (_14, &MEM  [(void
*)&constantString + 2B], 2);

The invalid call survives until expansion which is when the -Wstringop-overread
is issued.  I suspect the default -Wno-system-headers setting has something to
do with the warning being masked.

In the IL above, the pointer inequalities that lead to the transformation are
the result of the call to _M_disjunct(__s) in std::string::_M_replace,
presumably done to identify and cope with self-insertion.  Since constantString
is a distinct object, the invalid call is unreachable, but without more context
GCC can't figure that out.  Annotating the std::string::_M_dataplus._M_p
pointer as one that cannot alias a declared object (other than the _M_local_buf
member) would be one way to avoid the warning (and improve the codegen at the
same time).  IIRC, I suggested something like that in the past but no nothing
has materialized yet.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
[Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings

[Bug tree-optimization/98467] New: gcc optimizes tapping code away

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 98467
   Summary: gcc optimizes tapping code away
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Consider this test case:

$ cat test.cc
struct MyClass;
struct ptr {
MyClass* get() { return t; }
MyClass* t;
};
struct MyClass { void call(); };
void MyClass::call() {
*(char*)(nullptr) = 1;
}
static void intermediate(ptr p) {
p.get()->call();
}
int main() {
intermediate(ptr{new MyClass});
}

$ g++ -g -O0 test.cc
$ ./a.out
Segmentation fault (core dumped)
$ g++ -g -Og test.cc
$ ./a.out
$ g++ -g -O1 test.cc
$ ./a.out
$ g++ -g -O2 test.cc
$ ./a.out
Segmentation fault (core dumped)
$ g++ -g -O3 test.cc
$ ./a.out
Segmentation fault (core dumped)
$ g++ -g -Ofast test.cc
$ ./a.out
Segmentation fault (core dumped)

It is somehow unexpected that this code is optimized
away only at -Og -O1, but not at very high or very low optimization levels.

I would even say although the code is of course invalid, it should
not be optimized away, as it might be a debug-code that intentionally taps.

[Bug target/98468] New: [9 regression] test case gcc.target/powerpc/rlwimi-2.c fails starting with r9-3594

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

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

Bug ID: 98468
   Summary: [9 regression] test case gcc.target/powerpc/rlwimi-2.c
fails starting with r9-3594
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:8d2d39587d941a40f25ea0144cceb677df115040, r9-3594

This may have occurred earlier but it definitely started (maybe again) here. 
It currently occurs in gcc 9, 10, and trunk though only the first one still
occurs in gcc trunk/11.


make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/rlwimi-2.c"
FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+[a-z] 20217
FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+rldicl 6728
FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+rlwimi 1692
# of expected passes4
# of unexpected failures3

[Bug tree-optimization/98467] gcc optimizes tapping code away

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This code is not invalid but undefined at runtime.  This means anything can
happen.  In this case, GCC optimizes it away.
It is better to use __builtin_trap or __builtin_abort/std::abort if you want to
get a trap going on.

[Bug c++/17314] Error message wrongly shows declared rather than inherited access

[anthonysharp15 at gmail dot com via Gcc-bugs]

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

Anthony Sharp  changed:

   What|Removed |Added

 CC||anthonysharp15 at gmail dot com

--- Comment #22 from Anthony Sharp  ---
I am currently working on a fix for this.

There seems to be three issues here. 

1. The primary issue is that in cases of private inheritance, GCC incorrectly
reports that the member is inaccessible because it is protected, when the (more
correct) reason is because it is private. This has required some re-working of
the diagnostics code.

2. The second issue (more of a discussion topic) seems to revolve around
whether virtual inheritance is private by default. A few people here have said
that it is. They might be right, but I am not sure.

3. The third issue seems to be an academic debate on the proper effect of a
virtual private inheritance. Currently, it is possible to inherit from a
private virtual base, e.g. the following code compiles:

class Foo { public: Foo(){}  ~Foo(){} };
class A:virtual private Foo { public: A(){}  ~A(){} };
class Bar:public A { public: Bar(){}  ~Bar(){} };

As Jason Merrill points out, this wasn't intended
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7). Also see
https://stackoverflow.com/questions/3900192/msvc9-0-bug-or-misunderstanding-of-virtual-inheritance-and-friends/3917482.
Apparently MSVC9 has the same quirk.

I'm not sure why the C++ standards committee would say it was intended for the
above code to be ill-formed (or that's what they seem to say). There seems to
me to be no access violation in the above code, technically speaking. Jason
Merrill says '~Bar() calls ~Foo(), which is ill-formed due to access violation,
right? (Bar's constructor has the same problem since it needs to call Foo's
constructor.)', but as far as I'm aware, constructors and destructors aren't
affected by access protection levels. It is possible for a class to derive from
a private class (e.g. see
https://stackoverflow.com/questions/30572835/c-private-class-inheritance).
Jason Merrill points out that there might be some under-the-hood issues with
the above code, and he might be right, but that's beyond my current level of
understanding.

Even if such code is ill-formed, it doesn't really bother me (and nor has it
bothered anyone else, considering this bug report was issued 16 years ago).
Virtual private inheritance is a feature that virtually (haha, get it?) no one
uses, and I think it'd be a waste of time to patch a dead feature. So, I intend
to only fix issue 1. After that, I might create a new bug report to do with 3.,
just so the issue is not buried.

Any thoughts are welcome.

[Bug tree-optimization/98464] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nop_conversion_p, at tree.c:12825 by r11-4637

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

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

Kewen Lin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin  ---
Thanks for reporting and bisecting, I'll investigate this first.

[Bug libstdc++/98456] Use of std::get instead of get

[moub.ahmed at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from moub.ahmed at hotmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to moub.ahmed from comment #0)
> > This uses std::get :
> > 
> > https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/
> > ranges#L3050
> > 
> > Whereas the standard uses get:
> > 
> > https://eel.is/c++draft/range.elements#view
> 
> But when it says "get" it means "::std::get", see
> https://eel.is/c++draft/contents#3
> 
> std::get is not a customization point.

I see. Thank you for the reply.

[Bug target/92658] x86 lacks vector extend / truncate

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #23 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #22)
> (In reply to Hongtao.liu from comment #21)
> > Add define_code_attr like aarch64/iterators.md?
> > 
> > --
> > ;; Map rtl objects to optab names
> > (define_code_attr optab [(ashift "ashl")
> >  (ashiftrt "ashr")
> >  (lshiftrt "lshr")
> >  (rotatert "rotr")
> >  (sign_extend "extend")
> >  (zero_extend "zero_extend")
> 
> Yes. Please go ahead, the patch is preapproved.

Fixed by r11-6351

[Bug c++/98461] Suboptimal codegen for negating a movemask

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
in rtl phase, gcc successfully simplify 
(and:V4DI (not:V4DI (reg:V4DI 91)) 
  (constm1_rtx)
to

(not:V4DI (reg:V4DI 91)).

But combine failed to match 

(set (reg:SI 88)
(unspec:SI [
(subreg:V32QI (not:V4DI (reg:V4DI 91)) 0)
] UNSPEC_MOVMSK))

So add combine splitter?

[Bug c++/98461] Suboptimal codegen for negating a movemask

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
> So add combine splitter?

I'm testing this patch

1 file changed, 15 insertions(+), 1 deletion(-)
gcc/config/i386/sse.md | 16 +++-

modified   gcc/config/i386/sse.md
@@ -640,7 +640,8 @@ (define_mode_attr ssedoublemode

 (define_mode_attr ssebytemode
   [(V8DI "V64QI") (V4DI "V32QI") (V2DI "V16QI")
-   (V16SI "V64QI") (V8SI "V32QI") (V4SI "V16QI")])
+   (V16SI "V64QI") (V8SI "V32QI") (V4SI "V16QI")
+   (V32HI "V64QI") (V16HI "V32QI") (V8HI "V16QI")])

 ;; All 128bit vector integer modes
 (define_mode_iterator VI_128 [V16QI V8HI V4SI V2DI])
@@ -16065,6 +16066,19 @@ (define_insn "_pmovmskb"
(set_attr "prefix" "maybe_vex")
(set_attr "mode" "SI")])

+(define_split
+  [(set (match_operand:SI 0 "register_operand")
+   (unspec:SI
+ [(subreg:
+(not:VI248_AVX2
+  (match_operand:VI248_AVX2 1 "register_operand")) 0)]
+ UNSPEC_MOVMSK))]
+  "TARGET_SSE2"
+  [(set (match_dup 0)
+   (unspec:SI [(match_dup 2)] UNSPEC_MOVMSK))
+   (set (match_dup 0) (not:SI (match_dup 0)))]
+  "operands[2] = lowpart_subreg (mode, operands[1],
mode);")
+
 (define_insn "*_pmovmskb_zext"
   [(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI

[Bug c++/98461] Suboptimal codegen for negating a movemask

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
Hi  Denis Yaroshevskiy:
Could you mark this bug as blocks PR98375 
(This metabug is used to track all the patches which have been written during 
Stage 3 of GCC 11 but do not qualify for that stage, and are waiting for Stage 
1 of GCC 12 to be applied.)

[Bug c++/98469] New: ICE in cxx_eval_constant_expression, at cp/constexpr.c:6350

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 98469
   Summary: ICE in cxx_eval_constant_expression, at
cp/constexpr.c:6350
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-11.0.0-alpha20201227 snapshot (g:9a48892bea70a1e6a82e24b882f22807b73debe7)
ICEs when compiling the following testcase, reduced from
test/CodeGenCXX/builtin-bit-cast.cpp from the clang 11.0.0 test suite, w/
-Wall:

struct ze {
  int cd;
};

ze
uu ()
{
  return __builtin_bit_cast (ze, 0);
}

% g++-11.0.0 -Wall -c czlmwkjs.cpp
czlmwkjs.cpp: In function 'ze uu()':
czlmwkjs.cpp:8:35: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:6350
8 |   return __builtin_bit_cast (ze, 0);
  |   ^
0x6275ff cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/constexpr.c:6350
0x906606 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/constexpr.c:6609
0x909f46 cxx_eval_outermost_constant_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/constexpr.c:7126
0x90e7cf maybe_constant_value(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/constexpr.c:7397
0x9a125b fold_for_warn(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/expr.c:416
0xb6a7f7 check_function_restrict
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/c-family/c-common.c:5497
0xb6a7f7 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/c-family/c-common.c:5869
0x8d4b4a build_over_call
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:9043
0x8d2af8 build_new_method_call_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:10520
0x8d769b build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:10595
0x8d769b build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:9996
0x8ce8bb build_temp
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:7189
0x8ce8bb convert_like_internal
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:7734
0x8d00c9 convert_like
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:7964
0x8d00c9 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/call.c:12042
0xb2ae98 check_return_expr(tree_node*, bool*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/typeck.c:10310
0xadaeef finish_return_stmt(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/semantics.c:1022
0xa418d6 cp_parser_jump_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/parser.c:13470
0xa418d6 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/parser.c:11639
0xa42f3d cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/parser.c:12112

[Bug c++/98332] [10/11 Regression] ICE in unshare_constructor, at cp/constexpr.c:1527 since r6-7607-g52228180f1e50cbb

[asolokha at gmx dot com via Gcc-bugs]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #5 from Arseny Solokha  ---
Should this PR be closed now, or are there other fixes pending?

[Bug target/98470] New: ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa

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

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

Bug ID: 98470
   Summary: ICE: "error: insn does not satisfy its constraints"
with hard FP on xtensa
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49848&action=edit
float-ice.c

With the following change that enables hardware floating point for the xtensa
target
--->8---
diff --git a/include/xtensa-config.h b/include/xtensa-config.h
index 58d52db0c9b3..6ea55f94dc2a 100644
--- a/include/xtensa-config.h
+++ b/include/xtensa-config.h
@@ -25,7 +25,7 @@
macros.  */

 #undef XCHAL_HAVE_BE
-#define XCHAL_HAVE_BE  1
+#define XCHAL_HAVE_BE  0

 #undef XCHAL_HAVE_DENSITY
 #define XCHAL_HAVE_DENSITY 1
@@ -85,22 +85,22 @@
 #define XCHAL_HAVE_S32C1I  1

 #undef XCHAL_HAVE_BOOLEANS
-#define XCHAL_HAVE_BOOLEANS0
+#define XCHAL_HAVE_BOOLEANS1

 #undef XCHAL_HAVE_FP
-#define XCHAL_HAVE_FP  0
+#define XCHAL_HAVE_FP  1

 #undef XCHAL_HAVE_FP_DIV
-#define XCHAL_HAVE_FP_DIV  0
+#define XCHAL_HAVE_FP_DIV  1

 #undef XCHAL_HAVE_FP_RECIP
-#define XCHAL_HAVE_FP_RECIP0
+#define XCHAL_HAVE_FP_RECIP1

 #undef XCHAL_HAVE_FP_SQRT
-#define XCHAL_HAVE_FP_SQRT 0
+#define XCHAL_HAVE_FP_SQRT 1

 #undef XCHAL_HAVE_FP_RSQRT
-#define XCHAL_HAVE_FP_RSQRT0
+#define XCHAL_HAVE_FP_RSQRT1

 #undef XCHAL_HAVE_DFP_accel
 #define XCHAL_HAVE_DFP_accel   0

--->8---
the following compiler invocation with the attached example:

cc1 -O2 float-ice.c

results in the following ICE:

float-ice.c: In function ‘d’:
float-ice.c:15:1: error: insn does not satisfy its constraints:
   15 | }
  | ^
(insn 538 168 169 32 (set (reg:SF 19 f0 [orig:71 iftmp.0_87 ] [71])
(mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"float-ice.c":11:17 45 {movsf_internal}
 (nil))
during RTL pass: postreload
float-ice.c:15:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x113e0bd _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x113e11d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0x10ecd55 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2670
0x10a1448 reload_cse_simplify_operands
../../gcc/gcc/postreload.c:407
0x10a08cd reload_cse_simplify
../../gcc/gcc/postreload.c:132
0x10a0ca8 reload_cse_regs_1
../../gcc/gcc/postreload.c:238
0x10a06c1 reload_cse_regs
../../gcc/gcc/postreload.c:66
0x10a6490 execute
../../gcc/gcc/postreload.c:2358

[Bug target/98470] ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa

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

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

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
It happens at the reload pass when reload transforms the following RTL that
comes to it from the IRA pass:

(insn 20 163 164 30 (set (reg:SF 162 [ iftmp.0_87 ])
(mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"float-ice.c":11:17 45 {movsf_internal}
 (expr_list:REG_EQUIV (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2])
[0  S4 A32])
(nil)))
...
(insn 538 168 169 32 (set (reg:SF 71 [ iftmp.0_87 ])
(reg:SF 162 [ iftmp.0_87 ])) "float-ice.c":11:17 45 {movsf_internal}
 (nil))

to the following RTL:

(insn 538 168 169 32 (set (reg:SF 19 f0 [orig:71 iftmp.0_87 ] [71])
(mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"float-ice.c":11:17 45 {movsf_internal}
 (nil))

which tries to load a literal into a hardware FP register. There's no opcode
for it in the xtensa ISA, there's no constraint that would match it in the
movsf_internal and the predicate in this instruction definition evaluates to
false on such input, but the substitution happens anyway.