[Bug other/80719] gcc build fails on libiberty conflicting types: CP_STATIC_IF_GLIBCPP_V3

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
*** Bug 80720 has been marked as a duplicate of this bug. ***

[Bug other/80720] gcc build fails on libiberty conflicting types: CP_STATIC_IF_GLIBCPP_V3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
dup

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

[Bug other/80719] gcc build fails on libiberty conflicting types: CP_STATIC_IF_GLIBCPP_V3

[joriswu at gmail dot com]

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

--- Comment #3 from joris  ---
Further analysis shows the conflict is that the source has 'const' yet the
header has no 'const' qualifier for struct demangle_component

Unpacking binutils into the gcc source tree is what the install guide at
https://gcc.gnu.org/install/download.html suggests.

If building binutils separately, the resulting libiberty.a is not compatible
with gcc's expectations, likely related to relocatability.

P.S. the duplicate bug is because bugzilla showed a gateway timeout at submit.

[Bug preprocessor/47857] Pragma once warning when compiling PCH

[ian at geometrian dot com]

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

Ian Mallett  changed:

   What|Removed |Added

 CC||ian at geometrian dot com

--- Comment #7 from Ian Mallett  ---
I can also confirm this bug still exists in GCC 7.1.

[Bug middle-end/80710] Stack smashing detected in correct code depending on optimization flag

[dr.markus.hoffmann at gmx dot de]

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

dr.markus.hoffmann at gmx dot de  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from dr.markus.hoffmann at gmx dot de  ---
Well, OK, so I have to switch off omit-frame-pointer... Unless I find another
more compatible solution how to call functions not knowing at compile time, if
they return a struct or not.

[Bug lto/80717] LTO wrappers segfault if run with absolute path

[theivorytower at gmail dot com]

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

--- Comment #2 from Hao Zhang  ---
Thank you for your reply. For me basically any arguments with /usr/bin/gcc-ar
fails with segfault, even running /usr/bin/gcc-ar with no additional arguments
at all. 

When I run gcc-ar with gdb (here I don't even need to have the absolute path,
"gdb gcc-ar" fails with segfault), before line 203 of gcc-ar.c, the variable
path.plist consists of the following entries:

{0x6070a0 "/usr/local/sbin/",  0x607010 "/usr/local/bin/", 0x6073c0
"/usr/bin/", 0x607400 "/usr/lib/jvm/default/bin/", 0x607450
"/usr/bin/site_perl/", 0x607490 "/usr/bin/vendor_perl/", 0x6074d0
"/usr/bin/core_perl/"}

After line 203, /usr/bin/ is removed from the list of paths:

{0x6070a0 "/usr/local/sbin/",  0x607010 "/usr/local/bin/", 0x0 , 0x607400
"/usr/lib/jvm/default/bin/", 0x607450 "/usr/bin/site_perl/", 0x607490
"/usr/bin/vendor_perl/", 0x6074d0 "/usr/bin/core_perl/"}

Since the third item is set to 0, strcpy segfaults at file-find.c:81.

[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

[theivorytower at gmail dot com]

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

Hao Zhang  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Hao Zhang  ---
The problem is now fixed with the latest gcc 7.1.1.

[Bug fortran/80722] New: gfortran can not compile omp clause with default(none) when there is a type bind method

[yundantianchang at hotmail dot com]

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

Bug ID: 80722
   Summary: gfortran can not compile omp clause with default(none)
when there is a type bind method
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yundantianchang at hotmail dot com
  Target Milestone: ---

Created attachment 41346
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41346&action=edit
this is the tow file x.f90 and bug.f90

gcc version is 5.3.1, but the version 6.3.1 and 7.1.0 is the same
Using built-in specs.
COLLECT_GCC=gcc
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.3.1-14ubuntu2'
--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.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2)


I compile it with "gfortran -fopenmp x.f90 bug.f90", error happens, it shows:

write(*,*) ss%show()
 ^
Error: ‘__vtab_module_x_Type_x’ not specified in enclosing parallel
bug.f90:7:0:

 !$omp parallel do  private(i) shared(ss)  num_threads(2) default(none)
 ^
Error: enclosing parallel

this is the case one.


but if i change omp clause default(none) to default(shared), it is ok of
course(this is case two)


and if i merge the two file into one file then use the same options to compile,
even though it is default(none), it is ok too.(this is case three)

