[Bug c++/69095] internal compiler error: in dependent_type_p, at cp/pt.c:19399

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-31
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. May be related to pr60153.

markus@x4 /tmp % cat test.ii
struct A {
  A(char *);
};
struct B {
  template 
  void insert(A, Ret);
};
void fun2() {
  B a1;
  a1.insert("", fun2);
}

markus@x4 /tmp % g++ -std=c++14 -c test.ii
test.ii: In substitution of ‘template > void B::insert(A, Ret) [with Ret = void (*)(); Args = {};
unsigned int  = ]’:
test.ii:10:21:   required from here
test.ii:5:62: internal compiler error: in dependent_type_p, at cp/pt.c:22376
   template 
  ^

0x62ddb3 dependent_type_p(tree_node*)
../../gcc/gcc/cp/pt.c:22376
0x72851f cxx_sizeof_or_alignof_type(tree_node*, tree_code, bool)
../../gcc/gcc/cp/typeck.c:1569
0x649a9c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16121
0x63e3a8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15658
0x64f1cc tsubst_template_arg
../../gcc/gcc/cp/pt.c:10302
0x668db2 type_unification_real
../../gcc/gcc/cp/pt.c:18346
0x675dcf fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:17611
0x5dfc6c add_template_candidate_real
../../gcc/gcc/cp/call.c:3059
0x5e06bc add_template_candidate
../../gcc/gcc/cp/call.c:3160
0x5e06bc add_candidates
../../gcc/gcc/cp/call.c:5332
0x5e0f4d build_new_method_call_1
../../gcc/gcc/cp/call.c:8261
0x5e0f4d build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8457
0x6f3eeb cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6851
0x6fd414 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7954
0x6fdffb cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:8631
0x6fe418 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8732
0x6fee04 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9019
0x7022f9 cp_parser_expression
../../gcc/gcc/cp/parser.c:9188
0x702db0 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10649
0x6ee334 cp_parser_statement
../../gcc/gcc/cp/parser.c:10500

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

[dominiq at lps dot ens.fr]

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

Bug ID: 69099
   Summary: ICE when compiling gcc.dg/atomic/c11-atomic-exec-2.c
with -fsanitize=float-cast-overflow
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
mpolacek at gcc dot gnu.org
  Target Milestone: ---

Compiling gcc.dg/atomic/c11-atomic-exec-2.c with -fsanitize=float-cast-overflow
gives the ICE

/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c: In function
'test_mult':
/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:60: internal
compiler error: in gimplify_expr, at gimplify.c:10845
   TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
^

