[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On November 14, 2015 12:09:28 AM GMT+01:00, "hjl.tools at gmail dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
>
>--- Comment #14 from H.J. Lu  ---
>(In reply to Richard Biener from comment #13)
>> 
>> Can you check whether disabling PRE fixes the runtime failure?
>> 
>
>-O1: OK.
>-O1 -finline-small-functions: Bad.
>-O1 -fno-tree-fre -finline-small-functions: Bad.

So maybe bisect with the no-fre case then.

[Bug rtl-optimization/68185] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Things start to go awry in the get_defs called at the end of
make_defs_and_copies_lists for conditional move in ree.c. ree correctly detect
that insn 308 is a conditional move and do the transitive closure on it in
search for its definition. It finds insn 304 as the definition for register di
but then screw up by finding insn 308 itself as the definition for bp in insn
308.

This all happens in get_defs that uses df information. For insn 308, there is
only one link in the use-def chain for the dp use and the ref for that link
points to insn 308.

I'm not sure if it's a failure of df to link the use to the def being done in
the same instruction or if it's ree failing to detect this. If the latter, I
guess the fix would be to ignore a def to the same instruction and return an
error if there is only that def (so add a counter in the last loop).

[Bug target/66785] internal compiler error in record_operand_use

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
Created attachment 36705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36705&action=edit
untested patch that may be wasting memory

[Bug target/66785] internal compiler error in record_operand_use

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson  ---
The operand_rr_info struct has arrays sized by MAX_REGS_PER_ADDRESS.

regrename is calling record_operand_use for a write to an operand.  It is also
calling record_operand_use when a use (read or write) overlaps an earlier
write.  Hence a mem operand using an address with N regs can overlap N previous
writes explaining the use of MAX_REGS_PER_ADDRESS. 

However, we can also have an operand that is N-regs wide that can overlap N
previous 1-reg wide writes.  Thus, we need to be able to handle the number of
regs in the widest possible mode also.  If we can have multiword regs used
inside an address, things get even more complicated, but that isn't an issue at
the moment.

So instead of using just MAX_REGS_PER_ADDRESS, we need here something like
#define OPERAND_RR_INFO_ARRAY_SIZE\
  MAX (MAX_REGS_PER_ADDRESS,  \
   (MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT) / MIN_UNITS_PER_WORD)

Unfortunately, this increases the array size from 2 to 16 for aarch64, as the
widest mode is CXImode which takes 16 registers.  This change may be wasting
too much memory to be useful.  This only affects the ports that have their own
target dependent regrename pass though, which is only c6x and aarch64 at the
moment.

I suspect that we only need an array size of 4 for arm, as the widest
instructions operate on 4 registers at a time, but I don't see an obvious way
to get that info without adding another macro.

I don't see any obvious uses of the chains member in operand_rr_info.  The c6x
and aarch64 ports are only using the heads member.  So we could partially
offset the memory size increase by dropping the chains member.

Or maybe we can modify mode creation to avoid getting the CXI mode, as we don't
need it.  It is created automatically because we define XI as an 8-wide integer
mode.  Without CXImode the widest modes are only 8 registers wide.  Combined
with the removal of the chains member we are only doubling the size of this
structure.

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to Sebastian Pop from comment #5)
> You need ISL 0.15 to have these tests pass.
> Could you please report which ISL version you configured gcc with?

isl-0.14

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #5 from Sebastian Pop  ---
You need ISL 0.15 to have these tests pass.
Could you please report which ISL version you configured gcc with?
I will try to get a check in the graphite.exp to only select fuse-* files when
configured with ISL 0.15 or later.

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Richard Biener from comment #13)
> 
> Can you check whether disabling PRE fixes the runtime failure?
> 

-O1: OK.
-O1 -finline-small-functions: Bad.
-O1 -fno-tree-fre -finline-small-functions: Bad.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[e.menezes at samsung dot com]

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

--- Comment #37 from Evandro  ---
Here's what I had in mind:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01787.html

Feedback is welcome.

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> Hmm, before r230190 (add testsuite automatic dg-options and dg-do action for
> isl-ast-gen-* and fuse-* files) I have one FAIL, but two UNRESOLVED:
> ...
> UNRESOLVED: gcc.dg/graphite/fuse-1.c scan-tree-dump-times graphite "ISL AST
> generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
> {.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
> UNRESOLVED: gcc.dg/graphite/fuse-2.c scan-tree-dump-times graphite "ISL AST
> generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
> {.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
> ...

And these UNRESOLVEDs seems to have been present since the tests were added.

[Bug c/68344] New: No warning for old-style function declarations.

[i.hamsa at gmail dot com]

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

Bug ID: 68344
   Summary: No warning for old-style function declarations.
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.hamsa at gmail dot com
  Target Milestone: ---

The following minimal test case

int a();

generates no warning when -Wold-style-declaration -std=c11 is specified.

It is expected that a warning should be produced.

The manual at https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says:

-Wold-style-declaration
Warn for obsolescent usages, according to the C Standard, in a declaration

The C11 draft standard says:
6.11.6 Function declarators
The use of function declarators with empty parentheses (not prototype-
format parameter type declarators) is an obsolescent feature.

===
Information about the compiler:

* output of gcc -v
Using built-in specs.
COLLECT_GCC=gcc-5.2.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.2.0/work/gcc-5.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.2.0 p1.0, pie-0.6.3' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts
--enable-lto --without-isl --enable-libsanitizer
Thread model: posix
gcc version 5.2.0 (Gentoo 5.2.0 p1.0, pie-0.6.3)

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Hmm, before r230190 (add testsuite automatic dg-options and dg-do action for
isl-ast-gen-* and fuse-* files) I have one FAIL, but two UNRESOLVED:
...
PASS: gcc.dg/graphite/fuse-1.c (test for excess errors)
PASS: gcc.dg/graphite/fuse-1.c execution test
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times forwprop4
"gimple_simplified to[^\\n]*\\^ 12" 1
UNRESOLVED: gcc.dg/graphite/fuse-1.c scan-tree-dump-times graphite "ISL AST
generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
{.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
PASS: gcc.dg/graphite/fuse-2.c (test for excess errors)
PASS: gcc.dg/graphite/fuse-2.c execution test
UNRESOLVED: gcc.dg/graphite/fuse-2.c scan-tree-dump-times graphite "ISL AST
generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
{.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
...

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Nov 13 21:28:10 2015
New Revision: 230352

URL: https://gcc.gnu.org/viewcvs?rev=230352&root=gcc&view=rev
Log:
2015-11-13  Steven G. Kargl  

PR fortran/68319
* decl.c (gfc_match_data, gfc_match_entry): Enforce F2008:C1206.
* io.c (gfc_match_format): Ditto.
* match.c (gfc_match_st_function): Ditto.

2015-11-13  Steven G. Kargl  

PR fortran/68319
* gfortran.dg/pr68319.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68319.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/fortran/io.c
branches/gcc-5-branch/gcc/fortran/match.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
This failure is introduced here:
https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00186.html :
...
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times forwprop4
"gimple_simplified to[^\\n]*\\^ 12" 1
...

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 Ever confirmed|0   |1

--- Comment #1 from vries at gcc dot gnu.org ---
confirmed: https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00399.html

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Nov 13 21:11:42 2015
New Revision: 230351

URL: https://gcc.gnu.org/viewcvs?rev=230351&root=gcc&view=rev
Log:
2015-11-13  Steven G. Kargl  

PR fortran/68319
* decl.c (gfc_match_data, gfc_match_entry): Enforce F2008:C1206.
* io.c (gfc_match_format): Ditto.
* match.c (gfc_match_st_function): Ditto.

2015-11-13  Steven G. Kargl  

PR fortran/68319
* gfortran.dg/pr68319.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68319.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68343] New: FAIL: gcc.dg/graphite/fuse-{1,2}.c scan

[vries at gcc dot gnu.org]

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

Bug ID: 68343
   Summary: FAIL: gcc.dg/graphite/fuse-{1,2}.c scan
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Fails with revision r230329 (on x86_64):
...
FAIL: gcc.dg/graphite/fuse-2.c scan-tree-dump-times graphite "ISL AST generated
by ISL:.*for \\(int c0 = 0; c0 <= 99; c0 \\+= 1\\)
{.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*}" 1
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times graphite "ISL AST generated
by ISL:.*for \\(int c0 = 0; c0 <= 99; c0 \\+= 1\\)
{.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*}" 1
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times forwprop4
"gimple_simplified to[^\\n]*\\^ 12" 1
...

[Bug tree-optimization/68341] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 CC||spop at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from vries at gcc dot gnu.org ---
At https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00399.html, we find
confirmation.

Caused by:
...
commit 30162daabfa9ba2702a361c7837be3773e353fe4
Author: spop 
Date:   Thu Nov 12 00:37:47 2015 +

Preserve the original program while using graphite.



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

[Bug fortran/67803] ICE on concatenating wrong character array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I have an ugly patch for this one.

[Bug c++/68342] New: Unexpected expansion pattern contains no argument packs error

[pkeir at outlook dot com]

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

Bug ID: 68342
   Summary: Unexpected expansion pattern contains no argument
packs error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

Created attachment 36704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36704&action=edit
The code which produces the unexpected error

The C++11 code below unexpectedly fails to compile on 64-bit Ubuntu 15.04 using
g++ (GCC) 6.0.0 20151110 (experimental) with the following message:

nullary.cpp:12:27: error: expansion pattern ‘g(xs#0)’ contains no argument
packs
   using r_t  = decltype(mt(g(x),g(xs)...))

It compiles with Clang 3.8.0.

struct vec { int x; };

template 
int g(T y) { return y.x; }

template 
int mt(Ts ...xs){ return 0; }

template 
void quack(T x, Ts ...xs)
{
  using r_t  = decltype(mt(g(x),g(xs)...));
  auto f = []() { return r_t{}; };
}

int main(int argc, char *argv[])
{
  quack(vec{0},vec{0},vec{0});
  return 0;
}

[Bug tree-optimization/68341] New: FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[vries at gcc dot gnu.org]

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

Bug ID: 68341
   Summary: FAIL: gcc.dg/graphite/interchange-{1,11,13}.c
(internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Fails with revision r230329 (testing x86_64 non-bootstrap build):
...
FAIL: gcc.dg/graphite/interchange-1.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-1.c (test for excess errors)
FAIL: gcc.dg/graphite/interchange-11.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-11.c (test for excess errors)
FAIL: gcc.dg/graphite/interchange-13.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-13.c (test for excess errors)
...

ICE in more detail:
...
src/gcc/testsuite/gcc.dg/graphite/interchange-1.c:13:1: internal compiler
error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:701
0x10949ce check_loop_closed_ssa_use
src/gcc/tree-ssa-loop-manip.c:701
0x1094b3c verify_loop_closed_ssa(bool)
src/gcc/tree-ssa-loop-manip.c:745
0x1ced442 checking_verify_loop_closed_ssa
src/gcc/tree-ssa-loop-manip.h:35
0x1ced4f4 graphite_verify
src/gcc/graphite-isl-ast-to-gimple.c:107
0x1cef88d graphite_regenerate_ast_isl(scop*)
src/gcc/graphite-isl-ast-to-gimple.c:1216
0x1cecc3f graphite_transform_loops()
src/gcc/graphite.c:343
0x1ceccce graphite_transforms
src/gcc/graphite.c:371
0x1cecdf5 execute
src/gcc/graphite.c:448
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/68237] ICE on invalid with submodules

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> > This slightly changed test case should demonstrate the problem:
> 
> Confirmed, the backtrace is
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0001000288c7 in gfc_match_submod_proc () at
> ../../work/gcc/fortran/decl.c:7649
> 7649if (sym->ts.interface->attr.function)
> (gdb) bt
> #0  0x0001000288c7 in gfc_match_submod_proc () at
> ../../work/gcc/fortran/decl.c:7649
> #1  0x000100082e8d in decode_statement () at
> ../../work/gcc/fortran/parse.c:384
> #2  0x000100084bc5 in next_statement () at
> ../../work/gcc/fortran/parse.c:1075
> #3  0x00010008b0f4 in parse_contained (module=) at
> ../../work/gcc/fortran/parse.c:4990
> #4  0x00010008c1df in parse_module () at
> ../../work/gcc/fortran/parse.c:5390
> #5  0x00010008cc43 in gfc_parse_file () at
> ../../work/gcc/fortran/parse.c:5696
> #6  0x0001000d39db in gfc_be_parse_file () at
> ../../work/gcc/fortran/f95-lang.c:205
> #7  0x000100aec62a in compile_file () at ../../work/gcc/toplev.c:466
> #8  0x000100fc173c in ?? ()
> #9  0x000100fc30f9 in main (argc=2, argv=0x7fff5fbff308) at
> ../../work/gcc/main.c:39

This patch

Index: decl.c
===
--- decl.c  (revision 230336)
+++ decl.c  (working copy)
@@ -7650,7 +7666,7 @@ gfc_match_submod_proc (void)

   /* Make sure that the result field is appropriately filled, even though
  the result symbol will be replaced later on.  */
-  if (sym->ts.interface->attr.function)
+  if (sym->ts.interface && sym->ts.interface->attr.function)
 {
   if (sym->ts.interface->result
  && sym->ts.interface->result != sym->ts.interface)

yields

troutmask:sgk[215] gfc6 -c k1.f90
k1.f90:14:19:

module procedure foo
   1

Error: MODULE PROCEDURE at (1) must be in a generic module interface
k1.f90:15:6:

end procedure
  1

Error: Expecting END SUBMODULE statement at (1)

Have no idea if it is correct.  pault?

[Bug rtl-optimization/68340] New: Inner-nested constant-bounded loop not recognized as constant-bounded during loop unrolling

[kelvin at gcc dot gnu.org]

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

Bug ID: 68340
   Summary: Inner-nested constant-bounded loop not recognized as
constant-bounded during loop unrolling
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

As currently implemented, only inner-most loops are unrolled by the loop
unrolling code found in loop-unroll.c.

If a constant-bounded loop is nested within another loop, processing of the
outer loop results in induction variable optimization of the inner loop before
the inner loop is seen by the loop unroller.  After the original code is
replaced with induction variables, the inner loop is no longer recognized by
the loop unrolling code as constant bounded.

Consider, for example, this simple program:

void foo(double *d, unsigned long int n) {
  unsigned long int i, j;

  for (i = 0; i < n; i++) {
for (j = 0; j < 1002; j++) {
  d[j * 2] = 0.0;
}
  }
}

Compile this code with:
  gcc -S -O3 -fno-tree-vectorize -funroll-loops --param max-unroll-times=4
-fdump-rtl-loop2_unroll file.c

Following induction-variable replacements, the transformed inner loop is
restructured to resemble the following:

void *array_end = (void *) &d[1002 * 2];
double *ivtmp_9 = d;
while (ivtmp_9 < (double *) array_end) {
  *ivtmp_9 = 0.0;
  ivtmp_9 += 2;
}

This can be seen in the trace output reported by the loop2_unroll file. 
Following the first heading "starting region dump", the rtl instructions
associated with "bb 4" (basic block 4) holds the contents of the loop body,
which matches the C pseudo-code shown immediately above.  Subsequent messages
within this same file report:

;; Considering unrolling loop with constant number of iterations
;; Unable to prove that the loop iterates constant times

If the same inner loop is compiled in an outer-most context, you will not see
the error message about "unable to prove that the loop iterates constant times"
and consequently, the result of loop unrolling will be very different.

[Bug middle-end/68339] New: g++.dg/vect/simd-clone-2.cc ICEs with aggressive GC settings and OpenMP

[jason at gcc dot gnu.org]

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

Bug ID: 68339
   Summary: g++.dg/vect/simd-clone-2.cc ICEs with aggressive GC
settings and OpenMP
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Compiling g++.dg/vect/simd-clone-2.cc with

  --param ggc-min-heapsize=0 --param ggc-min-expand=0 -fopenmp-simd

results in a memory corruption ICE.  This seems to be because
expand_simd_clones calls simd_clone_mangle, which generates an identifier, and
then calls simd_clone_create, which eventually calls ggc_collect from
execute_one_ipa_transform_pass.

Since nothing refers to the identifier yet, it gets collected as garbage, so
when expand_simd_clones tries to use it the compiler blows up.

[Bug c++/63517] bogus Wreturn-type warning after error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Gcc 5.1 and current trunk (6.0) print just the first error message and not the
-Wreturn-type warning.  Resolving as fixed.

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #3 from Dmitry Vyukov  ---
As far as I remember there was a real bug in gcc that it emitted non-atomic
load for static var initialization fast-path (think broken double-checked
locking). This bug should be fixed by now. So if it works with tip gcc, I
propose to close this.

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

[dushistov at mail dot ru]

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

--- Comment #2 from Evgeniy Dushistov  ---
The problem as I understand assembler in check
that find out is static variable initialized,

clang emit this:

callq  45bdb0 <__tsan_atomic8_load>

while gcc emit 

callq  401260 <__tsan_read1@plt>

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
See also bug 68336, which may be a possible duplicate of this one.

[Bug middle-end/68336] False positive Wreturn-type warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  An even simpler test case is below.  See also bug 67629.

$ cat z.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S -Wall
-o/dev/null z.c
int f (void)
{
for (int i = 1; i; )
return 1;
}
z.c: In function ‘f’:
z.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

G++ also warns on the trivial:

int f (void)
{
if (bool b = true)
return 1;
}

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |5.2.0

--- Comment #1 from Jonathan Wakely  ---
I can reproduce this with 5.2 but not trunk.

I suspect it's a false positive and libtsan on trunk has been taught to ignore
it.

[Bug libstdc++/58393] Please relax feature check for std::to_string and std::sto* for uClibc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Should be fixed on trunk now.

[Bug libstdc++/61580] stoi function unknown on W7/Cygwin/x86_64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Should be fixed on trunk now.

[Bug sanitizer/68338] New: tsan report error about c++11 static local initialize

[dushistov at mail dot ru]

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

Bug ID: 68338
   Summary: tsan report error about c++11 static local initialize
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

With code like this:

#include 
#include 
#include 

std::string message()
{
static std::string msg("hi");
return msg;
}

int main()
{
std::thread t1([]() { std::cout << message() << "\n"; });
std::thread t2([]() { std::cout << message() << "\n"; });

t1.join();
t2.join();
}

compile like this:
g++ -O3 -g3 -fsanitize=thread -Wall -std=c++11 -pthread -Wextra test.cpp

according to c++11 statnadard such code should be thread safe,

at the same time if replate g++(gcc 5.2) by clang++(clang 3.7)
it does run without any reported failures.

[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #2)
> Hrm, I don't think your analysis is entirely correct yet -- you say
> with the old compiler insn 19 is removed, but that sets reg 73 which
> is still used in insn 20.

For some reason, the transformation slightly mixes insn numbers:

(note 18 15 19 2 NOTE_INSN_DELETED)
(insn 19 18 20 2 (set (reg/v:DI 73 [ x ])
(xor:DI (reg/v:DI 71 [ x ])
(reg:DI 72 [ _4 ]))) pr42269.c:9 58 {xordi3}
 (expr_list:REG_DEAD (reg/v:DI 71 [ x ])
(expr_list:REG_DEAD (reg:DI 72 [ _4 ])
(nil
(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) pr42269.c:10 48
{zero_extendsidi2}
 (nil))

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
Creating a forwarder outside the path doesn't help since you still have to have
an edge to the forwarder from each copy of the block with the SWITCH_EXPR. 

The solution is to realize that a path containing a SWITCH_EXPR that does not
have a compile-time determinable destination probably isn't worth optimizing to
start with!  Essentially we're duplicating a block with 1k outgoing edges to
eliminate a single conditional later in the path.  From a cost/benefit analysis
that's just silly.

As I mentioned, this kind of situation was possible with the old threader too,
it was just too dumb to discover the path.

[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Hrm, I don't think your analysis is entirely correct yet -- you say
with the old compiler insn 19 is removed, but that sets reg 73 which
is still used in insn 20.

Anyway, mine, I'll figure it out.

[Bug tree-optimization/68060] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r228811.

[Bug c/68337] New: [MPX] memcpy() for arrays with function pointers results in huge resource usage and binaries

[jussi.judin at ericsson dot com]

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

Bug ID: 68337
   Summary: [MPX] memcpy() for arrays with function pointers
results in huge resource usage and binaries
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jussi.judin at ericsson dot com
  Target Milestone: ---

Created attachment 36703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36703&action=edit
Preprocessed source file including string.h

If I compile following program with GCC 5.2.0 with following options, it takes
around 7.6 seconds to compile and uses over 500 megabytes of memory (Maximum
resident set size):

$ gcc -save-temps -fcheck-pointer-bounds -mmpx -o mpx-funcptr-explosion -c
mpx-funcptr-explosion.c

#include 

#define ARRAY_SIZE 8192

typedef int (* funcptr_t) (void);

typedef struct {
int data;
funcptr_t callback1;
funcptr_t callback2;
funcptr_t callback3;
funcptr_t callback4;
} funcptr_struct_t;

funcptr_struct_t source[ARRAY_SIZE];

void memcpy_user(void) {
funcptr_struct_t target[ARRAY_SIZE];
memcpy(target, source, sizeof(source));
}

The resulting binary takes 4197096 bytes and assembly file 8117029 bytes. Every
funcptr_t instance I add to the structure adds around 2.6 seconds to execution
time of the compilation. This basically makes it impossible to use static
memory with callback functions with MPX support, as it explodes the compilation
resources and the resulting binary.

GCC has following specifications:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/local/ejusjud/intel-mpx/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure --enable-libmpx
--with-as=/home/ejusjud/local/intel-mpx/bin/as
--with-ld=/home/ejusjud/local/intel-mpx/bin/ld
--prefix=/home/ejusjud/local/intel-mpx
Thread model: posix
gcc version 5.2.0 (GCC)

[Bug fortran/68319] ICE on using interface with included entry

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Fri, Nov 13, 2015 at 04:08:05PM +, sgk at troutmask dot
apl.washington.edu wrote:
> --- Comment #6 from Steve Kargl  ---
> On Fri, Nov 13, 2015 at 12:42:16AM +, kargl at gcc dot gnu.org wrote:
> >
> > It seems that gfortran is missing a check for ENTRY.  F2008 has
> > 
> > C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt,
> > entry-stmt, or stmt-function-stmt.
> > 
> 
> I have a patch for stmt-function-stmt and entry.
> data-stmt and format-stmt will follow shortly.
> 

I now have data-stmt and format-stmt covered.  Patch to be submitted
later today.

[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #0)
> Revision r230164 [1] regressed:
> 
> FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl
> 
> on alpha-linux-gnu.
> 
> The difference starts in combine, where before the patch, we were able
> to combine insns:

Please scrap this, the correct analysis is below.

We start with following sequence:

(insn 19 18 20 2 (set (reg/v:DI 73 [ x ])
(sign_extend:DI (subreg:SI (reg:DI 90) 0))) pr42269.c:9 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg:DI 90)
(nil)))
(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) pr42269.c:10 48
{zero_extendsidi2}
 (nil))

where before the referred patch, combine pass removes (insn 19), leaving only:

(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) pr42269.c:10 48
{zero_extendsidi2}
 (nil))
(note 21 20 22 2 NOTE_INSN_DELETED)

With the patched gcc, we still have:

(insn 19 18 20 2 (set (reg/v:DI 73 [ x ])
(sign_extend:DI (subreg:SI (reg:DI 90) 0))) pr42269-fail.c:9 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg:DI 90)
(nil)))
(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0)))
pr42269-fail.c:10 48 {zero_extendsidi2}
 (nil))

Please note that (insn 19) above is redundant.

BTW: I wonder if combine pass is the correct place to perform this optimization
(please see PR 42269), we have ree pass that should remove redundant
extensions.

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Working on this.

[Bug fortran/68319] ICE on using interface with included entry

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Fri, Nov 13, 2015 at 12:42:16AM +, kargl at gcc dot gnu.org wrote:
>
> It seems that gfortran is missing a check for ENTRY.  F2008 has
> 
> C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt,
> entry-stmt, or stmt-function-stmt.
> 

I have a patch for stmt-function-stmt and entry.
data-stmt and format-stmt will follow shortly.

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #5 from Jiong Wang  ---
(In reply to Marek Polacek from comment #4)
> FWIW, started with r230150.

Sorry for the breakage, let me have a further check

[Bug middle-end/68336] False positive Wreturn-type warning

[yyc1992 at gmail dot com]

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

--- Comment #1 from Yichao Yu  ---
Ref clang bug report https://llvm.org/bugs/show_bug.cgi?id=25521

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
FWIW, started with r230150.

[Bug middle-end/68336] New: False positive Wreturn-type warning

[yyc1992 at gmail dot com]

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

Bug ID: 68336
   Summary: False positive Wreturn-type warning
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

The following code gives a warning about control flow reaching the end of
function without returning a value even though the function will always reach
the `return 1;` statement and won't reach the end of the function.

```
int f()
{
for (int i = 1;--i >= 0;) {
return 1;
}
}
```

Given no warning about this is given if the loop condition is replaced with `1`
I hope it is also possible for gcc to figure out that the loop is executed as
least once and silence the warning.

This (admittedly stupid) code pattern arise from macro expansion to setup a
single time local context.

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 Ever confirmed|0   |1

--- Comment #23 from Markus Trippelsdorf  ---
Unfortunately it is a ggc_collect and not a ggc_free:

Hardware watchpoint 1: *(const_tree*)0x3fff9d65aa30

Old value = (const_tree) 0x0
New value = (const_tree) 0xa5a5a5a5a5a5a5a5
0x3fffb793bfa8 in __memset_power7 () from /lib64/libc.so.6
(gdb) bt
#0  0x3fffb793bfa8 in __memset_power7 () from /lib64/libc.so.6
#1  0x102a4bf4 in poison_pages () at ../../gcc/gcc/ggc-page.c:2085
#2  0x102a6ca4 in ggc_collect () at ../../gcc/gcc/ggc-page.c:2180
#3  0x10717b50 in execute_one_pass (pass=0x116e2de0) at
../../gcc/gcc/passes.c:2383
#4  0x10718038 in execute_pass_list_1 (pass=0x116e2de0) at
../../gcc/gcc/passes.c:2398
#5  0x10718050 in execute_pass_list_1 (pass=0x116e1d60) at
../../gcc/gcc/passes.c:2399
#6  0x107180fc in execute_pass_list (fn=0x3fff9f468298, pass=) at ../../gcc/gcc/passes.c:2409
#7  0x10351514 in cgraph_node::expand (this=0x3fff9d2d2f70) at
../../gcc/gcc/cgraphunit.c:1965
#8  0x10353588 in expand_all_functions () at
../../gcc/gcc/cgraphunit.c:2101
#9  symbol_table::compile (this=0x3fffaf39) at
../../gcc/gcc/cgraphunit.c:2450
#10 0x10355c5c in symbol_table::finalize_compilation_unit
(this=0x3fffaf39) at ../../gcc/gcc/cgraphunit.c:2540
#11 0x10812f30 in compile_file () at ../../gcc/gcc/toplev.c:491
#12 0x10153288 in do_compile () at ../../gcc/gcc/toplev.c:1954
#13 toplev::main (this=, argc=107, argv=0x3fffe188) at
../../gcc/gcc/toplev.c:2061
#14 0x101551e8 in main (argc=, argv=0x3fffe188) at
../../gcc/gcc/main.c:39

[Bug fortran/68319] ICE on using interface with included entry

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> In fact, gfortran is not issues an error for data-stmt, format-stmt,
> or stmt-function-stmt.

Confirmed: the following test compiles

module m
   interface
  subroutine s
  entry e
integer :: x
data x /1/
f(x) = x*x
10  format (a)
  end
   end interface
contains
   subroutine g
   end
end

[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r230098.

[Bug libstdc++/68323] chrono reference to ‘literals’ namespace is ambiguous when using gnu-versioned-namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Daniel Morilha from comment #0)
> /home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:873:19: error:
> reference to ‘literals’ is ambiguous
>using namespace literals::chrono_literals;
>^
> /home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:788:3: note:
> candidates are: namespace std::literals { }

Ah, I think we should have a __7 in there.

> /home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/bits/basic_string.h:
> 5547:3: note: namespace std::__7::literals { }

And the __7 there might be in the wrong place.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[chrbr at gcc dot gnu.org]

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

--- Comment #30 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Nov 13 15:19:19 2015
New Revision: 230327

URL: https://gcc.gnu.org/viewcvs?rev=230327&root=gcc&view=rev
Log:
2015-11-13  Christian Bruel  

PR target/65837
* config/arm/arm.c (arm_option_override): Move NEON check...
(arm_option_check_internal): here
(arm_file_start): Move .fpu print...
(arm_declare_function_name): here
(arm_option_print): Dump current fpu name.
* config/arm/arm.opt (arm_fpu_index): Mark Save.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.opt

[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
  Known to fail||6.0

--- Comment #4 from ktkachov at gcc dot gnu.org ---
In the end, I think the "ree" pass is at fault here.
I'm testing a patch.

[Bug fortran/68319] ICE on using interface with included entry

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Fri, Nov 13, 2015 at 12:42:16AM +, kargl at gcc dot gnu.org wrote:
> --- Comment #2 from kargl at gcc dot gnu.org ---
> It seems that gfortran is missing a check for ENTRY.  F2008 has
> 
> C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt,
> entry-stmt, or stmt-function-stmt.
> 

In fact, gfortran is not issues an error for data-stmt, format-stmt,
or stmt-function-stmt.

[Bug tree-optimization/68264] tree-call-cdce wrongly uses ordered comparisons

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug target/64358] Wrong code for __int128 operations in powerpc64le

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #6 from Pat Haugen  ---
Fixed a while ago.

[Bug libstdc++/58393] Please relax feature check for std::to_string and std::sto* for uClibc

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri Nov 13 14:51:25 2015
New Revision: 230324

URL: https://gcc.gnu.org/viewcvs?rev=230324&root=gcc&view=rev
Log:
More fine-grained autoconf checks for C99 library

2015-11-13  Jennifer Yao  
Jonathan Wakely  

PR libstdc++/58393
PR libstdc++/61580
* acinclude.m4 (GLIBCXX_ENABLE_C99): Perform tests twice, with
-std=c++11 as well as -std=c++98, and define separate macros for each.
Cache the results of checking for complex math and wide character
functions. Reformat for readability.
* config.h.in: Regenerate.
* include/bits/c++config: Define _GLIBCXX_USE_C99_XXX macros to
either _GLIBCXX98_USE_C99_XXX or _GLIBCXX11_USE_C99_XXX according to
language standard in use.
* config/locale/dragonfly/c_locale.h (std::__convert_from_v): Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* config/locale/generic/c_locale.h (std::__convert_from_v): Likewise.
* config/locale/gnu/c_locale.h (std::__convert_from_v): Likewise.
* config/os/bsd/dragonfly/os_defines.h: Define _GLIBCXX_USE_C99_STDIO,
_GLIBCXX_USE_C99_STDLIB, and _GLIBCXX_USE_C99_WCHAR.
* configure: Regenerate.
* include/bits/basic_string.h: Make numeric conversion functions
depend on _GLIBCXX_USE_C99_STDIO, _GLIBCXX_USE_C99_STDLIB, or
_GLIBCXX_USE_C99_WCHAR, instead of _GLIBCXX_USE_C99.
* include/ext/vstring.h: Likewise.
* include/bits/locale_facets.tcc (std::num_put::_M_insert_float):
Replace _GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* include/bits/locale_facets_nonio.tcc (std::money_put::do_put):
Likewise.
* include/c_compatibility/math.h: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_MATH.
* include/c_compatibility/wchar.h: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/c_global/cstdio: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDIO.
* include/c_global/cstdlib: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* include/c_global/cwchar: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/c_std/cstdio: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDIO.
* include/c_std/cstdlib: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* include/c_std/cwchar: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/tr1/cstdio: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDIO.
* include/tr1/cstdlib: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* include/tr1/cwchar: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/tr1/stdlib.h: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* src/c++98/locale_facets.cc (std::__num_base::_S_format_float):
Replace _GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* testsuite/18_support/exception_ptr/60612-terminate.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDLIB.
* testsuite/18_support/exception_ptr/60612-unexpected.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
(test01): Replace _GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_WCHAR.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stof.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoi.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stol.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stold.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoll.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoul.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoull.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
to_wstring.cc: Likewise.
* testsuite/26_numerics/headers/cstdlib/13943.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDLIB.
* testsuite/26_numerics/headers/cstdlib/types_std_c++0x.cc: Likewise.
* testsuite/lib/libstdc++.exp (check_v3_target_string_conversions):
Change preprocessor #if conditional so that it uses
_GLIBCXX_USE_C99_STDIO, _GLIBCXX_USE_C99_STDLIB, and
_GLIBCXX_USE_C99_WCHAR, instead of _GLIBCXX_USE_C99.
* testsuite/tr1/8_c_compatibility/cmath/templates.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_MATH.
* testsuite/tr1/8_c_compatibility/cstdio/functions.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* testsuite/tr1/8_c

[Bug libstdc++/61580] stoi function unknown on W7/Cygwin/x86_64

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Nov 13 14:51:25 2015
New Revision: 230324

URL: https://gcc.gnu.org/viewcvs?rev=230324&root=gcc&view=rev
Log:
More fine-grained autoconf checks for C99 library

2015-11-13  Jennifer Yao  
Jonathan Wakely  

PR libstdc++/58393
PR libstdc++/61580
* acinclude.m4 (GLIBCXX_ENABLE_C99): Perform tests twice, with
-std=c++11 as well as -std=c++98, and define separate macros for each.
Cache the results of checking for complex math and wide character
functions. Reformat for readability.
* config.h.in: Regenerate.
* include/bits/c++config: Define _GLIBCXX_USE_C99_XXX macros to
either _GLIBCXX98_USE_C99_XXX or _GLIBCXX11_USE_C99_XXX according to
language standard in use.
* config/locale/dragonfly/c_locale.h (std::__convert_from_v): Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* config/locale/generic/c_locale.h (std::__convert_from_v): Likewise.
* config/locale/gnu/c_locale.h (std::__convert_from_v): Likewise.
* config/os/bsd/dragonfly/os_defines.h: Define _GLIBCXX_USE_C99_STDIO,
_GLIBCXX_USE_C99_STDLIB, and _GLIBCXX_USE_C99_WCHAR.
* configure: Regenerate.
* include/bits/basic_string.h: Make numeric conversion functions
depend on _GLIBCXX_USE_C99_STDIO, _GLIBCXX_USE_C99_STDLIB, or
_GLIBCXX_USE_C99_WCHAR, instead of _GLIBCXX_USE_C99.
* include/ext/vstring.h: Likewise.
* include/bits/locale_facets.tcc (std::num_put::_M_insert_float):
Replace _GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* include/bits/locale_facets_nonio.tcc (std::money_put::do_put):
Likewise.
* include/c_compatibility/math.h: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_MATH.
* include/c_compatibility/wchar.h: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/c_global/cstdio: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDIO.
* include/c_global/cstdlib: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* include/c_global/cwchar: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/c_std/cstdio: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDIO.
* include/c_std/cstdlib: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* include/c_std/cwchar: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/tr1/cstdio: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDIO.
* include/tr1/cstdlib: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* include/tr1/cwchar: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_WCHAR.
* include/tr1/stdlib.h: Replace _GLIBCXX_USE_C99 with
_GLIBCXX_USE_C99_STDLIB.
* src/c++98/locale_facets.cc (std::__num_base::_S_format_float):
Replace _GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* testsuite/18_support/exception_ptr/60612-terminate.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDLIB.
* testsuite/18_support/exception_ptr/60612-unexpected.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
(test01): Replace _GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_WCHAR.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stof.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoi.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stol.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stold.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoll.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoul.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
stoull.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/
to_wstring.cc: Likewise.
* testsuite/26_numerics/headers/cstdlib/13943.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDLIB.
* testsuite/26_numerics/headers/cstdlib/types_std_c++0x.cc: Likewise.
* testsuite/lib/libstdc++.exp (check_v3_target_string_conversions):
Change preprocessor #if conditional so that it uses
_GLIBCXX_USE_C99_STDIO, _GLIBCXX_USE_C99_STDLIB, and
_GLIBCXX_USE_C99_WCHAR, instead of _GLIBCXX_USE_C99.
* testsuite/tr1/8_c_compatibility/cmath/templates.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_MATH.
* testsuite/tr1/8_c_compatibility/cstdio/functions.cc: Replace
_GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_STDIO.
* testsuite/tr1/8_c

[Bug tree-optimization/68264] tree-call-cdce wrongly uses ordered comparisons

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Nov 13 14:43:38 2015
New Revision: 230323

URL: https://gcc.gnu.org/viewcvs?rev=230323&root=gcc&view=rev
Log:
PR68264: Use unordered comparisons for tree-call-cdce.c

As reported in PR 68264, tree-call-cdce.c should be using unordered
comparisons for the range checks, in order to avoid raising FE_INVALID
for quiet NaNs.

Tested on x86_64-linux-gnu and aarch64-linux-gnu.  The test failed on
aarch64-linux-gnu before the patch, but it didn't on x86_64-linux-gnu
because it used unordered comparisons for the previous ordered tree codes.

gcc/
PR tree-optimization/68264
* tree-call-cdce.c (gen_one_condition): Update commentary.
(gen_conditions_for_pow_int_base): Invert the sense of the tests
passed to gen_one_condition.
(gen_conditions_for_domain): Likewise.  Use unordered comparisons.
(shrink_wrap_one_built_in_call): Invert the sense of the tests,
using EDGE_FALSE_VALUE for edges to the call block and
EDGE_TRUE_VALUE for the others.

gcc/testsuite/
PR tree-optimization/68264
* gcc.dg/torture/pr68264.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr68264.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-call-cdce.c

[Bug c/68320] internal compiler error: in declspecs_add_type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed.

[Bug c/68320] internal compiler error: in declspecs_add_type

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Author: mpolacek
Date: Fri Nov 13 14:05:59 2015
New Revision: 230322

URL: https://gcc.gnu.org/viewcvs?rev=230322&root=gcc&view=rev
Log:
PR c/68320
* c-parser.c (c_parser_for_statement): Treat unknown tokens as IDs.

* gcc.dg/pr68320.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68320.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug other/68247] Remove pass_first_instance

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from vries at gcc dot gnu.org ---
patch for pass_vrp only:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html

[Bug c/68334] combination of weak and noreturn attributes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Invalid code and not a GCC bug.

[Bug middle-end/68335] ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed at revision r230269, r230172 is OK.

[Bug c/68334] combination of weak and noreturn attributes

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I don't see any difference between declaring the function noreturn (or 
pure, or const, or returning non-aliased memory like malloc, or ...) and 
declaring it to have a certain type.  In both cases, if overriding at link 
time is allowed, the overriding copy must still have the declared 
property.

[Bug middle-end/68335] ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch, spop at gcc dot gnu.org

--- Comment #1 from Joost VandeVondele  
---
graphite ICE trying to collect some timing data..
gcc version 6.0.0 20151113 (experimental) [trunk revision 230282] (GCC)

[Bug middle-end/68335] New: ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68335
   Summary: ICE: tree check: expected ssa_name, have real_cst in
add_phi_arg_for_new_expr, at sese.c:1373
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

current trunk:

> gfortran -c -O2 -floop-nest-optimize bug.f90
bug.f90:27:0:

   SUBROUTINE whittaker_c0 ( wc, r, expa, erfa, alpha, l, n )


internal compiler error: tree check: expected ssa_name, have real_cst in
add_phi_arg_for_new_expr, at sese.c:1373
0xdece94 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9587
0x12ee8ba tree_check
../../gcc/gcc/tree.h:2938
0x12ee8ba add_phi_arg_for_new_expr
../../gcc/gcc/sese.c:1373
0x12ee8ba copy_cond_phi_args(gphi*, gphi*, vec,
sese_info_t*, bool)
../../gcc/gcc/sese.c:1589
0x12f05ca copy_cond_phi_nodes
../../gcc/gcc/sese.c:1624
0x12f05ca copy_bb_and_scalar_dependences(basic_block_def*, sese_info_t*,
edge_def*, vec, bool*)
../../gcc/gcc/sese.c:1824
0x1256b65
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:816
0x1257ee5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:853
0x1257ee5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:853
0x1257126 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:585
0x125729c translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:738
0x1257ee5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:853
0x1257ee5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:853
0x1257ee5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:853
0x1257ee5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:853
0x1257126 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:585
0x125729c translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:738
0x12577f3 graphite_regenerate_ast_isl(scop*)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:1195
0x1255330 graphite_transform_loops()
../../gcc/gcc/graphite.c:343
0x1255800 graphite_transforms
../../gcc/gcc/graphite.c:371
Please submit a full bug report,

> cat bug.f90
MODULE whittaker
  INTEGER, PARAMETER :: dp=8
  INTEGER, PARAMETER :: maxfac = 30
  REAL(KIND=dp), PARAMETER, DIMENSION (-1:2*maxfac+1) :: dfac = (/&
 0.1000E+01_dp, 0.1000E+01_dp,
0.1000E+01_dp,&
 0.2000E+01_dp, 0.3000E+01_dp,
0.8000E+01_dp,&
 0.1500E+02_dp, 0.4800E+02_dp,
0.1050E+03_dp,&
 0.3840E+03_dp, 0.9450E+03_dp,
0.3840E+04_dp,&
 0.10395000E+05_dp, 0.4608E+05_dp,
0.13513500E+06_dp,&
 0.64512000E+06_dp, 0.20270250E+07_dp,
0.10321920E+08_dp,&
 0.34459425E+08_dp, 0.18579456E+09_dp,
0.654729075000E+09_dp,&
 0.37158912E+10_dp, 0.137493105750E+11_dp,
0.817496064000E+11_dp,&
 0.316234143225E+12_dp, 0.196199055360E+13_dp,
0.7905853580625000E+13_dp,&
 0.510117543936E+14_dp, 0.2134580466768750E+15_dp,
0.1428329123020800E+16_dp,&
 0.6190283353629375E+16_dp, 0.4284987369062400E+17_dp,
0.19189878396251062500E+18_dp,&
 0.1371195958099968E+19_dp, 0.63326598707628506250E+19_dp,
0.46620662575398912000E+20_dp,&
 0.221643

[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
So in fact started with r211725.

[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I'll try bisecting with --param allow-store-data-races=0.

[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r212034.

[Bug c++/52277] spell corrector for misspelled identifiers

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Implementation of Levenshtein distance (in C++) committed to trunk as r230285;
currently we offer hints for misspelled command-line options (PR 67613), and in
the C FE for misspelled fields.

There's plenty more that could be implemented; see:
  https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01090.html
for some other implementation ideas.

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[mikael at gcc dot gnu.org]

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

--- Comment #9 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #8)
> In comment 6
> 
>   * gfortran.dg/warn_unused_function_2.f90: New test.
> 
> should be
> 
>   * gfortran.dg/module_private_2.f90: New test.
> 
> The typo has been fixed in the ChangeLog.
> 
You can also amend the svn log.
http://stackoverflow.com/questions/304383/how-do-i-edit-a-log-message-that-i-already-committed-in-subversion

[Bug c/68334] New: combination of weak and noreturn attributes

[chantry.xavier at gmail dot com]

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

Bug ID: 68334
   Summary: combination of weak and noreturn attributes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chantry.xavier at gmail dot com
  Target Milestone: ---

It's probably more a nonsense than a bug, and all compilers behave the same way
(from gcc 4.4 to 5.2 and clang too).

If a function definition has both weak and noreturn, then it looks like the
noreturn optimization is applied anyway in the local compilation unit, even
though the function can be overriden by another one at link time.

main.c
---
#include 
#include "test.h"

__attribute__((weak)) __attribute__((noreturn))
void test(void)
{
assert (0);
}

int main(void)
{
test();
return 0;
}
---

test.c
---
#include 
#include "test.h"

void test(void)
{
printf("toto\n");
}
---

test.h
---
void test(void);
---


$CC -Wall -Wextra -c test.c -o test.o
$CC -Wall -Wextra -c main.c -o main.o
$CC -Wall -Wextra main.o test.o -o test

Running ./test produces the following output which shows that the function was
overriden but the code is executed twice and then segfaults:
---
toto
toto
zsh: segmentation fault (core dumped)  ./test
---

I thought that noreturn optim shouldn't be applied in this case (it could maybe
still be done at linking time when using lto).
Otherwise I might have missed something in the doc which explains what's wrong.

[Bug ipa/68311] gcc/ipa-icf.c:3041: possible sequence point error ?

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Fri Nov 13 12:39:00 2015
New Revision: 230313

URL: https://gcc.gnu.org/viewcvs?rev=230313&root=gcc&view=rev
Log:
Enhance Changelog entry related to PR ipa/68311.

Modified:
trunk/gcc/ChangeLog

[Bug ipa/68311] gcc/ipa-icf.c:3041: possible sequence point error ?

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #6)
> (In reply to Martin Liška from comment #5)
> > Fixed.
> 
> Except that the Changelog doesn't describe the patch :).

Enhanced in r230313 :)

Martin

[Bug ipa/68311] gcc/ipa-icf.c:3041: possible sequence point error ?

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #5)
> Fixed.

Except that the Changelog doesn't describe the patch :).

[Bug ipa/68311] gcc/ipa-icf.c:3041: possible sequence point error ?

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[Bug ipa/68311] gcc/ipa-icf.c:3041: possible sequence point error ?

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Fri Nov 13 12:26:23 2015
New Revision: 230311

URL: https://gcc.gnu.org/viewcvs?rev=230311&root=gcc&view=rev
Log:
Fix PR ipa/68311

PR ipa/68311
* ipa-icf.c (sem_item_optimizer::traverse_congruence_split):
Replace ctor with auto_vec and initialization in a loop.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-icf.c

[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 13 12:14:57 2015
New Revision: 230310

URL: https://gcc.gnu.org/viewcvs?rev=230310&root=gcc&view=rev
Log:
2015-11-13  Richard Biener  

PR tree-optimization/68306
* tree-vect-data-refs.c (verify_data_ref_alignment): Move
loop related checks ...
(vect_verify_datarefs_alignment): ... here.
(vect_slp_analyze_and_verify_node_alignment): Compute and
verify alignment of the single DR that it matters.
* tree-vect-stmts.c (vectorizable_store): Add an assert.
(vectorizable_load): Add a comment.
* tree-vect-slp.c (vect_analyze_slp_cost_1): Fix DR used
for determining load cost.

* gcc.dg/pr68306.c: Adjust.
* gcc.dg/pr68306-2.c: New testcase.
* gcc.dg/pr68306-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr68306-2.c
trunk/gcc/testsuite/gcc.dg/pr68306-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr68306.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to H.J. Lu from comment #4)
> +   /* If that didn't simplify to a constant see if we have recorded
> +  temporary expressions from taken edges.  */
> +   if (!val || TREE_CODE (val) != INTEGER_CST)
> + {
> +   tree ops[2];
> +   ops[0] = gimple_cond_lhs (stmt);
> +   ops[1] = gimple_cond_rhs (stmt);
> +   val = vn_nary_op_lookup_pieces (2, gimple_cond_code (stmt),
> +   boolean_type_node, ops, NULL);
> + }
> 
> turns
> 
>  type  used unsigned type_6 SI
> size 
> unit size 
> align 32 symtab 1390664112 alias set -1 canonical type
> 0x7f205894a888 precision 32 min  max
> >
> visited var def_stmt GIMPLE_NOP
> 
> version 5>
>  
> constant 536870911>
> 
> if (__n_5(D) > 536870911)
> 
> into
> 
>  
> constant 0>
> 
> This can't be right.

If that's the transform done to
_ZN9__gnu_cxx20throw_allocator_baseINSt8__detail10_Hash_nodeIiLb0EEENS_15limit_conditionEE8allocateEjPKv
then that looks perfectly valid.  We have


  :
  if (__n_5(D) > 536870911)
goto ;
  else
goto ;

  :
  std::__throw_bad_alloc ();

  :
  _18 = _S_count;
  _19 = _S_limit;
  if (_18 == _19)
goto ;
  else
goto ;

  :
  __gnu_cxx::__throw_forced_error ();

  :
  _20 = _18 + 1;
  _S_count = _20;
  _8 = &this_2(D)->_M_allocator;
  if (__n_5(D) > 536870911)
goto ;
  else
goto ;

and we optimize the compare in bb 6 which is redundant as the one in BB2
dominates it.

Can you check whether disabling PRE fixes the runtime failure?

Maybe it is also just inlining of the above function that is enabled by
the patch and causes followup errors.

[Bug tree-optimization/68333] [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-13
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug c++/68295] internal compiler error / segmentation fault

[tho...@maier-komor.de]

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

--- Comment #4 from Thomas Maier-Komor  ---
(In reply to Richard Biener from comment #3)
> Works for me on x86_64-linux.

Yes - it seems to be cygwin specific...

[Bug tree-optimization/68333] New: [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 68333
   Summary: [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c
-flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1
   Product: gcc
   Version: 6.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: dje at gcc dot gnu.org, michael.collison at linaro dot org,
rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64-unknown-linux-gnu

This failure, along with:

FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-multitypes-4.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-multitypes-4.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-125.c -flto -ffat-lto-objects  scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/vect-125.c scan-tree-dump vect "vectorized 1 loops"

Seems to have started some time in May, near vectorization patches added on
2015-05-22. On IRC:

 Rhy0lite: but yes, widen-sum pattern might be detected but not
supported afterwards as well
 richi: On AArch64 it was slp-multitypes-4.c:16:3: note: not
vectorized: relevant stmt not supported: patt_127 = _7 w+ 1;
 ah, caused by 2015-05-22, (vect_recog_widen_sum_pattern): Likewise.
 formerly only detected for reductions now also in other places
 there is a PR for the dot_prod case (and the sad case as well)
 richi: same note in PPC dump as jgreenhalgh showed
 hum, vect_recog_widen_sum_pattern misses an optab check.
 note: not vectorized: relevant stmt not supported: patt_127 = _7 w+
1;
 ok, can you open a new PR please?  looks like a different issue than
the dot_prod/sad issue

The failure currently shows up for the rs6000 and ia64 backends, but Michael
Collison's proposed patch adding support for vector widening add patterns would
introduce it to the aarch64 port (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00898.html ).

With Michael's patch applied, I see the following in the dumps for vect-125.c
on AArch64:

vect-125.c:10:3: note: vect_recog_widen_sum_pattern: detected: patt_58
= _13 w+ _24;
vect-125.c:10:3: note: pattern recognized: patt_58 = _13 w+ _24;
[...snip...]
vect-125.c:10:3: note: ==> examining pattern statement: patt_58 = _13
w+ _24;
vect-125.c:10:3: note: vect_is_simple_use: operand _13
vect-125.c:10:3: note: def_stmt: _13 = *_12;
vect-125.c:10:3: note: type of def: internal
vect-125.c:10:3: note: not vectorized: relevant stmt not supported:
patt_58 = _13 w+ _24;

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Richard Biener from comment #11)
> Can you attach preprocessed source for x32?

Ah, it's in the tar file.

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Can you attach preprocessed source for x32?

[Bug middle-end/67790] [6 Regression] verify_ssa failed: definition in block 20 follows the use

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The issue here is that

  /* If we detected "res -= x[i]" earlier, rewrite it into
 "res += -x[i]" now.  If this turns out to be useless reassoc
 will clean it up again.  */
  if (orig_code == MINUS_EXPR)
{
  tree rhs = gimple_assign_rhs2 (def_stmt);
  tree negrhs = make_ssa_name (TREE_TYPE (rhs));
  gimple *negate_stmt = gimple_build_assign (negrhs, NEGATE_EXPR, rhs);
  gimple_stmt_iterator gsi = gsi_for_stmt (def_stmt);
  set_vinfo_for_stmt (negate_stmt, new_stmt_vec_info (negate_stmt,
  loop_info));
  gsi_insert_before (&gsi, negate_stmt, GSI_NEW_STMT);
  gimple_assign_set_rhs2 (def_stmt, negrhs);
  gimple_assign_set_rhs_code (def_stmt, PLUS_EXPR);
  update_stmt (def_stmt);
}

actually inserts stmts into the IL which assigns UIDs to them (via
set_vinfo_for_stmt) which later confuses get_later/earlier_stmt.

The "proper" way of doing the above is by using a pattern which avoids
this issue.

[Bug driver/67613] spell suggestions for misspelled command line options

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
This is awesome! Great job. Do not forget to mention all your awesome work in
https://gcc.gnu.org/gcc-6/changes.html Some people think GCC is dead, and it is
far from it. Let them know!

[Bug target/68332] [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Statistics for other variants:
  4  internal compiler error: RTL check: expected code 'const_int', have
'mem' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052
  4  internal compiler error: RTL check: expected code 'const_int', have
'subreg' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052
 16  internal compiler error: RTL check: expected code 'const_int', have
'reg' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052

[Bug fortran/36854] [meta-bug] fortran front-end optimization

[dominiq at lps dot ens.fr]

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

Bug 47266 Summary: Optimization: Declare PRIVATE module procedures as 
"TREE_PUBLIC = 0" ("static function")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47266

   What|Removed |Added

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

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #8 from Dominique d'Humieres  ---
In comment 6

* gfortran.dg/warn_unused_function_2.f90: New test.

should be

* gfortran.dg/module_private_2.f90: New test.

The typo has been fixed in the ChangeLog.

Closing as FIXED. Please file new PR(s) for remaining issue(s).

[Bug target/68332] [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68315] ivdep has no effect in parloops

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Yes.  The easiest way would be to make tree-data-ref.c use it I suppose.

[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
   Target Milestone|--- |5.3
Summary|wrong code at -O3 on|[5/6 Regression] wrong code
   |x86_64-linux-gnu (in 64-bit |at -O3 on x86_64-linux-gnu
   |mode)   |(in 64-bit mode)
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

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

[Bug tree-optimization/68324] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #3 from Richard Biener  ---
(gdb) p debug_generic_expr (max)
4294443008(OVF)

We have OVF in the IL before VRP:

fn1 ()
{
  unsigned int ivtmp.8;
  int i;
  int _5;

  :

  :
  # ivtmp.8_8 = PHI <4294443008(OVF)(2), ivtmp.8_11(3)>
  _5 = (int) ivtmp.8_8;
  fn2 (_5);
  ivtmp.8_11 = ivtmp.8_8 - 524288;
  goto ;

introduced by IVOPTs which does

 fn1 ()
 {
+  unsigned int ivtmp.8;
   int i;
-  int _4;
   int _5;

   :

   :
-  # i_1 = PHI <7(2), i_7(4)>
-  _4 = i_1 + 8184;
-  _5 = _4 * 524288;
+  # ivtmp.8_8 = PHI <4294443008(OVF)(2), ivtmp.8_11(4)>
+  _5 = (int) ivtmp.8_8;
   fn2 (_5);
-  i_7 = i_1 + -1;

   :
+  ivtmp.8_11 = ivtmp.8_8 - 524288;
   goto ;

 }

note that the infinite loop contains undefined overflow.

IVOPTs should simply strip the overflow flag (using drop_tree_overflow).

[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid
   |x86_64-linux-gnu in |code at -O3 on
   |vect_is_simple_use, at  |x86_64-linux-gnu in
   |tree-vect-stmts.c:8562  |vect_is_simple_use, at
   ||tree-vect-stmts.c:8562
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #6)
> Fixing ought to be fairly easy...

Create a forwarder block outside of the path?

[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.8.5
   Target Milestone|--- |4.9.4
Summary|wrong code at -O2 and -O3   |[4.9/5/6 Regression] wrong
   |on x86_64-linux-gnu |code at -O2 and -O3 on
   ||x86_64-linux-gnu

[Bug c++/68295] internal compiler error / segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-cygwin
   Host||cygwin

--- Comment #3 from Richard Biener  ---
Works for me on x86_64-linux.

[Bug target/68332] New: [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

[zsojka at seznam dot cz]

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

Bug ID: 68332
   Summary: [6 Regression] ICE: in rs6000_is_valid_mask, at
config/rs6000/rs6000.c:17052 with
__sync_and_and_fetch() @ powerpc
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Running the testsuite with RTL checking enabled shows several times the
following assertion failure:

$ powerpc-unknown-linux-gnu-gcc testcase.c 
testcase.c: In function 'foo':
testcase.c:6:3: internal compiler error: RTL check: expected code 'const_int',
have 'reg' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052
   __sync_and_and_fetch (&a, b);
   ^

0xaa4747 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.c:811   
0xe59608 rs6000_is_valid_mask(rtx_def*, int*, int*, machine_mode)
/repo/gcc-trunk/gcc/config/rs6000/rs6000.c:17052
0xe59627 rs6000_is_valid_and_mask(rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/config/rs6000/rs6000.c:17109
0x1045eff and_operand(rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/config/rs6000/predicates.md:867
0x9f9ee6 insn_operand_matches
/repo/gcc-trunk/gcc/optabs.c:6691
0x9f9ee6 maybe_legitimize_operand_same_code
/repo/gcc-trunk/gcc/optabs.c:6719
0x9fdc61 maybe_legitimize_operand
/repo/gcc-trunk/gcc/optabs.c:6789
0x9fdc61 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:6854
0x9fe349 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:6872
0x9fea58 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:6915
0xa003d1 maybe_emit_op
/repo/gcc-trunk/gcc/optabs.c:6457
0xa06640 expand_atomic_fetch_op_no_fallback
/repo/gcc-trunk/gcc/optabs.c:6497
0xa0685f expand_atomic_fetch_op(rtx_def*, rtx_def*, rtx_def*, rtx_code,
memmodel, bool)
/repo/gcc-trunk/gcc/optabs.c:6575
0x690301 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/repo/gcc-trunk/gcc/builtins.c:6538
0x7d1fbf expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:10578
0x6b6f8e expand_expr
/repo/gcc-trunk/gcc/expr.h:256
0x6b6f8e expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:2622
0x6b6f8e expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3510
0x6b6f8e expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:3673
0x6b8702 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:5679
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ powerpc-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc/bin/powerpc-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-230115-checking-yes-rtl-df-nographite-powerpc/bin/../libexec/gcc/powerpc-unknown-linux-gnu/6.0.0/lto-wrapper
Target: powerpc-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=powerpc-unknown-linux-gnu
--with-ld=/usr/bin/powerpc-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc-unknown-linux-gnu-as --with-sysroot=/chroot/powerpc
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-230115-checking-yes-rtl-df-nographite-powerpc
Thread model: posix
gcc version 6.0.0 20151110 (experimental) (GCC) 

RTL checking must be enabled.

Tested revisions:
r230264 - ICE
r230115 - ICE
5-branch r230247 - OK
4_9-branch r230249 - OK
4_8-branch r224828 - OK