[Bug tree-optimization/92788] New: [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313

[asolokha at gmx dot com]

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

Bug ID: 92788
   Summary: [10 Regression] ICE in redirect_eh_edge_1, at
tree-eh.c:2313
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, 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: ---
Target: x86_64-pc-linux-gnu

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

g++-10.0.0-alpha20191201 snapshot (r278886) ICEs when compiling the attached
testcase, reduced from
libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/53622.cc, w/
-march=k8 -O3 -fnon-call-exceptions -ftracer:

% x86_64-pc-linux-gnu-g++-10.0.0-alpha20191201 -march=k8 -O3
-fnon-call-exceptions -ftracer -w -c s0uf5lnv.cc
during GIMPLE pass: dom
s0uf5lnv.cc: In copy constructor 'std::vector<_Tp,
_Alloc>::vector(std::vector<_Tp, _Alloc>&) [with _Tp =
std::Trans_NS___cxx11_regex_traits::_RegexMask; _Alloc =
new_allocator]':
s0uf5lnv.cc:154:5: internal compiler error: in redirect_eh_edge_1, at
tree-eh.c:2313
  154 | vector(vector &__x) : _Base(0, _M_get_Tp_allocator()) {
  | ^~
0x73dcdc redirect_eh_edge_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-eh.c:2313
0xf979ea redirect_eh_edge(edge_def*, basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-eh.c:2378
0xaee9a0 redirect_edge_and_branch(edge_def*, basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/cfghooks.c:373
0x1125d54 ssa_fix_duplicate_block_edges(redirection_data*, ssa_local_info_t*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-ssa-threadupdate.c:1017
0x11282c9 ssa_fixup_template_block(redirection_data**, ssa_local_info_t*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-ssa-threadupdate.c:1246
0x11282c9 void hash_table::traverse_noresize(ssa_local_info_t*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/hash-table.h:1084
0x11282c9 void hash_table::traverse(ssa_local_info_t*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/hash-table.h:1105
0x11282c9 thread_block_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-ssa-threadupdate.c:1503
0x112990e thread_block
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-ssa-threadupdate.c:1540
0x112990e thread_through_all_blocks(bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-ssa-threadupdate.c:2652
0x1049eb7 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/tree-ssa-dom.c:775

[Bug lto/92599] ICE in speculative_call_info, at cgraph.c:1142

[luoxhu at cn dot ibm.com]

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

--- Comment #4 from Xiong Hu XS Luo  ---
(In reply to Xiong Hu XS Luo from comment #3)
> (In reply to Martin Liška from comment #2)
> > So we ICE at the end of cgraph_edge::speculative_call_info:
> > (gdb) p ref
> > $4 = 
> > 
> > (gdb) p e
> > $5 =  > "ConvertASEToModelSurfaces.constprop"/113> ->  > "NumSurfaces"/115>)>
> > (gdb) p e2
> > $6 =  > "ConvertASEToModelSurfaces.constprop"/113> -> )>
> > 
> > As seen the edge is within idRenderModelStatic class.
> > I bet the problem is the ODR warning message, the class is polymorphic in
> > one TU, and normal class in another one.
> 
> Seems side effect in indirect->set_call_stmt.
> The "ref" is changed in recursive call line "indirect->set_call_stmt
> (new_stmt, false)", it will call resolve_speculation to redirect one of it's
> polymorphic call 
> ConvertASEToModelSurfaces/2 => FindMaterial/45, ref->remove_reference will
> the related reference, then ref will be pointed to another reference, then
> the followed "ref->stmt = new_stmt" will update wrong stmt to the original
> reference.
> 
> p *ref
> $378 = {referring = 0x3fffb55f10e0, referred = 0x3fffb55f09d8, stmt =
> 0x3fffb7f71440, lto_stmt_uid = 10, referred_index = 1, use = IPA_REF_ADDR,
> speculative = 1
> 
> After returning from indirect->set_call_stmt (new_stmt, false):
> 
> p *ref
> $380 = {referring = 0x3fffb55f10e0, referred = 0x3fffb55f0ca8, stmt =
> 0x3fffb7f713b0, lto_stmt_uid = 6, referred_index = 1, use = IPA_REF_ADDR,
> speculative = 1}
> 
> (gdb) pedge direct
> $381 = 0x3fffb5560498 "ConvertASEToModelSurfaces.constprop/113"
> $382 = 0x3fffb53d78a0 "FindMaterial/116"
> (gdb) ps new_stmt
> FindMaterial (_6);
>  ps ref->stmt
> # .MEM = VDEF <.MEM>
> OBJ_TYPE_REF(_5;(struct idRenderModelStatic)this_3(D)->1) (this_3(D));
> 
> 
> How about patch candidate as below? Or check the ref->speculative is true
> after return from indirect->set_call_stmt? 

Not "ref->speculative", should be indirect->speculative as indirect edge is
removed speculative now, or lto_stmt_uid is more reliable?

(gdb) p *indirect
$385 = {count = {static n_bits = 61, static max_count = 2305843009213693950,
static uninitialized_count = 2305843009213693951, m_val = 406913472214181285,
m_quality = AFDO}, caller = 0xa5a5a5a5a5a5a5a5, callee = 0xa5a5a5a5a5a5a5a5,
prev_caller = 0xa5a5a5a5a5a5a5a5, next_caller = 0xa5a5a5a5a5a5a5a5, prev_callee
= 0xa5a5a5a5
a5a5a5a5, next_callee = 0xa5a5a5a5a5a5a5a5, call_stmt = 0xa5a5a5a5a5a5a5a5,
indirect_info = 0xa5a5a5a5a5a5a5a5, aux = 0xa5a5a5a5a5a5a5a5, inline_failed =
2779096485, lto_stmt_uid = 2779096485, indirect_inlining_edge= 1,
indirect_unknown_callee = 0, call_stmt_cannot_inline_p = 1, can_throw_external
= 0, speculative = 0, in_polymorphic_cdtor = 1, m_uid = -1515870811,
m_summary_id = -1515870811}

[Bug tree-optimization/92772] wrong code vectorizing masked max

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||amdgcn
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Blocks||53947

--- Comment #1 from Richard Biener  ---
Looks like cond-reduction cannot handle fully masked loops unless we'd somehow
mask the condition operation itself?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c/92773] GCC compilation with big array / header is infinite

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-04
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Can you please attach preprocessed source of the compilation unit that shows
the problem?

[Bug lto/92599] ICE in speculative_call_info, at cgraph.c:1142

[luoxhu at cn dot ibm.com]

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

--- Comment #3 from Xiong Hu XS Luo  ---
(In reply to Martin Liška from comment #2)
> So we ICE at the end of cgraph_edge::speculative_call_info:
> (gdb) p ref
> $4 = 
> 
> (gdb) p e
> $5 =  "ConvertASEToModelSurfaces.constprop"/113> ->  "NumSurfaces"/115>)>
> (gdb) p e2
> $6 =  "ConvertASEToModelSurfaces.constprop"/113> -> )>
> 
> As seen the edge is within idRenderModelStatic class.
> I bet the problem is the ODR warning message, the class is polymorphic in
> one TU, and normal class in another one.

Seems side effect in indirect->set_call_stmt.
The "ref" is changed in recursive call line "indirect->set_call_stmt (new_stmt,
false)", it will call resolve_speculation to redirect one of it's polymorphic
call 
ConvertASEToModelSurfaces/2 => FindMaterial/45, ref->remove_reference will the
related reference, then ref will be pointed to another reference, then the
followed "ref->stmt = new_stmt" will update wrong stmt to the original
reference.

p *ref
$378 = {referring = 0x3fffb55f10e0, referred = 0x3fffb55f09d8, stmt =
0x3fffb7f71440, lto_stmt_uid = 10, referred_index = 1, use = IPA_REF_ADDR,
speculative = 1

After returning from indirect->set_call_stmt (new_stmt, false):

p *ref
$380 = {referring = 0x3fffb55f10e0, referred = 0x3fffb55f0ca8, stmt =
0x3fffb7f713b0, lto_stmt_uid = 6, referred_index = 1, use = IPA_REF_ADDR,
speculative = 1}

(gdb) pedge direct
$381 = 0x3fffb5560498 "ConvertASEToModelSurfaces.constprop/113"
$382 = 0x3fffb53d78a0 "FindMaterial/116"
(gdb) ps new_stmt
FindMaterial (_6);
 ps ref->stmt
# .MEM = VDEF <.MEM>
OBJ_TYPE_REF(_5;(struct idRenderModelStatic)this_3(D)->1) (this_3(D));


How about patch candidate as below? Or check the ref->speculative is true after
return from indirect->set_call_stmt? 

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index b75430f3f3a..65b6f93c3fe 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -793,7 +793,8 @@ cgraph_edge::set_call_stmt (gcall *new_stmt, bool
update_speculative)
   speculative_call_info (direct, indirect, ref);
   direct->set_call_stmt (new_stmt, false);
   indirect->set_call_stmt (new_stmt, false);
-  ref->stmt = new_stmt;
+  if (ref->lto_stmt_uid == direct->lto_stmt_uid)
+   ref->stmt = new_stmt;
   return;
 }

[Bug other/92784] [10 regression] ICE when compiling g++.dg/torture/pr59226.C after r278944

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/92787] New: P0634R3 is not implemented correctly if parameter-declaration appears in a default argument

[boostcpp at gmail dot com]

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

Bug ID: 92787
   Summary: P0634R3 is not implemented correctly if
parameter-declaration appears in a default argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boostcpp at gmail dot com
  Target Milestone: ---

The lambda expression's parameter-declaration don't assume a qualified-id to
name a type if that parameter-declaration appears in a default argument.

> parameter-declaration in a lambda-declarator, unless that 
> parameter-declaration appears in a default argument, or
parameter-declaration of a (non-type) template-parameter.

template < typename T >
// lambda expression's parameter-declaration appears in a default argument
void f( typename T::type x = []( T::type x ){return x ;}( typename T::type{}) 
)
{
}

https://wandbox.org/permlink/7d2d6aqjZWOhL5Pq

But current GCC 10 head assume it to name a type.

Or am I reading the wording wrong?

[Bug c++/92786] [c++11] static constexpr member link error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
You still need a definition and not just a declaration even with constexpr. 
Though I think a newer C++ standard changed that; try -std=c++17 :)

[Bug c++/92786] [c++11] static constexpr member link error

[xavierb at gmail dot com]

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

--- Comment #1 from Xavier B  ---
additional info:
 - getting the array out of the struct works, 
 - using 'namespace' instead of 'struct' also works fine.

[Bug c++/92652] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction

[boostcpp at gmail dot com]

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

--- Comment #2 from Ryou Ezoe  ---
Yes. this is C++20 concepts .

[Bug c++/92786] New: [c++11] static constexpr member link error

[xavierb at gmail dot com]

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

Bug ID: 92786
   Summary: [c++11] static constexpr member link error
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xavierb at gmail dot com
  Target Milestone: ---

hi,

this code doesn't link:

---
struct STest {
static int GetVal(int x) {return vals[x];}
static constexpr int vals[] = { 1,2,3,4,4,4,4 };
};
int main() 
{
return STest::GetVal(1);
}
---

/usr/bin/ld: /tmp/ccqFvLiy.o: in function `STest::GetVal(int)':
bug.cpp:(.text._ZN5STest6GetValEi[_ZN5STest6GetValEi]+0x17): undefined
reference to `STest::vals'
collect2: error: ld returned 1 exit status


(seems to work fine with 
clang >= 9  (but not with version <=8),
msvc and icc )

[Bug target/92760] [10 regression] several vector test cases fail on power 7 after r278800

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #3 from Kewen Lin  ---
Fixed on trunk.

[Bug target/92760] [10 regression] several vector test cases fail on power 7 after r278800

[linkw at gcc dot gnu.org]

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

--- Comment #2 from Kewen Lin  ---
Author: linkw
Date: Wed Dec  4 05:10:46 2019
New Revision: 278955

URL: https://gcc.gnu.org/viewcvs?rev=278955=gcc=rev
Log:
[rs6000] Fix PR92760 by checking VECTOR_MEM_NONE_P instead

PR92760 exposed one issue that VECTOR_UNIT_NONE_P (V2DImode) is true on Power7
then we won't return it as preferred_simd_mode but ISA 2.06 (Power7) does
introduce partial support on vector doubleword (very limitted) and more basic
support origins from ISA 2.07 (Power8) though.  To make vectorizer still
leverage those few but available V2DImode related instructions, we need to
claim it's available on VSX (Power7 and up).

gcc/ChangeLog

PR target/92760
* gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Use
VECTOR_MEM_NONE_P instead of VECTOR_UNIT_NONE_P.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug fortran/92785] New: expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

[urbanjost at comcast dot net]

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

Bug ID: 92785
   Summary: expressions passed as real arguments to a dummy
polymorphic argument fail with indexing error
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

I thought this was a duplicate of Bug 84074 at first.  I could not
find a way to tell when a fix is applied to a release and GNU Fortran
(Ubuntu 9.2.1-17ubuntu1~18.04.1) 9.2.1 20191102 seems to have come out
after the fix for 84074 was applied?

Is there a field somewhere I am missing that would tell at what release
a fix becomes available?

Anyway, I took the code from Bug 84074 and compiled it and it ran OK
so I now assume this is a similar but distinct bug:

TEST PROGRAM

   program tst
  use iso_fortran_env, only : compiler_version, compiler_options
  implicit none
  integer :: i
  integer :: ibad=0
  integer :: iarr(10)=[(i*10,i=1,size(iarr))]
  character(len=:),allocatable :: line
  character(len=*),parameter :: expected= '10 20 30 40 50 60 70 80 90 100'
  print '(4a)', &
 'This file was compiled by ', compiler_version(), &
 ' using the options ',compiler_options()
  call write_row('iarr   ',iarr)   ! pass in the array, OK
  call write_row('iarr+0 ',iarr+0) ! pass in an expression,
SHIFTED(?)
  call write_row('-iarr  ',-iarr)  ! pass in an expression,
SHIFTED(?)
  call write_row('iarr(::1)  ',iarr(::1))
  call write_row('[iarr(::1)]',[iarr(::1)])
  call write_row('[(i*10,i=1,size(iarr))]',[(i*10,i=1,size(iarr))])
  call write_row('10*[(i,i=1,size(iarr))]',10*[(i,i=1,size(iarr))])
  if(ibad.gt.0)stop 'FAILED'
   contains
  subroutine write_scalar(g1)
 class(*) :: g1
 character(len=20) :: word
 select type(g1)
  type is (integer)
write(word,'(i0)') g1
line=line//trim(word)//' '
 end select
  end subroutine write_scalar
  subroutine write_row(string,array )
 character(len=*) :: string
 class(*) :: array(:)
 integer  :: i
 line=''
 do i = 1,size(array)
call write_scalar( array(i) )
 enddo
 if(expected.eq.line)then
write(*,*)string,':GOOD'
 else
write(*,*)string,':BAD. EXPECTED [',expected,'] got
[',trim(line),']'
ibad=ibad+1
 endif
  end subroutine write_row
   end program tst

OUTPUTS

 GIVES BAD ANSWERS WITHOUT BOUNDS CHECK


   This file was compiled by GCC version 9.2.1 20191102 using the options
-mtune=generic -march=x86-64 -Wall -Wextra -fno-strict-aliasing -fwrapv
iarr   :GOOD
iarr+0 :BAD. EXPECTED [10 20 30 40 50 60 70 80 90 100] got
[20 30 40 50 60 70 80 90 100 335544320]
-iarr  :BAD. EXPECTED [10 20 30 40 50 60 70 80 90 100] got
[-20 -30 -40 -50 -60 -70 -80 -90 -100 335544320]
iarr(::1)  :GOOD
[iarr(::1)]:BAD. EXPECTED [10 20 30 40 50 60 70 80 90 100] got
[20 30 40 50 60 70 80 90 100 8064]
[(i*10,i=1,size(iarr))]:GOOD
10*[(i,i=1,size(iarr))]:GOOD
   This file was compiled by GCC version 9.2.1 20191102 using the options
-mtune=generic -march=x86-64 -g0 -Wall -Wextra -fbacktrace -fno-strict-aliasing
-fwrapv -fbounds-check
iarr   :GOOD
   STOP FAILED

 FAILS WITH BOUNDS CHECK

   At line 36 of file xx.f90
   Fortran runtime error: Index '10' of dimension 1 of array 'array%_data'
above upper bound of 9

   Error termination. Backtrace:
   #0  0x7fab5f57f74a
   #1  0x7fab5f580235
   #2  0x7fab5f580712
   #3  0x7fab5fe0190d
   #4  0x7fab5fe00f58
   #5  0x7fab5fe01f40
   #6  0x7fab5f181b96
   #7  0x7fab5fe00b29
   #8  0x

[Bug c++/92735] unused member variable causes code to compile for member to function for undefined function

[marcpawl at gmail dot com]

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

--- Comment #4 from Marc Pawlowsky  ---
(In reply to Jonathan Wakely from comment #2)
> For the case reported here, Clang and EDG do reject it, but I'm not yet
> convinced GCC is wrong to accept it.
> 
> The implicit instantiation of is_Foo causes:
> 
> "the implicit instantiation of the declarations, but not of the definitions,
> of the non-deleted class member functions, member classes, scoped member
> enumerations, static data members, member templates, and friends;"
> 
> and:
> 
> "in particular, the initialization (and any associated side effects) of a
> static data member does not occur unless the static data member is itself
> used in a way that requires the definition of the static data member to
> exist."
> 
> Nothing requires the instantiation of is_Foo::hello.

FYI, Forcing the use of hello does cause a compile time error.
template 
struct is_Foo {
using hello_fn_t = void (T::*)(int);
constexpr static void (T::*hello)(int) = ::hello;
static constexpr bool value=(!!hello);
};
source>:16:46: error: 'hello' is not a member of 'Bad'

   16 | constexpr static void (T::*hello)(int) = ::hello;

[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Tue Dec  3 23:57:46 2019
New Revision: 278951

URL: https://gcc.gnu.org/viewcvs?rev=278951=gcc=rev
Log:
libstdc++: Implement spaceship for std::pair (P1614R2)

This defines operator<=> as a non-member function template and does not
alter operator==. This contradicts the changes made by P1614R2, which
specify both as hidden friends, but that specification of operator<=> is
broken and the subject of a soon-to-be-published LWG issue.

* include/bits/stl_pair.h [__cpp_lib_three_way_comparison]
(operator<=>): Define for C++20.
* libsupc++/compare (__cmp2way_res_t): Rename to __cmp3way_res_t,
move into __detail namespace. Do not turn argument types into lvalues.
(__cmp3way_helper): Rename to __cmp3way_res_impl, move into __detail
namespace. Constrain with concepts instead of using void_t.
(compare_three_way_result): Adjust name of base class.
(compare_three_way_result_t): Use __cmp3way_res_impl directly.
(__detail::__3way_cmp_with): Add workaround for PR 91073.
(compare_three_way): Use workaround.
(__detail::__synth3way, __detail::__synth3way_t): Define new helpers
implementing synth-three-way and synth-three-way-result semantics.
* testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc: New
test.

Added:
   
trunk/libstdc++-v3/testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_pair.h
trunk/libstdc++-v3/libsupc++/compare

[Bug other/92784] [10 regression] ICE when compiling g++.dg/torture/pr59226.C after r278944

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-03
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I see this natively on x86_64-linux as well.

[Bug bootstrap/92783] [10 regression] SEGV in field_byte_offset

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
This should work again now.

[Bug bootstrap/92783] [10 regression] SEGV in field_byte_offset

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Dec  3 23:10:46 2019
New Revision: 278948

URL: https://gcc.gnu.org/viewcvs?rev=278948=gcc=rev
Log:
PR bootstrap/92783
* gcc-interface/utils.c (rest_of_record_type_compilation): Move down
the guard for the position of fields in the descriptive type.

Modified:
trunk/gcc/ada/gcc-interface/utils.c

[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #10 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00180.html

[Bug other/92784] New: [10 regression] ICE when compiling g++.dg/torture/pr59226.C after r278944

[seurer at gcc dot gnu.org]

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

Bug ID: 92784
   Summary: [10 regression] ICE when compiling
g++.dg/torture/pr59226.C after r278944
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

FAIL: g++.dg/torture/pr59226.C   -O2  (internal compiler error)
FAIL: g++.dg/torture/pr59226.C   -O2  (test for excess errors)
FAIL: g++.dg/torture/pr59226.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr59226.C   -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/pr59226.C   -Os  (internal compiler error)
FAIL: g++.dg/torture/pr59226.C   -Os  (test for excess errors)
FAIL: g++.dg/torture/pr59226.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: g++.dg/torture/pr59226.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr59226.C   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0  
-O2-S -o pr59226.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr59226.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -O2
-S -o pr59226.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr59226.C:27:1: error:
calls_comdat_local is set outside of a comdat group
_ZTv0_n24_N1D3fooEv/4 (virtual void D::_ZTv0_n24_N1D3fooEv()) @0x3fffb5f00708
  Type: function
  Body removed by symtab_remove_unreachable_nodes
  Visibility: externally_visible public weak comdat comdat_group:_ZN1D3fooEv
one_only section:.text._ZN1D3fooEv (implicit_section) virtual artificial
  References: 
  Referring: 
  Availability: not_available
  Function flags: calls_comdat_local indirect_call_target
  Former thunk fixed offset 0 virtual value -24 indirect_offset 0 has virtual
offset 1
  Called by: 
  Calls: 
during IPA pass: inline
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr59226.C:27:1:
internal compiler error: verify_cgraph_node failed
0x1077d77b cgraph_node::verify_node()
/home/seurer/gcc/gcc-test2/gcc/cgraph.c:3444
0x1076a173 symtab_node::verify()
/home/seurer/gcc/gcc-test2/gcc/symtab.c:1279
0x1076bc07 symtab_node::verify_symtab_nodes()
/home/seurer/gcc/gcc-test2/gcc/symtab.c:1299
0x10b14fd3 symtab_node::checking_verify_symtab_nodes()
/home/seurer/gcc/gcc-test2/gcc/cgraph.h:650
0x10b14fd3 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/home/seurer/gcc/gcc-test2/gcc/ipa.c:672
0x11940aab ipa_inline
/home/seurer/gcc/gcc-test2/gcc/ipa-inline.c:2695
0x11940aab execute
/home/seurer/gcc/gcc-test2/gcc/ipa-inline.c:3088
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

[Bug bootstrap/92783] [10 regression] SEGV in field_byte_offset

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Fixing.

[Bug bootstrap/92783] [10 regression] SEGV in field_byte_offset

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
I think I know what's going on...

[Bug bootstrap/92783] [10 regression] SEGV in field_byte_offset

[ebotcazou at gcc dot gnu.org]

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

--- Comment #1 from Eric Botcazou  ---
> No patch in that range is immediately obvious, so I'll have to run a reghunt.

Probably r278930 though.

[Bug bootstrap/92783] [10 regression] SEGV in field_byte_offset

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug bootstrap/92783] New: [10 regression] SEGV in field_byte_offset

[ro at gcc dot gnu.org]

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

Bug ID: 92783
   Summary: [10 regression] SEGV in field_byte_offset
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

Between 20191202 (r278904) and 20191203 (r278942), Solaris/SPARC Ada bootstrap
got broken:

/var/gcc/regression/trunk/11.5-gcc/build/./gcc/xgcc
-B/var/gcc/regression/trunk/11.5-gcc/build/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include   -fchecking=1 -c -g -O2 -m64 -fPIC 
-W -Wall -gnatpg -nostdinc -m64  s-interr.adb -o s-interr.o

raised CONSTRAINT_ERROR : SIGSEGV

The failure can be reproduced with

$ gnat1 -quiet -nostdinc -O2 -g -m64 -gnatpg -mcpu=v9 -mptr64 -mstack-bias
-mno-v8plus -gnatO s-interr.o s-interr.adb -o s-interr.s

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00c2d3d0 in field_byte_offset (cst_offset=0xffbfd768, ctx=0xffbfd908, 
decl=0xfa901340) at /vol/gcc/src/hg/trunk/local/gcc/tree.h:3530
3530  return __t;
1: x/i $pc
=> 0xc2d3d0 :   lduh  [ %g1 ], %g1
(gdb) p/x $g1
$1 = 0x0
(gdb) where
#0  0x00c2d3d0 in field_byte_offset (cst_offset=0xffbfd768, ctx=0xffbfd908, 
decl=0xfa901340) at /vol/gcc/src/hg/trunk/local/gcc/tree.h:3530
#1  add_data_member_location_attribute (die=0xfaa25f50, decl=0xfa901340, 
ctx=0xffbfd908) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:19425
#2  0x00c2deb8 in gen_field_die (context_die=, ctx=0xffbfd908, 
decl=0xfa901340) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:24408
#3  gen_field_die (decl=0xfa901340, ctx=0xffbfd908, 
context_die=)
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:24380
#4  0x00c10e20 in gen_decl_die (decl=0xfa901340, origin=0x0, ctx=0xffbfd908, 
context_die=0xfaa25e90)
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:26548
#5  0x00c14178 in gen_member_die (context_die=, type=0xfa9049c0)
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25298
#6  gen_struct_or_union_type_die (usage=, 
context_die=0xfa82e000, type=0xfa9049c0)
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25394
#7  gen_tagged_type_die (type=0xfa9049c0, context_die=0xfa82e000, 
usage=) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25595
#8  0x00c15904 in gen_tagged_type_die (usage=DINFO_USAGE_DIR_USE, 
context_die=0xfa82e000, type=0xfa9049c0)
at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:4256
#9  gen_type_die_with_usage (type=0xfa9049c0, context_die=0xfa82e000, 
usage=DINFO_USAGE_DIR_USE) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25790
#10 0x00c17708 in gen_type_die (type=0xfa9049c0, context_die=0xfa82e000) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25844
#11 0x00c178d0 in add_gnat_descriptive_type_attribute (die=0xfaa25560,
type=0xfa904300, context_die=0xfa82e000) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:20713
#12 0x00c14190 in gen_struct_or_union_type_die (usage=,
context_die=0xfa82e000, type=0xfa904300) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25396
#13 gen_tagged_type_die (type=0xfa904300, context_die=0xfa82e000,
usage=) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25595
#14 0x00c15904 in gen_tagged_type_die (usage=DINFO_USAGE_DIR_USE,
context_die=0xfa82e000, type=0xfa904300) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:4256
#15 gen_type_die_with_usage (type=0xfa904300, context_die=0xfa82e000,
usage=DINFO_USAGE_DIR_USE) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25790
#16 0x00c17708 in gen_type_die (type=0xfa904300, context_die=0xfa82e000) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25844
#17 0x00c18148 in modified_type_die (type=0xfa904300, cv_quals=0,
reverse=, context_die=0xfa82e000) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:13446
#18 0x00c19cf4 in force_type_die (type=0xfa904300) at
/vol/gcc/src/hg/trunk/local/gcc/tree.h:3397
#19 0x00c19dc4 in force_type_die (type=0xfa904300) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:26218
#20 get_context_die (context=0xfa904300) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:26138
#21 get_context_die (context=) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:26130
#22 force_type_die (type=0xfa9043c0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:26220
#23 0x00c1a030 in force_type_die (type=0xfa9043c0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:26218
#24 get_context_die (context=0xfa9043c0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:26138
#25 0x00c15fa8 in gen_descr_array_type_die (context_die=0xfa82e000,
info=0xffbfe0a0, type=0xfa904540) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:25712
#26 gen_type_die_with_usage (type=0xfa904540, context_

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
I have a patch I'm testing for the second problem.  Basically, it verifies that
the builtin we are overloading has already been defined or not.  If it hasn't
(ie, it wasn't supported for some reason, like dfp being disabled), then we
skip defining this builtin too.

[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
A local native bootstrap went through without problems, so maybe it's a problem
with the Debian buildds. I'll try to track it down and if I can reproduce it
locally, I will provide the preprocessed source, of course.

[Bug fortran/92782] New: ICE in fold_convert_loc, at fold-const.c:2431

[gs...@t-online.de]

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

Bug ID: 92782
   Summary: ICE in fold_convert_loc, at fold-const.c:2431
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With an improper type down to gfortran-7 :


$ cat z1.f90
subroutine test(a)
   real :: a
   !$omp target is_device_ptr(a)
   !$omp end target
end


$ gfortran-10-20191201 -c z1.f90 -fopenmp
during GIMPLE pass: omplower
z1.f90:3:0:

3 |!$omp target is_device_ptr(a)
  |
internal compiler error: in fold_convert_loc, at fold-const.c:2431
0x8ca047 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2430
0xa7c66b lower_omp_target
../../gcc/omp-low.c:12032
0xa7c66b lower_omp_1
../../gcc/omp-low.c:12846
0xa7c66b lower_omp
../../gcc/omp-low.c:12989
0xa784ee lower_omp_1
../../gcc/omp-low.c:12781
0xa784ee lower_omp
../../gcc/omp-low.c:12989
0xa7f99b execute_lower_omp
../../gcc/omp-low.c:13031
0xa7f99b execute
../../gcc/omp-low.c:13079

[Bug fortran/92781] New: ICE in convert_nonlocal_reference_op, at tree-nested.c:1065

[gs...@t-online.de]

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

Bug ID: 92781
   Summary: ICE in convert_nonlocal_reference_op, at
tree-nested.c:1065
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This affects versions down to at least gfortran-4.9;
Starting with a legal source ...


$ cat z0.f90
function f()
   character(:), allocatable :: f
   f = 'abc'
end

$ gfortran-10-20191201 -c z0.f90
$


... then adding a local procedure (here unused and empty) :

$ cat z1.f90
function f()
   character(:), allocatable :: f
   f = 'abc'
contains
   subroutine s
   end
end


$ gfortran-10-20191201 -c z1.f90
z1.f90:1:0:

1 | function f()
  |
internal compiler error: Segmentation fault
0xd0039f crash_signal
../../gcc/toplev.c:328
0xdbed18 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3386
0xdbed18 convert_nonlocal_reference_op
../../gcc/tree-nested.c:1065
0x1028493 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:11957
0x9fc177 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:221
0x9fc558 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9fc740 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9fc681 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:641
0x9fc740 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9fc5e1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:605
0x9fc740 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xdb7df8 walk_body
../../gcc/tree-nested.c:713
0xdb7e48 walk_function
../../gcc/tree-nested.c:724
0xdb7e48 walk_all_functions
../../gcc/tree-nested.c:789
0xdc174f lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3528
0x84ed00 cgraph_node::analyze()
../../gcc/cgraphunit.c:675
0x8521f5 analyze_functions
../../gcc/cgraphunit.c:1212
0x853572 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2925

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

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

--- Comment #4 from Hannes Hauswedell  ---
Thanks for the quick reply, Jonathan!

I am familiar with the error in general, but I am using vanilla packages by the
vendor (FreeBSD) which should not have any funky optimisations. Also, my
colleague just reported that she is seeing the same on gcc9 on Ubuntu -- I'll
try to confirm that myself.

The code is not expected to build on trunk/gcc10 because of other known and
reported issues (strip_typedefs...), so I think what you are seeing is not the
same thing.

[Bug fortran/92780] New: [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[gs...@t-online.de]

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

Bug ID: 92780
   Summary: [10 Regression] ICE in gfc_get_class_from_expr, at
fortran/trans-expr.c:484
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190922 (silently accepted) and 20190929 (ICE) :


$ cat z1.f90
program p
   associate (y => p)
   end associate
end


$ gfortran-10-20190922 -c z1.f90
$
$ gfortran-10-20191201 -c z1.f90
z1.f90:2:0:

2 |associate (y => p)
  |
internal compiler error: tree check: expected class 'expression', have
'declaration' (function_decl) in tree_operand_check, at tree.h:3771
0x5ee034 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9738
0x742f19 expr_check(tree_node*, char const*, int, char const*)
../../gcc/tree.h:3442
0x742f19 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3771
0x742f19 gfc_get_class_from_expr(tree_node*)
../../gcc/fortran/trans-expr.c:484
0x79b4c2 trans_associate_var
../../gcc/fortran/trans-stmt.c:2099
0x7a1d51 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2282
0x706e17 trans_code
../../gcc/fortran/trans.c:1948
0x73e04d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6798
0x6b80f6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6b80f6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x7030ef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Because "illegal instruction" happens if the executable contains an instruction
that your CPU doesn't support. And that should never happen if you built GCC
correctly.

When I try to compile with gcc-9-branch it I get:

g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

which suggests a stackoverflow or other memory problem.

With trunk I get:

In file included from
/home/hannes/devel/lambda/submodules/seqan3/include/seqan3/std/iterator:24,
 from
/home/hannes/devel/lambda/submodules/seqan3/include/seqan3/core/type_traits/iterator.hpp:20,
 from
/home/hannes/devel/lambda/submodules/seqan3/include/seqan3/core/type_traits/range.hpp:20,
 from
/home/hannes/devel/lambda/submodules/seqan3/include/seqan3/range/views/translate_join.hpp:18,
 from /home/hannes/devel/lambda/src/seqan2seqan3.hpp:7,
 from /home/hannes/devel/lambda/src/lambda.cpp:22:
/home/hannes/devel/lambda/submodules/seqan3/submodules/range-v3/include/range/v3/iterator/access.hpp:222:76:
internal compiler error: in strip_typedefs, at cp/tree.c:1681
0x675f3a strip_typedefs(tree_node*, bool*, unsigned int)
/home/jwakely/src/gcc/gcc/gcc/cp/tree.c:1681
0x675f3a strip_typedefs(tree_node*, bool*, unsigned int)
/home/jwakely/src/gcc/gcc/gcc/cp/tree.c:1461
0x9f8792 canonicalize_type_argument
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:7935
0xa230db coerce_template_parms
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:8778
0xa336b9 lookup_template_class_1
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:9615
0xa336b9 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:9985
0xa5d73b finish_template_type(tree_node*, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/semantics.c:3396
0x9e44ad cp_parser_template_id
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:16544
0x9e473a cp_parser_class_name
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23416
0x9e10bb cp_parser_qualifying_entity
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:6705
0x9e10bb cp_parser_nested_name_specifier_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:6388
0x9ddfd0 cp_parser_simple_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17925
0x9df247 cp_parser_postfix_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:7103
0x9e78cf cp_parser_unary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:8472
0x9bf9af cp_parser_cast_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9365
0x9c0605 cp_parser_simple_cast_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29048
0x9c0605 cp_parser_binary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9533
0x9c1247 cp_parser_assignment_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9768
0x9e318a cp_parser_template_argument
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17196
0x9e318a cp_parser_template_argument_list
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:16895
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/92779] [8/9/10 Regression] ICE in gfc_conv_intrinsic_funcall, at fortran/trans-intrinsic.c:4225

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

These slightly modified variants are doing well :


$ cat z2.f90
program p
   associate (y => spread(trim('abc'),1,2) // 'd')
  print *, y
   end associate
end


$ cat z3.f90
program p
   character(3) :: a = 'abc'
   associate (y => spread(a,1,2) // 'd')
  print *, y
   end associate
end


$ gfortran-10-20191201 z2.f90 && ./a.out
 abcdabcd
$
$ gfortran-10-20191201 z3.f90 && ./a.out
 abcdabcd

[Bug fortran/92779] New: [8/9/10 Regression] ICE in gfc_conv_intrinsic_funcall, at fortran/trans-intrinsic.c:4225

[gs...@t-online.de]

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

Bug ID: 92779
   Summary: [8/9/10 Regression] ICE in gfc_conv_intrinsic_funcall,
at fortran/trans-intrinsic.c:4225
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Starting with gcc-8 before 20180525 :


$ cat z1.f90
program p
   character(3) :: a = 'abc'
   associate (y => spread(trim(a),1,2) // 'd')
  print *, y
   end associate
end


$ gfortran-7 -c z1.f90
$
$ gfortran-10-20191201 -c z1.f90
z1.f90:4:0:

4 |   print *, y
  |
internal compiler error: in gfc_conv_intrinsic_funcall, at
fortran/trans-intrinsic.c:4225
0x729f9e gfc_conv_intrinsic_funcall
../../gcc/fortran/trans-intrinsic.c:4225
0x72cfe7 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9778
0x704ada gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8657
0x709129 gfc_conv_string_length(gfc_charlen*, gfc_expr*, stmtblock_t*)
../../gcc/fortran/trans-expr.c:2276
0x6e7b97 get_array_charlen
../../gcc/fortran/trans-array.c:7082
0x6e7c6e get_array_charlen
../../gcc/fortran/trans-array.c:7014
0x6e671a gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7402
0x740442 trans_associate_var
../../gcc/fortran/trans-stmt.c:1889
0x747101 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2282
0x6d47b7 trans_code
../../gcc/fortran/trans.c:1948
0x6fda64 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6798
0x686c26 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x686c26 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d10bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[gs...@t-online.de]

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

--- Comment #14 from G. Steinmetz  ---

$ cat z3.f90
program p
   character(:), pointer :: c
   common c
   n = len(c)
end


$ gfortran-10-20191201 -c z3.f90
z3.f90:4:0:

4 |n = len(c)
  |
internal compiler error: in gfc_conv_intrinsic_len, at
fortran/trans-intrinsic.c:7122
0x72ee62 gfc_conv_intrinsic_len
../../gcc/fortran/trans-intrinsic.c:7122
0x72ee62 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:10166
0x704ada gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8657
0x71445a gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10848
0x6d4617 trans_code
../../gcc/fortran/trans.c:1852
0x6fda64 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6798
0x686c26 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x686c26 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d10bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
This usually means you built GCC (or one of the libraries it uses, like libgmp)
on a different machine with a different CPU.

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #13 from G. Steinmetz  ---

Updating variants :


$ cat z1.f90
program p
   character(:), pointer :: c
   common c
   c = 'abc'
end


$ cat z2.f90
program p
   character(:), pointer :: c
   common c
   n = len_trim(c)
end


$ gfortran-10-20191201 -c z1.f90
z1.f90:4:0:

4 |c = 'abc'
  |
internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:2789
0x708eb9 gfc_conv_variable
../../gcc/fortran/trans-expr.c:2789
0x704afa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8665
0x71470f gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10884
0x6d4617 trans_code
../../gcc/fortran/trans.c:1852
0x6fda64 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6798
0x686c26 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x686c26 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d10bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

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

--- Comment #1 from Hannes Hauswedell  ---
Here is the intermediate code:
https://hauswedell.net/lambda.ii.xz

[Bug c++/92778] New: ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

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

Bug ID: 92778
   Summary: ICE: Illegal instruction signal terminated program
cc1plus
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

The beautiful intermediate code that I attached (Yes, I know it's huge), ICEs
with the very non-descriptive message of:

g++9: internal compiler error: Illegal instruction signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The command to build the intermediate code is:

g++9 -std=c++17 -fconcepts -pthread -fopenmp lambda.ii

Reproducible with the compiler versions:
g++9 (FreeBSD Ports Collection) 9.2.0 
g++9 (FreeBSD Ports Collection) 9.2.1 20191123

[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed

[bernds at gcc dot gnu.org]

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

--- Comment #1 from Bernd Schmidt  ---
People will be more likely to look at it if there's a preprocessed .i file that
reproduces the issue, ideally with a cross compiler rather than a native
bootstrap.
If it only occurs when bootstrapping, narrowing down the offending commit would
be helpful.

[Bug c++/92735] unused member variable causes code to compile for member to function for undefined function

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Related to http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1396

[Bug c++/88323] implement C++20 language features.

[jakub at gcc dot gnu.org]

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

Bug 91369 Summary: Implement P0784R7: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369

   What|Removed |Added

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

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #23 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/55004] [meta-bug] constexpr issues

[jakub at gcc dot gnu.org]

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

Bug 91369 Summary: Implement P0784R7: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369

   What|Removed |Added

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

[Bug c++/92777] New: ICE on concept containing lambda with auto variable declaration

[jason.e.cobb at gmail dot com]

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

Bug ID: 92777
   Summary: ICE on concept containing lambda with auto variable
declaration
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.e.cobb at gmail dot com
  Target Milestone: ---

With GCC trunk in std=c++2a mode and the following code:

[begin code]

template
concept auto_in_lambda = requires() {
[](){
auto x = 4;
}();
};

static_assert(auto_in_lambda);

[end code]

GCC ICEs with the following message:

: In lambda function:
:4:14: internal compiler error: in tsubst_decl, at cp/pt.c:14375
4 | auto x = 4;
  |  ^

GCC does not ICE if the concept is never instantiated, nor does it ICE if the
"auto" variable is changed to have a defined type.

On Compiler Explorer: https://godbolt.org/z/myujUX

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec  3 19:27:47 2019
New Revision: 278945

URL: https://gcc.gnu.org/viewcvs?rev=278945=gcc=rev
Log:
PR c++/91369
* constexpr.c (struct constexpr_global_ctx): Add cleanups member,
initialize it in the ctor.
(cxx_eval_constant_expression) : If TARGET_EXPR_SLOT
is already in the values hash_map, don't evaluate it again.  Put
TARGET_EXPR_SLOT into hash_map even if not lval, and push it into
save_exprs too.  If there is TARGET_EXPR_CLEANUP and not
CLEANUP_EH_ONLY, push the cleanup to cleanups vector.
: Save outer cleanups, set cleanups to
local auto_vec, after evaluating the body evaluate cleanups and
restore previous cleanups.
: Don't crash if the first operand is NULL_TREE.
(cxx_eval_outermost_constant_expr): Set cleanups to local auto_vec,
after evaluating the expression evaluate cleanups.

* g++.dg/cpp2a/constexpr-new8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-new8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/92756] [9/10 Regression] ICE in lower_omp, at omp-low.c:12988

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug fortran/92756] [9/10 Regression] ICE in lower_omp, at omp-low.c:12988

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|8.4 |9.3

--- Comment #2 from Jakub Jelinek  ---
It used to be invalid in OpenMP 4.5, but is completely valid in OpenMP 5.0. 
Before the above mentioned change, it was the generic code that used to
diagnose it as invalid, but that was removed when C/C++ started supporting it.
Easiest is to support in Fortran too, after all, Fortran already gained some
OpenMP 5.0 features.

[Bug c++/92776] New: Can't define member function out of line with non-type template parameter

[barry.revzin at gmail dot com]

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

Bug ID: 92776
   Summary: Can't define member function out of line with non-type
template parameter
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

From StackOverflow (https://stackoverflow.com/q/59163716/2069064):

struct A {};

template 
struct B {
void f();
};

template 
void B::f() { }

On the gcc trunk on godbolt, this fails with:

:9:14: error: invalid use of incomplete type 'struct B<((const A)a)>'
9 | void B::f() { }
  |  ^
:4:8: note: declaration of 'struct B<((const A)a)>'
4 | struct B {
  |^

But compiles fine if you replace the declaration of A with something like
"using A = int;"

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[ch3root at openwall dot com]

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

--- Comment #16 from Alexander Cherepanov  ---
BTW this bug combines nicely with pr71460. Possible effects:
- padding in a long double inside a struct is lost on x86-64;
- sNaN is converted to qNaN in a double inside a struct on x86-32.

Both are illustrated at https://godbolt.org/z/VKmGbY . E.g., the former, this:

--
#include 

struct s1 { long double d; };
void f1(struct s1 *restrict p, struct s1 *restrict q)
{
*p = *q;
memcpy(p, q, sizeof(struct s1));
}
--

is compiled into this:

--
f1:
fldt(%rsi)
fstpt   (%rdi)
ret
--

[Bug fortran/92775] New: Incorrect expression in DW_AT_byte_stride on an array

[andrew.burgess at embecosm dot com]

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

Bug ID: 92775
   Summary: Incorrect expression in DW_AT_byte_stride on an array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.burgess at embecosm dot com
  Target Milestone: ---

Created attachment 47411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47411=edit
Example.

1. Unpack the example, and run 'make'.  This creates a test binary
   called 'test', and the DWARF from that binary is placed into
   'test.dwarf'.  Initially I'm using GCC 7.4.0.

2. In the generated 'test.dwarf' Find the DW_TAG_variable for
   'point_dimension', note its DW_AT_type and DW_AT_location.  For me
   I have:

   <2>: Abbrev Number: 10 (DW_TAG_variable)
 DW_AT_name: (indirect string, offset: 0x0):
point_dimension
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 13
 DW_AT_type: <0x18a>
 DW_AT_location: 9 byte block: 3 80 10 60 0 0 0 0 0  
(DW_OP_addr: 601080)
   ...
   <1><18a>: Abbrev Number: 16 (DW_TAG_array_type)
  <18b>   DW_AT_data_location: 2 byte block: 97 6
(DW_OP_push_object_address; DW_OP_deref)
  <18e>   DW_AT_associated  : 4 byte block: 97 6 30 2e   
(DW_OP_push_object_address; DW_OP_deref; DW_OP_lit0; DW_OP_ne)
  <193>   DW_AT_type: <0x5d>
   <2><197>: Abbrev Number: 17 (DW_TAG_subrange_type)
  <198>   DW_AT_lower_bound : 4 byte block: 97 23 20 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref)
  <19d>   DW_AT_upper_bound : 4 byte block: 97 23 28 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref)
  <1a2>   DW_AT_byte_stride : 15 byte block: 97 23 18 6 3 b0 10 60 0 0 0 0
0 6 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref;
DW_OP_addr: 6010b0; DW_OP_deref; DW_OP_mul)

3. Figure out the expression to read the DW_AT_byte_stride, from the above it
will be:

   ((*(0x601080 + 24)) * (*0x6010b0))

4. Run the test program, this just confirms what we expect the value
   of 'point_dimension' to be, which is: { 2, 2, 2, 2, 2, 2, 2, 2, 2 }.

5. Now fire up GDB on the test program:

   $ gdb test
   (gdb) break 18
   (gdb) run
   (gdb) p/d ((*(0x601080 + 24)) * (*0x6010b0))
   $1 = 24

   # So the stride appears to be 24.  Now to check, first, where's the
   # first element:

   (gdb) p _dimension(1)
   $2 = (PTR TO -> ( integer(kind=8) )) 0x7fffccd8

   # Now lets check the stride is correct by examining all the
   # remaining elements:

   (gdb) x/1w 0x7fffccd8 + (24 * 0)
   0x7fffccd8:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 1)
   0x7fffccf0:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 2)
   0x7fffcd08:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 3)
   0x7fffcd20:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 4)
   0x7fffcd38:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 5)
   0x7fffcd50:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 6)
   0x7fffcd68:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 7)
   0x7fffcd80:  2
   (gdb) x/1w 0x7fffccd8 + (24 * 8)
   0x7fffcd98:  2

   # So it looks like a stride of 24 is correct.  Based on the code
   # this is what I would expect.

