[Bug fortran/71883] [5/6/7 Regression] ICE in identical_array_ref, at fortran/dependency.c:104

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #14 from Paul Thomas  ---
Fixed on 5-branch, 6-branch and trunk. Thanks for the report.

Steve and Thomas, thanks for the ready-to-roll fixes.

Paul

[Bug fortran/71883] [5/6/7 Regression] ICE in identical_array_ref, at fortran/dependency.c:104

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Fri Jul 29 05:16:05 2016
New Revision: 238848

URL: https://gcc.gnu.org/viewcvs?rev=238848=gcc=rev
Log:
2016-07-29  Steven G. Kargl  
Thomas Koenig  

PR fortran/71883
* frontend-passes.c (gfc_run_passes): Bail out if there are any
errors.
* error.c (gfc_internal_error): If there are any errors in the
buffer, exit with EXIT_FAILURE.

2016-07-29  Paul Thomas  

PR fortran/71883
* gfortran.dg/pr71883.f90 : New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr71883.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/error.c
branches/gcc-5-branch/gcc/fortran/frontend-passes.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

[cesar at gcc dot gnu.org]

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

--- Comment #1 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Fri Jul 29 04:20:00 2016
New Revision: 238847

URL: https://gcc.gnu.org/viewcvs?rev=238847=gcc=rev
Log:
PR fortran/72741
gcc/fortran/
* openmp.c (gfc_oacc_routine_dims): Move gfc_error to
gfc_match_oacc_routine.  Return OACC_FUNCTION_NONE on error.
(gfc_match_oacc_routine): Call gfc_oacc_routine_dims for all
routines directives.  Propagate error as appropriate.

gcc/testsuite/
* gfortran.dg/goacc/pr72741.f90: New test.


Added:
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/pr72741.f90
Modified:
branches/gomp-4_0-branch/gcc/fortran/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/fortran/openmp.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp

[Bug target/72749] New: [7 Regression] ICE: verify_flow_info failed (error: wrong amount of branch edges after conditional jump in bb 5) w/ -O2 -fsched2-use-superblocks

[asolokha at gmx dot com]

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

Bug ID: 72749
   Summary: [7 Regression] ICE: verify_flow_info failed (error:
wrong amount of branch edges after conditional jump in
bb 5) w/ -O2 -fsched2-use-superblocks
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20160724 fails to compile the following reduced testcase for
32-bit BE powerpc target w/ -O2 (-O3, -Ofast) -fsched2-use-superblocks
-mcpu=power7 (power8, powerpc64le):

int as;

void
ji (int *x4)
{
  if (0)
{
  unsigned int pv;

  while (as < 0)
{
  for (*x4 = 0; *x4 < 1; ++(*x4))
yj:
x4 = (int *)
  ++as;
}
}
  goto yj;
}

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20160724 -c -O2
-fsched2-use-superblocks dao4bxj1.c
(or
% powerpc-e500v2-linux-gnuspe-gcc-7.0.0-alpha20160724 -c -mcpu=power7 -Ofast
-fsched2-use-superblocks -w dao4bxj1.c)
dao4bxj1.c: In function 'ji':
dao4bxj1.c:19:1: error: wrong amount of branch edges after conditional jump in
bb 5
 }
 ^
dao4bxj1.c:19:1: internal compiler error: verify_flow_info failed

[Bug target/72748] New: ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952

[su at cs dot ucdavis.edu]

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

Bug ID: 72748
   Summary: ICE on valid code at -O2 and -O3 with -g enabled in
64-bit mode on x86_64-linux-gnu: in simplify_subreg,
at simplify-rtx.c:5952
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 with -g enabled on x86_64-linux-gnu in the 64-bit mode (but not in
the 32-bit mode). 

It is a regression from 6.1.x, and has the same crash message as PR 71549,
which has been fixed. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160728 (experimental) [trunk revision 238811] (GCC)
$
$ gcc-trunk -m64 -O2 -c small.c
$ gcc-6.1 -m64 -O2 -g -c small.c
$
$ gcc-trunk -m64 -O2 -g -c small.c
small.c: In function ‘fn1’:
small.c:24:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5952
 }
 ^
0xbb03d2 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
../../gcc-source-trunk/gcc/simplify-rtx.c:5951
0xbb0939 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
../../gcc-source-trunk/gcc/simplify-rtx.c:6178
0xeb83cb vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8429
0x7ebed9 cselib_expand_value_rtx_1
../../gcc-source-trunk/gcc/cselib.c:1648
0x7ed8be cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeb8853 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8324
0xeb8853 vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8486
0x7ebdf5 cselib_expand_value_rtx_1
../../gcc-source-trunk/gcc/cselib.c:1683
0x7ed8be cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeb8853 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8324
0xeb8853 vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8486
0x7ed8be cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeb8853 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8324
0xeb8853 vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8486
0x7ebdf5 cselib_expand_value_rtx_1
../../gcc-source-trunk/gcc/cselib.c:1683
0x7ed8be cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeb7439 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8324
0xeb7439 vt_expand_1pvar
../../gcc-source-trunk/gcc/var-tracking.c:8599
0xeb7439 emit_note_insn_var_location(variable**, emit_note_data*)
../../gcc-source-trunk/gcc/var-tracking.c:8654
0xeba4aa traverse_noresize<emit_note_data*, emit_note_insn_var_location>
../../gcc-source-trunk/gcc/hash-table.h:950
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


---


volatile int a;
int c, d, e, f, g, h;

int fn1 ()
{ 
  int i;
  for (; d;)
{ 
  if (e)
break;
  g = 0;
  int j[4];
  for (h = 0; h < 4; h++)
g++;
  for (; c < 2; c++)
{ 
  e = j[g];
  i = j[0];
  f = 4;
}
  f |= d;
}
  return a;
}

[Bug rtl-optimization/68217] Wrong constant folding

[kugan at gcc dot gnu.org]

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

--- Comment #4 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Fri Jul 29 00:35:23 2016
New Revision: 238846

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

2016-07-29  Kugan Vivekanandarajah  

PR middle-end/68217
* tree-vrp.c (extract_range_from_binary_expr_1): In case of signed
& sign-bit-CST, generate [-INF, 0] instead of [-INF, INF].


gcc/testsuite/ChangeLog:

2016-07-29  Kugan Vivekanandarajah  

PR middle-end/68217
* gcc.dg/pr68217.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68217.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug target/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target||powerpc64le-unknown-linux-g
   ||nu
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2016-07-29
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |5.4
  Known to fail||5.3.1, 6.1.1, 7.0

[Bug target/72747] New: powerpc: wrong code generated for vec_splats in cascading assignment

[wschmidt at gcc dot gnu.org]

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

Bug ID: 72747
   Summary: powerpc: wrong code generated for vec_splats in
cascading assignment
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

A statement such as "v = vec_splats (1);" correctly initializes a vector. 
However, a statement such as "v[1] = v[0] = vec_splats (1);" initializes both
v[1] and v[0] to random garbage.  The following code can be used to verify the
problem:

#include 
#include 
#include 

using std::cout;
using std::endl;

int main (int argc, char *argv[])
{
  int i, j;
  __vector short v1[2];

  v1[1] = v1[0] = vec_splats ((short) 1);

  for (i = 0; i < 2; ++i)
{
  cout << "v1[" << i << "]: ";
  for (j = 0; j < 8; ++j)
cout << v1[i][j] << " ";
  cout << endl;
}

  return EXIT_SUCCESS;
}

Probable cause is the special handling of vec_splats in rs6000-c.c during
parsing.  Compiled at -O0 with current trunk, the "optimized" dump shows:

  :
  _1 = v1[0];
  v1[1] = _1;

where v1[0] is uninitialized.

Reported on GCC 5.3.1, but confirmed to occur also in GCC 6.1 and current
trunk.

