[Bug middle-end/83004] [8 regression] gcc.dg/vect/pr81136.c fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/83007] [8 Regression] -Wstringop-overflow false positive

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c/82963] -Waddress too trigger happy

[mhocko at kernel dot org]

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

--- Comment #3 from Michal Hocko  ---
(In reply to Manuel López-Ibáñez from comment #2)
[...]
> > Moreover the warning itself is quite inconsistent. E.g. the following warns
> > about the explicit &m but not for n. So I believe this is more of a
> > suboptimal warning implementation than real intention.
> 
> This is because the warning is given in the front-end, which does not know
> the value of n. Not that it matters much, this is really trying to catch a
> typo, not the actual value of a pointer.

Would it be possible to skip the warning for macros at least?

[Bug fortran/83012] [8 Regression] Simply contiguous pointer function not recognized as contiguous

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-16
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Target Milestone|--- |8.0
Summary|Simply contiguous pointer   |[8 Regression] Simply
   |function not recognized as  |contiguous pointer function
   |contiguous  |not recognized as
   ||contiguous
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
This was probably me. Apparently, the test for simply contiguous
does not catch this case.

I'll take a look.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-* i?86-*-*
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
The strange code is because we perform basic-block vectorization resulting in

  vect_cst__249 = {_251, _251, _251, _251, _334, _334, _334, _334, _417, _417,
_417, _417, _48, _48, _48, _48};
  MEM[(unsigned int *)&tmp] = vect_cst__249;
  _186 = tmp[0][0];
  _185 = tmp[1][0];
...

which for some reason is deemed profitable:

t.c:32:12: note: Cost model analysis:
  Vector inside of basic block cost: 24
  Vector prologue cost: 64
  Vector epilogue cost: 0
  Scalar cost of basic block: 192
t.c:32:12: note: Basic block will be vectorized using SLP

what is odd is that the single vector store is costed 24 while the 16 scalar
int stores are costed 192.  The vector build from scalar costs 64.

I guess Honzas cost-model tweaks might have gone wrong here or we're hitting an
oddity in the SLP costing.

Even if it looks strange maybe the sequence _is_ profitable?

The second loop would be vectorized if 'sum' was unsigned.

[Bug sanitizer/83014] New: ICE in pretty-print with -fsanitize=bounds

[ghjghj530-bubu at yahoo dot de]

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

Bug ID: 83014
   Summary: ICE in pretty-print with -fsanitize=bounds
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ghjghj530-bubu at yahoo 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: ---

Compiling the following testcode leads to an internal compiler error

int setArrayElemment()
{
int data[5];
data[5] = 0;
return data[0];
}
int main()
{
}

Compile with GCC 6.3 or 5.3
gcc.exe C:\temp\test.cpp -c -fsanitize=bounds
or
gcc.exe C:\temp\test.cpp -c -fsanitize=undefined

Leads to:

c:\temp\test.cpp: In function 'int setArrayElemment()':
c:\temp\test.cpp:1:5: internal compiler error: in pp_format, at
pretty-print.c:630
 int setArrayElemment()
 ^~~~

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

c:\temp\test.cpp:1:5: internal compiler error: Aborted

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[Bug bootstrap/83015] New: [8 regression] bootstrap comparison failure on ia64

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

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

Bug ID: 83015
   Summary: [8 regression] bootstrap comparison failure on ia64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: hubicka at ucw dot cz
  Target Milestone: ---
Target: ia64-*-*

ia64 fails to bootstrap since r254636.

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/ipa-icf.o differs
gcc/tree-sra.o differs
gcc/cp/name-lookup.o differs
gcc/cp/tree.o differs
gcc/cp/pt.o differs
gcc/cp/constexpr.o differs
gcc/cp/cp-gimplify.o differs
gcc/cp/cxx-pretty-print.o differs
gcc/cp/cp-objcp-common.o differs
gcc/cp/parser.o differs
gcc/var-tracking.o differs
gcc/tree-vect-generic.o differs
gcc/tree-vect-stmts.o differs
gcc/go/expressions.o differs
gcc/go/statements.o differs
gcc/go/types.o differs
gcc/cfgbuild.o differs
gcc/tree-chkp.o differs
gcc/function.o differs
gcc/tree-ssa-sccvn.o differs
gcc/fold-const.o differs
gcc/emit-rtl.o differs
gcc/tree-ssa-uninit.o differs
gcc/lto/lto.o differs
gcc/tree-vrp.o differs
gcc/ipa-fnsummary.o differs
gcc/tree.o differs
gcc/tree-data-ref.o differs
gcc/fibonacci_heap.o differs
gcc/tree-into-ssa.o differs
gcc/gcov.o differs
gcc/tree-ssa-loop-im.o differs
gcc/varasm.o differs
gcc/tree-eh.o differs
gcc/builtins.o differs
gcc/tree-vect-slp.o differs
gcc/tree-ssa-reassoc.o differs
gcc/tree-switch-conversion.o differs
gcc/c/c-parser.o differs
gcc/objcp/objc-next-runtime-abi-02.o differs
gcc/loop-unroll.o differs
gcc/tree-inline.o differs
gcc/tree-cfg.o differs
gcc/omp-low.o differs
gcc/tree-if-conv.o differs
gcc/dse.o differs
gcc/trans-mem.o differs
gcc/except.o differs
gcc/cfgexpand.o differs
gcc/tree-vect-patterns.o differs
gcc/hsa-gen.o differs
gcc/gimple-fold.o differs
gcc/tree-nested.o differs
gcc/ipa-cp.o differs
gcc/simplify-rtx.o differs
gcc/ipa-devirt.o differs
gcc/tree-vect-loop.o differs
gcc/graphite-isl-ast-to-gimple.o differs
gcc/objc/objc-next-runtime-abi-02.o differs
gcc/tree-vect-data-refs.o differs
gcc/gimple-match.o differs
gcc/tree-ssa-loop-prefetch.o differs
gcc/ipa-prop.o differs
gcc/tree-tailcall.o differs
gcc/passes.o differs
gcc/multiple_target.o differs
gcc/predict.o differs
gcc/dwarf2out.o differs
gcc/tree-ssa-loop-niter.o differs

$ diff -u <(nm stage{2,3}-gcc/tree-ssa.o)
--- /dev/fd/63  2017-11-12 12:13:17.607494656 +0100
+++ /dev/fd/62  2017-11-12 12:13:17.607494656 +0100
@@ -131,9 +131,9 @@
 03b0 t _ZL15gimple_call_argPK6gimplej.part.69
 09c0 t _ZL15verify_ssa_nameP9tree_nodeb
 04d0 t _ZL16op_iter_init_defP11ssa_op_iterP6gimplei.part.76
-1ec0 t _ZL16op_iter_next_defP11ssa_op_iter
+1a80 t _ZL16op_iter_next_defP11ssa_op_iter
 05e0 t _ZL17gimple_assign_lhsPK6gimple.part.85
-1a80 t _ZL17op_iter_next_treeP11ssa_op_iter
+1e40 t _ZL17op_iter_next_treeP11ssa_op_iter
 0470 t
_ZL18first_imm_use_stmtP16imm_use_iteratorP9tree_node.part.75
 0580 t _ZL18gimple_assign_rhs1PK6gimple.part.83
 0ec0 t _ZL18maybe_optimize_varP9tree_nodeP11bitmap_headS2_S2_

[Bug driver/83016] New: gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[aldot at gcc dot gnu.org]

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

Bug ID: 83016
   Summary: gnat1: warning: command line option ‘-nostdinc++’ is
valid for C++/ObjC++ but not for Ada
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
CC: charlet at adacore dot com, derodat at adacore dot com,
ebotcazou at libertysurf dot fr
  Target Milestone: ---

When bootstrapping trunk @253865 (for example, IIRC occurs since quite some
time now):

xg++ -c -gnatA -gnatWb -gnatiw -B/scratch/obj.x86_64/gcc-8.0.mine/./gcc/
-nostdinc++ -nostdinc++
-I/scratch/obj.x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/scratch/obj.x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/scratch/src/gcc-8.0.mine/libstdc++-v3/libsupc++
-I/scratch/src/gcc-8.0.mine/libstdc++-v3/include/backward
-I/scratch/src/gcc-8.0.mine/libstdc++-v3/testsuite/util
-B/scratch/obj.x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/scratch/obj.x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/bin/
-B/opt/x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/lib/ -isystem
/opt/x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/include -isystem
/opt/x86_64/gcc-8.0.mine/x86_64-pc-linux-gnu/sys-include -static-libstdc++
-static-libgcc -I- -I../rts -I. -I/scratch/src/gcc-8.0.mine/gcc/ada
-static-libstdc++ -static-libgcc -gnatws
/scratch/obj.x86_64/gcc-8.0.mine/gcc/ada/tools/b~gnatcmd.adb
gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but
not for Ada

ISTM the driver should filter out -nostdinc++ for ADA (or gnat1 should silently
ignore it)

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-16
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce on linux. Can you please add '--verbose' flag?
Can you please attach output (pre-processed source filE) of -E?

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[ghjghj530-bubu at yahoo dot de]

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

--- Comment #2 from ghjghj530-bubu at yahoo dot de ---
Thanks for your quick response:

Compiling with --verbose:

Using built-in specs.
COLLECT_GCC=i686-elf-gcc.exe
Target: i686-elf
Configured with: ../gcc-6.3.0/configure --prefix=/opt/V6.3.0 --target=i686-elf
--with-pic --with-newlib --enable-languag
ray --disable-nls --disable-shared --disable-multilib --disable-threads
--disable-tls --disable-win32-registry --enable-
-pointer --disable-__cxa_atexit --disable-libgomp --disable-libquadmath
--disable-libssp --disable-libada --disable-libi
 --disable-libstdcxx-visibility --with-default-libstdcxx-abi=gcc4-compatible
--without-headers : (reconfigured) ../gcc-6
6.3.0 --target=i686-elf --with-pic --with-newlib --enable-languages=c,c++
--disable-initfini-array --disable-nls --disab
-disable-threads --disable-tls --disable-win32-registry
--enable-sjlj-exceptions --enable-frame-pointer --disable-__cxa_
able-libquadmath --disable-libssp --disable-libada --disable-libitm
--disable-libstdcxx-verbose --disable-libstdcxx-visi
x-abi=gcc4-compatible --with-headers
Thread model: single
gcc version 6.3.0 (GCC)
COLLECT_GCC_OPTIONS='-c' '-fsanitize=undefined' '-v' '-mtune=generic'
'-march=pentiumpro'
 C:/gnuinst/v6.3.0/bin/../libexec/gcc/i686-elf/6.3.0/cc1plus.exe -quiet -v
-iprefix c:
k\as\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/ c:\temp\test.cpp -quiet
-dumpbase test.cpp -mtune=generic -march=pent
-fsanitize=undefined -o C:\Users\grosst\AppData\Local\Temp\ccVWHL7C.s
GNU C++14 (GCC) version 6.3.0 (i686-elf)
compiled by GNU C version 5.3.0, GMP version 5.1.2, MPFR version 3.1.2,
MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"C:\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/../../
ignoring duplicate directory
"C:/gnuinst/v6.3.0/lib/gcc/../../lib/gcc/i686-elf/6.3.0/.
+/6.3.0"
ignoring duplicate directory
"C:/gnuinst/v6.3.0/lib/gcc/../../lib/gcc/i686-elf/6.3.0/.
+/6.3.0/i686-elf"
ignoring duplicate directory
"C:/gnuinst/v6.3.0/lib/gcc/../../lib/gcc/i686-elf/6.3.0/.
+/6.3.0/backward"
ignoring duplicate directory
"C:/gnuinst/v6.3.0/lib/gcc/../../lib/gcc/i686-elf/6.3.0/i
ignoring duplicate directory
"C:/gnuinst/v6.3.0/lib/gcc/../../lib/gcc/i686-elf/6.3.0/i
ignoring nonexistent directory
"C:/gnuinst/v6.3.0/lib/gcc/../../lib/gcc/i686-elf/6.3.0
ude"
ignoring duplicate directory
"C:/gnuinst/v6.3.0/lib/gcc/../../lib/gcc/i686-elf/6.3.0/.
#include "..." search starts here:
#include <...> search starts here:

C:\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/../../../../i686-elf/include/c++/6.3.

C:\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/../../../../i686-elf/include/c++/6.3.

C:\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/../../../../i686-elf/include/c++/6.3.
 C:\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/include
 C:\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/include-fixed
 C:\gnuinst\v6.3.0\bin\../lib/gcc/i686-elf/6.3.0/../../../../i686-elf/include
End of search list.
GNU C++14 (GCC) version 6.3.0 (i686-elf)
compiled by GNU C version 5.3.0, GMP version 5.1.2, MPFR version 3.1.2,
MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b10cc2d805285f11263a2d3a4a7dce91
c:\temp\test.cpp: In function 'int setArrayElemment()':
c:\temp\test.cpp:1:5: internal compiler error: in pp_format, at
pretty-print.c:630
 int setArrayElemment()
 ^~~~

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

c:\temp\test.cpp:1:5: internal compiler error: Aborted

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
i686-elf-gcc.exe: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compiling with -E:

# 1 "c:\\temp\\test.cpp"
# 1 ""
# 1 ""
# 1 "c:\\temp\\test.cpp"
int setArrayElemment()
{
 int data[5];
 data[5] = 0;
 return data[0];
}
int main()
{
}

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Ok, so it's i686 target. What operation system is that?

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
And can you please run it in debugger in order to display back-trace?

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[derodat at adacore dot com]

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

--- Comment #1 from Pierre-Marie de Rodat  ---
I can’t reproduce with “--enable-languages=c,c++,ada --disable-multilib
--disable-libsanitizer” on trunk r254797. Do you use specific options?

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[ghjghj530-bubu at yahoo dot de]

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

--- Comment #5 from ghjghj530-bubu at yahoo dot de ---
The OS is Windows 7, 64-bit.

Unfortunately i don't use the debug-version of GCC and can therefore not
provide a detailed backtrace right now. Maybe next week.

Note that my original message contains at least the error position "pp_format,
at pretty-print.c:630"

The problems also occurs with this version of GCC:

Target: mingw32
Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu
--host=m
ingw32 --prefix=/mingw --disable-win32-registry --target=mingw32
--with-arch=i58
6 --enable-languages=c,c++,objc,obj-c++,fortran,ada --enable-static
--enable-sha
red --enable-threads --with-dwarf2 --disable-sjlj-exceptions
--enable-version-sp
ecific-runtime-libs --with-libintl-prefix=/mingw --enable-libstdcxx-debug
--with
-tune=generic --enable-libgomp --disable-libvtv --enable-nls : (reconfigured)
..
/src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32
--prefix=/mi
ngw --disable-win32-registry --target=mingw32 --with-arch=i586
--enable-language
s=c,c++,objc,obj-c++,fortran,ada --enable-static --enable-shared
--enable-thread
s --with-dwarf2 --disable-sjlj-exceptions
--enable-version-specific-runtime-libs
 --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw
--enable-libstdcxx-d
ebug --with-tune=generic --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 5.3.0 (GCC)

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[aldot at gcc dot gnu.org]

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

--- Comment #2 from Bernhard Reutner-Fischer  ---
../../src/gcc-8.0.mine/configure \  
-v \
--enable-languages=c,fortran,c++,go,objc,obj-c++,lto,ada \  
CFLAGS='-O0 -g3 -ggdb3 ' \  
CXXFLAGS='-O0 -g3 -ggdb3 ' \
'BOOT_CFLAGS=-O0 -g3 -ggdb3 ' \ 
'BOOT_CXXFLAGS=-O0 -g3 -ggdb3 ' \   
'CFLAGS_FOR_TARGET=-O0 -g3 -ggdb3 ' \   
'CXXFLAGS_FOR_TARGET=-O0 -g3 -ggdb3 ' \ 
--prefix=/opt/x86_64/gcc-8.0.mine// \   
--enable-shared \   
--without-system-zlib \ 
--enable-nls \  
--without-included-gettext \
--enable-threads=posix \
--enable-__cxa_atexit \ 
--enable-libstdcxx-allocator=mt \   
--enable-clocale=gnu \  
--enable-libstdcxx-debug \  
--enable-mpfr \ 
--disable-werror \  
--enable-checking=yes \ 
--enable-debug \
-C \
--disable-intermodule \ 
--enable-multilib \ 
--disable-libstdcxx-pch \   
--enable-bootstrap \
--enable-checking=yes \ 
--with-cpu=native \ 
--with-tune=native \
--enable-plugin
make bootstrap

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-16
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
I am trying to reproduce it - so far I have learnt that compile farm computer
listed as itanium is not, so bootstrap passed there.

[Bug c++/70383] Bogus error when attempting to capture a reference to function by copy

[paolo at gcc dot gnu.org]

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

--- Comment #1 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Nov 16 10:36:51 2017
New Revision: 254808

URL: https://gcc.gnu.org/viewcvs?rev=254808&root=gcc&view=rev
Log:
2017-11-16  Paolo Carlini  

PR c++/70383
* g++.dg/cpp0x/lambda/lambda-70383.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70383.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/70383] Bogus error when attempting to capture a reference to function by copy

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Fixed by the patch which fixed c++/81574.

