[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault

[eyenseo at gmail dot com]

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

eyenseo at gmail dot com changed:

   What|Removed |Added

  Attachment #37264|0   |1
is obsolete||

--- Comment #1 from eyenseo at gmail dot com ---
Created attachment 37265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37265&action=edit
Fixed precompiled testcase

The other precompiled testcase had text in it.

[Bug middle-end/69156] [6 Regression] gcc.dg/pr59630.c: ICE: verify_gimple failed: non-trivial conversion at assignment with -fno-tree-ccp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37266&action=edit
gcc6-pr69156.patch

Untested fix.  Not sure if it is the best spot though.  And the testcase is
really nasty.

[Bug debug/68860] [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Mon, 21 Dec 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 37097
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37097&action=edit
> gcc6-pr68860-lto.patch
> 
> I've noticed that the new tests still fail with LTO.
> It seems the reason is that LTO ignores DECL_HAS_DEBUG_ARGS_P etc., so this
> stuff is just lost.
> I've added some changes so that this is streamed, but it seems that is not
> enough, DECL_ORIGIN of the decls is wrong, so it isn't used anyway.
> BTW, Honza, why is:
>   if (code == VAR_DECL
>   && DECL_HAS_DEBUG_EXPR_P (t))
> visit (DECL_DEBUG_EXPR (t));
> used in hash_tree?  Depends on what the function is used for, if it is for 
> code
> generation or something like that, better it should not depend on the debug
> info stuff...

It's needed to properly identify SCCs to stream - it should not result
in code-gen differences.

[Bug go/68980] [6 regression] ps -o cmd in gotest isn't portable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-08
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Ian, any progress on this?

[Bug testsuite/69007] [6 regression] test cases gcc.dg/vect/vect-reduc-dot-s8a.c fails starting with r231815

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.  Probably the change that would make two patterns at the same stmt
unrecognizable and

static vect_recog_func vect_vect_recog_func_ptrs[NUM_PATTERNS] = {
  { vect_recog_widen_mult_pattern, "widen_mult" },
  { vect_recog_widen_sum_pattern, "widen_sum" },
  { vect_recog_dot_prod_pattern, "dot_prod" },

which means widen_sum should be only after dot_prod detection.  Maybe you
can verify if swapping them passes testing on power (until I get to this
myself).

[Bug debug/68860] [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 22 Dec 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860
> 
> --- Comment #5 from Jakub Jelinek  ---
> (In reply to Jakub Jelinek from comment #4)
> > Created attachment 37097 [details]
> > gcc6-pr68860-lto.patch
> > 
> > I've noticed that the new tests still fail with LTO.
> > It seems the reason is that LTO ignores DECL_HAS_DEBUG_ARGS_P etc., so this
> > stuff is just lost.
> > I've added some changes so that this is streamed, but it seems that is not
> > enough, DECL_ORIGIN of the decls is wrong, so it isn't used anyway.
> > BTW, Honza, why is:
> >   if (code == VAR_DECL
> >   && DECL_HAS_DEBUG_EXPR_P (t))
> > visit (DECL_DEBUG_EXPR (t));
> > used in hash_tree?  Depends on what the function is used for, if it is for
> > code generation or something like that, better it should not depend on the
> > debug info stuff...
> 
> So, the reason why nothing is emitted on the callee side with this patch is
> that LTO does never stream DECL_ABSTRACT_ORIGIN, and this is used to double
> check the data before actually trying to emit anything.  Perhaps this could be
> bypassed by some lto condition, but in any case we'd need a way how to find 
> out
> the correspondence between those decl_debug_args decls and the original
> arguments that were optimized away.
> The reason why nothing is emitted on the caller sides is that for some reason
> when streaming in the decl_debug_args, all the DEBUG_EXPR_DECLs turn out to be
> D#1, while they really should be D#1, D#2 etc. and the DEBUG_EXPR_DECLs 
> emitted
> in the callers before those calls should match them, while they are assigned
> independently.

I wouldn't worry about this too much (LTO) for GCC 6 but you can 
experiment with just letting the specific case through streaming
(and otherwise stream NULL_TREE).

early LTO debug is supposed to fix all this ...

[Bug tree-optimization/69083] [6 Regression] ICE at -O3 in 64-bit mode on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan  8 08:37:17 2016
New Revision: 232153

URL: https://gcc.gnu.org/viewcvs?rev=232153&root=gcc&view=rev
Log:
PR tree-optimization/69083
* tree-vect-slp.c (vect_get_constant_vectors): For
VECTOR_BOOLEAN_TYPE_P assert op is fold_convertible_p to vector_type's
element type.  If op is fold_convertible_p to vector_type's element
type, use NOP_EXPR instead of VCE.

* gcc.dg/vect/pr69083.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr69083.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Tue, 22 Dec 2015, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
> 
> --- Comment #23 from alalaw01 at gcc dot gnu.org ---
> Yes, difficult. I'm conscious that this is stage 3, and worried about adding
> too much complexity, especially if we're writing code that we'd eventually 
> drop
> in favour of a more complete framework later (i.e. in gcc7).
> 
> I'm inclined against
> 
> > (I wondered
> > if load-lanes would require more unrolling we should prefer SLP anyway?).
> 
> As we've seen cases where load-lanes requires more unrolling but the code is
> still much better. Likewise your argument against
> 
> > to query whether _all_ loads need to be permuted with SLP
> ...
> > thus if there is a load node which is not permuted then retain the SLP.
> 
> seems convincing. I think the heuristic in comment 16 handles permutation well
> enough, and beyond that, sharing (rather than the permutation) then appears to
> be the critical factor. Unfortunately as you say SLP doesn't really handle
> sharing yet...so
> 
> > I fear that to get a better heuristic
> > than what is proposed we need to push this for example to
> > vect_make_slp_decision where all instances are built
> 
> Might be reasonable, but I fear it'd be of dubious benefit without:
> 
> > and we'd need to gather some sharing data therein.
> 
> I guess if that were a useful step towards
> 
> > But then there is only a small step to the point where we could actually
> > compare SLP vs. non-SLP costs.
> 
> then there is some justification, but the former feels like too much 
> complexity
> at this stage - especially to do it well; how much do we really want to gather
> data on the sharing that exists at present, rather than looking at removing
> that sharing entirely? I'm thinking of e.g. SLP nodes that are performing the
> same computations but with different permutations too - shouldn't we be aiming
> at making permutations into first class citizens/operations, and making SLP
> trees into DAGs? Longer-term goals, sure...
> 
> So my instinct is to go with the comment 16 patch, and accept that we take the
> hit in that last testcase (i.e. the one with the sharing).

Works for me - can you get the patch "aprroved" on the ml then?

[Bug tree-optimization/69083] [6 Regression] ICE at -O3 in 64-bit mode on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69013] [5/6 Regression] gfortran-5.3.0 ICE in prune_uninit_phi_opnds_in_unrealizable_paths, at tree-ssa-uninit.c:1121

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|error-recovery  |
 Status|NEW |ASSIGNED
 CC||xinliangli at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[5 Regression]  |[5/6 Regression]
   |gfortran-5.3.0 ICE in   |gfortran-5.3.0 ICE in
   |prune_uninit_phi_opnds_in_u |prune_uninit_phi_opnds_in_u
   |nrealizable_paths, at   |nrealizable_paths, at
   |tree-ssa-uninit.c:1121  |tree-ssa-uninit.c:1121

--- Comment #4 from Richard Biener  ---
I dont' know the code good enough but the assert might be bogus?  Thus

Index: gcc/tree-ssa-uninit.c
===
--- gcc/tree-ssa-uninit.c   (revision 231672)
+++ gcc/tree-ssa-uninit.c   (working copy)
@@ -1118,14 +1118,16 @@ prune_uninit_phi_opnds_in_unrealizable_p
   edge opnd_edge;
   unsigned uninit_opnds2
   = compute_uninit_opnds_pos (opnd_def_phi);
-  gcc_assert (!MASK_EMPTY (uninit_opnds2));
-  opnd_edge = gimple_phi_arg_edge (phi, i);
-  if (!is_use_properly_guarded (phi,
-opnd_edge->src,
-opnd_def_phi,
-uninit_opnds2,
-visited_phis))
-  return false;
+  if (!MASK_EMPTY (uninit_opnds2))
+   {
+ opnd_edge = gimple_phi_arg_edge (phi, i);
+ if (!is_use_properly_guarded (phi,
+   opnd_edge->src,
+   opnd_def_phi,
+   uninit_opnds2,
+   visited_phis))
+   return false;
+   }
 }
   else
 return false;

"fixes" it.  Marking as 6 regression as well because it's clearly only latent.

A smaller testcase for easier investigation would be nice.

Not sure if David is still around...

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

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Andrew Pinski from comment #11)
> We still get the bogus IR but we don't ICE any more:
>   v4qi c;
>   uv4qi d;
> 
>   c = {a, a, a, a};
>   d = {a, a, a, a};
>   D.2757 = c != d;
>   D.2758 = VEC_COND_EXPR ;
>   D.2759 = VIEW_CONVERT_EXPR(D.2758);
> 
> Also VEC_COND_EXPR really should not be there.

What's bogus with the IR?  The VIEW_CONVERT need not be there as it can
be combined with the VEC_COND_EXPR RHSs.  We can't drop the VEC_COND_EXPR
as c != d results in a vector bool while we want a v4qi.

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
That just made a latent issue (re-)appear.  It looks like just a reg-reg DImode
move - what can be possibly wrong with it?

[Bug target/69176] [6 Regression] ICE in in final_scan_insn, at final.c:2981 on aarch64-linux-gnu

[rth at gcc dot gnu.org]

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

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

--- Comment #10 from Richard Henderson  ---
Created attachment 37267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37267&action=edit
proposed patch

Andrew is exactly right re plus being special.

The pluslong hoops that are being jumped through are really the
domain for post-reload splitters and peepholes.

[Bug tree-optimization/67781] [5/6 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations

[thopre01 at gcc dot gnu.org]

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

--- Comment #14 from Thomas Preud'homme  ---
Author: thopre01
Date: Fri Jan  8 09:21:19 2016
New Revision: 232154

URL: https://gcc.gnu.org/viewcvs?rev=232154&root=gcc&view=rev
Log:
2016-01-08  Thomas Preud'homme  

gcc/
PR tree-optimization/67781
* tree-ssa-math-opts.c (find_bswap_or_nop): Zero out bytes in cmpxchg
and cmpnop in two steps: first the ones not accessed in original
gimple expression in a endian independent way and then the ones not
accessed in the final result in an endian-specific way.

gcc/testsuite/
PR tree-optimization/67781
* gcc.c-torture/execute/pr67781.c: New file.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr67781.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug tree-optimization/68967] Build and test parloops on by default

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
(In reply to vries from comment #9)
> Though at the end, make check hung in fix-include.

More specifically, the testing of fixincludes hangs:
...
22074 pts/6S+ 0:00  | \_ /bin/sh ./check.sh src/fixincludes/tests/base
23706 pts/6Sl+0:00  | \_ ../../fixincl
23796 pts/6S+ 0:00  | \_ ../../fixincl
...

[Bug tree-optimization/69110] [4.9/5/6 Regression] execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression]|[4.9/5/6 Regression]
   |execution failure in|execution failure in
   |gcc.c-torture/execute/doloo |gcc.c-torture/execute/doloo
   |p-2.c with  |p-{1,2}.c with
   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2

--- Comment #11 from vries at gcc dot gnu.org ---
Same problem with src/gcc/testsuite/gcc.c-torture/execute/doloop-1.c

[Bug target/69071] [6 Regression] ICE: in decompose, at rtl.h:2107 with -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-08
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug c/69192] New: valgrind trunk build fail in predict_loops

[dcb314 at hotmail dot com]

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

Bug ID: 69192
   Summary: valgrind trunk build fail in predict_loops
   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: ---

I just tried a trunk gcc build with valgrind

svn says 

$ svn info
Revision: 232153

Configure line is

$ ../src/trunk/configure --prefix=/home/dcb/gcc/results \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=valgrind \
--enable-languages=c,c++,fortran \
CC="/home/dcb/llvm/results/bin/clang" \
CXX="/home/dcb/llvm/results/bin/clang++"

and the valgrind error is 

/home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/
-B/home/dcb/gcc/results/x86_64-pc-linux-gnu/bin/
-B/home/dcb/gcc/results/x86_64-pc-linux-gnu/lib/ -isystem
/home/dcb/gcc/results/x86_64-pc-linux-gnu/include -isystem
/home/dcb/gcc/results/x86_64-pc-linux-gnu/sys-include-g -O3 -march=native
-O2  -g -O3 -march=native -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -fpic -mlong-double-80
-DUSE_ELF_SYMVER -I. -I. -I../.././gcc -I../../../src/trunk/libgcc
-I../../../src/trunk/libgcc/. -I../../../src/trunk/libgcc/../gcc
-I../../../src/trunk/libgcc/../include
-I../../../src/trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o _powidf2.o -MT _powidf2.o -MD -MP -MF _powidf2.dep
-DL_powidf2 -c ../../../src/trunk/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
==25598== Conditional jump or move depends on uninitialised value(s)
==25598==at 0x9073D6: predict_loops (predict.c:1503)
==25598==by 0x9073D6: tree_estimate_probability() (predict.c:2349)
==25598==by 0x90B3F7: (anonymous
namespace)::pass_profile::execute(function*) (predict.c:3043)
==25598==by 0x8FA4CD: execute_one_pass(opt_pass*) (passes.c:2336)

In the source code predict.c:1503 is

  if (!niter || TREE_CODE (niter_desc.niter) != INTEGER_CST)
niter = loop_niter_by_eval (loop, ex);

svn blame says

118694hubicka if (!niter || TREE_CODE (niter_desc.niter) !=
INTEGER_CST)
119039rakdver   niter = loop_niter_by_eval (loop, ex);

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
I still see the ICE.

[Bug tree-optimization/69172] [6 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan  8 10:13:23 2016
New Revision: 232155

URL: https://gcc.gnu.org/viewcvs?rev=232155&root=gcc&view=rev
Log:
PR tree-optimization/69172
* gimple-fold.c (gimple_fold_builtin_memory_chk): Pass type to
gimple_build.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69172.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69162] [6 Regression] ICE in create_tmp_var, at gimple-expr.c:468

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan  8 10:14:29 2016
New Revision: 232156

URL: https://gcc.gnu.org/viewcvs?rev=232156&root=gcc&view=rev
Log:
PR tree-optimization/69162
* gimplify.c (gimplify_va_arg_expr): Encode original type of
valist argument in another argument.
(gimplify_modify_expr): Adjust for the above change.  Cleanup.
* tree-stdarg.c (expand_ifn_va_arg_1): Use new 3rd argument
to determine the va_list type, build a MEM_REF instead of
build_fold_indirect_ref.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69162.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-stdarg.c

[Bug c/69192] valgrind trunk build fail in predict_loops

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
May well be a clang bug. Does it also happen if you use gcc to build?

[Bug tree-optimization/69170] [6 Regression] ICE (segfault) in find_uses_to_rename_use

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69162] [6 Regression] ICE in create_tmp_var, at gimple-expr.c:468

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69172] [6 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.  But as I said, please make sure the broken package that uses this is
fixed too.

[Bug target/68648] [4.9/5/6 Regression][ARM] ICE: fail to generate BIC(immediate) instruction

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Jan  8 10:36:37 2016
New Revision: 232157

URL: https://gcc.gnu.org/viewcvs?rev=232157&root=gcc&view=rev
Log:
[ARM] PR target/68648: Fold NOT of CONST_INT in andsi_iorsi3_notsi splitter

PR target/68648
* config/arm/arm.md (*andsi_iorsi3_notsi): Try to simplify
the complement of operands[3] during splitting.

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


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68648.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-08
 CC||jakub at gcc dot gnu.org,
   ||rth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r207518.

[Bug rtl-optimization/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to ktkachov from comment #4)
> > Ok, judging from this my simplistic patch from
> > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00329.html
> > is not appropriate
> 
> I think so.  Also note that the testcase really should be reduced, try delta
> or creduce.

It was somewhat of a pain to get creduce installed (it required llvm and some
other stuff) but it was worth it.
The reduced testcase  for -O3 is:

char a;
b, c, d, e;
fn1() {
  int f = 0;
  for (; f <= 4; f++) {
d = 0;
for (; d < 20; d++) {
  long g = &c;
  b &= (0 != g) > e;
}
e &= a;
  }
}

[Bug tree-optimization/69160] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1436

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
A much smaller reduced testcase ICEs at -O3:

a, b, c;
fn1() {
  for (;;) {
int *d;
fn2();
c = 0;
for (; c <= 3; c++) {
  *d ^= 9;
  b = 0;
  for (; b <= 3; b++)
*d ^= a;
}
  }
}

[Bug rtl-optimization/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to ktkachov from comment #7)

You want to turn that back to at least valid C99 if that still reproduces the
issue:

> char a;
> b, c, d, e;
> fn1() {
>   int f = 0;
>   for (; f <= 4; f++) {
> d = 0;
> for (; d < 20; d++) {
>   long g = &c;
>   b &= (0 != g) > e;
> }
> e &= a;
>   }
> }

char a;
int b, c, d, e;

void
foo (void)
{
  int f;
  for (f = 0; f <= 4; f++)
{
  for (d = 0; d < 20; d++)
{
  long g = &c; // would it reproduce even with int *g = &c; ?
  b &= (0 != g) > e;
}
  e &= a;
}
}


}

[Bug c/69193] New: ICE: openmp + nested function + VLA

[uecker at eecs dot berkeley.edu]

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

Bug ID: 69193
   Summary: ICE: openmp + nested function  + VLA
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at eecs dot berkeley.edu
  Target Milestone: ---

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

Trying to get openmp to make a private copy of an array passed
to a function, I tried to use a nested function which produces
the following ICE (recent gcc build from git):


$ ~/src/gcc_build/gcc/xgcc -fopenmp -B ~/src/gcc_build/gcc/ test.c 
test.c: In function ‘md_parallel_loop_r’:
test.c:19:11: internal compiler error: in lower_rec_input_clauses, at
omp-low.c:4756
   #pragma omp parallel for firstprivate(pos)
   ^~~

0x9fb368 lower_rec_input_clauses
../../gcc/gcc/omp-low.c:4756
0x9fd62e lower_omp_taskreg
../../gcc/gcc/omp-low.c:14972
0x9ef4c6 lower_omp_1
../../gcc/gcc/omp-low.c:16345
0x9ef4c6 lower_omp
../../gcc/gcc/omp-low.c:16484
0x9ef15d lower_omp_1
../../gcc/gcc/omp-low.c:16337
0x9ef15d lower_omp
../../gcc/gcc/omp-low.c:16484
0x9f6489 execute_lower_omp
../../gcc/gcc/omp-low.c:16522
0x9f6489 execute
../../gcc/gcc/omp-low.c:16559
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/68449] [5/6 Regression] ICE in cxx_eval_constant_expression on atomic_load in C++

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
I think I'll post

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3195,7 +3195,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
   if (VAR_P (r))
if (tree *p = ctx->values->get (r))
  r = *p;
-  if (DECL_P (r))
+  if (r == NULL_TREE || DECL_P (r))
{
  if (!ctx->quiet)
non_const_var_error (r);

[Bug libstdc++/69190] FAIL: experimental/type_erased_allocator/uses_allocator.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/69184] [6 Regression] ICE in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2685

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Created attachment 37270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37270&action=edit
reduced testcase

More reduced testcase for -O3 -floop-interchange

[Bug target/69194] New: internal compiler error: in extract_insn, at recog.c:2286

[kugan at gcc dot gnu.org]

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

Bug ID: 69194
   Summary: internal compiler error: in extract_insn, at
recog.c:2286
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

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

Attached testcase ICE with:

t.C: In function ‘crashes do_crash(Table, Points)’:
t.C:504:1: error: unrecognizable insn:
 }
 ^

