[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #38 from Thomas Koenig  ---
This works for Intel and AMD now.

If anybody wants another architecture, we know how to do it.

Closing.

[Bug target/80510] Optimize Power7/power8 Altivec load/stores

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Fri May 26 01:52:24 2017
New Revision: 248480

URL: https://gcc.gnu.org/viewcvs?rev=248480=gcc=rev
Log:
[gcc]
2017-05-25  Michael Meissner  

Backport from trunk
2017-05-18  Michael Meissner  

PR target/80510
* config/rs6000/predicates.md (simple_offsettable_mem_operand):
New predicate.

* config/rs6000/rs6000.md (ALTIVEC_DFORM): New iterator.
(define_peephole2 for Altivec d-form load): Add peepholes to catch
cases where the register allocator uses a move and an offsettable
memory operation to/from a FPR register on ISA 2.06/2.07.
(define_peephole2 for Altivec d-form store): Likewise.

Backport from trunk
2017-05-09  Michael Meissner  

PR target/68163
* config/rs6000/rs6000.md (f32_lr): Delete mode attributes that
are now unused after splitting mov{sf,sd}_hardfloat.
(f32_lr2): Likewise.
(f32_lm): Likewise.
(f32_lm2): Likewise.
(f32_li): Likewise.
(f32_li2): Likewise.
(f32_lv): Likewise.
(f32_sr): Likewise.
(f32_sr2): Likewise.
(f32_sm): Likewise.
(f32_sm2): Likewise.
(f32_si): Likewise.
(f32_si2): Likewise.
(f32_sv): Likewise.
(f32_dm): Likewise.
(f32_vsx): Likewise.
(f32_av): Likewise.
(mov_hardfloat): Split into separate movsf and movsd pieces.
For movsf, order stores so the VSX stores occur before the GPR
store which encourages the register allocator to use a traditional
FPR instead of a GPR.  For movsd, order the stores so that the GPR
store comes before the VSX stores to allow the power6 to work.
This is due to the power6 not having a 32-bit integer store
instruction from a FPR.
(movsf_hardfloat): Likewise.
(movsd_hardfloat): Likewise.

[gcc/testsuite]
2017-05-25  Michael Meissner  

Backport from trunk
2017-05-18  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: New test.
* gcc.target/powerpc/pr80510-2.c: Likewise.

Backport from trunk
2017-05-09  Michael Meissner  

PR target/68163
* gcc.target/powerpc/pr68163.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr68163.c
  - copied unchanged from r248471,
trunk/gcc/testsuite/gcc.target/powerpc/pr68163.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
  - copied unchanged from r248471,
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
  - copied unchanged from r248471,
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/predicates.md
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/68163] GCC on power8 does not issue the stxsspx instruction on power8

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Fri May 26 01:52:24 2017
New Revision: 248480

URL: https://gcc.gnu.org/viewcvs?rev=248480=gcc=rev
Log:
[gcc]
2017-05-25  Michael Meissner  

Backport from trunk
2017-05-18  Michael Meissner  

PR target/80510
* config/rs6000/predicates.md (simple_offsettable_mem_operand):
New predicate.

* config/rs6000/rs6000.md (ALTIVEC_DFORM): New iterator.
(define_peephole2 for Altivec d-form load): Add peepholes to catch
cases where the register allocator uses a move and an offsettable
memory operation to/from a FPR register on ISA 2.06/2.07.
(define_peephole2 for Altivec d-form store): Likewise.

Backport from trunk
2017-05-09  Michael Meissner  

PR target/68163
* config/rs6000/rs6000.md (f32_lr): Delete mode attributes that
are now unused after splitting mov{sf,sd}_hardfloat.
(f32_lr2): Likewise.
(f32_lm): Likewise.
(f32_lm2): Likewise.
(f32_li): Likewise.
(f32_li2): Likewise.
(f32_lv): Likewise.
(f32_sr): Likewise.
(f32_sr2): Likewise.
(f32_sm): Likewise.
(f32_sm2): Likewise.
(f32_si): Likewise.
(f32_si2): Likewise.
(f32_sv): Likewise.
(f32_dm): Likewise.
(f32_vsx): Likewise.
(f32_av): Likewise.
(mov_hardfloat): Split into separate movsf and movsd pieces.
For movsf, order stores so the VSX stores occur before the GPR
store which encourages the register allocator to use a traditional
FPR instead of a GPR.  For movsd, order the stores so that the GPR
store comes before the VSX stores to allow the power6 to work.
This is due to the power6 not having a 32-bit integer store
instruction from a FPR.
(movsf_hardfloat): Likewise.
(movsd_hardfloat): Likewise.

[gcc/testsuite]
2017-05-25  Michael Meissner  

Backport from trunk
2017-05-18  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: New test.
* gcc.target/powerpc/pr80510-2.c: Likewise.

Backport from trunk
2017-05-09  Michael Meissner  

PR target/68163
* gcc.target/powerpc/pr68163.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr68163.c
  - copied unchanged from r248471,