[Bug fortran/69964] ICE on misspelled end block data, in gfc_ascii_statement

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
This appears to be fixed on trunk.

[Bug fortran/71067] [4.9/5/6/7 Regression] ICE on data initialization with insufficient value

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|4.9.4   |7.0

--- Comment #10 from kargl at gcc dot gnu.org ---
fixed on trunk.

[Bug fortran/71067] [4.9/5/6/7 Regression] ICE on data initialization with insufficient value

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jul 28 23:12:23 2016
New Revision: 238842

URL: https://gcc.gnu.org/viewcvs?rev=238842=gcc=rev
Log:
2016-07-28  Steven G. Kargl  

PR fortran/71067
* decl.c (match_data_constant): On error, set 'result' to NULL.

2016-07-28  Steven G. Kargl  

PR fortran/71067
* gfortran.dg/pr71067_1.f90: New test.
* gfortran.dg/pr71067_2.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71067_1.f90
trunk/gcc/testsuite/gfortran.dg/pr71067_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/72103] ICE with gcc 7 for povray benchmark

[amodra at gmail dot com]

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

--- Comment #9 from Alan Modra  ---
I looked, and decided there wasn't much we could do.  So the main nastiness in
the sequence is the mem store/load, but that is just reload running out of regs
and spilling.  Yes, it looks really dumb when viewing the assembly but not so
obvious to fix in reload.

Also, I didn't show that there is a use of the int value (r9) later.  That
makes xvcvdpsxws, xvcvsxwdp not so good.

[Bug tree-optimization/72746] New: gcc ICE at -O2 and above on valid code on x86_64-linux-gnu with “seg fault”

[helloqirun at gmail dot com]

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

Bug ID: 72746
   Summary: gcc ICE at -O2 and above on valid code on
x86_64-linux-gnu with “seg fault”
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

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


It appears to be a 7 regression.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160728 (experimental) [trunk revision 238824] (GCC) 

$ gcc-trunk -O2 abc.c
abc.c: In function ‘fn1’:
abc.c:12:20: warning: division by zero [-Wdiv-by-zero]
   *d = a *= (c %= 0) > c + (f ? c : e);
^~
abc.c:17:9: warning: division by zero [-Wdiv-by-zero]
   f %= 0;
 ^~
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ cat abc.c
int a, b, f;
long c;
int *d;
unsigned long e;
void fn1 ()
{
  for (; f;)
{
  for (;;)
;
lblE83BAD08:
  *d = a *= (c %= 0) > c + (f ? c : e);
}
  if ((a = 0) || (a = b ? 8 : a))
{
  f = 3;
  f %= 0;
  goto lblE83BAD08;
}
}

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
> Confirmed as fortran FE bug.  The FE manages to set ".r" as fn spec attribute
> on save_cptr which specifies that its first argument does not escape.
> 
> It's trans-types.c:create_fn_spec that does this by doing
> 
>   for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
> if (spec_len < sizeof (spec))
>   {
> if (!f->sym || f->sym->attr.pointer || f->sym->attr.target
> || f->sym->attr.external || f->sym->attr.cray_pointer
> || (f->sym->ts.type == BT_DERIVED
> && (f->sym->ts.u.derived->attr.proc_pointer_comp
> || f->sym->ts.u.derived->attr.pointer_comp))
> || (f->sym->ts.type == BT_CLASS
> && (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
> || CLASS_DATA
> (f->sym)->ts.u.derived->attr.pointer_comp)))
>   spec[spec_len++] = '.';
> else if (f->sym->attr.intent == INTENT_IN)
>   spec[spec_len++] = 'r';
> else if (f->sym)
>   spec[spec_len++] = 'w';
>   }
> 
> and it looks like the side-effect of marking arguments as not escaping as
> soon
> as you specify anything else than . was overlooked.
> 
> Or Fortran really doesn't allow args to be stored away but has an exception
> for
> C binding types which needs handling above.

This patch works around the inability of a programmer
to type SAVE in the line 'integer(c_int), pointer :: a'.

I'm not convinced that gfortran cannot optimize away the
assignment 'a = 100' as 'a' is a local variable in 
subroutine init().  I can find nothing in the standard that
requires a compiler to assume that the return result from
c_loc() is cached somewhere.

I have no intentions to commit this patch.  It is recorded
here so that I can clean up my development tree.  If one thinks
about its ramifications, one should arrive at the conclusion
that the patch will cause a leak of memory.

Index: match.c
===
--- match.c (revision 237481)
+++ match.c (working copy)
@@ -1349,6 +1349,11 @@ gfc_match_assignment (void)

   gfc_set_sym_referenced (lvalue->symtree->n.sym);

+  if (lvalue->symtree->n.sym->attr.pointer == 1
+  && lvalue->symtree->n.sym->attr.referenced == 1
+  && lvalue->symtree->n.sym->attr.save == SAVE_NONE)
+lvalue->symtree->n.sym->attr.save = SAVE_IMPLICIT;
+
   new_st.op = EXEC_ASSIGN;
   new_st.expr1 = lvalue;
   new_st.expr2 = rvalue;

[Bug tree-optimization/49695] conditional moves for stores

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug c++/72457] [6/7 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Reduced:

template  struct box {
  Element value;
  constexpr box() : value{} {}
};
struct B: box { };
template box::box();

[Bug fortran/71883] [5/6/7 Regression] ICE in identical_array_ref, at fortran/dependency.c:104

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Author: pault
Date: Thu Jul 28 21:21:49 2016
New Revision: 238841

URL: https://gcc.gnu.org/viewcvs?rev=238841=gcc=rev
Log:
2016-07-28  Steven G. Kargl  
Thomas Koenig  

PR fortran/71883
* frontend-passes.c (gfc_run_passes): Bail out if there are any
errors.
* error.c (gfc_internal_error): If there are any errors in the
buffer, exit with EXIT_FAILURE.

2016-07-28  Paul Thomas  

PR fortran/71883
* gfortran.dg/pr71883.f90 : New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr71883.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/error.c
branches/gcc-6-branch/gcc/fortran/frontend-passes.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/72745] Please static assert in std::get to check out of range

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-28
 Ever confirmed|0   |1
   Severity|normal  |enhancement

[Bug libstdc++/72745] New: Please static assert in std::get to check out of range

[markus.ilmola at pp dot inet.fi]

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

Bug ID: 72745
   Summary: Please static assert in std::get to check out of range
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.ilmola at pp dot inet.fi
  Target Milestone: ---

Currently using an out of range tuple index with std::get will result in long
and confusing error message like:

"error: invalid use of incomplete type 'class std::tuple_element<0ul,
std::tuple<> >'"

See:
http://melpon.org/wandbox/permlink/q7L1cdFrdPQ8R3Bk

It would be easy to add a one line static assert to check the index to get a
better error message such as:

"error: tuple index out of range"

[Bug fortran/71799] [7 Regression] ICE in DO loop code emission (gfc_resolve_iterator)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|marxin at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
fixed.

[Bug c++/72457] [6/7 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/71799] [7 Regression] ICE in DO loop code emission (gfc_resolve_iterator)

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jul 28 19:04:12 2016
New Revision: 238830

URL: https://gcc.gnu.org/viewcvs?rev=238830=gcc=rev
Log:
2016-07-28  Steven G. Kargl  

PR fortran/71799
* resolve.c(gfc_resolve_iterator): Failure of type conversion need
not ICE.

2016-07-28  Steven G. Kargl  