(insn 27 26 28 4 (set (reg:V4SF 123)
(unspec:V4SF [
(mem/c:V4SF (reg/f:SI 104 virtual-incoming-args) [0 MEM[(const
float[4] *)&p]+0 S16 A32])
] UNSPEC_VLD1)) t.C:31 -1
 (nil))

command line options:arm-none-linux-gnueabi-g++  -O2 -mfpu=neon -S 
-Wno-deprecated-declarations t.C

gcc -v:

Using built-in specs.
COLLECT_GCC=/home/kugan/work/builds/gcc-fsf-gcc/tools/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/kugan/work/builds/gcc-fsf-gcc/tools/libexec/gcc/arm-none-linux-gnueabi/6.0.0/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with: /home/kugan/work/sources/gcc-fsf/gcc/configure
--target=arm-none-linux-gnueabi
--prefix=/home/kugan/work/builds/gcc-fsf-gcc/tools
--with-sysroot=/home/kugan/work/builds/gcc-fsf-gcc/sysroot-arm-none-linux-gnueabi
--disable-libssp --disable-libgomp --disable-libmudflap
--enable-languages=c,c++ --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-float=softfp --with-thumb
Thread model: posix
gcc version 6.0.0 20151231 (experimental) (GCC)

[Bug target/69082] Final link fails on ARM using lto

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org
  Component|lto |target

