[Bug target/69617] PowerPC/e6500: Atomic byte/halfword operations not properly supported

[sebastian.hu...@embedded-brains.de]

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

--- Comment #2 from Sebastian Huber  ---
Yes, sorry, I meant the load with reservation and store conditional
instructions.

[Bug c++/70558] New: POD datatype array crash in initialization when using optimization

[hlprasu at gmail dot com]

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

Bug ID: 70558
   Summary: POD datatype array crash in initialization when using
optimization
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hlprasu at gmail dot com
  Target Milestone: ---

Created attachment 38197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38197=edit
Contains example code to reproduce this problem

I have created a simple POD class named Double, which encapsulates 'double'
type so that comparison operators can be handled in a numerically correct
fashion. This is in the attached .tar.gz file.

My problem is that if a create a fixed array with it and try to initialize all
elements in a single statement then it crashes only when optimization is
enabled.

E.g.:

Double v[3];

v[0] = v[1] = v[2] = 0.0; // <- crash here with -O or -O2 or -O3

Funnily enough, this does not crash if you do
v[0] = 0.0;
v[1] = 0.0;
v[2] = 0.0;


To reproduce this error,
1. Untar the attached file and go to the directory

   tar -xvzf double-pod-crash.tar.gz
   cd double-pod-crash/

2. Run 'make' and execute the test file.

   make
   ./test # <- This segfaults at the above statement

I saw the crash to be at the above statement by using gdb after recompiling
with -g option.

Please let me know a solution to this problem.

