[Bug tree-optimization/69666] [5/6 Regression] gcc ICE at -O2 and -O3 on valid code on x86_64-linux-gnu in "verify_gimple failed"

[helloqirun at gmail dot com]

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

--- Comment #5 from Qirun Zhang  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Qirun Zhang from comment #3)
> > (In reply to Jakub Jelinek from comment #2)
> > > This invalid VCE is created by SRA.  The code has multiple undefined
> > > behaviors in it, but we shouldn't ICE on that.
> > 
> > Hi Jakub,
> > 
> > This code example is reduced from a file from ghostscript. Therefore, I
> > assume the original test case should not have any undefined behavior. If
> > helpful, I can attach the original pre-processed file which triggers the
> > same ICE.
> 
> Why do you think ghostscript doesn't have undefined behavior in it?
> Anyway, the bugs are both store of e[16] (only &e[16] is valid, but not
> dereferencing it), and memcpy of 16 characters to c which has only sizeof
> (int) (usually 4) characters.

Ah.. I forgot that I have modified that file. Please ignore my previous
message.

[Bug target/69667] New: [6 Regression] ppc64le -mlra: ICE: Max. number of generated reload insns per insn is achieved (90)

[trippels at gcc dot gnu.org]

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

Bug ID: 69667
   Summary: [6 Regression] ppc64le -mlra: ICE: Max. number of
generated reload insns per insn is achieved (90)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---
Target: p

Running the boost testsuite with -mlra shows:

trippels@gcc2-power8 status % cat test_nc_beta.ii
struct A {
  typedef int evaluation_error_type;
};
template  T get_epsilon();
template  __attribute__((__noreturn__)) void throw_exception(E);
template  char do_format(Formatter, Group &);
int raise_error_e, non_central_beta_p_k;
template  void raise_error(T &p1) {
  char msg = do_format(msg, p1);
  throw_exception(raise_error_e);
}
char raise_evaluation_error_function;
template 
T1 gamma_p_derivative(T1, T2, Policy);
template  T ibeta_imp(Policy, bool, T *);
template  struct B {};
template  B complement(Dist, RealType);
template  class C;
template  struct D {
  D(C p1, T, bool) : dist(p1) {}
  void operator()(T p1) { comp ? cdf(complement(dist, p1)) : T(); }
  C dist;
  bool comp;
};
template  class C {
public:
  C(int, int, int);
};
template  void quantile(Policy p1, RealType) {
  nc_beta_quantile(p1, false);
}
double quantile_sanity_check___trans_tmp_1,
quantile_sanity_check___trans_tmp_3,
quantile_sanity_check___trans_tmp_5, quantile_sanity_check___trans_tmp_7;
void Trans_NS_detail_raise_evaluation_error(char *, char *, long double &p3,
int) {
  raise_error(p3);
}
template 
void raise_evaluation_error(char *, T &p2, Policy) {
  Trans_NS_detail_raise_evaluation_error(
  &raise_evaluation_error_function, "", p2,
  typename Policy::evaluation_error_type());
}
template 
T non_central_beta_p(T p1, T p2, T p3, Policy p4, T p5 = 0) {
  T y, errtol = get_epsilon(), l2,
   pois = gamma_p_derivative(T(), l2, p4), xterm, last_term = 0;
  if (pois)
return p5;
  T beta = y ? ibeta_imp(p4, false, &xterm) : ibeta_imp(p4, true, &xterm);
  xterm = y - 1;
  T sum = p5;
  if (beta && xterm)
return p5;
  for (; non_central_beta_p_k;) {
sum += beta;
if (errtol && last_term || beta)
  break;
xterm *=
p1 + non_central_beta_p_k - 1 / p3 * p1 + p2 + non_central_beta_p_k -
2;
last_term = beta;
  }
  raise_evaluation_error("", sum, p4);
}
template 
RealType non_central_beta_cdf(RealType, bool, Policy) {
  RealType b, a, x;
  non_central_beta_p(a, b, x, A());
}
template 
int bracket_and_solve_root_01(F p1, T, bool, Tol, unsigned, Policy) {
  T guess;
  p1(guess);
}
template 
void nc_beta_quantile(C, bool p2) {
  RealType p;
  typedef RealType value_type;
  D f(C(0, 0, 0), p, p2);
  void tol();
  long max_iter =
  bracket_and_solve_root_01(f, value_type(), true, tol, max_iter,
Policy());
}
template  RealType cdf(B>) {
  RealType l = non_central_beta_cdf(l, true, Policy());
}
template  void quantile_sanity_check(T) {
  quantile(C(quantile_sanity_check___trans_tmp_1,
  quantile_sanity_check___trans_tmp_3,
  quantile_sanity_check___trans_tmp_5),
   quantile_sanity_check___trans_tmp_7);
}
void test_accuracy() {
  int ncbeta;
  quantile_sanity_check(ncbeta);
}

trippels@gcc2-power8 status % ~/gcc_5/usr/local/bin/g++ -O2 -std=c++14 -mlra -w
-c test_nc_beta.ii
trippels@gcc2-power8 status % ~/gcc_6/usr/local/bin/g++ -O2 -std=c++14 -w -c
test_nc_beta.ii
trippels@gcc2-power8 status % ~/gcc_6/usr/local/bin/g++ -O2 -std=c++14 -mlra -w
-c test_nc_beta.ii
test_nc_beta.ii: In function ‘T non_central_beta_p(T, T, T, Policy, T) [with T
= long double; Policy = A]’:
test_nc_beta.ii:64:1: internal compiler error: Max. number of generated reload
insns per insn is achieved (90)

[Bug fortran/69668] New: Error reading namelist opened with DELIM='NONE'

[phil1691 at gmail dot com]

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

Bug ID: 69668
   Summary: Error reading namelist opened with DELIM='NONE'
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phil1691 at gmail dot com
  Target Milestone: ---

When reading a namelist opened with DELIM='NONE' and filling an array, the
content of the file is not read correctly.

Example:
program namelist
  implicit none

  integer,parameter :: tabsz=10
  integer :: i,ilu
  character(len=10),dimension(tabsz) :: tab
  namelist/tab_nml/tab

  tab(:)='invalid'

  open(unit=ilu,file="data.nml",delim='NONE')
  READ(UNIT=ilu,NML=tab_nml)
  close(unit=ilu)

  do i=1,tabsz
print *,'i=',i,' tab(i)=***',tab(i),'***'
  end do

end program namelist

with the following namelist (data.nml file):
&tab_nml
  tab(1)='in1',
  tab(2)='in2'
/

The output is:
> ./a.out 
 i=   1  tab(i)=***in1   ***
 i=   2  tab(i)=***tab(2)='in***
 i=   3  tab(i)=***2'***
 i=   4  tab(i)=***invalid   ***
 i=   5  tab(i)=***invalid   ***
 i=   6  tab(i)=***invalid   ***
 i=   7  tab(i)=***invalid   ***
 i=   8  tab(i)=***invalid   ***
 i=   9  tab(i)=***invalid   ***
 i=  10  tab(i)=***invalid   ***

This problem appears with GCC 5.3.0 and also 5.2.0.

If DELIM is set to 'APOSTROPHE' or 'QUOTE', the code works as expected.
The fortran standards (95, 2003, 2008) say about the DELIM option: "This mode
has no effect on input".

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[amodra at gmail dot com]

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

--- Comment #13 from Alan Modra  ---
Note that testcases with smaller atomic ops fail too, but at runtime.  For
example:

struct foo { char pad; char x[4]; } a;

int
bar (int val)
{
  int ret;
  __atomic_exchange (&a.x, &val, &ret, 5);
  return  ret;
}

int main ()
{
  return bar (42);
}

Fails with a bus error.

[Bug c++/69657] [6 Regression] abs() not inlined after including math.h

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #9 from Jakub Jelinek  ---
If there is in #c3 extern "C" int abs(int); before the using foo::abs;, it
works fine.
The problem is during do_toplevel_using_decl (and likely other spots in
name-lookup.c) - do_nonmember_using_decl throws away the DECL_ANTICIPATED
olddecls:
2586  /* It is impossible to overload a built-in function; any explicit
2587 declaration eliminates the built-in declaration.  So, if OLDVAL
2588 is a built-in, then we can just pretend it isn't there.  */
2589  if (oldval
2590  && TREE_CODE (oldval) == FUNCTION_DECL
2591  && DECL_ANTICIPATED (oldval)
2592  && !DECL_HIDDEN_FRIEND_P (oldval))
and do_toplevel_using_decl then overwrites the binding->value with an OVERLOAD
that doesn't contain the builtin.
Perhaps we should keep the cxx_binding with ->value of DECL_ANTICIPATED
FUNCTION_DECL around, but hide it with another binding if the new OVERLOAD or
value is not builtin, and then when pushing extern "C" decls look if we don't
have a DECL_ANTICIPATED decl in some earlier binding of the same scope, and if
yes, duplicate_decls that decl with the anticipated one or something similar.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #39 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  4 09:02:01 2016
New Revision: 233128

URL: https://gcc.gnu.org/viewcvs?rev=233128&root=gcc&view=rev
Log:
PR target/69454
* config/i386/i386.c (convert_scalars_to_vector): Remove
stack alignment fixes.
(ix86_option_override_internal): Disable TARGET_STV if stack
might not be aligned enough.
(ix86_minimum_alignment): Assert that TARGET_STV is false.

* gcc.target/i386/pr69454-1.c: New test.
* gcc.target/i386/pr69454-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69454-1.c
trunk/gcc/testsuite/gcc.target/i386/pr69454-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69282] [6 Regression] aarch64/armhf ICE on SPEC2006 464.h264ref at -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Any progress on this P1?  Has the #c6 patch been submitted to gcc-patches?
Does that fix the issue, or shall in addition to that tree-vect-generic.c be
modified to use the new gimple-fold.c (gimple_build) APIs?

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to Bernd Schmidt from comment #5)
> > Yeah, my current theory is that r87 is spilled at the start, then the spill
> > reg is inherited in all the existing uses of it, and lra thinks it can avoid
> > storing it to memory.
> > 
> > Then we add a new reference to it for the pinsrw insn, and that isn't
> > initialized.
> > 
> > I seem to recall that this is a general problem with the idea of using a
> > pseudo for the PIC register, so surely there must have been some attempt to
> > address this when x86 was converted. So far I can't find anything though.
> > Uroš - any pointers?
> 
> Let's ask Ilya.

