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

[doko at gcc dot gnu.org]

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

Bug ID: 69154
   Summary: [6 Regression] ICE in gfc_trans_where_2, at
fortran/trans-stmt.c:5005 on *-linux
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen with trunk r232077 on several architectures, building the abinit package.
worked around by building with -O0:

$ gfortran -ffree-form -g -O1 -c -o m_numeric_tools.o m_numeric_tools.f90 
m_numeric_tools.F90:2085:0:


internal compiler error: in gfc_trans_where_2, at fortran/trans-stmt.c:5005
0x1030c173 gfc_trans_where_2
../../src/gcc/fortran/trans-stmt.c:5005
0x10313653 gfc_trans_where(gfc_code*)
../../src/gcc/fortran/trans-stmt.c:5237
0x102952b7 trans_code
../../src/gcc/fortran/trans.c:1832
0x102c19ff gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:6083
0x10299ad3 gfc_generate_module_code(gfc_namespace*)
../../src/gcc/fortran/trans.c:2054
0x102384f7 translate_all_program_units
../../src/gcc/fortran/parse.c:5599
0x102384f7 gfc_parse_file()
../../src/gcc/fortran/parse.c:5818
0x1029122f gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug fortran/69080] No automatic deallocation of allocatable function results

[sv.muel...@tu-braunschweig.de]

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

--- Comment #8 from Mueller  ---
(In reply to Dominique d'Humieres from comment #6)
> > I know that allocatables that are declared in the program itself aren't
> > deallocated automatically because of the implicit save attribute. 
> > But my thinking was that Fortran will take care of deallocating allocatable
> > in all other cases. Of course, I may be mistaken.
> 
> Well, if the user is unable to decide when and where something should be
> deallocate, how can you expect the compiler to do better? AFAIU this should
> be handled through finalization, but I am still learning and I am not in
> position to give advice in this area.

I think, in theory, the compiler could detect something like

call some_subroutine(function_returning_allocatable())

to be a potential case for automatic deallocation of the returned allocatable.
But, as was pointed out above (if I understood correctly), automatic
deallocation of allocatable function results is not part of the standard.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #12 from Uroš Bizjak  ---
(In reply to Eric Botcazou from comment #11)
> > Yes, forced stack alignment on x86_64 was introduced after 5.2, in r228728
> > for pr66697. Also, I can confirm that adding -fno-omit-frame-pointer allows
> > Wine to compile normally.
> 
> I see, thanks.  Uros, would you mind having a look?  I don't know this stuff.

Ugh ... prologue and epilogue generation is not exactly the most pleasant part
of the compiler. There are many different fragile code paths, so no wonder that
with specialized options something breaks in this area.

Looking into it.

[Bug target/69129] [6 Regression] ICE in get_attr_got, at config/mips/mips.md:694 on mips-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
rechecked with today's trunk on Debian unstable, reproduced. The compiler is
configured with:

configure -v --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-6 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib
--enable-multiarch --enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx
--enable-targets=all --with-arch-64=mips64r2 --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=mips-linux-gnu
--program-prefix=mips-linux-gnu- --includedir=/usr/mips-linux-gnu/include

according to
https://buildd.debian.org/status/logs.php?pkg=gcc-snapshot=mipsel

the libgfortran failure is first seen with trunk 20150722 in native builds.

[Bug fortran/69080] No automatic deallocation of allocatable function results

[sv.muel...@tu-braunschweig.de]

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

--- Comment #9 from Mueller  ---
(In reply to Mueller from comment #8)
> I think, in theory, the compiler could detect something like
> 
> call some_subroutine(function_returning_allocatable())
> 
> to be a potential case for automatic deallocation of the returned
> allocatable. But, as was pointed out above (if I understood correctly),
> automatic deallocation of allocatable function results is not part of the
> standard.

Now that I'm thinking about the example above: Isn't the allocatable function
result here a local (temporary) variable and should thus be deallocated
automatically?

[Bug target/69053] [6 Regression] ICE in build_vector_from_val

[alalaw01 at gcc dot gnu.org]

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

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Well, this fixes it, but I'm not sure it fixes it in the right place...

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index ee32166..bd66aa5 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -4178,7 +4178,9 @@ get_initial_def_for_reduction (gimple *stmt, tree
init_val
break;
  }
  }
-   init_def = build_vector_from_val (vectype, init_value);
+   init_def = build_vector_from_val (vectype,
+ fold_convert (TREE_TYPE (vectype),
+   init_value));
break;

   default:

[Bug sanitizer/69099] ICE when compiling gcc.dg/atomic/c11-atomic-exec-2.c with -fsanitize=float-cast-overflow

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  6 10:24:15 2016
New Revision: 232099

URL: https://gcc.gnu.org/viewcvs?rev=232099=gcc=rev
Log:
PR sanitizer/69099
* c-convert.c (convert) [INTEGER_TYPE]: Drop ARG.  Don't pass ARG to
ubsan_instrument_float_cast.  Fold EXPR.  Use NULL_TREE instead of
NULL.

* convert.c (convert_to_integer_1): Adjust call to
ubsan_instrument_float_cast.  Use NULL_TREE instead of NULL.
* ubsan.c (ubsan_instrument_float_cast): Drop the ARG parameter.  Use
EXPR instead of ARG.
* ubsan.h (ubsan_instrument_float_cast): Adjust declaration.

* gcc.dg/ubsan/float-cast-overflow-atomic.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ubsan/float-cast-overflow-atomic.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-convert.c
trunk/gcc/convert.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c
trunk/gcc/ubsan.h

[Bug sanitizer/69099] ICE when compiling gcc.dg/atomic/c11-atomic-exec-2.c with -fsanitize=float-cast-overflow

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 6.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #12)

> Looking into it.

At the beginning of ix86_expand_epilogue, we have:

  m->fs.sp_valid = (!frame_pointer_needed
|| (crtl->sp_is_unchanging
&& !stack_realign_fp));

so, we can say in a similar way at the end of the ix86_expand_prologue:

  m->fs.sp_valid = !frame_pointer_needed;

Justas, can you please test the following patch:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c6c66c7..9c3fa70 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13065,6 +13065,8 @@ ix86_expand_prologue (void)
   m->fs.fp_valid = true;
 }

+  m->fs.sp_valid = !frame_pointer_needed;
+
   if (!int_registers_saved)
 ix86_emit_save_regs_using_mov (frame.reg_save_offset);
   if (!sse_registers_saved)
--cut here--

[Bug fortran/69080] No automatic deallocation of allocatable function results

[sv.muel...@tu-braunschweig.de]

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

--- Comment #7 from sv.muel...@tu-braunschweig.de ---
(In reply to kargl from comment #5)
> When the execution of a procedure is terminated by execution of a
> RETURN or END statement, an allocatable variable that is a named
> local variable of the procedure retains its allocation and definition
> status if it has the SAVE attribute or is a function result variable
> or a subobject thereof; otherwise, it is deallocated.

If you are stating it like that it sounds like these are the directives of the
current Fortran standard. I've read a little bit of the standard before posting
my question here, but could not really figure out the meaning in terms of
allocatable function results. So if what you stated is standard Fortran, I'm
thanking you for clearing this up.

[Bug libstdc++/69152] _GLIBCXX_BITSET_BITS_PER_WORD is wrong for x32

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The macro might have a slightly confusing name, but it's not wrong.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[bucaneer at gmail dot com]

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

--- Comment #14 from Justas L  ---
(In reply to Uroš Bizjak from comment #13)
> Justas, can you please test the following patch

Thank you, it indeed solves the problem.

[Bug pch/68758] [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551)

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> Is your gcc configured with --enable-valgrind-annotations ?

Hello Jakub.

So the problem is that even though the configure option was passed to
configure, valgrind discard magic is done just in case
ENABLE_VALGRIND_CHECKING, as added in:
https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html

I would consider it better to guard the valgrind code in case
ENABLE_VALGRIND_ANNOTATIONS:

diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index c919ba8..9b291aa 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -492,7 +492,7 @@ gt_pch_save (FILE *f)

   ggc_pch_prepare_write (state.d, state.f);

-#if defined ENABLE_VALGRIND_CHECKING && defined VALGRIND_GET_VBITS
+#if defined ENABLE_VALGRIND_ANNOTATIONS && defined VALGRIND_GET_VBITS
   vec vbits = vNULL;
 #endif

@@ -504,7 +504,7 @@ gt_pch_save (FILE *f)
  this_object_size = state.ptrs[i]->size;
  this_object = XRESIZEVAR (char, this_object, this_object_size);
}
-#if defined ENABLE_VALGRIND_CHECKING && defined VALGRIND_GET_VBITS
+#if defined ENABLE_VALGRIND_ANNOTATIONS && defined VALGRIND_GET_VBITS
   /* obj might contain uninitialized bytes, e.g. in the trailing
 padding of the object.  Avoid warnings by making the memory
 temporarily defined and then restoring previous state.  */
@@ -561,7 +561,7 @@ gt_pch_save (FILE *f)
state.ptrs[i]->note_ptr_fn == gt_pch_p_S);
   if (state.ptrs[i]->note_ptr_fn != gt_pch_p_S)
memcpy (state.ptrs[i]->obj, this_object, state.ptrs[i]->size);
-#if defined ENABLE_VALGRIND_CHECKING && defined VALGRIND_GET_VBITS
+#if defined ENABLE_VALGRIND_ANNOTATIONS && defined VALGRIND_GET_VBITS
   if (__builtin_expect (get_vbits == 1, 0))
{
  (void) VALGRIND_SET_VBITS (state.ptrs[i]->obj, vbits.address (),
@@ -575,7 +575,7 @@ gt_pch_save (FILE *f)
}
 #endif
 }
-#if defined ENABLE_VALGRIND_CHECKING && defined VALGRIND_GET_VBITS
+#if defined ENABLE_VALGRIND_ANNOTATIONS && defined VALGRIND_GET_VBITS
   vbits.release ();
 #endif


Using the patch, the issue has gone.
What do you think about it?

Martin

[Bug c++/69158] New: [6 Regression] ICE in in cxx_eval_indirect_ref, at cp/constexpr.c:2598

[doko at gcc dot gnu.org]

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

Bug ID: 69158
   Summary: [6 Regression] ICE in in cxx_eval_indirect_ref, at
cp/constexpr.c:2598
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

$ cat FGFDMExec.ii 
char IdHdr[] { (IdHdr)[0] }

$ g++ -c -g -O2 FGFDMExec.ii
FGFDMExec.ii:1:27: internal compiler error: in cxx_eval_indirect_ref, at
cp/constexpr.c:2598
 char IdHdr[] { (IdHdr)[0] }
   ^

0x6f92bb cxx_eval_indirect_ref
../../src/gcc/cp/constexpr.c:2597
0x6f92bb cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3371
0x6f6eb2 cxx_eval_array_reference
../../src/gcc/cp/constexpr.c:1767
0x6f6eb2 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3506
0x6fa278 cxx_eval_outermost_constant_expr
../../src/gcc/cp/constexpr.c:3773
0x6fb293 maybe_constant_value_1
../../src/gcc/cp/constexpr.c:3960
0x6fb293 maybe_constant_value(tree_node*, tree_node*)
../../src/gcc/cp/constexpr.c:3981
0x61a313 massage_init_elt
../../src/gcc/cp/typeck2.c:1227
0x619847 process_init_constructor_array
../../src/gcc/cp/typeck2.c:1291
0x619847 process_init_constructor
../../src/gcc/cp/typeck2.c:1593
0x619847 digest_init_r
../../src/gcc/cp/typeck2.c:1121
0x61acca digest_init_flags(tree_node*, tree_node*, int)
../../src/gcc/cp/typeck2.c:1166
0x61acca store_init_value(tree_node*, tree_node*, vec**, int)
../../src/gcc/cp/typeck2.c:800
0x5d4ca7 check_initializer
../../src/gcc/cp/decl.c:6137
0x5ea89d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../src/gcc/cp/decl.c:6765
0x66f640 cp_parser_init_declarator
../../src/gcc/cp/parser.c:18601
0x66fc0e cp_parser_simple_declaration
../../src/gcc/cp/parser.c:12324
0x670024 cp_parser_block_declaration
../../src/gcc/cp/parser.c:12200
0x647e47 cp_parser_declaration
../../src/gcc/cp/parser.c:12097
0x67775a cp_parser_declaration_seq_opt
../../src/gcc/cp/parser.c:11976
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Created attachment 37239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37239=edit
unreduced testcase

Compile with 
gcc -O3 pix.i -flto -r -nostdlib -std=gnu99 -fgnu89-inline -fno-strict-aliasing
-ffunction-sections  -fno-omit-frame-pointer -fPIC --verbose -march=bdver1
-mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mno-movbe
-maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi
-mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle
-mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave
-mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf
-mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq
-mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb
-mno-pcommit -mno-mwaitx -mno-clzero -mno-pku --param l1-cache-size=16 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1

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

[ktkachov at gcc dot gnu.org]

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

Bug ID: 69161
   Summary: [6 Regression] ICE in simplify_const_unary_operation,
at simplify-rtx.c:1633
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

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

The attached testcases ICEs on aarch64 with -O3 -w:
besttry.c: In function 'func_40':
besttry.c:860:1: internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1633
 }
 ^