--- Comment #11 from Richard Earnshaw  ---
Looks like 
https://gcc.gnu.org/ml/gcc-cvs/2015-08/msg00665.html

would be an appropriate fix for this.

[Bug target/69175] [6 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7895

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 37272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37272&action=edit
gcc6-pr69175.patch

One possible fix that seems to work.

[Bug target/69194] [5/6 Regression] internal compiler error: in extract_insn, at recog.c:2286

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-01-08
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|internal compiler error: in |[5/6 Regression] internal
   |extract_insn, at|compiler error: in
   |recog.c:2286|extract_insn, at
   ||recog.c:2286
   Target Milestone|--- |5.4
  Known to fail||5.3.1, 6.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on trunk and 5 branch.
4.9 doesn't build for language-level issues (different intrinsics
implementation back then or something)
-O2 -std=gnu++11 -mfpu=neon -S  -w -mfloat-abi=softfp
is needed. -mfloat-abi=hard doesn't ICE

[Bug tree-optimization/69166] [6 Regression] ICE in get_initial_def_for_reduction, at tree-vect-loop.c:4188

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-01-08
 CC||alalaw01 at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
No, not a dup - 69053 results from a type mismatch/missing conversion building
the initial value for a COND_EXPR; this PR is because the 'reduction' is an
RDIV_EXPR, which get_initial_def_for_reduction doesn't handle.

