[Bug target/79932] _mm512_packus_epi32 does not compile under -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-07
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug target/69034] ICE: RTL check: expected elt 1 type 'e' or 'u', have 'i' (rtx unspec) in copy_replacements_1, at reload.c:6323 with -fPIC and "X" asm input

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
FYI: The latest version of my patch is here:

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01363.html


Unfortunately there was no consensus about it ...

[Bug sanitizer/79897] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.3.1, 7.0.1
 Resolution|--- |FIXED
   Target Milestone|--- |7.0
Summary|ICE in  |[7 Regression] ICE in
   |gimplify_modify_expr, at|gimplify_modify_expr, at
   |gimplify.c:5627 on ARM  |gimplify.c:5627 on ARM
   |target  |target
  Known to fail||7.0

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

[Bug sanitizer/79897] ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  7 06:11:14 2017
New Revision: 245945

URL: https://gcc.gnu.org/viewcvs?rev=245945=gcc=rev
Log:
PR sanitizer/79897
* ubsan.c (ubsan_encode_value): Call mark_addressable on the
temporary.

* c-c++-common/ubsan/pr79897.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr79897.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c

[Bug c/79927] 5.4.0: exponential notation triggers bogus "variably modified" warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
1e6 is floating point.  So:
>((1 << (sizeof(((struct my_struct *) 0)->n_usecs) * 8)) / ONE_MILLION
>= 16) - 1

is not integer constant expression.

[Bug libstdc++/79862] Compilation error while building libstdc++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Sumit from comment #6)
> Hi Andrew,
> 
> Somehow these files were missing in my package. I have recopied them back
> and things have moved further.
> 
> Now, I am seeing compilation error at :

> ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:523:5: error: unable
> to find string literal operator 'operator"" _ASSERT_STR'
>  assert(this->_M_kind != _Parameter::__unused_param);

Looks like the assert in assert.h vxworks has is not C++11 friendly.  Add a
space before the _ASSERT_STR.

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77978 for some history on the
change.

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
Well, from the comments I see in our matchers, the blank is required by F2008
Standard so we are enforcing that requirement.

From my copy of the standard:

3.3.2.2 Blank characters in free form

1) A blank shall be used to separate names, constants, or labels from adjacent
keywords, names, constants, or labels.

So I would put a blank in there and then forget about it.  I noticed that the
file has a scattering of TAB characters in there which are strictly speaking
forbidden, but we allow it. -Wtabs or -Wall will show where.

I would call this "not a bug"

[Bug libstdc++/79862] Compilation error while building libstdc++

[sbansal at ciena dot com]

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

--- Comment #6 from Sumit  ---
Hi Andrew,

Somehow these files were missing in my package. I have recopied them back and
things have moved further.

Now, I am seeing compilation error at :

../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc -o debug.o
In file included from
/home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/cassert:43:0,
 from
../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:31:
../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc: In member function
'void __gnu_debug::_Error_formatter::_Parameter::_M_print_field(const
__gnu_debug::_Error_formatter*, const char*) const':
../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:523:5: error: unable to
find string literal operator 'operator"" _ASSERT_STR'
 assert(this->_M_kind != _Parameter::__unused_param);
 ^
../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:531:6: error: unable to
find string literal operator 'operator"" _ASSERT_STR'
  assert(_M_variant._M_iterator._M_name);
  ^
../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:577:6: error: unable to
find string literal operator 'operator"" _ASSERT_STR'
  assert(_M_variant._M_iterator._M_sequence);

[Bug c/79936] ICE with -Walloc-size-larger-than=32767

[egall at gwmail dot gwu.edu]

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

--- Comment #3 from Eric Gallager  ---
Created attachment 40903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40903=edit
preprocessed source

(In reply to Andrew Pinski from comment #2)
> >Interestingly, the ICE seems to go away when I try to save the preprocessed
> >source to attach to this bug:
> 
> That usually might point to a GC issue.  still attach the preprocessed
> source and we can try to see what is going on.

OK, I did

[Bug c/79936] ICE with -Walloc-size-larger-than=32767

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
>Interestingly, the ICE seems to go away when I try to save the preprocessed 
>source to attach to this bug:

That usually might point to a GC issue.  still attach the preprocessed source
and we can try to see what is going on.

[Bug c/79936] ICE with -Walloc-size-larger-than=32767

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Can you create a translation unit by saving the output of the -E option and
attach it?  From the stack trace in attachment 40902 it looks like the abort is
in the diagnostic code (diagnostic_impl) and so not very likely to be directly
caused by the warning but we need to reproduce it to tell for sure.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[npickito at gmail dot com]

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

--- Comment #4 from Kito Cheng  ---
Hi Eric:
>> vfscanf.c: In function ‘_IO_vfscanf_internal’:
>> vfscanf.c:3050:1: error: unable to generate reloads for:
>> (insn 11026 11523 5651 1080 (set (reg:QI 3515)
>> (mem/c:QI (plus:SI (reg/f:SI 65 frame)
>> (const_int -1568 [0xf9e0])) [65 %sfp+-1504 S1
>> A32])) "vfscanf.c":266 138 {*movqi_internal}
>>  (expr_list:REG_DEAD (reg:QI 3956)
>> (nil)))

> I presume that it's not a valid address?  If so, why isn't it valid?

RISC-V have 12-bit signed immediate for offset (2047~-2048), so it's should be
valid address.




Here is another simple case in gcc testsuite:

riscv32-unknown-linux-gnu-gcc gcc/testsuite/gcc.c-torture/compile/pr52750.c -O0
-march=rv32imafd -mabi=ilp32d

/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c:
In function ‘foo’:
/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c:11:1:
error: unable to generate reloads for:
 }
 ^
(insn 194 197 145 2 (set (reg:QI 180)
(mem/c:QI (plus:SI (reg/f:SI 65 frame)
(const_int -268 [0xfef4])) [2 %sfp+-204 S1 A32]))
"/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c":10
138 {*movqi_internal}
 (expr_list:REG_DEAD (reg:QI 183)
(nil)))
/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c:11:1:
internal compiler error: in curr_insn_transform, at lra-constraints.c:3785
0xa9f298 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../src/gcc/trunk/gcc/rtl-error.c:108
0x9a2001 curr_insn_transform
../../../src/gcc/trunk/gcc/lra-constraints.c:3785
0x9a3286 lra_constraints(bool)
../../../src/gcc/trunk/gcc/lra-constraints.c:4754
0x98cf7c lra(_IO_FILE*)
../../../src/gcc/trunk/gcc/lra.c:2392
0x942ddb do_reload
../../../src/gcc/trunk/gcc/ira.c:5451
0x942ddb execute
../../../src/gcc/trunk/gcc/ira.c:5635
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/69034] ICE: RTL check: expected elt 1 type 'e' or 'u', have 'i' (rtx unspec) in copy_replacements_1, at reload.c:6323 with -fPIC and "X" asm input

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Segher Boessenkool  ---
Still fails on trunk (needs -mno-lra there, on powerpc -- the bug is
(exposed) in reload).

[Bug c/79936] New: ICE with -Walloc-size-larger-than=32767

[egall at gwmail dot gwu.edu]

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

Bug ID: 79936
   Summary: ICE with -Walloc-size-larger-than=32767
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: diagnostic, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin10.8.0
Target: x86_64-apple-darwin10.8.0
 Build: x86_64-apple-darwin10.8.0

Created attachment 40902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40902=edit
system-generated crash report

Found when compiling my fork of emacs:

$ make sha256.o V=1
/usr/local/bin/gcc -DHAVE_CONFIG_H -D_IN_GNULIB -I. -I../src  -I.
-I/Users/ericgallager/emacs/lib -I../src -I/Users/ericgallager/emacs/src
-DMAC_OSX=1   -DXASSERTS=1  -fno-common -Wabi -Waddress
-Waggressive-loop-optimizations -Wall -Wattributes -Wbool-compare
-Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wchkp -Wclobbered
-Wcomment -Wcoverage-mismatch -Wcpp -Wdate-time -Wdeprecated
-Wdeprecated-declarations -Wdesignated-init -Wdisabled-optimization
-Wdiscarded-array-qualifiers -Wdiscarded-qualifiers -Wdiv-by-zero
-Wduplicated-cond -Wempty-body -Wendif-labels -Wenum-compare -Wextra
-Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k
-Wformat-zero-length -Wframe-address -Wfree-nonheap-object -Whsa -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Winit-self -Wint-conversion -Wint-to-pointer-cast -Winvalid-memory-model
-Winvalid-pch -Wjump-misses-init -Wlogical-not-parentheses -Wmain
-Wmaybe-uninitialized -Wmemset-transposed-args -Wmisleading-indentation
-Wmissing-braces -Wmissing-declarations -Wmissing-include-dirs
-Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing -Wnonnull
-Wnonnull-compare -Wnull-dereference -Wold-style-declaration
-Wold-style-definition -Woverflow -Woverlength-strings -Woverride-init -Wpacked
-Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign
-Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type
-Wscalar-storage-order -Wsequence-point -Wshift-count-negative
-Wshift-count-overflow -Wshift-negative-value -Wsizeof-array-argument
-Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes
-Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-final-methods
-Wsuggest-final-types -Wswitch-bool -Wtautological-compare -Wtrampolines
-Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations
-Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function
-Wunused-label -Wunused-local-typedefs -Wunused-result -Wunused-value
-Wunused-variable -Wvarargs -Wvariadic-macros -Wvector-operation-performance
-Wvolatile-register-var -Wwrite-strings -Warray-bounds=2 -Wnormalized=nfc
-Wshift-overflow=2 -Wunused-const-variable=2 -Wno-missing-field-initializers
-Wno-sign-compare -Wno-type-limits -Wno-switch -Wno-unused-parameter
-Wno-format-nonliteral -Wno-logical-op -Wnonportable-cfstrings
-Wstrict-overflow=1 -Wdeclaration-after-statement -Wmissing-noreturn
-Wunreachable-code -Woverride-init-side-effects -Wshift-overflow=2
-Wdangling-else -Wduplicate-decl-specifier -Wmemset-elt-size
-Wswitch-unreachable -Wimplicit-fallthrough -Wformat-overflow=2
-Wformat-truncation=2 -Wstringop-overflow=2 -Wexpansion-to-defined -Wrestrict
-Wint-in-bool-context -Wpointer-compare -Wbool-operation -Wduplicated-branches
-Walloca-larger-than=16384 -Wvla-larger-than=16384
-Walloc-size-larger-than=32767 -Walloc-zero -Wpsabi
-Wbuiltin-declaration-mismatch   -ggdb3 -Og -gdwarf-2 -gfull -mfix-and-continue
-MT sha256.o -MD -MP -MF .deps/sha256.Tpo -c -o sha256.o sha256.c
sha256.c: In function 'sha256_stream':
sha256.c:181:9: warning: argument 1 value '32840' exceeds maximum object size
32767 [-Walloc-size-larger-than=]
   char *buffer = malloc (BLOCKSIZE + 72);
 ^~
In file included from ./stdlib.h:36:0,
 from ../src/conf_post.h:226,
 from ../src/config.h:3616,
 from sha256.c:23:
/usr/include/stdlib.h:169:7: note: in a call to allocation function 'malloc'
declared here
 void *malloc(size_t);
   ^~
sha256.c: In function 'sha224_stream':
sha256.c:252:9: internal compiler error: tree check: expected tree that
contains 'typed' structure, have 'block' in extended_tree, at tree.h:5286
   char *buffer = malloc (BLOCKSIZE + 72);
 ^~

sha256.c:252:9: internal compiler error: Abort trap
gcc: internal compiler error: Abort trap (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [sha256.o] Error 4


Interestingly, the ICE seems to go away when I try to save the preprocessed
source to attach to this 

[Bug target/79935] New: DJGPP: misaligned stack in static constructors

[jwjagersma at gmail dot com]

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

Bug ID: 79935
   Summary: DJGPP: misaligned stack in static constructors
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

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

See included test case. The aligned_t variables are meant to be aligned on a
16-byte boundary, but the alignment is 8 bytes off when used in static
constructors.

GCC version:
$ g++ -v
Using built-in specs.
COLLECT_GCC=D:\msys64\usr\local\djgpp\i586-pc-msdosdjgpp\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/msys64/usr/local/djgpp/lib/gcc/../../libexec/gcc/i586-pc-msdosdjgpp/6.1.0/lto-wrapper.exe
Target: i586-pc-msdosdjgpp
Configured with: ../gnu/gcc-6.10/configure --build=x86_64-w64-mingw32
--target=i586-pc-msdosdjgpp --program-prefix=i586-pc-msdosdjgpp-
--prefix=/usr/local/djgpp --disable-nls --disable-plugin --enable-lto
--enable-libquadmath-support
--with-gmp=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst
--with-mpfr=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst
--with-mpc=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: single
gcc version 6.1.0 (GCC)

[Bug tree-optimization/79934] New: Vectorization of descending-index loops can produce unnecessary permutes

[wschmidt at gcc dot gnu.org]

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

Bug ID: 79934
   Summary: Vectorization of descending-index loops can produce
unnecessary permutes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
CC: anton at samba dot org, rguenth at gcc dot gnu.org
  Target Milestone: ---

Consider

long *a, *c;
int b;
void d() {
  for (; b; b--)
a[b] |= c[b];
}

On POWER9, the core vectorized loop for this looks like this:

.L8:
lxvx 0,6,9   // load a[b] and a[b-1]
lxvx 12,8,9  // load c[b] and c[b-1]
xxpermdi 0,0,0,2 // swap elements of a
xxpermdi 12,12,12,2  // swap elements of c
xxlor 0,0,12 // produce a | c
xxpermdi 0,0,0,2 // swap elements of result
stxvx 0,6,9  // store a[b] and a[b-1]
addi 9,9,-16
bdnz .L8

The xxpermdi instructions are reversing the order of vector elements in a
register.  However, the only operation being performed on these values is
"lane-insensitive."  Since the swaps occur on all inputs and outputs to the
computation, and none of the values escape the iteration, performing the
operation in the "wrong" lanes does not affect the result.  Better code would
be:

.L8:
lxvx 0,6,9   // load a[b] and a[b-1]
lxvx 12,8,9  // load c[b] and c[b-1]
xxlor 0,0,12 // produce a | c in "wrong" lanes
stxvx 0,6,9  // store a[b] and a[b-1]
addi 9,9,-16
bdnz .L8

This code is introduced by the vectorizer:

   [55.08%]:
  # b.7_18 = PHI <_10(11), b.7_78(9)>
  # vectp.21_110 = PHI 
  # vectp.25_119 = PHI 
  # vectp.30_129 = PHI 
  # ivtmp_133 = PHI 
  _2 = (long unsigned int) b.7_18;
  _3 = _2 * 8;
  _4 = a.0_1 + _3;
  vect__5.23_112 = MEM[(long int *)vectp.21_110];
  vect__5.24_113 = VEC_PERM_EXPR ;
  _5 = *_4;
  _7 = c.2_6 + _3;
  vect__8.27_121 = MEM[(long int *)vectp.25_119];
  vect__8.28_122 = VEC_PERM_EXPR ;
  _8 = *_7;
  vect__9.29_123 = vect__5.24_113 | vect__8.28_122;
  _9 = _5 | _8;
  vect__9.32_131 = VEC_PERM_EXPR ;
  MEM[(long int *)vectp.30_129] = vect__9.32_131;
  _10 = b.7_18 + -1;
  vectp.21_111 = vectp.21_110 + 18446744073709551600;
  vectp.25_120 = vectp.25_119 + 18446744073709551600;
  vectp.30_130 = vectp.30_129 + 18446744073709551600;
  ivtmp_134 = ivtmp_133 + 1;
  if (ivtmp_134 < bnd.18_99)
goto ; [83.34%]
  else
goto ; [16.66%]

The unnecessary VEC_PERM_EXPRs (element reversals) could be removed after
vectorization by scanning for closed computations in each iteration having
these properties:

 - All loads feed into an element reversal and nothing else;
 - All stores are fed by an element reversal and nothing else;
 - All intermediate computations are lane-insensitive;
 - The computation has no other inputs than the element-reversed loads; and
 - The computation has no other outputs than the element-reversed stores.

This is quite similar to the requirements of the analyze_swaps() pass in the
POWER back end (rs6000.c), which is somewhat more general in that closed
computations aren't limited to a single loop iteration but can contain general
control flow.

[Bug fortran/79933] New: gfortran no longer able to compile dolfyn benchmark

[tulipawn at gmail dot com]

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

Bug ID: 79933
   Summary: gfortran no longer able to compile dolfyn benchmark
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Created attachment 40900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40900=edit
fortran source

Used to work fine a few months ago.

$ gfortran-7 -O2 gmsh2dolfyn.f90
gmsh2dolfyn.f90:159:9:

  stop'bug: error in dimensions of array v'
 1
Error: Blank required in STOP statement near (1)

Adding -std=f95 solves the issue so maybe some sort of suggestion is in order?

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[adam at aphirst dot karoo.co.uk]

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

--- Comment #8 from Adam Hirst  ---
Ah, it seems that Jerry was tinkering with tp_array.f90 (intrinsic array
version of the Vector type), while I was with tp_xyz.f90 (explicit separate
elements). I was going to remark at how he didn't need to use -flto to get any
of the matmul paths working better than the DO/SUM paths.

I'm curious as to whether he reproduces my results on his system, but I'll
first reproduce his.

1) When I use his modified TP_LEFT and compile only under -O2 I get, as he
does, that the matmul path is faster than the DO/SUM path. Not by as large a
margin, but I expect that this varies system-to-system.