PR fortran/71799
* gfortran.dg/pr71799.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71799.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71665] [4.9/5/6 Regression] ICE on invalid C++ code with non-integral constant enumerator value: in cxx_eval_constant_expression, at cp/constexpr.c:3918

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 Regression] ICE  |[4.9/5/6 Regression] ICE on
   |on invalid C++ code with|invalid C++ code with
   |non-integral constant   |non-integral constant
   |enumerator value: in|enumerator value: in
   |cxx_eval_constant_expressio |cxx_eval_constant_expressio
   |n, at cp/constexpr.c:3918   |n, at cp/constexpr.c:3918

--- Comment #5 from Paolo Carlini  ---
Fixed in mainline so far.

[Bug c++/71665] [4.9/5/6/7 Regression] ICE on invalid C++ code with non-integral constant enumerator value: in cxx_eval_constant_expression, at cp/constexpr.c:3918

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jul 28 18:43:29 2016
New Revision: 238828

URL: https://gcc.gnu.org/viewcvs?rev=238828=gcc=rev
Log:
/cp
2016-07-28  Paolo Carlini  

PR c++/71665
* decl.c (build_enumerator): Check the type of the enumerator before
calling cxx_constant_value.

/testsuite
2016-07-28  Paolo Carlini  

PR c++/71665
* g++.dg/cpp0x/pr71665-1.C: New.
* g++.dg/cpp0x/pr71665-2.C: Likewise.
* g++.dg/cpp0x/enum29.C: Adjust dg-error string.
* g++.dg/ext/label10.C: Likewise.
* g++.dg/parse/constant5.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr71665-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr71665-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/enum29.C
trunk/gcc/testsuite/g++.dg/ext/label10.C
trunk/gcc/testsuite/g++.dg/parse/constant5.C