The testcase invokes undefined behaviour, too (e is not initialized). Moving
'double *e' to be a parameter to fn2 avoids the ICE.

[Bug target/69195] New: [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[zsojka at seznam dot cz]

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

Bug ID: 69195
   Summary: [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs
with -O3 -fno-dce -fno-forward-propagate
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64-unknown-linux-gnu

Created attachment 37273
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37273&action=edit
reduced testcase (gcc.dg/torture/pr44913.c)

Output: (qemu user emulation is used)
$ powerpc64-unknown-linux-gnu-gcc -O3 -fno-dce -fno-forward-propagate
testcase.c
$ ./a.out 
Invalid data memory access: 0x002c0050
NIP 1e60   LR 100015e8 CTR 1e20 XER
 CPU#0
MSR 82806000 HID0   HF 02806000 idx 0
TB 00142866 613604922925824
GPR00 0009000a 0040007ff3a0 100bea00 0001
GPR04 000d 000d000e 000f0010 00010002
GPR08 00060006 002c0050 00100018 000b000c
GPR12 00070008 100c0750  
GPR16    
GPR20    
GPR24    
GPR28 100b1b70 100b1b58 100b6e08 12e8
CR 2842  [ E  L  -  -  -  -  G  E  ] RES 
FPR00    
FPR04    
FPR08    
FPR12    
FPR16    
FPR20    
FPR24    
FPR28    
FPSCR 
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

(gdb) disassemble 
...
   0x1e54 <+52>:ld  r0,32(r9)
   0x1e58 <+56>:ld  r9,88(r9)
   0x1e5c <+60>:stdur1,-256(r1)
=> 0x1e60 <+64>:ld  r31,0(r9)
   0x1e64 <+68>:std r31,176(r1)
   0x1e68 <+72>:ld  r31,8(r9)
   0x1e6c <+76>:addir3,r1,184
...
(gdb) info reg
...
r9 0x2c0050 188978561104
...

The load at 0x1e58 clobbers r9, which is still later used to load
values for a[]/r[] initialisation.

Only the powerpc64 target seems to be affected.

Tested revisions:
trunk r232129 - FAIL
5-branch r232044 - FAIL
4_9-branch r232043 - FAIL
4_8-branch r224828 - FAIL
4_7-branch r211571 - FAIL
4_6-branch r197894 - OK
4_5-branch r189152 - OK
4_4-branch r185318 - OK

[Bug fortran/69154] [6 Regression] ICE in gfc_trans_where_2, at fortran/trans-stmt.c:5005 on *-linux

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
A quick fix is rather easy - don't do the matmul inlining
within a WHERE block. We do the same thing already for
function elimination.

[Bug target/69182] Internal compiler error, dwarf2out_frame_debug_expr, at dwarf2cfi.c:1550

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-08
  Component|c++ |target
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.2, 5.3.0, 6.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/69186] ICE at -O3 on x86_64-linux-gnu in vect_update_misalignment_for_peel, at tree-vect-data-refs.c:889

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-08
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed, mine.

[Bug preprocessor/69177] [6 Regression] Bit-packing optimization makes it too easy to have location_t >= LINE_MAP_MAX_LOCATION_WITH_COLS

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|Bit-packing optimization|[6 Regression] Bit-packing
   |makes it too easy to have   |optimization makes it too
   |location_t >=   |easy to have location_t >=
   |LINE_MAP_MAX_LOCATION_WITH_ |LINE_MAP_MAX_LOCATION_WITH_
   |COLS|COLS

[Bug tree-optimization/69174] [6 Regression] ICE (segfault) in operand_equal_p

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
$ powerpc64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64/bin/powerpc64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-232129-checking-yes-rtl-df-nographite-powerpc64/bin/../libexec/gcc/powerpc64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=powerpc64-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64-unknown-linux-gnu-as
--with-sysroot=/usr/powerpc64-unknown-linux-gnu --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-232129-checking-yes-rtl-df-nographite-powerpc64
Thread model: posix
gcc version 6.0.0 20160107 (experimental) (GCC)

[Bug tree-optimization/69173] [6 Regression] ICE (segfault) in vinfo_for_stmt

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69168] [6 Regression] ICE in vect_analyze_loop_2, at tree-vect-loop.c:2182

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69166] [6 Regression] ICE in get_initial_def_for_reduction, at tree-vect-loop.c:4188

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||x86_64-*-*
 Status|REOPENED|NEW
   Target Milestone|--- |6.0

