[Bug tree-optimization/92260] [10 Regression] ICE in exact_div, at poly-int.h:2162

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:584a3c080bbd6e64131fa53771c7424bcf9d21fa

commit r11-418-g584a3c080bbd6e64131fa53771c7424bcf9d21fa
Author: Richard Biener 
Date:   Fri May 15 11:14:53 2020 +0200

tree-optimization/92260 - improve fix

This improves the fix for PR92260 changing the number of vector
computation to the canonical one, not needing to look at the
using stmt.

2020-05-15  Richard Biener  

PR tree-optimization/92260
* tree-vect-slp.c (vect_get_constant_vectors): Compute
the number of vector stmts in a canonical way.

[Bug bootstrap/95147] [11 Regression] Bootstrap fails with GCC 4.8 host compiler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/545
   ||822.html
   Keywords||patch

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> --disable-cet seems to be a workaround, it looks like the configury fails to
> check for host compiler support (or alternatively --disable-cet should be
> the default for stage1?)

This patch:

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545822.html

fixes it.

[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Any update on this Kees?

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Martin Liška  ---
I'm sorry but I can't install all pre-requisites.
Do you have a Docker/podman I can use to build the package?
Or do you have a reduced test-case?

[Bug c++/95153] Arrays of 'const void *' should not be copyable

[alisdairm at me dot com]

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

--- Comment #1 from Alisdair Meredith  ---
Forgot to add this is specific to -std=c++20 too.

[Bug analyzer/95152] New: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938

[pieter+gcc-bugzilla at plexis dot eu]

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

Bug ID: 95152
   Summary: internal compiler error: in get_or_create_mem_ref, at
analyzer/region-model.cc:6938
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: pieter+gcc-bugzilla at plexis dot eu
  Target Milestone: ---

Created attachment 48545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48545=edit
The pre-processed source

While compiling dnsdist[1] from git with '-fanalyzer', GCC 10.1.0 has an
internal compiler error:

during IPA pass: analyzer
In file included from dnsdist.hh:24,
 from dnsdist-lua-bindings.cc:23:
ext/luawrapper/include/LuaContext.hpp: In lambda function:
ext/luawrapper/include/LuaContext.hpp:1241:27: internal compiler error: in
get_or_create_mem_ref, at analyzer/region-model.cc:6938
 1241 | writeFunction_(*object, value);
  | ~~^~~~
Please submit a full bug report,
with preprocessed source if appropriate.

The full commandline is as follows:

g++ -DHAVE_CONFIG_H -I.  -I. -I. -pthread   -I/usr/include/luajit-2.0 
-I/usr/include/editline-I./ext/yahttp  -march=x86-64 -mtune=generic -O2
-pipe -fno-plt -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -DNETSNMP_REMOVE_U64
-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Ulinux -Dlinux=linux
-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe
-fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -I/usr/lib/perl5/5.30/core_perl/CORE
-I/usr/include/libnl3 -D_FORTIFY_SOURCE=2 -I. -I/usr/include 
-DSYSCONFDIR=\"/usr/local/etc\"   -fPIE -DPIE -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 --param ssp-buffer-size=4 -fstack-protector -g -O3 -Wall
-Wextra -Wshadow -Wno-unused-parameter -Wmissing-declarations -Wredundant-decls
-fanalyzer -MT dnsdist-lua-bindings.o -MD -MP -MF $depbase.Tpo -c -o
dnsdist-lua-bindings.o dnsdist-lua-bindings.cc

This is a ArchLinux system, where 'g++ -v' shows this:

Using built-in specs.
COLLECT_GCC=/usr/bin/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) 

The triggering line is in the LuaWrapper[2], a project that can wrap C++
objects and to Lua. I have attached the pre-processed source.

If you need more information, let me know!

1 - https://dnsdist.org
2 -
https://github.com/PowerDNS/pdns/blob/134755f54093a595610e035d01a07f125df3ab13/ext/luawrapper/include/LuaContext.hpp#L1241

[Bug d/94496] [D] Use aggressive optimizations in release mode

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #3 from Witold Baryluk  ---
Also about 'nothrow' and Errors.

I would really welcome a flag to compiler that simply terminates all threads
immidetly any Error is thrown at throw location. They aren't really
recoverable. The only option is either catch them really high in the stack or
terminate the program (in D this will I think unwind all the stack and destroy
scoped structs, also call full GC collection, optionally call all class
destrustors, and module destructors). But in many cases terminating the program
at the spot (_exit(2) or _Exit(2), from glibc (not kernel) to terminate all
threads via exit_group).

As of the 'nothrow' itself. I belive it doesn't mean there is 'no thrown
exceptions in the call tree'. I think it means there is no 'uncought exceptions
possibly throw by call to this function'.

```d
extern int g(int x);  // not nothrow

int f(int x) nothrow {
  try {
 return g(x);
 throw new MyException("ble");
  } catch (Exception e) {
return 1;
  }
  return 0;
}
```

https://gcc.godbolt.org/z/Y3vNQr


As of the asm pure, considering there is asm volatile, wouldn't it make sense
to not allow 'asm pure volatilve' in the first place in the source?

strict aliasing should be enabled for dynamic arrays, static arrays and normal
pointer to other types.   I.e.

```d
void f(int* x, float[] y);  // x, y, y.ptr should not alias.
```



```d
void f(int* x, int[] y);  // x, y and y.ptr can alias.
```

Also how about using `restrict` automatically for transitively const types?
I.e. 

```d
void f(const scope int[] a, int *b);  // can't alias. if b aliases a, then it
is UB.
```