[Bug other/80719] gcc build fails on libiberty conflicting types: CP_STATIC_IF_GLIBCPP_V3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Simply unpacking binutils would require lockstep updates, that the files in the
common directories and toplevel directory that are present in both are
identical at all times.  That is almost never the true.  So the only way that
works if you want a combined tree build (still, the snapshots have to be
roughly from the same time) is unpack on the side and copy over or symlink the
binutils subdirectories that aren't present in the gcc tree (bfd, opcodes, ld,
as, binutils etc.), for include/ just link/copy over the include/*/
subdirectories that are missing, for libiberty nothing etc.

[Bug rtl-optimization/80723] New: [8 Regression] FAIL gcc.target/i386/cadd.c scan assembler sbb

[ubizjak at gmail dot com]

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

Bug ID: 80723
   Summary: [8 Regression] FAIL gcc.target/i386/cadd.c scan
assembler sbb
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

This is a recent failure on 32bit x86 target, where if-conversion is not
performed for some reason (but it is for 32bit target).

gcc -O2 -march=k8

64 bit target:
==

_.243r.ce1:

;; Function q (q, funcdef_no=0, decl_uid=1821, cgraph_uid=0, symbol_order=1)

0 registers.

9 basic blocks, 10 edges.

4: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
6: r89:DI=`t'
3: r88:SI=0

   16: L16:
8: NOTE_INSN_BASIC_BLOCK 3
9: flags:CCZ=cmp([r89:DI],0)
   10: pc={(flags:CCZ==0)?L13:pc}
  REG_DEAD flags:CCZ
  REG_BR_PROB 5000

   11: NOTE_INSN_BASIC_BLOCK 4
   12: {r88:SI=r88:SI+0x1;clobber flags:CC;}
  REG_UNUSED flags:CC

   13: L13:
   14: NOTE_INSN_BASIC_BLOCK 5
   15: {r89:DI=r89:DI+0x4;clobber flags:CC;}
  REG_UNUSED flags:CC
   17: flags:CCZ=cmp(r89:DI,const(`t'+0x28))
   18: pc={(flags:CCZ!=0)?L16:pc}
  REG_DEAD flags:CCZ
  REG_BR_PROB 9000

   19: NOTE_INSN_BASIC_BLOCK 6
   20: flags:CCZ=cmp(r88:SI,0x6)
  REG_DEAD r88:SI
   21: pc={(flags:CCZ==0)?L27:pc}
  REG_DEAD flags:CCZ
  REG_BR_PROB 9996

   22: NOTE_INSN_BASIC_BLOCK 7
   23: call [`abort'] argc:0
  REG_CALL_DECL `abort'
  REG_NORETURN 0
  REG_EH_REGION 0

   27: L27:
   28: NOTE_INSN_BASIC_BLOCK 8






try_optimize_cfg iteration 1

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5 6 7 8
;;
;; Loop 1
;;  header 3, latch 5
;;  depth 1, outer 0
;;  nodes: 3 5 4
;; 2 succs { 3 }
;; 3 succs { 4 5 }
;; 4 succs { 5 }
;; 5 succs { 3 6 }
;; 6 succs { 7 8 }
;; 7 succs { }
;; 8 succs { 1 }
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called

IF-THEN-JOIN block found, pass 1, test 3, then 4, join 5
scanning new insn with uid = 30.
scanning new insn with uid = 31.
if-conversion succeeded through noce_try_addcc
Removing jump 10.
deleting insn with uid = 10.
deleting insn with uid = 12.
deleting block 4
Conversion succeeded on pass 1.

IF-CASE-2 found, start 6, else 8

32 bit target:
==

;; Function q (q, funcdef_no=0, decl_uid=1760, cgraph_uid=0, symbol_order=1)

0 registers.

9 basic blocks, 10 edges.

5: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
3: r90:SI=0
4: r88:SI=0

   16: L16:
7: NOTE_INSN_BASIC_BLOCK 3
9: flags:CCZ=cmp([r90:SI*0x4+`t'],0)
   10: pc={(flags:CCZ==0)?L13:pc}
  REG_DEAD flags:CCZ
  REG_BR_PROB 5000

   11: NOTE_INSN_BASIC_BLOCK 4
   12: {r88:SI=r88:SI+0x1;clobber flags:CC;}
  REG_UNUSED flags:CC

   13: L13:
   14: NOTE_INSN_BASIC_BLOCK 5
   15: {r90:SI=r90:SI+0x1;clobber flags:CC;}
  REG_UNUSED flags:CC
   17: flags:CCZ=cmp(r90:SI,0xa)
   18: pc={(flags:CCZ!=0)?L16:pc}
  REG_DEAD flags:CCZ
  REG_BR_PROB 9000

   19: NOTE_INSN_BASIC_BLOCK 6
   20: flags:CCZ=cmp(r88:SI,0x6)
  REG_DEAD r88:SI
   21: pc={(flags:CCZ==0)?L27:pc}
  REG_DEAD flags:CCZ
  REG_BR_PROB 9996

   22: NOTE_INSN_BASIC_BLOCK 7
   23: call [`abort'] argc:0
  REG_CALL_DECL `abort'
  REG_NORETURN 0
  REG_EH_REGION 0

   27: L27:
   28: NOTE_INSN_BASIC_BLOCK 8





try_optimize_cfg iteration 1

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5 6 7 8
;;
;; Loop 1
;;  header 3, latch 5
;;  depth 1, outer 0
;;  nodes: 3 5 4
;; 2 succs { 3 }
;; 3 succs { 4 5 }
;; 4 succs { 5 }
;; 5 succs { 3 6 }
;; 6 succs { 7 8 }
;; 7 succs { }
;; 8 succs { 1 }
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called

IF-THEN-JOIN block found, pass 1, test 3, then 4, join 5

IF-CASE-2 found, start 6, else 8


AFAICS, the starting sequence is almost equal (32bit target has more complex
memory access, but it shouldn't matter here), so it should also be converted
through noce_try_addcc on 32bit targets.

[Bug rtl-optimization/80723] [8 Regression] FAIL gcc.target/i386/cadd.c scan assembler sbb

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||i686
 CC||jakub at redhat dot com
   Target Milestone|--- |8.0

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

[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  Isn't it enough to add, after

  else if (reinterpret_cast  (e) + sz
   == reinterpret_cast  (first_free_entry))
{
...

a

  else if (reinterpret_cast  (e)
   < reinterpret_cast  (first_free_entry))
{
  // First is right of us, replace the head.
  free_entry *f = reinterpret_cast  (e);
  new (f) free_entry;
  f->next = first_free_entry;
  first_free_entry = f;
}

?  That's a much less intrusive (and hard to review) fix.

[Bug middle-end/80715] NULL pointer dereferenced in find_costs_and_classes, at ira-costs.c

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
gcc gccerr55.c -O2 -flive-range-shrinkage -E
# 1 "gccerr55.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "gccerr55.c"
# 25 "gccerr55.c"
void f()
{
}


gcc gccerr55.c -O2 -flive-range-shrinkage -v -S
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/vitti/local/gcc-7.1.0
--enable-languages=c,c++,fortran --enable-bootstrap
Thread model: posix
gcc version 7.1.0 (GCC)
COLLECT_GCC_OPTIONS='-O2' '-flive-range-shrinkage' '-v' '-S'
'-mtune=generic' '-march=x86-64'

/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1
-quiet -v -iprefix
/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.1.0/
gccerr55.c -quiet -dumpbase gccerr55.c -mtune=generic -march=x86-64
-auxbase gccerr55 -O2 -version -flive-range-shrinkage -o gccerr55.s
GNU C11 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.1, MPFR version
3.1.5, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/7.1.0/include"
ignoring duplicate directory
"/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/7.1.0/include-fixed"
ignoring nonexistent directory
"/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/tbb/include"
ignoring duplicate directory
"/home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/ipp/include"
ignoring duplicate directory
"/home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/mkl/include"
ignoring duplicate directory
"/home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/pstl/include"
ignoring duplicate directory
"/home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/tbb/include"
ignoring duplicate directory
"/home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/tbb/include"
ignoring duplicate directory
"/home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/daal/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/ipp/include
 /home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/mkl/include
 /home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/pstl/include
 /home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/tbb/include
 /home/vitti/intel18/compilers_and_libraries_2018.0.061/linux/daal/include

/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.1.0/include

/home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/7.1.0/include-fixed
 /usr/local/include
 /home/vitti/1tb/vitti/local/gcc-7.1.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C11 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.1, MPFR version
3.1.5, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d7ed344a9ac7cfb4ff4debc46fef710a
gccerr55.c: In function ‘f’:
gccerr55.c:27:1: internal compiler error: in find_costs_and_classes,
at ira-costs.c:1748
 }
 ^
0x863be3 find_costs_and_classes
../../gcc/gcc/ira-costs.c:1748
0x864959 ira_costs()
../../gcc/gcc/ira-costs.c:2261
0x85e356 ira_build()
../../gcc/gcc/ira-build.c:3420
0x855ccb ira
../../gcc/gcc/ira.c:5302
0x855ccb execute
../../gcc/gcc/ira.c:5613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/80723] [8 Regression] FAIL gcc.target/i386/cadd.c scan assembler sbb

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #2 from Uroš Bizjak  ---
This is a cost issue.

[Bug middle-end/80715] NULL pointer dereferenced in find_costs_and_classes, at ira-costs.c

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Hmm, it works for me just fine.

[Bug c++/67983] ICE: Error reporting routines re-entered.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed between 6.1 and 6.2. It's a duplicate of another bug I resolved recently,
I'll see if I can find it.

[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete

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

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

--- Comment #2 from Markus Eisenmann  ---
Hi!

(In reply to Richard Biener from comment #1)
> Confirmed.  Isn't it enough to add, after
> 
>   else if (reinterpret_cast  (e) + sz
>== reinterpret_cast  (first_free_entry))
> {
> ...
> 
> a
> 
>   else if (reinterpret_cast  (e)
>< reinterpret_cast  (first_free_entry))
> {
>   // First is right of us, replace the head.
>   free_entry *f = reinterpret_cast  (e);
>   new (f) free_entry;
>   f->next = first_free_entry;
>   first_free_entry = f;
> }
> 
> ?  That's a much less intrusive (and hard to review) fix.

Okay, a less intrusive fix for issue a) [set in front, if free-list is empty
or starts with a non merge-able block on a higher address]

Instead of (sorry, not fully formatted as unified diff), my suggestion would:

   allocated_entry *e = reinterpret_cast 
(reinterpret_cast  (data) - offsetof (allocated_entry, data));
   std::size_t sz = e->size;
-  if (!first_free_entry)
+  if (!first_free_entry
+  || (reinterpret_cast  (e) + sz
+  < reinterpret_cast  (first_free_entry)))
{
  // If the free list is empty just put the entry there.
  free_entry *f = reinterpret_cast  (e);
  new (f) free_entry;
  f->size = sz;
- f->next = NULL;
+ f->next = first_free_entry;
  first_free_entry = f;
}
  else if (reinterpret_cast  (e) + sz

I.e., set in front if first_free_entry = null or has to be first, because non
merge-able and a "right" item.
Note: Following Merging with head will be "is-as-is";

About issue b) - additional merging with direct right follower - I have to
think a little about ...

Best regards,
Markus

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
Seems to work for me.

[Bug rtl-optimization/80709] [8 Regression] ICE in setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Configured with: ../configure --disable-bootstrap --target=arm-linux-gnueabihf
Thread model: posix

$ ./cc1plus -fpreprocessed /home/marxin/Programming/testcases/arm.ii -quiet
-dumpbase arm.ii -mtls-dialect=gnu -auxbase arm -O2 -version -fdump-rtl-all -o
arm.s

[Bug rtl-optimization/80709] [8 Regression] ICE in setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed||2017-5-12

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Thanks, I can reproduce it with -O2 -mcpu=arm7tdmi -mfloat-abi=soft -marm

[Bug middle-end/69921] Switch OpenACC kernels number of gangs from "decide at run time" to "decide at compile time"

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri May 12 09:18:34 2017
New Revision: 247957

URL: https://gcc.gnu.org/viewcvs?rev=247957&root=gcc&view=rev
Log:
[PR middle-end/69921] Use "oacc kernels parallelized" attribute for
parallelized OpenACC kernels

gcc/
PR middle-end/69921
* tree-parloops.c (create_parallel_loop): Set "oacc kernels
parallelized" attribute for parallelized OpenACC kernels.
* omp-offload.c (execute_oacc_device_lower): Use it.
gcc/testsuite/
* c-c++-common/goacc/classify-kernels-unparallelized.c: Adjust.
* c-c++-common/goacc/classify-kernels.c: Likewise.
* c-c++-common/goacc/kernels-counter-vars-function-scope.c:
Likewise.
* c-c++-common/goacc/kernels-double-reduction-n.c: Likewise.
* c-c++-common/goacc/kernels-double-reduction.c: Likewise.
* c-c++-common/goacc/kernels-loop-2.c: Likewise.
* c-c++-common/goacc/kernels-loop-3.c: Likewise.
* c-c++-common/goacc/kernels-loop-g.c: Likewise.
* c-c++-common/goacc/kernels-loop-mod-not-zero.c: Likewise.
* c-c++-common/goacc/kernels-loop-n.c: Likewise.
* c-c++-common/goacc/kernels-loop-nest.c: Likewise.
* c-c++-common/goacc/kernels-loop.c: Likewise.
* c-c++-common/goacc/kernels-one-counter-var.c: Likewise.
* c-c++-common/goacc/kernels-reduction.c: Likewise.
* gfortran.dg/goacc/classify-kernels-unparallelized.f95: Likewise.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-enter-exit.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-update.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-n.f95: Likewise.
* gfortran.dg/goacc/kernels-loop.f95: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-offload.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/classify-kernels-unparallelized.c
trunk/gcc/testsuite/c-c++-common/goacc/classify-kernels.c
   
trunk/gcc/testsuite/c-c++-common/goacc/kernels-counter-vars-function-scope.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-double-reduction-n.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-double-reduction.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-loop-2.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-loop-3.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-loop-g.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-loop-mod-not-zero.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-loop-n.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-loop-nest.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-loop.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-one-counter-var.c
trunk/gcc/testsuite/c-c++-common/goacc/kernels-reduction.c
trunk/gcc/testsuite/gfortran.dg/goacc/classify-kernels-unparallelized.f95
trunk/gcc/testsuite/gfortran.dg/goacc/classify-kernels.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop-2.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-2.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-update.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop-data.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop-n.f95
trunk/gcc/testsuite/gfortran.dg/goacc/kernels-loop.f95
trunk/gcc/tree-parloops.c

[Bug middle-end/69921] Switch OpenACC kernels number of gangs from "decide at run time" to "decide at compile time"

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri May 12 09:20:35 2017
New Revision: 247958

URL: https://gcc.gnu.org/viewcvs?rev=247958&root=gcc&view=rev
Log:
[PR middle-end/69921] Use "oacc kernels parallelized" attribute for
parallelized OpenACC kernels

gcc/
PR middle-end/69921
* tree-parloops.c (create_parallel_loop): Set "oacc kernels
parallelized" attribute for parallelized OpenACC kernels.
* omp-low.c (execute_oacc_device_lower): Use it.
* config/nvptx/nvptx.c (nvptx_goacc_validate_dims): Likewise.
* omp-low.c (set_oacc_fn_attrib): Make it "static".
* omp-low.h (set_oacc_fn_attrib): Remove prototype.
gcc/testsuite/
* c-c++-common/goacc/classify-kernels-unparallelized.c: Adjust.
* c-c++-common/goacc/classify-kernels.c: Likewise.
* c-c++-common/goacc/kernels-acc-loop-reduction.c: Likewise.
* c-c++-common/goacc/kernels-acc-loop-smaller-equal.c: Likewise.
* c-c++-common/goacc/kernels-counter-vars-function-scope.c:
Likewise.
* c-c++-common/goacc/kernels-double-reduction-n.c: Likewise.
* c-c++-common/goacc/kernels-double-reduction.c: Likewise.
* c-c++-common/goacc/kernels-loop-2-acc-loop.c: Likewise.
* c-c++-common/goacc/kernels-loop-2.c: Likewise.
* c-c++-common/goacc/kernels-loop-3-acc-loop.c: Likewise.
* c-c++-common/goacc/kernels-loop-3.c: Likewise.
* c-c++-common/goacc/kernels-loop-acc-loop.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-2.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-enter-exit-2.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-enter-exit.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-update.c: Likewise.
* c-c++-common/goacc/kernels-loop-data.c: Likewise.
* c-c++-common/goacc/kernels-loop-g.c: Likewise.
* c-c++-common/goacc/kernels-loop-mod-not-zero.c: Likewise.
* c-c++-common/goacc/kernels-loop-n-acc-loop.c: Likewise.
* c-c++-common/goacc/kernels-loop-n.c: Likewise.
* c-c++-common/goacc/kernels-loop-nest.c: Likewise.
* c-c++-common/goacc/kernels-loop.c: Likewise.
* c-c++-common/goacc/kernels-one-counter-var.c: Likewise.
* c-c++-common/goacc/kernels-parallel-loop-data-enter-exit.c:
Likewise.
* c-c++-common/goacc/kernels-reduction.c: Likewise.
* gfortran.dg/goacc/classify-kernels-unparallelized.f95: Likewise.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-enter-exit.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-update.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-n.f95: Likewise.
* gfortran.dg/goacc/kernels-loop.f95: Likewise.
* gfortran.dg/goacc/kernels-parallel-loop-data-enter-exit.f95:
Likewise.

trunk r247957

Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/config/nvptx/nvptx.c
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/omp-low.h
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/classify-kernels-unparallelized.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/classify-kernels.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-acc-loop-reduction.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-acc-loop-smaller-equal.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-counter-vars-function-scope.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-double-reduction-n.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-double-reduction.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-2-acc-loop.c
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-2.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-3-acc-loop.c
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-3.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-acc-loop.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-data-2.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-data-enter-exit-2.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-data-enter-exit.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-data-update.c
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-data.

[Bug middle-end/69921] Switch OpenACC kernels number of gangs from "decide at run time" to "decide at compile time"

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Schwinge  ---
.

[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete

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

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

--- Comment #3 from Markus Eisenmann  ---
Hi Richard!

And now a less-intrusive (suggested) patch to do also a "right" merge
[Sorry, also udiff-like but not fully formatted/with line-info; to see "my"
idea]


  free_entry **fe;
  for (fe = &first_free_entry;
   (*fe)->next
   && (reinterpret_cast  ((*fe)->next)
   > reinterpret_cast  (e) + sz);
   fe = &(*fe)->next)
;
+ // If the next/right block follows immediately to the end of the
block
+ // to free, add its size to current 'free' and unlink it from the
list.
+ if (reinterpret_cast  (e) + sz
+ == reinterpret_cast  ((*fe)->next))
+ {
+   sz += ((*fe)->next)->size;
+   (*fe)->next = ((*fe)->next)->next;
+ }
  if (reinterpret_cast  (*fe) + (*fe)->size
  == reinterpret_cast  (e))
/* Merge with the freelist entry.  */
(*fe)->size += sz;


