[Bug target/100952] [12 regression] several test case failures after r12-1202

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

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

--- Comment #4 from HaoChen Gui  ---
For fusion-p10-ldcmpi.c and prefix-no-update.c, the optimization doesn't work
when mode promotion is disabled. I will do further investigation.

[Bug testsuite/100943] [12 regression] new test gcc.dg/pr100887.c in r12-1256 fails with excess errors

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/100946] [11/12 Regression] [concepts] nonsensical results of compound requirements in requires expressions

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.5

[Bug tree-optimization/28794] missed optimization with non-COND_EXPR and vrp and comparisions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2020-01-17 00:00:00 |2021-6-8

--- Comment #4 from Andrew Pinski  ---
Note really the loops at -O3 should really be optimized to:
void f3(int x, int y)
{
  int t;
  g(0);
  for (t = 1; t < 50; t++)
  {
   g(1);
  }
}

That is peel off the first iteration.  I don't know why -O3 -fno-ssa-phiopt
-fno-tree-vrp does not do that either. I will file that as a different bug
because this is about converting the comparison only in COND_EXPR gimple.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

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

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

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

https://gcc.gnu.org/g:245517470d6948a40cead9f5c312b8d79ac5c491

commit r12-1278-g245517470d6948a40cead9f5c312b8d79ac5c491
Author: Tobias Burnus 
Date:   Tue Jun 8 09:51:09 2021 +0200

Fortran/OpenMP: Fix clause splitting for target/parallel/teams [PR99928]

PR middle-end/99928

gcc/fortran/ChangeLog:

* trans-openmp.c (gfc_add_clause_implicitly): New.
(gfc_split_omp_clauses): Use it.
(gfc_free_split_omp_clauses): New.
(gfc_trans_omp_do_simd, gfc_trans_omp_parallel_do,
gfc_trans_omp_parallel_do_simd, gfc_trans_omp_distribute,
gfc_trans_omp_teams, gfc_trans_omp_target, gfc_trans_omp_taskloop,
gfc_trans_omp_master_taskloop, gfc_trans_omp_parallel_master): Use
it.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/openmp-simd-6.f90: Update scan-tree-dump.
* gfortran.dg/gomp/scan-5.f90: Likewise.
* gfortran.dg/gomp/loop-1.f90: Likewise; remove xfail.
* gfortran.dg/gomp/pr99928-1.f90: Remove xfail.
* gfortran.dg/gomp/pr99928-2.f90: Likewise.
* gfortran.dg/gomp/pr99928-3.f90: Likewise.
* gfortran.dg/gomp/pr99928-8.f90: Likewise.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

--- Comment #3 from Richard Biener  ---
So we hit

/* Check if a STRING_CST fits into the field.
   Tolerate only the case when the NUL termination
   does not fit into the field.   */

static bool
check_string_literal (tree string, unsigned HOST_WIDE_INT size)
{
...
  if (mem_size != size)
return false;

so in this case the NUL termination is missing.  TREE_STRING_LENGTH is 1
but the field size is 2.  The CTOR is

{"a", "b"}

and has a type of char[2][2].  Looks like a FE bug to me.

[Bug middle-end/100951] vec_duplicate leads to worse code

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Testing patch.

[Bug target/100952] [12 regression] several test case failures after r12-1202

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug inline-asm/100953] Add memory clobbers just for reads or just for writes

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2021-06-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Obviously "just for writes" is nonsense, but what's missing is the ability
to add a (use "memory"), which maybe just means allowing to specify
"memory" as use?  That would prevent moving stores across such asm() but
it would not cause "pointless reloading of globals".

[Bug c++/100957] [12 Regression] ICE: Segmentation fault (in copy_tree_body_r)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug testsuite/100943] [12 regression] new test gcc.dg/pr100887.c in r12-1256 fails with excess errors

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

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

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

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

commit r12-1279-gec2174c6957e97bd69c001a782cd52b98e6ba2fb
Author: Jakub Jelinek 
Date:   Tue Jun 8 10:06:13 2021 +0200

testsuite: Add -Wno-psabi -w to pr100887.c test [PR100943]

On x86 the test is using -mavx512f and so never reports the various
-Wpsabi notes/warnings, but on other targets it can.

2021-06-08  Jakub Jelinek  

PR target/100887
PR testsuite/100943
* gcc.dg/pr100887.c: Add -Wno-psabi -w to dg-options.

[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()

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

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

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

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

commit r12-1279-gec2174c6957e97bd69c001a782cd52b98e6ba2fb
Author: Jakub Jelinek 
Date:   Tue Jun 8 10:06:13 2021 +0200

testsuite: Add -Wno-psabi -w to pr100887.c test [PR100943]

On x86 the test is using -mavx512f and so never reports the various
-Wpsabi notes/warnings, but on other targets it can.

2021-06-08  Jakub Jelinek  

PR target/100887
PR testsuite/100943
* gcc.dg/pr100887.c: Add -Wno-psabi -w to dg-options.

[Bug other/100959] New: -fuse-ld=lld does not work when -flto is enabled

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100959
   Summary: -fuse-ld=lld does not work when -flto is enabled
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Linux:
cqwrteur@Home-Server:~/fast_io/.tmp/unit$ g++ -o iobuf_file iobuf_file.cc
-Ofast -std=c++20 -s -fuse-ld=lld -I../../include -march=native -flto
ld.lld: error: undefined symbol: main
>>> referenced by /usr/lib/x86_64-linux-gnu/crt1.o:(_start)
collect2: error: ld returned 1 exit status
Windows:
Cannot find winmain.

[Bug c++/100957] [12 Regression] ICE: Segmentation fault (in copy_tree_body_r)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with my r12-1171-g098f4e989beb1a1be1157430c56ea4f158c1d538

[Bug tree-optimization/100299] [11 Regression] cc1plus taking all RAM in EVRP

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11/12 Regression] cc1plus  |[11 Regression] cc1plus
   |taking all RAM in EVRP  |taking all RAM in EVRP
   Assignee|unassigned at gcc dot gnu.org  |amacleod at redhat dot 
com
  Known to fail||11.1.0
 Resolution|FIXED   |---
 Status|RESOLVED|ASSIGNED
  Known to work||12.0

--- Comment #4 from Richard Biener  ---
On trunk.  Keeping open for eventual backporting.

[Bug lto/100959] -fuse-ld=lld does not work when -flto is enabled (aka LLVM lld does not work correctly with gcc)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
Yes this is not our bug to fix.  Use -fno-use-linker-plugin

[Bug lto/100959] -fuse-ld=lld does not work when -flto is enabled (aka LLVM lld does not work correctly with gcc)

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

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

--- Comment #2 from Andrew Pinski  ---
That is the plugin API/ABI is different between LLVM and binutils ld (bfd and
gold).  We only support binutils ld plugins.