trunk/gcc/testsuite/gcc.target/powerpc/pr68163.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
  - copied unchanged from r248471,
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
  - copied unchanged from r248471,
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/predicates.md
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/71451] [5/6/7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: in dependent_type_p, at cp/pt.c:22599

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[5/6/7/8 Regression] ICE on |[5/6/7 Regression] ICE on
   |invalid C++11 code on   |invalid C++11 code on
   |x86_64-linux-gnu: in|x86_64-linux-gnu: in
   |dependent_type_p, at|dependent_type_p, at
   |cp/pt.c:22599   |cp/pt.c:22599

--- Comment #6 from Paolo Carlini  ---
Done.

[Bug c++/79652] [5/6/7 Regression] ICE on invalid c++ code in warn_extern_redeclared_static in cp/decl.c:1231

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[5/6/7/8 Regression] ICE on |[5/6/7 Regression] ICE on
   |invalid c++ code in |invalid c++ code in
   |warn_extern_redeclared_stat |warn_extern_redeclared_stat
   |ic in cp/decl.c:1231|ic in cp/decl.c:1231

--- Comment #6 from Paolo Carlini  ---
Done.

[Bug c++/79652] [5/6/7/8 Regression] ICE on invalid c++ code in warn_extern_redeclared_static in cp/decl.c:1231

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu May 25 22:29:40 2017
New Revision: 248474

URL: https://gcc.gnu.org/viewcvs?rev=248474=gcc=rev
Log:
2017-05-25  Paolo Carlini  

PR c++/79652
* g++.dg/cpp0x/pr79652.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr79652.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/71451] [5/6/7/8 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: in dependent_type_p, at cp/pt.c:22599

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu May 25 22:28:54 2017
New Revision: 248473

URL: https://gcc.gnu.org/viewcvs?rev=248473=gcc=rev
Log:
2017-05-25  Paolo Carlini  

PR c++/71451
* g++.dg/cpp0x/variadic170.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic170.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #37 from Thomas Koenig  ---
Author: tkoenig
Date: Thu May 25 21:51:27 2017
New Revision: 248472

URL: https://gcc.gnu.org/viewcvs?rev=248472=gcc=rev
Log:
2017-05-25  Thomas Koenig  

PR libfortran/78379
* Makefile.am: Add generated/matmulavx128_*.c files.
Handle them for compiling and setting the right flags.
* acinclude.m4: Add tests for FMA3, FMA4 and AVX128.
* configure.ac: Call them.
* Makefile.in: Regenerated.
* config.h.in: Regenerated.
* configure: Regenerated.
* m4/matmul.m4:  Handle AMD chips by calling 128-bit AVX
versions which use FMA3 or FMA4.
* m4/matmulavx128.m4: New file.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Regenerated.
* generated/matmul_c4.c: Regenerated.
* generated/matmul_c8.c: Regenerated.
* generated/matmul_i1.c: Regenerated.
* generated/matmul_i16.c: Regenerated.
* generated/matmul_i2.c: Regenerated.
* generated/matmul_i4.c: Regenerated.
* generated/matmul_i8.c: Regenerated.
* generated/matmul_r10.c: Regenerated.
* generated/matmul_r16.c: Regenerated.
* generated/matmul_r4.c: Regenerated.
* generated/matmul_r8.c: Regenerated.
* generated/matmulavx128_c10.c: New file.
* generated/matmulavx128_c16.c: New file.
* generated/matmulavx128_c4.c: New file.
* generated/matmulavx128_c8.c: New file.
* generated/matmulavx128_i1.c: New file.
* generated/matmulavx128_i16.c: New file.
* generated/matmulavx128_i2.c: New file.
* generated/matmulavx128_i4.c: New file.
* generated/matmulavx128_i8.c: New file.
* generated/matmulavx128_r10.c: New file.
* generated/matmulavx128_r16.c: New file.
* generated/matmulavx128_r4.c: New file.
* generated/matmulavx128_r8.c: New file.


Added:
trunk/libgfortran/generated/matmulavx128_c10.c
trunk/libgfortran/generated/matmulavx128_c16.c
trunk/libgfortran/generated/matmulavx128_c4.c
trunk/libgfortran/generated/matmulavx128_c8.c
trunk/libgfortran/generated/matmulavx128_i1.c
trunk/libgfortran/generated/matmulavx128_i16.c
trunk/libgfortran/generated/matmulavx128_i2.c
trunk/libgfortran/generated/matmulavx128_i4.c
trunk/libgfortran/generated/matmulavx128_i8.c
trunk/libgfortran/generated/matmulavx128_r10.c
trunk/libgfortran/generated/matmulavx128_r16.c
trunk/libgfortran/generated/matmulavx128_r4.c
trunk/libgfortran/generated/matmulavx128_r8.c
trunk/libgfortran/m4/matmulavx128.m4
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/acinclude.m4
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/generated/matmul_c10.c
trunk/libgfortran/generated/matmul_c16.c
trunk/libgfortran/generated/matmul_c4.c
trunk/libgfortran/generated/matmul_c8.c
trunk/libgfortran/generated/matmul_i1.c
trunk/libgfortran/generated/matmul_i16.c
trunk/libgfortran/generated/matmul_i2.c
trunk/libgfortran/generated/matmul_i4.c
trunk/libgfortran/generated/matmul_i8.c
trunk/libgfortran/generated/matmul_r10.c
trunk/libgfortran/generated/matmul_r16.c
trunk/libgfortran/generated/matmul_r4.c
trunk/libgfortran/generated/matmul_r8.c
trunk/libgfortran/m4/matmul.m4

[Bug c++/80605] [7/8 Regression] Bad is_standard_layout result with empty base classes

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu May 25 21:24:36 2017
New Revision: 248470

URL: https://gcc.gnu.org/viewcvs?rev=248470=gcc=rev
Log:
PR c++/80605 - __is_standard_layout and zero-length array

* class.c (check_bases): Use DECL_FIELD_IS_BASE.

Added:
trunk/gcc/testsuite/g++.dg/ext/is_std_layout2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247848

[ian at airs dot com]

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

--- Comment #15 from Ian Lance Taylor  ---
Thanks for looking into this.  What you are seeing is odd and I have no
explanation.  Can you try building the test with GOCFLAGS="-g -O2
-fgo-dump-ast" which should give you a .go.dump.ast file in the working
directory.  Attach that file.  That will help show whether the problem is in
the Go frontend or whether the missing assignments are being removed by the GCC
middle-end somewhere.  Thanks.

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||x86_64-apple-darwin16
 Status|UNCONFIRMED |NEW
   Last reconfirmed|2017-05-24 00:00:00 |2017-05-25
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
> I just got the following building trunk on x86_64-pc-linux-gnu
> with no special flags, just $srcdir/configure --enable-languages=c,c++,ada
> --enable-werror

Same thing on darwin between revisions r248422 (bootstrap modulo pr80556) and
r248466.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #16 from Daniel Santos  ---
Sorry for my delayed response.  I'm working on adding extended tests triggered
by an environment variable (because I needed to better validate somebody else's
changes to my -mcall-ms2sysv-xlogues feature and I encountered a flaw in my
test program when the header is generated with a -p range of 7 or higher.

(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> You need to make certain to have the necessary 32-bit libraries and
> headers.  Apart from that, configure --target=i686-pc-linux-gnu
> --enable-targets=all should be enough, together with CC='gcc -m32'
> CXX='g++ -m32'.  I don't pass --enable-multilib, this happens by default.

I seem to have encountered some type of bug in something here (autoconf
maybe?).  When the build gets to running configure on libgcc, it fails with:

configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [Makefile:13549: configure-target-libgcc] Error 1
make[1]: Leaving directory
'/home/daniel/proj/sys/gcc/builds/testsuite-fixes-i686-pc-linux-gnu'
make: *** [Makefile:898: all] Error 2


The failure is actually when it's calling exec with -- and the option isn't
recognized:


configure:3469:
/home/daniel/proj/sys/gcc/builds/testsuite-fixes-i686-pc-linux-gnu/./gcc/xgcc
-B/home/daniel/proj/sys/gcc/builds/testsuite-fixes-i686-pc-linux-gnu/./gc
c/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-incl
ude-o conftest -g -O2   conftest.c  >&5
/home/daniel/proj/sys/gcc/builds/testsuite-fixes-i686-pc-linux-gnu/./gcc/as:
line 106: exec: --: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
configure:3472: $? = 1
configure:3660: checking for suffix of object files
configure:3682:
/home/daniel/proj/sys/gcc/builds/testsuite-fixes-i686-pc-linux-gnu/./gcc/xgcc
-B/home/daniel/proj/sys/gcc/builds/testsuite-fixes-i686-pc-linux-gnu/./gc
c/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-incl
ude-c -g -O2  conftest.c >&5
/home/daniel/proj/sys/gcc/builds/testsuite-fixes-i686-pc-linux-gnu/./gcc/as:
line 106: exec: --: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
configure:3686: $? = 1


I don't fancy myself an autotools expert, so I'm not yet certain that it's a
bug.  I'm using gentoo with 

app-shells/bash-4.3_p48-r1
sys-devel/autoconf-2.64 (among others)
sys-devel/binutils-2.26.1

My spidy-sense tells me to try out binutils 2.27 or some such.

I'll get back on the rest of this soon.

[Bug tree-optimization/80884] New: [8 regression] test case gcc.target/powerpc/20050830-1.c fails starting with r247886

[seurer at gcc dot gnu.org]

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

Bug ID: 80884
   Summary: [8 regression] test case
gcc.target/powerpc/20050830-1.c fails starting with
r247886
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This test fails on power6 (BE obviously) but still works on power7 and later. 
The test case is looking for a specific assembler instruction

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk-p6/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk-p6/gcc/
/home/seurer/gcc/gcc-trunk-p6/gcc/testsuite/gcc.target/powerpc/20050830-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ffat-lto-objects -S
-o 20050830-1.s
PASS: gcc.target/powerpc/20050830-1.c (test for excess errors)
FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

and the assembler output changed like this from r247885 to r247886:

seurer@makalu-lp1:~/gcc/build/gcc-test$ diff 20050830-1.s.old 20050830-1.s.new
19,30c19,29
<   addis 10,2,.LC0@toc@ha
<   addi 9,3,-512
<   rldicl 9,9,56,40
<   addi 9,9,1
<   ld 8,.LC0@toc@l(10)
<   addi 10,3,-256
<   sldi 3,3,2
<   cmpwi 7,10,256
<   mtctr 9
<   add 3,3,8
<   li 9,42
<   blt 7,.L7
---
>   addis 9,2,.LC0@toc@ha
>   addi 10,3,-512
>   rlwinm 10,10,0,0,23
>   subf 10,10,3
>   ld 8,.LC0@toc@l(9)
>   sldi 10,10,2
>   sldi 9,3,2
>   addi 7,8,-1024
>   add 9,9,8
>   add 10,10,7
>   li 8,42
33,35c32,35
<   stw 9,0(3)
<   addi 3,3,-1024
<   bdnz .L3
---
>   stw 8,0(9)
>   addi 9,9,-1024
>   cmpld 7,9,10
>   bne 7,.L3
38,41d37
< .L7:
<   li 10,1
<   mtctr 10
<   b .L3
45c41
<   .ident  "GCC: (GNU) 8.0.0 20170511 (experimental) [trunk revision
247885]"
---
>   .ident  "GCC: (GNU) 8.0.0 20170511 (experimental) [trunk revision 
> 247886]"


When I tried it with a compiler built for power7 there was no difference is the
assembly before/after this revision.

[Bug c++/79583] ICE (internal compiler error) upon instantiation of class template with `auto` template parameter containing inner class template

[jason at redhat dot com]

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

--- Comment #6 from Jason Merrill  ---
FAIL: g++.dg/cpp0x/pr79583.C  -std=c++1z  (test for errors, line 3)

On Thu, May 25, 2017 at 5:33 AM, paolo at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79583
>
> --- Comment #3 from paolo at gcc dot gnu.org  ---
> Author: paolo
> Date: Thu May 25 09:32:46 2017
> New Revision: 248451
>
> URL: https://gcc.gnu.org/viewcvs?rev=248451=gcc=rev
> Log:
> 2017-05-25  Paolo Carlini  
>
> PR c++/79583
> * g++.dg/cpp0x/pr79583.C: New.
>
> Added:
> trunk/gcc/testsuite/g++.dg/cpp0x/pr79583.C
> Modified:
> trunk/gcc/testsuite/ChangeLog
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/79583] ICE (internal compiler error) upon instantiation of class template with `auto` template parameter containing inner class template

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
FAIL: g++.dg/cpp0x/pr79583.C  -std=c++1z  (test for errors, line 3)