--- Comment #3 from Richard Biener  ---
Confirmed on x86_64.

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Author: jamborm
Date: Fri Jan  8 12:30:56 2016
New Revision: 232159

URL: https://gcc.gnu.org/viewcvs?rev=232159&root=gcc&view=rev
Log:
[PR 68851] Do not collect thunks in collect_callers

2016-01-08  Martin Jambor  

PR ipa/68851
gcc/
* cgraph.c (collect_callers_of_node_1): Do not collect thunks.
* cgraph.h (cgraph_node): Change comment of collect_callers.

testsuite/
* g++.dg/ipa/pr68851.C: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/ipa/pr68851.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/cgraph.c
branches/gcc-5-branch/gcc/cgraph.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/69160] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1436

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|aarch64 |aarch64, x86_64-*-*
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-08
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed, mine.

[Bug tree-optimization/69157] [6 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:8176

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/69196] New: Code size regression on SPARC

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

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

Bug ID: 69196
   Summary: Code size regression on SPARC
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Created attachment 37274
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37274&action=edit
Test case.

This is quite an increase of the code size for the attached test case.

sparc-rtems4.11-gcc (GCC) 4.9.4 20150723 (prerelease)
sparc-rtems4.12-gcc (GCC) 6.0.0 20160108 (experimental)
sparc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i
sparc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i
size vprintk.4.11.o
   textdata bss dec hex filename
688   0   0 688 2b0 vprintk.4.11.o
size vprintk.4.12.o
   textdata bss dec hex filename
   1272   0   01272 4f8 vprintk.4.12.o

I noticed a size increase for various files, but this one was quite drastic.

[Bug middle-end/69156] [6 Regression] gcc.dg/pr59630.c: ICE: verify_gimple failed: non-trivial conversion at assignment with -fno-tree-ccp

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 37266 [details]
> gcc6-pr69156.patch
> 
> Untested fix.  Not sure if it is the best spot though.  And the testcase is
> really nasty.

Hmm, but this means things were mismatched in the first place (earlier) and
thus this should be checked somewhere else?

[Bug fortran/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
I think we have a dup/related bug where we run into the issue that
tree-complex.c
wrecks SSA form during its rewrite.

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[jamborm at gcc dot gnu.org]

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

--- Comment #14 from Martin Jambor  ---
Author: jamborm
Date: Fri Jan  8 12:34:34 2016
New Revision: 232160

URL: https://gcc.gnu.org/viewcvs?rev=232160&root=gcc&view=rev
Log:
[PR 68851] Do not collect thunks in collect_callers

2016-01-08  Martin Jambor  

PR ipa/68851
gcc/
* cgraph.c (collect_callers_of_node_1): Do not collect thunks.
(collect_callers): Change comment.

testsuite/
* g++.dg/ipa/pr68851.C: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr68851.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cgraph.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/69139] [4.9/5/6 Regression] deduction failure with trailing return type in function template argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.0 |4.9.4

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Jambor  ---
Yes, they did, thanks for the reminder. This is now fixed.

[Bug target/69082] Final link fails on ARM using lto

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

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

--- Comment #12 from Renlin Li  ---
(In reply to Richard Earnshaw from comment #11)
> Looks like 
> https://gcc.gnu.org/ml/gcc-cvs/2015-08/msg00665.html
> 
> would be an appropriate fix for this.

I verified that, this patch fixes the problem described here.

I will do full regression test first. If nothing is broken, I will send a
backport patch to branch 4.9.

[Bug target/69196] Code size regression on SPARC

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Probably jump (FSM) threading gets in the way.  Btw, if you look for code-size
use -Os ... (aka, does it get faster?)

[Bug target/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

--- Comment #2 from Richard Biener  ---
Flags to check are -fno-tree-vectorize and -fno-ivopts.

[Bug c++/68926] [4.9/5/6 Regression] decltype and sfinae to check for template instance availability fails to compile

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug ipa/68981] [4.9/5/6 Regression] g++.dg/ipa/pr60640-4.C FAILs with -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Started with r230365:

commit d2c638268e30dea7631ca2ee9b7489da2317526b
Author: jason 
Date:   Sat Nov 14 00:08:05 2015 +

Merge C++ delayed folding branch.

[Bug libstdc++/68995] [4.9/5/6 Regression] Including both and can cause ADL problems in std::function SFINAE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug target/69196] Code size regression on SPARC

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

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

--- Comment #2 from Sebastian Huber  ---
Ok, with -Os I don't have the problem:

sparc-rtems4.11-gcc -c -Os -o vprintk.4.11.o vprintk.i
sparc-rtems4.12-gcc -c -Os -o vprintk.4.12.o vprintk.i
size vprintk.4.11.o
   textdata bss dec hex filename
612   0   0 612 264 vprintk.4.11.o
size vprintk.4.12.o
   textdata bss dec hex filename
608   0   0 608 260 vprintk.4.12.o

It seems that this is not SPARC specific. I get it also on PowerPC:

powerpc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i
powerpc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i
size vprintk.4.11.o
   textdata bss dec hex filename
797   0   0 797 31d vprintk.4.11.o
size vprintk.4.12.o
   textdata bss dec hex filename
   1385   0   01385 569 vprintk.4.12.o

I am not sure if this is an improvement.

