[Bug libgcc/59305] [4.9/5/6/7 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |libgcc

--- Comment #29 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #28)
> Me too on a ThunderX, I thought it was due to an hardware errata too (where
> load acquire was not a memory barrier after a store release).

The problem turns out that pthread_mutex_lock/unlock is not fair.  So what is
happening is the newly created thread (which does the stores) will happen to
get the lock more often than the other thread which is doing the arithmetic
operations and is the time thread which is keeping count.

There are a few ways of fixing this.  One is to loop on try lock for a few
thousand times before falling through to the full mutex_lock  [Really this
should be done this way in libc].  The other way is to use spin locks (which
does not fix darwin as darwin does not have pthread spinlocks).

[Bug driver/71651] Option suggestion provides a non-existing hint

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01766.html

[Bug c++/41437] No access control for classes in template functions

[vgheorgh at gmail dot com]

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

Vlad Gheorghiu  changed:

   What|Removed |Added

 CC||vgheorgh at gmail dot com

--- Comment #8 from Vlad Gheorghiu  ---
The bug exists in gcc 6.1 as well:

class X
{
template
class A{};
};

int main()
{
X::A a; // compiles just fine
}

[Bug inline-asm/43998] inline assembler: can't set clobbering for input register

[stsp at users dot sourceforge.net]

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

--- Comment #15 from Stas Sergeev  ---
Btw, clang seems to allow same regs in input and clobber list.

[Bug inline-asm/43998] inline assembler: can't set clobbering for input register

[stsp at users dot sourceforge.net]

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

Stas Sergeev  changed:

   What|Removed |Added

 CC||stsp at users dot 
sourceforge.net

--- Comment #14 from Stas Sergeev  ---
(In reply to Eric Botcazou from comment #12)
> > the compiler may think that "something" do not modify eax. So next 
> > assignment
> > may use eax ( mov eax, x ). So, "it does not make sense to have it as a
> > clobber" is not correct. does not it ?
> 
> Andrew was saying that it doesn't make sense to consider input operands as
> clobbered by an inline asm, generically.
How about allowing an ampersand in the input list?
Just like early clobber in output list, in input list
it may mean "late clobber" - that is, clobbered after
the argument is taken.
Then you won't contradict with any doc and will avoid
any logical inconsistency.
This makes a lot of sense for things like "rep; movsl"
where you'd need 3 dummy values...

[Bug fortran/71649] Internal compiler error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
(In reply to jack.s...@nasa.gov from comment #2)

> >
> > Could someone check that the problem is not darwin specific?
> >

Not darwin specific. Is the sample code valid?

[Bug target/71656] ICE in reload when generating code for -mcpu=power9 -mpower9-dform-vector

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #1 from Peter Bergner  ---
I'm testing a patch to fix this.

[Bug target/71656] New: ICE in reload when generating code for -mcpu=power9 -mpower9-dform-vector

[bergner at gcc dot gnu.org]

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

Bug ID: 71656
   Summary: ICE in reload when generating code for -mcpu=power9
-mpower9-dform-vector
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

The following test case ICEs when generating code for POWER9 vector dform
addressing and reload.  It compiles fine when using LRA:

bergner@genoa:~/gcc/BUGS/RELOAD$ cat bug.i 
typedef __attribute__((altivec(vector__))) int type_t;
type_t
fn1 (type_t *src)
{
  asm volatile ("# force the base reg on the load below to be spilled"
   : /* no outputs */
   : /* no inputs */
   : "r0", "r1", "r3", "r4", "r5", "r6", "r7",
 "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
 "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
 "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31");
  return src[1];
}

bergner@genoa:~/gcc/BUGS/RELOAD$
/home/bergner/gcc/build/gcc-fsf-mainline-vec-dform-base/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-vec-dform-base/gcc -S -O1
-mcpu=power9 -mpower9-dform-vector -mno-lra bug.i 
bug.i:1:0: warning: -mpower9-dform-vector might need -mlra
 typedef __attribute__((altivec(vector__))) int type_t;

bug.i: In function ‘fn1’:
bug.i:13:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 12 7 13 2 (set (reg/i:V4SI 79 2)
(mem:V4SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
(const_int 32 [0x20])) [2 %sfp+32 S8 A64])
(const_int 16 [0x10])) [1 MEM[(type_t *)src_2(D) + 16B]+0 S16
A128])) bug.i:13 946 {*vsx_movv4si_64bit}
 (nil))
bug.i:13:1: internal compiler error: in extract_constrain_insn, at recog.c:2211

The problem is that rs6000_legitimize_reload_address() does not have any
support for POWER9 vector dform addresses.

[Bug middle-end/71650] unnecessary call to __memcpy_chk emitted on a bounded copy

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The question is if we want to do anything here.  The problem is that VRP ranges
are computed from many sources, it can be comparisons in the code you show, or
masking of values, but it can as well be just because we prove that using
values outside of the ranges would necessarily trigger undefined behavior.
But, -D_FORTIFY_SOURCE=2 is a security feature to protect against undefined
behavior, and we don't have information whether the particular VR is guaranteed
in all executions or only those that don't invoke UB.

[Bug middle-end/71654] [6/7 Regression] missing VRP optimization on c++ unsigned char and short expressions

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-24
Summary|missing VRP optimization on |[6/7 Regression] missing
   |c++ unsigned char and short |VRP optimization on c++
   |expressions |unsigned char and short
   ||expressions
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
  _1 = (intD.9) i_3(D);
  if (_1 <= 3)
[...]
  _5 = i_3(D) & 4;