[Bug fortran/35339] Improve translation of implied do loop in transfer

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #41419|0   |1
is obsolete||

--- Comment #7 from Nicolas Koenig  ---
Created attachment 41420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41420=edit
Early patch for simplifying impl do loops - 2

Sorry, wrong patch _and_ wrong testcase... Still fails for mysterious reasons,
though.

gcc@dcm-linux:~/pr/35339> cat z3.f90
program main
implicit none
integer:: i
integer, parameter:: k = 2
integer, dimension(4):: a = [(i, i=1,4)]
write (*,*) (a(k), i=1,4) 
end program
gcc@dcm-linux:~/pr/35339> gfortran -O z3.f90
z3.f90:6:0:

 write (*,*) (a(k), i=1,4)

internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6792
0x73175d gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../trunk/gcc/fortran/trans-array.c:6792
0x7a811b gfc_trans_transfer(gfc_code*)
../../trunk/gcc/fortran/trans-io.c:2581
0x71dffb trans_code
../../trunk/gcc/fortran/trans.c:2017
0x71e164 gfc_trans_code_cond(gfc_code*, tree_node*)
../../trunk/gcc/fortran/trans.c:2120
0x7c4fa2 gfc_trans_simple_do
../../trunk/gcc/fortran/trans-stmt.c:1942
0x7c5473 gfc_trans_do(gfc_code*, tree_node*)
../../trunk/gcc/fortran/trans-stmt.c:2075
0x71ddf4 trans_code
../../trunk/gcc/fortran/trans.c:1917
0x71e164 gfc_trans_code_cond(gfc_code*, tree_node*)
../../trunk/gcc/fortran/trans.c:2120
0x7a6bad build_dt
../../trunk/gcc/fortran/trans-io.c:2017
0x7a6c88 gfc_trans_write(gfc_code*)
../../trunk/gcc/fortran/trans-io.c:2056
0x71df71 trans_code
../../trunk/gcc/fortran/trans.c:1989
0x71e183 gfc_trans_code(gfc_code*)
../../trunk/gcc/fortran/trans.c:2128
0x7590ed gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6332
0x71e1c7 gfc_generate_code(gfc_namespace*)
../../trunk/gcc/fortran/trans.c:2145
0x6b0646 translate_all_program_units
../../trunk/gcc/fortran/parse.c:6074
0x6b0c56 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6274
0x706d3f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/80883] New: Hardcoded null DSO handle parameter to __cxa_thread_atexit() on MinGW-w64 targets

