[Bug target/70293] [ICE, AVX-512] Wrong reg constraints in vec_dup

[kyukhin at gcc dot gnu.org]

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

--- Comment #2 from Kirill Yukhin  ---
Created attachment 38020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38020=edit
Proposed patch

Attached patch solves the issue by blocking AVX2's broadcast pattern
alternative: $r->Yi, which is subject of split2

[Bug c++/70277] Improve code generation for large initializer lists

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I only see a single try {} finally {} generated by the FE.  It looks like
the remaining are generated by gimplification do be able to output CLOBBERs.

I think for large initializer lists it would be good to emit a sorry ()
and have a compile-time limit on their element count - is sth like this
allowed by the standard?  Because I can't see how generally emitting
more optimal code is possible at all...

[Bug other/70183] fdump-rtl-all-flags doesn't have impact on vzeroupper pass

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from vries at gcc dot gnu.org ---
Approved for stage1: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00902.html,
conditional on successful bootstrap & regtest.

[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Vladimir Makarov  ---
(In reply to Ramana Radhakrishnan from comment #2)
> Waiting.

Actually, I have a candidate patch to deal with scratches created during LRA. 
But I can not test it as I have no "local change to gcc", a test case and used
option set.

In any case, if this problem is solved by other means (e.g. using another
patterns), we should probably close the bug.

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 17 08:01:26 2016
New Revision: 234279

URL: https://gcc.gnu.org/viewcvs?rev=234279=gcc=rev
Log:
PR target/70261
* rtlanal.c (replace_rtx): Revert 2016-03-16 change.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c

[Bug middle-end/70280] -fcompare-debug failure (length) with --param=integer-share-limit=4016 -mavx512bw

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 17 23:00:04 2016
New Revision: 234312

URL: https://gcc.gnu.org/viewcvs?rev=234312=gcc=rev
Log:
PR c/70280
* c-typeck.c (composite_type): Don't count void_list_node
into len, if the list is terminated by void_list_node, start
with void_list_node instead of NULL for newargs.  Stop
at void_list_node.

Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c

[Bug c++/61198] Crash when selecting specializations through aliases.

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Fri Mar 18 15:57:58 2016
New Revision: 234337

URL: https://gcc.gnu.org/viewcvs?rev=234337=gcc=rev
Log:
Backport PR c++/61198 fix

gcc:
2014-12-19  Kai Tietz  

PR c++/61198
* pt.c (most_general_template): Don't break for template-alias.

gcc/testsuite:

2014-12-19  Kai Tietz  
Paolo Carlini  

PR c++/61198
* g++.dg/cpp0x/alias-decl-45.C: New file.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-45.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/pt.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/70264] [6 Regression] ICE at -O0 to -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (compatible_locations_p, at diagnostic-show-locus.c:490)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Thu Mar 17 18:27:47 2016
New Revision: 234303

URL: https://gcc.gnu.org/viewcvs?rev=234303=gcc=rev
Log:
PR c/70264: fix crash in compatible_locations_p with BUILTINS_LOCATION

In r234088 my fix for PR c++/70105 didn't allow for the possibility that
when comparing a pair of macro expansion histories that one of the
macros in the history might not be located within a line-map, and
PR c/70264 reports a crash due to encountering BUILTINS_LOCATION within
the traversal.

Fixed thusly.

Successfully bootstrapped on x86_64-pc-linux-gnu; adds 4 PASS results
to gcc.sum and 12 to g++.sum.

gcc/ChangeLog:
PR c/70264
* diagnostic-show-locus.c (compatible_locations_p): Handle the case
where one or both locations aren't within a line_map.

gcc/testsuite/ChangeLog:
PR c/70264
* c-c++-common/pr70264.c: New test case.

Added:
trunk/gcc/testsuite/c-c++-common/pr70264.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70295] [6 Regression] bogus -Wnonnull-compare for "dynamic_cast(this) != nullptr"

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Unfortunately that patch regresses the c-c++-common/nonnull-1.c testcase.
The problem is that finish_parenthesized_expr which sets TREE_NO_WARNING on all
expressions.  Will see if setting it solely on MODIFY_EXPRs isn't enough.

[Bug libgomp/65362] OpenACC compilation on Tegra K1 (ARM)

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
Hello Marcin,

In the past few months I've been working on OpenMP offloading to NVIDIA PTX,
and in the last couple of weeks together with Vladimir Zhukov we've tried
offloading on his Jetson TK1 board. Please let me know if you'd like to test
OpenMP offloading there -- I can put up a temporary branch for you with a
hack-patch that enables PTX offloading on ARM (while breaking it on x86_64).

(I realize the report is about OpenACC, but I expect OpenMP offloading is of
similar interest)