[Bug tree-optimization/55155] Autovectorization does not use unaligned loads/stores

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Been fixed since at least GCC 8.
_Z4funcPfS_fj:
sall$4, %edx
je  .L1
shrl$2, %edx
xorl%eax, %eax
shufps  $0, %xmm0, %xmm0
salq$4, %rdx
.p2align 4,,10
.p2align 3
.L3:
movups  (%rsi,%rax), %xmm1
movups  (%rdi,%rax), %xmm2
mulps   %xmm0, %xmm1
subps   %xmm1, %xmm2
movups  %xmm2, (%rdi,%rax)
addq$16, %rax
cmpq%rax, %rdx
jne .L3
.L1:
ret

[Bug debug/100960] New: var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com via Gcc-bugs]

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

Bug ID: 100960
   Summary: var-tracking: parameter location in subregister not
tracked
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---
Target: s390x-*-*

Created attachment 50960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50960&action=edit
var-tracking dump

On IBM Z we often have the case that debug information for a parameter points
to the entry value only although the value is held in a register, too.

__attribute__((noinline, noclone)) void
f1 (int x)
{
  __asm volatile ("" : "+r" (x) : : "memory");
}

__attribute__((noinline, noclone)) int
f2 (int x)
{
  f1 (x);
  return x;  // (*)
}

__attribute__((noinline, noclone)) int
f3 (int x)
{
  f2 (x);
  return 3;
}

int
main ()
{
  f3 (42);
  return 0;
}

0x1000600   stmg%r12,%r15,96(%r15)
0x1000606 lay %r15,-160(%r15)
0x100060clgr %r12,%r2
0x1000610brasl   %r14,0x10005f8 
0x1000616lgr %r2,%r12
0x100061almg %r12,%r15,256(%r15)
0x1000620br  %r14

At program point (*) debug information for parameter x points to the entry
value only. Thus it gets neglected that the value was moved to call-saved
register r12 prior function call f1.

Having a look at var-tracking this seems to boil down to the fact that register
r2 is saved (lgr %r12,%r2) and restored (lgr %r2,%r12) in DI mode whereas
parameter x has only SI mode and the relation is not tracked. In other words,
for parameter x var-tracking is looking after the function call f1 for an SI
value and doesn't find it although it is a subvalue held in register r12.

Is this a known deficiency or am I missing something?

[Bug target/14224] GCC generates pessimizes code for integer division

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #2)
> I suggest to mark this bug as invalid, because it is not possible for gcc to
> know maximum value of (x*y).

Invalid then.

[Bug target/14255] i386 backend should be teached how to use divl

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

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

Bug 14224 Summary: GCC generates pessimizes code for integer division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14224

   What|Removed |Added

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

[Bug fortran/100961] New: Intrinsic function as value to a class(*) assumed rank argument fails

[mscfd at gmx dot net via Gcc-bugs]

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

Bug ID: 100961
   Summary: Intrinsic function as value to a class(*) assumed rank
argument fails
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

Created attachment 50961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50961&action=edit
test case

Providing the value of an intrinsic function to a subroutine with an class(*)
assumed rank argument fails. The correct rank is not recognised.
Encapsulating the intrinsic function invocation in parenthesis avoids the bug.

[Bug middle-end/30267] folding (~ -x) >= (-2147483647-1) to x != -2147483648

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Known to fail||4.8.5

--- Comment #3 from Andrew Pinski  ---
Fixed with at least GCC 7.
It was still broken in GCC 4.8.5 though.

[Bug middle-end/100951] vec_duplicate leads to worse code

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

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

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

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

commit r12-1280-gffe3a37f54ab866d85bdde48c2a32be5e09d8515
Author: Richard Biener 
Date:   Mon Jun 7 20:08:13 2021 +0200

middle-end/100951 - make sure to generate VECTOR_CST in lowering

When vector lowering creates piecewise ops make sure to create
VECTOR_CSTs instead of CONSTRUCTORs when possible.

gcc/

2021-06-07  Richard Biener  

PR middle-end/100951
* tree-vect-generic.c (expand_vector_piecewise): Build a
VECTOR_CST if all elements are constant.
(expand_vector_condition): Likewise.
(lower_vec_perm): Likewise.
(expand_vector_conversion): Likewise.

gcc/testsuite/

2021-06-07  H.J. Lu  

PR middle-end/100951
* gcc.target/i386/pr100951.c: New test.

[Bug middle-end/100951] vec_duplicate leads to worse code

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

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

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

--- Comment #1 from Richard Biener  ---
sounds like an implementation oversight to me.

[Bug target/43526] ICE: in construct_container, at config/i386/i386.c:5733 with -m96bit-long-double at x86_64-linux

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Known to work||12.0
  Known to fail||

--- Comment #6 from Zdenek Sojka  ---
Since r12-94 (PR100041 fix), -m96bit-long-double is rejected for this target.

[Bug target/14224] GCC generates pessimizes code for integer division

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Well, during expansion VRP can be queried (SSA_NAME_RANGE_INFO or ranger if it
is extended to be queryable during expansion) and in some cases (not in the #c0
testcase though) we can know the range.

[Bug rtl-optimization/17234] if-conversion problem

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

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

--- Comment #8 from Andrew Pinski  ---
I can no longer reproduce this issue with a more recent compiler.  Also The
order of the basic block changed.
So we have now:
entry
je L3
calls
L3:
ret

Most likely due to the heurstics changes.
Anyways I force the other order using __builtin_expect and I get:
bar:
pushl   %esi
xorl%eax, %eax
pushl   %ebx
subl$20, %esp
movl32(%esp), %esi
movl4(%esi), %ebx
testl   %ebx, %ebx
jne .L8
addl$20, %esp
popl%ebx
popl%esi
ret
.p2align 4,,10
.p2align 3
.L8:
subl$12, %esp
sall$2, %ebx
pushl   $132
callbaz
addl$12, %esp
pushl   %ebx
pushl   (%esi)
pushl   %eax
movl%eax, 28(%esp)
callfoo
addl$16, %esp
movl12(%esp), %eax
addl$20, %esp
popl%ebx
popl%esi
ret

 CUT ---
We duplicate the ret here even.

[Bug tree-optimization/22196] Missed back prop

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Andrew Pinski  ---
This actually undos some of what phi-opt might do and only should be done for a
few operations.  I think divide, multiple, shifts and rotates should be done
and only with a constant operand.  This has to be done late very close to
expand even.

I will be implementing this but might miss GCC 12 as I have a lot on my plate
already for GCC 12.

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
We have two different VALUEs here,
(value/u:SI 5:5 @0x4a99810/0x4a402e0)
 locs:
  from insn 1 (value/u:SI 6:261 @0x4a99828/0x4a40310)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ x ]))
  from insn 1 (reg:SI 2 %r2 [ x ])
 no addrs
