[Bug tree-optimization/68493] [6 Regression] [graphite] ICE in copy_loop_phi_args

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #2 from Sebastian Pop  ---
fixed in r230772.

[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #7 from Sebastian Pop  ---
Fixed in r230771

[Bug target/67808] LRA ICEs on simple double to long double conversion test case

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Mon Nov 23 19:25:32 2015
New Revision: 230769

URL: https://gcc.gnu.org/viewcvs?rev=230769=gcc=rev
Log:
[gcc]
2015-11-23  Michael Meissner  

Backport from mainline
2015-10-05  Michael Meissner  
Peter Bergner  

PR target/67808
* config/rs6000/rs6000.md (extenddftf2): In the expander, only
allow registers, but provide insns for the combiner to create for
loads from memory. Separate VSX code from non-VSX code. For
non-VSX code, combine extenddftf2_fprs into extenddftf2 and rename
externaldftf2_internal to externaldftf2_fprs. Reorder constraints
so that registers come before memory operations. Drop support from
converting DFmode to TFmode, if the DFmode value is in a GPR
register.
(extenddftf2_fprs): Likewise.
(extenddftf2_internal): Likewise.
(extenddftf2_vsx): Likewise.
(extendsftf2): In the expander, only allow registers, but provide
insns for the combiner to create for stores and loads.

[gcc/testsuite]
2015-11-23  Michael Meissner  

2015-10-05  Michael Meissner  
Peter Bergner 

PR target/67808
* gcc.target/powerpc/pr67808.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr67808.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/59828] Broken assembly on ppc* with two -mcpu= options

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|5.3 |6.0

--- Comment #5 from Segher Boessenkool  ---
Fixed; no backport to 5 planned.

[Bug sanitizer/59302] tsan: Unexpected mmap in InternalAllocator!

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

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

--- Comment #5 from Joost VandeVondele  
---
I suppose this is fixed by now, haven't seen it again.

[Bug target/67071] GCC misses an optimization to load vector constants

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #3 from David Edelsohn  ---
Fixed.

[Bug c++/55077] implement and enable by default -Wliteral-conversion

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to Manuel López-Ibáñez from comment #5)
> Created attachment 33637 [details]
> untested patch
> 
> Untested patch. Bonus points if we show the value before and after
> conversion like clang does.

I tried out the patch by building a test compiler and
then building the current Linux kernel. 

Trivial problem with doubled tokens (&& &&), but the main problem is that the
patch doesn't fix the problem I described of double and float literals
into integral types.

Also, plenty of false positives for integer into smaller integral types,
for example integer into short or integer into char. 

For example, the patch warns for this reasonable code:

 charVariable = 0x80;

As is, I would not use the patch, but maybe with some further work,
it might be suitable for future use.

[Bug go/68496] [libgo] reflect test fails on Linux x86-64

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
I can not recreate this problem.  It works fine for me.

The stack trace is incomplete for some reason so I don't know what is going
wrong.

If you cd into x86_64-pc-linux-gnu/libgo, you can run
make GOTESTFLAGS="--keep" reflect/check
Presumably that will fail.  It will leave behind a gotest directory.  In
that directory you will find an a.out executable.  Running that executable runs
the test (you may have to set LD_LIBRARY_PATH so that it finds libgo.so).  Try
running that executable under gdb and see if you can get a better backtrace.