(offloading to PTX is quite young; I'll work on making it more efficient later)

(I'd like to submit PTX/ARM enablement patches eventually anyway)

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
But all the replace_rtx behavior seen here is IMHO bogus and might cause latent
issues.

An option besides asserting is to fail replacement (as we did before - the
assert was to catch other cases where not replacing might just hide a bug).

Of course as far as I understand the PPC regressions show cases where
replacing more (the REGNO == REGNO with equal mode case) actually _breaks_
things?

Rather than adding a new function I'd add a param to replace_rtx, like
'bool all_regs' guarding the new REG case.

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

[arnd at linaro dot org]

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

--- Comment #4 from Arnd Bergmann  ---
I've tried out a few more things as well, to see if the alignment of the struct
lpfc_name type or the builtin memcpy makes a different. Replacing the array of
eight bytes with a single uint64_t and scalar operations instead of string
functions makes very little difference, so it seems to be neither of them.

However, I think the wwn_to_uint64_t() function is what causes the problem.
This is supposed to be turned into a direct load or a byte reversing load
depending on endianess, but this apparently does not happen.

Adding -mbig-endian to the compiler flags brings the stack usage down, so
presumably the optimization step that identifies byteswap patters is what
causes the stack growth.

[Bug c++/70282] New: cc1plus hangs taking 100% CPU

[tulipawn at gmail dot com]

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

Bug ID: 70282
   Summary: cc1plus hangs taking 100% CPU
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Created attachment 38004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38004=edit
Preprocessed source

Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.9.3-8ubuntu2~14.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-libitm
--disable-libquadmath --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-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-multilib --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix


gcc version 4.9.3 (Ubuntu/Linaro 4.9.3-8ubuntu2~14.04)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-I'
'/rust-master/arm-unknown-linux-gnueabihf/llvm/include' '-I'
'/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR' '-I'
'/rust-master/src/llvm/include' '-I' '/rust-master/src/llvm/lib/IR' '-D'
'_DEBUG' '-D' '_GNU_SOURCE' '-D' '__STDC_CONSTANT_MACROS' '-D'
'__STDC_FORMAT_MACROS' '-D' '__STDC_LIMIT_MACROS' '-O3' '-fomit-frame-pointer'
'-std=c++11' '-fvisibility-inlines-hidden' '-fno-exceptions' '-fno-rtti'
'-fPIC' '-ffunction-sections' '-fdata-sections' '-Wcast-qual' '-marm' '-marm'
'-marm' '-Wpedantic' '-Wno-long-long' '-Wall' '-Wextra' '-Wno-unused-parameter'
'-Wwrite-strings' '-Wno-maybe-uninitialized' '-Wno-missing-field-initializers'
'-Wno-comment' '-c' '-MMD' '-MP' '-MF'
'/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.d.tmp'
'-MT'
'/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.o'
'-MT'
'/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.d'
'-o'
'/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.o'
'-shared-libgcc' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16'
'-mtls-dialect=gnu'
 /usr/lib/gcc/arm-linux-gnueabihf/4.9/cc1plus -E -quiet -v -I
/rust-master/arm-unknown-linux-gnueabihf/llvm/include -I
/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR -I
/rust-master/src/llvm/include -I /rust-master/src/llvm/lib/IR -imultiarch
arm-linux-gnueabihf -MMD
/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.d
-MF
/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.d.tmp
-MP -MT
/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.o
-MT
/rust-master/arm-unknown-linux-gnueabihf/llvm/lib/IR/Release+Asserts/Function.d
-D_GNU_SOURCE -D _DEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D
__STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS
/rust-master/src/llvm/lib/IR/Function.cpp -marm -marm -marm -march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16 -mtls-dialect=gnu -std=c++11 -Wcast-qual
-Wpedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
-Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-comment
-fomit-frame-pointer -fvisibility-inlines-hidden -fno-exceptions -fno-rtti
-fPIC -ffunction-sections -fdata-sections -O3 -fpch-preprocess
-fstack-protector -Wformat-security -o Function.ii


I managed to produce Function.ii by changing O3 to O0

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #5 from Viktor Ostashevskyi  ---
Bisected to:

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

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

gcc/
   * tree-inline.c (copy_fn): New.
   * tree-inline.h: Declare it.
gcc/cp/
   * constexpr.c (use_new_call): New macro.
   (build_data_member_initialization): Ignore non-mem-inits.
   (check_constexpr_bind_expr_vars): Remove C++14 checks.
   (constexpr_fn_retval): Likewise.
   (check_constexpr_ctor_body): Do nothing in C++14.
   (massage_constexpr_body): In C++14 only collect mem-inits.
   (get_function_named_in_call): Handle null CALL_EXPR_FN.
   (cxx_bind_parameters_in_call): Build bindings in same order as
   parameters.  Don't treat iniviref parms specially in new call mode.
   (cxx_eval_call_expression): If use_new_call, do constexpr expansion
   based on DECL_SAVED_TREE rather than the massaged constexpr body.
   Set up ctx->object from AGGR_INIT_EXPR_SLOT if we don't have one.
   (is_sub_constant_expr): Don't mess with ctx.ctor here.
   (cxx_eval_component_reference): A null element means we're mid-
   initialization.
   (cxx_eval_store_expression, cxx_eval_increment_expression): New.
   (cxx_eval_constant_expression): Handle RESULT_DECL, DECL_EXPR,
   MODIFY_EXPR, STATEMENT_LIST, BIND_EXPR, USING_STMT,
   PREINCREMENT_EXPR, POSTINCREMENT_EXPR, PREDECREMENT_EXPR,
   POSTDECREMENT_EXPR.  Don't look into DECL_INITIAL of variables in
   constexpr functions.  In new-call mode find parms in the values table.
   (potential_constant_expression_1): Handle null CALL_EXPR_FN.
   Handle STATEMENT_LIST, MODIFY_EXPR, MODOP_EXPR, IF_STMT,
   PREINCREMENT_EXPR, POSTINCREMENT_EXPR, PREDECREMENT_EXPR,
   POSTDECREMENT_EXPR, BIND_EXPR, WITH_CLEANUP_EXPR,
   CLEANUP_POINT_EXPR, MUST_NOT_THROW_EXPR, TRY_CATCH_EXPR,
   EH_SPEC_BLOCK, EXPR_STMT, DECL_EXPR, CASE_LABEL_EXPR, BREAK_STMT,
   CONTINUE_STMT, USING_STMT, IF_STMT, DO_STMT, FOR_STMT, WHILE_STMT,
   SWITCH_STMT, ASM_EXPR.
   (cxx_eval_vec_init_1): Call build_aggr_init_expr.
   (cxx_eval_indirect_ref): Don't return a CONSTRUCTOR when the
   caller wants an lvalue.
   (cxx_eval_outermost_constant_expr): Pull object out of AGGR_INIT_EXPR.
   (maybe_constant_init): Look through INIT_EXPR.
   (ensure_literal_type_for_constexpr_object): Set
   cp_function_chain->invalid_constexpr.
   * cp-tree.h (struct language_function): Add invalid_constexpr bitfield.
   * decl.c (start_decl): Set cp_function_chain->invalid_constexpr.
   (check_for_uninitialized_const_var): Likewise.
   (maybe_save_function_definition): Check it.
   * parser.c (cp_parser_jump_statement): Set
   cp_function_chain->invalid_constexpr.
   (cp_parser_asm_definition): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@217663
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug debug/70271] [6 Regression] internal compiler error: in dwarf2out_finish, at dwarf2out.c:27346

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 17 13:43:01 2016
New Revision: 234289

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

PR debug/70271
* dwarf2out.c (dwarf2out_early_finish): Process deferred_asm_name
last.

* g++.dg/debug/pr70271.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr70271.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70284] ICE: in replace_rtx at rtlanal.c for mips n32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
The change to replace_rtx has been reverted, retry with newer trunk.

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
--- constexpr.c.xx  2016-03-11 17:37:42.0 +0100
+++ constexpr.c 2016-03-18 18:35:11.302453270 +0100
@@ -1245,7 +1245,10 @@ cxx_eval_call_expression (const constexp
   if (call_expr_nargs (t) == 2)
{
  tree arg = convert_from_reference (get_nth_callarg (t, 1));
- return cxx_eval_constant_expression (ctx, arg,
+ tree dest = get_nth_callarg (t, 0);
+ dest = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (dest)), dest);
+ tree set = build2 (MODIFY_EXPR, void_type_node, dest, arg);
+ return cxx_eval_constant_expression (ctx, set,
   lval, non_constant_p,
   overflow_p);
}

doesn't work though, so I'll defer this to Jason.  As for the priority, P2 is
right, we've already shipped GCC 5.[123] with this bug, so it can't be a
release blocker, but is of course very much desirable to get fixed for GCC 6.

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

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 17 Mar 2016, ienkovich at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
> 
> --- Comment #6 from Ilya Enkovich  ---
> (In reply to rguent...@suse.de from comment #5)
> > I think that would be an odd transform.  But yes, The pattern is probably
> > dead now and can as well be removed...
> 
> This test proves pattern is not dead and still can be applied for all
> non-AVX-512 targets.  I don't think all targets make such optimizations so why
> not to keep it?

Looks like it was added for gcc.target/aarch64/vect-add-sub-cond.c so
we indeed should keep it.

[Bug libstdc++/69879] Create a pointer to the default operator new and delete

[gabriel.ibarra at tallertechnologies dot com]

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

Gabriel Ibarra  changed:

   What|Removed |Added

  Attachment #37887|0   |1
is obsolete||

--- Comment #7 from Gabriel Ibarra  ---
Created attachment 37998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37998=edit
[RFC] Added default functions for new and delete operators + unit test.

Hi, thanks for answering,
I know that you are focused in the gcc 6 release, but i have another question.
I noticed that after I added the new GLIBCXX_3.4.23 the abi_check breaks
because the new incompatible symbols, so the question is:
- Will this error be fixed automatically after the release (for example because
the update of the baseline_symbol.txt)? or is there something that i can do to
fix it?

Thanks

[Bug ipa/70269] [5/6 Regression] ICE with -fdump-ipa-pta-graph -fipa-pta

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

--- Comment #2 from Richard Biener  ---
Looks good.

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

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Ilya Enkovich from comment #2)
> Here is a responsible match.pd pattern:
> 
> /* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C), since vector comparisons
>return all-1 or all-0 results.  */

Since we don't simplify (x  A - (B vcmp C ? -1 : 0)

?

[Bug c++/70299] pow(long double, int) gives more imprecise result than pow(long double,long double) in c++03 mode

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Without libstdc++ dependencies:

inline long double pil(long double x, int n) { return __builtin_powil(x, n); }
inline long double pl(long double x, long double n) { return __builtin_powl(x,
n); }

int main()
{
  __builtin_printf("pow(long double, int) :%.21Le\n", pil(10.L,-4823));
  __builtin_printf("pow(long double, long double): %.21Le\n",
pl(10.L,-4823.L));
}

[Bug c++/70106] [4.9/5 Regression][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
Summary|[4.9/5/6 Regression][C++11  |[4.9/5 Regression][C++11 or
   |or above] adding|above] adding parenthesis
   |parenthesis [cerr << (var)] |[cerr << (var)] cause
   |cause error: invalid|error: invalid static_cast
   |static_cast from type   |from type 'const size_t
   |'const size_t {aka const|{aka const long unsigned
   |long unsigned int}' to type |int}' to type 'size_t& {aka
   |'size_t& {aka long unsigned |long unsigned int&}'
   |int&}'  |

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