2) I notice that he moved the matmul() calls out of the dot_product calls, but
didn't move the D%vec calls out of matmul. If I do the same with in tp_xyz.f90,
and recompile under simply -O2, I get the same kind of performance boost as
Jerry does.

What do you think the reason could be that:

Dx = D%x
Dy = D%y
Dz = D%z
NUDx = matmul(NU, Dx)
NUDy = matmul(NU, Dy)
NUDz = matmul(NU, Dz)
tensorproduct%x = ...

performs so much worse with -O2 than

NUDx = matmul(NU, D%x)
NUDy = matmul(NU, D%y)
NUDz = matmul(NU, D%z)
tensorproduct%x = ...

that the former needs -flto to be able to compete?

---

It's probably important that we remain clear on which version of the Vector
type we're doing the tests, as (as someone commented to me earlier, probably
Jerry), array-stride-shenanigans are bound to play some role.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[adam at aphirst dot karoo.co.uk]

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

--- Comment #7 from Adam Hirst  ---
OK, I tried a little harder, and was able to get a performance increase.

  type(Vect3D) pure function TP_LEFT(NU, D, NV) result(tensorproduct)
real(dp), intent(in) :: NU(4), NV(4)
type(Vect3D), intent(in) :: D(4,4)
real(dp) :: Dx(4,4), Dy(4,4), Dz(4,4), NUDx(4), NUDy(4),
NUDz(4)

Dx = D%x
Dy = D%y
Dz = D%z
NUDx = matmul(NU, Dx)
NUDy = matmul(NU, Dy)
NUDz = matmul(NU, Dz)
tensorproduct%x = dot_product(NUDx,NV)
tensorproduct%y = dot_product(NUDy,NV)
tensorproduct%z = dot_product(NUDz,NV)
  end function

The result of this (still using -Ofast) is that the matmul path sped up by a
factor of about 6 (on my machine), which would have placed it now faster than
the "explicit DO" approach, but that too gained a huge reduction under -Ofast,
so the result is that matmul here is about half as fast as the explicit loop.

But here is where things get really interesting. If also use -flto on this
post's matmul codepath, I get the result that the matmul implementation is
twice as fast as the (already now VERY fast) DO-implementation. This huge boost
doesn't seem to apply to the version of TP_LEFT from my previous post, nor to
the original TP_LEFT from the initial ticket submission.

In conclusion: It seems that your remark about matmul inlining also applies to
dot_product.

NOTE: For the -flto tests, gcc is clever enough to realise that we're not
actually using these results, so I have to save tp(1:i_max) and have the user
specify an element to print, in order to force the computation. I of course put
those "outside" each pair of cpu_time calls.

As an aside, I also tried the effect of -fexpensive-optimizations but it did
more or less nothing.

---

By the way, are there any thoughts yet on the random number calls taking
/longer/ once optimisations are enabled? If I'm reading my results right, -flto
seems to "fix" that, but it doesn't seem obvious that it should be occurring in
the first place.

[Bug target/79932] New: _mm512_packus_epi32 does not compile under -O0

[carloscastro10 at hotmail dot com]

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

Bug ID: 79932
   Summary: _mm512_packus_epi32 does not compile under -O0
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carloscastro10 at hotmail dot com
  Target Milestone: ---

The _mm512_packus_epi32 intrinsic compiles fine under -Og, -O2, -O3, but does
not compile under -O0. For a simple example consider the following code:

#include 

__m512i packus(__m512i a)
{

  return _mm512_packus_epi32(a,a);
}

Try compiling with "-march=skylake-avx512 -O0". It will fail. However, under
-Og, -O2, or -O3 it will compile fine.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Thanks Thomas, somehow I thought we would have built the temporary to do this.
(Well actully we do, but after the frontend passes)

Now we get:

$ gfc -O2 tp_array.f90 
$ time ./a.out 
 This code variant uses intrinsic arrays to represent the contents of
Type(Vect3D).
 Random Numbers, time: 43.6485367
 Using SUM, time:  2.20666122
 Using MATMUL (L), time:   1.58225632
 Using MATMUL (R), time:   7.54129410 

Where the LEFT case I did this:

  type(Vect3D) pure function TP_LEFT(NU, D, NV) result(tensorproduct)
real(dp), intent(in) :: NU(4), NV(4)
real(dp) :: tmp(4)
type(Vect3D), intent(in) :: D(4,4)

tmp = matmul(NU, D%vec(1))
tensorproduct%vec(1) = dot_product(tmp, NV) ! "left"
tmp = matmul(NU, D%vec(2))
tensorproduct%vec(2) = dot_product(tmp, NV)
tmp = matmul(NU, D%vec(2))
tensorproduct%vec(3) = dot_product(tmp, NV) ! gives more expected results
  end function

and just for grins:

$ gfc -Ofast -march=native -ftree-vectorize tp_array.f90 
$ time ./a.out 
 This code variant uses intrinsic arrays to represent the contents of
Type(Vect3D).
 Random Numbers, time: 42.7615433
 Using SUM, time: 0.741546631
 Using MATMUL (L), time:  0.522426605
 Using MATMUL (R), time:   6.76409149

real0m51.331s
user0m50.389s
sys 0m0.501s

So we need to be careful how we use the tool to get the most out of the
optimizers.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[adam at aphirst dot karoo.co.uk]

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

--- Comment #5 from Adam Hirst  ---
Hmm, even with -Ofast, I don't get any noticeable performance increase if I
change, say, TP_LEFT, to be:

  type(Vect3D) pure function TP_LEFT(NU, D, NV) result(tensorproduct)
real(dp), intent(in) :: NU(4), NV(4)
type(Vect3D), intent(in) :: D(4,4)
real(dp) :: Dx(4,4), Dy(4,4), Dz(4,4)

Dx = D%x
Dy = D%y
Dz = D%z
tensorproduct%x = dot_product(matmul(NU, Dx),NV)
tensorproduct%y = dot_product(matmul(NU, Dy),NV)
tensorproduct%z = dot_product(matmul(NU, Dz),NV)
  end function

Perhaps you meant to introduce the explicit temporaries at a different level,
or there's another flag I need.

It's worth maybe noting, though, that -Ofast makes the "explicit DO"
implementation EVEN faster, so I'll in the meantime definitely investigate
reintroducing -Ofast to my real codebase.

[Bug c++/71543] [concepts] ICE on ill-formed declaration of a parameter with a constrained-type-specifier in a requires expression

[jetrull at sbcglobal dot net]

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

Jeff Trull  changed:

   What|Removed |Added

 CC||jetrull at sbcglobal dot net

--- Comment #1 from Jeff Trull  ---
Created attachment 40899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40899=edit
repo test case for confirming bug