[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values

[jwyatt at feralinteractive dot com]

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

--- Comment #5 from Jason Wyatt  ---
When parsing the initialisation of const TestStruct var:
  store_init_value ends up calling split_nonconstant_init, so that only the
constant part of the initialisation of var is stored in DECL_INITIAL(t).

Then when parsing the initialisation of the array, maybe_constant_init
eventually calls through to decl_constant_value(t), i.e. constant_value_1(t,
false, true). That then uses DECL_INITIAL(t) as if it were the whole
initialisation, rather than just the constant part, hence all the non constant
parts aren't initialised correctly.

I've got no idea how this is supposed to work though, presumably at some point
in the chain of calls it's supposed to realise this is not a constant?

[Bug go/68496] [libgo] reflect test fails on Linux x86-64

[ismail at i10z dot com]

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

--- Comment #2 from İsmail Dönmez  ---
(In reply to Ian Lance Taylor from comment #1)
> I can not recreate this problem.  It works fine for me.
> 
> The stack trace is incomplete for some reason so I don't know what is going
> wrong.
> 
> If you cd into x86_64-pc-linux-gnu/libgo, you can run
> make GOTESTFLAGS="--keep" reflect/check
> Presumably that will fail.  It will leave behind a gotest directory.  In
> that directory you will find an a.out executable.  Running that executable
> runs the test (you may have to set LD_LIBRARY_PATH so that it finds
> libgo.so).  Try running that executable under gdb and see if you can get a
> better backtrace.

Try export MALLOC_CHECK_=2 before testing. Backtrace shows an invalid free:

(gdb) bt
#0  0x7f8d36c51d38 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x7f8d36c5318a in __GI_abort () at abort.c:78
#2  0x7f8d36c960b0 in malloc_printerr (action=,
str=0x7f8d36d840fa "free(): invalid pointer", ptr=, ar_ptr=) at malloc.c:5004
#3  0x00433298 in reflect.call.N13_reflect.Value
(pointer=pointer@entry=0xc2080c56a0, op=..., param=...) at value.go:4
50
#4  0x004328d4 in reflect.Call.N13_reflect.Value
(pointer=pointer@entry=0x7f8d33da0c40, in=...) at value.go:300
#5  0x0044ec3a in reflect_test.TestCallWithStruct (t=)
at all_test.go:1492
#6  0x7f8d37e6f71c in testing.tRunner (test=0xc20807a318, param=) at ../../../libgo/go/testing/testing.go:4
55
#7  testing.$thunk15 (__go_thunk_parameter=) at
../../../libgo/go/testing/testing.go:560
#8  0x7f8d37d8fa9c in kickoff () at ../../../libgo/runtime/proc.c:235
#9  0x7f8d3812a135 in __morestack () at
../../../libgcc/config/i386/morestack.S:544
#10 0x7f8d36c62900 in ?? () from /lib64/libc.so.6
#11 0x in ?? ()

[Bug target/36358] -mvrsave / -mno-vrsave ignored

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Segher Boessenkool  ---
This is long fixed.  Thanks for the report.

[Bug middle-end/68314] [6 Regression] Invalid read in build_pbb_minimal_scattering_polyhedrons (graphite-sese-to-poly.c:148)

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
This patch exposes the problem without valgrind:

diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index 2054fad..b932dae 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -143,6 +143,9 @@ build_pbb_minimal_scattering_polyhedrons (isl_aff
*static_sched, poly_bb_p pbb,
  /* False for loop dimension.  */
  sequence_and_loop_dims[i + j] = false;
}
+
+  gcc_assert (nb_sequence_dim > j);
+
   /* Fake loops make things shifted by one.  */
   if (sequence_dims && sequence_dims[j] == i)
sequence_and_loop_dims[i + j] = true;

[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation

[arnout at mind dot be]

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

--- Comment #2 from Arnout Vandecappelle  ---
Created attachment 36813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36813=edit
Preprocessed source file that exposes the bug

Attached preprocessed source file.

Compilation output (with gcc 4.9.3; I also tried with 5.2.0 with the same
result):

$
../../../../host/opt/ext-toolchain/bin/microblazeel-buildroot-linux-gnu-g++.br_real
  -O1 -g -c -v btSoftBody.ii
Using built-in specs.
COLLECT_GCC=../../../../host/opt/ext-toolchain/bin/microblazeel-buildroot-linux-gnu-g++.br_real
Target: microblazeel-buildroot-linux-gnu
Configured with: ./configure
--prefix=/opt/br-microblaze-full-2015.08-647-gc356fb2/usr
--sysconfdir=/opt/br-microblaze-full-2015.08-647-gc356fb2/etc --enable-static
--target=microblazeel-buildroot-linux-gnu
--with-sysroot=/opt/br-microblaze-full-2015.08-647-gc356fb2/usr/microblazeel-buildroot-linux-gnu/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--with-gmp=/opt/br-microblaze-full-2015.08-647-gc356fb2/usr
--with-mpfr=/opt/br-microblaze-full-2015.08-647-gc356fb2/usr
--with-pkgversion='Buildroot 2015.11-git-00647-gc356fb2'
--with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath --enable-tls
--disable-libmudflap --enable-threads
--with-mpc=/opt/br-microblaze-full-2015.08-647-gc356fb2/usr --without-isl
--without-cloog --disable-decimal-float --enable-languages=c,c++
--with-build-time-tools=/opt/br-microblaze-full-2015.08-647-gc356fb2/usr/microblazeel-buildroot-linux-gnu/bin
--enable-shared --disable-libgomp
Thread model: posix
gcc version 4.9.3 (Buildroot 2015.11-git-00647-gc356fb2) 
COLLECT_GCC_OPTIONS='-O1' '-g' '-c' '-v' '-shared-libgcc'

/gentoo/home2/arnout/br-out/bullet/host/opt/ext-toolchain/bin/../libexec/gcc/microblazeel-buildroot-linux-gnu/4.9.3/cc1plus
-fpreprocessed btSoftBody.ii -quiet -dumpbase btSoftBody.ii -auxbase btSoftBody
-g -O1 -version -o /tmp/ccHn1vcs.s
GNU C++ (Buildroot 2015.11-git-00647-gc356fb2) version 4.9.3
(microblazeel-buildroot-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Buildroot 2015.11-git-00647-gc356fb2) version 4.9.3
(microblazeel-buildroot-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a3940dfdf166fdf4d5b4711c8bdc0b77

[Bug target/33236] -mminimal-toc register should be psedu-register

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed|2007-08-30 21:15:01 |2015-11-23
 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
Still happens.

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #16)
> For what its worth:
> 
> $ gfc pr51119.f90 -lblas -fno-external-blas -Ofast -march=native 
> $ ./a.out 
>  Time, MATMUL:21.2483196   21.25444964601 1.5055670945599979
> 
>  Time, dgemm:33.2441711   33.24308728902  .96260614189671445
> 

Running a sample matrix multiply program on this same platform using the
default OpenCL (Mesa on Fedora 22) the machine is achieving:

64 x 64  2.76 Gflops
1000 x 1000  14.10
2000 x 2000  24.4

[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
*** Bug 68328 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |DUPLICATE

--- Comment #10 from Jeffrey A. Law  ---
Same issue as 68194.

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

[Bug rtl-optimization/68185] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |DUPLICATE

--- Comment #4 from Jeffrey A. Law  ---
Same issue as 68194.

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

[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
*** Bug 68185 has been marked as a duplicate of this bug. ***

[Bug c++/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Vladimir Sedach from comment #2)
> It is not just about "long long".

It isn't about long long at all, it is about whether your code is valid. In
your latest example, you are casting an int* to a float*, that's pretty much
the definition of an aliasing violation.

The types __m128 etc are documented as allowing aliasing, but I don't think
that extends to other operands of the intrinsics.

[Bug libstdc++/68479] Dynamic loading multiple shared libraries with identical static libstdc++ breaks streams

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I don't think this is intended to work when you re-export the
libstdc++ symbols.  Not sure if there is an easy way to make them hidden
with --begin-group/--end-group and a linker flag.  So you'd need to provide
a version script to the link of x.so and y.so.

[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||microblaze
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Waiting for at least a preprocessed source file and the compile output with -v
appended.

[Bug libfortran/51119] MATMUL slow for large matrices

[tkoenig at gcc dot gnu.org]

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

--- Comment #21 from Thomas Koenig  ---

> Hidden behind a -fexternal-blas-n switch might be an option. Including GPUs
> seems even a tad more tricky. We have a paper on GPU (small) matrix
> multiplication, http://dbcsr.cp2k.org/_media/gpu_book_chapter_submitted.pdf

Quite interesting what can be done with GPUs...

> . BTW, another interesting project is the libxsmm library more aimed at
> small (<128) matrices see : https://github.com/hfp/libxsmm . Not sure if
> this info is useful in this context, but it might provide inspiration.

I assume that for  small matrices bordering on the silly
(say, a matrix multiplication with dimensions of (1,2) and (2,1))
the inline code will be faster if the code is compiled with the
right options, due to function call overhead.  I also assume that
libxsmm will become faster quite soon for bigger sizes.

Do you have an idea where the crossover is?

[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

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

[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
On i?86 this regressed with r217509, aka part of VEC_RSHIFT_EXPR removal.
Guess we'll need to have a look at the i?86 vec perm handling.

[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Ah, no, the problem is not on the backend side, but during veclower2 pass.
Before that pass we after the replacement of v>> 64 or v>>32 shifts we have:
  vect_sum_15.12_58 = VEC_PERM_EXPR ;
  vect_sum_15.12_59 = vect_sum_15.12_58 + vect_sum_15.10_57;
  vect_sum_15.12_60 = VEC_PERM_EXPR ;
  vect_sum_15.12_61 = vect_sum_15.12_60 + vect_sum_15.12_59;
but veclower2 for some reason decides to lower the latter VEC_PERM_EXPR into:
  _32 = BIT_FIELD_REF ;
  _17 = BIT_FIELD_REF ;
  _23 = BIT_FIELD_REF ;
  vect_sum_15.12_60 = {_32, _17, _23, 0};
The first VEC_PERM_EXPR is kept and generates efficient code.  If I manually
disable in the debugger the lowering, the code regression is gone.

[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined

[fw at gcc dot gnu.org]

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

--- Comment #14 from Florian Weimer  ---
(In reply to Szabolcs Nagy from comment #13)
> if gcc treats p-q as (ssize_t)p-(ssize_t)q and makes
> optimization decisions based on signed int range then
> that's broken and leads to wrong code gen.

Thanks for the test case.  I think the remedy proposed so far (glibc should
block allocations sized half of the address space and larger) is insufficient.

[Bug c/67999] Wrong optimization of pointer comparisons

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=63303

--- Comment #26 from Florian Weimer  ---
(In reply to Florian Weimer from comment #12)
> (In reply to Daniel Micay from comment #10)
> > (In reply to Florian Weimer from comment #7)
> > > If this is not a GCC bug and it is the responsibility of allocators not to
> > > produce huge objects, do we also have to make sure that no object crosses
> > > the boundary between 0x7fff_ and 0x8000_?  If pointers are treated
> > > as de-facto signed, this is where signed overflow would occur.
> > 
> > No, that's fine.
> 
> Is this based on your reading of the standard, the GCC sources, or both? 
> (It is unusual to see people making such definite statements about
> middle-end/back-end behavior, that's why I have to ask.)

As I suspect, the claim that this is fine seems to be incorrect, see bug 63303
comment 13.

[Bug rtl-optimization/68128] A huge regression in Parboil v2.5 OpenMP CUTCP test (2.5 times lower performance)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
.omp_data_i = _NOALIAS.0+64
PARM_NOALIAS.0+64 = 
PARM_NOALIAS.64+192 = 
...
_35 = *.omp_data_i
pg_36 = _35 + UNKNOWN
pg_63 = pg_36

.omp_data_i_12(D), points-to vars: { D.1985 } (nonlocal)
pg_63 = { NONLOCAL }

and we end up with

  :
  # iftmp.0_7 = PHI 
  _47 = iftmp.0_7 + _46;
  *pg_63 = _47;
  i_49 = i_62 + 1;
  # PT = nonlocal
  pg_50 = pg_63 + 4;
  _51 = MEM[(struct .omp_data_s.1 &).omp_data_i_12(D) clique 1 base
1].gridspacing;
  dx_52 = _51 + dx_64;
  if (ib_28 >= i_49)
goto ;
  else
goto ;

where we consider the load of gridspacing to alias *pg_63.  That is because
of the not implemented ??? in

/* Mark "other" loads and stores as belonging to CLIQUE and with
   base zero.  */

static bool
visit_loadstore (gimple *, tree base, tree ref, void *clique_)
{
  unsigned short clique = (uintptr_t)clique_;
  if (TREE_CODE (base) == MEM_REF
  || TREE_CODE (base) == TARGET_MEM_REF)
{
  tree ptr = TREE_OPERAND (base, 0);
  if (TREE_CODE (ptr) == SSA_NAME
  && ! SSA_NAME_IS_DEFAULT_DEF (ptr))
{
  /* ???  We need to make sure 'ptr' doesn't include any of
 the restrict tags we added bases for in its points-to set.  */
  return false;
}

which would need to look at ptr's points-to solution and intersect that
with a bitmap we'd need to form out of the restrict tags used for the
respective clique (we only use a single one at the moment, thus a
single bit test is enough if you consider properly pt_anything for ptr).

It's not a complicated fix I think so if you have time to play with it...

[Bug target/68497] New: ICE: in output_387_binary_op, at config/i386/i386.c:17689 with -fno-checking

[zsojka at seznam dot cz]

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

Bug ID: 68497
   Summary: ICE: in output_387_binary_op, at
config/i386/i386.c:17689 with -fno-checking
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Compiler output:
$ gcc -fno-checking testcase.c 
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in output_387_binary_op, at
config/i386/i386.c:17689
 }
 ^

0xecd4d6 output_387_binary_op(rtx_def*, rtx_def**)
/repo/gcc-trunk/gcc/config/i386/i386.c:17689
0x85693b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.c:2947
0x8584c2 final(rtx_insn*, _IO_FILE*, int)
/repo/gcc-trunk/gcc/final.c:2044
0x858e69 rest_of_handle_final
/repo/gcc-trunk/gcc/final.c:4435
0x858e69 execute
/repo/gcc-trunk/gcc/final.c:4510
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.

$ gcc -v   
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-230738-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-230738-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20151123 (experimental) (GCC) 

The failing assertion is:
17686:  && (STACK_TOP_P (operands[1]) || STACK_TOP_P (operands[2])))
17687:; /* ok */
17688:  else
17689:gcc_checking_assert (is_sse);
17690:
17691:  switch (GET_CODE (operands[3]))
17692:{


The above if(flag_checking ... ) is false for -fno-checking, but
gcc_checking_assert() doesn't care about -fno-checking.


Tested revisions:
r230738 - ICE

[Bug tree-optimization/68455] [6 Regression] ICE: tree check: expected integer_cst, have plus_expr in decompose, at tree.h:5123

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
I'll have a look then.

[Bug target/68494] [ARM] Use vector multiply by lane

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
NTAPS is undefined.

What's the current output and what output do you expect ?

[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values

[jwyatt at feralinteractive dot com]

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

--- Comment #4 from Jason Wyatt  ---
It appears that while parsing the initialiser for the array,
maybe_constant_init switches the var for a constructor. This constructor only
sets the m2 member variable. You can see the result in the gimple it produces:

testValue = 1;
var = {};
var.m2 = 2;
var.m1 = testValue;
array = {};
array[0].m2 = 2;

[Bug tree-optimization/68493] [6 Regression] [graphite] ICE in copy_loop_phi_args

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-23
  Component|other   |target
 Blocks||53947
   Target Milestone|--- |5.3
Summary|gcc 5.2: suboptimal code|[5/6 Regression] gcc 5.2:
   |compared to 4.9 |suboptimal code compared to
   ||4.9
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Hum, on x86_64 I don't see either GCC 4.9 or GCC 5.2 vectorize the function at
all because they fail to analyze the evolution of the dataref for input[j] as
the initial j of the inner loop is not propagated as zero.

With i?86 I can confirm your observation but I don't see it fixed on trunk.

Note that this boils down to vector shift detection of permutes where (IIRC)
some patterns were not properly guarded on SSE3 support previously and a
wrong-code bug was fixed conservatively on the GCC 5 branch while missing
support was only implemented on trunk.

The failure to vectorize on x86_64 isn't a regression.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
  Component|other   |driver

--- Comment #1 from Richard Biener  ---
> Or maybe just print an error during linking that offloading doesn't support
> mixing LTO and non-LTO objects (even if some of them doesn't have offload)?

That's the worst solution - having non-LTO objects is the whole point of
linker-plugin support.

I presume the same issue exists for GCC 5.

[Bug tree-optimization/68460] ICE in init_stmt_vec_info_vec with -ftree-vectorize and -ftree-parallelize-loops

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Nov 23 09:45:38 2015
New Revision: 230742

URL: https://gcc.gnu.org/viewcvs?rev=230742=gcc=rev
Log:
Always call free_stmt_vec_info_vec in gather_scalar_reductions

2015-11-23  Tom de Vries  

PR tree-optimization/68460
* tree-parloops.c (gather_scalar_reductions): Also call
free_stmt_vec_info_vec if simple_loop_info == NULL.

* gcc.dg/autopar/pr68460.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr68460.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug debug/66432] [4.9 Regression] libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|openmp  |
Summary|[4.9/5/6 Regression]|[4.9 Regression]
   |libgomp.c/appendix-a/a.29.1 |libgomp.c/appendix-a/a.29.1
   |.c -O2 -g: type mismatch|.c -O2 -g: type mismatch
   |between an SSA_NAME and its |between an SSA_NAME and its
   |symbol  |symbol

--- Comment #11 from Jakub Jelinek  ---
Fixed for 5.3+ so far.

[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Mon Nov 23 10:01:51 2015
New Revision: 230743

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

PR tree-optimization/68327
* tree-vect-loop.c (vect_determine_vectorization_factor): Don't
compute vectype for non-relevant mask producers.
* gcc/tree-vect-stmts.c (vectorizable_comparison): Check stmt
relevance earlier.

gcc/testsuite/

PR tree-optimization/68327
* gcc.dg/pr68327.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr68327.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/68465] pass_lim doesn't detect identical loop entry conditions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Richard Biener  ---
I don't think that's LIMs job then.  Iterating LIM won't help here w/o
intermediate optimization.

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[winter-...@bfw-online.de]

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

Leon Winter  changed:

   What|Removed |Added

Version|5.0 |5.2.1

--- Comment #4 from Leon Winter  ---
Bug still persists.

[Bug tree-optimization/68326] ICE at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:380

[jiwang at gcc dot gnu.org]

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

--- Comment #2 from Jiong Wang  ---
Author: jiwang
Date: Mon Nov 23 12:14:05 2015
New Revision: 230754

URL: https://gcc.gnu.org/viewcvs?rev=230754=gcc=rev
Log:
[Patch] Drop constant overflow flag in adjust_range_with_scev when possible

2015-11-23  Richard Biener  
Jiong Wang  

gcc/
  PR tree-optimization/68317
  PR tree-optimization/68326
  * tree-vrp.c (adjust_range_with_scev): Call drop_tree_overflow if the
  final min and max are not infinity.

gcc/testsuite/
  * gcc.dg/pr68317.c: New testcase.


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

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #12 from Jiong Wang  ---
Mark as fixed.

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[jiwang at gcc dot gnu.org]

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

--- Comment #11 from Jiong Wang  ---
Author: jiwang
Date: Mon Nov 23 12:14:05 2015
New Revision: 230754

URL: https://gcc.gnu.org/viewcvs?rev=230754=gcc=rev
Log:
[Patch] Drop constant overflow flag in adjust_range_with_scev when possible

2015-11-23  Richard Biener  
Jiong Wang  

gcc/
  PR tree-optimization/68317
  PR tree-optimization/68326
  * tree-vrp.c (adjust_range_with_scev): Call drop_tree_overflow if the
  final min and max are not infinity.

gcc/testsuite/
  * gcc.dg/pr68317.c: New testcase.


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

[Bug target/68497] ICE: in output_387_binary_op, at config/i386/i386.c:17689 with -fno-checking

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-23
 CC||miyuki at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |miyuki at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Mikhail Maltsev  ---
Confirmed. I have a patch and I'll post it shortly (after regtest).

[Bug c/68499] New: Unclear STDC FP_CONTRACT behavior in non-standard modes

[vincent-gcc at vinc17 dot net]

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

Bug ID: 68499
   Summary: Unclear STDC FP_CONTRACT behavior in non-standard
modes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Created attachment 36807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36807=edit
example of C program based on the STDC FP_CONTRACT pragma

The following applies to:
gcc (Debian 20151030-1) 6.0.0 20151031 (experimental) [trunk revision 229615]

When I compile a C program like the attached one with

#pragma STDC FP_CONTRACT OFF

in a standard mode, the pragma is now taken into account as expected (see
PR37845 / r204460). However, in a non-standard mode such as the default gnu99
(?), it is not taken into account (a FMA is generated for an operation like
x*y+z), but one gets no warnings either. One should have one of the following
behaviors in non-standard modes:

1. The pragma is taken into account.

2. The pragma is not taken into account, but one gets a warning (making it
unknown in non-standard modes is OK).

If possible, (1) is probably the best choice, at least in gnu99 and gnu11
modes, as the user may want to disable contraction for some floating-point
algorithms while still being able to use specific GNU extensions.

[Bug c/68499] Unclear STDC FP_CONTRACT behavior in non-standard modes

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
Well, actually the pragma is ignored in all cases. The fix was to set the
default to OFF in the standard modes. So, currently, one should get a warning
in non-standard modes.

[Bug other/68500] New: Remove in_loop_pipeline usage

[vries at gcc dot gnu.org]

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

Bug ID: 68500
   Summary: Remove in_loop_pipeline usage
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider pass_slp_vectorize::execute
...
pass_slp_vectorize::execute (function *fun)
{
  basic_block bb;

  bool in_loop_pipeline = scev_initialized_p ();
  if (!in_loop_pipeline)
{
  loop_optimizer_init (LOOPS_NORMAL);
  scev_initialize ();
}

  ...

  if (!in_loop_pipeline)
{
  scev_finalize ();
  loop_optimizer_finalize ();
} 
...

It uses an in_loop_pipeline variable, initialized using scev_initialized_p to
detect whether the pass is run in the loop pipeline, to allow different
behaviour inside and outside the loop pipeline.

We want a cleaner way to allow passes to run correctly inside and outside the
loop pipeline.

[Bug c++/68001] [cilkplus] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:760

[kyukhin at gcc dot gnu.org]

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

--- Comment #1 from Kirill Yukhin  ---
Author: kyukhin
Date: Mon Nov 23 12:58:12 2015
New Revision: 230755

URL: https://gcc.gnu.org/viewcvs?rev=230755=gcc=rev
Log:
PR c++/68001

gcc/c-family
PR c++/68001
* c-gimplify.c (c_gimplify_expr): Stop the process if see an error.
* cilk.c (recognize_spawn): Determine location in a more precise
way.
gcc/cp
* cp-gimplify.c (cp_gimplify_expr): Stop the process if see an error.
gcc/testsuite
* g++.dg/cilk-plus/CK/pr68001.cc: New test.


Added:
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-gimplify.c
trunk/gcc/c-family/cilk.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c/68499] Unclear STDC FP_CONTRACT behavior in non-standard modes

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
Unknown pragmas are diagnosed with -Wunknown-pragmas (part of -Wall).

[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #3 from Ilya Enkovich  ---
Looks like a duplicate of PR68327.  r230743 fixed 465.tonto build for me.

[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-23
 Ever confirmed|0   |1

--- Comment #15 from Richard Biener  ---
Note that in practice it needs exposal of the address constant to trigger the
bogus optimization.

Note that the IL from the frontend is indeed the one to blame here:

char * p = (char *) mmap (2147479552B, 8192, 3, 50, -1, 0);
char * q = 2147483647B;
  if ((int) (p + 4096) - (int) q > 0)
{

for correctness WRT undefined overflow we need to do the subtraction
in unsigned arithmetic and then interpret the result as signed
(for an eventual division by element size).

Same issue in the C++ frontend btw.

[Bug other/68498] New: Replace LOOPS_MAY_HAVE_MULTIPLE_LATCHES with LOOPS_HAVE_SINGLE_LATCH

[vries at gcc dot gnu.org]

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

Bug ID: 68498
   Summary: Replace LOOPS_MAY_HAVE_MULTIPLE_LATCHES with
LOOPS_HAVE_SINGLE_LATCH
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider apply_loop_flags:
...
static void
apply_loop_flags (unsigned flags)
{
  if (flags & LOOPS_MAY_HAVE_MULTIPLE_LATCHES)
{
  /* If the loops may have multiple latches, we cannot canonicalize
 them further (and most of the loop manipulation functions will
 not work).  However, we avoid modifying cfg, which some
 passes may want.  */
  gcc_assert ((flags & ~(LOOPS_MAY_HAVE_MULTIPLE_LATCHES
 | LOOPS_HAVE_RECORDED_EXITS)) == 0);
  loops_state_set (LOOPS_MAY_HAVE_MULTIPLE_LATCHES);
}
  else
disambiguate_loops_with_multiple_latches ();

  /* Create pre-headers.  */
  if (flags & LOOPS_HAVE_PREHEADERS)
{
  int cp_flags = CP_SIMPLE_PREHEADERS;

  if (flags & LOOPS_HAVE_FALLTHRU_PREHEADERS)
cp_flags |= CP_FALLTHRU_PREHEADERS;

  create_preheaders (cp_flags);
}

  /* Force all latches to have only single successor.  */
  if (flags & LOOPS_HAVE_SIMPLE_LATCHES)
force_single_succ_latches ();

  /* Mark irreducible loops.  */
  if (flags & LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS)
mark_irreducible_loops ();

  if (flags & LOOPS_HAVE_RECORDED_EXITS)
record_loop_exits ();
}
...

Most properties in there have a handling bit: if property, do something.

The odd one out is LOOPS_MAY_HAVE_MULTIPLE_LATCHES, where we have if !property,
do something.

LOOPS_MAY_HAVE_MULTIPLE_LATCHES is not really a property, it's the absence of
LOOPS_MAY_HAVE_MULTIPLE_LATCHES that's a property, which we might call
LOOPS_HAVE_SINGLE_LATCH).

It would properly be better to replace uses of LOOPS_MAY_HAVE_MULTIPLE_LATCHES
with uses of LOOPS_HAVE_SINGLE_LATCH. We would get in apply_loop_flags:
...
  if (flags & LOOPS_HAVE_SINGLE_LATCH)
disambiguate_loops_with_multiple_latches ();
  else
{
  /* If the loops may have multiple latches, we cannot canonicalize
 them further (and most of the loop manipulation functions will
 not work).  However, we avoid modifying cfg, which some
 passes may want.  */
  gcc_assert ((flags & ~(LOOPS_HAVE_RECORDED_EXITS)) == 0);
}
...

[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Richard Biener from comment #4)
> As the summary mentions 'volatile' I'll also point to the implementation of
> the intrinsics which have
> 
> /* Store four SPFP values.  The address must be 16-byte aligned.  */
> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_store_ps (float *__P, __m128 __A)
> {
>   *(__v4sf *)__P = (__v4sf)__A;
> }
> 
> so they are not using a volatile qualified type to access *__P which means
> the stores are not considered volatile by GCC.
> 
> The arguments about strict-aliasing requirements still hold, only __m128 is
> declared as __may_alias__:
> 
> /* The Intel API is flexible enough that we must allow aliasing with other
>vector types, and their scalar components.  */
> typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
> 
> /* Internal data types for implementing the intrinsics.  */
> typedef float __v4sf __attribute__ ((__vector_size__ (16)));
> 
> so the v4sf store has regular TBAA rules applied (and the __may_alias__ on
> the by value passed __A has no effect).
> 
> -> target "bug", but I'd say an INVALID one.
> 
> HJ, I remember the "master" copy of the intrinsics documentation is
> somewhere at Intel - what does that say to the two above issues?
> 
> Thus all of this boils down to the question whether the intrinsics are
> implemented correctly (as documented).  The volatile part of it would
> mean to either pessimize all users or that we can't implement the
> intrinsics as C functions.

_mm_store_ps is documented in Intel SDM for movaps.  It doesn't say
anything about aliasing.

[Bug other/68500] Remove in_loop_pipeline usage

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 36808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36808=edit
Tentative patch: "Don't reapply loops flags if unnecessary in
loop_optimizer_init"

[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
clang has:

static __inline__ void __DEFAULT_FN_ATTRS
_mm_storel_epi64(__m128i *__p, __m128i __a)
{
  struct __mm_storel_epi64_struct {
long long __u;
  } __attribute__((__packed__, __may_alias__));
  ((struct __mm_storel_epi64_struct*)__p)->__u = __a[0];
}

It doesn't prove anything, this is just a point of comparison.
(I haven't checked, but I suspect that they have an implicit may_alias on all
vector types)

[Bug plugins/54959] current_pass == NULL during invocation of pass->gate within execute_ipa_summary_passes()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Yeah, 'this' should be used instead of current_pass.

[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined

[ch3root at openwall dot com]

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

--- Comment #16 from Alexander Cherepanov  ---
On 2015-11-23 14:58, rguenth at gcc dot gnu.org wrote:
> Note that in practice it needs exposal of the address constant to trigger the
> bogus optimization.

No. The program:

#include 
#include 
#include 
#include 

int main()
{
   // make sure our allocation will cross 0x8000 boundary
   // but still will not violate limits of gcc
   size_t len = 0x7fff;
   char *p1 = malloc(len);
   char *volatile v = p1 + len;
   char *p2 = v;
   long l1 = (long)(uintptr_t)p1;
   long l2 = (long)(uintptr_t)p2;
   if (l2 < l1) {
 long z = p2 - p1;
 if (z < 0)
   printf("%ld\n", z);
   }
}

prints a positive number for me even though it guards against it. gcc 
5.2 with -m32 -O2.

[Bug other/68500] Remove in_loop_pipeline usage

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 36810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36810=edit
Tentative patch: Add PROP_loops_normal_re_lcssa

[Bug other/68500] Remove in_loop_pipeline usage

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 36809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36809=edit
Tentative patch: Add PROP_scev

[Bug c/20785] Pragma STDC * (C99 FP) unimplemented

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #7 from Vincent Lefèvre  ---
For the STDC FENV_ACCESS pragma specifically, there is PR34678.

For the STDC FP_CONTRACT pragma, there is PR37845, which was fixed by r204460,
though things could be improved in the future as the pragma is actually
ignored: it's just that the default is now OFF in standard modes to be C99/C11
conforming. In the non-standard modes, one now misses the warning: PR68499.

[Bug other/68500] Remove in_loop_pipeline usage

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
First patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02634.html

Last two patches fyi-posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02688.html

[Bug middle-end/56956] [4.9 Regression] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.3.0
Summary|[4.9/5 Regression] ftrapv   |[4.9 Regression] ftrapv
   |traps on valid abs-like |traps on valid abs-like
   |code|code
  Known to fail||5.2.0

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 23 08:32:28 2015
New Revision: 230736

URL: https://gcc.gnu.org/viewcvs?rev=230736=gcc=rev
Log:
2015-11-23  Richard Biener  

Backport from mainline
2015-10-29  Richard Biener  

PR middle-end/56956
* fold-const.c (fold_cond_expr_with_comparison): Do not fold
unsigned conditonal negation to ABS_EXPR.

* c-c++-common/ubsan/pr56956.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr56956.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/56956] [4.9 Regression] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.3.0
Summary|[4.9/5 Regression] ftrapv   |[4.9 Regression] ftrapv
   |traps on valid abs-like |traps on valid abs-like
   |code|code
  Known to fail||5.2.0

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 23 08:32:28 2015
New Revision: 230736

URL: https://gcc.gnu.org/viewcvs?rev=230736=gcc=rev
Log:
2015-11-23  Richard Biener  

Backport from mainline
2015-10-29  Richard Biener  

PR middle-end/56956
* fold-const.c (fold_cond_expr_with_comparison): Do not fold
unsigned conditonal negation to ABS_EXPR.

* c-c++-common/ubsan/pr56956.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr56956.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/68495] Error when expanding nontype variadic argument in trailing return type

[sneves at dei dot uc.pt]

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

--- Comment #1 from Samuel Neves  ---
Minimal example can be further reduced to 

  template struct int_seq {};

  constexpr struct {
  constexpr int operator()(int x) const { return x + 1; }
  } f1 {};

  template
  auto f2(F f, int_seq) -> int_seq {
  return {};
  }

  int main() {
  f2(f1, int_seq<0>{});
  }

This suggests that the issue is with GCC not recognizing that `f::operator()`
is constexpr; this information is seemingly lost somewhere along the way.

[Bug go/68496] New: [libgo] reflect test fails on Linux x86-64

[ismail at i10z dot com]

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

Bug ID: 68496
   Summary: [libgo] reflect test fails on Linux x86-64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ismail at i10z dot com
CC: cmang at google dot com
  Target Milestone: ---

Getting:

Aborted

reflect.call.N13_reflect.Value
   
/havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/value.go:450
reflect.Call.N13_reflect.Value
   
/havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/value.go:300
reflect_test.TestCallWithStruct
   
/havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1492
testing.tRunner
../../../libgo/go/testing/testing.go:455

goroutine 16 [chan receive]:
testing.RunTests
../../../libgo/go/testing/testing.go:561
testing.Run.pN9_testing.M
../../../libgo/go/testing/testing.go:493
main.main
   
/havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/_testmain.go:146
created by main
../../../libgo/runtime/go-main.c:48

goroutine 18 [finalizer wait]:
created by runtime_createfing
../../../libgo/runtime/mgc0.c:2577

goroutine 53 [sleep]:
reflect_test.selectWatcher
   
/havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1383
created by reflect_test.$nested2
   
/havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1113
FAIL: reflect

λ ./gcc/gccgo -v
Using built-in specs.
COLLECT_GCC=./gcc/gccgo
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran,go --enable-checking=release --enable-ssp
--disable-libssp --disable-libvtv --disable-libmpx --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --enable-linker-build-id
--disable-plugin --enable-linux-futex --program-suffix=-6
--without-system-libunwind --with-tune=corei7-avx
--with-build-config=bootstrap-lto --disable-multilib --disable-werror
--disable-nls --with-fpmath=sse --enable-clocale=gnu
Thread model: posix
gcc version 6.0.0 20151123 (experimental) (GCC)

[Bug target/68482] No vectorization for x86-64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/68482] No vectorization for x86-64

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 23 09:11:00 2015
New Revision: 230740

URL: https://gcc.gnu.org/viewcvs?rev=230740=gcc=rev
Log:
2015-11-23  Richard Biener  

PR tree-optimization/68482
* gcc.dg/vect/pr68482.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr68482.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/68470] [4.9/5/6 Regression] Internal Compiler Error observed by g++-4.9.2 and a few other versions (reported to Debian)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||mliska at suse dot cz
   Target Milestone|--- |4.9.4

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
I have a patch series that fixes the bug but I need to make sure
that it works on other targets that use the "enabled" attribute,
and run it through an all-target test.  I'm hoping to post the
patches tomorrow.

[Bug tree-optimization/68445] [6 Regression] ICE: internal compiler error: in operator[], at vec.h

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/68445] [6 Regression] ICE: internal compiler error: in operator[], at vec.h

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 23 08:36:59 2015
New Revision: 230737

URL: https://gcc.gnu.org/viewcvs?rev=230737=gcc=rev
Log:
2015-11-23  Richard Biener  

PR tree-optimization/68445
* tree-vect-slp.c (vect_create_mask_and_perm): Properly use
two different strides.

* gcc.dg/vect/pr68445.c: New testcase.

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

[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|NEW |ASSIGNED
  Component|middle-end  |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0

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

[Bug tree-optimization/68474] [6 Regression] ICE: in get_no_error_domain, at tree-call-cdce.c:699 with -funsafe-math-optimizations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug c/68462] -fno-strict-aliasing not respected

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
With N_domains non-static GCC has to assume it has its address taken and thus
it thinks that the stores to ->next, .lol and .size can alias it.

So the issue that -fno-strict-aliasing is not "respected" is that type-based
aliasing only matters for memory accesses via pointers and GCC can independelty
prove that N_domains is not pointed-to if it is static.

[Bug rtl-optimization/68173] gcc takes a long time and a lot of memory with -O0 on source file with very large expression

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Fri, 20 Nov 2015, vmakarov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68173
> 
> --- Comment #13 from Vladimir Makarov  ---
> (In reply to Richard Biener from comment #12)
> > callgrind points at bitmap_set_bit called via process_bb_lives ->
> > mark_regno_dead.
> > Maybe some code in that (the DCE code?) can be keyed on if (optimize).
> > 
> > in mark_regno_dead callgrind points to
> > 
> >   bitmap_set_bit (bb_killed_pseudos, regno);
> > 
> > being the expensive one.
> 
> I've tried to implement bb_killed_pseudos and bb_gen_pseudos as 
> sparsesets but it gave nothing in term of compiler speed.  I think the 
> major problem is in processing too many pseudos in -O0 mode which are 
> about 1000 times more than in -O2 mode.

Yeah, but without optimization we can't do sth about that (well, do
more coalescing maybe, but as said coalescing is O(n^2) because of
liveness - so we'd run into the very same issue there).

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-23
 CC||hjl.tools at gmail dot com
  Component|c++ |target
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
As the summary mentions 'volatile' I'll also point to the implementation of the
intrinsics which have

/* Store four SPFP values.  The address must be 16-byte aligned.  */
extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_store_ps (float *__P, __m128 __A)
{
  *(__v4sf *)__P = (__v4sf)__A;
}

so they are not using a volatile qualified type to access *__P which means
the stores are not considered volatile by GCC.

The arguments about strict-aliasing requirements still hold, only __m128 is
declared as __may_alias__:

/* The Intel API is flexible enough that we must allow aliasing with other
   vector types, and their scalar components.  */
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));

/* Internal data types for implementing the intrinsics.  */
typedef float __v4sf __attribute__ ((__vector_size__ (16)));

so the v4sf store has regular TBAA rules applied (and the __may_alias__ on
the by value passed __A has no effect).

-> target "bug", but I'd say an INVALID one.

HJ, I remember the "master" copy of the intrinsics documentation is somewhere
at Intel - what does that say to the two above issues?

Thus all of this boils down to the question whether the intrinsics are
implemented correctly (as documented).  The volatile part of it would
mean to either pessimize all users or that we can't implement the
intrinsics as C functions.

[Bug go/68477] error: type variant differs by TYPE_STRING_FLAG.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-23
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Sorry, the second file isn't necessary at all:

 % gccgo -flto foo1.go
go1: error: type variant differs by TYPE_STRING_FLAG.

[Bug libfortran/51119] MATMUL slow for large matrices

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #22 from Joost VandeVondele  
---
(In reply to Thomas Koenig from comment #21)
> I assume that for  small matrices bordering on the silly
> (say, a matrix multiplication with dimensions of (1,2) and (2,1))
> the inline code will be faster if the code is compiled with the
> right options, due to function call overhead.  I also assume that
> libxsmm will become faster quite soon for bigger sizes.
> 
> Do you have an idea where the crossover is?

I agree that inline should be faster, if the compiler is reasonably smart, if
the matrix dimensions are known at compile time (i.e. should be able to
generate the same kernel). I haven't checked yet.

[Bug middle-end/68221] libgomp reduction-11/12 failures

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 230671)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -750,8 +750,11 @@ copy_reference_ops_from_ref (tree ref, v
case MEM_REF:
  /* The base address gets its own vn_reference_op_s structure.  */
  temp.op0 = TREE_OPERAND (ref, 1);
- if (tree_fits_shwi_p (TREE_OPERAND (ref, 1)))
-   temp.off = tree_to_shwi (TREE_OPERAND (ref, 1));
+   {
+ offset_int off = mem_ref_offset (ref);
+ if (wi::fits_shwi_p (off))
+   temp.off = off.to_shwi ();
+   }
  temp.clique = MR_DEPENDENCE_CLIQUE (ref);
  temp.base = MR_DEPENDENCE_BASE (ref);
  temp.reverse = REF_REVERSE_STORAGE_ORDER (ref);

[Bug go/66574] Time is provided in millisecond precision instead of nanoseconds as described in go documentation

[boger at us dot ibm.com]

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

--- Comment #6 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #5)
> Fixed on mainline.

Can this be backported to the gcc 5 branch?

[Bug target/68483] [5/6 Regression] gcc 5.2: suboptimal code compared to 4.9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug ipa/65908] [5 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #17 from Martin Liška  ---
Fixed in gcc-5-branch.

[Bug ipa/65908] [5 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
Author: marxin
Date: Mon Nov 23 13:58:40 2015
New Revision: 230756

URL: https://gcc.gnu.org/viewcvs?rev=230756=gcc=rev
Log:
PR ipa/65908

* ipa-icf.c (sem_item::target_supports_symbol_aliases): Remove
construction of arg_types.
(sem_function::sem_function): Likewise.
(sem_function::~sem_function): Remove destruction of arg_types.
(sem_function::compatible_parm_types_p): New function.
(sem_function::equals_wpa): Reorg matching of return values
and parameter types.
(sem_function::equals_private): Reorg mathcing of argument types.
(sem_function::parse_tree_args): Remove.
(sem_function::param_used_p): New function.
* ipa-icf.h (init_wpa): Do not call it.
(parse_tree_args): Remove.
(compatible_parm_types_p): Declare.
(result_type): Remove.
(arg_types): Remove.
(param_used_p): Declare.
* g++.dg/ipa/pr65908.C: New testcase.

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

[Bug middle-end/68221] libgomp reduction-11/12 failures

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-23
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug ipa/68470] [4.9/5/6 Regression] Internal Compiler Error observed by g++-4.9.2 and a few other versions (reported to Debian)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
(In reply to Mikhail Maltsev from comment #3)
> A bit simplified testcase:
> 
> void deallocate(void *);
> void *a;
> 
> struct C {
>   virtual void m_fn1();
> };
> 
> struct D {
>   C *m_fn2() {
> if (a)
>   __builtin_abort();
>   }
> };
> D getd();
> 
> struct vec_int {
>   int _M_start;
>   ~vec_int() {
> if (_M_start)
>   deallocate(&_M_start);
>   }
> };
> vec_int *b;
> 
> struct I {
>   virtual void m_fn3();
> };
> 
> void I::m_fn3() {
>   if (a)
> getd().m_fn2()->m_fn1();
>   b->~vec_int();
> }
> 
> $ cc1plus -O2 test.cc - ICE after fnsplit
> $ cc1plus -O2 test.cc -fno-checking - ICE in IPA-ICF (like in the original
> bug report)
> $ cc1plus -O2 test.cc -fno-devirtualize - OK
> $ cc1plus -O2 test.cc --param partial-inlining-entry-probability=0 - OK
> 
> ISTM, this is some IPA-related issue:
> D::m_fn2 and vec_int::~vec_int are inlined into I::m_fn3.
> D::m_fn2 (D::operator-> in previous comments) does not return any value
> (undefined behavior), so gimple_fold_call devirtualizes
> getd().m_fn2()->m_fn1() into __builtin_unreachable during fwprop1.
> fnsplit then tries to split I::m_fn3. This is how the function looks before
> fnsplit:
> 
> ;; Function virtual void I::m_fn3() (_ZN1I5m_fn3Ev, funcdef_no=4,
> decl_uid=2299, cgraph_uid=4, symbol_order=6)
> 
> virtual void I::m_fn3() (struct I * const this)
> {
>   struct C * D.2356;
>   void * a.0_3;
>   void * a.2_5;
>   struct vec_int * b.1_12;
>   int _14;
>   int * _15;
> 
>   :
>   a.0_3 = a;
>   if (a.0_3 != 0B)
> goto ;
>   else
> goto ;
> 
>   :
>   getd ();
>   a.2_5 = a;
>   if (a.2_5 != 0B)
> goto ;
>   else
> goto ;
> 
>   :
>   __builtin_abort ();
> 
>   :
>   __builtin_unreachable ();
> 
>   :
>   b.1_12 = b;
>   _14 = b.1_12->_M_start;
>   if (_14 != 0)
> goto ;
>   else
> goto ;
> 
>   :
>   _15 = _12->_M_start;
>   deallocate (_15);
> 
>   :
>   MEM[(struct  &)b.1_12] ={v} {CLOBBER};
>   return;
> 
> }
> 
> The splitting pass tries to do this:
> 
> Splitting function at:
> Split point at BB 6
>   header time: 19646 header size: 10
>   split time: 2491 split size: 6
>   bbs: 6, 7
>   SSA names to pass: 
> Introduced new external node (void __builtin_unreachable()/18).
> 
> ICE probably happens in this part:
> 
> virtual void I::m_fn3() (struct I * const this)
> {
>   struct C * D.2356;
>   void * a.0_3;
>   void * a.2_5;
> 
>   :
>   a.0_3 = a;
>   if (a.0_3 != 0B)
> goto ;
>   else
> goto ;
> 
>   :
>   getd ();
>   a.2_5 = a;
>   if (a.2_5 != 0B)
> goto ;
>   else
> goto ;
> 
>   :
>   __builtin_abort ();
> 
>   :
>   __builtin_unreachable ();
> 
>   :
>   I::_ZN1I5m_fn3Ev.part.1 ();
>   MEM[(struct  &)_12] ={v} {CLOBBER};
>   return;
> 
> }

Hi.

The problem is really in , which contains definition of 'b.1_12' that is
used in return_bb (). The return_bb is eventually merged with .

I'm not sure about proper fix, I would expect that return_bb must be pruned of
all unused stmts (that would be moved to newly created function). Any ideas?

Martin

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[gang.chen.5i5j at gmail dot com]

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

--- Comment #19 from Chen Gang  ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Chen Gang from comment #17)
> > I guess the diff below should be OK, I shall give a make check test.
> 
> I would rather have the C front-end behavior for C++ rather than the
> opposite way around.  Because _Pragma are considered statements.

For me, this bug is related with the demands (language definition), and C need
not be part of C++.

 - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more
new features, and want to let the users (C++ programmer) use the language
freely and in common sense.

 - But for C, if one feature is in discussing, it should not be treated as a
common features (C standard is more stricter than C++). So we need not care
about this 'bug' quite much (In real world, C programmers need not use #pragma
in this way).

In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it
may cause misunderstanding for C/C++ programmers more or less), cc1 need report
error during compiling.

[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #3)
> Looks like a duplicate of PR68327.  r230743 fixed 465.tonto build for me.

r230743 still fails for me.  Can you show me your linking command line
for 465.tonto build?

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[gang.chen.5i5j at gmail dot com]

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

--- Comment #20 from Chen Gang  ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Chen Gang from comment #17)
> > I guess the diff below should be OK, I shall give a make check test.
> 
> I would rather have the C front-end behavior for C++ rather than the
> opposite way around.  Because _Pragma are considered statements.

For me, this bug is related with the demands (language definition), and C need
not be part of C++.

 - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more
new features, and want to let the users (C++ programmer) use the language
freely and in common sense.

 - But for C, if one feature is in discussing, it should not be treated as a
common features (C standard is more stricter than C++). So we need not care
about this 'bug' quite much (In real world, C programmers need not use #pragma
in this way).

In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it
may cause misunderstanding for C/C++ programmers more or less), cc1 need report
error during compiling.

[Bug target/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[vvsed at hotmail dot com]

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

--- Comment #7 from Vladimir Sedach  ---
The "store" pointer could be not only volatile, but also static or global with
same error.

[Bug c/68499] Unclear STDC FP_CONTRACT behavior in non-standard modes

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

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

--- Comment #3 from Vincent Lefèvre  ---
Sorry, I forgot that I had an alias gcc='gcc -Wall', so that I got a warning
for gcc, but not for gcc-snapshot. I've now changed by config to define such an
alias for each GCC command found in $PATH.

I'm closing this bug since nothing has changed concerning the warnings compared
to old GCC versions.

[Bug tree-optimization/68501] New: [6 Regression] sqrt builtin is not used anymore

[afomin.mailbox at gmail dot com]

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

Bug ID: 68501
   Summary: [6 Regression] sqrt builtin is not used anymore
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: afomin.mailbox at gmail dot com
CC: izamyatin at gmail dot com, rsandifo at redhat dot com,
ysrumyan at gmail dot com
  Target Milestone: ---
Target: x86_64-*-*

Created attachment 36812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36812=edit
A reproducer

For the attached reproducer compiled with g++ -mavx -Ofast we do not use IA
sqrt builtin since r230492 thus emitting more insns.

r230491
.L8:
vmovaps (%r14,%rax), %ymm0
addl$1, %r12d
vmovups 0(%r13,%rax), %xmm1
vinsertf128 $0x1, 16(%r13,%rax), %ymm1, %ymm1
vmulps  %ymm1, %ymm1, %ymm1
vmulps  %ymm0, %ymm0, %ymm0
vaddps  %ymm1, %ymm0, %ymm1
vrsqrtps%ymm1, %ymm2
vmulps  %ymm1, %ymm2, %ymm0
vmulps  %ymm2, %ymm0, %ymm0
vaddps  %ymm4, %ymm0, %ymm0
vmulps  %ymm3, %ymm2, %ymm2
vmulps  %ymm2, %ymm0, %ymm0
vmovups %xmm0, (%r10,%rax)
vextractf128$0x1, %ymm0, 16(%r10,%rax)
addq$32, %rax
cmpl%r12d, %r9d
ja  .L8 

r230492
.L8:
.L8:
vmovaps (%r14,%rax), %ymm0
addl$1, %r12d
vmovups 0(%r13,%rax), %xmm1
vinsertf128 $0x1, 16(%r13,%rax), %ymm1, %ymm1
vmulps  %ymm1, %ymm1, %ymm1
vmulps  %ymm0, %ymm0, %ymm0
vaddps  %ymm1, %ymm0, %ymm1
vcmpneqps   %ymm1, %ymm2, %ymm5
vrsqrtps%ymm1, %ymm0
vandps  %ymm5, %ymm0, %ymm0
vmulps  %ymm1, %ymm0, %ymm1
vmulps  %ymm0, %ymm1, %ymm0
vaddps  %ymm4, %ymm0, %ymm0
vmulps  %ymm3, %ymm1, %ymm1
vmulps  %ymm1, %ymm0, %ymm0
vrcpps  %ymm0, %ymm1
vmulps  %ymm0, %ymm1, %ymm0
vmulps  %ymm0, %ymm1, %ymm0
vaddps  %ymm1, %ymm1, %ymm1
vsubps  %ymm0, %ymm1, %ymm0
vmovups %xmm0, (%r10,%rax)
vextractf128$0x1, %ymm0, 16(%r10,%rax)
addq$32, %rax
cmpl%r12d, %r9d
ja  .L8

[Bug tree-optimization/66721] [6 regression] gcc.target/i386/pr61403.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So I have a "solution" that I hope to prettify a bit still.  The basic issue
is that SLP is "broken" in that it builds a tree of operations instead of a
graph.
That is, it un-CSEs all n in the testcase:

  for (i = 0; i < size; ++i)
{
  float n = sqrt (in[i].x * in[i].x + in[i].y * in[i].y + in[i].z *
in[i].z);
  out[i].x = in[i].x / n;
  out[i].y = in[i].y / n;
  out[i].z = in[i].z / n;
}

which results in bloat in the SLP tree and initial vectorized code and also
cost which is good in this case.  Usually with nicely vector-size aligned
things later passes can CSE all the mess again and the generated code isn't
so bad (so the costs are overly conservative).  But in this case with an
"interleaving size" of 3 we end up with three vectors containing 4 groups
we'd want to CSE.

 sqrt { in[0].x * in[0].x + in[0].y * in[0].y + ...,
in[0].x * 
in[0].x * ...,
in[1].x * in[1].x + in[1].y * ... }
 sqrt { ... }
 sqrt { ... }

this way we avoid the permutes on the stores of course, but the lack of
CSE here makes the generated code worse (when you look at it with
-fno-vect-cost-model, the cost-model rejects the code even though it
might be profitable at a slightly larger theshold in practice).

.L5:
movups  (%r8), %xmm8
addl$1, %r10d
addq$48, %r8
addq$48, %rax
movups  -16(%r8), %xmm6
movups  -32(%r8), %xmm7
movaps  %xmm8, %xmm13
movdqa  %xmm6, %xmm11
movdqa  %xmm6, %xmm10
movaps  %xmm6, %xmm1
movdqa  %xmm7, %xmm9
movdqa  %xmm7, %xmm0
movaps  %xmm7, %xmm12
shufps  $252, %xmm6, %xmm1
palignr $8, %xmm7, %xmm11
shufps  $175, %xmm7, %xmm13
mulps   %xmm1, %xmm1
movaps  %xmm7, %xmm2
palignr $12, %xmm7, %xmm10
shufps  $252, %xmm11, %xmm11
mulps   %xmm11, %xmm11
shufps  $240, %xmm7, %xmm12
shufps  $252, %xmm10, %xmm10
mulps   %xmm10, %xmm10
palignr $4, %xmm8, %xmm9
shufps  $5, %xmm6, %xmm2
shufps  $192, %xmm9, %xmm9
mulps   %xmm9, %xmm9
palignr $8, %xmm8, %xmm0
shufps  $192, %xmm0, %xmm0
mulps   %xmm0, %xmm0
mulps   %xmm13, %xmm13
addps   %xmm10, %xmm11
mulps   %xmm12, %xmm12
movaps  %xmm8, %xmm10
shufps  $192, %xmm8, %xmm10
mulps   %xmm10, %xmm10
mulps   %xmm2, %xmm2
addps   %xmm11, %xmm1
addps   %xmm13, %xmm12
addps   %xmm10, %xmm9
movaps  %xmm3, %xmm10
addps   %xmm12, %xmm2
addps   %xmm9, %xmm0
rsqrtps %xmm0, %xmm9
cmpneqps%xmm0, %xmm10
andps   %xmm10, %xmm9
mulps   %xmm9, %xmm0
movaps  %xmm3, %xmm10
cmpneqps%xmm2, %xmm10
mulps   %xmm0, %xmm9
mulps   %xmm4, %xmm0
addps   %xmm5, %xmm9
mulps   %xmm9, %xmm0
rsqrtps %xmm2, %xmm9
andps   %xmm10, %xmm9
mulps   %xmm9, %xmm2
movaps  %xmm3, %xmm10
cmpneqps%xmm1, %xmm10
mulps   %xmm2, %xmm9
mulps   %xmm4, %xmm2
addps   %xmm5, %xmm9
mulps   %xmm9, %xmm2
rsqrtps %xmm1, %xmm9
andps   %xmm10, %xmm9
mulps   %xmm9, %xmm1
mulps   %xmm1, %xmm9
mulps   %xmm4, %xmm1
addps   %xmm5, %xmm9
mulps   %xmm9, %xmm1
rcpps   %xmm0, %xmm9
mulps   %xmm9, %xmm0
mulps   %xmm9, %xmm0
addps   %xmm9, %xmm9
subps   %xmm0, %xmm9
rcpps   %xmm2, %xmm0
mulps   %xmm9, %xmm8
mulps   %xmm0, %xmm2
movups  %xmm8, -48(%rax)
mulps   %xmm0, %xmm2
addps   %xmm0, %xmm0
subps   %xmm2, %xmm0
mulps   %xmm7, %xmm0
movups  %xmm0, -32(%rax)
rcpps   %xmm1, %xmm0
mulps   %xmm0, %xmm1
mulps   %xmm0, %xmm1
addps   %xmm0, %xmm0
subps   %xmm1, %xmm0
mulps   %xmm6, %xmm0
movups  %xmm0, -16(%rax)
cmpl%r10d, %r9d
ja  .L5

of course it doesn't use any blend instruction.  The testcase was to
test interleaving of size 3 support which should better have used
different operations to make SLP impossible (of course the testcase
is also from real-world code which means it is a relevant regression).

[Bug target/68261] GCC needs to use optimized version of memcpy

[geir at cray dot com]

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

--- Comment #4 from Geir Johansen  ---
(In reply to Andrew Pinski from comment #1)
> Note glibc does provide a memcpy which is optimized for each target via
> ifuncs. What version of glibc are you running.

2.11.3

[Bug target/68261] GCC needs to use optimized version of memcpy

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Geir Johansen from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > Note glibc does provide a memcpy which is optimized for each target via
> > ifuncs. What version of glibc are you running.
> 
> 2.11.3

That is a very old release which was released before most of the modern v2/v3
were relased so no wonder you are having performance issues.

[Bug tree-optimization/68460] ICE in init_stmt_vec_info_vec with -ftree-vectorize and -ftree-parallelize-loops

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from vries at gcc dot gnu.org ---
patch and test-case committed, marking resolved-fixed

[Bug go/68503] New: [powerpc64le] miscompilation of composite literal

[michael.hudson at canonical dot com]

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

Bug ID: 68503
   Summary: [powerpc64le] miscompilation of composite literal
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: michael.hudson at canonical dot com
CC: cmang at google dot com
  Target Milestone: ---

Running commands like this on Ubuntu trusty ppc64le:

$ go get github.com/juju/juju/...
$ cd $GOPATH/src/github.com/juju/juju
$ git checkout 1.25
$ git apply << EOF
diff --git a/state/filesystem_test.go b/state/filesystem_test.go
index a7113bc..e0b20dd 100644
--- a/state/filesystem_test.go
+++ b/state/filesystem_test.go
@@ -258,7 +258,7 @@ func (s *FilesystemStateSuite) TestFilesystemInfo(c *gc.C)
{

// Explicitly set both MountPoint and ReadOnly to work around
// bug #1517611
-   filesystemAttachmentInfo := state.FilesystemAttachmentInfo{MountPoint:
"/srv", ReadOnly: false}
+   filesystemAttachmentInfo := state.FilesystemAttachmentInfo{MountPoint:
"/srv"}
err = s.State.SetFilesystemAttachmentInfo(machineTag, filesystemTag,
filesystemAttachmentInfo)
c.Assert(err, jc.ErrorIsNil)
s.assertFilesystemAttachmentInfo(c, machineTag, filesystemTag,
filesystemAttachmentInfo)
EOF
$ go test -c -v  ./state  && ./state.test -gocheck.v -gocheck.f
TestFilesystemInfo

Leads to a failure along the lines of 

... obtained state.FilesystemAttachmentInfo =
state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}
... expected state.FilesystemAttachmentInfo =
state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}

What's going on appears to be that the line "filesystemAttachmentInfo :=
state.FilesystemAttachmentInfo{MountPoint: "/srv"}" is copying from the wrong
place in .rodata (the part that should be a pointer to string data is actually
the string data "action-9", which is part of a composite literal in a different
file).

This error appears to be present in the GIMPLE already.

The bug does not manifest on ppc64le with a newer gccgo or on arm64 at all, so
it's probably been fixed by now -- but it also disappears if I delete seemingly
irrelevant code, so it would be nice to know how this was fixed, and that it's
not just disappeared by luck. But only nice: we don't expect to use gccgo on
ppc64le for much longer.

[Bug tree-optimization/67984] [GRAPHITE] internal compiler error: isl_ctx freed, but some objects still reference it

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-23
 CC||spop at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Sebastian Pop  ---
I cannot reproduce the error on GCC 6.0 trunk.
Also, please provide a reduced testcase, the attached testcase fails with:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/immintrin.h:43:0,
 from /usr/include/CL/cl_platform.h:441,
 from /usr/include/CL/cl.h:30,
 from /usr/include/CL/opencl.h:42,
 from dcttest.c:61:
/usr/lib/gcc/x86_64-linux-gnu/5/include/avx2intrin.h: In function
‘_mm256_mpsadbw_epu8’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/avx2intrin.h:46:12: error: can’t
convert a value of type ‘int’ to vector type ‘__vector(4) long long int’ which
has different size