[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #26 from Jeffrey A. Law  ---
In response to c#24.  Coalescing's primary sort key is highly dependent on the
edge frequencies -- which is generally what we want.

The highest edge frequency represents the highest cost for any particular copy
implied by a PHI node.

This obviously falls down if there are > 1 lower frequency copies that can't be
coalesced due to a higher frequency copy that does coalesce and the sum of the
lower frequency copy costs are greater than the sum of the single higher
frequency copy.

One might be able to model that by looking at the conflict lists, but before
going down that path, it'd obviously be best to know if that scenario is the
root cause of the slowdown.

[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
I wonder if this implies there's a problem with the implementation of C11
atomic_load() or with the resolution of DR 459:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_459

$ cat x.c && gcc -Wall -Wextra -Wpedantic -latomic -std=gnu11 x.c && ./a.out 
#include 
#include 

__int128 test(void)
{
const void *ptr = mmap(0, 4096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0);
const _Atomic __int128 *p_v = (const _Atomic __int128 *)ptr;
return atomic_load (p_v);
}

int main () {
test ();
}
x.c:4:1: warning: ISO C does not support ‘__int128’ types [-Wpedantic]
 __int128 test(void)
 ^
x.c: In function ‘test’:
x.c:7:19: warning: ISO C does not support ‘__int128’ types [-Wpedantic]
 const _Atomic __int128 *p_v = (const _Atomic __int128 *)ptr;
   ^
x.c:7:50: warning: ISO C does not support ‘__int128’ types [-Wpedantic]
 const _Atomic __int128 *p_v = (const _Atomic __int128 *)ptr;
  ^
Segmentation fault (core dumped)

[Bug c++/70492] Libiberty Demangler segfaults (2)

[boehme.marcel at gmail dot com]

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

--- Comment #1 from Marcel Böhme  ---
This error was found during fuzzing with a more efficient version of AFL.

Patch and reviews available here:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg0.html

[Bug c++/70492] New: Libiberty Demangler segfaults (2)

[boehme.marcel at gmail dot com]

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

Bug ID: 70492
   Summary: Libiberty Demangler segfaults (2)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boehme.marcel at gmail dot com
  Target Milestone: ---

Valgrind reports an invalid write of size 8 due to an integer overflow in the
demangling of virtual tables in method gnu_special.

How to Reproduce:
$ valgrind c++filt __vt_900cafebabe
==69112== Invalid write of size 8
==69112==at 0x4C2F793: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==69112==by 0x781F4A: memcpy (string3.h:51)
==69112==by 0x781F4A: string_appendn (cplus-dem.c:4855)
==69112==by 0x781F4A: gnu_special (cplus-dem.c:3015)
==69112==by 0x782B3E: internal_cplus_demangle (cplus-dem.c:1191)
==69112==by 0x74F572: cplus_demangle (cplus-dem.c:887)
==69112==by 0x406251: demangle_it (cxxfilt.c:62)
==69112==by 0x40582E: main (cxxfilt.c:227)
==69112==  Address 0x5400060 is 0 bytes after a block of size 32 alloc'd
==69112==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==69112==by 0x7F919C: xmalloc (xmalloc.c:147)
==69112==by 0x782367: string_need (cplus-dem.c:4775)
==69112==by 0x782367: string_appendn (cplus-dem.c:4854)
==69112==by 0x782367: gnu_special (cplus-dem.c:3015)
==69112==by 0x782B3E: internal_cplus_demangle (cplus-dem.c:1191)
==69112==by 0x74F572: cplus_demangle (cplus-dem.c:887)
==69112==by 0x406251: demangle_it (cxxfilt.c:62)
==69112==by 0x40582E: main (cxxfilt.c:227)
==69112== 
==69112== Invalid read of size 8
==69112==at 0x4C2F79E: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==69112==by 0x781F4A: memcpy (string3.h:51)
==69112==by 0x781F4A: string_appendn (cplus-dem.c:4855)
==69112==by 0x781F4A: gnu_special (cplus-dem.c:3015)
==69112==by 0x782B3E: internal_cplus_demangle (cplus-dem.c:1191)
==69112==by 0x74F572: cplus_demangle (cplus-dem.c:887)
==69112==by 0x406251: demangle_it (cxxfilt.c:62)
==69112==by 0x40582E: main (cxxfilt.c:227)
==69112==  Address 0xfff001000 is not stack'd, malloc'd or (recently) free'd
..
==69112== 
==69112== HEAP SUMMARY:
==69112== in use at exit: 32 bytes in 1 blocks
==69112==   total heap usage: 1 allocs, 0 frees, 32 bytes allocated
==69112== 
==69112== LEAK SUMMARY:
==69112==definitely lost: 0 bytes in 0 blocks
==69112==indirectly lost: 0 bytes in 0 blocks
==69112==  possibly lost: 0 bytes in 0 blocks
==69112==still reachable: 32 bytes in 1 blocks
==69112== suppressed: 0 bytes in 0 blocks
==69112== Rerun with --leak-check=full to see details of leaked memory
==69112== 
==69112== For counts of detected and suppressed errors, rerun with: -v
==69112== ERROR SUMMARY: 243 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault

Bug Fix: Handle the special case when consume_count returns -1 due to an
integer overflow in gnu_special for the length of the virtual table qualifier.

Preparing a patch.

[Bug c++/70491] slow compilation initializing a VLA

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Blocks||16994
  Known to fail||5.3.0, 6.0
   Severity|normal  |minor


Referenced Bugs:

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

[Bug c++/70491] New: slow compilation initializing a VLA

[msebor at gcc dot gnu.org]

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

Bug ID: 70491
   Summary: slow compilation initializing a VLA
   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: ---

Compiling a program that initializes a VLA is several times slower that
compiling the same program that initializes an ordinary array.  The following
scripts create a pair of programs, the first initializes 100 arrays, and the
second initializes 100 VLAs.  The output shows the difference between the two
using an unoptimized GCC build on powerpc64le.

The difference between the two with an optimized GCC is less dramatic but the
VLA case is still 3 times slower on x86_64.

While compiling the VLA program is expected to take more cycles it shouldn't
take several times as long as the equivalent program with ordinary arrays.

$ (i=0; init=""; echo > z.cpp; while [ $i -lt 100 ]; do echo "int f$i (int n) {
int a [$i] = { $init }; return a [0]; }" >> z.cpp; init="$init $i,";
i=$((i+1)); done && time /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S
-Wall -xc++ z.cpp)

real0m0.545s
user0m0.543s
sys 0m0.002s
tmp$ (i=0; init=""; echo > z.cpp; while [ $i -lt 100 ]; do echo "int f$i (int
n) { int a [n] = { $init }; return a [0]; }" >> z.cpp; init="$init $i,";
i=$((i+1)); done && time /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S
-Wall -xc++ z.cpp)

real0m6.415s
user0m6.393s
sys 0m0.022s