0xa872ea simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
$SRC/gcc/simplify-rtx.c:1633
0xa84d8f simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
$SRC/gcc/simplify-rtx.c:838
0xfa1b2a combine_simplify_rtx
$SRC/gcc/combine.c:5506
0xfa4317 subst
$SRC/gcc/combine.c:5456
0xfa41bb subst
$SRC/gcc/combine.c:5401
0xfa757c try_combine
$SRC/gcc/combine.c:3264
0xfac385 combine_instructions
$SRC/gcc/combine.c:1267
0xfac385 rest_of_handle_combine
$SRC/gcc/combine.c:14311
0xfac385 execute
$SRC/gcc/combine.c:14354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The assert:
if (!VECTOR_MODE_P (GET_MODE (op)))
  gcc_assert (GET_MODE_INNER (mode) == GET_MODE (op));

in simplify-rtx.c gets triggered when trying to simplify:
(vec_duplicate:V4SI (eq:CC_NZ (reg:CC_NZ 66 cc)
(const_int 0 [0])))

I think we shouldn't be asserting here but rather returning zero to indicate
that no simplification is possible.

I think this bug is latent on previous releases, but this testcases ICEs only
on trunk

[Bug libstdc++/63218] More compact std::bitset for small n

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
(In reply to Marc Glisse from comment #0)
> (another ABI-breaking change in bitset would be to set _WordT to unsigned
> long long on win64)

X32 also wants long long.

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

[doko at gcc dot gnu.org]

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

Bug ID: 69162
   Summary: [6 Regression] ICE in create_tmp_var, at
gimple-expr.c:468
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, i686-linux-gnu, works with -O0

reduced test case:

void fn1() {
  void *a;
  __builtin_va_list *b = a;
  __builtin_va_arg(*b, struct _CK_ATTRIBUTE *);
}

$ gcc -g -O2 -c attrs.i 
attrs.i: In function 'fn1':
attrs.i:4:24: internal compiler error: in create_tmp_var, at gimple-expr.c:468
   __builtin_va_arg(*b, struct _CK_ATTRIBUTE *);
   ~^~~

0x83d3de7 create_tmp_var(tree_node*, char const*)
../../src/gcc/gimple-expr.c:468
0x83f13e7 create_tmp_from_val
../../src/gcc/gimplify.c:498
0x83f13e7 lookup_tmp_var
../../src/gcc/gimplify.c:519
0x83f13e7 internal_get_tmp_var
../../src/gcc/gimplify.c:563
0x85c2fae std_gimplify_va_arg_expr(tree_node*, tree_node*, gimple**, gimple**)
../../src/gcc/targhooks.c:1828
0x881d631 ix86_gimplify_va_arg
../../src/gcc/config/i386/i386.c:10288
0x8748e59 expand_ifn_va_arg_1
../../src/gcc/tree-stdarg.c:1043
0x8748e59 expand_ifn_va_arg
../../src/gcc/tree-stdarg.c:
0x874a100 execute
../../src/gcc/tree-stdarg.c:1164
Please submit a full bug report,
with preprocessed source if appropriate.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

commit ec11da34ececa49554fc8834f0379f25696253f6
Author: rguenth 
Date:   Mon Oct 19 13:58:27 2015 +

2015-10-19  Richard Biener  

* gimple-fold.c (gimple_phi_nonnegative_warnv_p): New function.
(gimple_stmt_nonnegative_warnv_p): Use it.
* match.pd (CPROJ): New operator list.
(cproj (complex ...)): Move simplifications from ...
* builtins.c (fold_builtin_cproj): ... here.

* gcc.dg/torture/builtin-cproj-1.c: Skip for -O0.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@228970
138bc75d-0d04-0410-961f-82ee72b054a4

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

commit 6d37c1112ee274824159e7697fc5e216b9222e0f
Author: rguenth 
Date:   Mon Dec 14 15:26:24 2015 +

2015-12-14  Richard Biener  

PR tree-optimization/68852
* tree-vectorizer.h (struct _slp_tree): Add def_type member.
(SLP_TREE_DEF_TYPE): New accessor.
* tree-vect-stmts.c (vect_is_simple_use): Remove BB vectorization
hack.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_DEF_TYPE.
(vect_build_slp_tree): When a node is to be built up from scalars
do not push a NULL as child but instead set its def_type to
vect_external_def.
(vect_analyze_slp_cost_1): Check for child def-type instead
of NULL.
(vect_detect_hybrid_slp_stmts): Likewise.
(vect_bb_slp_scalar_cost): Likewise.
(vect_get_slp_defs): Likewise.
(vect_slp_analyze_node_operations): Likewise.  Before
processing node push the children def-types to the underlying
stmts vinfo and restore it afterwards.
(vect_schedule_slp_instance): Likewise.
(vect_slp_analyze_bb_1): Do not mark stmts not in SLP instances
as not vectorizable.

* g++.dg/torture/pr68852.C: New testcase.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231619
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[bucaneer at gmail dot com]

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

--- Comment #16 from Justas L  ---
(In reply to Uroš Bizjak from comment #15)
> Please also do some runtime tests, I don't have the Wine source here ...

Wine compiles and runs with no apparent issues.

[Bug rtl-optimization/49358] [4.9 Regression] RA regressed for SSE 2 operand math

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Known to work||5.3.1, 6.0
   Target Milestone|6.0 |4.9.4
Summary|[4.9/5/6 Regression] RA |[4.9 Regression] RA
   |regressed for SSE 2 operand |regressed for SSE 2 operand
   |math|math

--- Comment #4 from H.J. Lu  ---
-O2 with GCC 5.3 and 6 generate:

movapd  %xmm0, %xmm1
mulsd   %xmm0, %xmm1
mulsd   %xmm0, %xmm1
mulsd   %xmm1, %xmm0
ret

[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED
  Known to fail||5.3.1

--- Comment #20 from H.J. Lu  ---
Fixed for 6.0.

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Created attachment 37238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37238=edit
testcase ICEing at -Ofast -floop-interchange

Attaching another testcase that seems to ICE in the same way but it needs
-Ofast -floop-interchange

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 37241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37241=edit
reduced testcase

Compile command line:

gcc -O3 tc.ii -march=bdver1 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-msse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp
-mno-fma -mfma4 -mxop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2
-msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase
-mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f
-mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt
-mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl
-mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx -mno-clzero
-mno-pku --param l1-cache-size=16 --param l1-cache-line-size=64 --param
l2-cache-size=2048 -mtune=bdver1 -fpermissive

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

[doko at gcc dot gnu.org]

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

Bug ID: 69155
   Summary: [6 Regression] ICE (segfault in
gimple_stmt_nonnegative_warnv_p)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37235=edit
preprocessed source

lhapdf package; trunk r232077, x86_64-linux-gnu, works with -O0

$ gfortran -ffree-form -O1 -fPIC -c EVLNNPDF.f
EVLNNPDF.f:1827:29:

   CALL LH_ANDIM_LO(ZN,NF,G0NS,G0)
 1

Warning: Rank mismatch in argument 'p0ns' at (1) (scalar and rank-1)
EVLNNPDF.f:2921:0:

FUNCTION LH_PSI (Z)


internal compiler error: Segmentation fault
0xa4989f crash_signal
../../src/gcc/toplev.c:334
0x85ae35 gimple_stmt_nonnegative_warnv_p(gimple*, bool*, int)
../../src/gcc/gimple-fold.c:6252
0x85aee9 gimple_phi_nonnegative_warnv_p
../../src/gcc/gimple-fold.c:6237
0x85aee9 gimple_stmt_nonnegative_warnv_p(gimple*, bool*, int)
../../src/gcc/gimple-fold.c:6262
0x818e24 tree_expr_nonnegative_p(tree_node*)
../../src/gcc/fold-const.c:13239
0xd67b97 generic_simplify_ABS_EXPR
/build/gcc-6-qAq0ot/gcc-6-6-20160105/build/gcc/generic-match.c:6688
0xd67b97 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*)
/build/gcc-6-qAq0ot/gcc-6-6-20160105/build/gcc/generic-match.c:8959
0x82892b fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../src/gcc/fold-const.c:7652
0x829a79 fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../src/gcc/fold-const.c:12345
0xa783de gimplify_build1(gimple_stmt_iterator*, tree_code, tree_node*,
tree_node*)
../../src/gcc/tree-cfg.c:8562
0xa82274 expand_complex_div_wide
../../src/gcc/tree-complex.c:1113
0xa82274 expand_complex_division
../../src/gcc/tree-complex.c:1319
0xa82274 expand_complex_operations_1
../../src/gcc/tree-complex.c:1588
0xa82274 tree_lower_complex
../../src/gcc/tree-complex.c:1644
0xa82274 execute
../../src/gcc/tree-complex.c:1723
Please submit a full bug report,
with preprocessed source if appropriate.

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

[ktkachov at gcc dot gnu.org]

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

Bug ID: 69160
   Summary: [6 Regression] ICE in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1436
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

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

The attached testcase ICEs on aarch64 with -O3 -w:

besttry.c: In function 'main':
besttry.c:184:1: internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1436
 main (int argc, char *argv[])
 ^~~~

0xcd63d9 vect_get_vec_def_for_operand(tree_node*, gimple*, tree_node*)
$SRC/gcc/tree-vect-stmts.c:1436
0xcd8a98 vect_get_vec_defs(tree_node*, tree_node*, gimple*, vec*, vec*, _slp_tree*, int)
$SRC/gcc/tree-vect-stmts.c:1591
0xcd92bb vectorizable_assignment
$SRC/gcc/tree-vect-stmts.c:4349
0xced320 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
$SRC/gcc/tree-vect-stmts.c:8180
0xcf5d9e vect_transform_loop(_loop_vec_info*)
$SRC/gcc/tree-vect-loop.c:6868
0xd13da3 vectorize_loops()
$SRC/gcc/tree-vectorizer.c:554
0xc1e8d4 execute
$SRC/gcc/tree-ssa-loop.c:420
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Jan Hubicka from comment #2)
> Created attachment 37239 [details]
> unreduced testcase
> 
> Compile with 
> gcc -O3 pix.i -flto -r -nostdlib -std=gnu99 -fgnu89-inline
> -fno-strict-aliasing -ffunction-sections  -fno-omit-frame-pointer -fPIC
> --verbose -march=bdver1 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a
> -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp
> -mno-fma -mfma4 -mxop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2
> -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase
> -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f
> -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt
> -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl
> -mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx
> -mno-clzero -mno-pku --param l1-cache-size=16 --param l1-cache-line-size=64
> --param l2-cache-size=2048 -mtune=bdver1

Reducing Honza's test-case.

[Bug libstdc++/68984] error: ‘constexpr bool std::isinf(double)’ conflicts with a previous declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-06
 Ever confirmed|0   |1

[Bug c++/69158] [6 Regression] ICE in in cxx_eval_indirect_ref, at cp/constexpr.c:2598

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||5.3.1
  Known to fail||6.0

--- Comment #1 from Matthias Klose  ---
trunk r232040, x86_64-linux-gnu

[Bug middle-end/68983] [6 Regression] ICE: in store_field, at expr.c:6659

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

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

[Bug c++/69159] [6 Regression] ICE in store_field, at expr.c:6659

[trippels at gcc dot gnu.org]

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

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 68983 ***

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka  ---
I am seeing same bug. Is there any chance to get a testcase? :))

