[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[acrsofter at gmail dot com]

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

--- Comment #4 from acrsofter at gmail dot com ---
someone here can deal with it?

[Bug tree-optimization/33562] [4.9/5/6 Regression] aggregate DSE disabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P4  |P2

--- Comment #24 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #23)
> Pushing this to a P4 given that the regression, while real, is very rare in
> real world code.
> 
> A fix for the regression as well as further enhancements to DSE is queued
> for gcc-7.

Please leave such kind of bugs at P2, they are not blocking the release and
criteria for prioritization are here: https://gcc.gnu.org/bugs/management.html

[Bug tree-optimization/26854] Inordinate compile times on large routines

[rguenth at gcc dot gnu.org]

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

--- Comment #133 from Richard Biener  ---
Thanks for the update - this PR (one of the testcases) is also tracked in
http://gcc.opensuse.org/c++bench-czerny/random/ (two testcases, pr26854.c is
"all.c" and pr26854-2.c is "_num.c").

note that our focus is primarily -O1 for this kind of testcases - -O2 contains
too many known quadraticnesses though _num.c seems to survive fine (well, ~2gb
of ram).

[Bug tree-optimization/69907] wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug target/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r233267.  But perhaps it was just a latent issue.

[Bug tree-optimization/26854] Inordinate compile times on large routines

[rguenth at gcc dot gnu.org]

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

--- Comment #134 from Richard Biener  ---
We can see from _num.i detailled stats

df_chain_block pool df-problems.c:2398 (df_chain_alloc)
152 0:  0.0% 937593072  61860737: 90.1%  24

which shows an odd element size (expected is 16) which comes from
base_pool_allocator::allocation_object having a ALLOC_POOL_ID_TYPE member
by default.

Then we have (bitmaps)

df-problems.c:1914 (df_mir_alloc)615680:  0.2% 249285640 
12495192: 13.3%   0   0  heap
df-problems.c:1915 (df_mir_alloc)615880:  0.2% 249285680 
12495197: 13.3%   0   0  heap
...
tree-ssa-structalias.c:1268 (build_pred_graph) 62026224: 15.9%  62048368  
7961338:  8.5%  186859  248364  heap
df-problems.c:3658 (df_note_compute)   88025520: 22.6%  88026080  
3719686:  4.0%  515641 1741186  heap
df-problems.c:4405 (df_md_alloc)  -39759960:4741239668736.0%   
   -40520627:  0.6%   0   0  heap
df-problems.c:225 (df_rd_alloc)   -17948440:4741239668736.0%   
   -40284572:  0.3%   0   0  heap

with the overflow thing (and the odd leaks which probably are not properly
tracking when we release bitmaps via releasing the bitmap obstack?)

Most interesting is the peak number, highest for df_mir_alloc.  Eventually
we can do sth to shrink that peak usage by freeing unneeded bitmaps
earlier.

Compile-time looks reasonable.

I'll have a look at the accounting overflows and reducing the pool allocator
overhead as well as looking at the MIR problem bitmap use.

[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 #69 from rguenther at suse dot de  ---
On Mon, 22 Feb 2016, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> Thomas Koenig  changed:
> 
>What|Removed |Added
> 
>Severity|normal  |major
> 
> --- Comment #68 from Thomas Koenig  ---
> The problem here is that there is a large existing codebase
> which depends on memory management which was
> 
> - illegal from the start
> 
> - the only game in town if you wanted to do any
>   sort of dynamic memory management.
> 
> because FORTRAN 66 and 77 explicitly forbade any sort
> of dynamic memory management. We can lament the fact
> fifty years later, but we cannot change it.
> 
> The idea was to use
> 
>   COMMON /FOO/ A(1)
> 
> in a subroutine (even a library), and use
> 
>   COMMON /FOO/ A(1)
> 
> or whatever 'dynamic' size you needed for your memory
> in the main program.
> 
> This idiom appears to be common enough that, if we
> don't support it, or support it only with a severe
> performance penalty, we will simply push people away from
> gfortran.

Ok, so we can also use sth like the following to work around that
unintended optimization side-effect of get_ref_base_and_extent.
Untested, not sure if it catches all cases, it at least "fixes"
some of the small undefined testcases in this PR (not tested on
416.gamess).  I'm not sure about testsuite fallout (I might have
decided to add a testcase for the surprising behavior).

Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c  (revision 233598)
+++ gcc/tree-dfa.c  (working copy)
@@ -617,7 +617,19 @@ get_ref_base_and_extent (tree exp, HOST_
   if (maxsize == -1
  && DECL_SIZE (exp)
  && TREE_CODE (DECL_SIZE (exp)) == INTEGER_CST)
-   maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+   {
+ maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+ /* If we've seen a variable array ref and the above adjusted
+maxsize to size make sure the caller doesn't mistake this
+as a non-variable access by adjusting maxsize slightly.
+???  This is strictly pessimizing the case where a
+one element array is accessed with a variable index
+which should be a rare case in practice but hits legacy
+fortran code - see PR69368 for example.  */
+ if (seen_variable_array_ref
+ && maxsize == bitsize)
+   maxsize *= 2;
+   }
 }
   else if (CONSTANT_CLASS_P (exp))
 {

[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

--- Comment #70 from Jakub Jelinek  ---
If you want to go this way, I'd at least key it off DECL_COMMON on the decl.
And instead of multiplying max_size by 2 perhaps just add BITS_PER_UNIT?
And only if it is equal to size?

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[piotrwn1 at gmail dot com]

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

Piotr Nycz  changed:

   What|Removed |Added

   Severity|normal  |major

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[sch...@linux-m68k.org]

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

--- Comment #33 from Andreas Schwab  ---
make[3]: Entering directory '/opt/gcc/test/Build/lto-plugin'
/bin/sh ./libtool --tag=CC --tag=disable-static  --mode=compile
/opt/gcc/test/Build/./prev-gcc/xgcc -B/opt/gcc/test/Build/./prev-gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/bin/
-B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include
-isystem /usr/aarch64-suse-linux/sys-include-DHAVE_CONFIG_H -I.
-I../../lto-plugin  -I../../lto-plugin/../include -DHAVE_CONFIG_H  -Wall -g -O2
-gtoggle -c -o lto-plugin.lo ../../lto-plugin/lto-plugin.c
libtool: compile:  /opt/gcc/test/Build/./prev-gcc/xgcc
-B/opt/gcc/test/Build/./prev-gcc/ -B/usr/aarch64-suse-linux/bin/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../lto-plugin -I../../lto-plugin/../include
-DHAVE_CONFIG_H -Wall -g -O2 -gtoggle -c ../../lto-plugin/lto-plugin.c  -fPIC
-DPIC -o .libs/lto-plugin.o
cc1: internal compiler error: Segmentation fault
0xf1a03b crash_signal
../../gcc/toplev.c:335
0x17fb3cf filename_cmp
../../libiberty/filename_cmp.c:60

(gdb) bt
#0  strcmp () at ../sysdeps/aarch64/strcmp.S:63
#1  0x017fb3d0 in filename_cmp (
s1=0x1f36b00 "../../lto-plugin/lto-plugin.c", s2=0x0)
at ../../libiberty/filename_cmp.c:60
#2  0x0099a038 in check_global_declaration (snode=0x3ffb5e90480)
at ../../gcc/cgraphunit.c:947
#3  0x0099adb8 in analyze_functions (first_time=true)
at ../../gcc/cgraphunit.c:1168
#4  0x0099f4e8 in symbol_table::finalize_compilation_unit (
this=0x3ffb59e) at ../../gcc/cgraphunit.c:2537
#5  0x00f1a688 in compile_file () at ../../gcc/toplev.c:490
#6  0x00f1da10 in do_compile () at ../../gcc/toplev.c:1988
#7  0x00f1dd74 in toplev::main (this=0x3fff038, argc=18, 
argv=0x3fff188) at ../../gcc/toplev.c:2096
#8  0x0176d228 in main (argc=18, argv=0x3fff188)
at ../../gcc/main.c:39