[lh_mouse at 126 dot com]

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

Bug ID: 80883
   Summary: Hardcoded null DSO handle parameter to
__cxa_thread_atexit() on MinGW-w64 targets
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

It looks like that GCC for MinGW-w64 targets always passes a null DSO handle to
`__cxa_thread_atexit()` when registering destructors for objects with thread
storage duration. This violates Itanium ABI apparently, doesn't it?
The `__cxa_thread_atexit()` function calls `GetModuleHandleExW()` to obtain a
DLL handle from the function that will be called, which isn't reliable at all,
because when we have `thread_local std::string s; s = "hello";` the first
parameter actually points to `std::string::~basic_string` which is in
libstdc++.
The destructor is then called only when libstdc++ is unloaded, but it should
have been called when the DLL that contains that thread_local definition is
unloaded.


Testcase:
(This can be found http://paste.ubuntu.com/24657853/ at the moment.)
-
E:\Desktop>cat test.cc
#include 

extern "C" int __stdcall DllMain(void *hInstance, void *, unsigned long
dwReason, void *pReserved){
thread_local std::string s;
s = "hello";
return 1;
}

E:\Desktop>g++ test.cc -std=c++11 -O3 -shared -S

E:\Desktop>cat test.s
.file   "test.cc"
.section .rdata,"dr"
.LC0:
.ascii "hello\0"
.text
.globl  DllMain
.defDllMain;.scl2;  .type   32; .endef
.seh_proc   DllMain
DllMain:
.LFB1041:
pushq   %rsi
.seh_pushreg%rsi
pushq   %rbx
.seh_pushreg%rbx
subq$56, %rsp
.seh_stackalloc 56
.seh_endprologue
leaq__emutls_v._ZGVZ7DllMainE1s(%rip), %rcx
call__emutls_get_address
movq%rax, %rsi
leaq__emutls_v._ZZ7DllMainE1s(%rip), %rcx
call__emutls_get_address
movq%rax, %rbx
cmpb$0, (%rsi)
jne .L2
leaq16(%rax), %rax
movq%rax, (%rbx)
movq$0, 8(%rbx)
movb$0, 16(%rbx)
movb$1, (%rsi)
xorl%r8d, %r8d
movq%rbx, %rdx
leaq   
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev(%rip), %rcx
call__cxa_thread_atexit
.L2:
movq8(%rbx), %r8
movq$5, 32(%rsp)
leaq.LC0(%rip), %r9
xorl%edx, %edx
movq%rbx, %rcx
call   
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEyyPKcy
movl$1, %eax
addq$56, %rsp
popq%rbx
popq%rsi
ret
.seh_endproc
.data
.align 32
__emutls_v._ZZ7DllMainE1s:
.quad   32
.quad   8
.quad   0
.quad   0
.align 32
__emutls_v._ZGVZ7DllMainE1s:
.quad   8
.quad   8
.quad   0
.quad   0
.ident  "GCC: (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.) 7.1.1 20170518"
.def__emutls_get_address;   .scl2;  .type   32; .endef
.def_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev; 
.scl2;  .type   32; .endef
.def__cxa_thread_atexit;.scl2;  .type   32; .endef
.def   
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEyyPKcy;  
.scl2;  .type   32; .endef
.section   
.rdata$.refptr._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev, "dr"
.globl 
.refptr._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev
.linkonce   discard
.refptr._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev:
.quad   _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev

E:\Desktop>gcc --version
gcc (gcc-7-branch HEAD with MCF thread model, built by LH_Mouse.) 7.1.1
20170518
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


E:\Desktop>
-
In the case of Windows x64 ABI the first four parameters are passed in
RCX/XMM0, RDX/XMM1, R8/XMM2 and R9/XMM3, respectively.
The third parameter (DSO handle) is R8 and here it is apparently set to zero on
line #43.

[Bug fortran/35339] Improve translation of implied do loop in transfer

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 CC||koenigni at gcc dot gnu.org

--- Comment #6 from Nicolas Koenig  ---
Created attachment 41419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41419=edit
Early patch for simplifying impl do loops

Attached is a patch that simplifies implied do loops in the way suggested by
Thomas. There are, however, still a few problems with this patch that I have a
hard time understanding. For example:

gcc@dcm-linux:~/pr/35339> cat z1.f90
program main
implicit none
integer:: i
integer, dimension(2,2):: a = reshape([1, 2, 3, 4], shape(a))
write (*,*) (a(i, 1), i=1,2)
end program
gcc@dcm-linux:~/pr/35339> gfortran -O z1.f90
z1.f90:5:0:

 write (*,*) (a(i, 1), i=1,4)

internal compiler error: Segmentation fault
0xbe58af crash_signal
../../trunk/gcc/toplev.c:337
0x6bea8d gfc_conv_scalarized_array_ref
../../trunk/gcc/fortran/trans-array.c:3228
0x6bfb1c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../trunk/gcc/fortran/trans-array.c:3382
0x6f95cd gfc_conv_variable
../../trunk/gcc/fortran/trans-expr.c:2680
0x6f529a gfc_conv_expr(gfc_se*, gfc_expr*)
../../trunk/gcc/fortran/trans-expr.c:7815
0x6fd41e gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../trunk/gcc/fortran/trans-expr.c:7915
0x724862 gfc_trans_transfer(gfc_code*)
../../trunk/gcc/fortran/trans-io.c:2539
0x6b3d37 trans_code
../../trunk/gcc/fortran/trans.c:2017
0x7214f2 build_dt
../../trunk/gcc/fortran/trans-io.c:2017
0x6b3d57 trans_code
../../trunk/gcc/fortran/trans.c:1989
0x6e5498 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6332
0x66c576 translate_all_program_units
../../trunk/gcc/fortran/parse.c:6074
0x66c576 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6274
0x6afe9f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


probably because the new 'transfer'-statement isn't properly inserted in the
code tree.

[Bug ipa/80882] New: [8 regression] test case gfortran.dg/pr48636.f90 fails starting with r248375

[seurer at gcc dot gnu.org]

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

Bug ID: 80882
   Summary: [8 regression] test case gfortran.dg/pr48636.f90 fails
starting with r248375
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This fails on powerpc (both BE and LE).

FAIL: gfortran.dg/pr48636.f90   -O   scan-ipa-dump fnsummary "inline hints:
loop_iterations"


Previous to this revision it failed this way:
FAIL: gfortran.dg/pr48636.f90   -O   scan-ipa-dump inline "inline hints:
loop_iterations"

And that failure started with r248365.

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[thorstenkurth at me dot com]

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

--- Comment #22 from Thorsten Kurth  ---
Hello Jakub,

that is stuff for Intel vTune. I have commented it out and added the NUM_TEAMS
defines in the GNUmakefile. Please pull the latest changes.

Best and thanks
Thorsten

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
It doesn't compile for me.
cmake -DENABLE_MPI=0 -DENABLE_OpenMP=1 ..
make -j16

I don't have ittnotify.h, I've tried to comment that out as well as the _itt*
calls, but then run into:
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:83:36: error:
‘NUM_TEAMS’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:93:82: error:
‘DEVID’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:98:74: error:
‘NUM_THREADS_PER_BOX’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:532:36: error:
‘NUM_TEAMS’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:542:82: error:
‘DEVID’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:547:78: error:
‘NUM_THREADS_PER_BOX’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:820:47: error:
‘NUM_TEAMS’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/ABecLaplacian.cpp:820:120: error:
‘DEVID’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/MultiGrid.cpp:786:36: error:
‘NUM_TEAMS’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/MultiGrid.cpp:796:82: error: ‘DEVID’
was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/MultiGrid.cpp:801:74: error:
‘NUM_THREADS_PER_BOX’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/MultiGrid.cpp:857:36: error:
‘NUM_TEAMS’ was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/MultiGrid.cpp:867:82: error: ‘DEVID’
was not declared in this scope
/usr/src/BoxLib/Src/LinearSolvers/C_CellMG/MultiGrid.cpp:872:74: error:
‘NUM_THREADS_PER_BOX’ was not declared in this scope

Is that something that ittnotify.h defines?  At least in the ittnotify.h I've
googled for it doesn't, so it is unclear from where these macros would be
satisfied.

[Bug libgomp/80881] [7.1 Regression] null pointer access in libgomp.h

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
That suggests TLS doesn't work at all on your platform (but then you should
obviously not --enable-tls).