[Bug target/69053] [6 Regression] ICE in build_vector_from_val

[alahay01 at gcc dot gnu.org]

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

--- Comment #4 from alahay01 at gcc dot gnu.org ---
(In reply to alalaw01 from comment #3)
> Well, this fixes it, but I'm not sure it fixes it in the right place...
> 
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index ee32166..bd66aa5 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -4178,7 +4178,9 @@ get_initial_def_for_reduction (gimple *stmt, tree
> init_val
> break;
>   }
>   }
> -   init_def = build_vector_from_val (vectype, init_value);
> +   init_def = build_vector_from_val (vectype,
> + fold_convert (TREE_TYPE (vectype),
> +   init_value));
> break;
>  
>default:

I don’t think we can move the conversion any earlier, it needs to be somewhere
in get_initial_def_for_reduction.
Possibly you could move the fold_convert on init_val earlier in the function
just before the switch statement, but that has the potential to break more
things. So I’d probably leave it where it is.

Also, the fold_convert should just vanish if there is nothing to do, so that
shouldn't be an issue for existing vectorisations.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to Justas L from comment #14)
> (In reply to Uroš Bizjak from comment #13)
> > Justas, can you please test the following patch
> 
> Thank you, it indeed solves the problem.

Please also do some runtime tests, I don't have the Wine source here ...

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

[zsojka at seznam dot cz]

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

Bug ID: 69156
   Summary: [6 Regression] gcc.dg/pr59630.c: ICE: verify_gimple
failed: non-trivial conversion at assignment with
-fno-tree-ccp
   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: ---

Created attachment 37236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37236=edit
reduced testcase (gcc.dg/pr59630.c)

Compiler output:
$ gcc -O -fno-tree-ccp testcase.c 
testcase.c: In function 'foo':
testcase.c:3:18: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
   _Bool (*f)() = __builtin_abs;
  ^

testcase.c:5:1: error: non-trivial conversion at assignment
 }
 ^

_Bool
int
_4 = 0;
testcase.c:5:1: internal compiler error: verify_gimple failed
0xbc8ec6 verify_gimple_in_cfg(function*, bool)
/repo/gcc-trunk/gcc/tree-cfg.c:5119
0xa7c3c7 execute_function_todo
/repo/gcc-trunk/gcc/passes.c:1958
0xa7ccbb execute_todo
/repo/gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


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

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

[doko at gcc dot gnu.org]

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

Bug ID: 69157
   Summary: [6 Regression] ICE in vect_transform_stmt, at
tree-vect-stmts.c:8176
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk r232040, x86_64-linux-gnu, -O2 avoids the issue.

reduced test case:

typedef struct {
  float *data_normal3f;
  float *data_texcoordtexture2f;
  float *data_texcoordlightmap2f;
  float *data_color4f;
} dp_model_t;
dp_model_t a;
float *b;
void fn1() {
  int c;
  a.data_normal3f = b + c * 3;
  a.data_texcoordtexture2f = a.data_normal3f + c * 3;
  a.data_texcoordlightmap2f = a.data_color4f =
  a.data_texcoordlightmap2f + c * 2;
}

$ gcc -c -g -O3 model_brush.i
model_brush.i: In function 'fn1':
model_brush.i:9:6: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:8176
 void fn1() {
  ^~~

0xb5a9b2 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../src/gcc/tree-vect-stmts.c:8176
0xb716b6 vect_schedule_slp_instance
../../src/gcc/tree-vect-slp.c:3537
0xb713ce vect_schedule_slp_instance
../../src/gcc/tree-vect-slp.c:3412
0xb74325 vect_schedule_slp(vec_info*)
../../src/gcc/tree-vect-slp.c:3609
0xb74b0c vect_slp_bb(basic_block_def*)
../../src/gcc/tree-vect-slp.c:2633
0xb76605 execute
../../src/gcc/tree-vectorizer.c:759
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/69158] [6 Regression] ICE in in cxx_eval_indirect_ref, at cp/constexpr.c:2598

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Confirmed.  Not sure if there's a dup.  With -std=c++1y started with:

commit 07850d167a92588ede252d582306ad441417ae42
Author: jason 
Date:   Fri Mar 29 19:51:36 2013 +

N3582
* cp-tree.h (AUTO_IS_DECLTYPE): New.
* parser.c (cp_parser_decltype): Handle decltype(auto).
(cp_parser_type_id_1): Allow auto without a late-specified
return in C++1y.
(cp_parser_primary_expression): Use the return value of
finish_parenthesized_expr.
(cp_parser_transaction_expression): Likewise.
* semantics.c (force_paren_expr): New.
(finish_parenthesized_expr): Use it.
* call.c (build_conditional_expr_1): Likewise.
* pt.c (do_auto_deduction): Handle decltype(auto).
(tsubst_copy): Handle PAREN_EXPR.
(tsubst_copy_and_build): Likewise.
* error.c (dump_expr): Handle PAREN_EXPR.
* cxx-pretty-print.c (pp_cxx_expression): Likewise.
* mangle.c (write_expression): Ignore PAREN_EXPR.

* parser.c (cp_parser_decltype_expr): Split out...
(cp_parser_decltype): ...from here.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197248
138bc75d-0d04-0410-961f-82ee72b054a4

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||5.3.1
   Target Milestone|--- |6.0
  Known to fail||6.0

[Bug libstdc++/68984] error: ‘constexpr bool std::isinf(double)’ conflicts with a previous declaration

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
This is really a dup of PR60407, PR48891, but it is true that the error message
looks a bit different when you write things this way.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
To check for an obvious suspect:

What do you get if you compile with "-O0 -ffrontend-optimize" ?

[Bug c++/69159] New: [6 Regression] ICE in store_field, at expr.c:6659

[doko at gcc dot gnu.org]

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

Bug ID: 69159
   Summary: [6 Regression] ICE in store_field, at expr.c:6659
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232040, x86_64-linux-gnu

reduced test case:

class GeneralIO {
protected:
  int util_;
  bool bin_;
  ~GeneralIO();
};
class A : GeneralIO {
  A(const GeneralIO &);
};
A::A(const GeneralIO ) : GeneralIO(p1) {}

$ g++ -c -g -O2 corpus-io-eda.ii 
corpus-io-eda.ii: In constructor 'A::A(const GeneralIO&)':
corpus-io-eda.ii:10:41: internal compiler error: in store_field, at expr.c:6659
 A::A(const GeneralIO ) : GeneralIO(p1) {}
 ^

0x86bf15 store_field
../../src/gcc/expr.c:6659
0x868f4e expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5020
0x788dbe expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3606
0x788dbe expand_gimple_stmt
../../src/gcc/cfgexpand.c:3702
0x78a8bc expand_gimple_basic_block
../../src/gcc/cfgexpand.c:5708
0x78f7c6 execute
../../src/gcc/cfgexpand.c:6323
Please submit a full bug report,
with preprocessed source if appropriate.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
The new ICE started with r230484:

commit 3a18d05c6e55490e20387ffed5a7a41582cd4f38
Author: rsandifo 
Date:   Tue Nov 17 18:47:44 2015 +

Add genmatch support for internal functions

This patch makes genmatch match calls based on combined_fn rather
than built_in_function and extends the matching to internal functions.
It also uses fold_const_call to fold the calls to a constant, rather
than going through fold_builtin_n.

In order to slightly simplify the code and remove potential
ambiguity, the patch enforces lower case for tree codes
(foo->FOO_EXPR), caps for functions (no built_in_hypot->BUILT_IN_HYPOT)
and requires an exact match for user-defined identifiers.  The first two
were already met in practice but there were a couple of cases where
operator lists were defined in one case and used in another.

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||5.3.1
   Target Milestone|--- |6.0
  Known to fail||6.0

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
markus@x4 tmp % cat pix.i
short c;
int d;
int fn1(int p1, int p2) {
  int a, b;
  a = p1 >> 3 & p2;
  b = p1 & 072;
  a |= a >> 5;
  a |= b >> 5;
  return a;
}
void fn2() {
  short *e = 
  int *f;
  int g;
  while (d -= 4) {
fn1(1, 1);
fn1(1, 1) * fn1(1, 1) * fn1(1, 1);
*e++ = fn1(*f++, g);
*e++ = fn1(*f++, g);
  }
}

markus@x4 tmp % gcc -c -mavx2 -O3 pix.i
pix.i: In function ‘fn2’:
pix.i:11:6: internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:229
 void fn2() {
  ^~~

0xc46f92 compute_live_loop_exits
../../gcc/gcc/tree-ssa-loop-manip.c:229
0xc46f92 add_exit_phis_var
../../gcc/gcc/tree-ssa-loop-manip.c:316
0xc46f92 add_exit_phis
../../gcc/gcc/tree-ssa-loop-manip.c:338
0xc46f92 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../gcc/gcc/tree-ssa-loop-manip.c:654
0xd491cd vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:634
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug other/67627] libatomic parallel build failure

[nsz at gcc dot gnu.org]

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

--- Comment #2 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Wed Jan  6 14:51:35 2016
New Revision: 232102

URL: https://gcc.gnu.org/viewcvs?rev=232102=gcc=rev
Log:
Fix libatomic multilib parallel build (PR other/67627)

The all-multi target may be built in parallel with the %_.lo
targets which generate make dependencies that are parsed during
the build of all-multi.

This patch forces all-multi to only run after the *_.lo targets
are done.

libatomic:
PR other/67627
* Makefile.am (all-multi): Add dependency.
* Makefile.in: Regenerate.


Modified:
trunk/libatomic/ChangeLog
trunk/libatomic/Makefile.am
trunk/libatomic/Makefile.in

[Bug tree-optimization/69163] New: [6 Regression] ICE in rewrite_use_nonlinear_expr, at tree-ssa-loop-ivopts.c:7086

[doko at gcc dot gnu.org]

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

Bug ID: 69163
   Summary: [6 Regression] ICE in rewrite_use_nonlinear_expr, at
tree-ssa-loop-ivopts.c:7086
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, powerpc64le-linux-gnu, works with -O2

reduced test case:

void fn1(char *p1, char *p2, int p3, int p4) {
  int x, y;
  for (; y; y++) {
x = 0;
for (; x < p4; x++) {
  *p1 = *p2;
  p1--;
  p2--;
}
p2 += p3;
  }
}

$ g++ -c -g -O3 -Wno-strict-aliasing svga_cirrus.ii
svga_cirrus.ii: In function 'void fn1(char*, char*, int, int)':
svga_cirrus.ii:1:6: internal compiler error: in rewrite_use_nonlinear_expr, at
tree-ssa-loop-ivopts.c:7086
 void fn1(char *p1, char *p2, int p3, int p4) {
  ^~~

0x1094dfbf rewrite_use_nonlinear_expr
../../src/gcc/tree-ssa-loop-ivopts.c:7086
0x1094dfbf rewrite_use
../../src/gcc/tree-ssa-loop-ivopts.c:7347
0x1094dfbf rewrite_uses
../../src/gcc/tree-ssa-loop-ivopts.c:7380
0x109567f3 tree_ssa_iv_optimize_loop
../../src/gcc/tree-ssa-loop-ivopts.c:7726
0x109567f3 tree_ssa_iv_optimize()
../../src/gcc/tree-ssa-loop-ivopts.c:7758
0x1096f23b execute
../../src/gcc/tree-ssa-loop.c:554
Please submit a full bug report,
with preprocessed source if appropriate.

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

[doko at gcc dot gnu.org]

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

Bug ID: 69164
   Summary: [6 Regression] ICE in create_tmp_var, at
gimple-expr.c:468
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, i686-linux-gnu, works with -O0

reduced test case:

class A {
public:
  class B {
friend A;
B() {}
bool : 1;
  };
  B m_fn1() {
B r;
return r;
  }
};

class C {
public:
  class D {
  public:
D(C *p1) : m_label(p1->m_assembler.m_fn1()) {}
A::B m_label;
  };
  A m_assembler;
};

enum YarrCharSize {};
class F : C {
  D generateDotStarEnclosure_findEOLLoop = this;

public:
  F(int, YarrCharSize) {}
};
YarrCharSize a;
int b;
void fn1() { F(b, a); }

$ g++ -c -march=i686 -g -O3 -std=gnu++11  -Wno-invalid-offsetof YarrJIT.ii
YarrJIT.ii: In constructor 'C::D::D(C*)':
YarrJIT.ii:33:23: internal compiler error: in analyze_access_subtree, at
tree-sra.c:2340
 void fn1() { F(b, a); }
   ^

0x876134e analyze_access_subtree
../../src/gcc/tree-sra.c:2339
0x87610c7 analyze_access_subtree
../../src/gcc/tree-sra.c:2312
0x87669dd analyze_access_trees
../../src/gcc/tree-sra.c:2402
0x87669dd analyze_all_variable_accesses
../../src/gcc/tree-sra.c:2655
0x8766dad perform_intra_sra
../../src/gcc/tree-sra.c:3631
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/69167] New: [6 Regression] internal compiler error: SSA corruption

[doko at gcc dot gnu.org]

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

Bug ID: 69167
   Summary: [6 Regression] internal compiler error: SSA corruption
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, powerpc64le-linux-gnu, works with -O0

reduced test case:

enum { SEND_TOFILE } __sigsetjmp();
void fclose();
void foldergets();
void sendpart_stats(int *p1) {
  int *a = p1;
  fclose();
  p1 = 0;
  if (__sigsetjmp())
while (foldergets)
  fclose(a ? sendpart_stats : 0);
  if (p1)
fclose();
}

$ gcc -c -g -O1 send.i 

Unable to coalesce ssa_names 2 and 8 which are marked as MUST COALESCE.
p1_2(ab) and  p1_8(D)(ab)
send.i: In function 'sendpart_stats':
send.i:4:6: internal compiler error: SSA corruption
 void sendpart_stats(int *p1) {
  ^~

0x107c0b23 fail_abnormal_edge_coalesce
../../src/gcc/tree-ssa-coalesce.c:936
0x107c0b23 coalesce_partitions
../../src/gcc/tree-ssa-coalesce.c:1337
0x107c0b23 coalesce_ssa_name()
../../src/gcc/tree-ssa-coalesce.c:1821
0x10762e6b remove_ssa_form
../../src/gcc/tree-outof-ssa.c:974
0x10762e6b rewrite_out_of_ssa(ssaexpand*)
../../src/gcc/tree-outof-ssa.c:1198
0x102a7efb execute
../../src/gcc/cfgexpand.c:6124
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug libstdc++/63218] More compact std::bitset for small n

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to H.J. Lu from comment #2)
> X32 also wants long long.

Is there a good way to ask for the longest of the integer types that are fast?
stdint.h has things like int_fastN_t (btw, I don't like some of the choices I
see for them in glibc (probably imposed by the ABI though)), but this is a
different question. That may not be so well-defined though.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

commit 8a36d0ec201ef1511b372523f72a763b836107b0
Author: jason 
Date:   Wed Apr 15 21:17:29 2015 +

* constexpr.c (cxx_eval_store_expression): Ignore clobbers.
(build_constexpr_constructor_member_initializers): Loop to find
the BIND_EXPR.
* decl.c (start_preparsed_function): Clobber the object at the
beginning of a constructor.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222135
138bc75d-0d04-0410-961f-82ee72b054a4

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

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #3 from Joost VandeVondele  
---
reduced