[Bug c/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #5 from H.J. Lu  ---
*** Bug 66400 has been marked as a duplicate of this bug. ***

[Bug c/70255] New: change of the order of summation of floating point numbers despite no-associative-math

[shatz at dsit dot co.il]

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

Bug ID: 70255
   Summary: change of the order of summation of floating point
numbers despite no-associative-math
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shatz at dsit dot co.il
  Target Milestone: ---

Created attachment 37989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37989=edit
minimal test case of change of the order of summation

Under certain very specific combination of factor gcc optimizer disregards
order of summation specified in the source code despite "no-associative-math"
option specified by means of function attribute.
The bug does not happen when -fno-associative-math option specified on the
command line.

In the file, attached below there are 3 very similar versions of the function
foo(). Only variant foo1() shows the bug.

Here is a asm code generated for foo1():

foo1:
.seh_endprologue
vmovsd  .LC0(%rip), %xmm2
vaddsd  %xmm2, %xmm0, %xmm3
vsubsd  %xmm3, %xmm0, %xmm0
vaddsd  %xmm1, %xmm0, %xmm1 ; order of summation changed
vaddsd  %xmm2, %xmm1, %xmm0
ret
.seh_endproc


Here is an output of gcc -v:

Using built-in specs.
COLLECT_GCC=D:\bin\msys64\mingw64\bin\gcc.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-5.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --with-gxx-include-dir=/mingw64/include/c++/5.2.0
--enable-bootstrap --with-arch=x86-64 --with-tune=generic
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-libatomic --enable-threads=posix --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-version-specific-runtime-libs --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64
--with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev4, Built by MSYS2
project' --with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 5.2.0 (Rev4, Built by MSYS2 project) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Ofast' '-Wall' '-mavx'
'-mtune=generic' '-march=x86-64'
 D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/cc1.exe -E
-quiet -v -iprefix
D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/ -D_REENTRANT
foo.c -mavx -mtune=generic -march=x86-64 -Wall -Ofast -fpch-preprocess -o foo.i
ignoring duplicate directory
"D:/bin/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.2.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory
"D:/bin/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.2.0/include-fixed"
ignoring duplicate directory
"D:/bin/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory
"C:/building/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/include

D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../include
 D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/include-fixed

D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Ofast' '-Wall' '-mavx'
'-mtune=generic' '-march=x86-64'
 D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/cc1.exe
-fpreprocessed foo.i -quiet -dumpbase foo.c -mavx -mtune=generic -march=x86-64
-auxbase foo -Ofast -Wall -version -o foo.s
GNU C11 (Rev4, Built by MSYS2 project) version 5.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Rev4, Built by MSYS2 project) version 5.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6d1a96b0d4d4a024cf53bcf4b7004358
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Ofast' '-Wall' '-mavx'
'-mtune=generic' '-march=x86-64'

D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/bin/as.exe
-v 

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> Or better yet decide whether to walk the initializers or not based on
> !gimple_body (fndecl) && !fun->cfg ?

or make the flag a tri-state and if we compute it before (during the 
tree-inline.c walk) then set it from there to avoid redundant work.

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> This patch leads to serious regressions.  Do not
> yet understand why.  Withdrawing...

Confirmed. Many failures are of the kind

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/array_constructor_type_16.f03:21:59:

   carr = [ CHARACTER(len=6) :: "foo", [ CHARACTER(len=4) :: "foobar", "xyz" ]
]
   1
Error: Different CHARACTER lengths (4/6) in array constructor at (1)

Another one is

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/unlimited_polymorphic_1.f03:158:16:

   call foo([sun, " & rain"], res)
1
Error: Different CHARACTER lengths (8/7) in array constructor at (1)

[Bug target/70188] [4.9/5/6 Regression] gcc 4.9+ miscompiles code on hppa

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
Author: danglin
Date: Thu Mar 17 22:55:38 2016
New Revision: 234310

URL: https://gcc.gnu.org/viewcvs?rev=234310=gcc=rev
Log:
PR target/70188
* config/pa/constraints.md: Revert 2015-02-13 change.  Use
define_constraint for "Q" and "T" constraints.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/pa/constraints.md

[Bug tree-optimization/70288] ICE with -O1 -fno-tree-dominator-opts

[tarasevich at cs dot uni-saarland.de]

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

--- Comment #1 from Andrey Tarasevich  ---
Created attachment 38014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38014=edit
test case with compile-time-hog

Same test case, but with line 28 removed (attached as test_case_2.i) takes 42
mins to compile with GCC 5.3.0, but crashes with GCC 4.8.2. Should I file a
separate bug report?

../build/gcc_530_clean_bin/bin/gcc -fno-tree-dominator-opts -O1 -save-temps
-ftime-report test_case_2.c

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  1093 kB ( 0%) ggc
 phase opt and generate  :2529.12 (100%) usr   1.99 (100%) sys2535.52 (100%)