Best regards from Salzburg,
Markus

P.S.: Should I add a (well-formatted) patch-file, containing these two
proposals?

[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Mine.

[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Fri, 12 May 2017, meisenmann@fh-salzburg.ac.at wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80721
> 
> --- Comment #3 from Markus Eisenmann  ---
> Hi Richard!
> 
> And now a less-intrusive (suggested) patch to do also a "right" merge
> [Sorry, also udiff-like but not fully formatted/with line-info; to see "my"
> idea]
> 
> 
>   free_entry **fe;
>   for (fe = &first_free_entry;
>(*fe)->next
>&& (reinterpret_cast  ((*fe)->next)
>> reinterpret_cast  (e) + sz);
>fe = &(*fe)->next)
> ;
> + // If the next/right block follows immediately to the end of the
> block
> + // to free, add its size to current 'free' and unlink it from the
> list.
> + if (reinterpret_cast  (e) + sz
> + == reinterpret_cast  ((*fe)->next))
> + {
> +   sz += ((*fe)->next)->size;
> +   (*fe)->next = ((*fe)->next)->next;
> + }
>   if (reinterpret_cast  (*fe) + (*fe)->size
>   == reinterpret_cast  (e))
> /* Merge with the freelist entry.  */
> (*fe)->size += sz;
> 
> 
> Best regards from Salzburg,
> Markus
> 
> P.S.: Should I add a (well-formatted) patch-file, containing these two
> proposals?

I'll deal with it and testing / posting the patch.  Thanks!

[Bug testsuite/77684] many tree-prof testsuite failures in parallel make check

[ak at gcc dot gnu.org]

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

--- Comment #6 from ak at gcc dot gnu.org ---
Author: ak
Date: Fri May 12 10:09:50 2017
New Revision: 247962

URL: https://gcc.gnu.org/viewcvs?rev=247962&root=gcc&view=rev
Log:
Limit perf data buffer during profiling

With high -j parallelism the autofdo tests can randomly fail.
autofdo uses Linux perf to record profiling data.
Linux perf uses a locked perf buffer. By default it has
around 516k buffer per uid (/proc/sys/kernel/perf_event_mlock_kb).

An individual perf record tries to grab the full 516k,
which makes parallel perf record fail.

This patch limits the perf buffer for individual perf record to 8k.
With the default settings this allows a parallelism of the test
cases of 16, which is hopefully good enough

(if not would need to add some kind of semaphore, or ask
the user to increase the limit as root)

I also removed an unneeded -o perf.data option

Thanks to Marcin to finally spotting the problem.

Passes bootstrap and test on x86_64-linux. Ok for trunk?

gcc/testsuite/:

2017-05-12  Andi Kleen  

PR testsuite/77684
* lib/target-supports.exp (profopt-perf-wrapper):
Add -m8 option to increase parallelism.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug middle-end/80710] Stack smashing detected in correct code depending on optimization flag

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Andrew Pinski  ---
Why not look into something like libffi?

[Bug c++/67687] ICE initializing constexpr member with constexpr constructor

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
This is fixed in 7.1.0, I'm adding a testcase and closing the bug.

[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #25 from Richard Biener  ---
This has been fixed with moving almost all mathfn foldings from builtins.c to
match.pd.

[Bug tree-optimization/80724] New: gcc.target/aarch64/pr62178.c failed because of r247885

[amker at gcc dot gnu.org]

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

Bug ID: 80724
   Summary: gcc.target/aarch64/pr62178.c failed because of r247885
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

After r247885, test gcc.target/aarch64/pr62178.c failed as below:
gcc.target/aarch64/pr62178.c scan-assembler ld1r\\t{v[0-9]+.

Firstly, innermost loop after ivopt is:

   [26.32%]:
  # vectp_b.12_66 = PHI 
  # vect__5.16_70 = PHI 
  # ivtmp.56_96 = PHI 
  _102 = (void *) ivtmp.56_96;
  _2 = MEM[base: _102, offset: 4B];
  vect_cst__62 = {_2, _2, _2, _2};
  vect__3.14_68 = MEM[base: vectp_b.12_66, offset: 0B];
  vect__4.15_69 = vect_cst__62 * vect__3.14_68;
  vect__5.16_71 = vect__4.15_69 + vect__5.16_70;
  vectp_b.12_67 = vectp_b.12_66 + 124;
  ivtmp.56_97 = ivtmp.56_96 + 4;
  _112 = (vector(4) int *) ivtmp.68_106;
  if (vectp_b.12_67 != _112)
goto ; [96.66%]
  else
goto ; [3.34%]

   [25.44%]:
  goto ; [100.00%]


Note candidate ivtmp.56_96 is shifted by 4, thus MEM[base: _102, offset: 4B] is
generated rather than:
  _2 = MEM[base: _102, offset: 0B];
Which combined with vect_cst__62 = {_2, _2, _2, _2}; ld1r can be used.
IVOPTs has no knowledge that MEM[base + 4] has different outcome to MEM[base]
in this case.

For this iv_use:
Group 0:
  Type: ADDRESS
  Use 0.0:
At stmt:_2 = a[i_27][k_29];
At pos: a[i_27][k_29]
IV struct:
  Type: int *
  Base: (int *) (&a + ((sizetype) i_27 * 124 + 4))
  Step: 4
  Object:   (void *) &a
  Biv:  N
  Overflowness wrto loop niter: Overflow
There are two candidates:
Candidate 13:
  Var befor: ivtmp.55
  Var after: ivtmp.55
  Incr POS: before exit test
  IV struct:
Type:   unsigned long
Base:   (unsigned long) (&a + ((sizetype) i_27 * 124 + 4))
Step:   4
Object: (void *) &a
Biv:N
Overflowness wrto loop niter:   Overflow
Applying pattern match.pd:1902, generic-match.c:9693
Candidate 14:
  Var befor: ivtmp.56
  Var after: ivtmp.56
  Incr POS: before exit test
  IV struct:
Type:   unsigned long
Base:   (unsigned long) (&a + (sizetype) i_27 * 124)
Step:   4
Object: (void *) &a
Biv:N
Overflowness wrto loop niter:   Overflow

The cost is as below:
:
  cand  cost
  0 5
  1 5
  2 5
  3 5
  4 4
  5 5
  6 5
  7 5
  8 5
  9 5
  105
  115
  125
  136
  145
:
Group 0:
  cand  costcompl.  inv.expr.   inv.vars
  1 2   2   1;  NIL;
  2 2   2   2;  NIL;
  3 1   2   3;  NIL;
  130   0   NIL;NIL;
  140   1   NIL;NIL;

Note we choose cand_14 only because cost of cand_13 itself is higher than
cand_14.
This is because the loop iterates 30 times, and we have:
cand_13
  base: (unsigned long) (&a + ((sizetype) i_27 * 124 + 4))
  cost: 33 (before amortize against loop niter) / 30 = 1
cand_14
  base: (unsigned long) (&a + (sizetype) i_27 * 124)
  cost: 29 (before amortize against loop niter) / 30 = 0

Note, we are on the verge of loop niters.

With this ivopts issue, the inner most loop should have only one more
instruction.  Unfortunately before RTL combine, we have:
   74: r74:SI=[++r99:DI]
  REG_INC r99:DI
   75: r123:V4SI=[post r90:DI+=0x7c]
  REG_INC r90:DI
   77: r124:V4SI=vec_duplicate(r74:SI)
  REG_DEAD r74:SI
   78: r126:V4SI=r123:V4SI*r124:V4SI
  REG_DEAD r124:V4SI
  REG_DEAD r123:V4SI
   79: r93:V4SI=r93:V4SI+r126:V4SI
  REG_DEAD r126:V4SI
Combine pass tries to combine 77/78, rather than 78/79, like:
   74: r74:SI=[++r99:DI]
  REG_INC r99:DI
   75: r123:V4SI=[post r90:DI+=0x7c]
  REG_INC r90:DI
   77: NOTE_INSN_DELETED
   78: r126:V4SI=vec_duplicate(r74:SI)*r123:V4SI
  REG_DEAD r74:SI
  REG_DEAD r123:V4SI
   79: r93:V4SI=r93:V4SI+r126:V4SI
  REG_DEAD r126:V4SI

So it misses mul+add combination, but combined an pattern which has generate
two instructions:
fmovs3, w0  // 157  *movsi_aarch64/12   [length = 4]
mul v0.4s, v0.4s, v3.s[0]   // 78   *aarch64_mul3_elt_from_dupv4si 
[length = 4]

[Bug tree-optimization/80724] gcc.target/aarch64/pr62178.c failed because of r247885

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
Also, the test case is fragile because we check instructions for a gimple level
transformation.  Note, though the case is regressed, the original bug in
PR62178 remains fixed.

[Bug tree-optimization/23094] store ccp, or store copy prop misses an optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Attachment #9375|0   |1
is obsolete||

--- Comment #16 from Richard Biener  ---
Created attachment 41347
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41347&action=edit
patch I'm sitting on

So this is the patch I am sitting on for a while.  It's reasonably a cheap
trick but is at the same time easily fooled by an intermediate (non-aliasing)
store
like in

float *f;
int g(int *a, int *b)
{
  int x = *b;
  *f = 1.;
  *a = x;
  return *b;
}

which is why I haven't pushed it sofar.  OTOH it might be good enough for
the most cases.

To make it more general one would need to store the seen value somewhere
and verify we can use it.  A bit hackish I'd say (well, a new global var
would do, not that we don't already have this kind).

[Bug c++/67687] ICE initializing constexpr member with constexpr constructor

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
In fact it's fixed for 6.4.0 too.

[Bug c/27214] The C frontend introduces undefined pointer overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #13 from Richard Biener  ---
The desired cleanup is to make POINTER_PLUS_EXPR take a signed offset argument,
aka ssizetype instead of sizetype.

Bin was working on this at some point, so was I ...  Bin, can you paste the
result (aka fallout) of your experiment(s)?

[Bug tree-optimization/80713] [8 Regression] recent crash in update_dep_bb

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri May 12 10:54:29 2017
New Revision: 247963

URL: https://gcc.gnu.org/viewcvs?rev=247963&root=gcc&view=rev
Log:
2017-05-12  Richard Biener  

PR tree-optimization/80713
* tree-ssa-pre.c (remove_dead_inserted_code): Clear
inserted_exprs bit for not removed stmts.

* gcc.dg/torture/pr80713.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80713.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug c++/67687] ICE initializing constexpr member with constexpr constructor

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri May 12 11:24:56 2017
New Revision: 247964

URL: https://gcc.gnu.org/viewcvs?rev=247964&root=gcc&view=rev
Log:
2017-05-12  Paolo Carlini  

PR c++/67687
* g++.dg/cpp0x/constexpr-ice17.C: New.

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

[Bug c++/67687] ICE initializing constexpr member with constexpr constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c++/55004] [meta-bug] constexpr issues

[paolo.carlini at oracle dot com]

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

Bug 67687 Summary: ICE initializing constexpr member with constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67687

   What|Removed |Added

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

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
This is fixed in 7.1.0. I'm adding testcases and closing the bug.

[Bug tree-optimization/80713] [8 Regression] recent crash in update_dep_bb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Should be fixed.

[Bug target/80725] New: s390x ICE on alsa-lib

[jakub at gcc dot gnu.org]

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

Bug ID: 80725
   Summary: s390x ICE on alsa-lib
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase reduced from alsa-lib ICEs on s390x with -O2
-march=zEC12:
int a, e;
const char b;
char c;
const int d;
void bar (short);

void
foo (int x, int y)
{
  long f = d;
  short g = 0;
  while (e)
while (a < x)
  {
if (y)
  goto *d;
g = b | b + g;
bar (g);
c = (char) (long) foo;
  }
}

The problem is in indirect jump, which is fine before LRA:
(jump_insn 13 12 14 3 (set (pc)
(reg/v:DI 66 [ f ])) "rh1450353.c":16 1922 {*indirect_jump}
 (expr_list:REG_DEAD (reg/v:DI 66 [ f ])
(nil)))
but starting with *.reload it is:
(jump_insn 13 12 14 3 (set (pc)
(reg/v:DI 24 %f8 [orig:66 f ] [66])) "rh1450353.c":16 1922
{*indirect_jump}
 (nil))
which for some strange reason happily satisfies the ZR constraint, as neither
s390_decompose_address, nor s390_check_qrst_address nor s390_mem_constraint
performs any verification of the hard registers in there (it is fine if it
accepts pseudos, but for hard registers it would be nice if it checked
what s390_legitimate_address_p checks.

[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 41348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41348&action=edit
Patch candidate

Sending untested patch. Can you please attach original pre-processed source
file from emacs. I would like to see how the problematic expression looks in
original.

[Bug middle-end/80710] Stack smashing detected in correct code depending on optimization flag

[dr.markus.hoffmann at gmx dot de]

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

--- Comment #5 from dr.markus.hoffmann at gmx dot de  ---
Hm, wow, thank you. I did not know it. Maybe rather depend on one more library
than have undefined and probably non-portable code

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Ian Lance Taylor from comment #12)
> Thanks, should be fixed now.

I can confirm that it fixed the problem.

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri May 12 13:20:21 2017
New Revision: 247969

URL: https://gcc.gnu.org/viewcvs?rev=247969&root=gcc&view=rev
Log:
2017-05-12  Paolo Carlini  

PR c++/49604
* g++.dg/cpp0x/forw_enum14.C: New.
* g++.dg/cpp0x/forw_enum15.C: Likewise.

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

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
Still broken over a week later and I notice this bug report is
not assigned to anyone.

I notice that hubicka has done seven of the last ten changes
in the ipa-inline-analysis.c. 

Maybe they are the best person to comment further ?

[Bug target/80725] [7/8 Regression] s390x ICE on alsa-lib

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-12
   Target Milestone|--- |7.2
Summary|s390x ICE on alsa-lib   |[7/8 Regression] s390x ICE
   ||on alsa-lib
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r246456.  Perhaps the problem is that there are now 2 identical
patterns with different predicates, where that %f8 satisfies
nonimmediate_operand, but not address_operand and the constraint checking
doesn't verify what the predicate checks.

[Bug target/80725] [7/8 Regression] s390x ICE on alsa-lib

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Tried
--- s390.c.jj1  2017-04-25 15:54:34.0 +0200
+++ s390.c  2017-05-12 15:33:15.816668225 +0200
@@ -3210,6 +3210,8 @@ s390_mem_constraint (const char *str, rt
return 0;
   break;
 case 'Z':
+  if (str[1] == 'R' && !address_operand (op, VOIDmode))
+   return 0;
   return s390_check_qrst_address (str[1], op, true);
 default:
   return 0;
as a hack, but that ICEs elsewhere:
rh1450353.c:21:1: error: insn does not satisfy its constraints:
 }
 ^
(jump_insn 13 12 14 3 (set (pc)
(reg/v:DI 24 %f8 [orig:66 f ] [66])) "rh1450353.c":16 1922
{*indirect_jump}
 (nil))

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Author: redi
Date: Fri May 12 14:43:11 2017
New Revision: 247973

URL: https://gcc.gnu.org/viewcvs?rev=247973&root=gcc&view=rev
Log:
PR libstdc++/78939 make tuple_size depend on tuple_size

PR libstdc++/78939
* include/std/utility (tuple_size): Only define partial
specializations when tuple_size::value is valid.
* testsuite/20_util/tuple/78939.cc: New.
* testsuite/20_util/tuple/cv_tuple_size_neg.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/78939.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/cv_tuple_size_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/utility

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 41349
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41349&action=edit
Patch candidate

Yep, it's Honza Hubicka's PR. I'm suggesting a new function that will handle
round off errors in sreal.

Can you please Honza take a look? Can you Dmitry test it?

[Bug tree-optimization/80726] New: Destructor not inlined anymore (regression)

[cuzdav at gmail dot com]

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

Bug ID: 80726
   Summary: Destructor not inlined anymore (regression)
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Inlining regression with noexcept(true) destructor that could possible throw,
but doesn't.

This code demonstrates that in main(), the destructor for Foo is no longer
inlined using g++ 7.1 -O3 (also with the 8.0 snapshot).  On the 6.x series it
is inlined.

Source:

// ---
bool shouldThrow = false;

struct Foo {
~Foo() {
   if (shouldThrow) throw "hmm";
}
};

int main() {
Foo f;
}// ---


As evidenced on godbolt.org, for g++7.1,  main() has function call for
destructor

.LC0:
.string "hmm"
Foo::~Foo():
movzx   eax, BYTE PTR shouldThrow[rip]
testal, al
jne .L7
rep ret
.L7:
mov edi, 8
sub rsp, 8
call__cxa_allocate_exception
xor edx, edx
mov QWORD PTR [rax], OFFSET FLAT:.LC0
mov esi, OFFSET FLAT:typeinfo for char const*
mov rdi, rax
call__cxa_throw
main:
sub rsp, 24
lea rdi, [rsp+15]
callFoo::~Foo()
xor eax, eax
add rsp, 24
ret
shouldThrow:
.zero   1


But with 6.3 the destructor is inlined:

.LC0:
.string "hmm"
main:
movzx   eax, BYTE PTR shouldThrow[rip]
testal, al
jne .L7
xor eax, eax
ret
.L7:
mov edi, 8
sub rsp, 8
call__cxa_allocate_exception
xor edx, edx
mov QWORD PTR [rax], OFFSET FLAT:.LC0
mov esi, OFFSET FLAT:typeinfo for char const*
mov rdi, rax
call__cxa_throw
shouldThrow:
.zero   1

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #16 from Jonathan Wakely  ---
Fixed for 7.2

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Author: redi
Date: Fri May 12 15:53:19 2017
New Revision: 247978

URL: https://gcc.gnu.org/viewcvs?rev=247978&root=gcc&view=rev
Log:
PR libstdc++/78939 make tuple_size depend on tuple_size

PR libstdc++/78939
* include/std/utility (tuple_size) [__cplusplus > 201402L]:
Only define partial specializations when tuple_size::value is
valid.
* testsuite/20_util/tuple/78939.cc: New.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/tuple/78939.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/std/utility

[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32

[ebotcazou at gcc dot gnu.org]

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

--- Comment #19 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri May 12 15:55:46 2017
New Revision: 247979

URL: https://gcc.gnu.org/viewcvs?rev=247979&root=gcc&view=rev
Log:
* system-linux-arm.ads (Memory_Size): Use Long_Integer'Size
instead of Word_Size.

Revert
2017-03-28  Andreas Schwab  

PR ada/80117
* system-linux-aarch64-ilp32.ads: New file.
* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Rename
from LIBGNAT_TARGET_PAIRS.
(LIBGNAT_TARGET_PAIRS_32, LIBGNAT_TARGET_PAIRS_64): Define.
(LIBGNAT_TARGET_PAIRS): Use LIBGNAT_TARGET_PAIRS_COMMON, and
LIBGNAT_TARGET_PAIRS_64 or LIBGNAT_TARGET_PAIRS_32 for -mabi=lp64
or -mabi=ilp32, resp.

Removed:
trunk/gcc/ada/system-linux-aarch64-ilp32.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in
trunk/gcc/ada/system-linux-arm.ads

[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32

[ebotcazou at gcc dot gnu.org]

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

--- Comment #20 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri May 12 15:58:34 2017
New Revision: 247980

URL: https://gcc.gnu.org/viewcvs?rev=247980&root=gcc&view=rev
Log:
* system-linux-arm.ads (Memory_Size): Use Long_Integer'Size
instead of Word_Size.

Revert
2017-03-28  Andreas Schwab  

PR ada/80117
* system-linux-aarch64-ilp32.ads: New file.
* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Rename
from LIBGNAT_TARGET_PAIRS.
(LIBGNAT_TARGET_PAIRS_32, LIBGNAT_TARGET_PAIRS_64): Define.
(LIBGNAT_TARGET_PAIRS): Use LIBGNAT_TARGET_PAIRS_COMMON, and
LIBGNAT_TARGET_PAIRS_64 or LIBGNAT_TARGET_PAIRS_32 for -mabi=lp64
or -mabi=ilp32, resp.

Removed:
branches/gcc-7-branch/gcc/ada/system-linux-aarch64-ilp32.ads
Modified:
branches/gcc-7-branch/gcc/ada/ChangeLog
branches/gcc-7-branch/gcc/ada/gcc-interface/Makefile.in
branches/gcc-7-branch/gcc/ada/system-linux-arm.ads

[Bug rtl-optimization/80715] NULL pointer dereferenced in find_costs_and_classes, at ira-costs.c

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
I see the ICE on trunk 247930.

To reproduce it you need ira_assert working,
definining  ENABLE_IRA_CHECKING implied by CHECKING_P,
best way to make it happen is configuring gcc with --enable-checking=yes
option.
Have the following lines:

ira_assert(cost_classes_ptr);/*!vz my addition pr60268.c -O2
-flive-range-shrinkage*/
enum reg_class *cost_classes = cost_classes_ptr->classes;

and compile with both options  -O2 -flive-range-shrinkage

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
It works.  Thanks.

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #6 from Pat Haugen  ---
(In reply to Martin Liška from comment #5)
> Created attachment 41349 [details]
> Patch candidate
> 
> Yep, it's Honza Hubicka's PR. I'm suggesting a new function that will handle
> round off errors in sreal.
> 
> Can you please Honza take a look? Can you Dmitry test it?

I just ran into the same ICE and the proposed patch fixes the problem.

[Bug libfortran/80727] New: Crash of runtime gfortran library during integer transformation

[user1 at lpetrov dot net]

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

Bug ID: 80727
   Summary: Crash of runtime gfortran library during integer
transformation
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: user1 at lpetrov dot net
  Target Milestone: ---

Dear gcc developers,

  Thank for maintaining the gcc collection. Recently I compiled from sources
gcc 7.1.0 and I found a bug in gfortran IO library. That example works 
correctly under gcc 5.1.0 and 6.1.0

  See below:

1) source file gfortran_710_io_bug.f
2) gfortran_710_io_bug.comp -- result of command line
   gfortran -v -save-temps -fno-underscoring -ffree-form -o
gfortran_710_io_bug.e gfortran_710_io_bug.f
3) gfortran_710_io_bug.out  -- result of running affected program:
./gfortran_710_io_bug.e 

/tmp> uname -a
Linux astrogeo 4.10.0 #2 SMP Thu Feb 23 09:59:20 EST 2017 x86_64 x86_64 x86_64
GNU/Linux

Sincerely,
Leonid Petrov
2017.05.12_11:48:39

1) Source code code that triggers the bug:

  PROGRAMGFORTRAN_710_IO_BUG
  CHARACTER  STR*4
  INTEGER*4  I4
  LOGICAL*1  FL_SHOW_BUG
!
  FL_SHOW_BUG = .TRUE.
  STR = CHAR(0)//CHAR(1)//CHAR(0)//CHAR(0)
  IF ( FL_SHOW_BUG ) THEN
!
!  The place where gfortran 7.1.0 crashes
!
   READ ( UNIT=STR(1:4), FMT='(A4)' ) I4
ELSE
!
!  Workaround
!
   CALL MEMCPY ( I4, %REF(STR), %VAL(4) )
  END IF
  WRITE ( 6, * ) ' I4= ', I4
  END  PROGRAM  GFORTRAN_710_IO_BUG 

2) Output of the command line gfortran -v -save-temps -fno-underscoring
-ffree-form -o gfortran_710_io_bug.e gfortran_710_io_bug.f

Driving: gfortran -v -save-temps -fno-underscoring -ffree-form -o
gfortran_710_io_bug.e gfortran_710_io_bug.f -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --enable-lto --without-isl
--enable-languages=c,c++,fortran,objc,obj-c++
Thread model: posix
gcc version 7.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fno-underscoring' '-ffree-form' '-o'
'gfortran_710_io_bug.e' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/f951 gfortran_710_io_bug.f -quiet
-dumpbase gfortran_710_io_bug.f -mtune=generic -march=x86-64 -auxbase
gfortran_710_io_bug -version -fno-underscoring -ffree-form
-fintrinsic-modules-path /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/finclude -o
gfortran_710_io_bug.s
GNU Fortran (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fno-underscoring' '-ffree-form' '-o'
'gfortran_710_io_bug.e' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o gfortran_710_io_bug.o gfortran_710_io_bug.s
GNU assembler version 2.24 (x86_64-redhat-linux) using BFD version version 2.24
Reading specs from
/usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fno-underscoring' '-ffree-form' '-o'
'gfortran_710_io_bug.e' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fno-underscoring' '-ffree-form' '-o'
'gfortran_710_io_bug.e' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/collect2 -plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
-plugin-opt=-fresolution=gfortran_710_io_bug.res
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lquadmath -plugin-opt=-pass-through=-lm
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc --eh-frame-hdr -

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-05/msg01043.ht
   ||ml

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

[Bug c++/59729] [DR1732] C++11 allows type definitions in conditions and for-range-declarations, but shouldn't

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
In 7.1.0 a proper error is emitted for the code in Comment 1. To be safe I'm
adding the testcase and closing the bug.

[Bug c++/59729] [DR1732] C++11 allows type definitions in conditions and for-range-declarations, but shouldn't

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |6.2

--- Comment #5 from Paolo Carlini  ---
Actually, we already got a proper testcase, added for c++/71604.

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Author: bergner
Date: Fri May 12 17:13:07 2017
New Revision: 247984

URL: https://gcc.gnu.org/viewcvs?rev=247984&root=gcc&view=rev
Log:
gcc/
PR middle-end/80707
* tree-cfg.c: Remove cfg edges of unreachable case statements.

gcc/testsuite/
PR middle-end/80707
* g++.dg/pr80707.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr80707.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug c++/60430] static_assert and reference to const/constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
This is fixed in 7.1.0. I'm adding the testcase and closing the bug.

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #9 from Peter Bergner  ---
Fixed.

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Peter Bergner  ---
Closing as fixed.

[Bug libfortran/80727] [7/8 Regression] Crash of runtime gfortran library during integer transformation

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||5.4.0, 6.3.0
   Keywords||wrong-code
   Last reconfirmed||2017-05-12
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Crash of runtime gfortran   |[7/8 Regression] Crash of
   |library during integer  |runtime gfortran library
   |transformation  |during integer
   ||transformation
   Target Milestone|--- |7.2
  Known to fail||7.1.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Simplified test (the infamous IO of numerical values with the '(A)' format)

  PROGRAMGFORTRAN_710_IO_BUG
  CHARACTER  STR*4
  INTEGER*4  I4
  str =''
  i = 256
  write(str,fmt='(A)') I
  print *, ichar(str(1:1)), ichar(str(2:2)), ichar(str(3:3)),
ichar(str(4:4))
  READ ( UNIT=STR(1:4), FMT='(A)' ) I4
  WRITE ( 6, * ) ' I4= ', I4
  END  PROGRAM  GFORTRAN_710_IO_BUG 

Likely caused by r246478 (pr78881).

[Bug c++/60430] static_assert and reference to const/constexpr

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri May 12 17:53:54 2017
New Revision: 247986

URL: https://gcc.gnu.org/viewcvs?rev=247986&root=gcc&view=rev
Log:
2017-05-12  Paolo Carlini  

PR c++/60430
* g++.dg/cpp0x/pr60430.C: New.

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

[Bug c++/55004] [meta-bug] constexpr issues

[paolo.carlini at oracle dot com]

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

Bug 60430 Summary: static_assert and reference to const/constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60430

   What|Removed |Added

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

[Bug c++/60430] static_assert and reference to const/constexpr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug target/80382] ICE with error: unrecognizable insn

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to fail||5.3.1, 6.1.0