I observe the (seemingly) same ICE with 7.0.1 on Compiler Explorer
(https://godbolt.org/) today with the attached code.

[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681

[lopezibanez at gmail dot com]

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

--- Comment #3 from Manuel López-Ibáñez  ---
Perhaps Fortran FE formatters can call the standard formatters if an
unknown directive is found? I don't know how C/C++ handles this case (does
it support this %-directive or does it switch to the standard pretty
printer?) but there is no reason to not do the same and share the code if
possible.

[Bug c/79918] Feature request: Warning about (may potential) misaligned address-reference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Confirmed.  A warning on accesses to packed members could be helpful.

[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The assert:
  gcc_assert (targets.length () <= len);

[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Related to PR 66301 but not exactly the same.
here is the full testcase:
cc1plus: internal compiler error: in dump_possible_polymorphic_call_targets, at
ipa-devirt.c:3361
0xb6b53b dump_possible_polymorphic_call_targets(_IO_FILE*, tree_node*, long,
ipa_polymorphic_call_context const&)
../../gcc/gcc/ipa-devirt.c:3361
0x96e693 dump_possible_polymorphic_call_targets(_IO_FILE*, cgraph_edge*)
../../gcc/gcc/ipa-utils.h:144
0x96e693 walk_polymorphic_call_targets
../../gcc/gcc/cgraphunit.c:849
0x96e693 analyze_functions
../../gcc/gcc/cgraphunit.c:1115
0x96f3f7 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Fixed by following commits on hppa64-*-*:
https://gcc.gnu.org/ml/gcc-cvs/2017-03/msg00134.html
https://gcc.gnu.org/ml/gcc-cvs/2017-03/msg00136.html
https://gcc.gnu.org/ml/gcc-cvs/2017-03/msg00137.html

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Currently, we only inline statements of the form

a = matmul(b,c)

so the more complex expressions in your code are not
inlined (and thus slow).  This is a known limitation,
which will not be fixed in time for gcc 7. Maybe 8...

If you want to use matmul, you would need to insert
temporaries by hand.  Also make sure to add flags
which allow reassociation (such as -Ofast); otherwise
the optimizer might not work well.

[Bug rtl-optimization/79858] Explain to translators what %smode means

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Yes, the whole %smode should stay as is somewhere in the translation.

[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[jeremyhu at macports dot org]

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

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

Summary|fix-includes does not honor |--with-build-sysroot= does
   |the value passed to |not get honored throughout
   |--with-build-sysroot=,  |the build (fix-includes,
   |looks for /usr/include  |CPP, CXXCPP,
   |instead of looking within   |configure-stage2)
   |the SDK |

--- Comment #7 from Jeremy Huddleston Sequoia  ---
Retitled to make the issue more clear/generic.

Note that using --with-sysroot, I'm able to get a built compiler, but the
result ends up using the configured sysroot as its default sysroot (as one
would expect based on the documentation for --with-sysroot).

My understanding is that --with-build-sysroot should behave the same as
--with-sysroot *except* that the installed compiler's default is modified by
--with-sysroot and not modified by --with-build-sysroot.

[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar  6 22:51:23 2017
New Revision: 245932

URL: https://gcc.gnu.org/viewcvs?rev=245932=gcc=rev
Log:
PR c++/79821
* dwarf2out.h (dw_vec_const): Change array type from unsigned char *
to void * for PCH reasons.
* dwarf2out.c (output_loc_operands, output_die): Cast
v.val_vec.array to unsigned char *.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/dwarf2out.h

[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||5.4.0, 7.0

--- Comment #1 from Andrew Pinski  ---
Also ICEs with:
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)


I don't know if Ubuntu has patches in their gcc or not which causes this ICE.

[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register

[meissner at gcc dot gnu.org]

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

--- Comment #11 from Michael Meissner  ---
Author: meissner
Date: Mon Mar  6 22:47:03 2017
New Revision: 245930

URL: https://gcc.gnu.org/viewcvs?rev=245930=gcc=rev
Log:
[gcc]
2017-03-06  Michael Meissner  

Back port from trunk
2017-03-01  Michael Meissner  

PR target/79439
* config/rs6000/predicates.md (current_file_function_operand): Do
not allow self calls to be local if the function is replaceable.

[gcc/testsuite]
2017-03-06  Michael Meissner  

Back port from trunk
2017-03-01  Michael Meissner  

PR target/79439
* gcc.target/powerpc/pr79439.c: New test.



Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr79439.c
  - copied, changed from r245813,
trunk/gcc/testsuite/gcc.target/powerpc/pr79439.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/predicates.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/28254] ICE with invalid class$

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #2 from Volker Reichelt  ---
Fixed in GCC 7, because Java was removed.
The code now produces a proper error message.

[Bug ipa/79931] New: ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

[pinskia at gcc dot gnu.org]

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

Bug ID: 79931
   Summary: ICE in dump_possible_polymorphic_call_targets with
-fdump-ipa-all -O2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

While adding a new pass, I noticed this ICE (tested with a plain version of GCC
also).
testcase:

class DocumentImpl;
struct NodeImpl
{
  virtual DocumentImpl * getOwnerDocument();
  virtual NodeImpl * getParentNode();
  virtual NodeImpl * removeChild(NodeImpl *oldChild);
};
struct AttrImpl : NodeImpl
{
  NodeImpl *insertBefore(NodeImpl *newChild, NodeImpl *refChild);
};
struct DocumentImpl : NodeImpl
{
  virtual NodeImpl *removeChild(NodeImpl *oldChild);
  virtual int* getRanges();
};
NodeImpl *AttrImpl::insertBefore(NodeImpl *newChild, NodeImpl *refChild) {
  NodeImpl *oldparent = newChild->getParentNode();
  oldparent->removeChild(newChild);
  this->getOwnerDocument()->getRanges();
}

--- CUT ---

This is reduced from 483.xalancbmk in SPEC CPU 2006.
Compile with -fdump-ipa-all -O2 and the ICE will produce.

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Le 6 mars 2017 à 16:55, tkoenig at gcc dot gnu.org  
> a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
> 
> --- Comment #3 from Thomas Koenig  ---
> On my Linux system, I can get a crash with
> 
> OMP_STACKSIZE=500k ./a.out
> 
> and successfull execution with
> 
> OMP_STACKSIZE=1M ./a.out
> 
> What happens if you try these commands?

I see the same behavior: crash up to 799k, successful execution above 800k.

Dominique

> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[anlauf at gmx dot de]

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

--- Comment #1 from Harald Anlauf  ---
Possibly related to PR78758, which is already fixed.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[adam at aphirst dot karoo.co.uk]

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

--- Comment #3 from Adam Hirst  ---
Created attachment 40898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40898=edit
Implementation using dimension(3) member

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[adam at aphirst dot karoo.co.uk]

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

--- Comment #2 from Adam Hirst  ---
Created attachment 40897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40897=edit
Implementation using %x %y and %z members

Will post the source code here as attachments.

[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I wouldn't call layout_type a middle-end, rather a helper shared by all FEs.
It would be best if the Fortran formatters were limited only to the Fortran
specific diagnostic functions (gfc_*) and error/error_at/warning_at etc. just
used the standard formatters.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
Need the attachments. Adding Thomasto cc

[Bug fortran/79930] New: Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[adam at aphirst dot karoo.co.uk]

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

Bug ID: 79930
   Summary: Potentially Missed Optimisation for MATMUL /
DOT_PRODUCT
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at aphirst dot karoo.co.uk
  Target Milestone: ---

In my codebase I'm performing many "Tensor Products", which is by far the
hottest routine. This is something like

tp = NU^T * P * NV
result [3-vector] = [4-vector]^T [4x4 "matrix" of 3-vectors] [4-vector]

I implement this in three different ways

1) use an explicit do (concurrent) loop over i and j returning a 4x4 result
"matrix", then respectively sum the x, y and z components of that into a single
result 3-vector.
2) use three separate matmul + dot_product calls (one for x, y and z),
dot_product(matmul(NU,P),NV)
3) the same, but the other way around, so dot_product(NU,matmul(P,NV))

My code is posted at
https://gist.github.com/aphirst/75e0599e2d4b14d182b52daaa6a74098 and after
discussing at length with JerryD and dominiq in IRC I'd like to summarise our
findings.

0) There are two versions of the test code, one where the 3-vector is
implemented as just a real dimension(3) member, the other as three separate %x
%y and %z members. Across all tests described below, the performance difference
was almost negligible, on my machine only slightly favouring the dimension(3)
implementation.
1) With no optimisations, and -fcheck=all, both "Vector" implementations yield
the "explicit DO" approach as being twice as slow as the matmul approach. This
case is the exception, presumably as -fcheck=all is heavily penalising the
explicit looping.
2) With no optimisations, and no -fcheck, both "Vector" implementations yield
the "explicit DO" approach about 1.5x as fast as one matmul orientation, and
very slightly slower than the other.
3) With -Og, regardless of -fcheck, both "Vector" implementations yield the
"explicit DO" approach to be either twice as fast as, or 1.5x as fast as, the
matmul orientations. Interestingly, the random number generation now takes an
extra 15% or so longer than with no optimisations.
4) Same for -O2, also regardless of -fcheck, except the difference between the
"explicit DO" and matmul approaches is slightly larger.