wall 1802260 kB (100%) ggc
 garbage collection  :   1.17 ( 0%) usr   0.00 ( 0%) sys   1.16 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa pure const  :   0.48 ( 0%) usr   0.00 ( 0%) sys   0.49 ( 0%) wall 
 3 kB ( 0%) ggc
 cfg construction:   0.29 ( 0%) usr   0.00 ( 0%) sys   0.28 ( 0%) wall 
 0 kB ( 0%) ggc
 cfg cleanup :1031.96 (41%) usr   0.07 ( 4%) sys1033.73 (41%) wall 
 0 kB ( 0%) ggc
 trivially dead code :   1.52 ( 0%) usr   0.00 ( 0%) sys   1.54 ( 0%) wall 
 0 kB ( 0%) ggc
 df scan insns   :   1.13 ( 0%) usr   0.14 ( 7%) sys   1.27 ( 0%) wall 
 0 kB ( 0%) ggc
 df multiple defs:   0.67 ( 0%) usr   0.04 ( 2%) sys   0.70 ( 0%) wall 
 0 kB ( 0%) ggc
 df reaching defs:   0.02 ( 0%) usr   0.02 ( 1%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 df live regs:   2.94 ( 0%) usr   0.02 ( 1%) sys   2.95 ( 0%) wall 
 0 kB ( 0%) ggc
 df live regs:   1.41 ( 0%) usr   0.09 ( 5%) sys   1.51 ( 0%) wall 
 0 kB ( 0%) ggc
 df reg dead/unused notes:   3.09 ( 0%) usr   0.00 ( 0%) sys   3.10 ( 0%) wall 
 61256 kB ( 3%) ggc
 register information:   0.35 ( 0%) usr   0.00 ( 0%) sys   0.35 ( 0%) wall 
 0 kB ( 0%) ggc
 alias analysis  :   1.83 ( 0%) usr   0.00 ( 0%) sys   1.83 ( 0%) wall 
 49152 kB ( 3%) ggc
 register scan   :   0.15 ( 0%) usr   0.00 ( 0%) sys   0.16 ( 0%) wall 
 0 kB ( 0%) ggc
 rebuild jump labels :   0.49 ( 0%) usr   0.00 ( 0%) sys   0.50 ( 0%) wall 
 0 kB ( 0%) ggc
 tree CFG cleanup:   2.57 ( 0%) usr   0.00 ( 0%) sys   2.57 ( 0%) wall 
 2 kB ( 0%) ggc
 tree SSA rewrite:   3.23 ( 0%) usr   0.01 ( 1%) sys   3.23 ( 0%) wall 
 1 kB ( 0%) ggc
 tree SSA incremental:   4.11 ( 0%) usr   0.21 (11%) sys   4.21 ( 0%) wall 
 38823 kB ( 2%) ggc
 tree operand scan   :   0.06 ( 0%) usr   0.05 ( 3%) sys   0.19 ( 0%) wall 
 5 kB ( 0%) ggc
 tree split crit edges   :   0.67 ( 0%) usr   0.04 ( 2%) sys   0.71 ( 0%) wall 
110287 kB ( 6%) ggc
 tree reassociation  :   0.23 ( 0%) usr   0.00 ( 0%) sys   0.24 ( 0%) wall 
 0 kB ( 0%) ggc
 tree linearize phis :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall 
 1 kB ( 0%) ggc
 tree forward propagate  :   0.44 ( 0%) usr   0.00 ( 0%) sys   0.45 ( 0%) wall 
 0 kB ( 0%) ggc
 tree aggressive DCE :1416.89 (56%) usr   0.07 ( 4%) sys1419.48 (56%) wall 
 16382 kB ( 1%) ggc
 tree DSE:   0.08 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall 
 0 kB ( 0%) ggc
 tree loop invariant motion:   0.34 ( 0%) usr   0.00 ( 0%) sys   0.34 ( 0%)
wall   0 kB ( 0%) ggc
 complete unrolling  :   1.31 ( 0%) usr   0.27 (14%) sys   1.63 ( 0%) wall 
382276 kB (21%) ggc
 tree rename SSA copies  :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 dominance frontiers :   0.14 ( 0%) usr   0.01 ( 1%) sys   0.17 ( 0%) wall 
 0 kB ( 0%) ggc
 dominance computation   :   2.32 ( 0%) usr   0.05 ( 3%) sys   2.34 ( 0%) wall 
 0 kB ( 0%) ggc
 out of ssa  :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall 
 0 kB ( 0%) ggc
 expand vars :   0.31 ( 0%) usr   0.00 ( 0%) sys   0.30 ( 0%) wall 
 0 kB ( 0%) ggc
 expand  :   1.45 ( 0%) usr   0.18 ( 9%) sys   1.64 ( 0%) wall 
471768 kB (26%) ggc
 post expand cleanups:   0.69 ( 0%) usr   0.00 ( 0%) sys   0.70 ( 0%) wall 
 0 kB ( 0%) ggc
 lower subreg:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 forward prop:   3.06 ( 0%) usr   0.03 ( 2%) sys   3.10 ( 0%) wall 
 40837 kB ( 2%) ggc
 CSE :   3.61 ( 0%) usr   0.00 ( 0%) sys   3.62 ( 0%) wall 
 0 kB ( 0%) ggc
 dead code elimination   :   0.42 ( 0%) usr   0.00 ( 0%) sys   0.42 ( 0%) wall 
 0 kB ( 0%) ggc
 dead store elim1:   1.65 ( 0%) usr   0.14 ( 7%) sys   1.80 ( 0%) wall 
 30628 kB ( 2%) ggc
 dead store elim2:   1.53 ( 0%) usr   0.01 ( 1%) sys   1.54 ( 0%) wall 
 10209 kB ( 1%) ggc
 loop analysis   :   0.03 ( 0%) usr   0.01 ( 1%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 loop init   :   1.21 ( 0%) usr   0.00 ( 0%) sys   1.20 ( 0%) wall 
  2600 kB ( 0%) ggc
 loop fini   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
 

[Bug debug/70297] GCC Segfaults when using -g3

[piotr.zierhoffer at gmail dot com]

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

--- Comment #1 from Piotr Zierhoffer  ---
Created attachment 38023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38023=edit
gcc -v output

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[andrewm.roberts at sky dot com]

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

Andrew Roberts  changed:

   What|Removed |Added

 CC||andrewm.roberts at sky dot com

--- Comment #4 from Andrew Roberts  ---
I've built latest snapshot on Arch Linux Arm aarch64 Odroid-C2 system and see
the same thing:

/usr/local/gcc-6.0.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-6.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-6.0.0/libexec/gcc/aarch64-unknown-linux-gnu/6
.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-6.0.0/configure --prefix=/usr/local/gcc-6.0.0
--program-
suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checkin
g=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exception
s --enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=g
nu --enable-plugin --enable-initfini-array --enable-gnu-indirect-function
--enab
le-lto --with-isl --enable-languages=c,c++,fortran --disable-libgcj
--enable-clo
cale=gnu --disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
-
-enable-shared --enable-clocale=gnu --with-arch-directory=aarch64
--enable-multi
arch --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu
--target
=aarch64-unknown-linux-gnu --with-arch=armv8-a --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160313 (experimental) (GCC) 

echo "int main(void) { return 0; }" | /usr/local/gcc-6.0.0/bin/gcc
-march=native
 -c -x c -
Assembler messages:
Error: must specify extensions to add before specifying those to remove
Error: unrecognized option -march=armv8-a+fp+simd+nocrypto+crc+nolse

Where as:
echo "int main(void) { return 0; }" | /usr/local/gcc-6.0.0/bin/gcc
-march=armv8-
a+simd+crc+nolse -c -x c -

works

This is with binutils:
ld -v
GNU ld (GNU Binutils) 2.26.0.20160302

cat /proc/cpuinfo
Processor   : AArch64 Processor rev 4 (aarch64)
processor   : 0
processor   : 1
processor   : 2
processor   : 3
Features: fp asimd crc32
CPU implementer : 0x41
CPU architecture: AArch64
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

Hardware: ODROID-C2
Revision: 020b

uname -a
Linux alarm 3.14.29-10-ARCH #1 SMP PREEMPT Wed Mar 16 20:13:56 MDT 2016 aarch64 
GNU/Linux

I also saw the same thing with the Linero compiler on Ubuntu, and Arch Linux's
gcc 5.3.0. I did try to build gcc 6 snapshot on Ubuntu to report it but it was
too flakey, Arch Works better.

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jason at gcc dot gnu.org]

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

--- Comment #30 from Jason Merrill  ---
Author: jason
Date: Fri Mar 18 15:31:35 2016
New Revision: 234335

URL: https://gcc.gnu.org/viewcvs?rev=234335=gcc=rev
Log:
PR c++/70147 - handle primary virtual bases

* class.c (vptr_via_virtual_p): New.
(most_primary_binfo): Factor out of build_rtti_vtbl_entries.
* cp-ubsan.c (cp_ubsan_dfs_initialize_vtbl_ptrs): Don't clear
a vptr from any virtual base in a not-in-charge 'structor.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/vptr-11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cp-ubsan.c

[Bug c++/70285] [6 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/70290] New: -mavx512vl breaks parsing of C++ vector comparison

[glisse at gcc dot gnu.org]

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

Bug ID: 70290
   Summary: -mavx512vl breaks parsing of C++ vector comparison
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

typedef int vec __attribute__((vector_size(32)));
vec f(vec x,vec y){return (x

[Bug c++/70295] New: [6 Regression] bogus -Wnonnull-compare for "dynamic_cast(this) != nullptr"

[trippels at gcc dot gnu.org]

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

Bug ID: 70295
   Summary: [6 Regression] bogus -Wnonnull-compare for
"dynamic_cast(this) != nullptr"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

trippels@CFARM-IUT-TLSE3 ~ % cat fudraw.ii
enum SdrHitKind {};
class FuSelection {
  void m_fn1(void *);
};
void FuSelection::m_fn1(void *) {
  SdrHitKind eHit;
  if (eHit && dynamic_cast(this) != nullptr)
;
}
trippels@CFARM-IUT-TLSE3 ~ % g++ -c -O2 -Wnonnull-compare fudraw.ii 
fudraw.ii: In member function ‘void FuSelection::m_fn1(void*)’:
fudraw.ii:7:55: warning: nonnull argument ‘this’ compared to NULL
[-Wnonnull-compare]
   if (eHit && dynamic_cast(this) != nullptr)
   ^~

[Bug c++/70267] ICE on valid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I think the compiler rightly assumes that _Jv_AllocObject will return some
pointer, not a struct.  So, IMHO we should just reject this as invalid.

[Bug c++/70267] ICE on valid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Perhaps
--- gcc/cp/init.c.jj2016-03-05 07:46:50.0 +0100
+++ gcc/cp/init.c   2016-03-17 17:18:21.326917746 +0100
@@ -2872,6 +2872,14 @@ build_new_1 (vec **placemen
  return error_mark_node;
}
   alloc_fn = OVL_CURRENT (alloc_fn);
+  if (TREE_CODE (alloc_fn) != FUNCTION_DECL
+ || TREE_CODE (TREE_TYPE (alloc_fn)) != FUNCTION_TYPE
+ || !POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (alloc_fn
+   {
+ if (complain & tf_error)
+   error ("%qD is not a function returning a pointer", alloc_fn);
+ return error_mark_node;
+   }
   class_addr = build1 (ADDR_EXPR, jclass_node, class_decl);
   alloc_call = cp_build_function_call_nary (alloc_fn, complain,
class_addr, NULL_TREE);
?
Though, there are many other calls to get_global_value_if_present in the C++
FE, which probably also need some sanity checking, whether declaring those
functions with weirdo return or argument types can't cause ICEs.

[Bug target/59407] gcc.target/i386/pr58218.c FAILs with Sun as

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]
 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-03/msg01056.ht
   ||ml
   Last reconfirmed||2016-03-18
   Host|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
 Ever confirmed|0   |1
  Build|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]

--- Comment #4 from Rainer Orth  ---
Mine, patch posted.

[Bug c++/70254] Compiler crash

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
The following code:

//---
template
class NamedResourceFactory
{
using ResourceType = decltype(Creator())::type::pointer;
};

int main(){}
//---

compiled against gcc 4.9.0, 5.1.0, 5.2.0 results in the following output:


prog.cc:4:26: internal compiler error: Segmentation fault
 using ResourceType = decltype(Creator())::type::pointer;
  ^
0x94d21f crash_signal
../../gcc-4.9.0/gcc/toplev.c:337
0x56c94a resolve_typename_type(tree_node*, bool)
../../gcc-4.9.0/gcc/cp/pt.c:21385
0x5b1c01 cp_parser_nested_name_specifier_opt
../../gcc-4.9.0/gcc/cp/parser.c:5188
0x5bcc13 cp_parser_id_expression
../../gcc-4.9.0/gcc/cp/parser.c:4713
0x5bd5ff cp_parser_parse_and_diagnose_invalid_type_name
../../gcc-4.9.0/gcc/cp/parser.c:3024
0x5aa3e7 cp_parser_type_specifier_seq
../../gcc-4.9.0/gcc/cp/parser.c:18139
0x5ba452 cp_parser_type_id_1
../../gcc-4.9.0/gcc/cp/parser.c:18000
0x5bf069 cp_parser_type_id
../../gcc-4.9.0/gcc/cp/parser.c:18040
0x5bf069 cp_parser_alias_declaration
../../gcc-4.9.0/gcc/cp/parser.c:16135
0x5a43a5 cp_parser_member_declaration
../../gcc-4.9.0/gcc/cp/parser.c:20186
0x5a7f50 cp_parser_member_specification_opt
../../gcc-4.9.0/gcc/cp/parser.c:20093
0x5a7f50 cp_parser_class_specifier_1
../../gcc-4.9.0/gcc/cp/parser.c:19321
0x5a7f50 cp_parser_class_specifier
../../gcc-4.9.0/gcc/cp/parser.c:19548
0x5a7f50 cp_parser_type_specifier
../../gcc-4.9.0/gcc/cp/parser.c:14337
0x5be620 cp_parser_decl_specifier_seq
../../gcc-4.9.0/gcc/cp/parser.c:11573
0x5c2d63 cp_parser_single_declaration
../../gcc-4.9.0/gcc/cp/parser.c:23159
0x5c3224 cp_parser_template_declaration_after_export
../../gcc-4.9.0/gcc/cp/parser.c:23035
0x5cb639 cp_parser_declaration
../../gcc-4.9.0/gcc/cp/parser.c:10973
0x5ca1a8 cp_parser_declaration_seq_opt
../../gcc-4.9.0/gcc/cp/parser.c:10895
0x5cb9aa cp_parser_translation_unit
../../gcc-4.9.0/gcc/cp/parser.c:4030
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

1

Finish


The problem seems to be fixed in the current head (Tested: gcc HEAD 6.0.0
20160311 (experimental)), where the normal compiler diagnostics is produced:


prog.cc:4:26: error: need 'typename' before 'typename decltype
(Creator())::type::pointer' because 'typename decltype (Creator())::type' is a
dependent scope
 using ResourceType = decltype(Creator())::type::pointer;

[Bug rtl-optimization/69557] [ARM] revsh instruction not being conditionalised for Thumb2

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/70188] [4.9/5/6 Regression] gcc 4.9+ miscompiles code on hppa

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #12 from John David Anglin  ---
64-bit Debian 4.4.4-2+b1 kernel booted successfully on c3750.

[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #14 from Marek Polacek  ---
Fixed on the trunk.  Not planning to backport this one.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

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

--- Comment #34 from Jonathan Wakely  ---
Author: redi
Date: Fri Mar 18 15:58:03 2016
New Revision: 234338

URL: https://gcc.gnu.org/viewcvs?rev=234338=gcc=rev
Log:
allocator_traits partial specialization

PR libstdc++/60976
* include/bits/alloc_traits.h (allocator_traits>):
Define partial specialization.
* testsuite/20_util/shared_ptr/cons/58659.cc: Add construct and
destroy members to std::allocator explicit specialization.

Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/alloc_traits.h
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/shared_ptr/cons/58659.cc

[Bug tree-optimization/70256] Add debug_varinfo and debug_varmap

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-16
 Ever confirmed|0   |1

--- Comment #2 from vries at gcc dot gnu.org ---
Confirmed: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00602.html

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
(In reply to Viktor Ostashevskyi from comment #5)
> Bisected to:
> 
> commit 9c96033c877975303250d6f6156eacba52fc8b44
> Author: jason 
> Date:   Mon Nov 17 18:16:14 2014 +
> 
> C++14 constexpr support (minus loops and multiple returns)

Ccing Jason.

[Bug c++/59950] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Last reconfirmed|2015-03-19 00:00:00 |2016-3-18
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
The current top of 6.0 trunk still issues the bogus diagnostic.  Confirming
also with prior versions.

$ cat t.c && /build/gcc-trunk-bootstrap/gcc/xgcc -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -xc++ v.c
struct S { int a [1]; };

struct S f (void);

void g (void)
{
int* p = f ().a;
int *q =  ().a [0];

(void)p;
(void)q;
}

v.c:3:27: error: taking address of temporary [-fpermissive]
  int n = f(&(Foo() = Foo()));
   ^

[Bug c++/70285] New: ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[su at cs dot ucdavis.edu]

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

Bug ID: 70285
   Summary: ICE on valid code on x86_64-linux-gnu: verify_gimple
failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

This is a regression from 5.3.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160317 (experimental) [trunk revision 234279] (GCC) 
$ 
$ g++-5.3 small.cpp -c
$ 
$ g++-trunk small.cpp -c
small.cpp: In function ‘int fn1()’:
small.cpp:9:1: error: non-trivial conversion at assignment
 fn1 ()
 ^~~
int
signed char
D.2294 = b.i;
small.cpp:9:1: internal compiler error: verify_gimple failed
0xd8b5fd verify_gimple_in_seq(gimple*)
../../gcc-source-trunk/gcc/tree-cfg.c:4792
0xae1a0b gimplify_body(tree_node*, bool)
../../gcc-source-trunk/gcc/gimplify.c:11404
0xae1dc6 gimplify_function_tree(tree_node*)
../../gcc-source-trunk/gcc/gimplify.c:11492
0x960027 cgraph_node::analyze()
../../gcc-source-trunk/gcc/cgraphunit.c:625
0x962b90 analyze_functions
../../gcc-source-trunk/gcc/cgraphunit.c:1086
0x963df8 symbol_table::finalize_compilation_unit()
../../gcc-source-trunk/gcc/cgraphunit.c:2542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





int a; 

struct S 
{
  int i:8;
} b;

int
fn1 ()
{
  return  ? b.i : a;
}

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

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

Summary|-mavx512vl breaks parsing   |-mavx512vl breaks parsing
   |of C++ vector comparison|of C++ vector condition

--- Comment #1 from Marc Glisse  ---
typedef int vec __attribute__((vector_size(32)));
vec f(vec x,vec y){
  vec zero={};
  vec one=zero+1;
  return (x

[Bug c++/70205] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
I suspect this started with r190969.

[Bug libstdc++/70294] operator< and operator== for std::thread::id only findable by ADL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/70287] New: Slow compilation time

[tarasevich at cs dot uni-saarland.de]

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

Bug ID: 70287
   Summary: Slow compilation time
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tarasevich at cs dot uni-saarland.de
  Target Milestone: ---

Created attachment 38011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38011=edit
test case

Combination of "-O3 -fgcse-sm -fno-tree-fre -fno-tree-copy-prop -fno-tree-ccp
-fno-tree-dce -ffloat-store" flags degrades compilation time significantly.
Removing any of those reduces compilation time to seconds. GCC 5.3.0 built from
source with Clang 3.7.1 on Ubuntu 14.04 64bit. Same behaviour observed with GCC
4.8.2

../build/gcc_530_clean_bin/bin/gcc test_case_587.c -O3 -fgcse-sm -fno-tree-fre
-fno-tree-copy-prop -fno-tree-ccp -fno-tree-dce -ffloat-store -ftime-report -v
-save-temps
Using built-in specs.
COLLECT_GCC=../build/gcc_530_clean_bin/bin/gcc
COLLECT_LTO_WRAPPER=/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../source/gcc_530/configure
--prefix=/home/tarasevich/build/gcc_530_clean_bin/ --enable-languages=c
--disable-multilib --disable-bootstrap
CC=/home/tarasevich/build/llvm_371_bin/bin/clang
CXX=/home/tarasevich/build/llvm_371_bin/bin/clang++
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-fgcse-sm' '-fno-tree-fre' '-fno-tree-copy-prop'
'-fno-tree-ccp' '-fno-tree-dce' '-ffloat-store' '-ftime-report' '-v'
'-save-temps' '-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-E -quiet -v -imultiarch x86_64-linux-gnu test_case_587.c -mtune=generic
-march=x86-64 -fgcse-sm -fno-tree-fre -fno-tree-copy-prop -fno-tree-ccp
-fno-tree-dce -ffloat-store -ftime-report -O3 -fpch-preprocess -o
test_case_587.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
 /usr/local/include
 /home/tarasevich/build/gcc_530_clean_bin/include

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (100%) wall
129 kB (89%) ggc
 TOTAL :   0.00 0.00 0.01  
 146 kB
COLLECT_GCC_OPTIONS='-O3' '-fgcse-sm' '-fno-tree-fre' '-fno-tree-copy-prop'
'-fno-tree-ccp' '-fno-tree-dce' '-ffloat-store' '-ftime-report' '-v'
'-save-temps' '-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-fpreprocessed test_case_587.i -quiet -dumpbase test_case_587.c -mtune=generic
-march=x86-64 -auxbase test_case_587 -O3 -version -fgcse-sm -fno-tree-fre
-fno-tree-copy-prop -fno-tree-ccp -fno-tree-dce -ffloat-store -ftime-report -o
test_case_587.s
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c53bb545b4c066cdbf5e42f0b9d9ad8b

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
  1093 kB ( 1%) ggc
 phase opt and generate  :1032.26 (100%) usr   0.23 (100%) sys1034.31 (100%)
wall   87758 kB (99%) ggc
 ipa pure const  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 4 kB ( 0%) ggc
 trivially dead code :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall 
 0 kB ( 0%) ggc
 df scan insns   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 df multiple defs:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 0 kB ( 0%) ggc
 df reaching defs:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 df live regs:   0.11 ( 0%) usr   0.00 ( 0%) sys   0.14 ( 0%) wall 
 0 kB ( 0%) ggc
 df live regs:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:   0.01 ( 

[Bug c++/70267] ICE on invalid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|ICE on valid code at -O1|ICE on invalid code at -O1
   |and above on|and above on
   |x86_64-linux-gnu in |x86_64-linux-gnu in
   |propagate_necessity, at |propagate_necessity, at
   |tree-ssa-dce.c:924  |tree-ssa-dce.c:924

--- Comment #7 from Jakub Jelinek  ---
As this is invalid, fixing just on trunk.

[Bug c++/70259] [6 Regression] -flifetime-dse=2 bug with empty bases

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug go/70304] 5.3.0 solaris: objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
This looks like a disagreement between the Solaris assembler and the GNU
objcopy program.  I don't know if there is anything that gccgo can do to fix
it.  You should probably report this as a GNU binutils bug.

[Bug c++/70301] New: missing diagnostic on taking the address of a temporary

[msebor at gcc dot gnu.org]

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

Bug ID: 70301
   Summary: missing diagnostic on taking the address of a
temporary
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following attempts to store the address of the temporary member array
returned from function f() in a couple of pointer variables.  Since the
lifetime of the temporary returned from the function ends at the end of the
complete expression the saved pointer is invalid and the code should be
diagnosed.

$ cat t.c && /build/gcc-trunk-bootstrap/gcc/xgcc -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -xc++ t.c
struct S { int a [1]; };

struct S f (void);

void g (void)
{
int* p = f ().a;
int *q =  ().a [0];

(void)p;
(void)q;
}

Clang diagnoses one of the two expressions above:

warning: pointer is initialized by a
  temporary array, which will be destroyed at the end of the
full-expression
  [-Waddress-of-array-temporary]
int* p = f ().a;
 ^~
1 warning generated.

[Bug c++/70295] [6 Regression] bogus -Wnonnull-compare for "dynamic_cast(this) != nullptr"

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
The warning goes away without the "eHit &&" in the if condition.

And please note that the testcase was reduced from a big Libreoffice C++ file
with a larger class hierarchy.

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #16 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #15)

> That option is not the default, and is only really useful for experimenting
> to understand how C++ works (as documented at
> https://gcc.gnu.org/wiki/FAQ#copyelision) so there are very few good reasons
> to use that option in real code (except broken code).

It is very useful for building code coverage reports.

Any workarounds possible?

[Bug rtl-optimization/29854] reload_combine looses track of uses

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #9 from Oleg Endo  ---
(In reply to Jorn Wolfgang Rennecke from comment #8)

Thanks for the clarification, Jörn.

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #14 from Viktor Ostashevskyi  ---
(In reply to Jakub Jelinek from comment #13)

> As for the priority, P2
> is right, we've already shipped GCC 5.[123] with this bug, so it can't be a
> release blocker, but is of course very much desirable to get fixed for GCC 6.

What about at least documenting that -fno-ellide-constructor is broken in GCC
5.[123] and GCC6 if it isn't get fixed till release?

[Bug rtl-optimization/70263] [4.9/5/6 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (segmentation fault)

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 18 19:30:20 2016
New Revision: 234344

URL: https://gcc.gnu.org/viewcvs?rev=234344=gcc=rev
Log:
PR rtl-optimization/70263
* ira.c (memref_used_between_p): Assert we found END in the insn chain.
(update_equiv_regs): When trying to move a store to after the insn
that sets the source of the store, make sure the store occurs after
the insn that sets the source of the store.  When successful note
the REG_EQUIV note created in the dump file.

PR rtl-optimization/70263
* gcc.c-torture/compile/pr70263-1.c: New test.
* gcc.target/i386/pr70263-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr70263-1.c
trunk/gcc/testsuite/gcc.target/i386/pr70263-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
The native handles are not required by the standard, whether they exist or not
is implementation-defined. If they're not supportable we'll remove them, that's
not a problem.

[Bug target/70113] [AArch64] -mpc-relative-literal-loads conflicts with fix-cortex-a53-843419

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
Author: clyon
Date: Fri Mar 18 13:58:32 2016
New Revision: 234330

URL: https://gcc.gnu.org/viewcvs?rev=234330=gcc=rev
Log:
2016-03-18  Christophe Lyon  

PR target/70113
* gcc.target/aarch64/pr63304_1.c: Add -mno-fix-cortex-a53-843419.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/pr63304_1.c

[Bug go/70304] New: 5.3.0 solaris: objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString

[andrew at ishiboo dot com]

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

Bug ID: 70304
   Summary: 5.3.0 solaris: objcopy: errors.o: no group info for
section
.group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.e
rrorString
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: andrew at ishiboo dot com
CC: cmang at google dot com
  Target Milestone: ---

Compiling gcc 5.3.0 release on Solaris 11, using platform assembler/linker and
passing binutils 2.26.20160125 objcopy to configure. Everything builds fine
until it gets to go where it fails like so:

rm -f libgobegin.a
ar cru libgobegin.a libgobegin_a-go-main.o
ranlib libgobegin.a
rm -f libgolibbegin.a
ar cru libgolibbegin.a libgolibbegin_a-go-libmain.o
ranlib libgolibbegin.a
f=`echo errors.lo | sed -e 's/.lo$/.o/'`; objcopy -j .go_export $f
errors.gox.tmp && mv -f errors.gox.tmp errors.gox
objcopy: errors.o: no group info for section
.group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString
objcopy: errors.o: no group info for section
.group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString
objcopy:errors.o: Bad value
make[9]: *** [errors.gox] Error 1
make[9]: *** Waiting for unfinished jobs

[Bug c++/70305] New: 5.3.0 solaris: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a

[andrew at ishiboo dot com]

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

Bug ID: 70305
   Summary: 5.3.0 solaris: ld: fatal: relocation error:
R_SPARC_DISP32: file
../src/c++11/.libs/libc++11convenience.a
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at ishiboo dot com
  Target Milestone: ---

In 5.3.0 release on Solaris, the libstdc++, libitm, and libgfortran libraries
all fail to link with hundreds of errors such as:

ld: fatal: relocation error: R_SPARC_DISP32: file
../src/c++11/.libs/libc++11convenience.a(wlocale-inst.o): section
[1504].rela.eh_frame: symbol
.text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::istreambuf_iterator::equal(std::istreambuf_iterator const&) const (section): symbol has been discarded
with discarded section:
[716].text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::istreambuf_iterator::equal(std::istreambuf_iterator const&) const

or

ld: fatal: relocation error: R_SPARC_UA32: file
../src/c++11/.libs/libc++11convenience.a(wlocale-inst.o): section [1509].rel
a.debug_line: symbol
.text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::istreambuf_iterator::equal(std::istreambuf_iterator const&) const (section): symb
ol has been discarded with discarded section:
[716].text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::i
streambuf_iterator::equal(std::istreambuf_iterator
 const&) const

The Solaris 11 linker by default now is very strict about COMDAT relocation
processing. A new linker flag has been added `-z relax=comdat` that relaxes
COMDAT rules and enables sloppy relocation processing. In order to get a
working 5.3.0 build, it is necessary to patch configure (since libtool is not
patched) to add the `-z relax=comdat` linker flag in all cases where GCC is
used with the Solaris linker.

I opened this here because patching libtool to add this flag seems incorrect.
The built xg++ compiler should not be generating code that causes the (now)
more strict linker to fail.

$ ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2329
$ as -V
as: Sun Compiler Common 12 SunOS_sparc s11_2sru04_1 09/30/2014
$ uname -a
SunOS xxx 5.11 11.2 sun4v sparc sun4v Solaris

From the man page:

 -z relax=item1,item2,...

 The link-editor performs validity  checks  in  order  to
 ensure  that  the  resulting  output object is valid and
 usable at runtime.  In  addition,  the  link-editor  can
 transition  a  variety  of  relocations to generate more
 optimal instruction sequences. The -z relax  option  can
 be  used to relax validity checking and relocation tran-
 sitions in order to produce an output object that  would
 otherwise be rejected.

 comdat

 The link-editor normally issues a fatal  error  upon
 encountering a relocation using a symbol that refer-
 ences  an   eliminated   COMDAT   section.   If   -z
 relax=comdat  is  enabled,  the  link-editor instead
 redirects such relocations to the equivalent  symbol
 in the COMDAT section that was kept.

[Bug c++/70305] 5.3.0 solaris: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a

[andrew at ishiboo dot com]

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

--- Comment #1 from Andrew Paprocki  ---
Created attachment 38028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38028=edit
Modifications to configure

Example showing where the `-z relax=comdat` flag needed to be applied in the
generated configure files to get a working build. Ultimately this flag should
not be necessary and the compiler should be emitting correct relocations.

[Bug libstdc++/70238] [5/6 Regression] std::future_category ABI change

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
I'm afraid so, I see nothing that can be done here, either you break the
experimental uses in 4.x by not changing anything, or you break
non-experimental gcc 5.x built code.

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
The change has been reverted.

[Bug libstdc++/70298] std::call_once hangs on second call if first threw an exception

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
PR66146 is non-x86, whereas this fails on x86 too. It's possibly related
though.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Thanks for picking this up.
I agree we should keep track of the extensions implied by the architecture

[Bug c/47931] missing -Waddress warning for comparison with NULL

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||4.8.4, 4.9.3, 5.1.0, 6.0

--- Comment #4 from Martin Sebor  ---
I have a simple patch for the C++ side of the problem (below).  Let me add the
C bits along with the cleanup discussed in the context of the fix for bug 70194
(https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01041.html) and post it for
review in stage 1 of GCC 7.

Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 234306)
+++ gcc/cp/typeck.c (working copy)
@@ -3985,13 +3985,20 @@ warn_for_null_address (location_t locati
   || TREE_NO_WARNING (op))
 return;

+  STRIP_NOPS (op);
   tree cop = fold_non_dependent_expr (op);
-
-  if (TREE_CODE (cop) == ADDR_EXPR
-  && decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0))
-  && !TREE_NO_WARNING (cop))
-warning_at (location, OPT_Waddress, "the address of %qD will never "
-   "be NULL", TREE_OPERAND (cop, 0));
+  if (TREE_CODE (cop) == ADDR_EXPR && !TREE_NO_WARNING (cop))
+{
+  cop = TREE_OPERAND (cop, 0);
+  if (TREE_CODE (cop) == ARRAY_REF)
+   cop = TREE_OPERAND (cop, 0);
+  if (TREE_CODE (cop) == STRING_CST)
+   warning_at (location, OPT_Waddress,
+   "the address of a string literal will never be NULL");
+  else if (decl_with_nonnull_addr_p (cop))
+   warning_at (location, OPT_Waddress,
+   "the address of %qD will never be NULL", cop);
+}

   if (CONVERT_EXPR_P (op)
   && TREE_CODE (TREE_TYPE (TREE_OPERAND (op, 0))) == REFERENCE_TYPE)

[Bug target/70014] [ARM] Predicate does not match constraint (*subsi3_carryin_const)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Ramana Radhakrishnan  ---
Fixed then.

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
The fix has been reverted, as it caused bootstrap issues on powerpc64* and
aarch64 (and perhaps others).

[Bug c++/70205] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #7 from Patrick Palka  ---
That would suppress the ICE but in turn it would make us silently generate
wrong code since the call to D::f() won't be emitted.

adjust_result_of_qualified_name_lookup() is responsible for clobbering the
BASELINK_BINFO of the function.  This seems to work:

--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -1751,9 +1751,11 @@ adjust_result_of_qualified_name_lookup (tree decl,
   if (base && base != error_mark_node)
{
  BASELINK_ACCESS_BINFO (decl) = base;
- BASELINK_BINFO (decl)
+ tree decl_binfo
= lookup_base (base, BINFO_TYPE (BASELINK_BINFO (decl)),
   ba_unique, NULL, tf_none);
+ if (decl_binfo && decl_binfo != error_mark_node)
+   BASELINK_BINFO (decl) = decl_binfo;
}
 }

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[andris.pavenis at iki dot fi]

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

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris.pavenis at iki dot fi

--- Comment #6 from Andris Pavenis  ---
Breaks include support for DJGPP native compiler as S_ISREG is 0 for it. One
should use S_ISREG(st.st_mode) instead. gcc/system.h ensures that S_ISREG is
defined, so there should be no problems with it.

Verified that replacing '(st.st_mode & S_IFREG)' with S_ISREG(st.st_mode) fixes
libgfortran native build for DJGPP.

[Bug c/70264] [6 Regression] ICE at -O0 to -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (compatible_locations_p, at diagnostic-show-locus.c:490)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-17
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE at -O0 to -O3 in both   |[6 Regression] ICE at -O0
   |32-bit and 64-bit modes on  |to -O3 in both 32-bit and
   |x86_64-linux-gnu|64-bit modes on
   |(compatible_locations_p, at |x86_64-linux-gnu
   |diagnostic-show-locus.c:490 |(compatible_locations_p, at
   |)   |diagnostic-show-locus.c:490
   ||)
 Ever confirmed|0   |1

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

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to Andris Pavenis from comment #6)
> Breaks include support for DJGPP native compiler as S_ISREG is 0 for it. One
> should use S_ISREG(st.st_mode) instead. gcc/system.h ensures that S_ISREG is
> defined, so there should be no problems with it.
> 
> Verified that replacing '(st.st_mode & S_IFREG)' with S_ISREG(st.st_mode)
> fixes libgfortran native build for DJGPP.

OK, thanks for the feedback, will fix and make sure this works on Linux as
well.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
I have isolated to a block of code which is dead relative to our current
testsuite. Now to work on the solution.

[Bug ipa/70269] [5/6 Regression] ICE with -fdump-ipa-pta-graph -fipa-pta

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Mar 18 09:17:23 2016
New Revision: 234321

URL: https://gcc.gnu.org/viewcvs?rev=234321=gcc=rev
Log:
Set dump_file to NULL in cgraph_node::get_body

2016-03-18  Tom de Vries  

PR ipa/70269
* cgraph.c (cgraph_node::get_body): Set dump_file to NULL after save.

* gcc.dg/pr70269.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70269.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70293] [ICE, AVX-512] Wrong reg constraints in vec_dup

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
Regtest is in progress

[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 #3 from Ilya Enkovich  ---
In build_conditional_expr_1 we check if used condition is a result of another
VEC_COND_EXPR and then may just re-use condition of that VEC_COND_EXPR.

In that case we deal with boolean vector as a condition type instead of integer
vector.  That confuses following type checkers since boolean vector size may
not match integer vector size in case of scalar masks.

I try a fix which always uses original condition type.  It helps for both
provided tests.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 1edbce8..d3a256c 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4634,6 +4634,8 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree
arg2, tree arg3,

   if (VECTOR_INTEGER_TYPE_P (TREE_TYPE (arg1)))
 {
+  tree arg1_type = TREE_TYPE (arg1);
+
   /* If arg1 is another cond_expr choosing between -1 and 0,
 then we can use its comparison.  It may help to avoid
 additional comparison, produce more accurate diagnostics
@@ -4653,7 +4655,6 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree
arg2, tree arg3,
  || error_operand_p (arg3))
return error_mark_node;

-  tree arg1_type = TREE_TYPE (arg1);
   arg2_type = TREE_TYPE (arg2);
   arg3_type = TREE_TYPE (arg3);

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||robert-gcc at debian dot org

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

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #15)
>friend bool
>operator<(thread::id __x, thread::id __y) noexcept
> -  { return __x._M_thread < __y._M_thread; }
> -
> +  {  return __less::_S_less(__x._M_thread,
> __y._M_thread); }
> +#endif
> +  
> 
> What's this?

Oh, from the earlier patch attached here, which I'd forgotten about! Sorry :)

[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 #9 from Oleg Endo  ---
Just out of curiosity ... what's with the 64 in rx_print_integer?  Why do
numbers in that range need to be printed in decimal?

[Bug c++/70286] [5 Regression] ICE on template specialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||4.9.3, 5.2.0, 6.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-03-18
 Ever confirmed|0   |1
Summary|ICE on template |[5 Regression] ICE on
   |specialization  |template specialization
   Target Milestone|--- |5.4
  Known to fail||5.3.0, 5.3.1

--- Comment #1 from Richard Biener  ---
Trunk and 4.9 say

> ./cc1plus  -quiet t.C
t.C:2:18: error: ‘B’ is not a class template
 template<>struct B<>:
  ^
t.C:2:21: error: expected class-name at end of input
 template<>struct B<>:
 ^
t.C:2:21: error: expected ‘{’ at end of input
rguenther@g29:/abuild/rguenther/trunk3-g/gcc> ./cc1plus  -quiet t.C -std=c++14
t.C:2:18: error: ‘B’ is not a class template
 template<>struct B<>:
  ^
t.C:2:21: error: expected class-name at end of input
 template<>struct B<>:
 ^
t.C:2:21: error: expected ‘{’ at end of input

the issue was introduced between 5.2.0 and 5.3.0.

[Bug rtl-optimization/70263] [4.9/5/6 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (segmentation fault)

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
In all the cases where we can have the store before the equiv we're in the
realm of undefined behavior AFAICT.  But it's not clear to me that the equiv
will always be a self-referencing.

So your patch will almost certainly fix this instance, but I'm not sure it'll
fix it in the more general case.