[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
This is a target specific warning rather than a generic one as some target
(like AARCH64 if ever implemented) does not need write access for the load.

[Bug c/70490] New: __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

[mdpoole at troilus dot org]

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

Bug ID: 70490
   Summary: __atomic_load_n(const __int128 *, ...) generates
CMPXCHG16B with no warning
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdpoole at troilus dot org
  Target Milestone: ---

When compiling for x86-64 with the -mcx16 flag, there is no diagnostic for code
like this:

#include 
__int128 test(void)
{
const void *ptr = mmap(0, 4096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0);
const __int128 *p_v = (const __int128 *)ptr;
return __atomic_load_n(p_v, __ATOMIC_SEQ_CST);
}

The CMPXCHG16B instruction that is generated unconditionally attempts to write
to the address, which causes a fault at runtime.  When __atomic_load_n() uses
that instruction, it seems prudent to reject a const pointer as the first
argument.

Command line: gcc -Wall -Wextra -mcx16 -O2 -c atomic.c
First line of "gcc --version": gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010

[Bug rtl-optimization/59393] [4.9/5/6 regression] mips16 code size

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
I was looking at this and noticed we have several sequences like

 _18 = l_11 >> 16;
  _19 = _18 & 255;
  _20 = _19 + 256;
  _21 = _20 * 8;

There's variations in the constants, but the pattern repeats regularly.  My
first thought was to rewrite that as

 _18 = l_11 >> 13;
 _19 = _18 & 0x7f8;
 _20 = _19 + 0x800;

That seemed to be slightly worse on x86_64.  I'd already noticed that the
addition was setting bits we knew to be zero, so it could be rewritten using an
IOR like this:


 _18 = l_11 >> 13;
 _19 = _18 & 0x7f8;
 _20 = _19 | 0x800;

In isolation, that looked good on x86_64.  So my thought was that we may have
an gcc-7 improvement that could be made for this code.  But then I coded up a
quick pattern in match.pd and tested it and the resulting assembly code was
considerably worse on x86_64 for the benchmark code.

There's a couple things in play here on x86_64.  In the benchmark code these
are address computations.  The *8 and +256 in the original sequence can be a
part of the effective address in the memory reference.  Furthermore, the
masking is a 2 byte movzbl in the original sequence, but a 3 byte and # in the
later sequences.  This negates all the gain by using IOR instead of PLUS, which
was shorter for x86_64.

mips16 does slightly better with the second sequence, saving ~76 bytes on the
included testcase.

However, given how highly dependent this is on the target's addressing modes,
match.pd is probably not the place to attack this problem.  Combine is likely a
better place, using either a generic splitting sequence that self-tunes via
rtx_cost.  Or via a target specific splitter.

The closest we get right now is this combine attempt:

(set (reg:SI 1077)
(plus:SI (ashift:SI (and:SI (lshiftrt:SI (reg:SI 1073)
(const_int 8 [0x8]))
(reg:SI 1074))
(const_int 2 [0x2]))
(const_int 1024 [0x400])))


reg:SI 1074 is (const_int 255), but we can't blindly substitute in because reg
1074 has other uses as seen by this attempt:

(parallel [
(set (reg:SI 1077)
(plus:SI (and:SI (ashift:SI (reg:SI 1072)
(const_int 2 [0x2]))
(const_int 1020 [0x3fc]))
(const_int 1024 [0x400])))
(set (reg:SI 1074)
(const_int 255 [0xff]))
])

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
The following additional patchlet does the trick.

Still need to regression test.

diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 2fc9dfaf..8fef30ce 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -421,6 +421,12 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;

+  if ((*upper)->expr_type == EXPR_CONSTANT && (*upper)->ts.type != BT_INTEGER)
+{
+  gfc_error ("Expecting a scalar INTEGER expression at %C");
+  return AS_UNKNOWN;
+}
+
   if ((*upper)->expr_type == EXPR_FUNCTION && (*upper)->ts.type == BT_UNKNOWN
   && (*upper)->symtree && strcmp ((*upper)->symtree->name, "null") == 0)
 {

[Bug c/70250] Compilation hangs without optimization.

[brijesh.s.singh at gmail dot com]

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

--- Comment #2 from brijesh singh  ---
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-0ubuntu1~12.04'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~12.04)

Command that hangs:
gcc file.c

On Wed, Mar 16, 2016 at 3:16 AM, rguenth at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70250
>
> Richard Biener  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2016-03-16
>  Ever confirmed|0   |1
>
> --- Comment #1 from Richard Biener  ---
> Can't reproduce on x86_64-linux.  Please provide the command line that
> causes
> the hang and the output when appending -v to it.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/70489] New: ICE in cxx_eval_increment_expression initializing a VLA in a constexpr function

[msebor at gcc dot gnu.org]

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

Bug ID: 70489
   Summary: ICE in cxx_eval_increment_expression initializing a
VLA in a constexpr function
   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: ---

Current top of trunk (6.0) as well as 5.x both fail with an ICE on the
following valid code.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -xc++ t.c
constexpr int f (int m, int n)
{
char a [m][n] = { 1, 2, 3, 4 };
return 0;
}

constexpr int i = f (2, 2);
t.c: In function ‘constexpr int f(int, int)’:
t.c:3:10: warning: unused variable ‘a’ [-Wunused-variable]
 char a [m][n] = { 1, 2, 3, 4 };
  ^
t.c: At global scope:
t.c:7:21:   in constexpr expansion of ‘f(2, 2)’
t.c:7:26: internal compiler error: in cxx_eval_increment_expression, at
cp/constexpr.c:3001
 constexpr int i = f (2, 2);
  ^
0x106f3147 cxx_eval_increment_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3001
0x106f6daf cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3789
0x106f63eb cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3720
0x106f5b47 cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3492
0x106f3a7f cxx_eval_statement_list
/src/gcc/trunk/gcc/cp/constexpr.c:3152
0x106f6cff cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3776
0x106f63eb cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3720
0x106f63eb cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3720
0x106f5b47 cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3492
0x106f5b47 cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3492
0x106f3a7f cxx_eval_statement_list
/src/gcc/trunk/gcc/cp/constexpr.c:3152
0x106f6cff cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3776
0x106f6d83 cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3782
0x106eb17b cxx_eval_call_expression
/src/gcc/trunk/gcc/cp/constexpr.c:1393
0x106f502b cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3374
0x106f77fb cxx_eval_outermost_constant_expr
/src/gcc/trunk/gcc/cp/constexpr.c:3939
0x106f80af cxx_constant_value(tree_node*, tree_node*)
/src/gcc/trunk/gcc/cp/constexpr.c:4028
0x1046900b store_init_value(tree_node*, tree_node*, vec**, int)
/src/gcc/trunk/gcc/cp/typeck2.c:822
0x1037bc43 check_initializer
/src/gcc/trunk/gcc/cp/decl.c:6155
0x1037f797 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/src/gcc/trunk/gcc/cp/decl.c:6783
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
They should be.
if (x)
#pragma omp for
  for (...)
if (y)
  ...
else
  ...
and #pragma omp simd and #pragma omp taskloop too.
For C++, perhaps we could just pass around if_p argument to a few more parsing
functions.

[Bug c++/70488] New: ICE in tree.c:7345 triggered by warning of placement new too small

[samschetgcc at gmail dot com]

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

Bug ID: 70488
   Summary: ICE in tree.c:7345 triggered by warning of placement
new too small
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samschetgcc at gmail dot com
  Target Milestone: ---

GCC built from revision 234633 fails with an ICE when trying to warn that the
buffer provided by placement new is too small if the array is a variable length
array on the stack:

when compiling this code:

struct failure_case {size_t s;};

void break_func(unsigned int s) {
char temp_buffer[sizeof(failure_case) + s];
failure_case *f = new (temp_buffer) failure_case;
};


$ ~/test_bin/bin/g++ repr_bug.cc
repr_bug.cc: In function ‘void break_func(int)’:
repr_bug.cc:16:41: internal compiler error: in tree_to_uhwi, at tree.c:7345
 failure_case *f = new (temp_buffer) failure_case;
 ^~~~
0xf79502 tree_to_uhwi(tree_node const*)
../../trunk/gcc/tree.c:7345
0x763a8a warn_placement_new_too_small
../../trunk/gcc/cp/init.c:2438
0x763a8a build_new_1
../../trunk/gcc/cp/init.c:2994
0x765095 build_new(vec**, tree_node*, tree_node*,
vec**, int, int)
../../trunk/gcc/cp/init.c:3449
0x6fd366 cp_parser_new_expression
../../trunk/gcc/cp/parser.c:8140
0x6fd967 cp_parser_unary_expression
../../trunk/gcc/cp/parser.c:7848
0x707957 cp_parser_cast_expression
../../trunk/gcc/cp/parser.c:8665
0x707eed cp_parser_binary_expression
../../trunk/gcc/cp/parser.c:8766
0x7087b0 cp_parser_assignment_expression
../../trunk/gcc/cp/parser.c:9053
0x708bc7 cp_parser_constant_expression
../../trunk/gcc/cp/parser.c:9323
0x7093b4 cp_parser_initializer_clause
../../trunk/gcc/cp/parser.c:20791
0x70abab cp_parser_initializer
../../trunk/gcc/cp/parser.c:20734
0x71c71d cp_parser_init_declarator
../../trunk/gcc/cp/parser.c:18604
0x71d070 cp_parser_simple_declaration
../../trunk/gcc/cp/parser.c:12372
0x71d3aa cp_parser_block_declaration
../../trunk/gcc/cp/parser.c:12248
0x71deb9 cp_parser_declaration_statement
../../trunk/gcc/cp/parser.c:11860
0x71aa93 cp_parser_statement
../../trunk/gcc/cp/parser.c:10528
0x71b4a4 cp_parser_statement_seq_opt
../../trunk/gcc/cp/parser.c:10806
0x71b5af cp_parser_compound_statement
../../trunk/gcc/cp/parser.c:10760
0x71b70d cp_parser_function_body
../../trunk/gcc/cp/parser.c:20653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

When removing the parameter addition, no warning is emitted and the code
compiles fine. Also, using a static size that is too small simply generates a
warning.

As a side note, the warning in this case could be considered spurious (although
overflow *could* generate too small of a buffer).

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #11 from Nathan Sidwell  ---
Applied to gcc-5 branch r234653.

[Bug target/70465] [4.9/5/6/7 Regression] Poor code for x87 asm

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #6 from Vladimir Makarov  ---
Neither IRA/LRA, nor old RA is/was aware about generation of good code for fp
stack.

GCC-6 generates before IRA (more correctly before coloring in IRA):

(insn 16 4 17 2 (set (reg:DF 90 [ res ])
(mem/c:DF (plus:SI (reg/f:SI 16 argp)
(const_int 8 [0x8])) [1 x+0 S8 A32])) b3.c:6 126
{*movdf_internal}
 (nil))
(insn 17 16 8 2 (set (reg/v:DF 88 [ y ])
(mem/c:DF (reg/f:SI 16 argp) [1 y+0 S8 A32])) b3.c:6 126
{*movdf_internal}
 (expr_list:REG_EQUIV (mem/c:DF (reg/f:SI 16 argp) [1 y+0 S8 A32])
(nil)))

while gcc-4.3 has before global/reload:

(insn:HI 2 5 3 2 b3.c:6 (set (reg/v:DF 60 [ y ])
(mem/c/i:DF (reg/f:SI 16 argp) [2 y+0 S8 A32])) 102 {*movdf_nointeger}
(nil))

(insn:HI 3 2 4 2 b3.c:6 (set (reg/v:DF 61 [ x ])
(mem/c/i:DF (plus:SI (reg/f:SI 16 argp)
(const_int 8 [0x8])) [2 x+0 S8 A32])) 102 {*movdf_nointeger}
(nil))

So gcc-4.3 was lucky to have load of y first and then x, while gcc-6 is unlucky
to have load of x first and than y.

There are a lot of PRs usually with tiny tests where old RA (or reload) has
a better code.  Unfortunately it will always be that way as RA is all about
heuristics.  There are no opposite PRs where reload/old RA generates worse code
because it is not used anymore.

In any case if we exchange x, y in the argument list, gcc-4.3 will also
generate fxch.

Still I think it can be fixed.  update_equiv_reg transforms code

2: r88:DF=[argp:SI]
3: r89:DF=[argp:SI+0x8]
   16: r90:DF=r89:DF

into

   16: r90:DF=[argp:SI+0x8]
   17: r88:DF=[argp:SI]

This is the source for fxch generation. If we exchange places of insns 16 and
17, fxch will be gone.  Although I can not guarantee that there will be no new
PRs as such change might result in some worse code generation.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell  ---
Author: nathan
Date: Thu Mar 31 20:51:20 2016
New Revision: 234653

URL: https://gcc.gnu.org/viewcvs?rev=234653=gcc=rev
Log:
PR c++/70393
* varasm.c (output_constructor_regular_field): Flush bitfield
earlier.  Assert we don't want to move backwards.

cp/
PR c++/70393
* constexpr.c (cxx_eval_store_expression): Keep CONSTRUCTOR
elements in field order.

testsuite/
PR c++/70393
* g++.dg/cpp0x/constexpr-virtual6.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual6.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/varasm.c

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
(In reply to Harald Anlauf from comment #5)
--- snip ---
> 
> Index: gcc/fortran/simplify.c
> ===
> --- gcc/fortran/simplify.c  (revision 234170)
> +++ gcc/fortran/simplify.c  (working copy)
> @@ -5163,6 +5163,9 @@
>|| !is_constant_array_expr (order_exp))
>  return NULL;
>  
> +  if (source->shape == NULL)
> +return NULL;
> +
>/* Proceed with simplification, unpacking the array.  */
>  
>mpz_init (index);
> 
> 

Although an error is thrown and no ICE, for the cases of comment #1, we get two
errors, one of which is bogus.

I believe the z2.f90 through z5.f90 need to be caught much earlier in syntax
checking

[Bug c++/70487] New: warn_unused_result attribute doesn't warn when return type is class

[tkrimer at epochlabs dot com]

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

Bug ID: 70487
   Summary: warn_unused_result attribute doesn't warn when return
type is class
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkrimer at epochlabs dot com
  Target Milestone: ---

Created attachment 38151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38151=edit
repro

warn_unused_result attribute doesn't warn when return type is class 
see attached to reproduce

[Bug c++/70486] New: Constexpr array captured in lambda function (used via std::function)

[krzyk240 at gmail dot com]

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

Bug ID: 70486
   Summary: Constexpr array captured in lambda function (used via
std::function)
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzyk240 at gmail dot com
  Target Milestone: ---

Created attachment 38150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38150=edit
The *.i* file



#include 
#include 

int main() {
constexpr int t[2] = { 1, 2 };
std::function foo = [&] {
for (int i = 0; i < 2; ++i)
std::cout << t[i] << ' ';
};

foo();
return 0;
}



$ g++-5.1 -std=c++11 -Wall -Wextra main.cpp -v -save-temps

Using built-in specs.
COLLECT_GCC=g++-5.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/usr/local --disable-multilib
--without-mpc --without-mpfr --without-gmp --without-cloog --without-isl
--enable-languages=c,c++
Thread model: posix
gcc version 5.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-std=c++11' '-Wall' '-Wextra' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -E -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic
-march=x86-64 -std=c++11 -Wall -Wextra -fpch-preprocess -o main.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++11' '-Wall' '-Wextra' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -fpreprocessed
main.ii -quiet -dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main
-Wall -Wextra -std=c++11 -version -o main.s
GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 03db94ff6398330bffd2a80db4ec6941
main.cpp: In lambda function:
main.cpp:8:20: internal compiler error: in make_decl_rtl, at varasm.c:1313
std::cout << t[i] << ' ';
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



$ uname -a

Linux stacked-crooked 3.2.0-74-virtual #109-Ubuntu SMP Tue Dec 9 17:04:48 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

[Bug c/70485] New: Duplicate typedef results in missing debug info

[freezer.spam at gmail dot com]

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

Bug ID: 70485
   Summary: Duplicate typedef results in missing debug info
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freezer.spam at gmail dot com
  Target Milestone: ---

Created attachment 38149
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38149=edit
gcc version output

For the past few years, GCC has allowed duplicate typedefs as long as they're
compatible with each other. The issue I'm facing is with DWARF debugging
extensions: it seems that GCC marks duplicate typedefs as unused, and does not
include them in DWARF.
Example:

typedef struct yyx yyx_handle;
typedef struct yyx yyx_handle;

yyx_handle *get_yyx(void *p)
{ return (yyx_handle *)p; }

Results:

$ gcc -o f1.o -c f1.c -g
$ readelf --debug-dump f1.o | grep yyx_handle | wc -l
0

If I add -fno-eliminate-unused-debug-types the typedef is included, but then
all my unused types appear as well, blowing up the object file size.

The obvious workaround is to remove the duplicate definition, but that's not
always practical.

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Below is a test case (derived from a test discussed in the context of another
bug: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01644.html) for another
example of a constexpr function whose use in a constexpr context is invalid due
to its return value relying on unspecified effects, this time the result of the
relational expression involving null pointers.

The test case shows two problems: first, that the invalid initialization of the
constexpr variables a0 and b1 is accepted, and second, an error on the use of
SFINAE to select one of the two overloads of the function template f (see also
bug 70380 for a similar SFINAE example that's not handled correctly, though for
a different reason).

The main point of the example is to demonstrate the first problem, but fixing
it should take into consideration the SFINAE case.

$ cat v.c && /build/gcc-trunk-bootstrap/gcc/xgcc -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -xc++ v.c
constexpr int *p = 0;
constexpr int *q = 0;

struct A {
  constexpr A (bool b) : m (b ? 1 : p < q) { }
  constexpr int foo () const { return m; }
  int m;
};

struct B {
  constexpr B (bool b) : m (b ? p < q : 1) { }
  constexpr int bar () const { return m; }
  int m;
};

constexpr int a0 = A (false).foo ();   // invalid, accepted
constexpr int a1 = A (true).foo ();// valid, accepted
constexpr int b0 = B (false).bar ();   // valid, accepted
constexpr int b1 = B (true).bar ();// invalid, accepted

template 
int f (int (*)[A (X).foo ()] = 0) { return !X; }

template 
int f (int (*)[B (X).bar ()] = 0) { return X; }

constexpr int f0 = f<0>();// valid, rejected
constexpr int f1 = f<1>();// valid, rejected
v.c:27:24: error: call to non-constexpr function ‘int f(int
(*)[(B)(X).B::bar()]) [with bool X = false]’
 constexpr int f0 = f<0>();// valid, rejected
^~
v.c:28:24: error: call to non-constexpr function ‘int f(int
(*)[(A)(X).A::foo()]) [with bool X = true]’
 constexpr int f1 = f<1>();// valid, rejected
^~

[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
The difference I see is that LRA chooses alternative "Q,0,Q" and reload chooses
"d,0,R".

For the "Q,O,Q" LRA reports:

  2 Spill pseudo into memory: reject+=3
  alt=11,overall=9,losers=1,rld_nregs=0

For "d,0,R" it reports:

0 Non-pseudo reload: reject+=2
0 Non input pseudo reload: reject++
1 Dying matched operand reload: reject++
alt=8,overall=10,losers=1 -- refuse

So it is 9 vs 10.  It would be the same # of insns if we already had a stack
frame.  Most non-toy functions will have a stack frame.  So the problem is not
that bad for a real world scenario.

I'll look what can I do to fix this.  But I should say that it is a very
sensitive code of LRA.  Fiddling with heuristics might affect many programs and
targets and might result in new PRs.

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointer-checks

[thadula at ciena dot com]

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

--- Comment #9 from Hadula, Tomasz  ---
Created attachment 38148
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38148=edit
Reduced testcase

I reduced the size of the testcase

[Bug c++/65923] False positive for warning about literal operator suffix and using

[richardg.work at gmail dot com]

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

Richard Geary  changed:

   What|Removed |Added

 CC||richardg.work at gmail dot com

--- Comment #2 from Richard Geary  ---
This is still present in g++ 5.3.0, and also affects
std::literals::string_literals. The flag -Wno-literal-suffix does not turn it
off.  Thus -Werror builds will fail, despite the C++ being clean.

A workaround is to use 'using namespace std::literals::chrono_literals;' but
having a 'using namespace' in a header file is usually considered bad practice.

Please can someone fix this?

[Bug c++/70462] Unnecessary "base object constructor" for final classes

[joerg.rich...@pdv-fs.de]

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

--- Comment #3 from Jörg Richter  ---
Well, my real problem is related to coverage analysis.  Function coverage will
show the base object constructor as not called.  But my concrete test case is
more complex and involves virtual functions and inheritance.  Might me that an
alias is not enough in the real code.

A different solution to my problem might be to exclude the base object
constructor from coverage analysis.  

A related problem: I also have a class that is always used as a base class and
will never be constructed directly (because it has pure virtual functions). 
The "complete object constructor" is emitted nevertheless.  But function
coverage marks it as never called.

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

[ppalka at gcc dot gnu.org]

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

--- Comment #11 from Patrick Palka  ---
Should non-standard constructs be considered in this PR? I noticed that we also
don't warn on

  if (a)
  #pragma GCC ivdep
 while (1)
   if (b)
 bar ();
  else
baz ();

and

  if (a)
_Cilk_for (int i = 0; i < 10; i++)
  if (b)
bar ();
  else
baz ();

and probably other such constructs.

[Bug rtl-optimization/70461] [6 Regression] Performance regression after r234527

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed by Vlad's commit on the trunk.

[Bug tree-optimization/70484] New: Wrong optimization with aliasing and access via char

[ch3root at openwall dot com]

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

Bug ID: 70484
   Summary: Wrong optimization with aliasing and access via char
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

The function:

int f(int *pi, long *pl)
{
  *pi = 1; // (1)
  *pl = 0; // (2)
  return *(char *)pi;  // (3)
}

is optimized (with -O2) to always return 1:

f:
movl$1, (%rdi)
movl$1, %eax
movq$0, (%rsi)
ret

This is wrong if pi and pl both point to the same allocated block. In this case
the function should return 0.

The first impression could be that it's invalid to call this function with
equal arguments as it violates strict aliasing rules. This is wrong.

Suppose the function is called like this:

  void *p = malloc(sizeof(long));
  int result = f(p, p);

Then (1) is clearly Ok.

(2) is fine too because allocated memory can be repurposed freely. C11, 6.5p6,
reads: "If a value is stored into an object having no declared type through an
lvalue having a type that is not a character type, then the type of the lvalue
becomes the effective type of the object for that access and for subsequent
accesses that do not modify the stored value."

(3) is fine according to 6.5p7 because a character type can be used to access
anything.

Full example with a function:

--
extern void *malloc (__SIZE_TYPE__);
extern void abort (void);

__attribute__((noinline,noclone))
int f(int *pi, long *pl)
{
  *pi = 1;
  *pl = 0;
  return *(char *)pi;
}

int main()
{
  void *p = malloc(sizeof(long));
  if (f(p, p) != 0)
abort();
}
--

Full example with volatile:

--
extern void *malloc (__SIZE_TYPE__);
extern void abort (void);

int main()
{
  void *volatile p = malloc(sizeof(long));
  int *pi = p;
  long *pl = p;
  *pi = 1;
  *pl = 0;
  if (*(char *)pi != 0)
abort();
}
--

Tested on gcc 6.0.0 20160331. According to https://gcc.godbolt.org/ the bug is
present since at least 4.4.7.

[Bug rtl-optimization/70461] [6 Regression] Performance regression after r234527

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Mar 31 17:51:13 2016
New Revision: 234649

URL: https://gcc.gnu.org/viewcvs?rev=234649=gcc=rev
Log:
2016-03-31  Vladimir Makarov  

PR rtl-optimization/70461
* ira-color.c (allocno_copy_cost_saving): Use allocno class if it
is necessary.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c

[Bug target/70465] [4.9/5/6/7 Regression] Poor code for x87 asm

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jeffrey A. Law from comment #4)
> No objections to deferring this to gcc-7.  Not surprisingly, my response
> when this issue was raised on Red Hat's internal IRC was the same -- nobody
> cares about x87 math anymore ;-)  IMHO it's really just a codesize issue
> anyway given how fxch is implemented on modern processors.

Related to PR 15492.

IMO, regstack.c should be taught to track loads to stack registers, so it would
be able to swap two FLDs, instead of emitting compensating FXCH right after two
FLDs.

[Bug hsa/70399] HSA: Wrong emission of st_align(4)_u8 HSAIL insn

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug hsa/70391] HSA back-end produces wrong alignment load/store instructions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug hsa/70399] HSA: Wrong emission of st_align(4)_u8 HSAIL insn

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Mar 31 17:28:29 2016
New Revision: 234647