6. Now recompile the test with a later version of GCC.  I've tested
   8.3.0 and 9.2.0, plus a version from trunk from mid-October 2019.
   The data below is from 9.2.0:

   <2>: Abbrev Number: 10 (DW_TAG_variable)
 DW_AT_name: (indirect string, offset: 0x0):
point_dimension
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 13
 DW_AT_type: <0x10f>
 DW_AT_location: 9 byte block: 3 80 10 60 0 0 0 0 0  
(DW_OP_addr: 601080)
   ...
   <1><10f>: Abbrev Number: 13 (DW_TAG_array_type)
  <110>   DW_AT_data_location: 2 byte block: 97 6
(DW_OP_push_object_address; DW_OP_deref)
  <113>   DW_AT_associated  : 4 byte block: 97 6 30 2e   
(DW_OP_push_object_address; DW_OP_deref; DW_OP_lit0; DW_OP_ne)
  <118>   DW_AT_type: <0x5d>
   <2><11c>: Abbrev Number: 14 (DW_TAG_subrange_type)
  <11d>   DW_AT_lower_bound : 4 byte block: 97 23 30 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 48; DW_OP_deref)
  <122>   DW_AT_upper_bound : 4 byte block: 97 23 38 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 56; DW_OP_deref)
  <127>   DW_AT_byte_stride : 6 byte block: 97 23 28 6 38 1e 
(DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_lit8;
DW_OP_mul)

7. Notice that the DW_AT_byte_stride expression has changed, it now
   looks like this:

   ((*(0x601080 + 40)) * 8)

8. Before we validate this in GDB, for our sanity rerun the test
   program and confirm that it does the correct thing at run time, it
   still prints the array as 9 elements, all containing the value 2.

9. 

[Bug target/65146] alignment of _Atomic structure member is not correct

[joseph at codesourcery dot com]

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

--- Comment #19 from joseph at codesourcery dot com  ---
On Tue, 3 Dec 2019, jason at gcc dot gnu.org wrote:

> Can we please fix this for GCC 10?  It's an important compatibility issue, and
> becoming more important.  Bumping to P1 to raise visibility.

Are we taking "this" to mean specifically the issue described in the bug 
summary, i.e. alignment in structures?  (And not anything about adding 
padding to atomic types, which isn't needed for correctness but might be 
needed on some platforms for ABI compatibility with the system compilers 
but is also likely to need changes somewhere to allow assignments from 
atomic to non-atomic to work properly without e.g. trying to copy the 
padding to a non-atomic type that doesn't include it - that might also 
affect stdatomic.h, which generally uses __atomic_* with temporaries of 
non-atomic type, which thus wouldn't have any such extra padding; maybe 
the generic __atomic_* would need to have special handling of pointers to 
different-sized arguments, or something like that.)