[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #6 from kargl at gcc dot gnu.org ---
fixed.

[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jul 28 17:48:54 2016
New Revision: 238825

URL: https://gcc.gnu.org/viewcvs?rev=238825=gcc=rev
Log:
2016-07-28  Steven G. Kargl  

PR fortran/71859
* check.c(numeric_check): Prevent ICE.  Issue error for invalid
subroutine as an actual argument when numeric argument is expected.

2016-07-28  Steven G. Kargl  

PR fortran/71859
* gfortran.dg/pr71859.f90: New test.
* gfortran.dg/intrinsic_numeric_arg.f: Update error message.
* gfortran.dg/coarray_collectives_1.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71859.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_collectives_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_numeric_arg.f

[Bug fortran/72744] ICE in verify_ssa, at tree-ssa.c:1039

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

As known, case above works with "workshare" :


$ cat z2.f90
program p
   integer, parameter :: n = 20
   integer :: i, z(n), h(n)
   z = [(i, i=1,n)]
   h = [(i, i=n,1,-1)]
   call sub (n, h)
   if ( any(h/=z) ) call abort
end
subroutine sub (n, x)
   integer :: n, x(n)
!$omp parallel workshare
   x(:) = x(n:1:-1)
!$omp end parallel workshare
end


$ gfortran-7-20160724 -Ofast -fopenmp -fall-intrinsics z2.f90
$ a.out

[Bug fortran/72744] New: ICE in verify_ssa, at tree-ssa.c:1039

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 72744
   Summary: ICE in verify_ssa, at tree-ssa.c:1039
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Using -fopenmp together with -O2|-O3 and -fstack-arrays
or with -Ofast alone for a test similar to pr49792 and pr71687 
hits 7 and older (also related to pr69281).


$ cat z1.f90
program p
   integer, parameter :: n = 20
   integer :: i, z(n), h(n)
   z = [(i, i=1,n)]
   h = [(i, i=n,1,-1)]
   call sub (n, h)
   if ( any(h/=z) ) call abort
end
subroutine sub (n, x)
   integer :: n, x(n)
!$omp parallel
   x(:) = x(n:1:-1)
!$omp end parallel
end


$ gfortran-7-20160724 -Ofast -fopenmp -c z1.f90
z1.f90:8:0:

 end

Error: type mismatch between an SSA_NAME and its symbol
z1.f90:8:0: Error: type mismatch between an SSA_NAME and its symbol
while verifying SSA_NAME A.13_20 in statement
# .MEM_19 = VDEF <.MEM_9>
A.13_20 = __builtin_alloca_with_align (_18, 32);
z1.f90:8:0: internal compiler error: verify_ssa failed
0xe18a52 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1039
0xb43e7d execute_function_todo
../../gcc/passes.c:1971
0xb4469d do_per_function
../../gcc/passes.c:1655
0xb447eb execute_todo
../../gcc/passes.c:2016

[Bug c/71858] Surprising suggestions for misspellings

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #9 from David Malcolm  ---
(In reply to Marek Polacek from comment #8)
> Anything left to be done here?

Oops, sorry for leaving this open.  Marking as RESOLVED FIXED.

[Bug fortran/72743] New: ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 72743
   Summary: ICE in get_constraint_for_ssa_var, at
tree-ssa-structalias.c:2958
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Not with -O1, but with optimization level -Os, -O2 or higher.
Seen with 6 an 7.


$ cat z1.f90
program p
   integer, parameter :: n = 8
   integer :: i, z(n)
   z = [(i, i=1,n)]
   print *, z
end
subroutine s
   integer, parameter :: n = 8
   integer :: i, z(n)
   z = [(i, i=1,n)]
   print *, z
end


$ gfortran-7-20160724 -O2 -fopenacc z1.f90
z1.f90:12:0:

 end

internal compiler error: in get_constraint_for_ssa_var, at
tree-ssa-structalias.c:2958
0xde8325 get_constraint_for_ssa_var
../../gcc/tree-ssa-structalias.c:2955
0xde8456 get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3544
0xde8d72 get_constraint_for_address_of
../../gcc/tree-ssa-structalias.c:3367
0xde86aa get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3435
0xde93ed get_constraint_for_ptr_offset
../../gcc/tree-ssa-structalias.c:3099
0xde84f6 get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3450
0xdeb4c9 do_structure_copy
../../gcc/tree-ssa-structalias.c:3627
0xdeb4c9 find_func_aliases
../../gcc/tree-ssa-structalias.c:4771
0xdf2fb6 ipa_pta_execute
../../gcc/tree-ssa-structalias.c:7808

[Bug c/71858] Surprising suggestions for misspellings

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #8 from Marek Polacek  ---
Anything left to be done here?

[Bug c/71939] sole flexible array member in an anonymous structure rejected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
Closing thus.

[Bug c/71986] Bug bug when compiling gammu-1.37.3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Severity|critical|normal

[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

[w6ws at earthlink dot net]

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

Walter Spector  changed:

   What|Removed |Added

 CC||w6ws at earthlink dot net

--- Comment #16 from Walter Spector  ---
Adding myself to the cc list.

Jerry - Your example in Comment 14 needs a little touching up to be legal.
The read methods need to have the dtv argument as intent (in out).  Also the
unformatted methods do not have iotype or vlist dummy args.

Walter

[Bug target/72103] ICE with gcc 7 for povray benchmark

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Per c#3, could we please have another bug opened to track the tragic code
generation opportunity? ;)

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[mpolacek at gcc dot gnu.org]

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

--- Comment #48 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jul 28 15:46:07 2016
New Revision: 238824

URL: https://gcc.gnu.org/viewcvs?rev=238824=gcc=rev
Log:
PR c/7652
* jcf-dump.c (print_constant): Add break.

Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/jcf-dump.c

[Bug target/72738] internal compiler error: in expand_shift_1, at expmed.c:2318

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton  ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to James Greenhalgh from comment #1)
> > Testcase needs a #include  to compile, but otherwise confirmed
> > from GCC 4.9 through to trunk.
> > 
> > Note that it isn't immediately clear that this is valid code - operations on
> > poly128_t other than vreinterpret, vldrq, and vstrq are not defined by ACLE,
> > so the equality/inequality operators have no defined meaning (though ICEing
> > is still not correct).

Here's the reason for the dodgy-ness. Its a LeMaker HiKey, ARMv8/Aarch64
running Linaro with Debian/Linaro 4.9.2-10:

$ grep -IR vreinterpretq_u64_p128 /usr/lib/gcc
$

Its missing some of the vreinterpret_*_p intrinsics, like
vreinterpretq_u64_p128.

*

$ find /usr/lib -name 'arm_neon.h'
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
/usr/lib/llvm-3.5/lib/clang/3.5.0/include/arm_neon.h
$ find /usr/lib -name 'arm_acle.h'
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
/usr/lib/llvm-3.5/lib/clang/3.5.0/include/arm_acle.h

And:

$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
$ grep p64 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
$ grep p64 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
vmull_p64 (poly64_t a, poly64_t b)
vmull_high_p64 (poly64x2_t a, poly64x2_t b)
$

[Bug target/72742] New: [7 Regression] ICE in extract_insn, at recog.c:2309 (error: unrecognizable insn) w/ -Os -mlra

[asolokha at gmx dot com]

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

Bug ID: 72742
   Summary: [7 Regression] ICE in extract_insn, at recog.c:2309
(error: unrecognizable insn) w/ -Os -mlra
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20160724 snapshot ICEs when compiling the following reduced
snippet for 32-bit BE powerpc w/ -Os -mlra:

int xi, m3;
unsigned short int a8;

void
p6 (int ey, unsigned short int *sa)
{
  int fx;
 reh5ef9u:
{
  unsigned short int va;
  if (ey != 0)
{
  a8 %= xi < 0;
  while (a8 < 17)
++a8;
  m3 &= fx;
  if ((xi & (m3 != 0 ? *sa : 0)) != 0)
{
  va /= 3;
  xi += (va != 0) ? (va = xi) : 0;
}
  xi = va && xi;
  goto reh5ef9u;
  sa = 
}
}
}

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20160724 -c -Os -mlra uwysfky3.c
uwysfky3.c: In function 'p6':
uwysfky3.c:27:1: error: unrecognizable insn:
 }
 ^
(insn 165 53 166 9 (set (reg:SI 10 10 [211])
(and:SI (reg:SI 9 9 [orig:161 xi_lsm.20 ] [161])
(const_int 0 [0]))) uwysfky3.c:17 -1
 (nil))
uwysfky3.c:27:1: internal compiler error: in extract_insn, at recog.c:2309

(unrecognizable insn dump for powerpc-e500v2-linux-gnuspe is very similar).

[Bug fortran/71883] [5/6/7 Regression] ICE in identical_array_ref, at fortran/dependency.c:104

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Thu Jul 28 14:47:02 2016
New Revision: 238822

URL: https://gcc.gnu.org/viewcvs?rev=238822=gcc=rev
Log:
2016-07-28  Steven G. Kargl  
Thomas Koenig  

PR fortran/71883
* frontend-passes.c (gfc_run_passes): Bail out if there are any
errors.
* error.c (gfc_internal_error): If there are any errors in the
buffer, exit with EXIT_FAILURE.

2016-07-28  Paul Thomas  

PR fortran/71883
* gfortran.dg/pr71883.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr71883.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/72741] New: Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

[tschwinge at gcc dot gnu.org]

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

Bug ID: 72741
   Summary: Fortran OpenACC routine directive doesn't properly
handle clauses specifying the level of parallelism
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

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

The Fortran OpenACC routine directive doesn't diagnose if there are clauses
specifying conflicting levels of parallelism (such as: "!$acc routine gang
worker").  Also, from a quick look it seems as if for a routine directive with
a name (such as: "!$acc routine (function_1) gang"), any clauses specified are
generally not evaluated to determine the specified function's level of
parallelism.

(Note that unless Cesar's recent

"[PATCH] OpenACC routines in fortran modules" is applied, a routine directive
for intrinsic functions (such as: "!$acc routine (ABORT) seq") will be
generally flagged as invalid.)

[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test

[ienkovich at gcc dot gnu.org]

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

--- Comment #10 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu Jul 28 14:19:18 2016
New Revision: 238817

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

2016-07-28  Yuri Rumyantsev  

PR tree-optimization/71734
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Pass value of safelen
attribute instead of REF_LOOP and use it.
(ref_indep_loop_p_2): Use SAFELEN argument instead of REF_LOOP and
set it for Loops having non-zero safelen attribute.
(ref_indep_loop_p): Pass zero as initial value for safelen.

gcc/testsuite/

2016-07-28  Yuri Rumyantsev  

PR tree-optimization/71734
* g++.dg/vect/pr70729-nest.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr70729-nest.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c

[Bug c/71573] ICE on invalid C code on x86_64-linux-gnu (tree check: expected function_decl, have var_decl in implicitly_declare)

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
gcc34 is fine:
q.c: In function `f2':
q.c:4: error: called object is not a function

but even r104500 ICEs, so this is ancient regression.

[Bug middle-end/71942] [ARM] Zero-extending whats allready zero-extended even when -O3

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #4 from James Greenhalgh  ---
(In reply to Albi from comment #3)
> Agreed, after way more google research a lot of people complain about this.
> 
> Never the less this poses a big problem since it halves the performance of
> every load on a sub-32-bit datatype.
> 
> Imho the problem issnt in the optimizer... i think the fundamental problem
> is that the instruction-set is not aware of the implicit unsigned
> zero-extention thats allready done by the load-instruction.
> 
> With that knowledge the idea of inserting the (redundant) zero-extending
> instruction like "uxth" wouldnt even come up even without optimization.
> 
> This is at least true for every unsigned short or unsigned char.
> Signed types need the sign extension of course.
> 
> In other words: there is actually no reason the instruction should be issued
> in the first place and therefore the optimizer should not really need to
> remove it afterwards.  Its fundamentally redundant.

But that isn't really how a compiler like GCC works! Think of the model as
first generating correct code, no matter the redundancy, then iteratively
transforming it down to the final output. Try compiling with -O0 to see just
how much redundancy the compiled code starts with.

Why do it this way? It gives a nicer structure to compilation. A language
front-end doesn't need to know much about the eventual target, and particularly
doesn't need to know the available instructions that are available.

As food for thought, imagine a compiler that chose to do this optimisation
immediately while parsing. Such a compiler would still need to repeat the logic
that could spot the redundant code in some future optimisation pass (imagine if
it wasn't yet clear that this was just a load followed by a zero-extend, maybe
there was some other redundant maths in the way so it wasn't immediately
clear), so for the sake of program design you'd probably want to factor the
common code out. For maximum effect you'd want the code that tries to spot the
opportunities you describe to have visibility of what comes both before and
after each individual fragment that it parses, which means you'd want to run it
after you've finished parsing. So you'd have a split between parsing and your
new redundancy removing pass. At that point you've designed a compiler which
first parses, then optimises, and you're back to the model that most production
compilers use.

[Bug middle-end/72657] [7 regression][CHKP] internal compiler error: in ix86_expand_builtin

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

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

[Bug middle-end/72657] [7 regression][CHKP] internal compiler error: in ix86_expand_builtin

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu Jul 28 12:58:37 2016
New Revision: 238816

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

PR middle-end/72657
PR target/72683
* tree-chkp.c (chkp_retbnd_call_by_val): Check for instrumentation
call using chkp_gimple_call_builtin_p.
(chkp_copy_bounds_for_assign): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-chkp.c

[Bug target/72683] [7 Regression] MPX test failures with LTO

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu Jul 28 12:58:37 2016
New Revision: 238816

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

PR middle-end/72657
PR target/72683
* tree-chkp.c (chkp_retbnd_call_by_val): Check for instrumentation
call using chkp_gimple_call_builtin_p.
(chkp_copy_bounds_for_assign): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-chkp.c

[Bug ada/72740] New: gnat.dg/specs/access[12].ads ICE when compiling with -g

[rguenth at gcc dot gnu.org]

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

Bug ID: 72740
   Summary: gnat.dg/specs/access[12].ads ICE when compiling with
-g
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

/home/abuild/rguenther/obj-early-lto-debug-g/gcc/gnat1 -I
/space/rguenther/src/svn/early-lto-debug/gcc/testsuite/gnat.dg/specs/ -I -
-quiet -dumpbase access2.ads -auxbase access2 -gnatez -fdiagnostics-color=never
-gnatea
-fRTS=/home/abuild/rguenther/obj-early-lto-debug-g/x86_64-pc-linux-gnu/./libada
-fno-diagnostics-show-caret -g -gnatez -mtune=generic -march=x86-64
/space/rguenther/src/svn/early-lto-debug/gcc/testsuite/gnat.dg/specs/access2.ads
-o access2.s

raised STORAGE_ERROR : stack overflow or erroneous memory access
gnatmake:
"/space/rguenther/src/svn/early-lto-debug/gcc/testsuite/gnat.dg/specs/access2.ads"
compilation error

the issue is that we have recursive pointer types and blow the stack when
dwarf2out calls verify_type which calls variably_modified_type_p:

(gdb) p type->typed.type->typed.type
$3 = 
(gdb) p type->typed.type->typed.type->typed.type
$4 = 
(gdb) p type->typed.type->typed.type->typed.type->typed.type
$5 = 

not sure how to best represent such a structure.  Maybe
variably_modified_type_p
needs adjustment?

[Bug fortran/71961] [7 Regression] 178.galgel in SPEC CPU 2000 is miscompiled

[renlin at gcc dot gnu.org]

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

--- Comment #15 from Renlin Li  ---
The change r238497 has been reverted as r238815.

I confirmed that, after the revert, the 178.gagel mis-compare
is fixed in aarch64-linux environment.

PR 71902 is reopend as well.

[Bug tree-optimization/72739] [7 Regression] FAIL: gcc.dg/vect/vect-mask-store-move-1.c after r238301

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-28
 CC||amker at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug fortran/71902] [5/6 Regression] Unneeded temporary on reallocatable character assignment

[renlin at gcc dot gnu.org]

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

--- Comment #6 from Renlin Li  ---
Author: renlin
Date: Thu Jul 28 11:21:53 2016
New Revision: 238815

URL: https://gcc.gnu.org/viewcvs?rev=238815=gcc=rev
Log:
[PATCH] Revert Revert r238497 because of PR 71961.

This patch reverts the change for PR 71902 since it causes 178.gagel
miscompile in spec2000 as reported in PR 71961 which was observed in
x86_64, aarch64, powerpc64.

gcc/fortran/ChangeLog:

2016-07-28  Renlin Li  

Revert
2016-07-19  Thomas Koenig  

PR fortran/71902
* dependency.c (gfc_check_dependency): Use dep_ref.  Handle case
if identical is true and two array element references differ.
(gfc_dep_resovler):  Move most of the code to dep_ref.
(dep_ref):  New function.
* frontend-passes.c (realloc_string_callback):  Name temporary
variable "realloc_string".

gcc/testsuite/ChangeLog:

2016-07-28  Renlin Li  

Revert
2016-07-19  Thomas Koenig  

PR fortran/71902
* gfortran.dg/dependency_47.f90:  New test.


Removed:
trunk/gcc/testsuite/gfortran.dg/dependency_47.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/71961] [7 Regression] 178.galgel in SPEC CPU 2000 is miscompiled

[renlin at gcc dot gnu.org]

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

--- Comment #14 from Renlin Li  ---
Author: renlin
Date: Thu Jul 28 11:21:53 2016
New Revision: 238815

URL: https://gcc.gnu.org/viewcvs?rev=238815=gcc=rev
Log:
[PATCH] Revert Revert r238497 because of PR 71961.

This patch reverts the change for PR 71902 since it causes 178.gagel
miscompile in spec2000 as reported in PR 71961 which was observed in
x86_64, aarch64, powerpc64.

gcc/fortran/ChangeLog:

2016-07-28  Renlin Li  

Revert
2016-07-19  Thomas Koenig  

PR fortran/71902
* dependency.c (gfc_check_dependency): Use dep_ref.  Handle case
if identical is true and two array element references differ.
(gfc_dep_resovler):  Move most of the code to dep_ref.
(dep_ref):  New function.
* frontend-passes.c (realloc_string_callback):  Name temporary
variable "realloc_string".

gcc/testsuite/ChangeLog:

2016-07-28  Renlin Li  

Revert
2016-07-19  Thomas Koenig  

PR fortran/71902
* gfortran.dg/dependency_47.f90:  New test.


Removed:
trunk/gcc/testsuite/gfortran.dg/dependency_47.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/72739] New: [7 Regression] FAIL: gcc.dg/vect/vect-mask-store-move-1.c after r238301

[ysrumyan at gmail dot com]

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

Bug ID: 72739
   Summary: [7 Regression] FAIL:
gcc.dg/vect/vect-mask-store-move-1.c after r238301
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

We noticed that after this revision test is failed:
FAIL: gcc.dg/vect/vect-mask-store-move-1.c scan-tree-dump-times vect "Move stm
t to created bb" 4
FAIL: gcc.dg/vect/vect-mask-store-move-1.c -flto -ffat-lto-objects  scan-tree-
dump-times vect "Move stmt to created bb" 4

The problem is caused by complete deletion of vectorized loop which requires
run-time alias check. Note that GCC 6 does not have such issue.

[Bug target/72738] internal compiler error: in expand_shift_1, at expmed.c:2318

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  ---
(In reply to James Greenhalgh from comment #1)
> Testcase needs a #include  to compile, but otherwise confirmed
> from GCC 4.9 through to trunk.
> 
> Note that it isn't immediately clear that this is valid code - operations on
> poly128_t other than vreinterpret, vldrq, and vstrq are not defined by ACLE,
> so the equality/inequality operators have no defined meaning (though ICEing
> is still not correct).

Ah, that's interesting. There were no warnings or diagnostics with -Wall
-Wextra (see below).

All my test platforms arrived at the correct result. I assumed GCC was doing
the right thing and generating code to compare elements for equality.

After the crash on Aarch32, I immediately started started looking at that
comparison. We have other code following the same dodgy pattern. Thanks for
helping with the test case.

**

$ gcc -Wall -Wextra -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -fPIC test.cc -o test.out
test.cc: In function ‘int main(int, char**)’:
test.cc:5:17: warning: variable ‘result’ set but not used
[-Wunused-but-set-variable]
   volatile bool result = true;
 ^
test.cc: At global scope:
test.cc:3:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
 int main(int argc, char* argv[])
  ^
test.cc:3:31: warning: unused parameter ‘argv’ [-Wunused-parameter]
 int main(int argc, char* argv[])
   ^
test.cc: In function ‘int main(int, char**)’:
test.cc:10:16: internal compiler error: in expand_shift_1, at expmed.c:2318
   result = (r1 != r2);
^
Please submit a full bug report,

[Bug target/72738] internal compiler error: in expand_shift_1, at expmed.c:2318

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Target|aarch64*|arm*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-28
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/72738] internal compiler error: in expand_shift_1, at expmed.c:2318

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #1 from James Greenhalgh  ---
Testcase needs a #include  to compile, but otherwise confirmed from
GCC 4.9 through to trunk.

Note that it isn't immediately clear that this is valid code - operations on
poly128_t other than vreinterpret, vldrq, and vstrq are not defined by ACLE, so
the equality/inequality operators have no defined meaning (though ICEing is
still not correct).

Further reduced testcase:

  #include 
  int
  foo (poly128_t a, poly128_t b)
  {
return a == b;
  }

Backtrace:

foo.c: In function 'main':
foo.c:11:16: internal compiler error: in expand_shift_1, at expmed.c:2450
   result = (r1 != r2);
^~
0x7ddece expand_shift_1
.../gcc/expmed.c:2450
0x7de849 expand_shift(tree_code, machine_mode, rtx_def*, int, rtx_def*, int)
.../gcc/expmed.c:2466
0x7e466a emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
.../gcc/expmed.c:5826
0x7e4179 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
.../gcc/expmed.c:5670
0x7e4d65 emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
.../gcc/expmed.c:5860
0x808724 do_store_flag
.../gcc/expr.c:11408
0x808724 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
.../gcc/expr.c:9196
0x6e7e47 expand_gimple_stmt_1
.../gcc/cfgexpand.c:3686
0x6e7e47 expand_gimple_stmt
.../gcc/cfgexpand.c:3746
0x6e9dc5 expand_gimple_basic_block
.../gcc/cfgexpand.c:5753
0x6ed427 execute
.../gcc/cfgexpand.c:6368

[Bug c/71574] ICE on code with alloc_align attribute on x86_64-linux-gnu: in default_conversion, at c/c-typeck.c:2126

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Started with my r210262.

[Bug target/72736] warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[noloader at gmail dot com]

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

--- Comment #6 from Jeffrey Walton  ---
(In reply to James Greenhalgh from comment #5)
> (In reply to Jeffrey Walton from comment #4)
> > Thanks, and sorry to waste your time with it.
> > 
> > Before I spin up another report that wastes a lot time, does this look like
> > another issue with me (likely), or an issue with GCC (unlikely):
> > 
> > internal compiler error: in expand_shift_1, at expmed.c:2318
> >result = (r1 != r2);
> > 
> > Here's a quick copy/paste of the relevant pieces. I'll do the minimal
> > working example if needed.
> > 
> > 
> > // Executed with a sig_handler guard
> > volatile bool result = true;
> > ...
> > 
> > const poly64_t a1={1}, b1={2};
> > const poly64x2_t a2={1}, b2={2};
> > const poly128_t r1 = vmull_p64(a1, b1);
> > const poly128_t r2 = vmull_high_p64(a2, b2);
> > 
> > result = (r1 != r2);
> 
> Internal compiler errors are almost never *your* fault, the compiler should
> gracefully handle most of what you throw at it. If you can build a minimum
> working example that would be handy ...

OK, thanks. Done at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72738 .

> (though note that GCC 4.9 is getting old
> now, and the branch is due to close permanently in the very near future, so
> unless this reproduces on 5/6/trunk we're probably past the point where it
> would get looked at and fixed).

Yeah, it is a bit dated. Debian is still supplying 4.9 with Jessie stable, so
its fairly ubiquitous. Its on nearly every test machine I have, including IoT
gadgets like BeagleBones, CunieTrucks, Raspberry Pi's, Banana Pi's, and HiKeys.

[Bug target/72738] New: internal compiler error: in expand_shift_1, at expmed.c:2318

[noloader at gmail dot com]

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

Bug ID: 72738
   Summary: internal compiler error: in expand_shift_1, at
expmed.c:2318
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

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

Raspberry Pi 3 with a 32-bit Debian-lite OS. Its ARMv8, Broadcom SoC under A53
architecture. I'm attempting to compile for Aarch32 with CRC and Crypto
enabled.

$ cat test.cc
#include 
#include 
int main(int argc, char* argv[])
{
  volatile bool result = true;
  const poly64_t a1={1}, b1={2};
  const poly64x2_t a2={1}, b2={2};
  const poly128_t r1 = vmull_p64(a1, b1);
  const poly128_t r2 = vmull_high_p64(a2, b2);
  result = (r1 != r2);
  return 0;
}

$ gcc -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -fPIC
test.cc -o test.out
test.cc: In function ‘int main(int, char**)’:
test.cc:10:16: internal compiler error: in expand_shift_1, at expmed.c:2318
   result = (r1 != r2);
^
Please submit a full bug report...

[Bug tree-optimization/72712] [7 Regression] Tenfold compile time regression

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
(In reply to Richard Biener from comment #3)
> Btw, is the compile-time spent in the threading or in followup passes that
> blow up with the large number of BBs?
> 

I was quite surprised because the original file tended to die in
various after-pass TODOs, but it seems that half of it is threading
itself:

These are excerpts from release-checking compiler -O2 time report:

 phase opt and generate  : 253.88 (100%) usr   0.81 (99%) sys 254.88 (100%)
wall  702308 kB (99%) ggc

 tree CFG cleanup:  38.68 (15%) usr   0.00 ( 0%) sys  38.69 (15%) wall 
  2543 kB ( 0%) ggc
 tree SSA incremental:  66.79 (26%) usr   0.03 ( 4%) sys  66.85 (26%) wall 
 33289 kB ( 5%) ggc
 backwards jump threading: 117.38 (46%) usr   0.07 ( 9%) sys 117.43 (46%) wall 
355352 kB (50%) ggc
 cfg cleanup :   4.16 ( 2%) usr   0.00 ( 0%) sys   4.15 ( 2%) wall 
 25782 kB ( 4%) ggc

However, checking=yes -O2 compilation does not differ very much:

 phase opt and generate  : 337.87 (100%) usr   0.96 (98%) sys 338.87 (100%)
wall  719371 kB (99%) ggc

 CFG verifier:   9.66 ( 3%) usr   0.00 ( 0%) sys   9.68 ( 3%) wall 
 0 kB ( 0%) ggc
 tree CFG cleanup:  43.23 (13%) usr   0.01 ( 1%) sys  43.28 (13%) wall 
  2998 kB ( 0%) ggc
 tree SSA incremental:  76.06 (22%) usr   0.09 ( 9%) sys  76.01 (22%) wall 
 33289 kB ( 5%) ggc
 backwards jump threading: 150.05 (44%) usr   0.05 ( 5%) sys 150.10 (44%) wall 
365739 kB (50%) ggc

in both cases, everything else is <3%.

[Bug target/72736] warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #5 from James Greenhalgh  ---
(In reply to Jeffrey Walton from comment #4)
> Thanks, and sorry to waste your time with it.
> 
> Before I spin up another report that wastes a lot time, does this look like
> another issue with me (likely), or an issue with GCC (unlikely):
> 
> internal compiler error: in expand_shift_1, at expmed.c:2318
>result = (r1 != r2);
> 
> Here's a quick copy/paste of the relevant pieces. I'll do the minimal
> working example if needed.
> 
> 
> // Executed with a sig_handler guard
> volatile bool result = true;
> ...
> 
> const poly64_t a1={1}, b1={2};
> const poly64x2_t a2={1}, b2={2};
> const poly128_t r1 = vmull_p64(a1, b1);
> const poly128_t r2 = vmull_high_p64(a2, b2);
> 
> result = (r1 != r2);

Internal compiler errors are almost never *your* fault, the compiler should
gracefully handle most of what you throw at it. If you can build a minimum
working example that would be handy (though note that GCC 4.9 is getting old
now, and the branch is due to close permanently in the very near future, so
unless this reproduces on 5/6/trunk we're probably past the point where it
would get looked at and fixed).

[Bug target/72736] warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
Thanks, and sorry to waste your time with it.

Before I spin up another report that wastes a lot time, does this look like
another issue with me (likely), or an issue with GCC (unlikely):

internal compiler error: in expand_shift_1, at expmed.c:2318
   result = (r1 != r2);

Here's a quick copy/paste of the relevant pieces. I'll do the minimal working
example if needed.


// Executed with a sig_handler guard
volatile bool result = true;
...

const poly64_t a1={1}, b1={2};
const poly64x2_t a2={1}, b2={2};
const poly128_t r1 = vmull_p64(a1, b1);
const poly128_t r2 = vmull_high_p64(a2, b2);

result = (r1 != r2);

[Bug target/72736] warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jgreenhalgh at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from James Greenhalgh  ---
I see several misunderstandings wrapped up in this bug - but as far as I can
see everything is working as documented (even if that documentation may not be
the easiest to decipher), so I'm resolving the report as invalid.

In short, try:

  $CC -mcpu=cortex-a53 -mfpu=crypto-neon-fp-armv8 (and -mfloat-abi=hard/softfp
if that is not preconfigured in your compiler)

See https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html for options applicable
to the ARM port.

  -march=armv8-a+crc+crypto

As I'm sure you've spotted from the error message given by the compiler, this
is not a valid value to pass to -march. The closest is -march=armv8-a+crc .
This would ask the compiler to generate instructions for the ARMv8-A
architecture profile, with the optional CRC32 extensions. That gets you halfway
to what you actually want (which is for the compiler to enable both the CRC32
extensions and the Crypto extensions).

  warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

As you've correctly identified, the CRC32 extension is optional for ARMv8-A
implementations, thus -march=armv8-a does not enable support for it. However,
the Cortex-A53 always provides the CRC32 extension, and -mcpu=cortex-a53 would
enable support for it. This is the conflict GCC is warning about;
-march=armv8-a turns off the CRC32 extension, but -mcpu=cortex-a53 would turn
on the CRC32 extension.

Note that -mcpu=$foo is a shorthand for -mtune=$foo -march=`arch_of ($foo)` so
you only need -mcpu=cortex-a53 on your command line to enable support for the
CRC32 extensions.

  -mfpu=neon

As you might know; historically ARM floating-point and vector hardware units
were implemented as coprocessors and were to some extent interchangeable. Thus,
the ARM port of GCC decouples the choice of floating-point and vector unit
(under the -mfpu= option) and architecture (under the -march= option).

Here you are asking the compiler to generate code for "neon". This option
refers to the Advanced SIMD instructions as defined in ARMv7-A and implemented
in Cortex-A8 and similar processors.

The other bit of knowledge you need is that the Cryptographic extensions use
the Advanced SIMD registers, and are therefore considered by GCC to be
something that should be enabled by an -mfpu option. Checking the list of valid
options, you will want crypto-neon-fp-armv8 .

   -D__ARM_FEATURE_CRYPTO -D__ARM_FEATURE_CRC 

These macros are predefined by the compiler when it thinks you have support for
these features. Defining them yourself is unlikely to work well, as you've
discovered.

[Bug target/72736] warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[ktkachov at gcc dot gnu.org]

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

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 ---
The crypto instructions use the Advanced SIMD registers and on aarch32 (the arm
gcc port) are therefore enabled by the -mfpu option (unlike on aarch64 where
you can just add +crypto to an -mcpu or -march argument)

To enable them use -mfpu=crypto-neon-fp-armv8.

Note that the -mcpu option is used as a shorthand for an -march + -mtune option
combination.

-mcpu=cortex-a53 is in this case equivalent to -march=armv8-a+crc
-mtune=cortex-a53 which is why you get the complaint about the conflict with
-march=armv8-a

[Bug target/72736] warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
*** Bug 72737 has been marked as a duplicate of this bug. ***

[Bug target/72737] warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Liška  ---
Dup.

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

[Bug gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed on trunk.

[Bug gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Thu Jul 28 08:45:29 2016
New Revision: 238811

URL: https://gcc.gnu.org/viewcvs?rev=238811=gcc=rev
Log:
Introduce no_profile_instrument_function attribute

PR gcov-profile/68025
* tree-profile.c (tree_profiling): Respect
no_profile_instrument_function attribute.
* doc/extend.texi: Document no_profile_instrument_function
attribute.
PR gcov-profile/68025
* c-common.c (handle_no_profile_instrument_function_attribute):
PR gcov-profile/68025
* gcc.dg/no_profile_instrument_function-attr-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-profile.c

[Bug tree-optimization/72517] [7 Regression] 436.cactusADM: More than 40% regression in O3 and Ofast on AMD bdver4 m/c.

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #12)
> On July 27, 2016 7:02:07 PM GMT+02:00, "Amit.Pawar at amd dot com"
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72517
> >
> >--- Comment #11 from Amit Pawar  ---
> >Improvement is seen but not same as best one. 
> >
> >
> >Current scores are
> >Flags   Latest trunk
> >O3  :31.4
> >O3 -march=bdver4:31.1
> >Ofast   :32.1
> >Ofast -march=bdver4 :31.2
> >
> >but good one.
> >Flags   Good Trunk
> >O3  37.69   
> >O3 bdver4   36.55   
> >Ofast   40.36
> >Ofast bdver438.31
> >
> >Can you please check at your end?
> 
> I checked r237473 plus the patch against r237472 and the regression was
> fully fixed.  I did not yet check current trunk but if there is any
> regression it is a new one caused by sth else.  Bisection with the fix for
> this regression might tell.

Double-checking against trunk, thus base is r237472 and peak is r238807 I get

436.cactusADM   11950320   37.3 *   11950318   37.5 *  

for -Ofast -march=native (three-run result).  This is FAM 21 Model 96 Stepping
1 detected as bdver4 by GCC.

[Bug target/72717] ICE: in emit_move_insn, at expr.c:3693 with vector shift @ powerpc64le

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-28
 CC||marxin at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug rtl-optimization/70944] [7 Regression] ICE in immed_wide_int_const, at emit-rtl.c:606 with -O3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/70944] [7 Regression] ICE in immed_wide_int_const, at emit-rtl.c:606 with -O3

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Jul 28 08:26:51 2016
New Revision: 238808

URL: https://gcc.gnu.org/viewcvs?rev=238808=gcc=rev
Log:
Do not allow make_compound_operation for vector mode

* g++.dg/vect/pr70944.cc: New test.
PR rtl-optimization/70944
* combine.c (make_compound_operation):
Do not allow make_compound_operation for vector mode

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/72712] [7 Regression] Tenfold compile time regression

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I've noted that we have suspiciously many 'thread' passes but of couse the
transform itself looks not appropriately limited.

Btw, is the compile-time spent in the threading or in followup passes that
blow up with the large number of BBs?

I notice that even at -O1 (ok, with a -O0 compiler and checking enabled but
with -fno-checking) we see:

 tree SSA incremental:   5.90 (30%) usr   0.02 ( 5%) sys   5.92 (29%) wall 
  8523 kB ( 9%) ggc
 rest of compilation :   6.51 (33%) usr   0.24 (65%) sys   6.73 (33%) wall 
 49015 kB (50%) ggc
 TOTAL :  19.93 0.3720.32 
97184 kB

Note that we do have quite some passes that exhibit quadraticness in the number
of loops (in some cases at least).  if-conversion comes to my mind here (wrt
dominance compute) and also ISTR some passes doing update-ssa one per function
(the above 30% hint at that).

[Bug driver/70132] ARM -mcpu=native can cause a double free abort.

[noloader at gmail dot com]

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

--- Comment #14 from Jeffrey Walton  ---
(In reply to ktkachov from comment #8)
> Fixed on trunk for now.
> Will backport after some time to the branches

Bump... I don't think this has made it into Debian's 4.9.2-10.

[Bug driver/70132] ARM -mcpu=native can cause a double free abort.

[noloader at gmail dot com]

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

Jeffrey Walton  changed:

   What|Removed |Added

 CC||noloader at gmail dot com

--- Comment #13 from Jeffrey Walton  ---
(In reply to Andrew Roberts from comment #5)
> Do I need to raise another bug report  to get the march=native to actually
> generate native code, or has one already been raised?
> 
> My original report (Bug 70136) included full /proc/cpuinfo for the BCM2834
> as used on the Raspberry Pi 3 in 32 bit mode.
> 
> CPU implementer   : 0x41
> CPU architecture: 7
> CPU variant   : 0x0
> CPU part  : 0xd03
> CPU revision  : 4

Andrew - this comment caught my eye because I have been struggling with it
on-and-off for a few days. How did you enable CRC and Crypto extensions on the
RPI-3 with the A-53?

My apologies for drifting off-topic.

[Bug target/72737] New: warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[noloader at gmail dot com]

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

Bug ID: 72737
   Summary: warning: switch -mcpu=cortex-a53 conflicts with
-march=armv8-a switch
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

This looks like an issue similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907. It also appears similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=70210. My apologies if it has
already been fixed.

Raspberry recently welcomed the Raspberry Pi 3. Its an ARMv8 SoC by Broadcom
based on the A-53 core. Raspberry is resisting an 64-bit Aarch64 image, so we
have to use a 32-bit image and toolchain. Fortunately, Aarch32 has the
necessary instructions, too (but with a different encoding). Also see
https://community.arm.com/groups/android-community/blog/2015/03/27/arm-neon-programming-quick-reference
.

Attempting to compile in this configuration results in:

$ cat test.cc
int main(int argc, char* argv[])
{
  return 0;
}

$ gcc -march=armv8-a -mcpu=cortex-a53 test.cc -o test.exe
test.cc:1:0: warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a
switch
 int main(int argc, char* argv[])
 ^

The same thing applies as in the 57907. The manual seems to indicate its a
supported configuration. And the same comments apply as well. There are some
optional instructions that may not be present in a baseline A53.

**

What I am ultimately after here is access to the PMULL, PMULL2, AES, SHA1 and
SHA2 intrinsics. But alas, that does not want to compile:

$ gcc -march=armv8-a+crc+crypto -mcpu=cortex-a53 test.cc -o test.exe

gcc: error: unrecognized argument in option ‘-march=armv8-a+crc+crypto’
gcc: note: valid arguments to ‘-march=’ are: armv2 armv2a armv3 armv3m armv4
armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2
armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv7ve armv8-a
armv8-a+crc iwmmxt iwmmxt2 native

**

And here's another attempt to enable CRC and Crypto. I'm probably going to have
to take this to the GCC mailing list for help.

raspberrypi:cryptopp-gcm$ gcc -D__ARM_FEATURE_CRYPTO -D__ARM_FEATURE_CRC
-march=armv8-a -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
test.cc:1:0: warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a
switch
 #include 
 ^
In file included from test.cc:1:0:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13707:50: error:
‘__builtin_arm_crypto_aese’ was not declared in this scope
   return __builtin_arm_crypto_aese (__data, __key);
  ^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaesdq_u8(uint8x16_t, uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13713:50: error:
‘__builtin_arm_crypto_aesd’ was not declared in this scope
   return __builtin_arm_crypto_aesd (__data, __key);
  ^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaesmcq_u8(uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13719:44: error:
‘__builtin_arm_crypto_aesmc’ was not declared in this scope
   return __builtin_arm_crypto_aesmc (__data);
^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaesimcq_u8(uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13725:45: error:
‘__builtin_arm_crypto_aesimc’ was not declared in this scope
   return __builtin_arm_crypto_aesimc (__data);
 ^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function ‘uint32_t
vsha1h_u32(uint32_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13733:40: error:
‘__builtin_arm_crypto_sha1h’ was not declared in this scope
   __t = __builtin_arm_crypto_sha1h (__t);
^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint32x4_t vsha1cq_u32(uint32x4_t, uint32_t, uint32x4_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13742:60: error:
‘__builtin_arm_crypto_sha1c’ was not declared in this scope
   return __builtin_arm_crypto_sha1c (__hash_abcd, __t, __wk);
^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint32x4_t vsha1pq_u32(uint32x4_t, uint32_t, uint32x4_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13750:60: error:
‘__builtin_arm_crypto_sha1p’ was not declared in this scope
   return __builtin_arm_crypto_sha1p (__hash_abcd, __t, __wk);
 

[Bug target/72736] New: warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

[noloader at gmail dot com]

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

Bug ID: 72736
   Summary: warning: switch -mcpu=cortex-a53 conflicts with
-march=armv8-a switch
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

This looks like an issue similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907. My apologies if it has
already been fixed.

Raspberry recently released the Raspberry Pi 3. Its an ARMv8 SoC by Broadcom
based on the A-53 core. Raspberry is resisting an 64-bit Aarch64 image, so we
have to use an 32-bit image and toolchain. Fortunately, Aarch32 has the
necessary instructions, too (but with a different encoding). Also see
https://community.arm.com/groups/android-community/blog/2015/03/27/arm-neon-programming-quick-reference
.

Attempting to compile in this configuration results in:

$ cat test.cc
int main(int argc, char* argv[])
{
  return 0;
}

$ gcc -march=armv8-a -mcpu=cortex-a53 test.cc -o test.exe
test.cc:1:0: warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a
switch
 int main(int argc, char* argv[])
 ^

The same thing applies as in the 57907. The manual seems to indicate its a
supported configuration. And the comments apply as well. There are some
optional instructions that may not be present in a baseline A53.

**

What I am ultimately after here is access to the PMULL, PMULL2, AES, SHA1 and
SHA2 intrinsics. But alas, that does not want to compile:

$ gcc -march=armv8-a+crc+crypto -mcpu=cortex-a53 test.cc -o test.exe
gcc: error: unrecognized argument in option ‘-march=armv8-a+crc+crypto’
gcc: note: valid arguments to ‘-march=’ are: armv2 armv2a armv3 armv3m armv4
armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2
armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv7ve armv8-a
armv8-a+crc iwmmxt iwmmxt2 native

**

$ gcc --version
gcc (Raspbian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

**

And here's another attempt to enable CRC and Crypto. I'm probably going to have
to take this to the GCC mailing list for help.

raspberrypi:cryptopp-gcm$ gcc -D__ARM_FEATURE_CRYPTO -D__ARM_FEATURE_CRC
-march=armv8-a -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
test.cc:1:0: warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a
switch
 #include 
 ^
In file included from test.cc:1:0:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13707:50: error:
‘__builtin_arm_crypto_aese’ was not declared in this scope
   return __builtin_arm_crypto_aese (__data, __key);
  ^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaesdq_u8(uint8x16_t, uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13713:50: error:
‘__builtin_arm_crypto_aesd’ was not declared in this scope
   return __builtin_arm_crypto_aesd (__data, __key);
  ^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaesmcq_u8(uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13719:44: error:
‘__builtin_arm_crypto_aesmc’ was not declared in this scope
   return __builtin_arm_crypto_aesmc (__data);
^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint8x16_t vaesimcq_u8(uint8x16_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13725:45: error:
‘__builtin_arm_crypto_aesimc’ was not declared in this scope
   return __builtin_arm_crypto_aesimc (__data);
 ^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function ‘uint32_t
vsha1h_u32(uint32_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13733:40: error:
‘__builtin_arm_crypto_sha1h’ was not declared in this scope
   __t = __builtin_arm_crypto_sha1h (__t);
^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint32x4_t vsha1cq_u32(uint32x4_t, uint32_t, uint32x4_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13742:60: error:
‘__builtin_arm_crypto_sha1c’ was not declared in this scope
   return __builtin_arm_crypto_sha1c (__hash_abcd, __t, __wk);
^
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h: In function
‘uint32x4_t vsha1pq_u32(uint32x4_t, uint32_t, uint32x4_t)’:
/usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:13750:60: error:
‘__builtin_arm_crypto_sha1p’ was not declared in this scope
   return __builtin_arm_crypto_sha1p (__hash_abcd, __t, __wk);