[Bug fortran/83017] New: DO CONCURRENT not parallelizing

[cfztol at hotmail dot com]

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

Bug ID: 83017
   Summary: DO CONCURRENT not parallelizing
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cfztol at hotmail dot com
  Target Milestone: ---

I found a strange behaviour, which I think is a bug. I'm trying to split a loop
with DO CONCURRENT and compile flag -ftree-parallelize-loops=2 . However,
whether parallelization actually happens depends on whether I use a computed
vector index in an assignment or a constant index. The indexing happens inside
a pure function, so I believe that should not affect the outer do concurrent
loop (?)

Here's my test code

! compile: 
!   gfortran -Ofast -march=native -ftree-parallelize-loops=2 -o main main.f90
! run;
!   time ./main
program main
use, intrinsic :: iso_fortran_env
implicit none

integer, parameter :: nsplit = 4
integer(int64), parameter :: ne = 20
integer(int64) :: stride, low(nsplit), high(nsplit), i
real, dimension(nsplit) :: pi

stride = ceiling(real(ne)/nsplit)
do i = 1, nsplit
high(i) = stride*i
end do
do i = 2, nsplit
low(i) = high(i-1) + 1
end do
low(1) = 1
high(nsplit) = ne

pi = 0
do concurrent (i = 1:nsplit)
pi(i) = sum(compute( low(i), high(i) ))
end do
print *, "PI", 4*sum(pi)
print *, "PI", 4*atan(1.0)

contains

pure function compute( low, high ) result( tmp )
integer(int64), intent(in) :: low, high
real, dimension(nsplit) :: tmp
integer(int64) :: j, k

tmp = 0

! With this loop no parallelization happens
do j = low, high
k = mod( j, nsplit ) + 1
tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 )   
end do