URL: https://gcc.gnu.org/viewcvs?rev=234647=gcc=rev
Log:
Fix PR hsa/70399

PR hsa/70399
* hsa-brig.c (hsa_op_immed::emit_to_buffer): Emit either
a tree value or an immediate integer value to a buffer
that is eventually copied to a BRIG section.
(emit_immediate_operand): Call the function here.
* hsa-dump.c (dump_hsa_immed): Remove checking assert.
* hsa-gen.c (hsa_op_immed::hsa_op_immed): Remove initialization
of class' fields that are removed.
(hsa_op_immed::~hsa_op_immed): Remove deinitialization.
* hsa.h (class hsa_op_immed): Remove m_brig_repr and
m_brig_repr_size fields.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/hsa-brig.c
trunk/gcc/hsa-dump.c
trunk/gcc/hsa-gen.c
trunk/gcc/hsa.h

[Bug libstdc++/70483] New: string_view::compare and coparision operators are not constexpr

[sir.vestnik at gmail dot com]

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

Bug ID: 70483
   Summary: string_view::compare and coparision operators are not
constexpr
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sir.vestnik at gmail dot com
  Target Milestone: ---

libstdc++ std::experimental::basic_string_view implementation mising a lot of
constexpr specifications (according to the n4480) for example commented out
static assert here
https://github.com/VestniK/cpp-metainf/blob/master/pretty_func_parse/member_name.h
is valid and can be compiled with clang libc++ but fails to compile with gcc
libstdc++