and
(value/u:DI 15:15 @0x4a99900/0x4a404c0)
 locs:
  from insn 17 (reg:DI 12 %r12 [63])
  from insn 17 (reg:DI 2 %r2 [ x+-4 ])
 no addrs
and cselib doesn't record that when insn 17 copies the 15:15 value to a new
location it effectively copies also the 5:5 value which is present in its low
bits.
Maybe it would be better to record among the locs of 5:5 that it is equivalent
to
lowpart subreg of (value:DI 15:15), perhaps at the point where the value 15:15
is created or so?

[Bug c++/100957] [12 Regression] ICE: Segmentation fault (in copy_tree_body_r)

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

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

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

https://gcc.gnu.org/g:8b4641033ab6901c18f68b98843f1038a9a52e03

commit r12-1284-g8b4641033ab6901c18f68b98843f1038a9a52e03
Author: Jakub Jelinek 
Date:   Tue Jun 8 11:16:41 2021 +0200

openmp: Fix ICE on depend(source) clause during cdtor cloning [PR100957]

The depend(source) clause has NULL OMP_CLAUSE_DECL, it has just the
depend kind specified and no arguments.  So copy_tree_body_r shouldn't
check TREE_CODE on it without checking it is non-NULL.

2021-06-08  Jakub Jelinek  

PR c++/100957
* tree-inline.c (copy_tree_body_r): For OMP_CLAUSE_DEPEND don't
check TREE_CODE if OMP_CLAUSE_DECL is NULL.

* g++.dg/gomp/doacross-2.C: New test.

[Bug c++/100957] [12 Regression] ICE: Segmentation fault (in copy_tree_body_r)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug testsuite/100943] [12 regression] new test gcc.dg/pr100887.c in r12-1256 fails with excess errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/29881] union causes inefficient code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.5
  Known to work||4.8.5

--- Comment #8 from Andrew Pinski  ---
Been fixed for a long time now.  At least since GCC 4.8.5.  


  a$m_4 = MEM[(const union I16x8 &)p_2(D)];
  _5 = VIEW_CONVERT_EXPR<__v8hi>(a$m_4);
  _6 = __builtin_ia32_paddw128 (_5, _5);
  _7 = VIEW_CONVERT_EXPR<__m128i>(_6);
  MEM[(union I16x8 *)p_2(D)] = _7;


Either it was when SRA was improved or MEM_REF was added but it has been fixed
for over 8 years now.

[Bug middle-end/35345] Scalar replacement to handle output dependence

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||7.4.0
   Target Milestone|--- |10.0
  Known to work||10.0
   Last reconfirmed|2008-12-29 06:18:38 |2021-6-8
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 10 and above.

[Bug c/100962] New: Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net via Gcc-bugs]

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

Bug ID: 100962
   Summary: Poor optimization of AVR code when using structs in
__flash
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mojo at world3 dot net
  Target Milestone: ---

Example code here: https://godbolt.org/z/1hnPoGdTd

In this code a const __flash struct holds some data used to initialize
peripherals. Line 59 is the definition of the struct.

With the __flash attribute the generated AVR assembly uses the X register as a
pointer to the peripheral. The X pointer lacks displacement with LDI so rather
inefficient code is generated, e.g.

141 channels[ch].dma.ch->TRFCNT = BUFFER_SIZE;
142 channels[ch].dma.ch->REPCNT = 0;

ldi r18,lo8(26)
ldi r19,0
adiw r26,4
st X+,r18
st X,r19
sbiw r26,4+1
adiw r26,6
st X,__zero_reg__
sbiw r26,6

Removing the __flash attribute produces much better code, with the Z register
used with displacement.

The issue appears to be because the other pointer register that supports
displacement, Y, is used for the stack so unavailable. Introducing the need to
use LPM instructions to read data from flash seems to cause Z not to be used
for the peripheral, with X used instead. Z is used only for LPM.

The best possible optimisation here seems to be to read all values needed from
flash first, and then switch to using Z as a pointer to the peripheral.

[Bug rtl-optimization/45215] Tree-optimization misses a trick with bit tests

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization

--- Comment #2 from Andrew Pinski  ---
Note on the trunk I have change the code slightly to get a cmove done.
With the cmove we could simplify the following RTL:
Trying 27, 28 -> 29:
   27: {flags:CCZ=cmp(r86:SI&0x100,0);r82:SI=r86:SI&0x100;}
  REG_DEAD r86:SI
   28: r85:SI=0xffe6
   29: r82:SI={(flags:CCZ==0)?r82:SI:r85:SI}
  REG_DEAD r85:SI
  REG_DEAD flags:CCZ
Failed to match this instruction:
(set (reg/v:SI 82 [ tt ])
(if_then_else:SI (eq (zero_extract:SI (reg:SI 86)
(const_int 1 [0x1])
(const_int 8 [0x8]))
(const_int 0 [0]))
(and:SI (reg:SI 86)
(const_int 256 [0x100]))
(const_int -26 [0xffe6])))

But that would be a 3->3 combine which I don't know if combine does.  I know it
does 3->1 and 3->2

andl$256, %edi
movl$-26, %eax
cmovne  %eax, %edi

I also don't know what the cost of doing cmov vs the shifts here though.
I know for aarch64, it is worse but that should have been modeled already.

[Bug tree-optimization/45217] Tree optimizations do not recognize partial stores

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Build|i686-pc-linux-gnu   |
   Host|i686-pc-linux-gnu   |
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Target|i686-pc-linux-gnu   |

--- Comment #2 from Andrew Pinski  ---
BIT_INSERT_EXPR can be used here.
I have a few set of patches which should do to this.

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

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

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

--- Comment #3 from Jakub Jelinek  ---
Slightly related was
https://gcc.gnu.org/legacy-ml/gcc-patches/2010-03/msg01379.html
So, perhaps for the case where we do not track the source register in the wider
mode we could for var-tracking purpose also pretend the move is not a DImode
copy, but a SImode copy.
But what I wrote above is also an option, record permanent equivalency that the
narrower value is lowpart subreg of the wider value.

[Bug target/47949] Missed optimization for -Os using xchg instead of mov.

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

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

--- Comment #4 from Andrew Pinski  ---
This might have been fixed already via the commit referenced in PR92549

[Bug tree-optimization/45217] Tree optimizations do not recognize partial stores

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

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