[Bug gcov-profile/91971] Profile directory concatenated with object file path

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #7 from Eric Botcazou  ---
Reopened because the new behavior is problematic.  Consider the file t.c:

int main (void)
{
  return 0;
}

in the directory /home/eric and compile it like so:

gcc -c /home/eric/t.c -o /home/eric/t.o -fprofile-arcs -ftest-coverage
gcc /home/eric/t.o -o /home/eric/t -lgcov
/home/eric/t

You get the following couple of files in the directory:
#home#eric#t.gcda
#home#eric#t.gcno
whereas you would have gotten t.gcda and t.gcno before.

Please consider making the change conditional on -fprofile-dir= or somesuch.

[Bug target/65146] alignment of _Atomic structure member is not correct

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jason at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #18 from Jason Merrill  ---
Here's the thread on the psABI mailing list.

https://groups.google.com/forum/#!topic/ia32-abi/Tlu6Hs-ohPY

Can we please fix this for GCC 10?  It's an important compatibility issue, and
becoming more important.  Bumping to P1 to raise visibility.

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On December 3, 2019 4:09:12 PM GMT+01:00, "jakub at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
>
>--- Comment #12 from Jakub Jelinek  ---
>(In reply to rguent...@suse.de from comment #11)
>> Alternatively add another flag to operand_equal_p to say whether
>> exact literal equality is asked for.
>
>That is fine with me.  Though, as I said on IRC, it can work then by
>accident,
>but might break any time, e.g. won't VN if it sees with
>-fno-signed-zeros:
>  _2 = { 0.f, 0.f, 0.f, 0.f };
>  use (_2);
>  ...
>  _5 = { 0.f, -0.f, 0.f, -0.f };
>  use (_5);
>happily replace _5 with _2, or anything else that uses operand_equal_p
>and
>won't pass this new magic flag?

Yes.

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #12)
> The __builtin_strcmp(ptr->header.magic, "x") call in comment #0 is undefined
> because the two-element array ptr->header.magic is not a nul-terminated
> string.  The warning was designed to point that out.

I don't agree with that view, but if you replace that first __builtin_strcmp
with say __builtin_memcmp(ptr->header.magic, "x", 2) == 0 it fails the same
way.  Plus all the other testcases in this PR.
The first call really doesn't matter, all that matters is that there is
something taking address of ptr->header.magic earlier in the function.
And a warning designed on something the GIMPLE IL does not preserve is wrong.

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
The __builtin_strcmp(ptr->header.magic, "x") call in comment #0 is undefined
because the two-element array ptr->header.magic is not a nul-terminated string.
 The warning was designed to point that out.

Removing the call removes the bug from the test case and lets it run to
completion.

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Untested patch to fix all these wrong-code issues would be something like:
--- gcc/tree-ssa-strlen.c.jj2019-11-28 09:35:32.443298424 +0100
+++ gcc/tree-ssa-strlen.c   2019-12-03 17:02:32.131658020 +0100
@@ -3473,54 +3473,30 @@ compute_string_length (int idx)
 static unsigned HOST_WIDE_INT
 determine_min_objsize (tree dest)
 {
-  unsigned HOST_WIDE_INT size = 0;
+  unsigned HOST_WIDE_INT size;

   init_object_sizes ();

   if (compute_builtin_object_size (dest, 2, ))
 return size;

-  /* Try to determine the size of the object through the RHS
- of the assign statement.  */
-  if (TREE_CODE (dest) == SSA_NAME)
-{
-  gimple *stmt = SSA_NAME_DEF_STMT (dest);
-  if (!is_gimple_assign (stmt))
-   return HOST_WIDE_INT_M1U;
-
-  if (!gimple_assign_single_p (stmt)
- && !gimple_assign_unary_nop_p (stmt))
-   return HOST_WIDE_INT_M1U;
+  return HOST_WIDE_INT_M1U;
+}

-  dest = gimple_assign_rhs1 (stmt);
-  return determine_min_objsize (dest);
-}
+/* Similarly, but maximum instead of minimum, and return 0 when the
+   size cannot be determined.  */

-  /* Try to determine the size of the object from its type.  */
-  if (TREE_CODE (dest) != ADDR_EXPR)
-return HOST_WIDE_INT_M1U;
-
-  tree type = TREE_TYPE (dest);
-  if (TREE_CODE (type) == POINTER_TYPE)
-type = TREE_TYPE (type);
-
-  type = TYPE_MAIN_VARIANT (type);
-
-  /* The size of a flexible array cannot be determined.  Otherwise,
- for arrays with more than one element, return the size of its
- type.  GCC itself misuses arrays of both zero and one elements
- as flexible array members so they are excluded as well.  */
-  if (TREE_CODE (type) != ARRAY_TYPE
-  || !array_at_struct_end_p (dest))
-{
-  tree type_size = TYPE_SIZE_UNIT (type);
-  if (type_size && TREE_CODE (type_size) == INTEGER_CST
- && !integer_onep (type_size)
- && !integer_zerop (type_size))
-return tree_to_uhwi (type_size);
-}
+static unsigned HOST_WIDE_INT
+determine_max_objsize (tree dest)
+{
+  unsigned HOST_WIDE_INT size;

-  return HOST_WIDE_INT_M1U;
+  init_object_sizes ();
+
+  if (compute_builtin_object_size (dest, 0, ))
+return size;
+
+  return 0;
 }

 /* Given strinfo IDX for ARG, set LENRNG[] to the range of lengths
@@ -3603,7 +3579,9 @@ get_len_or_size (tree arg, int idx, unsi
  /* Set *SIZE to the size of the smallest object referenced
 by ARG if ARG denotes a single object, or to HWI_M1U
 otherwise.  */
- *size = determine_min_objsize (arg);
+ *size = determine_max_objsize (arg);
+ if (*size == 0)
+   *size = HOST_WIDE_INT_M1U;
  *nulterm = false;
}
 }