So we know stuff about the range of _1, but we don't transfer that information
to i_3. Far from the first time I see something like this in VRP :-(

We could optimize _1 <= 3 to i_3(D) <= 3, and in this case it should help, but
IIRC there are also cases where it hurts (if we use _1 later on and don't move
the definition of _1 after the condition...). Here the failure is because we
were inconsistent about narrowing, forwprop changed (int)i & 4 to (int)(i & 4)
but not (int)i <= 3 to i <= 3. I get return 0" if I disable the first 2
forwprop passes.

[Bug target/71655] New: GCC trunk ICE on westmere target

[anton.mitrokhin at phystech dot edu]

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

Bug ID: 71655
   Summary: GCC trunk ICE on westmere target
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton.mitrokhin at phystech dot edu
  Target Milestone: ---

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

Reproducer:
> g++ -std=c++11 -Ofast -march=westmere -o out -c crash.cpp


Output:
crash.cpp: In function 'void fn1()':
crash.cpp:11:6: internal compiler error: in vect_get_vec_def_for_stmt_copy, at
tree-vect-stmts.c:1527
 void fn1() {
  ^~~
0xf302ef vect_get_vec_def_for_stmt_copy(vect_def_type, tree_node*)
/export/users/gnutester/stability/svn/trunk/gcc/tree-vect-stmts.c:1527
0xf3ee02 vectorizable_comparison
/export/users/gnutester/stability/svn/trunk/gcc/tree-vect-stmts.c:7938
0xf4ceab vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
/export/users/gnutester/stability/svn/trunk/gcc/tree-vect-stmts.c:8337
0xf53db5 vect_transform_loop(_loop_vec_info*)
/export/users/gnutester/stability/svn/trunk/gcc/tree-vect-loop.c:6893
0xf70cfe vectorize_loops()
/export/users/gnutester/stability/svn/trunk/gcc/tree-vectorizer.c:554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.




> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/users/amitrokh/gcc_trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/users/gnutester/stability/svn/trunk/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fh-pkgversion=Revision=237716/svn-rev:237719/
--prefix=/export/users/gnutester/stability/work/trunk/64/install
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 7.0.0 20160622 (experimental) (Revision=237716/svn-rev:237719/)

[Bug debug/71642] [7 Regression] ICE: in gen_type_die_with_usage, at dwarf2out.c:22729

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks for the small reproducer.

[Bug debug/71642] [7 Regression] ICE: in gen_type_die_with_usage, at dwarf2out.c:22729

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Jun 24 19:28:18 2016
New Revision: 237771

URL: https://gcc.gnu.org/viewcvs?rev=237771&root=gcc&view=rev
Log:
PR debug/71642
* tree-inline.c (remap_decl): When fixing up DECL_ORIGINAL_TYPE, just
copy the type name.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71642.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug middle-end/71654] New: missing VRP optimization on c++ unsigned char and short expressions

[msebor at gcc dot gnu.org]

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

Bug ID: 71654
   Summary: missing VRP optimization on c++ unsigned char and
short expressions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C mode, GCC optimizes the both of the following functions into "return 0" as
one would expect.  But in C++ mode, it emits suboptimal code for guc: it does
the computation at runtime.  The same limitation exists if the type of the
argument is unsigned short.  From the dumps it looks as though the promotion
from the narrower type to int that's done in C++ before the inequality test
might be what prevents VRP from doing the expected thing.

$ cat vrp.c && /build/gcc-49905/gcc/xgcc -B /build/gcc-49905/gcc -O2 -S -Wall
-Wextra -fdump-tree-optimized=/dev/stdout -xc++ vrp.c
int gui (unsigned i)
{
  return i < 4 ? i & 4 : 0;
}

int guc (unsigned char i)
{
  return i < 4 ? i & 4 : 0;
}

;; Function int gui(unsigned int) (_Z3guij, funcdef_no=0, decl_uid=2248,
cgraph_uid=0, symbol_order=0)

int gui(unsigned int) (unsigned int i)
{
  :
  return 0;

}



;; Function int guc(unsigned char) (_Z3guch, funcdef_no=1, decl_uid=2251,
cgraph_uid=1, symbol_order=1)

Removing basic block 5
int guc(unsigned char) (unsigned char i)
{
  int _1;
  unsigned char _5;
  unsigned char _7;
  int prephitmp_8;

  :
  _1 = (int) i_3(D);
  if (_1 <= 3)
goto ;
  else
goto ;

  :
  _5 = i_3(D) & 4;

  :
  # _7 = PHI <_5(3), 0(2)>
  prephitmp_8 = (int) _7;
  return prephitmp_8;

}

[Bug fortran/71649] Internal compiler error

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
possible patch:

diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 6d3860e..c4c6cb4 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -6157,7 +6157,7 @@ create_intrinsic_function (const char *name, int id,
   gfc_symbol *sym;

   tmp_symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);
-  if (tmp_symtree)
+  if (tmp_symtree && tmp_symtree->n.sym && tmp_symtree->n.sym->module)
 {
   if (strcmp (modname, tmp_symtree->n.sym->module) == 0)
 return;

With this code, the example compiles with errors. Does not like the subroutine
to have same name as the function in ISO_FORTRAN_ENV Compiler_Options.

[Bug tree-optimization/71647] aligned(x:32) in #pragma omp simd does not work

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 24 18:46:47 2016
New Revision: 237770

URL: https://gcc.gnu.org/viewcvs?rev=237770&root=gcc&view=rev
Log:
PR tree-optimization/71647
* omp-low.c (lower_rec_input_clauses): Convert
omp_clause_aligned_alignment (c) to size_type_node for the
last argument of __builtin_assume_aligned.

* gcc.target/i386/pr71647.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr71647.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/71647] aligned(x:32) in #pragma omp simd does not work

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 24 18:44:11 2016
New Revision: 237769

URL: https://gcc.gnu.org/viewcvs?rev=237769&root=gcc&view=rev
Log:
PR tree-optimization/71647
* omp-low.c (lower_rec_input_clauses): Convert
omp_clause_aligned_alignment (c) to size_type_node for the
last argument of __builtin_assume_aligned.

* gcc.target/i386/pr71647.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr71647.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71595] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[su at cs dot ucdavis.edu]

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

--- Comment #1 from Zhendong Su  ---
Below is another test case that triggers the same ICE, but also at -O1 and -Os
(in addition to -O2 and -O3). 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160624 (experimental) [trunk revision 237753] (GCC) 
$ 
$ gcc-trunk -O0 -c small.c
$ gcc-6.1 -O1 -c small.c
$ 
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:5:1: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:704
 fn1 ()
 ^~~