--- Comment #12 from Peter Bergner  ---
With a GCC 6 and GCC 5 builds I had laying around, the reduce test case ICEs
with those versions.  I assume it ICEs on GCC 7 as well. Therefore, we should
back port this fix to the release branches as well.

[Bug target/80723] [8 Regression] FAIL gcc.target/i386/cadd.c scan assembler sbb

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri May 12 18:52:51 2017
New Revision: 247991

URL: https://gcc.gnu.org/viewcvs?rev=247991&root=gcc&view=rev
Log:
PR target/80723
* config/i386/i386.c (ix86_rtx_cost) [case PLUS]: Ignore the
cost of adding a carry flag for ADC instruction.
[case MINUS]: Ignore the cost of subtracting a carry flag
for SBB instruction.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug target/80723] [8 Regression] FAIL gcc.target/i386/cadd.c scan assembler sbb

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug ipa/80728] New: IPA-reference suppresses compiler memory barrier

[amonakov at gcc dot gnu.org]

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

Bug ID: 80728
   Summary: IPA-reference suppresses compiler memory barrier
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

Consider:

static int i;
static int b;

void sighandler(void)
{
  b = i = 1;
}

__attribute__((noinline))
static int x(void)
{
  asm volatile("":::"memory");
  return b;
}