[Bug libgomp/80881] New: [7.1 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

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

Bug ID: 80881
   Summary: [7.1 Regression] null pointer access in libgomp.h
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

GCC 7.1.0 compiled OpenMP applications fail with invalid memory access to
address 0.

Used configuration:
../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--enable-tls --disable-nls --disable-shared --enable-static
--enable-fully-dynamic-string --enable-lto --enable-plugins --enable-libgomp
--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw64-64 --with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/usr/new-gcc/lib/gmp-5.0.5 --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
--with-mpc=/usr/new-gcc/lib/mpc-0.9 --with-isl=/usr/new-gcc/lib/isl-0.18
--with-cloog=/usr/new-gcc/lib/cloog-0.18.4 --with-host-libstdcxx='-lstdc++
-lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl
Thread model: posix
gcc version 7.1.0 (GCC)

Sample application:
#include 
#include 

#define N 1024

int main() {
int i;
float var[N];
volatile float PI = 3.1415927;

#   pragma omp parallel for private(i)
for (i = 0; i < N; i++) {
var[i] = (1024.0f / PI) + 0.5f;
}

return EXIT_SUCCESS;
}

Error message from Dr.Memory (32-bit variant):
Error #1: UNADDRESSABLE ACCESS: reading 0x-0x0004 4 byte(s)
# 0 GOMP_parallel  
[../../../../../src/gcc-7.1.0/libgomp/libgomp.h:677]
# 1 main[h:\Temp\cpp017/test.c:11]
Note: @0:00:00.642 in thread 6700
Note: instruction: mov%gs:0x00 -> %esi

Error message from Dr.Memory (64-bit variant):
Error #1: UNADDRESSABLE ACCESS: reading
0x-0x0008 8 byte(s)
# 0 GOMP_parallel  
[../../../../src/gcc-7.1.0/libgomp/libgomp.h:677]
# 1 main[h:\Temp\cpp017/test.c:11]
Note: @0:00:00.170 in thread 1320
Note: instruction: mov%fs:0x00 -> %rdi

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247848

[boger at us dot ibm.com]

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

--- Comment #14 from boger at us dot ibm.com ---
I have found the incorrect code that is causing this test to fail but not sure
what causes it.  My previous theory was not correct.

The problem is that the second argument being passed to runtime.DeepEqual in
net.TestParseIP is wrong.  The storage for the arguments are being generated by
calls to runtime.newobject, followed by code to fill in the contents.  The
arguments are slices so should have 3 doublewords including the address and 2
lengths.  The first argument is initialized correctly but the second is not
storing the length values.  Here is a snippet of code from the bad a.out:

  10066158:   69 91 fc 4b bl  1002f2c0
<3287.plt_call.runtime.newobject>
1006615c:   18 00 41 e8 ld  r2,24(r1)
10066160:   10 02 01 e9 ld  r8,528(r1)
10066164:   18 02 41 e9 ld  r10,536(r1)
10066168:   20 02 21 e9 ld  r9,544(r1)
1006616c:   f8 01 a1 38 addir5,r1,504
10066170:   78 1b 72 7c mr  r18,r3
10066174:   78 fb e3 7f mr  r3,r31
10066178:   78 93 44 7e mr  r4,r18
1006617c:   f8 01 01 f9 std r8,504(r1)
10066180:   00 02 41 f9 std r10,512(r1)
10066184:   08 02 21 f9 std r9,520(r1)
10066188:   d9 92 fc 4b bl  1002f460
<3287.plt_call.runtime.typedmemmove>
1006618c:   18 00 41 e8 ld  r2,24(r1)
10066190:   78 fb e3 7f mr  r3,r31
10066194:   2d 91 fc 4b bl  1002f2c0
<3287.plt_call.runtime.newobject>
10066198:   18 00 41 e8 ld  r2,24(r1)
1006619c:   e0 01 a1 38 addir5,r1,480
100661a0:   e0 01 c1 fb std r30,480(r1)
100661a4:   78 1b 70 7c mr  r16,r3
100661a8:   78 fb e3 7f mr  r3,r31
100661ac:   78 83 04 7e mr  r4,r16
100661b0:   b1 92 fc 4b bl  1002f460
<3287.plt_call.runtime.typedmemmove>
100661b4:   18 00 41 e8 ld  r2,24(r1)
100661b8:   78 fb e5 7f mr  r5,r31
100661bc:   78 83 06 7e mr  r6,r16
100661c0:   78 fb e3 7f mr  r3,r31
100661c4:   78 93 44 7e mr  r4,r18
100661c8:   49 9b fc 4b bl  1002fd10
<3287.plt_call.reflect.DeepEqual>


In gdb I can see that the length field in the slice passed to DeepEqual and
then deepValueEqual is 0 causing them to appear not equal, and the length 0
causes other problems later on.

I tried to reproduce this in a small testcase but it did not fail.  In that
case the code looks like this:

   10002c48:   19 f9 ff 4b bl  10002560
<00be.plt_call.runtime.newobject>
10002c4c:   18 00 41 e8 ld  r2,24(r1)
10002c50:   78 1b 69 7c mr  r9,r3
10002c54:   c0 02 3f f9 std r9,704(r31)
10002c58:   48 03 1f e9 ld  r8,840(r31)
10002c5c:   50 03 5f e9 ld  r10,848(r31)
10002c60:   58 03 3f e9 ld  r9,856(r31)
10002c64:   a8 02 1f f9 std r8,680(r31)
10002c68:   b0 02 5f f9 std r10,688(r31)
10002c6c:   b8 02 3f f9 std r9,696(r31)
10002c70:   c0 02 3f e9 ld  r9,704(r31)
10002c74:   a8 02 5f 39 addir10,r31,680
10002c78:   78 53 45 7d mr  r5,r10
10002c7c:   78 4b 24 7d mr  r4,r9
10002c80:   58 80 62 e8 ld  r3,-32680(r2)
10002c84:   fd fa ff 4b bl  10002780
<00be.plt_call.runtime.typedmemmove>
10002c88:   18 00 41 e8 ld  r2,24(r1)
10002c8c:   c0 02 3f e9 ld  r9,704(r31)
10002c90:   78 4b 33 7d mr  r19,r9
10002c94:   58 80 82 ea ld  r20,-32680(r2)
10002c98:   58 80 62 e8 ld  r3,-32680(r2)
10002c9c:   c5 f8 ff 4b bl  10002560
<00be.plt_call.runtime.newobject>
10002ca0:   18 00 41 e8 ld  r2,24(r1)
10002ca4:   78 1b 69 7c mr  r9,r3
10002ca8:   a0 02 3f f9 std r9,672(r31)
10002cac:   c8 02 1f e9 ld  r8,712(r31)
10002cb0:   d0 02 5f e9 ld  r10,720(r31)
10002cb4:   d8 02 3f e9 ld  r9,728(r31)
10002cb8:   88 02 1f f9 std r8,648(r31)
10002cbc:   90 02 5f f9 std r10,656(r31)
10002cc0:   98 02 3f f9 std r9,664(r31)
10002cc4:   a0 02 3f e9 ld  r9,672(r31)
10002cc8:   88 02 5f 39 addir10,r31,648
10002ccc:   78 53 45 7d mr  r5,r10
10002cd0:   78 4b 24 7d mr  r4,r9
10002cd4:   58 80 62 e8 ld  r3,-32680(r2)
10002cd8:   a9 fa ff 4b bl  10002780
<00be.plt_call.runtime.typedmemmove>
10002cdc:   18 00 41 e8 ld  r2,24(r1)
10002ce0:   a0 02 3f e9 ld  r9,672(r31)
10002ce4:   78 4b 35 7d mr  r21,r9
10002ce8:   78 a3 85 7e mr  r5,r20
10002cec:   78 ab a6 7e mr  r6,r21
10002cf0:   78 93 43 7e mr  r3,r18
10002cf4:   78 9b 64 7e mr  r4,r19
10002cf8:   19 

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[thorstenkurth at me dot com]

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

--- Comment #20 from Thorsten Kurth  ---
To compile the code, edit the GNUmakefile to suit your needs (feel free to ask
any questions) and in order to run it run the generated executable, called
something like

main3d.XXX...

and the XXX tell you if you compiled with MPI, OpenMP, etc. There is an inputs
file you just pass to it:

./main3d.. inputs

That's it. Tell me if you need more info.

[Bug tree-optimization/80880] New: internal compiler error: in ix86_expand_builtin

[aivchenk at gcc dot gnu.org]

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

Bug ID: 80880
   Summary: internal compiler error: in ix86_expand_builtin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aivchenk at gcc dot gnu.org
  Target Milestone: ---

While fixing bootstrap for MPX I faced this new ICE:

> cat gensupport.c
int *fn1() {
  int *r = fn1();
  if (r == __null)
return r;
}

> g++ gensupport.c -O1 -mmpx -fcheck-pointer-bounds

And the guilty revision is:

commit 380ca246b31875b432a536e54102959888d546fa
Author: rguenth 
Date:   Tue Apr 25 09:26:37 2017 +

2017-04-25  Richard Biener  

PR tree-optimization/79201
* tree-ssa-sink.c (statement_sink_location): Handle calls.

* gcc.dg/tree-ssa/ssa-sink-16.c: New testcase.
* gcc.target/i386/pr22152.c: Disable sinking.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@247159
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug rtl-optimization/80754] [8 Regression][LRA] Invalid smull instruction generated in lra-remat

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #7 from Wilco  ---
Fixed on trunk and GCC7.2.

