[Bug target/95436] [11 Regression] ICE in store_expr, at expr.c:5845 since r11-711-g43a4fc095e30188392cc42299c4081297e321104

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/95474] New: class member array cannot be mapped

[xw111luoye at gmail dot com]

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

Bug ID: 95474
   Summary: class member array cannot be mapped
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xw111luoye at gmail dot com
  Target Milestone: ---

https://github.com/ye-luo/openmp-target/blob/master/hands-on/tests/map/map_class_member.cpp

$ g++ -fopenmp map_class_member.cpp
map_class_member.cpp: In instantiation of ‘maptest::maptest() [with T =
float]’:
map_class_member.cpp:26:18:   required from here
map_class_member.cpp:12:45: error: ‘maptest::data’ is not a variable in
‘map’ clause
   12 | #pragma omp target enter data map(alloc:data[:6])
  | ^~~~
map_class_member.cpp: In instantiation of ‘maptest::~maptest() [with T =
float]’:
map_class_member.cpp:26:18:   required from here
map_class_member.cpp:19:45: error: ‘maptest::data’ is not a variable in
‘map’ clause
   19 | #pragma omp target exit data map(delete:data[:6])
  | ^~~~

Syntax parsing seems broken.

[Bug c++/95475] New: Imprecise column number of runtime error in unreachable program point

[haoxintu at gmail dot com]

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

Bug ID: 95475
   Summary: Imprecise column number of runtime error in
unreachable program point
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

$cat test.cc
int main(){
int var = 2;
switch (var) {
case 1:  
default:   
__builtin_unreachable();
}
}

$cat test.c
int main(){
int var = 2;
switch (var) {
case 1:  
default:   
__builtin_unreachable();

}
}

$g++ -fsanitize=undefined test.cc ; ./a.out
test.cc:6:34: runtime error: execution reached an unreachable program point

$gcc -fsanitize=undefined test.c ; ./a.out
test.c:6:13: runtime error: execution reached an unreachable program point

In clang-trunk

$clang++ -fsanitize=undefined test.cc ; ./a.out
test.cc:6:13: runtime error: execution reached an unreachable program point
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.cc:6:13 in 

$clang -fsanitize=undefined test.c ; ./a.out
test.c:6:13: runtime error: execution reached an unreachable program point
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.c:6:13 in 

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

[Bug testsuite/95416] Several gcc.misc-tests/outputs.exp tests FAIL

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
I've since run Solaris bootstraps with gld: all the failures are gone.
Conversely, in a Linux/i686 bootstrap with gld and --disable-lto-plugin, they
do occur just as on Solaris with the native ld.

[Bug target/95450] [10/11 regression] Wrong long double folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |10.1.0
   Target Milestone|--- |10.2
Summary|[10 regression] Wrong long  |[10/11 regression] Wrong
   |double folding  |long double folding
   Keywords||wrong-code

--- Comment #1 from Richard Biener  ---
Does it work with -O0?  I guess that we fold the read from gl_LDBL_MAX
in a "wrong" way, thus native_interpret_expr is maybe wrong?

[Bug c++/95451] [8/9/10/11 regression] ICE for lambda capturing this and calling operator() since r8-2720-gf44a8dd56f5bfbd0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
Summary|[8/9/10 regression] ICE for |[8/9/10/11 regression] ICE
   |lambda capturing this and   |for lambda capturing this
   |calling operator() since|and calling operator()
   |r8-2720-gf44a8dd56f5bfbd0   |since
   ||r8-2720-gf44a8dd56f5bfbd0

[Bug driver/95456] [11 Regression] gcc/gcc.c:6035:16: runtime error: null pointer passed as argument 2, which is declared to never be null

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/95475] Imprecise column number of runtime error in unreachable program point

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The question is where should it be, at the open of the () or the start of the
identifier __builtin_unreachable ?  In C++, it is the open.  In C, it is the
start.

[Bug tree-optimization/94274] fold phi whose incoming args are defined from binary operations

[z.zhanghaijian at huawei dot com]

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

--- Comment #5 from z.zhanghaijian at huawei dot com  ---
Created attachment 48659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48659&action=edit
Fold phi whose incoming args are defined from binary operations

I tried to make a patch to do this optimization(in attachment)：

replaces

bb0:
  if (cond) goto bb1; else goto bb2;
bb1:
  x1 = a + b;
  goto 
bb2:
  x2 = a + c;
bb3:
  x = PHI ;

with

bb0:
  if (cond) goto bb1; else goto bb2;
bb1:
bb2:
bb3:
  x3 = PHI ;
  x = a + x3;

This patch will check all the phi nodes in bb3. We do the optimization only if
these phis can all be converted, This can avoid most scenes that the blocks is
not empty after the optimization, but there are still some scenes that the
block is not empty.

For example 1：

int f1(int cond, int a, int b, int c, int d, int e, int f, int x, int y, int z,
int w, int m, int n)
{

  if (cond) {
x = e + f;
b = x >> w;
c = m + 12;
a = b + z;
  }
  else {
d = y >> w;
c = n + 12;
a = d + z;
  }
  a = a + 18;
  return c + a;

}

Tree dump before optimization：

   [local count: 536870913]:
  x_13 = e_11(D) + f_12(D);
  b_14 = x_13 >> w_5(D);
  c_16 = m_15(D) + 12;
  a_17 = z_9(D) + b_14;
  goto ; [100.00%]

   [local count: 536870913]:
  d_6 = y_4(D) >> w_5(D);
  c_8 = n_7(D) + 12;
  a_10 = d_6 + z_9(D);

   [local count: 1073741824]:
  # a_1 = PHI 
  # c_2 = PHI 
  a_18 = a_1 + 18;
  _19 = c_2 + a_18;
  return _19;

Tree dump after optimization：

   [local count: 536870913]:
  x_13 = e_11(D) + f_12(D);
  goto ; [100.00%]

   [local count: 536870913]:

   [local count: 1073741824]:
  # _21 = PHI 
  # _23 = PHI 
  c_2 = _23 + 12;
  _22 = _21 >> w_5(D);
  a_1 = z_9(D) + _22;
  a_18 = a_1 + 18;
  _19 = c_2 + a_18;
  return _19;

Assemble before optimization：

.LFB0:
.cfi_startproc
ldr w1, [sp, 8]
ldr w2, [sp, 16]
cbz w0, .L2
add w5, w5, w6
ldr w0, [sp, 24]
asr w5, w5, w2
add w1, w5, w1
add w1, w1, 18
add w0, w0, 12
add w0, w1, w0
ret
.p2align 2,,3
.L2:
ldr w0, [sp]
asr w2, w0, w2
ldr w0, [sp, 32]
add w1, w2, w1
add w1, w1, 18
add w0, w0, 12
add w0, w1, w0
ret
.cfi_endproc

Assemble after optimization：

.LFB0:
.cfi_startproc
ldr w1, [sp]
ldr w3, [sp, 8]
ldr w4, [sp, 16]
ldr w2, [sp, 32]
cbz w0, .L2
ldr w2, [sp, 24]
add w1, w5, w6
.L2:
asr w0, w1, w4
add w0, w0, w3
add w0, w0, w2
add w0, w0, 30
ret

Because the statement x_13 = e_11 (D) + f_12 (D) in bb3 does not have a phi
node in bb5, so bb3 cannot be emptied. I have not found a good way to solve it.
Any suggestions?

Without considering the register pressure, the performance of example 1 is
profitable. And this patch is effective for 500.perlbench_r in comment 3.

[Bug target/95460] ICE in execute, at adjust-alignment.c:74

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
dup

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

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from Richard Biener  ---
*** Bug 95460 has been marked as a duplicate of this bug. ***