plus add testsuite coverage from the testcases in this PR and deal with
testsuite regressions:
FAIL: gcc.dg/Wstring-compare.c  (test for warnings, line 123)
FAIL: gcc.dg/strcmpopt_2.c scan-tree-dump-times strlen1 "cmp_eq \\(" 8
FAIL: gcc.dg/strcmpopt_4.c scan-tree-dump-times strlen1 "cmp_eq \\(" 1
FAIL: gcc.dg/strlenopt-69.c scan-tree-dump-not optimized "abort|strcmp|strncmp"
where strcmpopt_2.c now matches just 4 times instead of 8.

Or do we consider the #c10 testcase valid, but what strcmpopt_2.c does like:
typedef struct { char s[8]; int x; } S;

__attribute__ ((noinline)) int
f1 (S *s)
{
  return __builtin_strcmp (s->s, "abc") != 0;
}

ok (in that if there is a pointer to S, at least sizeof (s->s) bytes will be
mapped?  We could look through COMPONENT_REFs in the access path and if there
is  any UNION_TYPE in there, be conservative and consider the same addresses in
all the union members and take conservative answer from all of them?  Wouldn't
that still be a problem if we have union somewhere earlier and just take
address of a union member?

[Bug c++/91363] Implement P0960R3: Parenthesized initialization of aggregates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Implemented for GCC 10.

[Bug c++/88323] implement C++20 language features.

[mpolacek at gcc dot gnu.org]

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

Bug 91363 Summary: Implement P0960R3: Parenthesized initialization of aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91363

   What|Removed |Added

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

[Bug c++/91363] Implement P0960R3: Parenthesized initialization of aggregates

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue Dec  3 15:59:40 2019
New Revision: 278939

URL: https://gcc.gnu.org/viewcvs?rev=278939=gcc=rev
Log:
PR c++/91363 - P0960R3: Parenthesized initialization of aggregates.

This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info).  Essentially, if you have
an aggregate, you can now initialize it by (x, y), similarly to {x, y}.  E.g.

  struct A {
int x, y;
// no A(int, int) ctor (see paren-init14.C for = delete; case)
  };
  A a(1, 2);

