[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

--- Comment #14 from Mikael Morin  ---
Created attachment 37613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37613=edit
Fix for comment #10

This is sufficient to fix comment #10.
It removes the optional attribute on c(1) if c is optional.
Then the can_be_null_ref attribute is not set during scalarization, and
gfc_scalar_elemental_arg_saved_as_reference returns false.
I'm not sure this is actually correct; should we consider c(1) optional if c is
optional?

[Bug driver/69711] New: Wrong suggestion for -ftree-ivopts

[pinskia at gcc dot gnu.org]

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

Bug ID: 69711
   Summary: Wrong suggestion for -ftree-ivopts
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

gcc: error: unrecognized command line option '-ftree-ivopts'; did you mean
'-ftree-pta'?


No I had meant -fivopts that is without the tree- part.

[Bug c++/69712] New: Storing and reusing a method pointer as compile time value

[realloc at outlook dot de]

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

Bug ID: 69712
   Summary: Storing and reusing a method pointer as compile time
value
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: realloc at outlook dot de
  Target Milestone: ---

Created attachment 37617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37617=edit
preprocessed file

Storing a method pointer as compile-time value and reusing it as non-type
parameter fails.

version: g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
os: Ubuntu 15.10
system: Kernel 4.3.0-040300rc6-generic x86_64 GNU/Linux

result of compilation attempt:
g++ --std=c++14 testcase.cpp -o test
-
testcase.cpp: In function ‘int main()’:
testcase.cpp:52:48: error: no matching function for call to ‘callMethod(A&)’
  callMethod(a);
^
testcase.cpp:33:16: note: candidate: template >::type fun, class Class, class ... Args>
decltype(auto) callMethod(Class&, Args&& ...)
 decltype(auto) callMethod(Class & obj, Args && ... args)
^
testcase.cpp:33:16: note:   template argument deduction/substitution failed:
testcase.cpp:52:48: error: ‘Value::value’ is not a
valid template argument for type ‘method_ptr::type {aka
void (A::* const)()}’
  callMethod(a);
^
testcase.cpp:52:48: error: it must be a pointer-to-member of the form ‘::Y’
testcase.cpp:52:48: error: could not convert template argument ‘Value::value’ to ‘method_ptr::type {aka
void (A::* const)()}’

More detailed:
g++ --std=c++14 -v -save-temps testcase.cpp | head
---
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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 --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-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 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) 
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE testcase.cpp -mtune=generic -march=x86-64
-std=c++14 -fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security
-o testcase.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed testcase.ii -quiet
-dumpbase testcase.cpp -mtune=generic -march=x86-64 -auxbase testcase
-std=c++14 -version -fstack-protector-strong -Wformat -Wformat-security -o
testcase.s
GNU C++14 (Ubuntu 5.2.1-22ubuntu2) version 5.2.1 20151010 (x86_64-linux-gnu)
compiled by GNU C version 5.2.1 20151010, GMP version 6.0.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 5.2.1-22ubuntu2) version 5.2.1 20151010 (x86_64-linux-gnu)
compiled by GNU C version 5.2.1 20151010, 