So to summarise:
* For some reason, either matmul or dot_product is missing some sort of
optimisation here. Whether or not this is actually possible isn't my
prerogative to say, but JerryD said that according to the tree dump, the matmul
isn't being inlined.
* Random number generation surely shouldn't take longer with optimisations than
without, should it?

---

I'm running on Arch Linux (x86_64), and gfortran -v gives:

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

[Bug sanitizer/79897] ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 40896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40896=edit
gcc7-pr79897.patch

Untested fix.  Without the patch fails on x86_64-linux with -m32 as well.

[Bug fortran/79929] New: [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[anlauf at gmx dot de]

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

Bug ID: 79929
   Summary: [7 Regression] Bogus Warning: '__builtin_memset':
specified size 4294967291 exceeds maximum object size
2147483647
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de
  Target Milestone: ---

Hi all,

for trunk rev.245718, GNU Fortran (GCC) 7.0.1 20170224 (experimental),
the code:

% cat gfcbug138.f90
subroutine gfcbug138 (yerrmsg)
  character(*) :: yerrmsg
  yerrmsg = ""
  yerrmsg = "bug: " // yerrmsg
end subroutine gfcbug138

produces

% gfc-trunk -Wall -c gfcbug138.f90 -O1
gfcbug138.f90:4:0:

   yerrmsg = "bug: " // yerrmsg

Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object
size 2147483647 [-Wstringop-overflow=]

at -O1, -O2, -O3, but not at -O0.

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Sorry, I can not reproduce the bug.  I built a cross-compiler configured as
--target=ppc64le-linux-gnu on today trunk.

[Bug target/79928] New: nds32: misspelled diagnostic: not support -fpic

[roland.illig at gmx dot de]

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

Bug ID: 79928
   Summary: nds32: misspelled diagnostic: not support -fpic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from config/nds32/nds32.c:

sorry ("not support -fpic");

As the German translator, am I supposed to translate this with incorrect
grammar? Since I don't know the nds32 architecture, I might be missing an
inside joke here. Or is the grammar accidentally wrong?

[Bug c/79927] New: 5.4.0: exponential notation triggers bogus "variably modified" warning

[dtikhonov at litespeedtech dot com]

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

Bug ID: 79927
   Summary: 5.4.0: exponential notation triggers bogus "variably
modified" warning
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dtikhonov at litespeedtech dot com
  Target Milestone: ---

I use a compile-time check to make sure that a particular value is correct:

-- 8< --
struct my_struct {
unsigned char   n_usecs[3];
};

#ifndef ONE_MILLION
#   define ONE_MILLION 1e6
#endif

/* Compile-time check that n_usecs holds at least 16 seconds worth. */
typedef char holds_at_least_16_seconds[
((1 << (sizeof(((struct my_struct *) 0)->n_usecs) * 8)) / ONE_MILLION
>= 16) - 1];

int
main (void)
{
return 0;
}
-- 8< --

Using 1e6 instead of 100 produces the following warning:

1e6.c:15:65: warning: variably modified ‘holds_at_least_16_seconds’ at file
scope
 >= 16) - 1];
 ^

I reproduced this using 5.4.0 and 4.9.4 versions of gcc.

[Bug target/79907] ICE in extract_constrain_insn, at recog.c:2213 on ppc64le

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-06
 CC||pthaugen at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pthaugen at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #16 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Mar  6 20:23:00 2017
New Revision: 245928

URL: https://gcc.gnu.org/viewcvs?rev=245928=gcc=rev
Log:
2017-03-06  Vladimir Makarov  

PR rtl-optimization/79571
* lra-constraints.c (process_alt_operands): Claculate static
reject and subtract it from overal when there will be only address
reloads.

2017-03-06  Vladimir Makarov  

PR rtl-optimization/79571
* gcc.target/i386/pr79571.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr79571.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79926] New: i386: untranslated placeholder "exception/interrupt" in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 79926
   Summary: i386: untranslated placeholder "exception/interrupt"
in diagnostic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from config/i386/i386.c:

sorry ("%s instructions aren't allowed in %s service routine",
   isa, (cfun->machine->func_type == TYPE_EXCEPTION
 ? "exception" : "interrupt"));

The word "exception" or "interrupt" cannot be translated by the i18n
translator, since it is inserted verbatimly. This leads to mixed language in
the diagnostics.

See bug 79868 for more examples of this kind.

[Bug target/79925] New: aarch64: misplaced quote in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 79925
   Summary: aarch64: misplaced quote in diagnostic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from config/aarch64/aarch64.c:

error ("invalid feature modifier in -mcpu=%qs", str);

The quotes should be around »-mcpu=given-value«, not around
-mcpu=»given-value«.

[Bug target/79924] New: aarch64: untranslated diagnostics in aarch64_err_no_fpadvsimd

[roland.illig at gmx dot de]

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

Bug ID: 79924
   Summary: aarch64: untranslated diagnostics in
aarch64_err_no_fpadvsimd
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

In config/aarch64/aarch64.c, the function aarch64_err_no_fpadvsimd assembles
diagnostics using plain string concatenation, leaving some elements
untranslated.

%qs is incompatible with %s %s

Translated into German, this becomes:

%qs ist inkompatibel zu floating-point return type

Whereas the proper translation is:

%qs ist inkompatibel zu Gleitkomma-Rückgabetyp

See bug 79868 for more examples of the same type.

[Bug other/79923] New: diagnostics: some diagnostics have trailing period

[roland.illig at gmx dot de]

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

Bug ID: 79923
   Summary: diagnostics: some diagnostics have trailing period
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Most diagnostics don't end with a period. But some do. Most of them can be
found using this perl-compatible regular expression:

\b(warning|warning_at|error)\s*\(.*\."\)

These diagnostics should have the trailing period removed.

In gcc-7-20170226, there are 35 occurrences in the code.

[Bug c/79922] New: i18n: unnecessary plural form translation in "passing argument %d"

[roland.illig at gmx dot de]

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

Bug ID: 79922
   Summary: i18n: unnecessary plural form translation in "passing
argument %d"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from c-family/c-warn.c:

  warning_at_rich_loc_n (, OPT_Wrestrict, arg_positions.length (),
 "passing argument %i to restrict-qualified parameter"
 " aliases with argument %Z",
 "passing argument %i to restrict-qualified parameter"
 " aliases with arguments %Z",
 param_pos + 1, arg_positions.address (),
 arg_positions.length ());

Translating plural forms is only necessary when the sentence contains "%i
argument(s)", but not when it contains "argument %i".

There are several other places where "argument %d" appears in the i18n
messages, apparently without any complaints by translators.

[Bug c/79921] New: missing translation for "...this statement, but the latter is misleadingly indented"

[roland.illig at gmx dot de]

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

Bug ID: 79921
   Summary: missing translation for "...this statement, but the
latter is misleadingly indented"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from c-family/c-indentation.c:

if (warning_at (guard_tinfo.location, OPT_Wmisleading_indentation,
"this %qs clause does not guard...",
guard_tinfo_to_string (guard_tinfo)))
  inform (next_tinfo.location,
  ("...this statement, but the latter is misleadingly indented"
   " as if it were guarded by the %qs"),
  guard_tinfo_to_string (guard_tinfo));

The first string literal ("this %qs...") appears in the gcc.pot file and is
thus being translated. The second string literal ("...this statement") doesn't
appear in gcc.pot and therefore cannot be translated.

The cause may be the parentheses around the two string literals, which are
unnecessary.

In general, there should be a consistency check for cases like these, checking
that the argument to all calls to the i18n functions are string literals or
concatenations thereof. This check should flag the above one, as well as the
following code from s390.md:

error ("invalid transaction abort code: " HOST_WIDE_INT_PRINT_DEC

[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
Not sure what that means:

When UBSAN_CHECK_MUL is expanded, the generated Rtl wants the vector constant
"3" in the litaral pool (insn 30):

--
;; _2 = UBSAN_CHECK_MUL (_1, { 11, 22, 33, 44, 0, 0, 0, 0 });
(insn 23 22 24 (set (reg:DI 69) (const_int 0 [0]))
(code_label 24 23 25 4 (nil) [0 uses])
(insn 25 24 26 (set (mem/c:DI (plus:DI (reg/f:DI 55 virtual-stack-vars)
(const_int -24 [0xffe8])) [0  S8 A64])
(reg:DI 60 [ _1 ]))
(insn 26 25 27 (set (reg:QI 72)
(mem/j:QI (plus:DI (plus:DI (reg/f:DI 55 virtual-stack-vars)
(reg:DI 69))
(const_int -24 [0xffe8])) [0  S1 A8]))
(insn 27 26 28 (set (reg:SI 71)
(ashift:SI (subreg:SI (reg:QI 72) 0)
(const_int 24 [0x18]))) "/home/vogt/z.c":5 -1
(insn 28 27 29 (parallel [
(set (reg:SI 71)
(ashiftrt:SI (reg:SI 71)
(const_int 24 [0x18])))
(clobber (reg:CC 33 %cc))
(insn 29 28 30 (set (reg:HI 70)
(subreg:HI (reg:SI 71) 2))
(insn 30 29 31 (set (reg:QI 75)
(mem/u/j:QI (plus:DI (reg:DI 69)
(symbol_ref/u:DI ("*.LC1") [flags 0x2])) [0  S1 A8]))
 ^
...
--

Without Ubsan, each byte of the vector is expanded to separate code, loading
the constant and the vector element and multiplying both, without involving the
literal pool.  Is that the fault of the backend (i.e. not supporting vector Gcc
constants in the literal pool; or not telling Ubsan that vector constants are
not supported) or the fault of the Ubsan code that generates a literal pool Gcc
vector constant when it shouldn't?

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-03/msg00264.ht
   ||ml

--- Comment #14 from Peter Bergner  ---
Patch submitted.

[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-06
 Ever confirmed|0   |1

[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909

[vogt at linux dot vnet.ibm.com]

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

--- Comment #2 from Dominik Vogt  ---
Reduced test:

--
typedef signed char V __attribute__((vector_size (8))); 
void foo (V *a) 
{ 
  *a = *a * 3; 
}
--

$ gcc -fsanitize=undefined ...

[Bug c++/79796] [5/6 Regression] ICE with NSDMI and this pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
Summary|[5/6/7 Regression] ICE with |[5/6 Regression] ICE with
   |NSDMI and this pointer  |NSDMI and this pointer

--- Comment #7 from Marek Polacek  ---
Fixed on the trunk so far.

[Bug c++/79796] [5/6/7 Regression] ICE with NSDMI and this pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Mon Mar  6 17:38:42 2017
New Revision: 245927

URL: https://gcc.gnu.org/viewcvs?rev=245927=gcc=rev
Log:
PR c++/79796 - ICE with NSDMI and this pointer
* call.c (build_over_call): Handle NSDMI with a 'this' by calling
replace_placeholders.

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

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69143] PowerPC64: aggregate results are badly handled

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #5 from Segher Boessenkool  ---
The SFs are converted to SI and back, which perhaps would work out
fine except that the SI->SF is an unspec (UNSPEC_SF_FROM_SI), and
that won't optimise.

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 on mips with -mlong-calls

[jan.smets at nokia dot com]

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

--- Comment #1 from Jan Smets  ---
Sorry, copy/pasted incorrect libtool compile, it's the one of
libstdc++-v3/src/c++98/strstream.cc
Also, occurs at any optimisation level.

libtool: compile:  /jasmets/git/tools/toolchains/gcc6/gcc-builddir/./gcc/xgcc
-shared-libgcc -B/jasmets/git/tools/toolchains/gcc6/gcc-builddir/./gcc
-nostdinc++ -L/jasm
ets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/src
-L/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long
-calls/O0/libstdc++-v3/src/.libs
-L/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/libsupc++/.libs
-B/jasmets/git/tools/t
oolchains/gcc6/prefix/mips-wrs-vxworks/bin/
-B/jasmets/git/tools/toolchains/gcc6/prefix/mips-wrs-vxworks/lib/ -isystem
/jasmets/git/tools/toolchains/gcc6/prefix/mips-wr
s-vxworks/include -isystem
/jasmets/git/tools/toolchains/gcc6/prefix/mips-wrs-vxworks/sys-include -mabi=64
-mlong-calls -O0 -I/jasmets/git/tools/toolchains/gcc6/gcc-bui
lddir/gcc-6.3.1/libstdc++-v3/../libgcc
-I/jasmets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/include/mips-wrs-vxworks
-I/jasm
ets/git/tools/toolchains/gcc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/include
-I/jasmets/git/tools/toolchains/gcc6/gcc-builddir/gcc-6.3.1/libstdc++-
v3/libsupc++ -std=gnu++98 -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -
frandom-seed=strstream.lo -O2 -fno-optimize-sibling-calls -fno-partial-inlining
-fasynchronous-unwind-tables -mabi=64 -mlong-calls -O0
-I/jasmets/git/tools/toolchains/g
cc6/gcc-builddir/mips-wrs-vxworks/64/long-calls/O0/libstdc++-v3/include/backward
-Wno-deprecated -c
../../../../../../.././gcc-6.3.1/libstdc++-v3/src/c++98/strstream.cc -o
strstream.o

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
Version|6.1.0   |7.0

--- Comment #3 from Eric Botcazou  ---
> vfscanf.c: In function ‘_IO_vfscanf_internal’:
> vfscanf.c:3050:1: error: unable to generate reloads for:
> (insn 11026 11523 5651 1080 (set (reg:QI 3515)
> (mem/c:QI (plus:SI (reg/f:SI 65 frame)
> (const_int -1568 [0xf9e0])) [65 %sfp+-1504 S1
> A32])) "vfscanf.c":266 138 {*movqi_internal}
>  (expr_list:REG_DEAD (reg:QI 3956)
> (nil)))

I presume that it's not a valid address?  If so, why isn't it valid?

[Bug sanitizer/79897] ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Another observation: doesn't ICE with -fsigned-char.

[Bug c++/79857] cgraph_node::verify_node should call internal_error instead of error

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
Assuming that the diagnostics containing words like "edge" or "BB" are
presented to the GCC user, how are they going to make any use of them?

Or "cgraph_node has wrong clone_of"? As a programmer, I have no idea what this
might mean. Therefore this should be made an internal error, or alternatively
be reworded so that it is understandable to a GCC user who doesn't know
anything about GIMPLE or RTL.

[Bug sanitizer/79897] ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
-fsanitize=enum is enough.

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-06
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed with a cross compiler.

[Bug rtl-optimization/79858] Explain to translators what %smode means

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
What about the letters "mode"? Are they to be translated? Or should the
resulting text, even in Arabic, be "QImode"?

[Bug c/79920] New: Incorrect floating point results when compiling with -O3

[wence at gmx dot li]

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

Bug ID: 79920
   Summary: Incorrect floating point results when compiling with
-O3
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wence at gmx dot li
  Target Milestone: ---

Created attachment 40895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40895=edit
Preprocessed source

The attached (preprocessed) code, which should produce the answer "12",
produces "0" when compiled with -O3 using gcc 6.3.0, and also a 7.0.0 snapshot
I had access to.

Details:

$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/6.3.0_1/libexec/gcc/x86_64-apple-darwin16.3.0/6.3.0/lto-wrapper
Target: x86_64-apple-darwin16.3.0
Configured with: ../configure --build=x86_64-apple-darwin16.3.0
--prefix=/usr/local/Cellar/gcc/6.3.0_1
--libdir=/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-6
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew GCC 6.3.0_1'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 6.3.0 (Homebrew GCC 6.3.0_1)

Also occurs with:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) 

and
$ gcc-snapshot -v
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
20161006-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --program-prefix= --enable-shared
--enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=yes
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.0.0 20161006 (experimental) [trunk revision 240826] (Ubuntu
20161006-1ubuntu1) 

Steps to reproduce:
$ gcc-6 -O3 -save-temps bug.c -o bug; ./bug
0 # expected 12

Debugging the execution, it looks like the initialisation of t33 is wrong. 
After the  first nested loop (on line 20), every entry of t33 ought to be 1,
however, when compiling with -O3, every entry is 0.

Bug goes away if I constant-fold t43 (either into the initialisation list or
the increment into A).

[Bug sanitizer/79897] ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-06
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Reproduced with a cross (--target=arm-linux-gnueabi).

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 7.

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Mar  6 16:08:59 2017
New Revision: 245926

URL: https://gcc.gnu.org/viewcvs?rev=245926=gcc=rev
Log:
Set incoming stack boundary to 128 for 64-bit targets

For 64-bit targets, the incoming stack of interrupt handler is aligned
to 16 bytes.  Update ix86_minimum_incoming_stack_boundary to set the
incoming stack boundary of interrupt handler to 128 for 64-bit targets.

gcc/

2017-03-06  Julia Koval  

PR target/79793
* config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Set
incoming stack boundary to 128 for 64-bit targets.

gcc/testsuite/

2017-03-06  Julia Koval  

PR target/79793
 * gcc.target/i386/interrupt-12.c: Update scan-assembler-times
 directives.
 * gcc.target/i386/interrupt-13.c: Ditto.
 * gcc.target/i386/interrupt-14.c: Ditto.
 * gcc.target/i386/interrupt-15.c: Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/interrupt-12.c
trunk/gcc/testsuite/gcc.target/i386/interrupt-13.c
trunk/gcc/testsuite/gcc.target/i386/interrupt-14.c
trunk/gcc/testsuite/gcc.target/i386/interrupt-15.c

[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
On my Linux system, I can get a crash with

OMP_STACKSIZE=500k ./a.out

and successfull execution with

OMP_STACKSIZE=1M ./a.out

What happens if you try these commands?

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-06
 Ever confirmed|0   |1

--- Comment #13 from Peter Bergner  ---
(In reply to Matthias Klose from comment #10)
> here is one more build failure seen with 20170221, with -O1 (works with
> -O0), seen in the gtk-gnutella package:

I have a patch that fixes this and the original test case.

[Bug c++/79919] New: Warning specifiedsend of method instead of correct line

[amacleod at redhat dot com]

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

Bug ID: 79919
   Summary: Warning specifiedsend of method instead of correct
line
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amacleod at redhat dot com
  Target Milestone: ---

Just stumbled across as useful warning, but the line number didn't help since
it specified the end of the method instead of the line the error was actually
on. 

Reduced to:

extern void foo ();
enum s { RS_INV, RS_I, RS_S };

class c {
  enum s state;
  int op2;
  void dump ();
};

void c::dump ()
{ 
  if (op2 && state == RS_I && state == RS_S)
foo();
}

produces:

./xg++  -B./ foo.c -O2  -c
foo.c: In member function ‘void c::dump()’:
foo.c:14:1: warning: ‘and’ of mutually exclusive equal-tests is always 0
 }
 ^

This is from trunk as on Mar 3.

[Bug c++/79822] [5/7 Regression] ICE with void statement expression

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar  6 15:43:51 2017
New Revision: 245925

URL: https://gcc.gnu.org/viewcvs?rev=245925=gcc=rev
Log:
PR c++/79822
* constexpr.c (cxx_eval_statement_list): Treat empty ({ }) like
({ (void) 0; }).

* g++.dg/cpp0x/constexpr-79822.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-79822.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
Converting the VRP threading into a domwalk with the appropriate callbacks is
trivial.  It's a nice side benefit from some 2016 work.

Probably the biggest driver for the gcc-7 vs gcc-8 decision will be whether or
not I can cleanly share recording expressions from conditionals and recording
expressions from ASSERT_EXPRs.  The rest of the stuff outlined in c#15 is very
simple and straightforward.

[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from Jakub Jelinek  ---
[...]
>> I can also run a full bootstrap if that's helpful.
>
> If you can, it is useful.  I'll do a x86_64/i686-linux bootstrap as well later
> today.

A sparc-sun-solaris2.12 bootstrap has just completed without
regressions.

Thanks again.

Rainer

[Bug c/79918] New: Feature request: Warning about (may potential) misaligned address-reference

[meisenmann....@fh-salzburg.ac.at]

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

Bug ID: 79918
   Summary: Feature request: Warning about (may potential)
misaligned address-reference
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meisenmann@fh-salzburg.ac.at
  Target Milestone: ---
Target: arm-none-eabi

Hi!

I'm currently working on porting code (from x86) to ARM-targets and detecting
(potential) "alignment-problems". By using the option '-Wcast-align', I'm able
determine some "problematic" implementations, but I haven't found an
warning-option to detect another issue: I.e., getting a (misaligned)
address-reference, if referencing a misaligned struct-member.

--- Begin: Test-Code ---
extern void foo(double* p);

struct __attribute__((packed)) una_t
{
chardata[2];
double  value;
};

voidTest1(char* p)
{
foo((double*)p);
}

voidTest2(struct una_t* p)
{
foo(>value);
}
--- End of Code ---

I think (IMHO), it should be possible to detect >value in Test2() as risk;
similar as the pointer-cast in Test1(), but based on referencing an unaligned
member of a struct-typ.

Perhaps, a corresponding warning-option could be introduced in a future release
...

Best regards from Salzburg,
Markus

[Bug c++/79900] [5/6/7 Regression] ICE in strip_typedefs, at cp/tree.c:1554

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-06
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug rtl-optimization/79901] ICE in prepare_cmp_insn, at optabs.c:3904

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
On the middle-end side, I see dom3 changing:
-  vect_patt_1.22_94 = VEC_COND_EXPR ;
-  vect_patt_1.22_95 = VEC_COND_EXPR ;
+  vect_patt_1.22_94 = MIN_EXPR ;
+  vect_patt_1.22_95 = MIN_EXPR ;
without actually verifying there is an optab for that (dunno where exactly, if
it is match.pd (which has some rule for something like that) or something
else),
or the problem is that MIN/MAX_EXPR expansion if there is no optab available
for it should attempt to expand it as a corresponding VEC_COND_EXPR (it ICEs
because it attempts to expand it as a condition followed by jump, which
obviously can't work).  Trying to fix this up in the veclower pass is not
possible, because dom3 comes after veclower2.

[Bug c++/79917] New: Internal compiler error with variadic template and concepts, internal compiler error: in tsubst_constraint, at cp/constraint.cc:1956

[czirkos.zoltan at gmail dot com]

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

Bug ID: 79917
   Summary: Internal compiler error with variadic template and
concepts, internal compiler error: in
tsubst_constraint, at cp/constraint.cc:1956
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: czirkos.zoltan at gmail dot com
  Target Milestone: ---

Created attachment 40894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40894=edit
minimal working example

G++ throws an internal compiler error for the following code (attached)

G++ version: g++ (Ubuntu 7-20170303-0ubuntu2) 7.0.1 20170303 (experimental)
[trunk revision 245860].

template 
concept bool Integral() {
return std::is_integral::value;
}

template 
void f (ARGS ... indices)
{
}

class C {
public:
template 
void operator() (ARGS ... indices)
{
}
};

int main() {
f(0, 0);

C obj;
obj(0, 0);
}

The global function works correctly, the method with the same template
arguments  crashes the compiler. Output is:


gpp_bugrep.cpp: In substitution of ‘template  requires
(Integral)()... void C::operator()(ARGS ...) [with ARGS = {int, int}]’:
gpp_bugrep.cpp:25:13:   required from here
gpp_bugrep.cpp:16:14: internal compiler error: in tsubst_constraint, at
cp/constraint.cc:1956
 void operator() (ARGS ... indices)
  ^~~~
0x6e8d7d tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/constraint.cc:1956
0x6e8e29 tsubst_constraint_info(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/constraint.cc:1918
0x5f6bef tsubst_decl
../../src/gcc/cp/pt.c:12346
0x5e33af tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13310
0x5e287b instantiate_template_1
../../src/gcc/cp/pt.c:18131
0x5e287b instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:18187
0x5fb628 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../src/gcc/cp/pt.c:18567
0x5adbd7 add_template_candidate_real
../../src/gcc/cp/call.c:3170
0x5a5594 add_template_candidate
../../src/gcc/cp/call.c:3252
0x5a5594 add_candidates
../../src/gcc/cp/call.c:5483
0x5b0062 build_op_call_1
../../src/gcc/cp/call.c:4456
0x5b0062 build_op_call(tree_node*, vec**, int)
../../src/gcc/cp/call.c:4550
0x68eba7 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../src/gcc/cp/semantics.c:2458
0x64293c cp_parser_postfix_expression
../../src/gcc/cp/parser.c:6991
0x64326d cp_parser_unary_expression
../../src/gcc/cp/parser.c:8102
0x643fd3 cp_parser_cast_expression
../../src/gcc/cp/parser.c:8780
0x644747 cp_parser_binary_expression
../../src/gcc/cp/parser.c:8881
0x644df4 cp_parser_assignment_expression
../../src/gcc/cp/parser.c:9168
0x647f6a cp_parser_expression
../../src/gcc/cp/parser.c:9337
0x64c908 cp_parser_expression_statement
../../src/gcc/cp/parser.c:10885

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #15 from Vladimir Makarov  ---
My approach is to fix it in LRA by using a reload pass behaviour.

We have 

(define_insn "*movti_internal"
  [(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,o ,v,v ,v ,m")
(match_operand:TI 1 "general_operand"  "riFo,re,C,BC,vm,v"))]

LRA rejects the 1st alternative as very costly ('!') when the memory ('o') is
not offsetable.  Reload pass just reload the memory address in this case and
does not count the first alternative as costly.  I believe LRA should take '!'
into account when the whole memory operand (or other operand) is reloaded (not
its address).

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
(In reply to Bernd Schmidt from comment #13)
> (In reply to Martin Liška from comment #11)
> > I see a similar test-case on ppc64le-linux-gnu (w/ cross-compiler):
> > 
> > $ ppc64le-linux-gnu-g++
> > /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.
> > C -mno-popcntd -Og
> 
> > 
> > Should I create a separate issue, or is it the same as this one?
> 
> Most likely something else, please create a new one and Cc me and Vlad.

Just done so: PR79916.

[Bug rtl-optimization/79916] New: ICE in Max. number of generated reload insns per insn is achieved (90)

[marxin at gcc dot gnu.org]

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

Bug ID: 79916
   Summary: ICE in Max. number of generated reload insns per insn
is achieved (90)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: bernds at gcc dot gnu.org, vmakarov at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le-linux-gnu

I see ICE with a cross-compiler:

$ ppc64le-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.C
-mno-popcntd -Og
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.C:7:0:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return_x.h: In
function ‘void testitd32()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return_x.h:84:1:
internal compiler error: Max. number of generated reload insns per insn is
achieved (90)

 }
 ^
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return_x.h:86:1:
note: in expansion of macro ‘T’
 T(d32, dec32, (dec32)1.5DF);
 ^
0xbffedb lra_constraints(bool)
.././../gcc/lra-constraints.c:4678
0xbe8cfc lra(_IO_FILE*)
.././../gcc/lra.c:2392
0xb9d681 do_reload
.././../gcc/ira.c:5451
0xb9d681 execute
.././../gcc/ira.c:5635

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[bernds at gcc dot gnu.org]

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

--- Comment #13 from Bernd Schmidt  ---
(In reply to Martin Liška from comment #11)
> I see a similar test-case on ppc64le-linux-gnu (w/ cross-compiler):
> 
> $ ppc64le-linux-gnu-g++
> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.
> C -mno-popcntd -Og

> 
> Should I create a separate issue, or is it the same as this one?

Most likely something else, please create a new one and Cc me and Vlad.

[Bug rtl-optimization/79901] ICE in prepare_cmp_insn, at optabs.c:3904

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-06
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
There is a bug in sse.md, vp{min,max}{s,u}q is available in AVX512F rather than
AVX512BW for 512-byte vectors.  I'll have a look if there is also a bug in the
middle-end.
--- gcc/config/i386/sse.md.jj   2017-03-06 12:35:27.0 +0100
+++ gcc/config/i386/sse.md  2017-03-06 14:49:00.847127695 +0100
@@ -10841,7 +10841,7 @@ (define_expand "3_mask"
   "TARGET_AVX512F"
   "ix86_fixup_binary_operands_no_copy (, mode, operands);")

-(define_insn "*avx512bw_3"
+(define_insn "*avx512f_3"
   [(set (match_operand:VI48_AVX512VL 0 "register_operand" "=v")
(maxmin:VI48_AVX512VL
  (match_operand:VI48_AVX512VL 1 "nonimmediate_operand" "%v")
@@ -10865,10 +10865,10 @@ (define_insn "
(set_attr "mode" "")])

 (define_expand "3"
-  [(set (match_operand:VI8_AVX2_AVX512BW 0 "register_operand")
-   (maxmin:VI8_AVX2_AVX512BW
- (match_operand:VI8_AVX2_AVX512BW 1 "register_operand")
- (match_operand:VI8_AVX2_AVX512BW 2 "register_operand")))]
+  [(set (match_operand:VI8_AVX2_AVX512F 0 "register_operand")
+   (maxmin:VI8_AVX2_AVX512F
+ (match_operand:VI8_AVX2_AVX512F 1 "register_operand")
+ (match_operand:VI8_AVX2_AVX512F 2 "register_operand")))]
   "TARGET_SSE4_2"
 {
   if (TARGET_AVX512F

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #12 from Matthias Klose  ---
still reproducible with r245899 on the gcc-6-branch

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
(In reply to Jakub Jelinek from comment #10)
> Wouldn't it penalize other code?  E.g. if you have a TImode MEM and store
> from something in XMM register, then it doesn't have to be offsetable and
> can use even zero_extend in the address.

Well, the testcase seems to come with -mno-sse, so maybe we check for that as
well and assume things can be reloaded into an SSE reg otherwise. Guess I'll
fire up a test.

[Bug tree-optimization/79824] [7 Regression] Failure to peel for gaps leads to read beyond mapped memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/79894] [5/6 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Mar  6 13:58:57 2017
New Revision: 245923

URL: https://gcc.gnu.org/viewcvs?rev=245923=gcc=rev
Log:
2017-03-06  Richard Biener  

PR tree-optimization/79894
* tree-vectorizer.c (vectorize_loops): Set loop_vectorized_call
to NULL after folding it.

* gcc.dg/vect/pr79887.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr79887.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vectorizer.c

[Bug tree-optimization/79887] [7 Regression] ICE in set_uid_loop_bbs, at tree-vectorizer.c:482

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/79894] [5/6 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||7.0.1
Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |gfc_add_modify_loc, at  |gfc_add_modify_loc, at
   |fortran/trans.c:159 |fortran/trans.c:159

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

[Bug tree-optimization/79824] [7 Regression] Failure to peel for gaps leads to read beyond mapped memory

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Mar  6 13:58:01 2017
New Revision: 245922

URL: https://gcc.gnu.org/viewcvs?rev=245922=gcc=rev
Log:
2017-03-06  Richard Biener  

PR tree-optimization/79824
* tree-vect-stmts.c (get_group_load_store_type): Fix alignment
check disabling peeling for gaps.

* gcc.dg/vect/pr79824-1.c: New testcase.
* gcc.dg/vect/pr79824-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr79824-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr79824-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-06
   Assignee|unassigned at gcc dot gnu.org  |krebbel at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Bernd Schmidt  ---
Unassigning myself.