MODULE m_numeric_tools
 INTEGER, PARAMETER :: dp=8
CONTAINS
subroutine llsfit_svd(xx,yy,sigma,nfuncs,funcs,chisq,par,var,cov,info)
 real(dp),intent(in) :: xx(:),yy(:),sigma(:)
 real(dp),dimension(SIZE(xx)) :: bb,sigm1
 real(dp) :: tmp(nfuncs)
 real(dp),allocatable :: work(:),Vt(:,:),U(:,:),S(:)
 WHERE (S>TOL_*MAXVAL(S))
  tmp=MATMUL(bb,U)/S
 END WHERE
end subroutine llsfit_svd
END MODULE m_numeric_tools

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

commit 82fc0e0a3a4f82770e7e076cab5309bb1bd9fe87
Author: vries 
Date:   Fri Apr 17 09:26:59 2015 +

Postpone expanding va_arg until pass_stdarg

2015-04-17  Tom de Vries  
Michael Matz  

* gimple-iterator.c (update_modified_stmts): Remove static.
* gimple-iterator.h (update_modified_stmts): Declare.
* gimplify.c (gimplify_modify_expr): Handle IFN_VA_ARG.
(gimplify_va_arg_internal): New function.
(gimplify_va_arg_expr): Use IFN_VA_ARG.
* gimplify.h (gimplify_va_arg_internal): Declare.
* internal-fn.c (expand_VA_ARG): New unreachable function.
* internal-fn.def (VA_ARG): New DEF_INTERNAL_FN.
* tree-stdarg.c (gimple_call_ifn_va_arg_p, expand_ifn_va_arg_1)
(expand_ifn_va_arg): New function.
(pass_data_stdarg): Add PROP_gimple_lva to properties_provided field.
(pass_stdarg::execute): Call expand_ifn_va_arg.
(pass_data_lower_vaarg): New pass_data.
(pass_lower_vaarg): New gimple_opt_pass.
(pass_lower_vaarg::gate, pass_lower_vaarg::execute)
(make_pass_lower_vaarg): New function.
* cfgexpand.c (pass_data_expand): Add PROP_gimple_lva to
properties_required field.
* passes.def (all_passes): Add pass_lower_vaarg.
* tree-pass.h (PROP_gimple_lva): Add define.
(make_pass_lower_vaarg): Declare.

* gcc.dg/tree-ssa/stdarg-2.c: Change f15 scan-tree-dump for target
x86_64-*-*.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222173
138bc75d-0d04-0410-961f-82ee72b054a4

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> To check for an obvious suspect:
>
> What do you get if you compile with "-O0 -ffrontend-optimize" ?

This gives the ICE. The test compiles with -O1 -fno-frontend-optimize. 

I see the ICE with r222875, but not with r222822. Likely revision r222864.

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

[doko at gcc dot gnu.org]

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

Bug ID: 69165
   Summary: [6 Regression] ICE in create_tmp_var, at
gimple-expr.c:468
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, i686-linux-gnu, works with -O0

reduced test case:

class A {
public:
  class B {
friend A;
B() {}
bool : 1;
  };
  B m_fn1() { return B(); }
};

class C {
  void m_fn2(int *&);
  class D {
  public:
C *Label_masm;
D() : m_label(Label_masm->m_assembler.m_fn1()) {}
A::B m_label;
  };
  A m_assembler;
};

void C::m_fn2(int *&) { D(); }

$ g++ -march=i686 -c -std=c++11 -g -O2 -c JITArithmetic.ii  
JITArithmetic.ii: In constructor 'C::D::D()':
JITArithmetic.ii:22:30: internal compiler error: in analyze_access_subtree, at
tree-sra.c:2340
 void C::m_fn2(int *&) { D(); }
  ^

0x876134e analyze_access_subtree
../../src/gcc/tree-sra.c:2339
0x87610c7 analyze_access_subtree
../../src/gcc/tree-sra.c:2312
0x87669dd analyze_access_trees
../../src/gcc/tree-sra.c:2402
0x87669dd analyze_all_variable_accesses
../../src/gcc/tree-sra.c:2655
0x8766dad perform_intra_sra
../../src/gcc/tree-sra.c:3631
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
*** Bug 69165 has been marked as a duplicate of this bug. ***

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Dup?

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

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

[doko at gcc dot gnu.org]

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

Bug ID: 69166
   Summary: [6 Regression] ICE in get_initial_def_for_reduction,
at tree-vect-loop.c:4188
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, powerpc64le-linux-gnu, works with -O2

reduced test case:

double a;
int b, c, d;
void fn1();
void fn2() {
  double *e;
  b = 0;
  for (; b < d; b++) {
c = 0;
for (; c < d; c++)
  e[b] /= a;
  }
  fn1();
}

$ gcc -c -g -O3 fft.i 
fft.i: In function 'fn2':
fft.i:4:6: internal compiler error: in get_initial_def_for_reduction, at
tree-vect-loop.c:4188
 void fn2() {
  ^~~

0x108e4b83 get_initial_def_for_reduction(gimple*, tree_node*, tree_node**)
../../src/gcc/tree-vect-loop.c:4188
0x1015e5ff vect_create_epilog_for_reduction
../../src/gcc/tree-vect-loop.c:4347
0x108e6517 vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**,
_slp_tree*)
../../src/gcc/tree-vect-loop.c:6175
0x108dd16b vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
../../src/gcc/tree-vect-stmts.c:8232
0x108e1e7f vect_transform_loop(_loop_vec_info*)
../../src/gcc/tree-vect-loop.c:6868
0x109005d3 vectorize_loops()
../../src/gcc/tree-vectorizer.c:554
0x108167eb execute
../../src/gcc/tree-ssa-loop.c:420
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/69163] [6 Regression] ICE in rewrite_use_nonlinear_expr, at tree-ssa-loop-ivopts.c:7086

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup. (Please check for dups before reporting. Thanks)

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

[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

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

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Another dup.
https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=get_initial_def_for_reduction_id=135280

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

[Bug target/69053] [6 Regression] ICE in build_vector_from_val

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

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

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

[doko at gcc dot gnu.org]

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

Bug ID: 69170
   Summary: [6 Regression] ICE (segfault) in
find_uses_to_rename_use
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, powerpc64le-linux-gnu, works with -O2 or without -fPIC

reduced test case:

typedef long sha2_word_t;
typedef struct {
  sha2_word_t length_upper, length_lower;
  char buf[];
} hash_state;
int a;
hash_state b;
void fn1() {
  a = 0;
  for (; a < 8; a++)
b.buf[a + 1024 / 8] = b.length_upper >> (1 - a) * 5;
  a = 0;
  for (; a < 8; a++)
b.buf[a + 1024 / 8 + 8] = b.length_lower >> (1 - a) * 5;
}

$ gcc -std=c99 -c -g -O3 -fno-strict-aliasing -fPIC hash_SHA2_template.i
hash_SHA2_template.i: In function 'fn1':
hash_SHA2_template.i:8:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~

0x106c33b3 crash_signal
../../src/gcc/toplev.c:334
0x1080027c find_uses_to_rename_use
../../src/gcc/tree-ssa-loop-manip.c:368
0x1080095f find_uses_to_rename_use
../../src/gcc/ssa-iterators.h:566
0x1080095f find_uses_to_rename_stmt
../../src/gcc/tree-ssa-loop-manip.c:425
0x1080095f find_uses_to_rename_bb
../../src/gcc/tree-ssa-loop-manip.c:457
0x10802e3f find_uses_to_rename
../../src/gcc/tree-ssa-loop-manip.c:479
0x10802e3f rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int,
loop*)
../../src/gcc/tree-ssa-loop-manip.c:642
0x10913b83 execute_vrp
../../src/gcc/tree-vrp.c:10303
0x10913b83 execute
../../src/gcc/tree-vrp.c:10405
Please submit a full bug report,
with preprocessed source if appropriate.

(gdb) bt
#0  0x1080027c in find_uses_to_rename_use (bb=0x3fffb59802d8,
use=0x3fffb59236d8, 
use_blocks=0x11687400, need_phis=0x115fb580) at
../../src/gcc/tree-ssa-loop-manip.c:368
#1  0x10800960 in find_uses_to_rename_use (need_phis=,
use_blocks=, 
use=, bb=0x3fffb59802d8) at
../../src/gcc/ssa-iterators.h:566
#2  find_uses_to_rename_stmt (use_flags=, need_phis=, 
use_blocks=, stmt=0x3fffb5a73ca0) at
../../src/gcc/tree-ssa-loop-manip.c:425
#3  find_uses_to_rename_bb (bb=0x3fffb59802d8, use_blocks=0x11687400,
need_phis=0x115fb580, use_flags=1)
at ../../src/gcc/tree-ssa-loop-manip.c:457
#4  0x10802e40 in find_uses_to_rename (use_flags=1,
need_phis=0x115fb580, use_blocks=0x11687400, 
changed_bbs=) at ../../src/gcc/tree-ssa-loop-manip.c:479
#5  rewrite_into_loop_closed_ssa_1 (changed_bbs=,
update_flag=, 
use_flags=, loop=0x0) at
../../src/gcc/tree-ssa-loop-manip.c:642
#6  0x10913b84 in execute_vrp (warn_array_bounds_p=false) at
../../src/gcc/tree-vrp.c:10303
#7  (anonymous namespace)::pass_vrp::execute (this=) at
../../src/gcc/tree-vrp.c:10405
#8  0x105de3b4 in execute_one_pass (pass=0x114ef0d0) at
../../src/gcc/passes.c:2336
#9  0x105dea38 in execute_pass_list_1 (pass=0x114ef0d0) at
../../src/gcc/passes.c:2410
#10 0x105dea50 in execute_pass_list_1 (pass=0x114ed010) at
../../src/gcc/passes.c:2411
#11 0x105deaf8 in execute_pass_list (fn=,
pass=)
at ../../src/gcc/passes.c:2421
#12 0x102e0800 in cgraph_node::expand (this=0x3fffb5930cf0) at
../../src/gcc/cgraphunit.c:1971
#13 0x102e22c8 in expand_all_functions () at
../../src/gcc/cgraphunit.c:2107
#14 symbol_table::compile (this=0x3fffb58d) at
../../src/gcc/cgraphunit.c:2463
#15 0x102e4724 in symbol_table::compile (this=0x3fffb58d) at
../../src/gcc/cgraphunit.c:2368
#16 symbol_table::finalize_compilation_unit (this=0x3fffb58d) at
../../src/gcc/cgraphunit.c:2553
#17 0x106c3854 in compile_file () at ../../src/gcc/toplev.c:489
#18 0x10170abc in do_compile () at ../../src/gcc/toplev.c:1985
#19 toplev::main (this=, argc=21, argv=0x33c8) at
../../src/gcc/toplev.c:2092
#20 0x10172a98 in main (argc=, argv=0x33c8) at
../../src/gcc/main.c:39

