[Bug tree-optimization/42046] missed optimization (a?b|1:b&~1) where b is a load from memory

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(a?b|1:b&~1) could also be turned into (b&~1)+(a!=0) or (b|1)-(a==0) (or with ^
instead of +-, or | instead of +, etc) but it is quite possible that none of
those are a win.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

--- Comment #20 from Oleg Endo  ---
(In reply to David Binderman from comment #19)
> (In reply to David Binderman from comment #17)
> > I had a go at cross compiling Linux kernel for sh, and got something similar
> > with gcc 5.1.1 dated 20150618
> 
> With recent gcc trunk on x86_64, I get
> 

This doesn't look related to the SH issue here.  Please file a new PR for this
issue.

[Bug tree-optimization/42046] missed optimization (a?b|1:b&~1) where b is a load from memory

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|missed optimization |missed optimization
   ||(a?b|1:b&~1)  where b is a
   ||load from memory
   Severity|normal  |enhancement

[Bug ipa/70366] [6 Regression] chromium fails to build with LTO due to segfault in ipa-inline-transform.c:inline_call

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |6.0
Summary|chromium fails to build |[6 Regression] chromium
   |with LTO due to segfault in |fails to build with LTO due
   |ipa-inline-transform.c:inli |to segfault in
   |ne_call |ipa-inline-transform.c:inli
   ||ne_call

--- Comment #1 from Andrew Pinski  ---
./glslang_lex.cpp:1068:8: warning: type 'struct yyguts_t' violates the C++ One
Definition Rule [-Wodr]
./Tokenizer.cpp:605:8: note: a different type is defined in another translation
unit
./glslang_lex.cpp:1072:19: note: the first difference of corresponding
definitions is field 'yyextra_r'
./Tokenizer.cpp:609:19: note: a field of same name but different type is
defined in another translation unit
../../third_party/angle/src/compiler/translator/ParseContext.h:28:7: note: type
name 'TParseContext' should match type name 'pp::Tokenizer::Context'
 class TParseContext : angle::NonCopyable
   ^
../../third_party/angle/src/compiler/preprocessor/Tokenizer.h:22:12: note: the
incompatible type is defined here
 struct Context
^
lto1: internal compiler error: Segmentation fault
0xa4981f crash_signal
../../gcc.git/gcc/toplev.c:335
0x107c105 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc.git/gcc/tree.h:3005
0x107c105 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../gcc.git/gcc/ipa-inline-transform.c:333
0x1074ac0 inline_small_functions
../../gcc.git/gcc/ipa-inline.c:2022
0x1074ac0 ipa_inline
../../gcc.git/gcc/ipa-inline.c:2432
0x1074ac0 execute
../../gcc.git/gcc/ipa-inline.c:2840


Can you try to reduce the problem?  You can use either multi-delta or any other
reducing program.  Using -r -nostdlib is also useful to reduce it too.

[Bug ipa/70366] New: chromium fails to build with LTO due to segfault in ipa-inline-transform.c:inline_call

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 70366
   Summary: chromium fails to build with LTO due to segfault in
ipa-inline-transform.c:inline_call
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

I tried building Chromium with LTO for arm-linux-gnueabihf and resulted in
segfault.
Backtrace:
http://pastebin.com/sX6yKLBP
Looks like it's probably caused by r231095.
Reverting that commit prevented the segfault.

GYP_DEFINES=target_arch=arm arm_float_abi=hard clang=0 host_clang=0
linux_use_gold_flags=1 linux_use_bundled_binutils=0 disable_nacl=1 werror=

arm-linux-gnueabihf-gcc -v:
Using built-in specs.
COLLECT_GCC=./arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/bilbo/chromium/armhf-toolchain/libexec/gcc/arm-linux-gnueabihf/6.0.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc.git/configure
--prefix=/home/bilbo/chromium/armhf-toolchain
--with-sysroot=/home/bilbo/chromium/src/build/linux/debian_wheezy_arm-sysroot
--enable-languages=c,c++,lto --disable-bootstrap --disable-werror --disable-nls
--with-float=hard --with-mode=thumb --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-tune=cortex-a9 --disable-multilib --enable-multiarch
--target=arm-linux-gnueabihf : (reconfigured) ../gcc.git/configure
--prefix=/home/bilbo/chromium/armhf-toolchain
--with-sysroot=/home/bilbo/chromium/src/build/linux/debian_wheezy_arm-sysroot
--disable-bootstrap --disable-werror --disable-nls --with-float=hard
--with-mode=thumb --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-tune=cortex-a9 --disable-multilib --enable-multiarch
--target=arm-linux-gnueabihf target_alias=arm-linux-gnueabihf
--enable-languages=c,c++,lto --no-create --no-recursion


Thanks,
Prathamesh

[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result

[dc-fukuoka at sgi dot com]

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

--- Comment #2 from Daichi Fukuoka  ---
Hi,

I confirmed that the patch had been applied into gomp-4_0-branch.
Thank you very much for fixing the issue.

Regards,
Daichi Fukuoka

[Bug c++/70344] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in adjust_temp_type, at cp/constexpr.c:1078

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
Problem ultimately seems to be that we're calling cp_fold_function on fn()
before we call cp_genericize on it which is responsible for fixing up fn()'s
parameter 'v' which is passed by invisible reference.  The TREE_TYPE of v is a
RECORD_TYPE before the fix-up, but after the fix-up it's a REFERENCE_TYPE to a
RECORD_TYPE.  The 1st argument to the recursive call to fn() however is a
REFERENCE_TYPE. So in cxx_eval_call_expression (called indirectly from
cp_fold_function) we see that fn() expects a RECORD_TYPE (because its parms
haven't been fixed up yet) but the call passes a REFERENCE_TYPE.  This type
confusion triggers the ICE.

[Bug c++/70344] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in adjust_temp_type, at cp/constexpr.c:1078

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
fn does not have to be a function template to trigger the ICE:

struct Z
{
  Z () = default;
  Z (Z const &) = default;
  constexpr Z (Z &&) {}
};

constexpr int
fn (Z v)
{
  return fn (v);
}

auto t = fn (Z ());

[Bug libstdc++/70360] --enable-vtable-verify

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to psturm from comment #3)
> I understand the test suite cannot contemplate every single combination of
> configure options. However, I would suggest that certain combinations might
> be more common than others.

That certainly doesn't apply to VTV, I don't know of anybody using it.

> I am not a programmer, but I can run the builds with various build
> parameters and report my results. Most of the 2106 failures for libstdc++
> are for "compilation failed to produce executable", so I suspect if we can
> figure out why that is happening, we can dramatically reduce the scope of
> what we need to look at.

Looks in $target/libstdc++-v3/testsuite/libstdc++.log

[Bug libstdc++/70360] --enable-vtable-verify

[psturm at computervoice dot com]

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

--- Comment #3 from psturm at computervoice dot com ---
Created attachment 38064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38064=edit
-default-pie -enable-vtv

I understand the test suite cannot contemplate every single combination of
configure options. However, I would suggest that certain combinations might be
more common than others. My particular area of focus is configuring GCC6 for
the most secure default configuration. Therefore, I am paying particular
attention to:

--enable--default-pie
--enable--default-ssp
--enable-vtable-verify

I have built GCC6 with each of these configure flags individually and reported
the test suite unexpected failures as bugs.

When I built with --enable-default-pie 

The result was bug fixes for the following related issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70192

When I built with --enable-default-ssp

I reported: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230

Richard Biener replied that the 11 regressions were expected for this configure
flag. I plan to revisit this and see if I am capable of modifying the relevant
tests to either be skipped for this configure flag or disable the default that
is passed so the test suite passes. Of note here is that I would have to deal
with 11 failed test cases.

For --enable-vtable-verify I already reported the ABI error that you said was
expected.

I next made a build with the combination of:

--enable--default-pie
--enable-vtable-verify

The result was:

gcc: 4 unexpected failures
libstdc++: 2106 unexpected failures
libvtv: 58 unexpected failures

I am not a programmer, but I can run the builds with various build parameters
and report my results. Most of the 2106 failures for libstdc++ are for
"compilation failed to produce executable", so I suspect if we can figure out
why that is happening, we can dramatically reduce the scope of what we need to
look at.

I have attached the test suite summary for the build that combines default-pie
and vtable-verify. I am building X86_64 on an Intel Broadwell CPU.

Please advise.

[Bug middle-end/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  ---
Comment #1 was incorrect about the problem starting in r233398.  It was my
bswap pattern addition in r233414 that introduced the problem.  On the other
hand, I looked at the bswapdi operation in gdb and it seems correct.

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I haven't had time to debug it beyond observing in the debugger that
remap_decls() defined in tree-inline.c calls add_local_decl() with the first
argument of null.  The argument is cfun (function*).

Both __func__ and __FUNCTION__ also trigger the same ICE.

[Bug target/69846] empty struct value fails to pass properly

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
In C++11 dummy is a POD, and passing non-PODs through varargs is
conditionally-supported anyway (and G++ supports it).

[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|[5 Regression]  |[5/6 Regression]
   |gcc.c-torture/compile/pr374 |gcc.c-torture/compile/pr374
   |33.c ICEs with -mabi=ilp32  |33.c ICEs with -mabi=ilp32

[Bug target/64971] [5 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
Version|5.0 |6.0
 Resolution|WORKSFORME  |---
   Target Milestone|5.0 |---

--- Comment #5 from Andrew Pinski  ---

FAIL: gcc.c-torture/compile/pr37433.c   -O2  (internal compiler error)
FAIL: gcc.c-torture/compile/pr37433.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr37433.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr37433.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr37433.c   -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/pr37433.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr37433.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: gcc.c-torture/compile/pr37433.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)


I definitely can reproduce it on the trunk:
Executing on host: /home/apinski/src/ilp32/gcc/objdir-ilp32/gcc/xgcc
-B/home/apinski/src/ilp32/gcc/objdir-ilp32/gcc/  -fno-diagnostics-show-caret
-fdiagnostics-color=never-O2  -w -c  -mabi=ilp32  -o pr37433.o
/home/apinski/src/ilp32/gcc/gcc/testsuite/gcc.c-torture/compile/pr37433.c   
(timeout = 300)
spawn /home/apinski/src/ilp32/gcc/objdir-ilp32/gcc/xgcc
-B/home/apinski/src/ilp32/gcc/objdir-ilp32/gcc/ -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -w -c -mabi=ilp32 -o pr37433.o
/home/apinski/src/ilp32/gcc/gcc/testsuite/gcc.c-torture/compile/pr37433.c^M
/home/apinski/src/ilp32/gcc/gcc/testsuite/gcc.c-torture/compile/pr37433.c: In
function 'regex_subst':^M
/home/apinski/src/ilp32/gcc/gcc/testsuite/gcc.c-torture/compile/pr37433.c:5:1:
error: unrecognizable insn:^M
(call_insn/j 6 5 7 2 (parallel [^M
(set (reg:SI 0 x0)^M
(call (mem:DI (symbol_ref/f:SI ("*.LC0") [flags 0x82] ) [0 *subst.0_1 S8 A8])^M
(const_int 0 [0])))^M
(return)^M
(use (const_int 0 [0]))^M
])
/home/apinski/src/ilp32/gcc/gcc/testsuite/gcc.c-torture/compile/pr37433.c:4
-1^M
 (expr_list:REG_CALL_DECL (nil)^M
(nil))^M
(expr_list (clobber (reg:DI 17 x17))^M
(expr_list (clobber (reg:DI 16 x16))^M
(expr_list:SI (use (reg:SI 0 x0))^M
(nil)^M
/home/apinski/src/ilp32/gcc/gcc/testsuite/gcc.c-torture/compile/pr37433.c:5:1:
internal compiler error: in extract_insn, at recog.c:2287^M
0xa9dd3f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)^M
../../gcc/rtl-error.c:108^M
0xa9dd87 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)^M
../../gcc/rtl-error.c:116^M
0xa702eb extract_insn(rtx_insn*)^M
../../gcc/recog.c:2287^M
0x854deb instantiate_virtual_regs_in_insn^M
../../gcc/function.c:1630^M
0x854deb instantiate_virtual_regs^M
../../gcc/function.c:1950^M
0x854deb execute^M
../../gcc/function.c:1999^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See <http://gcc.gnu.org/bugs.html> for instructions.^M
compiler exited with status 1

apinski@arm64:~/src/ilp32/gcc/objdir-ilp32/gcc$ ./xgcc --version
xgcc (GCC) 6.0.0 20160322 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug rtl-optimization/67396] [4.9/5/6 regression] Performance regression compiling variadic function with many arguments in RTL DSE

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug middle-end/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #6 from Eric Botcazou  ---
> Attached.  Test fails on "A1.A1 != B1.A1".

Thanks.  Investigating.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[dcb314 at hotmail dot com]

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

--- Comment #19 from David Binderman  ---
(In reply to David Binderman from comment #17)
> I had a go at cross compiling Linux kernel for sh, and got something similar
> with gcc 5.1.1 dated 20150618

With recent gcc trunk on x86_64, I get

$ ~/gcc/results/bin/gcc -c -O3 -march=native gcc.target/i386/pr70300.c
gcc.target/i386/pr70300.c: In function ‘bar’:
gcc.target/i386/pr70300.c:25:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 127 98 128 2 (set (reg:V4SF 53 xmm16 [125])
(vec_select:V4SF (vec_concat:V8SF (reg:V4SF 53 xmm16 [125])
(reg:V4SF 53 xmm16 [125]))
(parallel [
(const_int 0 [0])
(const_int 4 [0x4])
(const_int 1 [0x1])
(const_int 5 [0x5])
]))) gcc.target/i386/pr70300.c:21 2460 {vec_interleave_lowv4sf}
 (nil))
gcc.target/i386/pr70300.c:25:1: internal compiler error: in
extract_constrain_insn, at recog.c:2190
0xb7d207 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/trunk/gcc/rtl-error.c:108
0xb7d23f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/trunk/gcc/rtl-error.c:119
0xb3b39e extract_constrain_insn(rtx_insn*)
../../src/trunk/gcc/recog.c:2190
0xb47120 copyprop_hardreg_forward_1
../../src/trunk/gcc/regcprop.c:774
0xb47f91 execute
../../src/trunk/gcc/regcprop.c:1280
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 

But if I remove the -march=native, all goes well:

$ ~/gcc/results/bin/gcc -c -O3  gcc.target/i386/pr70300.c
$ 

Exact CPU model seems to be

model name  : AMD Phenom(tm) II X4 970 Processor

[Bug target/70232] [6 regression] excessive stack usage with -O2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug target/70232] [6 regression] excessive stack usage with -O2

[law at gcc dot gnu.org]

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

--- Comment #17 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 22 21:32:34 2016
New Revision: 234409

URL: https://gcc.gnu.org/viewcvs?rev=234409=gcc=rev
Log:
PR target/70232
tree-ssa-threadbackward.c
(fsm_find_control_statement_thread_paths): Correctly distinguish
between old style jump threads vs FSM jump threads.

PR target/70232
* gcc.dg/tree-ssa/pr70232.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr70232.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadbackward.c

[Bug libgcc/70363] PowerPC __float128 to long double doesn't link if built with an assember without ISA 3.0 support

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Tue Mar 22 21:05:43 2016
New Revision: 234408

URL: https://gcc.gnu.org/viewcvs?rev=234408=gcc=rev
Log:
2016-03-22  Michael Meissner  

PR libgcc/70363
* config/rs6000/extendkftf2-sw.c (__extendkftf2_sw): If libgcc was
built with an assembler that does not support ISA 3.0
instructions, rename __extendkftf2_sw to __extendkftf2.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/rs6000/extendkftf2-sw.c

[Bug c++/68469] warn_unused_result attribute ignored for templates return templates

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I suspect it is really a dup of bug 66177.

[Bug c++/66177] warn_unused_result doesn't work for non-PODs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jpetri at izotope dot com

--- Comment #2 from Andrew Pinski  ---
*** Bug 70365 has been marked as a duplicate of this bug. ***

[Bug c++/70365] warn_unused_result doesn't warn when the result is a class with a destructor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 66177.

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

[Bug c++/70365] New: warn_unused_result doesn't warn when the result is a class with a destructor

[jpetri at izotope dot com]

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

Bug ID: 70365
   Summary: warn_unused_result doesn't warn when the result is a
class with a destructor
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpetri at izotope dot com
  Target Milestone: ---

The __attribute__((warn_unused_result)) doesn't warn when the function result
is a class with a destructor.

struct Error {
~Error();
};

__attribute__((warn_unused_result)) Error test();

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

Compile as follows:
$ g++ -c test.c
[I get no output, just success.]

System info:
g++ version: g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Ubuntu 15.10, stock distro g++

Also repros on:
http://gcc.godbolt.org/ GCC 6 snapshot, and GCC 5.3.0

[Bug c++/70332] [5/6 Regression] ICE on x86_64-linux-gnu in tsubst_copy, at cp/pt.c:13887

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|static_assert + assert +|[5/6 regression] ICE on
   |c++14 crashes GCC   |__PRETTY_FUNCTION__ in a
   ||constexpr function

--- Comment #6 from Martin Sebor  ---
GCC 4.9 doesn't crash on the code so technically this could be considered a
regression.  Although 4.9 doesn't support C++ 14 constexpr functions consisting
of more than just a return statement, one might say it's not regression.  But
the 5.x and 5.0 both ICE even on the test C++ 11 case below, so I think
considering this a regression would be appropriate.  I've taken the liberty to
do that and also to adjust the Summary to better reflect the root cause of the
ICE.

$ cat v.c && /home/msebor/build/gcc-4.9.3/gcc/xgcc
-B/home/msebor/build/gcc-4.9.3/gcc -S -Wall -Wextra -Wpedantic -std=c++14 -xc++
v.c
constexpr int f () {
return __PRETTY_FUNCTION__ [0];
}

constexpr int i = f ();
v.c: In function ‘constexpr int f()’:
v.c:3:1: error: body of constexpr function ‘constexpr int f()’ not a
return-statement
 }
 ^
v.c: At global scope:
v.c:5:22: error: ‘constexpr int f()’ called in a constant expression
 constexpr int i = f ();
  ^

[Bug c++/70353] static_assert + assert + c++14 crashes GCC

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Blocks||55004
  Known to fail||5.2.1, 6.0

--- Comment #5 from Martin Sebor  ---
The trigger seems to be __PRETTY_FUNCTION__.  Below is a smaller test case:
constexpr int ce (int r)
{
   const char *s = __PRETTY_FUNCTION__;
   return r;
}

constexpr int i = ce (3);

v.c: In function ‘constexpr int ce(int)’:
v.c:3:16: warning: unused variable ‘s’ [-Wunused-variable]
const char *s = __PRETTY_FUNCTION__;
^
v.c: At global scope:
v.c:7:22:   in constexpr expansion of ‘ce(3)’
v.c:7:24: internal compiler error: Segmentation fault
 constexpr int i = ce (3);
^
0x10d5326 crash_signal
/src/gcc/trunk/gcc/toplev.c:335
0x7ce697 bool vec_safe_reserve(vec*&, unsigned int, bool)
/src/gcc/trunk/gcc/vec.h:553
0x7ce1aa tree_node** vec_safe_push(vec*&, tree_node* const&)
/src/gcc/trunk/gcc/vec.h:647
0xd48a73 add_local_decl(function*, tree_node*)
/src/gcc/trunk/gcc/function.c:6795
0x1169cf1 remap_decls
/src/gcc/trunk/gcc/tree-inline.c:620
0x116a19a remap_block
/src/gcc/trunk/gcc/tree-inline.c:688
0x116a55d copy_bind_expr
/src/gcc/trunk/gcc/tree-inline.c:761
0x116ba51 copy_tree_body_r(tree_node**, int*, void*)
/src/gcc/trunk/gcc/tree-inline.c:1095
0x140ec4b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
/src/gcc/trunk/gcc/tree.c:11531
0x11720b8 copy_tree_body
/src/gcc/trunk/gcc/tree-inline.c:2946
0x117b678 copy_fn(tree_node*, tree_node*&, tree_node*&)
/src/gcc/trunk/gcc/tree-inline.c:6151
0xa7a19d cxx_eval_call_expression
/src/gcc/trunk/gcc/cp/constexpr.c:1368
0xa81d72 cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3407
0xa83fb3 cxx_eval_outermost_constant_expr
/src/gcc/trunk/gcc/cp/constexpr.c:3973
0xa84611 cxx_constant_value(tree_node*, tree_node*)
/src/gcc/trunk/gcc/cp/constexpr.c:4062
0x89f86c store_init_value(tree_node*, tree_node*, vec**, int)
/src/gcc/trunk/gcc/cp/typeck2.c:822
0x7ec411 check_initializer
/src/gcc/trunk/gcc/cp/decl.c:6155
0x7ef3db cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/src/gcc/trunk/gcc/cp/decl.c:6800
0x9282b6 cp_parser_init_declarator
/src/gcc/trunk/gcc/cp/parser.c:18658
0x91d806 cp_parser_simple_declaration
/src/gcc/trunk/gcc/cp/parser.c:12379
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

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

[Bug libgcc/70363] PowerPC __float128 to long double doesn't link if built with an assember without ISA 3.0 support

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 38063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38063=edit
Proposed patch to fix the problem

[Bug testsuite/70364] New: gcc.target/i386/cleanup-[12].c don't align stack properly

[hjl.tools at gmail dot com]

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

Bug ID: 70364
   Summary: gcc.target/i386/cleanup-[12].c don't align stack
properly
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

gcc.target/i386/cleanup-[12].c has

   ".subsection 1\n\t"
".type  _L_mutex_lock_%=, @function\n"
"_L_mutex_lock_%=:\n"
"1:\t"  "leaq   %1, %%rdi\n"
"2:\t"  "subq   $128, %%rsp\n"
"3:\t"  "call   bar\n"
"4:\t"  "addq   $128, %%rsp\n"
"5:\t"  "jmp24f\n"
"6:\t"  ".size _L_mutex_lock_%=, .-_L_mutex_lock_%=\n\t"

It doesn't align stack to 16-byte boundary when calling bar.

[Bug c++/70353] static_assert + assert + c++14 crashes GCC

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
But we want to avoid the #include .

[Bug libgcc/70363] PowerPC __float128 to long double doesn't link if built with an assember without ISA 3.0 support

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-22
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/70353] static_assert + assert + c++14 crashes GCC

[mrlika at gmail dot com]

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

--- Comment #3 from Andriy Lysnevych  ---
static_assert is not required. This code also crashes:

#include 

constexpr int ce(int r) {
  assert(r == 3);
  return r;
}

const auto c = ce(3);

Problem is in assert called from constexpr function.

[Bug libgcc/70363] New: PowerPC __float128 to long double doesn't link if built with an assember without ISA 3.0 support

[meissner at gcc dot gnu.org]

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

Bug ID: 70363
   Summary: PowerPC __float128 to long double doesn't link if
built with an assember without ISA 3.0 support
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38062=edit
Compile this file with -DDEBUG to see the problem

If you build a GCC compiler from the trunk and build it with an assembler that
does not have support for the ISA 3.0 IEEE 128-bit instructions, and convert
__float128 to long double (or __ibm128), you will get a link error:

test-float128-6.c:(.text+0x84): undefined reference to `__extendkftf2'

This is due to the support in libgcc to allow using the ISA 3.0 instructions
via ifunc functions if you are running on a system with the instructions. 
However, if you build libgcc with an assembler that doesn't support these
instructions, it should eliminate the ifunc support, and compile all of the
emulator functions without the _sw suffix.

Unfortunately extendkftf2-sw.c did not have the proper #ifdef support.

[Bug target/70355] [5/6 Regression] ICE: in simplify_subreg_concatn, at lower-subreg.c:617 with -funroll-loops -mavx512f

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

[Bug target/70302] [6 Regression] crash on valid code at -O2 and -O3 in 32-bit mode on x86_64-linux-gnu (in convert_op, at config/i386/i386.c:3414)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Fixed by Ilya's patch on the trunk.

[Bug target/70302] [6 Regression] crash on valid code at -O2 and -O3 in 32-bit mode on x86_64-linux-gnu (in convert_op, at config/i386/i386.c:3414)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

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

[Bug target/70302] [6 Regression] crash on valid code at -O2 and -O3 in 32-bit mode on x86_64-linux-gnu (in convert_op, at config/i386/i386.c:3414)

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 22 19:00:14 2016
New Revision: 234406

URL: https://gcc.gnu.org/viewcvs?rev=234406=gcc=rev
Log:
2016-03-22  Ilya Enkovich  

PR target/70302
* config/i386/i386.c (scalar_chain::convert_op): Support
uninitialized register usage case.

PR target/70302
* gcc.target/i386/pr70302.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70302.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70232] [6 regression] excessive stack usage with -O2

[law at redhat dot com]

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

--- Comment #16 from Jeffrey A. Law  ---
So for thread paths noted in c#15 we have the following pieces of data

1. 69 statements to copy

2. 7 blocks to copy

3. Threads through latch, but does not create an irreducible loop

4. Eliminates a simple conditional branch, not a multiway branch


tree-ssa-threadbackwards is used for 2 cases.  Its first (and original) purpose
was to catch FSM loops.  Those are characterized by threading through the latch
and eliminating a multi-way branch at the end of path.  These are very
profitable and as such they allow for a lot of copying (100 statements).

The second case is as a replacement for the older forward-walking jump
threading done by VRP/DOM that we're phasing out.  These are less profitable
and have much lower copying thresholds.

#4 means that we've got the latter case.  But the code is not identifying it as
such.  The code tests !threaded_through_latch when it should be testing
!(threaded_through_latch && threaded_multiway_branch).

Fixing that results in all those threads around the loop being rejected as
needing too many statement copies.  Only two small/short jump threads are
realized.  All the undesirable copying is gone and we have a stack size of 140
bytes.

[Bug target/70355] [5/6 Regression] ICE: in simplify_subreg_concatn, at lower-subreg.c:617 with -funroll-loops -mavx512f

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-22
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.4
Summary|ICE: in |[5/6 Regression] ICE: in
   |simplify_subreg_concatn, at |simplify_subreg_concatn, at
   |lower-subreg.c:617 with |lower-subreg.c:617 with
   |-funroll-loops -mavx512f|-funroll-loops -mavx512f
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Tried to bisect it, but ended up with r212638, which looks just weird.
Anyway, 4.9 doesn't ICE.

[Bug middle-end/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2016-03-21 4:45 PM, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70319
>
> --- Comment #2 from Eric Botcazou  ---
> Unfortunately I can reproduce neither on 32-bit nor on 64-bit SPARC, so this
> might come from the RTL expander.  But experience showed that this might also
> come from the SRA pass.
>
> Can you attach a reduced testcase for gcc.dg/sso/q2.c which aborts at -Og?
Attached.  Test fails on "A1.A1 != B1.A1".

This might be mine.  I see the test uses the new DImode bswap pattern 
that I recently
added.

[Bug middle-end/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
Created attachment 38061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38061=edit
q2.c.290r.final

[Bug target/70362] New: 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

Bug ID: 70362
   Summary: Segmentation fault compiling scalar-by-value-4_x.c for
ARM arch < 4
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmargetts at ocz dot com
  Target Milestone: ---

This testcase fails with a segmentation fault on ARM architectures less then v4
(I.e. where halfword load/store are synthesised from byte accesses)

/usr/julien/toolchain_build_rel/gcc-4.9.3/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c:74:1:
internal compiler error: Segmentation fault
 T(cs, _Complex short, CINT (1, 2))
 ^
0x83650f crash_signal
../../gcc-4.9.0/gcc/toplev.c:337
0xa4bf2c arm_reload_out_hi(rtx_def**)
../../gcc-4.9.0/gcc/config/arm/arm.c:15063
0xa8475f gen_reload_outhi(rtx_def*, rtx_def*, rtx_def*)
../../gcc-4.9.0/gcc/config/arm/arm.md:7035
0x751f5d check_and_process_move
../../gcc-4.9.0/gcc/recog.h:285
0x751f5d curr_insn_transform
../../gcc-4.9.0/gcc/lra-constraints.c:3282
0x752c68 lra_constraints(bool)
../../gcc-4.9.0/gcc/lra-constraints.c:4216
0x744566 lra(_IO_FILE*)
../../gcc-4.9.0/gcc/lra.c:2353
0x70e435 do_reload
../../gcc-4.9.0/gcc/ira.c:5457
0x70e435 rest_of_handle_reload
../../gcc-4.9.0/gcc/ira.c:5598
0x70e435 execute
../../gcc-4.9.0/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.


Configured with: ../gcc-4.9.0/configure --target=arm-none-eabi
--enable-languages=c,c++ --with-newlib --with-gnu-as --with-gnu-ld
--disable-nls --disable-shared --disable-multilib --disable-threads
--with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch
--disable-libmudflap --disable-libgomp --disable-libunwind --with-system-zlib
--disable-newlib-supplied-syscalls


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

This problem does not exist in 4.8.5, but does in 4.9.0

[Bug target/70356] gcc.target/i386/avx-vextractf128-256-5.c FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Seems this test is the only one in gcc.target/i386 that has
dg-require-effective-target above dg-do.
Can you please try:
--- gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c  2016-01-28
22:02:17.029720615 +0100
+++ gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c  2016-03-22
19:18:25.946107764 +0100
@@ -1,5 +1,5 @@
-/* { dg-require-effective-target avx512f } */
 /* { dg-do assemble { target { ! ia32 } } } */
+/* { dg-require-effective-target avx512f } */
 /* { dg-options "-O2 -mavx512f" } */

 #include 

?

[Bug target/70356] gcc.target/i386/avx-vextractf128-256-5.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I see the r231167 trunk commit has not added this, while r232001 backport has
added it.  Kirill, can you please have a look?
But, avx-vextractf128-256-5.c has:
dg-require-effective-target avx512f, so wonder what is the problem.
Does the order of dg-do vs. dg-require-effective-target matter?

[Bug libstdc++/68210] nothrow operator fails to call default new

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The dup PR 65290 pointed out the requirements were changed by
http://cplusplus.github.io/LWG/lwg-defects.html#206 -- we still implement the
C++03 rules.

We should fix this. However, the C++11 requirement means that the nothrow
version of new has to pay for the throw/catch overhead. If we could tell when
these functions have not been replaced we could avoid that overhead.

Also we certainly don't want to conform to the new requirement when libstdc++
is built with -fno-exceptions, because allocation failure would abort in
operator new(size_t) and so the nothrow version never gets a chance to handle
the exception and return null.

We will also need to change operator new[](size_t, nothrow_t) which currently
calls operator new(size_t, nothrow_t), rather than operator new[](size_t) as
required. If a user only replaces operator new[](size_t) then their replacement
won't be called by operator new[](size_t, nothrow_t). Again, what we implement
is the C++03 rule.

[Bug libstdc++/68210] nothrow operator fails to call default new

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||kariya_mitsuru at hotmail dot 
com

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

[Bug libstdc++/65290] [C++11] operator new(std::size_t, const std::nothrow_t&) should call operator new(std::size_t)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
There's a more detailed testcase in bug 68210

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

[Bug middle-end/69845] [4.9/5/6 Regression] Expression getting incorrectly optimized after being rewritten by compiler

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson  ---
Proposed patch
  https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01255.html

[Bug c++/70361] Obviously false code in if not detected

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Maybe the new -Wtautological-compare flag could be extended to warn about these
kinds of conditionals.

[Bug target/70232] [6 regression] excessive stack usage with -O2

[law at redhat dot com]

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

--- Comment #15 from Jeffrey A. Law  ---
So this is definitely related to the FSM threader not being able to share a
single jump threading path.  Here's an example:

j.c.110t.dom2:  Registering FSM jump thread: (23, 25) incoming edge;  (25, 28) 
(28, 27)  (27, 11)  (11, 13)  (13, 14)  (14, 24) nocopy; (14, 24) 
j.c.110t.dom2:  Registering FSM jump thread: (22, 25) incoming edge;  (25, 28) 
(28, 27)  (27, 11)  (11, 13)  (13, 14)  (14, 24) nocopy; (14, 24) 


Note that the only difference is the incoming edge.  The old threader would
duplicate the path once and redirect both incoming edges to that single
duplicate path.   The FSM threader doesn't have that ability and won't until
gcc-7.

In bb27 and bb11 we have a fairly significant sequence of shifts and ior
operations that result in the large number of duplicated statements.

I'm a bit surprised that the statements-to-copy clamp didn't kick in here and
that's what I'll be looking at for gcc-6.  For gcc-7 sharing jump thread paths
is high on the TODO list.

[Bug c/69993] Misleading wording for -Wmisleading-indentation

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed as of r234403.  I've also updated the website:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01249.html

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #6)
> I see the problem: It's -Wall that suppresses the error.

Yeah, seems with -Wall ctx->quiet is true (probably desirable, for some kind of
warning we don't want to warn multiple times), but likely we then cache the
results in a hash table.
So we either need to cache also the ctx->quiet flag along with the from and to
trees and only use cache if either ctx->quiet or if the cached quiet value
matches the remembered value, or not cache ctx->quiet lookups (bad), or cache
the warnings/errors we need to emit along with the cached values.

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I see the problem: It's -Wall that suppresses the error.

[Bug libstdc++/57498] rethrow_exception causes segfault when another exception is active and catch present

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
Yes, it looks like a dup.

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

[Bug libstdc++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||f.heckenb...@fh-soft.de

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

[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #4 from James Greenhalgh  ---
Hi, sorry I missed this. I need to write a better filter for bugs I'm CCed on,
I'll work on that.

I'm hitting the limits of what I can guess from the Sparc machine files. I
don't understand why we get an expansion for the conditional branch that
explicitly generates new temporaries for i and j, necessitating an if..else..
structure. 

Compare how we expand on Sparc:

---
(insn 12 5 13 2 (set (reg:CC 100 %icc)
(compare:CC (subreg/s/u:SI (reg/v:DI 113 [ xD.1388+-4 ]) 4)
(subreg/s/u:SI (reg/v:DI 114 [ yD.1389+-4 ]) 4)))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 -1
 (nil))
(jump_insn 13 12 14 2 (set (pc)
(if_then_else (le (reg:CC 100 %icc)
(const_int 0 [0]))
(label_ref:DI 29)
(pc))) ../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 48
{*normal_branch}
 (int_list:REG_BR_PROB 3900 (nil))
 -> 29)
;;  succ:   4 [61.0%]  (FALLTHRU)
;;  5 [39.0%] 

;; basic block 4, loop depth 0, count 0, freq 6100, maybe hot
;;  prev block 2, next block 5, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:   2 [61.0%]  (FALLTHRU)
(note 14 13 8 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 8 14 9 4 (set (reg/v:SI 110 [ jD.1394 ])
(subreg:SI (reg/v:DI 115 [ aD.1390+-4 ]) 4))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:15 -1
 (nil))
(insn 9 8 26 4 (set (reg/v:SI 109 [ iD.1393 ])
(subreg:SI (reg/v:DI 115 [ aD.1390+-4 ]) 4))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:14 -1
 (nil))
(jump_insn 26 9 27 4 (set (pc)
(label_ref 15)) -1
 (nil)
 -> 15)
;;  succ:   6 [100.0%] 

(barrier 27 26 29)
;; basic block 5, loop depth 0, count 0, freq 3900, maybe hot
;;  prev block 4, next block 6, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:   2 [39.0%] 
(code_label 29 27 28 5 3 "" [1 uses])
(note 28 29 6 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 6 28 7 5 (set (reg/v:SI 110 [ jD.1394 ])
(subreg:SI (reg/v:DI 114 [ yD.1389+-4 ]) 4)) -1
 (nil))
(insn 7 6 15 5 (set (reg/v:SI 109 [ iD.1393 ])
(subreg:SI (reg/v:DI 113 [ xD.1388+-4 ]) 4)) -1
 (nil))
;;  succ:   6 [100.0%]  (FALLTHRU)

;; basic block 6, loop depth 0, count 0, freq 1, maybe hot
;;  prev block 5, next block 1, flags: (NEW, REACHABLE, RTL)
;;  pred:   5 [100.0%]  (FALLTHRU)
;;  4 [100.0%] 
(code_label 15 7 16 6 2 "" [1 uses])
(note 16 15 17 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 17 16 18 6 (set (reg:DI 117)
(mult:DI (subreg:DI (reg/v:SI 109 [ iD.1393 ]) 0)
(subreg:DI (reg/v:SI 110 [ jD.1394 ]) 0)))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:17 -1
 (nil))

---

Where [bb 5] acts as an else block setting registers 109/110 to the "old"
values. And the AArch64 expansion of the same:

---

(insn 10 5 11 2 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 74 [ xD.2750 ])
(reg/v:SI 75 [ yD.2751 ])))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 -1
 (nil))
(jump_insn 11 10 12 2 (set (pc)
(if_then_else (le (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 13)
(pc))) ../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 -1
 (int_list:REG_BR_PROB 3900 (nil))
 -> 13)
;;  succ:   4 [61.0%]  (FALLTHRU)
;;  5 [39.0%] 

;; basic block 4, loop depth 0, count 0, freq 6100, maybe hot
;;  prev block 2, next block 5, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:   2 [61.0%]  (FALLTHRU)
(note 12 11 6 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 6 12 7 4 (set (reg/v:SI 75 [ yD.2751 ])
(reg/v:SI 76 [ aD.2752 ]))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:15 -1
 (nil))
(insn 7 6 13 4 (set (reg/v:SI 74 [ xD.2750 ])
(reg/v:SI 76 [ aD.2752 ]))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:14 -1
 (nil))
;;  succ:   5 [100.0%]  (FALLTHRU)

;; basic block 5, loop depth 0, count 0, freq 1, maybe hot
;;  prev block 4, next block 1, flags: (NEW, REACHABLE, RTL)
;;  pred:   2 [39.0%] 
;;  4 [100.0%]  (FALLTHRU)
(code_label 13 7 14 5 2 "" [1 uses])
(note 14 13 15 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 15 14 16 5 (set (reg:SI 77)
(mult:SI (reg/v:SI 74 [ xD.2750 ])
(reg/v:SI 75 [ yD.2751 ])))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:17 -1
 (nil))

---

I guess it is those subregs down from DImode to SImode. Sure enough, if we swap
int for long in this testcase, we get the expected expansion and the expected
number of true changes made.

So, I'm not worried that the optimization is broken for Sparc (it does the
right thing for long), but I'm not sure I know the best way to work around this
for your target. swapping int for long would also help HPPA. HPPA chose to skip
the test entirely. That might also be right for Sparc.

What do you think?

[Bug c++/57498] rethrow_exception causes segfault when another exception is active and catch present

[curlypaul924 at gmail dot com]

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

Paul Brannan  changed:

   What|Removed |Added

 CC||curlypaul924 at gmail dot com

--- Comment #1 from Paul Brannan  ---
Found this via a google search because I was trying to track down unexplained
behavior I'm seeing in std::rethrow_exception.

I tried the attached test case on 5.3.0 and std::terminate does get called.

Perhaps this was fixed with #60612?

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 38054 [details]

Hmm.  Something else must be going on.  I've applied your patch on powerpc64le
but it hasn't changed anything.

[Bug tree-optimization/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Sadly, it will slightly penalize code that use 64-bit shift
counts (defined within the vectorized loop), by adding a vectorized and in
there;  but the information whether the 64-bit value had been passed unmodified
into the shift count or whether something has been added to it or subtracted
from it or otherwise modified the upper 32 bits is lost, unless we keep the
shift counters in the type that has been there (or widen to int if narrower).
But that would penalize scalar code.

[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
That's odd.  I do have local changes in my tree but I verified it on three
other machines.  I've retested with today's pristine top of trunk on
powerpc64le, still with no errors.

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Sorry Richi, no jump threads in this code, so it's not the root cause of any
codesize regressions.

[Bug c++/70361] Obviously false code in if not detected

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
-Wunreachable-code does nothing now and has not for a few years now.  Support
for it was removed as it provided too many false positives.

[Bug c++/70361] New: Obviously false code in if not detected

[dcb314 at hotmail dot com]

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

Bug ID: 70361
   Summary: Obviously false code in if not detected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Derived from code in the Linux kernel, the following C++ source code produces
no warning with gcc trunk

extern void g(int);

void f( int n)
{
if ((n & 0x02) == 1)
g( n);
}

$ ~/gcc/results/bin/gcc -c -Wunreachable-code  -O2 -Wall -Wextra bug275.cc
$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/trunk/configure --prefix=/home/dcb/gcc/results
--disable-bootstrap --disable-multilib --disable-werror --enable-checking=yes
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 6.0.0 20160321 (experimental) (GCC) 
$

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> My #1 bet would be FSM threading.

I doubt it as if I read the asm differences correctly, GCC 6 just no longer
does store with post increment and that causes register allocation differences.
 AKA there is no extra jump threading; just extra moves.  Like:

  68:   e1a05004mov r5, r4
  6c:   eaecb   24 

so it might be caused by out of SSA differences too :)

[Bug libstdc++/70360] --enable-vtable-verify

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
... and the testsuite doesn't know how to test the ABI for every configuration
that alters the ABI.

[Bug libstdc++/70360] --enable-vtable-verify

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
That's unsurprising, I'm pretty sure the vtable verification changes the ABI.

[Bug libstdc++/70360] New: --enable-vtable-verify

[psturm at computervoice dot com]

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

Bug ID: 70360
   Summary: --enable-vtable-verify
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psturm at computervoice dot com
  Target Milestone: ---

Built GCC6 SVN 234355 with patch for PR C++/70273

Test suite executed as expected with no unexpected failures in gcc or g++ and
only the two experimental failures in libstdc++.

Rebuilt GCC6 adding the --enable-vtable-verify. New test suite failure for
libstdc++:

FAIL: libstdc++abi/abi_check

[Bug target/70321] [6 Regression] STV generates less optimized code

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Why couldn't STV just "vectorize" AND and NOT patterns and let the combiner
> > combine that in the vectorized code?
> 
> I think the only thing we miss for that is corresponding NOT pattern in DI
> mode.

It is PR 70322.

[Bug c++/70343] internal compiler error: in tsubst_copy, wrong code with lambda in template fn

[tower120 at gmail dot com]

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

--- Comment #2 from tower120  ---
The workaround for all versions is use lambda that doesn't CAPTURE this, e.g.

http://coliru.stacked-crooked.com/a/e223ddb156d817c1


struct Empty{};

template 
struct Data{
int properties_parcel4[10];

Empty j = [](auto& self){
 self.properties_parcel4[0] = 10;
return Empty(); 
}(*this);
};

int main () {
Data k;

  return 0;
}


P.S. This maybe somehow related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636 - problem workarounds are
same.

[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 22 14:38:42 2016
New Revision: 234405

URL: https://gcc.gnu.org/viewcvs?rev=234405=gcc=rev
Log:
2016-03-22  Richard Biener  

PR middle-end/70251
* genmatch.c (gen_transform): Adjust last parameter to a three-state
int...
(capture::gen_transform): ... to change behavior when substituting
a condition into cond or not-cond expr context.
(dt_simplify::gen_1): Adjust.
* gimple-match-head.c: Include gimplify.h for unshare_expr.
* match.pd (A + (B vcmp C ? 1 : 0) -> A - (B vcmp C)): Revert
last change and instead change to
A + (B vcmp C ? 1 : 0) -> A - (B vcmp C ? -1 : 0).
(A - (B vcmp C ? 1 : 0) -> A + (B vcmp C)): Likewise.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr70251.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c
trunk/gcc/gimple-match-head.c
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c/69993] Misleading wording for -Wmisleading-indentation

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Tue Mar 22 14:20:49 2016
New Revision: 234403

URL: https://gcc.gnu.org/viewcvs?rev=234403=gcc=rev
Log:
PR c/69993: improvements to wording of -Wmisleading-indentation

gcc/c-family/ChangeLog:
PR c/69993
* c-indentation.c (warn_for_misleading_indentation): Rewrite the
diagnostic text, reversing the order of the warning and note so
that they appear in source order.

gcc/testsuite/ChangeLog:
PR c/69993
* c-c++-common/Wmisleading-indentation-3.c: New test, based on
Wmisleading-indentation.c.
* c-c++-common/Wmisleading-indentation.c: Update thoughout to
reflect change to diagnostic text and order of messages.
* gcc.dg/plugin/location-overflow-test-2.c: Likewise.


Added:
trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation-3.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-indentation.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
trunk/gcc/testsuite/gcc.dg/plugin/location-overflow-test-2.c

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||law at gcc dot gnu.org
   Host|linux   |
Version|unknown |6.0
   Target Milestone|--- |6.0
Summary|Code size increase for ARM  |[6 Regression] Code size
   |compared to gcc-5.3.0   |increase for ARM compared
   ||to gcc-5.3.0

--- Comment #1 from Richard Biener  ---
My #1 bet would be FSM threading.

[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
The problem is that there is a PARM_DECL in the IL of the function
which is not listed among DECL_ARGUMENTS of the function:

The function we are in is:

(gdb) call debug_generic_expr(cfun->decl)
foo._omp_fn.0

but look at the context of the PARM_DECL in question:

(gdb) call debug_tree (op)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x76891888 precision
32 min  max  context 
pointer_to_this >
addressable used unsigned SI file pr70348.c line 7 col 26 size  unit size 
align 32 context  arg-type >


Also, if you check the uid of the PARM_DECL:

(gdb) p op->decl_minimal.uid
$3 = 2907

you will see that it corresponds to a parameter the original function
foo, from which OpenACC outlined bits to foo._omp_fn.0:

   foo (intD.6 nD.2906, unsigned intD.9 sumD.2907)


And just by the way, because of the context mismatch, the testcase
ICEs in expand_expr_real_1 when compiled at -O0:

pr70348.c: In function ‘foo._omp_fn.0’:
pr70348.c:11:9: internal compiler error: in expand_expr_real_1, at expr.c:9651
 #pragma acc parallel reduction(+:sum)
 ^~~
0xa61521 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/mjambor/gcc/icln/src/gcc/expr.c:9645
0xa5a4c3 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/mjambor/gcc/icln/src/gcc/expr.c:7962
0xa5178b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/mjambor/gcc/icln/src/gcc/expr.c:5406
0xa5039c expand_assignment(tree_node*, tree_node*, bool)
/home/mjambor/gcc/icln/src/gcc/expr.c:5175
0x90e4bc expand_gimple_stmt_1
/home/mjambor/gcc/icln/src/gcc/cfgexpand.c:3618
0x90e8ad expand_gimple_stmt
/home/mjambor/gcc/icln/src/gcc/cfgexpand.c:3714
0x9159be expand_gimple_basic_block
/home/mjambor/gcc/icln/src/gcc/cfgexpand.c:5720
0x917487 execute
/home/mjambor/gcc/icln/src/gcc/cfgexpand.c:6335

All in all, this is an OpenACC lowering/expansion bug.

[Bug target/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #10 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #8)
> About the shifting of negative value, wonder if it isn't actually UBSAN bug,
> Marek, does C really say that -1 << 0 is invalid, or just -1 << 1?

I think -1 << 0 is still UB: it's a left shift, the left operand has a signed
type, but not nonnegative value.

[Bug target/70321] [6 Regression] STV generates less optimized code

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #6)
> Why couldn't STV just "vectorize" AND and NOT patterns and let the combiner
> combine that in the vectorized code?

I think the only thing we miss for that is corresponding NOT pattern in DI
mode.

For comparison we have

{r94:SI=r89:DI#4|r89:DI#0;clobber flags:CC;}
flags:CCZ=cmp(r94:SI,0)

combined into

{flags:CCZ=cmp(r89:DI#4|r89:DI#0,0);clobber scratch;}

which is converted into PTEST by STV.

[Bug c++/70340] Invalid constexpr template function causes internal compiler error (memory exhaustion)

[gccBugs at haatschii dot de]

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

--- Comment #3 from gccBugs at haatschii dot de ---
(In reply to Richard Biener from comment #2)

Not sure whether I understood you correctly, but I don't think that this is
purely a problem with the complexity/recursion depth. For example the same
error also occurs if '73ul' is replaced by '1ul' or even by non constant e.g.
'argC'.

[Bug target/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Simpler testcase:

unsigned long long a[64], b[64];

__attribute__((noinline, noclone)) void
foo (void)
{
  int i;
  for (i = 0; i < 64; i++)
a[i] <<= (b[i] - 0x12ULL);
}

int
main ()
{
  int i;
  for (i = 0; i < 64; i++)
{
  a[i] = 0x1234ULL;
  b[i] = 0x12ULL + (i % 54);
}
  foo ();
  for (i = 0; i < 64; i++)
if (a[i] != (0x1234ULL << (i % 54)))
  __builtin_abort ();
  return 0;
}

[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  ---
James, could you please have a look?  AFAICS, none of the issues mentioned in
PR testsuite/68232 apply to the sparcv9 case: sparc/sparc.h (BRANCH_COST) is >
0.

Thanks.
  Rainer

[Bug target/70359] New: Code size increase for ARM compared to gcc-5.3.0

[fredrik.hederstie...@securitas-direct.com]

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

Bug ID: 70359
   Summary: Code size increase for ARM compared to gcc-5.3.0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fredrik.hederstie...@securitas-direct.com
  Target Milestone: ---

Created attachment 38058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38058=edit
inttostr.c

Code size increase on master for ARM target compared to gcc-5.3.0
Target: arm-none-eabi
Flags: -Os -mcpu=arm966e-s -marm

gcc 5.3.0:

 :
   0:   e3a03000mov r3, #0
   4:   e92d4070push{r4, r5, r6, lr}
   8:   e1a06000mov r6, r0
   c:   e2422001sub r2, r2, #1
  10:   e0205fc0eor r5, r0, r0, asr #31
  14:   e0455fc0sub r5, r5, r0, asr #31
  18:   e0814002add r4, r1, r2
  1c:   e7c13002strbr3, [r1, r2]
  20:   e1a5mov r0, r5
  24:   e3a0100amov r1, #10
  28:   ebfebl  0 <__aeabi_uidivmod>
  2c:   e2811030add r1, r1, #48 ; 0x30
  30:   e5641001strbr1, [r4, #-1]!
  34:   e1a5mov r0, r5
  38:   e3a0100amov r1, #10
  3c:   ebfebl  0 <__aeabi_uidiv>
  40:   e2505000subsr5, r0, #0
  44:   1af5bne 20 
  48:   e356cmp r6, #0
  4c:   b3a0302dmovlt   r3, #45 ; 0x2d
  50:   b5443001strblt  r3, [r4, #-1]
  54:   b2444001sublt   r4, r4, #1
  58:   e1a4mov r0, r4
  5c:   e8bd8070pop {r4, r5, r6, pc}


gcc-6-20160313 snapshot from master:

 :
   0:   e3a03000mov r3, #0
   4:   e92d41f0push{r4, r5, r6, r7, r8, lr}
   8:   e1a07000mov r7, r0
   c:   e3a0800amov r8, #10
  10:   e2422001sub r2, r2, #1
  14:   e0206fc0eor r6, r0, r0, asr #31
  18:   e0466fc0sub r6, r6, r0, asr #31
  1c:   e0815002add r5, r1, r2
  20:   e7c13002strbr3, [r1, r2]
  24:   e1a6mov r0, r6
  28:   e1a01008mov r1, r8
  2c:   ebfebl  0 <__aeabi_uidivmod>
  30:   e2811030add r1, r1, #48 ; 0x30
  34:   e5451001strbr1, [r5, #-1]
  38:   e1a6mov r0, r6
  3c:   e1a01008mov r1, r8
  40:   ebfebl  0 <__aeabi_uidiv>
  44:   e2506000subsr6, r0, #0
  48:   e2454001sub r4, r5, #1
  4c:   1a05bne 68 
  50:   e357cmp r7, #0
  54:   b3a0302dmovlt   r3, #45 ; 0x2d
  58:   b5443001strblt  r3, [r4, #-1]
  5c:   b2454002sublt   r4, r5, #2
  60:   e1a4mov r0, r4
  64:   e8bd81f0pop {r4, r5, r6, r7, r8, pc}
  68:   e1a05004mov r5, r4
  6c:   eaecb   24 

[Bug libfortran/69788] FAIL: gfortran.dg/derived_constructor_comps_6.f90 -O0 execution test

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11,  |hppa2.0w-hp-hpux11.11,
   |arm-none-linux-gnueabihf|arm-none-linux-gnueabihf,
   ||*-*-solaris2.*
 CC||ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth  ---
I'm seeing the same on Solaris, both sparc and x86, 32-bit only, at -O0 and
-O1.

E.g. on i386-pc-solaris2.12, the SEGV is

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfe2bd312 in memcpy () from /lib/libc.so.1
(gdb) where
#0  0xfe2bd312 in memcpy () from /lib/libc.so.1
#1  0x080542f6 in new_prt_spec2 ()
#2  0x08052efc in MAIN__ ()
#3  0x080544d1 in main ()

  Rainer

[Bug target/70162] [RX] const_int printing causes wrong code on 32 bit host

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
(In reply to Nick Clifton from comment #10)

Thanks for the clarification, Nick.

[Bug target/70321] [6 Regression] STV generates less optimized code

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Ilya Enkovich from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > For stage1, I wonder if it can't move earlier, say before the combiner.  If
> > it could, then we could split the TARGET_STV patterns that weren't changed
> > into vector insns, and let the combiner deal with that.  Is there a reason
> > why it is done after the combiner now?
> 
> Yes, STV searches for ANDN pattern and also for DI comparison with zero
> executed via OR.  Those are produced by combiner.  I believe some STV tests
> would fail if we move it before combine.

Why couldn't STV just "vectorize" AND and NOT patterns and let the combiner
combine that in the vectorized code?

[Bug target/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
About the shifting of negative value, wonder if it isn't actually UBSAN bug,
Marek, does C really say that -1 << 0 is invalid, or just -1 << 1?

But, it is trivial to change the testcase so that it is not questionable:
long long int b[64], c[64], g[64];
unsigned long long int a[64], d[64], e[64], f[64], h[64];

__attribute__ ((noinline, noclone)) void
foo (void)
{
  int i;
  for (i = 0; i < 64; i++)
{
  d[i] = h[i] << (unsigned long long int) b[i] * e[i])
<< (-a[i] - 3752448776177690134ULL))
   - 8214565720323784703ULL) - 1ULL);
  e[i] = (_Bool) (f[i] + (unsigned long long int) g[i]);
  g[i] = c[i];
}
}

int
main ()
{
  int i;
  for (i = 0; i < 64; ++i)
{
  a[i] = 14694295297531861425ULL;
  b[i] = -1725558902283030715LL;
  c[i] = 4402992416302558097LL;
  e[i] = 6297173129107286501ULL;
  f[i] = 13865724171235650855ULL;
  g[i] = 982871027473857427LL;
  h[i] = 8193845517487445944ULL;
}
  foo ();
  for (i = 0; i < 64; i++)
if (d[i] != 8193845517487445944ULL || e[i] != 1
|| g[i] != 4402992416302558097ULL)
  __builtin_abort ();
  return 0;
}

I don't see any UB there.
The first shift left is << 57, which gives 0x7200ULL and we
subtract the same number from it and get 0, so the second shift is << 0.
The bug is in the vectorizer (or pattern detection), where we had in scalar
code:
  _9 = a[i_29];
  _10 = (unsigned int) _9;
  _11 = 705976810 - _10;
  _12 = _8 << _11;
  _13 = (unsigned int) _12;
  _14 = _4 << _13;
in the vectorized code we have:
  vect__9.20_26 = MEM[(long long unsigned int *)vectp_a.18_28];
  vectp_a.18_2 = vectp_a.18_28 + 16;
  vect__9.21_1 = MEM[(long long unsigned int *)vectp_a.18_2];
  _9 = a[i_29];
  vect__10.22_56 = VEC_PACK_TRUNC_EXPR ;
  _10 = (unsigned int) _9;
  vect__11.23_58 = vect_cst__57 - vect__10.22_56;
  _11 = 705976810 - _10;
  vect_patt_53.24_59 = [vec_unpack_lo_expr] vect__11.23_58;
  vect_patt_53.24_60 = [vec_unpack_hi_expr] vect__11.23_58;
  vect_patt_52.25_61 = vect__8.17_32 << vect_patt_53.24_59;
  vect_patt_52.25_62 = vect__8.17_31 << vect_patt_53.24_60;
  _12 = _8 << _11;
  _13 = (unsigned int) _12;
  vect_patt_51.26_63 = vect__4.6_47 << vect_patt_52.25_61;
  vect_patt_51.26_64 = vect__4.7_45 << vect_patt_52.25_62;
  _14 = _4 << _13;
As you can see, the formed (unsigned int) cast is lost, we really need to shift
just by low 32 bits of the 64-bit result, not all bits thereof (the subtraction
got optimized away earlier, as the shift counts are 32-bit).  I'll have a look.

[Bug target/70321] [6 Regression] STV generates less optimized code

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #5 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #4)
> For stage1, I wonder if it can't move earlier, say before the combiner.  If
> it could, then we could split the TARGET_STV patterns that weren't changed
> into vector insns, and let the combiner deal with that.  Is there a reason
> why it is done after the combiner now?

Yes, STV searches for ANDN pattern and also for DI comparison with zero
executed via OR.  Those are produced by combiner.  I believe some STV tests
would fail if we move it before combine.

[Bug libstdc++/70358] Several 26_numerics/random/binomial_distribution/operators etc. tests FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug libstdc++/70358] New: Several 26_numerics/random/binomial_distribution/operators etc. tests FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 70358
   Summary: Several
26_numerics/random/binomial_distribution/operators
etc. tests FAIL
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.1[12]
Target: *-*-solaris2.1[12]
 Build: *-*-solaris2.1[12]

Several libstdc++-v3 tests currently FAIL on Solaris 11 and 12, both sparc and
x86, both 32 and 64-bit, but on the gcc-4.9 and gcc-5 branches only:

FAIL: 26_numerics/random/binomial_distribution/operators/values.cc (test for
excess errors)
WARNING: 26_numerics/random/binomial_distribution/operators/values.cc
compilation failed to produce executable
FAIL: 26_numerics/random/binomial_distribution/operators/values2.cc (test for
excess errors)
WARNING: 26_numerics/random/binomial_distribution/operators/values2.cc
compilation failed to produce executable
FAIL: 26_numerics/random/binomial_distribution/operators/values3.cc (test for
excess errors)
WARNING: 26_numerics/random/binomial_distribution/operators/values3.cc
compilation failed to produce executable
FAIL: 26_numerics/random/binomial_distribution/operators/values4.cc (test for
excess errors)
WARNING: 26_numerics/random/binomial_distribution/operators/values4.cc
compilation failed to produce executable
FAIL: 26_numerics/random/binomial_distribution/operators/values5.cc (test for
excess errors)
WARNING: 26_numerics/random/binomial_distribution/operators/values5.cc
compilation failed to produce executable
FAIL: 26_numerics/random/negative_binomial_distribution/operators/values.cc
(test for excess errors)
WARNING: 26_numerics/random/negative_binomial_distribution/operators/values.cc
compilation failed to produce executable
FAIL: 26_numerics/random/poisson_distribution/operators/values.cc (test for
excess errors)
WARNING: 26_numerics/random/poisson_distribution/operators/values.cc
compilation failed to produce executable
FAIL: ext/random/hypergeometric_distribution/operators/values.cc (test for
excess errors)
WARNING: ext/random/hypergeometric_distribution/operators/values.cc compilation
failed to produce executable

For example,

Excess errors:
/vol/gcc/src/hg/gcc-5-branch/local/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:36:67:
error: 'binomial_pdf' was not declared in this scope
/vol/gcc/src/hg/gcc-5-branch/local/libstdc++-v3/testsuite/util/testsuite_random.h:56:7:
error: void value not ignored as it ought to be

It turns out, the same tests are UNSUPPORTED on mainline.  When I check
libstdc++.log, I find

output is:
c99_math20881.cc:3:4: error: #error No C99 math

on mainline while the test passes on e.g. gcc-5 branch.

The test is

#include 
#ifndef _GLIBCXX_USE_C99_MATH_TR1
#  error No C99 math
#endif

Strangely, _GLIBCXX_USE_C99_MATH_TR1 is defined in both gcc-5 and trunk
config.h.

Looking at c99_math.ii, I find

#define _GLIBCXX_USE_C99_MATH _GLIBCXX11_USE_C99_MATH
#define _GLIBCXX11_USE_C99_MATH 1
#define _GLIBCXX98_USE_C99_MATH 1
#define _GLIBCXX_USE_C99_MATH_TR1 1
#undef _GLIBCXX_USE_C99_MATH
#undef _GLIBCXX_USE_C99_MATH_TR1

on mainline, but

#define _GLIBCXX_USE_C99_MATH 1
#define _GLIBCXX_USE_C99_MATH_TR1 1

on the gcc-5 branch.

  Rainer

[Bug target/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #7 from Ilya Enkovich  ---
Running with -fsanitize=undefined I get:

pr70354.c:25:30: runtime error: left shift of negative value
-1725558902283030715
pr70354.c:25:19: runtime error: shift exponent 1729382256910270464 is too large
for 64-bit type 'long int'
pr70354.c:27:25: runtime error: left shift of negative value
-1725558902283030715
pr70354.c:28:26: runtime error: left shift of negative value
-1725558902283030715

In scalar code we use the lowest byte as a shift operand producing some
non-zero value.  In vector code it behaves differently and produces 0.

Invalid then?

[Bug target/70333] [5/6 Regression] Test miscompiled with -O0.

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 22 13:23:00 2016
New Revision: 234401

URL: https://gcc.gnu.org/viewcvs?rev=234401=gcc=rev
Log:
2016-03-22  Richard Biener  

PR middle-end/70333
* fold-const.c (extract_muldiv_1): Properly perform multiplication
in the wide type.

* gcc.dg/torture/pr70333.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70333.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70333] [5 Regression] Test miscompiled with -O0.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] Test   |[5 Regression] Test
   |miscompiled with -O0.   |miscompiled with -O0.
  Known to fail||5.3.0

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

[Bug target/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Simplified testcase (-O2 -mavx2 works, -O3 -mavx2 fails, -O2 -ftree-vectorize
-mavx2 fails):

long long int b[64], c[64], g[64], h[64];
unsigned long long int a[64], d[64], e[64], f[64];

__attribute__ ((noinline, noclone)) void
foo (void)
{
  int i;
  for (i = 0; i < 64; i++)
{
  d[i] = h[i] << (unsigned long long int) b[i] * e[i])
<< (-a[i] - 3752448776177690134ULL))
   - 8214565720323784703ULL) - 1ULL);
  e[i] = (_Bool) (f[i] + (unsigned long long int) g[i]);
  g[i] = c[i];
}
}

int
main ()
{
  int i;
  for (i = 0; i < 64; ++i)
{
  a[i] = 14694295297531861425ULL;
  b[i] = -1725558902283030715LL;
  c[i] = 4402992416302558097LL;
  e[i] = 6297173129107286501ULL;
  f[i] = 13865724171235650855ULL;
  g[i] = 982871027473857427LL;
  h[i] = 8193845517487445944LL;
}
  foo ();
  for (i = 0; i < 64; i++)
if (d[i] != 8193845517487445944ULL || e[i] != 1
|| g[i] != 4402992416302558097ULL)
  __builtin_abort ();
  return 0;
}

[Bug tree-optimization/70357] New: [openacc][gomp4] ICE on reduction (+:sum) private (sum)

[vries at gcc dot gnu.org]

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

Bug ID: 70357
   Summary: [openacc][gomp4] ICE on reduction (+:sum) private
(sum)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

testcase:
...
int
main (void)
{
  unsigned int sum = 0;
  #pragma acc parallel reduction (+:sum) private(sum)
  ;
  return 0;
}
...

ICE when compiling for openacc with gomp-4_0-branch:
...
$ gcc -O2 -fopenacc private.c
private.c: In function ‘main’:
private.c:5:11: internal compiler error: Segmentation fault
   #pragma acc parallel reduction (+:sum) private(sum)
   ^~~
0xf65b5a crash_signal
src/gcc/toplev.c:335
0xd02bdb lookup_decl
src/gcc/omp-low.c:1080
0xd15cb6 lower_oacc_reductions
src/gcc/omp-low.c:5714
0xd4806b lower_omp_target
src/gcc/omp-low.c:16978
0xd49240 lower_omp_1
src/gcc/omp-low.c:17301
0xd4976f lower_omp
src/gcc/omp-low.c:17394
0xd48e49 lower_omp_1
src/gcc/omp-low.c:17242
0xd4976f lower_omp
src/gcc/omp-low.c:17394
0xd48e49 lower_omp_1
src/gcc/omp-low.c:17242
0xd4976f lower_omp
src/gcc/omp-low.c:17394
0xd4b743 execute_lower_omp
src/gcc/omp-low.c:18129
0xd4b7e8 execute
src/gcc/omp-low.c:18166
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

On trunk instead we get:
...
private.c: In function ‘main’:
private.c:5:34: error: ‘sum’ appears more than once in data clauses
   #pragma acc parallel reduction (+:sum) private(sum)
...

[Bug c++/70353] static_assert + assert + c++14 crashes GCC

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

--- Comment #2 from Marek Polacek  ---
Started with r217663:

commit 9c96033c877975303250d6f6156eacba52fc8b44
Author: jason 
Date:   Mon Nov 17 18:16:14 2014 +

C++14 constexpr support (minus loops and multiple returns)

[Bug target/70356] New: gcc.target/i386/avx-vextractf128-256-5.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 70356
   Summary: gcc.target/i386/avx-vextractf128-256-5.c FAILs
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: kyukhin at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.*
Target: i386-pc-solaris2.*
 Build: i386-pc-solaris2.*

The gcc.target/i386/avx-vextractf128-256-5.c test FAILs on Solaris/x86 with
/bin/as:

Running target unix/-m64
FAIL: gcc.target/i386/avx-vextractf128-256-5.c (test for excess errors)

Excess errors:
Assembler: avx-vextractf128-256-5.c
"/var/tmp//cca8rMJb.s", line 11 : Invalid instruction argument
Near line: "vmovapd %zmm16, %zmm0"

Unlike all other avx512f tests, this one is an assemble test for no reason I
can
see.  I believe it should just be changed into a compile test.

In addition,the testcase only exists on the gcc-5 branch, but is missing on
mainline.

Something fishy is going on here.

  Rainer

[Bug c++/70353] static_assert + assert + c++14 crashes GCC

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

void foo (const char *);
constexpr int
ce (int r)
{
  r == 3 ? static_cast (0) : foo (__PRETTY_FUNCTION__);
  return r;
}
static_assert (ce (3) == 3, "");

[Bug target/70321] [6 Regression] STV generates less optimized code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

I'm afraid for GCC 6.x we can't do much more than attached patch, which
improves the generated code, but there is no combiner post RA that would
improve it even more.  For GCC 6.x, I think it is out of question to move STV
pass somewhere else.

For stage1, I wonder if it can't move earlier, say before the combiner.  If it
could, then we could split the TARGET_STV patterns that weren't changed into
vector insns, and let the combiner deal with that.  Is there a reason why it is
done after the combiner now?

[Bug target/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Looks like a target issue to me - the vectorized IL looks good.  Note we
use the V[24]DImode multiplication AVX2 code here.  But maybe that just
confuses me enough to give up here ;)  The -mprefer-avx128 code is a lot
easier to look at (smaller in size).

[Bug target/70290] -mavx512vl breaks parsing of C++ vector condition

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Tue Mar 22 12:31:12 2016
New Revision: 234399

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

PR target/70290
* call.c (build_conditional_expr_1): Always use original
condition type for vector type checks and build.

gcc/testsuite/

PR target/70290
* g++.dg/ext/pr70290.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/pr70290.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70290] -mavx512vl breaks parsing of C++ vector condition

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #5 from Ilya Enkovich  ---
Fixed

[Bug target/70354] [6 Regression] Wrong code with -O3 -march=broadwell and -march=skylake-avx512.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Also fails with -mprefer-avx128 -mavx2 (needs avx2 for integer vector shift it
seems).

Not yet spotted the actual issue we run into...