! With this loop the code is parallelized (apparent from time study)
! do j = low, high, 4 ! nsplit is equal to 4
! k = 1
! tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 ) 
! k = 2
! tmp(k) = tmp(k) + (-1)**(j+2) / real( 2*j+1 ) 
! k = 3
! tmp(k) = tmp(k) + (-1)**(j+3) / real( 2*j+3 ) 
! k = 4
! tmp(k) = tmp(k) + (-1)**(j+4) / real( 2*j+5 ) 
! end do

end function

end program main

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/83017] DO CONCURRENT not parallelizing

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk (8.0).

For the record, there is probably a bug in 4.8.5: the executable does not stop
(at least in a reasonable time).

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
We fail to analyze dependeces here

Considering loop 6
loop is innermost
Creating dr for MEM[(real(kind=4)[0:D.3539] *)&A.7][_85]
analyze_innermost: Applying pattern match.pd:84, generic-match.c:11356
failed: evolution of offset is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7]
Access function 0: scev_not_known;
Creating dr for MEM[(real(kind=4)[0:D.3539] *)&A.7][_85]
analyze_innermost: Applying pattern match.pd:84, generic-match.c:11356
failed: evolution of offset is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7]
Access function 0: scev_not_known;
(compute_affine_dependence
  stmt_a: _90 = MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
  stmt_b: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85] = _99;
Data ref a:
#(Data Ref:
#  bb: 7
#  stmt: _90 = MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
#  ref: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
#  base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7];
#  Access function 0: scev_not_known;
#)
Data ref b:
#(Data Ref:
#  bb: 7
#  stmt: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85] = _99;
#  ref: MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
#  base_object: MEM[(real(kind=4)[0:D.3539] *)&A.7];
#  Access function 0: scev_not_known;
#)
affine dependence test not usable: access function not affine or constant.
) -> dependence analysis failed

...

this is because

   k = mod( j, nsplit ) + 1

makes the k index not an affine function.

   [85.00%]:
  # j_205 = PHI <_87(8), _82(6)>
  _85 = j_205 % 4;
  _87 = j_205 + 1;
  _90 = MEM[(real(kind=4)[0:D.3539] *)&A.7][_85];
  _91 = _87 << 1;
  _92 = _91 & 2;
  _93 = 1 - _92;
  _94 = (real(kind=4)) _93;
  _95 = j_205 * 2;
  _96 = _95 + -1;
  _97 = (real(kind=4)) _96;
  _98 = _94 / _97;
  _99 = _90 + _98;
  MEM[(real(kind=4)[0:D.3539] *)&A.7][_85] = _99;
  if (_83 < _87)
goto ; [15.00%]
  else
goto ; [85.00%]

what the middle-end could do is remove the modulo and instead build an
inner loop (which might then be unrolled as your commented code shows).

[Bug tree-optimization/71026] Missing division optimizations

[wilco at gcc dot gnu.org]

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

--- Comment #9 from Wilco  ---
Author: wilco
Date: Thu Nov 16 11:54:49 2017
New Revision: 254816

URL: https://gcc.gnu.org/viewcvs?rev=254816&root=gcc&view=rev
Log:
Canonicalize constant multiplies in division

This patch implements some of the optimizations discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026.

Canonicalize x / (C1 * y) into (x * C2) / y.

This moves constant multiplies out of the RHS of a division in order
to allow further simplifications (such as (C1 * x) / (C2 * y) ->
(C3 * x) / y) and to enable more reciprocal CSEs.

2017-11-16  Wilco Dijkstra  
Jackson Woodruff  

gcc/
PR tree-optimization/71026
* match.pd: Canonicalize constant multiplies in division.

gcc/testsuite/
PR tree-optimization/71026
* gcc.dg/cse_recip.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/cse_recip.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed r254817.

[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 16 12:11:36 2017
New Revision: 254817

URL: https://gcc.gnu.org/viewcvs?rev=254817&root=gcc&view=rev
Log:
[PR c++/81060] ICE with invalid initialzer via lambda

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01323.html
PR c++/81060
* decl.c (xref_tag_1): Push lambda into current scope.
* name-lookup.c (do_pushtag): Don't deal with ts_lambda here.

PR c++81060
* g++.dg/cpp0x/lambda/lambda-template13.C: Avoid undefined
template using local type error.
* g++.dg/cpp0x/pr81060.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr81060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template13.C

[Bug c++/79331] ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
This is the same as 81574 and now fixed:
PR c++/81574
* lambda.c (lambda_capture_field_type): Function references are
always catured by reference.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[cfztol at hotmail dot com]

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

--- Comment #3 from Christian Felter  ---
Ultimately, I wanted to compute k like this

k = permutation( j )

where permutation is a 1D array of integers (from 1 to 4, e.g. [ 1, 4, 2, 1, 3,
... etc] ). This would allow an easy way of parallelizing the so-called "finite
element assembly procedure". But I guess, this case is even harder. Clearly, I
must have misunderstood the requirements for DO CONCURRENT... Maybe they could
be relaxed ?

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On November 16, 2017 1:22:37 PM GMT+01:00, cfztol at hotmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017
>
>--- Comment #3 from Christian Felter  ---
>Ultimately, I wanted to compute k like this
>
>k = permutation( j )
>
>where permutation is a 1D array of integers (from 1 to 4, e.g. [ 1, 4,
>2, 1, 3,
>... etc] ). This would allow an easy way of parallelizing the so-called
>"finite
>element assembly procedure". But I guess, this case is even harder.
>Clearly, I
>must have misunderstood the requirements for DO CONCURRENT... Maybe
>they could
>be relaxed ?

It's more an optimization pass issue or the frontend not communicating
guarantees for dependencies downstream. Might be a bit tricky for function
calls.

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Sorry, but I can't reproduce on linux with cross compiler for mingw32.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[cfztol at hotmail dot com]

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

--- Comment #5 from Christian Felter  ---
Okay, sounds like there is hope. By the way, the problem also exists without a
function call. Declaring

 real, dimension(nsplit) :: tmp

and replacing the loop with

 do concurrent (i = 1:nsplit)

 tmp = 0
 do j = low(i), high(i)
 k = mod( j, nsplit ) + 1
 tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 )
 end do
 pi(i) = sum(tmp)

 end do

also inhibits parallelization.

[Bug c++/83003] Using the detection idiom and void_t causes an error

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #3 from ensadc at mailnesia dot com ---
There doesn't even need to be a specialization of Zod.

template  class, class = void>
struct dtect1  { enum { value = 0 }; };

template  class TT>
struct dtect1{}, void())> { enum { value = 1 }; };

template  struct Zod { };
template  using Zod_t = typename Zod::type;

static_assert(!dtect1::value, "");

Zod_t z2; // !!

[Bug c++/83000] Constraints for union-templates do not work

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
Possible duplicate of issue 67217

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On November 16, 2017 2:22:50 PM GMT+01:00, cfztol at hotmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017
>
>--- Comment #5 from Christian Felter  ---
>Okay, sounds like there is hope. By the way, the problem also exists
>without a
>function call. Declaring
>
> real, dimension(nsplit) :: tmp
>
>and replacing the loop with
>
> do concurrent (i = 1:nsplit)
>
> tmp = 0
> do j = low(i), high(i)
> k = mod( j, nsplit ) + 1
> tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 )
> end do
> pi(i) = sum(tmp)
>
> end do
>
>also inhibits parallelization.

What does do concurrent guarantee?

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
If I "fix" GCC to consider the loop you annotate parallel:

do concurrent (i = 1:nsplit)
pi(i) = sum(compute( low(i), high(i) ))
end do

then we arrive at computing 4 iterations of that loop and with 2 threads
and MIN_PER_THREAD 100 (arbitrary define) we run into

  if (!flag_loop_parallelize_all
  && !oacc_kernels_p
  && ((estimated != -1
   && estimated <= (HOST_WIDE_INT) n_threads * MIN_PER_THREAD)
  /* Do not bother with loops in cold areas.  */
  || optimize_loop_nest_for_size_p (loop)))
continue;

(estimated is 4).  With -floop-parallelize-all I then get:

> ./f951 -quiet t.f90 -Ofast -ftree-parallelize-loops=2 
> -fdump-tree-parloops-details -floop-parallelize-all -fopt-info-loop
t.f90:28:0: note: loop with 5 iterations completely unrolled (header execution
count 375)
t.f90:26:0: note: loop with 5 iterations completely unrolled (header execution
count 1500)
t.f90:38:0: note: loop with 5 iterations completely unrolled (header execution
count 1500)
t.f90:18:0: note: loop with 4 iterations completely unrolled (header execution
count 375)
t.f90:15:0: note: loop with 5 iterations completely unrolled (header execution
count 375)
t.f90:26:0: note: parallelizing outer loop 3
t.f90:24:0: note: basic block vectorized
t.f90:41:0: note: basic block vectorized
t.f90:41:0: note: basic block vectorized

yay.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Created attachment 42620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42620&action=edit
patch

Otherwise untested patch.  Note ivdep is mapped to safelen which isn't useful
for parallelization given safelen perserves forward dependences.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Created attachment 42621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42621&action=edit
updated patch

[Bug c++/83018] New: To support creation of header-only C++ libraries with SIMD optimization and dynamic dispatch, allow all intrinsics regardless of target architecture

[kerukuro at gmail dot com]

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

Bug ID: 83018
   Summary: To support creation of header-only C++ libraries with
SIMD optimization and dynamic dispatch, allow all
intrinsics regardless of target architecture
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kerukuro at gmail dot com
  Target Milestone: ---