[Bug c/67854] Missing diagnostic for passing bool to va_arg

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Sorry about that.  I'll look into that this week.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #34 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01541.html

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED
   Severity|major   |normal

--- Comment #1 from Markus Trippelsdorf  ---
This bug is already fixed.

[Bug c/67854] Missing diagnostic for passing bool to va_arg

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
In cases where we want to emit diagnostics about a token that is located in a
macro that is itself defined in system header, for example, for the NULL macro,
using the original location of the token will suppress the diagnostic (unless
-Wsystem-header). Instead, one should use:

source_location loc =
expansion_point_location_if_in_system_header (original_location);

[Bug target/69040] cris allmodconfig fails

[sudipm.mukherjee at gmail dot com]

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

--- Comment #5 from Sudip  ---
(In reply to Hans-Peter Nilsson from comment #4)
> (In reply to Sudip from comment #3)
> > A gentle ping..
> > Any idea when this might get resolved.
> > 
> > regards
> > sudip
> 
> I thought I'd get to it this week, but didn't.  Maybe the next week.
> Thanks for your patience.

No problem. Take your time. Meanwhile I am getting ready to file one for
blackfin.

[Bug c/67854] Missing diagnostic for passing bool to va_arg

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Yeah, I know; I've already fixed the NULL case some time ago (though I'm not
sure if all the appropriate spots are fixed).

[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 #71 from rguenther at suse dot de  ---
On Tue, 23 Feb 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #70 from Jakub Jelinek  ---
> If you want to go this way, I'd at least key it off DECL_COMMON on the decl.
> And instead of multiplying max_size by 2 perhaps just add BITS_PER_UNIT?

Works for me.

> And only if it is equal to size?

That's already done.

[Bug middle-end/69913] New: [6 Regression] ICE (segfault) in check_global_declaration ../../gcc/cgraphunit.c:947

[burnus at gcc dot gnu.org]

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

Bug ID: 69913
   Summary: [6 Regression] ICE (segfault) in
check_global_declaration ../../gcc/cgraphunit.c:947
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37764&action=edit
Test case (tar.gz): Compile with: gcc -Wall  *c

Compiling the following test case, based on bfd/peigen.c (from today's
"binutils-gdb" Git), fails with an ICE when compiling it with:

gcc -Wall  test8.c

It fails with:

cc1: internal compiler error: Segmentation fault
0xb5f78f crash_signal
../../gcc/toplev.c:335
0x78b47d check_global_declaration
../../gcc/cgraphunit.c:947
0x78b47d analyze_functions
../../gcc/cgraphunit.c:1168
0x78bd58 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2537

[Bug tree-optimization/69760] [4.9/5/6 Regression] Wrong 64-bit memory address caused by an unneeded overflowing 32-bit integer multiplication on x86_64 under -O2 and -O3 code optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
So I believe the issue creeps in at SCEV time already.

We go from the BIV i with { 0, +, 1 }_1 via { -m, +, 1 }_1 for i - m to
{ -m * L, +, L } for the index of a[].  All in type int.  The initial
values for those derived IVs can may have undefined overflow behavior
(and for this testcase they do).  The issue is we create an IV for a
conditionally computed expression.

Things go really wrong when analyzing the derived IVs for the inner
reference of a[L*k] where we get to
{ (unsigned long) &a + 8 * (unsigned long) (-m * L), +, 8 * (unsigned long) L
}_1

We could recover from this very specific case by recognizing that when
analyzing (unsigned long) ( X * Y ) with a multiplication that may not overflow
we can analyze it as (unsigned long)((long) X * (long) Y).

But that doesn't fix the fact that the IVs in int type above are wrong as well
- we're just waiting for new interesting testcases to notice.

We'd need to re-write the IVs into unsigned arithmetic which then would make
us no longer be able to compute a polynomial chrec for &a[L*k] as the
multiplication then may wrap.  This is what you get from using -fwrapv or
unsigned i/k.  We only get as far as {-_6 * (unsigned int) L_12(D), +,
(unsigned int) L_12(D)}_1)

But doing this unconditionally really is going to pessimize SCEV and depending
optimizations (not checked).  Doing this conditionally on whether the IV
is computed at a place that is not known to be always executed in the loop
being analyzed would likely introduce other issues as well given we compare
IVs for structual equality when doing dependence analysis, so conditional
a[i*2] vs. unconditional a[i*2] would no longer be handled.

So the following is the minimal "fix" noted above

Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 233620)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -1883,6 +1883,27 @@ interpret_rhs_expr (struct loop *loop, g
   gimple_assign_rhs_code (def),
   gimple_assign_rhs2 (def));
}
+  /* In case we have a widening of an operation with undefined
+ overflow behavior analyze the operation done in the wide
+type with undefined overflow behavior.  This avoids undefined
+behavior if the undefined operation would overflow when
+being computed not at at_stmt which might be executed only
+conditionally.  See PR69760.  */
+  else if (TREE_CODE (TREE_TYPE (rhs1)) == INTEGER_TYPE
+  && TREE_CODE (TREE_TYPE (rhs1)) == INTEGER_TYPE
+  && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (rhs1))
+  && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (rhs1))
+  && TREE_CODE (rhs1) == SSA_NAME
+  && (def = SSA_NAME_DEF_STMT (rhs1))
+  && is_gimple_assign (def)
+  && TREE_CODE_CLASS (gimple_assign_rhs_code (def)) == tcc_binary)
+   {
+ tree stype = signed_type_for (type);
+ chrec1 = interpret_rhs_expr (loop, at_stmt, stype,
+  gimple_assign_rhs1 (def),
+  gimple_assign_rhs_code (def),
+  gimple_assign_rhs2 (def));
+   }
   else
chrec1 = analyze_scalar_evolution (loop, rhs1);
   res = chrec_convert (type, chrec1, at_stmt);

I've done it unconditionally and not based on at_stmt place in the loop we
analyze to avoid the issue mentioned above.

Note this really papers over the fundamental issue with CHRECs computed for
conditionally executed expressions.

About a testcase for the testsuite I'm not sure if allocating 300MB is ok
even if only very few pages are going to be touched.  I suppose restricting
the testcase to *-linux targets might work?  Or run_expensive_tests ...

[Bug middle-end/69913] [6 Regression] ICE (segfault) in check_global_declaration ../../gcc/cgraphunit.c:947

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Target Milestone|--- |6.0

[Bug middle-end/69913] [6 Regression] ICE (segfault) in check_global_declaration ../../gcc/cgraphunit.c:947

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug c/69911] [6 Regression] Massive test failures on ia32

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
*** Bug 69913 has been marked as a duplicate of this bug. ***

[Bug fortran/69296] [6 Regression] [F03] Problem with associate and vector subscript

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from vehre at gcc dot gnu.org ---
No regressions reported, closing.

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[vehre at gcc dot gnu.org]

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

--- Comment #14 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Feb 23 10:29:26 2016
New Revision: 233625

URL: https://gcc.gnu.org/viewcvs?rev=233625&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2016-02-23  Andre Vehreschild  

PR fortran/67451
* gfortran.dg/coarray_allocate_5.f08: New test.


gcc/fortran/ChangeLog:

2016-02-23  Andre Vehreschild  

PR fortran/67451
* trans-array.c (gfc_array_allocate): Take the attributes from the
expression to allocate and not from the source=-expression.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_5.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69760] [4.9/5/6 Regression] Wrong 64-bit memory address caused by an unneeded overflowing 32-bit integer multiplication on x86_64 under -O2 and -O3 code optimization

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Adjusted testcase that only needs 305MB virtual.

/* PR tree-optimization/69760 */
/* { dg-do run { target { { *-*-linux* *-*-gnu* } && mmap } } } */
/* { dg-options "-O2" } */