The difference between ()-init and {}-init is that narrowing conversions are
permitted, designators are not permitted, a temporary object bound to
a reference does not have its lifetime extended, and there is no brace elision.
Further, things like

  int a[](1, 2, 3); // will deduce the array size
  const A& r(1, 2.3, 3); // narrowing is OK
  int (&)[](1, 2, 3);
  int b[3](1, 2); // b[2] will be value-initialized

now work as expected.  Note that

  char f[]("fluff");

has always worked and this patch keeps it that way.  Also note that A a((1, 2))
is not the same as A a{{1,2}}; the inner (1, 2) remains a COMPOUND_EXPR.

The approach I took was to handle (1, 2) similarly to {1, 2} -- conjure up
a CONSTRUCTOR, and introduce LOOKUP_AGGREGATE_PAREN_INIT to distinguish
between the two.  This kind of initialization is only supported in C++20;
I've made no attempt to support it in earlier standards, like we don't
support CTAD pre-C++17, for instance.

* c-cppbuiltin.c (c_cpp_builtins): Predefine
__cpp_aggregate_paren_init=201902 for -std=c++2a.

* call.c (build_new_method_call_1): Handle parenthesized initialization
of aggregates by building up a CONSTRUCTOR.
(extend_ref_init_temps): Do nothing for CONSTRUCTOR_IS_PAREN_INIT.
* cp-tree.h (CONSTRUCTOR_IS_PAREN_INIT, LOOKUP_AGGREGATE_PAREN_INIT):
Define.
* decl.c (grok_reference_init): Handle aggregate initialization from
a parenthesized list of values.
(reshape_init): Do nothing for CONSTRUCTOR_IS_PAREN_INIT.
(check_initializer): Handle initialization of an array from a
parenthesized list of values.  Use NULL_TREE instead of NULL.
* tree.c (build_cplus_new): Handle BRACE_ENCLOSED_INITIALIZER_P.
* typeck2.c (digest_init_r): Set LOOKUP_AGGREGATE_PAREN_INIT if it
receives a CONSTRUCTOR with CONSTRUCTOR_IS_PAREN_INIT set.  Allow
narrowing when LOOKUP_AGGREGATE_PAREN_INIT.
(massage_init_elt): Don't lose LOOKUP_AGGREGATE_PAREN_INIT when passing
flags to digest_init_r.

* g++.dg/cpp0x/constexpr-99.C: Only expect an error in C++17 and
lesser.
* g++.dg/cpp0x/explicit7.C: Likewise.
* g++.dg/cpp0x/initlist12.C: Adjust dg-error.
* g++.dg/cpp0x/pr31437.C: Likewise.
* g++.dg/cpp2a/feat-cxx2a.C: Add __cpp_aggregate_paren_init test.
* g++.dg/cpp2a/paren-init1.C: New test.
* g++.dg/cpp2a/paren-init10.C: New test.
* g++.dg/cpp2a/paren-init11.C: New test.
* g++.dg/cpp2a/paren-init12.C: New test.
* g++.dg/cpp2a/paren-init13.C: New test.
* g++.dg/cpp2a/paren-init14.C: New test.
* g++.dg/cpp2a/paren-init15.C: New test.
* g++.dg/cpp2a/paren-init16.C: New test.
* g++.dg/cpp2a/paren-init17.C: New test.
* g++.dg/cpp2a/paren-init18.C: New test.
* g++.dg/cpp2a/paren-init19.C: New test.
* g++.dg/cpp2a/paren-init2.C: New test.
* g++.dg/cpp2a/paren-init3.C: New test.
* g++.dg/cpp2a/paren-init4.C: New test.
* g++.dg/cpp2a/paren-init5.C: New test.
* g++.dg/cpp2a/paren-init6.C: New test.
* g++.dg/cpp2a/paren-init7.C: New test.
* g++.dg/cpp2a/paren-init8.C: New test.
* g++.dg/cpp2a/paren-init9.C: New test.
* g++.dg/ext/desig10.C: Adjust dg-error.
* g++.dg/template/crash107.C: Likewise.
* g++.dg/template/crash95.C: Likewise.
* g++.old-deja/g++.jason/crash3.C: Likewise.
* g++.old-deja/g++.law/ctors11.C: Likewise.
* g++.old-deja/g++.law/ctors9.C: Likewise.
* g++.old-deja/g++.mike/net22.C: Likewise.
* g++.old-deja/g++.niklas/t128.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init1.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init10.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init11.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init12.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init13.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init14.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init15.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init16.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init17.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init18.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init19.C
trunk/gcc/testsuite/g++.dg/cpp2a/paren-init2.C

[Bug c++/92774] New: ICE with defaulted three-way comparison function

[redi at gcc dot gnu.org]

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

Bug ID: 92774
   Summary: ICE with defaulted three-way comparison function
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

template
struct X { };

template
bool operator==(const X&, const X&) { return true; }
template
bool operator<(const X&, const X&) { return true; }

struct Y
{
  int a;
  X c;

  auto operator <=>(Y const&) const = default;
};

void f()
{
  auto x = Y() < Y();
}


This gets an ICE when compiled with -std=gnu++2a:

ice.cc: In member function 'constexpr auto Y::operator<=>(const Y&) const':
ice.cc:16:8: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in is_cat, at cp/method.c:999
   16 |   auto operator <=>(Y const&) const = default;
  |^~~~