0xd30c3c check_loop_closed_ssa_use
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:703
0xd339f6 check_loop_closed_ssa_stmt
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:719
0xd339f6 verify_loop_closed_ssa(bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:753
0xd17a6e tree_unroll_loops_completely(bool, bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1431
0xd17afa execute
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





int a, d, e, f, g, h;
static int b[][6] = { {0}, {0}, {1, 1}, {1} };

void
fn1 ()
{
  for (; f; f++)
if (g)
  {
for (e = 0; e < 5; e++)
  if (b[e + 2][1])
{
  h = b[2][e] ? 0 : a;
  d |= 4;
}
  else
return;
  }
}

[Bug driver/71651] Option suggestion provides a non-existing hint

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Also affects gcc-6-branch

[Bug ada/62235] segmentation fault on Ada 2012 code

[porton at narod dot ru]

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

--- Comment #10 from Victor Porton  ---
(In reply to Victor Porton from comment #8)
> Note fixed in GCC 6.1.1.

Sorry, should read "Not fixed in GCC 6.1.1."

[Bug c++/71653] error when trying to compile a code with template friend function in a struct

[raphael.rg91 at gmail dot com]

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

--- Comment #2 from Raphael Gozzo  ---
This error happens in the 6.1 version too (tested here http://gcc.godbolt.org)

[Bug c++/71653] error when trying to compile a code with template friend function in a struct

[raphael.rg91 at gmail dot com]

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

--- Comment #1 from Raphael Gozzo  ---
Created attachment 38765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38765&action=edit
source file

[Bug ada/62235] segmentation fault on Ada 2012 code

[porton at narod dot ru]

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

--- Comment #9 from Victor Porton  ---
A similar bug (but with another error message) appears in GNAT GPL 2016 for
Windows x32 32bit.

[Bug c++/71653] New: error when trying to compile a code with template friend function in a struct

[raphael.rg91 at gmail dot com]

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

Bug ID: 71653
   Summary: error when trying to compile a code with template
friend function in a struct
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raphael.rg91 at gmail dot com
  Target Milestone: ---

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

$ g++ -v -save-temps -std=c++11 -c testcase.cpp

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/4.8/cc1plus -E -quiet -v -D_GNU_SOURCE
testcase.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o
testcase.ii
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.8
 /usr/include/c++/4.8/x86_64-suse-linux
 /usr/include/c++/4.8/backward
 /usr/lib64/gcc/x86_64-suse-linux/4.8/include
 /usr/local/include
 /usr/lib64/gcc/x86_64-suse-linux/4.8/include-fixed
 /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/4.8/cc1plus -fpreprocessed testcase.ii -quiet
-dumpbase testcase.cpp -mtune=generic -march=x86-64 -auxbase testcase
-std=c++11 -version -o testcase.s
GNU C++ (SUSE Linux) version 4.8.5 (x86_64-suse-linux)
compiled by GNU C version 4.8.5, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (SUSE Linux) version 4.8.5 (x86_64-suse-linux)
compiled by GNU C version 4.8.5, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ca63ef29755a145e45a587295d513e14
testcase.cpp: In function ‘int main()’:
testcase.cpp:16:9: error: no matching function for call to ‘f(S*)’
 f(&s);
 ^
testcase.cpp:16:9: note: candidate is:
testcase.cpp:5:28: note: template C f(T*)
 template  C f(T *);
^
testcase.cpp:5:28: note:   template argument deduction/substitution failed:
testcase.cpp:3:166: error: template instantiation depth exceeds maximum of 900
(use -ftemplate-depth= to increase the maximum) substituting ‘template
using C = typename std::conditional
>::value, typename std::add_const::type, typename
T::InnerType>::type [with T = S]’
 template  using C = typename
std::conditional::value, typename std::add_const::type, typename T::InnerType>::type;
   
   
  ^
testcase.cpp:3:166:   recursively required by substitution of ‘template using C = typename std::conditional
>::value, typename std::add_const::type, typename
T::InnerType>::type [with T = S]’
testcase.cpp:3:166:   required by substitution of ‘template using C =
typename std::conditional >::value,
typename std::add_const::type, typename
T::InnerType>::type [with T = S]’
testcase.cpp:5:28:   required by substitution of ‘template C f(T*)
[with T = S]’
testcase.cpp:16:9:   required from here

[Bug driver/71651] Option suggestion provides a non-existing hint

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Confirmed.  I'm working on a fix for this.

[Bug target/71648] C++ ICE on ppc64 with -m64

[markos at freevec dot org]

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

--- Comment #4 from Konstantinos Margaritis  ---
That's true, it compiled fine with -mcpu=power8.

[Bug target/71648] C++ ICE on ppc64 with -m64

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-24
 Ever confirmed|0   |1

--- Comment #3 from Michael Meissner  ---
This is a bug that shows up with -mcpu=power7, and it still is a bug in the
current GCC 7.0.  If you build it with -mcpu=power8, it will compile fine. 
This is because power8 has the direct move instructions, which power7 does not.

[Bug middle-end/71585] Cannot selectively disable stack protector with LTO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-24
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---

> The only question is whether we can add the flag to optimize flags? If so,
> I'll send the patch to mailing list.
> Btw. I've come to a misleading hint related to the option: PR69265 and
> accidentally I hit also this: PR71652.

Sorry, the first link should be: PR71651.

[Bug middle-end/71585] Cannot selectively disable stack protector with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Hello

The problem can be seen on both GCC 6.x and current trunk, where we show
following warning message:

pr71585.c:2:9: warning: bad option ‘-fno-stack-protector’ to pragma ‘optimize’
[-Wpragmas]
 #pragma GCC optimize ("-fno-stack-protector")
 ^~~
pr71585.c:7:1: warning: bad option ‘-fno-stack-protector’ to attribute
‘optimize’ [-Wattributes]
 {
 ^

The problem is that '-fstack-protect' is not marked as Optimize option.

Following patch fixed that:

diff --git a/gcc/common.opt b/gcc/common.opt
index 5d90385..a7c5125 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2221,19 +2221,19 @@ Common RejectNegative Joined
Var(common_deferred_options) Defer
 -fstack-limit-symbol=Trap if the stack goes past symbol .

 fstack-protector
-Common Report Var(flag_stack_protect, 1) Init(-1)
+Common Report Var(flag_stack_protect, 1) Init(-1) Optimization
 Use propolice as a stack protection method.

 fstack-protector-all
-Common Report RejectNegative Var(flag_stack_protect, 2) Init(-1)
+Common Report RejectNegative Var(flag_stack_protect, 2) Init(-1) Optimization
 Use a stack protection method for every function.

 fstack-protector-strong
-Common Report RejectNegative Var(flag_stack_protect, 3) Init(-1)
+Common Report RejectNegative Var(flag_stack_protect, 3) Init(-1) Optimization
 Use a smart stack protection method for certain functions.

 fstack-protector-explicit
-Common Report RejectNegative Var(flag_stack_protect, 4)
+Common Report RejectNegative Var(flag_stack_protect, 4) Optimization
 Use stack protection method only for functions with the stack_protect
attribute.

The only question is whether we can add the flag to optimize flags? If so, I'll
send the patch to mailing list.
Btw. I've come to a misleading hint related to the option: PR69265 and
accidentally I hit also this: PR71652.

Another possible problem I can see is that some i386 target attributes are not
handled,
for instance:

pr71585.c:3:9: error: attribute(target("stack-protector-guard=tls")) is unknown
 #pragma GCC target ("stack-protector-guard=tls")
 ^~~

Following hunk is necessary to enable the parsing:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index f7944f9..73f2149 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -6458,6 +6458,7 @@ ix86_valid_target_attribute_inner_p (tree args, char
*p_strings[],

 /* enum options */
 IX86_ATTR_ENUM ("fpmath=", OPT_mfpmath_),
+IX86_ATTR_ENUM ("stack-protector-guard=", OPT_mstack_protector_guard_),

 /* string options */
 IX86_ATTR_STR ("arch=",IX86_FUNCTION_SPECIFIC_ARCH),

I'll write a test-case for that.

Martin

[Bug target/71652] New: [7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187

[marxin at gcc dot gnu.org]

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

Bug ID: 71652
   Summary: [7 Regression] ICE in in ix86_target_macros_internal,
at config/i386/i386-c.c:187
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Running:

#pragma GCC push_options
#pragma GCC target ("arch=generic") // ICE

__attribute__((constructor)) void foo()
{
  asm ("");
}

#pragma GCC pop_options

int main() { return 0; }

$ gcc pr71585-ice.c
pr71585-ice.c:2:9: error: generic CPU can be used only for option("tune=")
attribute
 #pragma GCC target ("arch=generic") // ICE
 ^~~
pr71585-ice.c:2:9: internal compiler error: in ix86_target_macros_internal, at
config/i386/i386-c.c:187
0x8d0f27 ix86_target_macros_internal
../../gcc/config/i386/i386-c.c:187
0x8d1ecc ix86_pragma_target_parse
../../gcc/config/i386/i386-c.c:530
0x8ae3b1 handle_pragma_target
../../gcc/c-family/c-pragma.c:893
0x8af160 c_invoke_pragma_handler(unsigned int)
../../gcc/c-family/c-pragma.c:1482
0x8182e0 c_parser_pragma
../../gcc/c/c-parser.c:10289
0x80387f c_parser_external_declaration
../../gcc/c/c-parser.c:1537
0x80343b c_parser_translation_unit
../../gcc/c/c-parser.c:1437
0x835a33 c_parse_file()
../../gcc/c/c-parser.c:17985
0x8a9677 c_common_parse_file()
../../gcc/c-family/c-opts.c:1070

GCC 5.3.1 and GCC 6.1.1 are fine.

Thanks,
Martin

[Bug tree-optimization/71647] aligned(x:32) in #pragma omp simd does not work

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug driver/71651] New: Option suggestion provides a non-existing hint

[marxin at gcc dot gnu.org]

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

Bug ID: 71651
   Summary: Option suggestion provides a non-existing hint
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Running: gcc -fno-stack-protector-explicit -O2 pr71585.c -S

gcc: error: unrecognized command line option ‘-fno-stack-protector-explicit’;
did you mean ‘-fno-stack-protector-explicit’?

Problem is that the option has 'RejectNegative' flag set.

fstack-protector-explicit
Common Report RejectNegative Var(flag_stack_protect, 4)
Use stack protection method only for functions with the stack_protect
attribute.

Martin

[Bug middle-end/71650] New: unnecessary call to __memcpy_chk emitted on a bounded copy

[msebor at gcc dot gnu.org]

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

Bug ID: 71650
   Summary: unnecessary call to __memcpy_chk emitted on a bounded
copy
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Object Size Checking functions like __builtin___memcpy_chk apparently don't
take full advantage of the value range information available with the Value
Range Optimization and unnecessarily result in calls to the runtime checking
functions even in cases when the calls are provably safe.

For example, in the program below, the call to memcpy is bounded by the size of
the destination object yet GCC still emits a call to __memcpy_chk when it could
instead fold the call.

$ cat memcpy.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2
-S -Wall -Wextra -fdump-tree-optimized=/dev/stdout memcpy.ctypedef
__SIZE_TYPE__ size_t;

char buf [13];

void f (void *p, size_t n)
{
  if (n <= sizeof buf)
__builtin___memcpy_chk (buf, p, n, sizeof buf);
}

;; Function f (f, funcdef_no=0, decl_uid=1754, cgraph_uid=0, symbol_order=1)

Removing basic block 5
f (void * p, size_t n)
{
  :
  if (n_2(D) <= 13)
goto ;
  else
goto ;

  :
  __builtin___memcpy_chk (&buf, p_4(D), n_2(D), 13); [tail call]

  :
  return;

}

[Bug bootstrap/70473] genautomata memory footprint for arm

[lly.dev at gmail dot com]

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

--- Comment #6 from Leonid Lisovskiy  ---
Created attachment 38762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38762&action=edit
genautomata output ARM

I have the same problem for both ARM(armv7-a) & MIPS platforms. By valgrind
report genautomata requires:

1) 527MB for MIPS32
2) 903MB for ARM

genautomata output(-time -progress -stats) attached to PR. Probably we need to
try to decrease reservations for `xlp_cpu', `xlp_fpu' for MIPS and
`cortex_a8_neon', `cortex_a15_neon', `cortex_a53' for ARM ??!
Is it possible?

[Bug bootstrap/70473] genautomata memory footprint for arm

[lly.dev at gmail dot com]

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

Leonid Lisovskiy  changed:

   What|Removed |Added

 CC||lly.dev at gmail dot com

--- Comment #5 from Leonid Lisovskiy  ---
Created attachment 38761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38761&action=edit
genautomata output MIPS32

[Bug fortran/71649] Internal compiler error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug fortran/71649] Internal compiler error

[jack.saba at nasa dot gov]

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

--- Comment #2 from jack.saba at nasa dot gov  ---
I tried it on a ubuntu machine and got the same error.

Jack Saba
jack.s...@nasa.gov
Science, Systems, and Applications, Inc.
Cryospheric Sciences Laboratory, Code 615
Bldg 33 Room A328
NASA/Goddard Space Flight Center
Greenbelt Md 20771
301-614-5878
Fax: 301-614-5644

On 6/24/16 11:54, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71649
>
> Dominique d'Humieres  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2016-06-24
>  CC||fxcoudert at gcc dot gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #1 from Dominique d'Humieres  ---
> Confirmed from 4.8 up to trunk (7.0) without any option. The backtrace is
>
> * thread #1: tid = 0xfd5298, 0x7fff9feb78b5
> libsystem_platform.dylib`_platform_strcmp + 181, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
> frame #0: 0x7fff9feb78b5 libsystem_platform.dylib`_platform_strcmp +
> 181
> libsystem_platform.dylib`_platform_strcmp:
> ->  0x7fff9feb78b5 <+181>: movdqu (%rsi,%rcx), %xmm1
> 0x7fff9feb78ba <+186>: pcmpeqb %xmm1, %xmm0
> 0x7fff9feb78be <+190>: pcmpeqb %xmm2, %xmm1
> 0x7fff9feb78c2 <+194>: pandn  %xmm0, %xmm1
> (lldb) bt
> * thread #1: tid = 0xfd5298, 0x7fff9feb78b5
> libsystem_platform.dylib`_platform_strcmp + 181, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>   * frame #0: 0x7fff9feb78b5 libsystem_platform.dylib`_platform_strcmp +
> 181
> frame #1: 0x00010006a3e2
> f951`::create_intrinsic_function(name="compiler_options", id=27,
> modname="iso_fortran_env", module=INTMOD_ISO_FORTRAN_ENV,
> subroutine=, result_type=0x) + 82 at 
> module.c:6170
> frame #2: 0x00010006cc45 f951`::use_iso_fortran_env_module() + 773 at
> module.c:6752
> frame #3: 0x000100072910
> f951`::gfc_use_module(module=0x00014270a050) + 6384 at module.c:6881
> frame #4: 0x0001000744eb f951`gfc_use_modules() + 539 at module.c:7112
> frame #5: 0x00010008231e f951`::use_modules() + 46 at parse.c:114
> frame #6: 0x000100086335 f951`::decode_statement() + 949 at 
> parse.c:332
> frame #7: 0x000100088174 f951`::next_statement() + 276 at parse.c:1080
> frame #8: 0x000100089dcd f951`::parse_spec(st=ST_USE) + 3325 at
> parse.c:3637
> frame #9: 0x00010008d0d7 f951`::parse_progunit(st=) + 39
> at parse.c:5420
> frame #10: 0x00010008ed63 f951`gfc_parse_file() + 2003 at parse.c:5944
> frame #11: 0x0001000d625b f951`::gfc_be_parse_file() + 59 at
> f95-lang.c:201
> frame #12: 0x000100b67aba f951`::compile_file() + 58 at toplev.c:465
> frame #13: 0x000101051114 f951`toplev::main(int, char**) + 1544 at
> toplev.c:1998
> frame #14: 0x000101050b0c f951`toplev::main(this=0x7fff5fbff340,
> argc=, argv=) + 732
> frame #15: 0x000101052979 f951`main(argc=2, argv=0x7fff5fbff380) +
> 41 at main.c:39
> frame #16: 0x7fff9ea105ad libdyld.dylib`start + 1
>
> (lldb) p *tmp_symtree
> (gfc_symtree) $1 = {
>   priority = 1978153288
>   left = 0x84048d49a4048d4b
>   right = 0x0080c7848b41
>   name = 0x5c415d5b08c48348 
>   ambiguous = 1581342017
>   n = {
> sym = 0x6c266a358b00401f
> uop = 0x6c266a358b00401f
> common = 0x6c266a358b00401f
> tb = 0x6c266a358b00401f
> omp_udr = 0x6c266a358b00401f
>   }
> }
> (lldb) p tmp_symtree->n.sym->module
> error: Couldn't apply expression side effects : Couldn't dematerialize a 
> result
> variable: couldn't read its memory
>
> Could someone check that the problem is not darwin specific?
>

[Bug fortran/71649] Internal compiler error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-24
 CC||fxcoudert at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0) without any option. The backtrace is

* thread #1: tid = 0xfd5298, 0x7fff9feb78b5
libsystem_platform.dylib`_platform_strcmp + 181, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x7fff9feb78b5 libsystem_platform.dylib`_platform_strcmp +
181
libsystem_platform.dylib`_platform_strcmp:
->  0x7fff9feb78b5 <+181>: movdqu (%rsi,%rcx), %xmm1
0x7fff9feb78ba <+186>: pcmpeqb %xmm1, %xmm0
0x7fff9feb78be <+190>: pcmpeqb %xmm2, %xmm1
0x7fff9feb78c2 <+194>: pandn  %xmm0, %xmm1
(lldb) bt
* thread #1: tid = 0xfd5298, 0x7fff9feb78b5
libsystem_platform.dylib`_platform_strcmp + 181, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x7fff9feb78b5 libsystem_platform.dylib`_platform_strcmp +
181
frame #1: 0x00010006a3e2
f951`::create_intrinsic_function(name="compiler_options", id=27,
modname="iso_fortran_env", module=INTMOD_ISO_FORTRAN_ENV,
subroutine=, result_type=0x) + 82 at module.c:6170
frame #2: 0x00010006cc45 f951`::use_iso_fortran_env_module() + 773 at
module.c:6752
frame #3: 0x000100072910
f951`::gfc_use_module(module=0x00014270a050) + 6384 at module.c:6881
frame #4: 0x0001000744eb f951`gfc_use_modules() + 539 at module.c:7112
frame #5: 0x00010008231e f951`::use_modules() + 46 at parse.c:114
frame #6: 0x000100086335 f951`::decode_statement() + 949 at parse.c:332
frame #7: 0x000100088174 f951`::next_statement() + 276 at parse.c:1080
frame #8: 0x000100089dcd f951`::parse_spec(st=ST_USE) + 3325 at
parse.c:3637
frame #9: 0x00010008d0d7 f951`::parse_progunit(st=) + 39
at parse.c:5420
frame #10: 0x00010008ed63 f951`gfc_parse_file() + 2003 at parse.c:5944
frame #11: 0x0001000d625b f951`::gfc_be_parse_file() + 59 at
f95-lang.c:201
frame #12: 0x000100b67aba f951`::compile_file() + 58 at toplev.c:465
frame #13: 0x000101051114 f951`toplev::main(int, char**) + 1544 at
toplev.c:1998
frame #14: 0x000101050b0c f951`toplev::main(this=0x7fff5fbff340,
argc=, argv=) + 732
frame #15: 0x000101052979 f951`main(argc=2, argv=0x7fff5fbff380) +
41 at main.c:39
frame #16: 0x7fff9ea105ad libdyld.dylib`start + 1

