[Bug libstdc++/68307] New: [mingw32] Missing enum values in std::errc

[beck.ct at gmail dot com]

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

Bug ID: 68307
   Summary: [mingw32] Missing enum values in std::errc
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beck.ct at gmail dot com
  Target Milestone: ---

I originally encountered this problem when trying to cross-compile a C++
program using websocketpp to communicate using websockets, using the mingw-w64
toolchain.

The problem is that the libstdc++ header file
`libstdc++-v3/config/os/mingw32-w64/error_constants.h` comments out a large
number of enum values for the enum `std::errc` which are not optional and are
required by the C++11 standard to exist. In particular, I get this error
related to `std::errc::operation_canceled`:

```
In file included from
websocketpp-0.6.0/include/websocketpp/config/asio_no_tls_client.hpp:32:0,
from main.cpp:31:
websocketpp-0.6.0/include/websocketpp/transport/asio/endpoint.hpp: In member
function ‘void
websocketpp::transport::asio::endpoint::handle_accept(websocketpp::transport::accept_handler,
const error_code&)’:
websocketpp-0.6.0/include/websocketpp/transport/asio/endpoint.hpp:764:28:
error: ‘operation_canceled’ is not a member of ‘std::errc’
if (asio_ec == lib::asio::errc::operation_canceled) {
^
```

It compiles fine when using g++.

For simplicity, here is a trivial program which I believe conforms to the
standard but is prevented from compiling on mingw because of this problem:

```
#include 

int main() {
  std::errc temp;
  if (temp == std::errc::operation_canceled) {
return 1;
  }
  return 0;
}
```

In the C++11 standard section 19.5.2, the symbol
`std::errc::operation_canceled` is provided in the `` synopsis,
and its existence is not listed as optional.

Further, 19.5.3 states that "The value of each enum errc constant shall be the
same as the value of the  macro shown in
the above synopsis."

It was suggested to me on irc that this is a libstdc++ bug and not a mingw-w64
bug.

Cross-links to this issue on other issue trackers:
- Mingw-w64: http://sourceforge.net/p/mingw-w64/support-requests/105/
- websocketpp: https://github.com/zaphoyd/websocketpp/issues/478

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

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
ICE's in vectorizable_load, too:

markus@x4 linux % cat vsyscall_gtod.i
struct {
  int tz_minuteswest;
  int tz_dsttime;
} a, b;
void fn1() {
  b.tz_minuteswest = a.tz_minuteswest;
  b.tz_dsttime = a.tz_dsttime;
}

