[Bug c++/99590] New: ICE when pack expansion with lambda

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99590
   Summary: ICE when pack expansion with lambda
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

The following code will trigger ICE on gcc-8 ~ gcc-trunk with "-std=c++2a"
mode:

void g(auto... args) {
  ([args...](auto){}(args), ...);  
}

int main() { g(0, 1); }

(goldbot: https://godbolt.org/z/Tvzj7b)

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Not sure what you are refering to.

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

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #9 from Paul Thomas  ---
Created attachment 50386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50386&action=edit
Fix for the PR

Juergen,

Thanks for the report and the reduction.

r11-6253-gce8dcc9105cbd404 exposed at error in gfc_trans_allocate. What is
manifestly an initialization assignment was not being flagged as such.

I will commit as obvious later on today.

Regards

Paul

[Bug c/99577] Non-constant (but actually constant) initializers referencing other constants no longer diagnosed as of GCC 8

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-15
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||accepts-invalid, diagnostic

--- Comment #1 from Richard Biener  ---
Confirmed.  A diagnostic would be nice.

[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-15
 Blocks||56456
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
Note heuristically 0xe8ffc000 isn't likely such an offset from a NULL pointer
object because the object would be quite large.

The diagnostic could maybe also clarify that it assumes 0xe8ffc000 is an
offsetted NULL pointer.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread()

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Summary|internal compiler error:|[11 Regression] internal
   |during RTL pass: final -|compiler error: during RTL
   |void|pass: final - void
   |QTWTF::TCMalloc_PageHeap::s |QTWTF::TCMalloc_PageHeap::s
   |cavengerThread()|cavengerThread()

[Bug target/99582] No intrinsics to access rcl or rcr instruction on x86_64

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

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
ROR can be open-coded, GCC tries hard to detect common patterns.

RCR is difficult because it involves the carry flag and thus the carry producer
would have to be explicit.  Or it would need to be an awkward intrinsic
like

__builtin_rcr ({unsigned, unsigned short, unsigned char} word, bool carry,
unsigned amnt);

and you'd need to hope the compiler can arrange 'carry' to be produced in
the carry flag ...

[Bug target/99591] New: Improving __builtin_add_overflow performance on x86-64

[eggert at gnu dot org via Gcc-bugs]

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

Bug ID: 99591
   Summary: Improving __builtin_add_overflow performance on x86-64
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

This is with gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9) on x86-64. For the
function:

_Bool signed1_overflow (signed char a, signed char b)
{
  signed char r;
  return __builtin_add_overflow (a, b, &r);
}

gcc generates the code:

signed1_overflow:
movsbl  %sil, %esi
movsbl  %dil, %edi
addb%sil, %dil
seto%al
ret

The movsbl instructions are unnecessary and can be omitted.


For the function:

_Bool signed2_overflow (short a, short b)
{
  short r;
  return __builtin_add_overflow (a, b, &r);
}

gcc generates:

signed2_overflow:
movswl  %di, %edi
movswl  %si, %esi
xorl%eax, %eax
addw%si, %di
jo  .L8
.L6:
andl$1, %eax
ret
.L8:
movl$1, %eax
jmp .L6

Better would be this:

signed2_overflow:
addw%si, %di
seto%al
retq

There are similar opportunities for improvement in __builtin_sub_overflow and
__builtin_mul_overflow.

This bug report follows up on this discussion about Gnulib:

https://lists.gnu.org/r/bug-gnulib/2021-03/msg00078.html
https://lists.gnu.org/r/bug-gnulib/2021-03/msg00079.html
https://lists.gnu.org/r/bug-gnulib/2021-03/msg00080.html

[Bug c++/99583] Parameter packs not expanded in lambda noexcept specifier

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Last reconfirmed||2021-03-15
Version|4.7.0   |10.2.1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.0, 11.0, 7.5.0

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

> g++-10 -S t.C
t.C: In function 'void g()':
t.C:5:24: error: expansion pattern '' contains no parameter packs
5 |  f([]() noexcept(B) {} ...);
  |^~~

clang accepts it.

[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Summary|ICE Segmentation fault when |[11 Regression] ICE
   |expanding lambda noexcept   |Segmentation fault when
   |specifier with invalid  |expanding lambda noexcept
   |parameter pack  |specifier with invalid
   ||parameter pack
  Known to work||10.2.1
   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-15

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

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
The attribute is ignored because 'a' is exported, so it's retained anyway (but
not marked as SHF_GNU_RETAIN).  Not sure what the desired semantics of the
attribute are here.

static tree
handle_retain_attribute (tree *pnode, tree name, tree ARG_UNUSED (args),
 int ARG_UNUSED (flags), bool *no_add_attrs)
{
  tree node = *pnode;

  if (SUPPORTS_SHF_GNU_RETAIN
  && (TREE_CODE (node) == FUNCTION_DECL
  || (VAR_P (node) && TREE_STATIC (node
;
  else
{
  warning (OPT_Wattributes, "%qE attribute ignored", name);

in particular 'a' is not TREE_STATIC.  Maybe !DECL_EXTERNAL was intended here
to ignore it on

extern int a;

?

[Bug c/99588] variable set but not used warning on static _Atomic assignment

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org
   Last reconfirmed||2021-03-15
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We're likely confused by the "interesting" IL this emits:

;; Function test (null)
;; enabled by -tree-original


{
  static atomic int x = 0;

static atomic int x = 0;
  printf ((const char * restrict) "%d\n", TARGET_EXPR ;
  TARGET_EXPR , 5)>;, D.2477);
}

but clearly 'x' is used in the __atomic_add_fetch_4

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

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

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

--- Comment #2 from Florian Weimer  ---
The problem is that if GCC is not configured for SHF_GNU_RETAIN,
__has_attribute (retain) should not be true.

That is, __has_attribute needs to reflect the actual attribute support status,
and not what happens to be registered as attributes in the GCC codebase. 
__has_builtin has the same problem, see bug 96952 for an example.

[Bug c++/99590] ICE when pack expansion with lambda

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
I think this is a valid code:

void g(auto... args) {
  ([args...](auto...){}(args   ), ...);
}

void f(auto... args) {
  ([args   ](auto...){}(args...), ...);
}

int main() { 
  g(0, 1); // this one ICE
  f(0, 1); // this one works
}

[Bug fortran/99585] ICE with SIZE intrinsic on nested derived type components

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Started with r6-202-gf3b0bb7a560be0f0.

[Bug c++/99509] [OpenMP] 'omp declare target' for global variable → "hasn't been marked to be included in the offloaded code"

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

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

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

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

commit r11-7665-gf20fe2cb213dffba47ec1b62c625590b5bbe50d7
Author: Tobias Burnus 
Date:   Mon Mar 15 10:12:58 2021 +0100

OpenMP: Fix 'omp declare target' handling for vars [PR99509]

For variables with 'declare target' attribute,
varpool_node::get_create marks variables as offload; however,
if the node already exists, it is not updated. C/C++ may tag
decl with 'declare target implicit', which may only be after
varpool creation turned into 'declare target' or 'declare target link';
in this case, the tagging has to happen in the FE.

gcc/c/ChangeLog:

PR c++/99509
* c-decl.c (finish_decl): For 'omp declare target implicit' vars,
ensure that the varpool node is marked as offloadable.

gcc/cp/ChangeLog:

PR c++/99509
* decl.c (cp_finish_decl): For 'omp declare target implicit' vars,
ensure that the varpool node is marked as offloadable.

libgomp/ChangeLog:

PR c++/99509
* testsuite/libgomp.c-c++-common/declare_target-1.c: New test.

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

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:21ced2776a117924e52f6aab8b41afb613fef0e7

commit r11-7666-g21ced2776a117924e52f6aab8b41afb613fef0e7
Author: Paul Thomas 
Date:   Mon Mar 15 09:32:52 2021 +

Fortran: Fix problem with allocate initialization [PR99545].

2021-03-15  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/99545
* trans-stmt.c (gfc_trans_allocate): Mark the initialization
assignment by setting init_flag.

gcc/testsuite/ChangeLog

PR fortran/99545
* gfortran.dg/pr99545.f90: New test.

[Bug target/99592] New: arm: internal compiler error using arm_neon.h with -pg

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 99592
   Summary: arm: internal compiler error using arm_neon.h with -pg
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Including the arm_neon header fails when building with the 'pg' option

$ arm-linux-gnueabihf-gcc-11 --version
arm-linux-gnueabihf-gcc-11 (Ubuntu 11-20210310-1ubuntu1) 11.0.1 20210310
(experimental) [master revision
8dc225d311e:2453ef06221:5987d8a79cda1069c774e5c302d5597310270026]

$ arm-linux-gnueabihf-gcc-11 -pg   -O2 -c -xc /dev/null -include arm_neon.h
In file included from :
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:71:9: internal
compiler error: ‘global_options’ are modified in local context
   71 | #pragma GCC pop_options
  | ^~~
0xcf6aa3 cl_optimization_compare(gcc_options*, gcc_options*)
   
/build/gcc-11-cross-76rIbd/gcc-11-cross-3ubuntu1/gcc/build/gcc/options-save.c:12589
0x8b031d handle_pragma_pop_options
../../src/gcc/c-family/c-pragma.c:1092
0x822501 c_parser_pragma
../../src/gcc/c/c-parser.c:12519
0x84e065 c_parser_external_declaration
../../src/gcc/c/c-parser.c:1758
0x84e811 c_parser_translation_unit
../../src/gcc/c/c-parser.c:1650
0x84e811 c_parse_file()
../../src/gcc/c/c-parser.c:21984
0x8ade35 c_common_parse_file()
../../src/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/99593] New: [11 Regression] arm MVE ICE when compiling firefox (skia) since r11-6708

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

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

Bug ID: 99593
   Summary: [11 Regression] arm MVE ICE when compiling firefox
(skia) since r11-6708
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

typedef __simd64_int16_t e;
typedef __simd64_uint16_t f;
typedef __simd128_int32_t g;
typedef __simd128_float32_t h;
typedef __simd128_uint32_t i;
g j, p;
g k(int l) { return __builtin_neon_vdup_nv4si(l); }
i n(f l) { return (i)__builtin_neon_vmovluv4hi((e)l); }
template  struct q;
template  q operator<(aa s, q t) {
  return q(s) < t;
}
template  q ad(const q &);
typedef q<4, int> ae;
template <> class q<4, float> {
public:
  q(h af) : ag(af) {}
  q(float) {}
  static q ah(void *ai) {
float *l = (float *)ai;
return __builtin_neon_vld1v4sf(l);
  }
  q operator+(q o) {
h l = ag, m = o.ag;
return __builtin_neon_vaddv4sf(l, m);
  }
  q operator*(q) {
h l = ag, m;
return __builtin_neon_vmulfv4sf(l, m);
  }
  h ag;
};
template <> class q<4, unsigned short> {
public:
  q(f af) : ag(af) {}
  static q ah(void *ai) {
unsigned short *l = (unsigned short *)ai;
return (f)__builtin_neon_vld1v4hi((__builtin_neon_hi *)l);
  }
  void aj() {
f m = ag;
__builtin_neon_vst1v4hi(0, (e)m);
  }
  f ag;
};
template <> class q<4, int> {
public:
  q(g af) : ag(af) {}
  q(int u) { ag = k(u); }
  static q ah(void *ai) {
int *l = (int *)ai;
return __builtin_neon_vld1v4si(l);
  }
  q operator&(q o) {
g v = ag & o.ag;
return v;
  }
  q operator|(q o) {
g w = ag | o.ag;
return w;
  }
  q operator^(q) {
g x = ag ^ p;
return x;
  }
  q operator>>(int ak) { return ag >> q(ak).ag; }
  q operator<(q) {
g y, z = j < ag;
y = (g)z;
return y;
  }
  g ag;
};
template <> ae ad(const q<4, unsigned short> &al) { return g(n(al.ag)); }
template <> q<4, unsigned short> ad(const ae &al) {
  i l(i(al.ag));
  return (f)__builtin_neon_vmovnv4si((g)l);
}
q<4, float> am(long long an) {
  q ao = q<4, unsigned short>::ah(&an);
  ae ak = ad(ao), ap = ak & 8000, aq = ak ^ ap, ar = 55 < aq, as(aq);
  q at = as & ar;
  ae au = ap | at;
  return q<4, float>::ah(&au);
}
q<4, unsigned short> av(q<4, float> aw) {
  ae ak = ae::ah(&aw), ap = ak & 8000, aq = ap, ax = 5, as = aq >> 3,
 ay = 6;
  q az = ax & as;
  ae au = ay | az;
  return ad(au);
}
struct ba {
  typedef int bb;
  static q<4, float> bc(int s) { return am(s); }
};
q<4, float> bd(q<4, float> s) { return s * 0; }
template  void bf(void *bg, void *al, int bh, int bi) {
  int bj;
  auto bk(static_cast(al) + bh),
  d = static_cast(bg),
  bl = be::bc(static_cast(al)[0]), bm = be::bc(0),
  c = bm;
  for (; bi;) {
auto a = c, bn = be::bc(static_cast(al)[1]),
 bo = be::bc(1);
q bp = bn;
q bq = bp;
auto b = bq + bo;
bl = be::bc(static_cast(al)[2]);
bm = be::bc(bk[2]);
c = bl + bm;
q br = a + b;
auto bs = br;
q bt = bd(bs);
av(bt).aj();
d[0] = bj;
  }
}
int bu;
void bv() { bf(0, 0, 0, bu); }

reduced from firefox (skia) ICEs with -mtune=generic-armv7-a -mfloat-abi=hard
-mfpu=neon -O2 -std=c++17:
ccLSOUAW.ii: In function ‘void bf(void*, void*, int, int) [with be = ba]’:
ccLSOUAW.ii:119:1: internal compiler error: in neon_output_shift_immediate, at
config/arm/arm.c:12993
  119 | }
  | ^
0x1adad35 neon_output_shift_immediate(char const*, char, rtx_def**,
machine_mode, int, bool)
../../gcc/config/arm/arm.c:12993
0x212ff23 output_510
../../gcc/config/arm/arm.md:12899
0x111be52 get_insn_template(int, rtx_insn*)
../../gcc/final.c:2072
0x111e0c3 final_scan_insn_1
../../gcc/final.c:3058
0x111e54b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3171
0x111bc83 final_1
../../gcc/final.c:2022
0x1121245 rest_of_handle_final
../../gcc/final.c:4676
0x11215a4 execute
../../gcc/final.c:4754
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

since r11-6708-gbfab355012ca0f5219da8beb04f2fdaf757d34b7

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

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Richard Biener from comment #9)
> So we now have a "real" FRE after the vectorizer but we fail to CSE
> 
>   MEM  [(double *)&r] = vect__3.20_74;
> ...
>   MEM  [(double *)&r + 32B] = vect__62.26_88;
> ...
>   vect__5.7_34 = MEM  [(double *)&r + 16B];
> 
> mine for GCC 11 to look at.  The code to CSE that load for _74 and _88
> is going to be a bit awkward though but it will nicely combine with the
> following stmts
> 
>   vect__5.8_35 = VEC_PERM_EXPR ;
>   stmp_t_12.9_36 = BIT_FIELD_REF ;
>   stmp_t_12.9_37 = stmp_t_12.9_36 + 0.0;
>   stmp_t_12.9_38 = BIT_FIELD_REF ;
>   stmp_t_12.9_39 = stmp_t_12.9_37 + stmp_t_12.9_38;
>   stmp_t_12.9_40 = BIT_FIELD_REF ;
>   stmp_t_12.9_41 = stmp_t_12.9_39 + stmp_t_12.9_40;
>   stmp_t_12.9_42 = BIT_FIELD_REF ;
>   t_12 = stmp_t_12.9_41 + stmp_t_12.9_42;
> 
> and hopefully elide 'r' completely.

So the difficult thing is that we need to compose the upper v2df half of
vect__3.20_74 and the v2df vect__62.26_88.  Assembly for that would be sth
like

vextractf128$0x1, %ymm0, %xmm0
vinsertf128 $0x1, %xmm1, %ymm0, %ymm0

and on GIMPLE

tem_42 = BIT_FIELD_REF ;
vect__5.7_34 = { tem_42, vect__62.26_88 };

that's two stmts which at the moment VN simplification insertion doesn't
support.  It would be "nicer" to enhance for example VEC_PERM to allow

vect__5.7_34 = VEC_PERM 

"implicitely" extending _88 to v4df (aka a paradoxical v4df subreg of
the v2df SSE reg).  It would turn VEC_PERM into a concat + select operation
with not requiring the intermediate to have vector mode (in this case
it would have v6df without introducing subregs, a mode not possible).
On RTL unfortunately (vec_select:V4DF (vec_concat (reg:V4DF ..) (reg:V2DF ..))
..) is not possible because of that restriction.  OTOH RTL lacks that
concat-and-select operation, allowing the cited form and vec_merge to be
"merged" (vec_merge doesn't require such intermediate mode either).

I'll see how difficult it is to teach VN multi-stmt insertions.

[Bug target/99593] [11 Regression] arm MVE ICE when compiling firefox (skia) since r11-6708

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||clyon at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org
   Target Milestone|--- |11.0
   Last reconfirmed||2021-03-15
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
I think the bug is in mismatch between predicates and constraints:
(define_insn "mve_vshlq_"
  [(set (match_operand:VDQIW 0 "s_register_operand" "=w,w")
(unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w,w")
   (match_operand:VDQIW 2 "imm_lshift_or_reg_neon" "w,Dm")]
 VSHLQ))]
  "ARM_HAVE__ARITH && !TARGET_REALLY_IWMMXT"
  "@
   vshl.%#\t%0, %1, %2
   * return neon_output_shift_immediate (\"vshl\", 'i', &operands[2],
mode, VALID_NEON_QREG_MODE (mode), true);"
  [(set_attr "type" "neon_shift_reg, neon_shift_imm")]
)

imm_lshift_or_reg_neon predicate for CONST_VECTOR implies
imm_for_neon_lshift_operand, but the Dm constraint stands for
imm_for_neon_mov_operand.

--- gcc/config/arm/constraints.md.jj2021-01-04 10:25:44.136173777 +0100
+++ gcc/config/arm/constraints.md   2021-03-15 10:49:28.660795496 +0100
@@ -32,7 +32,7 @@

 ;; The following multi-letter normal constraints have been used:
 ;; in ARM/Thumb-2 state: Da, Db, Dc, Dd, Dn, DN, Dm, Dl, DL, Do, Dv, Dy, Di,
-;;  Dt, Dp, Dz, Tu, Te
+;;  Ds, Dt, Dp, Dz, Tu, Te
 ;; in Thumb-1 state: Pa, Pb, Pc, Pd, Pe
 ;; in Thumb-2 state: Ha, Pj, PJ, Ps, Pt, Pu, Pv, Pw, Px, Py, Pz, Rd, Rf, Rb,
Ra,
 ;;  Rg, Ri
@@ -412,6 +412,14 @@ (define_constraint "Dt"
   (and (match_code "const_double")
(match_test "TARGET_32BIT && vfp3_const_double_for_fract_bits (op)")))

+(define_constraint "Ds"
+ "@internal
+  In ARM/Thumb-2 state a const_vector which can be used as immediate
+  in vshl instruction."
+ (and (match_code "const_vector")
+  (match_test "TARGET_32BIT
+  && imm_for_neon_lshift_operand (op, GET_MODE (op))")))
+
 (define_constraint "Dp"
  "@internal
   In ARM/ Thumb2 a const_double which can be used with a vcvt.s32.f32 with
bits operation"
--- gcc/config/arm/vec-common.md.jj 2021-01-29 11:54:15.650661610 +0100
+++ gcc/config/arm/vec-common.md2021-03-15 10:50:26.570150770 +0100
@@ -299,7 +299,7 @@ (define_expand "movmisalign"
 (define_insn "mve_vshlq_"
   [(set (match_operand:VDQIW 0 "s_register_operand" "=w,w")
(unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w,w")
-  (match_operand:VDQIW 2 "imm_lshift_or_reg_neon" "w,Dm")]
+  (match_operand:VDQIW 2 "imm_lshift_or_reg_neon" "w,Ds")]
 VSHLQ))]
   "ARM_HAVE__ARITH && !TARGET_REALLY_IWMMXT"
   "@

fixes the ICE for me (though I really don't know what to put into dg-*
directives for the testcase, arm and aarch64 testcases are a puzzle for me).

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[11 Regression] arm MVE ICE |[11 Regression] arm Neon
   |when compiling firefox  |ICE when compiling firefox
   |(skia) since r11-6708   |(skia) since r11-6708
   Keywords||ice-on-valid-code

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(Note it's a Neon ICE, not MVE). Yeah, that fix looks ok.
Chritophe, could you help here to write a testcase using arm_neon.h intrinsics
(rather than the builtins they decompose to)?

[Bug fortran/99345] [11 Regression] ICE in doloop_contained_procedure_code, at fortran/frontend-passes.c:2464 since r11-2578-g27eac9ee6137a6b5

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #12 from Thomas Koenig  ---
Fixed with https://gcc.gnu.org/g:52654036a544389fb66855bf3972f2a8013bec59 .

Thanks for the bug report!

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
But we currently have no easy way how to know that.  The rejection of the
attribute as unsupported is done in various places and can depend on many
conditions, in this case it is just a configure thing (plus it is ignored on
entities other than variables and function declarations), but for other
attributes it can depend on command line options, and that can even be changed
on a function by function basis.

__has_attribute as currently implemented just answers the question whether gcc
knows about the attribute (has it registered).

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

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

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

--- Comment #4 from Florian Weimer  ---
For retain, something along these lines might work:

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index c1f652d1dc9..cdae464ab8a 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -329,8 +329,10 @@ const struct attribute_spec c_common_attribute_table[] =
  handle_used_attribute, NULL },
   { "unused", 0, 0, false, false, false, false,
  handle_unused_attribute, NULL },
+#if SUPPORTS_SHF_GNU_RETAIN
   { "retain", 0, 0, true,  false, false, false,
  handle_retain_attribute, NULL },
+#endif
   { "externally_visible", 0, 0, true,  false, false, false,
  handle_externally_visible_attribute, NULL },
   { "no_reorder",0, 0, true, false, false, false,

In other cases, it's more difficult because those are subtarget-dependent.

It's not particularly useful to know that a particular source code base of GCC
knows about the attribute in principle, if built for the right target and with
the right binutils/glibc versions etc. A programmer can already use a version
check for that. __has_attribute and __has_builtin are only useful if they
reflect the current GCC build and its target flags.

[Bug target/99582] No intrinsics to access rcl or rcr instruction on x86_64

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
(In reply to Richard Biener from comment #1)
> ROR can be open-coded, GCC tries hard to detect common patterns.
> 
> RCR is difficult because it involves the carry flag and thus the carry
> producer
> would have to be explicit.  Or it would need to be an awkward intrinsic
> like
> 
> __builtin_rcr ({unsigned, unsigned short, unsigned char} word, bool carry,
> unsigned amnt);
> 
> and you'd need to hope the compiler can arrange 'carry' to be produced in
> the carry flag ...

so is that possible to __builtin_rcl and __builtin_rcr? I think a lot of
cryptography and multi-precision libraries need that for pow stuffs

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Florian Weimer from comment #4)
> For retain, something along these lines might work:
> 
> diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> index c1f652d1dc9..cdae464ab8a 100644
> --- a/gcc/c-family/c-attribs.c
> +++ b/gcc/c-family/c-attribs.c
> @@ -329,8 +329,10 @@ const struct attribute_spec c_common_attribute_table[] =
>   handle_used_attribute, NULL },
>{ "unused", 0, 0, false, false, false, false,
>   handle_unused_attribute, NULL },
> +#if SUPPORTS_SHF_GNU_RETAIN
>{ "retain", 0, 0, true,  false, false, false,
>   handle_retain_attribute, NULL },
> +#endif
>{ "externally_visible", 0, 0, true,  false, false, false,
>   handle_externally_visible_attribute, NULL },
>{ "no_reorder",0, 0, true, false, false, false,
> 
> In other cases, it's more difficult because those are subtarget-dependent.

Doing the above would "fix" __has_attribute, but on the other side would mean
the compiler would not know how many and what kind of operands the attribute
has, whether it is for function declarations, other declarations, types or what
etc., so for invalid code it would have inconsistent diagnostics.

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #3 from Jakub Jelinek  ---
I've tried to reproduce it with
typedef __simd128_int32_t int32x4_t;

void
foo (int32x4_t c)
{
  int32x4_t b = __builtin_neon_vdup_nv4si (3);
  register int32x4_t a __asm ("d16");
  asm volatile ("" : "=w" (a));
  a = a >> b;
  a |= c;
  asm volatile ("" : : "w" (a));
}
but it doesn't, for some reason the ICE needs a REG_EQUAL attribute on the
right shift into which we propagate the constant and LRA picks the constant
from there, but haven't managed to force that.

[Bug c++/99509] [OpenMP] 'omp declare target' for global variable → "hasn't been marked to be included in the offloaded code"

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #5 from Tobias Burnus  ---
FIXED on mainline (GCC 11).

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

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

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

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

https://gcc.gnu.org/g:62bba614ffadb593baaaf13c881874ee96c7b7ce

commit r10-9442-g62bba614ffadb593baaaf13c881874ee96c7b7ce
Author: Paul Thomas 
Date:   Mon Mar 15 09:32:52 2021 +

Fortran: Fix problem with allocate initialization [PR99545].

2021-03-15  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/99545
* trans-stmt.c (gfc_trans_allocate): Mark the initialization
assignment by setting init_flag.

gcc/testsuite/ChangeLog

PR fortran/99545
* gfortran.dg/pr99545.f90: New test.

(cherry picked from commit 21ced2776a117924e52f6aab8b41afb613fef0e7)

[Bug c++/99594] New: Parameter packs not expanded in lambda requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99594
   Summary: Parameter packs not expanded in lambda requires clause
   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: ---

Same form with PR 99583, this code should work:

template 
auto f() {
  ([](auto) requires (B) {}, ...);
}

(goldbot: https://godbolt.org/z/jdn4je)

[Bug rtl-optimization/98791] [10 Regression] ICE in paradoxical_subreg_p (in ira) with SVE

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Andre Simoes Dias Vieira
:

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

commit r10-9443-g9b0bbe19afb2a6800e95f61cc57206e069a400d6
Author: Andre Vieira 
Date:   Mon Feb 22 13:41:46 2021 +

ira: Make sure allocno copies are ordered [PR98791]

gcc/ChangeLog:
2021-02-22  Andre Vieira  

PR rtl-optimization/98791
* ira-conflicts.c (process_regs_for_copy): Don't create allocno
copies
for unordered modes.

gcc/testsuite/ChangeLog:
2021-02-22  Andre Vieira  

PR rtl-optimization/98791
* gcc.target/aarch64/sve/pr98791.c: New test.

(cherry picked from commit 4c31a3a6d31b6214ea774d403bf8ab7ebe1ea862)

[Bug rtl-optimization/98791] [10 Regression] ICE in paradoxical_subreg_p (in ira) with SVE

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from avieira at gcc dot gnu.org ---
Closing now as backport is done.

[Bug c++/99595] New: ICE when pack expansion with template lambda

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99595
   Summary: ICE when pack expansion with template lambda
   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: ---

The following code will trigger ICE on gcc-trunk:

auto f(auto... args) {
  ([]{ y; }, ...);
}

int main() { f(0); }

(godbolt: https://godbolt.org/z/11G8G5)
(wanbox: https://wandbox.org/permlink/Bbmq4ZWehhJqlBdk)

[Bug target/99596] New: arm: internal error in single_pred_edge

[arnd at linaro dot org via Gcc-bugs]

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

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

I ran into this internal compiler error while building the Linux kernel in
random configurations, made a reduced test case:

$ arm-linux-gnueabihf-gcc-11 -Os -mtune=xscale -c cfi_cmdset_0002.c 
during RTL pass: fwprop2
cfi_cmdset_0002.c: In function ‘i’:
cfi_cmdset_0002.c:16:1: internal compiler error: in single_pred_edge, at
basic-block.h:350
   16 | }
  | ^
0x7bf679 single_pred_edge
../../src/gcc/basic-block.h:350
0x7bf679 single_pred
../../src/gcc/basic-block.h:369
0x7bf679 rtl_ssa::function_info::create_degenerate_phi(rtl_ssa::ebb_info*,
rtl_ssa::set_info*)
../../src/gcc/rtl-ssa/blocks.cc:535
0x1860f6d rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:508
0x18617c3
rtl_ssa::function_info::change_insns(array_slice)
../../src/gcc/rtl-ssa/changes.cc:659
0x1862078 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:717
0x172f1cd try_fwprop_subst_pattern
../../src/gcc/fwprop.c:552
0x172f1cd try_fwprop_subst
../../src/gcc/fwprop.c:625
0x172f73e forward_propagate_and_simplify
../../src/gcc/fwprop.c:823
0x172f73e forward_propagate_into
../../src/gcc/fwprop.c:883
0x172fb8a forward_propagate_into
../../src/gcc/fwprop.c:835
0x172fb8a fwprop_insn
../../src/gcc/fwprop.c:954
0x172fc49 fwprop
../../src/gcc/fwprop.c:992
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ cat cfi_cmdset_0002.c
register int a asm("sp");
extern int b;
typedef struct {
  long c[16 * 8 / 32];
} d;
int e;
int f;
int g;
d h;
int j(int, int, int, d);
int i(void) {
  for (;;) {
b &&j(e, f, g, h);
j(e, f, g, h);
  }
}

$ arm-linux-gnueabihf-gcc-11 --version
arm-linux-gnueabihf-gcc-11 (Ubuntu 11-20210310-1ubuntu1) 11.0.1 20210310
(experimental) [master revision
8dc225d311e:2453ef06221:5987d8a79cda1069c774e5c302d5597310270026]

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

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

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

Alex Coplan  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-15
  Known to fail||11.0
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org,
   ||sripar01 at gcc dot gnu.org
   Keywords||ice-on-valid-code
 Target|arm |arm-eabi
 Status|UNCONFIRMED |NEW

--- Comment #1 from Alex Coplan  ---
The problematic insn is:

(insn 8 7 9 2 (set (reg:V4SI 119)
(const_vector:V4SI [
(const_int 4095 [0xfff])
(const_int 0 [0]) repeated x3
])) "ice.c":3:21 2998 {*mve_movv4si}
 (nil))

We ICE in the output code for *mve_mov with which_alternative == 4. It
looks like the constraint is wrong for this alternative:

(define_insn "*mve_mov"
  [(set (match_operand:MVE_types 0 "nonimmediate_operand"
"=w,w,r,w,w,r,w,Ux,w")
(match_operand:MVE_types 1 "general_operand"
"w,r,w,Dn,Uxi,r,Dm,w,Ul"))]

Unless I'm missing something, I don't think "Uxi" is a valid constraint.
Perhaps the "Ux" constraint was intended instead?

If the constraint really is invalid, it would be nice to catch this earlier
(ideally when the MD files are processed at build time).

Changing the constraint to Ux leads to cycling in LRA. Perhaps something went
wrong at expand time? Need to do some more debugging.

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

[doko at debian dot org via Gcc-bugs]

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

--- Comment #5 from Matthias Klose  ---
Created attachment 50387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50387&action=edit
readelf -Wa output

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

[doko at debian dot org via Gcc-bugs]

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

--- Comment #6 from Matthias Klose  ---
https://people.debian.org/~doko/tmp/go1-mips64el.xz

[Bug target/99596] [11 Regression] arm: internal error in single_pred_edge

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

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

Alex Coplan  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Target||arm
 CC||acoplan at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to fail||11.0
   Last reconfirmed||2021-03-15
  Known to work||10.2.1
Summary|arm: internal error in  |[11 Regression] arm:
   |single_pred_edge|internal error in
   ||single_pred_edge

--- Comment #1 from Alex Coplan  ---
Confirmed on trunk. GCC 10 doesn't ICE.

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

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

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

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

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

commit r9-9284-gb4f86a21263b8e731de68a78862e5c480ef3d160
Author: Paul Thomas 
Date:   Mon Mar 15 09:32:52 2021 +

Fortran: Fix problem with allocate initialization [PR99545].

2021-03-15  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/99545
* trans-stmt.c (gfc_trans_allocate): Mark the initialization
assignment by setting init_flag.

gcc/testsuite/ChangeLog

PR fortran/99545
* gfortran.dg/pr99545.f90: New test.

(cherry picked from commit 21ced2776a117924e52f6aab8b41afb613fef0e7)

[Bug c++/99597] New: Parameter packs not expanded in lambda template list

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99597
   Summary: Parameter packs not expanded in lambda template list
   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: ---

The following code intends to work, even if it fails in three major compilers:

template  
void f(Ts...) {
  ([](){}, ...);  
}

int main() { f(0, 0.5); }

(goldbot: https://godbolt.org/z/xnM9dY)

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

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

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

--- Comment #7 from Jakub Jelinek  ---
  [43] .debug_line_str   MIPS_DWARF   ecf07bf 0066e6 01  MS
 0   0  1
  [44] .debug_line_str   MIPS_DWARF   ecf6ea5 0005d1 01  MS
 0   0  1
Thus, doesn't seem to be dwz fault, the two .debug_line_str sections is
something unexpected.

[Bug target/99596] [11 Regression] arm: internal error in single_pred_edge

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

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

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

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

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

--- Comment #8 from Mark Wielaard  ---
On Mon, 2021-03-15 at 12:21 +, jakub at gcc dot gnu.org wrote:
> --- Comment #7 from Jakub Jelinek  ---
>   [43] .debug_line_str   MIPS_DWARF   ecf07bf 0066e6 01  
> MS
>  0   0  1
>   [44] .debug_line_str   MIPS_DWARF   ecf6ea5 0005d1 01  
> MS
>  0   0  1
> Thus, doesn't seem to be dwz fault, the two .debug_line_str sections is
> something unexpected.

But that is odd. It has the same name, section type, flags (merge
strings) and alignment. Why didn't the linker merge these?

The only difference with other arches would be the MIPS_DWARF instead
of PROGBITS type. But that shouldn't really matter to the linker.

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell  ---
most likely dup of 99425

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell  ---
most likely dup of 99425

[Bug ipa/98834] [10/11 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

--- Comment #7 from Richard Biener  ---
So for the missed optimization we run into

  /* 5) For aggregate copies translate the reference through them if
 the copy kills ref.  */
  else if (data->vn_walk_kind == VN_WALKREWRITE
...
  /* Adjust *ref from the new operands.  */
  ao_ref rhs1_ref;
  ao_ref_init (&rhs1_ref, rhs1);
  if (!ao_ref_init_from_vn_reference (&r, ao_ref_alias_set (&rhs1_ref),
  ao_ref_base_alias_set (&rhs1_ref),
  vr->type, vr->operands))
return (void *)-1;
  /* This can happen with bitfields.  */
  if (maybe_ne (ref->size, r.size))
return (void *)-1;

because the IL looks like

  __xD.2835 = __xD.2753._M_dataD.2625;
  __xx_11 = MEM  [(struct _TupleD.2456 *)&__xD.2835];

and we try to express the load in terms of the RHS of the aggregate copy
but we end up with __xD.2753._M_dataD.2625 itself (there's no subsetting
component ref on the original load) but that loads 64 bytes, not 32 as
requested.  The code tries to handle variable index accesses and thus
doesn't simply try to compute base + offset and a corresponding MEM_REF
to look up.

The following seems to work but is otherwise untested:

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index e3806e55457..c47bd19a1fa 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -3306,7 +3306,17 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
return (void *)-1;
   /* This can happen with bitfields.  */
   if (maybe_ne (ref->size, r.size))
-   return (void *)-1;
+   {
+ /* If the access lacks some subsetting simply apply that by
+shortening it.  That in the end can only be successful
+if we can pun the lookup result which in turn requires
+exact offsets.  */
+ if (known_eq (r.size, r.max_size)
+ && known_lt (ref->size, r.size))
+   r.size = r.max_size = ref->size;
+ else
+   return (void *)-1;
+   }
   *ref = r;

   /* Do not update last seen VUSE after translating.  */

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

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

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

--- Comment #9 from Jakub Jelinek  ---
Sure.
One interesting question is whether there are *.o objects with multiple
.debug_line_str sections (but even if there are, shouldn't the linker merge
them?).
So primary suspect here is the linker.

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #3 from Nathan Sidwell  ---
most likely dup of 99496

[Bug c++/99481] [modules] ICE tree check: expected template_decl, have function_decl in decl_value, at cp/module.cc:7938

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nathan at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Nathan Sidwell  ---
most likely 99528

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

[Bug c++/99528] [modules] ICE with iostream& vector

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||alexander.lelyakin@googlema
   ||il.com

--- Comment #4 from Nathan Sidwell  ---
*** Bug 99481 has been marked as a duplicate of this bug. ***

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

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

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

Bug 99481 Summary: [modules] ICE tree check: expected template_decl, have 
function_decl in decl_value, at cp/module.cc:7938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99481

   What|Removed |Added

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

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
please don;t reopen bugs with different ICEs

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

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

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

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

   What|Removed |Added

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

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #1 from Nathan Sidwell  ---
most likely dup of 99425

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

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug web/99598] New: Commits are not transferred to bugzilla

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

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

Bug ID: 99598
   Summary: Commits are not transferred to bugzilla
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

See https://gcc.gnu.org/pipermail/gcc-cvs/2021-March/343081.html ,
which is not distributed to bugzilla and the gcc-bugs mailing list,
despite the ChangeLog entry reading


Handle EXEC_IOLENGTH in doloop_contained_procedure_code.

This rather obvious patch fixes an ICE on valid which came about
because I did not handle EXEC_IOLENGTH as start of an I/O statement
when checking for the DO loop variable.  This is an 11 regression.

gcc/fortran/ChangeLog:

PR fortran/99345
* frontend-passes.c (doloop_contained_procedure_code):
Properly handle EXEC_IOLENGTH.

gcc/testsuite/ChangeLog:

PR fortran/99345
* gfortran.dg/do_check_16.f90: New test.
* gfortran.dg/do_check_17.f90: New test.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

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

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

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

--- Comment #13 from Jürgen Reuter  ---
I confirm that with that patch our code compiles again, however, more or less
all functionality fails because of runtime errors about 
Fortran runtime error: Pointer actual argument '' is not associated.
Not sure whether this is related. Shall I open another PR? 
Working on a reproducer for that problem.

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:
struct A { void foo () { __asm__("stw %1, %0" : "=o" (c) : "r" (0)); } int c; }
d;
struct B { A *e; B (A *g) : e(g) { e->foo (); } };
struct C { void *i; };
struct D { void bar (); A e; C l[68]; } m[68];
struct E { E (A *); };
int p;
void D::bar () { E (&m[p].e); }
void baz () { B h(&d); }

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

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #5 from Tobias Burnus  ---
FIXED on mainline (GCC 11).

Thanks for the report!

[Bug c++/99599] New: Concepts requirement falsely reporting recursion, breaks tag_invoke pattern

[the_gamester28 at msn dot com via Gcc-bugs]

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

Bug ID: 99599
   Summary: Concepts requirement falsely reporting recursion,
breaks tag_invoke pattern
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: the_gamester28 at msn dot com
  Target Milestone: ---

The following code compiles fine on GCC 10, Clang, MSVC, but fails in GCC
11/trunk:

### begin

struct foo_tag{};
struct bar_tag{};

template 
concept fooable = requires(T it) {
invoke_tag(foo_tag{}, it); // <-- here
};

template
auto invoke_tag(foo_tag, T in) {
return in;
}

template
auto invoke_tag(bar_tag, T it) {
return it;
}

int main() {
// Neither line below compiles in GCC 11, independently of the other
return invoke_tag(foo_tag{}, 2);
return invoke_tag(bar_tag{}, 2);
}

### end

Produces the following compiler error:

### begin

: In substitution of 'template  requires  fooable auto
invoke_tag(bar_tag, T) [with T = int]':
:6:15:   required by substitution of 'template  requires 
fooable auto invoke_tag(bar_tag, T) [with T = int]'
:21:35:   required from here
:5:9:   required for the satisfaction of 'fooable' [with T = int]
:5:19:   in requirements with 'T it' [with T = int]
:5:19: error: satisfaction of atomic constraint 'requires(T it)
{invoke_tag({}, it);} [with T = T]' depends on itself
5 | concept fooable = requires(T it) {
  |   ^~~~
6 | invoke_tag(foo_tag{}, it);
  | ~~
7 | };
  | ~  

### end

It seems that the template requirements of invoke_tag(bar_tag, int) are
considered while evaluating line marked "here". Requirements of irrelevant
overloads should not be considered, as it can potentially lead to falsely
reporting a cyclic dependency.

This bug effectively prevents using the modern tag_invoke pattern, which is
increasingly used as a customisation point in many modern libraries.

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

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #7 from Tobias Burnus  ---
Missed to add a PR fortran/99529, hence, the commit did not show up:

r11-7647-ga6e9633ccb593937fceec67fafc2afe5d518d735

commit a6e9633ccb593937fceec67fafc2afe5d518d735
Author: Tobias Burnus 
Date:   Fri Mar 12 16:31:32 2021 +0100

Fortran: Fix libgfortran I/O race with newunit_free [PR99529]

libgfortran/ChangeLog:

* io/transfer.c (st_read_done_worker, st_write_done_worker):
Call unlock_unit here, add unit_lock lock around newunit_free call.
(st_read_done, st_write_done): Only call unlock_unit when not
calling the worker function.
* io/unit.c (set_internal_unit): Don't reset the unit_number
to the same number as this cause race warnings.

 * * *

Committed patch was the revised version
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566600.html

Martin (who reported the issue + helped debugging it) wrote in one of the email
threads:
"BTW, I will do some more tests, but it looks like the patch fixes
the memory corruption issue."

Thus, hopefully, this issue is fixed for good. Thanks to all involved for the
help!

→ Close as FIXED (on mainline, GCC 11).

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

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #5 from Tobias Burnus  ---
FIXED on mainline (GCC 11).

Thanks for the report!

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11 Regression] internal|[11 Regression] internal
   |compiler error: during RTL  |compiler error: during RTL
   |pass: final - void  |pass: final - void
   |QTWTF::TCMalloc_PageHeap::s |QTWTF::TCMalloc_PageHeap::s
   |cavengerThread()|cavengerThread() since
   ||r11-7526
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-15
 CC||segher at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Priority|P3  |P1
 Ever confirmed|0   |1
   Keywords||ra

--- Comment #2 from Jakub Jelinek  ---
Started with r11-7526-g9105757a59b890194ebf5b4fcbacd58db34ef332
o in =o is a generic constraint though (but maybe the bug is in the rs6000
backend).

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

--- Comment #3 from Jakub Jelinek  ---
C test (for -O2 too):
char e[37540];
struct A { int c; } d;

void
bar (int n)
{
  __asm__("" : : "r" (e));
}

void
foo (void)
{
  __asm__("stw %1, %0" : "=o" (d.c) : "r" (0));
}

[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
Summary|Concepts requirement|[11 Regression] Concepts
   |falsely reporting cyclic|requirement falsely
   |dependency, breaks  |reporting cyclic
   |tag_invoke pattern  |dependency, breaks
   ||tag_invoke pattern
  Known to work||10.2.0
   Target Milestone|--- |11.0

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

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

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

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

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #4 from Christophe Lyon  ---
I have updated the test in the initial description to call intrinsics, added
relevant dg-* directives. Testing with several configurations under progress.


Is it really r11-6708 that introduced the problem? It doesn't modify vshq
unlike it's predecessor r11-6707-g7432f255b70811dafaf325d94036ac580891de69.

And that one only moves the offending pattern from neon.md to vec-common.md, so
the bug was probably already present?

As of -mtune=generic-armv7-a, I can reproduce the ICE with
-mcpu=generic-armv7-a, but I haven't found a -march equivalent
(-march=armv7-a+fp does not trigger the ICE)

[Bug c++/99595] ICE when pack expansion with template lambda

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed||2021-03-15
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  ICEs with -fconcepts-ts, on the branch that causes an
error-recovery ICE and we first diagnose

t.C: In function 'auto f(auto:1 ...)':
t.C:2:24: error: expected '(' before '{' token
2 |   ([]{ y; }, ...);
  |^
  |(

[Bug c++/99594] Parameter packs not expanded in lambda requires clause

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Richard Biener  ---
t.C: In function 'auto f()':
t.C:3:4: error: operand of fold expression has no unexpanded parameter packs
3 |   ([](auto) requires (B) {}, ...);
  |^~~~

clang 9 rejects it with

t.C:3:13: error: expected body of lambda expression
  ([](auto) requires (B) {}, ...);
^

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

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #2 from Tobias Burnus  ---
FIXED on mainline (GCC 11) by one of the recent use_device_* patches.

Thanks for the report!

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Christophe Lyon from comment #4)
> I have updated the test in the initial description to call intrinsics, added
> relevant dg-* directives. Testing with several configurations under progress.
> 
> 
> Is it really r11-6708 that introduced the problem? It doesn't modify vshq
> unlike it's predecessor r11-6707-g7432f255b70811dafaf325d94036ac580891de69.

I think so, r11-6707 doesn't ICE.
In *.expand dump, the only r11-6707 to r11-6708 differences are 4 times
UNSPEC_ASHIFT_SIGNED -> VSHLQ_S
changes, and that is true up to ira dump too.
*.lra dump has:
-(insn 256 174 176 4 (set (reg:V4SI 52 d18 [331])
-(const_vector:V4SI [
-(const_int -3 [0xfffd]) repeated x4
-])) "ccLSOUAW.ii":66:45 1061 {*neon_movv4si}
- (nil))
-(insn 176 256 177 4 (set (reg:V4SI 48 d16 [297])
+(insn 176 174 177 4 (set (reg:V4SI 48 d16 [297])
 (unspec:V4SI [
 (reg:V4SI 48 d16 [296])
-(reg:V4SI 52 d18 [331])
-] UNSPEC_ASHIFT_SIGNED)) "ccLSOUAW.ii":66:45 1350
{ashlv4si3_signed}
+(const_vector:V4SI [
+(const_int -3 [0xfffd]) repeated x4
+])
+] VSHLQ_S)) "ccLSOUAW.ii":66:45 510 {mve_vshlq_sv4si}
  (expr_list:REG_EQUAL (unspec:V4SI [
 (reg:V4SI 48 d16 [296])
 (const_vector:V4SI [
 (const_int -3 [0xfffd]) repeated x4
 ])
-] UNSPEC_ASHIFT_SIGNED)
+] VSHLQ_S)
 (nil)))
difference.

[Bug target/99600] New: [11 regression] out of memory for simple test case (x86 -march=atom)

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 99600
   Summary: [11 regression] out of memory for simple test case
(x86 -march=atom)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Testing random Linux kernel builds with gcc-11 killed my box before I had a
reasonable "ulimit -d" limit set when it filled up 384GB of memory.

I have now set a limit and managed to produce a small test case:

$ ulimit -S -d 100 # one gigabyte
$ gcc-11 -O2 -march=atom test.c
virtual memory exhausted: Cannot allocate memory

$ cat test.c
char a;
char b;
long c;
long d() {
  if (a )
c = b == 1 ? 1 << 3 : 1 << 2;
  else
c = 0;
  return 0 ;
}

$ gcc-11 --version
gcc-11 (Ubuntu 11-20210310-1ubuntu1) 11.0.1 20210310 (experimental) [master
revision 8dc225d311e:2453ef06221:5987d8a79cda1069c774e5c302d5597310270026]

[Bug target/99600] [11 regression] out of memory for simple test case (x86 -march=atom)

[arnd at linaro dot org via Gcc-bugs]

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

--- Comment #1 from Arnd Bergmann  ---
https://godbolt.org/z/z7h7r3

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #6 from Jakub Jelinek  ---
Before r11-6708 it was using different patterns - ashl3_signed - and
those
don't accept immediate CONST_VECTOR at all, while mve_vshlq_ does.

[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||11.0
 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Rejected since r11-2774

c++: Check satisfaction before non-dep convs. [CWG2369]

It's very hard to use concepts to protect a template from hard errors due
to
unwanted instantiation if constraints aren't checked until after doing all
substitution and checking of non-dependent conversions.

It was pretty straightforward to insert the satisfaction check into the
logic, but I needed to make the 3-parameter version of
satisfy_declaration_constraints call push_tinst_level like the 2-parameter
version already does.  For simplicity, I also made it add any needed outer
template arguments from the TEMPLATE_DECL to the args.

The testsuite changes are mostly because this change causes unsatisfaction
to cause deduction to fail rather than reject the candidate later in
overload resolution.

[Bug c++/99601] New: [11 regression] g++.dg/modules/iostream-1_b.C on x86_64 with -m32

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

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

Bug ID: 99601
   Summary: [11 regression] g++.dg/modules/iostream-1_b.C on
x86_64 with -m32
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

, FAIL: g++.dg/modules/builtin-3_a.C and FAIL: g++.dg/modules/iostream-1_b.C on
x86_64 with -m32

(perhaps similar to 99496?)

[Bug fortran/99602] New: [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

Bug ID: 99602
   Summary: [11 regression] runtime error: pointer actual argument
not associated
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

This is a new bug report, maybe related to PR 99545, might be created by the
same commits. When compiling Whizard with the following checking/debug flags, 
-O0 -fbacktrace -fcheck=all -Wconversion -Wconversion-extra -Wsurprising
almost all of our functionality fails with the following runtime error:
Fortran runtime error: Pointer actual argument '' is not associated
I will provide a reproducer in a moment.

[Bug target/99600] [11 regression] out of memory for simple test case (x86 -march=atom)

[arnd at linaro dot org via Gcc-bugs]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #2 from Arnd Bergmann  ---
perf shows these functions as the most commonly called ones, presumably it's
looping through all of those:

   5.39%  cc1  cc1[.] df_ref_create_structure   
   5.33%  cc1  cc1[.] df_uses_record
   4.41%  cc1  cc1[.] ggc_internal_alloc
   3.41%  cc1  cc1[.] df_ref_record 
   2.79%  cc1  cc1[.] peephole2_insns   
   2.69%  cc1  cc1[.] ix86_lea_outperforms  
   2.58%  cc1  cc1[.] df_insn_rescan
   2.33%  cc1  cc1[.] df_sort_and_compress_refs 
   2.05%  cc1  cc1[.] df_free_ref   

This recent change touches ix86_lea_outperforms, could be related:
https://github.com/gcc-mirror/gcc/commit/decd8fb01288

[Bug c++/99603] New: [11 regression] ICE in libstdc++ tests due to module

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

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

Bug ID: 99603
   Summary: [11 regression] ICE in libstdc++ tests due to module
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

I also see 23_containers/vector/modifiers/insert_vs_emplace.cc ICE on x86_64
with -m32 during GC ...

[Bug c++/99604] New: GC related ICE in 23_containers/vector/modifiers/insert_vs_emplace.cc

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

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

Bug ID: 99604
   Summary: GC related ICE in
23_containers/vector/modifiers/insert_vs_emplace.cc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see on x86_64-unknown-linux-gnu when testing with -m32:

spawn -ignore SIGHUP /tmp/obj/./gcc/xg++ -shared-libgcc -B/tmp/obj/./gcc
-nostdinc++ -L/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fchecking=1 -m32
-B/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -fmessage-length=0
-fno-show-column -ffunction-sections -fdata-sections -fcf-protection -mshstk -g
-O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/home/rguenther/src/trunk/libstdc++-v3/libsupc++
-I/home/rguenther/src/trunk/libstdc++-v3/include/backward
-I/home/rguenther/src/trunk/libstdc++-v3/testsuite/util
/home/rguenther/src/trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/insert_vs_emplace.cc
-m32 -include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a
-Wl,--gc-sections
-L/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/.libs -lm -o
./insert_vs_emplace.exe^M
In file included from /usr/include/endian.h:60,^M
 from /usr/include/ctype.h:39,^M
 from
/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/include/cctype:42,^M
 from
/tmp/obj/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h:35,^M
 from :^M
/usr/include/bits/byteswap.h:48: internal compiler error: Segmentation fault^M
0x10c425f crash_signal^M
/home/rguenther/src/trunk/gcc/toplev.c:327^M
0xbf0c03 lookup_page_table_entry^M
/home/rguenther/src/trunk/gcc/ggc-page.c:630^M
0xbf0c03 ggc_set_mark(void const*)^M
/home/rguenther/src/trunk/gcc/ggc-page.c:1544^M
0xb328e7 gt_ggc_mx_lang_tree_node(void*)^M
./gt-cp-tree.h:107^M
...
0xbf15b1 ggc_collect()^M
/home/rguenther/src/trunk/gcc/ggc-page.c:2220^M
0xc82e04 cgraph_node::finalize_function(tree_node*, bool)^M
/home/rguenther/src/trunk/gcc/cgraphunit.c:494^M
0xb12d4a expand_or_defer_fn(tree_node*)^M
/home/rguenther/src/trunk/gcc/cp/semantics.c:4595^M
0xa91d41 cp_parser_function_definition_after_declarator^M
/home/rguenther/src/trunk/gcc/cp/parser.c:30020^M
0xa930f9 cp_parser_function_definition_from_specifiers_and_declarator^M
/home/rguenther/src/trunk/gcc/cp/parser.c:29923^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M

[Bug target/99600] [11 regression] out of memory for simple test case (x86 -march=atom)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
It is too peephole2 rules that run on newly added instructions (each on the
ones added by the other one), in particular:
(define_peephole2
  [(set (match_operand:SWI48 0 "register_operand")
(match_operand:SWI48 1 "address_no_seg_operand"))]
  "ix86_hardreg_mov_ok (operands[0], operands[1])
   && peep2_regno_dead_p (0, FLAGS_REG)
   && ix86_avoid_lea_for_addr (peep2_next_insn (0), operands)"
  [(const_int 0)]
and
(define_peephole2
  [(match_scratch:W 5 "r")
   (parallel [(set (match_operand 0 "register_operand")
   (ashift (match_operand 1 "register_operand")
   (match_operand 2 "const_int_operand")))
   (clobber (reg:CC FLAGS_REG))])
   (parallel [(set (match_operand 3 "register_operand")
   (plus (match_dup 0)
 (match_operand 4 "x86_64_general_operand")))
   (clobber (reg:CC FLAGS_REG))])]
  "IN_RANGE (INTVAL (operands[2]), 1, 3)
   /* Validate MODE for lea.  */
   && ((!TARGET_PARTIAL_REG_STALL
&& (GET_MODE (operands[0]) == QImode
|| GET_MODE (operands[0]) == HImode))
   || GET_MODE (operands[0]) == SImode
   || (TARGET_64BIT && GET_MODE (operands[0]) == DImode))
   && (rtx_equal_p (operands[0], operands[3])
   || peep2_reg_dead_p (2, operands[0]))
   /* We reorder load and the shift.  */
   && !reg_overlap_mentioned_p (operands[0], operands[4])"
  [(set (match_dup 5) (match_dup 4))
   (set (match_dup 0) (match_dup 1))]

[Bug testsuite/99605] New: [11 regress] new test case g++.dg/modules/builtin-3_a.C fails for 32 bits

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

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

Bug ID: 99605
   Summary: [11 regress] new test case
g++.dg/modules/builtin-3_a.C fails for 32 bits
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:a5469584f61abeec98ff89347294f9ed72eca280, r11-6448
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
modules.exp=g++.dg/modules/builtin-3_a.C"
FAIL: g++.dg/modules/builtin-3_a.C -std=c++17  scan-lang-dump module "Wrote
fixed:[0-9]* pointer_type:'::__builtin_va_list'"
FAIL: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump module "Wrote
fixed:[0-9]* pointer_type:'::__builtin_va_list'"
# of expected passes26
# of unexpected failures2

This failure is only for 32 bit.

Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/modules/builtin-3_a.C  -m32 
 -fdiagnostics-plain-output  -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++2a -pedantic-errors -Wno-long-long -fmodules-ts
-fdump-lang-module-blocks-alias-uid  -S -o builtin-3_a.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/modules/builtin-3_a.C -m32
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++2a -pedantic-errors -Wno-long-long -fmodules-ts
-fdump-lang-module-blocks-alias-uid -S -o builtin-3_a.s
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a (test for excess errors)
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump-not module
"Cluster members:\\n  \\[0\\]=decl declaration '::__builtin_strlen'\\n 
\\[1\\]=binding '::__builtin_strlen'\\n"
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump module "Wrote
GMF:-[0-9]* function_decl:'::__builtin_strlen'@builtins"
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump module
"Writing:-[0-9]*'s named merge key \\(decl\\)
function_decl:'::__builtin_strlen'"
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump-not module
"Writing tree:-[0-9]* function_decl:'__builtin_strlen'\\(strlen\\)"
FAIL: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump module "Wrote
fixed:[0-9]* pointer_type:'::__builtin_va_list'"
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump-not module "
Cluster members:\\n  \\[0\\]=decl declaration '::va_list'\\n  \\[1\\]=binding
'::va_list'\\n"
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump module "Wrote
GMF:-[0-9]* type_decl:'::va_list'@builtins"
PASS: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump module
"Writing:-[0-9]*'s named merge key \\(decl\\) type_decl:'::va_list'"


commit a5469584f61abeec98ff89347294f9ed72eca280
Author: Nathan Sidwell 
Date:   Mon Jan 4 07:45:36 2021 -0800

c++: Add stdlib module test cases

[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 #1 from Jürgen Reuter  ---
Created attachment 50389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50389&action=edit
First (large) reproducer to play with, reducing atm

[Bug fortran/97927] gfortran: ICE in lookup_field_for_decl, at tree-nested.c:288

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

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

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

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

commit r10-9444-ga14691e924ea4a8277ea36df08b2f5359082bf62
Author: Tobias Burnus 
Date:   Mon Mar 8 13:05:48 2021 +0100

tree-nested: Update assert for Fortran module vars [PR97927]

gcc/ChangeLog:

PR fortran/97927
* tree-nested.c (convert_local_reference_stmt): Avoid calling
lookup_field_for_decl for Fortran module (= namespace context).

gcc/testsuite/ChangeLog:

PR fortran/97927
* gfortran.dg/module_variable_3.f90: New test.

(cherry picked from commit 8a6a62614a8ae4544770420416d1632d6c3d3f6e)

[Bug fortran/97927] gfortran: ICE in lookup_field_for_decl, at tree-nested.c:288

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #18 from Tobias Burnus  ---
Finally reduced and, hence, finally
FIXED – on mainline (GCC 11) and GCC 10.

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

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

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

--- Comment #14 from Paul Thomas  ---
(In reply to Jürgen Reuter from comment #13)
> I confirm that with that patch our code compiles again, however, more or
> less all functionality fails because of runtime errors about 
> Fortran runtime error: Pointer actual argument '' is not
> associated.
> Not sure whether this is related. Shall I open another PR? 
> Working on a reproducer for that problem.

Please work on a reproducer. I cannot quite see that the new problem is related
but keep this PR open for now.

The test below works, so the correct functionality of allocate is retained.
Your original reproducer no longer ICEs and gives the correct runtime error.

Cheers

Paul

! { dg-do compile }
! { dg-options "-fcheck=mem" }
!
! Test the fix for PR99545, in which the allocate statements caused an ICE.
!
! Contributed by Juergen Reuter  
!
module commands
  implicit none
!  private

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

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

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

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

contains

  subroutine cmd_scan_compile (cmd, sw)
class(cmd_scan_t), intent(inout) :: cmd
integer :: sw

if (allocated (cmd%range)) deallocate (cmd%range)
if (sw .eq. 1) then
  allocate (range_int_t :: cmd%range (3))
else
  allocate (range_real_t :: cmd%range (3))
end if
  end subroutine cmd_scan_compile

end module commands

  use commands
  class(cmd_scan_t), allocatable :: x
  integer :: i
  allocate (x)
  do i = 1, 2
call x%compile (i)
select type (y => x%range)
  type is (range_int_t)
print *, y%i_step
  type is (range_real_t)
print *, y%lr_step
end select
  end do
end

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

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

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

--- Comment #15 from Jürgen Reuter  ---
Paul, thanks for the quick response, I opened a new one, PR99602. Please close
this one.

[Bug debug/99606] New: [10/11 Regression] ld.bfd: DWARF error: could not find abbrev number 64 since r10-7521-g54af95767e887d63

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

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

Bug ID: 99606
   Summary: [10/11 Regression] ld.bfd: DWARF error: could not find
abbrev number 64 since r10-7521-g54af95767e887d63
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

I noticed that for a package that used to link successfully:

$ cat foma.i
char main_prompt[1];
int sprintf(char *, char *, ...);
void stack_size();
void main() { sprintf(main_prompt, "", stack_size); }

$ gcc -gdwarf-5 -Werror -O2 foma.i -flto=auto -g -c && gcc -fPIC foma.o
-flto=16 -fuse-ld=bfd -gdwarf-5
/usr/bin/ld.bfd: /usr/bin/ld.bfd: DWARF error: could not find abbrev number 64
/tmp/ccmeHh1F.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x3): undefined reference to `stack_size'
collect2: error: ld returned 1 exit status

A similar test-case triggers error for ld.gold:

$ cat foma.i
int printf(char *, ...);
  int sprintf(char *, char *, ...);
  void stack_size();
  char main_prompt[1];
  void main() {
   sprintf(main_prompt, "", stack_size);
   printf("\n");
 }

$ gcc -gdwarf-5 -Werror -O2 foma.i -flto=auto -g -c && gcc -fPIC foma.o
-flto=16 -fuse-ld=gold -gdwarf-5
/usr/bin/ld.gold: internal error in format_file_lineno, at
../../gold/dwarf_reader.cc:2278
collect2: error: ld returned 1 exit status

$ gcc -gdwarf-5 -Werror -O2 foma.i -flto=auto -g -c && gcc -fPIC foma.o
-flto=16 -fuse-ld=bfd -gdwarf-5
/usr/bin/ld.bfd: /usr/bin/ld.bfd: DWARF error: could not find abbrev number 64
/tmp/ccylqmOx.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x7): undefined reference to `stack_size'
collect2: error: ld returned 1 exit status

[Bug debug/99606] [10/11 Regression] ld.bfd: DWARF error: could not find abbrev number 64 since r10-7521-g54af95767e887d63

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0
 Status|UNCONFIRMED |NEW
  Known to work||9.3.0
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-15

[Bug c++/99604] GC related ICE in 23_containers/vector/modifiers/insert_vs_emplace.cc

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

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

--- Comment #1 from Richard Biener  ---
Doesn't reproduce with

make check-libstdc++-v3 RUNTESTFLAGS="--target_board=unix/-m32
conformance.exp=insert_vs_emplace.cc"

but appeared in a full (parallel) make check.  Running the command in
valgrind doesn't show anything either.

Will see if it re-surfaces (maybe somebody else saw the same?).  Note I
have address-space randomization disabled.

[Bug ipa/98834] [10/11 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 #8 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:99415d0f18716deeaa8d80e929b1337968cdfa23

commit r11-7671-g99415d0f18716deeaa8d80e929b1337968cdfa23
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.

[Bug ipa/98834] [10/11 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

--- Comment #9 from Richard Biener  ---
This patch restores the optimization of _b_c_p on trunk (and hides the issue
again).

[Bug target/99600] [11 regression] out of memory for simple test case (x86 -march=atom) since r11-7274

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[11 regression] out of  |[11 regression] out of
   |memory for simple test case |memory for simple test case
   |(x86 -march=atom)   |(x86 -march=atom) since
   ||r11-7274
   Target Milestone|--- |11.0

--- Comment #4 from Jakub Jelinek  ---
Therefore, most likely started with my
r11-7274-gdecd8fb0128870d0d768ba53dae626913d6d9c54 that changed a splitter into
the first peephole2.
Will try to see which of those two actually won and will need to adjust the
other peephole2 to punt.

[Bug target/99592] arm: internal compiler error using arm_neon.h with -pg

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Please, how do you configure the cross compiler?

[Bug target/99592] arm: internal compiler error using arm_neon.h with -pg

[arnd at linaro dot org via Gcc-bugs]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #2 from Arnd Bergmann  ---
(In reply to Martin Liška from comment #1)
> Please, how do you configure the cross compiler?

This is the Ubuntu snapshot build, Matthias Klose probably has the exact
configuration at hand.

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

--- Comment #4 from Vladimir Makarov  ---
I've reproduced it too and started to work on it.