(lldb) p *tmp_symtree
(gfc_symtree) $1 = {
  priority = 1978153288
  left = 0x84048d49a4048d4b
  right = 0x0080c7848b41
  name = 0x5c415d5b08c48348 
  ambiguous = 1581342017
  n = {
sym = 0x6c266a358b00401f
uop = 0x6c266a358b00401f
common = 0x6c266a358b00401f
tb = 0x6c266a358b00401f
omp_udr = 0x6c266a358b00401f
  }
}
(lldb) p tmp_symtree->n.sym->module
error: Couldn't apply expression side effects : Couldn't dematerialize a result
variable: couldn't read its memory

Could someone check that the problem is not darwin specific?

[Bug target/71648] C++ ICE on ppc64 with -m64

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #2 from Bill Schmidt  ---
Mike, does this look familiar?  Looks like DImode in VSX registers on BE back
on 6.1, which I didn't think was enabled there.

[Bug fortran/71649] New: Internal compiler error

[jack.saba at nasa dot gov]

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

Bug ID: 71649
   Summary: Internal compiler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jack.saba at nasa dot gov
  Target Milestone: ---

MAC-bash: gfortran -c -Wall -Wextra -fno-strict-aliasing -fwrapv test.f90
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Computer info:
 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016;
root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64


Here's the code, based on the example in section 9.65 of gfortran.pdf