[Bug c++/67394] crash due to null pointer deref in demangle_signature()

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |DUPLICATE

--- Comment #2 from Jeffrey A. Law  ---
Duplicate of 70481 which was just fixed on the trunk.

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

[Bug c++/70481] [Regression] Libiberty Demangler segfaults

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||brian.carpenter at gmail dot 
com

--- Comment #4 from Jeffrey A. Law  ---
*** Bug 67394 has been marked as a duplicate of this bug. ***

[Bug c++/70481] [Regression] Libiberty Demangler segfaults

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug hsa/70391] HSA back-end produces wrong alignment load/store instructions

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Mar 31 17:10:48 2016
New Revision: 234644

URL: https://gcc.gnu.org/viewcvs?rev=234644=gcc=rev
Log:
HSA: handle alignment of string builtins (PR hsa/70391)

PR hsa/70391
* hsa-gen.c (hsa_function_representation::update_dominance): New
function.
(convert_addr_to_flat_segment): Likewise.
(gen_hsa_memory_set): New alignment argument.
(gen_hsa_ctor_assignment): Likewise.
(gen_hsa_insns_for_single_assignment): Provide alignment
to gen_hsa_ctor_assignment.
(gen_hsa_insns_for_direct_call): Add new argument.
(expand_lhs_of_string_op): New function.
(expand_string_operation_builtin): Likewise.
(expand_memory_copy): New function.
(expand_memory_set): New function.
(gen_hsa_insns_for_call): Use HOST_WIDE_INT.
(convert_switch_statements): Change signature.
(generate_hsa): Use a return value of the function.
(pass_gen_hsail::execute): Do not call
convert_switch_statements here.
* hsa-regalloc.c (hsa_regalloc): Call update_dominance.
* hsa.h (hsa_function_representation::m_modified_cfg):
New flag.
(hsa_function_representation::update_dominance): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/hsa-gen.c
trunk/gcc/hsa-regalloc.c
trunk/gcc/hsa.h

[Bug hsa/70391] HSA back-end produces wrong alignment load/store instructions

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Thu Mar 31 17:10:15 2016
New Revision: 234643

URL: https://gcc.gnu.org/viewcvs?rev=234643=gcc=rev
Log:
HSA: support alignment for hsa_symbols (PR hsa/70391)

PR hsa/70391
* hsa-brig.c (emit_directive_variable): Emit alignment
according to hsa_symbol::m_align.
* hsa-dump.c (hsa_byte_alignment): Move the function to
another file.
(dump_hsa_symbol): Dump alignment of HSA symbols.
* hsa-gen.c (get_symbol_for_decl): Set-up alignment
of a symbol.
(gen_hsa_addr_with_align): New function.
(hsa_bitmemref_alignment): Use newly added function.
(gen_hsa_insns_for_load): Likewise.
(gen_hsa_insns_for_store): Likewise.
(gen_hsa_memory_copy): New argument added.
(gen_hsa_insns_for_single_assignment): Respect
alignment for assignments processed via
gen_hsa_memory_copy.
(gen_hsa_insns_for_direct_call): Likewise.
(gen_hsa_insns_for_return): Likewise.
(gen_function_def_parameters): Set default
alignment.
* hsa.c (hsa_object_alignment): New function.
(hsa_byte_alignment): Pasted function.
* hsa.h (hsa_symbol::m_align): New field.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/hsa-brig.c
trunk/gcc/hsa-dump.c
trunk/gcc/hsa-gen.c
trunk/gcc/hsa.c
trunk/gcc/hsa.h

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Created attachment 38145 [details]
> patch
>
> Attached patch seems to work OK on Linux and removes all string.h includes
> from chkp-str* tests.  I believe this should resolve all related issues
> on Darwing and other targets.
>
> Could you please test it on Darwin?

The patch fixes the issues on darwin:

[Book15] build_w/gcc% make -k check-gcc RUNTESTFLAGS="i386.exp=chkp*
--target_board=unix'{-m32,-m64}'" 
...
=== gcc Summary for unix/-m64 ===

# of expected passes63
# of unsupported tests  6

=== gcc Summary ===

# of expected passes126
# of unsupported tests  12
/opt/gcc/build_w/gcc/xgcc  version 6.0.0 20160330 (experimental) [trunk
revision 234577p26] (GCC) 

make[1]: Leaving directory '/opt/gcc/build_w/gcc'

[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 #17 from Julien Margetts  ---
The following test case still fails with the patch applied (originally bug
70362)

arm-none-eabi-gcc -march=armv3m -c -o c_compat_x_tst.o
gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c

The assert in the added by the patch is firing:

/* The slot is out of range, or was dressed up in a SUBREG.  */
base = reg_equiv_address (REGNO (ref));
+
+  /* PR 62554: If there is no equivalent memory location then just move
+the value as an SImode register move.  This happens when the target
+architecure variant does not have an HImode register move.  */
+  if (base == NULL)
+   {
+ gcc_assert (REG_P (operands[0]));  FAIL 
+ emit_insn (gen_movsi (gen_rtx_SUBREG (SImode, operands[0], 0),
+   gen_rtx_SUBREG (SImode, ref, 0)));
+ return;
+   }
 }

At this point I believe operands[0] is a QImode SUBREG

[Bug target/70465] [4.9/5/6/7 Regression] Poor code for x87 asm

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
No objections to deferring this to gcc-7.  Not surprisingly, my response when
this issue was raised on Red Hat's internal IRC was the same -- nobody cares
about x87 math anymore ;-)  IMHO it's really just a codesize issue anyway given
how fxch is implemented on modern processors.

[Bug tree-optimization/70482] New: Opimization opportunity to vectorize basic block for -mavx target.

[ysrumyan at gmail dot com]

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

Bug ID: 70482
   Summary: Opimization opportunity to vectorize basic block for
-mavx target.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

If we compile bb-slp-pattern-1.c from gcc.dg/vect suite with -mavx pattern
vectorization won't happen since AVX has very poor support for 256-bit integer
arithmetic. Particularly, widen-mult pattern is recognized but it is not
supported for 256-bit vectors.
Test is failed for native compiler build on AVX machine. The most simple
decision is to use the same scheme as for loop vectorization by decreasing
vector size from 256-bit to 128-bit.