[Bug c++/95132] Concept checked after auto return type deduction

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
(In reply to Francesco Biscani from comment #0)
> This is problematic because it means that another concept that would check
> whether or not bar() can be called with a specific argument type would fail
> with a hard compile time error, instead of marking the concept as not
> satisfied.

Would you have a concrete testcase for this behavior?

[Bug c++/95100] xxx_view adaptors don't work with pipeline operator

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
(In reply to rhalbersma from comment #0)
> Combining the std::ranges::xxx_view adaptors with the pipeline operator does
> not compile, in contrast to the supposedly expression equivalent
> std::ranges:views::xxx 

Hmm, I don't see anything in the spec that would imply views::xxx should be
expression-equivalent to xxx_view.  What I see is that views::xxx(E) is, for
some values of E, expression-equivalent to xxx_view{E}.

For instance [range.reverse.overview] says:

   Given a subexpression E, the expression views​::​reverse(E) is
expression-equivalent to: 
   [...]
   - Otherwise, equivalent to reverse_­view{E}.

Could you point me to the relevant bits of the spec that would imply this
stronger expression-equivalence?

[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-421-g0ec52417fd9b3bef5227cdc9a18ff4f0247b0ea4
Author: Tobias Burnus 
Date:   Fri May 15 16:40:34 2020 +0200

[Fortran] OpenMP 5 â permit more sharing clauses for SIMD (PR94690)

gcc/fortran/
PR fortran/94690
* openmp.c (resolve_omp_do): Permit more clauses for SIMD
iteration variables.

gcc/testsuite/
PR fortran/94690
* gfortran.dg/gomp/openmp-simd-4.f90: New test.

[Bug analyzer/95152] internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||needs-bisection,
   ||needs-reduction
   Last reconfirmed||2020-05-15
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, I'm reducing that..

[Bug c++/95153] New: Arrays of 'const void *' should not be copyable

[alisdairm at me dot com]

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

Bug ID: 95153
   Summary: Arrays of 'const void *' should not be copyable
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

In general, we do not expect array types to be copyable according to the
'is_copy_constructible_v' trait.  However, the following started passing in gcc
10:

#include 
static_assert(!std::is_copy_constructible_v);

Note that the 'const' is important, arrays of 'void *' remain non-copyable
according to the trait.

'void' may be a specific trigger too, as arrays of 'const int *' do not have
this problem.

Finally, the array bound does not seem significant, other than it gives the
expected answer again for an array of unknown bound.

[Bug target/95154] New: [11 regression] FAIL: g++.dg/abi/pure-virtual1.C -std=c++14 (test for excess errors)

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

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

Bug ID: 95154
   Summary: [11 regression] FAIL: g++.dg/abi/pure-virtual1.C
-std=c++14 (test for excess errors)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: ia64-*-*

spawn -ignore SIGHUP
/usr/local/gcc/gcc-20200515/Build/gcc/testsuite/g++3/../../xg++
-B/usr/local/gcc/gcc-20200515/Build/gcc/testsuite/g++3/../../
/usr/local/gcc/gcc-20200515/gcc/testsuite/g++.dg/abi/pure-virtual1.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/usr/local/gcc/gcc-20200515/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux
-I/usr/local/gcc/gcc-20200515/Build/ia64-suse-linux/libstdc++-v3/include
-I/usr/local/gcc/gcc-20200515/libstdc++-v3/libsupc++
-I/usr/local/gcc/gcc-20200515/libstdc++-v3/include/backward
-I/usr/local/gcc/gcc-20200515/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++14 -pedantic-errors -Wno-long-long -fno-rtti -nodefaultlibs -lc
-L/usr/local/gcc/gcc-20200515/Build/ia64-suse-linux/./libstdc++-v3/src/.libs
-B/usr/local/gcc/gcc-20200515/Build/ia64-suse-linux/./libstdc++-v3/src/.libs
-L/usr/local/gcc/gcc-20200515/Build/ia64-suse-linux/./libstdc++-v3/src/.libs
-lm -o pure-virtual1.exe
/tmp/ccyWJZLT.o:(.data.rel.ro._ZTV1A[_ZTV1A]+0x10): undefined reference to
`__cxa_pure_virtual'
collect2: error: ld returned 1 exit status
compiler exited with status 1

The reference comes from the vtable for A, the weak declaration for
__cxa_pure_virtual is missing:

.weak   _ZTV1A#
.section.data.rel.ro._ZTV1A,"awG",@progbits,_ZTV1A,comdat
.align 8
.type   _ZTV1A#, @object
.size   _ZTV1A#, 32
_ZTV1A:
data8   0
data8   0
data16.ua @iplt(__cxa_pure_virtual#)

[Bug target/95151] New: Add cmpmemM pattern for -minline-all-stringops

[hjl.tools at gmail dot com]

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

Bug ID: 95151
   Summary: Add cmpmemM pattern for -minline-all-stringops
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

'cmpmemM'
 Block compare instruction, with five operands like the operands of
 'cmpstrM'.  The two memory blocks specified are compared byte by
 byte in lexicographic order starting at the beginning of each
 block.  Unlike 'cmpstrM' the instruction can prefetch any bytes in
 the two memory blocks.  Also unlike 'cmpstrM' the comparison will
 not stop if both bytes are zero.  The effect of the instruction is
 to store a value in operand 0 whose sign indicates the result of
 the comparison.

We should add

(define_expand "cmpmemsi"
  [(set (match_operand:SI 0 "register_operand" "")
(compare:SI (match_operand:BLK 1 "memory_operand" "")
(match_operand:BLK 2 "memory_operand" "") ) )
   (use (match_operand 3 "general_operand"))
   (use (match_operand 4 "immediate_operand"))]
  ""
{
  if (ix86_expand_cmpmem (operands[0], operands[1], operands[2],
  operands[3]))
DONE; 
  else
FAIL; 
})

which can be expanded to sysdeps/i386/memcmp.S in glibc:

movl BLK1(%esp), %esi
cfi_rel_offset (esi, 0)
movl BLK2(%esp), %edi
movl LEN(%esp), %ecx

cld /* Set direction of comparison.  */

xorl %eax, %eax /* Default result.  */

repe/* Compare at most %ecx bytes.  */
cmpsb
jz L(1) /* If even last byte was equal we return 0.  */

/* The memory blocks are not equal.  So result of the last
   subtraction is present in the carry flag.  It is set when
   the byte in block #2 is bigger.  In this case we have to
   return -1 (=0x), else 1.  */
sbbl %eax, %eax /* This is tricky.  %eax == 0 and carry is set
   or not depending on last subtraction.  */

/* At this point %eax == 0, if the byte of block #1 was bigger, and
   0x if the last byte of block #2 was bigger.  The latter
   case is already correct but the former needs a little adjustment.
   Note that the following operation does not change 0x.  */
orb $1, %al /* Change 0 to 1.  */

L(1):

[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
I see :(.  I'll take a look, thanks for noticing.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[alisdairm at me dot com]

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

--- Comment #13 from Alisdair Meredith  ---
As this has shipped for two releases now (gcc9 and 10) I recommend closing as
Works As Designed, citing C standard paper N2322 as reason for the change.

[Bug libgomp/95150] New: Some offloaded programs crash with openmp

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 95150
   Summary: Some offloaded programs crash with openmp
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

This is the reduced program:

$ cat matmul.F90
program main
  implicit none
  integer, parameter :: sp = selected_real_kind(6,37)
  integer, parameter :: l = 1024, m = 1024, n = 1024
  real(sp), allocatable :: a(:,:), b(:,:), c(:,:)
  integer :: i, j, k, t1, t2
  real(sp) :: tic
  !
  call system_clock( t1, tic)
  !
  allocate( a(l,m), b(m,n), c(l,n) )
  !
  call random_number(a)
  call random_number(b)
  c = 0._sp
  !
  !$acc data copyin(a,b) copyout(c)
  !$acc parallel loop collapse(3)
  !$omp target teams distribute collapse(3) map( to:a,b ) map( tofrom:c)
  do j = 1, n
do k = 1, m
  do i = 1, l
c(i,j) = a(i,k)*b(k,j) + c(i,j)
  end do
end do
  end do
  !$acc end data
  !
  call system_clock(t2)
  print*, (t2-t1)/tic
  !
end program main

This program compiles successfully with both OpenMP and OpenACC but it crashs
with OpenMP after a short time of running, throwing this error message:

$ gfortran-10 -fopenmp -foffload=nvptx-none="-lm -lgfortran" matmul.F90 -o
test.x
$ $ ./test.x

libgomp: cuCtxSynchronize error: the launch timed out and was terminated

The same message appears with gfortran-9

[Bug other/67300] -foffload* undocumented

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
(In reply to Thomas Schwinge from comment #1)
> … in the patch submission email,
>  GA16368%40msticlxl57.ims.intel.com%3E>.

Actually working link:
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg01057.html

[Bug bootstrap/95147] [11 Regression] Bootstrap fails with GCC 4.8 host compiler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-15
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug libgomp/95150] Some offloaded programs crash with openmp

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
* You compilation uses "-O0" – I do not know whether that's intended.

* I did not see any timeout message although it did take a while to run
  with offloading. (See timing results below.)
  I wonder what causes the problem you are seeing.

  You could try whether setting the environment variable
GOMP_DEBUG=1
  shows some useful details for the launch.

* The OpenACC test case is wrong as "c" has to be "copy" not "copyout"
  as the initial value is used (→ NaN)

On the technical side, at startup, one calls:
  cuLaunchKernel
and when that has succeeded, one calls
  cuCtxSynchronize
and if that fails, the error message is printed with
  cuda_error
which shows the time-out message:
  libgomp: cuCtxSynchronize error: the launch timed out and was terminated


I added a ", sum(c)" to the print output and did some tests:

On AMDGCN:
== -O0 == 3.5688   268048112.
== -Ofast ==  0.10999  268698816.
== -fopenmp -O0 ==  193.227997 268186448.
== -fopenmp -Ofast ==43.1559982268455872.
== -fopenacc -O0 == 186.399002 268531136.
== -fopenacc -Ofast ==   43.4970016268206464.
== -fopenmp -foffload=disable -O0 ==  7.27299976   268241776.
== -fopenmp -foffload=disable -Ofast ==   1.4901   268171680.


On NVidia:
== -O0 ==8.00599957268253520.
== -Ofast == 0.25495   268399056.
== -fopenmp -O0 ==  64.2089996 268092608.
== -fopenmp -Ofast ==   33.6360016 268359952.
== -fopenacc -O0 ==  0.86189 NaN (see note)
== -fopenacc -Ofast ==   0.30012 NaN (see note)
== -fopenmp -foffload=disable -O0 ==15.2220001 268511968.
== -fopenmp -foffload=disable -Ofast ==  3.5294268573568.
== -fopenacc -foffload=disable -O0 ==   14.5790005 268442496.
== -fopenacc -foffload=disable -Ofast == 4.41099977268511968.

[Bug libgomp/95150] Some offloaded programs crash with openmp

[chinoune.mehdi at hotmail dot com]

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

--- Comment #2 from Chinoune  ---
Created attachment 48546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48546=edit
debug ouput

[Bug libgomp/95150] Some offloaded programs crash with openmp

[chinoune.mehdi at hotmail dot com]

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

--- Comment #3 from Chinoune  ---
(In reply to Tobias Burnus from comment #1)
> * You compilation uses "-O0" – I do not know whether that's intended.
I didn't set any optimization flag, maybe the compiler default to "-O0".

>  
> * I did not see any timeout message although it did take a while to run
>   with offloading. (See timing results below.)
>   I wonder what causes the problem you are seeing.
> 
>   You could try whether setting the environment variable
> GOMP_DEBUG=1
>   shows some useful details for the launch.
> 
I have attached the output with GOMP_DEBUG=1

> * The OpenACC test case is wrong as "c" has to be "copy" not "copyout"
>   as the initial value is used (→ NaN)
Thanks, I did observe after I reported the bug.

I am using a Kepler (sm_35) Graphics card, if this helps.

[Bug c++/83028] Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

 CC||rafael at espindo dot la

--- Comment #3 from Rafael Avila de Espindola  ---
We just hit this and incorrectly assumed our codebase had a bug. It would be
really nice for this warning to take -std=XX into consideration and not warn
for code that is now valid.

[Bug target/95154] [11 regression] FAIL: g++.dg/abi/pure-virtual1.C -std=c++14 (test for excess errors)

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

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

--- Comment #1 from Andreas Schwab  ---
The problem is that when output_constant processes a FDESC_EXPR it calls
ASM_OUTPUT_FDESC, which doesn't do weak processing (it doesn't call
assemble_external).

[Bug bootstrap/95147] [11 Regression] Bootstrap fails with GCC 4.8 host compiler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed.

[Bug bootstrap/95147] [11 Regression] Bootstrap fails with GCC 4.8 host compiler

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-422-g4c1a5d8b71e29b71e0bc1004480c12c5fc427cb7
Author: H.J. Lu 
Date:   Fri May 15 09:06:50 2020 -0700

x86: Also check if -fcf-protection works

When defaulting CET run-time support to auto, check if -fcf-protection
works.  Even if the stage1 GCC doesn't support -fcf-protection, since
the final GCC does, CET run-time support will be enabled by default if
binutils support CET.

config/

PR bootstrap/95147
* cet.m4 (GCC_CET_FLAGS): Also check if -fcf-protection works
when defaulting to auto.

libatomic/

PR bootstrap/95147
* configure: Regenerated.

libbacktrace/

PR bootstrap/95147
* configure: Regenerated.

libgcc/

PR bootstrap/95147
* configure: Regenerated.

libgfortran/

PR bootstrap/95147
* configure: Regenerated.

libgomp/

PR bootstrap/95147
* configure: Regenerated.

libitm/

PR bootstrap/95147
* configure: Regenerated.

libobjc/

PR bootstrap/95147
* configure: Regenerated.

libphobos/

PR bootstrap/95147
* configure: Regenerated.

libquadmath/

PR bootstrap/95147
* configure: Regenerated.

libsanitizer/

PR bootstrap/95147
* configure: Regenerated.

libssp/

PR bootstrap/95147
* configure: Regenerated.

libstdc++-v3/

PR bootstrap/95147
* configure: Regenerated.

libvtv/

PR bootstrap/95147
* configure: Regenerated.

zlib/

PR bootstrap/95147
* configure: Regenerated.

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[rafael at espindo dot la]

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

--- Comment #3 from Rafael Avila de Espindola  ---
Yes, our build bots use podman, so you can reproduce with:

$ git clone https://github.com/scylladb/seastar
$ cd seastar
$ podman run -v $PWD:$PWD:z -w $PWD -it
docker.io/scylladb/scylla-toolchain:fedora-31-20200512
$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Debug -G Ninja ../
$ ninja tests/unit/chunked_fifo_test
$ time ASAN_OPTIONS=detect_stack_use_after_return=0
./tests/unit/chunked_fifo_test -t chunked_fifo_big
$ time ASAN_OPTIONS=detect_stack_use_after_return=1
./tests/unit/chunked_fifo_test -t chunked_fifo_big
$ cd ..
$ dnf install clang
$ mkdir build-clang
$ cd build-clang
$ CC=clang CXX=clang++ cmake -DCMAKE_BUILD_TYPE=Debug -G Ninja ../
-DSeastar_CXX_FLAGS=-Wno-error
$ ninja tests/unit/chunked_fifo_test
$ time ASAN_OPTIONS=detect_stack_use_after_return=0
./tests/unit/chunked_fifo_test -t chunked_fifo_big
$ time ASAN_OPTIONS=detect_stack_use_after_return=1
./tests/unit/chunked_fifo_test -t chunked_fifo_big

[Bug c++/95153] Arrays of 'const void *' should not be copyable in C++20

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
This is behaving as specified.

const void* const a[10];
const void* const b[10](a);

is valid code in C++20; it initializes b[0] with [0] converted to a const
void*, and the rest of b with null pointers.

The void* case is

void* const a[10];
void* const b[10](a);

which is invalid because [0] is a void* const*; converting that to void* is
not allowed because it casts away constness.

[Bug c++/93286] [10 Regression] ICE: tree check: did not expect class ‘type’, have ‘type’ (reference_type) in convert_from_reference, at cp/cvt.c:550 since g:e0d91792eec490d1

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-423-gcda6396a1b6e6bba2a3b0847931567c3458f2184
Author: Jason Merrill 
Date:   Fri May 15 14:06:48 2020 -0400

PR c++/93286 - ICE with __is_constructible and variadic template.

My GCC 10 patch for 93286 fixed the missing piece in tsubst's handling of
lists vs. that in tsubst_copy_and_build, but it would be better to share
the
code between them.

gcc/cp/ChangeLog
2020-05-15  Jason Merrill  

PR c++/93286 - ICE with __is_constructible and variadic template.
* pt.c (tsubst_tree_list): New.
(tsubst, tsubst_copy_and_build): Use it.
* decl2.c (is_late_template_attribute): Handle error_mark_node
args.

[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

[qinzhao at gcc dot gnu.org]

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
So, based on the previous discussion on the LLVM option 
-ftrivial-auto-var-init=[uninitialized|pattern|zero]

we can see:
-ftrivial-auto-var-init=pattern 

might not be a good idea due to the following:

1. performance data is not good;
2. doesn't really help improve the general situation. People see it as a
debugging tool, not a "improve code quality and improve the life of kernel
developers" tool. (Per Linus)

On the other hand,
-ftrivial-auto-var-init=zero

might be helpful to improve code quality and improve the life fo kernel
developers. 

At the same time, a new variable attribute might be needed at the same time
along with -ftrivial-auto-var-init=zero:

__attribute((uninitialized) 

to mark variables that are uninitialized intentionally for performance purpose.

In a summary, in GCC, we should provide:
1. add a new GCC option: -ftrivial-auto-var-init to initialize trivial auto
variable to zero.
2. provide a new attribute for variable: __attribute((uninitialized) to mark
variables that are uninitialized intentionally for performance purpose.

[Bug c/95157] New: Missing -Wtautological-compare warning

[simon.marchi at polymtl dot ca]

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

Bug ID: 95157
   Summary: Missing -Wtautological-compare warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

Using this code:

volatile short insn;

int main()
{
  if (insn < 0 && insn > 3) {
  return 1;
  } else {
  return 0;
  }
}


clang 11 warns, but gcc doesn't:

$ gcc-10 test.c -c -Wall
$ g++-10 test.c -c -Wall
$ clang-11 test.c -c -Wall 
test.c:5:16: warning: overlapping comparisons always evaluate to false
[-Wtautological-overlap-compare]
  if (insn < 0 && insn > 3) {
  ~^~~
1 warning generated.
$ clang++-11 test.c -c -Wall
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated [-Wdeprecated]
test.c:5:16: warning: overlapping comparisons always evaluate to false
[-Wtautological-overlap-compare]
  if (insn < 0 && insn > 3) {
  ~^~~
1 warning generated.


I think -Wtautological-compare should trigger here.

[Bug d/95155] New: d: wrong vtable offset in virtual function call

[ibuclaw at gdcproject dot org]

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

Bug ID: 95155
   Summary: d: wrong vtable offset in virtual function call
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Seen when compiling self-hosted D compiler.

release/gcc-9 compiles:

isBaseOf (struct TypeClass * const this, struct Type * t, int * poffset)
{
  if (t != 0B && t->ty == 7)
{
  {
struct ClassDeclaration * cd;

cd = ((struct TypeClass *) t)->sym;
if (MEM[(bool (*) (struct ClassDeclaration *, struct
ClassDeclaration *, int *))this->sym->__vptr + 704B] (this->sym, cd, poffset))
  {
return  = 1;
  }
  }
}
  return  = 0;
}


release/gcc-10 compiles:

isBaseOf (struct TypeClass * const this, struct Type * t, int * poffset)
{
  if (t != 0B && t->ty == 7)
{
  {
struct ClassDeclaration * cd;

cd = ((struct TypeClass *) t)->sym;
if (MEM[(bool (*) (struct ClassDeclaration *, struct
ClassDeclaration *, int *))this->sym->__vptr + 736B] (this->sym, cd, poffset))
  {
return  = 1;
  }
  }
}
  return  = 0;
}


Applied all changes to gcc/d to the gcc-9 branch, and the problem gets
resolved, so will have to comb through the diff to find out what missing change
is causing gdc-9 to miscompile.

[Bug c++/95156] New: -Wtautological-compare warns in C but not C++

[simon.marchi at polymtl dot ca]

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

Bug ID: 95156
   Summary: -Wtautological-compare warns in C but not C++
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

Any reason why this code:

volatile unsigned short insn;

int main()
{
  if ((insn & 0xffb0) == 0xe950) {
  return 1;
  } else {
  return 0;
  }
}

warns when compiled with gcc:

$ gcc-10 test.c -c -Wall
test.c: In function ‘main’:
test.c:5:23: warning: bitwise comparison always evaluates to false
[-Wtautological-compare]
5 |   if ((insn & 0xffb0) == 0xe950) {
  |  

but not when compiled with g++:

$ g++-10 test.c -c -Wall


?

[Bug c++/90996] [8/9 Regression] ICE in gimplify_expr, at gimplify.c:13495

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:289fbbe75f6d1c69605fcfde769ac46944c14a4a

commit r11-424-g289fbbe75f6d1c69605fcfde769ac46944c14a4a
Author: Patrick Palka 
Date:   Fri May 15 14:50:17 2020 -0400

c++: Revert unnecessary parts of fix for [PR90996]

The process_init_constructor_array part of my PR90996 patch turns out to
be neither necessary nor sufficient to make the pr90996.C testcase work,
and I wasn't able to come up with a testcase that demonstrates this part
is ever necessary.

gcc/cp/ChangeLog:

Revert:

2020-04-07  Patrick Palka  

PR c++/90996
* typeck2.c (process_init_constructor_array): Propagate
CONSTRUCTOR_PLACEHOLDER_BOUNDARY up from each element
initializer to the array initializer.

gcc/testsuite/ChangeLog:

PR c++/90996
* g++.dg/cpp1y/pr90996.C: Turn into execution test to verify
that each PLACEHOLDER_EXPR gets correctly resolved.

[Bug c++/95158] New: Templates + Diamond Inheritance + Final = Pure Virtual Function Call

[sudgylacmoe at gmail dot com]

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

Bug ID: 95158
   Summary: Templates + Diamond Inheritance + Final = Pure Virtual
Function Call
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudgylacmoe at gmail dot com
  Target Milestone: ---

With this code:

class Base {
public:
virtual void foo()=0;
};

template 
class MiddleA : virtual public Base {
public:
virtual void foo() override {}
};

class MiddleB : virtual public Base {};

template 
class Derived final : public MiddleA, public MiddleB {
public:
void bar()
{
this->foo();
}
};

int main()
{
auto a = Derived();
a.bar(); // Instantiate the template
}

Compiling it with gcc 10.1 with just "g++ test.cpp" (and many other ways to
compile, such as optimization levels and warnings) causes gcc to try to call
Base::foo(), a pure virtual function:

/usr/bin/ld: /tmp/cce0CW5N.o: in function `Derived::bar()':
test.cpp:(.text._ZN7DerivedIvE3barEv[_ZN7DerivedIvE3barEv]+0x14): undefined
reference to `Base::foo()'
collect2: error: ld returned 1 exit status

Trying a few different versions, with gcc 9.3 and before this code compiles
correctly.  On any other compiler I tried (the most recent versions of clang,
msvc and icc on godbolt) it compiled fine.  Removing the template from either
MiddleA or Derived fixes it, removing the inheriting from MiddleB fixes it, and
removing final from Derived fixes it.  If a definition of Base::foo() is added,
the code compiles and calls it.  A workaround is to call MiddleA::foo()
directly.

Output of g++ -v:

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 d/95155] d: wrong vtable offset in virtual function call

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
Looks like fix was in r10-7280, taken from the upstream backport in
https://github.com/dlang/dmd/pull/10913

[Bug c++/95156] -Wtautological-compare warns in C but not C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Version|unknown |11.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org
  Known to fail||10.1.0, 11.0, 9.2.0
   Keywords||diagnostic
   Last reconfirmed||2020-05-15

--- Comment #1 from Martin Sebor  ---
In C mode the warning function, warn_tautological_bitwise_comparison (const
op_location_t , tree_code code, tree lhs, tree rhs), gets a BIT_AND_EXPR
while in C++ mode it's passed a NOP_EXPR that casts the result of the same
BIT_AND_EXPR as in C to int.  The cast seems pointless since the type of the
BIT_AND_EXPR already is int.

I couldn't find a version where G++ did issue the expected warning so it's not
a regression.

(As an aside, the volatile qualifier isn't necessary to reproduce the bug.)

[Bug tree-optimization/15880] No 'may be used uninitialize' warning for arrays.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||4.1.0
 Resolution|DUPLICATE   |FIXED
 Blocks||24639
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
GCC has diagnosed this bug since at least version 4.1 so it's FIXED (and
unrelated to bug 10138).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/95100] xxx_view adaptors don't work with pipeline operator

[rhalbersma at gmail dot com]

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

--- Comment #2 from rhalbersma  ---
OK, so the rewriting rules [range.adaptors]/4, that make views::xxx(R)
equivalent to R | views::xxx, do not allow to rewrite the expression equivalent
xxx_view{R} as R | xxx_view? That would be rather finicky, perhaps even a
defect in the Standard?

[Bug c++/57943] [c++11] invalid decltype expression accepted in template default type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:115232b778943be075fc4df991e03d9387563114

commit r11-434-g115232b778943be075fc4df991e03d9387563114
Author: Patrick Palka 
Date:   Fri May 15 18:51:11 2020 -0400

c++: decltype of invalid non-dependent expr [PR57943]

We sometimes fail to reject an invalid non-dependent operand to decltype
when inside a template, because finish_decltype_type resolves the
decltype to the TREE_TYPE of the operand before we ever instantiate and
fully process the operand.  Fix this by adding a call to
instantiate_non_dependent_expr_sfinae in finish_decltype_type.

gcc/cp/ChangeLog:

PR c++/57943
* semantics.c (finish_decltype_type): Call
instantiate_non_dependent_expr_sfinae on the expression.

gcc/testsuite/ChangeLog:

PR c++/57943
* g++.dg/cpp0x/decltype76.C: New test.

[Bug c++/57943] [c++11] invalid decltype expression accepted in template default type

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 11.

[Bug c++/95159] New: ICE on aggregate template parameter with empty angle brackets

[pacoarjonilla at yahoo dot es]

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

Bug ID: 95159
   Summary: ICE on aggregate template parameter with empty angle
brackets
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pacoarjonilla at yahoo dot es
  Target Milestone: ---

The following snippet triggers an ICE when compiled with --std=c++20 on GCC
10.0.1

>>>

template  struct A {
A(const char (&)[L]) { }
};

template  struct B { };

template  void fu(B>) { }


>>>


Compiler output:

bug.cc:7:27: internal compiler error: Segmentation fault
7 | template  void fu(B>) { }
  |   ^
0xc4dc7f crash_signal
/home/paco/git/gcc/gcc/toplev.c:328
0x62e613 resolve_args(vec*, int)
/home/paco/git/gcc/gcc/cp/call.c:4455
0x743b6e do_class_deduction
/home/paco/git/gcc/gcc/cp/pt.c:28787
0x743b6e do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/paco/git/gcc/gcc/cp/pt.c:28920
0x744ff2 convert_template_argument
/home/paco/git/gcc/gcc/cp/pt.c:8395
0x757e9f convert_template_argument
/home/paco/git/gcc/gcc/cp/pt.c:8168
0x757e9f coerce_template_parms
/home/paco/git/gcc/gcc/cp/pt.c:8899
0x75a681 lookup_template_class_1
/home/paco/git/gcc/gcc/cp/pt.c:9737
0x75b8cc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/paco/git/gcc/gcc/cp/pt.c:10109
0x77808d finish_template_type(tree_node*, tree_node*, int)
/home/paco/git/gcc/gcc/cp/semantics.c:3408
0x71fbdd cp_parser_template_id
/home/paco/git/gcc/gcc/cp/parser.c:16734
0x71fe4c cp_parser_class_name
/home/paco/git/gcc/gcc/cp/parser.c:23697
0x71cb81 cp_parser_qualifying_entity
/home/paco/git/gcc/gcc/cp/parser.c:6776
0x71cb81 cp_parser_nested_name_specifier_opt
/home/paco/git/gcc/gcc/cp/parser.c:6458
0x724126 cp_parser_simple_type_specifier
/home/paco/git/gcc/gcc/cp/parser.c:18129
0x70ae9d cp_parser_type_specifier
/home/paco/git/gcc/gcc/cp/parser.c:17787
0x70be76 cp_parser_decl_specifier_seq
/home/paco/git/gcc/gcc/cp/parser.c:14359
0x726dda cp_parser_parameter_declaration
/home/paco/git/gcc/gcc/cp/parser.c:22765
0x7276fa cp_parser_parameter_declaration_list
/home/paco/git/gcc/gcc/cp/parser.c:22588
0x727a65 cp_parser_parameter_declaration_clause
/home/paco/git/gcc/gcc/cp/parser.c:22515
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-432-ge478cacb62f116d2c8efdabc4b51e6d2d7041aae
Author: Ian Lance Taylor 
Date:   Fri May 15 10:50:57 2020 -0700

libgo: only build syscall test with -static if it works

Test whether -static works, and use it if possible.

This time for sure.

For PR go/95061

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/234024

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[rafael at espindo dot la]

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

--- Comment #5 from Rafael Avila de Espindola  ---
With a seastar patched for c++ 20 (mostly dropping a few experimental/ from
includes and experimental:: from names), the following is all that is needed:

#include 
#include 
using namespace seastar;
int main(int argc, char** argv) {
seastar::app_template app;
app.run(argc, argv, [] () -> future<> {
future<> xyz = make_ready_future<>().then([] {});
co_await std::move(xyz);
});
return 0;
}

I have attached a partially preprocessed version that can be use with current
seastar from https://github.com/scylladb/seastar.

First build seastar in debug mode:

$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Debug .. -GNinja
$ ninja

And the test can be built with

$ g++ test.cc -fcoroutines $(pkg-config --cflags --libs
/seastar/build-dbg/seastar.pc --static)  -o t-asan

It crashes like this:

$ export ASAN_OPTIONS=disable_coredump=0:abort_on_error=1
$ export UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1
$ gdb --args ./t-asan -c 1
...
run
...
test.cc:3749:5: runtime error: member call on misaligned address 0x41b58ab3
for type 'struct awaiter', which requires 8 byte alignment
0x41b58ab3: note: pointer points here


If seastar is build with clang (CC=clang CXX=clang++ cmake...) or if the
sanitizers are disabled (-DSeastar_SANITIZE=OFF) and valgrind is used instead,
the program doesn't crash.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[rafael at espindo dot la]

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

--- Comment #4 from Rafael Avila de Espindola  ---
Created attachment 48547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48547=edit
testcase

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Last reconfirmed|2008-03-30 20:45:14 |2020-5-15
   Target Milestone|--- |11.0

--- Comment #29 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545856.html

[Bug c++/95159] ICE on aggregate template parameter with empty angle brackets

[pacoarjonilla at yahoo dot es]

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

--- Comment #1 from Paco Arjonilla  ---
GCC 10.1, not GCC 10.0.1

[Bug middle-end/95140] [10/11 Regression] bogus -Wstringop-overflow for a loop unrolled past the end of a trailing array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
   Priority|P3  |P2

[Bug c/95141] [8/9/10/11 Regression] Incorrect integer overflow warning message for bitand expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2020-05-15
   Target Milestone|--- |8.5
 Ever confirmed|0   |1
Summary|Incorrect integer overflow  |[8/9/10/11 Regression]
   |warning message for bitand  |Incorrect integer overflow
   |expression  |warning message for bitand
   ||expression
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r7-7544-g2d143ba8cfef7ef480c639882fd5518b7afd822b

[Bug c/95145] [8/9/10/11 Regression]internal compiler error: in analyze_functions, at cgraphunit.c:1380

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
  Known to work||4.9.4
   Target Milestone|--- |8.5
  Known to fail||5.4.0
Summary|[10/11 Regression]internal  |[8/9/10/11
   |compiler error: in  |Regression]internal
   |analyze_functions, at   |compiler error: in
   |cgraphunit.c:1380   |analyze_functions, at
   ||cgraphunit.c:1380
   Priority|P3  |P4

--- Comment #1 from Richard Biener  ---
GCC 9 ICEs as well, but 4.9.4 does not.

[Bug c++/95143] SFINAE failure with static_cast

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||mpolacek at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #12 from Richard Biener  ---
Thus fixed.  Adding the testcase might be nice.

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r11-409-gf4356120ba88c083dd5987376aab7590dd1e0e13
Author: Uros Bizjak 
Date:   Fri May 15 09:24:38 2020 +0200

i386: Add V2SFmode hadd/hsub instructions [PR95046]

PFACC/PFNACC 3dNow! instructions got their corresponding SSE alternative
in SSE3, so these can't be implemented with TARGET_MMX_WITH_SSE, which
implies SSE2.  These instructions are only generated via builtins, and
since several 3dNow! insns have no corresponding SSE alternative,
we can't avoid MMX registers with 3dNow! builtins anyway.

Add SSE3/AVX alternatives to the insn pattern, so compiler will be able
to use XMM registers when available, but don't prevent MMX registers,
since they are needed when SSE3 is not active.

Add additional generic insn patterns, used by the combiner to
synthesize horizontal V2SFmode add/sub instructions.  These patterns
are active for TARGET_MMX_WITH_SSE only, and use only XMM registers.

gcc/ChangeLog:

PR target/95046
* config/i386/i386.md (isa): Add sse3_noavx.
(enabled): Handle sse3_noavx.

* config/i386/mmx.md (mmx_haddv2sf3): New expander.
(*mmx_haddv2sf3): Rename from mmx_haddv2sf3.  Add SSE/AVX
alternatives.  Match commutative vec_select selector operands.
(*mmx_haddv2sf3_low): New insn pattern.

(*mmx_hsubv2sf3): Add SSE/AVX alternatives.
(*mmx_hsubv2sf3_low): New insn pattern.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-8.c: New test.

[Bug tree-optimization/33315] stores not commoned by sinking

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Biener  ---
Fixed on trunk.  Individual missed cases should be tracked by separate
bugreports.

[Bug tree-optimization/33315] stores not commoned by sinking

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:84935c9822183ce403bb361c5f405711b9a808c6

commit r11-408-g84935c9822183ce403bb361c5f405711b9a808c6
Author: Richard Biener 
Date:   Wed Apr 15 12:09:01 2020 +0200

tree-optimization/33315 - common stores during sinking

This implements commoning of stores to a common successor in
a simple ad-hoc way.  I've decided to put it into the code sinking
pass since, well, it sinks stores.  It's still separate since
it does not really sink code into less executed places.

It's ad-hoc since it does not perform any dataflow or alias analysis
but simply only considers trailing stores in a block, iteratively
though.  If the stores are from different values a PHI node is
inserted to merge them.  gcc.dg/tree-ssa/split-path-7.c shows
that path splitting will eventually undo this very transform,
I've decided to not bother with it and simply disable sinking for
the particular testcase.

Doing this transform is good for code size when the stores are
from constants, once we have to insert PHIs the situation becomes
less clear but it's a transform we do elsewhere as well
(cselim for one), and reversing the transform should be easy.

2020-05-15  Richard Biener  

PR tree-optimization/33315
* tree-ssa-sink.c: Include tree-eh.h.
(sink_stats): Add commoned member.
(sink_common_stores_to_bb): New function implementing store
commoning by sinking to the successor.
(sink_code_in_bb): Call it, pass down TODO_cleanup_cfg returned.
(pass_sink_code::execute): Likewise.  Record commoned stores
in statistics.

* gcc.dg/tree-ssa/ssa-sink-13.c: New testcase.
* gcc.dg/tree-ssa/ssa-sink-14.c: Likewise.
* gcc.dg/tree-ssa/split-path-7.c: Disable sinking.

[Bug other/16996] [meta-bug] code size improvements

[rguenth at gcc dot gnu.org]

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

Bug 33315 Summary: stores not commoned by sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315

   What|Removed |Added

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

[Bug tree-optimization/94566] conversion between std::strong_ordering and int

[rguenth at gcc dot gnu.org]

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

Bug 33315 Summary: stores not commoned by sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315

   What|Removed |Added

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

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

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

Bug 33315 Summary: stores not commoned by sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315

   What|Removed |Added

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

[Bug tree-optimization/91532] [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c

[rguenth at gcc dot gnu.org]

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

Bug 33315 Summary: stores not commoned by sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315

   What|Removed |Added

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

[Bug tree-optimization/95133] [8/9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.5

--- Comment #4 from Richard Biener  ---
Mine then.

[Bug rtl-optimization/11832] Optimization of common stores in switch statements

[rguenth at gcc dot gnu.org]

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

Bug 33315 Summary: stores not commoned by sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315

   What|Removed |Added

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

[Bug fortran/95146] New: gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[burnus at gcc dot gnu.org]

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

Bug ID: 95146
   Summary: gfortran -cpp – leading spaces before '#'
preprocessing directive not handled
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Found when looking at the build results for
  meson (Python-based build system)
which fail like:

[  384s] Command line:  gfortran /home/abuild/rpmbuild/BUILD/meson-0.54.1/b
536484cc32/meson-private/tmpp6hst_hh/testfile.f90 -pipe -cpp -E -P
-D_FILE_OFFSET_BITS=64 -cpp -P -O0 
[  384s] 
[  384s] Code:
[  385s]  
[  385s] #ifdef __has_include
[  385s]  #if !__has_include("omp.h")
[  385s]   #error "Header 'omp.h' could not be found"
[  385s]  #endif
[  385s] #else
[  385s]  #include 
[  385s] #endif
...
[  385s] Error: "__has_include" used outside of preprocessing directive

The problem is that the leading spaces before the '#' are not properly handled.

Simpler example ' #define A 5'. Without space, "gfortran -E" removes that line,
with space, the line remains after preprocessing.

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
This seems to be a side effect of using
  -traditional
in gfortran see PR 28662 for moving to no traditional.

Also gcc -E -traditional shows this behavior of just echoing the strings.

[Bug target/95134] Add a target option to avoid libcall

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #6 from Richard Biener  ---
As decided by Uros (I agree).

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Pre ANSI/ISO C (aka K C), preprocessor were true preprocessor and always
> required # in the first column.
> 
> I think meson should be fixed really to work rather than working around the
> issue in gfortran.

Actually it was already fixed:
https://github.com/mesonbuild/meson/issues/7017

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r11-410-gf8b0665445bee8673b62c0a40ae257fe8c75a9b6
Author: Uros Bizjak 
Date:   Fri May 15 10:02:00 2020 +0200

i386: Add V2SFmode hadd/hsub instructions [PR95046]

PFACC/PFNACC 3dNow! instructions got their corresponding SSE alternative
in SSE3, so these can't be implemented with TARGET_MMX_WITH_SSE, which
implies SSE2.  These instructions are only generated via builtins, and
since several 3dNow! insns have no corresponding SSE alternative,
we can't avoid MMX registers with 3dNow! builtins anyway.

Add SSE3/AVX alternatives to the insn pattern, so compiler will be able
to use XMM registers when available, but don't prevent MMX registers,
since they are needed when SSE3 is not active.

Add additional generic insn patterns, used by the combiner to
synthesize horizontal V2SFmode add/sub instructions.  These patterns
are active for TARGET_MMX_WITH_SSE only, and use only XMM registers.

gcc/ChangeLog:

PR target/95046
* config/i386/i386.md (isa): Add sse3_noavx.
(enabled): Handle sse3_noavx.

* config/i386/mmx.md (mmx_haddv2sf3): New expander.
(*mmx_haddv2sf3): Rename from mmx_haddv2sf3.  Add SSE/AVX
alternatives.  Match commutative vec_select selector operands.
(*mmx_haddv2sf3_low): New insn pattern.

(*mmx_hsubv2sf3): Add SSE/AVX alternatives.
(*mmx_hsubv2sf3_low): New insn pattern.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-8.c: New test.

[Bug target/92658] x86 lacks vector extend / truncate

[crazylht at gmail dot com]

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

--- Comment #13 from Hongtao.liu  ---
*** Bug 92611 has been marked as a duplicate of this bug. ***

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

[crazylht at gmail dot com]

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

Bug 92611 Summary: auto vectorization failed for type promotation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92611

   What|Removed |Added

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

[Bug middle-end/92492] AVX512: Missed vectorization opportunity

[crazylht at gmail dot com]

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

Bug 92611 Summary: auto vectorization failed for type promotation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92611

   What|Removed |Added

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

[Bug target/92611] auto vectorization failed for type promotation

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #3 from Hongtao.liu  ---
x86 lacks vector extend / truncate

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

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-05-15

--- Comment #3 from Martin Liška  ---
@Rafael: Can you please create a simplified test-case?

[Bug c++/95148] New: -Wtype-limits always-false warning triggered despite comparison being avoided

[eyalroz at technion dot ac.il]

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

Bug ID: 95148
   Summary: -Wtype-limits always-false warning triggered despite
comparison being avoided
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Consider the following program:

  #include 

  int main() {
  unsigned x { 5 };
  return (std::is_signed::value and (x < 0)) ? 1 : 0;
  }

when compiling it with GCC versions 11.0 20200511, 10.1, 9.2.1, 8.3.0, I get
the warning:

  a.cpp:5:52: warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]

I should not be getting this warning, because when x is unsigned, the
comparison is never performed, due to the short-circuit semantics of `and`.
This can be easily determined by the compiler - and probably is. No less
importantly, the author of such a line in a program clearly specified his/her
intent here with this check. 

clang doesn't seem to issue a warn inf does come to pass.

[Bug bootstrap/95147] [11 Regression] Bootstrap fails with GCC 4.8 host compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com
 Target||x86_64-*-*
   Priority|P3  |P1
Summary|Bootstrap fails with GCC|[11 Regression] Bootstrap
   |4.8 host compiler   |fails with GCC 4.8 host
   ||compiler
   Target Milestone|--- |11.0

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
(In reply to Andrew Pinski from comment #2)
> Pre ANSI/ISO C (aka K C), preprocessor were true preprocessor and always
> required # in the first column.
> 
> I think meson should be fixed really to work rather than working around the
> issue in gfortran.

Well, gfortran should finally move to non-traditional, but that's not that
trivial as PR 28662 shows.

→ Close as INVALID as the current behavior is fine with -traditional and the
other is already covered.

[Bug bootstrap/95147] New: Bootstrap fails with GCC 4.8 host compiler

[rguenth at gcc dot gnu.org]

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

Bug ID: 95147
   Summary: Bootstrap fails with GCC 4.8 host compiler
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc: error: unrecognized command line option ?-fcf-protection?
gcc: error: unrecognized command line option ?-mshstk?
Makefile:603: recipe for target 'libz_a-adler32.o' failed
make[3]: *** [libz_a-adler32.o] Error 1
make[3]: Leaving directory '/home/abuild/rguenther/obj/zlib'
Makefile:12959: recipe for target 'all-stage1-zlib' failed
make[2]: *** [all-stage1-zlib] Error 2
make[2]: Leaving directory '/home/abuild/rguenther/obj'
Makefile:24483: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/home/abuild/rguenther/obj'
Makefile:998: recipe for target 'all' failed
make: *** [all] Error 2

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Pre ANSI/ISO C (aka K C), preprocessor were true preprocessor and always
required # in the first column.

I think meson should be fixed really to work rather than working around the
issue in gfortran.

[Bug bootstrap/95147] [11 Regression] Bootstrap fails with GCC 4.8 host compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
--disable-cet seems to be a workaround, it looks like the configury fails to
check for host compiler support (or alternatively --disable-cet should be the
default for stage1?)

[Bug c/95141] [8/9/10/11 Regression] Incorrect integer overflow warning message for bitand expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
So there's already (OVF) at

((long unsigned int) IA1 & 158(OVF)) & 1

but we only check

375   if (TREE_OVERFLOW_P (ret)
376   && !TREE_OVERFLOW_P (op0)
377   && !TREE_OVERFLOW_P (op1))
378 overflow_warning (EXPR_LOC_OR_LOC (expr, input_location), ret,
expr);

which doesn't catch the pre-existing overflow on op0 which then propagates.

The original overflow is introduced folding short 158 to signed char -98(OVF)
via convert.c:do_narrow:

437   /* We should do away with all this once we have a proper
438  type promotion/demotion pass, see PR45397.  */
439   expr = maybe_fold_build2_loc (dofold, loc, ex_form, typex,
440 convert (typex, arg0),
441 convert (typex, arg1));

specifically the convert (typex, arg1).

Now TREE_OVERFLOW in general is quite a fragile thing, but it's tempting to
adjust the overflow_warning guard for this case ...

The do_narrow code also specifically looks for overflow cases that matter
and does not perform narrowing then so clearing TREE_OVERFLOW there would
also look reasonable.

Thus like the following?  Should be cheaper than adding walk_tree to the
diagnostic guard.

diff --git a/gcc/convert.c b/gcc/convert.c
index 42509c518a9..ed00ded1a89 100644
--- a/gcc/convert.c
+++ b/gcc/convert.c
@@ -436,9 +436,16 @@ do_narrow (location_t loc,
}
   /* We should do away with all this once we have a proper
 type promotion/demotion pass, see PR45397.  */
+  /* Above we checked for all cases where overflow matters, avoid
+geneating overflowed constants here which otherwise propagate
+and cause spurious warnings, see PR95141.  */
+  tree converted_arg1 = convert (typex, arg1);
+  if (TREE_OVERFLOW_P (converted_arg1)
+ && !TREE_OVERFLOW_P (arg1))
+   converted_arg1 = drop_tree_overflow (converted_arg1);
   expr = maybe_fold_build2_loc (dofold, loc, ex_form, typex,
convert (typex, arg0),
-   convert (typex, arg1));
+   converted_arg1);
   return convert (type, expr);
 }

[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #9 from Volker Reichelt  ---
Hi Marek,

your fix unfortunately breaks the following valid code (reduced from pybind11):

===
template  struct A
{
  typedef int type;
  operator int();
};

template  using B = A;

template  typename B::type foo(B b)
{
  return b.operator typename B::type();
}

void bar()
{
  foo(A());
}
===

bug.cc: In instantiation of 'typename B::type foo(B) [with T = int;
typename B::type = int; B = A; B = A]':
bug.cc:16:15:   required from here
bug.cc:11:36: error: no type named 'B' in 'struct A'
   11 |   return b.operator typename B::type();
  |  ~~^~~~

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-412-g9f0f7da9aa98eec28b4e5e34ade0aa0028df161d
Author: Tobias Burnus 
Date:   Fri May 15 11:50:34 2020 +0200

[OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

gcc/
PR middle-end/94635
* gimplify.c (gimplify_scan_omp_clauses): For MAP_TO_PSET with
OMP_TARGET_EXIT_DATA, use 'release:' unless the associated
item is 'delete:'.

gcc/testsuite
PR middle-end/94635
* gfortran.dg/gomp/target-exit-data.f90: New.

[Bug tree-optimization/95133] [8/9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-414-gaaf1ee48316f9b414b11c17e298198925d816595
Author: Richard Biener 
Date:   Fri May 15 09:38:54 2020 +0200

tree-optimization/95133 - avoid abnormal edges in path splitting

When path splitting tries to detect a CFG diamond make sure it
is composed of normal (non-EH, not abnormal) edges.  Otherwise
CFG manipulation later may fail.

2020-05-15  Richard Biener  

PR tree-optimization/95133
* gimple-ssa-split-paths.c
(find_block_to_duplicate_for_splitting_paths): Check for
normal edges.

* gcc.dg/pr95133.c: New testcase.

[Bug tree-optimization/95133] [8/9/10 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
   |in  |gimple_redirect_edge_and_br
   |gimple_redirect_edge_and_br |anch_force, at
   |anch_force, at  |tree-cfg.c:6075
   |tree-cfg.c:6075 |

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug pch/95131] Instantiate templates at pch generation time

[trass3r at gmail dot com]

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

--- Comment #3 from Trass3r  ---
Well sure but most existing codebases won't be ported to modules because of the
effort while enabling pch is now straightforward with latest CMake.

These conformance issues have also been identified in
https://reviews.llvm.org/D69585#1946765,
which is why a flag -fpch-instantiate-templates was suggested.

For C++20 header unit compilation this behavior is actually required it seems,
so at least if -fmodule-header reuses pch code this may be a low-hanging fruit.


Is anything else from the wiki valid?
"Mangle names, instantiate templates, and generate debug information at pch
generation time"

[Bug c++/95149] New: lex.c:1729:8: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]

[marxin at gcc dot gnu.org]

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

Bug ID: 95149
   Summary: lex.c:1729:8: warning: result of comparison against a
string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org, nathan at gcc dot gnu.org
  Target Milestone: ---

I see the following Clang warnings for lex.c. It comes from:

1729: BUF_APPEND ("\\", 1);

#define BUF_APPEND(STR,LEN) \
  do {  \
bufring_append (pfile, (const uchar *)(STR), (LEN), \
_buff, _buff);   \
total_len += (LEN); \
if (__builtin_expect (temp_buffer_len < 17, 0)  \
&& (const uchar *)(STR) != base \
&& (LEN) <= 2)  \
  { \
memcpy (temp_buffer + temp_buffer_len,  \
(const uchar *)(STR), (LEN));   \
temp_buffer_len += (LEN);   \
  } \
  } while (0)

If I see correctly the problematic comparison is '(const uchar *)(STR) != base'
which is really a comparison in between a string literal and a local variable.

[Bug c++/95149] lex.c:1729:8: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
And?
It is unspecified if "foo" == "foo", not whether "foo" can compare equal to an
automatic variable (it can't).

[Bug c++/95149] lex.c:1729:8: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
With string merging even "foobar" + 3 == "bar" (or not, depending on alignment
decision, how hard does the linker optimize etc.).  For static vars only if
-fmerge-all-constants and the var would be const and contain the same chars.

[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
But this PR has more info, so I'll close the older one as dup, instead.

[Bug target/95070] vec_cntlz_lsbb implementation uses BE semantics on LE

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
Closing as dup.

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

[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
*** Bug 95070 has been marked as a duplicate of this bug. ***

[Bug c++/95149] lex.c:1729:8: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The code here is correct.  In that the warning might be valid for normal code
but the comparasion it is making is valid one.
Mainly because we do:
  /* Restore backslash followed by newline.  */
  BUF_APPEND (base, cur - base);
  base = cur;
  BUF_APPEND ("\\", 1);