int f(void)
{
  i = 0;
  return x() ? i : 0;
}


This is compiled as expected with either -Dnoinline= , or with
-fno-ipa-reference, but otherwise IPA-reference suppresses the effect of
compiler memory barrier in 'x', causing 'f' to be optimized to 'return 0'.

A similar issue exists for atomic accesses (i.e. if x contained one rather than
the volatile asm).

[Bug testsuite/80643] NA->FAIL: gcc.dg/pr79214.c gcc.dg/pr79222.c gcc.dg/pr79223.c gcc.dg/tree-ssa/builtins-folding-gimple-ub.c

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Fri May 12 19:23:00 2017
New Revision: 247993

URL: https://gcc.gnu.org/viewcvs?rev=247993&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

PR testsuite/80643
* gfortran.dg/mvbits_7.f90: Prune diagnostic output incidental
to the purpose of the test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90

[Bug target/80718] GCC generates slow code for offsettable vec_duplicate

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Fri May 12 19:48:54 2017
New Revision: 247994

URL: https://gcc.gnu.org/viewcvs?rev=247994&root=gcc&view=rev
Log:
Rework pr 80718

Modified:
branches/ibm/meissner-work/gcc/ChangeLog.meissner
branches/ibm/meissner-work/gcc/config/rs6000/vsx.md