Visual C++ already does this. Using Visual C++, I can use e.g. AVX2 intrinsics
in a program compiled with SSE2 target architecture and dispatch to that code
path dynamically if CPU supports AVX2. GCC requires compiling separate object
files to achieve that, which is not possible for header-only libraries.

[Bug middle-end/83019] New: Compiler dumps predictions with -nan%

[ubizjak at gmail dot com]

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

Bug ID: 83019
   Summary: Compiler dumps predictions with -nan%
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Recent patch caused some dumps to dump -nam%.

One example is gcc.dg/graphite/interchange-12.c, which generates:

./cc1 -O2 -ffast-math -floop-nest-optimize -fdump-tree-graphite-all
interchange-12.c

interchange-12.c.150t.graphite:

...
Predictions for bb 29
  first match heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  combined heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  loop iterations heuristics of edge 29->28: 1.0%  exec 0 (estimated locally)
hit 0 (estimated locally) (-nan%)
Predictions for bb 30
1 edges in bb 30 predicted to even probabilities
Predictions for bb 28
  first match heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  combined heuristics: 99.0%  exec 0 (estimated locally) hit 0 (estimated
locally) (-nan%)
  loop iterations heuristics of edge 28->22: 1.0%  exec 0 (estimated locally)
hit 0 (estimated locally) (-nan%)
...

The above dump was generated with x86_64-linux-gnu host. This is problematic
with hosts (e.g. alpha) that require -mieee when dealing with NaNs, resulting
in several ICEs [1].

The cause is the division 0/0 in:

Program received signal SIGFPE, Arithmetic exception.
0x0001207a4ee4 in dump_prediction (file=0x121665bf0, predictor=, probability=, bb=0x299df48, reason=, 
ep_edge=) at
/space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:750
750   fprintf (file, " (%.1f%%)", e->count ().to_gcov_type() *
100.0
(gdb) bt
#0  0x0001207a4ee4 in dump_prediction (file=0x121665bf0,
predictor=, probability=, bb=0x299df48, 
reason=, ep_edge=) at
/space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:750
#1  0x0001207af424 in combine_predictions_for_bb (bb=0x299df48,
dry_run=) at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:1
270
#2  0x0001207b23d0 in tree_estimate_probability (dry_run=)
at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:2819
#3  0x000120f6bf24 in graphite_transform_loops () at
/space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:425
#4  0x000120f6d374 in graphite_transforms (fun=0x12120fc31) at
/space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:447
#5  (anonymous namespace)::pass_graphite_transforms::execute (this=0x121665bf0,
fun=0x12120fc31) at /space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:
524
#6  0x00012078b038 in execute_one_pass (pass=0x1214fe7c0) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2497
#7  0x00012078bc08 in execute_pass_list_1 (pass=0x1214fe7c0) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2586
#8  0x00012078bc24 in execute_pass_list_1 (pass=0x1214fe760) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587
#9  0x00012078bc24 in execute_pass_list_1 (pass=0x1214fe400) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587
#10 0x00012078bc24 in execute_pass_list_1 (pass=0x1214fd070) at
/space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587
#11 0x00012078bca4 in execute_pass_list (fn=,
pass=0x12120fc31) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2597
#12 0x000120363804 in cgraph_node::expand (this=0x29c8000) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2139
#13 0x0001203652a0 in expand_all_functions () at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2275
#14 symbol_table::compile (this=) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2623
#15 0x00012036874c in compile (this=0x28a4000) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2682
#16 symbol_table::finalize_compilation_unit (this=0x28a4000) at
/space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2716
#17 0x0001208a695c in compile_file () at
/space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:480
#18 0x00012013ae90 in do_compile () at
/space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:2060
#19 toplev::main (this=0x11fdff040, argc=, argv=)
at /space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:2195
#20 0x00012013cf60 in main (argc=, argv=0x11fdff168) at
/space/homedirs/uros/gcc-svn/trunk/gcc/main.c:39
(gdb) list
745   bb->count.dump (file);
746   if (e)
747 {
748   fprintf (file, " hit ");
749   e->count ().dump (file);
750   fprintf (file, " (%.1f%%)", e->count ().to_gcov_type() *
100.0
751/ bb->count.to_gcov_type ());
752 }
753 }
754

[1] https://gcc.gnu.org/ml/gcc-testresults/2017-11/msg01330.html

[Bug middle-end/83019] Compiler dumps predictions with -nan%

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Adding CC.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
This also breaks 'make all-gnattools' in a bootstrap build:

g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I.
-I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc  -DIN_GCC  -g -O2
-W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o
s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o
einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o
fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o
lib.o make.o makeusg.o make_util.o namet.o nlists.o opt.o osint.o osint-m.o
output.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o
scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o
sinfo.o sinput.o sinput-c.o snames.o stand.o stringt.o styleg.o stylesw.o
system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o
types.o uintp.o uname.o urealp.o usage.o widechar.o  ../link.o ../targext.o
../../ggc-none.o ../../libcommon-target.a ../../libcommon.a
../../../libcpp/libcpp.a ../rts/libgnat.a  
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a  
-no-pie -ldl
g++: error: unrecognized command line option ‘-no-pie’
../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed
make[2]: *** [../../gnatmake] Error 1
make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools'
Makefile:188: recipe for target 'gnattools-native' failed
make[1]: *** [gnattools-native] Error 2
make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools'
Makefile:13917: recipe for target 'all-gnattools' failed
make: *** [all-gnattools] Error 2

During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++
-B/home/eric/build/gcc/native/./gcc/ so this still works.

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-16
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Known old problem, gnatlink is invoked with:

/home/eric/build/gcc/native/gcc/ada/tools/gnatclean.ali
../../gnatlink -v gnatcmd -o ../../gnat \
--GCC="/home/eric/build/gcc/native/./gcc/xg++
-B/home/eric/build/gcc/native/./gcc/ -nostdinc++ -nostdinc++
-I/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux
-I/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/include
-I/home/eric/svn/gcc/libstdc++-v3/libsupc++
-I/home/eric/svn/gcc/libstdc++-v3/include/backward
-I/home/eric/svn/gcc/libstdc++-v3/testsuite/util
-L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src
-L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src/.libs
-L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-B/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src/.libs
-B/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-B/home/eric/install/gcc/x86_64-suse-linux/bin/
-B/home/eric/install/gcc/x86_64-suse-linux/lib/ -isystem
/home/eric/install/gcc/x86_64-suse-linux/include -isystem
/home/eric/install/gcc/x86_64-suse-linux/sys-include-static-libstdc++
-static-libgcc -I- -I../rts -I. -I/home/eric/svn/gcc/gcc/ada -static-libstdc++
-static-libgcc " ../link.o ../targext.o ../../ggc-none.o
../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
../rts/libgnat.a   ../../../libbacktrace/.libs/libbacktrace.a
../../../libiberty/libiberty.a   -no-pie

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[nathan at gcc dot gnu.org]

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

--- Comment #23 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 16 14:54:54 2017
New Revision: 254823

URL: https://gcc.gnu.org/viewcvs?rev=254823&root=gcc&view=rev
Log:
[PATCH] New lang hook

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01340.html
PR c++/82836
PR c++/82737
* tree.h (COPY_DECL_RTL): Rename parms for clarity.
(SET_DECL_ASSEMBLER_NAME): Forward to
overwrite_decl_assembler_name.
(COPY_DECL_ASSEMBLER_NAME): Rename parms for clarity.
(overwrite_decl_assembler_name): Declare.
* tree.c (overwrite_decl_assembler_name): New.
* langhooks-def.h (lhd_overwrite_decl_assembler_name): Declare.
(LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Provide default.
(LANG_HOOKS_INITIALIZER): Add it.
* langhooks.h (struct lang_hooks): Add overwrite_decl_assembler_name.
* langhooks.c (lhd_set_decl_assembler_name): Use
SET_DECL_ASSEMBLER_NAME.
(lhd_overwrite_decl_assembler_name): Default implementation.

PR c++/82836
PR c++/82737
* cp-objcp-common.h (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME):
Override.
* cp-tree.h (overwrite_mangling): Declare.
* decl2.c (struct mangled_decl_hash): Entries are deletable.
(overwrite_mangling): New.

PR c++/82836
PR c++/82737
* g++.dg/pr82836.C: New.


Added:
trunk/gcc/testsuite/g++.dg/pr82836.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.h
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.c
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/82836] [8 Regression] ICE on valid code

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 16 14:54:54 2017
New Revision: 254823