[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4

[jmargetts at ocz dot com]

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

Julien Margetts  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #7 from Julien Margetts  ---
I agree, adding Nick Clifton on CC as the originator of the PR62254 patch

FWIW: It turns out when the assert fires:
GET_MODE(SUBREG_REG(operands[0])) == QImode

I will re-open PR62254

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Should it be fixed on gcc-5-branch too?

[Bug rtl-optimization/70467] Useless "and [esp],-1" emitted on AND with uint64_t variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
As for the double word additions/subtractions with low bits 0, like:
unsigned long long
foo (unsigned long long x)
{
  return x + 0x123456ULL;
}

unsigned long long
bar (unsigned long long x)
{
  return x - 0x123456ULL;
}
for -m32 -O2 and
__uint128_t
foo (__uint128_t x)
{
  return x + ((__uint128_t) 123456 << 64);
}

__uint128_t
bar (__uint128_t x)
{
  return x - ((__uint128_t) 123456 << 64);
}
for -m64 -O2, I have a partial fix here:

--- gcc/config/i386/i386.md.jj  2016-03-29 19:31:23.0 +0200
+++ gcc/config/i386/i386.md 2016-03-31 17:33:36.848167239 +0200
@@ -5449,7 +5449,14 @@ (define_insn_and_split "*add3_doubl
   (match_dup 4))
 (match_dup 5)))
  (clobber (reg:CC FLAGS_REG))])]
-  "split_double_mode (mode, [0], 3, [0],
[3]);")
+{
+  split_double_mode (mode, [0], 3, [0], [3]);
+  if (operands[2] == const0_rtx)
+{
+  ix86_expand_binary_operator (PLUS, mode, [3]);
+  DONE;
+}
+})

 (define_insn "*add_1"
   [(set (match_operand:SWI48 0 "nonimmediate_operand" "=r,rm,r,r")
@@ -6379,7 +6386,14 @@ (define_insn_and_split "*sub3_doubl
   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
 (match_dup 5)))
  (clobber (reg:CC FLAGS_REG))])]