[Bug lto/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

--- Comment #14 from vries at gcc dot gnu.org ---
Created attachment 37616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37616=edit
further updated tentative patch

[Bug tree-optimization/69710] performance issue with SP Linpack with Autovectorization

[doug.gilmore at imgtec dot com]

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

--- Comment #1 from Doug Gilmore  ---
Created attachment 37615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37615=edit
daxpy for DP (previous was for SP)

Compilation example:

arm-linux-gnueabihf-gcc -O3 -save-temps daxpy.c saxpy.c -c -mfpu=neon  -c
-fdump-tree-{vect,ivopts}-{verbose,details} -fdump-tree-{slp1,optimized}
-fsched-verbose=9 \
-fdump-rtl-sched{1,2} -marm  -funsafe-math-optimizations -funroll-all-loops

Note that Neon does not support DP, thus daxpy.s won't contain
autovectorized code.

I haven't built a ToT compiler for aarch64-linux-gnu, but I suspect
that you will see autovectorized code in daxpy.s in which reasonable
schedules are being produced (loads are being moved above stores).

[Bug tree-optimization/69710] performance issue with SP Linpack with Autovectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
For the double one, in .optimized on the trunk for aarch64
(--with-cpu=thunderx) I get:

  :
  # ivtmp.22_60 = PHI <0(10), ivtmp.22_59(11)>
  # ivtmp.25_75 = PHI <0(10), ivtmp.25_79(11)>
  vect__12.14_86 = MEM[base: vectp_dy.13_82, index: ivtmp.25_75, offset: 0B];
  vect__15.17_91 = MEM[base: vectp_dx.16_87, index: ivtmp.25_75, offset: 0B];
  vect__17.19_94 = vect__15.17_91 * vect_cst__92 + vect__12.14_86;
  MEM[base: vectp_dy.13_82, index: ivtmp.25_75, offset: 0B] = vect__17.19_94;
  ivtmp.22_59 = ivtmp.22_60 + 1;
  ivtmp.25_79 = ivtmp.25_75 + 16;
  if (bnd.9_55 > ivtmp.22_59)
goto ;
  else

So yes there are two IV one for the memory accesses and one for the comparison.

The assembly code for the above loop (without -funroll-all-loops):
.L8:
ldr q1, [x7, x0]
add w5, w5, 1
ldr q2, [x2, x0]
fmlav1.2d, v2.2d, v3.2d
str q1, [x7, x0]
add x0, x0, 16
cmp w6, w5
bhi .L8


For SP I get:

  :
  # ivtmp.22_80 = PHI <0(12), ivtmp.22_79(13)>
  # ivtmp.25_113 = PHI <0(12), ivtmp.25_112(13)>
  vect__12.14_87 = MEM[base: vectp_dy.13_83, index: ivtmp.25_113, offset: 0B];
  vect__15.17_92 = MEM[base: vectp_dx.16_88, index: ivtmp.25_113, offset: 0B];
  vect__17.19_95 = vect__15.17_92 * vect_cst__93 + vect__12.14_87;
  MEM[base: vectp_dy.13_83, index: ivtmp.25_113, offset: 0B] = vect__17.19_95;
  ivtmp.22_79 = ivtmp.22_80 + 1;
  ivtmp.25_112 = ivtmp.25_113 + 16;
  if (bnd.9_55 > ivtmp.22_79)
goto ;
  else
goto ;


.L8:
ldr q1, [x8, x4]
add w7, w7, 1
ldr q2, [x2, x4]
fmlav1.4s, v2.4s, v3.4s
str q1, [x8, x4]
add x4, x4, 16
cmp w5, w7
bhi .L8

So it works for me on aarch64 correctly.

For -funroll-all-loops I get (similarly for DP also):
.L8:
ldr q7, [x15, x4]
add x7, x4, 16
ldr q16, [x16, x4]
add x9, x4, 32
ldr q17, [x16, x7]
add x8, x4, 48
ldr q19, [x16, x9]
add x11, x4, 64
ldr q22, [x16, x8]
add x14, x4, 80
fmlav7.4s, v16.4s, v21.4s
ldr q24, [x16, x11]
ldr q26, [x16, x14]
add x12, x4, 96
ldr q28, [x16, x12]
add x17, x4, 112
ldr q30, [x16, x17]
add w2, w2, 8
str q7, [x15, x4]
add x4, x4, 128
ldr q18, [x15, x7]
fmlav18.4s, v17.4s, v21.4s
str q18, [x15, x7]
ldr q20, [x15, x9]
fmlav20.4s, v19.4s, v21.4s
str q20, [x15, x9]
ldr q23, [x15, x8]
fmlav23.4s, v22.4s, v21.4s
str q23, [x15, x8]
ldr q25, [x15, x11]
fmlav25.4s, v24.4s, v21.4s
str q25, [x15, x11]
ldr q27, [x15, x14]
fmlav27.4s, v26.4s, v21.4s
str q27, [x15, x14]
ldr q29, [x15, x12]
fmlav29.4s, v28.4s, v21.4s
str q29, [x15, x12]
ldr q31, [x15, x17]
fmlav31.4s, v30.4s, v21.4s
str q31, [x15, x17]
cmp w13, w2
bhi .L8

[Bug lto/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org ---
(In reply to vries from comment #14)
> Created attachment 37616 [details]
> further updated tentative patch

Fixes -fno-use-linker-plugin failures, apart from:
- PR69707
- PR69705
- PR67709

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Alexander Monakov from comment #1)
> 
> So it wants to pick a scratch register in SIBCALL_REGS ("k", r0-r7), but in
> the circumstances r4-r7 are already used for argument passing, and r0-r3 are
> used for the return value -- and GCC cannot know that the scratch reg
> wouldn't be simultaneously live with those.
> 
> I must say I don't quite see the point of using match_scratch for the callee
> address there.  After all, it's making a sibcall, so GCC can simply pick r0
> or whatever's convenient, no?

I haven't checked the details of this issue, but generally, yes,  It should be
able to pick r0...r3 for the scratch register in this case.  At the time of the
call the values in r0...r3 are undefined and they get defined only after the
call.  Not sure what's the problem here.

> In response to the last sentence in my analysis, on IRC Rich pointed out
> that using r1/r2/r3 should be better that r0 because some instruction can
> operate only on r0 so that would constrain scheduling.

Are there any examples for this statement?

[Bug c++/69700] [C++14] constexpr incorrectly implies const

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The same problem also exists in the current gcc 6.0 trunk (tested using gcc
6.0.0 20160131 (experimental))

[Bug c++/69712] Storing and reusing a method pointer as compile time value

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-06
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.2.0, 6.0

--- Comment #2 from Ville Voutilainen  ---
clang and msvc accept the code.

[Bug tree-optimization/69710] performance issue with SP Linpack with Autovectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
IV-opts runs after the vectorizer so if that does not optimize it to where you
want it to be the problem is there.

[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|tree-optimization   |rtl-optimization

--- Comment #4 from Andrew Pinski  ---
For me, the problem is only on the rtl level for the scheduling issue.

[Bug c++/69712] Storing and reusing a method pointer as compile time value

[realloc at outlook dot de]

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

--- Comment #1 from realloc at outlook dot de ---
Created attachment 37618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37618=edit
testcase

[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization

[doug.gilmore at imgtec dot com]

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

--- Comment #5 from Doug Gilmore  ---
Thanks for checking on AArch64 Andrew.

BTW, I made my (incorrect) hunch by running a test on gcc113, where
the installed 4.8 compile showed problems for both DP and SP.  (I
assumed that the problem was addressed on DP since we don't see it on
MIPS at DP ToT with the MSA patch applied.)

For Neon after ivopts I see:

  :
  # vectp_dy.20_96 = PHI 
  # ivtmp.22_78 = PHI <0(13), ivtmp.22_77(21)>
  # ivtmp.26_112 = PHI 
  # ivtmp.31_153 = PHI 
  vectp_dx.15_88 = (vector(4) float *) ivtmp.26_112;
  _156 = (void *) ivtmp.31_153;
  vect__12.14_85 = MEM[base: _156, offset: 0B];
  ivtmp.31_154 = ivtmp.31_153 + 16;
  vect__15.17_90 = MEM[(float *)vectp_dx.15_88];
  vect__16.18_92 = vect_cst__91 * vect__15.17_90;
  vect__17.19_93 = vect__12.14_85 + vect__16.18_92;
  MEM[base: vectp_dy.20_96, offset: 0B] = vect__17.19_93;
  vectp_dy.20_97 = vectp_dy.20_96 + 16;
  ivtmp.22_77 = ivtmp.22_78 + 1;
  ivtmp.26_111 = ivtmp.26_112 + 16;
  if (ivtmp.22_77 < bnd.9_53)
goto ;
  else
goto ;
...
  :
  goto ;

So the problem is indeed exposed on Neon.

[Bug target/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|libstdc++   |target

--- Comment #2 from John David Anglin  ---
Probably, this test exposes an issue with target pthreads or atomic support.

[Bug c++/69111] Problem with expansion of a parameter pack of templates

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-06
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.2.0, 6.0

--- Comment #2 from Ville Voutilainen  ---
clang and msvc accept the code.

[Bug bootstrap/69709] New: [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[doko at gcc dot gnu.org]

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

Bug ID: 69709
   Summary: [6 Regression] profiled bootstrap error on
s390x-linux-gnu with r233194
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

profiled bootstrap error on s390x-linux-gnu with r233194. for some reason I
don't get a preprocessed source.

Configured with: -v
 --with-pkgversion='Ubuntu 6-20160206-0ubuntu2'
 --with-bugurl='file:///usr/share/doc/gccgo-6/README.Bugs'
 --enable-languages=c,c++,go
 --prefix=/usr
 --program-suffix=-6
 --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-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libsanitizer
 --disable-libquadmath
 --enable-plugin
 --enable-default-pie
 --with-system-zlib
 --enable-multiarch
 --disable-werror
 --with-arch=zEC12
 --with-long-double-128
 --enable-multilib
 --enable-checking=release
 --build=s390x-linux-gnu
 --host=s390x-linux-gnu
 --target=s390x-linux-gnu

In file included from
/<>/build/s390x-linux-gnu/libstdc++-v3/include/parallel/types.h:36:0,
 from
/<>/build/s390x-linux-gnu/libstdc++-v3/include/parallel/settings.h:86,
 from
../../../../../src/libstdc++-v3/src/c++98/parallel_settings.cc:25:
/<>/build/s390x-linux-gnu/libstdc++-v3/include/limits:1676:7:
internal compiler error: in real_to_decimal_for_mode, at real.c:1780
   max() _GLIBCXX_USE_NOEXCEPT { return __DBL_MAX__; }
   ^~~
0x808b3f9b real_to_decimal_for_mode(char*, real_value const*, unsigned long,
unsigned long, int, machine_mode)
../../src/gcc/real.c:1780
0x80d0fc05 lazy_hex_fp_value
../../src/gcc/c-family/c-cppbuiltin.c:1426
0x80ca62b3 enter_macro_context
../../src/libcpp/macro.c:1101
0x80ca7ab7 cpp_get_token_1
../../src/libcpp/macro.c:2523
0x80ca7ab7 cpp_get_token_with_location(cpp_reader*, unsigned int*)
../../src/libcpp/macro.c:2625
0x8061fbdd c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../src/gcc/c-family/c-lex.c:391
0x80cc347b cp_lexer_get_preprocessor_token
../../src/gcc/cp/parser.c:792
0x80cc347b cp_lexer_new_main
../../src/gcc/cp/parser.c:656
0x80cc347b cp_parser_new
../../src/gcc/cp/parser.c:3687
0x80cc347b c_parse_file()
../../src/gcc/cp/parser.c:37354
0x80d14e63 c_common_parse_file()
../../src/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.

Makefile:825: recipe for target 'parallel_settings.lo' failed
make[8]: *** [parallel_settings.lo] Error 1
make[8]: Leaving directory
'/<>/build/s390x-linux-gnu/libstdc++-v3/src/c++98'
Makefile:640: recipe for target 'all-recursive' failed
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory
'/<>/build/s390x-linux-gnu/libstdc++-v3/src'
Makefile:507: recipe for target 'all-recursive' failed
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory
'/<>/build/s390x-linux-gnu/libstdc++-v3'
Makefile:414: recipe for target 'all' failed
make[5]: *** [all] Error 2
make[5]: Leaving directory
'/<>/build/s390x-linux-gnu/libstdc++-v3'
Makefile:13479: recipe for target 'all-stagefeedback-target-libstdc++-v3'
failed
make[4]: *** [all-stagefeedback-target-libstdc++-v3] Error 2
make[4]: Leaving directory '/<>/build'
Makefile:20515: recipe for target 'stagefeedback-bubble' failed
make[3]: *** [stagefeedback-bubble] Error 2
make[3]: Leaving directory '/<>/build'
Makefile:20534: recipe for target 'profiledbootstrap' failed
make[2]: *** [profiledbootstrap] Error 2

complete build log at
https://launchpadlibrarian.net/236787309/buildlog_ubuntu-xenial-s390x.gccgo-6_6-20160206-0ubuntu2_BUILDING.txt.gz

[Bug tree-optimization/69710] New: performance issue with SP Linpack with Autovectorization

[doug.gilmore at imgtec dot com]

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

Bug ID: 69710
   Summary: performance issue with SP Linpack with
Autovectorization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug.gilmore at imgtec dot com
  Target Milestone: ---

Created attachment 37614
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37614=edit
extracted daxpy example

We've noticed a performance problem in single precision
Linpack with the MSA patch applied:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00177.html

which I have been able to reproduce with ARM Neon.

The problem that the autovectorization is generating more induction
variables for memory references in daxpy (this is an issue on all
architectures).  That is, when the statement:

  dy[i] = dy[i] + da*dx[i];

is vectorized the vector load associated with load of dy[i] uses
a different Induction Variable (IV) for the subsequent vector store
for dy[i].  For example, for ARM neon after vect we see:

  :
  # i_26 = PHI 
  # vectp_dy.12_83 = PHI 
  # vectp_dx.15_88 = PHI 
  # vectp_dy.20_96 = PHI 
  # ivtmp_99 = PHI <0(11), ivtmp_100(20)>
  i.0_7 = (unsigned int) i_26;
  _8 = i.0_7 * 4;
  _10 = dy_9(D) + _8;
  vect__12.14_85 = MEM[(float *)vectp_dy.12_83];
  _12 = *_10;
  _14 = dx_13(D) + _8;
  vect__15.17_90 = MEM[(float *)vectp_dx.15_88];
  _15 = *_14;
  vect__16.18_92 = vect_cst__91 * vect__15.17_90;
  _16 = da_6(D) * _15;
  vect__17.19_93 = vect__12.14_85 + vect__16.18_92;
  _17 = _12 + _16;
  MEM[(float *)vectp_dy.20_96] = vect__17.19_93;
  i_19 = i_26 + 1;
  vectp_dy.12_84 = vectp_dy.12_83 + 16;
  vectp_dx.15_89 = vectp_dx.15_88 + 16;
  vectp_dy.20_97 = vectp_dy.20_96 + 16;
  ivtmp_100 = ivtmp_99 + 1;
  if (ivtmp_100 < bnd.9_53)
goto ;
  else
goto ;
...
  :
  goto ;

Note that the use of a separate IV for the load and store off of dy
can introduces a false memory dependency which causes poor scheduling
after unrolling.  From what I have seen so far, for double precision
the ivopts phase is able to clean up the induction variables so the
false memory dependency is removed.  However the cleanup does not
happen for single precision.

Attached simple example for single precision, more to follow.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
That macro is fairly useless.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Target||sh*-*-*

--- Comment #3 from Oleg Endo  ---
This PR stayed under the radar because the target field was not filled in. 
Please fill in the target field of the PR as above next time you file bugs.

[Bug lto/67709] ICE: in estimate_function_body_sizes, at ipa-inline-analysis.c:2489 on x86_64-apple-darwin*

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
The scenario is the following:

During pass_omp_simd_clone, we call simd_clone_create for foo, and execute the 
!old_node->definition part:
...
  tree old_decl = old_node->decl;
  tree new_decl = copy_node (old_node->decl);
  DECL_NAME (new_decl) = clone_function_name (old_decl, "simdclone");
  SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl));
  SET_DECL_RTL (new_decl, NULL);
  DECL_STATIC_CONSTRUCTOR (new_decl) = 0;
  DECL_STATIC_DESTRUCTOR (new_decl) = 0;
  new_node = old_node->create_version_clone (new_decl, vNULL, NULL);
  if (old_node->in_other_partition)
new_node->in_other_partition = 1;
  symtab->call_cgraph_insertion_hooks (new_node);
...

The 'symtab->call_cgraph_insertion_hooks (new_node)' calls
'inline_summary_t::insert', a hook inserted during pass_ipa_inline.

During execution of the hook we stumble over the fact that the new node has no
'struct function' in estimate_function_body_sizes:
...
  struct function *my_function = DECL_STRUCT_FUNCTION (node->decl);
  ...
  gcc_assert (my_function && my_function->cfg);
...

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Also see:

*** Error in `./default_weaktoshared.exe': double free or corruption (fasttop):
0x0001d858 ***
*** Error in `./default_weaktoshared.exe': double free or corruption (fasttop):
0x0001d880 
***FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[Bug c++/69687] Buffer Overflow in libiberty

[boehme.marcel at gmail dot com]

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

--- Comment #5 from Marcel Böhme  ---
Created attachment 37612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37612=edit
Debug This

[Bug target/69706] internal compiler error: in extract_constrain_insn, at recog.c:2246

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce the ICE with -std=c++11 -m64 -O2 and g++ 5.3 or 6.0 (r233023)
on sparc64-linux.  g++ 4.9 can't compile this preprocessed code.

[Bug c/52085] incomplete enum not completed correctly if packed was used

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #6 from Bernd Edlinger  ---
note: the enum forward declaration can have an __attribute__((whatever))
but it is completely ignored which would be OK, but there should be at least
a warning, "warning: 'whatever' attribute directive ignored [-Wattributes]"

example:

enum __attribute__ ((whatever)) e1;
enum e1 { A } __attribute__ ((__packed__));

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
(added SH maintainers, Oleg Endo and Kaz Kojima to Cc)

In response to the last sentence in my analysis, on IRC Rich pointed out that
using r1/r2/r3 should be better that r0 because some instruction can operate
only on r0 so that would constrain scheduling.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[nalimilan at club dot fr]

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

--- Comment #18 from Milan Bouchet-Valat  ---
FWIW, Debian has identified a few packages failing to build with the "flexible
array member in otherwise empty struct" error under GCC 6:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812023
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812024
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812026

Not sure whether these affect public API or not.

[Bug libstdc++/69703] char16_t conversions broken in filesystem::path

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
That looks like it should pass, not sure when I'll get a chance to look at it
though.

[Bug target/69693] Wrong mode is used to load spilled register

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to H.J. Lu from comment #4)
> 
> > It looks that it is done on purpose.
> 
> In this case, our planned transition to generic unaligned SSE loads should
> "fix" this issue. The realignment will be necessary only for performance
> reasons, not for the correctness. Maybe we should also look if
> SLOW_UNALIGNED_ACCESS affects moves that may result in muvups insns.
> 
> (However, since movups from unaligned address is slow, I still think that
> realignment should be fixed for STV pass).

STV paradoxical V2DI subregs only needs 8-byte alignment. LRA generates
aligned V2DI move on paradoxical V2DI subregs since we don't provide
paradoxical V2DI subreg move and SLOW_UNALIGNED_ACCESS is 0.  STV doesn't
need 16-byte alignment.  I bootstrapped 32-bit GCC using my patch with
--with-arch=corei7 --with-cpu=corei7. There are no regressions.

[Bug fortran/66643] Missing compilation error for formatted data transfer without format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Created attachment 37610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37610=edit
A preliminary patch

Attached patch gives a diagnostic. Interestingly I found three test cases in
the test suite that use the invalid construct.

[Bug lto/69707] FAIL: parallel-dims.c test for excess errors with -flto -fno-use-linker-plugin

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37611
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37611=edit
tentative patch

[Bug ipa/69708] New: ipa inline not working for function reference in static const struct

[carlosjosepita at gmail dot com]

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

Bug ID: 69708
   Summary: ipa inline not working for function reference in
static const struct
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosjosepita at gmail dot com
  Target Milestone: ---

Please see full discussion at https://gcc.gnu.org/ml/gcc/2016-02/msg00042.html.

Here is a summary of the above:

```
typedef struct F {
  int (*call)(int);
} F;

static int g(F f, int x) {
  x = f.call(x);
  x = f.call(x);
  x = f.call(x);
  x = f.call(x);
  x = f.call(x);
  x = f.call(x);
  x = f.call(x);
  x = f.call(x);
  return x;
}

static int sq(int x) {
  return x * x;
}

static const F f = {sq};

void dosomething(int);

int h(int x) {
  dosomething(g(f, x));
  dosomething(g((F){sq}, x));
}
```

I've reported this: .

Just to summarize:

1) If early inlining is forced then fre replaces the many references to sq and
ipa inlining is able to do its job.

2) If early inlining is disabled then ipa inlining only works for the compound
literal case. The cp pass (happening immediately before the ipa inline one)
results in:

```
h (int x)
{
  ...
  _4 = g (f, x_2(D));
  dosomething (_4);
  D.1847.call = sq;
  _8 = g (D.1847, x_2(D));
  dosomething (_8);
  
}
```

Nevertheless ipa inline seems clever enough to expand the second call to g.

3) The proper solution seems to be that cp were able to propagate sq to both
call sites in order to make things easy to ipa inline.

[Bug c++/69687] Buffer Overflow in libiberty

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Marcel Böhme from comment #5)
> Created attachment 37612 [details]
> Debug This

Scary.

[Bug target/69713] New: Invalid code of optimization in SH

[ysato at users dot sourceforge.jp]

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

Bug ID: 69713
   Summary: Invalid code of optimization in SH
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysato at users dot sourceforge.jp
  Target Milestone: ---

Created attachment 37619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37619=edit
reproduce code

Attached code compiled. Getting output below.

82  lookup_user_key:
83  mov.l   r8,@-r15
84  mov #0,r3
85  mov.l   r9,@-r15
86  mov #15,r1
87  mov.l   r10,@-r15
88  mov.l   r11,@-r15
89  mov r5,r11
90  mov.l   r12,@-r15
91  mov r4,r12
92  mov.l   r13,@-r15
93  mov.l   r14,@-r15
94  sts.l   pr,@-r15
95  add #-76,r15
96  mov r15,r2
97  mov.l   r6,@(4,r15)
98  add #16,r2
99  .L16:
   100  add #-1,r1
   101  mov.l   r3,@r2
   102  tst r1,r1
   103  add #4,r2
   104  bf  .L16
   105  mov.l   .L111,r1
   106  mov r12,r10
   107  add #8,r10
   108  mova.L21,r0
   109  mov.l   r1,@(32,r15)
   110  mov r10,r2
   111  mov #1,r1
   112  mov.l   r1,@(48,r15)
   113  add r2,r2
   114  mov.w   @(r0,r2),r1

Line 114 is lookup jump table. But not check offset range.
So if r2 is out of range (in default case). Refer out of table.

-O0 generate collect code. I think optimizing bug.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
(In reply to Rich Felker from comment #5)
> 
> 1. that the "k" constraint that's currently used is not working to
> automatically assign a scratch register because r4-r7 are all live as
> argument registers and r0-r3 are spuriously live as the return value, or
> something like that,

Yes, clearly something is not working as it should ... There are also similar
issues with the R0-spill failures when adjacent instructions need R0 reloads.  

Have you tried using LRA (-mlra option)?


> 2. that using a fixed register that's not represented at all in the RTL
> constraints for sibcall_value_pcrel would work instead, and

> 3. that if a fixed register is used, r1-r3 would be better choices than r0
> since r0 is special and some instructions (that could otherwise be scheduled
> between the load of the target address and the actual call) have r0
> hard-coded as one of their operands.

OK, now I get the idea.  Using r1-r3 for this could be better, but probably it
won't matter much.  What I have observed is that for function calls, the
function address is often loaded shortly before the branch instruction.  

Anyway, I don't think it's a good solution.  It a trap for future development
(e.g. ABI changes/extensions) and it could open another can of worms.  For
example, if you use r1 implicitly in the instruction without specifying it in
the RTL, other optimizers will not see the r1 use and will potentially generate
wrong code.

I think that...

> and GCC cannot know that the scratch reg
> wouldn't be simultaneously live with those.

.. this is the core issue here and that should be fixed instead.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[amonakov at gcc dot gnu.org]

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

--- Comment #7 from Alexander Monakov  ---
Oleg, Rich, there's some confusion in comments 4-6.  Please unwind all the way
back to comment #1, and let me explain the issue once again.  I now see that my
phrasing back then was insufficiently detailed.

Look at the RTL template I quote there, and note how it picks a register to
hold relative callee address:

10484(clobber (match_scratch:SI 3 "="))

It then proceeds to specify how to emit a sequence of insns, first to load the
address into operands[3] (the scratch reg above), and then to make a call using
operands[3]. The split takes part after reload, so at the time of register
allocation the instruction is not split and is represented by the RTL template
as quoted.

Note that there's no way to specify that the match_scratch reg is not going to
be live simultaneously with operands[0], the return value. In fact, you can
imagine that splitting emits some third instruction after the call that tries
to use operands[3] and operands[0], and then there's no way to pick a scratch
reg.

So it's not like GCC is not doing something it should. It's sh.md that demands
the impossible.

This is why I suggested using a hard register in place of a scratch (because
r0-r3 are free to use for that purpose anyway), but of course it has to be
properly encoded in the RTL template: you'd clobber a specific hardreg instead
of clobbering a scratch. Perhaps Rich misremembered something when saying that
the chosen hardreg would not be explicit in the RTL.

Does that clarify?

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker  ---
Oleg, thanks for the tip. I think what Alexander is saying about r0-r3 is:

1. that the "k" constraint that's currently used is not working to
automatically assign a scratch register because r4-r7 are all live as argument
registers and r0-r3 are spuriously live as the return value, or something like
that,
2. that using a fixed register that's not represented at all in the RTL
constraints for sibcall_value_pcrel would work instead, and
3. that if a fixed register is used, r1-r3 would be better choices than r0
since r0 is special and some instructions (that could otherwise be scheduled
between the load of the target address and the actual call) have r0 hard-coded
as one of their operands.

I'm still not sufficiently familiar with RTL to know if I got all that right,
but hopefully it's at least close.

[Bug c++/69687] Buffer Overflow in libiberty

[boehme.marcel at gmail dot com]

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

--- Comment #7 from Marcel Böhme  ---
Created attachment 37620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37620=edit
Valgrind This

$ cat compileme.c
#include
#include

const char*
X00020A___R0020A__U000R03000N_020A__K000(){
  char *p;
  p = (char *) malloc(19);
  p = (char *) malloc(12);
  free(p);
  p = (char *) malloc(16);
  return "Hello World!";
}

int main()
{
  
printf("%s\n",X00020A___R0020A__U000R03000N_020A__K000());
   return 0;
}

$ g++ compileme.c -o temp
$ sed -b s/Z68/_20/g temp > valgrindme
$ chmod u+x valgrindme
$ ./valgrindme
Hello World!
$ valgrind --leak-check=yes ./valgrindme
..
$ gdb ./valgrindme
..

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Hm, if GCC won't accept clobbering a hardreg that overlaps the output hardregs
holding the return value (operands[0]), then it's less obvious. r0 is always
suitable then and does not require mentioning in the RTL template, but
constrains scheduling as Rich said. On the other hand, r1-r3 are also always
suitable by virtue of being call-clobbered, and thus they wouldn't require a
mention in the RTL template either.

[Bug target/69634] [6 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fschedule-insns -fno-tree-vrp @ i686

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
+/* { dg-additional-options "-Wno-psabi -mno-sse" { target i?86-*-* x86_64-*-*
} } */
+/* { dg-additional-options "-m32" { target x86_64-*-* } } */

Please don't use explicit -m32. If the test is valid only for 32bit target, you
should use "target ia32", otherwise just leave it out. 32bit multilib tests
will add -m32 automatically.

Explicit -m32 will probably fail with x32, which is x86_64 target, too.

[Bug lto/67709] ICE: in estimate_function_body_sizes, at ipa-inline-analysis.c:2489 on x86_64-apple-darwin*

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
a.
I'm not sure if we still should be update inline_summaries at the point that we
do pass_omp_simd_clone. AFAICT, it's the last ipa pass. Simply cloning
pass_ipa_free_inline_summary in front of pass_omp_simd_clone fixes this.

b.
Another way of looking at this, is to look at the pass before:
pass_dispatcher_calls. It has a function create_target_clone, similar to
simd_clone_create, with a node.defition and !node.defition part. The
!node.defition part looks like:
...
  tree new_decl = copy_node (node->decl);
  new_node = cgraph_node::get_create (new_decl);
  /* Generate a new name for the new version.  */
  symtab->change_decl_assembler_name (new_node->decl,
  clone_function_name (node->decl,
   name));
...

It does similar stuff to what simd_clone_create does. But it does not call
'symtab->call_cgraph_insertion_hooks (new_node)'.

Just removing the call also seems to work.

[Bug lto/67709] ICE: in estimate_function_body_sizes, at ipa-inline-analysis.c:2489 on x86_64-apple-darwin*

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||lto, openmp
 Target|x86_64-apple-darwin*|x86_64-apple-darwin*,
   ||x86_64-pc-linux-gnu
 CC||vries at gcc dot gnu.org
   Host|x86_64-apple-darwin*|x86_64-apple-darwin*,
   ||x86_64-pc-linux-gnu
  Build|x86_64-apple-darwin*|x86_64-apple-darwin*,
   ||x86_64-pc-linux-gnu

--- Comment #2 from vries at gcc dot gnu.org ---
Same on x86_64-pc-linux-gnu with -fno-use-linker-plugin.

Reproduce:
...
$ f951 src/libgomp/testsuite/libgomp.fortran/declare-simd-3.f90 -O0 -fopenmp
-flto -fno-use-linker-plugin
...

Surprisingly, reproduces also without -fopenmp.

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[rsandifo at gcc dot gnu.org]

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

--- Comment #13 from rsandifo at gcc dot gnu.org  
---

(In reply to Bill Schmidt from comment #10)
> Looking at scan_rtx_address () in regrename.c, it indeed looks like a PLUS
> nested inside a PLUS isn't handled.  I'm not sure if this is a deficiency in
> regrename.c, or whether the definition of fusion_gpr_load_di is just playing
> with fire here.  Richard S., do you have an opinion?

Like you say, I don't think nested (plus ... (const_int))s are valid.
It still sounds like a deficiency if they trigger wrong code though --
an ICE would be OK.

I'm probably misreading the code, but I don't see how scan_rtx_address
would get this wrong.  The first (plus ... (const_int)) ought to go
through:

else if (code1 == CONST_INT || code1 == CONST
 || code1 == SYMBOL_REF || code1 == LABEL_REF)
  {
locB =  (x, 0);
index_code = GET_CODE (XEXP (x, 1));
  }

and then we'd recurse with locB treated as a base address.  *locB
is the inner plus and ought to come through the same code again,
meaning that we recurse a second time with locB pointing to r9.

So there might still be a regrename.c bug here.

[Bug c++/69658] [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[jakub at gcc dot gnu.org]

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

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  ---
http://gcc.gnu.org/ml/gcc-patches/2016-02/msg00352.html

[Bug debug/69705] New: segfault in libgomp.fortran/task1.f90 with -flto -fno-use-linker-plugin -fno-toplevel-reorder -O1 -g

[vries at gcc dot gnu.org]

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

Bug ID: 69705
   Summary: segfault in libgomp.fortran/task1.f90 with -flto
-fno-use-linker-plugin -fno-toplevel-reorder -O1 -g
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
$ gfortran src/libgomp/testsuite/libgomp.fortran/task1.f90 -fopenmp -flto
-fno-use-linker-plugin -fno-toplevel-reorder -O1 -g 
src/libgomp/testsuite/libgomp.fortran/task1.f90: In function
‘MAIN__._omp_fn.1’:
src/libgomp/testsuite/libgomp.fortran/task1.f90:11:0: internal compiler error:
Segmentation fault
   !$omp task if (.false.) default(firstprivate)

0xe49108 crash_signal
src/gcc/toplev.c:335
0x717c62 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
src/gcc/tree.h:3119
0x8a790d add_name_and_src_coords_attributes
src/gcc/dwarf2out.c:18765
0x8b08cd gen_variable_die
src/gcc/dwarf2out.c:21073
0x8b8412 gen_decl_die
src/gcc/dwarf2out.c:23535
0x8b69e5 process_scope_var
src/gcc/dwarf2out.c:23021
0x8b6afe decls_for_scope
src/gcc/dwarf2out.c:23049
0x8b2365 gen_lexical_block_die
src/gcc/dwarf2out.c:21481
0x8b671e gen_block_die
src/gcc/dwarf2out.c:22990
0x8b6b7b decls_for_scope
src/gcc/dwarf2out.c:23060
0x8b2504 gen_inlined_subroutine_die
src/gcc/dwarf2out.c:21519
0x8b6709 gen_block_die
src/gcc/dwarf2out.c:22987
0x8b6b7b decls_for_scope
src/gcc/dwarf2out.c:23060
0x8acc46 gen_subprogram_die
src/gcc/dwarf2out.c:20771
0x8b8097 gen_decl_die
src/gcc/dwarf2out.c:23468
0x8b9412 dwarf2out_decl
src/gcc/dwarf2out.c:23951
0x8b945c dwarf2out_function_decl
src/gcc/dwarf2out.c:23966
0x966297 rest_of_handle_final
src/gcc/final.c:4474
0x96660a execute
src/gcc/final.c:4516
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: ./lean-fortran/install/bin/gfortran returned 1 exit
status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
...

[Bug c++/56665] -O2 with -fno-strict-aliasing makes boost::spirit::classic::assign_a not working

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #5 from Markus Trippelsdorf  ---
Created attachment 37607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37607=edit
reduced testcase

Here's a somewhat reduced testcase that fails with gcc-5 and gcc-6.
I haven't looked deeper yet.

markus@x4 tmp % clang++ -std=c++14 -O2 boost.ii && ./a.out
markus@x4 tmp % clang++ -std=c++14 -O3 boost.ii && ./a.out
markus@x4 tmp % clang++ -std=c++14 -O0 boost.ii && ./a.out
markus@x4 tmp % icpc -std=c++14 -O0 boost.ii && ./a.out
markus@x4 tmp % icpc -std=c++14 -O2 boost.ii && ./a.out
markus@x4 tmp % icpc -std=c++14 -O3 boost.ii && ./a.out
markus@x4 tmp % g++ -std=c++14 -O1 boost.ii && ./a.out
markus@x4 tmp % g++ -std=c++14 -O2 boost.ii && ./a.out
[1]12466 abort  ./a.out

[Bug target/69693] Wrong mode is used to load spilled register

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #4)

> It looks that it is done on purpose.

In this case, our planned transition to generic unaligned SSE loads should
"fix" this issue. The realignment will be necessary only for performance
reasons, not for the correctness. Maybe we should also look if
SLOW_UNALIGNED_ACCESS affects moves that may result in muvups insns.

(However, since movups from unaligned address is slow, I still think that
realignment should be fixed for STV pass).

[Bug lto/67709] ICE: in estimate_function_body_sizes, at ipa-inline-analysis.c:2489 on x86_64-apple-darwin*

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
libgomp.fortran/declare-simd-3.f90:
...
subroutine bar
  use declare_simd_2_mod
  real :: b(128)
  integer :: i

  !$omp simd   
  do i = 1, 128
b(i) = i * 2.0
  end do
  !$omp simd   
  do i = 1, 128
b(i) = foo (7.0_8, 5 * i, b(i))
  end do
  do i = 1, 128
if (b(i).ne.(7.0 + 10.0 * i * i)) call abort
  end do
end subroutine bar
...

So foo has no definition in the current module, and a call to foo is part of an
omp simd construct.

[Bug lto/67709] ICE: in estimate_function_body_sizes, at ipa-inline-analysis.c:2489 on x86_64-apple-darwin*

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
ICE backtrace:
...
src/libgomp/testsuite/libgomp.fortran/declare-simd-3.f90: At top level:
src/libgomp/testsuite/libgomp.fortran/declare-simd-3.f90:7:0: internal compiler
error: in estimate_function_body_sizes, at ipa-inline-analysis.c:2486
   use declare_simd_2_mod

0xc9319d estimate_function_body_sizes
src/gcc/ipa-inline-analysis.c:2486
0xc950dd compute_inline_parameters(cgraph_node*, bool)
src/gcc/ipa-inline-analysis.c:2953
0xc9813b inline_analyze_function(cgraph_node*)
src/gcc/ipa-inline-analysis.c:4078
0xc98205 inline_summary_t::insert(cgraph_node*, inline_summary*)
src/gcc/ipa-inline-analysis.c:4105
0x9a6213 symbol_table::call_cgraph_insertion_hooks(cgraph_node*)
src/gcc/cgraph.c:371
0xdefa0e simd_clone_create
src/gcc/omp-low.c:18738
0xdf5012 expand_simd_clones
src/gcc/omp-low.c:19799
0xdf519b ipa_omp_simd_clone
src/gcc/omp-low.c:19839
0xdf520a execute
src/gcc/omp-low.c:19867
Please submit a full bug report,
...

[Bug lto/67709] ICE: in estimate_function_body_sizes, at ipa-inline-analysis.c:2489 on x86_64-apple-darwin*

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 37609
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37609=edit
tentative patch

[Bug lto/69707] New: FAIL: parallel-dims.c test for excess errors with -flto -fno-use-linker-plugin

[vries at gcc dot gnu.org]

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

Bug ID: 69707
   Summary: FAIL: parallel-dims.c test for excess errors with
-flto -fno-use-linker-plugin
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

gcc is called with -fdiagnostics-color=never, but lto1 is called without it:
...
lto1 -quiet -m64 -O2 -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-openmp -foffload-abi=lp64 -fno-diagnostics-show-caret -fopenacc
-ftree-parallelize-loops=32 @/tmp/cc9vUz7t -o parallel-dims.s
...

It seems lto-wrapper drops it.

Running lto1 diagnostics color confuses the 'test for excess errors'.

[Bug target/69706] New: internal compiler error: in extract_constrain_insn, at recog.c:2246

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 69706
   Summary: internal compiler error: in extract_constrain_insn, at
recog.c:2246
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: jemarch at gnu dot org
  Target Milestone: ---
  Host: sparc*-*-*
Target: sparc*-*-*

Created attachment 37608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37608=edit
Preprocessed source for matio.cpp (gzip compressed)

Hello!

Building gromacs on sparc64 in Debian currently fails with:

/«PKGBUILDDIR»/src/gromacs/fileio/matio.cpp: In function 'void write_xpm(FILE*,
unsigned int, const char*, const char*, const char*, const char*, int, int,
real*, real*, real**, real, real, t_rgb, t_rgb, int*)':
/«PKGBUILDDIR»/src/gromacs/fileio/matio.cpp:1189:1: error: insn does not
satisfy its constraints:
 }
 ^
(insn 53 58 48 2 (set (reg:SF 40 %f8 [orig:291 rhi+8 ] [291])
(reg:SF 64 %f32 [ rhi+8 ]))
/«PKGBUILDDIR»/src/gromacs/fileio/matio.cpp:1162 97 {*movsf_insn}
 (expr_list:REG_EQUIV (mem/c:SF (plus:DI (reg/f:DI 101 %sfp)
(const_int 256 [0x100])) [15 rhi+8 S4 A64])
(nil)))
/«PKGBUILDDIR»/src/gromacs/fileio/matio.cpp:1189:1: internal compiler error: in
extract_constrain_insn, at recog.c:2246
0x71a3cf _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:110
0x71a3ff _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:121
0x6e2bc7 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2246
0x6c5097 reload_cse_simplify_operands
../../src/gcc/postreload.c:430
0x6c683f reload_cse_simplify
../../src/gcc/postreload.c:207
0x6c683f reload_cse_regs_1
../../src/gcc/postreload.c:246
0x6c7f4b reload_cse_regs
../../src/gcc/postreload.c:94
0x6c7f4b execute
../../src/gcc/postreload.c:2387
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccvx0J6o.out file, please attach this to
your bugreport.

Full build log in [1].

Attaching the pre-processed source.

Cheers,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gromacs=sparc64=5.1.1-2=1454662797