SUBROUTINE Compiler_Options ( Options, Version, WriteOpt )

   USE ISO_FORTRAN_ENV, ONLY : Compiler_Version, Compiler_Options
   IMPLICIT NONE
   CHARACTER (LEN=*), INTENT(OUT) :: Options
   CHARACTER (LEN=*), INTENT(OUT) :: Version
   LOGICAL, INTENT(IN), OPTIONAL  :: WriteOpt

  
!

   Version = Compiler_Version()
   Options = Compiler_Options()
   IF ( PRESENT(WriteOpt) ) THEN
  IF ( WriteOpt ) &
 PRINT '(A)', 'This file was compiled using gfortran by ' &
   // TRIM(Version) // ' using the options ' // TRIM(Options)
   END IF

   RETURN

END SUBROUTINE Compiler_Options

[Bug tree-optimization/70032] tree-ssa-tail-merge engine replacement

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Note the very first "cleanup" would be to rip out all value numbering use
> from
> the current implementation and make the pass properly separate.  Now that
> FRE/PRE do full copy/constant propagation valueization shouldn't be necessary
> any more.

Richard,

any comments on my remarks in comment 2?

Thanks,
- Tom

[Bug target/71648] C++ ICE on ppc64 with -m64

[markos at freevec dot org]

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

--- Comment #1 from Konstantinos Margaritis  ---
Created attachment 38760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38760&action=edit
Reduced testcase for ICE on ppc64

[Bug target/71648] New: C++ ICE on ppc64 with -m64

[markos at freevec dot org]

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

Bug ID: 71648
   Summary: C++ ICE on ppc64 with -m64
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markos at freevec dot org
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc-linux-gnu
Target: powerpc-linux-gnu
 Build: powerpc-linux-gnu

$ g++-6 -m64 -O2 -c testcase2.cpp 
testcase2.cpp: In function ‘void x33()’:
testcase2.cpp:55:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 40 39 41 2 (set (reg:DI 63 31 [orig:157 _6 ] [157])
(reg:DI 9 9)) testcase2.cpp:44 549 {*movdi_internal64}
 (nil))
testcase2.cpp:55:1: internal compiler error: in extract_constrain_insn, at
recog.c:2190
0x107077ff _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x10707833 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:119
0x106d5be7 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2190
0x106da11f copyprop_hardreg_forward_1
../../src/gcc/regcprop.c:774
0x106db59f copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
../../src/gcc/regcprop.c:1152
0x107493bf prepare_shrink_wrap
../../src/gcc/shrink-wrap.c:440
0x107493bf try_shrink_wrapping(edge_def**, bitmap_head*, rtx_insn*)
../../src/gcc/shrink-wrap.c:646
0x104f0c7b thread_prologue_and_epilogue_insns()
../../src/gcc/function.c:6066
0x104f1757 rest_of_handle_thread_prologue_and_epilogue
../../src/gcc/function.c:6588
0x104f1757 execute
../../src/gcc/function.c:6630
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/71647] New: aligned(x:32) in #pragma omp simd does not work

[niva at niisi dot msk.ru]

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

Bug ID: 71647
   Summary: aligned(x:32) in #pragma omp simd does not work
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niva at niisi dot msk.ru
  Target Milestone: ---

Created attachment 38759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38759&action=edit
The source file to reproduce the problem.

I use gcc (GCC) 6.1.1 20160623. The command line is:

gcc -O3 -S -mavx -fopt-info-vec-optimized  -fopenmp-simd  test1a.c 

When I use #pragma omp simd aligned(a,b:32) in the source file (see
attachment), the compiler reports:

test1a.c:9:8: note: loop vectorized
test1a.c:9:8: note: loop peeled for vectorization to enhance alignment

But when I use #pragma omp simd aligned(a,b:4*sizeof(double)),
the alignment is taken into account, and the compiler output is:

test1a.c:9:8: note: loop vectorized

gcc 5.3.1 works ok in both cases.

[Bug debug/71642] [7 Regression] ICE: in gen_type_die_with_usage, at dwarf2out.c:22729

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from Eric Botcazou  ---
*** Bug 71645 has been marked as a duplicate of this bug. ***

[Bug debug/71645] [7 Regression] FAIL: libgomp.fortran/nestedfn5.f90 -O3 -g (internal compiler error)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|middle-end  |debug
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Botcazou  ---
.

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

[Bug libgomp/71646] New: incompability between ptx code and GPU hardware

[didu31 at hotmail dot fr]

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