[Bug target/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka  ---
(In reply to Richard Biener from comment #2)
> Flags to check are -fno-tree-vectorize and -fno-ivopts.

The testcase crashes with either -fno-tree-vectorize and/or -fno-ivopts.

[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

--- Comment #41 from Richard Biener  ---
There will be.

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #14 from Nick Clifton  ---
Created attachment 37275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37275&action=edit
Use SFmode variant of DFmode builtin vector types when -fshort-doubles is
enabled.

Hi Guys,

  I recently created and posted a patch for PR 55113 which also fixes this PR. 
(Patch attached here for easy reference).

  One reviewer however has suggested that a better solution would be to disable
-fshort-double option entirely:

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01900.html

  I am not of the best way to proceed.  Any suggestions ?

Cheers
  Nick

[Bug c++/68252] [5 regression] left operand of shift expression, while we shift > 0 integer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

[nickc at redhat dot com]

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

--- Comment #15 from Nick Clifton  ---
Sorry I meant:

  I am not sure of the best way to proceed.
   

[Bug target/69019] [5 regression] Failure of test case gcc.target/powerpc/ti_math1.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug target/43052] [4.9/5/6 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #32 from Nick Clifton  ---
Is this PR still a problem ?

I tried building the testcase from comment #1 today and found the memcmp is
being called even at -O3.  The run times are approximately the same for -O3 and
-O0 as well.

Cheers
  Nick

[Bug tree-optimization/69160] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1436

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan  8 13:14:01 2016
New Revision: 232162

URL: https://gcc.gnu.org/viewcvs?rev=232162&root=gcc&view=rev
Log:
Add missing include for std::__addressof

PR libstdc++/69160
* include/bits/uses_allocator.h: Add missing include.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/uses_allocator.h

[Bug tree-optimization/69160] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1436

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> Author: redi
> Date: Fri Jan  8 13:14:01 2016
> New Revision: 232162
> 
> URL: https://gcc.gnu.org/viewcvs?rev=232162&root=gcc&view=rev
> Log:
> Add missing include for std::__addressof
> 
>   PR libstdc++/69160

Sorry, that was meant to be PR 69190

[Bug c++/68738] call to overridden function segfaults

[rianquinn at gmail dot com]

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

Rian Quinn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Rian Quinn  ---
It appears to be resolved by simply executing the symbols located in .ctors /
.dtors. Although these sections are documented as being dedicated for globally
defined constructors / destructors, on x86_64, they actually point to a set of
functions labeled:

_GLOBAL__sub_I_XXX
_GLOBAL__sub_D_XXX

which appear to call:

_Z41__static_initialization_and_destruction_0ii

Once this symbol is executed, not only are the globally defined constructors /
destructors executed, but the crashes that were identified in this bug report
are also addressed. This includes crashes for pointers to globally defined
classes, but also pointers to member variables.

[Bug libstdc++/69190] FAIL: experimental/type_erased_allocator/uses_allocator.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed at r232162

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #218 from Martin Liška  ---
Hi.

Building Firefox revision:
commit a704d34fb1f9e0f5dbf4113298d885cdb650906c
Author: Matthew Noorenberghe 
Date:   Thu Dec 3 17:33:35 2015 -0800

Bug 1230391 - Disable password visibility toggling in the capture
doorhanger outside Nightly. rs=bnicholson, a=lizzard on a CLOSED TREE

--HG--
extra : source : aea828e2cdf767a358ebc6ea661dd3b9b4160321
extra : intermediate-source : 366dd290472633b06f0942d7737c34e942e0916a

This is a minimal set of LTO options for which the built binary can run:
MYFLAGS="$OPT -march=native -flto=9 -fno-lifetime-dse -fno-devirtualize"

For more details:
# MYFLAGS="$OPT -march=native -flto=9" FAILED
# MYFLAGS="$OPT -march=native -flto=9 -fno-lifetime-dse
-fno-delete-null-pointer-checks -fno-devirtualize -fno-strict-aliasing" OK
# MYFLAGS="$OPT -march=native -flto=9 -fno-lifetime-dse
-fno-delete-null-pointer-checks" FAILED
# MYFLAGS="$OPT -march=native -flto=9 -fno-lifetime-dse
-fno-delete-null-pointer-checks -fno-devirtualize" OK
# MYFLAGS="$OPT -march=native -flto=9 -fno-devirtualize" FAILED
# MYFLAGS="$OPT -march=native -flto=9 -fno-lifetime-dse -fno-devirtualize" OK
# MYFLAGS="$OPT -march=native -flto=9 -fno-lifetime-dse" FAILED

Martin

[Bug rtl-optimization/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
You're right, thanks.
char a;
int b, c, d, e;

void
foo (void)
{
  int f;
  for (f = 0; f <= 4; f++)
{
  for (d = 0; d < 20; d++)
{
  long g = &c;
  b &= (0 != g) > e;
}
  e &= a;
}
}

Replacing the "long g = &c;"
with "int g = &c;" unfortunately doesn't reproduce the ICE

[Bug rtl-optimization/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Sorry. Of course you meant "int *". That still ICEs:
char a;
int b, c, d, e;

void
foo (void)
{
  int f;
  for (f = 0; f <= 4; f++)
{
  for (d = 0; d < 20; d++)
{
  int *g = &c;
  b &= (0 != g) > e;
}
  e &= a;
}
}

[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
The machinery in dwarf2out is somewhat fragile (as discovered from LTO early
debug work).  Note that I changed lto_symtab_merge to OR DECL_POSSIBLY_INLINED
during that work (committed to trunk).  But I remember I still hit that very
same assert.

[Bug ipa/69075] ICE when setting early-inlining-insns to other than default

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Ick - re-gimplification hits C++ FE hooks...

We should really do parts of

  /* Reset some langhooks.  Do not reset types_compatible_p, it may
 still be used indirectly via the get_alias_set langhook.  */
  lang_hooks.dwarf_name = lhd_dwarf_name;
  lang_hooks.decl_printable_name = gimple_decl_printable_name;
  lang_hooks.gimplify_expr = lhd_gimplify_expr;

unconditionally (not on LTO) in free_lang_data.

Eventually the gimplify hook even earlier at the start of finalize_CU.

[Bug rtl-optimization/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to ktkachov from comment #10)
> Sorry. Of course you meant "int *". That still ICEs:
> char a;
> int b, c, d, e;
> 
> void
> foo (void)
> {
>   int f;
>   for (f = 0; f <= 4; f++)
> {
>   for (d = 0; d < 20; d++)
> {
>   int *g = &c;
>   b &= (0 != g) > e;
> }
>   e &= a;
> }
> }

And __INTPTR_TYPE__ g = (__INTPTR_TYPE__) &g; ?
Because the version with long isn't portable.

[Bug rtl-optimization/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)

> And __INTPTR_TYPE__ g = (__INTPTR_TYPE__) &g; ?

You mean (__INTPTR_TYPE__) &c; ?
It ICEs as well:

char a;
int b, c, d, e;

void
foo (void)
{
  int f;
  for (f = 0; f <= 4; f++)
{
  for (d = 0; d < 20; d++)
{
  __INTPTR_TYPE__ g = (__INTPTR_TYPE__) &c;
  b &= (0 != g) > e;
}
  e &= a;
}
}

[Bug ipa/69044] [6 regression] [CHKP] internal compiler error: in duplicate_thunk_for_node

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
OK, so after looking into this (and CHKP) a bit more, this is only one
of many issues with costant propagating into CHKP functions and
thunks.  In fact, there is an attempt to disable that in
propagate_constants_accross_call but it fails because Honza made
IPA-CP also clone for removal useless parameters.  Which is something
we should not do if the function's signature cannot be changed.  So
the correct fix to this seems to be the following, which I will submit
to the mailing list after testing:

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 782df71..d99e69c 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -2518,7 +2518,8 @@ estimate_local_effects (struct cgraph_node *node)
   known_aggs_ptrs = agg_jmp_p_vec_for_t_vec (known_aggs);
   int devirt_bonus = devirtualization_time_bonus (node, known_csts,
   known_contexts, known_aggs_ptrs);
-  if (always_const || devirt_bonus || removable_params_cost)
+  if (always_const || devirt_bonus
+  || (removable_params_cost && node->local.can_change_signature))
 {
   struct caller_statistics stats;
   inline_hints hints;

[Bug rtl-optimization/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to ktkachov from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> 
> > And __INTPTR_TYPE__ g = (__INTPTR_TYPE__) &g; ?
> 
> You mean (__INTPTR_TYPE__) &c; ?
> It ICEs as well:

Sure, sorry for the typo.

[Bug tree-optimization/69097] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #37219|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Updated patch.

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[civil.over at gmail dot com]

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

--- Comment #1 from Vladimir Smirnov  ---
I've also tried to test gcc 6.0, snapshot 20160103 but still getting this:
root@katje ~ # gcc-6.0.0-alpha20160103 -mfpu=neon ./bug.c
./bug.c: In function 'bug':
./bug.c:3:9: internal compiler error: Segmentation fault
 __builtin_neon_vmlals_lanev4hi(a, b, c, 0);
 ^~

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libgomp/69183] ICE when using OpenMP PRIVATE keyword in OMP DO loop not explicitly encapsulated in OMP PARALLEL region

[iain.miller at ecmwf dot int]

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

--- Comment #2 from Iain Miller  ---
On further testing and investigation the ICE only appears when attempting to
allocate and use ZHOFX.

Removing all references to ZHOFX in the test case allows it the subroutine to
compile.

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Can you please post the output of gcc -v so we know the configure options

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[civil.over at gmail dot com]

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

--- Comment #3 from Vladimir Smirnov  ---
GCC 5.3:
katje ~ # gcc -v
Using built-in specs.
COLLECT_GCC=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/5.3.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/5.3.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /var/tmp/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/configure
--host=armv7a-hardfloat-linux-gnueabi --build=armv7a-hardfloat-linux-gnueabi
--prefix=/usr --bindir=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/5.3.0
--includedir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.3.0/include
--datadir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/5.3.0
--mandir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/5.3.0/man
--infodir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/5.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.3.0/include/g++-v5
--with-python-dir=/share/gcc-data/armv7a-hardfloat-linux-gnueabi/5.3.0/python
--enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.3.0 p1.0, pie-0.6.5' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point
--with-float=hard --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
--disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp
--disable-libcilkrts --enable-lto --with-isl --disable-isl-version-check
--enable-libsanitizer
Thread model: posix
gcc version 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5)


GCC 6.0-snapshot:
katje ~ # gcc-6.0.0-alpha20160103 -v
Using built-in specs.
COLLECT_GCC=gcc-6.0.0-alpha20160103
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0-alpha20160103/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with:
/var/tmp/portage/sys-devel/gcc-6.0.0_alpha20160103/work/gcc-6-20160103/configure
--host=armv7a-hardfloat-linux-gnueabi --build=armv7a-hardfloat-linux-gnueabi
--prefix=/usr
--bindir=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/6.0.0-alpha20160103
--includedir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0-alpha20160103/include
--datadir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/6.0.0-alpha20160103
--mandir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/6.0.0-alpha20160103/man
--infodir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabi/6.0.0-alpha20160103/info
--with-gxx-include-dir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0-alpha20160103/include/g++-v6
--with-python-dir=/share/gcc-data/armv7a-hardfloat-linux-gnueabi/6.0.0-alpha20160103/python
--enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 6.0.0_alpha20160103' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point
--with-float=hard --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
--disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp
--disable-libcilkrts --enable-lto --with-isl --disable-isl-version-check
--enable-libsanitizer --disable-default-pie --enable-default-ssp
Thread model: posix
gcc version 6.0.0-alpha20160103 20160103 (experimental) (Gentoo
6.0.0_alpha20160103)

[Bug middle-end/69156] [6 Regression] gcc.dg/pr59630.c: ICE: verify_gimple failed: non-trivial conversion at assignment with -fno-tree-ccp

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Created attachment 37266 [details]
> > gcc6-pr69156.patch
> > 
> > Untested fix.  Not sure if it is the best spot though.  And the testcase is
> > really nasty.
> 
> Hmm, but this means things were mismatched in the first place (earlier) and
> thus this should be checked somewhere else?

This happens in gimple-match-head.c:
714   tree decl = TREE_OPERAND (fn, 0);
715   if (DECL_BUILT_IN_CLASS (decl) != BUILT_IN_NORMAL
716   || !gimple_builtin_call_types_compatible_p (stmt,
decl))
717 return false;
and the problem is that gimple_builtin_call_types_compatible_p is extremely
lose (basically, for return type or arguments considers all integral types
equal, or all pointer types equal, or all RECORD_TYPEs equal etc.).
Bet for this purpose (but don't about all the others) it might be better to
check useless_type_conversion_p equality instead.
I guess the question is when is a mere validate_type instead of
types_compatible_p useful.

[Bug c/69197] New: Can't compile older

[bogdan-megamen at yandex dot ru]

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

Bug ID: 69197
   Summary: Can't compile older
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bogdan-megamen at yandex dot ru
  Target Milestone: ---

I can't compile gcc 2.95.I need this gcc.Lubuntu 15.10 x32.Full compile log:
root@bogdan-desktop:/home/bogdan/gcc-2.95# make bootstrap
make[1]: Entering directory '/home/bogdan/gcc-2.95/libiberty'
make[2]: Entering directory '/home/bogdan/gcc-2.95/libiberty/testsuite'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/bogdan/gcc-2.95/libiberty/testsuite'
make[1]: Leaving directory '/home/bogdan/gcc-2.95/libiberty'
make[1]: Entering directory '/home/bogdan/gcc-2.95/texinfo'
make all-recursive
make[2]: Entering directory '/home/bogdan/gcc-2.95/texinfo'
Making all in intl
make[3]: Entering directory '/home/bogdan/gcc-2.95/texinfo/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/bogdan/gcc-2.95/texinfo/intl'
Making all in lib
make[3]: Entering directory '/home/bogdan/gcc-2.95/texinfo/lib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/bogdan/gcc-2.95/texinfo/lib'
Making all in makeinfo
make[3]: Entering directory '/home/bogdan/gcc-2.95/texinfo/makeinfo'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/bogdan/gcc-2.95/texinfo/makeinfo'
make[2]: Leaving directory '/home/bogdan/gcc-2.95/texinfo'
make[1]: Leaving directory '/home/bogdan/gcc-2.95/texinfo'
Bootstrapping the compiler
make[1]: Entering directory '/home/bogdan/gcc-2.95/gcc'
make CC="cc" libdir=/usr/local/lib LANGUAGES="c "
make[2]: Entering directory '/home/bogdan/gcc-2.95/gcc'
(cd intl && make all)
make[3]: Entering directory '/home/bogdan/gcc-2.95/gcc/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/bogdan/gcc-2.95/gcc/intl'
cc  -DIN_GCC -g  -DHAVE_CONFIG_H  -o cc1 toplev.o version.o tree.o
print-tree.o stor-layout.o fold-const.o function.o stmt.o except.o expr.o
calls.o expmed.o explow.o optabs.o intl.o varasm.o rtl.o print-rtl.o rtlanal.o
emit-rtl.o genrtl.o real.o dbxout.o sdbout.o dwarfout.o dwarf2out.o xcoffout.o
bitmap.o alias.o gcse.o integrate.o jump.o cse.o loop.o unroll.o flow.o
stupid.o combine.o varray.o regclass.o regmove.o local-alloc.o global.o
reload.o reload1.o caller-save.o insn-peep.o reorg.o sched.o final.o recog.o
reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o
lcm.o profile.o insn-attrtab.o i386.o getpwd.o  convert.o mbchar.o dyn-string.o
splay-tree.o graph.o sbitmap.o resource.o hash.o c-parse.o c-lang.o c-lex.o
c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o 
obstack.o../libiberty/libiberty.a
c-lex.o: In function `init_lex':
/home/bogdan/gcc-2.95/gcc/c-lex.c:284: undefined reference to
`is_reserved_word'
/home/bogdan/gcc-2.95/gcc/c-lex.c:288: undefined reference to
`is_reserved_word'
/home/bogdan/gcc-2.95/gcc/c-lex.c:289: undefined reference to
`is_reserved_word'
/home/bogdan/gcc-2.95/gcc/c-lex.c:290: undefined reference to
`is_reserved_word'
/home/bogdan/gcc-2.95/gcc/c-lex.c:291: undefined reference to
`is_reserved_word'
c-lex.o:/home/bogdan/gcc-2.95/gcc/c-lex.c:292: more undefined references to
`is_reserved_word' follow
collect2: error: ld returned 1 exit status
Makefile:2304: recipe for target 'cc1' failed
make[2]: *** [cc1] Error 1
make[2]: Leaving directory '/home/bogdan/gcc-2.95/gcc'
Makefile:4331: recipe for target 'bootstrap' failed
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory '/home/bogdan/gcc-2.95/gcc'
Makefile:1490: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2
root@bogdan-desktop:/home/bogdan/gcc-2.95# make ccv
make: *** No rule to make target 'ccv'.  Stop.
root@bogdan-desktop:/home/bogdan/gcc-2.95# make cc
make: *** No rule to make target 'cc'.  Stop.
root@bogdan-desktop:/home/bogdan/gcc-2.95# make cc1
make: *** No rule to make target 'cc1'.  Stop.
root@bogdan-desktop:/home/bogdan/gcc-2.95#

[Bug ipa/68419] ICE segfault in determine_locally_known_aggregate_parts / ipa_compute_jump_functions_for_edge

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Sorry, but I still cannot reproduce it.  I have checkout out the
latest gcc_5-branch (rev 232044) and configured it (on an
x86_64-linux) with

../src/configure --prefix=/home/mjambor/gcc/5/m68k/ --target=m68k-elf
--enable-languages=c --enable-checking=release --disable-bootstrap
--disable-libssp --disable-tls --enable-threads=single

Then I build the compiler simply with make (which fails afterwards
because it cannot build libgcc without other cross m68k tools but I do
get cc1).  Then I run cc1 on the provided example:

~/gcc/5/cross/gcc/cc1 -O2 unwind-dw2.i -g -auxbase-strip unwind-dw2.o
-g -O2 -fbuilding-libgcc -fno-stack-protector -fexceptions
-fvisibility=hidden -quiet

and I get only warnings, no ICE.  Can you please try to find any
difference in between my setup and yours which makes the issue
non-reproducible for me?  Thanks.

[Bug target/69198] New: [6 Regression] FAIL: gcc.target/i386/avx512vl-vmovaps-1.c scan-assembler-times vmovaps[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[ \\t]+#) 1

[hjl.tools at gmail dot com]

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

Bug ID: 69198
   Summary: [6 Regression] FAIL:
gcc.target/i386/avx512vl-vmovaps-1.c
scan-assembler-times vmovaps[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[
\\t]+#) 1
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com
  Target Milestone: ---
Target: x86

r231275 gave:

FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx512vl-vmovaps-1.c scan-assembler-times vmovaps[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx512vl-vmovaps-1.c scan-assembler-times vmovaps[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[ \\t]+#) 1

r231267 is OK.

[Bug target/69198] [6 Regression] FAIL: gcc.target/i386/avx512vl-vmovaps-1.c scan-assembler-times vmovaps[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[ \\t]+#) 1

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-08
 CC||ienkovich at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It may be caused by r231269.

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
I haven't looked at the bug, but on PowerPC systems before power8, the
following is illegal:

(insn 258 153 259 8 (set (reg:DI 9 9)
(reg/f:DI 63 31 [orig:185 p3$_M_node ] [185])) pr67211.C:28 540
{*movdi_internal64}
 (nil))

That is because register 9 is a GPR register and register 63 is a FPR register.
 Power8 systems in 64-bit mode have the ability to move values between GPRs and
FPRs/VSX registers, but earlier systems don't.  In order to transfer stuff
between the two register sets, you would need to do a store and a load.  Power8
32-bit (big endian only) would need scratch registers and multiple instructions
to transfer 64-bit values.

[Bug c++/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
Looking at calls to linemap_compare_locations, the crucial comparison is the
comparison of the location of the 2nd diagnostic with that of the "ignore"
pragma:

Breakpoint 2, linemap_compare_locations (set=0x77ffb000, pre=226930,
post=post@entry=2147483645)
at ../../src/libcpp/line-map.c:1311

(gdb) call inform (226930, "pre, the location of the ignore")
/tmp/test.cc:17:24: note: pre, the location of the ignore
 MACRO;
^  
(gdb) call inform (2147483645, "post, the location of the diagnostic")
/tmp/test.cc:13:9: note: post, the location of the diagnostic
 int x;
 ^
/tmp/test.cc:17:5: note: in expansion of macro ‘MACRO’
 MACRO;
 ^

The initial value of l1 == post (location of the diagnostic):
(gdb) p /x l1
$15 = 0x7ffd

linemap_compare_locations expands macro locations at LRK_MACRO_EXPANSION_POINT
and obtains:

(gdb) p l1
$19 = 226308

(gdb) call inform (226308, "")
/tmp/test.cc:17:5: note: 
 MACRO;
 ^

and hence treats the location of "post" (the diagnostic) as the "M" of the
macro expansion point.

However, the location of the "ignore" within the macro definition is 226930,
which is *after* that "M":

(gdb) call inform (226930, "pre, the location of the ignore")
/tmp/test.cc:17:24: note: pre, the location of the ignore
 MACRO;
^  

Hence that strange-looking synthesized location of the "ignore" directive
within the tokens synthesized by _cpp_do__Pragma is effectively *after* that of
the macro expansion point.   Hence the "ignore" is treated as occurring after
the diagnostic, hence the "ignore" doesn't affect the diagnostic, and the
warning is emitted.

FWIW, there's also some logic in linemap_compare_locations for handling
locations in the same macro expansion, but this isn't the case here as the
location of the pragma has been recorded as an ordinary location.