0x7e1d30 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/jwakely/src/gcc/gcc/gcc/tree.c:9738
0x618612 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3396
0x618612 is_cat
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:999
0x9a226c cat_tag_for
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:1011
0x9a226c common_comparison_type
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:1166
0x9a226c build_comparison_op
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:1341
0x9a8809 synthesize_method(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/method.c:1501
0x9637c7 mark_used(tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/decl2.c:5481
0x8c8611 build_over_call
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:8956
0x8cfc58 build_new_op_1
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6234
0x8d023d build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6499
0xa9b533 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:4229
0x9cc6e1 cp_parser_binary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9645
0x9cd557 cp_parser_assignment_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9780
0x9ccf3d cp_parser_constant_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:10074
0x9cd501 cp_parser_initializer_clause
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23023
0x9d16a7 cp_parser_initializer
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22961
0x9fa521 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20669
0x9da932 cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13624
0x9dc669 cp_parser_declaration_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13055
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug preprocessor/47857] Pragma once warning when compiling PCH

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #8 from Romain Geissler  ---
Hi,

This is still the case up to gcc 9 (already released) and current trunk of gcc
10.

Cheers,
Romain

[Bug target/92758] [10 regression] r278833 breaks gcc.target/powerpc/fold-vec-splat-floatdouble.c

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
OK, thanks.

BTW, for reference this also affected a couple other test cases on LE power 8
and power 9.

FAIL: gcc.target/powerpc/swaps-p8-16.c scan-assembler vspltw
FAIL: gcc.target/powerpc/swaps-p8-27.c scan-assembler-times lxvd2x 2

[Bug c/92773] GCC compilation with big array / header is infinite

[renault at fedoraproject dot org]

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

--- Comment #2 from Charles-Antoine Couret  
---
Created attachment 47410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47410=edit
one big header which raises the problem

[Bug c/92773] GCC compilation with big array / header is infinite

[renault at fedoraproject dot org]

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

--- Comment #1 from Charles-Antoine Couret  
---
Created attachment 47409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47409=edit
module driver header

[Bug c/92773] New: GCC compilation with big array / header is infinite

[renault at fedoraproject dot org]

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

Bug ID: 92773
   Summary: GCC compilation with big array / header is infinite
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: renault at fedoraproject dot org
  Target Milestone: ---

Created attachment 47408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47408=edit
module driver

I'm working on a new Linux kernel module. I'm using Fedora 31 with GCC 9.2.1

This module has several big arrays generated by a external tool which should be
included into the driver itself. I use C headers for that.

Without those headers, the compilation works fine. But if I try to include
them, the compilation takes a infinite amount of time with cc1 process which
uses one CPU at 100%.

I tried with GCC 5.3.1 (Fedora 22) and 5.3.0 (Yocto) and the build succeed. And
I don't see any reason to have this behaviour on earlier GCC.

[Bug bootstrap/92762] hash_table::empty_slow invokes assignment on invalid objects

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
It looks to me like the whole else block with the BROKEN_VALUE_INITIALIZATION
guard is incorrect.  The following test case aborts:

typedef int_hash IntHash;

hash_map > x;

static void test_hash_table ()
{
  for (int i = 1; i != 32; ++i)
x.put (i, i);

  x.empty ();

  gcc_assert (!x.get (0));   << abort here
}

internal compiler error: in test_hash_table, at cp/parser.c:43483
0xaea59d test_hash_table
/src/gcc/61339/gcc/cp/parser.c:43483
0xaea5a9 c_parse_file()
/src/gcc/61339/gcc/cp/parser.c:43491
0xcd3987 c_common_parse_file()
/src/gcc/61339/gcc/c-family/c-opts.c:1185
Please submit a full bug report,


Changing the assert to

  gcc_assert (!x.get (1));

leads to an infinite loop in hash_table::find_with_hash().

[Bug tree-optimization/92772] New: wrong code vectorizing masked max

[ams at gcc dot gnu.org]

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

Bug ID: 92772
   Summary: wrong code vectorizing masked max
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ams at gcc dot gnu.org
  Target Milestone: ---

The testcase pr65947-10.c fails on amdgcn because there are more vector lanes
than there is data, and the algorithm created doesn't allow for this. (Actually
there's also a backend pattern missing, but I have a patch for that I'll commit
shortly.)

Here's the affected loop:

 float last = 0;

 for (int i = 0; i < 32; i++)
   if (a[i] < min_v)
 last = a[i];

Which produces the following code (long lines shortened).

   vect_cst__33 = {min_v_11(D),  min_v_11(D)};
   vect__4.16_32 = .MASK_LOAD (a_10(D), 4B, { -1, [...] -1, 0, [...] 0 });
   vect_last_6.17_34 = VEC_COND_EXPR ;
   _38 = VEC_COND_EXPR ;
   _40 = .REDUC_MAX (_38);
   _41 = {_40, _40, [...] _40};
   _43 = VEC_COND_EXPR <_38 == _41, vect_last_6.17_34, { 0.0, [...] 0.0 }>;
   _44 = VIEW_CONVERT_EXPR(_43);
   _45 = .REDUC_MAX (_44);
   _46 = VIEW_CONVERT_EXPR(_45);
   return _46;

In English:

1. Do a masked load of 32 elements (into 64-lane register). Loads "0.0" into
the spare lanes.
2. Compare the all 64-lanes against "min_v". Label all the "true" lanes with
the lane number.
3. Use a reduction to find the greatest numbered "true" lane.
4. Zero all the loaded values apart from the one in the greatest lane.
5. Use a reduction to find the value of the lane that isn't zeroed.

That's slightly tortuous when we could just do a vec_extract on "_40", but
that's an aside.

The problem is in step 2: the spare lanes contain 0.0, which means that
comparing them against "min_v" returns "true". This means that the algorithm
always finds "last = a[63]" which isn't a real value and therefore always ends
up being "0.0".

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #11)
> Alternatively add another flag to operand_equal_p to say whether
> exact literal equality is asked for.

That is fine with me.  Though, as I said on IRC, it can work then by accident,
but might break any time, e.g. won't VN if it sees with -fno-signed-zeros:
  _2 = { 0.f, 0.f, 0.f, 0.f };
  use (_2);
  ...
  _5 = { 0.f, -0.f, 0.f, -0.f };
  use (_5);
happily replace _5 with _2, or anything else that uses operand_equal_p and
won't pass this new magic flag?

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Testcase showing wrong-code with the __builtin_strcmp_eq stuff (assuming the
testcase is considered valid):
/* { dg-do run { target mmap } } */
/* { dg-options "-O2" } */

#include 
#include 
#ifndef MAP_ANONYMOUS
#define MAP_ANONYMOUS MAP_ANON
#endif
#ifndef MAP_ANON
#define MAP_ANON 0
#endif
#ifndef MAP_FAILED
#define MAP_FAILED ((void *)-1)
#endif

union U { struct T { char a[2]; char b[4094]; } c; struct S { char d[4]; int e;
} f; };

__attribute__((noipa)) void
bar (char *p)
{
  asm volatile ("" : : "g" (p) : "memory");
}

__attribute__((noipa)) int
foo (union U *p)
{
  bar ((char *) >c.b);
  return __builtin_strcmp (>f.d[2], "abcdefghijk") == 0;
}

int
main ()
{
  char *p = mmap (NULL, 131072, PROT_READ | PROT_WRITE,
  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (p == MAP_FAILED)
return 0;
  if (munmap (p + 65536, 65536) < 0)
return 0;
  union U *u;
  u = (union U *) (p + 65536 - sizeof (u->f));
  __builtin_memcpy (u->f.d, "abc", 4);
  u->f.e = 1;
  if (foo (u) != 0)
__builtin_abort ();
  return 0;
}

[Bug target/92758] [10 regression] r278833 breaks gcc.target/powerpc/fold-vec-splat-floatdouble.c

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Dec  3 14:47:24 2019
New Revision: 278938

URL: https://gcc.gnu.org/viewcvs?rev=278938=gcc=rev
Log:
2019-12-03  Richard Biener  

PR tree-optimization/92758
* tree-ssa-forwprop.c (simplify_vector_constructor): Restore
operation on uniform vectors.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug target/92758] [10 regression] r278833 breaks gcc.target/powerpc/fold-vec-splat-floatdouble.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Jeffrey A. Law from comment #8)
> Perhaps related to:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01874.html