--- Comment #3 from Richard Biener  ---
Note that alternatively we do allow BIT_FIELD_REF on the LHS if it operates on
memory... (we're inserting into a global variable for the testcase).  But
indeed a RMW cycle might be prefered on targets that cannot do stv on memory.

[Bug c++/100963] New: GCC 11 regression: templated constructor with std::initializer_list is not selected

[j.l.k at gmx dot com via Gcc-bugs]

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

Bug ID: 100963
   Summary: GCC 11 regression: templated constructor with
std::initializer_list is not selected
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.l.k at gmx dot com
  Target Milestone: ---

Consider the following program (preprocessed source is attached):

```
#include 

struct A
{
explicit A(int)
{
std::cout << "A(int) constructor called" << std::endl;
}

A(std::initializer_list)
{
std::cout << "A's constructor with initializer_list called" <<
std::endl;
}
};

struct B
{
explicit B(int)
{
std::cout << "B(int) constructor called" << std::endl;
}

template
B(std::initializer_list)
{
std::cout << "B's constructor with initializer_list called" <<
std::endl;
}
};

int main()
{
A({0});
B({0});
}
```

When compiled with GCC 11 (`g++ -std=c++14
gcc11_initializer_list_constructor.cpp -o gcc11_initializer_list_constructor`),
the program gives the following output:

A's constructor with initializer_list called
B(int) constructor called

Whereas with GCC 10 it produced this as expected:

A's constructor with initializer_list called
B's constructor with initializer_list called

Tested with GCC 11.1.0 from Arch Linux, the PKGBUILD is located here: 
https://github.com/archlinux/svntogit-packages/blob/92c91ef891e9e2ed48f7f75921eb6321a2c7947d/trunk/PKGBUILD

[Bug middle-end/30267] folding (~ -x) >= (-2147483647-1) to x != -2147483648

[bruno at clisp dot org via Gcc-bugs]

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

Bruno Haible  changed:

   What|Removed |Added

  Known to work||10.3.0, 11.1.0, 6.5.0,
   ||7.5.0, 8.4.0, 9.3.0
  Known to fail||4.9.4, 5.5.0

--- Comment #4 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #3)
> Fixed with at least GCC 7.
> It was still broken in GCC 4.8.5 though.

Indeed. Here's the status with GCC versions since 4.0.x:

4.0.4 optimized
4.1.2 missed
4.2.4 missed
4.3.6 missed
4.4.7 missed
4.5.4 missed
4.6.4 missed
4.7.3 missed
4.8.5 missed
4.9.4 missed
5.5.0 missed
6.5.0 optimized
7.5.0 optimized
8.4.0 optimized
9.3.0 optimized
10.3.0 optimized
11.1.0 optimized

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |11.2
Summary|GCC 11 regression:  |[11/12 Regression] GCC 11
   |templated constructor with  |regression: templated
   |std::initializer_list is |constructor with
   |not selected|std::initializer_list is
   ||not selected

[Bug target/43526] ICE: in construct_container, at config/i386/i386.c:5733 with -m96bit-long-double at x86_64-linux

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
Now resolved as invalid, see #c6.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

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

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

--- Comment #1 from Richard Biener  ---
You are using quite old (and unmaintained) GCC - does using newer GCC, like GCC
10 or GCC 11 improve things?

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

[j.l.k at gmx dot com via Gcc-bugs]

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

Jakub Klinkovský  changed:

   What|Removed |Added

 CC||j.l.k at gmx dot com

--- Comment #1 from Jakub Klinkovský  ---
Created attachment 50962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50962&action=edit
preprocessed file for the test case

[Bug d/100964] New: d: TypeInfo error when using slice copy on Structs with -fno-rtti

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 100964
   Summary: d: TypeInfo error when using slice copy on Structs
with -fno-rtti
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Example test:
---
//flags: -fno-druntime
struct A{}

extern(C):
void main() 
{
int* x;
x[0 .. 0] = x[0 .. 0]; 
//OK

A* a;
a[0 .. 0] = a[0 .. 0];
//Error: TypeInfo cannot be used with -fno-rtti
}

[Bug debug/100852] [11/12 Regression] -fcompare-debug failure (length) with -Og -fif-conversion -fno-tree-ccp -fno-tree-copy-prop

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r11-2588-gc072fd236dc08f990bfcffd98b27f211a39bb404

[Bug rtl-optimization/100622] Conversion to smaller unsigned type in loop

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

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

--- Comment #7 from Segher Boessenkool  ---
Nice :-)

[Bug fortran/100965] New: [OpenMP] ICE: Error: incorrect sharing of tree nodes

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

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

Bug ID: 100965
   Summary: [OpenMP] ICE: Error: incorrect sharing of tree nodes
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Found when working on 'defaultmap' (related: PR90742, PR92568).

The following gives an ICE:

SAVE_EXPR <.strxa.6>
#pragma omp target num_teams(1) thread_limit(0) map(tofrom:*strxa [len:
SAVE_EXPR <.strxa.6>]) map(alloc:strxa [pointer assign, bias: 0]) map(to:.strxa
[len: 8]) [child fn: MAIN__._omp_fn.1 (.omp_data_arr.7, .omp_data_sizes.8,
.omp_data_kinds.9)]
during GIMPLE pass: cfg

foo.f90:8:14: internal compiler error: verify_gimple failed

0xf8b4e1 verify_gimple_in_cfg(function*, bool)
../../repos/gcc/gcc/tree-cfg.c:5509

but only when used in two separate target regions:

implicit none
  character(len=:), allocatable :: strXa
  !$omp target
strXa = ""
  !$omp end target

  !$omp target
strXa = ""
  !$omp end target
end

[Bug c/100920] bogus warnings with -Wscalar-storage-order

[george.thopas at gmail dot com via Gcc-bugs]

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

--- Comment #9 from George Thopas  ---
/*
Hi Eric,

1) I noticed there's a typo in the test, (which is my fault) and may give
   unexpected behavior later on

memcpy(msg2, &msg1, sizeof(t_s12));
 => should be  memcpy(msg2, msg1, sizeof(t_s12));

2) Trying to get a platform built free of these warning, I still see quite some
which match below example.  
Raising one for these cases is really problematic. Functions using void in
stead of an explicit type are explicitly saying that the type does not matter.
There never is a warning for any other type where you pass them. so
I hope  you can give this one another go.

Thanks again for your patience.

*/


#include 
#include 

#define SIZE 10

struct be {
int a;
int b; 
} __attribute__((scalar_storage_order("big-endian")));

typedef struct be t_be;

struct le {
int a;
int b; 
} __attribute__((scalar_storage_order("little-endian")));

typedef struct le t_le;