We had multiple register allocation issues related to pseudo PIC register and
initial commit (r216154) has related fixes in LRA by Vladimir Makarov.  IIRC
all problems were related to wrong PIC register used for rematerialization.  I
don't remember any case with uninitialized stack slot usage.

[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> Tested -flto-partition=.
> 
> fails:
> - balanced
> - 1to1
> 
> passes:
> - max
> - none
> - one

Same with -fno-use-linker-plugin.

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #8 from Uroš Bizjak  ---
(In reply to Ilya Enkovich from comment #7)

> We had multiple register allocation issues related to pseudo PIC register
> and initial commit (r216154) has related fixes in LRA by Vladimir Makarov. 
> IIRC all problems were related to wrong PIC register used for
> rematerialization.  I don't remember any case with uninitialized stack slot
> usage.

Forgot to add Vladimir to the discussion...

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
   Target Milestone|--- |5.4
 Ever confirmed|0   |1

--- Comment #9 from Uroš Bizjak  ---
Confirmed

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:50:12 2016
New Revision: 233130

URL: https://gcc.gnu.org/viewcvs?rev=233130&root=gcc&view=rev
Log:
[ARM] PR target/65932: stop changing signedness in PROMOTE_MODE

2016-02-04  Jim Wilson  

PR target/65932
PR target/67714
* config/arm/arm.h (PROMOTE_MODE): Don't set UNSIGNEDP for QImode and
HImode.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.h

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[ktkachov at gcc dot gnu.org]

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

--- Comment #25 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:50:12 2016
New Revision: 233130

URL: https://gcc.gnu.org/viewcvs?rev=233130&root=gcc&view=rev
Log:
[ARM] PR target/65932: stop changing signedness in PROMOTE_MODE

2016-02-04  Jim Wilson  

PR target/65932
PR target/67714
* config/arm/arm.h (PROMOTE_MODE): Don't set UNSIGNEDP for QImode and
HImode.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.h

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

--- Comment #14 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:51:35 2016
New Revision: 233131

URL: https://gcc.gnu.org/viewcvs?rev=233131&root=gcc&view=rev
Log:
[ARM][1/4] PR target/65932: Add testcase

PR target/65932
PR target/67714
* gcc.c-torture/execute/pr67714.c: New test.

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

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[ktkachov at gcc dot gnu.org]

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

--- Comment #26 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:51:35 2016
New Revision: 233131

URL: https://gcc.gnu.org/viewcvs?rev=233131&root=gcc&view=rev
Log:
[ARM][1/4] PR target/65932: Add testcase

PR target/65932
PR target/67714
* gcc.c-torture/execute/pr67714.c: New test.

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

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[ktkachov at gcc dot gnu.org]

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

--- Comment #27 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:54:37 2016
New Revision: 233132

URL: https://gcc.gnu.org/viewcvs?rev=233132&root=gcc&view=rev
Log:
[ARM][2/4] Fix operand costing logic for SMUL[TB][TB]

PR target/65932
PR target/67714
* config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract
the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

--- Comment #15 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:54:37 2016
New Revision: 233132

URL: https://gcc.gnu.org/viewcvs?rev=233132&root=gcc&view=rev
Log:
[ARM][2/4] Fix operand costing logic for SMUL[TB][TB]

PR target/65932
PR target/67714
* config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract
the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

--- Comment #16 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:56:13 2016
New Revision: 233133

URL: https://gcc.gnu.org/viewcvs?rev=233133&root=gcc&view=rev
Log:
[cse][3/4] Don't overwrite original rtx when folding source of set

PR target/65932
PR target/67714
* cse.c (cse_insn): Pass NULL to fold_rtx when initially
folding the source of a SET.

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

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[ktkachov at gcc dot gnu.org]

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

--- Comment #28 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:56:13 2016
New Revision: 233133

URL: https://gcc.gnu.org/viewcvs?rev=233133&root=gcc&view=rev
Log:
[cse][3/4] Don't overwrite original rtx when folding source of set

PR target/65932
PR target/67714
* cse.c (cse_insn): Pass NULL to fold_rtx when initially
folding the source of a SET.

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

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[ktkachov at gcc dot gnu.org]

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

--- Comment #29 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:57:36 2016
New Revision: 233134

URL: https://gcc.gnu.org/viewcvs?rev=233134&root=gcc&view=rev
Log:
[ARM][4/4] Adjust gcc.target/arm/wmul-[123].c tests

PR target/65932
PR target/67714
* gcc.target/arm/wmul-3.c: Simplify test to generate just
a single smulbb instruction.
* gcc.target/amr/wmul-1.c: Add -mtune=cortex-a9 to dg-options.
* gcc.target/amr/wmul-2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/wmul-1.c
trunk/gcc/testsuite/gcc.target/arm/wmul-2.c
trunk/gcc/testsuite/gcc.target/arm/wmul-3.c

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

--- Comment #17 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Feb  4 09:57:36 2016
New Revision: 233134

URL: https://gcc.gnu.org/viewcvs?rev=233134&root=gcc&view=rev
Log:
[ARM][4/4] Adjust gcc.target/arm/wmul-[123].c tests

PR target/65932
PR target/67714
* gcc.target/arm/wmul-3.c: Simplify test to generate just
a single smulbb instruction.
* gcc.target/amr/wmul-1.c: Add -mtune=cortex-a9 to dg-options.
* gcc.target/amr/wmul-2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/wmul-1.c
trunk/gcc/testsuite/gcc.target/arm/wmul-2.c
trunk/gcc/testsuite/gcc.target/arm/wmul-3.c

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #18 from ktkachov at gcc dot gnu.org ---
Fixed on trunk.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[ktkachov at gcc dot gnu.org]

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

--- Comment #30 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 6.
I've asked for a backport to GCC 5 and if approved I'll do it after it had a
bit of time to bake on trunk.

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Seems get_ref_base_and_extent already has code for some cases of the flexible
array members, but it has apparently some dead code in it that wasn't really
meant to be dead (hint, this check is after a while (1) { switch (TREE_CODE
(exp)) { ... } exp = TREE_OPERAND (exp, 0); } loop, thus break inside of the
switch does not terminate the loop and the only way to get out of the loop is
then goto done;, but that bypasses the stmt):

--- gcc/tree-dfa.c.jj   2016-01-21 08:58:44.0 +0100
+++ gcc/tree-dfa.c  2016-02-04 11:18:40.061621702 +0100
@@ -588,6 +588,7 @@ get_ref_base_and_extent (tree exp, HOST_
   exp = TREE_OPERAND (exp, 0);
 }

+ done:
   /* We need to deal with variable arrays ending structures.  */
   if (seen_variable_array_ref
   && maxsize != -1
@@ -597,7 +598,6 @@ get_ref_base_and_extent (tree exp, HOST_
  == wi::to_offset (TYPE_SIZE (TREE_TYPE (exp))
 maxsize = -1;

- done:
   if (!wi::fits_shwi_p (bitsize) || wi::neg_p (bitsize))
 {
   *poffset = 0;

But I guess even this doesn't help, while it will help poor man's flexible
array members in C/C++, in this Fortran case the problem is that there is
COMMON /FMCOM/ X(1)
in this TU, while
COMMON /FMCOM / X(100)
in some other TU, and get_ref_base_and_extent caps maxsize at DECL_SIZE -
bit_offset (which is generally right, but Fortran COMMON is just weird).
So, perhaps we want some flag on the Fortran COMMON decls that would be set on
COMMON that ends with an array and would tell get_ref_base_and_extent (and
other spots?) that accesses can be beyond end of the decl?

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> But I guess even this doesn't help, while it will help poor man's flexible
> array members in C/C++, in this Fortran case the problem is that there is
> COMMON /FMCOM/ X(1)
> in this TU, while
> COMMON /FMCOM / X(100)
> in some other TU, and get_ref_base_and_extent caps maxsize at
> DECL_SIZE - bit_offset (which is generally right, but Fortran COMMON
> is just weird).

This invalid Fortran.

> So, perhaps we want some flag on the Fortran COMMON decls that would be
> set on COMMON that ends with an array and would tell get_ref_base_and_extent
> (and other spots?) that accesses can be beyond end of the decl?

Related to/ duplicate of pr44882?

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Note the dead code is there since r204391.  Perhaps we need goto done; vs. goto
done2;, so that for MEM_REF/TARGET_MEM_REF we bypass this check?

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Dominique d'Humieres from comment #14)
> > But I guess even this doesn't help, while it will help poor man's flexible
> > array members in C/C++, in this Fortran case the problem is that there is
> > COMMON /FMCOM/ X(1)
> > in this TU, while
> > COMMON /FMCOM / X(100)
> > in some other TU, and get_ref_base_and_extent caps maxsize at
> > DECL_SIZE - bit_offset (which is generally right, but Fortran COMMON
> > is just weird).
> 
> This invalid Fortran.

Yes, but this is SPEC2k6, so we need some workaround or workaround option or
something for that I'm afraid.

> > So, perhaps we want some flag on the Fortran COMMON decls that would be
> > set on COMMON that ends with an array and would tell get_ref_base_and_extent
> > (and other spots?) that accesses can be beyond end of the decl?
> 
> Related to/ duplicate of pr44882?

[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
I recognize most of the code your patch strips, because I initially
wrote/modified it to get the deferred length character arrays working. I am
somewhat unconvinced that removing them is safe.

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Dominique d'Humieres from comment #14)
> > > But I guess even this doesn't help, while it will help poor man's flexible
> > > array members in C/C++, in this Fortran case the problem is that there is
> > > COMMON /FMCOM/ X(1)
> > > in this TU, while
> > > COMMON /FMCOM / X(100)
> > > in some other TU, and get_ref_base_and_extent caps maxsize at
> > > DECL_SIZE - bit_offset (which is generally right, but Fortran COMMON
> > > is just weird).
> > 
> > This invalid Fortran.
> 
> Yes, but this is SPEC2k6, so we need some workaround or workaround option or
> something for that I'm afraid.

No, tonto had this same crap and we required patching it.  That said, all
users of get_ref_base_and_extent are effected here (SRA, FRE, PRE, DSE),
so this isn't sth new - it's just that now we catch this as well after
loop opts did enough massaging to the IL to expose it.

> > > So, perhaps we want some flag on the Fortran COMMON decls that would be
> > > set on COMMON that ends with an array and would tell 
> > > get_ref_base_and_extent
> > > (and other spots?) that accesses can be beyond end of the decl?
> > 
> > Related to/ duplicate of pr44882?

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #13)
> Seems get_ref_base_and_extent already has code for some cases of the
> flexible array members, but it has apparently some dead code in it that
> wasn't really meant to be dead (hint, this check is after a while (1) {
> switch (TREE_CODE (exp)) { ... } exp = TREE_OPERAND (exp, 0); } loop, thus
> break inside of the switch does not terminate the loop and the only way to
> get out of the loop is then goto done;, but that bypasses the stmt):
> 
> --- gcc/tree-dfa.c.jj 2016-01-21 08:58:44.0 +0100
> +++ gcc/tree-dfa.c2016-02-04 11:18:40.061621702 +0100
> @@ -588,6 +588,7 @@ get_ref_base_and_extent (tree exp, HOST_
>exp = TREE_OPERAND (exp, 0);
>  }
>  
> + done:
>/* We need to deal with variable arrays ending structures.  */
>if (seen_variable_array_ref
>&& maxsize != -1
> @@ -597,7 +598,6 @@ get_ref_base_and_extent (tree exp, HOST_
> == wi::to_offset (TYPE_SIZE (TREE_TYPE (exp))
>  maxsize = -1;
>  
> - done:
>if (!wi::fits_shwi_p (bitsize) || wi::neg_p (bitsize))
>  {
>*poffset = 0;
> 
> But I guess even this doesn't help, while it will help poor man's flexible
> array members in C/C++,

get_ref_base_and_extent is supposed to properly detect trailing arrays in
case the size cannot be adjusted by the underlying decls size.  You don't
mention which goto done you think is broken here, the only relvant one is
that from the [TARGET_]MEM_REF case which sets maxsize to -1 itself.

I don't remember what the seen_variable_array_ref case after the while (1)
loop body was for.

Care to build a C testcase that goes wrong and that your patch would fix?

> in this Fortran case the problem is that there is
> COMMON /FMCOM/ X(1)
> in this TU, while
> COMMON /FMCOM / X(100)
> in some other TU, and get_ref_base_and_extent caps maxsize at DECL_SIZE -
> bit_offset (which is generally right, but Fortran COMMON is just weird).
> So, perhaps we want some flag on the Fortran COMMON decls that would be set
> on COMMON that ends with an array and would tell get_ref_base_and_extent
> (and other spots?) that accesses can be beyond end of the decl?

We certainly don't want to do that, it will pessimize all code that wants
max_size != -1 for commons.

[Bug target/69146] [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #5 from Alan Modra  ---
This is actually a dup of pr69644, and Jakub's patch for gcc-6 fixes this bug
on gcc-5 and gcc-4.9.  I didn't verify the claim that 4.9.3 works, but did
check that the current 4.9 branch fails.

In reply to comment #4, yes, mis-alignment will cause failures, but that isn't
what is happening with the testcases here.

[Bug fortran/69646] multiple warnings with -Wintrinsics-std

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug sanitizer/69276] Address sanitizer does not handle heap overflow

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Feb  4 11:50:40 2016
New Revision: 233137

URL: https://gcc.gnu.org/viewcvs?rev=233137&root=gcc&view=rev
Log:
Fix PR sanitizer/69276

* g++.dg/asan/pr69276.C: New test.
PR sanitizer/PR69276
* asan.c (has_stmt_been_instrumented_p): Instrument gimple calls
that are gimple_store_p.
(maybe_instrument_call): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr69276.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P4
  Component|tree-optimization   |fortran

--- Comment #19 from Jakub Jelinek  ---
Ok, so after discussions on IRC, I'm going to just remove the unreachable code
from get_ref_base_and_extent, and the conclusion is that this is a 416.gamess
bug.  If the Fortran folks want to provide a workaround on the Fortran FE side,
it is possible, otherwise let's close this as INVALID.

[Bug lto/69630] [6 Regression] LTO ICE in types_same_for_odr at ipa-devirt.c:402

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

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

Program received signal SIGSEGV, Segmentation fault.
0x00a8c195 in types_same_for_odr (type1=0x0, type2=0x76a722a0, 
strict=false) at /space/rguenther/src/svn/trunk3/gcc/ipa-devirt.c:402
402   gcc_checking_assert (TYPE_P (type1) && TYPE_P (type2));

from

3200  && types_same_for_odr (DECL_CONTEXT
(nodes[0]->decl),
3201 outer_type->type))

we get __cxa_pure_virtual for nodes[0]->decl.

[Bug target/69634] [6 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fschedule-insns -fno-tree-vrp @ i686

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/69639] [6 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #2 from Richard Biener  ---
I think this is "known" to be an issue, so did you confirm the required stack
space grow or so?  And whether that's target specific?

[Bug fortran/69654] ICE in gfc_trans_structure_assign

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug middle-end/69643] Address space discarded

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
  Component|c   |middle-end
Version|unknown |6.0
 Ever confirmed|0   |1

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

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug sanitizer/69276] Address sanitizer does not handle heap overflow

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed in trunk.

[Bug tree-optimization/69653] More CSE opportunities in address expressions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
We've talked about lowering memory references somewhere on GIMPLE.  The issue
is always failing dependence queries and forcing decls to be addressable
(causing
the same issue).

But I don't think it was backed up with real numbers if done reasonably late
(read: after loop opts but before the final DOM which would do some CSE).

If you look at gimple-laddress.c you can see how lowering can be easily
achieved (if you have some followup cleanup passes).

For each not already lowered address do

 1) take its address and lower it the laddress way
 2) create a new reference based on dereferencing that pointer

You might want to restrict yourself to non-invariant "pieces", thus for example
lower a.b.c[j].d[3].e as

  void *p = &a.b.c[j]; // lowered
  ... = MEM [p].d[3].e;

because for the non-constant part we're not very smart anyway (after loop
opts).

The requirement to mark 'a' as TREE_ADDRESSABLE might still be the killer
though.

Which leaves us with the question why RTL optimizers don't do their job.

[Bug c/69669] New: ICE with enum __attribute__((mode(QI)))

[bernd.edlinger at hotmail dot de]

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

Bug ID: 69669
   Summary: ICE with enum __attribute__((mode(QI)))
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

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

Hi,

the attached program gives ICE with gcc-6 trunk:

gcc -O2 small.c
small.c: In function 'OpcUa_UpdateDataDetails_Decode':
small.c:21:18: internal compiler error: in decompose, at wide-int.h:897
 OpcUa_StatusCode OpcUa_UpdateDataDetails_Decode(
  ^~
0xd5c99e wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int
> const&)
../../gcc-6-20160131/gcc/wide-int.h:897
0xd5c99e
wide_int_ref_storage::wide_int_ref_storage
> >(generic_wide_int > const&, unsigned int)
../../gcc-6-20160131/gcc/wide-int.h:945
0xd5c99e generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc-6-20160131/gcc/wide-int.h:722
0xd5c99e trailing_wide_int_storage&
trailing_wide_int_storage::operator=
> >(generic_wide_int > const&)
../../gcc-6-20160131/gcc/wide-int.h:1345
0xd5c99e generic_wide_int&
generic_wide_int::operator=
> >(generic_wide_int > const&)
../../gcc-6-20160131/gcc/wide-int.h:850
0xd5c99e void
range_info_def::set_min >
>(generic_wide_int > const&)
../../gcc-6-20160131/gcc/tree-ssanames.h:52
0xd5c99e set_range_info(tree_node*, value_range_type,
generic_wide_int > const&,
generic_wide_int > const&)
../../gcc-6-20160131/gcc/tree-ssanames.c:341
0xdcbbf3 vrp_finalize
../../gcc-6-20160131/gcc/tree-vrp.c:10250
0xdcbbf3 execute_vrp
../../gcc-6-20160131/gcc/tree-vrp.c:10350
0xdcbbf3 execute
../../gcc-6-20160131/gcc/tree-vrp.c:10435
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug preprocessor/69664] [6 Regression] column info is lost

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
 Ever confirmed|0   |1

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

[Bug target/69639] [6 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
(In reply to Markus Trippelsdorf from comment #1)
> # Overhead  Command  Shared Object  Symbol
>  4.48%  cc1plus  cc1plus[.] bitmap_set_bit
>  2.34%  cc1plus  cc1plus[.] bitmap_clear_bit
>  1.48%  cc1plus  cc1plus[.] record_operand_costs
>  1.37%  cc1plus  cc1plus[.] bitmap_bit_p
>  1.23%  cc1plus  cc1plus[.] gt_ggc_mx_lang_tree_node
>  1.11%  cc1plus  cc1plus[.] run_fast_df_dce
>  1.09%  cc1plus  cc1plus[.] df_note_compute
>  0.98%  cc1plus  cc1plus[.] df_insn_refs_collect

Pretty generic, so - callers?  It also uses quite some more memory for me (>2GB
with GCC 5).

[Bug fortran/69659] [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |6.0

[Bug c/69661] missing -Wsequence-point warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/69667] [6 Regression] ppc64le -mlra: ICE: Max. number of generated reload insns per insn is achieved (90)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/69666] [5/6 Regression] gcc ICE at -O2 and -O3 on valid code on x86_64-linux-gnu in "verify_gimple failed"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/69659] [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
 CC||vehre at gcc dot gnu.org
  Known to work||5.3.0
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #2 from Dominique d'Humieres  ---
Confirmed. This occurred between revisions r222352 (2015-04-23, compiles) and
r222398 (2015-04-24, ICE), likely r222361 (pr60322).

[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> Yeah,
> (insn 12 11 13 (set (reg:DI 85)
> (lshiftrt:DI (subreg:DI (reg/v:OI 79 [ v32u128_1 ]) 0)
> (const_int 1 [0x1]))) pr69613-3.c:19 -1
>  (nil))
> and similar shifts by 1 look just weird when the TImode shift is with
> variable shift count.

Those shifts are ok. They are generated by expand_subword_shift in optabs.c as
part of expand_doubleword_shift.

The problem is that TARGET_SHIFT_TRUNCATION_MASK for aarch64 returns 63 for
word_mode even when SHIFT_COUNT_TRUNCATED is false.
I'll test and post a fix

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > # Overhead  Command  Shared Object  Symbol
> >  4.48%  cc1plus  cc1plus[.] bitmap_set_bit
> >  2.34%  cc1plus  cc1plus[.] bitmap_clear_bit
> >  1.48%  cc1plus  cc1plus[.] record_operand_costs
> >  1.37%  cc1plus  cc1plus[.] bitmap_bit_p
> >  1.23%  cc1plus  cc1plus[.] gt_ggc_mx_lang_tree_node
> >  1.11%  cc1plus  cc1plus[.] run_fast_df_dce
> >  1.09%  cc1plus  cc1plus[.] df_note_compute
> >  0.98%  cc1plus  cc1plus[.] df_insn_refs_collect
> 
> Pretty generic, so - callers?  It also uses quite some more memory for me
> (>2GB
> with GCC 5).

from

 TOTAL :  42.09 2.2744.41   
1101751 kB

to

 df live regs:  17.87 ( 7%) usr   0.04 ( 1%) sys  17.50 ( 7%) wall 
 0 kB ( 0%) ggc
 combiner:  17.08 ( 7%) usr   0.11 ( 2%) sys  17.21 ( 7%) wall 
252066 kB ( 4%) ggc
 integrated RA   :  20.29 ( 8%) usr   0.09 ( 2%) sys  20.37 ( 8%) wall 
480341 kB ( 8%) ggc
 scheduling 2:  11.12 ( 5%) usr   0.04 ( 1%) sys  11.16 ( 5%) wall 
 12347 kB ( 0%) ggc
 TOTAL : 239.77 5.48   245.33   
5807892 kB
Timing error: total of phase timers exceeds total time.
user2.3978000296e+02 > 2.3977000102e+02
wall2.45349996274710e+02 > 2.4533745058e+02
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,

[Bug fortran/62536] ICE (segfault) for invalid END BLOCK statement

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
I am currently testing the following patch to eventually mitigate the issue
somewhat by forcing all "registers" to have non-qualified type (their
qualification does not matter nor does their alignment).  The create_tmp_reg
hunk is more risky (in case we have bogus callers ending up forcing the
result to memory).

It will hide the PRE bug (well, still if the user wrote a 64bit aligned
type and a 32bit aligned type PRE might change one for the other - in
fact it will even end up using a 32bit aligned type if the code consistently
uses 64bit aligned types).

But as said earlier, the GCC implemented ABI is simply seriously broken
if you consider the user can control "alignment" of (register-typed) values.

Index: gcc/gimple-expr.c
===
--- gcc/gimple-expr.c   (revision 233136)
+++ gcc/gimple-expr.c   (working copy)
@@ -484,9 +484,8 @@ create_tmp_var (tree type, const char *p
 tree
 create_tmp_reg (tree type, const char *prefix)
 {
-  tree tmp;
-
-  tmp = create_tmp_var (type, prefix);
+  gcc_assert (is_gimple_reg_type (type));
+  tree tmp = create_tmp_var (TYPE_MAIN_VARIANT (type), prefix);
   if (TREE_CODE (type) == COMPLEX_TYPE
   || TREE_CODE (type) == VECTOR_TYPE)
 DECL_GIMPLE_REG_P (tmp) = 1;
Index: gcc/tree-ssanames.c
===
--- gcc/tree-ssanames.c (revision 233136)
+++ gcc/tree-ssanames.c (working copy)
@@ -286,7 +286,7 @@ make_ssa_name_fn (struct function *fn, t

   if (TYPE_P (var))
 {
-  TREE_TYPE (t) = var;
+  TREE_TYPE (t) = TYPE_MAIN_VARIANT (var);
   SET_SSA_NAME_VAR_OR_IDENTIFIER (t, NULL_TREE);
 }
   else

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Created attachment 37577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37577&action=edit
-ftime-report -c -fsanitize=undefined -O2

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
Created attachment 37578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37578&action=edit
-ftime-report -c -O2 gen_emitter_test.ii

[Bug tree-optimization/69669] [5/6 Regression] ICE with enum __attribute__((mode(QI)))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
  Component|c   |tree-optimization
   Target Milestone|--- |5.4
Summary|ICE with enum   |[5/6 Regression] ICE with
   |__attribute__((mode(QI)))   |enum
   ||__attribute__((mode(QI)))
 Ever confirmed|0   |1

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

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to Richard Biener from comment #14)
> I am currently testing the following patch to eventually mitigate the issue
> somewhat by forcing all "registers" to have non-qualified type (their
> qualification does not matter nor does their alignment).  The create_tmp_reg
> hunk is more risky (in case we have bogus callers ending up forcing the
> result to memory).
> 
> It will hide the PRE bug (well, still if the user wrote a 64bit aligned
> type and a 32bit aligned type PRE might change one for the other - in
> fact it will even end up using a 32bit aligned type if the code consistently
> uses 64bit aligned types).
> 
> But as said earlier, the GCC implemented ABI is simply seriously broken
> if you consider the user can control "alignment" of (register-typed) values.
> 
> Index: gcc/gimple-expr.c
> ===
> --- gcc/gimple-expr.c   (revision 233136)
> +++ gcc/gimple-expr.c   (working copy)
> @@ -484,9 +484,8 @@ create_tmp_var (tree type, const char *p
>  tree
>  create_tmp_reg (tree type, const char *prefix)
>  {
> -  tree tmp;
> -
> -  tmp = create_tmp_var (type, prefix);
> +  gcc_assert (is_gimple_reg_type (type));
> +  tree tmp = create_tmp_var (TYPE_MAIN_VARIANT (type), prefix);
>if (TREE_CODE (type) == COMPLEX_TYPE
>|| TREE_CODE (type) == VECTOR_TYPE)
>  DECL_GIMPLE_REG_P (tmp) = 1;

Ok, the assert doesn't go well here.  The PRE issue should be mitigated
by the tree-ssanames.c hunk already.  Re-testing with a different above
variant.

> Index: gcc/tree-ssanames.c
> ===
> --- gcc/tree-ssanames.c (revision 233136)
> +++ gcc/tree-ssanames.c (working copy)
> @@ -286,7 +286,7 @@ make_ssa_name_fn (struct function *fn, t
>  
>if (TYPE_P (var))
>  {
> -  TREE_TYPE (t) = var;
> +  TREE_TYPE (t) = TYPE_MAIN_VARIANT (var);
>SET_SSA_NAME_VAR_OR_IDENTIFIER (t, NULL_TREE);
>  }
>else

[Bug target/69146] [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #6 from Alan Modra  ---
Jakub's patch now regression tested powerpc64le-linux for gcc-4.9 and gcc-5.

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.8.5
   Keywords||wrong-code
   Last reconfirmed||2016-02-04
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Error reading namelist  |[4.9/5/6 Regression] Error
   |opened with DELIM='NONE'|reading namelist opened
   ||with DELIM='NONE'
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk, it "works" with 4.8.5. The change occurred
between revisions r208241 (2014-03-01, works) and r208311 (2014-03-04, fails),
likely r208302 (pr60148).

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #6 from Bernd Schmidt  ---
pass_sanopt adds huge amounts of code, so to some degree I think this is
expected. Do gcc and clang do exactly the same checks with
-fsanitize=undefined?

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug rtl-optimization/64081] [5/6 Regression] r217827 prevents RTL loop unroll

[dje at gcc dot gnu.org]

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

--- Comment #24 from David Edelsohn  ---
The most recent patch did not cause bootstrap failure for AIX.

[Bug fortran/69636] ICE(s) on using option -fmodule-private

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> Placing statement "private" explicit in source, reducing a bit,
> then compiling without "-fmodule-private" :

Even simpler

character(1,char_t) function test1()
  test1 = 'A'
end function test1

function_kinds_3_red.f90:1:12:

 character(1,char_t) function test1()
1
Error: Parameter 'char_t' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
f951: internal compiler error: Segmentation fault: 11

"-fmodule-private" triggers errors for used names not marked as PUBLIC, some
errors in turn may have a recovery problem, hence trigger an ICE.

[Bug c++/69658] [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
On this testcase, we used to call reshape_init already before, it is called
from
  else
{
  init = reshape_init (type, init, tf_warning_or_error);
  flags |= LOOKUP_NO_NARROWING;
}
in check_initializer, and a few lines below this it calls
init_code = build_aggr_init_full_exprs (decl, init, flags);
that down the line calls expand_default_init and calls reshape_init again,
which is wrong from what I can understand, reshape_init should be called just
once.
On the other hand, on the mem-init-aggr1.C testcase, reshape_init has not been
called before, and thus it probably needs to be called.

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
The problematic symbol:

(gdb) p node->debug()
_ZN2JS3ubi20PreComputedEdgeRangeD2Ev/73127 (__base_dtor ) @0x75666e60
  Type: function definition analyzed
  Visibility: prevailing_def_ironly artificial
  Aux: @0x2a89e30  References: 
  Referring: 
  Read from file: Unified_cpp_js_src35.o
  Availability: local
  First run: 0
  Function flags: local merged_comdat unlikely_executed
  Called by: 
  Calls:

[Bug c++/69658] [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Just a shot in the dark:
--- gcc/cp/init.c.jj2016-01-29 12:12:46.0 +0100
+++ gcc/cp/init.c   2016-02-04 14:49:15.383997315 +0100
@@ -1636,16 +1636,15 @@ expand_default_init (tree binfo, tree tr
   gcc_checking_assert ((flags & LOOKUP_ONLYCONVERTING) == 0
   && TREE_CHAIN (init) == NULL_TREE);
   init = TREE_VALUE (init);
+  if (BRACE_ENCLOSED_INITIALIZER_P (init) && CP_AGGREGATE_TYPE_P (type))
+   init = reshape_init (type, init, complain);
 }

   if (init && BRACE_ENCLOSED_INITIALIZER_P (init)
   && CP_AGGREGATE_TYPE_P (type))
 /* A brace-enclosed initializer for an aggregate.  In C++0x this can
happen for direct-initialization, too.  */
-{
-  init = reshape_init (type, init, complain);
-  init = digest_init (type, init, complain);
-}
+init = digest_init (type, init, complain);

   /* A CONSTRUCTOR of the target's type is a previously digested
  initializer, whether that happened just above or in

will call reshape_init on mem-init-aggr1.C where we want it and not on this new
testcase where we've already done that and don't want to do that again.
But whether it is the right fix, no idea.

[Bug target/69644] ICE with -O on __sync_bool_compare_and_swap with short in extract_insn, at recog.c:2286

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  4 13:58:21 2016
New Revision: 233138

URL: https://gcc.gnu.org/viewcvs?rev=233138&root=gcc&view=rev
Log:
Backported from mainline
2016-02-03  Jakub Jelinek  

PR target/69644
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Force oldval into register if it does not satisfy reg_or_short_operand
predicate.  Fix up formatting.

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

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr69644.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/69644] ICE with -O on __sync_bool_compare_and_swap with short in extract_insn, at recog.c:2286

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  4 13:59:27 2016
New Revision: 233139

URL: https://gcc.gnu.org/viewcvs?rev=233139&root=gcc&view=rev
Log:
Backported from mainline
2016-02-03  Jakub Jelinek  

PR target/69644
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Force oldval into register if it does not satisfy reg_or_short_operand
predicate.  Fix up formatting.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr69644.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
>From correspondence with Uli Weigand, it appears that the code is valid even
with misaligned data, but a locking implementation is needed.  I haven't
checked whether other targets succeed here; that would be interesting to know.

[Bug c++/69670] New: Useless -Wenum-compare when comparing parallel enums in static_assert

[wipedout at yandex dot ru]

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

Bug ID: 69670
   Summary: Useless -Wenum-compare when comparing parallel enums
in static_assert
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wipedout at yandex dot ru
  Target Milestone: ---

I'm trying this on http://gcc.godbolt.org/ the version is "x86 gcc 5.3.0", the
options line is "-O3 -Wall -std=c++11" The code is as follows:

enum One {
  One_Magic
};

enum Two {
  Two_Magic
};

void test()
{
  static_assert( One_Magic == Two_Magic, "");
}

I get "warning: comparison between 'enum One' and 'enum Two' [-Wenum-compare]"
which is completely useless. The intent is to check that two parallel enum
elements have identical values. If they have identical values - the user is
happy, no problem. If they don't have identical values then static_assert fails
and this is impossible to ignore.

Same goes for pre-c++11 implementations of "static assert" (one is with an
array typedef and the other is with a template and a specialization thereof).

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

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 69671
   Summary: [6 Regression] FAIL:
gcc.target/i386/avx512vl-vpmovqb-1.c
scan-assembler-times vpmovqb[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
CC: kyrylo.tkachov at arm dot com
  Target Milestone: ---
Target: x86_64-none-linux-gnu

Starts with r233133:

PASS->FAIL: gcc.target/i386/avx512vl-vpmovdb-1.c scan-assembler-times vpmovdb[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovdb-1.c scan-assembler-times vpmovdb[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovdb-1.c scan-assembler-times vpmovdb[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovdb-1.c scan-assembler-times vpmovdb[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqw-1.c scan-assembler-times vpmovqw[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqw-1.c scan-assembler-times vpmovqw[
\\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqw-1.c scan-assembler-times vpmovqw[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovqw-1.c scan-assembler-times vpmovqw[
\\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsdb-1.c scan-assembler-times
vpmovsdb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsdb-1.c scan-assembler-times
vpmovsdb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsdb-1.c scan-assembler-times
vpmovsdb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsdb-1.c scan-assembler-times
vpmovsdb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqb-1.c scan-assembler-times
vpmovsqb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqb-1.c scan-assembler-times
vpmovsqb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqb-1.c scan-assembler-times
vpmovsqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqb-1.c scan-assembler-times
vpmovsqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqw-1.c scan-assembler-times
vpmovsqw[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqw-1.c scan-assembler-times
vpmovsqw[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqw-1.c scan-assembler-times
vpmovsqw[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovsqw-1.c scan-assembler-times
vpmovsqw[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusdb-1.c scan-assembler-times
vpmovusdb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusdb-1.c scan-assembler-times
vpmovusdb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusdb-1.c scan-assembler-times
vpmovusdb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusdb-1.c scan-assembler-times
vpmovusdb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusqb-1.c scan-assembler-times
vpmovusqb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusqb-1.c scan-assembler-times
vpmovusqb[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusqb-1.c scan-assembler-times
vpmovusqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusqb-1.c scan-assembler-times
vpmovusqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
PASS->FAIL: gcc.target/i386/avx512vl-vpmovusqw-1.c scan-assembler-times

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-04
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
More or less the same, there can be differences though.
Anyway, sanopt pass indeed will add huge amount of basic blocks (for every
thing that needs to be sanitized some condition check, and conditional call);
before sanopt we intentionally keep it many of the most common checks in the
form of internal calls without the need for extra basic blocks.

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Andreas, if this is complete, please move to RESOLVED/FIXED state.  Thanks!

[Bug target/69274] [6 Regression] 435.gromacs performance regression after r231814 on x86 Haswell and bdver2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I'd say the patch can make a difference for when

  if (!TEST_BIT (preferred, nalt)
  || TEST_HARD_REG_BIT (alts, nalt))
continue;

hit before.  But I can't see any preferred_for_* pattern in i386 that also has
a '%' constraint ...

So it must be (somehow) to the "already processed" TEST_HARD_REG_BIT test, but
I can't imagine how.

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[bernds at gcc dot gnu.org]

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

--- Comment #10 from Bernd Schmidt  ---
A slightly hackish attempt to solve it, by not removing stores to the PIC
register. As far as I can tell we now end up with an unnecessary store to
memory, which is better than an uninitialized load I guess. Haven't yet looked
at what that does to code quality for other code; I'm not massively optimistic.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 232689)
+++ lra-constraints.c   (working copy)
@@ -5127,8 +5127,10 @@ update_ebb_live_info (rtx_insn *head, rt
   curr_id = lra_get_insn_recog_data (curr_insn);
   curr_static_id = curr_id->insn_static_data;
   remove_p = false;
-  if ((set = single_set (curr_insn)) != NULL_RTX && REG_P (SET_DEST (set))
+  if ((set = single_set (curr_insn)) != NULL_RTX
+ && REG_P (SET_DEST (set))
  && (regno = REGNO (SET_DEST (set))) >= FIRST_PSEUDO_REGISTER
+ && SET_DEST (set) != pic_offset_table_rtx
  && bitmap_bit_p (&check_only_regs, regno)
  && ! bitmap_bit_p (&live_regs, regno))
remove_p = true;

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Looking at the RTL dumps before the patch in cse1 we had:
(insn 27 26 28 2 (set (reg:V16QI 138)
(const_vector:V16QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])) {*movv16qi_internal}
 (nil))

(insn 30 29 31 2 (set (reg:V16QI 136)
(vec_concat:V16QI (vec_merge:V4QI (truncate:V4QI (reg:V4SI 137 [ x.4_10
]))
(vec_select:V4QI (const_vector:V16QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
]))
(subreg:QI (reg:SI 139 [ m.5_11 ]) 0))
(const_vector:V12QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
]))) {avx512vl_truncatev4siv4qi2_mask}
 (expr_list:REG_DEAD (reg:SI 140 [ m.5_11 ])
(expr_list:REG_DEAD (reg:V16QI 138)
(expr_list:REG_DEAD (reg:V4SI 137 [ x.4_10 ])
(nil)

but after the patch the const_vector is CSE'd into:
(insn 27 26 28 2 (set (reg:V16QI 138)
(const_vector:V16QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
]))
/work/kyrtka01/local-checkouts/build-x86/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/avx512vlintrin.h:1491
1214 {*movv16qi_internal}
 (nil))
(insn 28 27 29 2 (set (reg:SI 139 [ m.5_11 ])
(zero_extend:SI (reg:QI 94 [ m.5_11 ]))) avx.c:21 136
{*zero_extendqisi2}
 (expr_list:REG_DEAD (reg:QI 94 [ m.5_11 ])
(nil)))
(insn 29 28 30 2 (set (reg:SI 140 [ m.5_11 ])
(reg:SI 139 [ m.5_11 ]))
/work/kyrtka01/local-checkouts/build-x86/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/avx512vlintrin.h:1491
86 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 139 [ m.5_11 ])
(nil)))
(insn 30 29 31 2 (set (reg:V16QI 136)
(vec_concat:V16QI (vec_merge:V4QI (truncate:V4QI (reg:V4SI 137 [ x.4_10
]))
(vec_select:V4QI (reg:V16QI 138)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
]))
(subreg:QI (reg:SI 139 [ m.5_11 ]) 0))
(const_vector:V12QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Using unoptimized checking compilers, I get the same compile time for -O2
-fsanitize=undefined for the 5 branchpoint and current trunk, so where is the
regression part?

[Bug c++/69672] Useless -Wenum-compare when comparing enum vaue against the same value in enum hack

[wipedout at yandex dot ru]

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

--- Comment #1 from wipedout at yandex dot ru ---
"distinct warnings" should be "distinct enums"

[Bug c++/69672] New: Useless -Wenum-compare when comparing enum vaue against the same value in enum hack

[wipedout at yandex dot ru]

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

Bug ID: 69672
   Summary: Useless -Wenum-compare when comparing enum vaue
against the same value in enum hack
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wipedout at yandex dot ru
  Target Milestone: ---

I'm trying this on http://gcc.godbolt.org/ the version is "x86 gcc 5.3.0", the
options line is "-O3 -Wall -std=c++11" The code is as follows:

#include 

enum Magic {
  One, Two, Three
};

class Base {
public:
  virtual Magic GetType() = 0;
};

class ClassOne : public Base {
public:
  enum {
MagicValue = One
  };
  Magic GetType() { return One; }
};

class ClassTwo : public Base {
public:
  enum {
MagicValue = Two
  };
  Magic GetType() { return Two; }
};

template

Target* Cast( Base* from)
{
  if( from->GetType() != Target::MagicValue )
throw new std::exception();
  return static_cast( from );
}

void test()
{
  ClassOne obj;
  Cast( &obj ); 
}

I get the following:

warning: comparison between 'enum Magic' and 'enum ClassOne::'
[-Wenum-compare]

Well, yes, these two are indeed distinct warnings but code uses so-called enum
hack to define a compile-time constant. The enum arising from the enum hack is
a strict subset of the original enum. There's no room for error here. The
warning is useless in this scenario.

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
grep call.*__ubsan_ gen_emitter_test.s | sort | uniq -c | sort -nr
  63814 call__ubsan_handle_type_mismatch
  49332 call__ubsan_handle_dynamic_type_cache_miss
637 call__ubsan_handle_nonnull_arg
100 call__ubsan_handle_load_invalid_value
 19 call__ubsan_handle_sub_overflow
 15 call__ubsan_handle_add_overflow

The clang++ I have around refuses to compile it, so can't compare the number of
instrumented spots with clang.

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> The code compiles with 4.8.5, 4.9.3, 5.2.0, and to trunk (6.0), but not
> with 4.8.2 or 4.9.0. The change occurred between revisions r215860
> (2014-10-03, error) and r216098 (2014-10-10, compiles).

Does someone care to add a test case? Otherwise this PR can be closed as FIXED.

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
CC'ing Kirill for AVX512 opinion

[Bug c++/69673] New: Can't pass members in lambda capture list

[petschy at gmail dot com]

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

Bug ID: 69673
   Summary: Can't pass members in lambda capture list
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

struct A
{
int i;
};

void foo(A& a)
{
auto l = [&a.i]() { };
}

void bar(A& a)
{
auto& i = a.i;
auto l = [&i]() { };
}

void baz()
{
A a;
auto l = [&a.i]() { };
}
---8<---8<---8<---

Only bar() compiles, the other two functions fail : 
g++-5.3.1 -std=c++11 20160204-lambda.cpp
error: expected ‘,’ before ‘.’ token
  auto l = [&a.i]() { };
  ^

Every gcc version I tried failed: 4.7.4, 4.8.4, 4.9.2, 5.3.1, 6.0.0

g++-5.3.1 -v
Using built-in specs.
COLLECT_GCC=g++-5.3.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.3.1 --with-build-config=my-bootstrap-O3-native
Thread model: posix
gcc version 5.3.1 20160204 (GCC)

Regards, Peter

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
So somewhat oldish trunk shows 30s -> 170s for me.  Nothing obvious in
-ftime-report.

Generated assembly is 82MB vs. 16MB so we're shoveling a lot more code through
the machinery and that's what we'd need to fix.

We instrument GIMPLE which means we might end up instrumenting a lot more than
clang.

We instrument quite early as well and we might not be very good in eliminating
instrumentation code as dead even in optimized.  I'm only aware on the overflow
IFNs being optimized.

Our instrumentation code might be big (too much inline?).

All not verified in any way.

A good start would be to try individual ubsan sanitizers to spot the "worst"
one
(I guess overflow or maybe null/alignment).

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Does clang++ even have objsize instrumentation?  Do we ever optimize those
calls?

[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
Jacub,

Thanks a lot for your detail comments!

I've just sent a patch for review to gcc-patches. Could you please
take a look on it?

Best regards.
Yuri.

2016-02-03 20:22 GMT+03:00 jakub at gcc dot gnu.org :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
>
> Jakub Jelinek  changed:
>
>What|Removed |Added
> 
>  CC|jakub at redhat dot com|
>
> --- Comment #3 from Jakub Jelinek  ---
> Clearly a bug in optimize_mask_stores.
> At the start of that function we have:
> ...
> mask__46.14_129 = vect__14.9_121 != vect__21.12_127;
> _46 = _14 != _21;
> mask__ifc__47.15_130 = mask__46.14_129;
> _ifc__47 = _46;
> MASK_STORE (vectp.16_132, 8B, mask__ifc__47.15_130, vect__22.13_128);
> vect__24.20_140 = MEM[(double *)vectp.18_138];
> _24 = *_13;
> vect__25.21_141 = vect__21.12_127 + vect__24.20_140;
> _25 = _21 + _24;
> MASK_STORE (vectp.22_145, 8B, mask__ifc__47.15_130, vect__25.21_141);
> k_27 = k_28 + 1;
> ...
> Now, the MASK_STORE calls are processed from last to first, which is fine, we
> first move the second MASK_STORE and the vector stmts that feed it:
> vect__24.20_140 = MEM[(double *)vectp.18_138];
> vect__25.21_141 = vect__21.12_127 + vect__24.20_140;
> MASK_STORE (vectp.22_145, 8B, mask__ifc__47.15_130, vect__25.21_141);
> but then continue trying to move the second MASK_STORE into the same
> conditional block, because it has the same mask.  In this case it is wrong,
> because there is
> the scalar load in between (_24 = *_13) that just waits for DCE, but generally
> there could be arbitrary code.
> /* Put other masked stores with the same mask to STORE_BB.  */
> if (worklist.is_empty ()
> || gimple_call_arg (worklist.last (), 2) != mask
> || worklist.last () != stmt1)
>   break;
> has a simplistic check (doesn't consider other MASK_STORE unless the walking
> walked up to that stmt), but of course it doesn't work too well if some scalar
> stmts were skipped.
>
> I see various issues in that function:
> 1) wrong formatting:
>   gsi_to = gsi_start_bb (store_bb);
>   if (dump_enabled_p ())
> {
>   dump_printf_loc (MSG_NOTE, vect_location,
>"Move stmt to created bb\n");
>   dump_gimple_stmt (MSG_NOTE, TDF_SLIM, last, 0);
> }
> /* Move all stored value producers if possible.  */
> while (!gsi_end_p (gsi))
>   {
> The Move all stored value and everything below up to corresponding closing }
> should be moved two columns to the left
> 2) IMHO stmt1 should be set to NULL before that while (!gsi_end_p (gsi)),
> as the function is prepared to handle multiple bbs
> 3) next to gimple_vdef non-NULL break IMHO should be also
> gimple_has_volatile_ops -> break check, just for safety, we don't wanto to
> mishandle say volatile reads etc.
> 4) you have to skip over debug stmts if there are any, otherwise we have a
> -fcompare-debug issue
> 5) IMHO you should give up also for !is_gimple_assign, say trying to move an
> elemental function call into the conditional is just wrong
> 6) the
> /* Skip scalar statements.  */
> if (!VECTOR_TYPE_P (TREE_TYPE (lhs)))
>   continue;
> should be reconsidered.  IMHO if you have scalar stmts that feed just the 
> stmts
> in the STORE_BB, there is no reason not to move them too, if you have scalar
> stmts that feed other stmts too, IMHO you should give up on them if they have 
> a
> vuse; what code did you have in mind when adding the !VECTOR_TYPE_P check?
> 7) FOR_EACH_IMM_USE_FAST loop should ignore debug stmts, at least for 
> decisions
> when to stop in some stmt; bet the debug stmts if there are any need to be
> reset
> if we move the def stmt that they are using, otherwise we risk -fcompare-debug
> issues
> 8) the worklist.last () != stmt1 check need to be -fcompare-debug friendly 
> too,
> so if there are debug stmts in between the last moved stmt and the previous
> MASK_STORE, we need to handle it as if there aren't any debug stmts in between
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.0

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
It's the --param max-dse-active-local-stores stuff, but the default value is
apparently not well suited to this testcase.

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[trippels at gcc dot gnu.org]

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

--- Comment #12 from Markus Trippelsdorf  ---
Hmm, today's clang takes over 11 minutes to compile the testcase with
-fsanitize=undefined.

The instrumented spots are fewer however:

  28856 callq   __ubsan_handle_type_mismatch
  22770 callq   __ubsan_handle_dynamic_type_cache_miss
 31 callq   __ubsan_handle_load_invalid_value
 11 callq   __ubsan_handle_add_overflow
  5 callq   __ubsan_handle_sub_overflow
  1 callq   __ubsan_handle_nonnull_arg

[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Created attachment 37579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37579&action=edit
Clear explicit function result variables for deferred length char arrays

Well, using the explicit result declaration of comment #3 the code is far less
optimized. Furthermore are the .__result and __result parameters in the code of
comment #3 not cleared in tree-original.

When I add this clearing by modifying trans-decl.c (gfc_trans_deferred_vars (),
see attached patch1.txt), i.e.,

__.003t.original:
test (character(kind=1)[1:*.__result] * & __result, integer(kind=4) *
.__result, integer(kind=4) & restrict alen)
{
  integer(kind=4) i;

  *.__result = 0;
  *__result = 0B;
...

then I get the same result, like in the original program. The question is, does
this information help us in any way?

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #20 from alalaw01 at gcc dot gnu.org ---
Hmmm, hang on. In unport.fppized.f, shouldn't we be using the 'F2C/GCC COMPILER
ON PC RUNNING UNIX (LINUX,BSD386,ETC)' version? In which case X has size (1)
everywhere?

[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -mavx and 128bit arithmetics since r215450

[rsandifo at gcc dot gnu.org]

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

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Feb  4 15:01:15 2016
New Revision: 233143

URL: https://gcc.gnu.org/viewcvs?rev=233143&root=gcc&view=rev
Log:
PR 69577: Invalid RA of destination subregs

In PR 69577 we have:

  A: (set (reg:V2TI X) ...)
  B: (set (subreg:TI (reg:V2TI X) 0) ...)

X gets allocated to an AVX register, as usual for V2TI.  The problem is
that the movti for B doesn't then preserve the other half of X, even
though the subreg semantics are supposed to guarantee that.

If instead the same value had been set by:

  A': (set (subreg:TI (reg:V2TI X) 16) ...)
  B: (set (subreg:TI (reg:V2TI X) 0) ...)

the subreg in A' would have prevented the use of AVX registers for X,
since you can't directly access the high part.

IMO these are really the same thing.  An alternative way to view it
is that the original sequence is equivalent to:

  A: (set (reg:V2TI X) ...)
  B1: (set (subreg:TI (reg:V2TI X) 0) ...)
  B2: (set (subreg:TI (reg:V2TI X) 16) (subreg:TI (reg:V2TI X) 16))

in which B2 is a no-op and therefore implicit.  The handling ought
to be the same regardless of whether there is an rtl insn that
explicitly assigns to (subreg:TI (reg:V2TI X) 16).

This patch implements that idea.  Hopefully the comments explain
what's going on.

Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf.

gcc/
PR rtl-optimization/69577
* reginfo.c (record_subregs_of_mode): Add a partial_def parameter.
(find_subregs_of_mode): Update accordingly.  Iterate over partial
definitions.

gcc/testsuite/
PR rtl-optimization/69577
* gcc.target/i386/pr69577.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69577.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reginfo.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
The node is added to reachable set in symbol_table::remove_unreachable_nodes
because of following condition is true:

  /* If any symbol in a comdat group is reachable, force
 all externally visible symbols in the same comdat
 group to be reachable as well.  Comdat-local symbols
 can be discarded if all uses were inlined.  */
  if (node->same_comdat_group)
{
  symtab_node *next;
  for (next = node->same_comdat_group;
   next != node;
   next = next->same_comdat_group)
if (!next->comdat_local_p ()
&& !reachable.add (next))
  enqueue_node (next, &first, &reachable);
}

Where node->debug():

(gdb) p node->debug()
_ZN2JS3ubi20PreComputedEdgeRangeD0Ev/73129 (__deleting_dtor ) @0x756702e0
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def_ironly public weak comdat
comdat_group:_ZN2JS3ubi20PreComputedEdgeRangeD5Ev one_only visibility_specified
visibility:hidden virtual artificial
  Same comdat group as: _ZN2JS3ubi20PreComputedEdgeRangeD2Ev/73127
  Address is taken.
  Aux: @0x75667000  References: 
  Referring: _ZTVN2JS3ubi20PreComputedEdgeRangeE/73125 (addr)
  Read from file: Unified_cpp_js_src35.o
  First run: 0
  Function flags: merged_comdat
  Called by: 
  Calls: _ZdlPvm/39897 (1.00 per call) 

I've been still reducing the test-case, currently the total size is about
5.5MB.

Martin

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On Thu, 4 Feb 2016, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #20 from alalaw01 at gcc dot gnu.org ---
> Hmmm, hang on. In unport.fppized.f, shouldn't we be using the 'F2C/GCC 
> COMPILER
> ON PC RUNNING UNIX (LINUX,BSD386,ETC)' version? In which case X has size (1)
> everywhere?

It's called DM elsewhere, just look for /FMCOM/ and compare its contents

[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
If I add back the candidate, ivopt can fix attached case, but it still can't
handle a slightly tuned case as below:

extern const int indexes[];

int bar (int code);

int
foo (short *data)
{
  register int i, j;

  j = 0;
  for (i = 1; i < 64; i++) {
if (data[indexes[i]]) {
  j++;
} else {
  if (bar (j))
return 0;
  j = 0;
  __asm__("":::"eax","ebx","ecx","edx","esi","edi","ebp");
}
  }

  return 1;
}

The only difference is change bar from a function definition to a declaration.

The cost computed in ivopt for pic related symbol-ref is different because of
issue described at : https://gcc.gnu.org/ml/gcc/2016-02/msg00040.html