[Bug fortran/99688] AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685

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

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

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

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

commit r9-9305-gcdce7732ed2c91f6cc73f83bf05ab971b9d0a62e
Author: Tobias Burnus 
Date:   Mon Mar 22 09:49:48 2021 +0100

Fortran: Fix 'name' bound size [PR99688]

gcc/fortran/ChangeLog:

PR fortran/99688
* match.c (select_type_set_tmp, gfc_match_select_type) Fix 'name'
buffersize to avoid out of bounds.
* resolve.c (resolve_select_type): Likewise.

(cherry picked from commit 0e792ee11aa6ebb6f61e9ed33eb06e260f0ec703)

[Bug fortran/99688] AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #6 from Tobias Burnus  ---
FIXED on mainline (GCC 11) and on GCC 9 and 10.

Martin: Thanks for running asan-bootstrap!
Harald: Thanks for the debugging/first patch!

[Bug other/86656] [meta-bug] Issues found with -fsanitize=address

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

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

Bug 99688 Summary: AddressSanitizer: stack-buffer-overflow on address at 
gfc_match_name(char*) gcc/fortran/match.c:685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688

   What|Removed |Added

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

[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated

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

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

--- Comment #34 from Jürgen Reuter  ---
(In reply to Paul Thomas from comment #33)
> (In reply to Jürgen Reuter from comment #32)
> > Ready for merge?
> 
> Hi Juergen,
> 
> Daytime work intervened. I will submit to the list today.
> 

Great!


> Thanks for all your support BTW.
> 

On the contrary, thanks for your continuous great support!

> Paul

[Bug tree-optimization/99726] [10/11 Regression] ICE in create_intersect_range_checks_index, at tree-data-ref.c:1855 since r10-4762-gf9d6338bd15ce1fae36bf25d3a0545e9678ddc58

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/96858] Many i386 testcases failed with different configured gcc on different hosts.

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #1 from Hongtao.liu  ---
.

[Bug tree-optimization/96244] Redudant mask load generated

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Hongtao.liu  ---
.

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #1 from Tamar Christina  ---
That testcase doesn't seem to compile.  It looks like some line numbering etc
snuck in.  Tried to repair it but don't know enough fortran to.

[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
(In reply to Richard Biener from comment #2)
> Do you have a working GCC version as well?
> 
> Please specify how you configured.

Hello. I know why the bug happens.

It looks like it is a bug when I use the attribute [[gnu::sysv_abi]] since I
want my parameters to be passed by value.

It has to be a bug related between the swap of [[gnu::ms_abi]] and
[[gnu::sysv_abi]].

However, it looks like swapping to ms_abi from sysv_abi will cleanup SIMD
registers. Is that correct?

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
(In reply to Tamar Christina from comment #1)
> That testcase doesn't seem to compile.  It looks like some line numbering
> etc snuck in.  Tried to repair it but don't know enough fortran to.

I can reproduce it. You likely named the file x.f90 (and not x.f). Please try
that..

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #3 from Martin Liška  ---
Do you want me to bisect that?

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #4 from Tamar Christina  ---
> I can reproduce it. You likely named the file x.f90 (and not x.f). Please try 
> that..

Aha.. Fortran such a mystery :)

> Do you want me to bisect that?

No, they'll all point to the commit which introduced the optabs, since that's
the one causing the vectorizer to go down this path.  But it won't be the
actual commit with the changes to the vectorizer.

[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|c++ |tree-optimization
   Last reconfirmed||2021-03-24

--- Comment #9 from Richard Biener  ---
The issue for store-motion is that we see an aggregate copy:

Unanalyzed memory reference 0: *d_28(D).lam1 = *d_28(D).lam2;

  __MEM  (d_28(D)).lam1 = __MEM 
(d_28(D)).lam2;
  __MEM  (d_28(D)).lam2.v = _38;
  il_36 = il_74 + 1ul;

there is another PR about those Unanalyzed refs preventing LIM/SM but then
getting rid of those aggregate copies would be nice as well since many
passes do not like them.  I suppose 'vtype' in this case has a FP mode
which prevents us from simplistic folding of this (unless we'd always
expand those to FP load/store sequences).

Indeed, we're copying

type 
unit-size 
align:256 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7437dbd0
fields 
public external autoinline decl_3 QI t.C:3:8 align:16
warn_if_not_align:0 context 
full-name "constexpr Tvsimple& Tvsimple::operator=(Tvsimple&&)
noexcept ()"
not-really-extern chain >
context 
full-name "struct Tvsimple"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  reference_to_this
 chain >

OK, so for a simple

struct X { double x; };

void foo (struct X *x, struct X *y)
{
  *x = *y;
}

we do generate x87 FP load/store insns and do not transfer bytes.  Probably
OK from a C language perspective but questionable on the GIMPLE side
(we've been there before).

So one thing we can experiment with is to gimplify those aggregate
copies to register load/store when the aggregates have been assigned
non-BLKmode by the target.  This might of course confuse SRA which
means that SRA itself might be a better place to perform this
optimization.  [mind struct { double; double; } on x86 gets TImode
for example]

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #5 from Martin Liška  ---
(In reply to Tamar Christina from comment #4)
> > I can reproduce it. You likely named the file x.f90 (and not x.f). Please 
> > try that..
> 
> Aha.. Fortran such a mystery :)

Yep, all black magic. Btw. one can convert the forms with:
https://github.com/ylikx/fortran-legacy-tools/blob/master/fixed2free/fixed2free2.py

> 
> > Do you want me to bisect that?
> 
> No, they'll all point to the commit which introduced the optabs, since
> that's the one causing the vectorizer to go down this path.  But it won't be
> the actual commit with the changes to the vectorizer.

Good, have fun.

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #6 from Martin Liška  ---
A bit reduced test-case:

SUBROUTINE CLAREF(A, WANTZ, Z, ICOL1, ITMP1, ITMP2, T1, T2, V2)
LOGICALBLOCK, WANTZ
COMPLEXT1, T2, V2
COMPLEXA(LDA, *), VECS, Z(LDA, *)
COMPLEXSUM 
LOGICALLSAME
IF (LSAME) THEN
  DO 30 K = ITMP1, ITMP2, 3
 T1 = VECS0
30   CONTINUE
ELSE
   IF (BLOCK) THEN
  DO 90 K = ITMP1, ITMP2 - 1, 3
 A(J, ICOL1) = ITMP1
 IF (WANTZ) THEN
DO 80 J = ITMP1, ITMP2
   SUM =  ICOL1
   Z(J, 3) = V23
80 CONTINUE
 END IF
90   CONTINUE
  DO 120 K = ITMP1, ITMP2
 V2 = VECS()
 DO 100 J = ITMP1, ITMP2
A(J, ICOL1) = A(J, ICOL1) - SUM
100  CONTINUE
 IF (WANTZ) THEN
DO 110 J = 1, 3
   SUM = Z(J, ICOL1)
   Z(J, ICOL1) = 0
110 CONTINUE
 END IF
 ICOL1 = ICOL1 + 1
120   CONTINUE
   ELSE
  DO 130 J = ITMP1, ITMP2
 SUM = T1 * A(J, ICOL1) + T2 * A(J, 1) + V2 * A(J, 2)
 A(J, ICOL1) = SUM
 A(J, ICOL1 + 2) = SUM * V1
130   CONTINUE
   END IF
END IF
END

[Bug tree-optimization/99739] [11 Regression] missing optimization of a repeated conditional

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
Whether we handle this or not at -O1 is quite dependent on short-circuiting
anyway - we only have jump threading at our hands at -O1 (we could consider
enabling non-iterating EVRP).

So I'm not sure this is an important regression.  At -O2 we end up with

   [local count: 1073741824]:
  _7 = i_2(D) != 0;
  _8 = j_3(D) != 0;
  _9 = _7 & _8;
  if (_9 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870911]:
  _23 = k_4(D) != 0;
  _24 = _7 & _23;
  _11 = _8 & _24;
  if (_11 != 0)
goto ; [94.27%]
  else
goto ; [5.73%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

where reassociation leaves redundant _9 on the plate.

[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types

[kretz at kde dot org via Gcc-bugs]

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

--- Comment #10 from Matthias Kretz (Vir)  ---
Is this the same issue:

struct A {
  double v;
};

struct B {
  double v;
  B& operator=(const B& rhs) {
  v = rhs.v;
  return *this;
  }
};

// 10 loads & stores
void f(A& a, const A& b) {
  for (int i = 0; i < 10; ++i) a = b;
}

// 1 load & store
void f(B& a, const B& b) {
  for (int i = 0; i < 10; ++i) a = b;
}

I.e. by turning the aggregate assignment into an explicit assignment of the
fundamental (including vector) type, the issue can be worked around.

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

--- Comment #1 from Richard Biener  ---
it's difficult to check all requirements so elsewhere I suggested to be
forgiving when inlining always-inline functions.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |11.0
Summary|ICE in  |[11 Regression] ICE in
   |vect_get_vec_defs_for_opera |vect_get_vec_defs_for_opera
   |nd, at  |nd, at
   |tree-vect-stmts.c:1450  |tree-vect-stmts.c:1450

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

Tamar Christina  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Tamar Christina  ---
reduced to

  SUBROUTINE CLAREF(A)
  LOGICALBLOCK
  COMPLEXT1 , V2
  COMPLEXA(LDA, *) , SUM
  LOGICALLSAME
  IF (LSAME) THEN
 IF (BLOCK) THEN
DO 130 J = ITMP1, ITMP2
   SUM = T1 * A(J, ICOL1) * A0 +
 $   V2 * A(J, 2)
   A(J, ICOL1) = -SUM
   A(J, 2) = SUM
  130   CONTINUE
 END IF
  END IF
  END

which produces the following SLP tree,

   node 0x4e150c0 (max_nunits=2, refcnt=1)
   op template: REALPART_EXPR <(*a_29(D))[_12]> = sum$real_60;
 stmt 0 REALPART_EXPR <(*a_29(D))[_12]> = sum$real_60;
 stmt 1 IMAGPART_EXPR <(*a_29(D))[_12]> = sum$imag_61;
 children 0x4e15720
   node 0x4e15720 (max_nunits=2, refcnt=1)
   op template: slp_patt_69 = .COMPLEX_FMA (sum$real_60, sum$real_60,
sum$real_60);
 stmt 0 sum$real_60 = _48 + _58;
 stmt 1 sum$imag_61 = _49 + _59;
 children 0x4e15500 0x4e15e08 0x4e15ad8
   node 0x4e15500 (max_nunits=2, refcnt=1)
   op template: _48 = a0_31(D) * _46;
 stmt 0 _48 = a0_31(D) * _46;
 stmt 1 _49 = a0_31(D) * _47;
 children 0x4e15588 0x4e151d0
   node (external) 0x4e15588 (max_nunits=1, refcnt=1)
 { a0_31(D), a0_31(D) }
   node 0x4e151d0 (max_nunits=2, refcnt=1)
   op template: slp_patt_71 = .COMPLEX_MUL (_46, _46);
 stmt 0 _46 = _42 - _43;
 stmt 1 _47 = _44 + _45;
 children 0x4e15038 0x4e15d80
   node (external) 0x4e15038 (max_nunits=1, refcnt=1)
 { t1$real_38(D), t1$imag_41(D) }
   node 0x4e15d80 (max_nunits=2, refcnt=2)
   op template: _17 = REALPART_EXPR <(*a_29(D))[_5]>;
 stmt 0 _17 = REALPART_EXPR <(*a_29(D))[_5]>;
 stmt 1 _16 = IMAGPART_EXPR <(*a_29(D))[_5]>;
 load permutation { 0 1 }
   node 0x4e15e08 (max_nunits=2, refcnt=2)
   op template: _50 = REALPART_EXPR <(*a_29(D))[_12]>;
 stmt 0 _50 = REALPART_EXPR <(*a_29(D))[_12]>;
 stmt 1 _51 = IMAGPART_EXPR <(*a_29(D))[_12]>;
 load permutation { 0 1 }
   node (external) 0x4e15ad8 (max_nunits=1, refcnt=1)
 { v2$real_52(D), v2$imag_53(D) }

which is correct, but vect_detect_hybrid_slp determines

   marking hybrid: slp_patt_71 = .COMPLEX_MUL (_46, _46);

Which is a problem since the patterns are only valid in SLP.

I don't quite see why the sub-tree is hybrid though.. it determines

   marking hybrid: _50 = REALPART_EXPR <(*a_29(D))[_12]>;
   marking hybrid: _51 = IMAGPART_EXPR <(*a_29(D))[_12]>;
   marking hybrid: _48 = a0_31(D) * _46;
   marking hybrid: slp_patt_71 = .COMPLEX_MUL (_46, _46);
   marking hybrid: sum$imag_61 = _49 + _59;
   marking hybrid: _49 = a0_31(D) * _47;
   marking hybrid: _59 = _56 + _57;
   marking hybrid: _56 = _50 * v2$imag_53(D);
   marking hybrid: _57 = _51 * v2$real_52(D);
   marking hybrid: _47 = _44 + _45;
   marking hybrid: _44 = _17 * t1$imag_41(D);
   marking hybrid: _45 = _16 * t1$real_38(D);
   marking hybrid: _16 = IMAGPART_EXPR <(*a_29(D))[_5]>;
   marking hybrid: _17 = REALPART_EXPR <(*a_29(D))[_5]>;

So either the vect_detect_hybrid_slp is correct but then SLP should be aborted
or it's not right and this should have been pure.

the problem starts because it marks _50 as hybrid, but don't see why it thinks
that...

[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #11 from rguenther at suse dot de  ---
On Wed, 24 Mar 2021, kretz at kde dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
> 
> --- Comment #10 from Matthias Kretz (Vir)  ---
> Is this the same issue:
> 
> struct A {
>   double v;
> };
> 
> struct B {
>   double v;
>   B& operator=(const B& rhs) {
>   v = rhs.v;
>   return *this;
>   }
> };
> 
> // 10 loads & stores
> void f(A& a, const A& b) {
>   for (int i = 0; i < 10; ++i) a = b;
> }
> 
> // 1 load & store
> void f(B& a, const B& b) {
>   for (int i = 0; i < 10; ++i) a = b;
> }
> 
> I.e. by turning the aggregate assignment into an explicit assignment of the
> fundamental (including vector) type, the issue can be worked around.

Yes, that's a good cut-down of the issue at hand.  Using
memcpy () for the assignment also tends to work since we inline
that using a load/store sequence if we can.

Note this might also point at a solution in the C++ FE and it's
default-generated copy/assign operations to copy the ultimate
single element there rather than the containing aggregate.
(one could argue that this would be premature optimization of course)

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
in ix86_can_inline_p

static bool
ix86_can_inline_p (tree caller, tree callee)
{
  tree caller_tree = DECL_FUNCTION_SPECIFIC_TARGET (caller);
  tree callee_tree = DECL_FUNCTION_SPECIFIC_TARGET (callee);
...
  if (!callee_tree)
callee_tree = target_option_default_node;
  if (!caller_tree)
caller_tree = target_option_default_node;
  if (callee_tree == caller_tree)
return true;

caller_tree is like:

-m64 -mfxsr -m128bit-long-double -mfp-ret-in-387 -mieee-fp
-mno-fancy-math-387 -mtls-direct-seg-refs -mvzeroupper -mstv
-mgeneral-regs-only -mfpmath=387

callee_tree is null, then it's assigned with target_option_default_node which
is like

-m64 -msse2 -msse -mmmx -mfxsr -m128bit-long-double -m80387 -mfp-ret-in-387
-mieee-fp -mtls-direct-seg-refs -mvzeroupper -mstv -mfpmath=sse

So should it's safe to inline when callee_tree is null?

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #8 from Richard Biener  ---
I'm testing the following:

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f1a2b5d60fa..762cba54bb5 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3770,6 +3770,20 @@ vect_slp_analyze_node_operations_1 (vec_info *vinfo,
slp_tree node,
   return false;
 }

+  /* ???  We're getting confused with pattern marking since the loop
+ vect part would need to use the original scalar stmts but we've
+ registered the SLP pattern as pattern stmt for those which isn't
+ technically correct.  Give up for now.  */
+  if (STMT_VINFO_SLP_VECT_ONLY_PATTERN (stmt_info)
+  && HYBRID_SLP_STMT (stmt_info))
+{
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"cannot do hybrid SLP on SLP pattern "
+"stmt %G", stmt_info->stmt);
+  return false;
+}
+
   bool dummy;
   return vect_analyze_stmt (vinfo, stmt_info, &dummy,
node, node_instance, cost_vec);

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #9 from Tamar Christina  ---
@Arseny,

Thanks for reporting these.

I wonder if whatever you're compiling is open source.  I'd love to fix some of
these cases properly in GCC 12.

[Bug c++/99246] [modules] ICE in write_location, at cp/module.cc:15687

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

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

--- Comment #3 from Alexander Lelyakin  ---
This ICE appeared again, gcc at commit
bf1f3168f474734400e7a97660d1e7dec664bca9:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bit
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header istream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bitset
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header new
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ciso646
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header thread
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex

In module imported at /usr/local/include/c++/11.0.1/sstream:38:1,
included from /usr/local/include/c++/11.0.1/regex:46:
/usr/local/include/c++/11.0.1/istream: note: unable to represent further
imported source locations
/usr/local/include/c++/11.0.1/regex: internal compiler error: in
write_location, at cp/module.cc:15642
0x6e02e9 module_state::write_location(bytes_out&, unsigned int)
../../gcc/gcc/cp/module.cc:15642
0xa60e13 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5894
0xa64244 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7044
0xa64244 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8926
0xa60314 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9124
0xa6462a trees_out::write_var_def(tree_node*)
../../gcc/gcc/cp/module.cc:11511
0xa658c5 module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
../../gcc/gcc/cp/module.cc:14697
0xa6721e module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17769
0xa67dff finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19883
0x9fb20b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5175
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug target/99748] New: MVE: Wrong code at -O0 with float to integer conversion

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

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

Bug ID: 99748
   Summary: MVE: Wrong code at -O0 with float to integer
conversion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

GCC miscompiles the following testcase:

int main() {
  float a = 1.0f;
  return (int)a != 1;
}

with -march=armv8.1-m.main+mve -mfloat-abi=hard. The program should return 0
but returns 1 when compiled with these options. Looking at the generated code:

main:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
push{r7, lr}
sub sp, sp, #8
add r7, sp, #0
mov r3, #1065353216
str r3, [r7, #4]@ float
vldr.32 s0, [r7, #4]
bl  __aeabi_f2iz
mov r3, r0
cmp r3, #1
ite ne
movne   r3, #1
moveq   r3, #0
uxtbr3, r3
mov r0, r3
addsr7, r7, #8
mov sp, r7
@ sp needed
pop {r7, pc}
.size   main, .-main

we use the aeabi_f2iz libcall to do the float to integer conversion, passing
the argument in the s0 (VFP) register. However, looking at the implementation
of aeabi_f2iz in libgcc/config/arm/ieee754-sf.S, the function appears to be
expecting its argument in the GPR r0. So we do the conversion on whatever
happens to be in r0 when the libcall is made.

[Bug target/99748] MVE: Wrong code at -O0 with float to integer conversion

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

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

--- Comment #1 from Alex Coplan  ---
I should have mentioned, I found this because a number of the execution tests
are failing when testing with --with-arch=armv8.1-m.main+mve --with-float=hard.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #10 from Arseny Solokha  ---
(In reply to Tamar Christina from comment #9)
> I wonder if whatever you're compiling is open source.  I'd love to fix some
> of these cases properly in GCC 12.

These Fortran snippets I've been filing this week are from SCALAPACK 2.0.2 as
found on Netlib[1].

[1] https://www.netlib.org/scalapack

[Bug target/99748] MVE: Wrong code at -O0 with float to integer conversion

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

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

--- Comment #2 from Alex Coplan  ---
GCC 10 also has the issue, so not a regression.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Tamar Christina from comment #7)
> the problem starts because it marks _50 as hybrid, but don't see why it
> thinks that...

Because

t.f:36:16: note:   Processing hybrid candidate : IMAGPART_EXPR
<(*a_117(D))[_73]> = _189;
t.f:36:16: note:   Found loop_vect sink: IMAGPART_EXPR <(*a_117(D))[_73]> =
_189;
t.f:36:16: note:   Processing hybrid candidate : REALPART_EXPR
<(*a_117(D))[_73]> = _188;
t.f:36:16: note:   Found loop_vect sink: REALPART_EXPR <(*a_117(D))[_73]> =
_188;

so there are not SLPed stores which makes the whole use-def chain of
_189 and _188 loop vectorized (and hybrid if it has common pieces using SLP
vectorization).

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

--- Comment #4 from Jakub Jelinek  ---
__SIZEOF_FLOAT128__ is predefined on all targets that have the __float128 type,
except for rs6000:
grep '"__float128"' */*
i386/i386-builtins.c:  lang_hooks.types.register_builtin_type
(float128_type_node, "__float128");
ia64/ia64.c: "__float128");
ia64/ia64.c:   "__float128");
pa/pa.c: "__float128");
rs6000/rs6000-c.c:  rs6000_define_or_undefine_macro (false, "__float128");
grep SIZEOF_FLOAT128 */*
i386/i386-c.c:  cpp_define (parse_in, "__SIZEOF_FLOAT128__=16");
ia64/ia64.h:builtin_define("__SIZEOF_FLOAT128__=16");\
pa/pa.h:   builtin_define("__SIZEOF_FLOAT128__=16");\
See also PR56540

[Bug target/99724] [11 Regression] CE in in extract_insn, at recog.c:2770

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

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

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

https://gcc.gnu.org/g:4f992de4f369e17b64a66246ec35bf75f41dc98d

commit r11-7814-g4f992de4f369e17b64a66246ec35bf75f41dc98d
Author: Jakub Jelinek 
Date:   Wed Mar 24 11:22:35 2021 +0100

arm: Fix some more vec-common.md patterns for iwmmxt [PR99724]

The following patch fixes similar issues as in PR98849;
in older gcc versions, the expanders were present in neon.md guarded
with TARGET_NEON, but they got moved to vec-common.md and guarded with
ARM_HAVE__ARITH so that they handle both MVE and Neon.
The macros are enabled for some modes even for iwmmxt which has some
vector support for those modes, but only limited.  In particular,
neither the one_cmpl, nor neg, nor movmisalign patterns are present.
For some reason I've failed to construct something that ICEs with
movmisalign, so that is not covered by the testsuite, but both
one_cmpl and neg ICE.

2021-03-24  Jakub Jelinek  

PR target/99724
* config/arm/vec-common.md (one_cmpl2, neg2,
movmisalign): Disable expanders for TARGET_REALLY_IWMMXT.

* gcc.target/arm/pr99724.c: New test.

[Bug target/99724] [11 Regression] CE in in extract_insn, at recog.c:2770

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #12 from Richard Biener  ---
Btw, the following also works as a fix but obviously I'm not in a position to
fully evaluate this.  That said, hybrid SLP detection was rewritten during
SLP pattern development so the requirement to hook things up as regular
pattern might no longer be there.

Tamar - can you fully test this on aarch64?  I see the testcase from this
PR being hybrid vectorized appropriately then.

diff --git a/gcc/tree-vect-slp-patterns.c b/gcc/tree-vect-slp-patterns.c
index 85f2d03754d..cdd61e9a5cf 100644
--- a/gcc/tree-vect-slp-patterns.c
+++ b/gcc/tree-vect-slp-patterns.c
@@ -571,14 +571,8 @@ complex_pattern::build (vec_info *vinfo)
   STMT_VINFO_RELEVANT (call_stmt_info) = vect_used_in_scope;
   STMT_SLP_TYPE (call_stmt_info) = pure_slp;

-  /* add_pattern_stmt can't be done in vect_mark_pattern_stmts because
-the non-SLP pattern matchers already have added the statement to VINFO
-by the time it is called.  Some of them need to modify the returned
-stmt_info.  vect_mark_pattern_stmts is called by recog_pattern and it
-would increase the size of each pattern with boilerplate code to make
-the call there.  */
-  vect_mark_pattern_stmts (vinfo, stmt_info, call_stmt,
-  SLP_TREE_VECTYPE (node));
+  gimple_set_bb (call_stmt, gimple_bb (stmt_info->stmt));
+  STMT_VINFO_VECTYPE (call_stmt_info) = SLP_TREE_VECTYPE (node);
   STMT_VINFO_SLP_VECT_ONLY_PATTERN (call_stmt_info) = true;

   /* Since we are replacing all the statements in the group with the same

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Looks like the same thing as PR98209.  Basically, that for always_inline we
don't know whether the implicitly set target/optimization flags (inherited from
command line rather than from explicit target pragmas or optimize/target
attributes) must be matched in the caller or not.  And we don't really track
what was from the command line and what was overridden.
For some functions we don't really care and want to inline them always no
matter if there are any optimize/target differences (e.g. the various glibc
-D_FORTIFY_SOURCE* functions), in other functions we care about the explicit
but not implicit flags, and in yet other we care about everything.

[Bug c++/99749] New: Error when using std::string in a module (versions 11.0.1 20210307, 11.0.1 20210314, and 11.0.1 20210321)

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

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

Bug ID: 99749
   Summary: Error when using std::string in a module (versions
11.0.1 20210307, 11.0.1 20210314, and 11.0.1 20210321)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.kox at commandoregel dot be
  Target Milestone: ---

Created attachment 50468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50468&action=edit
AirlineTicket example code from Professional C++ 5th Edition

When trying to compile the "AirlineTicket" example/exercise from the book
Professional C++ (5th edition by Marc Gregoire) I'm getting the following error
message when I use a std::string in my module.

The complete error is:
-
In file included from /opt/gcc-11/include/c++/11.0.1/string:55,
of module /opt/gcc-11/include/c++/11.0.1/string, imported at
AirlineTicket.cpp:3,
of module airline_ticket, imported at main.cpp:2:
/opt/gcc-11/include/c++/11.0.1/bits/basic_string.h: In function ‘int main()’:
/opt/gcc-11/include/c++/11.0.1/bits/basic_string.h:431:7: error:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ cannot be overloaded with
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
  431 |   basic_string()
  |   ^~~~
In file included from /opt/gcc-11/include/c++/11.0.1/string:55,
 from /opt/gcc-11/include/c++/11.0.1/bits/locale_classes.h:40,
 from /opt/gcc-11/include/c++/11.0.1/bits/ios_base.h:41,
 from /opt/gcc-11/include/c++/11.0.1/ios:42,
 from /opt/gcc-11/include/c++/11.0.1/ostream:38,
 from /opt/gcc-11/include/c++/11.0.1/iostream:39,
of module /opt/gcc-11/include/c++/11.0.1/iostream, imported at main.cpp:1:
/opt/gcc-11/include/c++/11.0.1/bits/basic_string.h:431:7: note: previous
declaration ‘std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string() [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]’
  431 |   basic_string()
  |   ^~~~
In file included from /opt/gcc-11/include/c++/11.0.1/string:55,
of module /opt/gcc-11/include/c++/11.0.1/string, imported at
AirlineTicket.cpp:3,
of module airline_ticket, imported at main.cpp:2:
/opt/gcc-11/include/c++/11.0.1/bits/basic_string.h:431:7: error:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ cannot be overloaded with
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
  431 |   basic_string()
  |   ^~~~
In file included from /opt/gcc-11/include/c++/11.0.1/string:55,
 from /opt/gcc-11/include/c++/11.0.1/bits/locale_classes.h:40,
 from /opt/gcc-11/include/c++/11.0.1/bits/ios_base.h:41,
 from /opt/gcc-11/include/c++/11.0.1/ios:42,
 from /opt/gcc-11/include/c++/11.0.1/ostream:38,
 from /opt/gcc-11/include/c++/11.0.1/iostream:39,
of module /opt/gcc-11/include/c++/11.0.1/iostream, imported at main.cpp:1:
/opt/gcc-11/include/c++/11.0.1/bits/basic_string.h:431:7: note: previous
declaration ‘std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string() [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]’
  431 |   basic_string()
  |   ^~~~
main.cpp:6:9: note: during load of binding ‘::AirlineTicket@airline_ticket’
6 | AirlineTicket myTicket;
  | ^
make: *** [Makefile:76: debug] Error 1
-

The code that I'm using is:
-
export module airline_ticket;

import;

export class AirlineTicket{
public:
AirlineTicket();
~AirlineTicket();

double calculatePriceInDollars()const;

std::string getPassengerName()const;
void setPassengerName(std::string name);

int getNumberOfMiles() const;
void setNumberOfMiles(int miles);

bool hasEliteSuperRewardsStatus() const;
void setHasEliteSuperRecardsStatus(bool status);

private:
std::string m_passengerName{};
int m_numberOfMiles{};
bool m_hasEliteSuperRewardsStatus{};
};

AirlineTicket::AirlineTicket() : m_passengerName{"Unknown Passenger"},
m_numberOfMiles{0},m_hasEliteSuperRewardsStatus{false}{}

AirlineTicket::~AirlineTicket() {}
double AirlineTicket::calculatePriceInDollars() const
{
if (hasEliteSuperRewardsStatus()) {
// Elite Super Rewards Customers fly for free.
return 0;   
   

[Bug c++/99750] New: gcc allow operator literal operator have default parameters

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99750
   Summary: gcc allow operator literal operator have default
parameters
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

constexpr auto operator""_s(const char*, unsigned long size = 2) {
  return size;
}
static_assert(operator""_s(nullptr) == 2);

https://godbolt.org/z/x3YjPT8vd

[Bug tree-optimization/99751] New: wrong code at -O1

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 99751
   Summary: wrong code at -O1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[549] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210324 (experimental) [master revision
be70bb5e4ba:220fd7ed5f2:bf1f3168f474734400e7a97660d1e7dec664bca9] (GCC) 
[550] % 
[550] % gcctk -O0 small.c; ./a.out
[551] % 
[551] % gcctk -O1 small.c
[552] % ./a.out
Aborted
[553] % 
[553] % cat small.c
int *a, **c = &a;
int *b(int *d) { return d; }
void e(int *d) { *c = b(d); }
int main() {
  int f = (e(&f), 0);
  if (a != &f)
__builtin_abort();
  return 0;
}

[Bug tree-optimization/99751] [11 Regression] wrong code at -O1

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-24
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
  Known to work||10.2.1
   Keywords||wrong-code
Summary|wrong code at -O1   |[11 Regression] wrong code
   ||at -O1
Version|unknown |11.0

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

[Bug tree-optimization/99751] [11 Regression] wrong code at -O1

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
-fno-ipa-modref fixes it

[Bug c++/95615] [coroutines] Coroutine frame and promise is leaked if exception thrown from promise.initial_suspend()

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Sandoe  ---
so fixed for master and 10.3.

[Bug c++/98118] [coroutines] ICE with coroutine with parameter with non-trivial destructor since r10-6876-gdc192bbdd0442f75

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Sandoe  ---
fixed for master and 10.3

[Bug ipa/99751] [11 Regression] wrong code at -O1

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |ipa
   Priority|P3  |P1
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
And -fno-inline-small-functions makes it appear at -O2 as well.

[Bug ipa/99751] [11 Regression] wrong code at -O1

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

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

--- Comment #4 from Jakub Jelinek  ---
Started with r11-5391-gbb07490abba850fd5b1d2d09d76d18b8bdc7d817

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

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

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

Bug 96749 Summary: [coroutines] unexpected 'warning: statement has no effect 
[-Wunused-value]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749

   What|Removed |Added

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

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

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Sandoe  ---
fixed for master and 10.3

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

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
fixed (according to the current agreement about done = true being set for a
coroutine suspended just before the promise lifetime end) for 10.3 and master.

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

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Sandoe  ---
fixed for master and 10.3.

[Bug c++/99047] ICE on simple task coroutine example

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
fixed for master and 10.3

[Bug c++/95822] [coroutines] compiler internal error with local object with noexcept false destructor

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Sandoe  ---
fixed for master and 10.3

[Bug c++/97587] [coroutines] promise_type constructor is called with original parameters, not parameter copies

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Sandoe  ---
fixed for master and 10.3

[Bug c++/95616] [coroutines] coroutines with potentially-throwing 'co_await promise.final_suspend()' expressions should be ill-formed

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Sandoe  ---
fixed for master and 10.3.

[Bug ipa/99751] [11 Regression] wrong code at -O1

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

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

--- Comment #5 from Richard Biener  ---
  parm 0 flags: nodirectescape
void e (int * d)
{
  int * * c.0_1;
  int * _2;

   :
  c.0_1 = c;
  _2 = b (d_4(D));
  *c.0_1 = _2;
  return;

is wrong, it does escape through the *c store.  I suppose b (d) is "wrong"
somehow, the escape through the return is not mentioned:

  parm 0 flags: direct noclobber noescape nodirectescape
int * b (int * d)
{
   :
  return d_1(D);

[Bug target/65847] SSE2 code for adding two structs is much worse at -O3 than at -O2

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

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

--- Comment #3 from Richard Biener  ---
Similarly

struct X { int a; int b; int c; int d; };

struct X foo (struct X x, struct X y)
{
  struct X res;
  res.a = x.a + y.a;
  res.b = x.b + y.b;
  res.c = x.c + y.c;
  res.d = x.d + y.d;
  return res;
}

is vectorized as

foo:
.LFB0:
.cfi_startproc
movq%rdi, -40(%rsp)
movq%rsi, -32(%rsp)
movdqa  -40(%rsp), %xmm0
movq%rdx, -24(%rsp)
movq%rcx, -16(%rsp)
paddd   -24(%rsp), %xmm0
movaps  %xmm0, -40(%rsp)
movq-40(%rsp), %rax
movq-32(%rsp), %rdx
ret

which is bad because the on-stack construction of %xmm0 causes a STLF fail.
Unvectorized code isn't necessarily worse, but the vectorized sequence
can be improved 

foo:
.LFB0:
.cfi_startproc
movq%rdi, %rax
movq%rdi, %r10
movq%rdx, %rdi
movq%rsi, %r9
sarq$32, %r10
sarq$32, %rdi
addl%edx, %eax
movq%rcx, %r8
addl%r10d, %edi
sarq$32, %r9
movl%eax, %eax
leal(%rsi,%rcx), %edx
movl%edi, %edi
sarq$32, %r8
salq$32, %rdi
orq %rdi, %rax
leal(%r9,%r8), %edi
salq$32, %rdi
orq %rdi, %rdx
ret

in this case the spill is caused by LRA not knowing how to re-load
the TImode reg build by pieces by the RTL expansion code.

[Bug ipa/98834] [10 Regression] Code path incorrectly determined to be unreachable

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
Mine for a backport.

[Bug c++/99750] gcc allow operator literal operator have default parameters

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #56 from jyong at gcc dot gnu.org ---
OK, I've tested the patch from attachment 50461, seems to work fine:
gcc uses dwarf 4 by default if it does find a broken linker, but allows the
user to specify -gdwarf-5 if they want, resulting in a broken executable.
If the linker was found to be working at build time, dwarf-5 would be default.

I prefer the non-noisy patch because gcc doesn't actually detect the linker bug
at runtime, just silently doing what it thinks is best, which may not be
accurate if the user upgrades or downgrades binutils without a rebuild.

[Bug sanitizer/96318] FAIL: c-c++-common/asan/strncpy-overflow-1.c * output pattern test with C on Darwin

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Target Milestone|--- |9.4

--- Comment #3 from Iain Sandoe  ---
I fixed this for master, but failed to mention the PR number.

r11-7704-gc86c5195c8c02f58

Part of the problem is that Darwin defaults to _FORTIFY_SOURCE if that is not
explicitly given, and this results in the substitution of _chk builtins.  This
means that the disabling of the regular builtins fails (and we never have the
call expected).

That's fixable by adding -D _FORTIFY_SOURCE=0 to the command line.

The other part of the issue is that the system address symboliser (atos) is not
consuming the debug / frame information we are producing.  At present, it's not
clear if that's a GCC debug bug or an atos bug.  Adding "-gdwarf-3" is
sufficient to fix things in this case and is functional for the test-case.

Investigation of the debug etc. will need to be deferred to the next stage1 and
I am leaving this PR open, since the problem also exists on 10.x and 9.x (I
will back port to at least 10.x).

[Bug libstdc++/99752] New: ranges::find_end should return empty subrange when search range is empty

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99752
   Summary: ranges::find_end should return empty subrange when
search range is empty
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

In ranges::find_end implementation:

674 else
675   {
676 auto __i = ranges::next(__first1, __last1);
677 if (__first2 == __last2)
678   return {__i, __i};

when the examined range is not bidirectional_range and the search range is
empty, we still do the ranges::next call, this makes the following code
infinite loop:

#include 
#include 

int main() {
  auto r = std::views::iota(0);
  std::ranges::empty_view e;
  std::ranges::find_end(r, e);
}

But according to the [alg.find.end]: "i be last1 if [first2, last2) is empty", 
so I think this is a library bug since in such case ranges::find_end never
return.

Same situations in ranges::rotate with performance loss in more rare
conditions:

1573  {
1574auto __lasti = ranges::next(__first, __last);
1575if (__first == __middle)
1576  return {__lasti, __lasti};
1577if (__last == __middle)
1578  return {std::move(__first), std::move(__lasti)};

[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:79cdbabbc4cbf79491c274220928406dff3d4039

commit r11-7816-g79cdbabbc4cbf79491c274220928406dff3d4039
Author: Christophe Lyon 
Date:   Wed Mar 24 08:51:41 2021 +

arm: Fix MVE constraints for movmisalign [PR target/99727]

MVE has different constraints than Neon for load/store: we should use
the Ux constraint instead of Um.

2021-03-24  Christophe Lyon  

PR target/99727
gcc/
* config/arm/mve.md (movmisalign_mve_store): Use Ux
constraint.
(movmisalign_mve_load): Likewise.

gcc/testsuite/
* gcc.target/arm/pr99727.c: New test.

[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #4 from Christophe Lyon  ---
Fixed

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

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

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

Jonathan Wakely  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/libstdc++/2021-March/052
   ||237.html
   Target Milestone|--- |12.0

--- Comment #16 from Jonathan Wakely  ---
Partial fix attached to
https://gcc.gnu.org/pipermail/libstdc++/2021-March/052237.html

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

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

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

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

https://gcc.gnu.org/g:73d1e612011f1781275c7504c4fa5c365c0c3ddd

commit r10-9525-g73d1e612011f1781275c7504c4fa5c365c0c3ddd
Author: Richard Biener 
Date:   Mon Mar 22 11:09:46 2021 +0100

tree-optimization/99694 - fix value-numbering PHIs

This avoids endless cycling when a PHI node with unchanged backedge
value (the PHI result appearing there) is subject to CSE since doing
that effectively alters the hash entry.  The way to avoid this is
to ignore such edges when processing the PHI node.

2021-03-22  Richard Biener  

PR tree-optimization/99694
* tree-ssa-sccvn.c (visit_phi): Ignore edges with the
PHI result.

* gcc.dg/torture/pr99694.c: New testcase.

(cherry picked from commit b931e4792b8696f3da69f70988720c4d1ec6142a)

[Bug lto/96591] [8/9/10 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams

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

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

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

https://gcc.gnu.org/g:277fbd0748279cfcb241eff7c4d5ef93afbfbafd

commit r10-9526-g277fbd0748279cfcb241eff7c4d5ef93afbfbafd
Author: Richard Biener 
Date:   Mon Feb 8 09:52:56 2021 +0100

lto/96591 - walk VECTOR_CST elements in walk_tree

This implements walking of VECTOR_CST elements in walk_tree, mimicing
the walk of COMPLEX_CST elements.  Without this free-lang-data fails
to see some types in case they are only refered to via tree constants
used only as VECTOR_CST elements.

2021-02-08  Richard Biener  

PR lto/96591
* tree.c (walk_tree_1): Walk VECTOR_CST elements.

* g++.dg/lto/pr96591_0.C: New testcase.

(cherry picked from commit d4536e431316b4568e236afd7a6017e5efd1b0a1)

[Bug ipa/98834] [10 Regression] Code path incorrectly determined to be unreachable

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:592388d4f6e8a6adb470428fef6195694f4a3dce

commit r10-9527-g592388d4f6e8a6adb470428fef6195694f4a3dce
Author: Richard Biener 
Date:   Mon Mar 15 13:44:07 2021 +0100

tree-optimization/98834 - fix optimization regression with _b_c_p

The following makes FRE optimize a load we formerly required
SRA + CCP for which now run after we get rid of all __builtin_constant_p
calls.

2021-03-15  Richard Biener  

PR tree-optimization/98834
* tree-ssa-sccvn.c (vn_reference_lookup_3): Handle missing
subsetting by truncating the access size.

* g++.dg/opt/pr98834.C: New testcase.

(cherry picked from commit 99415d0f18716deeaa8d80e929b1337968cdfa23)

[Bug ipa/98834] [10 Regression] Code path incorrectly determined to be unreachable

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689

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

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

--- Comment #5 from Alex Coplan  ---
Thanks for the quick fix :)

[Bug testsuite/98894] New test case experimental/simd/standard_abi_usable.cc in r11-6935 fails on power 7

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
This was committed last month as r11-7071

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #9 from Iain Sandoe  ---
fixed for 10.x+
as noted in comment #2 the invoke.texi is correct as is.

[Bug libstdc++/99752] ranges::find_end should return empty subrange when search range is empty

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
My pardon, since the ranges::find_end return type is ranges::subrange, we
still to get the common last1 iterator through the ranges::next call, so this
seems not a bug.

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Segher Boessenkool from comment #3)
> In an ideal world the user can just assume those types exist always.  In a
> less ideal world, use autoconf?  You have to anyway, if you want to support
> older compilers at all.

Libstdc++ headers cannot use autoconf to check for features in a compiler that
users run on their own machine.

Libstdc++ needs to know whether types such as __float128 and __ibm128 are
defined **by the compiler that happens to be including the headers**. That
might be GCC (in which case we have complete knowledge about what types it
defines) or it could be an arbitrary version of clang. For the latter case we
cannot run autoconf to probe the user's clang version because libstdc++ has
already been installed. We need clang to expose macros that say which types are
defined, and obviously it would be preferable for gcc and clang to agree on
which macros are used for which types.

Arguably a __SIZEOF_xxx__ macro isn't a very sensible macro for types where the
type has a guaranteed size, but we need *something* that says the type exists.
Since all other targets already use __SIZEOF_xxx__ to say that the type exists,
it would be consistent and helpful for powerpc to do the same.

[Bug libstdc++/99752] ranges::find_end should return empty subrange when search range is empty

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #2 from 康桓瑋  ---
Since the ranges::find_end return type is ranges::subrange, we still to get
the common last1 iterator through the ranges::next call, so this seems not a
bug.

[Bug target/99753] New: [11 Regression] ICE in ix86_target_macros_internal, at config/i386/i386-c.c:250 since r11-5757-g3e2ae3ee285a5745

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

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

Bug ID: 99753
   Summary: [11 Regression] ICE in ix86_target_macros_internal, at
config/i386/i386-c.c:250 since
r11-5757-g3e2ae3ee285a5745
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

The following fails:

$ gcc -march=amd ~/Programming/testcases/a.c -m32 -c
: internal compiler error: in ix86_target_macros_internal, at
config/i386/i386-c.c:250
0x657e49 ix86_target_macros_internal
/home/marxin/Programming/gcc/gcc/config/i386/i386-c.c:250
0x96c24c ix86_target_macros()
/home/marxin/Programming/gcc/gcc/config/i386/i386-c.c:770
0x91d3d7 c_cpp_builtins(cpp_reader*)
/home/marxin/Programming/gcc/gcc/c-family/c-cppbuiltin.c:1498
0x9382fe c_finish_options
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1467
0x93b201 c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I've got a patch for it.

[Bug target/99753] [11 Regression] ICE in ix86_target_macros_internal, at config/i386/i386-c.c:250 since r11-5757-g3e2ae3ee285a5745

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug libstdc++/99752] ranges::find_end should return empty subrange when search range is empty

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

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

--- Comment #3 from Jonathan Wakely  ---
Your example is an infinite loop because you're asking for the last occurrence
of e in an infinite range. There is no end of an infinite range.

[Bug target/99753] [11 Regression] ICE in ix86_target_macros_internal, at config/i386/i386-c.c:250 since r11-5757-g3e2ae3ee285a5745

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
  Known to fail||11.0
  Known to work||10.2.0

[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug c++/99745] ICE when parameter pack not expanded in bit field

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #13 from Tamar Christina  ---
(In reply to Arseny Solokha from comment #10)
> (In reply to Tamar Christina from comment #9)
> > I wonder if whatever you're compiling is open source.  I'd love to fix some
> > of these cases properly in GCC 12.
> 
> These Fortran snippets I've been filing this week are from SCALAPACK 2.0.2
> as found on Netlib[1].
> 
> [1] https://www.netlib.org/scalapack

Thanks! This looks like a useful target to improve this with in GCC 12.  But am
I missing an option here?:

CC=~/gcc-base/install/bin/gcc \
FC=~/gcc-base/install/bin/gfortran \
CXX=~/gcc-base/install/bin/g++ \
CFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
CXXFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
FFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
cmake .. && make -j

I can't seem to get it to trigger the crash (or even detect the pattern).

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

--- Comment #14 from Tamar Christina  ---
(In reply to Richard Biener from comment #12)
> Btw, the following also works as a fix but obviously I'm not in a position
> to fully evaluate this.  That said, hybrid SLP detection was rewritten during
> SLP pattern development so the requirement to hook things up as regular
> pattern might no longer be there.
> 
> Tamar - can you fully test this on aarch64?  I see the testcase from this
> PR being hybrid vectorized appropriately then.
> 

Done, testsuite and local tests are clean :)

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-24
   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-March/5
   ||67255.html

--- Comment #4 from H.J. Lu  ---
A patch has been posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567255.html

[Bug target/99754] New: [sse2] new _mm_loadu_si16 and _mm_loadu_si32 implemented incorrectly

[evan--- via Gcc-bugs]

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

Bug ID: 99754
   Summary: [sse2] new _mm_loadu_si16 and _mm_loadu_si32
implemented incorrectly
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Created attachment 50470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50470&action=edit
Trivial patch

_mm_loadu_si16 and _mm_loadu_si32 were implemented in GCC 11, but incorrectly. 
The value pointed to by the argument is supposed to go in the first element,
but _mm_set_epi16 / _mm_set_epi32 reverse the argument order so in GCC they go
in the *last* elemement.

The most straightforward solution would be to change the _mm_set_* calls so the
input is used for the last argument instead of the first (patch attached).

FWIW, here is LLVM's implementation:
.
I've verified that LLVM's implementation matches ICC's.

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

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:7e1c6d7a53a64fdca23b2299b43f57f7a1dece74

commit r10-9528-g7e1c6d7a53a64fdca23b2299b43f57f7a1dece74
Author: Richard Sandiford 
Date:   Wed Mar 24 19:18:02 2021 +

aarch64: Make aarch64_add_offset work with -ftrapv [PR99540]

aarch64_add_offset uses expand_mult to multiply the SVE VL by an
out-of-range constant.  expand_mult takes an argument to indicate
whether the multiplication is signed or unsigned, but in this
context the multiplication is effectively signless and so the
choice seemed arbitrary.

However, one of the things that the signedness input does is
indicate whether signed overflow should be trapped for -ftrapv.
We don't want that here, so we must treat the multiplication
as unsigned.

gcc/
2021-03-24  Jakub Jelinek  

PR target/99540
* config/aarch64/aarch64.c (aarch64_add_offset): Tell
expand_mult to perform an unsigned rather than a signed
multiplication.

gcc/testsuite/
2021-03-24  Richard Sandiford  

PR target/99540
* gcc.dg/vect/pr99540.c: New test.

[Bug c++/99735] [modules] in system headers: non-template type ‘rebind_alloc’ used as a template

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

path.h:1133:66: error: non-template type
‘rebind_alloc’ used as a template
/usr/local/include/c++/11.0.1/filesystem: warning: not writing module
‘/usr/local/include/c++/11.0.1/filesystem’ due to errors

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

[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r11-7817-gf225c6b0c50dc472e0b73b440b572a3bf1514020
Author: Martin Jambor 
Date:   Wed Mar 24 20:27:27 2021 +0100

ipa: Check that scalar types that IPA-CP comes up with are sane (PR99122)

This patch fixes the last bit of PR 99122 where various bits of IPA
infrastructure are presented with a program with type mismatches that
make it have undefined behavior, and when inlining or performing
IPA-CP, and encountering such mismatch, we basically try to
VIEW_CONVERT_EXPR whatever the caller has into whatever the callee has
or simply use an empty constructor if that cannot be done.  This
however does not work when the callee has VLA parameters because we
ICE in the process.

Richi has already disabled inlining for such cases, this patch avoids
the issue in IPA-CP.  It adds checks that whatever constant the
propagation arrived at is actually compatible or fold_convertible to
the callees formal parameer type.  Unlike in the past, we now have
types of all parameters of functions that we have analyzed, even with
LTO, and so can do it.

This should prevent only bogus propagations.  I have looked at the
effect of the patch on WPA of Firefox and did not have any.

I have bootstrapped and LTO bootstrapped and tested the patch on
x86_64-linux.  OK for trunk?  And perhaps later for GCC 10 too?

Thanks

gcc/ChangeLog:

2021-02-26  Martin Jambor  

PR ipa/99122
* ipa-cp.c (initialize_node_lattices): Mark as bottom all
parameters with unknown type.
(ipacp_value_safe_for_type): New function.
(propagate_vals_across_arith_jfunc): Verify that the constant type
can be used for a type of the formal parameter.
(propagate_vals_across_ancestor): Likewise.
(propagate_scalar_across_jump_function): Likewise.  Pass the type
also to propagate_vals_across_ancestor.

gcc/testsuite/ChangeLog:

2021-02-26  Martin Jambor  

PR ipa/99122
* gcc.dg/pr99122-3.c: Remove -fno-ipa-cp from options.

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

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

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

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

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string_view
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header deque
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable

In file included from /usr/local/include/c++/11.0.1/semaphore:35,
 from /usr/local/include/c++/11.0.1/stop_token:37,
 from /usr/local/include/c++/11.0.1/condition_variable:47:
/usr/local/include/c++/11.0.1/bits/semaphore_base.h: In instantiation of
‘struct std::__atomic_semaphore’:
/usr/local/include/c++/11.0.1/bits/semaphore_base.h:292:45:   required from
here
/usr/local/include/c++/11.0.1/bits/semaphore_base.h:172:23: error: non-constant
condition for static assertion
  171 |   static_assert(__gnu_cxx::__int_traits<_Tp>::__max
  |   ~
  172 |   <= __gnu_cxx::__int_traits::__max);
  |   ^~~~
/usr/local/include/c++/11.0.1/bits/semaphore_base.h:172:23: error: the value of
‘__gnu_cxx::__numeric_traits_integer::__max’ is not usable in a
constant expression
In file included from /usr/local/include/c++/11.0.1/bits/stl_algobase.h:63,
 from /usr/local/include/c++/11.0.1/bits/char_traits.h:39,
 from /usr/local/include/c++/11.0.1/string_view:41,
of module /usr/local/include/c++/11.0.1/string_view, imported at
/usr/local/include/c++/11.0.1/bits/basic_string.h:48,
included from /usr/local/include/c++/11.0.1/string:55,
of module /usr/local/include/c++/11.0.1/string, imported at
/usr/local/include/c++/11.0.1/stdexcept:39,
included from /usr/local/include/c++/11.0.1/system_error:41,
 from /usr/local/include/c++/11.0.1/bits/std_mutex.h:39,
 from /usr/local/include/c++/11.0.1/condition_variable:40:
/usr/local/include/c++/11.0.1/ext/numeric_traits.h:75:27: note:
‘__gnu_cxx::__numeric_traits_integer::__max’ was not initialized with
a constant expression
   75 |   static const _Value __max = __is_signed
  |   ^
/usr/local/include/c++/11.0.1/condition_variable: warning: not writing module
‘/usr/local/include/c++/11.0.1/condition_variable’ due to errors

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

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[rogero at howzatt dot co.uk via Gcc-bugs]

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

--- Comment #57 from Roger Orr  ---
I've also confirmed the "non-noisy" patch  when used with binutils 2.35.2
(Sadly I've not yet manged to build binutils from source to try dwarf-5 with
the fix)

Many thanks.

I believe the "noisy" patch needs an edit in the line:

@@ -1861,6 +1861,15 @@ ix86_option_override_internal (bool main

which should be

@@ -1861,6 +1861,21 @@ ix86_option_override_internal (bool main

(at least, I can't apply it without that change...)

[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data

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

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

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

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header system_error
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header complex

In module imported at /usr/local/include/c++/11.0.1/ios:43:1,
included from /usr/local/include/c++/11.0.1/istream:38,
 from /usr/local/include/c++/11.0.1/sstream:38,
 from /usr/local/include/c++/11.0.1/complex:45:
/usr/local/include/c++/11.0.1/streambuf: error: failed to read compiled module
cluster 1269: Bad file data
/usr/local/include/c++/11.0.1/streambuf: note: compiled module file is
‘gcm.cache/./usr/local/include/c++/11.0.1/streambuf.gcm’
In file included from /usr/local/include/c++/11.0.1/string:55,
 from /usr/local/include/c++/11.0.1/bits/locale_classes.h:40,
 from /usr/local/include/c++/11.0.1/bits/ios_base.h:41,
 from /usr/local/include/c++/11.0.1/ios:42,
 from /usr/local/include/c++/11.0.1/istream:38,
 from /usr/local/include/c++/11.0.1/sstream:38,
 from /usr/local/include/c++/11.0.1/complex:45:
/usr/local/include/c++/11.0.1/bits/basic_string.h:6608:54: fatal error: failed
to load pendings for ‘__gnu_cxx::__stoa’
 6608 | __idx, __base); }
  |  ^
compilation terminated.

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

[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584

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

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

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

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

In file included from /usr/local/include/c++/11.0.1/bits/ios_base.h:41,
 from /usr/local/include/c++/11.0.1/ios:42,
 from /usr/local/include/c++/11.0.1/ostream:38,
 from /usr/local/include/c++/11.0.1/bits/unique_ptr.h:42,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:59,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/condition_variable:43:
/usr/local/include/c++/11.0.1/bits/locale_classes.h:163:23: internal compiler
error: in install_entity, at cp/module.cc:7457
  163 | locale(const std::string& __s) : locale(__s.c_str()) { }
  |   ^~
0xa68138 trees_in::install_entity(tree_node*)
../../gcc/gcc/cp/module.cc:7457
0xa7063b trees_in::decl_value()
../../gcc/gcc/cp/module.cc:8009
0xa69017 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9189
0xa6f61b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14846
0xa6fb1d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18117
0xa6fbdf module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18778
0xa69e80 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9700
0xa6b4d2 trees_in::lang_decl_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6860
0xa703ea trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7053
0xa703ea trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7962
0xa69017 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9189
0xa6a1cc trees_in::chained_decls()
../../gcc/gcc/cp/module.cc:4832
0xa6af79 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6534
0xa686e7 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7051
0xa686e7 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8966
0xa68b1f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9184
0xa6af87 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6536
0xa686e7 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7051
0xa686e7 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8966
0xa68b1f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9184
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

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

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

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

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

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cwchar
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future

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

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

[Bug target/99753] [11 Regression] ICE in ix86_target_macros_internal, at config/i386/i386-c.c:250 since r11-5757-g3e2ae3ee285a5745

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:4f00c4d40a539360938607561460904663c64cda

commit r11-7818-g4f00c4d40a539360938607561460904663c64cda
Author: Martin Liska 
Date:   Wed Mar 24 15:58:03 2021 +0100

i386: fix -march=amd crash

It started with g:3e2ae3ee285a57455d5a23bd352a68c289130186 where
new entry was added to processor_alias_table after generic node:

+  {"amdfam19h", PROCESSOR_GENERIC, CPU_GENERIC, 0,
+M_CPU_TYPE (AMDFAM19H), P_NONE},

and then the following is violated:

/* NB: processor_alias_table stops at the "generic" entry.  */

gcc/ChangeLog:

PR target/99753
* common/config/i386/i386-common.c (ARRAY_SIZE): Fix off-by-one
error.
* config/i386/i386-options.c (ix86_option_override_internal):
Add run-time assert.

gcc/testsuite/ChangeLog:

PR target/99753
* gcc.target/i386/pr99753.c: New test.

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

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

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

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

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string_view
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header mutex
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future

In file included from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:53,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/condition_variable:43,
 from /usr/local/include/c++/11.0.1/future:39:
/usr/local/include/c++/11.0.1/bits/allocated_ptr.h:48:32: internal compiler
error: in assert_definition, at cp/module.cc:4484
   48 |   using pointer = typename allocator_traits<_Alloc>::pointer;
  |^~~~
0x6e204d trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4484
0xa5d810 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11362
0xa6d497 trees_in::read_var_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11550
0xa6f4a1 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14855
0xa6fb1d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18117
0xa6fbdf module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18778
0xa69e80 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9700
0xa6a921 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6407
0xa686e7 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7051
0xa686e7 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8966
0xa68b1f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9184
0xa6a921 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6407
0xa686e7 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7051
0xa686e7 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8966
0xa68b1f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9184
0xa6b072 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6615
0xa686e7 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7051
0xa686e7 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8966
0xa68b1f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9184
0xa6b080 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6616
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug target/99753] [11 Regression] ICE in ix86_target_macros_internal, at config/i386/i386-c.c:250 since r11-5757-g3e2ae3ee285a5745

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits

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

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

--- Comment #5 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #3)
> If the non-constant vec_set can't be supported when
> !(TARGET_P8_VECTOR && TARGET_DIRECT_MOVE_64BIT)

I don't see why not?  It may need different code, sure, but that is much
preferable over contorting the rest of the backend.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #27 from Iain Sandoe  ---
bootstrap with Apple GCC-4.2.1 for gcc-10 works as of r10-9528

NOTE: GCC-11 requires C++11 to bootstrap, and therefore is NOT expected to work
with Apple GCC-4.2.1.

[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4

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

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

--- Comment #33 from Iain Sandoe  ---
Have we now resolved this issue?

All current open branches work OK for me on all Darwin versions from 10.4 -
11.2.

Please update if there is still something to fix.

[Bug target/90834] Header and startup objects not found on macOS 10.15

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

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

--- Comment #17 from Iain Sandoe  ---
ping for closing this - or new information otherwise.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl via Gcc-bugs]

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

Piotr Kubaj  changed:

   What|Removed |Added

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

--- Comment #28 from Piotr Kubaj  ---
I just tried on FreeBSD 12.2-RELEASE on powerpc64 with base gcc 4.2.1:
gmake[4]: Entering directory
'/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/gcc'
c++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC   
-fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Icp
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../include
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libcpp/include
-I/usr/local/include 
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libdecnumber
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libbacktrace 
-DLIBICONV_PLUG -o cp/coroutines.o -MT cp/coroutines.o -MMD -MP -MF
cp/.deps/coroutines.TPo
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc:2700:
error: invalid pure specifier (only `= 0' is allowed) before ';' token
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc:2700:
error: initializer specified for non-virtual method
'var_nest_node::var_nest_node()'

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

--- Comment #6 from Segher Boessenkool  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Segher Boessenkool from comment #3)
> > In an ideal world the user can just assume those types exist always.



> Arguably a __SIZEOF_xxx__ macro isn't a very sensible macro for types where
> the type has a guaranteed size,

Yes.  And it does not mean the type exist (or is usable), either.

> but we need *something* that says the type
> exists.

Do we?  The types should always exist!

> Since all other targets already use __SIZEOF_xxx__ to say that the
> type exists, it would be consistent and helpful for powerpc to do the same.

Other targets do not have __ieee128 or __ibm128.