void memset2(void *s, char c, int n)
{
   char *d=(char *)s;
   for(int i=0;i

[Bug target/100966] New: [AArch64] __builtin_roundeven[f] is not inlined

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

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

Bug ID: 100966
   Summary: [AArch64] __builtin_roundeven[f] is not inlined
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

The new roundeven builtins are not inlined on AArch64:

double f1 (double x)
{
  return __builtin_roundeven (x);
}

float f2 (float x)
{
  return __builtin_roundevenf (x);
}

f1:
b   roundeven
f2:
b   roundevenf

These should use the frintn instructions instead of calling the GLIBC
functions.

[Bug libstdc++/100947] gthr-default.h

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

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

--- Comment #1 from Jonathan Wakely  ---
Please provide your full configure command.

Does using --disable-threads make any difference?

[Bug c++/100956] Unused variable warnings ignore "if constexpr" blocks where variables are conditionally used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The warning is already fixed in the GCC 10 branch.

N.B. if you have a loop that does nothing but run trivial destructors, GCC will
optimize it out anyway.

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

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mattreecebentley at gmail dot 
com

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

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||10.3.0, 9.4.0
  Known to fail||11.1.0
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2021-06-08

--- Comment #2 from Patrick Palka  ---
Confirmed, started with r11-7289.

Reduced:

#include 

struct B {
  B(int) = delete;
  template B(std::initializer_list);
};

int main() {
  B({0});
}

[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to Patrick Palka from comment #3)
> Good point, confirmed.  Though I'm not sure if perfect forwarding here is
> strictly necessary to fix this testcase.  Perhaps the
> _S_has_simple_extra_args versions of _Partial should be forwarding the bound
> arguments as prvalues instead of as const lvalues?

It's pretty easy to come up with counterexamples that don't work (for example,
the type might be move-only).

It may be better to limit the "simple" case for take/drop to when the argument
type is integer-like; that's like 99% of uses anyway. Contrived examples gets
the perfect forwarding fun but that's fine.

Similarly, it might be a good idea to restrict the "simple" case for the other
adaptors a bit - perhaps to the case where the predicate is trivially copyable,
which should still give good diagnostic for a lot of uses, but avoids a
performance hit if the function object at issue is like...std::function.

[Bug d/100967] New: d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258) with -fno-rtti

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 100967
   Summary: d: ICE: Segmentation fault
(../../gcc/d/dmd/declaration.c:1258) with -fno-rtti
   Product: gcc
   Version: 9.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

With an empty object module - or an object module without a `class Object'
definition, a segfault occurs when attempting to use anything that requires
TypeInfo.

---
module object;
extern(C) int main()
{
int[int] aa;
aa[0] = 1;
return 0;
}

[Bug d/100967] d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258) with -fno-rtti

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
ice.d:4:7: internal compiler error: Segmentation fault
4 | aa[0] = 1;
  |   ^
0xe958af crash_signal
../../gcc/toplev.c:327
0x88d8b8 TypeInfoDeclaration::TypeInfoDeclaration(Type*)
../../gcc/d/dmd/declaration.c:1258
0x88ddb8
TypeInfoAssociativeArrayDeclaration::TypeInfoAssociativeArrayDeclaration(Type*)
../../gcc/d/dmd/declaration.c:1461
0x88de11 TypeInfoAssociativeArrayDeclaration::create(Type*)
../../gcc/d/dmd/declaration.c:1472
0x9de4f5 create_typeinfo(Type*, Module*)
../../gcc/d/typeinfo.cc:1559
0x9de8fa build_typeinfo(Loc const&, Type*)
../../gcc/d/typeinfo.cc:1394
0x9cd628 ExprVisitor::visit(IndexExp*)
../../gcc/d/expr.cc:1266
0x9c9ae0 build_expr(Expression*, bool, bool)
../../gcc/d/expr.cc:3129
0x9cdedc ExprVisitor::visit(AssignExp*)
../../gcc/d/expr.cc:1218
0x9c9ae0 build_expr(Expression*, bool, bool)
../../gcc/d/expr.cc:3129
0x9ca54c ExprVisitor::visit(CommaExp*)
../../gcc/d/expr.cc:1330
0x9c9ae0 build_expr(Expression*, bool, bool)
../../gcc/d/expr.cc:3129
0x9c9b8b build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3152
0x9d8101 IRVisitor::visit(ExpStatement*)
../../gcc/d/toir.cc:1092
0x9d7c1f IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:274
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1109
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1099
0x9d7c1f IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:274
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1109
0x9d7c1f IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1099
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/100923] [9/10/11/12 Regression] wrong code at -O2 and above on x86_64-linux-gnu

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

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

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

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

commit r12-1295-g7a56d3d3e99cc77ad8a6a674870c814da6225675
Author: Richard Biener 
Date:   Tue Jun 8 12:52:12 2021 +0200

tree-optimization/100923 - fix alias-ref construction wrt availability

This PR shows that building an ao_ref from value-numbers is prone to
expose bogus contextual alias info to the oracle.  The following makes
sure to construct ao_refs from SSA names available at the program point
only.

On the way it modifies the awkward valueize_refs[_1] API.

2021-06-08  Richard Biener  

PR tree-optimization/100923
* tree-ssa-sccvn.c (valueize_refs_1): Take a pointer to
the operand vector to be valueized.
(valueize_refs): Likewise.
(valueize_shared_reference_ops_from_ref): Adjust.
(valueize_shared_reference_ops_from_call): Likewise.
(vn_reference_lookup_3): Likewise.
(vn_reference_lookup_pieces): Likewise.  Re-valueize
with honoring availability when we are about to create
the ao_ref and valueized before.
(vn_reference_lookup): Likewise.
(vn_reference_insert_pieces): Adjust.

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

[Bug tree-optimization/100923] [9/10/11 Regression] wrong code at -O2 and above on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression] wrong
   |wrong code at -O2 and above |code at -O2 and above on
   |on x86_64-linux-gnu |x86_64-linux-gnu
  Known to work||12.0

--- Comment #7 from Richard Biener  ---
OK, fixed on trunk.  Let's see if there's any fallout optimization-wise.

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/91706] [9/10/11/12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:46c1a9f6d03ab444b42c41067597e3fbfba38486

commit r11-8524-g46c1a9f6d03ab444b42c41067597e3fbfba38486
Author: Jason Merrill 
Date:   Fri Apr 16 11:13:40 2021 -0400

c++: alias with same name as base fn [PR91706]

This is a bit complex.  Looking up c in the definition of D::c finds
C::c, OK.  Looking up c in the definition of E finds D::c, OK.  Since the
alias is not dependent, we strip it from the template argument, leaving

using E = A())>;

where 'c' still refers to C::c.  But instantiating E looks up 'c' again and
finds D::c, which isn't a function, and sadness ensues.

I think the bug here is looking up 'c' in D at instantiation time; the
declaration we found before is not dependent.  This seems to happen because
baselink_for_fns gets BASELINK_BINFO wrong; it is supposed to be the base
where lookup found the functions, C in this case.

gcc/cp/ChangeLog:

PR c++/91706
* semantics.c (baselink_for_fns): Fix BASELINK_BINFO.

gcc/testsuite/ChangeLog:

PR c++/91706
* g++.dg/template/lookup17.C: New test.

[Bug middle-end/54400] recognize vector reductions

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Hmm, with vectorizer support we get

   [local count: 1073741824]:
  _7 = .REDUC_PLUS (v_3(D)); [tail call]
  return _7;

but

f:
.LFB5669:
.cfi_startproc
movapd  %xmm0, %xmm1
unpckhpd%xmm0, %xmm0
addpd   %xmm1, %xmm0
ret

(note avoiding hadd in the reduc pattern was intended).  Not sure if
two element reduction vectorization is worthwhile - my current patch
bails w/o -fassociative-math (which is supposedly unnecessary for
two elements).

But mine anyway.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net via Gcc-bugs]

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

--- Comment #2 from mojo at world3 dot net ---
avr-gcc-11.1.0-x64-windows>bin\avr-gcc -Og  -xc -Wall -mmcu=atxmega64a1u test.c
avr-gcc-11.1.0-x64-windows>bin\avr-objdump -h -S a.out > list.s

Still producing code like this

 2de:   18 97   sbiwr26, 0x08   ; 8
 2e0:   19 96   adiwr26, 0x09   ; 9

Thanks.

[Bug debug/100852] [11/12 Regression] -fcompare-debug failure (length) with -Og -fif-conversion -fno-tree-ccp -fno-tree-copy-prop

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

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

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-06-08
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50963&action=edit
gcc12-pr100852.patch

Untested fix.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

[mojo at world3 dot net via Gcc-bugs]

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

--- Comment #3 from mojo at world3 dot net ---
Apologies, I noticed I had -Og on. Tried with -O3 and it optimised the struct
away. With -O2 it uses the Z register with displacement, reading data from
flash.

So it seems that only -Og produces poor code with V11. The older version 5.4.0
has issues either way. Not sure if that is a bug or just necessary for
debugging.

[Bug inline-asm/100953] Add memory clobbers just for reads or just for writes

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

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

--- Comment #2 from Segher Boessenkool  ---
Sure :-)  But syntactically it probably is best put amongst the clobbers,
all code parsing that already knows about handling various special cases
of syntax (well, just "memory" and "cc", and the various ways of naming
registers).

[Bug target/58790] [missed optimization] reduction of masks of builtin vectors not transformed to ptest or movemask instructions

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-08
 Target||x86_64-*-* i?86-*-*

--- Comment #3 from Richard Biener  ---
So it's slightly more complex than a BB reduction with plus since SLP sees

   [local count: 1073741824]:
  _1 = a_8(D) == b_9(D);
  _2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
  _3 = BIT_FIELD_REF <_2, 32, 0>;
  if (_3 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1006632961]:
  goto ; [100.00%]

   [local count: 536870913]:
  _4 = BIT_FIELD_REF <_2, 32, 32>;
  if (_4 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]
...

and thus it requires some if-conversion.  Maybe this is even good enough
for pattern matching in forwprop, turning it into

   if (_2 == { -1, -1, -1, -1 })

[Bug tree-optimization/58821] conditional reduction does not vectorize

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||7.5.0
 Status|NEW |RESOLVED

--- Comment #2 from Richard Biener  ---
This now works, at least GCC 7+.  I believe we fix this up in if-conversion
via is_cond_scalar_reduction & friends which was added 2014.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 58821 Summary: conditional reduction does not vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58821

   What|Removed |Added

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

[Bug other/100968] New: libiberty: stuck in infinite loop in nm-new while demangling rust symbols

[terrynini38514 at gmail dot com via Gcc-bugs]

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

Bug ID: 100968
   Summary: libiberty: stuck in infinite loop in nm-new while
demangling rust symbols
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terrynini38514 at gmail dot com
  Target Milestone: ---

Created attachment 50964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50964&action=edit
demangling POC

Sorry for didn't identify the actual version of libiberty, but this bug can be
reproduce by clone the latest version (2.36.50) of binutils-gdb.

The POC cause nm-new stuck in infinite loop at rust-demangle.c:1024 and
rust-demangle.c:747 while using the nm-new with option -C, and there are more
similar case I found, I can attach them if needed. All of these cases just
stuck in a infinite loop in rust-demangle.c.

And I want to apply for CVE, if that requires me to do anything more, like
attach a valid patch or something ? Let me know, please.

Thanks.

[Bug target/58790] [missed optimization] reduction of masks of builtin vectors not transformed to ptest or movemask instructions

[kretz at kde dot org via Gcc-bugs]

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

--- Comment #4 from Matthias Kretz (Vir)  ---
I'm still not familiar with this part of GCC, but isn't `_2 == { -1, -1, -1, -1
}` equivalent to _1, i.e. it reverses VEC_COND_EXPR? However, if the `==` is
supposed to return a scalar boolean instead of a vector boolean, then that's
the expression which most generally describes all_equal1.

[Bug target/57952] AVX/AVX2 no ymm registers used in a trivial reduction

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.1.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from Richard Biener  ---
I can now see this vectorized with at least GCC 10 and up.  Note we're
vectorizing the _outer_ loop here but we also manage to vectorize the
inner loop only if I comment out the outer one, it just looks less efficient.

.L2:
vmovdqa %ymm6, %ymm2
movl$1000, %eax
.p2align 4,,10
.p2align 3
.L3:
vmovdqa %ymm2, %ymm0
vpaddd  %ymm6, %ymm2, %ymm2
vcvtdq2ps   %ymm0, %ymm0
vaddps  %ymm5, %ymm0, %ymm0
vmulps  %ymm11, %ymm0, %ymm0
vmovaps %ymm0, %ymm1
vfmadd132ps %ymm10, %ymm9, %ymm1
vfmadd132ps %ymm0, %ymm8, %ymm1
vfmadd132ps %ymm0, %ymm7, %ymm1
vfmadd132ps %ymm0, %ymm5, %ymm1
vfmadd132ps %ymm0, %ymm4, %ymm1
vfmadd132ps %ymm1, %ymm4, %ymm0
vaddps  %ymm0, %ymm3, %ymm3
decl%eax
jne .L3
incl%edx
cmpl$12, %edx
jne .L2

[Bug libgomp/59546] wrong behavior with reduction

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Invalid then.

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||7.5.0

--- Comment #6 from Richard Biener  ---
Fixed in GCC 8+.

[Bug tree-optimization/81815] Invalid conditional reduction

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||8.1.0
  Known to fail||7.5.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed in GCC 8+.

[Bug fortran/100965] [OpenMP] ICE: Error: incorrect sharing of tree nodes

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug fortran/100965] [OpenMP] ICE: Error: incorrect sharing of tree nodes

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 50965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50965&action=edit
gcc12-pr100965.patch

Untested fix.

[Bug libstdc++/100947] gthr-default.h

[kclifford at tranaptic dot ca via Gcc-bugs]

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

--- Comment #2 from Keith Clifford  ---
The configure command is:

configure --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=arm-eabi
--enable-__cxa_atexit --with-pkgversion=Tranaptic-2021/06/06-12:09:39
--with-bugurl=none --enable-languages=c,c++ --enable-interwork
--enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs
--disable-shared --disable-threads --disable-win32-registry --disable-nls
--with-newlib --with-gmp=/home/cross-gcc/11.1.0/cross-local
--with-mpfr=/home/cross-gcc/11.1.0/cross-local
--with-mpc=/home/cross-gcc/11.1.0/cross-local --with-host-libstdcxx=-lstdc++
-lsupc++ --prefix=/home/cross-gcc/11.1.0/arm-eabi -v

I'm already using --disable-threads so no it doesn't help.

[Bug debug/100969] New: Incorrect debug info for struct under O1 optimization

[liyd2021 at gmail dot com via Gcc-bugs]

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

Bug ID: 100969
   Summary: Incorrect debug info for struct under O1 optimization
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liyd2021 at gmail dot com
  Target Milestone: ---

Reproduced on: gcc 11.1.0, 9.3.0, 8.4.0 with gdb or lldb (Ubuntu 20.04.2)

$ cat test.c
struct foo { int a, b, c; };

void not_opt(struct foo x) __attribute__((noipa));
void not_opt(struct foo x) {}

int main ()
{
struct foo f = { 7, 8, 9 };
not_opt(f);
return 0;
}

Compile command:
$ gcc -g -O1 test.c -o test
$ gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/vm/opt/gcc-11.1.0/libexec/gcc/x86_64-unknown-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/vm/var/tmp/vm/gcc-11.1.0_source/gcc-11.1.0/configure
--prefix=/home/vm/opt/gcc-11.1.0 --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-linker-build-id
--enable-languages=c,c++,lto --disable-vtable-verify
--with-default-libstdcxx-abi=new --enable-libstdcxx-debug
--without-included-gettext --enable-plugin --disable-initfini-array
--disable-libgcj --enable-plugin --disable-multilib --with-tune=generic
--build=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --with-pkgversion=vm
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0

Debugging with gdb:
(gdb) l
1 struct foo { int a, b, c; };
2
3 void not_opt(struct foo x) __attribute__((noipa));
4 void not_opt(struct foo x) {}
5
6 int main ()
7 {
8 struct foo f = { 7, 8, 9 };
9 not_opt(f);
10 return 0;
(gdb) b 9
(gdb) r
(gdb) print f
$1 = {a = 7, b = 8, c = 0} <-- **BUG**: c should be 9

LLDB also reports c = 0. Should be a debug-info bug.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> So we hit
> 
> /* Check if a STRING_CST fits into the field.
>Tolerate only the case when the NUL termination
>does not fit into the field.   */
> 
> static bool
> check_string_literal (tree string, unsigned HOST_WIDE_INT size)
> {
> ...
>   if (mem_size != size)
> return false;
> 
> so in this case the NUL termination is missing.  TREE_STRING_LENGTH is 1
> but the field size is 2.  The CTOR is
> 
> {"a", "b"}
> 
> and has a type of char[2][2].  Looks like a FE bug to me.

Yes, it's a FE bug.

If the line is changed to 

   print *, [character(len(x(1:2))) :: 'a ', ' b']

or

   print *, [character(len(x(1:1))) :: 'a', 'b']

the code compiles and runs as expected.  The type
declaration is set to 2 while the elements in the
constructor have a len of 1.  The FE should likely
check for too short of an element and blank pad.

However, someone needs to check if this is a valid
structure constructor, because technically the 
elements are type incompatible with declared type
(ie., different type kind parameters).

[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-08
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
AFAIU the test it works for me with GCC10, 11, and 12.

What is tour output of

Fortran -v?

[Bug c/100920] bogus warnings with -Wscalar-storage-order

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

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

--- Comment #10 from Eric Botcazou  ---
> Raising one for these cases is really problematic. Functions using void in
> stead of an explicit type are explicitly saying that the type does not
> matter. There never is a warning for any other type where you pass them. so
> I hope  you can give this one another go.

No, the warning needs to be conservative.

[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org

--- Comment #11 from Peter Bergner  ---
(In reply to H.J. Lu from comment #10)
> (In reply to seurer from comment #9)
> > 
> > seurer@gcc1-power7:~/gcc/git/build/gcc-test$ grep .rodata attr-retain-1.s 
> > .string "used_rodata2"
> > .string "unused_rodata"
> > .string "used_rodata"
> > .globl used_rodata2
> > .globl unused_rodata
> > .globl used_rodata
> > .type   unused_rodata, @object
> > .size   unused_rodata, 4
> > unused_rodata:
> > .section.sdata.used_rodata,"awR"
> ^
> used_rodata is in a writable section.  Is this intentional? -m64 generates
> 
> .section.rodata.used_rodata,"aR"
> .align 2
> .type   used_rodata, @object
> .size   used_rodata, 4
> used_rodata:
> .long   2   
> 
> which looks correct.  If it is intentional, test should exclude -m32 for
> powerpc64-linux-gnu.

Adding Alan for his input here.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

[gscfq--- via Gcc-bugs]

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

--- Comment #5 from G. Steinmetz  ---

It should be valid, type-spec is explicitly given and the ac-values
are type compatible (see e.g. F2018 7.8). With len(x(1:2))==2 the
following simplified example works :


$ cat zz1.f90
program p
   print *, [character(2) :: 'a', 'b']
   print *
   print *, 'len :', len ([character(3) :: 'a', 'bc', 'def', 'last'])
   print *, 'size:', size([character(3) :: 'a', 'bc', 'def', 'last'])
   print *, [character(3) :: 'a', 'bc', 'def', 'last']
end


$ gfortran zz1.f90 && ./a.out
 a b

 len :   3
 size:   4
 a  bc deflas

[Bug fortran/100970] New: ICE in output_constructor_regular_field, at varasm.c:5514

[gscfq--- via Gcc-bugs]

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

Bug ID: 100970
   Summary: ICE in output_constructor_regular_field, at
varasm.c:5514
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

These invalid codes (different shape for array assignment, see z0)
affect versions down to at least r5. Case z1 is silently accepted
(but not with -m32). I wonder how this could be related to pr100950.


$ cat z0.f90
module m
   integer :: a(1) = [1, 2]
end


$ cat z1.f90
module m
   type t
  integer :: a(1) = [1, 2]
  real, pointer :: b => null()
   end type
end


$ cat z2.f90
module m
   type t
  integer :: a(1) = [1, 2, 3]
  real, pointer :: b => null()
   end type
end


$ cat z3.f90
module m
   type t
  integer :: a(1) = [1, 2, 3, 4]
  real, pointer :: b => null()
   end type
end


$ cat z4.f90
module m
   type t
  integer :: a(1) = [1, 2, 3, 4, 5]
  real, pointer :: b => null()
   end type
   type(t) :: x
end


$ gfortran-12-20210606 -c z0.f90
z0.f90:2:18:

2 |integer :: a(1) = [1, 2]
  |  1
Error: Different shape for array assignment at (1) on dimension 1 (1 and 2)

$ gfortran-12-20210606 -c z1.f90

$ gfortran-12-20210606 -c z4.f90
z4.f90:7:3:

7 | end
  |   ^
internal compiler error: in output_constructor_regular_field, at varasm.c:5514
0xf3fdad output_constructor_regular_field
../../gcc/varasm.c:5514
0xf3fdad output_constructor
../../gcc/varasm.c:5820
0xf400ef output_constant
../../gcc/varasm.c:5172
0xf400ef assemble_variable_contents
../../gcc/varasm.c:2235
0xf47e8d assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2414
0xf4a18a varpool_node::assemble_decl()
../../gcc/varpool.c:595
0x8b0a8f output_in_order
../../gcc/cgraphunit.c:2135
0x8b0a8f symbol_table::compile()
../../gcc/cgraphunit.c:2353
0x8b33af symbol_table::compile()
../../gcc/cgraphunit.c:2540
0x8b33af symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2537

[Bug fortran/100971] New: ICE: Bad IO basetype (7)

[gscfq--- via Gcc-bugs]

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

Bug ID: 100971
   Summary: ICE: Bad IO basetype (7)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This invalid code z1 affects versions down to at least r5.
For reference, the case z0 is already rejected.


$ cat z0.f90
program p
   type t
   end type
   class(t), allocatable :: a
   print *, a
end


$ cat z1.f90
program p
   type t
   end type
   class(t), allocatable :: a
   print *, [a]
end


$ gfortran-12-20210606 -c z0.f90
z0.f90:5:13:

5 |print *, a
  | 1
Error: Data transfer element at (1) cannot be polymorphic unless it is
processed by a defined input/output procedure


$ gfortran-12-20210606 -c z1.f90
f951: internal compiler error: Bad IO basetype (7)
0x6ea049 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x6eb76a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x7f9e09 transfer_expr
../../gcc/fortran/trans-io.c:2507
0x7fd430 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2661
0x79e6c7 trans_code
../../gcc/fortran/trans.c:2138
0x7faefe build_dt
../../gcc/fortran/trans-io.c:2026
0x79e6a7 trans_code
../../gcc/fortran/trans.c:2110
0x7c4bc4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6893
0x74b3f6 translate_all_program_units
../../gcc/fortran/parse.c:6461
0x74b3f6 gfc_parse_file()
../../gcc/fortran/parse.c:6730
0x79772f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/100972] New: Missing error with "implicit none (external)"

[gscfq--- via Gcc-bugs]

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

Bug ID: 100972
   Summary: Missing error with "implicit none (external)"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

In the following example function g has no known interface and is
not declared external. implicit none (external) does not catch it.
Affects versions down to at least r5.


$ cat z1.f90
program p
   implicit none (external)
   real, external :: f
   real :: a, b
   a = f()
   b = g()
end


$ gfortran-12-20210606 -c z1.f90
$

BTW, ifort/ifx 2021.2 gets it right with
error #8889: Explicit declaration of the EXTERNAL attribute is required. [G]

[Bug fortran/53653] [IR Tracking] Disallow abstract/unlimited-polymorphic types in array constructors

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

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

--- Comment #3 from G. Steinmetz  ---

Very similar :

$ cat zz1.f90
program p
   type t
   end type
   class(t), allocatable :: a, b(:)
   allocate (b, source=[a])
end


$ gfortran-12-20210606 -c zz1.f90
zz1.f90:5:27:

5 |allocate (b, source=[a])
  |   1
internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1249
0x81cbea gfc_get_element_type(tree_node*)
../../gcc/fortran/trans-types.c:1249
0x7a1f4c gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*,
tree_node*, tree_node*, bool, bool, bool, locus*)
../../gcc/fortran/trans-array.c:1329
0x7ac382 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5319
0x7ac615 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7555
0x815fff gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:6289
0x79e617 trans_code
../../gcc/fortran/trans.c:2090
0x7c4bc4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6893
0x74b3f6 translate_all_program_units
../../gcc/fortran/parse.c:6461
0x74b3f6 gfc_parse_file()
../../gcc/fortran/parse.c:6730
0x79772f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug preprocessor/100904] [9/10/11/12 Regression] Wrong line location #include error "No such file or directory" – line + 1 [traditional mode as used by gfortran]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-08
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r7-1651-gac81cf0b2bf5efdd716d10d1c218eb5a17e1035b

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:91349e57bbfd010156b9128b2ad751c8843e7245

commit r12-1299-g91349e57bbfd010156b9128b2ad751c8843e7245
Author: Jason Merrill 
Date:   Tue Jun 8 09:19:58 2021 -0400

c++: braced-list overload resolution [PR100963]

My PR969626 patch made us ignore template candidates when there's a perfect
non-template candidate.  In this case, we were considering B(int) a perfect
match for B({0}), but the brace elision makes it imperfect.

PR c++/100963

gcc/cp/ChangeLog:

* call.c (perfect_conversion_p): Check check_narrowing.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist124.C: New test.

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:5af06ce836d4d8d1654db3855db8b86a994faf49

commit r11-8526-g5af06ce836d4d8d1654db3855db8b86a994faf49
Author: Jason Merrill 
Date:   Tue Jun 8 09:19:58 2021 -0400

c++: braced-list overload resolution [PR100963]

My PR969626 patch made us ignore template candidates when there's a perfect
non-template candidate.  In this case, we were considering B(int) a perfect
match for B({0}), but the brace elision makes it imperfect.

PR c++/100963

gcc/cp/ChangeLog:

* call.c (perfect_conversion_p): Check check_narrowing.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist124.C: New test.

[Bug c++/100973] New: gcc does not optimise based on knowing that `_mm256_movemask_ps` returns less than 255

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

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

Bug ID: 100973
   Summary: gcc does not optimise based on knowing that
`_mm256_movemask_ps` returns less than 255
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.yaroshevskij at gmail dot com
  Target Milestone: ---

Options: -O3 -std=c++20 -DNDEBUG -mavx

Code:

```
#include 

int masking_should_evaporate(__m256 values) {
  int top_bits = _mm256_movemask_ps(values);
  top_bits &= 255;
  return top_bits;
}
```

Godbolt: https://gcc.godbolt.org/z/a81qPWcon


For this code top_bits &= 255 does not actually do anything. Clang can optimise
based on that:

```
   vmovmskps   eax, ymm0
   vzeroupper
   ret
```

It comes from real code.

[Bug c++/100963] [11/12 Regression] GCC 11 regression: templated constructor with std::initializer_list is not selected

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 11.2/12.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jun 08, 2021 at 05:09:05PM +, gs...@t-online.de wrote:
> 
> It should be valid, type-spec is explicitly given and the ac-values
> are type compatible (see e.g. F2018 7.8). With len(x(1:2))==2 the
> following simplified example works :
> 

Thanks for the leg work with the standard.  I was heading
out the door for work when I saw Richard's comment.  I
simply wanted to confirm that it is indeed a FE bug.

Likely, needed to check array.c(walk_array_constructor)
to see how the typespec/conversion is handled and possibly
array.c(gfc_match_array_constructor).