[Bug middle-end/70307] [6 Regression] ICE: in gimplify_expr, at gimplify.c:10915 on valid code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug other/70183] fdump-rtl-all-flags doesn't have impact on vzeroupper pass

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
(In reply to vries from comment #4)
> Approved for stage1:
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00902.html, conditional on
> successful bootstrap & regtest.

bootstrap & regtest succeeded.

[Bug c/70302] New: crash on valid code at -O2 and -O3 in 32-bit mode on x86_64-linux-gnu (in convert_op, at config/i386/i386.c:3414)

[chengniansun at gmail dot com]

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

Bug ID: 70302
   Summary: crash on valid code at -O2 and -O3 in 32-bit mode on
x86_64-linux-gnu (in convert_op, at
config/i386/i386.c:3414)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes the trunk at -O2 and -O3 in 32-bit mode (not 64-bit)
on x86_64-linux-gnu.



$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160318 (experimental) [trunk revision 234330] (GCC) 
$: 
$: gcc-trunk -c -w -m32 -O2 small.c
small.c: In function ‘fn1’:
small.c:14:1: internal compiler error: in convert_op, at
config/i386/i386.c:3414
 }
 ^
0xe815c0 scalar_chain::convert_op(rtx_def**, rtx_insn*)
../../gcc-source-trunk/gcc/config/i386/i386.c:3414
0xe817ae scalar_chain::convert_insn(rtx_insn*)
../../gcc-source-trunk/gcc/config/i386/i386.c:3445
0xea3c92 scalar_chain::convert()
../../gcc-source-trunk/gcc/config/i386/i386.c:3521
0xea44d5 convert_scalars_to_vector
../../gcc-source-trunk/gcc/config/i386/i386.c:3582
0xea44d5 execute
../../gcc-source-trunk/gcc/config/i386/i386.c:3674
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$: 
$: gcc-trunk -c -w -m32 -O1 small.c
$: 
$: cat small.c
long a, c, e;
int b, d;
unsigned long long f;
void fn1(long long p1) {
  unsigned long long g;
  int i;
  for (; i;)
if (e)
  g = c;
  if (a)
f = p1;
  if (!f && !g)
printf("", b, d, d);
}
$:

[Bug middle-end/70282] cc1plus hangs taking 100% CPU

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog
  Component|c++ |middle-end
   Severity|major   |normal

[Bug lto/70258] [6 Regression] flag_pic is cleared for PIE in lto_post_options

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Mar 17 11:07:10 2016
New Revision: 234284

URL: https://gcc.gnu.org/viewcvs?rev=234284&root=gcc&view=rev
Log:
Set flag_pic to flag_pie for PIE in LTO

Since PIE implies PIC, we should set flag_pic to flag_pie for PIE in
LTO.

PR lto/70258
* lto-lang.c (lto_post_options): Set flag_pic to flag_pie for
PIE.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c

[Bug c++/70259] [6 Regression] -flifetime-dse=2 bug with empty bases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-16
 CC||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Or on the definition, but not after it.

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
The point of my patch in comment 6 was to allow the customization to be done in
os_defines.h, not to litter the  header. If you're going to add #ifdef
checks for PTW32_VERSION in  then there's no point using my patch in
comment 6.

[Bug tree-optimization/70256] Add debug_varinfo and debug_varmap

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Approved for stage1: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00912.html

[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Waiting.

[Bug c++/61198] Crash when selecting specializations through aliases.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||5.1.0
   Target Milestone|--- |4.9.4

--- Comment #11 from Jonathan Wakely  ---
Also backported to gcc-4_9-branch, as approved by Jason at
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00810.html

[Bug c/70281] valgrind error in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-17
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks.  Confirmed on my box; am investigating.

[Bug fortran/70244] ICE spec_dimen_size() Bad dimension

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-16
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
Confirmed with GCC 6.


The ICE is triggered for:

0x61723e spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1])
2118  if (dimen < 0 || dimen > as->rank - 1)

as dimen == 1 and as->rank == 1. That's called via "gfc_array_dimen_size",
which first has:

case EXPR_FUNCTION:
  for (ref = array->ref; ref; ref = ref->next)

but that never gets executed as one has one REF_ARRAY of type AR_ELEMENT and
then 4 REF_COMPONENT. Thus, the following code is used:
  else if (!spec_dimen_size (array->symtree->n.sym->as, dimen, result))
which resolves to "e" which is a rank-1 array.

That fails as the proper "as" is the one at
   array->ref->next->next->next->u.c.component->as



Replacing the check in "gfc_array_dimen_size" by the following should works:

  gfc_array_spec *as = gfc_get_full_arrayspec_from_expr (array);
  if (!spec_dimen_size (as, dimen, result))
return false;

One just has to check which parts in gfc_array_dimen_size can be replaced by
this and whether all special cases are taken care of in
gfc_get_full_arrayspec_from_expr.

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Btw, the bswap pass for arm doesn't detect any bswap32 or bswap64 instruction.

There is