URL: https://gcc.gnu.org/viewcvs?rev=254823&root=gcc&view=rev
Log:
[PATCH] New lang hook

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01340.html
PR c++/82836
PR c++/82737
* tree.h (COPY_DECL_RTL): Rename parms for clarity.
(SET_DECL_ASSEMBLER_NAME): Forward to
overwrite_decl_assembler_name.
(COPY_DECL_ASSEMBLER_NAME): Rename parms for clarity.
(overwrite_decl_assembler_name): Declare.
* tree.c (overwrite_decl_assembler_name): New.
* langhooks-def.h (lhd_overwrite_decl_assembler_name): Declare.
(LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Provide default.
(LANG_HOOKS_INITIALIZER): Add it.
* langhooks.h (struct lang_hooks): Add overwrite_decl_assembler_name.
* langhooks.c (lhd_set_decl_assembler_name): Use
SET_DECL_ASSEMBLER_NAME.
(lhd_overwrite_decl_assembler_name): Default implementation.

PR c++/82836
PR c++/82737
* cp-objcp-common.h (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME):
Override.
* cp-tree.h (overwrite_mangling): Declare.
* decl2.c (struct mangled_decl_hash): Entries are deletable.
(overwrite_mangling): New.

PR c++/82836
PR c++/82737
* g++.dg/pr82836.C: New.


Added:
trunk/gcc/testsuite/g++.dg/pr82836.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.h
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.c
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/82836] [8 Regression] ICE on valid code

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r254823.

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #24 from Nathan Sidwell  ---
Fixed r254823.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
(In reply to Eric Botcazou from comment #16)
> This also breaks 'make all-gnattools' in a bootstrap build:
> 
> g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I.
> -I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc  -DIN_GCC  -g
> -O2 -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o
> aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o
> debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o
> fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o
> i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o make_util.o namet.o
> nlists.o opt.o osint.o osint-m.o output.o restrict.o rident.o s-exctab.o
> s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o
> s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o
> snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o
> switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o
> urealp.o usage.o widechar.o  ../link.o ../targext.o ../../ggc-none.o
> ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
> ../rts/libgnat.a   ../../../libbacktrace/.libs/libbacktrace.a
> ../../../libiberty/libiberty.a   -no-pie -ldl
> g++: error: unrecognized command line option ‘-no-pie’
> ../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed
> make[2]: *** [../../gnatmake] Error 1
> make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools'
> Makefile:188: recipe for target 'gnattools-native' failed
> make[1]: *** [gnattools-native] Error 2
> make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools'
> Makefile:13917: recipe for target 'all-gnattools' failed
> make: *** [all-gnattools] Error 2
> 
> During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++
> -B/home/eric/build/gcc/native/./gcc/ so this still works.

Hmm, all-gnattools does

all-gnattools: configure-gnattools
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS)  \
(cd $(HOST_SUBDIR)/gnattools && \
  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
$(STAGE1_FLAGS_TO_PASS)  \
$(TARGET-gnattools))

so it builds for the host.  But when bootstrapping we want to build it
similar to if it were a target library, that is, with the just built GCC.
So,

host_modules= { module= gnattools; };

is technically not correct.  Not sure how it works during bootstrap, I'd have
expected that the host compiler is used as well (gnattools is not
bootstrapped).

[Bug middle-end/83019] [8 Regression] Compiler dumps predictions with -nan%

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|Compiler dumps predictions  |[8 Regression] Compiler
   |with -nan%  |dumps predictions with
   ||-nan%

[Bug c++/83018] To support creation of header-only C++ libraries with SIMD optimization and dynamic dispatch, allow all x86 intrinsics regardless of target instruction set

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
You need to guard affected code portions with #pragma GCC target ("avx2") for
example.

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Andreas Krebbel  ---
Hi Vladimir. What do you think about the additional patch?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #18 from Eric Botcazou  ---
> all-gnattools: configure-gnattools
> @: $(MAKE); $(unstage)
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(HOST_EXPORTS)  \
> (cd $(HOST_SUBDIR)/gnattools && \
>   $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
> $(STAGE1_FLAGS_TO_PASS)  \
> $(TARGET-gnattools))
> 
> so it builds for the host.  But when bootstrapping we want to build it
> similar to if it were a target library, that is, with the just built GCC.

Yes, that's what happens, i.e. the CXX passed to gnattools is CXX_FOR_TARGET.

> So,
> 
> host_modules= { module= gnattools; };
> 
> is technically not correct.  Not sure how it works during bootstrap, I'd have
> expected that the host compiler is used as well (gnattools is not 
> bootstrapped).

This would simply break, because the gnattools really need to be bootstrapped
as they generally cannot be built by the host compiler.  Quite puzzling indeed.