[Bug other/67627] libatomic parallel build failure

[nsz at gcc dot gnu.org]

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

--- Comment #4 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Wed Jan  6 17:43:24 2016
New Revision: 232107

URL: https://gcc.gnu.org/viewcvs?rev=232107=gcc=rev
Log:
2016-01-06  Szabolcs Nagy  

Backport from mainline:
2016-01-06  Szabolcs Nagy  

PR other/67627
* Makefile.am (all-multi): Add dependency.
* Makefile.in: Regenerate.


Modified:
branches/gcc-4_9-branch/libatomic/ChangeLog
branches/gcc-4_9-branch/libatomic/Makefile.am
branches/gcc-4_9-branch/libatomic/Makefile.in

[Bug other/67627] libatomic parallel build failure

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from nsz at gcc dot gnu.org ---
Fixed in r232102, backported to gcc-5 and gcc-49 branches.

[Bug target/69171] [6 Regression] error: unrecognizable insn: on x86_64 with -O2

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-06
 CC||hjl.tools at gmail dot com,
   ||trippels at gcc dot gnu.org
Summary|error: unrecognizable insn: |[6 Regression] error:
   |on x86_64 with -O2  |unrecognizable insn: on
   ||x86_64 with -O2
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
trippels@CFARM-IUT-TLSE3 ~ % cat bug261.c
#pragma pack(2)
struct {
  int n;
} a;
float b;
int c;
void fn1() { fn2(c, fn1, b * a.n); }

trippels@CFARM-IUT-TLSE3 ~ % gcc -w -c -O2 bug261.c
bug261.c: In function ‘fn1’:
bug261.c:7:1: error: unrecognizable insn:
 void fn1() { fn2(c, fn1, b * a.n); }
 ^~~~

(insn 18 17 6 2 (set (reg:V4SF 21 xmm0 [93])
(vec_merge:V4SF (vec_duplicate:V4SF (float:SF (mem/c:SI (symbol_ref:DI
("a") [flags 0x2] ) [2 a.n+0 S4 A16])))
(reg:V4SF 21 xmm0 [93])
(const_int 1 [0x1]))) bug261.c:7 -1
 (nil))
bug261.c:7:1: internal compiler error: in extract_insn, at recog.c:2286
0xa6541a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0xa65449 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0xa32857 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2286
0xa328d4 extract_insn_cached(rtx_insn*)
../../gcc/gcc/recog.c:2177
0x7f4fed cleanup_subreg_operands(rtx_insn*)
../../gcc/gcc/final.c:3103
0xa30037 split_insn
../../gcc/gcc/recog.c:2899
0xa34ba7 split_all_insns()
../../gcc/gcc/recog.c:2953
0xa34c28 rest_of_handle_split_after_reload
../../gcc/gcc/recog.c:3889
0xa34c28 execute
../../gcc/gcc/recog.c:3918

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

[doko at gcc dot gnu.org]

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

Bug ID: 69173
   Summary: [6 Regression] ICE (segfault) in vinfo_for_stmt
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, powerpc64le-linux-gnu, works with -O2

reduced test case:

unsigned a;
unsigned *b;
void fn1() {
  char c;
  while (b < (unsigned *)fn1) {
a += b[2] + c;
b++;
  }
}

$ gcc -c -g -O3 woff.i
woff.i: In function 'fn1':
woff.i:3:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~

0x106c33b3 crash_signal
../../src/gcc/toplev.c:334
0x108e9adc vinfo_for_stmt
../../src/gcc/tree-vectorizer.h:704
0x108e9adc vect_fixup_reduc_chain
../../src/gcc/tree-vect-loop.c:966
0x108e9adc vect_fixup_scalar_cycles_with_patterns
../../src/gcc/tree-vect-loop.c:988
0x108e9adc vect_analyze_loop_2
../../src/gcc/tree-vect-loop.c:1836
0x108e9adc vect_analyze_loop(loop*)
../../src/gcc/tree-vect-loop.c:2251
0x1090002f vectorize_loops()
../../src/gcc/tree-vectorizer.c:532
0x108167eb execute
../../src/gcc/tree-ssa-loop.c:420
Please submit a full bug report,
with preprocessed source if appropriate.

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

[tulipawn at gmail dot com]

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

--- Comment #6 from PeteVine  ---
The two lines read:

movwr0, #:lower16:.LANCHOR0+32768
movtr0, #:upper16:.LANCHOR0+32768

[Bug target/69171] New: error: unrecognizable insn: on x86_64 with -O2

[dcb314 at hotmail dot com]

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

Bug ID: 69171
   Summary: error: unrecognizable insn: on x86_64 with -O2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 37242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37242=edit
gzipped C source code

The attached code, when compiled by gcc trunk dated 20160106, revision 232102,
says this:

$ ../results/bin/gcc -c -O2 bug261.c
./argus_util.c: In function ‘ArgusPrintSum’:
./argus_util.c:5856:1: error: unrecognizable insn:

(insn 213 212 36 6 (set (reg:V4SF 21 xmm0 [122])
(vec_merge:V4SF (vec_duplicate:V4SF (float:SF (mem:SI (plus:DI
(reg/v/f:DI 0 ax [orig:90 agr ] [90])
(const_int 24 [0x18])) [2 agr_11->act.n+0 S4
A16])))
(reg:V4SF 21 xmm0 [122])
(const_int 1 [0x1]))) ./argus_util.c:5830 -1
 (nil))
./argus_util.c:5856:1: internal compiler error: in extract_insn, at
recog.c:2286
0xa8c259 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/trunk/gcc/rtl-error.c:108
0xa8c27e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/trunk/gcc/rtl-error.c:116
0xa503da extract_insn(rtx_insn*)
../../src/trunk/gcc/recog.c:2277
0xa549ca extract_insn_cached(rtx_insn*)
../../src/trunk/gcc/recog.c:2177

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

[doko at gcc dot gnu.org]

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

Bug ID: 69172
   Summary: [6 Regression] ICE in make_ssa_name_fn, at
tree-ssanames.c:266
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

r232077, powerpc64le-linux-gnu, works with -O2

reduced test case:

int a;
__inline __attribute__((__always_inline__)) void *mempcpy(void *p1, void *p2,
  long p3) {
  return __builtin___mempcpy_chk(p1, p2, p3, 0);
}

void sd_inode_set_vid() {
  int *b = , *c = 
  mempcpy(c, b, sizeof(int));
}

$ gcc -c -g -O3 sd_inode.i
sd_inode.i: In function 'sd_inode_set_vid':
sd_inode.i:10:1: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.c:266
 }
 ^

0x108af2bf make_ssa_name_fn(function*, tree_node*, gimple*)
../../src/gcc/tree-ssanames.c:263
0x1043d077 make_ssa_name
../../src/gcc/tree-ssanames.h:110
0x1043d077 gimple_build(gimple**, unsigned int, tree_code, tree_node*,
tree_node*)
../../src/gcc/gimple-fold.c:5985
0x10443e27 gimple_fold_builtin_memory_chk
../../src/gcc/gimple-fold.c:1713
0x10443e27 gimple_fold_builtin
../../src/gcc/gimple-fold.c:2836
0x104451f7 gimple_fold_call
../../src/gcc/gimple-fold.c:3112
0x104451f7 fold_stmt_1
../../src/gcc/gimple-fold.c:3716
0x1084270f
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../src/gcc/tree-ssa-propagate.c:1232
0x10cbb2bf dom_walker::walk(basic_block_def*)
../../src/gcc/domwalk.c:265
0x10841bd7 substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../src/gcc/tree-ssa-propagate.c:1332
0x107b2373 ccp_finalize
../../src/gcc/tree-ssa-ccp.c:947
0x107b2373 do_ssa_ccp
../../src/gcc/tree-ssa-ccp.c:2409
0x107b2373 execute
../../src/gcc/tree-ssa-ccp.c:2452
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug fortran/69080] No automatic deallocation of allocatable function results

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #12 from Mikael Morin  ---
(In reply to kargl from comment #11)
> (In reply to Mueller from comment #9)
> > (In reply to Mueller from comment #8)
> > > I think, in theory, the compiler could detect something like
> > > 
> > > call some_subroutine(function_returning_allocatable())
> > > 
> > > to be a potential case for automatic deallocation of the returned
> > > allocatable. But, as was pointed out above (if I understood correctly),
> > > automatic deallocation of allocatable function results is not part of the
> > > standard.
> > 
> > Now that I'm thinking about the example above: Isn't the allocatable
> > function result here a local (temporary) variable and should thus be
> > deallocated automatically?
> 
> No, it is not a local temporary variable.  If the function
> result is deallocated prior to returning from the function,
> what exactly is going to be returned?  Whatever had been stored
> in the memory associated with the allocated function result
> variable would be gone.  That is, you can't reference 
> unallocated memory.
> 
I think by local temporary he was meaning local to the _outer_ procedure call,
not local to the inner procedure body.
For the following code
  call foo(some_func())
a temporary variable is made to hold the value of some_func() before calling
foo, and it is cleaned up after foo has returned.

I think the point is not whether the return value should be deallocated before
returning (it should not as stated by Steve), it is instead whether it should
be deallocated after being used as actual argument (in my opinion it makes
sense to do it).

[Bug tree-optimization/68911] [6 Regression] wrong code with -O1 -ftree-vrp

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2016-01-04 00:00:00 |2015-12-15 0:00

--- Comment #6 from amker at gcc dot gnu.org ---
Here is the situation:
  scev_probably_wraps_p returns:
 A) true, in this case there is nothing to do;
 B) false.  since this information only indicates no-overflow when
may_be_zero is false.  We then have three sub-cases:
B.1) may_be_zero is false.  The current code logic works.
B.2) may_be_zero is true, and scev will overflow after nit(bound)
iterations.
B.3) may_be_zero is true, and scev doesn't overflow after nit(bound)
iterations.

