[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h

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

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

--- Comment #1 from Thomas Koenig  ---
Created attachment 49311
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49311=edit
Output from the attempt

[Bug target/97302] New: FreeBSD build fails with contrib/download_prerequisites with missing gmp.h

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

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

Bug ID: 97302
   Summary: FreeBSD build fails with
contrib/download_prerequisites with missing gmp.h
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49310=edit
config.log from the attempt

I tried to bootstrap gcc on FreeBSD (to test the native_coarray
branch) using contrib/download_prerequisites.  The script worked, but
the build failed with

checking format of `long double' floating point... IEEE extended, little endian
checking for TLS support using C11... yes
checking for library containing clock_gettime... none required
checking for gmp.h... no
configure: error: gmp.h can't be found, or is unusable.
gmake[2]: *** [Makefile:6521: configure-stage1-mpfr] Error 1
gmake[2]: Leaving directory '/usr/home/tkoenig/trunk-bin'
gmake[1]: *** [Makefile:27350: stage1-bubble] Error 2
gmake[1]: Leaving directory '/usr/home/tkoenig/trunk-bin'
gmake: *** [Makefile:1005: all] Error 2

This is on gcc303.fsffrance.org in my home directory (nothing else there),
so if somebody wants to look, go right ahead.

It was configured with

../trunk/configure --enable-languages=c,c++,fortran

and compilation attempted with

gmake -j3

[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp

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

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

Alexander Monakov  changed:

   What|Removed |Added

  Known to fail||9.3.0
  Known to work|9.3.0   |

--- Comment #19 from Alexander Monakov  ---
That was set early on and not adjusted when new testcases were found. Changed
now.

The original testcase in comment #0 happened to work with 9.3, but breaks if
'float z[1]' is changed to 'char z[4]'. Testcases from the dup and from comment
#7 also fail with 9.3.

[Bug other/97301] New: [11 regression] gcc.target/powerpc/sse-movlps-1.c fails after r11-3434

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

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

Bug ID: 97301
   Summary: [11 regression] gcc.target/powerpc/sse-movlps-1.c
fails after r11-3434
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:c33f474239308d81bf96cfdb2520d25488ad8724, r11-3434

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/sse-movlps-1.c"

FAIL: gcc.target/powerpc/sse-movlps-1.c execution test

# of expected passes1
# of unexpected failures1

commit c33f474239308d81bf96cfdb2520d25488ad8724
Author: Jan Hubicka 
Date:   Thu Sep 24 15:09:17 2020 +0200

(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/./sse-movlps-1.exe 

Program received signal SIGABRT, Aborted.
0x3fffb7cd260c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
55return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) where
#0  0x3fffb7cd260c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x3fffb7cd47f8 in __GI_abort () at abort.c:90
#2  0x1768 in sse_test () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse-movlps-1.c:46
#3  do_test () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse-check.h:14
#4  0x1510 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse-check.h:20

[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp

[luke-jr+gccbugs at utopios dot org via Gcc-bugs]

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

--- Comment #18 from Luke Dashjr  ---
Someone pointed out to me that the bug metadata says "Known to work: 9.3.0"

[Bug c++/97297] typename wrongly required in out-of-class member function definitions

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Marek Polacek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/43.html

[Bug c++/97279] GCC ignores the operation definition of the template

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk  ---
(In reply to Marek Polacek from comment #1)
> Hmm, ICC also produces 2.  Not quite sure what's going on here.

ICC produces 2 by default, but produces 1 when the -strict-ansi command line
option is used.

[Bug ipa/97300] New: [11 regression] several test cases fail after r11-3308

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

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

Bug ID: 97300
   Summary: [11 regression] several test cases fail after r11-3308
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g:d119f34c952f8718fdbabc63e2f369a16e92fa07, r11-3308

make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/assumed_type_9.f90

FAIL: gfortran.dg/assumed_type_9.f90   -O2  execution test
FAIL: gfortran.dg/assumed_type_9.f90   -Os  execution test

# of expected passes10
# of unexpected failures2

The line that fails here is the first if:

! { dg-do run }
!
! Test the fix for PR85742 in which the descriptors, passed to alsize,
! for 'a' and 'b' had the wrong element length.
!
! Contributed by Cesar Philippidis  
!
program main
  implicit none
  integer, allocatable :: a
  real, pointer :: b
  integer, allocatable :: am(:,:)
  real, pointer :: bm(:,:)

  allocate (a)
  allocate (b)
  allocate (am(3,3))
  allocate (bm(4,4))

  if (sizeof (a) /= alsize (a)) stop 1




Also a couple of powerpc tests fail:

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/sse-andnps-1.c"

FAIL: gcc.target/powerpc/sse-andnps-1.c execution test

# of expected passes1
# of unexpected failures1

and

FAIL: gcc.target/powerpc/sse2-andnpd-1.c execution test


Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
exceptions_enabled126558.cc-fdiagnostics-plain-output 
-fdiagnostics-plain-output  -S -o exceptions_enabled126558.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
exceptions_enabled126558.cc -fdiagnostics-plain-output
-fdiagnostics-plain-output -S -o exceptions_enabled126558.s
PASS: gfortran.dg/assumed_type_9.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../..:.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../..:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gfortran.dg/assumed_type_9.f90   -O0  execution test
Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/assumed_type_9.f90   
-fdiagnostics-plain-output  -fdiagnostics-plain-output-O1  
-pedantic-errors 
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
 -lm  -o ./assumed_type_9.exe(timeout = 

[Bug fortran/89219] ICE with derived type I/O

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #6 from Dominique d'Humieres  ---
*** Bug 97037 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/97295] ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273

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

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

--- Comment #3 from Sergei Trofimovich  ---
Poking at the crash to get clues:

"""
(gdb) bt
#0  internal_error (gmsgid=0x285ac9f "in %s, at %s:%d") at
../../gcc-10/gcc/diagnostic.c:1706
#1  0x01f7c34a in fancy_abort (file=0x20c3e90
"../../gcc-10/gcc/profile-count.c", line=273, function=0x20c3e81
"to_frequency") at ../../gcc-10/gcc/diagnostic.c:1778
#2  0x00f0563a in profile_count::to_frequency (this=0x7759b190,
fun=0x77585000) at ../../gcc-10/gcc/profile-count.c:273
#3  0x00f3b5a4 in regstat_bb_compute_ri (bb=0x7759b138,
live=0x2ee0c20) at ../../gcc-10/gcc/regstat.c:200
#4  0x00f3b9df in regstat_compute_ri () at
../../gcc-10/gcc/regstat.c:253
#5  0x00d23399 in ira (f=0x0) at ../../gcc-10/gcc/ira.c:5294
#6  0x00d23d95 in (anonymous namespace)::pass_ira::execute
(this=0x2ddb750) at ../../gcc-10/gcc/ira.c:5666
#7  0x00ec631d in execute_one_pass (pass=0x2ddb750) at
../../gcc-10/gcc/passes.c:2502
#8  0x00ec6655 in execute_pass_list_1 (pass=0x2ddb750) at
../../gcc-10/gcc/passes.c:2590
#9  0x00ec6686 in execute_pass_list_1 (pass=0x2dda4d0) at
../../gcc-10/gcc/passes.c:2591
#10 0x00ec66df in execute_pass_list (fn=0x77585000, pass=0x2dd6790)
at ../../gcc-10/gcc/passes.c:2601
#11 0x009c5de3 in cgraph_node::expand (this=0x7758e2d0) at
../../gcc-10/gcc/cgraphunit.c:2300
#12 0x009c682d in output_in_order () at
../../gcc-10/gcc/cgraphunit.c:2578
#13 0x009c6e6d in symbol_table::compile (this=0x7773e100) at
../../gcc-10/gcc/cgraphunit.c:2819
#14 0x008c41e7 in lto_main () at ../../gcc-10/gcc/lto/lto.c:653
#15 0x010222ab in compile_file () at ../../gcc-10/gcc/toplev.c:458
#16 0x010254cd in do_compile () at ../../gcc-10/gcc/toplev.c:2278
#17 0x010257d8 in toplev::main (this=0x7fffd526, argc=21,
argv=0x2db0700) at ../../gcc-10/gcc/toplev.c:2417
#18 0x01f4b529 in main (argc=21, argv=0x7fffd638) at
../../gcc-10/gcc/main.c:39
"""

"""
(gdb) fr 2
#2  0x00f0563a in profile_count::to_frequency (this=0x7759b190,
fun=0x77585000) at ../../gcc-10/gcc/profile-count.c:273
273   gcc_assert (REG_BR_PROB_BASE == BB_FREQ_MAX

(gdb) call print_generic_decl(stderr,  fun->decl, 0)
  static long unsigned int BitwiseCast (double);

(gdb) call debug_gimple_stmt(fun->gimple_body)
# .MEM_6 = VDEF <.MEM_5(D)>
BitwiseCast (aFrom_2(D), );
"""


"""
$ lto-dump -dump-body=BitwiseCast Unified_cpp_mfbt0.o
Gimple Body of Function: BitwiseCast
BitwiseCast (const double aFrom)
{
   [count: 1509]:
  _3 = VIEW_CONVERT_EXPR(aFrom_2(D));
  return _3;

}

$ lto-dump -dump-body=BitwiseCast TestFloatingPoint.o
...
Gimple Body of Function: BitwiseCast
BitwiseCast (const double aFrom)
{
  long unsigned int temp;
  long unsigned int D.4528;

   :
  BitwiseCast (aFrom_2(D), );
  _4 = temp;
  temp ={v} {CLOBBER};

   :
:
  return _4;

}

Gimple Body of Function: BitwiseCast
BitwiseCast (const double aFrom, long unsigned int * aResult)
{
  long unsigned int D.4534;

   :
  _2 = MEM  [(char * {ref-all})];
  MEM  [(char * {ref-all})aResult_3(D)] = _2;
  return;

}
...
"""

Source definition of the template:

"""
// from firefox-81.0.1/mfbt/Casting.h

template 
inline void BitwiseCast(const From aFrom, To* aResult) {
  static_assert(sizeof(From) == sizeof(To),
"To and From must have the same size");

  // We could maybe downgrade these to std::is_trivially_copyable, but the
  // various STLs we use don't all provide it.
  static_assert(std::is_trivial::value,
"shouldn't bitwise-copy a type having non-trivial "
"initialization");
  static_assert(std::is_trivial::value,
"shouldn't bitwise-copy a type having non-trivial "
"initialization");

  std::memcpy(static_cast(aResult), static_cast(),
  sizeof(From));
}
"""

My interpretation of the above: under some circumstances (different profile
data?) gcc generates two variants of specialised form of
BitwiseCast:
1. VIEW_CONVERT_EXPR form
2. and 'call BitwiseCast (const double aFrom, long unsigned int * aResult)'
form

Once LTO merges both definitions somehow one of them becomes unreachable for
initial part of register allocator (initial analysis?) but not later phase
(actual register allocation?). And assertion fails.

[Bug fortran/97037] ICE on user-defined derived-type output of an intermediate ancestor type

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> This may be related to or the same as pr89219

At least they ICE the same way.

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

[Bug fortran/96992] Class arrays of different ranks are rejected as storage association argument

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-05
 Status|UNCONFIRMED |NEW

[Bug libfortran/97017] The function determine_precision is called twice for each formatted real write

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Priority|P3  |P4
   Last reconfirmed||2020-10-05

--- Comment #1 from Dominique d'Humieres  ---
AFAICT determine_precision is called in two different branches of an IF, i.e.,
no performance penalty.

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

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

[Bug lto/97298] [11 regression] ICE at lto-streamer-out.c:554 after r11-3303

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
This is a target-independent problem also reported in pr97172.

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

[Bug other/97299] New: [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563

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

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

Bug ID: 97299
   Summary: [11 regression] gcc.dg/vect/slp-reduc-3.c fails after
r11-3563
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:9ff2bcd9df8f189dcc94e3bef33f7f282dcaa780, r11-3563
make  -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/slp-reduc-3.c"
FAIL: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect "VEC_PERM_EXPR" 0
FAIL: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "VEC_PERM_EXPR" 0
# of expected passes6
# of unexpected failures2

commit 9ff2bcd9df8f189dcc94e3bef33f7f282dcaa780 (HEAD, refs/bisect/bad)
Author: Richard Biener 
Date:   Wed Sep 30 16:12:20 2020 +0200


Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled346952.cc   
-fdiagnostics-plain-output  -S -o exceptions_enabled346952.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled346952.cc
-fdiagnostics-plain-output -S -o exceptions_enabled346952.s
PASS: gcc.dg/vect/slp-reduc-3.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test/gcc::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/vect/slp-reduc-3.c execution test
gcc.dg/vect/slp-reduc-3.c: pattern found 0 times
XFAIL: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect
"vect_recog_dot_prod_pattern: detected" 1
PASS: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect "vectorized 1 loops"
2
gcc.dg/vect/slp-reduc-3.c: pattern found 0 times
XFAIL: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
gcc.dg/vect/slp-reduc-3.c: pattern found 12 times
FAIL: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect "VEC_PERM_EXPR" 0
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/slp-reduc-3.c   
-fdiagnostics-plain-output  -flto -ffat-lto-objects -maltivec -mpower8-vector
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details --param=vect-epilogues-nomask=0  -lm 
-o ./slp-reduc-3.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/slp-reduc-3.c
-fdiagnostics-plain-output -flto -ffat-lto-objects -maltivec -mpower8-vector
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details --param=vect-epilogues-nomask=0 -lm -o
./slp-reduc-3.exe
PASS: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects (test for excess
errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test/gcc::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects execution test
gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects : pattern found 0 times
XFAIL: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vect_recog_dot_prod_pattern: detected" 1
PASS: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 2
gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects : pattern found 0 times
XFAIL: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorizing stmts using SLP" 1
gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects : pattern found 12 times
FAIL: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "VEC_PERM_EXPR" 0
testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp
completed in 2 seconds

=== gcc Summary ===

# of expected passes6

[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> Maybe the issue is related to PR87711, where the optional KIND argument
> causes havoc with the elementalness of an intrinsic. (There it is LEN_TRIM).

Replying to myself: it seems to be that simplification fails when one of
the arguments to INDEX is array-valued.  Might be a general issue.

[Bug lto/97298] New: [11 regression] ICE at lto-streamer-out.c:554 after r11-3303

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

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

Bug ID: 97298
   Summary: [11 regression] ICE at lto-streamer-out.c:554 after
r11-3303
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g:6450f07388f9fe575a489c9309c36012b17b88b0, r11-3303


make -k check-gcc RUNTESTFLAGS=atomic.exp=gcc.dg/atomic/pr65345-4.c
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
FAIL: gcc.dg/atomic/pr65345-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
# of expected passes5
# of unexpected failures4


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/atomic/pr65345-4.c
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs
-latomic -fdiagnostics-plain-output -O2 -flto -fno-use-linker-plugin
-flto-partition=none -S -o pr65345-4.s
during IPA pass: pure-const
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/atomic/pr65345-4.c:58:1:
internal compiler error: tree code 'ssa_name' is not supported in LTO streams

0x1091db67 lto_write_tree
/home/seurer/gcc/git/gcc-test/gcc/lto-streamer-out.c:554
0x1091db67 lto_output_tree_1
/home/seurer/gcc/git/gcc-test/gcc/lto-streamer-out.c:592
0x10927a3f DFS::DFS(output_block*, tree_node*, bool, bool, bool)
/home/seurer/gcc/git/gcc-test/gcc/lto-streamer-out.c:892
0x10929537 lto_output_tree(output_block*, tree_node*, bool, bool)
/home/seurer/gcc/git/gcc-test/gcc/lto-streamer-out.c:1853
0x1091cf87 write_global_stream
/home/seurer/gcc/git/gcc-test/gcc/lto-streamer-out.c:2846
0x1092d2c7 lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
/home/seurer/gcc/git/gcc-test/gcc/lto-streamer-out.c:2893
0x1092d2c7 produce_asm_for_decls()
/home/seurer/gcc/git/gcc-test/gcc/lto-streamer-out.c:3287
0x109df15b write_lto
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2624
0x109e5747 ipa_write_summaries_1
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2685
0x109e5747 ipa_write_summaries()
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2740
0x105088b3 ipa_passes
/home/seurer/gcc/git/gcc-test/gcc/cgraphunit.c:2689
0x105088b3 symbol_table::compile()
/home/seurer/gcc/git/gcc-test/gcc/cgraphunit.c:2776
0x1050c707 symbol_table::compile()
/home/seurer/gcc/git/gcc-test/gcc/cgraphunit.c:2987
0x1050c707 symbol_table::finalize_compilation_unit()
/home/seurer/gcc/git/gcc-test/gcc/cgraphunit.c:3021


commit 6450f07388f9fe575a489c9309c36012b17b88b0
Author: Martin Sebor 
Date:   Sat Sep 19 17:21:52 2020 -0600

[Bug c++/97297] typename wrongly required in out-of-class member function definitions

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-10-05
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/97297] New: typename wrongly required in out-of-class member function definitions

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

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

Bug ID: 97297
   Summary: typename wrongly required in out-of-class member
function definitions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This should compile with -std=c++20 due to P0634R3:

template 
struct S {
int simple(T::type);

template 
int member(U::type);
};

template 
int S::simple(T::type) { // we still wrongly require 'typename' here...
return 1;
}

template 
template 
int S::member(U::type) { // ...and here
return 2;
}

[temp.res]/5.2.4 covers the out-of-class member function definitions.

[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

[longb at cray dot com via Gcc-bugs]

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

--- Comment #4 from Bill Long  ---
The customer has nuclear weapons.  They do not do "bounty". :)  Cray/HPE is
just the messenger. I think they would be happy with a plan for including the
routine.

[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|IEEE_FMA is missing from|[F2018] IEEE_FMA is missing
   |the IEEE_ARITHMETIC module  |from the IEEE_ARITHMETIC
   ||module

--- Comment #3 from anlauf at gcc dot gnu.org ---
> Any update on a fix for this?  (The original customer is asking.)

I assume the customer or Cray didn't set a bounty on this?

Adding F2018 to summary.

[Bug c++/97296] [10/11 Regression] g++ accepts-invalid after DR2352 fix

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Target Milestone|--- |10.3
Summary|g++ accepts-invalid after   |[10/11 Regression] g++
   |DR2352 fix  |accepts-invalid after
   ||DR2352 fix

[Bug c++/97296] New: g++ accepts-invalid after DR2352 fix

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

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

Bug ID: 97296
   Summary: g++ accepts-invalid after DR2352 fix
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

void f(const int * const &); // #1
void f(const int *); // #2
int *x;
int main()
{
  f(x);
}

has been accepted since r276058, but should be ambiguous.  The follow-up fix to
DR2352 (r276251) didn't make a difference for this test.

[Bug rtl-optimization/97295] ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273

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

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

--- Comment #2 from Sergei Trofimovich  ---
Also fails on unpatched releases/gcc-10.2.0 built as:

"""
$ ${HOME}/dev/git/gcc-10-build/gcc/xg++ -B${HOME}/dev/git/gcc-10-build/gcc -v

Reading specs from /home/slyfox/dev/git/gcc-10-build/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-10-build/gcc/xg++
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-10-build/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-10-build/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O0 -ggdb3 ' CXXFLAGS='-O0 -ggdb3 '
--with-sysroot=/usr/x86_64-HEAD-linux-gnu --enable-valgrind-annotations
--without-zstd
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
"""

[Bug rtl-optimization/97295] ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273

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

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 49309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49309=edit
ICE-testcase-gcc-10.2.0.tar.gz

ICE-testcase-gcc-10.2.0.tar.gz contains two object files that seems to be
enough to feed into gcc-10.2.0 to get IRA crash. Unfortunately it's not a
source-based example. Is it useful to get the idea where ira goes wrong?

I hope it's a simple(ish) bug in not traversing some subset of CFG.

[Bug rtl-optimization/97295] New: ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273

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

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

Bug ID: 97295
   Summary: ICE on firefox built with lto+pgo:
dist/include/mozilla/Casting.h:64:1: internal compiler
error: in to_frequency, at profile-count.c:273
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

It's an upstream report of downstream bug https://bugs.gentoo.org/746578 where
firefox-81.0 built with gcc-9.3.0 or gcc-10.2.0 ICEs on LTO+PGO build:

The crash happens somewhere in register allocator:

"""
$ LANG=C g++-10.2.0 -o TestFloatingPoint TestFloatingPoint.o 
Unified_cpp_mfbt0.o -shared
during RTL pass: ira
/var/tmp/portage/www-client/firefox-81.0.1/work/firefox_build/dist/include/mozilla/Casting.h:
In function 'BitwiseCast':
/var/tmp/portage/www-client/firefox-81.0.1/work/firefox_build/dist/include/mozilla/Casting.h:64:1:
internal compiler error: in to_frequency, at profile-count.c:273
0x5b0db1 profile_count::to_frequency(function*) const
   
/usr/src/debug/sys-devel/gcc-10.2.0-r2/gcc-10.2.0/gcc/profile-count.c:273
0x9edea9 regstat_bb_compute_ri
/usr/src/debug/sys-devel/gcc-10.2.0-r2/gcc-10.2.0/gcc/regstat.c:200
0x9edea9 regstat_compute_ri()
/usr/src/debug/sys-devel/gcc-10.2.0-r2/gcc-10.2.0/gcc/regstat.c:253
0x8a5958 ira
/usr/src/debug/sys-devel/gcc-10.2.0-r2/gcc-10.2.0/gcc/ira.c:5294
0x8a5958 execute
/usr/src/debug/sys-devel/gcc-10.2.0-r2/gcc-10.2.0/gcc/ira.c:5666
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/g++-10.2.0 returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
"""

$ LANG=C g++-10.2.0 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-10.2.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-10.2.0-r2/work/gcc-10.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/10.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/python
--enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 10.2.0-r2 p3' --disable-esp --enable-libstdcxx-time
--enable-host-shared --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-systemtap
--enable-vtable-verify --without-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Gentoo 10.2.0-r2 p3)

[Bug fortran/97123] double free detected in tcache 2 with recursive allocatable type

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-05

--- Comment #3 from Dominique d'Humieres  ---
Confirmed since at least GCC7.

[Bug fortran/96910] intrinsic assignment does not duplicate allocatable component of nested derived type

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-05
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed since at least GCC7.

[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
I see no progress on this bug for over a month now.
I'd be happy to help with testing. 

Perhaps Jason is best placed to make progress on this bug.

[Bug c++/97279] GCC ignores the operation definition of the template

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Hmm, ICC also produces 2.  Not quite sure what's going on here.

[Bug c++/97197] With -O2, Incorrect -Werror=maybe-uninitialized thrown, leads to 'target_mem_ref' and 'dump_expr' in message

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

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

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

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

commit r11-3659-gac1c65ad1a16d83ec63674efa07c00b062562f15
Author: Jakub Jelinek 
Date:   Mon Oct 5 18:33:17 2020 +0200

support TARGET_MEM_REF in C/C++ error pretty-printing [PR97197]

> See my comment above for Martins attempts to improve things.  I don't
> really want to try decide what to do with those late diagnostic IL
> printing but my commit was blamed for showing target-mem-ref unsupported.
>
> I don't have much time to spend to think what to best print and what not,
> but yes, printing only the MEM_REF part is certainly imprecise.

Here is an updated version of the patch that prints TARGET_MEM_REF the way
it should be printed - as C representation of what it actually means.
Of course it would be better to have the original expressions, but with the
late diagnostics we no longer have them.

2020-10-05  Richard Biener  
Jakub Jelinek  

PR c++/97197
gcc/cp/
* error.c (dump_expr): Handle TARGET_MEM_REF.
gcc/c-family/
* c-pretty-print.c: Include langhooks.h.
(c_pretty_printer::postfix_expression): Handle TARGET_MEM_REF as
expression.
(c_pretty_printer::expression): Handle TARGET_MEM_REF as
unary_expression.
(c_pretty_printer::unary_expression): Handle TARGET_MEM_REF.

[Bug target/96835] Constructor in offload template class

[tobias.weinzierl at durham dot ac.uk via Gcc-bugs]

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

--- Comment #3 from Tobias Weinzierl  ---
The full compilation error is 

+ g++-10 -fopenmp -foffload=nvptx-none bug.cpp -o bug
ptxas /tmp/cc1XobxJ.o, line 253; error   : Illegal operand type to instruction
'ld'
ptxas /tmp/cc1XobxJ.o, line 266; error   : Label expected for argument 0 of
instruction 'call'
ptxas /tmp/cc1XobxJ.o, line 266; error   : Function '_ZN6vectorILi4EEC1ERKi'
not declared in this scope
ptxas /tmp/cc1XobxJ.o, line 266; fatal   : Call target not recognized
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-10 returned 1
exit status
compilation terminated.
lto-wrapper: fatal error:
/usr/lib/gcc/x86_64-linux-gnu/10//accel/nvptx-none/mkoffload returned 1 exit
status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

As long as the constructor is not used within the map region, the code
translates fine.

[Bug target/96835] Constructor in offload template class

[tobias.weinzierl at durham dot ac.uk via Gcc-bugs]

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

--- Comment #2 from Tobias Weinzierl  ---
#include 

#pragma omp declare target
template
struct vector {
  int values_[sz];
  vector();
  vector(int const& init_val);
  int dot(vector o) {
int res = 0;
for (int i = 0; i < sz; ++ i)
  res += values_[i] * o.values_[i];
return res;
  }
};

template
vector::vector(int const& init_val) {
  for (int i = 0; i < sz; ++ i) values_[i] = init_val;
}
template
vector::vector() : vector(0) {
}

#pragma omp end declare target

int main() {
  int res;
  #pragma omp target map(from:res)
  {
vector<4> v1(1);
vector<4> v2(2);
res = v1.dot(v2);
  }
  printf("%d\n", res);
  return 0;
}

[Bug c++/97285] Interaction between no_unique_address and has_unique_object_representations

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-05
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Sounds plausible.

[Bug target/96914] missing MVE intrinsics

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org

--- Comment #5 from avieira at gcc dot gnu.org ---
Hi Christophe,

The docs are right and so are you, those instructions should only have a signed
variant as the hardware instructions also only supports .S suffixes or in the
case of vmlaldavax do not support the cross 'X' variant with unsigned
datatypes.

[Bug sanitizer/97294] New: ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector

[paulg-b at web dot de via Gcc-bugs]

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

Bug ID: 97294
   Summary: ASAN "dynamic-stack-buffer-overflow" false positive
with OpenMP reduction to std::vector
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paulg-b at web dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 49308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49308=edit
Minimal example

When the attached minimal example is compiled with

g++ -fsanitize=address -fopenmp -o asan_omp_test asan_omp_test.cpp

and executed, ASAN reports a dynamic-stack-buffer-overflow. I tested gcc 10.2.1
and 8.2 on different systems (one being the login node of a cluster, the other
being my personal computer with a Fedora 32 OS). 

ASAN seems to report on the copy of the array-section invoked by the omp clause
reduction(+ : ptr[:v.size()])
where ptr is a copy of v.data() and v is the std::vector.

This does *not* happen when the std::vector is replaced by std::array. 

The same code does *not* report anything when compiled and ASAN-instrumented
with clang 10.0.1. I first filed a issue
https://github.com/google/sanitizers/issues/1326 and was sent here.

The problem is also *not* reproducible in C when replacing the std::vector with
dynamic memory allocated via calloc.

[Bug fortran/69090] Allocatable arrays mishandled in 'omp declare target'

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

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

--- Comment #6 from Dominique d'Humieres  ---
Should not this PR be closed?

[Bug lto/97290] Segmentation fault in lto-wrapper

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

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

--- Comment #7 from Martin Liška  ---
I've got a patch candidate for it.

[Bug c++/97293] ICE Segfault in C++20 mode

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Thanks for the report.  I think it's a dup.

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

[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||furkanusta17 at gmail dot com

--- Comment #8 from Marek Polacek  ---
*** Bug 97293 has been marked as a duplicate of this bug. ***

[Bug libgomp/97291] [SIMT] Move SIMT_XCHG_* out of non-uniform execution region

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

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

--- Comment #1 from Alexander Monakov  ---
Reshuffling statements and piling up extra abstraction doesn't help solve the
core issue that GIMPLE passes can duplicate any basic block, but basic blocks
of SIMT loop epilogue should be protected from that. More generally, arbitrary
duplication demonstrably causes miscompilation even without SIMT: PR 80053.

[Bug fortran/97070] Discrepancy in results between OpenMP/OpenACC

[venetis at ceid dot upatras.gr via Gcc-bugs]

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

--- Comment #5 from Ioannis E. Venetis  ---
I am sorry for coming back to this and for the confusion, but my previous
report of having solved the problem proved wrong.

I was getting the correct result because the code was running on the CPU, not
the GPU.

After some more experimentation and setting GOMP_DEBUG=1 I am now certain that
the code runs on the GPU, but the results are wrong for OpenACC. Hence, the
problem remains.

[Bug target/96914] missing MVE intrinsics

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

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

--- Comment #4 from Christophe Lyon  ---
(In reply to Christophe Lyon from comment #1)
> The following intrinsics are implemented, but not documented:
> __arm_vqrdmlashq_n_u8
> __arm_vqrdmlahq_n_u8
> __arm_vqdmlahq_n_u8
> __arm_vqrdmlashq_n_u16
> __arm_vqrdmlahq_n_u16
> __arm_vqdmlahq_n_u16
> __arm_vqrdmlashq_n_u32
> __arm_vqrdmlahq_n_u32
> __arm_vqdmlahq_n_u32
> __arm_vmlaldavaxq_p_u32
> __arm_vmlaldavaxq_p_u16

So, is the doc wrong (and my patch at comment #3 missing the unsigned
versions), or should I prepare a patch to remove these?

[Bug testsuite/81690] libgomp.c/{target-32,thread-limit-2}.c fail for nvptx: missing usleep

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

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

--- Comment #8 from Tom de Vries  ---
Pinged issue here (
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555496.html ).

[Bug c++/97293] New: ICE Segfault in C++20 mode

[furkanusta17 at gmail dot com via Gcc-bugs]

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

Bug ID: 97293
   Summary: ICE Segfault in C++20 mode
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: furkanusta17 at gmail dot com
  Target Milestone: ---

g++ (SUSE Linux) 10.2.1 20200825 
[revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c]


Following compiles with -std=c++17 but fails with 20

g++ -c -std=c++20 main.cpp

template 
struct receiver {
  struct type;
};

struct test {
void operator()(){}
};

template 
struct receiver::type {

  template 
  using func = test;

  void cleanup() noexcept {
func<>();
  }
};


main.cpp: In substitution of ‘template template
using func = _func [with Values = {}; Type = Type]’:
main.cpp:17:10:   required from here
main.cpp:17:10: internal compiler error: Segmentation fault
   17 | func<>();
  |  ^



Using gcc-trunk (11.0.0 20201004) in godbolt, it seems to fail with -std=c++17
as well 
https://godbolt.org/z/re7347

[Bug target/97281] Mark -march=x86-64-v[234] binaries

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-05

--- Comment #2 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #1)
> I'm not convinced it is a good idea.
> What if only some TUs or even only some functions are compiled that way and
> the app uses cpuid or cpuid based mechanisms to determine whether such code
> can or can't be called?

With glibc-hwcaps change:

https://sourceware.org/pipermail/libc-alpha/2020-October/118184.html

shared libraries under subdirectories compiled with -march=x86-64-v[234]
have no CPUID check. A command-line option to mark these libraries informs
people that these libraries can only run on processors with proper x86-64
ISA level support.

[Bug ipa/97292] New: [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054

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

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

Bug ID: 97292
   Summary: [11 Regression] dealII from SPECCPU 2016 no longer
terminates after
g:c34db4b6f8a5d80367c709309f9b00cb32630054
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-none-linux-gnu

With just -Ofast the benchmark doesn't seem to ever terminate until it is
eventually killed.

With -Ofast -flto it seems to give a runtime error.

Tweaking various params gets you one of the above behavior.

Bisected to g:c34db4b6f8a5d80367c709309f9b00cb32630054

[Bug rtl-optimization/97282] division done twice for modulo and divsion for 128-bit integers

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-10-05

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49307
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49307=edit
gcc11-pr97282.patch

Untested fix.

[Bug target/96914] missing MVE intrinsics

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

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

--- Comment #3 from Christophe Lyon  ---
Patch for vqdmlash* sent:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555497.html

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

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

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

--- Comment #8 from Dominique d'Humieres  ---
No feedback after four more years!-(

[Bug fortran/80255] Segfault from accessing class(*) component in an array of any-type-wrappers

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

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

--- Comment #2 from Dominique d'Humieres  ---
No feedback for over three years!-(

[Bug lto/97290] Segmentation fault in lto-wrapper

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Good, I can reproduce that right now. I didn't use -ffat-lto-objects, that's
why I didn't see it before.

[Bug libgomp/97212] [OpenMP] 'depend' clause with 'target nowait' (!) + 'task' does not work

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

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

--- Comment #1 from Tobias Burnus  ---
The testcase has:
  #pragma omp target map(tofrom: a, sum) depend(out: a) nowait
  #pragma omp task depend(in: a) shared(a)

and calls:
  __builtin_GOMP_target_ext
  __builtin_GOMP_task


The libgomp code has for "GOMP_task":

  if (!if_clause || team == NULL
  || (thr->task && thr->task->final_task)
  || team->task_count > 64 * team->nthreads)
...
  if ((flags & GOMP_TASK_FLAG_DEPEND)
  && thr->task && thr->task->depend_hash)
gomp_task_maybe_wait_for_dependencies (depend);
...
  else
...
  if (depend_size)
{
  gomp_task_handle_depend (task, parent, depend);
  if (task->num_dependees)
{
  /* Tasks that depend on other tasks are not put into the
 various waiting queues, so we are done for now.  Said
 tasks are instead put into the queues via
 gomp_task_run_post_handle_dependers() after their
 dependencies have been satisfied.  After which, they
 can be picked up by the various scheduling
 points.  */
  gomp_mutex_unlock (>task_lock);
  return;
}
}


For the attached code, we run into the else branch, i.e. the dependency is
analyzed – a dependency is detected but then the code just returns.

There is no call to gomp_task_run_post_handle_dependers (which is only called
by  gomp_task_run_post_handle_depend which in turn is only called by
(gomp_barrier_handle_tasks and GOMP_taskwait).

The latter are "task synchronization point = A taskwait, taskgroup, or a
barrier construct." (OpenMP glossary)

Thus, the question is whether
* either the if branch should be called instead of the else branch
* or whether some task synchronization should be done after the task.

[Bug lto/97290] Segmentation fault in lto-wrapper

[markus.rothe at rite dot cc via Gcc-bugs]

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

--- Comment #5 from Markus Rothe  ---
The spec file is available here: https://github.com/markus289/aws-sdk-cpp-rpms

But I was also able to reproduce the problem on a Fedora 32 machine without
rpm/mock/etc involved as follows:

[ Note, that this would install some files in ${HOME}/test-error/ when running
'make' as it downloads dependencies and installs them to the prefix (e.g.
aws-c-common). ]

curl -L https://github.com/aws/aws-sdk-cpp/archive/1.8.61.tar.gz|tar xz
cd aws-sdk-cpp-1.8.61 && mkdir build && cd build
CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection'
export CFLAGS
CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection'
export CXXFLAGS
FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-I/usr/lib64/gfortran/modules'
export FFLAGS
FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-I/usr/lib64/gfortran/modules'
export FCFLAGS
LDFLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' 
export LDFLAGS
LT_SYS_LIBRARY_PATH=/usr/lib64:
export LT_SYS_LIBRARY_PATH
CC=gcc
export CC
CXX=g++
export CXX
/usr/bin/cmake ../ -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=${HOME}/test-error/usr
-DINCLUDE_INSTALL_DIR:PATH=${HOME}/test-error/usr/include
-DLIB_INSTALL_DIR:PATH=${HOME}/test-error/usr/lib64
-DSYSCONF_INSTALL_DIR:PATH=${HOME}/test-error/etc
-DSHARE_INSTALL_PREFIX:PATH=${HOME}/test-error/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_DEPS:BOOL=TRUE
-DAUTORUN_UNIT_TESTS:BOOL=FALSE -DCUSTOM_MEMORY_MANAGEMENT:BOOL=FALSE
-DBUILD_ONLY=ec2
make
[...]
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Does this help? I know that the *FLAGS are quite specific to Fedora...

[Bug fortran/92350] Document non-standard namelist quote handling in gfortran

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Should not this PR be closed?

[Bug target/96914] missing MVE intrinsics

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

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

--- Comment #2 from Christophe Lyon  ---
Patch for __arm_vcvtnq_u32_f32 sent:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555485.html

[Bug fortran/97031] the content of a comment line breaks compilation

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
> This should be closed as INVALID.

I agree!

[Bug fortran/97176] Cannot return deferred length strings when using -fno-automatic

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2020-10-05
   Priority|P3  |P5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/96914] missing MVE intrinsics

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

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

--- Comment #1 from Christophe Lyon  ---
The following intrinsics are implemented, but not documented:
__arm_vqrdmlashq_n_u8
__arm_vqrdmlahq_n_u8
__arm_vqdmlahq_n_u8
__arm_vqrdmlashq_n_u16
__arm_vqrdmlahq_n_u16
__arm_vqdmlahq_n_u16
__arm_vqrdmlashq_n_u32
__arm_vqrdmlahq_n_u32
__arm_vqdmlahq_n_u32
__arm_vmlaldavaxq_p_u32
__arm_vmlaldavaxq_p_u16

[Bug lto/97290] Segmentation fault in lto-wrapper

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

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

--- Comment #4 from Martin Liška  ---
I was able to build the package in openSUSE with both DCMAKE_BUILD_TYPE=Release
and DCMAKE_BUILD_TYPE=Debug and debugging enabled (-g):

https://build.opensuse.org/package/show/Cloud:Tools/aws-sdk-cpp

[Bug libgomp/97291] New: [SIMT] Move SIMT_XCHG_* out of non-uniform execution region

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

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

Bug ID: 97291
   Summary: [SIMT] Move SIMT_XCHG_* out of non-uniform execution
region
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

We have:
...
/* Allocate per-lane storage and begin non-uniform execution region.  */

static void
expand_GOMP_SIMT_ENTER_ALLOC (internal_fn, gcall *stmt)
...
and:
...
/* Deallocate per-lane storage and leave non-uniform execution region.  */

static void
expand_GOMP_SIMT_EXIT (internal_fn, gcall *stmt)
...

So, if the SIMT_ENTER_ALLOC and the SIMT_EXIT mark the start and end of a
region of non-uniform execution, it's strange that such a region can contain
SIMT_XCHG_*, which on nvptx requires uniform execution.

Moving SIMT_VOTE_ANY/SIMT_LAST_LANE/SIMT_XCHG_* as a whole after SIMT_EXIT is
not possible given that VOTE_ANY may have data dependencies to storage that is
deallocated by SIMT_EXIT (as Alexander mentioned here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555475.html).

A possible solution would be to split the SIMT_EXIT into separate bits for
exiting non-uniform execution and deallocation, and have:
- SIMT_ENTER_ALLOC
- SIMT_EXIT_UNI
- SIMT_VOTE_ANY/SIMT_LAST_LANE/SIMT_XCHG_*
- SIMT_EXIT_DEALLOC

Also I've wondered if we could do:
- SIMT_ENTER_ALLOC
- SIMT_VOTE_ANY
- SIMT_EXIT
- SIMT_LAST_LANE/SIMT_XCHG_*
but perhaps there are again data dependency problems.

[Bug lto/97290] Segmentation fault in lto-wrapper

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

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

--- Comment #3 from Martin Liška  ---
Or you can link to a SPEC file and I can try to build it locally..

[Bug lto/97290] Segmentation fault in lto-wrapper

[markus.rothe at rite dot cc via Gcc-bugs]

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

--- Comment #2 from Markus Rothe  ---
I am writing the instructions on how the .o file is produced now.

The instructions to fetch the files are wrong. This is correct:

$ mkdir -p reproduce-tmp/CMakeFiles/aws-cpp-sdk-ec2.dir/
$ cd reproduce-tmp/
$ curl -o CMakeFiles/aws-cpp-sdk-ec2.dir/ub_EC2.cpp.o
https://files.markus289.com/aifoo3/ub_EC2.cpp.o
$ curl -o lm.res https://files.markus289.com/aifoo3/lm.res
$ mv -- lm.res -lm.res
$ tree
.
├── CMakeFiles
│   └── aws-cpp-sdk-ec2.dir
│   └── ub_EC2.cpp.o
└── lm.res

2 directories, 2 files

[Bug lto/97290] Segmentation fault in lto-wrapper

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
> 
> Could someone please continue debugging this? I would be glad to offer more
> help.

Sure, I can help you with that.

> 
> If there is need to come up with the steps that produce ub_EC2.cpp.o, then I
> would write something that one can follow.

Yes, please provide steps how the .o file is produced.

[Bug lto/97290] New: Segmentation fault in lto-wrapper

[markus.rothe at rite dot cc via Gcc-bugs]

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

Bug ID: 97290
   Summary: Segmentation fault in lto-wrapper
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.rothe at rite dot cc
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello, I get a segmentation fault when building RPMs for the AWS SDK for C++ on
Fedora 33. This version of Fedora enables LTO by default, previous versions did
not use LTO by default. So there are several layers that I had to peal apart in
order to come up with what I can show you below. I welcome any suggestions on
how to debug this problem further.

Within the cmake based build process, lto-wrapper is called and it segfaults.

To reproduce, I did the following on a Fedora 33 machine:

[ Warning, ub_EC2.cpp.o is about 700MB large. ]

$ gcc --version
gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)
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.

$ mkdir -p reproduce-tmp/CMakeFiles/aws-cpp-sdk-ec2.dir/
$ cd reproduce-tmp/
$ curl -o CMakeFiles/aws-cpp-sdk-ec2.dir/
https://files.markus289.com/aifoo3/ub_EC2.cpp.o
$ curl -o -lm.res https://files.markus289.com/aifoo3/-lm.res
$ tree
.
├── -lm.res
└── CMakeFiles
└── aws-cpp-sdk-ec2.dir
└── ub_EC2.cpp.o

2 directories, 2 files
$ gdb
[...]
(gdb) set environment COLLECT_GCC=/usr/bin/g++
(gdb) set environment
COMPILER_PATH="/usr/libexec/gcc/x86_64-redhat-linux/10/:/usr/libexec/gcc/x86_64-redhat-linux/10/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/10/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/libexec/gcc/x86_64-redhat-linux/10/:/usr/libexec/gcc/x86_64-redhat-linux/10/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/10/:/usr/lib/gcc/x86_64-redhat-linux/"
(gdb) set environment
LIBRARY_PATH="/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/../lib64/:/lib/../lib64/../lib64/:/usr/lib/../lib64/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/10/:/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/10/:/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/10/../../../:/lib/:/usr/lib/:/usr/lib/gcc/x86_64-redhat-linux/10/../../../:/lib/:/usr/lib/"
(gdb) set environment COLLECT_GCC_OPTIONS="-c -fno-openmp -fno-openacc -g -O2
-fPIC -O2 -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
-Werror=format-security -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -shared -pthread -v -save-temps
-shared-libgcc -march=x86-64 -dumpdir ./ -dumpbase libaws-cpp-sdk-ec2.so.wpa
-fltrans-output-list=libaws-cpp-sdk-ec2.so.ltrans.out -fwpa=12
-fresolution=-lm.res -flinker-output=dyn -shared-libgcc"
(gdb) file /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
Reading symbols from /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper...
Reading symbols from
/usr/lib/debug/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper-10.2.1-3.fc33.x86_64.debug...
(gdb) set args -fresolution=-lm.res -flinker-output=dyn
CMakeFiles/aws-cpp-sdk-ec2.dir/ub_EC2.cpp.o
(gdb) run
Starting program: /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
-fresolution=-lm.res -flinker-output=dyn
CMakeFiles/aws-cpp-sdk-ec2.dir/ub_EC2.cpp.o
[Detaching after vfork from child process 109]

Program received signal SIGSEGV, Segmentation fault.
0x0043b314 in simple_object_elf_copy_lto_debug_sections (sobj=0x52b740,
dobj=0x52b7d0, pfn=, err=0x7fffdbf8)
at ../../libiberty/simple-object-elf.c:1515
1515ELF_SET_FIELD (type_functions, ei_class, Sym,
(gdb) bt
#0  0x0043b314 in simple_object_elf_copy_lto_debug_sections
(sobj=0x52b740, dobj=0x52b7d0, pfn=, err=0x7fffdbf8)
at ../../libiberty/simple-object-elf.c:1515
#1  0x00439865 in simple_object_copy_lto_debug_sections (sobj=0x52b740,
dest=0x52b770 "/tmp/ccYbFOK9.debug.temp.o", 
err=0x7fffdbf8, rename=1) at ../../libiberty/simple-object.c:352
#2  0x004562c7 in debug_objcopy (infile=,
rename=rename@entry=true) at ../../gcc/lto-wrapper.c:1127
#3  0x0045857f in run_gcc (argc=, argv=)
at ../../gcc/lto-wrapper.c:1736
#4  0x0043e577 in main (argc=, argv=) at
../../gcc/lto-wrapper.c:1998
(gdb)


The error happens in the following line of code in
libiberty/simple-object-elf.c:1515:

ELF_SET_FIELD (type_functions, ei_class, Sym, ent, 

[Bug c++/97198] __is_constructible(int[], int) should return true

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

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

--- Comment #4 from Jonathan Wakely  ---
This is now https://wg21.link/lwg3486

[Bug target/97281] Mark -march=x86-64-v[234] binaries

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'm not convinced it is a good idea.
What if only some TUs or even only some functions are compiled that way and the
app uses cpuid or cpuid based mechanisms to determine whether such code can or
can't be called?

[Bug rtl-optimization/97282] division done twice for modulo and divsion for 128-bit integers

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
We have the divmod discovery in tree-ssa-math-opts.c and it will handle this
case if the division/modulo is by the same variable.  But for constants it
punts:
  /* Disable the transform if either is a constant, since division-by-constant
 may have specialized expansion.  */
  if (CONSTANT_CLASS_P (op1) || CONSTANT_CLASS_P (op2))
return false;

So, perhaps we want to get it through if CONSTANT_CLASS_P (op2) (but not op1)
and
some further conditions are met, e.g. that op2 is not a power of two, and
either the type's precision is > HOST_BITS_PER_WIDE_INT (then expand_divmod
punts on it), as choose_multiplier etc. work on HOST_WIDE_INTs), or compute
choose_multiplier for the constant divisor and if pre or post shift needs to be
BITS_PER_WORD or more bits.
Or optimize into DIVMOD always even for constant op2 and when trying to expand
DIVMOD ifn with constant op2, see if the target can expand division by that
constant using just shifts and +/- and if so, emit it as that division +
subtraction, otherwise throw away the division expansion and emit a divmod.

[Bug libstdc++/91486] future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration

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

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

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

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

commit r11-3653-gf33a43f9f7eab7482837662821abb7fd02cb4350
Author: Mike Crowe 
Date:   Mon Oct 5 11:12:38 2020 +0100

libstdc++: Use correct duration for atomic_futex wait on custom clock [PR
91486]

As Jonathan Wakely pointed out[1], my change in commit
f9ddb696a289cc48d24d3d23c0b324cb88de9573 should have been rounding to
the target clock duration type rather than the input clock duration type
in __atomic_futex_unsigned::_M_load_when_equal_until just as (e.g.)
condition_variable does.

As well as fixing this, let's create a rather contrived test that fails
with the previous code, but unfortunately only when run on a machine
with an uptime of over 208.5 days, and even then not always.

[1] https://gcc.gnu.org/pipermail/libstdc++/2020-September/051004.html

libstdc++-v3/ChangeLog:

PR libstdc++/91486
* include/bits/atomic_futex.h:
(__atomic_futex_unsigned::_M_load_when_equal_until): Use target
clock duration type when rounding.
* testsuite/30_threads/async/async.cc (test_pr91486_wait_for):
Rename from test_pr91486.
(float_steady_clock): New class for test.
(test_pr91486_wait_until): New test.

[Bug target/97286] GCC sometimes uses an extra xmm register for the destination of _mm_blend_ps

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
We have:
(insn 17 15 19 4 (set (reg:V4SF 92)
(vec_merge:V4SF (mem:V4SF (plus:DI (reg/v/f:DI 88 [ in ])
(reg:DI 87 [ ivtmp.15 ])) [0 MEM[(const __m128i_u *
{ref-all})in_7(D) + ivtmp.15_30 * 1]+0 S16 A8])
(subreg:V4SF (reg/v:V2DI 91 [ a ]) 0)
(const_int 5 [0x5]))) "include/smmintrin.h":193:19 4587
{sse4_1_blendps}
 (expr_list:REG_DEAD (reg/v:V2DI 91 [ a ])
(nil)))
(insn 19 17 20 4 (set (reg/v:V2DI 91 [ a ])
(subreg:V2DI (reg:V4SF 92) 0)) "pr97286.c":5:11 1405 {movv2di_internal}
 (nil))
in the loop (plus pseudo 91 setter before the loop and pseudo 92 store in the
loop).
There are no conflicts:
;; a4(r91,l0) conflicts: a15(r92,l0)
;; total conflict hard regs:
;; conflict hard regs:
so it is unclear why IRA doesn't prefer putting it into the same register. 
Maybe the subregs are the reason and if there weren't any, it would do it?

[Bug middle-end/97289] [11 Regression] ICE in get, at cgraph.h:446

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 49306
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49306=edit
gcc11-pr97289.patch

Untested fix.

[Bug libstdc++/93542] std::future::wait_for should use monotonic clock

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

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

--- Comment #4 from Jonathan Wakely  ---
Thanks, Mike. I've added the PR number to the ChangeLog file in
g:b98d3cc5666f36bf3cbeed7cd6a23483cc5e4eca

[Bug middle-end/97289] [11 Regression] ICE in get, at cgraph.h:446

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Last reconfirmed||2020-10-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97273
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-05

[Bug fortran/97209] TODO: building array references needs a big tidy up

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

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

Paul Thomas  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-05
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  ---
Manifestly confirmed :-)

Paul

[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

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

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

--- Comment #4 from Tom de Vries  ---
I did a libgomp test run with commit f96b6328fa7 "[tree-optimization] Don't
clear ctrl-altering flag for IFN_UNIQUE" reverted, and with this patch:
...
diff --git a/gcc/tracer.c b/gcc/tracer.c
index 0f69b335b8c..3a4403d92b1 100644
--- a/gcc/tracer.c
+++ b/gcc/tracer.c
@@ -93,11 +93,15 @@ can_duplicate_insn_p (gimple *g)
  The IFN_GOMP_SIMT_VOTE_ANY is currently part of such a group,
  so the same holds there, but it could be argued that the
  IFN_GOMP_SIMT_VOTE_ANY could be generated after that group,
- in which case it could be duplicated.  */
+ in which case it could be duplicated.
+ An IFN_UNIQUE call must be duplicated as part of its group,
+ or not at all.  */
   if (is_gimple_call (g)
   && (gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
  || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
- || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)))
+ || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)
+ || (gimple_call_internal_p (g)
+ && gimple_call_internal_unique_p (g
 return false;

   return true;
@@ -117,8 +121,6 @@ can_duplicate_bb_no_insn_iter_p (const_basic_block bb)
   if (gimple_code (g) == GIMPLE_TRANSACTION)
return false;

-  /* An IFN_UNIQUE call must be duplicated as part of its group,
-or not at all.  */
   if (is_gimple_call (g)
  && gimple_call_internal_p (g)
  && gimple_call_internal_unique_p (g))
...

No issues found.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

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

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

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

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

commit r10-8851-gcd547f0ddcd3a54e5b73bcda5ac0f0c46808db8b
Author: Jakub Jelinek 
Date:   Sat Sep 26 10:07:41 2020 +0200

powerpc, libcpp: Fix gcc build with clang on power8 [PR97163]

libcpp has two specialized altivec implementations of search_line_fast,
one for power8+ and the other one otherwise.
Both use __attribute__((altivec(vector))) and the GCC builtins rather than
altivec.h and the APIs from there, which is fine, but should be restricted
to when libcpp is built with GCC, so that it can be relied on.
The second elif is
and thus e.g. when built with clang it isn't picked, but the first one was
just guarded with
and so according to the bugreporter clang fails miserably on that.

The following patch fixes that by adding the same GCC_VERSION requirement
as the second version.  I don't know where the 4.5 in there comes from and
the exact version doesn't matter that much, as long as it is above 4.2 that
clang pretends to be and smaller or equal to 4.8 as the oldest gcc we
support as bootstrap compiler ATM.
Furthermore, the patch fixes the comment, the version it is talking about
is
not pre-GCC 5, but actually the GCC 5+ one.

2020-09-26  Jakub Jelinek  

PR bootstrap/97163
* lex.c (search_line_fast): Only use _ARCH_PWR8 Altivec version
for GCC >= 4.5.

(cherry picked from commit d00b1b023ecfc3ddc3fe952c0063dab7529d5f7a)

[Bug c++/97145] Sanitizer pointer-subtract breaks constexpr functions subtracting pointers

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:3f56563cf84f97ef271ef0f949a571c13cdd06e2

commit r10-8850-g3f56563cf84f97ef271ef0f949a571c13cdd06e2
Author: Jakub Jelinek 
Date:   Tue Sep 22 21:06:32 2020 +0200

c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant
expression evaluation [PR97145]

These two builtin calls are added already during parsing before pointer
subtractions or comparisons, normally they perform runtime verification
of whether the pointers point to the same object or different objects,
but during constant expressione valuation we don't really need those
builtins for anything.

2020-09-22  Jakub Jelinek  

PR c++/97145
* constexpr.c (cxx_eval_builtin_function_call): Return void_node
for
calls to __sanitize_ptr_{sub,cmp} builtins.

* g++.dg/asan/pr97145.C: New test.

(cherry picked from commit bc13106e0414b86af8f6878e7681e6a959921b9e)

[Bug c++/97195] construct_at on a union member is not a constant expression

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

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

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

https://gcc.gnu.org/g:355b42c5d9d58d266829d2e44528f7a5ca0eae37

commit r10-8852-g355b42c5d9d58d266829d2e44528f7a5ca0eae37
Author: Jakub Jelinek 
Date:   Thu Oct 1 11:16:44 2020 +0200

c++: Handle std::construct_at on automatic vars during constant evaluation
[PR97195]

As mentioned in the PR, we only support due to a bug in constant
expressions
std::construct_at on non-automatic variables, because we VERIFY_CONSTANT
the
second argument of placement new, which fails verification if it is an
address of an automatic variable.
The following patch fixes it by not performing that verification, the
placement new evaluation later on will verify it after it is dereferenced.

2020-10-01  Jakub Jelinek  

PR c++/97195
* constexpr.c (cxx_eval_call_expression): Don't VERIFY_CONSTANT the
second argument.

* g++.dg/cpp2a/constexpr-new14.C: New test.

(cherry picked from commit 2805fcb32660bc0cdcd5ba54310f1f02651e039f)

[Bug c++/96994] Missing code from consteval constructor initializing const variable

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

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

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

https://gcc.gnu.org/g:2513dad670c00dd9db3a85be348f6f4020b18b81

commit r10-8853-g2513dad670c00dd9db3a85be348f6f4020b18b81
Author: Jakub Jelinek 
Date:   Thu Oct 1 11:18:35 2020 +0200

c++: Fix up default initialization with consteval default ctor [PR96994]

> > The following testcase is miscompiled (in particular the a and i
> > initialization).  The problem is that build_special_member_call due to
> > the immediate constructors (but not evaluated in constant expression
mode)
> > doesn't create a CALL_EXPR, but returns a TARGET_EXPR with CONSTRUCTOR
> > as the initializer for it,
>
> That seems like the bug; at the end of build_over_call, after you
>
> >call = cxx_constant_value (call, obj_arg);
>
> You need to build an INIT_EXPR if obj_arg isn't a dummy.

That works.  obj_arg is NULL if it is a dummy from the earlier code.

2020-10-01  Jakub Jelinek  

PR c++/96994
* call.c (build_over_call): If obj_arg is non-NULL, return
INIT_EXPR
setting obj_arg to call.

* g++.dg/cpp2a/consteval18.C: New test.

(cherry picked from commit 56da736cc6ced0f1c339744321a14ae569db8606)

[Bug target/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

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

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

--- Comment #9 from Alex Coplan  ---
So the plan is to fix this with a patch to combine. Waiting on a review from
Segher for https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555158.html

[Bug rtl-optimization/97275] Linux kernel cgroup.c internal compiler error (ICE).

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #2 from Alex Coplan  ---
Dup.

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

[Bug target/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||dr.duncan.p.simpson at gmail 
dot c
   ||om

--- Comment #8 from Alex Coplan  ---
*** Bug 97275 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/97289] New: [11 Regression] ICE in get, at cgraph.h:446

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 97289
   Summary: [11 Regression] ICE in get, at cgraph.h:446
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, openmp
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20201004 snapshot (g:35d2c6b6e8a7448a84abbf967feeb78a29117014)
ICEs when compiling the following testcase, reduced from
test/OpenMP/declare_target_codegen.cpp from the clang 10.0.1 test suite, w/
-fopenmp:

void
cq (void);

static __typeof (cq) gb __attribute__ ((__weakref__ ("cq")));

void *
z9 (void)
{
#pragma omp target
  return gb;
}

% gcc-11.0.0 -fopenmp -c exaknu0q.c
cc1: internal compiler error: in get, at cgraph.h:446
0x67f3cc symtab_node::get(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/cgraph.h:446
0x67f7d7 symtab_node::get(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/tree.h:3417
0x67f7d7 omp_discover_declare_target_tgt_fn_r
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/omp-offload.c:203
0x108937a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/tree.c:12001
0x108d03a walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/tree.c:12362
0xc5508d omp_discover_declare_target_fn_r
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/omp-offload.c:266
0x108937a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/tree.c:12001
0x108d03a walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/tree.c:12362
0xc57c43 omp_discover_implicit_declare_target()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/omp-offload.c:358
0x96acf9 analyze_functions
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/cgraphunit.c:1169
0x96aead symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201004/work/gcc-11-20201004/gcc/cgraphunit.c:2995

[Bug tree-optimization/97159] [11 Regression] segfault in modref_may_conflict

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

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

--- Comment #4 from Tom de Vries  ---
I'm currently not running into this ICE anymore, so presumably it was fixed.

I'm not sure by which commit though.

[Bug fortran/97272] Wrong answer from MAXLOC with character arg

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Bill Long from comment #5)
> The original intent of adding the KIND argument was because some
> implementations used a 32-bit integer for the result, and it is possible for
> the answer to be larger than 2**31-1.  Just checking to be sure that the
> underlying library code returns a 64-bit integer that can later be converted
> based on the KIND value.

Did you try?  It's not exactly fast, but

program test
  implicit none
  integer(8) :: k, l = 10 + 2_8**32
  character, allocatable :: a(:)
  allocate (a(l))
  print *, l
  a(:) = 'a'
  l = l - 1
  a(l) = 'b'
  print *, l
  print *, size (a, kind=8)
  k = maxloc (a, dim=1, kind=8, back=.true.)
 print *, 'k = ', k, 'a(k) = ', a(k)
end

works for me on master now on a 64-bit platform:

   4294967306
   4294967305
   4294967306
 k =4294967305 a(k) = b

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

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

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

Tom de Vries  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #17 from Tom de Vries  ---
Patch with test-case committed, marking resolved-fixed.

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r11-3648-gab3f4b27abe8abc947e84ef84bfc9a18797c5868
Author: Tom de Vries 
Date:   Tue Sep 22 16:38:07 2020 +0200

[omp, ftracer] Don't duplicate blocks in SIMT region

When running the libgomp testsuite on x86_64-linux with nvptx accelerator
on
the test-case included in this patch, we run into:
...
FAIL: libgomp.fortran/pr95654.f90 -O3 -fomit-frame-pointer -funroll-loops \
  -fpeel-loops -ftracer -finline-functions  execution test
...

The test-case is a minimal version of this FAIL:
...
FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops
\
  -fpeel-loops -ftracer -finline-functions  execution test
...
but that one has stopped failing at commit c2ebf4f10de "openmp: Add support
for non-rect simd and improve collapsed simd support".

The problem is that ftracer duplicates a block containing
GOMP_SIMT_VOTE_ANY.

That is, before ftracer we have (dropping the GOMP_SIMT_ prefix):
...
bb4(ENTER_ALLOC)
*--+
|   \
|\
| v
| *
v bb8
*<*
bb5(VOTE_ANY)
*-+
| |
| |
| |
| |
| v
| *
v bb7(XCHG_IDX)
*<*
bb6(EXIT)
...

The XCHG_IDX internal-fn does inter-SIMT-lane communication, which for
nvptx
maps onto shfl, an operator which has the requirement that the warp
executing
the operator is convergent.  The warp diverges at bb4, and
reconverges at bb5, and does not diverge by going to bb7, so the shfl is
indeed executed by a convergent warp.

After ftracer, we have:
...
bb4(ENTER_ALLOC)
*--+
|   \
|\
| \
|  \
v   v
*   *
bb5(VOTE_ANY)   bb8(VOTE_ANY)
*   *
|\ /|
| \  ++ |
|  \/   |
|  /\   |
| /  +--v
|/  *
v   bb7(XCHG_IDX)
*<--*
bb6(EXIT)
...

The warp diverges again at bb5, but does not reconverge again before bb6,
so
the shfl is executed by a divergent warp, which causes the FAIL.

Fix this by making ftracer ignore blocks containing ENTER_ALLOC, VOTE_ANY
and
EXIT, effectively treating the SIMT region conservatively.

An argument can be made that the test needs to be added in a more
generic place, like gimple_can_duplicate_bb_p or some such, and that
ftracer
then needs to use the generic test.  But that's a discussion with a much
broader scope, so I'm leaving that for another patch.

Bootstrapped and reg-tested on x86_64-linux.

Build on x86_64-linux with nvptx accelerator, tested with libgomp.

gcc/ChangeLog:

PR fortran/95654
* tracer.c (ignore_bb_p): Ignore GOMP_SIMT_ENTER_ALLOC,
GOMP_SIMT_VOTE_ANY and GOMP_SIMT_EXIT.

libgomp/ChangeLog:

2020-10-05  Tom de Vries  

PR fortran/95654
* testsuite/libgomp.fortran/pr95654.f90: New test.

[Bug c++/97284] internal compiler error: 'global_options' are modified in local context

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-10-05

--- Comment #1 from Martin Liška  ---
Please provide a pre-processed soure file (-E option).