[Bug target/80671] config/aarch64/cortex-a57-fma-steering.c:416: bad statement order ?

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #4 from Wilco  ---
Fixed in trunk and GCC7.2.

[Bug sanitizer/80879] False positive for -fsanitize-address-use-after-scope

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-25
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||7.1.0, 8.0

[Bug sanitizer/80879] New: False positive for -fsanitize-address-use-after-scope

[marxin at gcc dot gnu.org]

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

Bug ID: 80879
   Summary: False positive for -fsanitize-address-use-after-scope
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

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

Test-case is isolated from libmozsqlite:
https://bugzilla.mozilla.org/show_bug.cgi?id=1367148

[Bug rtl-optimization/80754] [8 Regression][LRA] Invalid smull instruction generated in lra-remat

[wilco at gcc dot gnu.org]

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

--- Comment #6 from Wilco  ---
Author: wilco
Date: Thu May 25 15:12:49 2017
New Revision: 248463

URL: https://gcc.gnu.org/viewcvs?rev=248463=gcc=rev
Log:
When lra-remat rematerializes an instruction with a clobber, it checks
that the clobber does not kill live registers.  However it fails to check
that the clobber also doesn't overlap with the destination register of the 
final rematerialized instruction.  As a result it is possible to generate
illegal instructions with the same hard register as the destination and a
clobber.  Fix this by also checking for overlaps with the destination
register.