[Bug c++/83020] New: ('17) Class template constructor call skipped with no error when substitution fails in default argument

[oremanj at mit dot edu]

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

Bug ID: 83020
   Summary: ('17) Class template constructor call skipped with no
error when substitution fails in default argument
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oremanj at mit dot edu
  Target Milestone: ---

The below C++ program is ill-formed, but gcc 7.1 and 7.2 accept it in C++17
mode, and emit code that simply doesn't call the constructor of Whoops at all.
This is reproducible if the constructor is defined out-of-line as well; there's
no reference to Whoops in the generated assembly. In C++14 mode or with gcc
6.3, the error is correctly diagnosed.


$ cat t.cc
struct NoDefault {
int val = 1234;
NoDefault(int v) : val(v) {}
};
template 
struct Whoops {
const char *str;
T obj;
Whoops(const char *s, T v = T()) : str(s), obj(v) {}
};
const char *test() {
return Whoops("hi").str;
}


$ g++-7 -O3 -std=c++17 -Wall -c t.cc && objdump -d t.o

t.o: file format elf64-x86-64

Disassembly of section .text:

 <_Z4testv>:
   0:   31 c0   xor%eax,%eax
   2:   c3  retq   


$ g++-7 -O0 -std=c++17 -Wall -c t.cc && objdump -d t.o

t.o: file format elf64-x86-64

Disassembly of section .text:

 <_Z4testv>:
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   5d  pop%rbp
   5:   c3  retq   


$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
7.2.0-12+hrtdeb8u1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-initfini-array
Thread model: posix
gcc version 7.2.1 20171025 (Debian 7.2.0-12)

[Bug fortran/69455] [6/7/8 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK

[drikosev at gmail dot com]

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

Ev Drikos  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #12 from Ev Drikos  ---
Is there any chance to see this patch?

Thanks,
Ev. Drikos

[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 16 16:12:36 2017
New Revision: 254830

URL: https://gcc.gnu.org/viewcvs?rev=254830&root=gcc&view=rev
Log:
PR tree-optimization/82588 - missing -Warray-bounds on a excessively large
index
PR tree-optimization/82583 - missing -Warray-bounds on out-of-bounds inner
indic

gcc/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* tree-vrp.c (check_array_ref): Handle flexible array members,
string literals, and inner indices.
(search_for_addr_array): Add detail to diagnostics.

gcc/testsuite/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* c-c++-common/Warray-bounds.c: New test.
* gcc.dg/Warray-bounds-11.c: Adjust.
* gcc.dg/Warray-bounds-22.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/Warray-bounds.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-22.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-11.c
trunk/gcc/tree-vrp.c

[Bug tree-optimization/82583] missing -Warray-bounds on out-of-bounds inner indices

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 16 16:12:36 2017
New Revision: 254830

URL: https://gcc.gnu.org/viewcvs?rev=254830&root=gcc&view=rev
Log:
PR tree-optimization/82588 - missing -Warray-bounds on a excessively large
index
PR tree-optimization/82583 - missing -Warray-bounds on out-of-bounds inner
indic

gcc/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* tree-vrp.c (check_array_ref): Handle flexible array members,
string literals, and inner indices.
(search_for_addr_array): Add detail to diagnostics.

gcc/testsuite/ChangeLog:

PR tree-optimization/82588
PR tree-optimization/82583
* c-c++-common/Warray-bounds.c: New test.
* gcc.dg/Warray-bounds-11.c: Adjust.
* gcc.dg/Warray-bounds-22.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/Warray-bounds.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-22.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-11.c
trunk/gcc/tree-vrp.c

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 82583 Summary: missing -Warray-bounds on out-of-bounds inner indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82583

   What|Removed |Added

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

[Bug tree-optimization/82583] missing -Warray-bounds on out-of-bounds inner indices

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r254830.  GCC now issues the warnings below for the test case in
comment #0:

a.c: In function ‘f’:
a.c:6:12: warning: array subscript 4 is above array bounds of ‘int[4]’
[-Warray-bounds]
   p->a[1].a[4] = 1;
   ~^~~
a.c: In function ‘g’:
a.c:11:7: warning: array subscript 2 is above array bounds of ‘struct A[2]’
[-Warray-bounds]
   p->a[2].a[3] = 1;
   ^~~

[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82455
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
The -Warrray-bounds part of the issue has been fixed in r254830.  GCC now
issues the warnings below for the test case in comment #0:

a.c: In function ‘f1’:
a.c:17:11: warning: array subscript 4611686018427387904 is above array bounds
of ‘int[]’ [-Warray-bounds]
   return a[__SIZE_MAX__ / sizeof (int) + 1];   // missing -Warray-bounds
  ~^
a.c: In function ‘f2’:
a.c:22:14: warning: array subscript 9223372036854775807 is above array bounds
of ‘char[]’ [-Warray-bounds]
   return a->a[__SIZE_MAX__ / 2];   // missing -Warray-bounds
  ^~

The out-of-bounds offset is still not diagnosed.  It's the subject of a
separate bug (pr82455).

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 82588 Summary: missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588

   What|Removed |Added

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

[Bug c/68325] missing -Warray-bounds on a negative subscript into a flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
   Target Milestone|--- |8.0
  Known to fail||5.4.0, 6.4.0, 7.2.0

--- Comment #2 from Martin Sebor  ---
Fixed in r254830.  GCC now issues the warnings below for the test case in
comment #0:

z.c: In function ‘foo’:
z.c:7:16: warning: array subscript -2147483647 is below array bounds of
‘int[99]’ [-Warray-bounds]
 return s.a [-__INT_MAX__];
^~
z.c: In function ‘bar’:
z.c:12:17: warning: array subscript -2147483647 is below array bounds of
‘int[99]’ [-Warray-bounds]
 return p->a [-__INT_MAX__];
~^~

[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|--- |8.0
  Known to fail||5.4.0, 6.4.0, 7.2.0

[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jgreenhalgh at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is because the aarch64 backend doesn't define
TARGET_ASM_OUTPUT_DWARF_DTPREL hook.
Either the assembler lacks the corresponding support, or just the backend
doesn't define it even if it could.

[Bug tree-optimization/59124] [6 Regression] Wrong warnings "array subscript is above array bounds"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||8.0

--- Comment #47 from Martin Sebor  ---
None of the test cases here except for the one in comment #41 triggers
-Warray-bounds with GCC 8.0.  According to comments #42 and #43 the warning for
the test case in comment #41 is a true positive.  I'll go ahead and resolve
this as fixed.

I suggest to open a separate bug for any new/outstanding issues in this area to
make it easier to track each separately.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 59124 Summary: [6 Regression] Wrong warnings "array subscript is above 
array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

   What|Removed |Added

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

[Bug fortran/83017] DO CONCURRENT not parallelizing

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Created attachment 42621 [details]
> updated patch

AFAICT the patch does not fix the problem:

without the patch

 PI   2.98876095
 PI   3.14159274
4.742u 0.015s 0:04.77 99.5% 0+0k 0+0io 36pf+0w

with the patch

 PI   2.98876095
 PI   3.14159274
4.782u 0.012s 0:04.80 99.7% 0+0k 0+0io 0pf+0w

[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 16 16:48:36 2017
New Revision: 254833

URL: https://gcc.gnu.org/viewcvs?rev=254833&root=gcc&view=rev
Log:
PR middle-end/63477 - Bogus warning with -O3 -Warray-bounds: array subscript
is above array bounds

gcc/testsuite/ChangeLog:

PR middle-end/63477
* gcc.dg/pr63477.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr63477.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail|8.0 |

--- Comment #3 from Martin Sebor  ---
Strangely, I cannot reproduce this warning anymore with GCC 8.  Bisection
points to r220157 (gcc 5.0.0) as the revision that fixed it.  I've added the
test case to the test suite in r254833 and with that I'm resolving this bug as
fixed.  Please reopen it if the problem reappears.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 63477 Summary: [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: 
array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477

   What|Removed |Added

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

[Bug fortran/83017] DO CONCURRENT not parallelizing

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On November 16, 2017 5:42:02 PM GMT+01:00, "dominiq at lps dot ens.fr"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017
>
>--- Comment #10 from Dominique d'Humieres 
>---
>> Created attachment 42621 [details]
>> updated patch
>
>AFAICT the patch does not fix the problem:
>
>without the patch
>
> PI   2.98876095
> PI   3.14159274
>4.742u 0.015s 0:04.77 99.5% 0+0k 0+0io 36pf+0w
>
>with the patch
>
> PI   2.98876095
> PI   3.14159274
>4.782u 0.012s 0:04.80 99.7% 0+0k 0+0io 0pf+0w

Please use - fopt-info-loop to verify the loop is parallelized. You have to use
- floop-parallelize-all as well due to the cost model issue. 

It might be we employ the same cost model at runtime.

[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
>From quick look, it seems gas/ld just doesn't have corresponding support, so
that would need to be written first.  There is R_AARCH64_TLS_DTPREL64
relocation, wonder if that might do the job if gas has some way to emit that
relocation.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 63441 Summary: incorrect "array subscript is below/above array bounds" 
diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63441

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug middle-end/63441] incorrect "array subscript is below/above array bounds" diagnostic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||5.4.0, 6.4.0, 7.1.0, 8.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=63477
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Sebor  ---
Just like with pr63477, I cannot reproduce the warning with this test case in
GCC 8.0 anymore (despite what I said in comment #2), or 7-branch, or 6-branch,
or even 5-branch.  Just like in pr63477, bisection also points to r220157 (gcc
5.0.0) as the fix.  So I'll assume that what I saw in comment #2 was some
transient fluke and resolve this as worksforsome (based on comment #1 and #2
saying it would make sense to diagnose this).

[Bug fortran/83012] [8 Regression] Simply contiguous pointer function not recognized as contiguous

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
The regression is fixed, the other issues still need work.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug fortran/82904] [7/8 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:261

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/82799] [8 Regression] -Wunused-but-set-variable false positive

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-16
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r253266.

[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable

[qiyao at gcc dot gnu.org]

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

--- Comment #3 from Yao Qi  ---
(In reply to Jakub Jelinek from comment #2)
> From quick look, it seems gas/ld just doesn't have corresponding support, so
> that would need to be written first.  There is R_AARCH64_TLS_DTPREL64
> relocation, wonder if that might do the job if gas has some way to emit that
> relocation.

Yes, beside gcc, something is needed in ld too.  Clang emits DW_AT_location for
TLS variable, but ld failed to link,

$ ./clang+llvm-5.0.0-aarch64-linux-gnu/bin/clang   -g 4.c -o 4.exe
/usr/bin/ld: /tmp/4-767da1.o(.debug_info+0x37): R_AARCH64_ABS64 used with TLS
symbol a_thread_local

but gold is ok,

$ ./clang+llvm-5.0.0-aarch64-linux-gnu/bin/clang -fuse-ld=gold  -g 4.c -o 4.exe

 <1><2a>: Abbrev Number: 2 (DW_TAG_variable)
<2b>   DW_AT_name: (indirect string, offset: 0x3e): a_thread_local
<2f>   DW_AT_type: <0x40>
<33>   DW_AT_external: 1
<33>   DW_AT_decl_file   : 1
<34>   DW_AT_decl_line   : 2
<35>   DW_AT_location: 10 byte block: e 0 0 0 0 0 0 0 0 e0 
(DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll have a look.

[Bug fortran/83021] New: [7 Regression] gfortran segfault

[doko at gcc dot gnu.org]

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

Bug ID: 83021
   Summary: [7 Regression] gfortran segfault
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

[forwarded from https://bugs.debian.org/881918]

seen building open-coarrays with the gcc-7-branch 20171115, not seen on the
branch 20171001

$ gfortran global_field.f90 -fcoarray=lib
global_field.f90:126:0:

 lhs%values(:) = rhs%state()

internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

Program received signal SIGSEGV, Segmentation fault.
0x0067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) ()
(gdb) bt
#0  0x0067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) ()
#1  0x0067cf7a in gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ()
#2  0x006a6572 in ?? ()
#3  0x006b9814 in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ()
#4  0x006a0895 in ?? ()
#5  0x00696a3b in gfc_apply_interface_mapping(gfc_interface_mapping*,
gfc_se*, gfc_expr*) ()
#6  0x0066ee45 in
gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*) ()
#7  0x0069f37e in gfc_conv_procedure_call(gfc_se*, gfc_symbol*,
gfc_actual_arglist*, gfc_expr*, vec*) ()
#8  0x006a087d in ?? ()
#9  0x0067c239 in ?? ()
#10 0x0067cdf6 in gfc_conv_loop_setup(gfc_loopinfo*, locus*) ()
#11 0x006a32e0 in ?? ()
#12 0x00668b10 in ?? ()
#13 0x0068de98 in gfc_generate_function_code(gfc_namespace*) ()
#14 0x0066c86a in gfc_generate_module_code(gfc_namespace*) ()
#15 0x0062229c in gfc_parse_file() ()
#16 0x00665630 in ?? ()
#17 0x00a7ac6f in ?? ()
#18 0x0059923a in toplev::main(int, char**) ()
#19 0x0059b5eb in main ()

[Bug web/78315] "Changes" don't explain what "LRA" is

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
The "Changes" page for gcc-7 at least says now that LRA is "(a new local
register allocator)"; is that enough?

[Bug middle-end/83022] New: malloc & memset -> calloc is not always an optimization

[nathan at gcc dot gnu.org]

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

Bug ID: 83022
   Summary: malloc & memset -> calloc is not always an
optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42623&action=edit
exemplar

We like to optimize malloc followed by memset into a calloc call.  Even when
the memset is conditional.  That's well formed, but pessimizes, and noticeable
when the size is large and we do unnecessary clearing.

The attached example, compiled on x86_64 with -O results in:
_Z1mmb:
movl$1, %esi
jmp calloc

But, it causes a noticeable performance regression, as 'c' is false
sufficiently often and 's' is large sufficiently often.

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug fortran/83017] DO CONCURRENT not parallelizing

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
> Please use -fopt-info-loop to verify the loop is parallelized. You have
> to use -floop-parallelize-all as well due to the cost model issue. 

If I use the commented loop I get with/without the patch

% gfc -Ofast -ftree-parallelize-loops=4 -fopt-info-loop pr83017_db.f90
pr83017_db.f90:28:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:26:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:38:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:18:0: note: loop with 4 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:15:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:47:0: note: parallelizing inner loop 6
pr83017_db.f90:24:0: note: basic block vectorized
pr83017_db.f90:47:0: note: basic block vectorized
% time ./a.out
 PI   2.98875999
 PI   3.14159274
4.027u 0.015s 0:01.02 395.0%0+0k 0+0io 7pf+0w

i.e., a loop is parallelized, and with -floop-parallelize-all

% gfc -Ofast -ftree-parallelize-loops=4 -floop-parallelize-all -fopt-info-loop
pr83017_db.f90
pr83017_db.f90:28:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:26:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:38:0: note: loop with 5 iterations completely unrolled (header
execution count 1515)
pr83017_db.f90:18:0: note: loop with 4 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:15:0: note: loop with 5 iterations completely unrolled (header
execution count 379)
pr83017_db.f90:26:0: note: parallelizing outer loop 3
pr83017_db.f90:24:0: note: basic block vectorized
% time ./a.out 
 PI   2.98876095
 PI   3.14159274
4.152u 0.011s 0:04.16 100.0%0+0k 0+0io 0pf+0w

i.e., the report says the loop is parallelized, but this is not reflected at
run time (for the original test as well).

[Bug fortran/83021] [7 Regression] gfortran segfault

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Could you please provide the file(s) needed to generate local_field_module.mod?

Revision r254377 for the 7 branch is OK.

[Bug middle-end/83023] New: branch probabilities pessimize malloc

[nathan at gcc dot gnu.org]

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

Bug ID: 83023
   Summary: branch probabilities pessimize malloc
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42625&action=edit
exemplar

on x86_64 compiled with -O2 -fdump-tree-all, the ma.cc.046t.profile_estimate
contains:
  r_5 = malloc (s_3(D));
  if (r_5 != 0B)
goto ; [53.47%]
  else
goto ; [46.53%]

That's a pretty inaccurate guess at the behaviour of malloc!

[Bug target/62011] False Data Dependency in popcnt instruction

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m

--- Comment #17 from Andrew Senkevich  ---
(In reply to Travis Downs from comment #16)
> Also, this is fixed for Skylake for tzcnt and lzcnt but not popcnt.

How to confirm it? As I see it is fixed for popcnt. Could you show some
reproducer?

[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug c++/79092] template: type ignored if value already instantiated

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Nov 16 20:13:48 2017
New Revision: 254843

URL: https://gcc.gnu.org/viewcvs?rev=254843&root=gcc&view=rev
Log:
PR c++/79092 - non-type args of different types are different

* tree.c (cp_tree_equal): Check the type of constants.
* pt.c (unify) [TEMPLATE_PARM_INDEX]: Handle UNIFY_ALLOW_INTEGER
when comparing to previously deduced argument.
(maybe_convert_nontype_argument): New.
(convert_nontype_argument): Call it.
(tsubst_copy_and_build): Handle partial instantiation of
IMPLICIT_CONV_EXPR.
(unify): Ignore type when deducing from array bound.
(dependent_type_p_r): Handle DEFERRED_NOEXCEPT.
(value_dependent_expression_p): Any type-dependent expression is
value-dependent.  Handle IMPLICIT_CONV_EXPR.
* cp-tree.h (IMPLICIT_CONV_EXPR_NONTYPE_ARG): New.
* mangle.c (write_template_arg): Strip IMPLICIT_CONV_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto12.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/mangle.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c

[Bug tree-optimization/82946] member pointer defeats strlen optimization involving a string literal

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
(In reply to rguent...@suse.de from comment #5)
> This means you can very well replace memcpy with strcpy if you know
> there's a '\0' in and only in the right place.

Sure, except when dealing with a string literal we know that the source is a
string literal and not a pointer representation disguised as a sequence of
bytes.  The optimization I'm referring to is specifically for string literals:

  unsigned g (struct A *a)
  {
strcpy (a->d, "123");   // here we have a literal, not the representation
of a pointer 
return strlen (a->d);   // a->d must be a valid pointer
  }

> We certainly have to treat literal pointers encoded in any form
> conservatively.  I don't see how they are against any standard.  There's
> other clearly "valid" optimizations missing in GCC that look more
> important to implement.

The C and C++ standards are clear as to what are valid pointer values and how
they can come about.  Copying the representation from an arbitrary constant of
an incompatible type into a pointer object is certainly not one of them.  I.e.,
this:

  const char a[] = "123";
  char *p;
  memcpy (&p, a, sizeof p);
  strlen (p);

is undefined, but this is of course valid:

  const char a[4] = "123";
  char *p;
  char *q = a;
  memcpy (&p, &q, sizeof p);
  strlen (p);

because it just copies the representation of what's known to be a valid pointer
value into another pointer object of a compatible type.

The point is that the bytes of no string literal can also be a valid pointer
value, even if it happens to have the same representation as one, and this can
be exploited to allow the optimization above.  It will not invalidate any
correct programs.  It would be not only invalid but downright silly for a
program to represent valid addresses as string literals.  Embedded programs of
course do hardcode pointer values, but not in string literals: they hardcode
them as integers, e.g.,

  void *my_register = (void*)0x123;

but never like so:

  char my_register[] = "123";

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Nov 16 20:24:00 2017
New Revision: 254845

URL: https://gcc.gnu.org/viewcvs?rev=254845&root=gcc&view=rev
Log:
2017-11-16  Thomas Koenig  

PR bootstrap/82856
* doc/install.texi: Document incompatibility of Perl >=5.6.26
with the required version of automake 1.11.6.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi

[Bug target/79845] rs6000: make code in rs6000.c more i18n-friendly

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Nov 16 20:29:52 2017
New Revision: 254846

URL: https://gcc.gnu.org/viewcvs?rev=254846&root=gcc&view=rev
Log:
[gcc]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_expand_builtin): Do not do the
switch statement mapping KF built-ins to TF built-ins if we don't
have the proper ISA 3.0 assembler support.

Back port from trunk
2017-11-14  Michael Meissner  

* config/rs6000/rs6000-c.c (is_float128_p): New helper function.
(rs6000_builtin_type_compatible): Treat _Float128 and long double
as being compatible if -mabi=ieeelongdouble.
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_HW_1): New macros
to setup float128 built-ins with hardware support.
(BU_FLOAT128_HW_2): Likewise.
(BU_FLOAT128_HW_3): Likewise.
(BU_FLOAT128_HW_VSX_1): Likewise.
(BU_FLOAT128_HW_VSX_2): Likewise.
(scalar_extract_expq): Change float128 built-in functions to
accommodate having both KFmode and TFmode functions.  Use the
KFmode variant as the default.
(scalar_extract_sigq): Likewise.
(scalar_test_neg_qp): Likewise.
(scalar_insert_exp_q): Likewise.
(scalar_insert_exp_qp): Likewise.
(scalar_test_data_class_qp): Likewise.
(sqrtf128_round_to_odd): Delete processing the round to odd
built-in functions as special built-in functions, and define them
as float128 built-ins.  Use the KFmode variant as the default.
(truncf128_round_to_odd): Likewise.
(addf128_round_to_odd): Likewise.
(subf128_round_to_odd): Likewise.
(mulf128_round_to_odd): Likewise.
(divf128_round_to_odd): Likewise.
(fmaf128_round_to_odd): Likewise.
* config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Add
support for KFmode and TFmode xststdcqp calls.
(rs6000_expand_builtin): If long double is IEEE 128-bit floating
point, switch the built-in handlers for the get/set float128
exponent, get float128 mantissa, float128 test built-ins, and the
float128 round to odd built-in functions.  Eliminate creating the
float128 round to odd built-in functions as special built-ins.
(rs6000_init_builtins): Eliminate special creation of the float128
round to odd built-in functions.
* config/rs6000/vsx.md (xsxexpqp_): Change float128 built-in
function insns to support both TFmode and KFmode variants.
(xsxsigqp_): Likewise.
(xsiexpqpf_): Likewise.
(xsiexpqp_): Likewise.
(xststdcqp_): Likewise.
(xststdcnegqp_): Likewise.
(xststdcqp_): Likewise.

Back port from trunk
2017-11-06  Michael Meissner  

PR target/82748
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete
float128 helper macros, which are no longer used after deleting
the old 'q' built-in functions, and moving the round to odd
built-in functions to being special built-in functions.
(BU_FLOAT128_2): Likewise.
(BU_FLOAT128_1_HW): Likewise.
(BU_FLOAT128_2_HW): Likewise.
(BU_FLOAT128_3_HW): Likewise.
(FABSQ): Delete old 'q' built-in functions.
(COPYSIGNQ): Likewise.
(SQRTF128_ODD): Move round to odd built-in functions to be
special built-in functions, so that we can handle
-mabi=ieeelongdouble.
(TRUNCF128_ODD): Likewise.
(ADDF128_ODD): Likewise.
(SUBF128_ODD): Likewise.
(MULF128_ODD): Likewise.
(DIVF128_ODD): Likewise.
(FMAF128_ODD): Likewise.
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Map old 'q'
built-in names to 'f128'.
* config/rs6000/rs6000.c (rs6000_fold_builtin): Remove folding the
old 'q' built-in functions, as the machine independent code for
'f128' built-in functions handles this.
(rs6000_expand_builtin): Add expansion for float128 round to odd
functions, keying off on -mabi=ieeelongdouble of whether to use
the KFmode or TFmode variant.
(rs6000_init_builtins): Initialize the _Float128 round to odd
built-in functions.
* doc/extend.texi (PowerPC Built-in Functions): Document the old
_Float128 'q' built-in functions are now mapped into the new
'f128' built-in functions.


[gcc/testsuite]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* gcc.target/powerpc/bfp/bfp.exp: Look for *.c files, not *.c*
files to prevent ~ files from getting recognized.
* gcc.target/powerpc/dfp/dfp.exp: Likewise.
* gcc.target/powerpc/vsu/vsu.exp: Likewise.

Back port from trunk
2017-11-14  M

[Bug target/82748] ICE with __builtin_fabsq and __float128 in copy_to_mode_reg, at explow.c:612

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Nov 16 20:29:52 2017
New Revision: 254846

URL: https://gcc.gnu.org/viewcvs?rev=254846&root=gcc&view=rev
Log:
[gcc]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_expand_builtin): Do not do the
switch statement mapping KF built-ins to TF built-ins if we don't
have the proper ISA 3.0 assembler support.

Back port from trunk
2017-11-14  Michael Meissner  

* config/rs6000/rs6000-c.c (is_float128_p): New helper function.
(rs6000_builtin_type_compatible): Treat _Float128 and long double
as being compatible if -mabi=ieeelongdouble.
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_HW_1): New macros
to setup float128 built-ins with hardware support.
(BU_FLOAT128_HW_2): Likewise.
(BU_FLOAT128_HW_3): Likewise.
(BU_FLOAT128_HW_VSX_1): Likewise.
(BU_FLOAT128_HW_VSX_2): Likewise.
(scalar_extract_expq): Change float128 built-in functions to
accommodate having both KFmode and TFmode functions.  Use the
KFmode variant as the default.
(scalar_extract_sigq): Likewise.
(scalar_test_neg_qp): Likewise.
(scalar_insert_exp_q): Likewise.
(scalar_insert_exp_qp): Likewise.
(scalar_test_data_class_qp): Likewise.
(sqrtf128_round_to_odd): Delete processing the round to odd
built-in functions as special built-in functions, and define them
as float128 built-ins.  Use the KFmode variant as the default.
(truncf128_round_to_odd): Likewise.
(addf128_round_to_odd): Likewise.
(subf128_round_to_odd): Likewise.
(mulf128_round_to_odd): Likewise.
(divf128_round_to_odd): Likewise.
(fmaf128_round_to_odd): Likewise.
* config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Add
support for KFmode and TFmode xststdcqp calls.
(rs6000_expand_builtin): If long double is IEEE 128-bit floating
point, switch the built-in handlers for the get/set float128
exponent, get float128 mantissa, float128 test built-ins, and the
float128 round to odd built-in functions.  Eliminate creating the
float128 round to odd built-in functions as special built-ins.
(rs6000_init_builtins): Eliminate special creation of the float128
round to odd built-in functions.
* config/rs6000/vsx.md (xsxexpqp_): Change float128 built-in
function insns to support both TFmode and KFmode variants.
(xsxsigqp_): Likewise.
(xsiexpqpf_): Likewise.
(xsiexpqp_): Likewise.
(xststdcqp_): Likewise.
(xststdcnegqp_): Likewise.
(xststdcqp_): Likewise.

Back port from trunk
2017-11-06  Michael Meissner  

PR target/82748
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete
float128 helper macros, which are no longer used after deleting
the old 'q' built-in functions, and moving the round to odd
built-in functions to being special built-in functions.
(BU_FLOAT128_2): Likewise.
(BU_FLOAT128_1_HW): Likewise.
(BU_FLOAT128_2_HW): Likewise.
(BU_FLOAT128_3_HW): Likewise.
(FABSQ): Delete old 'q' built-in functions.
(COPYSIGNQ): Likewise.
(SQRTF128_ODD): Move round to odd built-in functions to be
special built-in functions, so that we can handle
-mabi=ieeelongdouble.
(TRUNCF128_ODD): Likewise.
(ADDF128_ODD): Likewise.
(SUBF128_ODD): Likewise.
(MULF128_ODD): Likewise.
(DIVF128_ODD): Likewise.
(FMAF128_ODD): Likewise.
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Map old 'q'
built-in names to 'f128'.
* config/rs6000/rs6000.c (rs6000_fold_builtin): Remove folding the
old 'q' built-in functions, as the machine independent code for
'f128' built-in functions handles this.
(rs6000_expand_builtin): Add expansion for float128 round to odd
functions, keying off on -mabi=ieeelongdouble of whether to use
the KFmode or TFmode variant.
(rs6000_init_builtins): Initialize the _Float128 round to odd
built-in functions.
* doc/extend.texi (PowerPC Built-in Functions): Document the old
_Float128 'q' built-in functions are now mapped into the new
'f128' built-in functions.


[gcc/testsuite]
2017-11-16  Michael Meissner  

Back port from trunk
2017-11-16  Michael Meissner  

* gcc.target/powerpc/bfp/bfp.exp: Look for *.c files, not *.c*
files to prevent ~ files from getting recognized.
* gcc.target/powerpc/dfp/dfp.exp: Likewise.
* gcc.target/powerpc/vsu/vsu.exp: Likewise.

Back port from trunk
2017-11-14  M

[Bug ipa/60243] IPA is slow on large cgraph tree

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #15 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #14)
> Author: hubicka
> Date: Fri Mar 28 19:50:28 2014
> New Revision: 208916
> 
> URL: http://gcc.gnu.org/viewcvs?rev=208916&root=gcc&view=rev
> Log:
>   PR ipa/60243
>   * ipa-inline.c (want_inline_small_function_p): Short circuit large
>   functions; reorganize to make cheap checks first.
>   (inline_small_functions): Do not estimate growth when dumping;
>   it is expensive.
>   * ipa-inline.h (inline_summary): Add min_size.
>   (growth_likely_positive): New function.
>   * ipa-inline-analysis.c (dump_inline_summary): Add min_size.
>   (set_cond_stmt_execution_predicate): Cleanup.
>   (estimate_edge_size_and_time): Compute min_size.
>   (estimate_calls_size_and_time): Likewise.
>   (estimate_node_size_and_time): Likewise.
>   (inline_update_overall_summary): Update min_size.
>   (do_estimate_edge_time): Likewise.
>   (do_estimate_edge_size): Update.
>   (do_estimate_edge_hints): Update.
>   (growth_likely_positive): New function.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/ipa-inline-analysis.c
> trunk/gcc/ipa-inline.c
> trunk/gcc/ipa-inline.h

Did this fix it?

[Bug lto/48724] Lto build of mozilla dies at lto-wrapper: error trying to exec 'make -j1': execvp: No such file or directory

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #9 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #8)
> This no longer happens with recent Firefox builds, but I think it was rather
> fixed at Firefox buildsystem...

That sounds like WORKSFORME then.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[egallager at gcc dot gnu.org]

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

Bug 48724 Summary: Lto build of mozilla dies at lto-wrapper: error trying to 
exec 'make -j1': execvp: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #11 from Eric Gallager  ---
(In reply to Martin Liška from comment #10)
> Is the issue still valid?

No response since you asked so I'm guessing not.

[Bug middle-end/83022] malloc & memset -> calloc is not always an optimization

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
I am pretty sure this was discussed when the patch was reviewed. IIRC the
original patch was specifically pattern-matching if(p!=0) (with p the result of
malloc) as the only acceptable condition between malloc and memset for this
transformation, but the move to the strlen pass made that inconvenient and it
was decided that always doing the transformation was ok (I hope I am not
rewriting history). If there is a way to check the probability of reaching the
call to memset from the call to malloc (preferably conditional to the fact that
malloc returned something != 0), that could be checked before generating
calloc, but that may not be easy... (compare the local count of the 2 BBs?
That's 1 and 3300 here, but I see you have already filed PR 83023 to
improve it)

Did you actually hit a measurable slowdown in a real application?

[Bug fortran/25829] [F03] Asynchronous IO support

[jb at gcc dot gnu.org]

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

--- Comment #32 from Janne Blomqvist  ---
Interestingly, Linux 4.14 contains a way to avoid a context switch to a
threadpool in case the data is already in the page cache:
https://kernelnewbies.org/Linux_4.14#head-8c8861fbded3e87631ab06bcd511f5f0d8bfa220

Might be an interesting optimization sometime in the future..

[Bug c++/83024] New: ICE in build_address, at cp/typeck.c:5623

[guille at berkeley dot edu]

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

Bug ID: 83024
   Summary: ICE in build_address, at cp/typeck.c:5623
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guille at berkeley dot edu
  Target Milestone: ---

The following short code ICEs on

$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 8.0.0 20171112 (experimental) (GCC)

Code that triggers ICE follows:
---
#include 

template  struct __optional: std::optional
{
__optional()= default;
__optional(T&& t)   : std::optional (std::move(t)) {}
operator bool () const { return (bool)(const std::optional&)*this; }   
// <- omit this line and it compiles fine
};

struct A : __optional
{
static __optional parse(auto& q)
{
return A{};
}
};

int main()
{
int q;
auto p = A::parse(q);
return 0;
}

ICE message follows:
-
$ c++ -fconcepts -std=c++1z tt.c -o tt
tt.c: In static member function ‘static __optional A::parse(auto:1&)’:
tt.c:14:12: internal compiler error: in build_address, at cp/typeck.c:5623
   return A{};
^
0x931657 build_address(tree_node*)
../../gcc/cp/typeck.c:5623
0x6fe147 add_function_candidate
../../gcc/cp/call.c:2166
0x6ffa87 add_candidates
../../gcc/cp/call.c:5522
0x6fab4e add_candidates
../../gcc/cp/call.c:5433
0x6fab4e build_user_type_conversion_1
../../gcc/cp/call.c:3849
0x6fc4f9 implicit_conversion
../../gcc/cp/call.c:1897
0x6f80a0 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:10559
0x94a905 check_return_expr(tree_node*, bool*)
../../gcc/cp/typeck.c:9218
0x8ee65e finish_return_stmt(tree_node*)
../../gcc/cp/semantics.c:893
0x843bd5 cp_parser_jump_statement
../../gcc/cp/parser.c:12483
0x843bd5 cp_parser_statement
../../gcc/cp/parser.c:10897
0x844b30 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11348
0x844c07 cp_parser_compound_statement
../../gcc/cp/parser.c:11302
0x85e2b1 cp_parser_function_body
../../gcc/cp/parser.c:21837
0x85e2b1 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21874
0x860ea6 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26765
0x8620fc cp_parser_late_parsing_for_member
../../gcc/cp/parser.c:27645
0x851c59 cp_parser_class_specifier_1
../../gcc/cp/parser.c:22728
0x853221 cp_parser_class_specifier
../../gcc/cp/parser.c:22754
0x853221 cp_parser_type_specifier
../../gcc/cp/parser.c:16818
Please submit a full bug report,

[Bug c++/83024] ICE in build_address, at cp/typeck.c:5623

[guille at berkeley dot edu]

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

--- Comment #1 from Guille  ---
I have tested the unsimplified version of this code, and it ICEs on every
version *after* gcc-8-20170827.