-  "split_double_mode (mode, [0], 3, [0],
[3]);")
+{
+  split_double_mode (mode, [0], 3, [0], [3]);
+  if (operands[2] == const0_rtx)
+{
+  ix86_expand_binary_operator (MINUS, mode, [3]);
+  DONE;
+}
+})

 (define_insn "*sub_1"
   [(set (match_operand:SWI 0 "nonimmediate_operand" "=m,")

but it only works for the -m32 testcase.  The problem is that for "" for
the TImode addition/subtraction we use "e" constraint and that is obviously
inappropriate, we want some new constraints that makes sure that both the low
and high 64-bits of the constant are "e".  Will hack on that tomorrow.

[Bug target/70442] [6 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "extract_insn"

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #4 from Ilya Enkovich  ---
Fixed

[Bug target/70442] [6 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "extract_insn"

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu Mar 31 15:37:12 2016
New Revision: 234637

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

PR target/70442
* config/i386/i386.c (scalar_chain::convert_op): Fix
description.
(scalar_chain::convert_insn): Call convert_op for reg
moves to handle undefined registers.

gcc/testsuite/

PR target/70442
* gcc.dg/pr70442.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70442.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70481] [Regression] Libiberty Demangler segfaults

[boehme.marcel at gmail dot com]

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

--- Comment #2 from Marcel Böhme  ---
These are two distinct bugs. During fuzzing the btypevec bug appears more
often. But it seemed less critical since only NULL is written to the freed
memory:
work -> btypevec[ret] = NULL;

On the other hand, the ktypevec bug allows to write arbitrary content to the
freed memory:
work -> ktypevec[work -> numk++] = tem;
where tem is "cafebabe."

I used a more efficient version of the AFL fuzzer. Interestingly, I submitted
the same patch: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01687.html

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
Fixed r234636.

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
Author: nathan
Date: Thu Mar 31 15:30:33 2016
New Revision: 234636

URL: https://gcc.gnu.org/viewcvs?rev=234636=gcc=rev
Log:
PR c++/70393
* varasm.c (output_constructor_regular_field): Flush bitfield
earlier.  Assert we don't want to move backwards.

cp/
* constexpr.c (cxx_eval_store_expression): Keep CONSTRUCTOR
elements in field order.

testsuite/
* g++.dg/cpp0x/constexpr-virtual6.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual6.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug target/70453] gcc generates invalid instruction vextractu64x4 (should be: vextracti64x4)

[kyukhin at gcc dot gnu.org]

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

--- Comment #7 from Kirill Yukhin  ---
Author: kyukhin
Date: Thu Mar 31 15:25:33 2016
New Revision: 234635

URL: https://gcc.gnu.org/viewcvs?rev=234635=gcc=rev
Log:
Fix PR target/70453.

gcc/
* config/i386/sse.md (define_mode_attr shuffletype): Fix typo.

gcc/testsuite/
* gcc.target/i386/pr70453.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr70453.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 target/70453] gcc generates invalid instruction vextractu64x4 (should be: vextracti64x4)

[kyukhin at gcc dot gnu.org]

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

--- Comment #6 from Kirill Yukhin  ---
Author: kyukhin
Date: Thu Mar 31 15:23:29 2016
New Revision: 234634

URL: https://gcc.gnu.org/viewcvs?rev=234634=gcc=rev
Log:
Fix PR target/70453.

gcc/
* config/i386/sse.md (define_mode_attr shuffletype): Fix typo.

gcc/testsuite/
* gcc.target/i386/pr70453.c: New test.

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

[Bug target/70404] pr70174.c fails on s390x

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

  Attachment #38142|0   |1
is obsolete||
   Assignee|jakub at gcc dot gnu.org   |krebbel at gcc dot 
gnu.org

--- Comment #4 from Andreas Krebbel  ---
Created attachment 38147
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38147=edit
Patch currently being tested

I'm currently regtesting this patch. The first patch probably doesn't work as
is since symbol_refs have a mode != VOIDmode and therefore the IF where the
check has been added will never be entered.

[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[akim.demaille at gmail dot com]

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

--- Comment #49 from Akim Demaille  ---
It looks like this story is missing an end.

[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[akim.demaille at gmail dot com]

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

Akim Demaille  changed:

   What|Removed |Added

 CC||akim.demaille at gmail dot com

--- Comment #48 from Akim Demaille  ---
It looks like this history is missing an end.

[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #6 from Andrey Belevantsev  ---
Fixed on trunk and gcc-5-branch, I'm not going to backport to 4.9.

[Bug c++/70481] [Regression] Libiberty Demangler segfaults

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
Likely a dup of PR67394

[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan  ---
Fails at O0 in this case, I cannot type. I still think this is a tail from
PR62254 and that should just be reopened.

[Bug rtl-optimization/69307] [4.9/5 Regression] wrong code with -O2 -fselective-scheduling @ armv7a

[abel at gcc dot gnu.org]

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

--- Comment #10 from Andrey Belevantsev  ---
Author: abel
Date: Thu Mar 31 14:50:57 2016
New Revision: 234629

URL: https://gcc.gnu.org/viewcvs?rev=234629=gcc=rev
Log:
Backport from mainline
2016-03-12  Andrey Belevantsev  

gcc/
PR rtl-optimization/69307
* sel-sched.c (choose_best_pseudo_reg): Properly check for hard
registers in modes that span more than one register.

testsuite/
PR rtl-optimization/69307
* gcc.dg/pr69307.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr69307.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/sel-sched.c

[Bug rtl-optimization/69032] [5 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4809 with -fsched-pressure -fsel-sched-pipelining -fselective-scheduling

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #5 from Andrey Belevantsev  ---
Fixed on gcc-5-branch.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I haven't checked for other relevant rules in the standard, but Clang and EDG
give the same result as G++.

[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4

[jmargetts at ocz dot com]

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

--- Comment #5 from Julien Margetts  ---
Yes, I applied both patches, and the test failure is still present, but on
closer inspection, it is no longer a segfault, but an internal compiler error:

The new assertion in the patch is firing:

gcc_assert (REG_P (operands[0]));

The discussion in PR62254 suggests not all cases are covered (hence the new
asserts I guess) so I think this is just another as yet unreached corner case

I guess either this bug, or 62254 should be re-opened?

[Bug target/70292] ICE in verify_target_availability, at sel-sched.c:1584 with -fno-inline -fno-dce -fschedule-insns -fselective-scheduling -fno-tree-dce -O1

[abel at gcc dot gnu.org]

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

--- Comment #2 from Andrey Belevantsev  ---
Author: abel
Date: Thu Mar 31 14:37:08 2016
New Revision: 234627

URL: https://gcc.gnu.org/viewcvs?rev=234627=gcc=rev
Log:
PR target/70292
* gcc.c-torture/pr70292.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr70292.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/70292] ICE in verify_target_availability, at sel-sched.c:1584 with -fno-inline -fno-dce -fschedule-insns -fselective-scheduling -fno-tree-dce -O1

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrey Belevantsev  ---
Test committed on trunk.

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

[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||tarasevich at cs dot 
uni-saarland.
   ||de

--- Comment #5 from Andrey Belevantsev  ---
*** Bug 70292 has been marked as a duplicate of this bug. ***

[Bug c++/70481] New: [Regression] Libiberty Demangler segfaults

[boehme.marcel at gmail dot com]

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

Bug ID: 70481
   Summary: [Regression] Libiberty Demangler segfaults
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boehme.marcel at gmail dot com
  Target Milestone: ---

In the most recent version, Valgrind reports an invalid write of size 8 due to
a use-after-free if the demangler is called with a certain class signature.
However, the demangling succeeds in earlier versions.

How to Reproduce:
binutils-2.26# valgrind binutils/cxxfilt _Q10-__9cafebabe.
==56086== Memcheck, a memory error detector
==56086== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==56086== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==56086== Command: binutils/cxxfilt _Q10-__9cafebabe.
==56086== 
==56086== Invalid write of size 8
==56086==at 0x787D9B: remember_Ktype (cplus-dem.c:4300)
==56086==by 0x787D9B: demangle_class (cplus-dem.c:2621)
==56086==by 0x787D9B: demangle_signature (cplus-dem.c:1494)
==56086==by 0x78DEA9: internal_cplus_demangle (cplus-dem.c:1204)
==56086==by 0x75DC6A: cplus_demangle (cplus-dem.c:887)
==56086==by 0x4063E1: demangle_it (cxxfilt.c:62)
==56086==by 0x4059BE: main (cxxfilt.c:227)
..

The root cause:
There is a variable ksize storing the amount of allocated memory for the array.
ksize being zero (0) indicates that some memory must be allocated upon the
first write. When more memory is needed, both ksize and the memory are doubled
during reallocation. At some point the memory for the array is freed but the
value of ksize remains. Since ksize is not 0, there is no indication that new
memory must be allocated when there is another write to the array.

The solution:
When freeing the memory of the array set ksize=0.

I am preparing a patch.

[Bug c/70297] [5 Regression] GCC Segfaults when using -g3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[5/6 Regression] GCC|[5 Regression] GCC
   |Segfaults when using -g3|Segfaults when using -g3

--- Comment #11 from Marek Polacek  ---
Fixed on the trunk so far.

[Bug c/70297] [5/6 Regression] GCC Segfaults when using -g3

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 31 14:29:15 2016
New Revision: 234626

URL: https://gcc.gnu.org/viewcvs?rev=234626=gcc=rev
Log:
PR c/70297
* c-decl.c (merge_decls): Also set TYPE_ALIGN and TYPE_USER_ALIGN.

* decl.c (duplicate_decls): Also set TYPE_ALIGN and TYPE_USER_ALIGN.

* c-c++-common/pr70297.c: New test.
* g++.dg/cpp0x/typedef-redecl.C: New test.
* gcc.dg/typedef-redecl2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr70297.c
trunk/gcc/testsuite/g++.dg/cpp0x/typedef-redecl.C
trunk/gcc/testsuite/gcc.dg/typedef-redecl2.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Julien Margetts from comment #3)
> Are you suggesting you confirmed the patch associated with bug 62254 fixes
> this issue?
> 
> As far as I can tell, in isolation at least, it does not
> Are you suggesting you confirmed the patch associated with bug 62254 fixes
> this issue?
> 
> As far as I can tell, in isolation at least, it does not

There are 2 patches associated with PR62254 - from my experiments the failure
went away with a tree that had both patches applied, could you check ?

[Bug c++/70480] New: Reduce RTTI code bloat for specified types

[frankhb1989 at gmail dot com]

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

Bug ID: 70480
   Summary: Reduce RTTI code bloat for specified types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

There are cases that certain type info symbols are not needed, e.g. a class as
operand of 'typeid' which has multiple Boost.Operators bases. These base
classes are essentially insignificant in the class hierarchy when the program
is running, and no sane users would play them with 'dynamic_cast'/'typeid' or
handling them in 'catch' clauses. So it is unnecessary to emit type info for
these types. However, I find no way to suppress the bloated symbol generation
for them separately, even if these bases themselves are not operands of
'typeid'. (Note I do want RTTI elsewhere in the same translation units, so
'-fno-rtti' does not work.) LTO also fails to optimize them away. Can there be
some attributes on the class-definitions or base-specifiers tweaking the
behavior here? With such attributes the compiler can also warn about unintended
use.

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

[ramana at gcc dot gnu.org]

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

--- Comment #16 from Ramana Radhakrishnan  ---
(In reply to Nick Clifton from comment #13)
> Patch applied.

https://gcc.gnu.org/ml/gcc-cvs/2016-03/msg00740.html - just in case someone
wants a link to it.

[Bug rtl-optimization/69102] [4.9/5 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2

[abel at gcc dot gnu.org]

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

--- Comment #7 from Andrey Belevantsev  ---
Author: abel
Date: Thu Mar 31 14:16:18 2016
New Revision: 234625

URL: https://gcc.gnu.org/viewcvs?rev=234625=gcc=rev
Log:
Backport from mainline
2016-03-21  Andrey Belevantsev  

gcc/
PR rtl-optimization/69102
* sched-deps.c (sched_analyze_insn): Do not set last_args_size field
when we have a readonly dependency context.

testsuite/
PR rtl-optimization/69102
* gcc.c-torture/compile/pr69102.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr69102.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/sched-deps.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4

[jmargetts at ocz dot com]

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

--- Comment #3 from Julien Margetts  ---
Are you suggesting you confirmed the patch associated with bug 62254 fixes this
issue?

As far as I can tell, in isolation at least, it does not

[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-31
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Ramana Radhakrishnan  ---
Confirmed - but not sure if this is a dup of PR48863

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

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |6.0

--- Comment #15 from Ramana Radhakrishnan  ---
Fixed on trunk - there has been no backport of this to older branches.

[Bug tree-optimization/70479] FMA is not reassociated causing x2 slowdown vs. ICC

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
(In reply to Richard Biener from comment #2)
> You mean we fail to handle ternary associative tree codes in GIMPLE reassoc?
> Yes, that's true.  It's not going to be easy to retro-fit there
> implementation-wise.  With rebalancing you mean handling reassoc-width > 1?

Hi Richard, yes to both.

[Bug rtl-optimization/69032] [5 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4809 with -fsched-pressure -fsel-sched-pipelining -fselective-scheduling

[abel at gcc dot gnu.org]

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

--- Comment #4 from Andrey Belevantsev  ---
Author: abel
Date: Thu Mar 31 14:01:22 2016
New Revision: 234624

URL: https://gcc.gnu.org/viewcvs?rev=234624=gcc=rev
Log:
Backport from mainline
2016-03-15  Andrey Belevantsev  

gcc/
PR rtl-optimization/69032
* sel-sched-ir.c (get_seqno_by_preds): Include both insn and head when
looping backwards over basic block insns.

testsuite/
PR rtl-optimization/69032
* gcc.dg/pr69032.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr69032.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/sel-sched-ir.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

Re: [BUG] Crash when demangling with libiberty

[Ian Lance Taylor]

Philippe Daouadi  writes:

> I have been given these e-mail addresses by Nick Clifton after
> reporting a bug on binutils here:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19877 . The bug is in
> libiberty, according to him.
>
> The bug boils down to this command (and objdump, and lldb) crashing:
>
> c++filt
> _ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_
>
> I'm using c++filt from binutils 2.26 and have gcc 5.3.1-8 on a debian
> unstable if it is of any matter.

Please refile your bug report at https://gcc.gnu.org/bugzilla .  If at
all possible, please include the preprocessed source code that produces
the symbol (you can get this by passing the --save-temps option to the
compiler; we want the .ii file) and please include complete details on
the compiler that produced the symbol.  Thanks.

Ian

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

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||jmargetts at ocz dot com

--- Comment #14 from Ramana Radhakrishnan  ---
*** Bug 70362 has been marked as a duplicate of this bug. ***

[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #2 from Ramana Radhakrishnan  ---
dup confirmed.

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

[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[abel at gcc dot gnu.org]

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

--- Comment #11 from Andrey Belevantsev  ---
Author: abel
Date: Thu Mar 31 13:55:36 2016
New Revision: 234622

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

Backport from mainline
2016-03-15  Andrey Belevantsev  

PR target/0
* sel-sched-ir.c (merge_expr): Avoid changing the speculative pattern
to non-speculative when propagating trap bits.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/sel-sched-ir.c

[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

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

--- Comment #4 from Andrey Belevantsev  ---
Author: abel
Date: Thu Mar 31 13:50:15 2016
New Revision: 234620

URL: https://gcc.gnu.org/viewcvs?rev=234620=gcc=rev
Log:
Backport from mainline
2016-03-15  Andrey Belevantsev  

gcc/
PR target/64411
* sched-deps.c (get_implicit_reg_pending_clobbers): New function,
factored out from ...
(sched_analyze_insn): ... here.
* sched-int.h (get_implicit_reg_pending_clobbers): Declare it.
* sel-sched-ir.c (setup_id_implicit_regs): New function, use
get_implicit_reg_pending_clobbers in it.
(setup_id_reg_sets): Use setup_id_implicit_regs.
(deps_init_id): Ditto.

testsuite/
PR target/64411
* gcc.target/i386/pr64411.C: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr64411.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/sched-deps.c
branches/gcc-5-branch/gcc/sched-int.h
branches/gcc-5-branch/gcc/sel-sched-ir.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener  ---
I benchmarked the patch in comment#17 with a full three-run on all_cpp
on a Haswell machine with -Ofast -march=native (peak is patched).

  Estimated   Estimated
Base Base   BasePeak Peak   Peak
Benchmarks  Ref.   Run Time Ratio   Ref.   Run Time Ratio
-- --  -  ---  -  -
400.perlbench   NR  NR 
401.bzip2   NR  NR 
403.gcc NR  NR 
429.mcf NR  NR 
445.gobmk   NR  NR 
456.hmmer   NR  NR 
458.sjeng   NR  NR 
462.libquantum  NR  NR 
464.h264ref NR  NR 
471.omnetpp  6250315   19.9 *6250312   20.0 *  
473.astar7020323   21.7 *7020323   21.7 *  
483.xalancbmk6900193   35.8 *6900192   35.9 *  
 Est. SPECint_base2006   --
 Est. SPECint2006--

  Estimated   Estimated
Base Base   BasePeak Peak   Peak
Benchmarks  Ref.   Run Time Ratio   Ref.   Run Time Ratio
-- --  -  ---  -  -
410.bwaves  NR  NR 
416.gamess  NR  NR 
433.milcNR  NR 
434.zeusmp  NR  NR 
435.gromacs NR  NR 
436.cactusADM   NR  NR 
437.leslie3dNR  NR 
444.namd 8020300   26.7 *8020300   26.8 *  
447.dealII  11440253   45.3 *   11440257   44.5 *  
450.soplex   8340218   38.3 *8340218   38.2 *  
453.povray   5320120   44.2 *5320120   44.2 *  
454.calculixNR  NR 
459.GemsFDTDNR  NR 
465.tonto   NR  NR 
470.lbm NR  NR 
481.wrf NR  NR 
482.sphinx3 NR  NR 
 Est. SPECfp_base2006--
 Est. SPECfp2006 --


dealII might be not noise, three runs are

447.dealII  11440319   35.8 S   11440257   44.5 S
447.dealII  11440252   45.4 S   11440257   44.5 *
447.dealII  11440253   45.3 *   11440256   44.7 S

and I think we can take peak values (stupid CPU freq boosting).

I'm re-running just 447.dealII now, results tomorrow.  Binaries do differ.

[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-31
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It seems to somehow "optimize" with regard to the and op being unsigned char
and thus all upper bits being zero and only the lower ones need to be computed?

Before RA

(insn 7 4 8 2 (set (reg:SI 66 [ *b_4(D)+-3 ])
(zero_extend:SI (mem:QI (reg:DI 3 %r3 [ b ]) [0 *b_4(D)+0 S1 A8])))
t.c:3 1209 {*zero_extendqisi2_extimm}
 (expr_list:REG_DEAD (reg:DI 3 %r3 [ b ])
(nil)))
(insn 8 7 11 2 (parallel [
(set (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32])
(and:SI (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32])
(reg:SI 66 [ *b_4(D)+-3 ])))
(clobber (reg:CC 33 %cc))
]) t.c:3 1473 {*andsi3_zarch}
 (expr_list:REG_DEAD (reg:SI 66 [ *b_4(D)+-3 ])
(expr_list:REG_DEAD (reg:DI 2 %r2 [ a ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)

after

(insn 7 4 8 2 (set (reg:SI 66 [ *b_4(D)+-3 ])
(zero_extend:SI (mem:QI (reg:DI 3 %r3 [ b ]) [0 *b_4(D)+0 S1 A8])))
t.c:3 1209 {*zero_extendqisi2_extimm}
 (expr_list:REG_DEAD (reg:DI 3 %r3 [ b ])
(nil)))
(insn 8 7 11 2 (parallel [
(set (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32])
(and:SI (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32])
(reg:SI 66 [ *b_4(D)+-3 ])))
(clobber (reg:CC 33 %cc))
]) t.c:3 1473 {*andsi3_zarch}
 (expr_list:REG_DEAD (reg:SI 66 [ *b_4(D)+-3 ])
(expr_list:REG_DEAD (reg:DI 2 %r2 [ a ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)

but then LRA chooses to spill while reload is happy with the above.

[Bug tree-optimization/70479] FMA is not reassociated causing x2 slowdown vs. ICC

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
You mean we fail to handle ternary associative tree codes in GIMPLE reassoc?
Yes, that's true.  It's not going to be easy to retro-fit there
implementation-wise.  With rebalancing you mean handling reassoc-width > 1?

[Bug tree-optimization/70479] FMA is not reassociated causing x2 slowdown vs. ICC

[kyukhin at gcc dot gnu.org]

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

--- Comment #1 from Kirill Yukhin  ---
(In reply to Kirill Yukhin from comment #0)
> Compile:
>   GCC: g++ -march=haswell -Ofast -flto -fopenmp-simd -fpermissive m.cpp -o
> m.gcc
>   ICC: icpc -O3 -ipo -fpermissive -xAVX2 -qopenmp m.cpp -o m.icc
Correct compile commands (original are for Haswell)
   GCC: g++ -march=knl -Ofast -flto -fopenmp-simd -fpermissive m.cpp -o m.gcc
   ICC: icpc -O3 -ipo -fpermissive -xMIC-AVX512 -qopenmp m.cpp -o m.icc

[Bug tree-optimization/70479] New: FMA is not reassociated causing x2 slowdown vs. ICC

[kyukhin at gcc dot gnu.org]

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

Bug ID: 70479
   Summary: FMA is not reassociated causing x2 slowdown vs. ICC
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyukhin at gcc dot gnu.org
  Target Milestone: ---

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

Attached example demonstrates the issue.
GCC is recent trunk. ICC is v16.

Compile:
  GCC: g++ -march=haswell -Ofast -flto -fopenmp-simd -fpermissive m.cpp -o
m.gcc
  ICC: icpc -O3 -ipo -fpermissive -xAVX2 -qopenmp m.cpp -o m.icc

Run
  GCC: time ./m.icc 2 2
  ICC: time ./m.gcc 2 2

Hot spot generated by GCC (annotated w/ perf hit counts):
157 │8d0:┌─→vbroad 0x4(%r13),%zmm0
193 ││  lea0x1(%rdx),%edx
173 ││  vmulps (%r14,%rax,1),%zmm0,%zmm0
2943││  vbroad 0x60(%r13),%zmm1
166 ││  vbroad 0x5c(%r13),%zmm2
151 ││  vbroad 0x58(%r13),%zmm3
144 ││  vbroad 0x54(%r13),%zmm4
164 ││  vbroad 0x50(%r13),%zmm5
170 ││  vbroad 0x4c(%r13),%zmm6
162 ││  vbroad 0x48(%r13),%zmm7
162 ││  vbroad 0x44(%r13),%zmm8
154 ││  vbroad 0x40(%r13),%zmm9
172 ││  vbroad 0x3c(%r13),%zmm10
167 ││  vbroad 0x38(%r13),%zmm11
172 ││  vbroad 0x34(%r13),%zmm12
171 ││  vbroad 0x30(%r13),%zmm13
161 ││  vbroad 0x2c(%r13),%zmm14
176 ││  vbroad 0x28(%r13),%zmm15
139 ││  vbroad 0x24(%r13),%zmm16
180 ││  vbroad 0x20(%r13),%zmm17
158 ││  vbroad 0x1c(%r13),%zmm18
165 ││  vbroad 0x18(%r13),%zmm19
140 ││  vbroad 0x10(%r13),%zmm21
179 ││  vbroad 0xc(%r13),%zmm22
146 ││  vbroad 0x8(%r13),%zmm23
170 ││  vbroad 0x0(%r13),%zmm24
170 ││  vbroad 0x14(%r13),%zmm20
168 ││  vfmadd (%r15,%rax,1),%zmm24,%zmm0
2732││  mov0xb8(%rsp),%rcx
172 ││  vfmadd (%r11,%rax,1),%zmm23,%zmm0
1649││  vfmadd (%rsi,%rax,1),%zmm22,%zmm0  
  3413││  vfmadd
(%rcx,%rax,1),%zmm21,%zmm0 
   3653││  mov0xc0(%rsp),%rcx  
 182 ││  vfmadd
(%rcx,%rax,1),%zmm20,%zmm0
2806││  mov0xc8(%rsp),%rcx
176 ││  vfmadd (%rcx,%rax,1),%zmm19,%zmm0
2439││  mov0xd0(%rsp),%rcx
179 ││  vfmadd (%rcx,%rax,1),%zmm18,%zmm0
2562││  mov0xd8(%rsp),%rcx
197 ││  vfmadd (%rcx,%rax,1),%zmm17,%zmm0
2867││  mov0xe0(%rsp),%rcx
141 ││  vfmadd (%rcx,%rax,1),%zmm16,%zmm0
3200││  mov0xe8(%rsp),%rcx
156 ││  vfmadd (%rcx,%rax,1),%zmm15,%zmm0
3557││  mov0xf0(%rsp),%rcx
158 ││  vfmadd (%rcx,%rax,1),%zmm14,%zmm0
││  mov0xf8(%rsp),%rcx
143 ││  vfmadd (%rcx,%rax,1),%zmm13,%zmm0
3004││  mov0x100(%rsp),%rcx
177 ││  vfmadd (%rcx,%rax,1),%zmm12,%zmm0
2876││  mov0x108(%rsp),%rcx
144 ││  vfmadd (%rcx,%rax,1),%zmm11,%zmm0
2838││  mov0x110(%rsp),%rcx
168 ││  vfmadd (%rcx,%rax,1),%zmm10,%zmm0
2503││  mov0x118(%rsp),%rcx
203 ││  vfmadd (%rcx,%rax,1),%zmm9,%zmm0
2471││  mov0x120(%rsp),%rcx
185 ││  vfmadd (%rcx,%rax,1),%zmm8,%zmm0
2153││  mov0x128(%rsp),%rcx
152 ││  vfmadd (%r12,%rax,1),%zmm7,%zmm0
2091││  vfmadd (%rbx,%rax,1),%zmm6,%zmm0
3049││  vfmadd (%r10,%rax,1),%zmm5,%zmm0
3737││  vfmadd (%r9,%rax,1),%zmm4,%zmm0
3665││  vfmadd (%r8,%rax,1),%zmm3,%zmm0
3627││  vfmadd (%rdi,%rax,1),%zmm2,%zmm0
3804││  vfmadd (%rcx,%rax,1),%zmm1,%zmm0
4052││  mov0x130(%rsp),%rcx
160 ││  cmp0x138(%rsp),%edx
534 ││  vmovup %zmm0,(%rcx,%rax,1)
3235││  lea0x40(%rax),%rax
161 │└──jb 8d0

Hot spot generated by ICC (annotated w/ perf hit counts):
   344 │47a:┌─→vmulps 0x204c(%r11,%r14,4),%zmm27,%zmm2
   821 ││  vmulps 0x2050(%r11,%r14,4),%zmm4,%zmm1
   318 ││  vmulps 0x2040(%r11,%r14,4),%zmm6,%zmm29
   818 ││  vmulps 0x1840(%r11,%r14,4),%zmm7,%zmm31
   275 ││  vfmadd 0x1838(%r11,%r14,4),%zmm9,%zmm31
  1234 ││  vfmadd 0x183c(%r11,%r14,4),%zmm8,%zmm29
   442 ││  vfmadd 0x2044(%r11,%r14,4),%zmm5,%zmm2
  1110 ││  vfmadd 0x2048(%r11,%r14,4),%zmm28,%zmm1
   337 ││  vaddps %zmm29,%zmm31,%zmm0
  1047 ││  vaddps %zmm1,%zmm2,%zmm3
   655 ││  vmulps 0x1830(%r11,%r14,4),%zmm11,%zmm30
   956 ││  vmulps 0x1834(%r11,%r14,4),%zmm10,%zmm2
   296 ││  vmulps 0x1024(%r11,%r14,4),%zmm15,%zmm1
  1050 ││  vmulps 0x1028(%r11,%r14,4),%zmm14,%zmm31
   294 ││  vaddps %zmm0,%zmm3,%zmm3
  1057 ││  vfmadd 0x102c(%r11,%r14,4),%zmm13,%zmm30
   344 ││  vfmadd 0x1030(%r11,%r14,4),%zmm12,%zmm2
   911 ││  vfmadd 0x1020(%r11,%r14,4),%zmm16,%zmm31
   332 ││  vfmadd 0x820(%r11,%r14,4),%zmm17,%zmm1
   885 ││  vaddps 

[Bug rtl-optimization/70460] [4.9/5/6 Regression] Miscompilation of glibc on i686-linux starting with r234101

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/70460] [4.9/5/6 Regression] Miscompilation of glibc on i686-linux starting with r234101

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 31 13:21:43 2016
New Revision: 234618

URL: https://gcc.gnu.org/viewcvs?rev=234618=gcc=rev
Log:
PR rtl-optimization/70460
* ira.c (indirect_jump_optimize): Don't substitute LABEL_REF
with operand from REG_LABEL_OPERAND, instead substitute
SET_SRC or REG_EQUAL note content if it is a LABEL_REF.
Don't do anything for REG_NON_LOCAL_GOTO jumps.

* gcc.c-torture/execute/pr70460.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr70460.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ira.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70460] [4.9/5/6 Regression] Miscompilation of glibc on i686-linux starting with r234101

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 31 13:13:13 2016
New Revision: 234617

URL: https://gcc.gnu.org/viewcvs?rev=234617=gcc=rev
Log:
PR rtl-optimization/70460
* ira.c (indirect_jump_optimize): Don't substitute LABEL_REF
with operand from REG_LABEL_OPERAND, instead substitute
SET_SRC or REG_EQUAL note content if it is a LABEL_REF.
Don't do anything for REG_NON_LOCAL_GOTO jumps.

* gcc.c-torture/execute/pr70460.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr70460.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/63874] vtable address generation goes through memory

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
(In reply to Richard Earnshaw from comment #1)
> Sounds like this might be confusion between weak definitions and weak
> references.  If we have a weak reference to the object, we cannot convert it
> into a pc-relative expression, since that would mean we couldn't detect
> NULL.  However, if we have a non-weak reference to a weak object we can
> replace that with a pc-relative addressing mode, _provided_ that we can
> guarantee that the definition will appear in the same link unit (ie it's not
> part of building a DSO).

Patch posted here. 

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01680.html

[Bug rtl-optimization/70460] [4.9/5/6 Regression] Miscompilation of glibc on i686-linux starting with r234101

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 31 13:00:52 2016
New Revision: 234614

URL: https://gcc.gnu.org/viewcvs?rev=234614=gcc=rev
Log:
PR rtl-optimization/70460
* ira.c (indirect_jump_optimize): Don't substitute LABEL_REF
with operand from REG_LABEL_OPERAND, instead substitute
SET_SRC or REG_EQUAL note content if it is a LABEL_REF.
Don't do anything for REG_NON_LOCAL_GOTO jumps.

* gcc.c-torture/execute/pr70460.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr70460.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70467] Useless "and [esp],-1" emitted on AND with uint64_t variable

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
That is correct expectation, but the problem is that no pass that uses it
actually manages to update the insn.
As I said earlier, the combiner doesn't trigger, because there is just a single
insn, nothing to combine.
And CSE only triggers for & 0 and similar (which turns it into mem = 0), but
doesn't trigger for the case where we would want a no-op move.
There are two reasons for that.
One is PR35258, which wants to avoid overlapping sets, but doesn't consider
noop moves to be fine.  And then, most of the architectures actually don't
allow MEM to MEM moves, so even if we get through that, we don't validate the
changes.
The following untested patch fixes that:

--- gcc/cse.c.jj2016-02-17 11:40:19.0 +0100
+++ gcc/cse.c   2016-03-31 14:42:27.104824253 +0200
@@ -5166,7 +5166,7 @@ cse_insn (rtx_insn *insn)
}

  /* Avoid creation of overlapping memory moves.  */
- if (MEM_P (trial) && MEM_P (SET_DEST (sets[i].rtl)))
+ if (MEM_P (trial) && MEM_P (dest) && !rtx_equal_p (trial, dest))
{
  rtx src, dest;

@@ -5277,6 +5277,20 @@ cse_insn (rtx_insn *insn)
  break;
}

+ /* Similarly, lots of targets don't allow no-op
+(set (mem x) (mem x)) moves.  */
+ else if (n_sets == 1
+  && MEM_P (trial)
+  && MEM_P (dest)
+  && rtx_equal_p (trial, dest)
+  && !side_effects_p (dest)
+  && (cfun->can_delete_dead_exceptions
+  || insn_nothrow_p (insn)))
+   {
+ SET_SRC (sets[i].rtl) = trial;
+ break;
+   }
+
  /* Reject certain invalid forms of CONST that we create.  */
  else if (CONSTANT_P (trial)
   && GET_CODE (trial) == CONST
@@ -5495,6 +5509,21 @@ cse_insn (rtx_insn *insn)
  sets[i].rtl = 0;
}

+  /* Similarly for no-op MEM moves.  */
+  else if (n_sets == 1
+  && MEM_P (SET_DEST (sets[i].rtl))
+  && MEM_P (SET_SRC (sets[i].rtl))
+  && rtx_equal_p (SET_DEST (sets[i].rtl),
+  SET_SRC (sets[i].rtl))
+  && !side_effects_p (SET_DEST (sets[i].rtl))
+  && (cfun->can_delete_dead_exceptions || insn_nothrow_p (insn)))
+   {
+ if (cfun->can_throw_non_call_exceptions && can_throw_internal (insn))
+   cse_cfg_altered = true;
+ delete_insn_and_edges (insn);
+ sets[i].rtl = 0;
+   }
+
   /* If this SET is now setting PC to a label, we know it used to
 be a conditional or computed branch.  */
   else if (dest == pc_rtx && GET_CODE (src) == LABEL_REF

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
Created attachment 38145
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38145=edit
patch

Attached patch seems to work OK on Linux and removes all string.h includes from
chkp-str* tests.  I believe this should resolve all related issues on Darwing
and other targets.

Could you please test it on Darwin?

[Bug c++/70462] Unnecessary "base object constructor" for final classes

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
(In reply to Richard Biener from comment #1)
> Maybe the ABI mandates these nevertheless.

Right, the ABI doesn't say anything about final classes.  Note that the extra
symbol is only an alias; there aren't two function definitions taking up space.

[Bug target/70292] ICE in verify_target_availability, at sel-sched.c:1584 with -fno-inline -fno-dce -fschedule-insns -fselective-scheduling -fno-tree-dce -O1

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-31
 CC||abel at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrey Belevantsev  ---
(In reply to Andrey Tarasevich from comment #0)
> Created attachment 38016 [details]
> test case with ICE
> 
> This might be a duplicate of bug 64411
> 

It is, I have verified that the patch for 64411 fixes this as well.  However,
the patch is applied to trunk only for now.  I wasn't going to backport it to
gcc-5 because 64411 doesn't have any mentions of the compiler that works.  But
for this test my system opensuse gcc works.  Thus it can be classified as a
regression, and I would backport it to gcc-5 branch and add also this test case
to trunk and gcc 5.

[Bug middle-end/69526] ivopts candidate strangeness

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
So, we don't optimize at -O2

long foo (int a)
{
  return (long)(a + 1) - 1;
}

Note that (T)(A +- CST1) +- CST2 -> (T)A +- CST3 thus the combined
addition in general needs to be done in the larger type _unless_ the
absolute constant value of CST3 is equal or smaller than CST1.

Handling the special case of CST1 == CST2 might be easiest here.

[Bug middle-end/69526] ivopts candidate strangeness

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
(In reply to rdapp from comment #10)
> Created attachment 38144 [details]
> Tentative patch for VRP and loop-doloop
> 
> Meanwhile I found the time to implement a pattern for VRP which seems to do
> the job on tree level. Although larger now (and not many cases are covered
> yet) I suppose I agree that it fits better in VRP than in ivopts and might
> even catch more cases than before.
> 
> The fix on RTL level is nonetheless necessary since doloop calculates the
> number of iterations independently of the code before and also adds a +1.
> I cleaned up the fix a little by introducing niterp1_expr (niter plus 1) but
> there's still room for improvement.
> 
> No regressions so far, improvement ideas welcome.

It's a bit very ad-hoc (looking at the VRP part).  I think what we'd need to
do is

  a) in VRP have a general helper telling you whether UNOP A or A BINOP B
  overflows/underflows

  b) in the existing patterns that would handle this and similar situations
  in match.pd:

/* (A +- CST) +- CST -> A + CST  */
(for outer_op (plus minus)
 (for inner_op (plus minus)
...

  use such a generic predicate to handle cases with (A +- CST) wrapped
  inside a conversion (it should already be fine to handle this case
  if A +- CST cannot overflow because TYPE_OVERFLOW_UNDEFINED).

  c) use fold_stmt (or gimple_simplify directly) in vrp_fold_stmt to
  invoke the folding machinery - eventually simply unconditionally
  call fold_stmt in
tree-ssa-propagate.c:substitute_and_fold_dom_walker::before_dom_children rather
  than only when we progagated into a stmt.

Even when doing the "ad-hoc" thing initially splitting out a) (implementing
only a subset of operations) would be a useful thing to do.  Note that
during VRP itself you can use its own lattice while when not in VRP you'd
have to rely on SSA_NAME_RANGE_INFO.