Backport from mainline
PR rtl-optimization/80754
* lra-remat.c (do_remat): Add overlap checks for dst_regno.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/lra-remat.c

[Bug target/80671] config/aarch64/cortex-a57-fma-steering.c:416: bad statement order ?

[wilco at gcc dot gnu.org]

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

--- Comment #3 from Wilco  ---
Author: wilco
Date: Thu May 25 15:10:01 2017
New Revision: 248461

URL: https://gcc.gnu.org/viewcvs?rev=248461=gcc=rev
Log:
Move an use-after-free access before the delete.

Backport from mainline
PR target/80671
* config/aarch64/cortex-a57-fma-steering.c (merge_forest):
Move member access before delete.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/aarch64/cortex-a57-fma-steering.c

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I just got the following building trunk on x86_64-pc-linux-gnu with no special
flags, just $srcdir/configure --enable-languages=c,c++,ada --enable-werror


/home/jwakely/src/gcc/bootstrap/./gcc/xgcc
-B/home/jwakely/src/gcc/bootstrap/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-c -g -O2 -m32 -fpic  -W -Wall
-gnatpg -nostdinc -m32  s-regpat.adb -o s-regpat.o

raised STORAGE_ERROR : stack overflow or erroneous memory access
../gcc-interface/Makefile:296: recipe for target 's-regpat.o' failed

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Yes, I didn't say it's lock-free, but the code can be compiled and linked.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[admin_public at liblfds dot org]

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

--- Comment #4 from admin_public at liblfds dot org ---
I've had a look at the libatomic source code.  Obviously, it's problematic to
be sure you're understanding a large code base correctly when you go to it for
the first time and you're looking something specific, so forgive me if I am
here completely mistaken!

I think I understand you Jonathan to mean that in the absence (by whatever
means) of the native instruction, a replacement is provided, which has a
different internal mechanism.

>From what I can see in the libatomic code (and I may be completely wrong!),
this internal mechanism under POSIX is a mutex.

One of the advantages of lock-free data structures is that when properly
written, they scale well.  This advantage will absolutely and most certainly no
longer exist if the native instruction is replaced by an alternative, as there
are, as far as I know, no alternatives on any platforms which will continue to
allow the scaling properties of the native instruction.

In other words, libatomic is absolutely no use to lock-free data structures. 
This is not a fatal problem, as inline assembly can be used.

(Also, lock-free data structures do not sleep, where a mutex can, and that does
change the behaviour of the code, for there are some places in some kernels
where you are not permitted to sleep.)

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[weeks at iastate dot edu]

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

--- Comment #7 from Nathan Weeks  ---
The Cray 8.5.4 compiler supports only OpenMP 4.0, and so lacks support for
omp_get_num_places(), omp_get_place_num_procs(), and omp_get_place_proc_ids().

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
libatomic provides a definition for __atomic_compare_exchange_16 when the
native instruction isn't available.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[admin_public at liblfds dot org]

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

--- Comment #2 from admin_public at liblfds dot org ---
Am I right in understanding your comment to mean 128 bit CAS is no longer
supported for x86_64?

I publish a library of lock-free data structures, liblfds.  It has some users,
include AT, Red Hat and Xen.

Contigious double-word compare-and-swap is necessary for a range of such data
structures, and even though this means only aarch64, arm, x86_64 and x86, it is
still of immense value, as these are common platforms.

In particular, all three of those users would find the data structures they are
using no longer compile with 7.1.0.

This is not death-and-end-of-the-world, however.  The library provides an
abstraction layer to mask platform differences, and so I would need then to add
an additional abstraction layer for GCC 7.1.0 and later on x86_64, where I use
inline assembly for 128-bit CAS (such an abstraction already exists in fact for
early versions of GCC which lack -mcx16).

One minor note : the "-mcx16" command is specific to x86_64 and so its removal
means no more double word CAS on that platform.  However, aarch64, arm and x86
will still continue to support double word CAS, as they do so natively and
without the need for a special argument to GCC.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
IIRC this was removed as the instruction cannot be used for read only memory.

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[weeks at iastate dot edu]

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