[Bug middle-end/95464] [10/11 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I wonder where we'd simplify things like

(insn 67 66 68 3 (parallel [
(set (strict_low_part (subreg:QI (reg/v:SI 94 [ a ]) 0))
(ior:QI (subreg:QI (reg/v:SI 94 [ a ]) 0)
(const_int 5 [0x5])))
(clobber (reg:CC 17 flags))
]) "gallivm2.c":51:3 492 {*iorqi_1_slp}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

I guess simplify_rtx would just see the SET_SRC?  The above might appear
quite frequently from bit fiddling RTL expansion I guess.

[Bug target/95469] [11 regression] several vperm test case failures after r11-736 on power 9 (only)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Target||powerpc*

[Bug middle-end/95472] various diagnostics for C/C++ hyperlinks to gfortran doc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed for 10.2.

[Bug c++/95475] Imprecise column number of runtime error in unreachable program point

[haoxintu at gmail dot com]

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

--- Comment #2 from Haoxin Tu  ---
(In reply to Andrew Pinski from comment #1)
> The question is where should it be, at the open of the () or the start of
> the identifier __builtin_unreachable ?  In C++, it is the open.  In C, it is
> the start.

Hi, Andrew,

My question is that GCC treats the identifier "__builtin_unreachable" and
normal identifier differently?

For example

$cat test.cc
int foo_long_identifier(){;}
int main(){
   foo_long_identifier();   
}

$g++ -w -fsanitize=undefined test.cc ; ./a.out
test.cc:1:5: runtime error: execution reached the end of a value-returning
function without returning a value

I think this time the column number is the start of the identifier
"foo_long_identifier" rather than "()".

[Bug tree-optimization/95448] Missing optimization: pointer untag, re-tag should be no-op

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Last reconfirmed||2020-06-02
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The pass with the strongest bit tracking (CCP) does not handle
the special assume-like CFGs at all and EVRP which would does not handle
the indirect assumption of bit test vs. constant:

  _1 = v.v;
  _2 = _1 & 7;
  if (_2 != 1)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_unreachable ();

   :
  _12 = _1 & 18446744073709551608;

so while we see that _2 = [1, 1] at the start of bb 4 the value-range
for _1 is determined from

Adding assert for _1 from _1 + 18446744073709551615 <= 18446744073709551608
Adding assert for _1 from _1 != 0

to

pushing new range for _1: long unsigned int [1, 18446744073709551609] 
EQUIVALENCES: { _1 } (1 elements)

sth is amiss there.  It looks like is_masked_range_test is the closest
candidate but there

  if ((inv_mask & (inv_mask + 1)) != 0
  || (val & mask) != val)
return false;

trips.  Guess we're looking for a different kind of logic here.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
Created attachment 48660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48660&action=edit
work-in-progress patch

There's patch that does not stream all zero counters for a function. The patch
only supports streaming and gcov-dump:

$ gcov-dump -l a-foo.gcda
a-foo.gcda:data:magic `gcda':version `B10e'
a-foo.gcda:stamp 1948224357
a-foo.gcda:  a100:   2:OBJECT_SUMMARY runs=1, sum_max=1
a-foo.gcda:  0100:   3:FUNCTION ident=108032747,
lineno_checksum=0x2408bf36, cfg_checksum=0x7cb34af9
a-foo.gcda:01a1:   4:COUNTERS arcs 2 counts
a-foo.gcda:   0: 1 1 
a-foo.gcda:01af:   2:COUNTERS time_profiler 1 counts
a-foo.gcda:   0: 1 
a-foo.gcda:  0100:   3:FUNCTION ident=932535731,
lineno_checksum=0x74cbb94c, cfg_checksum=0xeb219516
a-foo.gcda:01a1:   4:COUNTERS arcs 2 counts (all zero)
a-foo.gcda:   0: 0 0 
a-foo.gcda:01af:   2:COUNTERS time_profiler 1 counts (all zero)
a-foo.gcda:   0: 0 

Can you please test the patch and measure how much does it help for your
test-case?
Note that the FUNCTION section will be streamed (it contains 3 64-bit integers
for each fn:
ident=932535731, lineno_checksum=0x74cbb94c, cfg_checksum=0xeb219516).

[Bug target/95450] [10/11 regression] Wrong long double folding

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
No, it doesn't.

[Bug target/95420] arm-wrs-vxworks7: xgcc: error: unrecognised -mcpu target: armv7-a

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:86b14bb1a93d8ef01678d132013a2006a4f00deb

commit r11-786-g86b14bb1a93d8ef01678d132013a2006a4f00deb
Author: Iain Buclaw 
Date:   Mon Jun 1 00:18:44 2020 +0200

Fix unrecognised -mcpu target 'armv7-a' on arm-wrs-vxworks7

In the removal of arm-wrs-vxworks, the default cpu was updated from arm8
to armv7-a, but this is not recognized as a valid -mcpu target.  There
is however generic-armv7-a, which was likely the intended cpu that
should have been used instead.

gcc/ChangeLog:

PR target/95420
* config.gcc (arm-wrs-vxworks7*): Set default cpu to
generic-armv7-a.

[Bug target/95420] arm-wrs-vxworks7: xgcc: error: unrecognised -mcpu target: armv7-a

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:89b625be0aab128b2316a937881147cd4a2e354a

commit r10-8221-g89b625be0aab128b2316a937881147cd4a2e354a
Author: Iain Buclaw 
Date:   Mon Jun 1 00:18:44 2020 +0200

Fix unrecognised -mcpu target 'armv7-a' on arm-wrs-vxworks7

In the removal of arm-wrs-vxworks, the default cpu was updated from arm8
to armv7-a, but this is not recognized as a valid -mcpu target.  There
is however generic-armv7-a, which was likely the intended cpu that
should have been used instead.

gcc/ChangeLog:

PR target/95420
* config.gcc (arm-wrs-vxworks7*): Set default cpu to
generic-armv7-a.

(cherry picked from commit 86b14bb1a93d8ef01678d132013a2006a4f00deb)

[Bug fortran/95476] New: Reading file of length zero

[m.diehl at mpie dot de]

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

Bug ID: 95476
   Summary: Reading file of length zero
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.diehl at mpie dot de
  Target Milestone: ---

There is some ambiguity when reading a file of zero length:

program test

 character(len=:), allocatable :: a
 a = IO_read('empty.txt')

 print*, len(a)
 print*, '#'//a//'#'

contains

function IO_read(fileName) result(fileContent)

  character(len=*),  intent(in) :: fileName
  character(len=:), allocatable :: fileContent
  integer ::  &
fileLength, &
fileUnit, &
myStat

  inquire(file = fileName, size=fileLength)
  open(newunit=fileUnit, file=fileName, access='stream',&
   status='old', position='rewind', action='read',iostat=myStat)
  if(myStat /= 0) stop 1
  allocate(character(len=fileLength)::fileContent)
  read(fileUnit,iostat=myStat) fileContent
  print*, mystat
  close(fileUnit)

end function IO_read

end program test

see also the discussion on 
https://software.intel.com/en-us/comment/1960049#comment-1960049

[Bug target/95471] vrndvq_f32 not supported on armv8

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
-mfpu=neon doesn't support the Neon features from Armv8-A.
The recommended way is to use -mfpu=auto and use an appropriate -mcpu or -march
option.
In this case, using -march=armv8-a+simd -mfpu=auto generates the instruction.

[Bug middle-end/95464] [10/11 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Perhaps define_split?  For xor and and too.

[Bug c++/95475] Imprecise column number of runtime error in unreachable program point

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Haoxin Tu from comment #2)
> My question is that GCC treats the identifier "__builtin_unreachable" and
> normal identifier differently?

Of course it doesn't.  What matters is what location the FE decides to use as
the location of the CALL_EXPR expression.

[Bug driver/95456] [11 Regression] gcc/gcc.c:6035:16: runtime error: null pointer passed as argument 2, which is declared to never be null

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/95474] class member array cannot be mapped

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
It is not broken, IMHO what you are trying to do is not valid in OpenMP 4.5.

It is valid in OpenMP 5.0, but GCC doesn't implement that part yet.

[Bug fortran/95467] ICE in parse_omp_structured_block: OpenMP Offload (target_parallel__simd)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, can't reproduce the ICE either.

[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

[manfred99 at gmx dot ch]

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

Manfred Schwarb  changed:

   What|Removed |Added

 CC||manfred99 at gmx dot ch

--- Comment #4 from Manfred Schwarb  ---
I see it too on i686 for current trunk: Instrumenting the testsuite checks with

/usr/bin/env LIBC_FATAL_STDERR_=1 MALLOC_PERTURB_=B MALLOC_CHECK_=3 make check


9 | class(t2), pointer :: q(2)  ! { dg-error "must have a deferred
shape" }
  |   1
Error: Pointer array component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
0x8e61e8d crash_signal
../../gcc-trunk-source/gcc/gcc/toplev.c:328
0x860f511 resolve_component
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14318
0x86107fb resolve_fl_derived0
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14753
0x8610d29 resolve_fl_derived
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14882
0x8611ad0 resolve_symbol
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:15251
0x8636a81 do_traverse_symtree
../../gcc-trunk-source/gcc/gcc/fortran/symbol.c:4150
0x8636b18 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
../../gcc-trunk-source/gcc/gcc/fortran/symbol.c:4175
0x8615988 resolve_types
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:17175
0x8615dd8 gfc_resolve(gfc_namespace*)
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:17290
0x85eb469 resolve_all_program_units
../../gcc-trunk-source/gcc/gcc/fortran/parse.c:6245
0x85ebb66 gfc_parse_file()
../../gcc-trunk-source/gcc/gcc/fortran/parse.c:6492
0x864043d gfc_be_parse_file
../../gcc-trunk-source/gcc/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.




With valgrind, the following analysis is shown:
==72395== Invalid read of size 4
==72395==at 0x860F4C3: resolve_component(gfc_component*, gfc_symbol*)
(resolve.c:14304)
==72395==by 0x86107FB: resolve_fl_derived0(gfc_symbol*) (resolve.c:14753)
==72395==by 0x8610D29: resolve_fl_derived(gfc_symbol*) (resolve.c:14882)
==72395==by 0x8611AD0: resolve_symbol(gfc_symbol*) (resolve.c:15251)
==72395==by 0x8636A81: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4150)
==72395==by 0x8636B18: gfc_traverse_ns(gfc_namespace*, void
(*)(gfc_symbol*)) (symbol.c:4175)
==72395==by 0x8615988: resolve_types(gfc_namespace*) (resolve.c:17175)
==72395==by 0x8615DD8: gfc_resolve(gfc_namespace*) (resolve.c:17290)
==72395==by 0x85EB469: resolve_all_program_units(gfc_namespace*)
(parse.c:6245)
==72395==by 0x85EBB66: gfc_parse_file() (parse.c:6492)
==72395==by 0x864043D: gfc_be_parse_file() (f95-lang.c:210)
==72395==by 0x8E62281: compile_file() (toplev.c:458)
==72395==  Address 0x46e99e4 is 116 bytes inside a block of size 204 free'd
==72395==at 0x4031B37: free (in
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so)
==72395==by 0x8635090: gfc_free_symbol(gfc_symbol*) (symbol.c:3096)
==72395==by 0x863515D: gfc_release_symbol(gfc_symbol*) (symbol.c:3123)
==72395==by 0x8635FCA: gfc_restore_last_undo_checkpoint() (symbol.c:3700)
==72395==by 0x863606B: gfc_undo_symbols() (symbol.c:3731)
==72395==by 0x85E60B0: reject_statement() (parse.c:2633)
==72395==by 0x85DE291: match_word(char const*, match (*)(), locus*)
(parse.c:70)
==72395==by 0x85DEE43: decode_statement() (parse.c:376)
==72395==by 0x85E4A6F: next_free() (parse.c:1279)
==72395==by 0x85E500C: next_statement() (parse.c:1511)
==72395==by 0x85E7256: parse_derived() (parse.c:3342)
==72395==by 0x85E7F06: parse_spec(gfc_statement) (parse.c:3883)
==72395==  Block was alloc'd at
==72395==at 0x4032CC6: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so)
==72395==by 0x9F4F125: xcalloc (xmalloc.c:162)
==72395==by 0x863517D: gfc_new_symbol(char const*, gfc_namespace*)
(symbol.c:3134)
==72395==by 0x86356A0: gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) (symbol.c:3368)
==72395==by 0x863584F: gfc_get_symbol(char const*, gfc_namespace*,
gfc_symbol**) (symbol.c:3421)
==72395==by 0x855E4D3: gfc_match_decl_type_spec(gfc_typespec*, int)
(decl.c:4494)
==72395==by 0x8560A37: gfc_match_data_decl() (decl.c:6119)
==72395==by 0x85DE270: match_word(char const*, match (*)(), locus*)
(parse.c:65)
==72395==by 0x85DEE43: decode_statement() (parse.c:376)
==72395==by 0x85E4A6F: next_free() (parse.c:1279)
==72395==by 0x85E500C: next_statement() (parse.c:1511)
==72395==by 0x85E7256: parse_derived() (parse.c:3342)

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to Kito Cheng from comment #6)
> Created attachment 48658 [details]
> i386-Implement-ROUND_TYPE_ALIGN-to-make-sure-alignme.patch
> 
> Some optimization might made decision depend on the alignment, and alignment
> shrinking might made the decision become wrong.

Nothing will happen on i386 if alignment of long long isn't 8 bytes.

> So I prefer keep the assertion checking and implement ROUND_TYPE_ALIGN for
> x86, so that it will set the alignment properly from the beginning.
> 
> PoC/untested  patch attached.

The i386 psABI specifies 4 byte alignment for long long.  But we want to
use 8 byte alignment if there is no ABI implication and no stack realignment
is needed.  Will ROUND_TYPE_ALIGN always align long long to 8 bytes?

[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:0bd4508f86889995f6864bf50773bd6859951007

commit r11-825-g0bd4508f86889995f6864bf50773bd6859951007
Author: Eric Botcazou 
Date:   Tue Jun 2 13:14:55 2020 +0200

Fix bits/bytes confusion in latest change to expand_unop

gcc/ChangeLog:
PR middle-end/95395
* optabs.c (expand_unop): Fix bits/bytes confusion in latest
change.

* tree-pretty-print.c (dump_generic_node) : Print
quals.

[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 2 Jun 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
> 
> --- Comment #8 from H.J. Lu  ---
> (In reply to Kito Cheng from comment #6)
> > Created attachment 48658 [details]
> > i386-Implement-ROUND_TYPE_ALIGN-to-make-sure-alignme.patch
> > 
> > Some optimization might made decision depend on the alignment, and alignment
> > shrinking might made the decision become wrong.
> 
> Nothing will happen on i386 if alignment of long long isn't 8 bytes.

GIMPLE passes see DECL_ALIGN and can for example elide runtime checks
like if(_Alignof(var) != 8) which is bogus when the actual alignment
is not ensured.  For this reason we cannot permit a larger aligment
early and resort to a lower one later.

> > So I prefer keep the assertion checking and implement ROUND_TYPE_ALIGN for
> > x86, so that it will set the alignment properly from the beginning.
> > 
> > PoC/untested  patch attached.
> 
> The i386 psABI specifies 4 byte alignment for long long.  But we want to
> use 8 byte alignment if there is no ABI implication and no stack realignment
> is needed.  Will ROUND_TYPE_ALIGN always align long long to 8 bytes?

So what we want here is RTL expansion pad out stack slots if they know
to be aligned but not adjust DECL_ALIGN.  Not sure if there's already
a target hook to pad out variables, if not this may be the way to get
what you desire here.

I guess the actual reason is crossing of cache-lines?

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
(In reply to Andrew Downing from comment #15)
> This is all kind of besides the point anyway though, because gcc is handling
> everything ok except for std::launder. std::launder is only supposed to be
> an optimization barrier, but it's causing the opposite problem. Here,
> std::launder is preventing an optimization that shouldn't be taking place
> from NOT taking place. I've been looking at gcc's code for a while and have
> gotten as far as seeing that the use of std::launder is preventing
> dse_classify_store() in tree-ssa-dse.c from seeing the relationship between
> double d = 3.14159; and _6 here.
> 
> // this is right before the tree-dse3 pass (I disabled some passes to
> prevent constant propagation)
> f1 ()
> {
>   long unsigned int u;
>   double d;
>   long unsigned int * _6;
> 
>[local count: 1073741824]:
> 
>   // this line is removed by tree-dse3
>   d = 3.141589988261834005243144929409027099609375e+0;
> 
>   _6 = .LAUNDER (&d);
>   u_3 = MEM[(uint64_t *)_6];
>   d ={v} {CLOBBER};
>   return u_3;
> 
> }
> 
> If the implementation of std::launder in gcc simply disallows optimization
> passes from seeing through it, I think that is a mistake. std::launder being
> an optimization barrier means disallowing checks that enable an optimization
> from seeing through it as well as allowing checks that disable an
> optimization from seeing through it.

Note that when you elide .LAUNDER nothing really changes in GCC other than
when seeing these kind of must alias of a definition and a use GCC chooses
to do-what-I-mean and allow type-punning.  So I don't think the .LAUNDER
implementation has an issue - of course I never understood the point
of std::launder in the first place, but ...

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
(In reply to Richard Smith from comment #20)
> (In reply to Andrew Downing from comment #19)
> > Not that it would make a difference in this particular situation, but is the
> > intent of P0593R6 to only allow implicitly creating an object in the
> > relevant storage location where one hasn't already been implicitly or
> > explicitly created?
> 
> No, the new objects are allowed to replace existing objects. For example,
> this implementation would also be correct:
> 
> std::uint64_t* s3(double* p) {
> std::memmove(p, p, sizeof(double));
> return std::launder(reinterpret_cast(p));
> }
> 
> ... on the basis that it has defined behavior if the memmove implicitly
> creates an 'uint64_t' object in the underlying storage after it (notionally)
> copies the contents elsewhere and before it (notionally) copies the contents
> back again. (The 'launder' is necessary in order to form a pointer to the
> implicitly-created uint64_t object, because p doesn't point to that object.)

Note that in GCCs view if there's a memcpy in the IL the memcpy destination
has indetermine type and accesses using any effective type lvalue are
well-defined.

The issue with the testcase at hand is that GCC elides the memcpy
(and the temporary object) completely - which was desired by the testcase
author.  But that loses this "barrier" from the IL.

Note that GCC both implements the C and the C++ language and performs
inter-CU optimization across language barriers and thus we need to find
common grounds of semantics - such as memcpy.  So for GCC the argument
"this is C++, we don't care for C semantics" isn't productive.

Note GCC also elides memcpy and memmove with identical source/destination
even though this technically has barrier semantics.

So IMHO std::start_lifetime_as would need first-class compiler support
and be appropriately represented in the IL.  Which also means it will
have a non-zero overhead but less overhead than for example keeping
a memmove (p, p, N) in the IL.

Which leads me towards the suggestion to work on memcpy semantics since
IMHO the C semantics provide the reason for what GCC does to the testcase
and I find it extremely odd (and bad for general optimization that doesn't
try to emulate std::start_lifetime_in_as) to require different semantics.

Note we're already allowing dynamic type changes of objects with a declared
type in C since that's also used in practice.  Note we're already pessimizing
C++ for re-using parts of objects.

So IMHO no GCC bug to see here.  And yes, GCC doesn't seem to be able to
implement std::start_lifetime_as without larger overhead at the moment.

[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN

[bouanto at zoho dot com]

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

--- Comment #6 from bouanto at zoho dot com ---
Any idea how I should change the generated code to make it work?
Or will a patch not require changing the generated code?
Thanks.

[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
This seems like a bug with how libgccjit interacts with __builtin_unreachable,
sorry.

As a workaround, try removing the __builtin_unreachable calls for now.

[Bug c++/95020] requires expression always evaluates to true in the definition of template lambda defined within template function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:0971201a1e5e1e5df7de666ea1c4b2605a51cc76

commit r10-8222-g0971201a1e5e1e5df7de666ea1c4b2605a51cc76
Author: Patrick Palka 
Date:   Tue Jun 2 08:52:21 2020 -0400

c++: premature requires-expression folding [PR95020]

In the testcase below we're prematurely folding away the
requires-expression to 'true' after substituting in the function's
template arguments, but before substituting in the lambda's deduced
template arguments.

This patch removes the uses_template_parms check when deciding in
tsubst_requires_expr whether to keep around a new requires-expression.
Regardless of whether the template arguments are dependent, there still
might be more template parameters to later substitute in (as in the
below testcase) and even if not, tsubst_expr doesn't perform full
semantic processing unless !processing_template_decl, so we should still
wait until then to fold away the requires-expression.

gcc/cp/ChangeLog:

PR c++/95020
* constraint.cc (tsubst_requires_expr): Produce a new
requires-expression when processing_template_decl, even if
template arguments are not dependent.

gcc/testsuite/ChangeLog:

PR c++/95020
* g++.dg/cpp2a/concepts-lambda7.C: New test.

(cherry picked from commit 7e52f8b1e03776575b92574252d9b6bbed9f1af4)

[Bug c++/92838] ICE (internal compiler error) calling lambda object with requires clause (in in dependent_type_p)

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:40912c25b57b4e21aae20a4896624387aa13f7ed

commit r10-8223-g40912c25b57b4e21aae20a4896624387aa13f7ed
Author: Patrick Palka 
Date:   Mon Jun 1 21:37:04 2020 -0400

c++: constrained lambda inside template [PR92633]

When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints.  Fix this by substituting through the constraints during
tsubst_lambda_expr.

gcc/cp/ChangeLog:

PR c++/92633
PR c++/92838
* pt.c (tsubst_function_decl): Don't do set_constraints when
regenerating a lambda.
(tsubst_lambda_expr): Substitute into the lambda's constraints
and do set_constraints here.

gcc/testsuite/ChangeLog:

PR c++/92633
PR c++/92838
* g++.dg/cpp2a/concepts-lambda11.C: New test.
* g++.dg/cpp2a/concepts-lambda12.C: New test.

(cherry picked from commit c2449995ca36ea955e3c6d4ee7f0d401b512c897)

[Bug c++/92633] [concepts] constrained lambda with placehoder syntax getting wrong substitution

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:40912c25b57b4e21aae20a4896624387aa13f7ed

commit r10-8223-g40912c25b57b4e21aae20a4896624387aa13f7ed
Author: Patrick Palka 
Date:   Mon Jun 1 21:37:04 2020 -0400

c++: constrained lambda inside template [PR92633]

When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints.  Fix this by substituting through the constraints during
tsubst_lambda_expr.

gcc/cp/ChangeLog:

PR c++/92633
PR c++/92838
* pt.c (tsubst_function_decl): Don't do set_constraints when
regenerating a lambda.
(tsubst_lambda_expr): Substitute into the lambda's constraints
and do set_constraints here.

gcc/testsuite/ChangeLog:

PR c++/92633
PR c++/92838
* g++.dg/cpp2a/concepts-lambda11.C: New test.
* g++.dg/cpp2a/concepts-lambda12.C: New test.

(cherry picked from commit c2449995ca36ea955e3c6d4ee7f0d401b512c897)

[Bug c++/95020] requires expression always evaluates to true in the definition of template lambda defined within template function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |10.2

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 10.2+.

[Bug c++/54367] [meta-bug] lambda expressions

[ppalka at gcc dot gnu.org]

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

Bug 95020 Summary: requires expression always evaluates to true in the 
definition of template lambda defined within template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95020

   What|Removed |Added

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

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

[ppalka at gcc dot gnu.org]

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

Bug 95020 Summary: requires expression always evaluates to true in the 
definition of template lambda defined within template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95020

   What|Removed |Added

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

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #9)

> > The i386 psABI specifies 4 byte alignment for long long.  But we want to
> > use 8 byte alignment if there is no ABI implication and no stack realignment
> > is needed.  Will ROUND_TYPE_ALIGN always align long long to 8 bytes?
> 
> So what we want here is RTL expansion pad out stack slots if they know
> to be aligned but not adjust DECL_ALIGN.  Not sure if there's already
> a target hook to pad out variables, if not this may be the way to get
> what you desire here.
> 
> I guess the actual reason is crossing of cache-lines?

If the incoming stack is 4 byte aligned, we can't align long long to
8 bytes without stack realignment.

[Bug c++/92633] [concepts] constrained lambda with placehoder syntax getting wrong substitution

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.2

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 10.2+.

[Bug c++/54367] [meta-bug] lambda expressions

[ppalka at gcc dot gnu.org]

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

Bug 92633 Summary: [concepts] constrained lambda with placehoder syntax getting 
wrong substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92633

   What|Removed |Added

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

[Bug c++/92838] ICE (internal compiler error) calling lambda object with requires clause (in in dependent_type_p)

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.2

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10.2+.

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

[ppalka at gcc dot gnu.org]

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

Bug 92633 Summary: [concepts] constrained lambda with placehoder syntax getting 
wrong substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92633

   What|Removed |Added

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

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 2 Jun 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
> 
> --- Comment #10 from H.J. Lu  ---
> (In reply to rguent...@suse.de from comment #9)
> 
> > > The i386 psABI specifies 4 byte alignment for long long.  But we want to
> > > use 8 byte alignment if there is no ABI implication and no stack 
> > > realignment
> > > is needed.  Will ROUND_TYPE_ALIGN always align long long to 8 bytes?
> > 
> > So what we want here is RTL expansion pad out stack slots if they know
> > to be aligned but not adjust DECL_ALIGN.  Not sure if there's already
> > a target hook to pad out variables, if not this may be the way to get
> > what you desire here.
> > 
> > I guess the actual reason is crossing of cache-lines?
> 
> If the incoming stack is 4 byte aligned, we can't align long long to
> 8 bytes without stack realignment.

I understand.  But if the stack is 4 byte aligned only and we don't
to stack realignment we may not claim long long is 8 bytes aligned.

[Bug c++/93152] derived_from on lambda arg causes ICE / uses wrong base, for some orders of template args on containing function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Thanks for the analysis and for the reduced testcase.

> This might have the same root cause as 93154, as in both cases, it looks like 
> the compiler is mixing up the template arguments of the outer function and 
> the inner lambda.

I think you're right.  PR92633 contains a smaller testcase whose root cause is
the same, and after fixing that PR (for GCC 10.2+) we now also correctly
compile the original testcase here.  So I'm marking this PR as a dup of
PR92633.

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

[Bug c++/92633] [concepts] constrained lambda with placehoder syntax getting wrong substitution

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||db0451 at gmail dot com

--- Comment #5 from Patrick Palka  ---
*** Bug 93152 has been marked as a duplicate of this bug. ***

[Bug c++/92633] [concepts] constrained lambda with placehoder syntax getting wrong substitution

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
*** Bug 93154 has been marked as a duplicate of this bug. ***

[Bug c++/93154] can't constrain captured functions to be invocable w/ lambda arg - func/lambda template args mixed up?

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #4 from Patrick Palka  ---
Marking this PR as a dup of PR92633 too, as with PR93152.  Thanks for the
reports.

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

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to H.J. Lu from comment #10)
> (In reply to rguent...@suse.de from comment #9)
> 
> > > The i386 psABI specifies 4 byte alignment for long long.  But we want to
> > > use 8 byte alignment if there is no ABI implication and no stack 
> > > realignment
> > > is needed.  Will ROUND_TYPE_ALIGN always align long long to 8 bytes?
> > 
> > So what we want here is RTL expansion pad out stack slots if they know
> > to be aligned but not adjust DECL_ALIGN.  Not sure if there's already
> > a target hook to pad out variables, if not this may be the way to get
> > what you desire here.
> > 
> > I guess the actual reason is crossing of cache-lines?
> 
> If the incoming stack is 4 byte aligned, we can't align long long to
> 8 bytes without stack realignment.

Only for local variable on stack. We still want to align global/static long
long to 8 bytes.

[Bug c++/95477] New: [coroutines] coroutine result object not properly freed

[natattak at gmail dot com]

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

Bug ID: 95477
   Summary: [coroutines] coroutine result object not properly
freed
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: natattak at gmail dot com
  Target Milestone: ---

In some cases, the result object of a coroutine is not properly destroyed after
the coroutine finishes execution. Consider the following example:


#include 

struct simple {
  static inline int alive = 0;
  simple() { ++alive; }
  simple(simple&&) { ++alive; }
  ~simple() { --alive; }

  struct promise_type {
simple get_return_object() { return simple{}; }
void return_void() {}
void unhandled_exception() {}
auto initial_suspend() noexcept { return std::suspend_never{}; }
auto final_suspend() noexcept { return std::suspend_never{}; }
  };
};

simple f() { co_return; }

int main() {
  {
f();
  }
  return simple::alive;
}


The return value should be 0, indicating that all created objects were
destroyed. However, when executing, I get the result 1. After commenting out
the move constructor, the return value is 0 as expected. 

See also:
https://stackoverflow.com/questions/62125871/simple-coroutine-leaking-with-gcc-10

This is compiled using `-std=c++20 -fcoroutines`.
My `gcc -v` is:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Tue, 2 Jun 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
> 
> --- Comment #12 from H.J. Lu  ---
> (In reply to H.J. Lu from comment #10)
> > (In reply to rguent...@suse.de from comment #9)
> > 
> > > > The i386 psABI specifies 4 byte alignment for long long.  But we want to
> > > > use 8 byte alignment if there is no ABI implication and no stack 
> > > > realignment
> > > > is needed.  Will ROUND_TYPE_ALIGN always align long long to 8 bytes?
> > > 
> > > So what we want here is RTL expansion pad out stack slots if they know
> > > to be aligned but not adjust DECL_ALIGN.  Not sure if there's already
> > > a target hook to pad out variables, if not this may be the way to get
> > > what you desire here.
> > > 
> > > I guess the actual reason is crossing of cache-lines?
> > 
> > If the incoming stack is 4 byte aligned, we can't align long long to
> > 8 bytes without stack realignment.
> 
> Only for local variable on stack. We still want to align global/static long
> long to 8 bytes.

Sure.  And yes, ROUND_TYPE_ALIGN doesn't work for that since it only
gets the type and not the decl.  We'd need a ROUND_DECL_ALIGN for this.
I alternatively suggested that LOCAL_DECL_ALIGNMENT should be used
there and I guess we can do that for alignment lowering.

[Bug c++/95478] New: CPP stack pointer SP is 0x5d but assembly shows __SP_L_ at 0x3d (target AVR MEGA2560)

[dov at keyscan dot com]

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

Bug ID: 95478
   Summary: CPP stack pointer SP is 0x5d but assembly shows
__SP_L_ at 0x3d (target AVR MEGA2560)
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dov at keyscan dot com
  Target Milestone: ---

I am using Eclipse IDE to develop CPP code for Arduino MEGA2560 target.

The compiler details as appeared on the compiler output:
GNU C++14 (GCC) version 7.3.0 (avr)
compiled by GNU C version 4.8.2, GMP version 5.0.2, MPFR version 3.1.0, MPC
version 0.9, isl version none

The problem:
I checked the stack pointer SP in a CPP program compiled for Arduino Mega2560
target.
The SP address is 0x5D which is correct.
I inserted assembly line into the CPP program to check the address of the
__SP_L__ which I expected also to be 0x5D but found out that it is 0x3D which
is wrong for the Mega2560

This is the code that I ran:

```
Serial.println( (unsigned int)&SP );
Serial.println( (unsigned int)&SPL );
asm("ldi r20,lo8(10)\n ldi r21,0\n ldi r22,__SP_L__\n  
ldi r23,0\n ldi r24,lo8(Serial)\n ldi r25,hi8(Serial)\n 
call _ZN5Print7printlnEji\n");
```

The above asm(...) line simply implements the call to Serial.println(...) line
with the assembler definition for the stack register.

The output is:
93
93
61   !!! the address of the stack register in the assembler
 is wrong  it should be 93 (decimal)

I check the assembly produced by the CPP compiler and found out that each file
includes at the top the following lines:

2 __SP_H__ = 0x3e
3 __SP_L__ = 0x3d
4 __SREG__ = 0x3f
5 __RAMPZ__ = 0x3b
6 __tmp_reg__ = 0
7 __zero_reg__ = 1

Which is wrong for the ATMega2560 , the stack pointer address should be 0x5D
and not 0x3D

The compiler command line contain the directives:
   " -mmcu=atmega2560 -DF_CPU=1600UL "
So the GCC compliler knows the correct target CPU and indeed use the correct
address for the SP stack pointer register on the CPP level but the wrong
address on the asm level  (the __SP_L__)!

Am I missing something? 
It seems that the stack pointer is managed in the asm through the wrong
registers address, __SP_L__ = 0x3D while the push & pop cpu address is SP =
0x5D which is the correct address for the stack pointer register on the target
processor STMEGA2560

Any one know this problem?
Any solutions?

[Bug c/95479] New: ICE in convert_move, at expr.c:271

[royeldar at hotmail dot com]

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

Bug ID: 95479
   Summary: ICE in convert_move, at expr.c:271
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: royeldar at hotmail dot com
  Target Milestone: ---

The following code doesn't compile and results in an ICE.
I suspect this behavior has something to do with the line
__attribute__((target(("avx2"


$ cat bug.c
typedef long long __m256i __attribute__((__vector_size__(32), __may_alias__));

struct {
__m256i w256;
} g_var;

__attribute__((target(("avx2"
void func() {
__m256i var = g_var.w256;
(void)var;
}

$ gcc -c -v bug.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1'
 --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada
 ,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6
 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
 --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
 --enable-libstdcxx-debug --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new --enable-gnu-unique-object
 --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
 --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
 --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
 --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
 --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
 --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
 --enable-multilib --with-tune=generic --enable-checking=release
 --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1 -quiet -v -imultiarch x86_64-linux-gnu
 bug.c -quiet -dumpbase bug.c -mtune=generic -march=x86-64 -auxbase bug
-version
 -o /tmp/ccpCodYe.s
GNU C11 (Debian 6.3.0-18+deb9u1) version 6.3.0 20170516 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2,
MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C11 (Debian 6.3.0-18+deb9u1) version 6.3.0 20170516 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2,
MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b8e5d7f3c4236757ee0871869b8330f3
bug.c: In function ‘func’:
bug.c:9:10: internal compiler error: in convert_move, at expr.c:271
  __m256i var = g_var.w256;
  ^~~

[Bug c/95479] ICE in convert_move, at expr.c:271

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Liška  ---
Fixed on master with r8-5073-ge034c5c895722e00.
Please update to any of the supported compilers: 8,9,10.

[Bug fortran/95467] ICE in parse_omp_structured_block: OpenMP Offload (target_parallel__simd)

[tapplencourt at anl dot gov]

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

--- Comment #3 from Thomas Applencorut  ---
Yes, it's indeed working. It's because I made a typo in the reproducer. I
Didn't copy the version who produce the ICE (should have been !$OMP END TARGET
PARALLEL and not !$OMP END PARALLEL). Sorry about that...

Please find below the correct version (the one who produce an ICE) bellow:


PROGRAM target_parallel__simd
USE OMP_LIB
implicit none
INTEGER :: i
INTEGER :: counter
!$OMP TARGET PARALLEL MAP(TOFROM: counter)
!$OMP SIMD
DO i = 1 , 262144
counter = 1
END DO
!$OMP END TARGET PARALLEL
END PROGRAM target_parallel__simd

And to compile, it's indeed:

gfortran -fopenmp target_parallel__simd.F90

Thanks a lot for looking at it,
Thomas

[Bug fortran/95467] ICE in parse_omp_structured_block: OpenMP Offload (target_parallel__simd)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Known to work||10.1.0, 11.0

--- Comment #4 from Martin Liška  ---
Fixed on master with r10-6136-g44a9d801a7080d39.

[Bug c++/95474] class member array cannot be mapped

[xw111luoye at gmail dot com]

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

--- Comment #2 from Ye Luo  ---
@jakub could you mention which page and line in 4.5 spec this code violates?
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf

[Bug c++/95474] class member array cannot be mapped

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
4.0 had a clear
"A variable that is part of another variable (such as a field of a structure)
but is not an array element or an array section cannot appear in a map clause."
restriction, this has been lifted in 4.5 to allow the var.xyz style mapping,
but it still didn't allow general expressions as the bases of array sections.
Only 5.0 allows arbitrary expressions there.

[Bug target/49854] Clean up SPE/e500 option handling

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Eric Gallager  ---
consensus here seemed to be to close the SPE bugs: 
https://gcc.gnu.org/pipermail/gcc/2020-May/232591.html
Thus, closing.

[Bug gcov-profile/95480] New: GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

Bug ID: 95480
   Summary: GCOV change breaks AIX build
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

The June 2 change to gcov breaks AIX because it now requires atomic 64 bit
operations in 32 bit mode.

g++-6.2.0 -std=c++11 -no-pie   -g   -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc 
gcov-tool.o libgcov-util.o libgcov-driver-tool.o libgcov-merge-tool.o
libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a
/gsa/yktgsa/home/e/d/edelsohn/install/lib/libiconv.a 
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -o gcov-tool
ld: 0711-317 ERROR: Undefined symbol: .__atomic_fetch_add_8
ld: 0711-317 ERROR: Undefined symbol: .__sync_val_compare_and_swap_8
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
make: *** [Makefile:3044: gcov-tool] Error 1

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-02
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Likely caused by

commit 871e5ada6d53d5eb495cc9f323983f347487c1b2
Author: Martin Liska 
Date:   Fri Jan 31 13:10:14 2020 +0100

Make TOPN counter dynamically allocated.

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
$ nm -BCpg libgcov-merge-tool.o | grep _8
 - U .__atomic_fetch_add_8
 - U .__sync_val_compare_and_swap_8

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Demangling the function names in the assembly output

gcov_counter_add(long long*, long long, int)
...
bl .__atomic_fetch_add_8


gcov_counter_set_if_null(long long*, gcov_kvp*, int)
...
bl .__sync_val_compare_and_swap_8

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
The references only occur when compiling without optimization during stage1.

[Bug gcov-profile/95480] GCOV change breaks AIX build

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/95474] class member array cannot be mapped

[xw111luoye at gmail dot com]

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

--- Comment #4 from Ye Luo  ---
Thanks. Hopefully this part of 5.0 feature will be implemented in the near
future.

[Bug gcov-profile/95480] GCOV change breaks AIX build

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
I have a patch candidate and I know the root cause of the patch.

[Bug c++/95474] class member array cannot be mapped

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Hopefully this year.  What you can do in the meantime is
auto *mydata = data;
and use mydata instead of data.

[Bug gcov-profile/95480] GCOV change breaks AIX build

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 48661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48661&action=edit
Patch candidate

@David: Can you please test the patch?

[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
Looks like the way libgccjit sets up attributes (such as "noreturn") on
builtins has somehow become a no-op.  Am investigating.

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
AIX build is happier with the patch

[Bug target/95469] [11 regression] several vperm test case failures after r11-736 on power 9 (only)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-02
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Segher Boessenkool  ---
Mine.

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #23 from Andrew Downing  ---
But gcc already can implement std::start_lifetime_as with no overhead.
https://godbolt.org/z/YdoEcH

My intent wasn't to draw attention to std::start_lifetime_as in this bug
report, I only mentioned it as the reason I came up with the original code. My
main focus was intended to be std::launder, which when used in this situation,
breaks something when it should do nothing at all. My thought was that if it
breaks something in this situation, it may break something in other situations
too. Possibly where it is actually required.

[Bug middle-end/95473] GCC misses -Wnull-dereference warning in a simple code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c++ |middle-end
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The reason for this is the same as in pr95461 comment #1.  Like -Warray-bounds,
for optimal results, -Wnull-dereference relies on optimization.  That includes
dead code elimination.  In the test case, since x1 is unused, it's eliminated
early on, well before the warning sees the code.

All these "late" warnings could also run earlier to detect more instances of
the problems, at the cost of issuing what most users view as false positives. 
Below is another example of such a trade-off.  Clang makes an effort to avoid
issuing these but a front end can only do that to a point.  To do much better
control and data flow analysis is required, which is what GCC does.

$ cat pr95473.c && clang -S -Wall -Wno-unused-variable -xc++ pr95473.c
void f ()
{ 
  if (0)
int &x1 = *(int *)nullptr; // unreachable null reference (no warning)

}

void g ()
{
  const int i = 0;
  if (i)
int &x1 = *(int *)nullptr; // unreachable null reference (no warning)

}

void h ()
{
  int i = 0;
  if (i)
int &x1 = *(int *)nullptr; // unreachable null reference (warning)
}
pr95473.c:20:15: warning: binding dereferenced null pointer to reference has
  undefined behavior [-Wnull-dereference]
int &x1 = *(int *)nullptr; // unreachable null reference (warning)
  ^~~
1 warning generated.

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

[Bug middle-end/95461] GCC misses -Warray-bounds warning message

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
*** Bug 95473 has been marked as a duplicate of this bug. ***

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Tue, 2 Jun 2020, andrew2085 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
> 
> --- Comment #23 from Andrew Downing  ---
> But gcc already can implement std::start_lifetime_as with no overhead.
> https://godbolt.org/z/YdoEcH

But it's "correct" only because your testcase is very simple and thus
GCCs knowledge is complete, DTRT here.

> My intent wasn't to draw attention to std::start_lifetime_as in this bug
> report, I only mentioned it as the reason I came up with the original code. My
> main focus was intended to be std::launder, which when used in this situation,
> breaks something when it should do nothing at all. My thought was that if it
> breaks something in this situation, it may break something in other situations
> too. Possibly where it is actually required.

It really depends on what the requirements on std::launder are.  AFAIK
it's an optimization barrier for the pointer.

[Bug target/95347] rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Aaron Sawdey :

https://gcc.gnu.org/g:85bce484d37fdda9c7eadb9bdcdb1ded891462bb

commit r11-830-g85bce484d37fdda9c7eadb9bdcdb1ded891462bb
Author: Aaron Sawdey 
Date:   Fri May 29 16:19:10 2020 -0500

Correctly identify stfs if prefixed

Because reg_to_non_prefixed() only looks at the register being used, it
doesn't get the right answer for stfs, which leads to us not seeing
that it has a PCREL symbol ref.  This patch works around this by
introducing a helper function that inspects the insn to see if it is in
fact a stfs. Then if we use NON_PREFIXED_DEFAULT, address_to_insn_form()
can see that it has the PCREL symbol ref.

gcc/ChangeLog:

PR target/95347
* config/rs6000/rs6000.c (prefixed_store_p): Add special case
for stfs.
(is_stfs_insn): New helper function.

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #25 from Andrew Downing  ---
Do you know how to change that example so that gcc's knowledge is incomplete
and it not longer does the correct thing?

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #26 from Andrew Downing  ---
I mean without modifying the definition of start_lifetime_as

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[skpgkp2 at gmail dot com]

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

--- Comment #14 from Sunil Pandey  ---
Created attachment 48662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48662&action=edit
Add target hook to skip alignment check for long long on x86 with -m32 and
-mpreferred-stack-boundary=2

Bootstrap and regression tested on x86_64.

[Bug tree-optimization/95481] New: Failure to optimize infinite recursion for struct types

[gabravier at gmail dot com]

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

Bug ID: 95481
   Summary: Failure to optimize infinite recursion for struct
types
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

struct A {};

struct A foo()
{
  return foo();
}

This can be optimized to an infinite loop. With -O3, GCC currently outputs an
explicit recursive call like this :

foo():
  sub rsp, 8
  call foo()
  xor eax, eax
  add rsp, 8
  ret

When it could just do this :

foo():
.L2:
  jmp .L2

[Bug debug/95482] New: Feature request: add -gsplit-dwarf=single

[i at maskray dot me]

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

Bug ID: 95482
   Summary: Feature request: add -gsplit-dwarf=single
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

DWARF v5 Appendix F. says

> The sections that do not require relocation, however, can be written to the 
> relocatable object (.o) file but ignored by the linker, or they can be 
> written to a separate DWARF object (.dwo) file that need not be accessed by 
> the linker.

GCC/clang -gsplit-dwarf write a separate DWARF object (.dwo)

clang in addition supports -gsplit-dwarf=single
(https://reviews.llvm.org/D52296 ) to write the sections (with the SHF_EXCLUDE
flag) in the .o file.
Linkers ignore SHF_EXCLUDE sections in non -r mode.

Note, SHF_EXCLUDE (0x8000) is in the range of processor-specific bits and
clashes with several processors's (obsoleted?) flags (see
https://sourceware.org/pipermail/binutils/2020-April/110691.html )

[Bug middle-end/95481] Failure to optimize infinite recursion for struct types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/95158] [10/11 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
That the issue goes away when templates are not involved seems an useful hint:
are we trying to optimize too early?

Sorry, for the time being I don't feel like assigning the bug to me, I'm in the
middle of too many other things...

[Bug target/49854] Clean up SPE/e500 option handling

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Please *NEVER* close bugs for things you are not the maintainer for.

[Bug target/95347] rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-06-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Turns out that lfs/plfs has the same problem. Patch for that coming shortly.

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-832-geca833b81289438ec5ae3ed4c77ffb49cfb65f34
Author: Jonathan Wakely 
Date:   Tue Jun 2 18:13:08 2020 +0100

libstdc++: Make debug containers prefer copy ctor to base ctor (PR 90102)

When given a type which can convert to any container-like type, the
C(const C&) copy constructor and C(const C::_Base&) converting
constructor are ambiguous. This change replaces the converting
constructor's parameter with a reference_wrapper-like type so that
calling that constructor requires an additional user-defined conversion.
This gives it a lower rank than the copy constructor, avoiding the
ambiguity.

While testing this change I discovered that __gnu_debug::forward_list
doesn't have a convering constructor from the std::forward_list base, so
this adds it.

We should probably consider whether the converting constructors should
be 'explicit' but I'm not changing that now.

libstdc++-v3/ChangeLog:

PR libstdc++/90102
* include/debug/deque (deque(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/forward_list (forward_list(_Base_ref)): New
constructor.
* include/debug/list (list(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/map.h (map(const _Base&)): Likewise.
* include/debug/multimap.h (multimap(const _Base&)): Likewise.
* include/debug/multiset.h (multiset(const _Base&)): Likewise.
* include/debug/set.h (set(const _Base&)): Likewise.
* include/debug/unordered_map (unordered_map(const _Base&))
(unordered_multimap(const _Base&)): Likewise.
* include/debug/unordered_set (unordered_set(const _Base&))
(unordered_multiset(const _Base&)): Likewise.
* testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
Adjust dg-error line number.
* include/debug/vector (vector(const _Base&)): Likewise.
* testsuite/23_containers/deque/debug/90102.cc: New test.
* testsuite/23_containers/forward_list/debug/90102.cc: New test.
* testsuite/23_containers/list/debug/90102.cc: New test.
* testsuite/23_containers/map/debug/90102.cc: New test.
* testsuite/23_containers/multimap/debug/90102.cc: New test.
* testsuite/23_containers/multiset/debug/90102.cc: New test.
* testsuite/23_containers/set/debug/90102.cc: New test.
* testsuite/23_containers/unordered_map/debug/90102.cc: New test.
* testsuite/23_containers/unordered_multimap/debug/90102.cc: New
test.
* testsuite/23_containers/unordered_multiset/debug/90102.cc: New
test.
* testsuite/23_containers/unordered_set/debug/90102.cc: New test.
* testsuite/23_containers/vector/debug/90102.cc: New test.

[Bug target/95459] aarch64: ICE in aarch64_short_vector_p, at config/aarch64/aarch64.c:16803

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-833-gb2672dd630c81513e08829adc63294ffeedf5693
Author: Fei Yang 
Date:   Tue Jun 2 18:17:34 2020 +0100

aarch64: Fix an ICE in aarch64_short_vector_p [PR95459]

In aarch64_short_vector_p, we are simply checking whether a type (and a
mode)
is a 64/128-bit short vector or not.  This should not be affected by the
value
of TARGET_SVE.  Simply leave later code to report an error if SVE is
disabled.

2020-06-02  Felix Yang  

gcc/
PR target/95459
* config/aarch64/aarch64.c (aarch64_short_vector_p):
Leave later code to report an error if SVE is disabled.

gcc/testsuite/
PR target/95459
* gcc.target/aarch64/mgeneral-regs_6.c: New test.

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #7 from Jonathan Wakely  ---
Fixed on master.

[Bug target/95459] aarch64: ICE in aarch64_short_vector_p, at config/aarch64/aarch64.c:16803

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug target/95483] New: [i386] Missing SIMD functions

[e...@coeus-group.com]

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

Bug ID: 95483
   Summary: [i386] Missing SIMD functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Created attachment 48663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48663&action=edit
Script to generate the list

I noticed the _mm_loadu_epi* functions were missing, so I threw together a
trivial script to look for missing functions based on the XML data backing the
Intel Intrinsics Guide
.  After
filtering out the the SVML and Other functions it came up with 122 results.

I attached the script in case anyone wants to reproduce.  It's ugly and slow
(it was really meant to be a throw-away), but it seems to work.  Just run it in
gcc/config/i386, and pass it the location of the IIG XML.

Here is the list:

  AVX _mm256_cvtsi256_si32
  AVX2 _mm_broadcastsd_pd
  AVX2 _mm_broadcastsi128_si256
  AVX-512 _mm512_storeu_epi16
  AVX-512 _mm512_storeu_epi8
  AVX-512 _mm256_storeu_epi16
  AVX-512 _mm256_storeu_epi8
  AVX-512 _mm_storeu_epi16
  AVX-512 _mm_storeu_epi8
  AVX-512 _mm512_loadu_epi16
  AVX-512 _mm512_loadu_epi8
  AVX-512 _mm256_loadu_epi16
  AVX-512 _mm256_loadu_epi8
  AVX-512 _mm_loadu_epi16
  AVX-512 _mm_loadu_epi8
  AVX-512 _mm512_mask_reduce_round_pd
  AVX-512 _mm512_maskz_reduce_round_pd
  AVX-512 _mm512_reduce_round_pd
  AVX-512 _mm512_mask_reduce_round_ps
  AVX-512 _mm512_maskz_reduce_round_ps
  AVX-512 _mm512_reduce_round_ps
  AVX-512 _mm_mask_reduce_round_sd
  AVX-512 _mm_maskz_reduce_round_sd
  AVX-512 _mm_reduce_round_sd
  AVX-512 _mm_mask_reduce_round_ss
  AVX-512 _mm_maskz_reduce_round_ss
  AVX-512 _mm_reduce_round_ss
  AVX-512 _mm_mask_rcp28_round_sd
  AVX-512 _mm_mask_rcp28_sd
  AVX-512 _mm_maskz_rcp28_round_sd
  AVX-512 _mm_maskz_rcp28_sd
  AVX-512 _mm_mask_rcp28_round_ss
  AVX-512 _mm_mask_rcp28_ss
  AVX-512 _mm_maskz_rcp28_round_ss
  AVX-512 _mm_maskz_rcp28_ss
  AVX-512 _mm_mask_rsqrt28_round_sd
  AVX-512 _mm_mask_rsqrt28_sd
  AVX-512 _mm_maskz_rsqrt28_round_sd
  AVX-512 _mm_maskz_rsqrt28_sd
  AVX-512 _mm_mask_rsqrt28_round_ss
  AVX-512 _mm_mask_rsqrt28_ss
  AVX-512 _mm_maskz_rsqrt28_round_ss
  AVX-512 _mm_maskz_rsqrt28_ss
  AVX-512 _mm256_mask_cvt_roundps_ph
  AVX-512 _mm256_maskz_cvt_roundps_ph
  AVX-512 _mm_mask_cvt_roundps_ph
  AVX-512 _mm_maskz_cvt_roundps_ph
  AVX-512 _mm256_store_epi32
  AVX-512 _mm_store_epi32
  AVX-512 _mm256_loadu_epi64
  AVX-512 _mm256_loadu_epi32
  AVX-512 _mm_loadu_epi64
  AVX-512 _mm_loadu_epi32
  AVX-512 _mm256_load_epi64
  AVX-512 _mm256_load_epi32
  AVX-512 _mm_load_epi64
  AVX-512 _mm_load_epi32
  AVX-512 _mm_cvtsd_i32
  AVX-512 _mm_cvtsd_i64
  AVX-512 _mm_mask_cvt_roundsd_ss
  AVX-512 _mm_mask_cvtsd_ss
  AVX-512 _mm_maskz_cvt_roundsd_ss
  AVX-512 _mm_maskz_cvtsd_ss
  AVX-512 _mm_cvti32_sd
  AVX-512 _mm_cvti64_sd
  AVX-512 _mm_cvti32_ss
  AVX-512 _mm_cvti64_ss
  AVX-512 _mm_mask_cvt_roundss_sd
  AVX-512 _mm_mask_cvtss_sd
  AVX-512 _mm_maskz_cvt_roundss_sd
  AVX-512 _mm_maskz_cvtss_sd
  AVX-512 _mm_cvtss_i32
  AVX-512 _mm_cvtss_i64
  AVX-512 _mm_mask_scalef_sd
  AVX-512 _mm_maskz_scalef_sd
  AVX-512 _mm_mask_scalef_ss
  AVX-512 _mm_maskz_scalef_ss
  AVX-512 _mm_mask_sqrt_sd
  AVX-512 _mm_maskz_sqrt_sd
  AVX-512 _mm_mask_sqrt_ss
  AVX-512 _mm_maskz_sqrt_ss
  AVX-512 _mm512_cvtsi512_si32
  AVX-512/KNC _mm512_mask_permutevar_epi32
  AVX-512/KNC _mm512_permutevar_epi32
  AVX-512/KNC _mm512_cvtpslo_pd
  AVX-512/KNC _mm512_mask_cvtpslo_pd
  AVX-512/KNC _mm512_cvtepi32lo_pd
  AVX-512/KNC _mm512_mask_cvtepi32lo_pd
  AVX-512/KNC _mm512_cvtepu32lo_pd
  AVX-512/KNC _mm512_mask_cvtepu32lo_pd
  AVX-512/KNC _mm512_i32extgather_epi32
  AVX-512/KNC _mm512_mask_i32extgather_epi32
  AVX-512/KNC _mm512_i32loextgather_epi64
  AVX-512/KNC _mm512_mask_i32loextgather_epi64
  AVX-512/KNC _mm512_i32extgather_ps
  AVX-512/KNC _mm512_mask_i32extgather_ps
  AVX-512/KNC _mm512_i32loextgather_pd
  AVX-512/KNC _mm512_mask_i32loextgather_pd
  AVX-512/KNC _mm512_i32extscatter_ps
  AVX-512/KNC _mm512_mask_i32extscatter_ps
  AVX-512/KNC _mm512_i32loextscatter_pd
  AVX-512/KNC _mm512_mask_i32loextscatter_pd
  AVX-512/KNC _mm512_i32loextscatter_epi64
  AVX-512/KNC _mm512_mask_i32loextscatter_epi64
  AVX-512/KNC _mm512_cvtpd_pslo
  AVX-512/KNC _mm512_mask_cvtpd_pslo
  AVX-512/KNC _mm512_i32logather_epi64
  AVX-512/KNC _mm512_mask_i32logather_epi64
  AVX-512/KNC _mm512_i32logather_pd
  AVX-512/KNC _mm512_mask_i32logather_pd
  AVX-512/KNC _mm512_i32loscatter_pd
  AVX-512/KNC _mm512_mask_i32loscatter_pd
  AVX-512/KNC _mm512_i32extscatter_epi32
  AVX-512/KNC _mm512_mask_i32extscatter_epi32
  AVX-512/KNC _mm512_prefetch_i32extgather_ps
  AVX-512/KNC _mm512_mask_prefetch_i32extgather_ps
  AVX-512/KNC _mm512_prefetch_i32extscatte

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qinzhao at gcc dot gnu.org]

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

--- Comment #24 from qinzhao at gcc dot gnu.org ---
with the patch added to gcc11, I tested it with the small testing case, and got
the following data:

**without the patch:
qinzhao@gcc14:~/Bugs/profile/small_gcc/gcc_prof_dir/13248$ ls -l
-rw-r--r-- 1 qinzhao qinzhao 100 Jun  2 19:02
#home#qinzhao#Bugs#profile#small_gcc#five.gcda
-rw-r--r-- 1 qinzhao qinzhao 184 Jun  2 19:02
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda
-rw-r--r-- 1 qinzhao qinzhao 100 Jun  2 19:02
#home#qinzhao#Bugs#profile#small_gcc#ten.gcda

**with the patch:
qinzhao@gcc14:~/Bugs/profile/small_gcc/gcc_prof_dir/20668$ ls -l
-rw-r--r-- 1 qinzhao qinzhao  68 Jun  2 19:34
#home#qinzhao#Bugs#profile#small_gcc#five.gcda
-rw-r--r-- 1 qinzhao qinzhao 144 Jun  2 19:34
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda
-rw-r--r-- 1 qinzhao qinzhao 100 Jun  2 19:34
#home#qinzhao#Bugs#profile#small_gcc#ten.gcda

from the above data, we can see:

1. there are size reduction for "five.c" and "lib.c" as expected.
2. However, we still keep the *.gcda file for five.c even though there is no
any meaningful data in this file. 

I will try to get more data on our real application. 

one question: why not just delete the entire records whose counter is zero and
delete the entire file whose counter is zero?

[Bug target/95471] vrndvq_f32 not supported on armv8

[e...@coeus-group.com]

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

--- Comment #2 from Evan Nemerson  ---
In that case shouldn't the header be adjusted to not define the vrndvq_f32
function unless it is enabled?

It is already guarded by a check for __ARM_ARCH >= 8 (see
,
but obviously that isn't sufficient.  If nothing else it would help document
the actual requirements, which would be great since the flags and macros on ARM
are a bit of a mess.

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On June 2, 2020 6:55:21 PM GMT+02:00, skpgkp2 at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
>
>--- Comment #14 from Sunil Pandey  ---
>Created attachment 48662
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48662&action=edit
>Add target hook to skip alignment check for long long on x86 with -m32
>and
>-mpreferred-stack-boundary=2
>
>Bootstrap and regression tested on x86_64.

That doesn't make sense.  The alignment is already too large, so the patch will
avoid the ICE but not fix the wrong-code issue.

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[rguenther at suse dot de]

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

--- Comment #27 from rguenther at suse dot de  ---
On June 2, 2020 6:34:12 PM GMT+02:00, andrew2085 at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
>--- Comment #25 from Andrew Downing  ---
>Do you know how to change that example so that gcc's knowledge is
>incomplete
>and it not longer does the correct thing?

Add std::launder ;) or, for example, conditionally assign another pointer
incoming to the function before dereferencing it (untested).

[Bug c++/95050] coroutine: no "mandatory copy elision" for prvalue await_resume expression.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:324276ff9b1aa5128e5cb9f5d43182d1ebab0752

commit r11-835-g324276ff9b1aa5128e5cb9f5d43182d1ebab0752
Author: Iain Sandoe 
Date:   Tue Jun 2 16:47:54 2020 +0100

coroutines: Wrap co_await in a target expr where needed [PR95050]

Since the co_await expression is mostly opaque to the existing
machinery, we were hiding the details of the await_resume return
value.  If that needs to be wrapped in a target expression, then
emulate this with the whole co_await.  Similarly, if the await
expression we build in response to co_await p.yield_value (e)
is wrapped in a target expression, then we need to transfer that
wrapper to the resultant CO_YIELD_EXPR (which is, itself, just
a proxy for the underlying co_await).

gcc/cp/ChangeLog:

PR c++/95050
* coroutines.cc (build_co_await): Wrap the co_await expression
in a TARGET_EXPR, where needed.
(finish_co_yield_expr): Likewise.

gcc/testsuite/ChangeLog:

PR c++/95050
* g++.dg/coroutines/pr95050.C: New test.