So simply bypass and return when loop may exit at its first iteration is not
optimal.  Because case B.3) will be missed.

I think the right fix is add overflow check in below code:

  /* We are only entering here for loop header PHI nodes, so using
 the number of latch executions is the correct thing to use.  */
  if (max_loop_iterations (loop, ))
{
  value_range maxvr = VR_INITIALIZER;
  signop sgn = TYPE_SIGN (TREE_TYPE (step));
  bool overflow;

  widest_int wtmp = wi::mul (wi::to_widest (step), nit, sgn,
 );
  /* If the multiplication overflowed we can't do a meaningful
 adjustment.  Likewise if the result doesn't fit in the type
 of the induction variable.  For a signed type we have to
 check whether the result has the expected signedness which
 is that of the step as number of iterations is unsigned.  */
  if (!overflow
  && wi::fits_to_tree_p (wtmp, TREE_TYPE (init))
  && (sgn == UNSIGNED
  || wi::gts_p (wtmp, 0) == wi::gts_p (step, 0)))
{
  tem = wide_int_to_tree (TREE_TYPE (init), wtmp);
  extract_range_from_binary_expr (, PLUS_EXPR,
  TREE_TYPE (init), init, tem);
  /* Likewise if the addition did.  */
  if (maxvr.type == VR_RANGE)
{

  //  <---HERE

  tmin = maxvr.min;
  tmax = maxvr.max;
}
}
}

This overflow check is specifically for scev when may_be_zero is true. 
Actually I think it might be possible for us to remove the call to
scev_probably_wraps_p, since this new check together with the variable
"overflow" can cover the case when scev does overflow when may_be_zero is
false.

I am testing a patch for this.

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #6 from Matthias Klose  ---
seen as well on powerpc64le-linux-gnu

typedef int uint32_t;
int c, e, f, g, h;
short *d;
uint32_t fn1(uint32_t p1, uint32_t p2) {
  uint32_t a, b;
  a = p1 >> 3 & p2;
  b = p1 & 072;
  a |= a >> 5;
  a |= b >> 5;
  return a;
}

void fn2() {
  uint32_t *i;
  uint32_t j;
  while (c -= 4) {
fn1(e, j);
fn1(f, j) * fn1(g, j) * fn1(h, j);
*d++ = fn1(*i++, j);
*d++ = fn1(*i++, j);
  }
}

$ gcc -c -g -O3 pixman-fast-path.i
pixman-fast-path.i: In function 'fn2':
pixman-fast-path.i:13:6: internal compiler error: in compute_live_loop_exits,
at tree-ssa-loop-manip.c:229
 void fn2() {
  ^~~

0x1080260f compute_live_loop_exits
../../src/gcc/tree-ssa-loop-manip.c:229
0x1080260f add_exit_phis_var
../../src/gcc/tree-ssa-loop-manip.c:316
0x1080260f add_exit_phis
../../src/gcc/tree-ssa-loop-manip.c:338
0x1080260f rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int,
loop*)
../../src/gcc/tree-ssa-loop-manip.c:654
0x109002eb vectorize_loops()
../../src/gcc/tree-vectorizer.c:634
0x108167eb execute
../../src/gcc/tree-ssa-loop.c:420
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug fortran/69080] No automatic deallocation of allocatable function results

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC|kargl at gcc dot gnu.org   |

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Mueller from comment #9)
> (In reply to Mueller from comment #8)
> > I think, in theory, the compiler could detect something like
> > 
> > call some_subroutine(function_returning_allocatable())
> > 
> > to be a potential case for automatic deallocation of the returned
> > allocatable. But, as was pointed out above (if I understood correctly),
> > automatic deallocation of allocatable function results is not part of the
> > standard.
> 
> Now that I'm thinking about the example above: Isn't the allocatable
> function result here a local (temporary) variable and should thus be
> deallocated automatically?

No, it is not a local temporary variable.  If the function
result is deallocated prior to returning from the function,
what exactly is going to be returned?  Whatever had been stored
in the memory associated with the allocated function result
variable would be gone.  That is, you can't reference 
unallocated memory.

Please bugzilla is not a forum for learning Fortran.

[Bug c/23087] Misleading warning, "... differ in signedness"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #14 from Marek Polacek  ---
I think I might have a fix, but there's this thing about e.g.

void
foo (void)
{
  char *p = "";
  signed char *ps = "";
  unsigned char *pu = "";
}

with this issue fixed, we'd warn like this
$ xgcc z.c -c
z.c: In function ‘foo’:
z.c:5:21: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
   signed char *ps = "";
 ^~

z.c:6:23: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
   unsigned char *pu = "";
   ^~
whereas older gcc would be silent on that.  I.e., -Wincompatible-pointer-types
is a warning that is enabled by default, but -Wpointer-sign is enabled by
-Wpedantic || -Wall.  I.e., we'd be more verbose.  Maybe this is a non-issue as
most of the people are using -Wall anyway.

In any case I agree that the message about signedness is wrong.

[Bug fortran/69080] No automatic deallocation of allocatable function results

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Mueller from comment #7)
> (In reply to kargl from comment #5)
> > When the execution of a procedure is terminated by execution of a
> > RETURN or END statement, an allocatable variable that is a named
> > local variable of the procedure retains its allocation and definition
> > status if it has the SAVE attribute or is a function result variable
> > or a subobject thereof; otherwise, it is deallocated.
> 
> If you are stating it like that it sounds like these are the directives of
> the current Fortran standard. I've read a little bit of the standard before
> posting my question here, but could not really figure out the meaning in
> terms of allocatable function results. So if what you stated is standard
> Fortran, I'm thanking you for clearing this up.

It is a verbatim quote from the Fortran 2003 standard.

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

[doko at gcc dot gnu.org]

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

Bug ID: 69168
   Summary: [6 Regression] ICE in vect_analyze_loop_2, at
tree-vect-loop.c:2182
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, powerpc64le-linux-gnu, works with -O2

reduced test case:

long a, b, e;
short *c;
int *d;
void fn1() {
  int i;
  for (; e; e--) {
i = 2;
for (; i; i--)
  a = b = *d++ / (1 << 9);
b = b ? 8 : a;
*c++ = *c++ = b;
  }
}

$ gcc -c -g -O3 virtch2.i
virtch2.i: In function 'fn1':
virtch2.i:4:6: internal compiler error: in vect_analyze_loop_2, at
tree-vect-loop.c:2182
 void fn1() {
  ^~~

0x108ea7fb vect_analyze_loop_2
../../src/gcc/tree-vect-loop.c:2182
0x108ea7fb vect_analyze_loop(loop*)
../../src/gcc/tree-vect-loop.c:2251
0x1090002f vectorize_loops()
../../src/gcc/tree-vectorizer.c:532
0x108167eb execute
../../src/gcc/tree-ssa-loop.c:420
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/69169] New: [6 Regression] ICE (segfault) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 69169
   Summary: [6 Regression] ICE (segfault) on powerpc64le-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk r232077, powerpc64le-linux-gnu, works with -O1

reduced test case:

struct pgm_slist_t {
  struct pgm_slist_t *__restrict next;
} fn1(struct pgm_slist_t p1) {
}

$ gcc -c -g -O2 slist.i 
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.

infinite recursion?

#0  0x3fffb7936308 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
#1  0x3fffb7939708 in malloc () from /lib/powerpc64le-linux-gnu/libc.so.6
#2  0x10e3efb8 in xrealloc (oldmem=, size=136) at
../../src/libiberty/xmalloc.c:178
#3  0x1087419c in va_heap::reserve (exact=,
reserve=, 
v=) at ../../src/gcc/vec.h:288
#4  vec::reserve (exact=false, nelems=1,
this=)
at ../../src/gcc/vec.h:1406
#5  vec::safe_push (obj=..., this=)
at ../../src/gcc/vec.h:1515
#6  push_fields_onto_fieldstack (type=0x3fffb5c6e508,
fieldstack=0x3c000320, offset=0)
at ../../src/gcc/tree-ssa-structalias.c:5499
#7  0x1087f9e0 in create_variable_info_for_1 (decl=0x20852020,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5810
#8  0x1087fe0c in create_variable_info_for_1 (decl=0x20851f00,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#9  0x1087fe0c in create_variable_info_for_1 (decl=0x20851de0,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#10 0x1087fe0c in create_variable_info_for_1 (decl=0x20851cc0,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#11 0x1087fe0c in create_variable_info_for_1 (decl=0x20851ba0,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#12 0x1087fe0c in create_variable_info_for_1 (decl=0x20851a80,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#13 0x1087fe0c in create_variable_info_for_1 (decl=0x20851960,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#14 0x1087fe0c in create_variable_info_for_1 (decl=0x20851840,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#15 0x1087fe0c in create_variable_info_for_1 (decl=0x20851720,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#16 0x1087fe0c in create_variable_info_for_1 (decl=0x20851600,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#17 0x1087fe0c in create_variable_info_for_1 (decl=0x208514e0,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#18 0x1087fe0c in create_variable_info_for_1 (decl=0x208513c0,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#19 0x1087fe0c in create_variable_info_for_1 (decl=0x208512a0,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#20 0x1087fe0c in create_variable_info_for_1 (decl=0x20851180,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911
#21 0x1087fe0c in create_variable_info_for_1 (decl=0x20851060,
name=0x10f93cf8 "PARM_NOALIAS", 
add_id=true, handle_param=true) at
../../src/gcc/tree-ssa-structalias.c:5911