/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:15:14: note: in
definition of macro 'TEST_COMPOUND'
   if ((a OP##= (RHSVAL)) != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL))) \
  ^~

/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:3: note: in
expansion of macro 'TEST_COMPOUND_ARITH'
   TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
   ^~~


/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:60: internal
compiler error: Abort trap: 6
   TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
^

/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:15:14: note: in
definition of macro 'TEST_COMPOUND'
   if ((a OP##= (RHSVAL)) != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL))) \
  ^~

/opt/gcc/_clean/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:71:3: note: in
expansion of macro 'TEST_COMPOUND_ARITH'
   TEST_COMPOUND_ARITH (CMPLX (1.5, 2.5), CMPLX (3.5, 4.5), *);
   ^~~

gcc: internal compiler error: Abort trap: 6 (program cc1)

with 5.3.0 and trunk (6.0).

[Bug sanitizer/69055] Internal compiler error -fsanitize=float-cast-overflow

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Created attachment 37174 [details]
> gcc6-pr69055.patch
>
> Untested fix. 

All the failures seen with gfortran are gone with the patch without regression.

> The c11-atomic* ICE is completely unrelated, please file it separately
> (and CC Marek Polacek).

PR69099

[Bug tree-optimization/68522] [6 Regression] SPEC CPU2006 435.gromacs miscomparison

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #5 from Yuri Rumyantsev  ---
I did deeper investigation of 435.gromacs miscomparison and found out that
1. It is caused by precision lost, i.e. this is not bug in split-paths phase.
2. This is caused by fmadd-sub instructions only (reproduced on avx2 with
fma-support), i.e. with -fno-fma option bench is passed.
3. I found the first guilty routine split-paths for which leads to
miscomparison: (fsettle) which is an ordinary fp-routine with big exit bb which
is replicated. I assume that restriction on size of exit bb to be duplicated
must be introduced to avoid useless code size growth. So you can close it after
adding correspondent parameter-limit.

[Bug c++/69089] C++11: alignas(0) causes an error

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
A tested patch with a test case is available here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02228.html

[Bug target/69100] New: ICE: in final_scan_insn, at final.c:2920 with -msoft-float and __builtin_apply()

[zsojka at seznam dot cz]

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

Bug ID: 69100
   Summary: ICE: in final_scan_insn, at final.c:2920 with
-msoft-float and __builtin_apply()
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: sparc64-unknown-linux-gnu

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

Compiler output:
$ sparc64-unknown-linux-gnu-gcc -msoft-float testcase.c 
testcase.c: In function 'foo':
testcase.c:5:1: error: insn does not satisfy its constraints:
 }
 ^

(insn 59 58 15 (set (reg:SI 32 %f0)
(mem/c:SI (plus:DI (reg/f:DI 30 %fp)
(const_int 1995 [0x7cb])) [0  S4 A32])) testcase.c:4 63
{*movsi_insn}
 (nil))
testcase.c:5:1: internal compiler error: in final_scan_insn, at final.c:2920
0xa90358 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0xa903c4 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:119
0x7d554c final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.c:2920
0x7d58cd final(rtx_insn*, _IO_FILE*, int)
/repo/gcc-trunk/gcc/final.c:2044
0x7d6fab rest_of_handle_final
/repo/gcc-trunk/gcc/final.c:4440
0x7d6fab execute
/repo/gcc-trunk/gcc/final.c:4515
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ sparc64-unknown-linux-gnu-gcc -v  
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-sparc64/bin/sparc64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231954-checking-yes-rtl-df-nographite-sparc64/bin/../libexec/gcc/sparc64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: sparc64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=sparc64-unknown-linux-gnu
--with-ld=/usr/bin/sparc64-unknown-linux-gnu-ld
--with-as=/usr/bin/sparc64-unknown-linux-gnu-as
--with-sysroot=/usr/sparc64-unknown-linux-gnu --disable-multilib
--disable-libsanitizer --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-231954-checking-yes-rtl-df-nographite-sparc64
Thread model: posix
gcc version 6.0.0 20151225 (experimental) (GCC) 


Other tested targets are not affected (apart from x86_64 4.0.4, which ICEs in
emit_swap_insn).

Tested revisions:
trunk r231954 - ICE
5-branch r231950 - ICE
4_9-branch r231949 - ICE
4_8-branch r224828 - ICE (in extract_constrain_insn_cached)

[Bug target/69100] ICE in final_scan_insn with -msoft-float and __builtin_apply ()

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|sparc64-unknown-linux-gnu   |sparc64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-31
 CC||ebotcazou at gcc dot gnu.org
   Host|x86_64-pc-linux-gnu |
Summary|ICE: in final_scan_insn, at |ICE in final_scan_insn with
   |final.c:2920 with   |-msoft-float and
   |-msoft-float and|__builtin_apply ()
   |__builtin_apply()   |
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Quite nonsensical though...

[Bug target/69100] ICE in final_scan_insn with -msoft-float and __builtin_apply ()

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

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

--- Comment #19 from Paul Thomas  ---
Created attachment 37198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37198&action=edit
Patch to fix the problem

The attached fixes all versions of the problem and regtests OK on FC21/x86_64.

I would prefer to have cured the problem in gfc_conv_expr_descriptor but the
logic associated with setting the offset has become so convoluted that I kept
breaking things. I guess that it would be neater to have a specific gfc_se flag
and to put the patch in gfc_conv_expr_descriptor?

I'll come back to this in the next day or so the latter being more likely
:-)

Paul

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

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
Another testcase:

[hjl@gnu-tools-1 pr68991]$ cat add.cc
typedef unsigned int size_type;

#define _GLIBCXX_BITSET_BITS_PER_WORD  (__CHAR_BIT__ * __SIZEOF_INT__)
#define _GLIBCXX_BITSET_WORDS(__n) \
  ((__n) / _GLIBCXX_BITSET_BITS_PER_WORD + \
   ((__n) % _GLIBCXX_BITSET_BITS_PER_WORD == 0 ? 0 : 1))

namespace std
{
  template
struct _Base_bitset
{
  typedef unsigned int _WordT;
  _WordT_M_w[_Nw];

  _WordT&
  _M_hiword()
  { return _M_w[_Nw - 1]; }

  void
  _M_do_and(const _Base_bitset<_Nw>& __x)
  {
for (size_type __i = 0; __i < _Nw; __i++)
  _M_w[__i] += __x._M_w[__i];
  }

  void
  _M_do_flip()
  {
for (size_type __i = 0; __i < _Nw; __i++)
  _M_w[__i] = ~_M_w[__i];
  }

  bool
  _M_is_equal(const _Base_bitset<_Nw>& __x) const
  {
for (size_type __i = 0; __i < _Nw; ++__i)
  if (_M_w[__i] != __x._M_w[__i])
return false;
return true;
  }

  bool
  _M_is_any() const
  {
for (size_type __i = 0; __i < _Nw; __i++)
  if (_M_w[__i] != static_cast<_WordT>(0))
return true;
return false;
  }
};

  template
struct _Sanitize
{
  typedef unsigned int _WordT;

  static void
  _S_do_sanitize(_WordT& __val)
  { __val &= ~((~static_cast<_WordT>(0)) << _Extrabits); }
};

  template
class bitset
: private _Base_bitset<_GLIBCXX_BITSET_WORDS(_Nb)>
{
private:
  typedef _Base_bitset<_GLIBCXX_BITSET_WORDS(_Nb)> _Base;
  typedef unsigned int _WordT;

  void
  _M_do_sanitize()
  { 
typedef _Sanitize<_Nb % _GLIBCXX_BITSET_BITS_PER_WORD> __sanitize_type;
__sanitize_type::_S_do_sanitize(this->_M_hiword());
  }

public:
  class reference
  {
friend class bitset;

_WordT* _M_wp;
size_type   _M_bpos;

  public:
reference&
flip()
{
  *_M_wp ^= _Base::_S_maskbit(_M_bpos);
  return *this;
}
  };

  bitset<_Nb>&
  operator&=(const bitset<_Nb>& __rhs)
  {
this->_M_do_and(__rhs);
return *this;
  }

  bitset<_Nb>&
  flip() 
  {
this->_M_do_flip();
this->_M_do_sanitize();
return *this;
  }

  bitset<_Nb>
  operator~() const 
  { return bitset<_Nb>(*this).flip(); }

  bool
  operator==(const bitset<_Nb>& __rhs) const 
  { return this->_M_is_equal(__rhs); }

  bool
  any() const 
  { return this->_M_is_any(); }
};

  template
inline bitset<_Nb>
operator&(const bitset<_Nb>& __x, const bitset<_Nb>& __y) 
{
  bitset<_Nb> __result(__x);
  __result &= __y;
  return __result;
}
}
template
class ArrayRef {
public:
typedef const T *iterator;

private:
const T *Data;
size_type Length;

public:
iterator begin() const { return Data; }
iterator end() const { return Data + Length; }
};

const unsigned MAX_SUBTARGET_FEATURES = 128;
class FeatureBitset : public std::bitset {
};

struct SubtargetFeatureKV {
  FeatureBitset Value;
  FeatureBitset Implies;
};

struct SubtargetInfoKV {
  const void *Value;
};
class SubtargetFeatures {
public:
FeatureBitset ToggleFeature(FeatureBitset Bits,
const SubtargetFeatureKV *,
ArrayRef FeatureTable);
};

static
void ClearImpliedBits(FeatureBitset &Bits,
  const SubtargetFeatureKV *FeatureEntry,
  ArrayRef FeatureTable) {
  for (auto &FE : FeatureTable) {
if ((FE.Implies & FeatureEntry->Value).any()) {
  Bits &= ~FE.Value;
  ClearImpliedBits(Bits, &FE, FeatureTable);
}
  }
}

FeatureBitset
SubtargetFeatures::ToggleFeature(FeatureBitset Bits,
 const SubtargetFeatureKV *FeatureEntry,
 ArrayRef FeatureTable) {
if ((Bits & FeatureEntry->Value) == FeatureEntry->Value) {
  Bits &= ~FeatureEntry->Value;
  ClearImpliedBits(Bits, FeatureEntry, FeatureTable);
}
  return Bits;
}
[hjl@gnu-tools-1 pr68991]$
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -m64 -O3 -fno-exceptions
-fno-rtti -da -S -o add.s add.cc
[hjl@gnu-tools-1 pr68991]$ 

LRA turns

(insn 17 15 109 2 (set (reg:V4SI 122 [ vect__19.94 ])
(plus:V4SI (mem/c:V4SI (plus:DI (reg/f:DI 20 frame)
(const_int -32 [0xffe0])) [6 MEM[(const struct
bitset &)&Bits]+0 S16 A32])
(subreg:V4SI (reg:V16QI 121) 0))) add.cc:24 2960 {*addv4si3}
 (expr_list:REG_DEAD (reg:V16QI 121)
(expr_list:REG_EQUIV (mem/c:V4SI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [3 MEM[(unsigned int
*)&__result]+0 S16 A128])
 

[Bug c++/68071] Generic lambda variadic argument pack cannot be empty

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
This looks like a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095

[Bug tree-optimization/69069] missing phi argument with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37199&action=edit
tentative patch

[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 37200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37200&action=edit
tentative patch

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres  ---
> Created attachment 37198 [details]
> Patch to fix the problem
>
> The attached fixes all versions of the problem and regtests OK on FC21/x86_64.

Are you sure you attached the right patch to the right PR?

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

  Attachment #37198|0   |1
is obsolete||

--- Comment #21 from Paul Thomas  ---
Created attachment 37201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37201&action=edit
the right patch this time

duuuh!

Thanks

[Bug fortran/69101] New: ICE when compiling some tests in gfortran.dg/ieee/ with -fdefault-integer-8 or -finteger-4-integer-8

[dominiq at lps dot ens.fr]

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

Bug ID: 69101
   Summary: ICE when compiling some tests in gfortran.dg/ieee/
with -fdefault-integer-8 or -finteger-4-integer-8
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

Compiling the tests gfortran.dg/ieee/large_*.f90 with -fdefault-integer-8 or
-finteger-4-integer-8 gives an ICE

f951: internal compiler error: Segmentation fault: 11

The backtrace is

* thread #1: tid = 0x3c4621a, 0x0001000bce4f
f951`simplify_ieee_selected_real_kind(expr=) + 15 at
simplify.c:7041, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x20)
frame #0: 0x0001000bce4f
f951`simplify_ieee_selected_real_kind(expr=) + 15 at
simplify.c:7041
   7038 {
   7039   gfc_actual_arglist *arg = expr->value.function.actual;
   7040   gfc_expr *p = arg->expr, *q = arg->next->expr,
-> 7041*rdx = arg->next->next->expr;
   7042 
   7043   /* Currently, if IEEE is supported and this module is built, it means
   7044  all our floating-point types conform to IEEE. Hence, we simply
handle
(lldb) bt
* thread #1: tid = 0x3c4621a, 0x0001000bce4f
f951`simplify_ieee_selected_real_kind(expr=) + 15 at
simplify.c:7041, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x20)
  * frame #0: 0x0001000bce4f
f951`simplify_ieee_selected_real_kind(expr=) + 15 at
simplify.c:7041
frame #1: 0x000100036578 f951`gfc_check_init_expr(e=0x000142326e30)
+ 1048 at expr.c:2485
frame #2: 0x000100036296 f951`gfc_check_init_expr(gfc_expr*) + 35 at
expr.c:2234
frame #3: 0x000100036273 f951`gfc_check_init_expr(gfc_expr*) [inlined]
check_conversion(e=0x000142326c10)
frame #4: 0x000100036273 f951`gfc_check_init_expr(e=0x000142326c10)
+ 275
frame #5: 0x0001000365c2 f951`gfc_check_init_expr(gfc_expr*) + 9 at
expr.c:2234
frame #6: 0x0001000365b9 f951`gfc_check_init_expr(gfc_expr*) [inlined]
check_elemental(e=0x000142325db0) + 35
frame #7: 0x000100036596 f951`gfc_check_init_expr(e=0x000142325db0)
+ 1078
frame #8: 0x000100036cd8
f951`gfc_reduce_init_expr(expr=0x000142325db0) + 56 at expr.c:2670
frame #9: 0x000100037daa
f951`gfc_match_init_expr(result=0x7fff5fbfece8) + 74 at expr.c:2709
frame #10: 0x000100026228 f951`gfc_match_data_decl() + 3704 at
decl.c:2167
frame #11: 0x000100080cfa f951`(subr=,
old_locus=0x7fff5fbfedd0, simd_matched=,
str=)(match (*)(), locus *, bool *, const char *) + 10 at
parse.c:93
frame #12: 0x000100084245 f951`(null)() + 677 at parse.c:372
frame #13: 0x000100086115 f951`::next_statement() + 389 at parse.c:1076
frame #14: 0x000100087a0d f951`::parse_spec(st=) + 3725 at
parse.c:3407
frame #15: 0x00010008b6e7 f951`::parse_progunit(st=) + 39
at parse.c:5189
frame #16: 0x00010008cfc2 f951`gfc_parse_file() + 994 at parse.c:5698
frame #17: 0x0001000d2cb6 f951`::gfc_be_parse_file() + 54 at
f95-lang.c:201
frame #18: 0x00010097e89a f951`::compile_file() + 58 at toplev.c:464
frame #19: 0x000100d6dcce f951`toplev::main(int, char**) + 1146 at
toplev.c:1985
frame #20: 0x000100d6d854 f951`toplev::main(this=, argc=5,
argv=0x7fff5fbff270) + 724
frame #21: 0x000100d6f689 f951`main(argc=5, argv=0x7fff5fbff270) +
41 at main.c:39

I get a second set of ICEs when compiling gfortran.dg/ieee/ieee_[78].f90. The
backtrace is

* thread #1: tid = 0x3c46716, 0x0001000bce57
f951`simplify_ieee_selected_real_kind(expr=) + 23 at
simplify.c:7046, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x18)
frame #0: 0x0001000bce57
f951`simplify_ieee_selected_real_kind(expr=) + 23 at
simplify.c:7046
   7043   /* Currently, if IEEE is supported and this module is built, it means
   7044  all our floating-point types conform to IEEE. Hence, we simply
handle
   7045  IEEE_SELECTED_REAL_KIND like SELECTED_REAL_KIND.  */
-> 7046   return gfc_simplify_selected_real_kind (p, q, rdx);
   7047 }
   7048 
   7049 gfc_expr *
(lldb) bt  
  * thread
#1: tid = 0x3c46716, 0x0001000bce57
f951`simplify_ieee_selected_real_kind(expr=) + 23 at
simplify.c:7046, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x18)
  * frame #0: 0x0001000bce57
f951`simplify_ieee_selected_real_kind(expr=) + 23 at
simplify.c:7046
frame #1: 0x000100036578 f951`gfc_check_init_expr(e=0x000142710e50)
+ 1048 at expr.c:2485
frame #2: 0x00010003

[Bug fortran/69101] ICE when compiling some tests in gfortran.dg/ieee/ with -fdefault-integer-8 or -finteger-4-integer-8

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-31
 Blocks||32770
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug 32770] [Meta-bug] -fdefault-integer-8 issues

[Bug target/34191] Using gcc with -mptr64 option on Solaris 5.9 produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #7 from Zdenek Sojka  ---
Similarly, gcc ICEs when compiling for 64bit target with -mptr32 :
$ sparc64-unknown-linux-gnu-gcc -mptr32 tmp.i 
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/nested-1.c: In function
'main':
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/nested-1.c:10:1: internal
compiler error: in emit_move_insn, at expr.c:3545
 main(int argc, char **argv)
 ^~~~

0x7b8b7f emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:3544
0x7955d7 force_reg
/repo/gcc-trunk/gcc/explow.c:631
0xe20190 sparc_trampoline_init
/repo/gcc-trunk/gcc/config/sparc/sparc.c:9316
0x660ff1 expand_builtin_init_trampoline
/repo/gcc-trunk/gcc/builtins.c:4638
0x671c17 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/repo/gcc-trunk/gcc/builtins.c:6138
0x7b2e9f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:10578
0x697a58 expand_expr
/repo/gcc-trunk/gcc/expr.h:256
0x697a58 expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:2648
0x697a58 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3536
0x697a58 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:3702
0x6991ad expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:5708
0x69e926 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6323
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/34191] Using gcc with -mptr64 option on Solaris 5.9 produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669

[zsojka at seznam dot cz]

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

--- Comment #8 from Zdenek Sojka  ---
And also when using -mcmodel=32 with a 64bit target:
$ sparc64-unknown-linux-gnu-gcc -mcmodel=32 tmp.i -w
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/2403-1.c: In function
'main':
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/2403-1.c:9:9: internal
compiler error: in sparc_emit_set_symbolic_const64, at
config/sparc/sparc.c:2085
   if (! seqgt (*aa, 0x1000, *bb) || ! seqgt2 (*aa, 0x1000, *bb))
 ^~~~

0xe32533 sparc_emit_set_symbolic_const64(rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/sparc/sparc.c:2085
0xe32e4e sparc_emit_set_const64
/repo/gcc-trunk/gcc/config/sparc/sparc.c:2442
0xe358b9 sparc_expand_move(machine_mode, rtx_def**)
/repo/gcc-trunk/gcc/config/sparc/sparc.c:1830
0xf2cda6 gen_movdi(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/sparc/sparc.md:1579
0x7b84ba insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/repo/gcc-trunk/gcc/recog.h:301
0x7b84ba emit_move_insn_1(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:3490
0x7b8814 emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:3585
0x797a7b copy_to_suggested_reg(rtx_def*, rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/explow.c:720
0x7976a0 memory_address_addr_space(machine_mode, rtx_def*, unsigned char)
/repo/gcc-trunk/gcc/explow.c:415
0x77a54c change_address_1
/repo/gcc-trunk/gcc/emit-rtl.c:2127
0x7b2de1 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:9672
0x7b0dda expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:10227
0x7c0729 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/repo/gcc-trunk/gcc/expr.c:5408
0x7c30f4 expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.c:5174
0x696c0d expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3606
0x696c0d expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:3702
0x6991ad expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:5708
0x69e926 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6323
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This switch is undocumented as well.

[Bug fortran/69101] ICE when compiling some tests in gfortran.dg/ieee/ with -fdefault-integer-8 or -finteger-4-integer-8

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
This has nothing to do with either -fdefault-integer-8 or
-finteger-4-integer-8.  The IEEE module is not implemented 
correctly.

program foo
   use ieee_arithmetic
   implicit none
   integer(8) n
   integer k1
   n = precision(0.d0)
   k1 = ieee_selected_real_kind(n)
end program foo

% gfc -c yy.f90
yy.f90:7:32:

k1 = ieee_selected_real_kind(n)
1

Error: Type mismatch in argument 'p' at (1); passed INTEGER(8) to INTEGER(4)

The Fortran 2003 standard contains

14.10.17 IEEE_SELECTED_REAL_KIND ([P, R])

Description. Returns a value of the kind type parameter of an IEEE
  real data type with decimal precision of at least P digits and
  a decimal exponent range of at least R.  For data objects of such
  a type, IEEE SUPPORT DATATYPE(X) has the value true.

Class. Transformational function.

Arguments. At least one argument shall be present.

P (optional)  shall be scalar and of type integer.
R (optional)  shall be scalar and of type integer.

Result Characteristics. Default integer scalar.


Note the description of P is 'of type integer' not 'of default
integer type'.

As a bonus, the result is a 'default integer scalar' so to
support the -fdefault-integer-8 or -finteger-4-integer-8 option,
you need to generate code that can return either kind type.

[Bug fortran/69101] ICE when compiling some tests in gfortran.dg/ieee/ with -fdefault-integer-8 or -finteger-4-integer-8

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> This has nothing to do with either -fdefault-integer-8 or
> -finteger-4-integer-8.  The IEEE module is not implemented 
> correctly.

F2003: 14.10 Specifications of the procedures

In the detailed descriptions below, procedure names are generic
and are not specific.

On x86_64, there are 5 integer kind type parameters.  For
IEEE_SELECTED_REAL_KIND(P,R), gfortran either needs 25 
helper functions to accommodate the 25 combinations of 
P and R or a helper conversion function that forces R and
P to a specific integer kind type.

[Bug rtl-optimization/69102] New: [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2

[zsojka at seznam dot cz]

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

Bug ID: 69102
   Summary: [4.9/5/6 Regression] ICE: in move_op_ascend, at
sel-sched.c:6138 with -fselective-scheduling2
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu

Created attachment 37202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37202&action=edit
testcase (gcc.c-torture/compile/pr20583.c)

Compiler output:
$ i686-pc-linux-gnu-gcc -Og -fPIC -fschedule-insns2 -fselective-scheduling2
-fno-tree-fre --param=max-sched-extend-regions-iters=10 testcase.c 
testcase.c: In function 'foo':
testcase.c:20:1: internal compiler error: in move_op_ascend, at
sel-sched.c:6138
 }
 ^

0xb3db50 move_op_ascend
/repo/gcc-trunk/gcc/sel-sched.c:6138
0xb38ccf code_motion_path_driver
/repo/gcc-trunk/gcc/sel-sched.c:6634
0xb39363 code_motion_process_successors
/repo/gcc-trunk/gcc/sel-sched.c:6331
0xb39363 code_motion_path_driver
/repo/gcc-trunk/gcc/sel-sched.c:6597
0xb3e0e3 move_op
/repo/gcc-trunk/gcc/sel-sched.c:6688
0xb3e0e3 move_exprs_to_boundary
/repo/gcc-trunk/gcc/sel-sched.c:5212
0xb3e0e3 schedule_expr_on_boundary
/repo/gcc-trunk/gcc/sel-sched.c:5424
0xb3f9ae fill_insns
/repo/gcc-trunk/gcc/sel-sched.c:5566
0xb4158d schedule_on_fences
/repo/gcc-trunk/gcc/sel-sched.c:7342
0xb4158d sel_sched_region_2
/repo/gcc-trunk/gcc/sel-sched.c:7480
0xb43fdb sel_sched_region_1
/repo/gcc-trunk/gcc/sel-sched.c:7522
0xb43fdb sel_sched_region(int)
/repo/gcc-trunk/gcc/sel-sched.c:7623
0xb45529 run_selective_scheduling()
/repo/gcc-trunk/gcc/sel-sched.c:7699
0xb195a5 rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.c:3729
0xb195a5 execute
/repo/gcc-trunk/gcc/sched-rgn.c:3873
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 r231954 - ICE
5-branch r231950 - ICE
4_9-branch r231949 - ICE
4_8-branch r224828 - OK

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  ---
> Created attachment 37201 [details]
> the right patch this time

Works as expected without regression!

[Bug c++/69103] New: Misleading diagnostic for invalid constexpr initialization

[rs2740 at gmail dot com]

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

Bug ID: 69103
   Summary: Misleading diagnostic for invalid constexpr
initialization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Consider:

static int i;
static int* temp = &i;
static constexpr int *&&r = static_cast(temp) + 1;

This correctly doesn't compile, but produces the misleading error message

prog.cc:3:57: error: modification of '_ZGRL1r0' is not a constant-expression
 static constexpr int *&&r = static_cast(temp) + 1;
 ^

We aren't modifying anything in the initializer.

In contrast, Clang produces:

prog.cc:3:25: error: constexpr variable 'r' must be initialized by a constant
expression
static constexpr int *&&r = static_cast(temp) + 1;
^   ~
prog.cc:3:29: note: read of non-constexpr variable 'temp' is not allowed in a
constant expression
static constexpr int *&&r = static_cast(temp) + 1;
^
prog.cc:2:13: note: declared here
static int* temp = &i;

[Bug target/34191] Using gcc with -mptr64 option on Solaris 5.9 produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> This switch is undocumented as well.

Exactly, so please do not try to fiddle with it.

[Bug target/69015] ICE: RTL check: expected code 'code_label', have 'return' in find_cond_trap, at ifcvt.c:3715 with -fno-if-conversion and __builtin_trap()

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 31 23:51:50 2015
New Revision: 232020

URL: https://gcc.gnu.org/viewcvs?rev=232020&root=gcc&view=rev
Log:
PR target/69015
* ifcvt.c (find_cond_trap): Give up if returnjump_p (jump).

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69015.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug c/69104] New: invalid atomic memory order not diagnosed

[msebor at gcc dot gnu.org]

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

Bug ID: 69104
   Summary: invalid atomic memory order not diagnosed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Gcc silently accepts invocations of C11 atomic operations with an invalid
memory_order argument.  For example, it doesn't diagnose any of the invalid
calls in the test case below (and emits fences for most).

In contrast, Clang issues "warning: memory order argument to atomic operation
is invalid [-Watomic-memory-ordering]" for each of them and treats them as
no-ops.

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -O2 -S -Wall -Wextra -Wpedantic
-o/dev/null z.c
#include 

/* atomic_store_explicit():
   The order argument shall not be memory_order_acquire,
   memory_order_consume, nor memory_order_acq_rel.  */

void store_consume (_Atomic int *i)
{
  atomic_store_explicit (i, 0, memory_order_consume);
}

void store_acquire (_Atomic int *i)
{
  atomic_store_explicit (i, 0, memory_order_acquire);
}

void store_acq_rel (_Atomic int *i)
{
  atomic_store_explicit (i, 0, memory_order_acq_rel);
}

/* atomic_load_explicit():
   The order argument shall not be memory_order_release nor
   memory_order_acq_rel.  */

int load_consume (_Atomic int *i)
{
  return atomic_load_explicit (i, memory_order_release);
}

int load_acq_rel (_Atomic int *i)
{
  return atomic_load_explicit (i, memory_order_acq_rel);
}

[Bug c++/69103] Misleading diagnostic for invalid constexpr initialization

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||miyuki at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
Link to the original thread, for the record:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/WS5pLaXwC8Y

_ZGRL1r0 demangles as "reference temporary #0 for r"

[Bug libstdc++/69105] New: front_/back_/insert_iterator should use addressof

[rs2740 at gmail dot com]

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

Bug ID: 69105
   Summary: front_/back_/insert_iterator should use addressof
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Test case:

#include 
#include 

struct test : std::deque {
void operator&() const = delete;
};

int main() {
test t;
std::back_insert_iterator b(t);
std::front_insert_iterator f(t);
std::insert_iterator i(t, t.begin());
}

http://wg21.link/LWG2324 requires std::addressof to be used.

gcc-bugs@gcc.gnu.org

[rs2740 at gmail dot com]

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

Bug ID: 69106
   Summary: std::promise should tolerate overloaded &
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Test case:

#include 

struct foo {
void operator&() const = delete;
};

int main() {
std::promise p;
p.set_value(foo());
}

results in:

In file included from prog.cc:1:0:
/usr/local/gcc-head/include/c++/6.0.0/future: In instantiation of 'static
std::__future_base::_State_baseV2::_Setter<_Res, _Arg&&>
std::__future_base::_State_baseV2::__setter(std::promise<_Res>*, _Arg&&) [with
_Res = foo; _Arg = foo]':
/usr/local/gcc-head/include/c++/6.0.0/future:1081:50:   required from 'void
std::promise<_Res>::set_value(_Res&&) [with _Res = foo]'
prog.cc:9:22:   required from here
/usr/local/gcc-head/include/c++/6.0.0/future:510:49: error: use of deleted
function 'void foo::operator&() const'
   return _Setter<_Res, _Arg&&>{ __prom, &__arg };
 ^~

prog.cc:4:10: note: declared here
 void operator&() const = delete;
  ^~~~