#include 
#include 

__attribute__((noinline, noclone)) void
test_func (double *a, int L, int m, int n, int N)
{
  int i, k;
  for (i = 0; i < N; i++)
{
  k = i - m;
  if (k >= 0 && k < n)
a[L * k] = 0.0;
}
}

int
main ()
{
  char *p;
  int L, m, n, N;
  long l;
  L = 1000;
  n = 4;
  N = 100 * n;
  long pgsz = sysconf(_SC_PAGESIZE);
  if (pgsz < sizeof (double) || pgsz > L * sizeof (double))
return 0;
  p = mmap ((void *) 0, L * n * sizeof (double), PROT_NONE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (p == MAP_FAILED)
return 0;
  if (mprotect (p, pgsz, PROT_READ | PROT_WRITE))
return 0;
  l = (L * sizeof (double)) / pgsz * pgsz;
  if (mprotect (p + l, pgsz, PROT_READ | PROT_WRITE))
return 0;
  l = (2 * L * sizeof (double)) / pgsz * pgsz;
  if (mprotect (p + l, pgsz, PROT_READ | PROT_WRITE))
return 0;
  l = (3 * L * sizeof (double)) / pgsz * pgsz;
  if (mprotect (p + l, pgsz, PROT_READ | PROT_WRITE))
return 0;
  for (m = 0; m < N; m += n)
test_func ((double *) p, L, m, n, N);
  return 0;
}

[Bug fortran/69910] ICE with NEWUNIT

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Confirmed (I did not test the patch yet).

[Bug target/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
It looks that alias set is already wrong when expanding to RTL:

(insn 13 12 14 2 (parallel [
(set (reg/f:DI 113)
(plus:DI (reg/f:DI 20 frame)
(const_int -64 [0xffc0])))
(clobber (reg:CC 17 flags))
]) pr69909.c:9 219 {*adddi_1}
 (nil))
(insn 14 13 15 2 (parallel [
(set (reg/f:DI 114)
(plus:DI (reg/f:DI 16 argp)
(const_int 64 [0x40])))
(clobber (reg:CC 17 flags))
]) pr69909.c:9 219 {*adddi_1}
 (nil))
(insn 15 14 16 2 (set (reg:DI 115)
(const_int 8 [0x8])) pr69909.c:9 85 {*movdi_internal}
 (nil))
(insn 16 15 17 2 (parallel [
(set (reg:DI 115)
(const_int 0 [0]))
(set (reg/f:DI 113)
(plus:DI (ashift:DI (reg:DI 115)
(const_int 2 [0x2]))
(reg/f:DI 113)))
(set (reg/f:DI 114)
(plus:DI (ashift:DI (reg:DI 115)
(const_int 2 [0x2]))
(reg/f:DI 114)))
(set (mem:BLK (reg/f:DI 113) [1  S32 A256])
(mem/c:BLK (reg/f:DI 114) [1 v32u32_1+0 S32 A256]))
(use (reg:DI 115))
]) pr69909.c:9 942 {*rep_movsi}
 (nil))
(insn 17 16 18 2 (set (reg:TI 116)
(mem/j/c:TI (plus:DI (reg/f:DI 16 argp)
(const_int 144 [0x90])) [2 v32u128_1+16 S16 A128])) pr69909.c:9
84 {*movti_internal}
 (nil))
(insn 18 17 19 2 (parallel [
(set (reg:TI 103 [ _33 ])
(minus:TI (reg:TI 116)
(mem/j/c:TI (plus:DI (reg/f:DI 20 frame)
(const_int -48 [0xffd0])) [2  S16
A128])))
(clobber (reg:CC 17 flags))
]) pr69909.c:9 258 {*subti3_doubleword}
 (expr_list:REG_EQUAL (minus:TI (mem/j/c:TI (plus:DI (reg/f:DI 16 argp)
(const_int 144 [0x90])) [2 v32u128_1+16 S16 A128])
(mem/j/c:TI (plus:DI (reg/f:DI 20 frame)
(const_int -48 [0xffd0])) [2  S16 A128]))
(nil)))

Register 113 points to FP-64, so (insn 16) copies 32 bytes to (FP-64 to FP-32).
(Insn 18) later accesses (FP-48 to FP-32), but its alias set [2] is different
from (insn 16) [1]. Later passes are free to move (insn 18) above (insn 16).

[Bug c/69914] New: ICE in check_global_declaration, upon -Wunused-variable of an array

[sbergman at redhat dot com]

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

Bug ID: 69914
   Summary: ICE in check_global_declaration, upon
-Wunused-variable of an array
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk@233620:

> $ cat test.c
> typedef struct S {
>   int a;
>   void * b;
>   int c;
> } S;
> void f(void) {
> S a[] = {
> {0x0120, ((void *)0), 0},
> {0x0120, ((void *)0), 0},
> {0x0120, ((void *)0), 0},
> {0x0120, ((void *)0), 0},
> {0, ((void *)0), 0},
> {0, ((void *)0), 0}
> };
> }

> $ gcc -Wunused-variable -c test.c
> test.c: In function ‘f’:
> test.c:7:7: warning: unused variable ‘a’ [-Wunused-variable]
>  S a[] = {
>^
> At top level:
> cc1: internal compiler error: Segmentation fault
> 0xb2497f crash_signal
>   ../../src/gcc/toplev.c:335
> 0x7506bd check_global_declaration
>   ../../src/gcc/cgraphunit.c:947
> 0x7506bd analyze_functions
>   ../../src/gcc/cgraphunit.c:1168
> 0x750f98 symbol_table::finalize_compilation_unit()
>   ../../src/gcc/cgraphunit.c:2537

[Bug target/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
And -fno-strict-aliasing "fixes" the problem

[Bug target/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Indeed, the *.optimized dump looks good, the late gimple DCE just removed
really dead stmts.
Slightly cleaned up testcase:
typedef unsigned V __attribute__ ((vector_size (32)));
typedef __int128 T;
typedef __int128 U __attribute__ ((vector_size (32)));

__attribute__((noinline, noclone)) T
foo (T a, V b, V c, V d, V e, U f)
{
  d[6] ^= 0x10;
  f -= (U) d;
  f[1] |= f[1] << (a & 127);
  c ^= d;
  return b[7] + c[2] + c[2] + d[6] + e[2] + f[1];
}

int
main ()
{
  T x = foo (1, (V) { 9, 2, 5, 8, 1, 2, 9, 3 },
(V) { 1, 2, 3, 4, 5, 6, 7, 8 },
(V) { 4, 1, 2, 9, 8, 3, 5, 2 },
(V) { 3, 6, 1, 3, 2, 9, 4, 8 }, (U) { 3, 5 });
  if (((unsigned long long) (x >> 64) != 0xULL
   || (unsigned long long) x != 0xfffe001aULL)
  && ((unsigned long long) (x >> 64) != 0xfffdULL
  || (unsigned long long) x != 0x0022ULL))
__builtin_abort ();
  return 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"

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
Author: jamborm
Date: Tue Feb 23 10:55:47 2016
New Revision: 233626

URL: https://gcc.gnu.org/viewcvs?rev=233626&root=gcc&view=rev
Log:
[pr 69666] No SRA default_def replacements for unscalarizable regions

2016-02-23  Martin Jambor  

PR tree-optimization/69666
* tree-sra.c (sra_modify_assign): Do not attempt to create
default_def replacements for unscalarizable regions.

testsuite/
* gcc.dg/tree-ssa/pr69666.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69666.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug tree-optimization/26854] Inordinate compile times on large routines

[rguenth at gcc dot gnu.org]

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

--- Comment #135 from Richard Biener  ---
bitmap stats seem to be confused by 1) bitmap_obstack_release not releasing
overhead of bitmaps allocated from it, 2) the DF machinery using embedded
bitmap heads which for this testcase seems to explode df_rd_alloc stats
by not accounting releases properly(?) - 'out' is updated by bitmap_clear
on it and copying over a local bitmap_head:

  struct df_rd_problem_data *problem_data;
  bitmap_head tmp;

  /* Note that TMP is _not_ a temporary bitmap if we end up replacing
 OUT with TMP.  Therefore, allocate TMP in the RD bitmaps obstack.  */
  problem_data = (struct df_rd_problem_data *) df_rd->problem_data;
  bitmap_initialize (&tmp, &problem_data->rd_bitmaps);

  bitmap_and_compl (&tmp, in, kill);
  EXECUTE_IF_SET_IN_BITMAP (sparse_kill, 0, regno, bi)
{
  bitmap_clear_range (&tmp,
  DF_DEFS_BEGIN (regno),
  DF_DEFS_COUNT (regno));
}
  bitmap_ior_into (&tmp, gen);
  changed = !bitmap_equal_p (&tmp, out);
  if (changed)
{
  bitmap_clear (out);
  bb_info->out = tmp;
}
  else
bitmap_clear (&tmp);

it looks like this "underflows" the counters.  It would be good to
have this abstracted into a bitmap_move () doing the proper accounting.
Trying if that fixes the above issue somewhat.

[Bug rtl-optimization/69904] [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ramana.radhakrishnan at arm 
dot co
   ||m

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #2)
> If you disallow this memory clobber from being copied (via the
> cannot_copy_insn_p hook), do you then get what you want?

Catching the memory barrier pattern in cannot_copy_insn_p does indeed get the
same sequence as GCC 5. But I don't see documentation for it in tm.texi ?

As for the single RTL insn idea, we keep the compare exchange operation as a
single insn up until after reload (to prevent the register allocator doing any
funny business with spills) and split if after reload.
We don't have precedent in the arm backend of keeping splittable insns any
further than that (for example until split4) and I don't know what splitting
predicate would look like for that.

Considering that the memory barrier insn is represented as a clobber of a
BLKmode MEM doesn't that conceptually mean that it potentially clobbers all of
memory and thus no memory operations should be moved past it?

[Bug tree-optimization/26854] Inordinate compile times on large routines

[rguenth at gcc dot gnu.org]

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

--- Comment #136 from Richard Biener  ---
Fixed bitmap stats look like

df-problems.c:4399 (df_md_alloc)4755456:  4.4%   4755456  
1842233:  7.3%  235730  124030  heap
df-problems.c:4398 (df_md_alloc)5085440:  4.7%   5085480  
1831405:  7.2%  242817  144125  heap
df-problems.c:4400 (df_md_alloc)7331576:  6.7%   7331576  
1905561:  7.5%  313524  195813  heap
df-problems.c:4402 (df_md_alloc)8224456:  7.5%   8224456  
1944135:  7.7%  253139  145564  heap
df-problems.c:4401 (df_md_alloc)8278944:  7.6%   8278944  
1961366:  7.7%  244665  128104  heap
tree-ssa-structalias.c:1134 (add_implicit_graph_9966464:  9.1%   9966464   
306806:  1.2%   30519 2554068  heap
tree-ssa-structalias.c:1149 (add_pred_graph_edge   10770848:  9.9%  10770848   
351339:  1.4%   29917 1239694  heap
lra-assigns.c:352 (init_lives) 18387720: 16.9%  18387720   
459901:  1.8%  229308   90251  heap

for _num.i at -O1.

[Bug middle-end/69915] New: [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[zsojka at seznam dot cz]

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

Bug ID: 69915
   Summary: [6 Regression] ICE: SIGSEGV with -O -ftracer with
broken backtrace
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -ftracer testcase.c testcase.c: In function 'foo':
testcase.c:4:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
 foo (unsigned x, unsigned c, V v)
 ^~~
testcase.c:4:1: internal compiler error: Segmentation fault
0xbbbe9f crash_signal
/repo/gcc-trunk/gcc/toplev.c:335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

(gdb) bt 
#0  0x76c50e88 in ?? ()
#1  0x76c50e88 in ?? ()
#2  0x76c50e88 in ?? ()
#3  0x76c50e88 in ?? ()
#4  0x76c50e88 in ?? ()
#5  0x006e in ?? ()
#6  0x023c4290 in ?? ()
#7  0x0040 in ?? ()
#8  0x76d54498 in ?? ()
#9  0x0002 in ?? ()
#10 0x76d7b5a0 in ?? ()
#11 0x76d7b5a0 in ?? ()
#12 0x7fffd030 in ?? ()
#13 0x in ?? ()

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233597-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233597-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20160222 (experimental) (GCC) 


Out of tested targets (powerpc{,64}, sparc{,64}, i686, arm), only
x86_64-pc-linux-gnu* and aarch64-unknown-linux-gnu seem to be affected.

Tested revisions:
trunk r233597 - ICE
trunk r230518 - ICE
5-branch r233596 - OK

[Bug middle-end/69915] [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu,|x86_64-pc-linux-gnu,
   |aarch64-unknown-linux-gnu   |aarch64-unknown-linux-gnu,
   ||arm-none-eab
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

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

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

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #1 from Daniel Gutson  
---
Remind to consider all the overloads (throwing, nothrow, etc.) which will
require different names.

[Bug target/69789] g++ -O2 is removing tests against a variable that can be changed

[tmark at isc dot org]

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

--- Comment #3 from Thomas Markwalder  ---
After further analysis we've discovered that the optimizer does not remove the
tests, it alters the comparison of (ec == enumerated value).   If one replaces
the "ec" with "ec.value()" in the expressions, such that you are explicitly
comparing the interger error value the code works correctly when optimized:

{{{
 :

// Retry operation if interrupted by signal.
if (ec.value() == boost::asio::error::interrupted)
  continue;

// Check if we need to run the operation again.
if (ec.value() == boost::asio::error::would_block
|| ec == boost::asio::error::try_again)
  return false;

 :
}}}

Alternatively, adding an inline operator:

{{{
  inline friend bool operator==( const error_code & lhs,
 const int & rhs ) BOOST_SYSTEM_NOEXCEPT
  {
return lhs.m_val == rhs;
  }
}}}

to error_code class also avoids the issue.

[Bug c/69911] [6 Regression] Massive test failures on ia32

[mark at gcc dot gnu.org]

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

--- Comment #3 from Mark Wielaard  ---
Author: mark
Date: Tue Feb 23 11:47:19 2016
New Revision: 233627

URL: https://gcc.gnu.org/viewcvs?rev=233627&root=gcc&view=rev
Log:
PR c/69911 Check main_input_filename and DECL_SOURCE_FILE are not NULL.

DECL_SOURCE_FILE can be NULL (for example when DECL_ARTIFICIAL).
So make sure to check before comparing against main_input_filename.

gcc/ChangeLog

PR c/69911
* cgraphunit.c (check_global_declaration): Check main_input_filename
and DECL_SOURCE_FILE are not NULL.

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

[Bug c/69911] [6 Regression] Massive test failures on ia32

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
fixed.

[Bug c/69914] ICE in check_global_declaration, upon -Wunused-variable of an array

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug c/69911] [6 Regression] Massive test failures on ia32

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #5 from Markus Trippelsdorf  ---
*** Bug 69914 has been marked as a duplicate of this bug. ***

[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 #72 from rguenther at suse dot de  ---
On Tue, 23 Feb 2016, Richard Biener wrote:

> On Tue, 23 Feb 2016, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> > 
> > --- Comment #70 from Jakub Jelinek  ---
> > If you want to go this way, I'd at least key it off DECL_COMMON on the decl.
> > And instead of multiplying max_size by 2 perhaps just add BITS_PER_UNIT?
> 
> Works for me.
> 
> > And only if it is equal to size?
> 
> That's already done.

Patch as posted passed bootstrap & regtest.  Adjusted according to 
comments but not tested otherwise - please somebody throw at
unpatched 416.gamess.

Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c  (revision 233620)
+++ gcc/tree-dfa.c  (working copy)
@@ -617,7 +617,20 @@ get_ref_base_and_extent (tree exp, HOST_
   if (maxsize == -1
  && DECL_SIZE (exp)
  && TREE_CODE (DECL_SIZE (exp)) == INTEGER_CST)
-   maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+   {
+ maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+ /* If we've seen a variable array ref and the above adjusted
+maxsize to size make sure the caller doesn't mistake this
+as a non-variable access by adjusting maxsize slightly.
+???  This is strictly pessimizing the case where a
+one element array is accessed with a variable index
+which should be a rare case in practice but hits legacy
+fortran code - see PR69368 for example.  */
+ if (seen_variable_array_ref
+ && maxsize == bitsize
+ && DECL_COMMON (exp))
+   maxsize += BITS_PER_UNIT;
+   }
 }
   else if (CONSTANT_CLASS_P (exp))
 {

[Bug libgomp/69916] New: [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[vries at gcc dot gnu.org]

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

Bug ID: 69916
   Summary: [openacc] ICE in single_succ_edge called from
oacc_loop_xform_loop
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

$ cat loop-clauses.c
int
main (void)
{

#pragma acc parallel
  {
int j;
#pragma acc loop private (j)
for (int i = 0; i < 10; i++)
  j++;
  }

  return 0;
}

$ gcc loop-clauses.c -fopenacc -S -O2 
loop-clauses.c: In function ‘main._omp_fn.0’:
loop-clauses.c:5:9: internal compiler error: in single_succ_edge, at
basic-block.h:351
 #pragma acc parallel
 ^~~
0xcf6d90 single_succ_edge
src/gcc/basic-block.h:351
0xcf6e0e single_succ
src/gcc/basic-block.h:371
0xd4eece oacc_loop_xform_loop
src/gcc/omp-low.c:20759
0xd4ef9f oacc_loop_process
src/gcc/omp-low.c:20781
0xd4ef2e oacc_loop_process
src/gcc/omp-low.c:20771
0xd4f888 execute_oacc_device_lower
src/gcc/omp-low.c:21085
0xd4fd74 execute
src/gcc/omp-low.c:21268
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libgomp/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, openacc

--- Comment #1 from vries at gcc dot gnu.org ---
AFAIU, valid code, so marking as ICE-on-valid-code.

[Bug middle-end/69915] [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/69912] [6 regression] ICE in build_ctor_subob_ref initializing a flexible array member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug target/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/69907] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

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

[Bug target/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
The wrong alias set appears in expr.c:10524
if (op0 == orig_op0)
  op0 = copy_rtx (op0);

set_mem_attributes (op0, exp, 0); /// < HERE

if (REG_P (XEXP (op0, 0)))
  mark_reg_pointer (XEXP (op0, 0), MEM_ALIGN (op0));

Before that op0 has the right alias set from expansion:
(mem:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -48 [0xffd0])) [1  S16 A128])
but after this
(mem/j/c:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -48 [0xffd0])) [2  S16 A128])
Alias set 1 is TYPE_ALIAS_SET of the V vector, 2 is TYPE_ALIAS_SET of the U
vector.
exp here is:
debug_generic_stmt (exp)
BIT_FIELD_REF <_7, 128, 128>;
where:
_7 = VIEW_CONVERT_EXPR(d.1_6);
I'd say that VIEW_CONVERT_EXPR expansion should make sure if it returns a MEM_P
that MEM_KEEP_ALIAS_SET is set on it at least if the TYPE_ALIAS_SET of the type
is different from MEM_ALIAS_SET.
And then BIT_FIELD_REF (and other handled_component_p expansion) should honor
MEM_KEEP_ALIAS_SET (or should that be set_mem_attributes_minus_bitpos itself),
and not adjust the alias set of the MEM.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mark at gcc dot gnu.org]

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

--- Comment #35 from Mark Wielaard  ---
Note the followup patch needed for PR c/69911
https://gcc.gnu.org/viewcvs?rev=233627&root=gcc&view=rev

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

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

--- Comment #36 from Mark Wielaard  ---
I believe the warning is perfect now.
If not, please feel free to reopen this issue.

[Bug middle-end/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org

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

Untested fix.

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

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Tue Feb 23 12:54:44 2016
New Revision: 233629

URL: https://gcc.gnu.org/viewcvs?rev=233629&root=gcc&view=rev
Log:
[pr 69666] No SRA default_def replacements for unscalarizable regions

2016-02-23  Martin Jambor  

PR tree-optimization/69666
* tree-sra.c (sra_modify_assign): Do not attempt to create
default_def replacements for unscalarizable regions.

testsuite/
* gcc.dg/tree-ssa/pr69666.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr69666.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-sra.c

[Bug tree-optimization/69907] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ok, we create an epilogue loop because of the gaps in p2[n*2]

t2.c:4:5: note: Data access with gaps requires scalar epilogue loop

but then SLP vectorize that epilogue which has been fully unrolled.

[Bug c/69900] [6 Regression] Unhelpful diagnostic about Ignored options

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 23 12:57:32 2016
New Revision: 233630

URL: https://gcc.gnu.org/viewcvs?rev=233630&root=gcc&view=rev
Log:
PR c/69900
* common.opt (Wunreachable-code): Add Warning flag.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69900.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/testsuite/ChangeLog

[Bug c++/69902] [6 Regression] Bogus -Wnonnull-compare for: dynamic_cast(&ref) == nullptr

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 23 12:58:53 2016
New Revision: 233631

URL: https://gcc.gnu.org/viewcvs?rev=233631&root=gcc&view=rev
Log:
PR c++/69902
* fold-const.c (fold_truth_not_expr): Propagate TREE_NO_WARNING
when inverting comparison.

* g++.dg/warn/Wnonnull-compare-5.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wnonnull-compare-5.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69902] [6 Regression] Bogus -Wnonnull-compare for: dynamic_cast(&ref) == nullptr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/69900] [6 Regression] Unhelpful diagnostic about Ignored options

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Tue, 23 Feb 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69909
> 
> --- Comment #8 from Jakub Jelinek  ---
> The wrong alias set appears in expr.c:10524
> if (op0 == orig_op0)
>   op0 = copy_rtx (op0);
> 
> set_mem_attributes (op0, exp, 0); /// < HERE
> 
> if (REG_P (XEXP (op0, 0)))
>   mark_reg_pointer (XEXP (op0, 0), MEM_ALIGN (op0));
> 
> Before that op0 has the right alias set from expansion:
> (mem:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
> (const_int -48 [0xffd0])) [1  S16 A128])
> but after this
> (mem/j/c:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
> (const_int -48 [0xffd0])) [2  S16 A128])
> Alias set 1 is TYPE_ALIAS_SET of the V vector, 2 is TYPE_ALIAS_SET of the U
> vector.
> exp here is:
> debug_generic_stmt (exp)
> BIT_FIELD_REF <_7, 128, 128>;
> where:
> _7 = VIEW_CONVERT_EXPR(d.1_6);
> I'd say that VIEW_CONVERT_EXPR expansion should make sure if it returns a 
> MEM_P
> that MEM_KEEP_ALIAS_SET is set on it at least if the TYPE_ALIAS_SET of the 
> type
> is different from MEM_ALIAS_SET.
> And then BIT_FIELD_REF (and other handled_component_p expansion) should honor
> MEM_KEEP_ALIAS_SET (or should that be set_mem_attributes_minus_bitpos itself),
> and not adjust the alias set of the MEM.

Nah, the thing to notice here is that

BIT_FIELD_REF <_7, 128, 128>;

is not a memory reference and thus set_mem_attributes should never
derive any memory attributes from it

[Bug middle-end/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #10)
> On Tue, 23 Feb 2016, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69909
> > 
> > --- Comment #8 from Jakub Jelinek  ---
> > The wrong alias set appears in expr.c:10524
> > if (op0 == orig_op0)
> >   op0 = copy_rtx (op0);
> > 
> > set_mem_attributes (op0, exp, 0); /// < HERE
> > 
> > if (REG_P (XEXP (op0, 0)))
> >   mark_reg_pointer (XEXP (op0, 0), MEM_ALIGN (op0));
> > 
> > Before that op0 has the right alias set from expansion:
> > (mem:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
> > (const_int -48 [0xffd0])) [1  S16 A128])
> > but after this
> > (mem/j/c:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
> > (const_int -48 [0xffd0])) [2  S16 A128])
> > Alias set 1 is TYPE_ALIAS_SET of the V vector, 2 is TYPE_ALIAS_SET of the U
> > vector.
> > exp here is:
> > debug_generic_stmt (exp)
> > BIT_FIELD_REF <_7, 128, 128>;
> > where:
> > _7 = VIEW_CONVERT_EXPR(d.1_6);
> > I'd say that VIEW_CONVERT_EXPR expansion should make sure if it returns a 
> > MEM_P
> > that MEM_KEEP_ALIAS_SET is set on it at least if the TYPE_ALIAS_SET of the 
> > type
> > is different from MEM_ALIAS_SET.
> > And then BIT_FIELD_REF (and other handled_component_p expansion) should 
> > honor
> > MEM_KEEP_ALIAS_SET (or should that be set_mem_attributes_minus_bitpos 
> > itself),
> > and not adjust the alias set of the MEM.
> 
> Nah, the thing to notice here is that
> 
> BIT_FIELD_REF <_7, 128, 128>;
> 
> is not a memory reference and thus set_mem_attributes should never
> derive any memory attributes from it

That is, this has nothing to do with VIEW_CONVERT_EXPRs, even if there were
no VCE but _7 were defined as

 _7 = MEM[(XXX *)p_1 + ...];

that BIT_FIELD_REF may not be used to set mem attributes on the MEM expanded
for _7.

[Bug rtl-optimization/69904] [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

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

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
Fixed.

[Bug middle-end/69909] [6 Regression] wrong code with -Os and vectors @ x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #37766|0   |1
is obsolete||

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

Different approach.

[Bug fortran/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 #73 from Dominique d'Humieres  ---
> Patch as posted passed bootstrap & regtest.  Adjusted according to 
> comments but not tested otherwise

The patch "fixes" the test in comment 45, but not the one in comment 61.

[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 #74 from rguenther at suse dot de  ---
On Tue, 23 Feb 2016, dominiq at lps dot ens.fr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #73 from Dominique d'Humieres  ---
> > Patch as posted passed bootstrap & regtest.  Adjusted according to 
> > comments but not tested otherwise
> 
> The patch "fixes" the test in comment 45, but not the one in comment 61.

It's expected that it doesn't fix the one w/o /COMMON/

[Bug fortran/69910] ICE with NEWUNIT

[epagone at email dot it]

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

epagone at email dot it changed:

   What|Removed |Added

 CC||epagone at email dot it

--- Comment #4 from epagone at email dot it ---
A workaround is substituting this excerpt

  case ('scratch')
open(newunit=funit, status=fstatus, access='sequential', &
  form='formatted', iostat=istat)

with the following 

  case ('scratch')
open(newunit=funit, status='scratch', access='sequential', &
  form='formatted', iostat=istat)

[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

--- Comment #75 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #74)
> On Tue, 23 Feb 2016, dominiq at lps dot ens.fr wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> > 
> > --- Comment #73 from Dominique d'Humieres  ---
> > > Patch as posted passed bootstrap & regtest.  Adjusted according to 
> > > comments but not tested otherwise
> > 
> > The patch "fixes" the test in comment 45, but not the one in comment 61.
> 
> It's expected that it doesn't fix the one w/o /COMMON/

The #c61 testcase is with /COMMON/ too.  But doesn't really use
get_ref_base_and_extent for the optimization, but array_at_struct_end_p.
Which is why I've suggested to Alan on gcc-patches to tweak those two places
for -funknown-commons.

[Bug target/69917] New: gcc.target/i386/chkp-hidden-def.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 69917
   Summary: gcc.target/i386/chkp-hidden-def.c FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.*
Target: i386-pc-solaris2.*
 Build: i386-pc-solaris2.*

Since about 20160122 the gcc.target/i386/chkp-hidden-def.c test FAILs on
Solaris/x86:

FAIL: gcc.target/i386/chkp-hidden-def.c scan-assembler-not test.chkp

both for 32 and 64-bit, irrespective of assembler used.  This was probably
triggered by

2016-01-20  H.J. Lu  

PR testsuite/69366
* g++.dg/pr63995-1.C: Require non-x32 target, instead of,
the MPX run-time library, for compile-time MPX test.
[...]
* gcc.target/i386/chkp-hidden-def.c: Likewise.

The same failure is present on the gcc-5 branch.

Comparing the assembler output between Linux and Solaris, I find

--- chkp-hidden-def.s.linux 2016-02-21 23:30:38.73858 +0100
+++ chkp-hidden-def.s   2016-02-21 23:33:54.305250251 +0100
@@ -5,19 +5,15 @@
.hidden __test
.type   __test, @function
 __test:
-.LFB1:
-   .cfi_startproc
movl4(%esp), %eax
bndldx  4(%esp,%eax), %bnd0
bndcl   (%eax), %bnd0
bndcu   3(%eax), %bnd0
movl(%eax), %eax
bnd ret
-   .cfi_endproc
-.LFE1:
.size   __test, .-__test
.globl  test
-   .settest,__test
+   .settest.chkp,__test
.weak   __chkp_none_bounds
.section   
.rodata.__chkp_none_bounds,"aG",@progbits,__chkp_none_bounds,comdat
.align 8
@@ -34,4 +30,3 @@
 __chkp_zero_bounds:
.zero   8
.ident  "GCC: (GNU) 6.0.0 20160219 (experimental) [trunk revision
233556]"
-   .section.note.GNU-stack,"",@progbits

No idea yet why Linux would behave differently here.  All other mpx compile
tests
pass on Solaris just as well.

  Rainer

[Bug target/69917] gcc.target/i386/chkp-hidden-def.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/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 #76 from Dominique d'Humieres  ---
> The #c61 testcase is with /COMMON/ too.

Well the test aborts for me on x86_64-apple-darwin15 (I still get 1025.0).
AFAIR some default sizes are larger on darwin than on linux.

[Bug middle-end/69915] [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r229574.

[Bug c/69918] [6 regression] gcc.dg/torture/builtin-integral-1.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c/69918] New: [6 regression] gcc.dg/torture/builtin-integral-1.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 69918
   Summary: [6 regression] gcc.dg/torture/builtin-integral-1.c
FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.*
Target: i386-pc-solaris2.*
 Build: i386-pc-solaris2.*

Since about 20160120, the gcc.dg/torture/builtin-integral-1.c FAILs on 32-bit
Solaris/x86:

FAIL: gcc.dg/torture/builtin-integral-1.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/builtin-integral-1.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/builtin-integral-1.c   -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/builtin-integral-1.c   -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.dg/torture/builtin-integral-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/builtin-integral-1.c   -Os  (test for excess errors)

All failures are like

Excess errors:
Undefined   first referenced
 symbol in file
link_failure/var/tmp//ccGNG4Sa.o
ld: fatal: symbol referencing errors

This was introduced by

2016-01-17 John David Anglin  

* gcc.dg/torture/builtin-integral-1.c: Require c99_runtime.

Omitting the -std=c99 lets the test PASS again.

  Rainer

[Bug target/69917] gcc.target/i386/chkp-hidden-def.c FAILs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.*  |i386-pc-solaris2.*
   ||x86_64-apple-darwin15
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
   Host|i386-pc-solaris2.*  |i386-pc-solaris2.*
   ||x86_64-apple-darwin15
 Ever confirmed|0   |1
  Build|i386-pc-solaris2.*  |i386-pc-solaris2.*
   ||x86_64-apple-darwin15

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on x86_64-apple-darwin15.

[Bug target/69917] gcc.target/i386/chkp-hidden-def.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Dominique d'Humieres  ---
> Confirmed on x86_64-apple-darwin15.

I don't think so: in my x86_64-apple-darwin15.4.0 builds, the test fails
like this:

FAIL: gcc.target/i386/chkp-hidden-def.c (test for excess errors)
UNRESOLVED: gcc.target/i386/chkp-hidden-def.c scan-assembler-not test.chkp

which strongly suggests the missing alias support fixed by

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01570.html

Rainer

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[dhowells at redhat dot com]

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

dhowells at redhat dot com  changed:

   What|Removed |Added

 CC||dhowells at redhat dot com

--- Comment #15 from dhowells at redhat dot com  ---
(In reply to Andreas Schwab from comment #7)
> ...
> In file included from ../../../libgcc/libgcc2.c:56:0:
> ../../../libgcc/libgcc2.c: In function ‘__mulvsi3’:
> ../../../libgcc/libgcc2.h:208:19: internal compiler error: in
> maybe_legitimize_operand, at optabs.c:6893
>  #define __NW(a,b) __ ## a ## si ## b
>^
> ../../../libgcc/libgcc2.h:299:19: note: in expansion of macro ‘__NW’
>  #define __mulvSI3 __NW(mulv,3)
>^~~~
> ../../../libgcc/libgcc2.c:152:1: note: in expansion of macro ‘__mulvSI3’
>  __mulvSI3 (Wtype a, Wtype b)
>  ^
> 0x9ab2ce maybe_legitimize_operand
> ../../gcc/optabs.c:6893
> ...

I'm seeing exactly this backtrace also building Fedora the cross-gcc-6 m68k
target, but the error goes away with the patch from bug 69885.

[Bug rtl-optimization/69904] [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to ktkachov from comment #3)
> (In reply to Segher Boessenkool from comment #2)
> > If you disallow this memory clobber from being copied (via the
> > cannot_copy_insn_p hook), do you then get what you want?
> 
> Catching the memory barrier pattern in cannot_copy_insn_p does indeed get
> the same sequence as GCC 5.

Good to hear.  This, together with this pattern being a very late split as
you say, sounds to me like a good way forward.  Probably make some special
unspec for this to not pessimise other barrier uses.

> But I don't see documentation for it in tm.texi ?

It is DEFHOOK_UNDOC in target.def, although it does have documentation.
It is the only undoc hook there that does not say "documenting this
requires a GFDL license grant".  Maybe just an oversight.  The doc is a
trivial one-liner anyway.

> Considering that the memory barrier insn is represented as a clobber of a
> BLKmode MEM doesn't that conceptually mean that it potentially clobbers all
> of memory and thus no memory operations should be moved past it?

Yes, but shrink-wrapping isn't actually moving any instructions; it decides
where to put *new* instructions.  Putting the prologue later than some barrier
is perfectly well and good in general, and quite beneficial.

[Bug middle-end/69919] New: pool allocator and mem-stat race at program exit

[rguenth at gcc dot gnu.org]

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

Bug ID: 69919
   Summary: pool allocator and mem-stat race at program exit
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

==16301== Invalid read of size 8
==16301==at 0x843457:
mem_alloc_description::release_instance_overhead(void*, unsigned
long, bool) (mem-stats.h:513)
==16301==by 0x8427C4: base_pool_allocator::release()
(alloc-pool.h:311)
==16301==by 0x84299D:
base_pool_allocator::~base_pool_allocator()
(alloc-pool.h:335)
==16301==by 0x844E1B: object_allocator::~object_allocator()
(alloc-pool.h:474)
==16301==by 0x5E13058: __run_exit_handlers (in /lib64/libc-2.18.so)
==16301==by 0x5E130A4: exit (in /lib64/libc-2.18.so)
==16301==by 0x5DFCBEB: (below main) (in /lib64/libc-2.18.so)
==16301==  Address 0x72529b0 is 1,088 bytes inside a block of size 3,048 free'd
==16301==at 0x4C28ADC: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16301==by 0x844C81: xcallocator, simple_hashmap_traits, mem_usage_pair > >::hash_entry>::data_free(hash_map,
simple_hashmap_traits,
mem_usage_pair > >::hash_entry*) (hash-table.h:273)
==16301==by 0x14DC512: hash_table, simple_hashmap_traits, mem_usage_pair > >::hash_entry,
xcallocator>::~hash_table() (hash-table.h:627)
==16301==by 0x14DCD77: hash_map,
simple_hashmap_traits,
mem_usage_pair > >::~hash_map() (hash-map.h:26)
==16301==by 0x14DCE52:
mem_alloc_description::~mem_alloc_description() (mem-stats.h:559)
==16301==by 0x5E13058: __run_exit_handlers (in /lib64/libc-2.18.so)
==16301==by 0x5E130A4: exit (in /lib64/libc-2.18.so)
==16301==by 0x5DFCBEB: (below main) (in /lib64/libc-2.18.so)

[Bug middle-end/69920] New: [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[hjl.tools at gmail dot com]

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

Bug ID: 69920
   Summary: [6 Regression] FAIL: g++.dg/torture/pr42704.C   -O2
-flto -fno-use-linker-plugin -flto-partition=none
(internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86, r233626 gave

FAIL: g++.dg/torture/pr42704.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: g++.dg/torture/pr42704.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/torture/pr42704.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
FAIL: g++.dg/torture/pr42704.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: g++.dg/torture/pr42704.C   -O2  (internal compiler error)
FAIL: g++.dg/torture/pr42704.C   -O2  (test for excess errors)
FAIL: g++.dg/torture/pr42704.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: g++.dg/torture/pr42704.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/torture/pr42704.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr42704.C   -O3 -g  (test for excess errors)

r233620 is good.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

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

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
 CC||nathan at gcc dot gnu.org
  Component|libgomp |middle-end
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
Confirmed.  Well, j has an undefined value, but that shouldn't cause an ICE.

Without having looked at any dump files, I guess that GCC optimizes away the
unused increment of j, optimizes away the whole for loop, and is left with an
"empty" OMP_FOR (OACC_LOOP) construct, which possibly confuses the OpenACC loop
partitioning code.  Nathan, do you want to have a look?

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #1 from Richard Biener  ---
Too much C++ here I guess?

==16301==by 0x14DCE52:
mem_alloc_description::~mem_alloc_description() (mem-stats.h:559)

vs.

==16301==by 0x8427C4: base_pool_allocator::release()
(alloc-pool.h:311)
==16301==by 0x84299D:
base_pool_allocator::~base_pool_allocator()
(alloc-pool.h:335)
==16301==by 0x8E25D3: object_allocator::~object_allocator()
(alloc-pool.h:474)

where the latter calls release_instance_overhead.

extern mem_alloc_description pool_allocator_usage;

comes from alloc-pool.c.  Looks like when linking LTO we get the bad destructor
order (by luck?).

Leaking pool_allocator_usage will fix this (making it a reference).  A very
bit ugly though.

Index: gcc/alloc-pool.c
===
--- gcc/alloc-pool.c(revision 233633)
+++ gcc/alloc-pool.c(working copy)
@@ -24,7 +24,7 @@ along with GCC; see the file COPYING3.
 #include "alloc-pool.h"

 ALLOC_POOL_ID_TYPE last_id;
-mem_alloc_description pool_allocator_usage;
+mem_alloc_description &pool_allocator_usage = *(new
mem_alloc_description);

 /* Output per-alloc_pool memory usage statistics.  */
 void
Index: gcc/alloc-pool.h
===
--- gcc/alloc-pool.h(revision 233633)
+++ gcc/alloc-pool.h(working copy)
@@ -95,7 +95,7 @@ struct pool_usage: public mem_usage
   const char *m_pool_name;
 };

-extern mem_alloc_description pool_allocator_usage;
+extern mem_alloc_description &pool_allocator_usage;

 #if 0
 /* If a pool with custom block size is needed, one might use the following

[Bug middle-end/69915] [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Mine.

[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 #77 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #72)
> 
> Patch as posted passed bootstrap & regtest.  Adjusted according to 
> comments but not tested otherwise - please somebody throw at
> unpatched 416.gamess.

Still miscompares on aarch64, I'm afraid. (Both with and without
-fno-aggressive-loop-optimizations.)

Also where Jakub wrote:
> If you want to go this way, I'd at least key it off DECL_COMMON on the decl.
> And instead of multiplying max_size by 2 perhaps just add BITS_PER_UNIT?

I wonder why you prefer setting such an arbitrary guess at max_size rather than
going with -1 which is defined as "unknown" ?

[Bug c++/69736] [4.9/5/6 Regression] "error: too few arguments to function" in c++14 but not c++11

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-23
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Patrick Palka  ---
A patch is posted at: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01587.html

[Bug middle-end/69915] [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
(In reply to H.J. Lu from comment #1)
> It may be caused by r233626.

What do you mean by "may be?"  I have just double checked that if I
apply the patch to r233489 and run the test, it passes here on my
x86_64-linux.

Anyway, once I move to a newer trunk (in a day or three), I'll check
again by reverting the change... unless someone finds a different
culprit in the meantime.

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Or maybe simply making mem_alloc_description::~mem_alloc_description () empty.

[Bug middle-end/69921] New: Switch OpenACC kernels number of gangs from "decide at run time" to "decide at compile time"

[tschwinge at gcc dot gnu.org]

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

Bug ID: 69921
   Summary: Switch OpenACC kernels number of gangs from "decide at
run time" to "decide at compile time"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: nathan at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---

Follow-up to r233634.  See
.

For OpenACC kernels, gcc/tree-parloops.c:create_parallel_loop currently sets:

OMP_CLAUSE_NUM_GANGS_EXPR (clause) = n_threads;

..., so to zero ("decide at run time").

| Originally, I want to use:
| 
| OMP_CLAUSE_NUM_GANGS_EXPR (clause) = build_int_cst (integer_type_node,
n_threads == 0 ? -1 : n_threads);
| 
| ... to store -1 "have the compiler decidew" (instead of now 0 "have the
| run-time decide", which might prevent some code optimizations, as I
| understand it) for the n_threads == 0 case, but it seems that for an
| offloaded OpenACC kernels region, gcc/omp-low.c:oacc_validate_dims is
| called with the parameter "used" set to 0 instead of "gang", and then the
| "Default anything left to 1 or a partitioned default" logic will default
| dims["gang"] to oacc_min_dims["gang"] (that is, 1) instead of the
| oacc_default_dims["gang"] (that is, 32).  Nathan, does that smell like a
| bug (and could you look into that)?

[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 #78 from rguenther at suse dot de  ---
On Tue, 23 Feb 2016, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #77 from alalaw01 at gcc dot gnu.org ---
> (In reply to rguent...@suse.de from comment #72)
> > 
> > Patch as posted passed bootstrap & regtest.  Adjusted according to 
> > comments but not tested otherwise - please somebody throw at
> > unpatched 416.gamess.
> 
> Still miscompares on aarch64, I'm afraid. (Both with and without
> -fno-aggressive-loop-optimizations.)
> 
> Also where Jakub wrote:
> > If you want to go this way, I'd at least key it off DECL_COMMON on the decl.
> > And instead of multiplying max_size by 2 perhaps just add BITS_PER_UNIT?
> 
> I wonder why you prefer setting such an arbitrary guess at max_size rather 
> than
> going with -1 which is defined as "unknown" ?

That would pessimize it too much IMHO.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-23
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Jambor  ---
Ah, I missed the "x86" part (when the target field is not filled in, I
always tend to think it's x86_64).  I can reproduce the failure now
and will take care of it.

[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 #79 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #78)
>
> That would pessimize it too much IMHO.

I'm not sure how to evaluate the pessimization, given it's thought to be a
widespread pseudo-FORTRAN construct; so I probably have to defer to your
judgement here. However...

Given maxsize of an array as two elements, say, would the compiler not be
entitled to optimize an index selection down to, say, computing only the LSBit
of the actual index?  Whereas 'unknown' means, well, exactly what is the case.
So I fear this is storing problems up for the future.

Is the concern that we can't hide this behind an option, as that would "drive
people away from gfortran" ? If that's the case, can we hide it behind an
option that defaults to pessimization (?? at least for fortran)??

[Bug c++/69922] New: Bogus -Wnonnull-compare for: ... ? static_cast(this) : nullptr

[sbergman at redhat dot com]

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

Bug ID: 69922
   Summary: Bogus -Wnonnull-compare for: ... ?
static_cast(this) : nullptr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With trunk@233631:

> $ cat test.cc
> struct S2 { virtual ~S2(); };
> struct S1 {
> virtual ~S1();
> S2 * f(bool);
> };
> struct S3: S1, S2 {};
> S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }

> $ g++ -Werror -Wnonnull-compare -c test.cc
> test.cc: In member function ‘S2* S1::f(bool)’:
> test.cc:7:59: error: nonnull argument ‘this’ compared to NULL 
> [-Werror=nonnull-compare]
>  S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }
>^~~
> cc1plus: all warnings being treated as errors

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
With the patch in comment 6 the test gfortran.dg/include_6.f90 has to be
updated to

--- ../_clean/gcc/testsuite/gfortran.dg/include_6.f90   2012-08-02
01:26:03.0 +0200
+++ gcc/testsuite/gfortran.dg/include_6.f90 2016-02-23 16:32:18.0
+0100
@@ -1,5 +1,5 @@
 ! { dg-do compile }
 ! { dg-options "-I gfortran.log" }
-! { dg-warning "is not a directory" "" { target *-*-* } 0 }
+! { dg-error "is not a directory" "" { target *-*-* } 0 }
 end 
-
+! { dg-prune-output "compilation terminated." }

[Bug c++/69922] Bogus -Wnonnull-compare for: ... ? static_cast(this) : nullptr

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Jakub, can you please check all the different C++ casts for similar issues?

dynamic_cast (should be fine now)
reinterpret_cast
static_cast
const_cast

[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Hmm, I think it's rather discover_iteration_bound_by_body_walk that merges the
two estimates of 3 iterations from both arms even though those are not based
off the same IV.  OTOH the estimates itself assume we are talking about the
first N iterations not any N iterations.  So it might be fundamentally flawed.

Testsuite fallout from the patch which shows recording those upper bounds was
intended:

FAIL: gcc.dg/tree-ssa/cunroll-10.c scan-tree-dump-times cunroll "Forced
statemen
t unreachable" 2
FAIL: gcc.dg/tree-ssa/cunroll-11.c scan-tree-dump cunroll "Loop 1 iterates at
mo
st 3 times"
FAIL: gcc.dg/tree-ssa/cunroll-9.c scan-tree-dump-times cunrolli "Removed
pointle
ss exit:" 1
FAIL: gcc.dg/tree-ssa/loop-38.c scan-tree-dump cunrolli "Loop 1 iterates at
most
 11 times"

Honza?

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[edlinger at gcc dot gnu.org]

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

--- Comment #23 from Bernd Edlinger  ---
Author: edlinger
Date: Tue Feb 23 15:57:09 2016
New Revision: 233636

URL: https://gcc.gnu.org/viewcvs?rev=233636&root=gcc&view=rev
Log:
2016-02-23  Bernd Edlinger  

PR libstdc++/69881
* include/c_global/cstdarg: Undefine __need___va_list.
* include/c_global/cstddef: Undefine all kinds of __need_*.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/c_global/cstdarg
trunk/libstdc++-v3/include/c_global/cstddef