[Bug libstdc++/63218] More compact std::bitset for small n

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Marc Glisse from comment #3)
> (In reply to H.J. Lu from comment #2)
> > X32 also wants long long.
> 
> Is there a good way to ask for the longest of the integer types that are
> fast? stdint.h has things like int_fastN_t (btw, I don't like some of the
> choices I see for them in glibc (probably imposed by the ABI though)), but
> this is a different question. That may not be so well-defined though.

typedef int word_type __attribute__ ((mode (__word__)));

is the closest thing I can think of.

[Bug other/67627] libatomic parallel build failure

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Wed Jan  6 17:32:41 2016
New Revision: 232105

URL: https://gcc.gnu.org/viewcvs?rev=232105=gcc=rev
Log:
2016-01-06  Szabolcs Nagy  

Backport from mainline:
2016-01-06  Szabolcs Nagy  

PR other/67627
* Makefile.am (all-multi): Add dependency.
* Makefile.in: Regenerate.


Modified:
branches/gcc-5-branch/libatomic/ChangeLog
branches/gcc-5-branch/libatomic/Makefile.am
branches/gcc-5-branch/libatomic/Makefile.in

[Bug tree-optimization/51049] A regression caused by "Improve handling of conditional-branches on targets with high branch costs"

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this has been fixed or at least for most cases.  That is the & part is
redone during the combineif pass.

[Bug c++/69178] [concepts] An invalid expression in a requires-expression is evaluated too eagerly

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
This check happens in check_bases(), which doesn't take complain flags, so
wherever that check fails, it's always a hard error. I suppose the checking
function call chains that go to that function should accept complain flags
and then decide whether to produce a hard error or not?

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

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Note -g is not needed to reproduce the bug and speeds up the compiling a lot.

[Bug target/45927] autoconf regression wrt .quad availability targeting amd64 from biarch cross compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Does this still happen in GCC 5?

[Bug middle-end/68983] [6 Regression] ICE: in store_field, at expr.c:6659

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Created attachment 37245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37245=edit
possible patch

Would this be an appropriate fix?  It seems that if the source is a ref we
won't copy anything onto the stack.

[Bug c++/69178] New: [concepts] An invalid expression in a requires-expression is evaluated too eagerly

[ville.voutilainen at gmail dot com]

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

Bug ID: 69178
   Summary: [concepts] An invalid expression in a
requires-expression is evaluated too eagerly
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Test snippet:

template  struct S : T {};
template  concept bool ConcreteDerivableFrom()
{
return requires()
{
S();
};
}

struct X final {};

template 
void f() {}

template 
void f() {}

int main()
{
f();
}

Fails with

prog.cc: In instantiation of 'struct S':
prog.cc:20:10:   required from here
prog.cc:1:27: error: cannot derive from 'final' base 'X' in derived type 'S'
 template  struct S : T {};
   ^

[Bug tree-optimization/60890] Performance regression in 4.8 for memory postinc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #4 from Andrew Pinski  ---
Can you try GCC 5.x and/or the trunk?  There has been many IVOPTs improvements
since 4.8.x.

[Bug libstdc++/69092] [4.9/5/6 Regression] basic_string constructor and throwing iterators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.8.3
Summary|basic_string constructor|[4.9/5/6 Regression]
   |and throwing iterators  |basic_string constructor
   ||and throwing iterators
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #3 from Jonathan Wakely  ---
This worked OK in 4.8, and still works OK in C++03 mode (if tweaked to remove
the C++11 features):

#include
#include

struct hate_T_iterator : std::iterator {
explicit hate_T_iterator(char* p) : p(p) {}
char* p;
hate_T_iterator& operator++() { ++p; return *this; }
hate_T_iterator operator++(int) { hate_T_iterator r = *this; ++*this;
return r; }
char& operator*() const { if(*p == 'T') throw 1; else return *p; }
char* operator->() const { return p; }
bool operator== (hate_T_iterator other) const { return p == other.p;}
bool operator!= (hate_T_iterator other) const { return p != other.p;}
};

int main(){
char test_str[4] = "ATA";
try {
std::string s(hate_T_iterator(test_str), hate_T_iterator(test_str+3));
}
catch(...) {
}
}

[Bug testsuite/68629] FAIL: c-c++-common/attr-simd-3.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #8 from Thomas Preud'homme  ---
It does fix it for arm-none-eabi targets, the test is now unsupported. I should
have done it myself. Jakub was talking about moving it in the cilk-plus
directory. Do you think it's still necessary?

[Bug middle-end/68983] [6 Regression] ICE: in store_field, at expr.c:6659

[lucdanton at free dot fr]

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

--- Comment #8 from lucdanton at free dot fr ---
(In reply to Jason Merrill from comment #7)
> (In reply to lucdanton from comment #6)
> > I've independently run into this bug and applying this patch to HEAD doesn't
> > help on my end, the same ICE happens (except it is now pointing to line 
> > 6660 of
> > course).
> 
> Good to know.  Please attach a testcase?

Compiled with: g++-trunk -std=c++11 main.cpp

class A {
public:
  A m_fn1();
  A(A const &);
  int *L;
  int ref;
};
struct B : A {
  using base_type = A;
  B();
};
B::B() : base_type((0, m_fn1())) {}

[Bug target/62273] doc: Invoke.texi -mkernel mentions undocumented option

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
I also see that the related driver options -findirect-virtual-calls and
-fterminated-vtables (which appear in DARWIN_CC1_SPEC) are not documented
either.  And, I just filed PR 69179 for missing documentation of the
"apple_kext_compatibility" attribute which is also tied to -fapple-kext.

[Bug c++/66735] [C++14] lambda init-capture fails for const references

[lichray at gmail dot com]

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

Zhihao Yuan  changed:

   What|Removed |Added

 CC||lichray at gmail dot com

--- Comment #3 from Zhihao Yuan  ---
As the standardization of `std::as_const`, this bug becomes a blocker.

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #31 from Eric Gallager  ---
(In reply to Jack Howarth from comment #30)
> 
> It certainly would be worthwhile getting some level of support for SIP in
> gcc 6 as we really don't want to encourage users to disable that feature.

Why wouldn't we want to encourage users to disable it? Does it actually do
anything useful? Judging by this thread, it seems more like an unnecessary
hassle to me, and further justification for my decision to stay on an old
version of OS X that isn't encumbered by such hassles...

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #14 from Alexandre Oliva  ---
Mine.

H.J., thanks for the reduced testcase.  I'm afraid the patch is not right,
though.  All the test you removed does is to allow an optimization in the
comparison between two dataflow sets, namely, to refrain from comparing each
element of the second set with corresponding element in the first, after
comparing each element of the first set with the corresponding element in the
second.  There's a comment at the end of dataflow_set_different_p to that
effect, and removing the optimization will result in incorrect dataflow
analysis, because GCC won't notice when entries have been added to the new
dataflow set.

I'm looking into it to figure out why it's oscillating.

[Bug c++/63192] non-mutable lambda capture by value on reference does not apply const

[lichray at gmail dot com]

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

Zhihao Yuan  changed:

   What|Removed |Added

 CC||lichray at gmail dot com

--- Comment #3 from Zhihao Yuan  ---
Confirmed, please fix.  As the standardization of `std::as_const`, this bug
becomes significant.

[Bug target/69179] New: undocumented darwin attributes "apple_kext_compatibility" and "weak_import"

[sandra at gcc dot gnu.org]

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

Bug ID: 69179
   Summary: undocumented darwin attributes
"apple_kext_compatibility" and "weak_import"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

config/darwin.c defines attributes "apple_kext_compatibility" and "weak_import"
which have no documentation in the GCC manual.

"apple_kext_compatibility" seems related to the also-undocumented -fapple-kext
command-line option (see PR 62273).  Reading the code, I'm wondering if a
feature intended to provide backwards compatibility with GCC 2.95 is even
relevant to modern versions of Darwin, or whether this might be a candidate for
deletion as obsolete.

"weak_import" seems related to the normal "weak" attribute, but just from
reading the code I cannot figure out how to explain the difference in a concise
but user-friendly way.

Can a Darwin expert help fill in the missing docs?

[Bug bootstrap/38866] [Regression] --enable-gstreamer-peer + multilib + 32 bit boot = broken build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
--enable-gstreamer-peer

says it works for all multi-libs.  It is not GCC/libjava's responsibility to
make sure that is true.

i386-pc-solaris2.11 defaults to be being a multi-lib (multi-arch) by default so
you need to disable multi-lib if you only want 32bit support.

[Bug other/68813] [openacc] lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c

[cesar at gcc dot gnu.org]

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

--- Comment #5 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Thu Jan  7 03:28:05 2016
New Revision: 232121

URL: https://gcc.gnu.org/viewcvs?rev=232121=gcc=rev
Log:
PR other/68813

gcc/
* omp-low.c (is_oacc_reduction_private): Delete.
(build_outer_var_ref): Remove special handling for private reductions
in openacc.
(scan_sharing_clauses): Likewise.
(lower_rec_input_clauses): Likewise.
(lower_oacc_reductions): Update support for private reductions.

libgomp/
* testsuite/libgomp.oacc-fortran/pr68813.f90: New test.
* testsuite/libgomp.oacc-fortran/reduction-7.f90: New test.


Added:
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/pr68813.f90
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug middle-end/68983] [6 Regression] ICE: in store_field, at expr.c:6659

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to lucdanton from comment #6)
> I've independently run into this bug and applying this patch to HEAD doesn't
> help on my end, the same ICE happens (except it is now pointing to line 6660 
> of
> course).

Good to know.  Please attach a testcase?

[Bug c++/63192] non-mutable lambda capture by value on reference does not apply const

[lichray at gmail dot com]

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

--- Comment #4 from Zhihao Yuan  ---
(In reply to Zhihao Yuan from comment #3)
> Confirmed, please fix.  As the standardization of `std::as_const`, this bug
> becomes significant.

Never mind, I will create another bug report to demonstrate my issue (very
likely to have the same cause but with different result).