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

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #21 from Joost VandeVondele  
---
(In reply to Markus Trippelsdorf from comment #20)
> I haven't seen this issue since Jason's GC related C++ patches went in:
> r230201 and r230202.
> 
> But of course this may well be another statistical fluke.

likely so, since my testcase is Fortran based. For me the nightly build of CP2K
now fails with 

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/pw_spline_utils.F:2303:0:

   SUBROUTINE add_fine2coarse(fine_values_pw,coarse_coeffs_pw,&


internal compiler error: Segmentation fault
0xb525df crash_signal
../../gcc/gcc/toplev.c:336
0x1322c4c dr_misalignment
../../gcc/gcc/tree-vectorizer.h:889
0x1322c4c aligned_access_p
../../gcc/gcc/tree-vectorizer.h:902
0x1322c4c vect_supportable_dr_alignment(data_reference*, bool)
../../gcc/gcc/tree-vect-data-refs.c:5863
0xd96d9f vectorizable_load
../../gcc/gcc/tree-vect-stmts.c:6706
0xda061d vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:7998
0xdc0a31 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3468

not sure if it is related.

[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

--- Comment #22 from Markus Trippelsdorf  ---
(In reply to Joost VandeVondele from comment #21)
> likely so, since my testcase is Fortran based. For me the nightly build of
> CP2K now fails with 
> 
> /data/vjoost/gnu/cp2k/cp2k/makefiles/../src/pw_spline_utils.F:2303:0:
> 
>SUBROUTINE add_fine2coarse(fine_values_pw,coarse_coeffs_pw,&
> 
> 
> internal compiler error: Segmentation fault
> 0xb525df crash_signal
> ../../gcc/gcc/toplev.c:336
> 0x1322c4c dr_misalignment
> ../../gcc/gcc/tree-vectorizer.h:889
> 0x1322c4c aligned_access_p
> ../../gcc/gcc/tree-vectorizer.h:902
> 0x1322c4c vect_supportable_dr_alignment(data_reference*, bool)
> ../../gcc/gcc/tree-vect-data-refs.c:5863
> 0xd96d9f vectorizable_load
> ../../gcc/gcc/tree-vect-stmts.c:6706
> 0xda061d vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
> _slp_tree*, _slp_instance*)
> ../../gcc/gcc/tree-vect-stmts.c:7998
> 0xdc0a31 vect_schedule_slp_instance
> ../../gcc/gcc/tree-vect-slp.c:3468
> 
> not sure if it is related.

No, that is PR68324 caused by Richi's recent vectorizer changes.

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

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

[Bug c++/68071] Generic lambda variadic argument pack cannot be empty

[ralph.tandetzky at gmail dot com]

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

Ralph Tandetzky  changed:

   What|Removed |Added

 CC||ralph.tandetzky at gmail dot 
com

--- Comment #2 from Ralph Tandetzky  ---
I can confirm that error. The code 

int main(){
[](auto...){}();
}

leads to the following compile-time error:

main.cpp: In function 'int main()':
main.cpp:2:23: error: no match for call to '(main()::)
()'
 [](auto...){}();
   ^
main.cpp:2:19: note: candidate: template
main()::
 [](auto...){}();
   ^
main.cpp:2:19: note:   template argument deduction/substitution failed:
main.cpp:2:23: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^

This is the case for gcc 4.9 and gcc 5.2 with C++14 enabled. Clang 3.6 compiles
it.

[Bug c/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 #3 from Martin Liška  ---
Created attachment 36700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36700&action=edit
Suggested patch

[Bug rtl-optimization/68328] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 68328
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk mis-compiles the following code on x86_64-linux-gnu at
-O2 and -O3 in the 64-bit mode (but not in the 32-bit mode). 

It also affects 4.9.x and later releases, making it a regression from 4.8.x. 

$ 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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151112 (experimental) [trunk revision 230270] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
$ gcc-4.8 -O2 small.c; ./a.out
$ 
$ gcc-trunk -O2 small.c
$ ./a.out
0
$ 


-


int printf (const char *, ...); 

int a, b, c = 1, d = 1, e;

int
fn1 (int p1)
{
  char g, h;
  int i, j;

  for (;;)
{
  if (c)
h = d;
  g = h < p1 ? h : 0; 
  i = (char) ((g - 120) ^ 1);
  j = i > 97;
  if (a - j)
printf ("%d\n", 0);
  if (!b)
return e;
}
}

int
main ()
{
  fn1 (2);
  return 0;
}

[Bug c/68329] New: [4.8 4.9]gcc using array index to accelerate loop running , why turn off at gcc 5.X

[zuogang at huawei dot com]

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

Bug ID: 68329
   Summary: [4.8 4.9]gcc using array index to accelerate loop
running , why turn off at gcc 5.X
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zuogang at huawei dot com
  Target Milestone: ---

[Bug libstdc++/68197] negative index to ios_base::iword lead to unpredictable result

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
No, it seems underspecified. I have raised it with the C++ committee.

[Bug c/68329] [4.8 4.9]gcc using array index to accelerate loop running , why turn off at gcc 5.X

[zuogang at huawei dot com]

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

zuogang  changed:

   What|Removed |Added

 Target||amd64 ppwerpc32 (tested)
   ||and others(no testing)
  Known to work||4.4.1, 5.2.0
   Host||amd64
  Known to fail||4.8.5, 4.9.4
  Build||amd64

--- Comment #1 from zuogang  ---
the src code file is:
/*
 * compiling options:
 * -g -w -c -Wall -fno-common -fno-omit-frame-pointer -Wextra
-Wformat-nonliteral -Wformat-security -Wswitch-default -O2 -fstrength-reduce
-fno-strict-aliasing
 *
 *  */
#define NULL 0
typedef unsigned int uint4;
typedef unsigned short ushort;
typedef unsigned long ulong;

typedef struct team {
ulong size;
ulong count;
ulong flag;
ulong peer;
 ulong event;
 ulong index[1];
 ulong addr;
}Team;

typedef struct entry {
uint4 *p1;
 uint4 *p2;
 char simple[64];
 char full[64];
 uint4 index;
}Entry;

extern uint4 get1(uint4 p1, uint4 *p2);
extern uint4 get2(uint4 p1, uint4 p2, Entry **p3);
extern void hand(uint4 p1, uint4 p2, Entry *p3);

void recvt(ushort id, Team *pTeam)
{
uint4 num = 0;
uint4 index   = 0;
Entry *pEntry   = NULL;
uint4 count = 0;
uint4 i   = 0;

if (0x01 & pTeam->flag)
{
count = pTeam->count;

for (i = 0; i < count; i++)
{
index = *(pTeam->index + i);
   if(0 != get1(index, &num))
{
continue;
}
if (0 == index)
{
continue;
}

if ( 0 != get2(num ,index, &pEntry))
{
continue;
}

hand(num, pTeam->event, pEntry);
}
}

return;
}

compile this file using :
gcc -g -w -c -Wall -fno-common -fno-omit-frame-pointer -Wextra
-Wformat-nonliteral -Wformat-security -Wswitch-default -O2 -fstrength-reduce
-fno-strict-aliasing test-loop.c -o testloop

see the disassemble file , wile find that the loop "for (i = 0; i < count;
i++)" run only once.

I think this "bug" is because gcc find the loop index "i", is a array's index,
and the array 's len is 1, so gcc tell the loop can only run once, so gcc don't
generate loop-specific asm codes.

my question is why this op are not support in gcc version 5. any option to
control this "bug"?

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 12 Nov 2015, jsm28 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
> 
> --- Comment #10 from Joseph S. Myers  ---
> I have verified that the patch in comment#7, (a) on its own and (b) together
> with my patch, does not cause any regressions on x86_64-pc-linux-gnu.  My
> inclination would be that this patch should go in, with a separate issue being
> filed in Bugzilla for the extra qualifiers, and then I can put my patch in.

Fine with me.

[Bug middle-end/68134] [6 Regression] float64x1_t comparison ICE on aarch64-none-elf

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #4 from Ilya Enkovich  ---
Seems the problem is that we have V1DF mode but don't have V1DI mode.  It
causes mode_for_vector to return DI instead of V1DI which makes vector lowering
pass think it is a scalar statements which doesn't need lowering.  This patch
should help:

diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index c34b4e9..66d983b 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1093,8 +1093,8 @@ default_get_mask_mode (unsigned nunits, unsigned
vector_size)
   gcc_assert (elem_size * nunits == vector_size);

   vector_mode = mode_for_vector (elem_mode, nunits);
-  if (VECTOR_MODE_P (vector_mode)
-  && !targetm.vector_mode_supported_p (vector_mode))
+  if (!VECTOR_MODE_P (vector_mode)
+  || !targetm.vector_mode_supported_p (vector_mode))
 vector_mode = BLKmode;

   return vector_mode;

[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 #8 from Richard Biener  ---
I'm testing another followup...

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

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

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

--- Comment #1 from Thomas Maier-Komor  ---
The bug is reproduceable with gcc 5.2.0 on cygwin.

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

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

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

--- Comment #2 from Thomas Maier-Komor  ---
Created attachment 36701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36701&action=edit
Another preprocessed testcase

This testcase has no missing symbols and should compile cleanly.

[Bug rtl-optimization/68330] New: [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

Bug ID: 68330
   Summary: [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c
scan-assembler-not addl on alpha-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---
Target: alpha-linux-gnu

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:

(insn 7 6 8 2 (set (reg:DI 82)
(lshiftrt:DI (reg:DI 81 [ x ])
(const_int 16 [0x10]))) pr42269-1.c:8 66 {lshrdi3}
 (expr_list:REG_DEAD (reg:DI 81 [ x ])
(nil)))
(insn 8 7 11 2 (set (reg:DI 70 [ _2 ])
(sign_extend:DI (subreg:SI (reg:DI 82) 0))) pr42269-1.c:8 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg:DI 82)
(nil)))

to:

Trying 7 -> 8:
Successfully matched this instruction:
(set (reg:DI 70 [ _2 ])
(zero_extract:DI (reg/v:DI 80 [ x ])
(const_int 16 [0x10])
(const_int 16 [0x10])))
allowing combination of insns 7 and 8
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 7.
modifying insn i3 8: r70:DI=zero_extract(r80:DI,0x10,0x10)
deferring rescan insn with uid = 8.

After the patch, the combination fails:

Trying 7 -> 8:
Failed to match this instruction:
(set (reg:DI 70 [ _2 ])
(sign_extend:DI (lshiftrt:SI (subreg:SI (reg/v:DI 80 [ x ]) 0)
(const_int 16 [0x10]

[1] https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00900.html

[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

Uroš Bizjak  changed:

   What|Removed |Added

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

[Bug c/65083] Can not indirectly call some C11 atomic library functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Confirmed; Joseph has posted a patch.

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

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Target||aarch64-none-linux-gnu,
   ||x86_64-none-linux-gnu
 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #1 from James Greenhalgh  ---
I can reproduce this on aarch64-none-linux-gnu.

I also see a similar backtrace in the testsuite for AArch64 on
gcc.target/aarch64/vect-vaddv.c:

FAIL: gcc.target/aarch64/vect-vaddv.c (test for excess errors)
Excess errors:
.../gcc/testsuite/gcc.target/aarch64/vect-vaddv.c:87:5: internal compiler
error: Segmentation fault
0xad6cd7 crash_signal
.../gcc/toplev.c:336
0x10a09b8 dr_misalignment(data_reference*)
.../gcc/tree-vectorizer.h:889
0x10a09b8 aligned_access_p
.../gcc/tree-vectorizer.h:902
0x10a09b8 vect_supportable_dr_alignment(data_reference*, bool)
.../gcc/tree-vect-data-refs.c:5863
0xd13ce3 vectorizable_load
.../gcc/tree-vect-stmts.c:6706
0xd1c1d7 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
.../gcc/tree-vect-stmts.c:7997
0xd33703 vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3468
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd35193 vect_schedule_slp(vec_info*)
.../gcc/tree-vect-slp.c:3533
0xd3851f vect_slp_bb(basic_block_def*)
.../gcc/tree-vect-slp.c:2525
0xd3a4db execute
.../gcc/tree-vectorizer.c:738

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

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Also seen on x86_64-apple-darwin14. Revision r230007 is OK, r230269 gives the
ICE.

[Bug tree-optimization/66558] Missed vectorization of loop with control flow

[alahay01 at gcc dot gnu.org]

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
Author: alahay01
Date: Fri Nov 13 10:51:34 2015
New Revision: 230297

URL: https://gcc.gnu.org/viewcvs?rev=230297&root=gcc&view=rev
Log:
Optimize condition reductions where the result is an integer induction variable

2015-11-13  Alan Hayward 

gcc/
PR tree-optimization/66558
* tree-vect-loop.c (is_integer_induction):Add.
(vectorizable_reduction): Add integer induction checks.

gcc/testsuite/
PR tree-optimization/66558
* gcc.dg/vect/pr65947-1.c: Add checks.
* gcc.dg/vect/pr65947-2.c: Add checks.
* gcc.dg/vect/pr65947-3.c: Add checks.
* gcc.dg/vect/pr65947-4.c: Add checks.
* gcc.dg/vect/pr65947-5.c: Add checks.
* gcc.dg/vect/pr65947-6.c: Add checks.
* gcc.dg/vect/pr65947-10.c: Add checks.
* gcc.dg/vect/pr65947-12.c: New test.
* gcc.dg/vect/pr65947-13.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65947-12.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr65947-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-10.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-2.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-3.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-4.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-5.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-6.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vectorizer.h

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

[dominiq at gcc dot gnu.org]

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

--- Comment #6 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Nov 13 10:58:53 2015
New Revision: 230298

URL: https://gcc.gnu.org/viewcvs?rev=230298&root=gcc&view=rev
Log:
2015-11-13  Dominique d'Humieres 

PR fortran/47266
* gfortran.dg/warn_unused_function_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/module_private_2.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/68331] New: [meta-bug] fipa-pta issues

[vries at gcc dot gnu.org]

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

Bug ID: 68331
   Summary: [meta-bug] fipa-pta issues
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

From https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01630.html :

1)
we lack good testing coverage for IPA PTA so wrong-code bugs might still exist

2)
IPA PTA can use a _lot_ of memory and compile-time

3)
for existing wrong-code issues I have merely dumbed down the use of the
analysis result resulting in weaker alias analysis compared to the local PTA
(for some cases)

Because of 2 and no good way to avoid this I decided to not make
fixing 3 a priority (and 1 still holds).

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

[dominiq at gcc dot gnu.org]

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

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Nov 13 11:03:40 2015
New Revision: 230299

URL: https://gcc.gnu.org/viewcvs?rev=230299&root=gcc&view=rev
Log:
2015-11-13  Dominique d'Humieres 

PR fortran/47266
* gfortran.dg/module_private_2.f90: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/module_private_2.f90
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[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

[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 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 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 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/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/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/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 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/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 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 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 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 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 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 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 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/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 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 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] [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 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/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 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 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 ?

[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

--- 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 ?

[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 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 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++/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 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 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

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

[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 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 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

[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

[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 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/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 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 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 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 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 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 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 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 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 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 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 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 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 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 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/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

[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 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 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

[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 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 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 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/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

[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 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 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 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 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 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 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 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 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 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 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.