[Bug target/80718] GCC generates slow code for offsettable vec_duplicate

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Fri May 12 19:54:03 2017
New Revision: 247995

URL: https://gcc.gnu.org/viewcvs?rev=247995&root=gcc&view=rev
Log:
Rework pr 80718

Modified:
branches/ibm/meissner-work/gcc/config/rs6000/vsx.md

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  ---
(In reply to Pat Haugen from comment #6)
> 
> I just ran into the same ICE and the proposed patch fixes the problem.

Unfortunately the patch introduces the same ICE on another benchmark that used
to build just fine.

[Bug fortran/80645] [8 regression] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
I have reproduced the warning in comment #0 with a powerpc64le-linux and
sparcv9-sun-solaris2.11 (but on x86_64-linux).  Based on the dumps the warning
seems justified.  Here's what I see in elemental_subroutine_3.f90.004t.gimple
for the second call to memcpy (the one that triggers the warning):

test ()
  ...
  static struct mytype x[6] = {{.x=1}, {.x=20}, {.x=300}, {.x=4000},
{.x=5}, {.x=100}};
  ...
parm.11.data = &x[3];
  ...
_15 = parm.11.data;
  __builtin_memcpy (data.13, _15, 16);

I.e., memcpy is being called to copy 16 bytes from the six-element array x,
starting at element 4.  With each element being 4 bytes wide, the last three
elements of x are only 12 bytes in size.  This doesn't significantly change in
any of the subsequent dumps and the warning seems to be faithfully reporting
the same numbers: a read of 16 bytes from a region of size 12.

The reason the warning doesn't show up on x86_64 is because there GCC doesn't
emit memcpy to copy the elements.  Instead it uses a MEM_REF.

[Bug c++/80729] New: [GCC 6, 7] -Wuseless-cast doesn't detect casting string literals to (const char*)

[eugene.zelenko at gmail dot com]

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

Bug ID: 80729
   Summary: [GCC 6, 7] -Wuseless-cast doesn't detect casting
string literals to (const char*)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com
  Target Milestone: ---

-Wuseless-cast doesn't detect casting string literals to (const char*), like

(const char*) "string"

I tried GCC 6.3 and 7.1 on C++98/03 code base.

[Bug c/80730] New: bogus initializer element is not computable at load time converting a string to bool

[msebor at gcc dot gnu.org]

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

Bug ID: 80730
   Summary: bogus initializer element is not computable at load
time converting a string to bool
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC rejects the following initialization of a bool variable with a string
literal but accepts (albeit with a warning) an initialization of a bool
variable with an array.  It seems that it should accept both since they're both
address constants.

$ cat t.c && gcc -O2 -S -Wall t.c
extern char a[];

const char *s1 = "";
const char *s2 = a;

_Bool b1 = "";
_Bool b2 = a;
t.c:6:12: error: initializer element is not computable at load time
 _Bool b1 = "";
^~
t.c:7:1: warning: the address of ‘a’ will always evaluate as ‘true’ [-Waddress]
 _Bool b2 = a;
 ^

[Bug c/80731] New: poor -Woverflow warnings, missing detail

[msebor at gcc dot gnu.org]

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

Bug ID: 80731
   Summary: poor -Woverflow warnings, missing detail
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

For the program below GCC emits three -Woverflow warnings, each slightly
differently worded, and each lacking in interesting or relevant detail.  The
second warning is also inaccurate (the integer is truncated, but because it's
unsigned to begin with, it's unclear to what unsigned type it is converted).

$ cat t.c && gcc -O2 -S -Wall t.c
enum { X = 123456789 };

char c = X;

enum __attribute__ ((packed)) E { e3 = 3 };

enum E e = X;

void f (void)
{
  switch (0)
  case X * X: ;
}
t.c:3:10: warning: overflow in implicit constant conversion [-Woverflow]
 char c = X;
  ^
t.c:7:12: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
 enum E e = X;
^
t.c: In function ‘f’:
t.c:12:10: warning: integer overflow in expression [-Woverflow]
   case X * X: ;
  ^


The warnings would be more useful if they included additional detail, such as
the type and value of the expressions.  For example, consider Clang output:

t.c:3:10: warning: implicit conversion from 'int' to 'char' changes value from
  123456789 to 21 [-Wconstant-conversion]
char c = X;
 ~   ^
t.c:7:12: warning: implicit conversion from 'int' to 'enum E' changes value
from
  123456789 to 21 [-Wconstant-conversion]
enum E e = X;
   ~   ^
t.c:12:10: warning: overflow in expression; result is -1757895751 with type
  'int' [-Winteger-overflow]
  case X * X: ;
 ^
t.c:11:11: warning: no case matching constant switch condition '0'
  switch (0)
  ^
4 warnings generated.

[Bug fortran/80645] [8 regression] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I'm not able to reproduce the warning mentioned in comment #1 either with a
native x86_64 compiler (-m32 or -m64), or with the cross-compilers I tried
(powerpc64le-linux and sparcv9-sun-solaris2.11).

[Bug c++/80729] [GCC 6, 7] -Wuseless-cast doesn't detect casting string literals to (const char*)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
Not warning is correct because the type of a string literal is array of const
char while the type it's being cast to is const char*.

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I think it should be understood implicitly that it's the initializer *as 
converted* that must be a constant expression (and, thus, to be an address 
constant, must be of pointer type).  Thus "unsigned int x = -2.0;" at file 
scope is invalid (while -2.0 is a constant expression, the conversion to 
unsigned int would involve runtime undefined behavior, so makes it not a 
constant expression).  And that where part of a constant expression is an 
address constant, that can only be related to an overall address constant 
as an initializer in the obvious way (effectively, through operations that 
add constants to it, and conditional expressions with integer constant 
expression conditions).  Thus address constants converted to _Bool are not 
valid initializers, and nor is ("" ? "" : "") an address constant, because 
of the truth-value test of the first "" making an invalid condition.

That is, this is an issue about the unclear standard wording regarding 
constant expressions where I think the compiler is behaving appropriately.  
A question about appropriate conditions and array indices in address 
constants (whether they must be integer or just arithmetic constant 
expressions) is point 7 in my old list of constant expressions issues 
.  _Bool 
initializers with address constants and such constants controlling ?: are 
on my notes of further constant expression issues (the former probably 
based on 

 
and 
,
 
the latter with the date 2007-10-24 but I'm not sure where the discussion 
was).

[Bug target/80732] New: target_clones does not work with dlsym

[yyc1992 at gmail dot com]

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

Bug ID: 80732
   Summary: target_clones does not work with dlsym
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

Compiling the code below to a executable with `gcc -Wall -Wextra -O3 -fPIC -ldl
-rdynamic`. On a haswell+ system, the output is

```
1:
0, 4.93038e-32, 0
2:
4.93038e-32, 4.93038e-32, 4.93038e-32
```

Showing that with the manually created ifunc, dlsym, direct function call, and
accessing function address produces the same result (the fma version) whereas
with `target_clones` only direct function call uses the fma versison.

This might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366 but
I'm not entirely sure. From that bug report I can understand that this is just
how `target_clones` is currently implemented but I do think this is not a
documentation issue and should be fixed / improved instead since

1. in this case there is user observable inconsistency in the result generated
when different code paths are used. The fast math object should be allowed to
produce slightly inaccurate result but I do think it should produce consistent
result every time the function is called.

2. probably more importantly, this behavior makes the `target_clone` attribute
useless for used in public interface if the shared library can ever by
dynamically loaded.

```
#include 
#include 

__attribute__((target_clones("default","fma"),noinline,optimize("fast-math")))
double f1(double a, double b, double c)
{
return a * b + c;
}

double k1(double a, double b, double c, void **p)
{
*p = f1;
return f1(a, b, c);
}

__attribute__((target("fma"),optimize("fast-math")))
static double f2_fma(double a, double b, double c)
{
return a * b + c;
}

__attribute__((optimize("fast-math")))
static double f2_default(double a, double b, double c)
{
return a * b + c;
}

static void *f2_resolve(void)
{
__builtin_cpu_init ();
if (__builtin_cpu_supports("fma"))
return f2_fma;
else
return f2_default;
}

double f2(double a, double b, double c) __attribute__((ifunc("f2_resolve")));

double k2(double a, double b, double c, void **p)
{
*p = f2;
return f2(a, b, c);
}

int main()
{
volatile double a = 1.0002;
volatile double b = -0.9998;
volatile double c = 1.0;

void *hdl = dlopen(NULL, RTLD_NOW);

printf("1:\n");
double (*pf1)(double, double, double) = dlsym(hdl, "f1");
double (*pk1)(double, double, double, void**) = dlsym(hdl, "k1");
double (*_pf1)(double, double, double);

double v1_1 = pf1(a, b, c);
double v1_2 = pk1(a, b, c, (void**)&_pf1);
double v1_3 = _pf1(a, b, c);
printf("%g, %g, %g\n", v1_1, v1_2, v1_3);

printf("2:\n");
double (*pf2)(double, double, double) = dlsym(hdl, "f2");
double (*pk2)(double, double, double, void**) = dlsym(hdl, "k2");
double (*_pf2)(double, double, double);

double v2_1 = pf2(a, b, c);
double v2_2 = pk2(a, b, c, (void**)&_pf2);
double v2_3 = _pf2(a, b, c);
printf("%g, %g, %g\n", v2_1, v2_2, v2_3);

return 0;
}
```

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
See  for my 
old syntactic model of constant expressions in C99.  I'd consider it 
appropriate to handle implicit conversions in initializers exactly the 
same as casts are handled.

Essentially, I think that the intent for address constants is something 
syntactic (including implicit type conversions and conversions of arrays 
to pointers in the syntax) which is only approximated by the wording.  
Much like e.g. C90 and C99 both messed up the definition of lvalue in 
different ways and only C11 captured the essential concept of lvalues as 
everyone understood them.

[Bug tree-optimization/80733] New: -fstrict-enum ineffective, incorrect -Wtype-limits warning

[msebor at gcc dot gnu.org]

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

Bug ID: 80733
   Summary: -fstrict-enum ineffective, incorrect -Wtype-limits
warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -fstrict-enums option's effect is documented as

Allow the compiler to optimize using the assumption that a value of
enumerated type can only be one of the values of the enumeration (as defined in
the C++ standard; basically, a value that can be represented in the minimum
number of bits needed to represent all the enumerators). 

The program below shows that GCC doesn't actually perform the optimization.  It
only appears to constrain the range of values of the type to that of the
underlying type, apparently disregarding the TYPE_{MIN,MAX}_VALUE set by the
C++ front end in 
finish_enum_value_list in response to the option.

To add insult to injury, the -Wtype-limits warning suggests that GCC actually
does perform the optimization (the "not eliminated (bug), warning (bug)" case
below).

When compiled without -fstrict-enums, the emitted code stays the same.  The
only thing that changes is that the first warning (on line 16) is not issued.

$ cat t.C && gcc -O2 -S -Wall -Wextra -Wpedantic -Wconversion -xc++
-fstrict-enums -fdump-tree-optimized=/dev/stdout t.C | grep -E "(^void
(foo|bar)|abort)"
enum E { e0, e15 = 15 };
enum __attribute__ ((packed)) F { f0, f15 = 15 };

void foo (E e)
{
  if (e > 15) __builtin_abort ();   // not eliminated (bug)
}

void bar (E e)
{
  if (e > 255) __builtin_abort ();   // not eliminated (bug)
}

void foo (F f)
{
  if (f > 15) __builtin_abort ();   // not eliminated (bug), warning (bug)
}

void bar (F f)
{
  if (f > 255) __builtin_abort ();   // eliminated, warning (good)
}
t.C: In function ‘void foo(F)’:
t.C:16:9: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
   if (f > 15) __builtin_abort ();   // not eliminated (bug), warning (bug)
   ~~^~~~
t.C: In function ‘void bar(F)’:
t.C:21:9: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
   if (f > 255) __builtin_abort ();   // eliminated, warning
   ~~^
void foo(E) (E e)
  __builtin_abort ();
void bar(E) (E e)
  __builtin_abort ();
void foo(F) (F f)
  __builtin_abort ();
void bar(F) (F f)

[Bug middle-end/79794] unnecessary copy from target to target results in poor code for aarch64

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson  ---
Author: wilson
Date: Sat May 13 01:32:40 2017
New Revision: 248004

URL: https://gcc.gnu.org/viewcvs?rev=248004&root=gcc&view=rev
Log:
Patch for RTL expand bug affecting aarch64 vector code.

gcc/
PR middle-end/79794
* expmed.c (extract_bit_field_1): Add alt_rtl argument.  Before
maybe_expand_insn call, set ops[0].target.  If still set after call,
set alt_rtl.  Add extra arg to recursive calls.
(extract_bit_field): Add alt_rtl argument.  Pass to
extract_bit_field.
* expmed.h (extract_bit_field): Fix prototype.
* expr.c (emit_group_load_1, copy_blkmode_from_reg)
(copy_blkmode_to_reg, read_complex_part, store_field): Pass extra NULL
to extract_bit_field_calls.
(expand_expr_real_1): Pass alt_rtl to expand_expr_real instead of 0.
Pass alt_rtl to extract_bit_field calls.
* calls.c (store_unaligned_arguments_into_psuedos)
load_register_parameters): Pass extra NULL to extract_bit_field calls.
* optabs.c (maybe_legitimize_operand): Clear op->target when call
gen_reg_rtx.
* optabs.h (struct expand_operand): Add target bitfield.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/expmed.c
trunk/gcc/expmed.h
trunk/gcc/expr.c
trunk/gcc/optabs.c
trunk/gcc/optabs.h