[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1

[ppalka at gcc dot gnu.org]

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

--- Comment #12 from Patrick Palka  ---
Turns out that a single line of code is responsible for the 50MB increase in
memory usage relative to 4.9, and that's the call to unshare_expr in
cxx_eval_call_expression:

  /* Associate the bindings with the remapped parms.  */
  tree bound = new_call.bindings;
  tree remapped = parms;
  while (bound)
{
  tree oparm = TREE_PURPOSE (bound);
  tree arg = TREE_VALUE (bound);
  gcc_assert (DECL_NAME (remapped) == DECL_NAME (oparm));
  /* Don't share a CONSTRUCTOR that might be changed.  */
  arg = unshare_expr (arg);  // <---
  ctx->values->put (remapped, arg);
  bound = TREE_CHAIN (bound);
  remapped = DECL_CHAIN (remapped);
}

We unshare each function argument unconditionally even though it's only
necessary to do so for CONSTRUCTORs.  This apparently creates a lot of garbage.
 I wonder if guarding the unsharing with "TREE_CODE (arg) == CONSTRUCTOR" would
be sufficient?

[Bug other/70557] uint64_t zeroing on 32-bit hardware

[acahalan at gmail dot com]

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

--- Comment #1 from Albert Cahalan  ---
For the 32-bit i386, gcc 4.8.4 doesn't zero a pair of registers. I doubt gcc is
doing the best for -Os regarding addressing, but at least the i386 is getting
better code than the m68k coldfire.

[Bug target/69617] PowerPC/e6500: Atomic byte/halfword operations not properly supported

[scottwood at freescale dot com]

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

Scott wood  changed:

   What|Removed |Added

 CC||scottwood at freescale dot com

--- Comment #1 from Scott wood  ---
Decorated storage (lbdx and such) requires cache-inhibited memory, and the
operations are defined by each SoC rather than by the e6500 core -- this makes
it unusable by GCC.  The non-decorated l[bh]arx/st[bh]cx. could be used,
though.

[Bug c++/70512] [6 Regression] ICE on valid code on x86_64-linux-gnu: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #7 from Nathan Sidwell  ---
Fixed r234768.

[Bug c++/70512] [6 Regression] ICE on valid code on x86_64-linux-gnu: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Tue Apr  5 23:47:21 2016
New Revision: 234768

URL: https://gcc.gnu.org/viewcvs?rev=234768=gcc=rev
Log:
PR c++/70512
* class.c (fixup_may_alias): New.
(fixup_attribute_variants): Call it.

* g++.dg/ext/attribute-may-alias-5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/attribute-may-alias-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[jmargetts at ocz dot com]

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

--- Comment #20 from Julien Margetts  ---
It is the gcc_assert (REG_P (operands[0])); in arm_reload_in_hi which fires,
which as far as I can see is still in trunk today.

At this point rtx operands[0] looks like this:

08 2d c2 7a 53 2b 00 00

The first pass through this code (no assert) looks like this:

80 b8 c1 7a 53 2b 00 00 

NOTE: This was recreated by merging both patches from trunk into otherwise
unchanged 4.9.3 release sources, as I am trying to back port this fix to 4.9.3

[Bug other/70557] New: uint64_t zeroing on 32-bit hardware

[acahalan at gmail dot com]

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

Bug ID: 70557
   Summary: uint64_t zeroing on 32-bit hardware
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acahalan at gmail dot com
  Target Milestone: ---

Created attachment 38196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38196=edit
C source, gcc 5.3.0 assembly output, IDA Pro disassembly

This is C with gcc 5.3.0 targeting the MCF5272 coldfire (m68k w/o alignment
constraint).

To clear 8 bytes of memory, gcc should always issue a pair of clr.L
instructions. 

This applies both when the address is known to the linker (the address should
be contained in an instruction that loads an address register) and when the
address is supplied as a function argument (the address should be loaded into a
register which the clr.L will then use).

Because the hardware is 32-bit, a 64-bit value should be handled the same as a
pair of 32-bit values. Because there is no alignment requirement, 8 adjacent
8-bit values (total of 64 bits) should likewise be handled the same.

All 6 cases (3 access sizes times 2 ways to address the data) are shown in the
provided attachment. Only one of the 6 cases seems optimal, the one named
"clear32p" which takes a pointer to a pair of 32-bit values as a function
argument. The case named "clear32", referring to global data, isn't bad... but
really the address should be loaded into an address register to save 2 bytes.

Though not the worst for performance (that honor going to the 8-bit functions),
the 64-bit functions are particularly painful to look at. With these, gcc
clears out two different registers and then moves both of them into memory. An
obvious optimization would be to clear only a single register and use it twice.
Another obvious optimization would be to directly clear the memory via a clr.L
that uses memory addressing, either absolute or register-based as appropriate,
though loading an address register is even better.

In any case, the 6 functions in this example should compile to 2 distinct kinds
of result. The access size should not change the resulting assembly.

[Bug c++/70556] ICE in cxx_eval_vec_init_1 on a ill-formed lambda capture of a VLA in a template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Blocks||16994
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
This is only tangentially related to VLAs in that the immediate cause apparent
from the stack trace is cxx_eval_vec_init_1() making the assumption that the
upper bound of the VLA is a constant expression.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++

[Bug c++/70018] [4.9/5/6 Regression] Possible issue around IPO and C++ comdats discovered as pure/const

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
Created attachment 38195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38195=edit
Patch I am testing

This patch handles const->pure transition for all functions detected const that
are not necessarily binding to current def. I think this is best we can do
without tracking down constness from the FE (i.e. before the folding).
The patch tries to be careful to optimize some cases (such as take into account
that inlined functions will bind locally).

I will try to collect some data on code quality effect.

[Bug c++/70556] New: ICE in cxx_eval_vec_init_1 on a ill-formed lambda capture of a VLA in a template

[msebor at gcc dot gnu.org]

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

Bug ID: 70556
   Summary: ICE in cxx_eval_vec_init_1 on a ill-formed lambda
capture of a VLA in a template
   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: ---

The following ill-formed snippet causes an ICE with today's trunk of GCC 6.0
and all prior versions.  In case someone wonders, I ran into it by accident (by
making a typo while writing a test case for a different bug), not by
deliberately trying to break things.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -xc++ t.c
template 
int f (int n)
{
  int x[1][n];

  return [x[0]] /* () { return 0; } */; 
}

int i = f<1>(1);
t.c: In function ‘int f(int)’:
t.c:6:12: error: expected ‘,’ before ‘[’ token
   return [x[0]] /* () { return 0; } */;
^
t.c:6:12: error: expected identifier before ‘[’ token
t.c: In lambda function:
t.c:6:39: error: expected ‘{’ before ‘;’ token
   return [x[0]] /* () { return 0; } */;
   ^
t.c: In instantiation of ‘int f(int) [with int N = 1]’:
t.c:9:15:   required from here
t.c:4:7: warning: ISO C++ forbids variable length array [-Wvla]
   int x[1][n];
   ^
t.c:6:10: internal compiler error: in tree_to_uhwi, at tree.c:7345
   return [x[0]] /* () { return 0; } */;
  ^
0x11504c5b tree_to_uhwi(tree_node const*)
/src/gcc/trunk/gcc/tree.c:7345
0x106f2157 cxx_eval_vec_init_1
/src/gcc/trunk/gcc/cp/constexpr.c:2469
0x106f242f cxx_eval_vec_init_1
/src/gcc/trunk/gcc/cp/constexpr.c:2521
0x106f29d3 cxx_eval_vec_init
/src/gcc/trunk/gcc/cp/constexpr.c:2591
0x106f8ffb cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3872
0x106fa4af cxx_eval_outermost_constant_expr
/src/gcc/trunk/gcc/cp/constexpr.c:4110
0x106fb2cb maybe_constant_value_1
/src/gcc/trunk/gcc/cp/constexpr.c:4298
0x106fb487 maybe_constant_value(tree_node*, tree_node*)
/src/gcc/trunk/gcc/cp/constexpr.c:4322
0x106fb9f3 fold_non_dependent_expr(tree_node*)
/src/gcc/trunk/gcc/cp/constexpr.c:4401
0x1046d70b massage_init_elt
/src/gcc/trunk/gcc/cp/typeck2.c:1229
0x1046e6f7 process_init_constructor_record
/src/gcc/trunk/gcc/cp/typeck2.c:1401
0x1046f66f process_init_constructor
/src/gcc/trunk/gcc/cp/typeck2.c:1609
0x1046cdab digest_init_r
/src/gcc/trunk/gcc/cp/typeck2.c:1123
0x1046d04b digest_init(tree_node*, tree_node*, int)
/src/gcc/trunk/gcc/cp/typeck2.c:1162
0x10601473 finish_compound_literal(tree_node*, tree_node*, int)
/src/gcc/trunk/gcc/cp/semantics.c:2732
0x106d7307 build_lambda_object(tree_node*)
/src/gcc/trunk/gcc/cp/lambda.c:114
0x104346ef tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/src/gcc/trunk/gcc/cp/pt.c:17123
0x1042c083 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/src/gcc/trunk/gcc/cp/pt.c:15802
0x10425f4b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/src/gcc/trunk/gcc/cp/pt.c:15114
0x10425e73 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/src/gcc/trunk/gcc/cp/pt.c:15104
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/46002] ICE: in update_copy_costs, at ira-color.c:319 with -fira-algorithm=priority

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Manuel López-Ibáñez  ---
No answer in years, closing.

[Bug target/45683] Segmentation fault on large unsigned integer values in C99 mode

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 CC||manu at gcc dot gnu.org
Version|4.4.2   |6.0
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
Still fails with 6.0

[Bug c++/14379] accepts invalid duplicate definition of member template

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |
   Last reconfirmed|2012-01-22 00:00:00 |2016-4-5
 CC||manu at gcc dot gnu.org
Summary|ICE in tsubst with  |accepts invalid duplicate
   |declaring then defining a   |definition of member
   |member template |template

--- Comment #4 from Manuel López-Ibáñez  ---
Not an ICE.

[Bug c/8960] invalid error mode `SI' applied to inappropriate type

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |
   Last reconfirmed|2008-12-06 09:37:22 |2016-4-5
Version|3.3 |6.0
Summary|Segfault with __attribute__ |invalid error mode `SI'
   |((mode (...))) in   |applied to inappropriate
   |start_function:5702 |type

--- Comment #13 from Manuel López-Ibáñez  ---
Not an ICE

[Bug c++/69733] -Wignored-qualifiers points to wrong const

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug other/8757] GCC crash when sizeof (long) > sizeof (char *), (splay_tree_compare_fn)strcmp is wrong

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Manuel López-Ibáñez  ---
It seems this was fixed a long time ago. Oldest ICE-on-valid!

[Bug c++/70555] ICE in expand_expr_real_1 accessing a multi-dimensional VLA via lambda-capture

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Actually, I did find where N3366
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html) disallows
the test case in vla7.C:

Change in 8.3.4 dcl.array paragraph 1 ...:

In a declaration T D where D has the form

   D1 [ expression opt ] attribute-specifier-seq opt

and the type of the identifier in the declaration T D1 is
"derived-declarator-type-list T", then the type of the identifier of D is an
array type; [...] T is called the array element type; this type shall not be a
[...] an array of unknown or runtime bound...

According to this specification (which was never ratified and ended up being
removed from the final C++ standard), the test case in comment #0 would also be
ill-formed.  Yet, GCC accepts such VLAs in most (all?) other contexts, so I'm
not sure that rejecting them here is helpful (though it certainly is
inconsistent).

I'm going to leave this as ice-on-valid code since as long as such arrays are
accepted in other contexts I think it makes sense to accept it here (and also
in vla7.C).

[Bug c++/70555] ICE in expand_expr_real_1 accessing a multi-dimensional VLA via lambda-capture

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Blocks||16994
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
Based on the dg-error directive, vla7.C is apparently invalid (though I'm not
sure I see support for it being invalid in the WG21 N3366 referenced in the
error message printed by GCC), but this test case seems valid to me.  Hence
ice-on-valid-code.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++

[Bug c++/70555] New: ICE in expand_expr_real_1 accessing a multi-dimensional VLA via lambda-capture

[msebor at gcc dot gnu.org]

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

Bug ID: 70555
   Summary: ICE in expand_expr_real_1 accessing a
multi-dimensional VLA via lambda-capture
   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: ---

The following test case derived from g++.dg/cpp1y/vla7.C causes an ICE in
todays's trunk of 6.0 as well as in 5.x and 4.9.3. 

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -xc++ t.c
int f (int n)
{
  int x[n][n];

  [](int i) { 
x[0][i] = 0;
  }(5);
}

t.c: In function ‘int f(int)’:
t.c:3:13: warning: ISO C++ forbids variable length array ‘x’ [-Wvla]
   int x[n][n];
 ^
t.c:3:13: warning: ISO C++ forbids variable length array ‘x’ [-Wvla]
t.c:8:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^
t.c: In lambda function:
t.c:5:15: warning: ‘’ is used uninitialized in this function
[-Wuninitialized]
   [](int i) {
   ^
t.c:6:11: warning: ‘’ is used uninitialized in this function
[-Wuninitialized]
 x[0][i] = 0;
 ~~^
t.c:5:15: internal compiler error: in expand_expr_real_1, at expr.c:9651
   [](int i) {
   ^
0x10a80e1f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:9645
0x10a77f2f expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:7962
0x10a56cf7 expand_expr
/src/gcc/trunk/gcc/expr.h:256
0x10a7939f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/src/gcc/trunk/gcc/expr.c:8181
0x1087a59b expand_gimple_stmt_1
/src/gcc/trunk/gcc/cfgexpand.c:3654
0x1087a8eb expand_gimple_stmt
/src/gcc/trunk/gcc/cfgexpand.c:3714
0x1088403f expand_gimple_basic_block
/src/gcc/trunk/gcc/cfgexpand.c:5720
0x10886267 execute
/src/gcc/trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/65173] ICE while compiling wrong code

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
Further reduced test:

  implicit none
  type :: param_t
 character(1), dimension(256), allocatable :: names
  end type param_t
end

% gfc-trunk pr65173.f90
pr65173.f90:3:55:

  character(1), dimension(256), allocatable :: names
   1
Error: Allocatable component of structure at (1) must have a deferred shape
f951: internal compiler error: gfc_resolve_expr(): Bad expression type
0x824c5e3 gfc_internal_error(char const*, ...)
../../trunk/gcc/fortran/error.c:1314
0x82b8817 gfc_resolve_expr(gfc_expr*)
../../trunk/gcc/fortran/resolve.c:6409
0x82c15ed resolve_index_expr
../../trunk/gcc/fortran/resolve.c:10958
0x82c16df resolve_charlen
../../trunk/gcc/fortran/resolve.c:11003
0x82c621d resolve_fl_derived0
../../trunk/gcc/fortran/resolve.c:13208
0x82c6bf7 resolve_fl_derived
../../trunk/gcc/fortran/resolve.c:13413
0x82c7656 resolve_symbol
../../trunk/gcc/fortran/resolve.c:13687
0x82de443 do_traverse_symtree
../../trunk/gcc/fortran/symbol.c:3817
0x82cb17f resolve_types
../../trunk/gcc/fortran/resolve.c:15476
0x82cb550 gfc_resolve(gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:15586
0x82a6718 resolve_all_program_units
../../trunk/gcc/fortran/parse.c:5552
0x82a6718 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:5804
0x82f40f5 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:201

[Bug c++/70336] [5 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 regression] Incorrect  |[5 regression] Incorrect
   |Wconversion warning |Wconversion warning

--- Comment #12 from Jakub Jelinek  ---
Fixed for 6+.

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  5 21:33:37 2016
New Revision: 234764

URL: https://gcc.gnu.org/viewcvs?rev=234764=gcc=rev
Log:
PR c++/70336
* match.pd (nested int casts): Limit to GIMPLE.

* c-c++-common/pr70336.c: New test.
* gcc.dg/torture/builtin-isinf_sign-1.c (foo): Guard tests
no longer optimized away at -O0 with #ifndef __OPTIMIZE__.

Added:
trunk/gcc/testsuite/c-c++-common/pr70336.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/builtin-isinf_sign-1.c

[Bug ipa/66223] [5 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  ---
Author: hubicka
Date: Tue Apr  5 20:58:56 2016
New Revision: 234762

URL: https://gcc.gnu.org/viewcvs?rev=234762=gcc=rev
Log:

PR ipa/66223
* ipa-devirt.c (maybe_record_node): Fix comment; use
SANITIZE_UNREACHABLE instead of SANITIZE_UNDEFINED.

* g++.dg/ipa/devirt-51.C: Use -fsanitize=unreachable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ipa/devirt-51.C

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[softadmin.lesia at obspm dot fr]

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

--- Comment #5 from softadmin.lesia at obspm dot fr ---
finally i can use gcc 4.9 

thanks

[Bug c++/70552] __builtin_constant_p fails to reflect the constness of constexpr calls

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
As an aside, Clang does evaluate both __builtin_constant_p(foo()) expressions
in the test case consistently to 1, and like GCC, also without emitting code
for foo().  Also like GCC, it emits a definition of foo() if it's called in the
program outside of a constexpr context (such as the __builtin_constant_p
argument).

[Bug c++/70552] __builtin_constant_p fails to reflect the constness of constexpr calls

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Yes, thanks for pointing that out.  I think the change is r233671.  I certainly
agree that it's useful to be able to step through constexpr functions in
non-constexpr contexts.  In the test case below, however, the definition of
foo() isn't emitted into the object file so it cannot be stepped into.  The
builtin simply returns the wrong result.  I hope we can make it so that it
returns the useful result I described in comment #0 while still maintaining the
useful debuggability outside of constexpr contexts.

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
In this case, the code was deliberately written this way, presumably to avoid
the branching in &&. Using & would be better (and that's what I am suggesting
we optimize it to), but * doesn't seem nonsensical to me. (we can still add a
warning if you want)

PR 45780 seems to be about something completely different, and the code here
would not trigger the warning requested there (the result is the same if we
replace bool by int everywhere).

[Bug libstdc++/70554] [6 Regression] _GLIBCXX_ATOMIC_BUILTINS changed value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Done.

[Bug libstdc++/70554] [6 Regression] _GLIBCXX_ATOMIC_BUILTINS changed value

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr  5 19:03:46 2016
New Revision: 234761

URL: https://gcc.gnu.org/viewcvs?rev=234761=gcc=rev
Log:
Restore atomic builtins usage in libstdc++-v3

PR libstdc++/70554
* acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Don't test
__atomic_fetch_add for bool.
* configure: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/configure

[Bug target/70510] ICE: output_operand: invalid %-code with -mavx512bw -masm=intel when emitting vpbroatcast

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  5 18:48:26 2016
New Revision: 234760

URL: https://gcc.gnu.org/viewcvs?rev=234760=gcc=rev
Log:
PR target/70510
* config/i386/sse.md (iptr): Add V16SI and V8DI modes.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/sse.md

[Bug target/70510] ICE: output_operand: invalid %-code with -mavx512bw -masm=intel when emitting vpbroatcast

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|kyukhin at gcc dot gnu.org |ubizjak at gmail dot com
   Target Milestone|--- |5.4

--- Comment #7 from Uroš Bizjak  ---
Fixed everywhere.

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
Hum, perhaps we should warn about such nonsense code, as suggested in PR45780:

warning: arithmetic applied to boolean expression
   return (a

[Bug c/70475] -Wmisleading-indentation quetionable in Eigen

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > See discussion in PR69415.
> 
> Sorry wrong bug number. 
> IMHO it is OK to warn for the code above.

I also agree with this and I think the warning seems appropriate. An even
clearer case:

   if (a) not_error();
  goto everything_ok;
   goto error;


or what about:

if (a)
   not_error();
   goto everything_ok;
goto error;

This is not Python! :-)

Note that you can easily silence the warning with explicit braces.

I think we discussed adding a heuristic for column 1 such that we would not
warn for:

else
do_stuff();
more_stuff();
if (a)  do_stuff();
more_stuff();

However, I'm not sure it was ever added.

[Bug c++/70551] member function of template instantiated even though only declaration is needed

[rbock at eudoxos dot de]

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

--- Comment #2 from Roland B  ---
(In reply to Jonathan Wakely from comment #1)
> Your interpretation would mean that whether a compiler performs copy elision
> would change whether a program is well-formed or not (rather than only
> changing whether any side effects of the constructor call happen). That is
> not a reasonable interpretation IMHO.

I see your point, but when I remove the definition from the code, it compiles
just fine, because the definition is irrelevant in case of copy elision.

So I could have the move constructor's declaration in file A and the definition
in file B. If the definition is irrelevant, why would it matter whether or not
I include the file B containing the definition?

[Bug target/70510] ICE: output_operand: invalid %-code with -mavx512bw -masm=intel when emitting vpbroatcast

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  5 18:03:55 2016
New Revision: 234758

URL: https://gcc.gnu.org/viewcvs?rev=234758=gcc=rev
Log:
PR target/70510
* config/i386/sse.md (iptr): Add V64QI, V32HI, V16SI and V8DI modes.

testsuite/ChangeLog:

PR target/70510
* gcc.target/i386/pr70510.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr70510.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/sse.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/70554] [6 Regression] _GLIBCXX_ATOMIC_BUILTINS changed value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug c++/70552] __builtin_constant_p fails to reflect the constness of constexpr calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I believe that has been intentional change not to "inline" constexpr functions
in non-constexpr contexts, unless inlining is enabled, so that one can actually
step through them etc.

[Bug libstdc++/70554] [6 Regression] _GLIBCXX_ATOMIC_BUILTINS changed value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-05
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug libstdc++/70554] New: [6 Regression] _GLIBCXX_ATOMIC_BUILTINS changed value

[redi at gcc dot gnu.org]

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

Bug ID: 70554
   Summary: [6 Regression] _GLIBCXX_ATOMIC_BUILTINS changed value
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01159.html observes that r232147
changed the value of _GLIBCXX_ATOMIC_BUILTINS in libstdc++, which affects how
atomic ref-counting is done. Previously most targets used atomics for
ref-counts, but now many targets will use the generic fallback which relies on
a mutex.

Code compiled with previous releases will still be using atomics, but code
compiled with gcc-6 will lock a mutex and then perform a non-atomic
increment/decrement, possibly concurrently with other threads that aren't using
the mutex.

This needs to be fixed for gcc-6.

[Bug testsuite/70553] New: pr70496.c should exclude Thumb only targets

[thopre01 at gcc dot gnu.org]

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

Bug ID: 70553
   Summary: pr70496.c should exclude Thumb only targets
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: ramana.radhakrishnan at arm dot com
  Target Milestone: ---
Target: arm-none-eabi

gcc.target/arm/pr70496.c fails with the following error when targeting
Cortex-M3:

"selected processor does not support ARM opcodes"

Since the test contains a .arm directive, it should skip Thumb only devices.

[Bug libstdc++/70503] [4.9/5 Regression] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
That should be fixed at r234757

[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1

[ppalka at gcc dot gnu.org]

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

--- Comment #11 from Patrick Palka  ---
gcc 5 shows:

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
  1311 kB ( 0%) ggc
 phase parsing   :   2.10 (100%) usr   0.28 (100%) sys   2.37 (100%)
wall  516276 kB (100%) ggc
 |name lookup:   0.03 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall 
83 kB ( 0%) ggc
 |overload resolution:   0.02 ( 1%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
   628 kB ( 0%) ggc
 preprocessing   :   0.01 ( 0%) usr   0.06 (21%) sys   0.06 ( 3%) wall 
  2048 kB ( 0%) ggc
 parser (global) :   0.04 ( 2%) usr   0.04 (14%) sys   0.09 ( 4%) wall 
 16180 kB ( 3%) ggc
 parser function body:   2.05 (98%) usr   0.18 (64%) sys   2.22 (93%) wall 
498040 kB (96%) ggc
 TOTAL :   2.10 0.28 2.38
517605 kB

trunk now shows:

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
  1287 kB ( 1%) ggc
 phase parsing   :   1.31 (100%) usr   0.21 (100%) sys   1.51 (99%)
wall  203649 kB (99%) ggc
 |name lookup:   0.02 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 2%) wall 
81 kB ( 0%) ggc
 |overload resolution:   0.04 ( 3%) usr   0.00 ( 0%) sys   0.04 ( 3%) wall 
   628 kB ( 0%) ggc
 preprocessing   :   0.02 ( 2%) usr   0.08 (38%) sys   0.08 ( 5%) wall 
  2048 kB ( 1%) ggc
 parser (global) :   0.02 ( 2%) usr   0.02 (10%) sys   0.06 ( 4%) wall 
  7735 kB ( 4%) ggc
 parser function body:   1.27 (97%) usr   0.11 (52%) sys   1.37 (90%) wall 
193854 kB (95%) ggc
 TOTAL :   1.31 0.21 1.52
204947 kB

Hmm, peak memory usage is still about 50MB more than 4.9...

[Bug c++/70552] __builtin_constant_p fails to reflect the constness of constexpr calls

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Blocks||55004
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
The test case aborts at runtime with all versions that support constexpr,
though with 5.1 and prior it also fails the second static_assert (i.e., the one
involving __builtin_constant_p), and optimization has no effect on it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/70552] New: __builtin_constant_p fails to reflect the constness of constexpr calls

[msebor at gcc dot gnu.org]

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

Bug ID: 70552
   Summary: __builtin_constant_p fails to reflect the constness of
constexpr calls
   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 testing the __builtin_constant_p() intrinsic to better understand the
motivation for and problems with bug 14505, I discovered that the built-in
doesn't behave as documented for calls to constexpr functions as arguments
except in constexpr contexts, or unless optimization is enabled.  For example,
the following program compiles successfully (i.e., both static assertions pass)
but then aborts at runtime.

Since not every call to a given constexpr function is necessarily a core
constant expression (i.e., a compile-time constant), for the instrinsic to be
useful with C++ constexpr expressions it needs to return the same result for
the same argument regardless of the context in which it's invoked.

This may be related to the problem as pointed out in comment #6 on bug 65656,
though the complaint there seems to be about the built-in yielding false
negatives due to folding non-constexpr expressions too early, while the problem
here seems to be that the built-in isn't attempting to fold the constexpr
function call at all without optimization.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra
-Wpedantic -xc++ t.c  && ./a.out 
constexpr int foo () { return 1; }

#define A(e) static_assert ((e), #e)

A (1 == foo ());
A (1 ==  __builtin_constant_p (foo ()));

int main ()
{
if (!__builtin_constant_p (foo ()))
__builtin_abort ();
}
Aborted

[Bug c++/70513] [4.9/5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
All right, I've got it now: we need to catch the extra qualification, similarly
as in

struct T
{
  struct U;
  struct T::U {};
};

I've got a patch.

[Bug libstdc++/70503] [4.9/5 Regression] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jonathan Wakely from comment #4)
> Fixed on trunk so far.

The testcase probably needs some special handling due to -static, it fails on
Fedora 23 with:

spawn -ignore SIGHUP /ssd/uros/gcc-build/./gcc/xg++ -shared-libgcc
-B/ssd/uros/gcc-build/./gcc -nostdinc++
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/ssd/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/ssd/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++
-I/home/uros/gcc-svn/trunk/libstdc++-v3/include/backward
-I/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/util
/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/30_threads/thread/70503.cc
-std=gnu++11 -static -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm
-o ./70503.exe
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status

FAIL: 30_threads/thread/70503.cc  (test for errors, line 30)
FAIL: 30_threads/thread/70503.cc  (test for errors, line 31)
FAIL: 30_threads/thread/70503.cc (test for excess errors)
Excess errors:
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc

and:

spawn -ignore SIGHUP /ssd/uros/gcc-build/./gcc/xg++ -shared-libgcc
-B/ssd/uros/gcc-build/./gcc -nostdinc++
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -m32
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/ssd/uros/gcc-build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/ssd/uros/gcc-build/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++
-I/home/uros/gcc-svn/trunk/libstdc++-v3/include/backward
-I/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/util
/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/30_threads/thread/70503.cc -m32
-std=gnu++11 -static -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/.libs
-lm -o ./70503.exe
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status

FAIL: 30_threads/thread/70503.cc  (test for errors, line 30)
FAIL: 30_threads/thread/70503.cc  (test for errors, line 31)

[Bug rtl-optimization/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  5 17:05:23 2016
New Revision: 234756

URL: https://gcc.gnu.org/viewcvs?rev=234756=gcc=rev
Log:
PR rtl-optimization/70542
* ree.c (add_removable_extension): For VECTOR_MODE_P punt
if there are any uses other than insn or debug insns.

* gcc.dg/torture/pr70542.c: New test.
* gcc.target/i386/avx2-pr70542.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70542.c
trunk/gcc/testsuite/gcc.target/i386/avx2-pr70542.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70551] member function of template instantiated even though only declaration is needed

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Your interpretation would mean that whether a compiler performs copy elision
would change whether a program is well-formed or not (rather than only changing
whether any side effects of the constructor call happen). That is not a
reasonable interpretation IMHO.

[Bug tree-optimization/70509] wrong code with extract from a v64qi

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  5 17:01:52 2016
New Revision: 234755

URL: https://gcc.gnu.org/viewcvs?rev=234755=gcc=rev
Log:
PR tree-optimization/70509
* simplify-rtx.c (simplify_binary_operation_1) :
Shift HOST_WIDE_INT_1U instead of 1.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c

[Bug c++/67376] [5 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 regression] Comparison |[5 regression] Comparison
   |with pointer to |with pointer to
   |past-the-end of array fails |past-the-end of array fails
   |inside constant expression  |inside constant expression
  Known to fail|6.0 |

--- Comment #19 from Martin Sebor  ---
With the change committed in r234698 this is no longer a GCC 6 regression so
I'm adjusting the regression marker but leaving it for 5 since the change
hasn't been backported to the 5.x branch.

[Bug tree-optimization/70509] wrong code with extract from a v64qi

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  5 16:58:50 2016
New Revision: 234754

URL: https://gcc.gnu.org/viewcvs?rev=234754=gcc=rev
Log:
PR tree-optimization/70509
* tree-ssa-forwprop.c (simplify_bitfield_ref): Use bitsize_int instead
of the vector base type for index.

* gcc.target/i386/avx512bw-pr70509.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr70509.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug libstdc++/70463] always use first element of mutex pool in src/c++11/shared_ptr.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> From https://bugzilla.redhat.com/show_bug.cgi?id=1315388
> 
> 
> const unsigned char mask = 0xf;
> 
> inline unsigned char key(const void* addr)
> { return _Hash_impl::hash(addr) & mask; }
> 
> This always returns 0 when addresses are 4-byte aligned.

Bah, no it doesn't. That's what std::hash does, but not
_Hash_impl::hash.

[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1

[ppalka at gcc dot gnu.org]

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

--- Comment #10 from Patrick Palka  ---
Author: ppalka
Date: Tue Apr  5 16:40:00 2016
New Revision: 234753

URL: https://gcc.gnu.org/viewcvs?rev=234753=gcc=rev
Log:
Fix PR c++/70452 (regression in C++ parsing performance)

gcc/cp/ChangeLog:

PR c++/70452
* constexpr.c (struct fundef_copy): New struct.
(struct fundef_copies_table_t): New struct.
(fundef_copies_table): New static variable.
(maybe_initialize_fundef_copies_table): New static function.
(get_fundef_copy): New static function.
(save_fundef_copy): New static function.
(cxx_eval_call_expression): Use get_fundef_copy, and
save_fundef_copy.
(constexpr_call_table): Add "deletable" GTY marker.

gcc/testsuite/ChangeLog:

PR c++/70452
* g++.dg/ext/constexpr-vla4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ext/constexpr-vla4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70551] New: member function of template instantiated even though only declaration is needed

[rbock at eudoxos dot de]

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

Bug ID: 70551
   Summary: member function of template instantiated even though
only declaration is needed
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbock at eudoxos dot de
  Target Milestone: ---

This code fails to compile:

template
struct X
{
  X(X&&) { static_assert(sizeof(T) < 1, "Intentional Failure"); }
};

auto impl() -> X;
auto test() -> decltype(impl())
{
  return impl();
}

int main()
{
  test();
}

My understanding is that it should compile just fine. I admit, I started a
discussion on stackoverflow for this (see
http://stackoverflow.com/questions/36371571/clang-and-gcc-vs-msvc-and-icc-is-a-static-assert-in-the-copy-move-constructor-r)

Citing from the answer I deem correct:

Copy elision requires declaration of copy/move constructors but doesn't require
definition.
Member function definitions of templates are not instantiated unless their
definitions are required.
If a definition is not instantiated it cannot be tested for being ill-formed.
References:

14.7.1.1 …The implicit instantiation of a class template specialization causes
the implicit instantiation of the declarations, but not of the definitions,
default arguments, or exception-specifications of the class member functions…

14.7.1.2 Unless a member of a class template… has been explicitly instantiated
or explicitly specialized, the specialization of the member is implicitly
instantiated when the specialization is referenced in a context that requires
the member definition to exist…

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Hmm, I can't seem to find a particular commit or PR from a quick scan of the
logs.
But then again, the "insn does not satisfy its constraints" is a fairly common
ICE.

your GCC reports "gcc (Debian/Linaro 4.8.4-1) 4.8.4"
Therefore I'd report it to Linaro.
Christophe, can you help with this?

[Bug target/70510] ICE: output_operand: invalid %-code with -mavx512bw -masm=intel when emitting vpbroatcast

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  5 16:26:40 2016
New Revision: 234752

URL: https://gcc.gnu.org/viewcvs?rev=234752=gcc=rev
Log:
PR target/70510
* config/i386/sse.md (iptr): Add V64QI, V32HI, V16SI and V8DI modes.

testsuite/ChangeLog:

PR target/70510
* gcc.target/i386/pr70510.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr70510.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/70513] [4.9/5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
No, I misunderstood, that would make us accept the code.  But at least I have
simpler testcase:

struct S
{
  enum E : int;
  enum S::E : int { foo } e;
};

[Bug middle-end/70550] -Wuninitialized false positives in OpenMP code

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 38194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38194=edit
gcc6-pr70550.patch

Untested fix.

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[julien.brule at obspm dot fr]

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

--- Comment #3 from julien.brule at obspm dot fr ---
Le 05/04/2016 17:24, ktkachov at gcc dot gnu.org a écrit :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70549
>
> ktkachov at gcc dot gnu.org changed:
>
> What|Removed |Added
> 
>   Target||aarch64
>   Status|UNCONFIRMED |RESOLVED
>   CC||ktkachov at gcc dot gnu.org
>Known to work||4.9.4, 5.3.1, 6.0
>   Resolution|--- |WONTFIX
>Known to fail||4.8.5
>
> --- Comment #2 from ktkachov at gcc dot gnu.org ---
> I can reproduce with 4.8 but not with 4.9 or higher.
> 4.8 is no longer maintained, please try a more recent release.
>

sorry to bother you but i'm stuck with the 4.8
is there a way to make it work ?

thanks

[Bug c/70550] -Wuninitialized false positives in OpenMP code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug c/70550] New: -Wuninitialized false positives in OpenMP code

[jakub at gcc dot gnu.org]

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

Bug ID: 70550
   Summary: -Wuninitialized false positives in OpenMP code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

#ifdef __SIZEOF_INT128__
typedef __int128 T;
#else
typedef long long T;
#endif

void bar (T);
#pragma omp declare target (bar)

void
foo (void)
{
  {
int i;
#pragma omp target defaultmap(tofrom:scalar)/* { dg-bogus "is used
uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target defaultmap(tofrom:scalar)/* { dg-bogus "is used
uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
  {
int i;
#pragma omp target  /* { dg-bogus "is used
uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target  /* { dg-bogus "is used
uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
  {
int i;
#pragma omp target firstprivate (i) /* { dg-warning "is
used uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target firstprivate (j) /* { dg-warning "is
used uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
  {
int i;
#pragma omp target private (i)  /* { dg-bogus "is used
uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target private (j)  /* { dg-bogus "is used
uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
}

shows some warnings that are IMNSHO desirable (explicit uses of firstprivate
clause with uninitialized var), and others where it is undesirable (mostly
implicit clauses).

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64
 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
  Known to work||4.9.4, 5.3.1, 6.0
 Resolution|--- |WONTFIX
  Known to fail||4.8.5

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I can reproduce with 4.8 but not with 4.9 or higher.
4.8 is no longer maintained, please try a more recent release.

[Bug libstdc++/69331] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #14 from Uroš Bizjak  ---
Also fails on alpha [1].

[1] https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg00299.html

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[softadmin.lesia at obspm dot fr]

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

--- Comment #1 from softadmin.lesia at obspm dot fr ---
Created attachment 38193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38193=edit
preprocessed source

[Bug c++/70549] New: insn does not satisfy its constraints aarch64 gcc-4.8

[softadmin.lesia at obspm dot fr]

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

Bug ID: 70549
   Summary: insn does not satisfy its constraints aarch64 gcc-4.8
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: softadmin.lesia at obspm dot fr
  Target Milestone: ---

Hello 

i m hitting that

error: insn does not satisfy its constraints

(insn 1160 16 17 33 (set (reg:SF 1 x1)
(const_double:SF 1.0e+0 [0x0.8p+1])) sparse-iter/src/ccg_res.cpp:71 37
{*movsf_aarch64}
 (nil))

sparse-iter/src/ccg_res.cpp:209:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:411
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


on 

Processor   : AArch64 Processor rev 1 (aarch64)
processor   : 0
model name  : APM X-Gene Mustang board
cpu MHz : 2400.00
fpu : yes

with
gcc (Debian/Linaro 4.8.4-1) 4.8.4


and this command line

g++ -O3 -fPIC -DADD_ -Wall -fopenmp  -std=c++11 -DHAVE_CUBLAS
-DMIN_CUDA_ARCH=200 -I/usr/local/cuda/include -I./include -I./control
-I./sparse-iter/include -I./sparse-iter/control -c -o sparse-iter/src/cbicg.o
sparse-iter/src/cbicg.cpp
sparse-iter/src/ccg_res.cpp: In function ‘magma_int_t
magma_ccg_res(magma_c_matrix, magma_c_matrix, magma_c_matrix*,
magma_c_solver_par*, magma_queue_t)’:

[Bug libstdc++/70463] always use first element of mutex pool in src/c++11/shared_ptr.cc

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Oops, clipboard fail, that's not what I thought I was pasting, this is:

--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -41,7 +41,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 const unsigned char invalid = mask + 1;

 inline unsigned char key(const void* addr)
-{ return _Hash_impl::hash(addr) & mask; }
+{
+  const int zero_bits = __builtin_ctz(alignof(shared_ptr));
+  return _Hash_impl::hash(uintptr_t(addr) >> zero_bits) & mask;
+}

 /* Returns different instances of __mutex depending on the passed address
  * in order to limit contention.

[Bug libstdc++/70463] always use first element of mutex pool in src/c++11/shared_ptr.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This would shift the address right to remove the bits that are always zero:

--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -41,7 +41,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 const unsigned char invalid = mask + 1;

 inline unsigned char key(const void* addr)
-{ return _Hash_impl::hash(addr) & mask; }
+{
+  const int zero_bits = __builtin_ctz(alignof(shared_ptr));
+  return _Hash_impl::hash(addzero_bitsaligned) & mask; }

 /* Returns different instances of __mutex depending on the passed address
  * in order to limit contention.

[Bug libstdc++/69331] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[6 regression] FAIL:|FAIL:
   |20_util/shared_ptr/thread/d |20_util/shared_ptr/thread/d
   |efault_weaktoshared.cc  |efault_weaktoshared.cc
   |execution test  |execution test

--- Comment #13 from Jeffrey A. Law  ---
Based on c#10 and c#11, removing regression marker.  If Jon can get this fixed,
he'd have final say on whether or not to include the fix in gcc-6.

[Bug c++/70513] [4.9/5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I think I see what's happening.  I should have a fix soon.

[Bug c++/70539] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su  ---
(In reply to Marek Polacek from comment #1)
> Dup?
> 
> *** This bug has been marked as a duplicate of bug 70540 ***

Sorry for the noise; it wasn't intentional. The server somehow wasn't
responding, and I clicked submit a second time.

[Bug c/70475] -Wmisleading-indentation quetionable in Eigen

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|UNCONFIRMED
   Assignee|ppalka at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 Ever confirmed|1   |0

--- Comment #4 from Patrick Palka  ---
The fix to PR c/68187 made resolving this PR a bit more complicated.  I'll let
David handle it :)

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Yes, I'm pretty sure it's not a regression.

[Bug libstdc++/70503] [4.9/5 Regression] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[4.9/5/6 Regression] extern |[4.9/5 Regression] extern
   |"C" functions in|"C" functions in
   |src/c++11/thread.cc are |src/c++11/thread.cc are
   |global in libstdc++.a   |global in libstdc++.a
  Known to fail|6.0 |

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[clyon at gcc dot gnu.org]

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

--- Comment #12 from Christophe Lyon  ---
How do people handle this in practice? I mean it's creating a lot of noise when
you are trying to track regressions.

That's the main reason why I refrained from automating sending regression
warnings :)

[Bug tree-optimization/70526] [5 Regression] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||6.0
   Target Milestone|6.0 |5.4
Summary|[6 Regression] GCC 6|[5 Regression] GCC 6
   |miscompiles Firefox JIT |miscompiles Firefox JIT
   |compiler|compiler

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/70526] [5 Regression] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Apr  5 14:26:59 2016
New Revision: 234749

URL: https://gcc.gnu.org/viewcvs?rev=234749=gcc=rev
Log:
2016-04-05  Richard Biener  

PR tree-optimization/70526
* tree-sra.c (build_ref_for_offset): Use prev_base to
extract the alias pointer type.

* g++.dg/torture/pr70526.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr70526.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

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

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

--- Comment #10 from Andreas Schwab  ---
It really affects all targets and is not a new problem.  You can find thousands
of hits on gcc-testresults.

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|target  |libstdc++

--- Comment #9 from Jonathan Wakely  ---
Changing component to libstdc++ since it's not limited to any single target, or
family of targets.

[Bug c/70475] -Wmisleading-indentation quetionable in Eigen

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-05
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Patrick Palka  ---
It doesn't make much sense that we warn for:

if (a) do_stuff();
   do_other_stuff();

but not for

if (a) do_stuff();
do_other_stuff();

or for

if (a) do_stuff();
  do_other_stuff();

So I agree that the warning is questionable.  I'll propose a patch.

[Bug target/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #8 from Bill Seurer  ---
This affects powerpc64 little endian as well but not apparently big endian.

[Bug libstdc++/70503] [4.9/5/6 Regression] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr  5 13:35:32 2016
New Revision: 234746

URL: https://gcc.gnu.org/viewcvs?rev=234746=gcc=rev
Log:
Ensure std::thread helpers have internal linkage

PR libstdc++/70503
* src/c++11/thread.cc (execute_native_thread_routine,
execute_native_thread_routine_compat): Give internal linkage.
* testsuite/30_threads/thread/70503.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/30_threads/thread/70503.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/thread.cc

[Bug libstdc++/70548] New: gdb pretty printers hang and spin cpu in gdb session.

[smark at datto dot com]

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

Bug ID: 70548
   Summary: gdb pretty printers hang and spin cpu in gdb session.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smark at datto dot com
  Target Milestone: ---

Created attachment 38192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38192=edit
stack trace for spinning gdb.

At first I opened this bug, 

https://sourceware.org/bugzilla/show_bug.cgi?id=19894

because I had no idea who owned the pretty printers, they referred me here

gdb spins a cpu and hangs, and the stack trace shows its buried in the pretty
printer. When I disable the pretty printer, I have no problem except that I
can't see my variables in the debugger. :-)

The stack trace is attached.
Thanks.

[Bug testsuite/70520] Incorrect child stack alignment in c-c++-common/asan/clone-test-1.c

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

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

--- Comment #4 from Andreas Schwab  ---
Does this really make a difference?  I think the attribute still applies to the
object, not the type.

[Bug c++/70540] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
*** Bug 70539 has been marked as a duplicate of this bug. ***

[Bug c++/70539] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Dup?

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

[Bug c++/70539] New: ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[webrown.cpp at gmail dot com]

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

Bug ID: 70539
   Summary: ICE on invalid code on x86_64-linux-gnu in
cxx_incomplete_type_diagnostic, at cp/typeck2.c:569
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

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

It is a regression from 5.3.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-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-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160404 (experimental) [trunk revision 234712] (GCC) 
$ 
$ g++-5.3 -c small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:4:8: error: ‘f’ does not name a type
   auto f = [&] { return f; };
^
$ 
$ g++-trunk -c small.cpp
small.cpp: In lambda function:
small.cpp:4:25: error: use of ‘f’ before deduction of ‘auto’
   auto f = [&] { return f; };
 ^
small.cpp:4:25: error: use of ‘foo()::::’ before deduction
of ‘auto’
small.cpp:4:28: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:569
   auto f = [&] { return f; };
^
0x6ce8e3 cxx_incomplete_type_diagnostic(tree_node const*, tree_node const*,
diagnostic_t)
../../gcc-source-trunk/gcc/cp/typeck2.c:569
0x765f99 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/typeck.c:150
0x7c37fc apply_deduced_return_type(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:9226
0x7342a2 cp_parser_lambda_body
../../gcc-source-trunk/gcc/cp/parser.c:10256
0x7342a2 cp_parser_lambda_expression
../../gcc-source-trunk/gcc/cp/parser.c:9756
0x734c9c cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4933
0x736d26 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6690
0x73fe6c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:7988
0x7406c7 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8665
0x740cc5 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8767
0x7415b0 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9055
0x7419ea cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9323
0x742174 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:20793
0x74391b cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:20734
0x752bce cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18604
0x7532b0 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12379
0x7535c1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12248
0x754018 cp_parser_declaration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11860
0x7326db cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10528
0x732ffc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10806
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


void
foo ()
{
  auto f = [&] { return f; };
}

[Bug testsuite/70520] Incorrect child stack alignment in c-c++-common/asan/clone-test-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That is very weird placement of the attribute, then it is array of overaligned
chars rather than aligned array of normal chars.

[Bug testsuite/70520] Incorrect child stack alignment in c-c++-common/asan/clone-test-1.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
It has been fixed upstream by

commit 5e263ef18766b562a05aa6736d6c7ea3c8af3b4e
Author: Reid Kleckner 
Date:   Mon Apr 4 18:27:32 2016 +

Apply suggestion from HJ Lu to avoid misaligned stack in test

Fixes PR27191

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@265322
91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/test/asan/TestCases/Linux/clone_test.cc
b/test/asan/TestCases/Linux/clone_test.cc
index e9c1f16..f6eb261 100644
--- a/test/asan/TestCases/Linux/clone_test.cc
+++ b/test/asan/TestCases/Linux/clone_test.cc
@@ -22,7 +22,7 @@ int Child(void *arg) {

 int main(int argc, char **argv) {
   const int kStackSize = 1 << 20;
-  char child_stack[kStackSize + 1];
+  char __attribute__((aligned(16))) child_stack[kStackSize + 1];
   char *sp = child_stack + kStackSize;  // Stack grows down.
   printf("Parent: %p\n", sp);
   pid_t clone_pid = clone(Child, sp, CLONE_FILES | CLONE_VM, NULL);

[Bug rtl-optimization/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 38191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38191=edit
gcc6-pr70542.patch

Perhaps better fix.  Looking at PR64286, the comment is right, if we change
somehow the definition for VECTOR_MODE_P, we need to make sure all uses are
modified, or none.  But there is tons of reasons why some of them could fail,
e.g. for the copy_needed case there is lots of tests that can fail, but even
for the !copy_needed case it could fail to get recognized etc., and we are
unable to handle all the uses as a single transaction.

[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug rtl-optimization/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 38190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38190=edit
gcc6-pr70542.patch

Untested fix.

[Bug libstdc++/70437] [6 Regression] Instantiation loop with pair and is_constructible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed.

[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15

[chefmax at gcc dot gnu.org]

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

--- Comment #6 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Tue Apr  5 11:52:34 2016
New Revision: 234744

URL: https://gcc.gnu.org/viewcvs?rev=234744=gcc=rev
Log:
Cherry-pick r224315,221379 and r241487 from upstream.

libsanitizer/

PR sanitizer/70474
* asan/asan_mac.cc (GetMacosVersionInternal): Cherry pick
upstream r241487, 221379 and r224315.
(void MaybeReexec): Cherry pick upstream r241487.
* asan/asan_mac.h (enum MacosVersion): Cherry pick upstream r224315.

Modified:
branches/gcc-4_9-branch/libsanitizer/ChangeLog
branches/gcc-4_9-branch/libsanitizer/asan/asan_mac.cc
branches/gcc-4_9-branch/libsanitizer/asan/asan_mac.h

[Bug tree-optimization/70526] [6 Regression] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|rtl-optimization|tree-optimization
   Target Milestone|--- |6.0
Summary|GCC 6 miscompiles Firefox   |[6 Regression] GCC 6
   |JIT compiler|miscompiles Firefox JIT
   ||compiler

--- Comment #7 from Richard Biener  ---
The issue is actually older so I'll backport this with my next batch(es).

[Bug libstdc++/70437] [6 Regression] Instantiation loop with pair and is_constructible

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Apr  5 11:31:30 2016
New Revision: 234743

URL: https://gcc.gnu.org/viewcvs?rev=234743=gcc=rev
Log:
PR libstdc++/70437
* include/bits/stl_pair.h (_ConstructiblePair,
_ImplicitlyConvertiblePair, _MoveConstructiblePair,
_ImplicitlyMoveConvertiblePair): Add shortcut conditions
for same-type cases.
* testsuite/20_util/pair/70437.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/pair/70437.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_pair.h

[Bug fortran/65438] Unnecessary ptr check

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Dominique d'Humieres  ---
No feedback after more than a year. Closing as INVALID.

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P2
   Target Milestone|--- |4.9.4