(define_expand "bswapsi2"
  [(set (match_operand:SI 0 "s_register_operand" "=r")
(bswap:SI (match_operand:SI 1 "s_register_operand" "r")))]
"TARGET_EITHER && (arm_arch6 || !optimize_size)"

but no bswapdi2.

[Bug c++/70205] [4.9/5 Regression] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE on |[4.9/5 Regression] ICE on
   |valid code on   |valid code on
   |x86_64-linux-gnu: tree  |x86_64-linux-gnu: tree
   |check: expected tree_binfo, |check: expected tree_binfo,
   |have error_mark in  |have error_mark in
   |add_candidates, at  |add_candidates, at
   |cp/call.c:5283  |cp/call.c:5283

--- Comment #11 from Patrick Palka  ---
Fixed on GCC 6 so far.

[Bug c++/70265] New: ICE on code with constexpr on x86_64-linux-gnu in tree check: expected statement_list, have nop_expr in tsi_start, at tree-iterator.h:42

[su at cs dot ucdavis.edu]

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

Bug ID: 70265
   Summary: ICE on code with constexpr on x86_64-linux-gnu in tree
check: expected statement_list, have nop_expr in
tsi_start, at tree-iterator.h:42
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It also seems to affect all 5.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160317 (experimental) [trunk revision 234278] (GCC) 
$ 
$ g++-trunk -c small.cpp
small2.cpp:10:20:   in constexpr expansion of ‘foo(1)’
small2.cpp:10:33: internal compiler error: tree check: expected statement_list,
have nop_expr in tsi_start, at tree-iterator.h:42
 static_assert (foo (1) == 0, "");
 ^
0xfe2bdc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9643
0x5d17ff tree_check
../../gcc-source-trunk/gcc/tree.h:3006
0x5d17ff tsi_start
../../gcc-source-trunk/gcc/tree-iterator.h:42
0x85382f tsi_start
../../gcc-source-trunk/gcc/cp/constexpr.c:3105
0x85382f cxx_eval_statement_list
../../gcc-source-trunk/gcc/cp/constexpr.c:3136
0x84d024 cxx_eval_loop_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:3184
0x84d024 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3842
0x8536b5 cxx_eval_statement_list
../../gcc-source-trunk/gcc/cp/constexpr.c:3152
0x84cf3a cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3776
0x84d18a cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3782
0x84c536 cxx_eval_call_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1393
0x84d46b cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3374
0x850fdd cxx_eval_binary_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1617
0x84d395 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3624
0x853999 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:3939
0x85669c maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4127
0x85669c maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4148
0x7c2465 finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../gcc-source-trunk/gcc/cp/semantics.c:8681
0x741520 cp_parser_static_assert
../../gcc-source-trunk/gcc/cp/parser.c:13050
0x753339 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12244
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





constexpr int
foo (int p)
{
  int t = 0; 
  while (1) 
;
  return t;
}

static_assert (foo (1) == 0, "");

[Bug middle-end/70199] [5/6 Regression] Crash at -O2 when using labels.

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 16:50:18 2016
New Revision: 234261

URL: https://gcc.gnu.org/viewcvs?rev=234261&root=gcc&view=rev
Log:
PR middle-end/70199

 * function.h (struct function): Add has_forced_label_in_static.
 * gimplify.c (force_labels_r): Set it.
 * lto-streamer-in.c (input_struct_function_base): Read it.
 * lto-streamer-out.c (output_struct_function_base): Write it.
 * tree-inline.c (has_label_address_in_static_1): Remove.
 (copy_forbidden): Remove fndecl parameter; test
 has_forced_label_in_static.
 (inline_forbidden_p): Update call to copy_forbidden.
 (tree_versionable_function_p): Likewise.
 * ipa-chkp.c (chkp_instrumentable_p): Likewise.
 (chkp_versioning): Likewise.
 * tree-inline.h (copy_forbidden): Update decl.

testsuite/
 * gcc.c-torture/compile/pr70199.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr70199.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.h
trunk/gcc/gimplify.c
trunk/gcc/ipa-chkp.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

  Attachment #38003|0   |1
is obsolete||

--- Comment #10 from Richard Henderson  ---
Created attachment 38034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38034&action=edit
second patch

The first patch fails full testing.  We fail to remap
the label for some reason without leaving it on the 
local decl list.

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Thomas Preud'homme from comment #9)
> (In reply to Richard Biener from comment #7)
> > The bswap pass could learn to split this up into two loads and bswaps and
> > combine the results with a single shift and or.
> 
> I'll add it to the bswap TODO list. Thanks.

Actually handles it via builtin_bswap64 already and generic code in optabs.c

But somehow bswap64 is still not detected for me on arm (works on x86-64 with
-m32).

[Bug c/70257] New: #line incorrectly handled in error messages

[rowe-gcc at excc dot ex.ac.uk]

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

Bug ID: 70257
   Summary: #line incorrectly handled in error messages
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rowe-gcc at excc dot ex.ac.uk
  Target Milestone: ---

When the following code is compiled with gcc -Wall :

// This line intentionally left blank
#line 1
#include 
int main() {
int k;

  return 0;
}

it produces the following:

text.c: In function ‘main’:
text.c:3:9: warning: unused variable ‘k’ [-Wunused-variable]
 #include 
 ^

Clearly although the #line directive is being recognised by the traditional
error code, the wrong line is then highlighted.
The version is: gcc (GCC) 5.3.0

Thanks for all your work on GCC.

John

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
--- gcc-5.3.0.old/libstdc++-v3/include/std/thread   2015-03-26
20:59:08.0 +0100
+++ gcc-5.3.0.old/libstdc++-v3/include/std/thread   2016-03-17
06:32:41.124378000 +0100
@@ -83,10 +83,19 @@ 
   operator==(thread::id __x, thread::id __y) noexcept
   { return __gthread_equal(__x._M_thread, __y._M_thread); }

+  // implement operator< explicitly in terms of the internals of
+  // pthreads-win32's ptw32_handle_t so that std::thread can use pthreads
+#ifdef PTW32_VERSION
+  friend bool
+  operator<(thread::id __x, thread::id __y)
+  { return ( (__x._M_thread.p < __y._M_thread.p) || 
+ ((__x._M_thread.p == __y._M_thread.p) && (__x._M_thread.x <
__y._M_thread.x) ) ); }

I suggest:

 return std::tie(__x._M_thread.p, __x._M_thread.x)
  < std::tie(__y._M_thread.p, __y._M_thread.x);

+#else
   friend bool
   operator<(thread::id __x, thread::id __y) noexcept
-  { return __x._M_thread < __y._M_thread; }
-
+  {return __less::_S_less(__x._M_thread,
__y._M_thread); }
+#endif
+  

What's this?

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
(In reply to Arnd Bergmann from comment #4)
> I've tried out a few more things as well, to see if the alignment of the
> struct lpfc_name type or the builtin memcpy makes a different. Replacing the
> array of eight bytes with a single uint64_t and scalar operations instead of
> string functions makes very little difference, so it seems to be neither of
> them.
> 
> However, I think the wwn_to_uint64_t() function is what causes the problem.
> This is supposed to be turned into a direct load or a byte reversing load
> depending on endianess, but this apparently does not happen.

I'm not aware of such transform - we have the 'bswap' pass on GIMPLE
but that only looks for the direct load case (-mbig-endian):

64 bit load in target endianness found at: _95 = MEM[(uint8_t
*)vport_wwpn_14(D)];
64 bit load in target endianness found at: _125 = MEM[(uint8_t
*)target_wwpn_16(D)];
64 bit load in target endianness found at: _167 = MEM[(uint8_t
*)vport_wwpn_14(D)];
64 bit load in target endianness found at: _197 = MEM[(uint8_t
*)target_wwpn_16(D)];
64 bit load in target endianness found at: _236 = MEM[(uint8_t
*)vport_wwpn_14(D)];
64 bit load in target endianness found at: _266 = MEM[(uint8_t
*)target_wwpn_16(D)];

as there is no "standard" target independent way to express a byte
reversed load (optab or so).  The closest we'd have is to "vectorize"
this as

  tem = load v8qi;
  tem = vec_perm ;
  ... = VIEW_CONVERT ;

if both the vector mode exists and the constant permute is handled
by the target.  The target would then need to combine the load
and the permute into a reversing load (if the target indeed has such
instruction).

> Adding -mbig-endian to the compiler flags brings the stack usage down, so
> presumably the optimization step that identifies byteswap patters is what
> causes the stack growth.

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> We'd likely want to warn in merge_decls for this case.

"this case" == all optimization attributes applied via newdecl to
olddecl with DECL_SAVED_TREE (or DECL_INITIAL?) set.

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[ralphengels at gmail dot com]

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

--- Comment #13 from ralphengels at gmail dot com  ---
Also needs a small change in pthread.h to guard against including windows.h

#if defined(PTW32_CONFIG_MINGW) && defined(__cplusplus)

change to

#if defined(PTW32_CONFIG_MINGW) && defined(PTW32_BUILD) && defined(__cplusplus)

[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Created attachment 38033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38033&action=edit
A patch

Here is the patch which might solve the problem.

[Bug fortran/69739] [4.9/5/6 Regression] ICE during array result, allocatable assignment

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #3)
> (In reply to John from comment #2)
> > So maybe the automatic-size result is the actual root of the ICE?
> 
> If I use
> 
> real  :: operate(1:size(A))
> 
> instead of
> 
> real  :: operate(1:PRODUCT(UBOUND(A)))
> 
> I do not get an ICE.  So it's not automatic-size per se.

More testing: both

real  :: operate(1:UBOUND(A,1)*UBOUND(A,2)*UBOUND(A,3))

and

real  :: operate(1:PRODUCT(shape (A)))

appear ok.

[Bug tree-optimization/70267] ICE on valid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
We ICE in propagate_necessity because it can't digest
# VUSE <.MEM_3>
f.0_4 = (struct Foo *) D.2296;
which is 
(gdb) p gimple_code(stmt)
$2 = GIMPLE_ASSIGN
but
(gdb) p gimple_assign_single_p (stmt)
$3 = false
thus we end up in the gcc_unreachable (); branch there.

[Bug target/70292] New: ICE in verify_target_availability, at sel-sched.c:1584 with -fno-inline -fno-dce -fschedule-insns -fselective-scheduling -fno-tree-dce -O1

[tarasevich at cs dot uni-saarland.de]

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

Bug ID: 70292
   Summary: ICE in verify_target_availability, at sel-sched.c:1584
with -fno-inline -fno-dce -fschedule-insns
-fselective-scheduling -fno-tree-dce -O1
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tarasevich at cs dot uni-saarland.de
  Target Milestone: ---

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

This might be a duplicate of bug 64411

../build/gcc_530_clean_bin/bin/gcc test_case_52485.c -fno-inline -fno-dce
-fschedule-insns -fselective-scheduling -fno-tree-dce -O1 -save-temps -v
Using built-in specs.
COLLECT_GCC=../build/gcc_530_clean_bin/bin/gcc
COLLECT_LTO_WRAPPER=/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../source/gcc_530/configure
--prefix=/home/tarasevich/build/gcc_530_clean_bin/ --enable-languages=c
--disable-multilib --disable-bootstrap
CC=/home/tarasevich/build/llvm_371_bin/bin/clang
CXX=/home/tarasevich/build/llvm_371_bin/bin/clang++
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-fno-inline' '-fno-dce' '-fschedule-insns'
'-fselective-scheduling' '-fno-tree-dce' '-O1' '-save-temps' '-v'
'-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-E -quiet -v -imultiarch x86_64-linux-gnu test_case_52485.c -mtune=generic
-march=x86-64 -fno-inline -fno-dce -fschedule-insns -fselective-scheduling
-fno-tree-dce -O1 -fpch-preprocess -o test_case_52485.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
 /usr/local/include
 /home/tarasevich/build/gcc_530_clean_bin/include

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-fno-inline' '-fno-dce' '-fschedule-insns'
'-fselective-scheduling' '-fno-tree-dce' '-O1' '-save-temps' '-v'
'-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-fpreprocessed test_case_52485.i -quiet -dumpbase test_case_52485.c
-mtune=generic -march=x86-64 -auxbase test_case_52485 -O1 -version -fno-inline
-fno-dce -fschedule-insns -fselective-scheduling -fno-tree-dce -o
test_case_52485.s
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c53bb545b4c066cdbf5e42f0b9d9ad8b
test_case_52485.c: In function 't106_1mul':
test_case_52485.c:9:1: internal compiler error: in verify_target_availability,
at sel-sched.c:1584
 }
 ^
0x906ac3 verify_target_availability(_expr*, bitmap_head*, reg_rename*)
../../../source/gcc_530/gcc/sel-sched.c:1581
0x906ac3 find_best_reg_for_expr(_expr*, _list_node*, bool*)
../../../source/gcc_530/gcc/sel-sched.c:1696
0x906ac3 fill_vec_av_set(_list_node*, _list_node*, _fence*, int*)
../../../source/gcc_530/gcc/sel-sched.c:3810
0x906ac3 fill_ready_list(_list_node**, _list_node*, _fence*, int*)
../../../source/gcc_530/gcc/sel-sched.c:4040
0x906ac3 find_best_expr(_list_node**, _list_node*, _fence*, int*)
../../../source/gcc_530/gcc/sel-sched.c:4403
0x906ac3 fill_insns(_fence*, int, _list_node***)
../../../source/gcc_530/gcc/sel-sched.c:5570
0x901fae schedule_on_fences(_list_node*, int, _list_node***)
../../../source/gcc_530/gcc/sel-sched.c:7395
0x901fae sel_sched_region_2(int)
../../../source/gcc_530/gcc/sel-sched.c:7533
0x8fe717 sel_sched_region_1()
../../../source/gcc_530/gcc/sel-sched.c:7575
0x8fe717 sel_sched_region(int)
../../../source/gcc_530/gcc/sel-sched.c:7676
0x8ff976 run_selective_scheduling()
../../../source/gcc_530/gcc/sel-sched.c:7752
0x8ed24e rest_of_handle_sched()
../../../source/gcc_530/gcc/sched-rgn.c:3633
0x8ed24e (anonymous namesp

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #2)
> Created attachment 37982 [details]
> Patch to generate error message

This patch leads to serious regressions.  Do not
yet understand why.  Withdrawing...

[Bug c++/70285] [6 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
In particular, we hit the
  /* [expr.cond]

 If the second and third operands are glvalues of the same value
 category and have the same type, the result is of that type and
 value category.  */
  if (((real_lvalue_p (arg2) && real_lvalue_p (arg3))
   || (xvalue_p (arg2) && xvalue_p (arg3)))
  && same_type_p (arg2_type, arg3_type))
{
  result_type = arg2_type;
  arg2 = mark_lvalue_use (arg2);
  arg3 = mark_lvalue_use (arg3);
  goto valid_operands;
}
case, and therefore bypass any promotion.
As I said, arg2 has type signed char, arg2_type is int, arg3 has type int and
arg3_type is int.
So, the question is what C++ says here we should do with the bitfields.
Shall it call same_type_p (TREE_TYPE (arg2), TREE_TYPE (arg3)) instead?  Saying
that int :8 bitfield has the same type as int is just weird.
But, what would happen if both arms are say the int :8 bitfields?  The result
type will be still int, different from the arm types.
Let's CC Jason on this.

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-18
 Ever confirmed|0   |1

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

[Bug c++/70265] ICE on code with constexpr on x86_64-linux-gnu in tree check: expected statement_list, have nop_expr in tsi_start, at tree-iterator.h:42

[su at cs dot ucdavis.edu]

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

--- Comment #1 from Zhendong Su  ---
A slight variation of the test causes GCC to hang (apparently in evaluating the
infinite loop). 


$ timeout -s 9 10 g++-trunk -c small.cpp
Killed
$ 
$ clang++-trunk -std=c++14 -c small.cpp
small.cpp:2:1: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
foo (int p)
^
small.cpp:6:5: note: constexpr evaluation hit maximum step limit; possible
infinite loop?
t = 0; 
^
small.cpp:10:16: error: static_assert expression is not an integral constant
expression
static_assert (foo (1) == 0, "");
   ^~~~
small.cpp:6:5: note: constexpr evaluation hit maximum step limit; possible
infinite loop?
t = 0; 
^
small.cpp:10:16: note: in call to 'foo(1)'
static_assert (foo (1) == 0, "");
   ^
2 errors generated.
$ 





constexpr int
foo (int p)
{
  int t = 0; 
  while (1) 
t = 0; // was ';' 
  return t;
}

static_assert (foo (1) == 0, "");

[Bug c/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
Bug 70150 depends on bug 70192, which changed state.

Bug 70192 Summary: -fno-pic doesn't work with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70192

   What|Removed |Added

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

[Bug fortran/70260] ICE: gimplification failed

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
(In reply to Gerhard Steinmetz from comment #1)
> Another situation :
> 
> 
> $ cat z3.f90
> subroutine s (f)
>integer, external :: f, g
>integer :: h
>g = f(2)
>h = g(2)
> end

Commenting out the assignment to h, I get:

% gfc-trunk pr70260-z3.f90
pr70260-z3.f90:4:3:

g = f(2)
   1
Error: 'g' in variable definition context (assignment) at (1) is not a variable

[Bug c++/70205] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
Thanks a lot Marek. The patch makes sense to me, I would recommend fully
regression testing it and sending it to the mailing list.

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
We'd likely want to warn in merge_decls for this case.

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jason at gcc dot gnu.org]

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

--- Comment #27 from Jason Merrill  ---
(In reply to Bernd Edlinger from comment #26)
> I just fail to understand why we cannot just clobber the whole
> object once in the in-charge constructor,
> then if sanitizing vptrs initialize every vptr once to zero.
> and skip all the clobber and vptr initializing on the
> not in-charge constructors.

That sounds fine, for classes with virtual bases.

[Bug libstdc++/70294] New: operator< and operator== for std::thread::id only findable by ADL

[redi at gcc dot gnu.org]

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

Bug ID: 70294
   Summary: operator< and operator== for std::thread::id only
findable by ADL
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
bool (*lt)(std::thread::id, std::thread::id) = &std::operator<;
bool (*eq)(std::thread::id, std::thread::id) = &std::operator==;

This fails because the friend functions in std::thread::id can't be found by
normal name lookup. There should be non-friend declarations at namespace scope.

I'll fix this post-gcc6.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #8 from James Greenhalgh  ---
(In reply to Christophe Lyon from comment #6)
> > 3) We should think about whether we need to put out these +no extension
> > strings at all. I don't like that for my older systems I'll need to keep
> > updating my binutils to cover any new extension strings (e.g. +nolse) that
> > are added by GCC if I want to use -march=native . We shouldn't force that if
> > we don't have to.
> > 
> 
> Do you know why these +no where introduced in the first place?
> 
> Why would there be a difference between "+nolse" and "" for instance?

We don't keep track (in aarch64-driver.c) of which flags are implicitly
included (e.g. +fp+simd) and would need an explicit +nofp to disable, and which
flags need explicitly enabled (e.g. +crc) and so don't need to be explicitly
disabled.

I'm working on a clean-up.

[Bug libstdc++/70238] [5/6 Regression] std::future_category ABI change

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
So RESOLVED|WONTFIX?

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Or better yet decide whether to walk the initializers or not based on
> > !gimple_body (fndecl) && !fun->cfg ?
> 
> or make the flag a tri-state and if we compute it before (during the 
> tree-inline.c walk) then set it from there to avoid redundant work.

Is cgraph_finalize_function () time early enough for C++ cloning?

[Bug libstdc++/70238] [5/6 Regression] std::future_category ABI change

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 16 13:34:36 2016
New Revision: 234258

URL: https://gcc.gnu.org/viewcvs?rev=234258&root=gcc&view=rev
Log:
PR tree-optimization/68714
* gcc.dg/tree-ssa/pr68714.c: Add -w -Wno-psabi to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[ralphengels at gmail dot com]

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

--- Comment #19 from ralphengels at gmail dot com  ---
Had problems with the define not being pulled in from os_defines.h (i think a
better place would have been gthr_posix.h since that gets pulled in at build
time) hence the change, also if using another posix thread implementation it
would break using that instead since your define would then be undefined
leading to a build error. Besides that better implementations are welcome :)
this was just an example of a possible fix.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Tobias Burnus from comment #7)
... snip ...
> 
> My gut feeling is that it has something to do with having "precision" == 17
> in that function. In any case, the nafter is too large when nblanks is
> calculated.

Yes, and I find one place where after a memmove to align digits, the
significant digit gets wiped to a zero, really odd. I am on the hunt

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #6)

All crashes for case 4 go away after the following change:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 234170)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -8275,7 +8275,7 @@
  gfc_add_expr_to_block (&block, tmp);
}
 }
-  else if (ts.type == BT_DERIVED || ts.type == BT_CLASS)
+  else if (ts.type == BT_DERIVED || ts.type == BT_CLASS || ts.type ==
BT_COMPLEX)
 {
   gfc_add_block_to_block (&block, &lse->pre);
   gfc_add_block_to_block (&block, &rse->pre);


Could somebody please check whether this makes sense?

[Bug c/70281] valgrind error in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Minimized reproducer:

$ cat bug.c
const char *bch_stats_show (unsigned long cache_hits)
{
  return (__builtin_types_compatible_p (typeof (cache_hits >> 16), int)
  ? "%i\n" : "%i\n");
}

Am working on a fix.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Christophe Lyon from comment #6)
> > 3) We should think about whether we need to put out these +no extension
> > strings at all. I don't like that for my older systems I'll need to keep
> > updating my binutils to cover any new extension strings (e.g. +nolse) that
> > are added by GCC if I want to use -march=native . We shouldn't force that if
> > we don't have to.
> > 
> 
> Do you know why these +no where introduced in the first place?
> 
> Why would there be a difference between "+nolse" and "" for instance?

X86, adds the -mno-* option too with respect of -march=native.

[Bug c++/70194] [6 regression] missing -Waddress on constexpr pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 17 10:29:36 2016
New Revision: 234281

URL: https://gcc.gnu.org/viewcvs?rev=234281&root=gcc&view=rev
Log:
PR c++/70194
* typeck.c (warn_for_null_address): New function.
(cp_build_binary_op): Call it.

* g++.dg/warn/constexpr-70194.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/constexpr-70194.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
Bug 70150 depends on bug 70258, which changed state.

Bug 70258 Summary: [6 Regression] flag_pic is cleared for PIE in 
lto_post_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70258

   What|Removed |Added

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

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 17 11:53:53 2016
New Revision: 234285

URL: https://gcc.gnu.org/viewcvs?rev=234285&root=gcc&view=rev
Log:
PR target/70245
* rtl.h (replace_rtx): Add ALL_REGS argument.
* rtlanal.c (replace_rtx): Likewise.  If true, use REGNO
equality and assert mode is the same, instead of just rtx pointer
equality.
* config/i386/i386.md (mov + arithmetics with load peephole): Pass
true as ALL_REGS argument to replace_rtx.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/rtl.h
trunk/gcc/rtlanal.c

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[wdijkstr at arm dot com]

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

--- Comment #20 from Wilco  ---
(In reply to Richard Henderson from comment #19)

> I wish that message had been a bit more complete with the description
> of the performance issue.  I must guess from this...
> 
> >   ldr dst1, [reg_base1, reg_index, #lsl 1]
> >   ldr dst2, [reg_base2, reg_index, #lsl 1]
> >   ldr dst3, [reg_base3, reg_index, #lsl 1]
> > 
> > into
> > 
> >   reg_index = reg_index << 1;
> >   ldr dst1, [reg_base1, reg_index]
> >   ldr dst2, [reg_base2, reg_index]
> >   ldr dst3, [reg_base3, reg_index]
> 
> that it must have something to do with the smaller cpus, e.g. exynosm1,
> based on the address cost tables.

Some CPUs emit seperate uops to do address shift by 1. So that would mean 6
uops in the first example vs 4 when doing the shift separately. According to
the cost tables this might actually be worse on exynosm1 as it has a cost for
any indexing.

> I'll note for the record that you cannot hope to solve this with
> the legitimize_address hook alone for the simple reason that it's not
> called for legitimate addresses, of which (base + index * 2) is
> a member.  The hook is only being called for illegitimate addresses.

Would it be possible to disallow expensive addresses initially, let CSE do its
thing and then merge addresses with 1 or 2 uses back into loads/stores?

> To include legitimate addresses, you'd have to force out the address
> components somewhere else.  Perhaps in the mov expanders, since that's
> one of the very few places mem's are allowed.  You'd want to do this
> only if !cse_not_expected.

And presumably only for addresses we would prefer to be CSEd, such as expensive
shifts or indexing.

> OTOH, it's also the sort of thing that one would hope that CSE itself
> would be able to handle.  Looking across various addresses, computing
> sums of costs, and breaking out subexpressions as necessary.

Yes that would be the ideal, but one can dream...

Did you post your patch btw? We should go ahead with that (with Jiong's minor
modification) as it looks significantly better overall.

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
See PR70261.

[Bug target/54746] config/s390/s390.c:1583: possible missing break in switch ?

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #5 from Andreas Krebbel  ---
Fixed.

[Bug c++/70121] Spurious warning and crash when returning a reference from lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|ppalka at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
Summary|[5/6 Regression] spurious   |Spurious warning and crash
   |warning and crash when  |when returning a reference
   |returning a reference from  |from lambda
   |lambda  |

--- Comment #5 from Patrick Palka  ---
Removing regression markers.

[Bug target/61821] gcc.target/i386/pr61599-1.c FAILs with Sun as

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]
 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-03/msg01059.ht
   ||ml
   Last reconfirmed||2016-03-18
   Host|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
 Ever confirmed|0   |1
  Build|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]

--- Comment #4 from Rainer Orth  ---
Mine, patch posted.

[Bug c++/70318] New: `std::sqrt(int)` Produces -Wfloat-conversion Warning, Erroneous After C++11.

[ian at geometrian dot com]

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

Bug ID: 70318
   Summary: `std::sqrt(int)` Produces -Wfloat-conversion
Warning, Erroneous After C++11.
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at geometrian dot com
  Target Milestone: ---

Created attachment 38032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38032&action=edit
Sample given in text, as a file.

As required by the C++ standard, after C++11, the `std::sqrt` function in
`` is required to have "A set of overloads or a function template
accepting an argument of any integral type."

Consider the following command-line tool for computing integer-square root:

//Compile like so: g++ isqrt.cpp -std=c++11 -Wfloat-conversion -o isqrt
#include 
#include 
int main(int argc, char* argv[]) {
if (argc!=2) {
std::cout << "Usage: \"./isqrt [integer]\"" << std::endl;
return -1;
} else {
int arg = atoi(argv[1]);
int isqrt = std::sqrt(arg);
std::cout << isqrt << std::endl;
return isqrt;
}
}

When compiling as the comment says, a warning is produced:

isqrt.cpp: In function ‘int main(int, char**)’:
isqrt.cpp:10:33: warning: conversion to ‘int’ from
‘__gnu_cxx::__enable_if::__type {aka double}’ may alter its value
[-Wfloat-conversion]
   int isqrt = std::sqrt(arg);
 ^

Internally, the argument is indeed converted to `double`, before doing the
square root with `double`s (at it should be).  However, since the overload is
required to exist separately and explicitly (and it evidently doesn't), I think
this warning is erroneous.

For your convenience, my sample is also attached as a file.

[Bug other/70268] New: add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[hongxu.jia at windriver dot com]

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

Bug ID: 70268
   Summary: add option -ffile-prefix-map to map one directory name
(old) to another (new) in __FILE__, __BASE_FILE__and
__builtin_FILE()
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hongxu.jia at windriver dot com
  Target Milestone: ---

Hi all,

I come from OpenEmbedded community (https://www.yoctoproject.org/),
and we use the powerful gcc for cross compilation. Previously, with
the help of Richard Biener and Jakub Jelinek, PR69821 was fixed which
do not expose the build path to others while '-g' used.

But there is another similar issue, while '__FILE__' used, this macro
expands to the name of the current input file which has build path.

I know the tradition solution is using relative path to compile.
(Such as instead of 'gcc /full/path/to/test.c',
try 'cd /full/path/to; gcc test.c; cd -;')

But if '__FILE__' exists in included header file and the header
file in standard system directories, the above way doesn't work.
Here is my test case:
---
1. Prepare a C source file and a C include file
$ cat << ENDOF > test.c
#include 
#include 

int main(int argc, char *argv[])
{
  printf("__FILE__ %s\n", __FILE__);
  test();
  return 0;
}

ENDOF

$ cat << ENDOF > test.h
#include 

void test(void)
{
  printf("__FILE__ %s\n", __FILE__);
  return;
}

ENDOF

2. Move include file to standard system directory.
$ sudo mv test.h /usr/include/

3. Compile C source file
$ gcc ./test.c -o test

4. Execute and the output shows full path header file.
$ ./test 
__FILE__ ./test.c
__FILE__ /usr/include/test.h
---

[Bug target/70008] [ARM] Reverse subtract with carry can be generated in thumb2 mode

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #3 from Ramana Radhakrishnan  ---
Invalid.

[Bug target/70162] [RX] const_int printing causes wrong code on 32 bit host

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #8 from Nick Clifton  ---
Patch applied.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #5 from James Greenhalgh  ---
The crux of this issue is going to be that your Cortex-A53 has no support for
the cryptography extension, but does have support for the CRC extensions.

By inspection of host_detect_local_cpu, I see that we run through all the
extensions that we know about, checking to see whether that extension is a
substring of the Features we read from /proc/cpuinfo . If it is we add
+extension, if not we add +noextension.

So, it seems reasonable to me that if we run this algorithm on a core without
crypto, but with CRC, we'll get the string described
(-march=armv8-a+fp+simd+nocrypto+crc+nolse) forwarded to the assembler on
command line.

And sure enough, the assembler wants to read everything you've got before you
start telling it what you've not got.

I see a few issues.

1) There's not really a good reason for an assembler to have this syntax
restriction. The code does the right thing whatever order you put your features
in.
2) We'll have to support these older assemblers anyway, so at the least we'll
have to hold off writing the "+no" extension strings until we're done with the
"+" extension strings.
3) We should think about whether we need to put out these +no extension strings
at all. I don't like that for my older systems I'll need to keep updating my
binutils to cover any new extension strings (e.g. +nolse) that are added by GCC
if I want to use -march=native . We shouldn't force that if we don't have to.

So, Confirmed.

[Bug rtl-optimization/70224] [5 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Jeffrey A. Law  ---
> So I realized that given the nature of this bug a simple bootstrap on sparc
> wasn't going to be particularly interesting -- bootstraps don't tickle this
> code (if they did, it'd fault in a manner similar to Rainer's test).  So my
> time trying to put together a usable sparc/sparc64 qemu testing environment 
> was
> largely wasted.
>
> I'm going to go forward with the obvious patch.
>
> Rainer, if you could do a bootstrap with -freorder-blocks-and-partition after 
> I
> commit the obvious fix, it'd be appreciated as an additional sanity check.

I just did, but it ICEed in stage2:

+===GNAT BUG DETECTED==+
| 6.0.0 20160317 (experimental) (sparc-sun-solaris2.12) GCC error: |
| in replace_rtx, at rtlanal.c:2969|
| Error detected around /vol/gcc/src/hg/trunk/dist/gcc/ada/types.adb:121:8 |

Rainer

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Created attachment 37990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37990&action=edit
A useful test program

I get correct results using the attached with gcc version 4.6.4 (GCC)

Broken in 4.9, 5, and 6.

[Bug target/70162] [RX] const_int printing causes wrong code on 32 bit host

[nickc at gcc dot gnu.org]

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

--- Comment #7 from Nick Clifton  ---
Author: nickc
Date: Thu Mar 17 10:16:38 2016
New Revision: 234280

URL: https://gcc.gnu.org/viewcvs?rev=234280&root=gcc&view=rev
Log:
PR target/70162
* config/rx/rx.c (rx_print_integer): Print negative constants in
decimal.

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

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[ralphengels at gmail dot com]

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

ralphengels at gmail dot com  changed:

   What|Removed |Added

 CC||ralphengels at gmail dot com

--- Comment #12 from ralphengels at gmail dot com  ---
Created attachment 38009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38009&action=edit
pthreads-w32 compatibility patch

Patch to allow building gcc-5.3.0 with pthreads-w32, no bugs so far but im
still running the testsuite so something might turn up, feel free to test.

[Bug tree-optimization/70252] ICE in vect_get_vec_def_for_stmt_copy with -O3 -march=skylake-avx512.

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

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

[Bug libstdc++/70303] New: Value-initialized debug iterators

[Casey at Carter dot net]

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

Bug ID: 70303
   Summary: Value-initialized debug iterators
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Since C++14 requires value-initialized Forward iterators to compare equal, and
subtraction/ordering of RandomAccess iterators is based on equality, this
program should run to completion:

#define _GLIBCXX_DEBUG

#include 
#include 

int main() {
  using I = std::vector::iterator;
  assert(I{} == I{});
  assert(!(I{} != I{}));
  assert(I{} - I{} == 0);
  assert(!(I{} < I{}));
  assert(!(I{} > I{}));
  assert(I{} <= I{});
  assert(I{} >= I{});
}

instead of reporting "Error: attempt to compare a singular iterator to a
singular iterator." for any of the listed iterator operations.

[Bug lto/70289] [openacc] ICE in input_varpool_node

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||tschwinge at gcc dot gnu.org

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

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Created attachment 37993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37993&action=edit
aarch64 pbase_type_info.ii

This will ICE with just cc1plus -O.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[rth at gcc dot gnu.org]

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

--- Comment #11 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 23:53:01 2016
New Revision: 234271

URL: https://gcc.gnu.org/viewcvs?rev=234271&root=gcc&view=rev
Log:
Gimplify vec_cond_expr with condition inside

  PR middle-end/70240
  PR middle-end/68215
  PR tree-opt/68714
  * gimplify.c (gimplify_expr) [VEC_COND_EXPR]: Gimplify the
  first operand as is_gimple_condexpr.

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

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[rth at gcc dot gnu.org]

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

--- Comment #11 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 23:53:18 2016
New Revision: 234273

URL: https://gcc.gnu.org/viewcvs?rev=234273&root=gcc&view=rev
Log:
PR middle-end/70240

  * gcc.c-torture/compile/pr70240.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr70240.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/70279] New: Crash duing compilation with NINT and 128 bits integer

[francois.willot at ensmp dot fr]

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

Bug ID: 70279
   Summary: Crash duing compilation with NINT and 128 bits integer
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francois.willot at ensmp dot fr
  Target Milestone: ---

Compiling the code below makes gfortran 4.8.4 crash:

gfortran -Wall -O3 -pedantic-errors -pedantic -Werror -std=f2003 -fopenmp -cpp
-DMULTITHREADS test.f90

test.f90: In function ‘MAIN__’:
test.f90:17:0: internal compiler error: in build_round_expr, at
fortran/trans-intrinsic.c:394
 PRINT *,NINT(a,i)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The code is:

PROGRAM MAIN
IMPLICIT NONE
INTEGER, PARAMETER :: i=SELECTED_INT_KIND(30)
DOUBLE PRECISION :: a
a=0.0D0
PRINT *,NINT(a,i)
END


Instead, this code runs as expected

PROGRAM MAIN
IMPLICIT NONE
INTEGER, PARAMETER :: i=SELECTED_INT_KIND(30)
PRINT *,NINT(0.0D0,i),i
END

(It produces:
 0 16  
)

[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[hongxu.jia at windriver dot com]

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

--- Comment #1 from hongxu jia  ---
So I suggest gcc could provide a option '-ffile-prefix-map=='
to map  directory in __FILE__ and replace it with  directory.

It is similar to '-fdebug-prefix-map==', but the latter is used
for DWARF, and the newly added option only works on '__FILE__', '__BASE_FILE__'
and '__builtin_FILE()'

---
5. Compile C source file with '-ffile-prefix-map'
$ gcc ./test.c -ffile-prefix-map=/usr/include= -o test

4. Execute and the header file is not pull path.
$ ./test 
__FILE__ ./test.c
__FILE__ /test.h
---

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 23:53:10 2016
New Revision: 234272

URL: https://gcc.gnu.org/viewcvs?rev=234272&root=gcc&view=rev
Log:
Revert r231575

  PR middle-end/70240
  PR middle-end/68215
  2015-12-11  Eric Botcazou  
  * tree-vect-generic.c (tree_vec_extract): Remove GSI parameter.
  Do not gimplify the result.
  (do_unop): Adjust call to tree_vec_extract.
  (do_binop): Likewise.
  (do_compare): Likewise.
  (do_plus_minus): Likewise.
  (do_negate): Likewise.
  (expand_vector_condition): Likewise.
  (do_cond): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug libffi/70024] [5/6 Regression] libffi ABI change w/o SONAME bump

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Wed Mar 16 16:58:12 2016
New Revision: 234262

URL: https://gcc.gnu.org/viewcvs?rev=234262&root=gcc&view=rev
Log:
PR rtl-optimization/70024
* reorg.c (relax_delay_slots): Pass right argument to CROSSING_JUMP_P.

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

[Bug tree-optimization/70317] New: [6 Regression] folding x<=x to true for large vectors, ignoring nans

[glisse at gcc dot gnu.org]

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

Bug ID: 70317
   Summary: [6 Regression] folding x<=x to true for large vectors,
ignoring nans
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

typedef double vecf __attribute__((vector_size(256)));
auto f(vecf x){
  return x <= x;
}

g++ x.c -O3 -S -fdump-tree-all

the .optimized dump has:
   = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };

This is because the corresponding match.pd pattern uses:
HONOR_NANS (TYPE_MODE (TREE_TYPE (@0)))
instead of
HONOR_NANS (@0)

(don't know if I missed it when I redefined HONOR_NANS or if it was added
later)

By the way, the pattern canonicalizes x==x, x<=x and x>=x to x==x, but
ORDERED_EXPR would be a nicer alternative IMHO (if we really prefer x==x, then
we should also canonicalize x ord x to x == x).

[Bug tree-optimization/70288] New: ICE with -O1 -fno-tree-dominator-opts

[tarasevich at cs dot uni-saarland.de]

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

Bug ID: 70288
   Summary: ICE with -O1 -fno-tree-dominator-opts
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tarasevich at cs dot uni-saarland.de
  Target Milestone: ---

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

GCC 5.3.0 built from with Clang 3.7.1 on Ubuntu 14.04 64bit. Same with GCC
4.8.2

../build/gcc_530_clean_bin/bin/gcc -fno-tree-dominator-opts test_case_1.c -O1
-save-temps -v
Using built-in specs.
COLLECT_GCC=../build/gcc_530_clean_bin/bin/gcc
COLLECT_LTO_WRAPPER=/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../source/gcc_530/configure
--prefix=/home/tarasevich/build/gcc_530_clean_bin/ --enable-languages=c
--disable-multilib --disable-bootstrap
CC=/home/tarasevich/build/llvm_371_bin/bin/clang
CXX=/home/tarasevich/build/llvm_371_bin/bin/clang++
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-fno-tree-dominator-opts' '-O1' '-save-temps' '-v'
'-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-E -quiet -v -imultiarch x86_64-linux-gnu test_case_1.c -mtune=generic
-march=x86-64 -fno-tree-dominator-opts -O1 -fpch-preprocess -o test_case_1.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
 /usr/local/include
 /home/tarasevich/build/gcc_530_clean_bin/include

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-fno-tree-dominator-opts' '-O1' '-save-temps' '-v'
'-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-fpreprocessed test_case_1.i -quiet -dumpbase test_case_1.c -mtune=generic
-march=x86-64 -auxbase test_case_1 -O1 -version -fno-tree-dominator-opts -o
test_case_1.s
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c53bb545b4c066cdbf5e42f0b9d9ad8b
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Or do you consider this just harmless?  If some ctor throws, even if dtor is
virtual, the dtor will change _vptr to what it expects before the rest of the
dtor body which could call virtual functions etc., and if you reach the body or
mem initializers of the ctor (B:B above), then the old vptr store is already
overwritten by another vptr store (or the vptr is living somewhere outside of
the current object, but then the clobber is not a problem).
If so, we'd need to at least disable the clobbers for -fsanitize=vptr, because
when calling the dtor ubsan also checks if the vptr is valid, and if it is NULL
or garbage, it is not considered valid.

[Bug c++/70121] [5/6/7 Regression] Spurious warning and crash when returning a reference from lambda

[ppalka at gcc dot gnu.org]

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

--- Comment #7 from Patrick Palka  ---
But as Jason said in comment #4, (IIUC) the test case never compiled correctly
in any gcc version.  It was marked a regression only because
-Wreturn-local-addr now deliberately returns null but arguably that's not a
regression either.

[Bug lto/70283] [6 regression] bogus vtable mismatch warnings

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-19
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
Testing patch...

[Bug preprocessor/70270] New: Spurious line directive with -g

[rguenth at gcc dot gnu.org]

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

Bug ID: 70270
   Summary: Spurious line directive with -g
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When preprocessing with -g0 vs. -g I see

> ./xgcc -B. t.c -E | head -3
# 1 "t.c"
# 1 ""
# 1 ""

> ./xgcc -B. t.c -E -g | head -3
# 1 "t.c"
# 1 "/abuild/rguenther/trunk3-g/gcc//"
# 1 ""

so a spurious directive

# 1 "/abuild/rguenther/trunk3-g/gcc//"

is added which may result in different line-map behavior of -save-temps
with -fcompare-debug vs. non-save-temps?

[Bug lto/70258] New: -fPIE isn't passed to lto by default when GCC is configured with --enable-default-pie

[hjl.tools at gmail dot com]

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

Bug ID: 70258
   Summary: -fPIE isn't passed to lto by default when GCC is
configured with --enable-default-pie
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

When GCC is configured with --enable-default-pie, I got

[hjl@gnu-skl-1 gcc]$ /export/build/gnu/gcc-pie/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/ 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -O0 -flto
-flto-partition=none -fuse-linker-plugin  -c -o c_lto_20081024_0.o
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/lto/20081024_0.c
[hjl@gnu-skl-1 gcc]$ /export/build/gnu/gcc-pie/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/ c_lto_20081024_0.o
-fno-diagnostics-show-caret -fdiagnostics-color=never  -O0 -flto
-flto-partition=none -fuse-linker-plugin -o gcc-dg-lto-20081024-01.exe -v
Reading specs from /export/build/gnu/gcc-pie/build-x86_64-linux/gcc/specs
COLLECT_GCC=/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/xgcc
COLLECT_LTO_WRAPPER=/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/gnu/import/git/sources/gcc/configure
--enable-languages=c,c++ --disable-bootstrap --disable-libcc1
--disable-libcilkrts --disable-libsanitizer --disable-libmpx
--prefix=/usr/gcc-6.0.0 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-default-pie --with-fpmath=sse
Thread model: posix
gcc version 6.0.0 20160316 (experimental) (GCC) 
COMPILER_PATH=/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/
LIBRARY_PATH=/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-fdiagnostics-color=never' '-B'
'/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/'
'-fno-diagnostics-show-caret' '-O0' '-flto' '-flto-partition=none'
'-fuse-linker-plugin' '-o' 'gcc-dg-lto-20081024-01.exe' '-v' '-mtune=generic'
'-march=x86-64'
 /export/build/gnu/gcc-pie/build-x86_64-linux/gcc/collect2 -plugin
/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/liblto_plugin.so
-plugin-opt=/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccfxn1F0.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -flto
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie
-o gcc-dg-lto-20081024-01.exe /lib/../lib64/Scrt1.o /lib/../lib64/crti.o
/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/crtbeginS.o
-L/export/build/gnu/gcc-pie/build-x86_64-linux/gcc -L/lib/../lib64
-L/usr/lib/../lib64 c_lto_20081024_0.o -lgcc --as-needed -lgcc_s --no-as-needed
-lc -lgcc --as-needed -lgcc_s --no-as-needed
/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/crtendS.o /lib/../lib64/crtn.o
/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/xgcc @/tmp/cc5z5itP
Reading specs from /export/build/gnu/gcc-pie/build-x86_64-linux/gcc/specs
COLLECT_GCC=/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: /export/gnu/import/git/sources/gcc/configure
--enable-languages=c,c++ --disable-bootstrap --disable-libcc1
--disable-libcilkrts --disable-libsanitizer --disable-libmpx
--prefix=/usr/gcc-6.0.0 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-default-pie --with-fpmath=sse
Thread model: posix
gcc version 6.0.0 20160316 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=never' '-c' '-fmath-errno'
'-fsigned-zeros' '-ftrapping-math' '-fno-trapv' '-fno-strict-overflow'
'-fno-openmp' '-fno-openacc' '-mtune=generic' '-march=x86-64' '-O0' '-B'
'/export/build/gnu/gcc-pie/build-x86_64-linux/gcc/'
'-fno-diagnostics-show-caret' '-O0' '-flto-partition=none'
'-fuse-linker-plugin' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' './'
'-dumpbase' 'gcc-dg-lto-20081024-01.exe' '-o' '/tmp/ccxq1b5Z.lto.o'
'-fresolution=/tmp/ccfxn1F0.res' '-flinker-output=pie'
 /export/build/gnu/gcc-pie/build-x86_64-linux/gcc/lto1 -quiet -dumpdir ./
-dumpbase gcc-dg-lto-20081024-01.exe -mtune=generic -march=x86-64
-mtune=generic -march=x86-64 -auxbase-strip /tmp/ccxq1b5Z.lto.o -O0 -O0
-version -fdiagnostics-color=never -fmath-errno -fsigned-zeros -ftrapping-math
-fno-trapv -fno-strict-overflow -fno-openmp -fno-openacc
-fno-diagnostics-show-caret -flto-partition=none -fuse-linker-plugin
-fresolution=/tmp/ccfxn1F0.res -flinker-output=pie @/tmp/cc40jC1Z -o
/tmp/ccXhR3pP.s
GNU GIMPLE (GCC) version 6.0.0 20160316 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 5.3.1 20160212 (Red Hat 5.3.1-4), GMP

[Bug fortran/69739] [4.9/5/6 Regression] ICE during array result, allocatable assignment

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
You probably hit something that's just not yet implemented:

trans-expr.c:

(gdb) list 4083,4096
4083case GFC_ISYM_LBOUND:
4084case GFC_ISYM_UBOUND:
4085/* TODO These implementations of lbound and ubound do not limit
if
4086   the size < 0, according to F95's 13.14.53 and 13.14.113.  */
4087
4088  if (!sym->as || sym->as->rank == 0)
4089return false;
4090
4091  if (arg2 && arg2->expr_type == EXPR_CONSTANT)
4092d = mpz_get_si (arg2->value.integer) - 1;
4093  else
4094/* TODO: If the need arises, this could produce an array of
4095   ubound/lbounds.  */
4096gcc_unreachable ();

[Bug rtl-optimization/70263] [4.9/5/6 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (segmentation fault)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r203895:

commit 4bc0f16ebd21b15d624ebbf8efa88c9c2f1df367
Author: law 
Date:   Mon Oct 21 15:25:09 2013 +

   * tree-ssa-threadedge.c (thread_through_normal_block): New argument
VISITED.
Remove VISISTED as a local variable.  When we have a threadable
jump, verify
the destination of the jump has not been visised.
(thread_across_edge): Allocate VISITED bitmap once at function
scope and
use it throughout.  Make sure to set appropriate bits in VISITED
for E (start
of jump thread path).

* tree-ssa-threadupdate.c (mark_threaded_blocks): Reject threading
through
a joiner if any edge on the path has a recorded jump thread.

[Bug c++/70139] [5/6 Regression] -fno-elide-constructor makes static std::regex to throw

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
Author: jason
Date: Fri Mar 18 20:16:05 2016
New Revision: 234345

URL: https://gcc.gnu.org/viewcvs?rev=234345&root=gcc&view=rev
Log:
PR c++/70139
* constexpr.c (cxx_eval_call_expression): Fix trivial copy.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[psturm at computervoice dot com]

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

--- Comment #10 from psturm at computervoice dot com ---
Yes, exact same errors when built without --enable-default-pie.

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[vhaisman at gmail dot com]

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

Václav Haisman  changed:

   What|Removed |Added

Version|4.9.2   |5.3.0

--- Comment #16 from Václav Haisman  ---
And this still fails for me with GCC 5.3:

`--> ./build.sh
+ g++ -std=gnu++11 -fvisibility=hidden -c use.cxx def.cxx
+ g++ -shared -o cygtest.dll use.o def.o
use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation truncated to
fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'
collect2: error: ld returned 1 exit status
.-(~/log4cplus-git/tls-test-case)
`--> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-3.x86_64/src/gcc-5.3.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-3.x86_64/src/gcc-5.3.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.3.0 (GCC)

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
(In reply to Jerry DeLisle from comment #4)
> I will get started on this one. Dominique, if you spot the problem let me
> know.

In determine_precision, one has:

  int precision = f->u.real.d;  // "3" as "F8.3" is used
case FMT_F:
  precision += dtp->u.p.scale_factor;  // 3 += -6 -> -3
  precision += 2 * len + 4; // -3 += 2 * 8 + 4 -> 17  ("8" from "F8.3")

i.e. one increased the precision for later manual rounding.

And later in "output_float"

  else /* p < 0  */
  if (nbefore + p >= 0)  // False as  5 + (-6) < -1
  else
  nafter = d + nbefore;

which sets nafter to 3 + 5 = 8. One then later has:

   nblanks = w - (nbefore + nzero + nafter + edigits + 1);
   // -2 = 8 - (0+1+8+0+1)

as nblanks < 0, one get the "".


My gut feeling is that it has something to do with having "precision" == 17 in
that function. In any case, the nafter is too large when nblanks is calculated.

[Bug c/70262] New: Segmentation fault with large stack array, no fault when alloca the same size

[nickdu at msn dot com]

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

Bug ID: 70262
   Summary: Segmentation fault with large stack array, no fault
when alloca the same size
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickdu at msn dot com
  Target Milestone: ---

I just ran into a segmentation fault in a binary I created with the gcc
compiler.  The code is written in c.  The problem appears to be with a stack
allocated buffer.  The buffer is large, 1024 * 1024 chars.  I realize that
there are some limitations on the stack size, though I think I'm still under
the limits.  The strange thing is that when I changed to using alloca(1024 *
1024) the segmentation fault no longer occurs.  My project consists of a bunch
of code and I have not yet attempted to pare it down to the bare minimum.  I
will attempt to give you as much information as I can with respect to the
function in question.

The signature of the function is:

void log_event(int level, const char* format, ...)

The lines of code in question are:

// INFO and more critical we send to HTTP endpoint. 

if ((level <= LOG_LEVEL_INFO) && (write_log_pipe != -1))
{

// Generate json for event. 

char json[1024 * 1024];
//  char* json = alloca(1024 * 1024);   
unsigned int len = 1024 * 1024;
//  generate_json(&ts, host_name, level_string, message,
//  json, &len);
strcpy(json, "hello, world");
len = strlen(json);

printf("log_event(), len = %d, json = %s\n", len, json);
if (len < 1024 * 1024)
{

// Write json event to log pipe.

if (pthread_mutex_lock(&log_pipe_lock) == 0)
{
write(write_log_pipe, &len, sizeof(len));
write(write_log_pipe, json, len);
pthread_mutex_unlock(&log_pipe_lock);
}
}
}

As you can see I was playing around with commenting out pieces of code.  Ignore
the commented function generate_json().  The code as it is above will generate
a segmentation fault.  If I comment out the 1024 * 1024 char array and
uncomment the alloca the segmentation fault goes away.

Thanks,
Nick

[Bug tree-optimization/70256] Add debug_varinfo and debug_varmap

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch
   Priority|P3  |P5
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #1 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00910.html

[Bug tree-optimization/70267] ICE on valid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed, but I can't really bisect this, even g++34 ICEs.  E.g. r104500 gives

h.c: In function ‘void Bar4()’:
h.c:34: internal compiler error: in emit_move_insn, at expr.c:3145
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|r234265 causes fails on |[6 Regression] r234265
   |rs6000  |causes fails on rs6000

--- Comment #1 from Jakub Jelinek  ---
This is combiner calling replace_rtx with x = (zero_extend:DI (reg:SI 3 3 [ p1
])) from = (reg:DI 3 3) to = (sign_extend:DI (clobber:SI (const_int 0 [0])))
(it will need better analysis, but perhaps it was just some optimization that
wouldn't break stuff it not everything is replaced).

So maybe we can just limit this to reload_completed (assert the mode is the
same), otherwise simply punt on replacing it at least for GCC 6.x, like we used
to do?

--- gcc/rtlanal.c   2016-03-16 18:51:43.735688164 +0100
+++ gcc/rtlanal.c   2016-03-17 00:24:28.949901218 +0100
@@ -2966,8 +2966,10 @@ replace_rtx (rtx x, rtx from, rtx to)
   if (GET_CODE (from) == REG
  && REGNO (x) == REGNO (from))
{
- gcc_assert (GET_MODE (x) == GET_MODE (from));
- return to;
+ if (GET_MODE (x) == GET_MODE (from))
+   return to;
+ else
+   gcc_assert (!reload_completed);
}
 }
   else if (GET_CODE (x) == SUBREG)

[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Fixed by Andrey's commit on the trunk.

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #20)
> I don't think that's a problem; the clobber only affects the as-base size of
> the class, which doesn't include any virtual bases unless they are primary,
> and virtual bases with data can't be primary.

So, perhaps then the clobbers should be conditional on in_chrg if there are
primary virtual bases?  What is the C++ FE test for existence of primary
virtual bases?  Or just do that for sanitization only?

[Bug fortran/70260] ICE: gimplification failed

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
ifort says:

t.f90(3): error #6643: This statement is incorrectly positioned.
  procedure g
--^
t.f90(3): error #8168: Parentheses are required after the PROCEDURE keyword.
  procedure g
--^
t.f90(10): error #6684: This is an incorrect value for a kind type parameter in
this context.   [KIND]
  character(kind=kind(gkind())) :: x
-^
t.f90(7): error #6793: The POINTER attribute is required
  g => 1
--^
t.f90(8): error #6377: FUNCTION must be present on the end-function-stmt of an
internal or module function
   end
^

and more errors.

[Bug bootstrap/69513] LTO bootstrap fails with bootstrap-profiled during linking gnat1 in stagefeedback

[rai...@emrich-ebersheim.de]

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

Rainer Emrich  changed:

   What|Removed |Added

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

--- Comment #7 from Rainer Emrich  ---
Sorry Eric, this isn't fixed!

Revision: 234256

/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/./prev-gcc/xg++
-B/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/./prev-gcc/
-B/opt/devel/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_13.2/gcc-6.0.0-test/x86_64-unknown-linux-gnu/bin/
-nostdinc++
-B/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/opt/devel/gnu/src/gcc/gcc-6.0.0-test/libstdc++-v3/libsupc++
-L/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/opt/devel/SCRATCH/tmp.SFOjUV9q4q/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fPIC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o gnat1 ada/adadecode.o
ada/adaint.o ada/argv.o ada/cio.o ada/cstreams.o ada/env.o ada/init.o
ada/initialize.o ada/raise.o ada/seh_init.o ada/targext.o ada/cuintp.o
ada/decl.o ada/rtfinal.o ada/rtinit.o ada/misc.o ada/utils.o ada/utils2.o
ada/trans.o ada/targtyps.o ada/a-charac.o ada/a-chlat1.o ada/a-elchha.o
ada/a-except.o ada/a-ioexce.o ada/ada.o ada/spark_xrefs.o ada/ali.o ada/alloc.o
ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o
ada/contracts.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o
ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o
ada/exp_aggr.o ada/exp_spark.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o
ada/exp_ch11.o ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o
ada/exp_ch4.o ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o
ada/exp_ch9.o ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o
ada/exp_fixd.o ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o
ada/exp_sel.o ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_unst.o
ada/exp_util.o ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o
ada/freeze.o ada/frontend.o ada/g-byorma.o ada/g-hesora.o ada/g-htable.o
ada/g-spchge.o ada/g-speche.o ada/g-u3spch.o ada/get_spark_xrefs.o
ada/get_targ.o ada/ghost.o ada/gnat.o ada/gnatvsn.o ada/hostparm.o
ada/impunit.o ada/inline.o ada/interfac.o ada/itypes.o ada/krunch.o
ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o ada/lib-xref.o
ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o ada/nmake.o
ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o ada/par_sco.o
ada/prep.o ada/prepcomp.o ada/put_spark_xrefs.o ada/put_scos.o ada/repinfo.o
ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o ada/s-assert.o
ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o
ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o
ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-excdeb.o ada/s-except.o
ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o
ada/s-memory.o ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o ada/s-restri.o
ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o
ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o ada/s-strhas.o
ada/s-string.o ada/s-strops.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o
ada/s-valint.o ada/s-valuns.o ada/s-valuti.o ada/s-wchcnv.o ada/s-wchcon.o
ada/s-wchjis.o ada/scans.o ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o
ada/sdefault.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o
ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o
ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o
ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_dim.o
ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o
ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_scil.o
ada/sem_smem.o ada/sem_type.o ada/sem_util.o ada/sem_warn.o ada/set_targ.o
ada/sinfo-cn.o ada/sinfo.o ada/sinput-d.o ada/sinput-l.o ada/sinput.o
ada/snames.o ada/sprint.o ada/stand.o ada/stringt.o a

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
But not sure how this became a regression - does GCC 5 really do better here?

With -fno-tree-dominator-opts the warning no longer triggers and we get

sub sp, sp, #428

so it may be another jump-threading related regression.  With additional
-fno-tree-vrp we get to

sub sp, sp, #140

> grep '<< 56' t.c.211t.optimized
  _68 = _38 << 56;
  _98 = _97 << 56;

for both and with VRP and DOM

> grep '<< 56' t.c.211t.optimized
  _68 = _38 << 56;
  _98 = _97 << 56;
  _137 = _138 << 56;
  _375 = _376 << 56;
  _342 = _343 << 56;
  _170 = _169 << 56;
  _603 = _602 << 56;
  _636 = _635 << 56;
  _209 = _208 << 56;
  _683 = _682 << 56;
  _716 = _715 << 56;
  _239 = _238 << 56;
  _523 = _522 << 56;
  _556 = _555 << 56;
  _300 = _301 << 56;
  _37 = _76 << 56;
  _443 = _442 << 56;
  _476 = _475 << 56;

so we get nine(!) copies of it.

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[glisse at gcc dot gnu.org]

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

--- Comment #19 from Marc Glisse  ---
(In reply to Marc Glisse from comment #18)
> I think this issue was already described in another PR.

Ah, that was PR 69134 for MPFR.
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00127.html

[Bug fortran/69739] [4.9/5/6 Regression] ICE during array result, allocatable assignment

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  ---
(In reply to John from comment #2)
> After reporting the bug, I noticed that in the actual code I have (not the
> reduced version I posted before), adding the (:) stride doesn't always make
> the ICE go away.
> 
> What solved the problem once and for all (and without using the
> -fno-realloc-lhs flag) was changing the result in the "operate" function to
> be that of an allocatable array:
> 
> function operate(A, X)
> type(sometype), intent(IN) :: A(:,:,:)
> real, intent(IN) :: X(:)
> !real :: operate(1:PRODUCT(UBOUND(A)))
> real, allocatable :: operate(:)
> 
> allocate (operate(1:PRODUCT(UBOUND(A
> operate(:) = 0
> end function
> 
> So maybe the automatic-size result is the actual root of the ICE?

If I use

real  :: operate(1:size(A))

instead of

real  :: operate(1:PRODUCT(UBOUND(A)))

I do not get an ICE.  So it's not automatic-size per se.