Bug ID: 71646
   Summary: incompability between ptx code and GPU hardware
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: didu31 at hotmail dot fr
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38758&action=edit
Very simple OpenACC program

Hardware : Core 2 Quad + Nvidia Geforce GT 430

OS : Linux 4.4.0-24-generic x86_64

lib environ : 
  - gcc 6.1 (compiled from sources) 
  - nvidia-toolkit-7.5
  - libcudart 7.5
  - libcuda1-361
  - nvptx-tools, master branch of June, the 17th (compiled from
sources)

The attached source program is compiled and linked thanks to this command :

gcc t.c -fopenacc -foffload=nvptx-none -foffload="-O3" -O3 -o t -lgomp
-Wl,-rpath=/usr/local/lib64 

Typing this : export ACC_DEVICE_TYPE=

then executing ./t and these messages appear :

libgomp: Link error log ptxas fatal   : SM version specified by .target is
higher than default SM version assumed


libgomp: cuLinkAddData (ptx_code) error: no kernel image is available for
execution on the device

Moreover, ./t hangs.

It is expected as my video card supports at most sm_20 ptx code while sm_30
instructions are generated by gcc and even .target sm_30 is hardcoded at
gcc/config/nvptx/nvptx.c:3904 : fputs ("\t.target\tsm_30\n", asm_out_file);

From my point of view, as sm_30 ptx code only is generated,  int
nvptx_get_num_devices (void) (libgomp/plugin/plugin-nvptx.c:680) should be
aware of that and should not count such a video card.
As a result, gomp runtime would switch to host as it does when cuInit(0) !=
CUDA_SUCCESS.

[Bug middle-end/71645] New: [7 Regression] FAIL: libgomp.fortran/nestedfn5.f90 -O3 -g (internal compiler error)

[hjl.tools at gmail dot com]

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

Bug ID: 71645
   Summary: [7 Regression] FAIL: libgomp.fortran/nestedfn5.f90
-O3 -g  (internal compiler error)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

On x86, r237734 caused:

FAIL: libgomp.fortran/nestedfn5.f90   -O3 -g  (internal compiler error)
FAIL: libgomp.fortran/nestedfn5.f90   -O3 -g  (test for excess errors)

[Bug c++/71644] New: gcc 6.1 generates movaps for unaligned memory

[justus at gmx dot li]

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

Bug ID: 71644
   Summary: gcc 6.1 generates movaps for unaligned memory
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: justus at gmx dot li
  Target Milestone: ---

Created attachment 38757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38757&action=edit
code for reproduction

compiling the code below using gcc 6.1.0 (on a x86_64 linux machine) or a
current svn snapshot genereates the expected two versions of Derived::Derived.
the problem is that in both the complete object constructor and the base object
construct 'movaps' is used to write both Derived::m2 and Derived::m3 at once,
but if Derived is the base of TestBug then Derived::m2 is not 16byte aligned
anymore. this results in a segfault.

-- gcc command
g++  -save-temps -Wall -Wextra -std=c++14 -ggdb -O3 -o /tmp/testbug
/tmp/testbug.cc

-- code -- 
#include 
struct Base  {
alignas(16) int64_t mAligned=0;
};

struct Derived : public virtual Base {
public:
int64_t m1;
int64_t m2{ 1234 };
int64_t m3{ 2345 };

  __attribute__ ((noinline)) // or put ctor into different compilation unit
Derived(){}
};

struct TestBug : public virtual Derived {};


int main() {
Derived derived; // good
TestBug testbug; // crashes because of using movaps on unaligned memory
}

[Bug tree-optimization/71643] [7 Regression] internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2318 after r237427

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 38756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38756&action=edit
gcc7-pr71643.patch

Untested fix.

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
The change occurred between revisions r221423 (2015-03-13, OK) and r221977
(2015-04-10, segfault), may be r221621 (PRs 57456, 63230, and 64787).

[Bug middle-end/69526] ivopts candidate strangeness

[amker at gcc dot gnu.org]

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

--- Comment #23 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #19)
> (In reply to rguent...@suse.de from comment #18)
> 2.
> Is there an idiomatic/correct way to check a VR_RANGE for overflow? Does it
> suffice to check if the range includes +-INF or +-INF(OVF)? I suspect other,
> naive methods like checking if min < max will fail, since the ranges are
> canonicalized.

Hmm, not sure if I mis-understood your point.
I think there is no *overflow* concept for a VR_RANGE (or a variable), overflow
is always a semantic concept for an (arithmetic) operation.  Take below loop as
an example:

unsigned int i;
for (i = 4; i != 2; i += 2)
  {
//
  }

Variable i has VR_RANGE [0, MAX_VALUE - 1], but it does overflow in the loop.

[Bug tree-optimization/71643] [7 Regression] internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2318 after r237427

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.1.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-06-24
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |7.0
  Known to fail||7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug tree-optimization/71643] New: [7 Regression] internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2318 after r237427

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 71643
   Summary: [7 Regression] internal compiler error: in
redirect_eh_edge_1, at tree-eh.c:2318 after r237427
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jakub at redhat dot com
  Target Milestone: ---

Created attachment 38755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38755&action=edit
Reduced testcase

After r237427:

PR tree-optimization/71520
* tree-ssa-tail-merge.c (find_duplicate): Handle labels.
(replace_block_by): Move user labels from bb1 to bb2.

* gcc.dg/tree-ssa/pr71520.c: New test.

I'm seeing the following ICE for the attached reduced testcase when compiling
with -O3 on aarch64-none-linux-gnu/x86_64-unknown-linux-gnu:

x.cpp:30:1: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2318
 foo (void)
 ^~~
0xd2d737 redirect_eh_edge_1
.../gcc/tree-eh.c:2318
0xd2d8e7 redirect_eh_edge(edge_def*, basic_block_def*)
.../gcc/tree-eh.c:2370
0xd12d5e gimple_redirect_edge_and_branch
.../gcc/tree-cfg.c:5664
0x8d2976 redirect_edge_and_branch(edge_def*, basic_block_def*)
.../gcc/cfghooks.c:356
0xec9098 replace_block_by
.../gcc/tree-ssa-tail-merge.c:1538
0xec9098 apply_clusters
.../gcc/tree-ssa-tail-merge.c:1635
0xec9098 tail_merge_optimize(unsigned int)
.../gcc/tree-ssa-tail-merge.c:1743
0xe78871 execute
.../gcc/tree-ssa-pre.c:4826
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

[zed.three at gmail dot com]

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

--- Comment #3 from zed.three at gmail dot com ---
Changing the pointer to an allocatable array results in the same behaviour:

$ cat allocate_size_mvce.f90
program allocatemvce
  implicit none
  character(len=:), allocatable :: string
  integer, dimension(4), target :: array = [1,2,3,4]
  integer, dimension(:), allocatable :: array_alloc
  integer :: alloc_size

  allocate(array_alloc(size(array)))
  allocate(character(len=size(array_alloc))::string)

  ! The following works:
  ! alloc_size = size(array_alloc)
  ! allocate(character(len=alloc_size)::string)

end program allocatemvce

---

In both cases, using -fdump-tree-original to see the IR reveals the
uninitialised variable:

1) For gfortran-4.8, we have something like this:

D.1892 = &array_ptr;
D.1893 = (integer(kind=4)) MAX_EXPR <(D.1892->dim[0].ubound -
D.1892->dim[0].lbound) + 1, 0>;
...
D.1894 = (unsigned long) D.1893;
string = (character(kind=1)[1:.string] *) __builtin_malloc (MAX_EXPR
);

2) Whereas for gfortran-6, we get:

struct array1_integer(kind=4) * D.3395;
...
D.3396 = (unsigned long) (integer(kind=4)) MAX_EXPR
<(D.3395->dim[0].ubound - D.3395->dim[0].lbound) + 1, 0>;
string = (character(kind=1)[1:.string] *) __builtin_malloc (MAX_EXPR
);

   and D.3395 is never assigned to.

---

When using "product(shape)", as in Gerhard's example, examining the IR shows
that product(shape(array_ptr)) is never calculated in gfortran-6:

1) For gfortran-4.8, we can see:
_gfortran_shape_4 (&atmp.1, D.1893);
{
  integer(kind=8) S.3;

  S.3 = 0;
  while (1)
{
  if (S.3 > 0) goto L.1;
  val.0 = (*(integer(kind=4)[1] * restrict) atmp.1.data)[S.3] *
val.0;
  S.3 = S.3 + 1;
}
  L.1:;
}
   which is clearly calculating product(shape(array_ptr))

2) For gfortran-6, nothing like that appears at all, and __builtin_malloc is
called with val.0 uninitialised.

---

Replacing "size(array_ptr)" in the original example with "mysize(array_ptr)",
which is defined as

  integer function mysize(ptr)
integer, dimension(:), pointer :: ptr
mysize = size(ptr)
  end function mysize

This results in the correct behaviour. In the IR for 6, we essentially get

  string = (character(kind=1)[1:.string] *) __builtin_malloc (MAX_EXPR
<(unsigned long) mysize (&array_ptr), 1>);

---

Finally, if we replace "size(array_ptr)" with "size(array)", the IR is

  string = (character(kind=1)[1:.string] *) __builtin_malloc (4);

and no intermediate variables are generated (i.e. it directly uses the value of
size(array)).

---

My best guess then is that in gfortran > 5 calls to intrinsics are being elided
in allocating deferred-len characters. That's just a guess though. I'm
currently trying to get my bearings in the gfortran source code to understand
what's going on.

[Bug c++/71638] [6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu with -Wall (internal compiler error: non-constant element in constant CONSTRUCTOR)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-24
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|ICE on invalid C++ code on  |[6/7 Regression] ICE on
   |x86_64-linux-gnu with -Wall |invalid C++ code on
   |(internal compiler error:   |x86_64-linux-gnu with -Wall
   |non-constant element in |(internal compiler error:
   |constant CONSTRUCTOR)   |non-constant element in
   ||constant CONSTRUCTOR)
 Ever confirmed|0   |1

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

[Bug debug/71642] [7 Regression] ICE: in gen_type_die_with_usage, at dwarf2out.c:22729

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug debug/71642] [7 Regression] ICE: in gen_type_die_with_usage, at dwarf2out.c:22729

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-24
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
I can reproduce.

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[renlin at gcc dot gnu.org]

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