[Bug middle-end/79794] unnecessary copy from target to target results in poor code for aarch64

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
Needs a testcase for the testsuite.

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I don't see what purpose rejecting

  bool b = "";

serves when

  bool b = !!"";

or even

  bool b = "" ? 1 : 0;

are accepted.

Even if it isn't 100% crystal clear, the standard encourages implementations to
be permissive and treat additional expressions as constant, beyond the bare
minimum it strictly requires.  It may be of value to issue pedantic warnings
for code that relies on more than the required minimum, but summarily rejecting
it based on a minimalist reading is unfriendly, especially when more involved
(and less intuitive) equivalent alternatives are accepted.  All that achieves
is that it penalizes users who write clean code, forcing them to come up with
clunky workarounds.

[Bug c/80734] New: GCC 6.3.1 errors compiling GCC 4.8.5 - error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute

[eric.parker at inventati dot org]

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

Bug ID: 80734
   Summary: GCC 6.3.1 errors compiling GCC 4.8.5 - error: ‘const
char* libc_name_p(const char*, unsigned int)’
redeclared inline with ‘gnu_inline’ attribute
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.parker at inventati dot org
  Target Milestone: ---

In file included from ../.././gcc/cp/except.c:1008:0:
cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’
redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’
previously declared here
cfns.gperf: At global scope:
cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const
char*, unsigned int)’ used but never defined