markus@x4 linux % gcc -mno-sse -mno-mmx -O3 -c vsyscall_gtod.i
vsyscall_gtod.i: In function ‘fn1’:
vsyscall_gtod.i:5:6: internal compiler error: in vectorizable_load, at
tree-vect-stmts.c:6707
 void fn1() {
  ^

0xd0a0d9 vectorizable_load
../../gcc/gcc/tree-vect-stmts.c:6707
0xd118d0 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:7998
0xd28e2d vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3484
0xd28c89 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3365
0xd2a936 vect_schedule_slp(vec_info*)
../../gcc/gcc/tree-vect-slp.c:3549
0xd2de7c vect_slp_bb(basic_block_def*)
../../gcc/gcc/tree-vect-slp.c:2543
0xd2fef5 execute
../../gcc/gcc/tree-vectorizer.c:734

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |
   |nu  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-12
   Host|powerpc64le-unknown-linux-g |
   |nu  |
 Ever confirmed|0   |1
  Build|powerpc64le-unknown-linux-g |
   |nu  |

--- Comment #1 from Markus Trippelsdorf  ---
Also happens on x86_64 with -mno-sse -mno-mmx.

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

[trippels at gcc dot gnu.org]

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

Bug ID: 68306
   Summary: [6 Regression] ICE: in vectorizable_store, at
tree-vect-stmts.c:5651
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

On ppc64le I get:

trippels@gcc2-power8 linux % cat cputable.i
enum powerpc_pmc_type { PPC_PMC_IBM };
struct {
  unsigned num_pmcs;
  enum powerpc_pmc_type pmc_type;
} a;
enum powerpc_pmc_type b;
void fn1() { a.num_pmcs = a.pmc_type = b; }

trippels@gcc2-power8 linux % gcc -mno-altivec -mno-vsx -O3 -c cputable.i
cputable.i: In function ‘fn1’:
cputable.i:7:6: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:5651
 void fn1() { a.num_pmcs = a.pmc_type = b; }
  ^

0x10acdeaf vectorizable_store
../../gcc/gcc/tree-vect-stmts.c:5651
0x10ad5c03 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:8003
0x10af2543 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3484
0x10af4487 vect_schedule_slp(vec_info*)
../../gcc/gcc/tree-vect-slp.c:3549
0x10af8053 vect_slp_bb(basic_block_def*)
../../gcc/gcc/tree-vect-slp.c:2543
0x10afa7cb execute
../../gcc/gcc/tree-vectorizer.c:734

[Bug fortran/68268] configure: error: GNU Fortran is not working;

[isearcher at 126 dot com]

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

--- Comment #5 from isearcher at 126 dot com ---
Hello! 

I create a build directory, cd to it, and execute "sources_dir/./configure ..."
like this :
/wk5/WJ/tmp/gcc-4.8.0/configure --prefix=/wk5/WJ/gcc -enable-threads=posix
-disable-checking -disable-multilib -enable-languages=c,c++,fortran
--with-gmp=/wk5/WJ/gmp-4.3.2 --with-mpfr=/wk5/WJ/mpfr-2.4.2
--with-mpc=/wk5/WJ/mpc-0.8.1

But there is a new error:
make[2]: Entering directory `/wk5/WJ/gcc'
make[3]: Entering directory `/wk5/WJ/gcc'
rm -f stage_current
make[3]: Leaving directory `/wk5/WJ/gcc'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/gcc.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/wk5/WJ/gcc'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/wk5/WJ/gcc'
make: *** [all] Error 2

thanks.

[Bug tree-optimization/68305] [6 regression] ICE on valid code at -O3 on x86_64-linux-gnu: tree check: expected class ‘expression’, have ‘exceptional’ (ssa_name) in tree_operand_check, at tree.h:3436

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-12
 CC||trippels at gcc dot gnu.org
Summary|ICE on valid code at -O3 on |[6 regression] ICE on valid
   |x86_64-linux-gnu: tree  |code at -O3 on
   |check: expected class   |x86_64-linux-gnu: tree
   |‘expression’, have  |check: expected class
   |‘exceptional’ (ssa_name) in |‘expression’, have
   |tree_operand_check, at  |‘exceptional’ (ssa_name) in
   |tree.h:3436 |tree_operand_check, at
   ||tree.h:3436
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
This is same as PR53050 comment 8, but your testcase is nicer.

[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Markus Trippelsdorf  ---
The issue from comment 8 is tracked by PR68305.
Closing this one.

[Bug tree-optimization/68305] New: ICE on valid code at -O3 on x86_64-linux-gnu: tree check: expected class ‘expression’, have ‘exceptional’ (ssa_name) in tree_operand_check, at tree.h:3436

[su at cs dot ucdavis.edu]

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

Bug ID: 68305
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu: tree
check: expected class ‘expression’, have ‘exceptional’
(ssa_name) in tree_operand_check, at tree.h:3436
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 5.2.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 20151110 (experimental) [trunk revision 230107] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-5.2 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: tree check: expected class ‘expression’,
have ‘exceptional’ (ssa_name) in tree_operand_check, at tree.h:3436
 fn1 ()
 ^

0xd66987 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-trunk/gcc/tree.c:9638
0xd3f9c3 expr_check(tree_node*, char const*, int, char const*)
../../gcc-trunk/gcc/tree.h:3107
0xd3f9c3 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc-trunk/gcc/tree.h:3436
0xd3f9c3 vect_get_constant_vectors
../../gcc-trunk/gcc/tree-vect-slp.c:2744
0xd3fce1 vect_get_slp_defs(vec, _slp_tree*,
vec, va_heap, vl_ptr>*, int)
../../gcc-trunk/gcc/tree-vect-slp.c:3025
0xd0e5f9 vectorizable_condition(gimple*, gimple_stmt_iterator*, gimple**,
tree_node*, int, _slp_tree*)
../../gcc-trunk/gcc/tree-vect-stmts.c:7389
0xd2137e vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc-trunk/gcc/tree-vect-stmts.c:8020
0xd38ce4 vect_schedule_slp_instance
../../gcc-trunk/gcc/tree-vect-slp.c:3482
0xd38b39 vect_schedule_slp_instance
../../gcc-trunk/gcc/tree-vect-slp.c:3363
0xd3a8d6 vect_schedule_slp(vec_info*)
../../gcc-trunk/gcc/tree-vect-slp.c:3547
0xd275c5 vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:6619
0xd4254b vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:533
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





int a, b;

void
fn1 ()
{
  int c, d; 
  for (; b; b++)
a = a ^ !c ^ !d; 
}

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[msebor at gcc dot gnu.org]

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

--- Comment #31 from Martin Sebor  ---
(In reply to Alexander Cherepanov from comment #23)

> 2. The practical problem is size calculation in general, it's not 
> limited to sizeof operation. You don't need to use sizeof to create 
> oversized automatic VLA (an example in the description).

Agreed.  Creating an automatic VLA object that exhausts the stack is bad.  In
all likelihood it will crash the program.  I'm not sure to what extent it might
be exploitable.  Allowing a sizeof expression to overflow given a VLA type is
benign in an of itself, but can lead to more subtle bugs depending on how the
result is used (e.g., to allocate an array on the heap whose elements are then
written to).  Some of those bugs have known exploits.

> 
> 3. IMHO overflow in sizeof operation is UB due to C11, 6.5p5, and 
> wrapping according to C11, 6.2.5p9, is not applicable (see the comment #7).

No, that's not a correct interpretation.  It's exactly the other way around. 
Sizeof is computed in an unsigned type.

> 4. From the POV of the standard I don't see much difference between VLA 
> and ordinary arrays in this question. AFAICT the standard doesn't place 
> limits on constructed types of any kind and hence oversized types are 
> permitted by the standard. See comment #3 (or pr68107) for a practical 
> example of sizeof overflow with an array of a known constant size which 
> works with the current gcc.

It is the intent of the standard to allow implementations to impose such a
limit.  It may not be specified with sufficient clarity in the text, but the
intent is reflected in the C99 Rationale.

> Gcc chooses to prohibit oversized types when it can easily catch them 
> and fails compilation stumbling upon an oversized array of a known 
> constant size (modulo pr68107) but is this a case of undefined behavior, 
> implementation-defined behavior or what?

For non-VLA types, creating a type whose size exceeds the
implementation-defined limit is a constraint violation.  Violations of
constraints are diagnosable; they lead to undefined behavior at runtime.  (IMO,
the standard is unclear for VLAs but I think the same rule should apply and I'm
working to get it clarified to that effect.)

> 
> 3. The same for sizes of objects. There is an environmental limit for 
> "bytes in an object" but it's marked as "(in a hosted environment 
> only)". So there is no such limit in the standard for a freestanding 
> implementation, right? But I doubt that you are supposed to be able to 
> create oversized arrays (either static or automatic) even in a 
> freestanding implementation.

Again, the limit is implementation-defined, and breaking it is a diagnosable
constraint violation.

[Bug middle-end/68304] New: [6 Regression] FAIL: gcc.c-torture/compile/950612-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 68304
   Summary: [6 Regression] FAIL: gcc.c-torture/compile/950612-1.c
 -O3 -fomit-frame-pointer -funroll-loops  -fpeel-loops
-ftracer -finline-functions  (internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -O3
-fomit-frame-
pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -w -c -o
950612-1.o
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c: In
functi
on 'f':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:134:1:
int
ernal compiler error: in scan_rtx_reg, at regrename.c:1074
0x6d0b1f scan_rtx_reg
../../gcc/gcc/regrename.c:1073
0x6d3d6f record_out_operands
../../gcc/gcc/regrename.c:1554
0x6d4f9b build_def_use
../../gcc/gcc/regrename.c:1802
0x6d4f9b regrename_analyze(bitmap_head*)
../../gcc/gcc/regrename.c:726
0x6d65af regrename_optimize
../../gcc/gcc/regrename.c:1871
0x6d65af execute
../../gcc/gcc/regrename.c:1908
Please submit a full bug report,

[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 #6 from H.J. Lu  ---
Does this patch

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 2ac3828..8b57875 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -4372,17 +4372,16 @@ sccvn_dom_walker::before_dom_children (basic_block bb)
{
  gimple *stmt = last_stmt (e->src);
  if (stmt
- && gimple_code (stmt) == GIMPLE_COND)
+ && gimple_code (stmt) == GIMPLE_COND
+ && (e->flags & EDGE_TRUE_VALUE) != 0)
{
  enum tree_code code = gimple_cond_code (stmt);
  tree lhs = gimple_cond_lhs (stmt);
  tree rhs = gimple_cond_rhs (stmt);
- record_conds (bb, code, lhs, rhs,
-   (e->flags & EDGE_TRUE_VALUE) != 0);
+ record_conds (bb, code, lhs, rhs, true);
  code = invert_tree_comparison (code, HONOR_NANS (lhs));
  if (code != ERROR_MARK)
-   record_conds (bb, code, lhs, rhs,
- (e->flags & EDGE_TRUE_VALUE) == 0);
+   record_conds (bb, code, lhs, rhs, false);
}
}
 }

make any senses? Do we need to check EDGE_FALSE_VALUE?

[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 #5 from H.J. Lu  ---
It came from

  enum tree_code code = gimple_cond_code (stmt);
  tree lhs = gimple_cond_lhs (stmt);
  tree rhs = gimple_cond_rhs (stmt);
  record_conds (bb, code, lhs, rhs, 
(e->flags & EDGE_TRUE_VALUE) != 0);
  code = invert_tree_comparison (code, HONOR_NANS (lhs));

(gdb) call debug_gimple_stmt (stmt)
if (__n_5(D) > 536870911)
(gdb) 

and it records that (__n_5(D) > 536870911) is false.  It looks very odd.

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
Created attachment 36693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36693&action=edit
Alternative patch

Alternative patch that does a couple of things:
- always defines BIGGEST_ALIGNMENT to 32 for TARGET_IAMCU
- changes "misaligned_operand" to always use natural alignment of the operand
- adds TARGET_IAMCU to generate unaligned vector load/store insns
- fixes ix86_legitimate_combined_insn to consider ssememalign value

The patch regresses sse-1.c (a very delicate test), where it generates slightly
unoptimal, but still correct code.

HJ, can you please test the patch for IAMCU, also with AVX target?

[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 #4 from H.J. Lu  ---
+   /* 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


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.

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #5)
> Could you please add it to your nightly test run and commit it if there no
> other new failures?  I'll be away for a few days...

OK, will do.

> Hm ... so maybe for now we should enable -mlra by default and add a 2nd
> postreload CSE pass as you have tried in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67732#c2 ?

I think that that trial and AMS show the backend like SH requires
something even for the old reload, though I'm not sure that
the 2nd postreload_cse is the right thing for that.

[Bug target/67771] integer-to-floating-point conversions wrongly produce -0 in FE_DOWNWARD mode

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Ignore that last comment, I must not be awake :-(

[Bug target/67771] integer-to-floating-point conversions wrongly produce -0 in FE_DOWNWARD mode

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
Can we just do  +0. + x  , where x is the current result?

[Bug rtl-optimization/67201] PowerPC -mlra hits ICE: Max. number of generated reload insns per insn is achieved

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
Hi Mike,

Do we need this to go in to trunk / 5?

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[joseph at codesourcery dot com]

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

--- Comment #30 from joseph at codesourcery dot com  ---
On Wed, 11 Nov 2015, ch3root at openwall dot com wrote:

> 4. From the POV of the standard I don't see much difference between VLA 
> and ordinary arrays in this question. AFAICT the standard doesn't place 
> limits on constructed types of any kind and hence oversized types are 
> permitted by the standard. See comment #3 (or pr68107) for a practical 

"permitted by" only in the sense of "the standard does not require 
implementations to reject them".  It is not intended that the listed 
implementation limits are the only limits that there may be, at compile 
time or run time.

> 3. The same for sizes of objects. There is an environmental limit for 
> "bytes in an object" but it's marked as "(in a hosted environment 
> only)". So there is no such limit in the standard for a freestanding 
> implementation, right? But I doubt that you are supposed to be able to 

No, what's "in a hosted environment only" is the requirement that the 
implementation translate and execute some program with a 65535-byte object 
(and an instance of the other given limits, simultaneously); freestanding 
implementations may have an object size limit smaller than 65535 bytes.  
That is, effectively, C99 and above do not support hosted environments 
with a 16-bit address space; systems with a 16-bit address space are only 
supported for freestanding implementations.

[Bug libstdc++/68303] New: performance: unordered_map&co. up to 7x speedup

[jan.kratochvil at redhat dot com]

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

Bug ID: 68303
   Summary: performance: unordered_map&co. up to 7x speedup
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---

libstdc++ spends most of the time on:
  div %rdi
computing modulo even when commonly the container is empty().

Moreover for small size()s it is more effective to iterate the container rather
than calculating the modulo.

-
template class unordered_map_find:public
unordered_map {
private:
  const size_t find_max_size=20;
public:
  /***/ iterator find(const From &k) /***/ {
if (unordered_map::size()>find_max_size) // too big?
  return unordered_map::find(k);
for (auto it=unordered_map::begin();;++it) // small => iterate
  if (it==unordered_map::end()||it->first==k)
return it;
  }
};
#define unordered_map unordered_map_find
-

gcc-5.1.1-4.fc23.x86_64
g++ -o findbench findbench.C -Wall -g -std=c++11 -O3;sync;for i in `seq 0
30`;do ./findbench $i;done

orig  wrapped
---  ---
 0=1.094465   0=0.157921
 1=1.119786   1=0.183768
 2=1.169548   2=0.279629
 3=1.347452   3=0.407056
 4=1.479790   4=0.415102
 5=1.301983   5=0.516378
 6=1.326878   6=0.629252
 7=1.467088   7=0.672654
 8=1.681829   8=0.632880
 9=1.755480   9=0.656492
10=1.712439  10=0.900121
11=1.515782  11=0.791073
12=1.351241  12=0.837695
13=1.434103  13=0.948055
14=1.671421  14=1.114046
15=1.683168  15=1.055906
16=1.521289  16=1.295058
17=1.537086  17=1.219568
18=1.766316  18=1.304961
19=1.807524  19=1.544631
20=1.848499  20=2.530600
21=1.895775  21=1.911767
22=1.792831  22=1.813895
23=1.562995  23=1.399753
24=1.560324  24=1.583886
25=1.419246  25=1.481225
26=1.609419  26=1.625853
27=1.482955  27=1.498665
28=1.483937  28=1.509582
29=1.506504  29=1.680078
30=1.522410  30=1.564460

[Bug tree-optimization/52560] if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
6.0.0 2015 doesn't issue any warnings on either the original translation
unit or the smaller test case in attachment 26877.  Since comment #3 indicates
the test case was buggy it doesn't seem like there's anything for us to do.

Resolving as Invalid.

[Bug middle-end/55217] False -Wstrict-overflow warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2015-11-11
 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
6.0.0 2015 issues the following slightly different warnings which disappear
when the increment of r in the first loop is made undonditional.  Since the
condition should always be true (r can never be zero), the warning on that line
seems pointless (though not necessarily incorrect -- GCC is right to assume
there's no overflow).

I don't really know what to make of this so I'm leaving it UNCONFIRMED and for
someone else to look into in more depth.

$ cat u.c && /home/msebor/build/gcc-trunk/gcc/xgcc -B
/home/msebor/build/gcc-trunk/gcc -O2 -S -Wstrict-overflow=3 -o/dev/null
-std=c99 u.c

void h(int *s);
void f(int n, int s)
{
int r = 1;
for (int i = 1; i < n; i++)
if (r)
r++;
if (r * s >= s + 3)   // warning here
for (int j = 0; j < r; j++)
h(&s);
}
u.c: In function ‘f’:
u.c:7:20: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
 if (r)
^

u.c:10:17: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
 for (int j = 0; j < r; j++)
 ^

u.c:10:17: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]

[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 #3 from H.J. Lu  ---
Still fails with r230191 at -O2:

Program received signal SIGSEGV, Segmentation fault.
0xf7571e97 in _Unwind_RaiseException (exc=)
at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:136
136 }
(gdb) bt
#0  0xf7571e97 in _Unwind_RaiseException (exc=)
at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:136
#1  0x00403510 in std::_Hashtable, std::__detail::_Identity,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >::_M_rehash
(this=, __n=, __state=)
at
/export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-pc-linux-gnu/x32/libstdc++-v3/include/bits/hashtable.h:1949
#2  0xcde0 in ?? ()
#3  0xcde0 in ?? ()
#4  0x0060aa20 in ?? ()
#5  0x0040358a in std::_Hashtable, std::__detail::_Identity,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >::_M_insert_unique_node
(this=this@entry=0xcde0, __bkt=4294954380, __bkt@entry=0, 
__code=__code@entry=0, __node=)
at
/export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-pc-linux-gnu/x32/libstdc++-v3/include/bits/hashtable.h:1587
#6  0x0040414a in std::_Hashtable, std::__detail::_Identity,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_r---Type  to
continue, or q  to quit---
ehash_policy, std::__detail::_Hashtable_traits
>::_M_insert > > > (__node_gen=, 
__v=@0xcddc: 0, this=0xcde0)
at
/export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-pc-linux-gnu/x32/libstdc++-v3/include/bits/hashtable.h:1691
#7  std::__detail::_Insert_base, std::__detail::_Identity,
std::equal_to, std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >::insert (
__v=@0xcddc: 0, this=0xcde0)
at
/export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-pc-linux-gnu/x32/libstdc++-v3/include/bits/hashtable_policy.h:713
#8  std::unordered_set, std::equal_to,
__gnu_cxx::throw_allocator_limit >::insert (__x=@0xcddc: 0,
this=0xcde0)
at
/export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-pc-linux-gnu/x32/libstdc++-v3/include/bits/unordered_set.h:413
#9  test01 ()
at
/export/gnu/import/git/sources/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/insert/hash_policy.cc:46
#10 0x00400f48 in main ()
at
/export/gnu/import/git/sources/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/insert/hash_policy.cc:110
(gdb)

[Bug c++/68301] self-dependent reference member initialization not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||24639

--- Comment #1 from Martin Sebor  ---
This seems related to bug 2972 or bug 19808 and probably falls under the
Wuninitialized alias.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #36674|0   |1
is obsolete||

--- Comment #9 from H.J. Lu  ---
Created attachment 36692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36692&action=edit
An updated patch

[Bug debug/68302] New: [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

Bug ID: 68302
   Summary: [5/6 Regression] ICE with debugging enabled on mips
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mipsel-linux-gnu
Target: mipsel-linux-gnu
 Build: mipsel-linux-gnu

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

The attached testcase, when compiled on mips with debugging enabled and with -g
-O2 -march=mips32r2 causes an internal compiler error: Segmentation fault
(program cc1). Removing one of this three options causes the issue to
disappear.

The problem appears on both  gcc-5-branch and trunk from today. It can be
reproduced with a native compiler or a cross-compiler targeting mips or mipsel.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
Even further reduced

MODULE neb_utils
  IMPLICIT NONE
  INTEGER, PARAMETER :: dp=8
  TYPE neb_var_type
 REAL(KIND=dp), DIMENSION(:, :),  POINTER  :: xyz, int, wrk
  END TYPE neb_var_type
CONTAINS
  RECURSIVE SUBROUTINE get_neb_force(&
  )
INTEGER  :: i
TYPE(neb_var_type), POINTER  :: forces
REAL(KIND=dp), ALLOCATABLE, DIMENSION(:) :: dtmp1, wrk
dtmp1 = forces%wrk(:,i)-dot_product_band
  END SUBROUTINE get_neb_force
END MODULE neb_utils

 dtmp1 = forces%wrk(:,i)-dot_product_band
1

Error: Symbol 'dot_product_band' at (1) has no IMPLICIT type
f951: internal compiler error: gfc_variable_attr(): Bad array reference

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
After PR 66250 is fixed, we need to adjust all alignments > 4 bytes
to 4 bytes.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
The reduced test with only one error

MODULE neb_utils
  IMPLICIT NONE
  INTEGER, PARAMETER :: dp=8
  TYPE neb_var_type
 REAL(KIND=dp), DIMENSION(:, :),  POINTER  :: xyz, int, wrk
  END TYPE neb_var_type
CONTAINS
  RECURSIVE SUBROUTINE get_neb_force(&
  )
INTEGER  :: i
TYPE(neb_var_type), POINTER  :: forces
REAL(KIND=dp), ALLOCATABLE, DIMENSION(:) :: dtmp1, wrk
   dtmp1   = forces%wrk(:,i)- &
dot_product_band(neb_env,forces%wrk(:,i))
  END SUBROUTINE get_neb_force
END MODULE neb_utils

still gives the ICE

pr68283_db_2.f90:15:28:

 dot_product_band(neb_env,forces%wrk(:,i))
1

Error: Symbol 'neb_env' at (1) has no IMPLICIT type
f951: internal compiler error: gfc_variable_attr(): Bad array reference
...

Backtrace is

Program received signal SIGABRT, Aborted.
0x7fff91ac0286 in __pthread_kill () from
/usr/lib/system/libsystem_kernel.dylib
(gdb) bt
#0  0x7fff91ac0286 in __pthread_kill () from
/usr/lib/system/libsystem_kernel.dylib
#1  0x7fff8ab039f9 in pthread_kill () from
/usr/lib/system/libsystem_pthread.dylib
#2  0x7fff8dbb29b3 in abort () from /usr/lib/system/libsystem_c.dylib
#3  0x000100fca611 in uw_init_context_1 (context=0x6,
outer_cfa=0x7fff5fbfea70, outer_ra=0x100f24879 )
at ../../../work/libgcc/unwind-dw2.c:1563
#4  0x000100fcb078 in _Unwind_Backtrace (trace=0x100f24780 ,
trace_argument=0x7fff739ce300) at ../../../work/libgcc/unwind.inc:283
#5  0x000100f24879 in backtrace_full (state=0x1425f9000, skip=, callback=, error_callback=, 
data=) at ../../work/libbacktrace/backtrace.c:127
#6  0x000100edfb33 in diagnostic_action_after_output (context=0x1418c8d00,
diag_kind=) at ../../work/gcc/diagnostic.c:460
#7  0x000100edfd6e in diagnostic_report_diagnostic (context=0x1418c8d00,
diagnostic=0x7fff5fbfeb40) at ../../work/gcc/diagnostic.c:801
#8  0x0001000327e3 in gfc_internal_error (gmsgid=) at
../../work/gcc/fortran/error.c:1295
#9  0x000100090ef1 in gfc_variable_attr (expr=, ts=0x0) at
../../work/gcc/fortran/primary.c:2272
#10 0x000100090f20 in gfc_expr_attr (e=) at
../../work/gcc/fortran/primary.c:2351
#11 0x0001000cb4be in gfc_check_dependency (expr1=,
expr2=, identical=)
at ../../work/gcc/fortran/dependency.c:1292
#12 0x0001000cb423 in gfc_check_dependency (expr1=,
expr2=, identical=)
at ../../work/gcc/fortran/dependency.c:1260
#13 0x0001001743ec in optimize_code (c=,
walk_subtrees=, data=)
at ../../work/gcc/fortran/frontend-passes.c:1160
#14 0x000100176f04 in gfc_code_walker (c=, codefn=, exprfn=, data=)
at ../../work/gcc/fortran/frontend-passes.c:3260
#15 0x00010017812c in optimize_namespace (ns=) at
../../work/gcc/fortran/frontend-passes.c:984
#16 0x000100178169 in optimize_namespace (ns=) at
../../work/gcc/fortran/frontend-passes.c:993
#17 0x000100178338 in gfc_run_passes (ns=) at
../../work/gcc/fortran/frontend-passes.c:127
#18 0x0001000a43d0 in gfc_resolve (ns=) at
../../work/gcc/fortran/resolve.c:15479
#19 0x00010008cec1 in gfc_parse_file () at
../../work/gcc/fortran/parse.c:5715
#20 0x0001000d3c9b in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:199
#21 0x000100af328a in compile_file () at ../../work/gcc/toplev.c:466
#22 0x000100fcf24c in ?? ()
#23 0x000100fd0c09 in main (argc=3, argv=0x7fff5fbff2f8) at
../../work/gcc/main.c:39

[Bug c++/68301] New: self-dependent reference member initialization not diagnosed

[msebor at gcc dot gnu.org]

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

Bug ID: 68301
   Summary: self-dependent reference member initialization not
diagnosed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While verifying that bug 68208 has been fixed (it has been), I noticed that
other, slightly more involved cases of reference members than the trivial
"m(m)" in the bug are not diagnosed.  For example, the following program which
is diagnosed by Clang as shown is accepted by GCC without a warning even with
-Wall and -Wextra.

 cat u.cpp && /build/llvm-trunk/bin/clang++ -S -Wall -o/dev/null u.cppstruct S
{
const int &r1, &r2;

S ():
r1 (r2),
r2 (r1)
{ }
};
u.cpp:5:9: warning: reference 'r2' is not yet bound to a value when used here
  [-Wuninitialized]
r1 (r2),
^
1 warning generated.

[Bug c++/68208] g++ doesn't warn against reference self-initialization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Patch posted for review here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01420.html

[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-11
 Depends on||66250
 Ever confirmed|0   |1

--- Comment #7 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to H.J. Lu from comment #2)
> > The maximum stack alignment is 4 byte for IA MCU.  That is why
> > reload generates misaligned load/store.
> 
> It looks to me that BIGGEST_ALIGNMENT is defined in a wrong way. If you want
> to use SSE with TARGET_IAMCU, then it needs to be defined to 128.

We can't change BIGGEST_ALIGNMENT due to PR 66250.  Alignment of
long long is 4 byte for IA MCU.  But alignment of long long can't be
changed.  With

#define BIGGEST_ALIGNMENT \
  (TARGET_AVX512F ? 512 \
   : (TARGET_AVX ? 256 \
  : (TARGET_SSE ? 128 \
 : (TARGET_IAMCU ? 32 : 128

I got:

[hjl@gnu-tools-1 gcc]$ cat x.i
int x = __alignof__(long long);
[hjl@gnu-tools-1 gcc]$ ./xgcc -B./ -S -m32 x.i -miamcu
[hjl@gnu-tools-1 gcc]$ cat x.s
.file   "x.i"
.globl  x
.data
.align 4
.type   x, @object
.size   x, 4
x:
.long   8
.ident  "GCC: (GNU) 6.0.0 20151110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 gcc]$ ./xgcc -B./ -S -m32 x.i 
[hjl@gnu-tools-1 gcc]$ cat x.s
.file   "x.i"
.globl  x
.data
.align 4
.type   x, @object
.size   x, 4
x:
.long   8
.ident  "GCC: (GNU) 6.0.0 20151110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 gcc]$


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66250
[Bug 66250] Can't adjust complex nor decimal floating point modes

[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #9 from Markus Trippelsdorf  ---
Quick reduction, several uninitialized vars.

markus@x4 tmp % cat b.ii
class A;
class B {
public:
  B(A *);
};
template  char saturate_cast(int p1) { return p1 > 0; }
class A {
  virtual void operator()(const unsigned char **, unsigned char *);
};
struct C : A {
  C(int) {}
  void operator()(const unsigned char **, unsigned char *p2) {
int i, a;
double b;
int *c;
unsigned char *D = p2;
for (; i; i += 2) {
  int d = a + c[i], e = a + c[i + 1];
  D[i] = saturate_cast(d * b);
  D[i + 1] = saturate_cast(e * b);
}
  }
};
int f;
void getColumnSumFilter() { B(new C(f)); }

markus@x4 tmp % g++ -O3 -c b.ii
b.ii: In member function ‘virtual void C::operator()(const unsigned char**,
unsigned char*)’:
b.ii:12:8: internal compiler error: tree check: expected class ‘expression’,
have ‘exceptional’ (ssa_name) in tree_operand_check, at tree.h:3436
   void operator()(const unsigned char **, unsigned char *p2) {
^

0xf398a7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9638
0xf12861 expr_check(tree_node*, char const*, int, char const*)
../../gcc/gcc/tree.h:3107
0xf12861 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/gcc/tree.h:3436
0xf12861 vect_get_constant_vectors
../../gcc/gcc/tree-vect-slp.c:2744
0xf12bb3 vect_get_slp_defs(vec, _slp_tree*,
vec, va_heap, vl_ptr>*, int)
../../gcc/gcc/tree-vect-slp.c:3025
0xee249a vectorizable_condition(gimple*, gimple_stmt_iterator*, gimple**,
tree_node*, int, _slp_tree*)
../../gcc/gcc/tree-vect-stmts.c:7389
0xef4998 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:8020
0xf0bd7d vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3482
0xf0bbd9 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3363
0xf0bbd9 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3363
0xf0d886 vect_schedule_slp(vec_info*)
../../gcc/gcc/tree-vect-slp.c:3547
0xefab65 vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:6619
0xf15287 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:533

[Bug go/68072] malformed DWARF TagVariable entry

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #6 from Ian Lance Taylor  ---
The patch seems plausible but we'll need a test case, even if that test case
only fails with current GCC.  It looks like the GCC change might be due to the
early-debug work.  It looks like it should be pretty easy to boil down the test
case into a small piece of code that fails.

[Bug c++/64667] -Winit-self ignored for reference fields

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||ooprala at redhat dot com

--- Comment #4 from Martin Sebor  ---
*** Bug 68208 has been marked as a duplicate of this bug. ***

[Bug c++/68208] g++ doesn't warn against reference self-initialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
This is fixed on trunk, apparently via bug 64667.

Unfortunately, the warning in the reference and pointer cases is missing a
caret (see below), and in the member case points to the constructor rather than
to the member initializer.  The following patch fixes the location information.
 I'll submit it shortly.

index 2e11acb..055e9d9 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -638,7 +638,7 @@ perform_member_init (tree member, tree init)
val = TREE_OPERAND (val, 0);
   if (TREE_CODE (val) == COMPONENT_REF && TREE_OPERAND (val, 1) == member
  && TREE_OPERAND (val, 0) == current_class_ref)
-   warning_at (DECL_SOURCE_LOCATION (current_function_decl),
+   warning_at (EXPR_LOC_OR_LOC (val, input_location),
OPT_Winit_self, "%qD is initialized with itself",
member);
 }


struct S {
int m;
int &r;
int *p;
S ():
m (m),
r (r),
p (p)
{ }
};
u.cpp: In constructor ‘S::S()’:
u.cpp:5:5: warning: ‘S::m’ is initialized with itself [-Winit-self]
 S ():
 ^

u.cpp:5:5: warning: ‘S::r’ is initialized with itself [-Winit-self]
u.cpp:5:5: warning: ‘S::p’ is initialized with itself [-Winit-self]

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

[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #8 from David Binderman  ---
Seems to go wrong with gcc trunk dated 2015

/home/dcb/rpmbuild/BUILD/OpenCV-2.3.1/modules/imgproc/src/smooth.cpp:112:10:
int
ernal compiler error: tree check: expected class ‘expression’, have
‘exceptional
’ (ssa_name) in tree_operand_check, at tree.h:3436

0x10114c7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*
, int, char const*)
../../src/trunk/gcc/tree.c:9638
0xfe85d2 expr_check(tree_node*, char const*, int, char const*)
../../src/trunk/gcc/tree.h:3107
0xfe85d2 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../src/trunk/gcc/tree.h:3436
0xfe85d2 vect_get_constant_vectors
../../src/trunk/gcc/tree-vect-slp.c:2746

It compiled ok a few days ago.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> yes, I noticed this as well, I think this is one of the fortran frontend
> optimization passes.

Indeed, no ICE with '-O -fno-frontend-optimize'.

[Bug ipa/68035] [5/6 Regression] ipa performance issue when no procedures are present

[ncahill_alt at yahoo dot com]

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

--- Comment #3 from ncahill_alt at yahoo dot com ---
Martin, your patch produces the identical object file in 10.3s versus 24.6s. 
The profile is also very smooth with none of the functions listed above
appearing.

Thank you very much, this is now not a problem for users of flite 2.0 (a very
good speech engine).

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #8 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #6)
> For some reason, the ICE requires to use at least -O.

yes, I noticed this as well, I think this is one of the fortran frontend
optimization passes.

[Bug tree-optimization/58926] -Wstrict-overflow unwanted warning comparing variables initialized from one of static duration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Still present on trunk. A slightly different test case involving two functions
is below.

The modified test case shows another problem with the warning: it names the
function foobar but the expression the diagnostic prints is the return
statement in foo.  When the body of foobar is large, there may not be a way for
the user to figure out what's causing it.

$ cat u.c && gcc -O2 -S -Wall -o/dev/null u.c
int foo (int i, int j) {
return i + 1 < j;
}

int foobar (int i) {
return foo (i, i);
}
u.c: In function ‘foobar’:
u.c:2:18: warning: assuming signed overflow does not occur when assuming that
(X + c) < X is always false [-Wstrict-overflow]
 return i + 1 < j;
  ^

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

Andreas Arnez  changed:

   What|Removed |Added

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

--- Comment #25 from Andreas Arnez  ---
To me the problem looks fixed now.  In particular checkpoint.exp from the GDB
test suite shows no more FAILs on s390x.

There's another patch pending that deals with C++:
  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html
But that addresses a different issue and shouldn't affect this PR's status.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Wed, Nov 11, 2015 at 06:01:19PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68283
> 
> --- Comment #6 from Dominique d'Humieres  ---
> For some reason, the ICE requires to use at least -O.
> 

Yep.  Mostlikely, a different path through the compiler stomping on different
chunks of memory.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
For some reason, the ICE requires to use at least -O.

[Bug other/60158] powerpc: usage of the .data.rel.ro.local section

[joakim.tjernlund at transmode dot se]

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

--- Comment #5 from joakim.tjernlund at transmode dot se  ---
I am sure I saw .data.rel.ro.local section with a .4byte statement in it
using -S

Now I cannot repeat it. The only thing that has changed that I know is
glibc 2.19 is no glibc 2.20 and binutils from 2.24 to 2.25.1

Maybe binutils version makes a difference?
Don't have that handy anymore

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #4)
>
> Does the ICE happens while printing an error? If not, something must be
> checking for buffered errors and changing behavior depending on that. The
> new code might be clearing the buffered errors flag (or not buffering them
> at all) too early.

No.  It happens after error messages have been issued.
The ICE goes away with

laptop-kargl:kargl[219] svn diff primary.c 
Index: primary.c
===
--- primary.c   (revision 229970)
+++ primary.c   (working copy)
@@ -2268,8 +2268,6 @@ gfc_variable_attr (gfc_expr *expr, gfc_t
&& errors > 0)
  break;
  }
-   if (n == ref->u.ar.as->rank)
- gfc_internal_error ("gfc_variable_attr(): Bad array reference");
  }

break;

There are a number of questionable gfc_internal_error()'s within gfortran.
I suspect some come from the idea "Correctly written Fortran code cannot
possibly reach this point, so there must be some internal error to get
here."  The original code should have simply returned because clearly
"Poorly written invalid code can reach this point, and an internal 
error is not appropriate.  So, let gfortran exit gracefully".

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
If we should pay attention to the sign, then maybe

--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -11903,9 +11903,9 @@ vector_types_compatible_elements_p (tree t1, tree t2)
  && (c2 == INTEGER_TYPE || c2 == REAL_TYPE
  || c2 == FIXED_POINT_TYPE));

-  t1 = c_common_signed_type (t1);
-  t2 = c_common_signed_type (t2);
-  /* Equality works here because c_common_signed_type uses
+  t1 = c_common_signed_or_unsigned_type (TYPE_UNSIGNED (t1), t1);
+  t2 = c_common_signed_or_unsigned_type (TYPE_UNSIGNED (t2), t2);
+  /* Equality works here because c_common_signed_or_unsigned_type uses
  TYPE_MAIN_VARIANT.  */
   if (t1 == t2)
 return true;

(it has a small fallout)

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

  Attachment #35567|0   |1
is obsolete||

--- Comment #7 from simon at pushface dot org ---
Created attachment 36690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36690&action=edit
Patch to gcc/ada/bindgen.adb

[Bug target/68286] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1468

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |powerpc64le-unknown-linux-g
   |nu  |nu,
   ||arm-none-linux-gnueabihf
 CC||renlin at gcc dot gnu.org

--- Comment #3 from Renlin Li  ---
same issue happens on arm-none-linuxgnu-eabihf toolchain.

[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jaak Ristioja from comment #6)
> Additionally, the nanosleep code is also missing proper EINTR handling,
> which again could break the sleep.

This part is done.

[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 11 17:08:51 2015
New Revision: 230183

URL: https://gcc.gnu.org/viewcvs?rev=230183&root=gcc&view=rev
Log:
Loop in std::this_thread sleep functions

PR libstdc++/60421
* include/std/thread (this_thread::sleep_for): Retry on EINTR.
(this_thread::sleep_until): Retry if time not reached.
* src/c++11/thread.cc (__sleep_for): Retry on EINTR.
* testsuite/30_threads/this_thread/60421.cc: Test interruption and
non-steady clocks.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/thread
trunk/libstdc++-v3/src/c++11/thread.cc
trunk/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc

[Bug sanitizer/68299] [5/6 Regression] runtime error: member call on null pointer of type 'const struct __lambda0'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Ah yes, so it is.

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

[Bug c++/68300] New: Bogus -Wnon-virtual-dtor warning with protected base class constructor

[trippels at gcc dot gnu.org]

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

Bug ID: 68300
   Summary: Bogus -Wnon-virtual-dtor warning with protected base
class constructor
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 ~ % cat non_virt.ii
class A {
protected:
  ~A();

public:
  friend struct C;
  virtual void foo();
};

class B final : public A {
  void foo() override;
};

markus@x4 ~ % clang++ -Wnon-virtual-dtor -c -std=c++14 non_virt.ii
markus@x4 ~ % g++ -Wnon-virtual-dtor -c -std=c++14 non_virt.ii
non_virt.ii:1:7: warning: ‘class A’ has virtual functions and accessible
non-virtual destructor [-Wnon-virtual-dtor]
 class A {
   ^
non_virt.ii:10:7: warning: base class ‘class A’ has accessible non-virtual
destructor [-Wnon-virtual-dtor]
 class B final : public A {
   ^

The warning goes away if I comment out the friend declaration.

[Bug sanitizer/67941] calls on function pointer from a captureless lambda cause ubsan warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
*** Bug 68299 has been marked as a duplicate of this bug. ***

[Bug sanitizer/68299] [5/6 Regression] runtime error: member call on null pointer of type 'const struct __lambda0'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Looks like a dup of PR67941.

[Bug sanitizer/68299] New: [5/6 Regression] runtime error: member call on null pointer of type 'const struct __lambda0'

[redi at gcc dot gnu.org]

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

Bug ID: 68299
   Summary: [5/6 Regression] runtime error: member call on null
pointer of type 'const struct __lambda0'
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

int main()
{
  void(*p)() = +[] { };
  p();
}

$ g++ -fsanitize=undefined ub.cc  
$ ./a.out
ub.cc:3:22: runtime error: member call on null pointer of type 'const struct
__lambda0'

[Bug rtl-optimization/68298] New: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 68298
   Summary: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
   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 (as well as 5.1.x and 5.2.x) miscompiles the following
code on x86_64-linux-gnu at -O3 in the 64-bit mode (but not in the 32-bit
mode). 

This is a regression from 4.9.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 20151110 (experimental) [trunk revision 230107] (GCC) 
$ 
$ gcc-trunk -m64 -O2 small.c; ./a.out
0
$ gcc-trunk -m32 -O3 small.c; ./a.out
0
$ gcc-4.9 -m64 -O3 small.c; ./a.out
0
$ 
$ gcc-trunk -m64 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ gcc-5.2 -m64 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ gcc-5.1 -m64 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ 


-


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

int a[1], b, c, d;
char e = 2;

char
fn1 ()
{
  if (e > 1)
return e;
}

void
fn2 ()
{
  b = fn1 ();
  for (; c;)
;
  if (!e)
b = a[400];
  printf ("0\n");
}

void
fn3 ()
{
  for (; d;)
;
  for (; d < 1; d++)
fn2 ();
}

int
main ()
{
  fn3 ();
  return 0;
}

[Bug libstdc++/68297] Faster std::make_exception

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Yes, this is certainly possible, someone just needs to do the work.

[Bug rtl-optimization/68282] Optimization fails to remove unnecessary sign extension instruction

[stanshebs at earthlink dot net]

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

--- Comment #3 from Stan Shebs  ---
Sorry, left out a detail - the cltq output is compilation as C++.  Compiled as
a C file, the code does have the andl as noted.  (I'm sure there are good
reasons why the *exact* *same* source text ends up with two completely
different asm sequences, ahem.)

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
Fixed on all active branches.

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

--- Comment #11 from Eric Botcazou  ---
Fixed on all active branches.

[Bug libstdc++/68297] New: Faster std::make_exception

[nyh at math dot technion.ac.il]

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

Bug ID: 68297
   Summary: Faster std::make_exception
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nyh at math dot technion.ac.il
  Target Milestone: ---

std::make_exception(object) currently does this:

make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
{
  try
{
  throw __ex;
}
  catch(...)
{
  return current_exception();
}
}

I think this could have been made much faster... Throwing an exception is very
slow, and not really needed here, as gcc (libsupc++) knows exactly how to
create an exception_ptr from the given object, without going through the
motions of looking for the exception frame (we know exactly where it will be).
By taking the right code from __cxa_throw, std::current_exception(), etc., this
can be done without any stack unwinding, and therefore much more quickly.

Such an improvement will benefit especially code that passes around
exception_ptrs instead of actually throwing exception (the Seastar library, for
example, does this).

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Nov 11 16:04:34 2015
New Revision: 230179

URL: https://gcc.gnu.org/viewcvs?rev=230179&root=gcc&view=rev
Log:
PR target/67265
* ira.c (ira_setup_eliminable_regset): Do not necessarily create the
frame pointer for stack checking if non-call exceptions aren't used.
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr67265.c
  - copied unchanged from r230177,
trunk/gcc/testsuite/gcc.target/i386/pr67265.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/ira.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
The FEs stopped rejecting the testcase with r202364.

[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.

[sorganov at gmail dot com]

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

--- Comment #5 from Sergey Organov  ---
Thanks, but my particular problem is that I do want nice GCC builtin when it is
available, and I want generic inline implementation, rather than function call,
when GCC builtin is not available.

[Bug tree-optimization/68294] gcc cannot deduce (a | b) != 0 from (a != 0 && b != 0)

[fuz at fuz dot su]

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

--- Comment #3 from Robert Clausecker  ---
Sorry, I forgot to attach the test case. Here it is.

[Bug tree-optimization/68294] gcc cannot deduce (a | b) != 0 from (a != 0 && b != 0)

[fuz at fuz dot su]

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

--- Comment #2 from Robert Clausecker  ---
Created attachment 36689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36689&action=edit
Testcase for bug #68294

[Bug c/68039] Incorrect unused-result warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Since op1 and op2 in that COND_EXPR are the same, we fold the conditional
expression to a COMPOUND_EXPR:
  return x ();, 0;
so the result of x () looks unused.

Same for C++.

[Bug middle-end/68296] New: [6 regression] ICE in prepare_cmp_insn, at optabs.c:3813

[sch...@linux-m68k.org]

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

Bug ID: 68296
   Summary: [6 regression] ICE in prepare_cmp_insn, at
optabs.c:3813
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*, ia64-*-*

Started with r230098.

For example on aarch64:

FAIL: gcc.c-torture/compile/pr53410-2.c   -O0  (internal compiler error)
FAIL: gcc.c-torture/compile/pr53410-2.c   -O0  (test for excess errors)
Excess errors:
/opt/gcc/gcc-2015/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:27:18:
internal compiler error: in prepare_cmp_insn, at optabs.c:3813
0xa10aeb prepare_cmp_insn
../../gcc/optabs.c:3813
0xa10b7f emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
../../gcc/optabs.c:3960
0x780d17 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
../../gcc/dojump.c:1140
0x781cc7 do_compare_and_jump
../../gcc/dojump.c:1219
0x820f33 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9076
0x70fd87 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3612
0x70fd87 expand_gimple_stmt
../../gcc/cfgexpand.c:3673
0x7139bb expand_gimple_basic_block
../../gcc/cfgexpand.c:5679
0x719077 execute
../../gcc/cfgexpand.c:6291

[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
You could work around this with -fno-builtin-abs.

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Nov 11 14:56:17 2015
New Revision: 230176

URL: https://gcc.gnu.org/viewcvs?rev=230176&root=gcc&view=rev
Log:
PR target/67265
* ira.c (ira_setup_eliminable_regset): Do not necessarily create the
frame pointer for stack checking if non-call exceptions aren't used.
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr67265.c
  - copied unchanged from r230168,
trunk/gcc/testsuite/gcc.target/i386/pr67265.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/ira.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/68293] [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to James Greenhalgh from comment #1)
> Looks related to pr68134 ?

Maybe; the compiler crashes at roughly the same place.
PR68134 is "r230014 or older", so either the buggy path is now triggered much
more often, or the bugs are unrelated.

[Bug c++/68266] pointers to arrays of excessive size not diagnosed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Should be fixed.

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Should be fixed.

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Nov 11 14:47:03 2015
New Revision: 230174

URL: https://gcc.gnu.org/viewcvs?rev=230174&root=gcc&view=rev
Log:
PR c/68107
PR c++/68266
* c-common.c (valid_array_size_p): New function.
* c-common.h (valid_array_size_p): Declare.

* c-decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* c-c++-common/pr68107.c: New test.
* g++.dg/init/new38.C (large_array_char): Adjust dg-error.
(large_array_char_template): Likewise.
* g++.dg/init/new44.C: Adjust dg-error.

Added:
trunk/gcc/testsuite/c-c++-common/pr68107.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/init/new38.C
trunk/gcc/testsuite/g++.dg/init/new44.C

[Bug c++/68266] pointers to arrays of excessive size not diagnosed

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Nov 11 14:47:03 2015
New Revision: 230174

URL: https://gcc.gnu.org/viewcvs?rev=230174&root=gcc&view=rev
Log:
PR c/68107
PR c++/68266
* c-common.c (valid_array_size_p): New function.
* c-common.h (valid_array_size_p): Declare.

* c-decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* decl.c (grokdeclarator): Call valid_array_size_p.  Remove code
checking the size of an array.

* c-c++-common/pr68107.c: New test.
* g++.dg/init/new38.C (large_array_char): Adjust dg-error.
(large_array_char_template): Likewise.
* g++.dg/init/new44.C: Adjust dg-error.

Added:
trunk/gcc/testsuite/c-c++-common/pr68107.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/init/new38.C
trunk/gcc/testsuite/g++.dg/init/new44.C

[Bug target/68293] [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #1 from James Greenhalgh  ---
Looks related to pr68134 ?

[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

[dominiq at gcc dot gnu.org]

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

--- Comment #16 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Nov 11 14:30:16 2015
New Revision: 230172

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

PR bootstrap/68271
* parser.h (cp_token): Update pragma_kind to 8.

gcc/c-family/ChangeLog
2015-11-11  Dominique d'Humieres 

PR bootstrap/68271
* c-pragma.c (c_register_pragma_1): Update the gcc_assert to 256.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.h

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Nov 11 14:24:39 2015
New Revision: 230170

URL: https://gcc.gnu.org/viewcvs?rev=230170&root=gcc&view=rev
Log:
PR target/67265
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise.

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

[Bug tree-optimization/67612] Unable to vectorize DOT_PROD_EXPR (PMADDWD?)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/66719] gcc.dg/vect/bb-slp-32.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
So fixed.

[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Nov 11 14:22:43 2015
New Revision: 230168

URL: https://gcc.gnu.org/viewcvs?rev=230168&root=gcc&view=rev
Log:
PR target/67265
* ira.c (ira_setup_eliminable_regset): Do not necessarily create the
frame pointer for stack checking if non-call exceptions aren't used.
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr67265.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #4)
> (In reply to Oleg Endo from comment #3)
> > I haven't read reload.*, but my speculation is that if something in reload
> > instantiates that rtx with an imm8 constant to calculate addresses, it might
> > also try to instantiate it with reg = reg + reg if the constant doesn't fit
> > into imm8.  Maybe we just don't hit the case (yet).  So it's probably safer
> > to allow reg = reg + reg, too.
> 
> Sounds reasonable.

Could you please add it to your nightly test run and commit it if there no
other new failures?  I'll be away for a few days...

> 
> > I guess those "new" failures are R0 related?
> 
> Yep, spill failure in R0.  Our old friend.

Hm ... so maybe for now we should enable -mlra by default and add a 2nd
postreload CSE pass as you have tried in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67732#c2 ?

[Bug rtl-optimization/68287] [6 Regression] conditional jump or move depends on uninitialized value in lra-lives.c:1048

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/68287] [6 Regression] conditional jump or move depends on uninitialized value in lra-lives.c:1048

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Wed Nov 11 14:04:47 2015
New Revision: 230163

URL: https://gcc.gnu.org/viewcvs?rev=230163&root=gcc&view=rev
Log:
Fix PR rtl-optimization/68287

PR rtl-optimization/68287
* lra-lives.c (lra_create_live_ranges_1): Reserve the right
number of elements.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug target/56592] [SH] Add vector ABI

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Oleg Endo from comment #0)
> 
> Function argument/return value aggregates are decomposed so that the
> individual members can be passed in different register classes, based on the
> data type.  E.g. 
> 
> ...
> 
> struct FuncArg
> {
>   float a;  // -> fr4
>   float b;  // -> fr5
>   float c;  // -> fr6
>   float d;  // -> fr7
> };
> 

Maybe such simple cases can be handled by implementing
TARGET_ARRAY_MODE_SUPPORTED_P

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #3)
> I haven't read reload.*, but my speculation is that if something in reload
> instantiates that rtx with an imm8 constant to calculate addresses, it might
> also try to instantiate it with reg = reg + reg if the constant doesn't fit
> into imm8.  Maybe we just don't hit the case (yet).  So it's probably safer
> to allow reg = reg + reg, too.

Sounds reasonable.

> I guess those "new" failures are R0 related?

Yep, spill failure in R0.  Our old friend.

[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
The test works if operator== is not a member. There's something fairly fishy
going on here.

[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-11
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.2, 5.2.0, 6.0

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #3 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #2)

Thanks for looking at this Kaz.

> Here is a workaround.  It changes the total text size of CSiBE
> from 3310543 to 3310579 which looks simply noise.

Most of the cases go like this:

before:
mov r0,r1<<< initial load of r1
add #-65,r1
cmp/hi  r10,r1
bt/s.L345
add #-22,r1  <<< r1 reused

after:
mov r0,r1<<< inital load of r1
add #-65,r1
cmp/hi  r10,r1
mov r0,r1<<< r1 reloaded again
bt/s.L345
add #-87,r1  <<< bigger constant


But as you said, there are only a few cases throughout CSiBE, so it doesn't
seem worth the trouble.

> 
> diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md
> index 557a0f0..ad39a3c 100644
> --- a/gcc/config/sh/sh.md
> +++ b/gcc/config/sh/sh.md
> @@ -2236,6 +2236,23 @@
>  }
>[(set_attr "type" "arith")])
>  
> +;; Old reload might generate add insns directly for the memory address
> +;; of complex insns like synchronization insns when reloading.
> +(define_insn_and_split "*addsi3"
> +  [(set (match_operand:SI 0 "arith_reg_dest" "=r")
> + (plus:SI (match_operand:SI 1 "arith_reg_operand" "r")
> +  (match_operand:SI 2 "const_int_operand" "I08")))]
> +  "TARGET_SH1 && !sh_lra_p ()
> +   && reload_completed
> +   && !reg_overlap_mentioned_p (operands[0], operands[1])"
> +  "#"
> +  "&& reload_completed"
> +  [(set (match_dup 0) (match_dup 1))
> +   (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
> +{
> +}
> +  [(set_attr "type" "arith")])
> +
>  (define_insn_and_split "*addsi3"
>[(set (match_operand:SI 0 "arith_reg_dest" "=r,r")
>   (plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r")
> 
> though I'm not sure that it's ok to add that hack to fix this corner
> case.

I don't have any alternative ideas either.  However, I think it's better to
also allow reg = reg + reg, instead of only allowing reg = reg + imm8:

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 230158)
+++ gcc/config/sh/sh.md (working copy)
@@ -2236,7 +2236,22 @@
 }
   [(set_attr "type" "arith")])

+
+;; Old reload might generate add insns directly (not through the expander) for
+;; for the memory address of complex insns like atomic insns when reloading.
 (define_insn_and_split "*addsi3"
+  [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+   (plus:SI (match_operand:SI 1 "arith_reg_operand" "r")
+(match_operand:SI 2 "const_int_operand" "rI08")))]
+  "TARGET_SH1 && !sh_lra_p ()
+   && reload_completed
+   && !reg_overlap_mentioned_p (operands[0], operands[1])"
+  "#"
+  "&& 1"
+  [(set (match_dup 0) (match_dup 1))
+   (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))])
+
+(define_insn_and_split "*addsi3"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r,r")
(plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r")
 (match_operand:SI 2 "arith_operand" "rI08,Z")))]

I haven't read reload.*, but my speculation is that if something in reload
instantiates that rtx with an imm8 constant to calculate addresses, it might
also try to instantiate it with reg = reg + reg if the constant doesn't fit
into imm8.  Maybe we just don't hit the case (yet).  So it's probably safer to
allow reg = reg + reg, too.


>  There are two "new" failures with gcc testsuite:
> 
> FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (internal compiler error)
> FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (test for excess errors)
> 
> which is not really new because these errors have popped up randomly
> in our testresults.  After all, unfortunately, some SH synchronization
> insns are too complex for the old reload.  You can avoid this PR and
> c11-atomic-exec-4.c ICE with -mlra.

I guess those "new" failures are R0 related?

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

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

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

Bug ID: 68295
   Summary: internal compiler error / segmentation fault
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tho...@maier-komor.de
  Target Milestone: ---

Created attachment 36688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36688&action=edit
file to reproduce the segv

g++ terminates on SegV and gives following message, when compiling the attached
file with following command line:

$ g++ -c -O2 -g gccbug.i
gccbug.cc:30:2: interner Compiler-Fehler: Segmentation fault
  cout << endl << "unknown: " << dec << unknown << '/' << total << '=' <<
(double)unknown/(double)total*100.f << '%' << endl;
  ^
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Siehe  für nähere Anweisungen.



The bug appears on CygWin:
$ uname -a
CYGWIN_NT-6.1 LMUC569133 2.3.0(0.291/5/3) 2015-11-09 10:24 x86_64 Cygwin

[Bug tree-optimization/58497] SLP vectorizes identical operations

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Index: gcc/tree-vect-generic.c
===
--- gcc/tree-vect-generic.c (revision 230146)
+++ gcc/tree-vect-generic.c (working copy)
@@ -105,6 +106,15 @@ static inline tree
 tree_vec_extract (gimple_stmt_iterator *gsi, tree type,
  tree t, tree bitsize, tree bitpos)
 {
+  if (TREE_CODE (t) == SSA_NAME)
+{
+  gimple *def_stmt = SSA_NAME_DEF_STMT (t);
+  if (is_gimple_assign (def_stmt)
+ && (gimple_assign_rhs_code (def_stmt) == VECTOR_CST
+ || (bitpos
+ && gimple_assign_rhs_code (def_stmt) == CONSTRUCTOR)))
+   t = gimple_assign_rhs1 (def_stmt);
+}
   if (bitpos)
 {
   if (TREE_CODE (type) == BOOLEAN_TYPE)

should fix it (in testing).

[Bug tree-optimization/68294] gcc cannot deduce (a | b) != 0 from (a != 0 && b != 0)

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Please always include a compilable testcase so everyone doesn't have to
reinvent one from your explanations.

Gcc knows that u|v is not 0 (from VRP), but does not take advantage of that
information in this case.

[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to Dominique d'Humieres from comment #14)
> > Quick temporary fix is easy, just make pragma_kind in cp/parser.h 8 bit,
> > and change id < 64 to id < 256 in c-family and update the comment.
> > This I believe shouldn't make the C++ token any larger.
> > And then incrementally we can improve this by dropping pragma_kind.
> 
> I have successfully bootstrapped r230151 with the following patch
> 
> --- ../_clean/gcc/cp/parser.h 2015-11-10 01:54:44.0 +0100
> +++ gcc/cp/parser.h   2015-11-11 12:10:28.0 +0100
> @@ -48,7 +48,7 @@ struct GTY (()) cp_token {
>/* Token flags.  */
>unsigned char flags;
>/* Identifier for the pragma.  */
> -  ENUM_BITFIELD (pragma_kind) pragma_kind : 6;
> +  ENUM_BITFIELD (pragma_kind) pragma_kind : 8;
>/* True if this token is from a context where it is implicitly extern "C"
> */
>BOOL_BITFIELD implicit_extern_c : 1;
>/* True if an error has already been reported for this token, such as a
> --- ../_clean/gcc/c-family/c-pragma.c 2015-11-10 01:54:43.0 +0100
> +++ gcc/c-family/c-pragma.c   2015-11-11 12:10:25.0 +0100
> @@ -1372,7 +1372,7 @@ c_register_pragma_1 (const char *space, 
>  
>/* The C++ front end allocates 6 bits in cp_token; the C front end
>allocates 7 bits in c_token.  At present this is sufficient.  */
> -  gcc_assert (id < 64);
> +  gcc_assert (id < 256);
>  }
>  
>cpp_register_deferred_pragma (parse_in, space, name, id,
> 
> I let people understanding the problem update the comment. IMO the comment
> should include a pointer to "ENUM_BITFIELD (pragma_kind) pragma_kind : n;"
> when updating the assert to 2**n. It would also be interesting to know how
> many pragmas can be added before reaching the limit.

With proper ChangeLog entry and changing the 6 bits to 8 bits and 7 bits also
to 8 bits in the comment about the assert this is ok for trunk, but please post
the patch to gcc-patches.

[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Quick temporary fix is easy, just make pragma_kind in cp/parser.h 8 bit,
> and change id < 64 to id < 256 in c-family and update the comment.
> This I believe shouldn't make the C++ token any larger.
> And then incrementally we can improve this by dropping pragma_kind.

I have successfully bootstrapped r230151 with the following patch

--- ../_clean/gcc/cp/parser.h   2015-11-10 01:54:44.0 +0100
+++ gcc/cp/parser.h 2015-11-11 12:10:28.0 +0100
@@ -48,7 +48,7 @@ struct GTY (()) cp_token {
   /* Token flags.  */
   unsigned char flags;
   /* Identifier for the pragma.  */
-  ENUM_BITFIELD (pragma_kind) pragma_kind : 6;
+  ENUM_BITFIELD (pragma_kind) pragma_kind : 8;
   /* True if this token is from a context where it is implicitly extern "C" */
   BOOL_BITFIELD implicit_extern_c : 1;
   /* True if an error has already been reported for this token, such as a
--- ../_clean/gcc/c-family/c-pragma.c   2015-11-10 01:54:43.0 +0100
+++ gcc/c-family/c-pragma.c 2015-11-11 12:10:25.0 +0100
@@ -1372,7 +1372,7 @@ c_register_pragma_1 (const char *space, 

   /* The C++ front end allocates 6 bits in cp_token; the C front end
 allocates 7 bits in c_token.  At present this is sufficient.  */
-  gcc_assert (id < 64);
+  gcc_assert (id < 256);
 }

   cpp_register_deferred_pragma (parse_in, space, name, id,

I let people understanding the problem update the comment. IMO the comment
should include a pointer to "ENUM_BITFIELD (pragma_kind) pragma_kind : n;" when
updating the assert to 2**n. It would also be interesting to know how many
pragmas can be added before reaching the limit.

[Bug tree-optimization/58497] SLP vectorizes identical operations

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Wed, 11 Nov 2015, ro at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58497
> 
> --- Comment #8 from Rainer Orth  ---
> Created attachment 36687
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36687&action=edit
> -fdump-tree-dom2-details dump

Ok, it's not supposed to look like this after lowering.  Does SPARC
not have an integer multiply instruction (SImode)?  Then the
FAIL is expected (though folding halfway does the transform anyway...).

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #29 from Alexander Cherepanov  ---
On 2015-11-11 14:57, ebotcazou at gcc dot gnu.org wrote:
>> Are you saying that -fstack-check is ready for use? Why it's not
>> documented (except for Ada and in gccint)?
>
> !???  See 3.18 Options for Code Generation Conventions in the manual.

Ouch. Searching in Google for 'fstack-check gcc', gnat and gccint are 
the first hits but Code-Gen-Options is not on the first page. (For other 
options it usually works quite well.) And looking for it in the manual 
near -fstack-protector, i.e. in "3.10 Options That Control 
Optimization", doesn't find anything. I should have tried Option Index 
at least. It's documented even for gcc 2.95.3.

>> According to comments[1][2] by Florian Wiemer (cc'd) in 2013 it's not
>> production-ready and "used to be rather buggy". Is this changed?
>>
>> [1] https://gcc.gnu.org/ml/gcc-patches/2013-09/msg01176.html
>> [2] http://www.openwall.com/lists/oss-security/2013/01/23/4
>
> Yes, at least on mainstream architectures (x86, x86-64, Alpha, MIPS, SPARC,
> PowerPC, IA-64).  ARM and AArch64 need the PR middle-end/65958 changes.

Cool! One more question, if you don't mind: which version of gcc do I 
need for this -- is 4.9.2 ok or 5 is required? Links to additional info 
would be appreciated.

[Bug tree-optimization/58497] SLP vectorizes identical operations

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Created attachment 36687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36687&action=edit
-fdump-tree-dom2-details dump

[Bug tree-optimization/58497] SLP vectorizes identical operations

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Rainer Orth from comment #6)
> The new gcc.dg/tree-ssa/vector-5.c testcase FAILs on 64-bit Solaris/SPARC:
> 
> FAIL: gcc.dg/tree-ssa/vector-5.c scan-tree-dump-times optimized " * 3;" 1
> 
>   Rainer

  :
  v1_2 = {i_1(D), i_1(D), i_1(D), i_1(D)};
  _6 = i_1(D);
  _7 = i_1(D) * 3;
  _8 = i_1(D);
  _9 = i_1(D) * 3;
  _10 = i_1(D);
  _11 = i_1(D) * 3;
  _12 = i_1(D);
  _13 = i_1(D) * 3;
  _3 = {_7, _9, _11, _13};

err, why would DOM which runs after lower_vector_ssa _not_ CSE those
multiplications?  Pleas attach dom2-details dumps.

[Bug target/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE on arm-none-eabi

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #10 from Jiong Wang  ---
fixed, r230158.