--- Comment #9 from Renlin Li  ---
(In reply to nsz from comment #8)
> (In reply to Jakub Jelinek from comment #6)
> > (In reply to Marc Glisse from comment #1)
> > > Or we could do like clang and improve alias analysis. We should know that
> > > array doesn't escape and thus that hallo() cannot write to it.
> > 
> > The strlen pass uses the alias oracle, so the question is why it thinks the
> > call might affect the array.
> 
> the optimization fails with
> 
>  const char array[] = "abc";
> 
> too (which is why i thought it was about pure strlen depending on global
> state
> other than the argument.. static const array works though).

char *array = "abc";

works, however, this generates string literals in read-only section.

[Bug middle-end/71625] missing strlen optimization on different array initialization style

[nsz at gcc dot gnu.org]

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

--- Comment #8 from nsz at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Marc Glisse from comment #1)
> > Or we could do like clang and improve alias analysis. We should know that
> > array doesn't escape and thus that hallo() cannot write to it.
> 
> The strlen pass uses the alias oracle, so the question is why it thinks the
> call might affect the array.

the optimization fails with

 const char array[] = "abc";

too (which is why i thought it was about pure strlen depending on global state
other than the argument.. static const array works though).

[Bug c++/71630] ICE on valid C++14 code with variable templates: in get, at cgraph.h:395

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-24
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
There's another test-case:

template 
extern T pi;

int main()
{
  return pi;
}

where we ICE on the following VAR_DECL:

(gdb) p debug_tree(decl)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x768857e0 precision
32 min  max 
pointer_to_this >
used public tree_1 decl_1 decl_2 SI file /tmp/t.c line 2 col 10 size
 unit size 
align 32 context 
template-info 0x769df980>

I guess the problem is that the declaration does not have DECL_EXTERNAL flag
set.

When I tried to link the code snippet (by clang++) with another one, where the
symbol is defined,
it worked fine.

My code snippet is problem also in GCC 5.3.1 and GCC 6.1.1 with the following
back trace:
/tmp/t.c: In function ‘int main()’:
/tmp/t.c:6:10: internal compiler error: in ctor_for_folding, at varpool.c:419
   return pi;
  ^~~
0xd17330 ctor_for_folding(tree_node*)
../../gcc/varpool.c:419
0x8e6c78 get_symbol_constant_value(tree_node*)
../../gcc/gimple-fold.c:228
0x8ef7be fold_gimple_assign
../../gcc/gimple-fold.c:396
0x8ef7be fold_stmt_1
../../gcc/gimple-fold.c:3710
0x905efa gimplify_modify_expr
../../gcc/gimplify.c:4869
0x8ffb7d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:10287
0x901be6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:5688
0x8ff115 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:425
0x8ff115 gimplify_return_expr
../../gcc/gimplify.c:1359
0x8ff115 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:10536
0x901be6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:5688
0x8ff7f3 gimplify_statement_list
../../gcc/gimplify.c:1537
0x8ff7f3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:10704
0x901be6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:5688
0x909e8c gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:11433
0x90a247 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:11589
0x7e20e7 cgraph_node::analyze()
../../gcc/cgraphunit.c:625
0x7e48af analyze_functions
../../gcc/cgraphunit.c:1086
0x7e515c symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2542

[Bug libstdc++/71640] [7 Regression] include/c++/7.0.0/bits/hashtable.h:293:7: error: too many template parameters in template redeclaration

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
One could also argue that this is an accept invalid issue:

markus@x4 tmp % cat llvm.ii
template  struct integral_constant {
  static constexpr _Tp value = 0;
};
template  using __bool_constant = integral_constant;
struct A : integral_constant {};
template  class, template  class>
using __detected_or_t_ = struct __undefined;
template  using __replace_first_arg_t = __undefined;
struct B {
  template  using __rebind = typename _Alloc::other;
};
template 
using __alloc_rebind = __detected_or_t_<__replace_first_arg_t, B::__rebind>;
namespace __detail {
template  struct _Hashtable_traits {
  using __hash_cached = __bool_constant<0>;
};
template  struct _Hash_node;
struct _Prime_rehash_policy;
template  struct C;
template  struct _Rehash_base {};
}
template  using __cache_default = A;
template 
struct _Hashtable
: __detail::_Rehash_base<
  __detail::_Prime_rehash_policy,
  __alloc_rebind::__hash_cached::value>>> {
  template  friend struct __detail::C;
};
template  using __uset_traits = __detail::_Hashtable_traits<0, 0, 0>;
template ::value>>
using __uset_hashtable = _Hashtable<_Tr>;
__uset_hashtable value_type;


markus@x4 tmp % icpc -c -std=c++14 llvm.ii
llvm.ii(31): warning #549: too many template parameters -- does not match
previous declaration (declared at line 20)
template  friend struct __detail::C;
  ^

markus@x4 tmp % clang++ -c -std=c++14 llvm.ii
llvm.ii:31:3: error: too many template parameters in template redeclaration
  template  friend struct __detail::C;
  ^~~
llvm.ii:37:23: note: in instantiation of template class
'_Hashtable<__detail::_Hashtable_traits<0, 0, 0> >' requested here
__uset_hashtable value_type;
  ^
llvm.ii:20:1: note: previous template declaration is here
template  struct C;
^~
1 error generated.
markus@x4 tmp % g++ -Wall -Wextra -c -std=c++14 llvm.ii
markus@x4 tmp %

[Bug debug/71642] New: [7 Regression] ICE: in gen_type_die_with_usage, at dwarf2out.c:22729

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 71642
   Summary: [7 Regression] ICE:  in gen_type_die_with_usage, at
dwarf2out.c:22729
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

overnight trunk regression:

> cat bug.f90
MODULE gauss_colloc
  INTEGER, PARAMETER :: dp=8
CONTAINS
SUBROUTINE collocGauss(h,h_inv,grid,poly,alphai,posi,max_r2,&
periodic,gdim,local_bounds,local_shift,poly_shift,scale,lgrid,error)
REAL(dp), DIMENSION(0:, 0:, 0:), &
  INTENT(inout)  :: grid
INTEGER, INTENT(inout), OPTIONAL :: lgrid
CONTAINS
SUBROUTINE kloop6
IF (kJump/=1 .AND. (ikstart+kmax-kstart>=ndim(2)+l_shift(2) .OR.&
ikstart2+kmin-kstart2<=l_ub(2)-ndim(2))) THEN
DO
DO k=kstart2,kend2,-1
IF ( PRESENT ( lgrid ) ) THEN
  grid(ik,ij,ii) = grid(ik,ij,ii) + p_v*res_k
END IF
END DO
END DO
END IF
END SUBROUTINE
END SUBROUTINE
END MODULE gauss_colloc

> gfortran -c -g bug.f90
bug.f90:21:0:

 END SUBROUTINE

internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:22729
0x826d80 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:22729
0x825fa5 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:22811
0x827246 gen_type_die
../../gcc/gcc/dwarf2out.c:22907
0x820c1b gen_decl_die
../../gcc/gcc/dwarf2out.c:23522
0x82239c process_scope_var
../../gcc/gcc/dwarf2out.c:23029
0x822607 decls_for_scope
../../gcc/gcc/dwarf2out.c:23054
0x823177 gen_subprogram_die
../../gcc/gcc/dwarf2out.c:20773
0x820e5c gen_decl_die
../../gcc/gcc/dwarf2out.c:23476
0x821bce dwarf2out_decl
../../gcc/gcc/dwarf2out.c:23959
0x821f69 dwarf2out_early_global_decl
../../gcc/gcc/dwarf2out.c:23632
0x7b0bd8 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2557
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


> gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data/vjoost/gnu/gcc_trunk/install/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160624 (experimental) [trunk revision 237753] (GCC)

[Bug middle-end/69526] ivopts candidate strangeness

[amker at gcc dot gnu.org]

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

--- Comment #22 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #21)
> (In reply to amker from comment #20)
> > IIUC we can simply handle signed/unsigned type differently.  Given a has
> > int/uint type. 
> > For unsigned case: (unsigned long long)(a + cst1) + cst2  and a is unsigned
> > int.
> > It can be simplified into (unsigned long long)a + cst3 iff a + cst1 doesn't
> > overflow/wrap.  Since unsigned type can wrap, simplify (unsigned long
> > long)cst1 + cst2 into cst3 is always safe.
> > For signed case: (long long)(a + cst) + cst2  and a is signed int.
> > It can be simplified into (long long)a + cst3 iff (long long)cst1 + cst2
> > doesn't overflow.  We don't need to prove (a+cst) doesn't overflow.
> 
> ok, the stipulation seems to be assume no signed overflow if the operation
> was already present but don't provoke a potentially new overflow by
> combining constants that previously would not have been. Makes sense. Your
> cases can be improved a little as Richard also pointed out: When abs(cst3) <
> abs(cst1) the combined operation can be done in the inner type (and the
> signs match so the overflow proof still holds).

Hmm, combine (long long)cst1 + cst2 is compilation time work, as long as it
doesn't overflow.  It doesn't matter in which type the combination is done? 
Oh, do you mean simplify the original expression into (long long)(a + cst3)?

[Bug libstdc++/71641] New: 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking

[cctsai57 at gmail dot com]

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

Bug ID: 71641
   Summary: 22_locale/time_get/get_date/wchar_t/4.cc runs failure
if static linking
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cctsai57 at gmail dot com
  Target Milestone: ---

Hi,

  I try to simplify the testcase as the following code:
~~
#include 
#include 
#include 

int main()
{
  std::istringstream iss{ "17.12.2003" };
  iss.imbue( std::locale{ "de_DE.UTF-8" } );
  auto& time_get_facet = std::use_facet>( iss.getloc() );

  using iterator_type = std::istreambuf_iterator;
  iterator_type begin{ iss };
  iterator_type end;
  auto err = std::ios_base::goodbit;
  std::tm t{};
  time_get_facet.get_date( begin, end, iss, err, &t );

  // 12/17/2003
  if ( err != std::ios_base::eofbit ||
   t.tm_mon != 11 ||
   t.tm_mday != 17 ||
   t.tm_year != 103)
__builtin_abort();
}
~~

The default compiler is dyanmic linking and it runs PASS, but
FAIL if static linking:

$ g++ -std=gnu++11 -static test.cc
$ a.out
Abort!

My Fedora host has de_DE.UTF-8 locale date:
$ LC_ALL=de_DE.UTF-8 locale -k -c d_fmt  
LC_TIME
d_fmt="%d.%m.%Y"

The following versions of gcc and glibc have the same problem:
(1) g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
glibc 2.21
Fedora: Linux 4.4.13-200.fc22.x86_64
(2) g++ (GCC) 6.1.1 20160621
glibc 2.21
(3) arm-linux-gnueabihf-g++ (GCC) 6.1.1 20160623
glibc 2.23

[Bug libstdc++/71640] New: [7 Regression] include/c++/7.0.0/bits/hashtable.h:293:7: error: too many template parameters in template redeclaration

[trippels at gcc dot gnu.org]

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

Bug ID: 71640
   Summary: [7 Regression]
include/c++/7.0.0/bits/hashtable.h:293:7: error: too
many template parameters in template redeclaration
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: fdumont at gcc dot gnu.org
  Target Milestone: ---

clang complains:

In file included from /home/trippels/llvm/tools/llvm-config/llvm-config.cpp:32:
In file included from
/home/trippels/gcc_test/usr/local/include/c++/7.0.0/unordered_set:47:
/home/trippels/gcc_test/usr/local/include/c++/7.0.0/bits/hashtable.h:293:7:
error: too many template parameters in template redeclaration
  template,
  std::__cxx11::basic_string,
std::allocator >, std::__detail::_Identity,
std::equal_to >,
  std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >' requested here
  _Hashtable _M_h;
 ^
/home/trippels/llvm/tools/llvm-config/llvm-config.cpp:613:39: note: in
instantiation of template class
'std::unordered_set, std::hash,
  std::equal_to >,
std::allocator > >' requested here
  std::unordered_set FullDyLibComponents;
  ^
/home/trippels/gcc_test/usr/local/include/c++/7.0.0/bits/hashtable_policy.h:905:3:
note: previous template declaration is here
  template   
 910 struct _Insert;   

hashtable.h 
 293   template  
 298 friend struct __detail::_Insert;  

Started with r236669.