--- Comment #6 from Nathan Weeks  ---
Created attachment 41417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41417=edit
output from comment #4 code compiled with Intel 17.0.2

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[weeks at iastate dot edu]

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

--- Comment #5 from Nathan Weeks  ---
Created attachment 41416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41416=edit
output from comment #4 code compiled with gcc 6.3.0

[Bug c/80878] New: -mcx16 (enable 128 bit CAS) on x86_64 seems not to work

[admin_public at liblfds dot org]

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

Bug ID: 80878
   Summary: -mcx16 (enable 128 bit CAS) on x86_64 seems not to
work
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: admin_public at liblfds dot org
  Target Milestone: ---

Hi.

I've been building GCC compilers, starting with 4.1.2 up till 7.1.0, on a
couple of platforms.  It's hard to do, and I'm really not good at it, and I
think it practically certain this bug is really me messing things up, rather
than there being an actual real bug, except that when I switch to 6.2.0, which
I built in exactly the same way (I've written a script), the problem goes away.

The problem is that the compiler when compiling reports "undefined reference to
`__atomic_compare_exchange_16'".

I have reduced this down to a short test program, thus;

#include 
#include 

int main( void );

int main()
{
  __uint128_t
compare = 1,
exchange = 2,
target = 1;

  printf( "target before = %llu\n", (int long long unsigned) target );

  __atomic_compare_exchange( , , , 1, __ATOMIC_SEQ_CST,
__ATOMIC_SEQ_CST );

  printf( "target after = %llu\n", (int long long unsigned) target );

  return EXIT_SUCCESS;
}

I compile this with;

gcc -Wall -march=native -mtune=native -mcx16 test.c

With GCC 6.2.0, the output is;

./a.out 
target before = 1
target after = 2

With GCC 7.1.0, the output is;

/tmp/ccjMRvw1.o: In function `main':
test.c:(.text+0x75): undefined reference to `__atomic_compare_exchange_16'
collect2: error: ld returned 1 exit status

This is the same error 6.2.0 gives if I omit "-mcx16".

[Bug target/80306] ICE in cfgexpand.c during cross-compilation for mips target

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #2 from Paul Hua  ---
The bug has been fixed on trunk between r245900 and r246851.

[Bug c++/79652] [5/6/7/8 Regression] ICE on invalid c++ code in warn_extern_redeclared_static in cp/decl.c:1231

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
This seems already fixed in trunk. I guess we can as well add the testcase and
of course keep the bug open.

[Bug c++/79583] ICE (internal compiler error) upon instantiation of class template with `auto` template parameter containing inner class template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug c++/68578] [5 Regression] ICE on invalid template declaration and instantiation

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |6.0

--- Comment #8 from Paolo Carlini  ---
Done.

[Bug c++/79583] ICE (internal compiler error) upon instantiation of class template with `auto` template parameter containing inner class template

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu May 25 09:32:46 2017
New Revision: 248451

URL: https://gcc.gnu.org/viewcvs?rev=248451=gcc=rev
Log:
2017-05-25  Paolo Carlini  

PR c++/79583
* g++.dg/cpp0x/pr79583.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr79583.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/68578] [5 Regression] ICE on invalid template declaration and instantiation

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu May 25 09:32:06 2017
New Revision: 248450

URL: https://gcc.gnu.org/viewcvs?rev=248450=gcc=rev
Log:
2017-05-25  Paolo Carlini  

PR c++/68578
* g++.dg/cpp1y/pr68578.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr68578.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
That just means they don't provide really helpful information on what they
expand threads to.  Can you try:
#include 
#include 
#include 

int
main ()
{
  int num_places = omp_get_num_places (), i, j;
  printf ("num_places %d\n", num_places);
  for (i = 0; i < num_places; i++)
{
  int num_procs = omp_get_place_num_procs (i);
  int *procs = malloc (num_procs * sizeof (int));
  omp_get_place_proc_ids (i, procs);
  for (j = 0; j < num_procs; j++)
printf ("%d ", procs[j]);
  printf ("\n");
  free (procs);
}
  return 0;
}
with all the 3 compilers+runtimes and get what it prints for
OMP_PLACES=threads,
OMP_PLACES=cores and OMP_PLACES=sockets on your machine?

[Bug tree-optimization/80874] gcc does not emit cmov for minmax

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Are you sure a cmov (you'd need 2 of them) is a win?  cmov on Intel/AMD has
terrible latency, and often is a serious performance degradation, branches are
certainly much better if they can be well predicted, cmov can be only useful if
the branches can't be predicted well.

[Bug tree-optimization/80874] gcc does not emit cmov for minmax

[denis.campredon at gmail dot com]

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

--- Comment #1 from denis.campredon at gmail dot com ---
Sorry, minmax3 should not produce the same asm, since minmax return a pair of
const reference.
But still the code is less than optimal.
One part it is because gcc might be because gcc is not able to optimize the two
functions the same way:

---
struct pair {
const int , y;
};

pair minmax(int x) {
return {x, x};
}

const std::pair minmax2(int x) {
return std::minmax(x, x);
}
--

[Bug tree-optimization/80876] [8 Regression] ICE in verify_loop_structure, at cfgloop.c:1644 (error: loop 1's latch does not have an edge to its header)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-25
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r247879.

[Bug debug/80877] New: Derived template class can access base class's private constexpr/const static fields

[tomasz.jankowski at nokia dot com]

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

Bug ID: 80877
   Summary: Derived template class can access base class's private
constexpr/const static fields
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomasz.jankowski at nokia dot com
  Target Milestone: ---

Following example shows that in some cases GCC incorrectly grants access to
base class's private static members (both constexpr and const). The issue
occurs when derived class is a template class.

class Base
{
   private:
  constexpr static int value1 {4};
  const static int value2 {5};
};

template
class Derived : public Base
{
   public:
  Derived() :
 x{value1 + value2}
  {
 x = value1 + value2;
  }

  T getX() const
  {
 return x + value1 + value2;
  }

   private:
  T x;
};   

int main()
{
   Derived temp;
   return temp.getX();
}

Code was tested on recent x86-64 Linux machine using GCC v6.2.0 and v5.3.0.
Sample was compiled with following flags:
-std=c++11 -Wall -Wextra