Yes, that is pretty much the same thing.  One thing is whether it is safe or
unsafe to use what determine_min_objsize does for the purposes Qing introduced
(probably unsafe, if we e.g. consider what GCC uses for tree/rtl/gimple, unions
containing members with different sizes and where the mapped size is actually
just the size of the corresponding member; if VN would see first
>member.elt
of some larger element and then >smaller_member which has the same
address,
Qing's code could assume at least that many bytes are mapped and perform *_eq).
And another thing as the #c7 testcase shows that it is wrong to use minimum
object size, whatever exact definition it has, at least for code generation
purposes, it has to consider maximum object size instead, as the code tries to
optimize the str{,n}cmp into not equal if one object is small enough and the
other object is too large to fit in there.

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 3 Dec 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #10 from Jakub Jelinek  ---
> The vector builder calls operand_equal_p, which in turn does:
>   case REAL_CST:
> if (real_identical (_REAL_CST (arg0), _REAL_CST (arg1)))
>   return true;
> 
> 
> if (!HONOR_SIGNED_ZEROS (arg0))
>   {
> /* If we do not distinguish between signed and unsigned zero,
>consider them equal.  */
> if (real_zerop (arg0) && real_zerop (arg1))
>   return true;
>   }
> return false;
> So, what could be done is temporarily enable flag_signed_zeros in the vector
> builder.

Alternatively add another flag to operand_equal_p to say whether
exact literal equality is asked for.

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #8 from Jeffrey A. Law  ---
Perhaps related to:

https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01874.html

[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2019-11-19 00:00:00 |2019-12-3

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> The bug only seems to happen when the concept is variadic.

Or has a default argument, as in the dup I just reported:

template
concept one_or_two = true;

template
concept one = one_or_two;

template
constexpr void
foo()
{
  if (one) // OK
  { }

  if (one_or_two) // ERROR
  { }
}

gcc-8-branch accepts this with -fconcepts.

gcc-9-branch rejects it with -fconcepts:

92771.cc: In function 'constexpr void foo()':
92771.cc:14:20: error: expected unqualified-id before ')' token
   14 |   if (one_or_two) // ERROR
  |^


trunk accepts it with -std=gnu++14 -fconcepts (since r276764) but still rejects
it with -std=gnu++17 -fconcepts or -std=gnu++2a:

92771.cc: In function 'constexpr void foo()':
92771.cc:14:7: error: expected 'auto' or 'decltype(auto)' after 'one_or_two'
   14 |   if (one_or_two) // ERROR
  |   ^
92771.cc:14:20: error: expected unqualified-id before ')' token
   14 |   if (one_or_two) // ERROR
  |^

[Bug c++/67491] [meta-bug] concepts issues

[redi at gcc dot gnu.org]

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

Bug 92771 Summary: [9/10 Regression] Concept won't use default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92771

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
*** Bug 92771 has been marked as a duplicate of this bug. ***

[Bug c++/92771] [9/10 Regression] Concept won't use default template argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
Oh it's another manifestation of Bug 91073

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

[Bug libstdc++/92770] std::unordered_map requires both T and U to be fully declared

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Not a bug.

(In reply to Raphael Kubo da Costa from comment #0)
> The excerpt above works fine with libc++ and MSVC's STL.

Implementations might accept it as an extension or by lucky accident, but the
standard says it's undefined:
http://eel.is/c++draft/requirements#res.on.functions-2.5

For our implementation accepting it is not possible.

[Bug fortran/92754] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:693

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Created attachment 47407
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47407=edit
Lightly tested patch

(In reply to Martin Liška from comment #1)
> Confirmed, started with r218068, it was rejected before the revision.
Which is from 2014 - 5 years ago … I am not sure whether it then really makes
sense to add someone as CC :-)


The problem is that gfc_finish_var_decl's
690   else if (sym->module && !sym->attr.result && !sym->attr.dummy)
is evaluated as true for the 'max' function as sym->module is "(intrinsic)" but
it is still marked as sym->attr.flavor == FL_VARIABLE and sym->attr.function ==
0

Or in other words, gfc_intrinsic_func_interface does:

  expr->value.function.isym = specific;
  if (!expr->symtree->n.sym->module)
gfc_intrinsic_symbol (expr->symtree->n.sym);

which updates expr->value.function and sets expr->symtree->n.sym to intrinsic,
but otherwise,  expr->symtree->n.sym is still FL_UNKNOWN and attr.function = 0.

As this is now fine, resolve_unknown_f returns and nothing happens later. (The
expr type is expr->type == EXPR_CONST).


Something like the following seems to work. But one really needs to do
something like that for all gfc_intrinsic_func_interface calls, e.g. by adding
such a resolve call to gfc_intrinsic_func_interface itself.

[Bug c++/92771] [9/10 Regression] Concept won't use default template argument

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> trunk accepts with -fconcepts (?!?)

At r276764 it started to be accepted with -std=gnu++14 -fconcepts but is still
rejected with -std=gnu++17 -fconcepts or -std=gnu++2a -fconcepts. Odd.

[Bug c++/92771] [9/10 Regression] Concept won't use default template argument

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Reduced:

template
concept one_or_two = true;

template
concept one = one_or_two;

template
constexpr void
foo()
{
  if (one) // OK
  { }

  if (one_or_two) // ERROR
  { }
}

gcc-8-branch accepts this with -fconcepts.
gcc-9-branch rejects it with -fconcepts

92771.cc: In function 'constexpr void foo()':
92771.cc:14:20: error: expected unqualified-id before ')' token
   14 |   if (one_or_two) // ERROR
  |^


trunk accepts with -fconcepts (?!?) but not with -std=gnu++2a:

92771.cc: In function 'constexpr void foo()':
92771.cc:14:7: error: expected 'auto' or 'decltype(auto)' after 'one_or_two'
   14 |   if (one_or_two) // ERROR
  |   ^
92771.cc:14:20: error: expected unqualified-id before ')' token
   14 |   if (one_or_two) // ERROR
  |^

[Bug c++/92771] [9/10 Regression] Concept won't use default template argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-03
  Known to work||8.3.1
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0, 9.2.0, 9.2.1

[Bug c++/92771] New: [9/10 Regression] Concept won't use default template argument

[redi at gcc dot gnu.org]

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

Bug ID: 92771
   Summary: [9/10 Regression] Concept won't use default template
argument
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: paolo at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

template
concept three = sizeof(P) == sizeof(Q);

#ifdef WORKAROUND
template
concept two = three;
#define three two
#endif

template
constexpr auto
foo(const T& t, const U& u)
{
  if constexpr (three)
return  == 
  return false;
}

int main()
{
  return foo(1, 2);
}

Using -std=gnu++2a this fails to compile:

c3.cc: In function 'constexpr auto foo(const T&, const U&)':
c3.cc:14:17: error: expected 'auto' or 'decltype(auto)' after 'three'
   14 |   if constexpr (three)
  | ^~~
c3.cc:14:28: error: expected unqualified-id before ')' token
   14 |   if constexpr (three)
  |^

Defining WORKAROUND to add the indirection through 'two' fixes it.

This was accepted prior to r260482 (which was fixing PR c++/84588).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug libstdc++/92770] New: std::unordered_map requires both T and U to be fully declared

[raphael.kubo.da.costa at intel dot com]

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

Bug ID: 92770
   Summary: std::unordered_map requires both T and U to be
fully declared
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raphael.kubo.da.costa at intel dot com
  Target Milestone: ---

$ cat unordered_map.cc
#include 
struct S;
class C {
  std::unordered_map map_;
};

$ g++ -std=gnu++14 -c unordered_map.cc 
In file included from /usr/include/c++/9/unordered_map:43,
 from unordered_map.cc:1:
/usr/include/c++/9/bits/stl_pair.h: In instantiation of ‘struct std::pair’:
/usr/include/c++/9/ext/aligned_buffer.h:91:28:   required from ‘struct
__gnu_cxx::__aligned_buffer >’
/usr/include/c++/9/bits/hashtable_policy.h:233:43:   required from ‘struct
std::__detail::_Hash_node_value_base >’
/usr/include/c++/9/bits/hashtable_policy.h:264:12:   required from ‘struct
std::__detail::_Hash_node, true>’
/usr/include/c++/9/bits/hashtable_policy.h:2027:13:   required from ‘struct
std::__detail::_Hashtable_alloc, true> > >’
/usr/include/c++/9/bits/hashtable.h:173:11:   required from ‘class
std::_Hashtable, std::allocator >, std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >’
/usr/include/c++/9/bits/unordered_map.h:105:18:   required from ‘class
std::unordered_map’
unordered_map.cc:4:30:   required from here
/usr/include/c++/9/bits/stl_pair.h:214:11: error: ‘std::pair<_T1, _T2>::first’
has incomplete type
  214 |   _T1 first; /// @c first is a copy of the first
object
  |   ^
unordered_map.cc:2:8: note: forward declaration of ‘struct S’
2 | struct S;
  |

The excerpt above works fine with libc++ and MSVC's STL.

[Bug c++/81202] Concept parsing error for default template arguments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-03
 Blocks||67491
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Your spacebar seems to be broken, and your testcase is incomplete ("tple"?!)

Fixed:

template
  constexpr bool IsPtrC = true;

template concept bool IsPtrC2 = IsPtrC;

template using TEST = int;

TEST> i;// OK
TEST> j;   // error: parse error in template argument list
TEST> k; // OK
TEST<(IsPtrC2)> l; // OK

This is still rejected by current versions of GCC with -std=gnu++17 -fconcepts.

With GCC 8 and 9:

81202.cc:9:1: error: parse error in template argument list
9 | TEST> j;   // error: parse error in template argument
list
  | ^~~~
81202.cc:9:1: error: declaration does not declare anything [-fpermissive]


And with trunk:

81202.cc:9:17: error: type/value mismatch at argument 1 in template parameter
list for 'template using TEST = int'
9 | TEST> j;   // error: parse error in template argument
list
  | ^~
81202.cc:9:17: note:   expected a constant of type 'bool', got 'auto [requires
IsPtrC2<, int>]'


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
The vector builder calls operand_equal_p, which in turn does:
  case REAL_CST:
if (real_identical (_REAL_CST (arg0), _REAL_CST (arg1)))
  return true;


if (!HONOR_SIGNED_ZEROS (arg0))
  {
/* If we do not distinguish between signed and unsigned zero,
   consider them equal.  */
if (real_zerop (arg0) && real_zerop (arg1))
  return true;
  }
return false;
So, what could be done is temporarily enable flag_signed_zeros in the vector
builder.

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #8 from Alexander Monakov  ---
Previously, in PR 86999 I pointed out to the reporter that it was okay for gcc
to turn a vector constructor with negative zeros to a trivial
all-positive-zeros constructor under -fno-signed-zeros, and nobody contradicted
me at the time.

I think the documentation needs to be clarified if that's not the intent, right
now I cannot for sure deduce from the manual what exactly the optimizations may
or may not do when constant propagation or such produces a "negative zero"
value.

[Bug c++/92214] Unhelpful diagnostic for static_assert( some_concept(some_type) )

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Even more reduced:
#include 

__m128
foo (__m128 x)
{
  int f[4] __attribute__((aligned (16)))
= { 0x, 0x8000, 0x, 0x8000 };
  return _mm_xor_ps (x, *(__m128 *) f);
}

int
main ()
{
  __m128 a = { -1.0f, -1.0f, -1.0f, -1.0f };
  if (foo (a)[1] != 1.0)
__builtin_abort ();
  return 0;
}

Though, with -fno-signed-zeros, we say that the sign of a zero isn't
significant, but for this testcase it is very much significant.
So, maybe invalid?

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Possibly the ->equal_p () use in vector-builder elides the -0.0 since it
may appear "equal" to 0.0?

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> Even more reduced:
> #include 
> 
> __m128
> foo (__m128 x)
> {
>   int f[4] __attribute__((aligned (16)))
> = { 0x, 0x8000, 0x, 0x8000 };
>   return _mm_xor_ps (x, *(__m128 *) f);
> }
> 
> int
> main ()
> {
>   __m128 a = { -1.0f, -1.0f, -1.0f, -1.0f };
>   if (foo (a)[1] != 1.0)
> __builtin_abort ();
>   return 0;
> }
> 
> Though, with -fno-signed-zeros, we say that the sign of a zero isn't
> significant, but for this testcase it is very much significant.
> So, maybe invalid?

Well, clearly the testcase simply loads a vector which we do not expect
to alter bit-patterns.

The issue is that besides the new vector encoder stuff, that
native_interpret_expr can end up "normalizing" a FP number as well.

Note that various intrinsic docs suggest to use the matching
xor_ps variant if the main work is on float vectors while xor_pd
when working on integer vectors.

[Bug c/92769] New: No way to set CR0[SO] on function return

[christophe.le...@c-s.fr]

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

Bug ID: 92769
   Summary: No way to set CR0[SO] on function return
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.le...@c-s.fr
  Target Milestone: ---

Linux system calls and Linux VDSO calls require the error status to be
reflected through SO bit of CR0 register on function return.

There is no way to do that from C functions. This requires to add Assembly
trampoline functions just for that, with all associated drawbacks (adding a
stack frame to save LR, etc ...)

Would it be possible to add to builtin-functions which would set/clear SO on
function return ?

Something like:
- __builtin_ppc_return_with_so_set()
- __builtin_ppc_return_with_so_cleared()

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Started with r255474.

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Slightly cleaned up testcase:
#include 

struct S { int f[4]; };

__m128
foo (__m128 x)
{
  const struct S a = { {0x, 0x8000, 0x, 0x8000}};
  return _mm_xor_ps (x, _mm_load_ps ((float *) a.f));
}

int
main ()
{
  __m128 a = { -1.0f, -1.0f, -1.0f, -1.0f };
  if (foo  (a)[1] != 1.0)
__builtin_abort ();

  return 0;
}