GCC version: 6.3.1
System: Fedora 25
GCC configuration: ./configure --prefix=`pwd`../build
GCC build command: make -j `nproc`

[Bug middle-end/80735] New: IPA: SRA inhibits constant propagation of structs across multiple function calls

[daniel.santos at pobox dot com]

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

Bug ID: 80735
   Summary: IPA: SRA inhibits constant propagation of structs
across multiple function calls
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.santos at pobox dot com
CC: mjambor at suse dot cz
  Target Milestone: ---

Created attachment 41350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41350&action=edit
test_case.c

I've finally managed a simple test case for this long-standing missed
optimization.  Given the test code built with -O2 -fno-inline:

static const struct foo {
  long a;
  long b;
} f = {8, 8};

static long a (const struct foo *foo) {return foo->b;}
static long b (const struct foo *foo) {return a (foo);}
long c (void) {return b (&f);}

Result:
 :
   0:   48 89 f8mov%rdi,%rax
   3:   c3  retq

0010 :
  10:   bf 08 00 00 00  mov$0x8,%edi
  15:   eb e9   jmp0 

0020 :
  20:   eb ee   jmp10 

Although we got isra for foo::b, I had expected a() to consist of only mov
$0x8, %eax; retq, and b() just be a jump to a().  But when we disable ipa-sra
we get the expected result (-O2 -fno-inline -fno-ipa-sra):

 :
   0:   b8 08 00 00 00  mov$0x8,%eax
   5:   c3  retq

0010 :
  10:   eb ee   jmp0 

0020 :
  20:   eb ee   jmp10 

If we replace the struct with an array or a pointer to a long then SRA does not
interfere with the constant propagation (-O2 -fno-inline):

static const long f[2] = {8, 8};
static long a (const long foo[]) {return foo[1];}
static long b (const long foo[]) {return a (foo);}
long c (void){return b (f);}

Result
 :
   0:   b8 08 00 00 00  mov$0x8,%eax
   5:   c3  retq

0010 :
  10:   eb ee   jmp0 

0020 :
  20:   eb ee   jmp10 

I'm still very new to this part of GCC, but I'm guessing that when we do the
SRA, we toss out the original aggregate.  If so, then we aren't reserving the
possibility that all of the function's callers could get cloned with a constant
for the aggregate, which would (probably always?) be better than just plucking
the scaler out of the aggregate.  I'll be digesting tree.sra.c and the cgraph
to try and figure this one out, but if anybody understands this better then I
would appreciate some hints.  :)

[Bug c/80734] GCC 6.3.1 errors compiling GCC 4.8.5 - error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Jakub Jelinek  ---
The bug is on the GCC 4.8 side, so either you need to patch it, or build with
-std=gnu++98 - then __GNUC_STDC_INLINE__ will not be defined and it ought to
compile fine.