public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
@ 2014-10-18 11:44 trippels at gcc dot gnu.org
2014-10-19 21:31 ` [Bug ipa/63587] " mliska at suse dot cz
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-10-18 11:44 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4694 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
Bug ID: 63587
Summary: [5 Regression] ICE : tree check: expected var_decl,
have result_decl in add_local_variables, at
tree-inline.c:4112
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
trippels@gcc1-power7 status % g++ -c -w -std=c++11 -O2 form_attr.ii
form_attr.ii: In static member function âstatic int
boost::function_obj_invoker0<FunctionObj>::invoke(boost::function_buffer&)
[with FunctionObj =
boost::test_case_template_invoker<default_formatting_invoker>]â:
form_attr.ii:216:66: internal compiler error: tree check: expected var_decl,
have result_decl in add_local_variables, at tree-inline.c:4112
make_output_actor<actor<LeftExprT>, attribute_actor<T> >::make (left,
right);
^
0x10c686af tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9185
0x10a1161f tree_check
../../gcc/gcc/tree.h:2733
0x10a1161f add_local_variables
../../gcc/gcc/tree-inline.c:4112
0x10a1c39f expand_call_inline
../../gcc/gcc/tree-inline.c:4389
0x10a1c39f gimple_expand_calls_inline
../../gcc/gcc/tree-inline.c:4518
0x10a1c39f optimize_inline_calls(tree_node*)
../../gcc/gcc/tree-inline.c:4659
0x10fc7acf inline_transform(cgraph_node*)
../../gcc/gcc/ipa-inline-transform.c:460
0x1089755f execute_one_ipa_transform_pass
../../gcc/gcc/passes.c:1990
0x1089755f execute_all_ipa_transforms()
../../gcc/gcc/passes.c:2031
0x1052cc67 cgraph_node::expand()
../../gcc/gcc/cgraphunit.c:1735
0x1052e957 expand_all_functions
../../gcc/gcc/cgraphunit.c:1878
0x1052e957 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2213
0x105309d3 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2290
0x10260d33 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4666
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
trippels@gcc1-power7 status % g++ -fno-ipa-icf -c -w -std=c++11 -O2
form_attr.ii
trippels@gcc1-power7 status %
>From gcc-bugs-return-464418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Oct 18 11:46:02 2014
Return-Path: <gcc-bugs-return-464418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18290 invoked by alias); 18 Oct 2014 11:46:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18261 invoked by uid 48); 18 Oct 2014 11:45:59 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
Date: Sat, 18 Oct 2014 11:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63587-4-FFM7j4Aqqq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01439.txt.bz2
Content-length: 240
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc587
--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 33754
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id3754&actioníit
reduced testcase
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
@ 2014-10-19 21:31 ` mliska at suse dot cz
2014-10-20 6:49 ` trippels at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mliska at suse dot cz @ 2014-10-19 21:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #2 from Martin Liška <mliska at suse dot cz> ---
Following two functions are merged:
static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actor<int,
boost::log::value_extractor, void, boost::actor>; ValueT = int;
boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actor<{anonymous}::my_class,
boost::log::value_extractor, void, boost::actor>; ValueT = int;
boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
with following body:
{
struct type D.3826;
struct to_log_fun D.3825;
struct attribute_name D.3824;
int SR.9;
struct actor left;
<bb 2>:
left = left;
SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
MEM[(struct attribute_name *)&D.3824] = SR.9_4;
boost::log::attribute_output_terminal<boost::actor<int>,
boost::log::to_log_fun>::attribute_output_terminal<int> (&D.3826, left, D.3824,
D.3825, 0);
D.3826 ={v} {CLOBBER};
return;
}
As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
template arguments: attribute_actor<int,...> vs.
attribute_actor<{anonymous}::my_class,...>.
What do you think Richard about these record_types from alias set perspective:
(gdb) p debug_tree(t1)
<mem_ref 0x7ffff6ab4000
type <integer_type 0x7ffff6c33690 int public type_6 SI
size <integer_cst 0x7ffff6c51048 constant 32>
unit size <integer_cst 0x7ffff6c51060 constant 4>
align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
2147483647>
pointer_to_this <pointer_type 0x7ffff6c55738>>
arg 0 <ssa_name 0x7ffff6aae678
type <reference_type 0x7ffff6e20d20 type <record_type 0x7ffff6de7dc8
attribute_actor>
unsigned DI
size <integer_cst 0x7ffff6c2fdf8 constant 64>
unit size <integer_cst 0x7ffff6c2fe10 constant 8>
align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20d20>
visited var <parm_decl 0x7ffff6e1eb00 right>def_stmt GIMPLE_NOP
version 2
ptr-info 0x7ffff6a7e3d8>
arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
constant 0>>
$1 = void
(gdb) p debug_tree(t2)
<mem_ref 0x7ffff6aa1ac8
type <integer_type 0x7ffff6c33690 int public type_6 SI
size <integer_cst 0x7ffff6c51048 constant 32>
unit size <integer_cst 0x7ffff6c51060 constant 4>
align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
2147483647>
pointer_to_this <pointer_type 0x7ffff6c55738>>
arg 0 <ssa_name 0x7ffff6a77dc8
type <reference_type 0x7ffff6e20540 type <record_type 0x7ffff6ddd888
attribute_actor>
unsigned DI
size <integer_cst 0x7ffff6c2fdf8 constant 64>
unit size <integer_cst 0x7ffff6c2fe10 constant 8>
align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20540>
visited var <parm_decl 0x7ffff6e1ea00 right>def_stmt GIMPLE_NOP
version 2
ptr-info 0x7ffff6a7e300>
arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
constant 0>>
these types are called for alias_set comparison, with following record_types:
(gdb) p debug_tree((tree_node*)0x7ffff6de7dc8)
<record_type 0x7ffff6de7dc8 attribute_actor needs-constructing type_5 type_6
SI
size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
bitsizetype> constant 32>
unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
sizetype> constant 4>
align 32 symtab 0 alias set 17 canonical type 0x7ffff6de7dc8
fields <field_decl 0x7ffff6de4ed8 D.2798
type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
4>
align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
<field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
boost>
full-name "struct boost::actor<boost::log::attribute_terminal>"
needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=1 interface-unknown
pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
<reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
align 32 offset_align 128
offset <integer_cst 0x7ffff6c2fe28 constant 0>
bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
0x7ffff6de7dc8 attribute_actor>
chain <type_decl 0x7ffff6de4da8 attribute_actor type <record_type
0x7ffff6de80a8 attribute_actor>
external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
line 168 col 1
align 8 context <record_type 0x7ffff6de7dc8 attribute_actor> result
<record_type 0x7ffff6de7dc8 attribute_actor>
chain <type_decl 0x7ffff6de4e40 value_type>>> context
<namespace_decl 0x7ffff6dbec78 log>
full-name "class boost::log::attribute_actor<int,
boost::log::value_extractor, void, boost::actor>"
needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
interface-unknown
pointer_to_this <pointer_type 0x7ffff6de81f8> reference_to_this
<reference_type 0x7ffff6e20d20> chain <type_decl 0x7ffff6de4d10
attribute_actor>>
$3 = void
(gdb) p debug_tree((tree_node*)0x7ffff6ddd888)
<record_type 0x7ffff6ddd888 attribute_actor needs-constructing type_5 type_6
SI
size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
bitsizetype> constant 32>
unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
sizetype> constant 4>
align 32 symtab 0 alias set 14 canonical type 0x7ffff6ddd888
fields <field_decl 0x7ffff6de0b48 D.2756
type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
4>
align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
<field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
boost>
full-name "struct boost::actor<boost::log::attribute_terminal>"
needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=1 interface-unknown
pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
<reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
align 32 offset_align 128
offset <integer_cst 0x7ffff6c2fe28 constant 0>
bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
0x7ffff6ddd888 attribute_actor>
chain <type_decl 0x7ffff6de0a18 attribute_actor type <record_type
0x7ffff6de12a0 attribute_actor>
external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
line 168 col 1
align 8 context <record_type 0x7ffff6ddd888 attribute_actor> result
<record_type 0x7ffff6ddd888 attribute_actor>
chain <type_decl 0x7ffff6de0ab0 value_type>>> context
<namespace_decl 0x7ffff6dbec78 log>
full-name "class boost::log::attribute_actor<{anonymous}::my_class,
boost::log::value_extractor, void, boost::actor>"
needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
interface-unknown
pointer_to_this <pointer_type 0x7ffff6de13f0> reference_to_this
<reference_type 0x7ffff6e20540> chain <type_decl 0x7ffff6dd2ed8
attribute_actor>>
If the alias sets can be considered to be equal, we must face some latent bug
in inliner?
Thank you,
Martin
>From gcc-bugs-return-464466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 19 21:31:46 2014
Return-Path: <gcc-bugs-return-464466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18411 invoked by alias); 19 Oct 2014 21:31:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18380 invoked by uid 48); 19 Oct 2014 21:31:43 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63592] Linux kernel build failure due to duplicate exported symbols
Date: Sun, 19 Oct 2014 21:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63592-4-1PGD2Cak9c@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63592-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63592-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01487.txt.bz2
Content-length: 428
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc592
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Igor Zamyatin from comment #4)
> The same could be seen for 253.perlbmk and 400.perlbench tests from
> spec2K/2006 suites
That is a bug in the SPEC CPU also.
There is a define for __attribute__ which causes the issue. I decided to use
-std=gnu90 when compiling SPEC CPU as a portability flag.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
2014-10-19 21:31 ` [Bug ipa/63587] " mliska at suse dot cz
@ 2014-10-20 6:49 ` trippels at gcc dot gnu.org
2014-10-20 7:54 ` rguenther at suse dot de
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-10-20 6:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Here's another smaller example:
% cat test.ii
template <class> struct A
{
};
template <typename> struct B
{
template <typename> struct C;
};
class D;
template <typename> class F;
struct G
{
void operator()(const D &, D);
};
class D
{
public:
D (int);
};
struct H
{
H (int);
};
template <typename _Key, typename, typename, typename _Compare, typename>
class I
{
typedef _Key key_type;
template <typename _Key_compare> struct J
{
_Key_compare _M_key_compare;
};
J<_Compare> _M_impl;
public:
A<int> _M_get_insert_unique_pos (const key_type &);
A<int> _M_get_insert_hint_unique_pos (H &);
template <typename... _Args> int _M_emplace_hint_unique (H, _Args &&...);
};
template <typename _Key, typename _Tp, typename _Compare = G,
typename _Alloc = F<A<_Tp> > >
class K
{
typedef _Key key_type;
typedef _Key value_type;
typedef typename B<_Alloc>::template C<value_type> _Pair_alloc_type;
I<key_type, value_type, int, _Compare, _Pair_alloc_type> _M_t;
public:
void operator[](key_type) { _M_t._M_emplace_hint_unique (0); }
};
template <typename _Key, typename _Val, typename _KeyOfValue,
typename _Compare, typename _Alloc>
A<int>
I<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_get_insert_unique_pos (
const key_type &p1)
{
_M_impl._M_key_compare (p1, 0);
}
template <typename _Key, typename _Val, typename _KeyOfValue,
typename _Compare, typename _Alloc>
A<int>
I<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_get_insert_hint_unique_pos (
H &)
{
_M_get_insert_unique_pos (0);
}
template <typename _Key, typename _Val, typename _KeyOfValue,
typename _Compare, typename _Alloc>
template <typename... _Args>
int
I<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_emplace_hint_unique (
H p1, _Args &&...)
{
_M_get_insert_hint_unique_pos (p1);
}
namespace
{
struct L;
}
void
fn1 ()
{
K<D, L> a;
a[0];
K<D, int> b;
b[0];
}
% g++ -c -O2 -std=c++11 -fno-strict-aliasing test.ii
test.ii: In function ‘void fn1()’:
test.ii:64:28: internal compiler error: tree check: expected var_decl, have
result_decl in add_local_variables, at tree-inline.c:4112
>From gcc-bugs-return-464477-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 20 06:49:08 2014
Return-Path: <gcc-bugs-return-464477-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8574 invoked by alias); 20 Oct 2014 06:49:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8538 invoked by uid 48); 20 Oct 2014 06:49:04 -0000
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported
Date: Mon, 20 Oct 2014 07:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libquadmath
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55821-4-coNkeMrq0i@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55821-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55821-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01498.txt.bz2
Content-length: 1136
https://gcc.gnu.org/bugzilla/show_bug.cgi?idU821
--- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Sandra Loosemore from comment #7)
> Trying to build an arm-none-linux-gnueabi cross from mainline head, I'm
> getting this error now:
>
> /scratch/sandra/arm-fsf/src/gcc-mainline/libquadmath/libquadmath.texi:369:
> @include `libquadmath-vers.texi': No such file or directory.
> /scratch/sandra/arm-fsf/src/gcc-mainline/libquadmath/libquadmath.texi:374:
> warning: undefined flag: BUGURL.
What is your configure line?
Does the following patch (untested for now) fix the issue for you?
Index: Makefile.am
==================================================================--- Makefile.am (revision 216036)
+++ Makefile.am (working copy)
@@ -163,11 +163,11 @@ MAKEINFOFLAGS = -I $(srcdir)/../gcc/doc/
if BUILD_LIBQUADMATH
info_TEXINFOS = libquadmath.texi
-libquadmath_TEXINFOS = libquadmath-vers.texi
else
info_TEXINFOS -libquadmath_TEXINFOS endif
+libquadmath_TEXINFOS = libquadmath-vers.texi
+
libquadmath-vers.texi:
echo "@set BUGURL $(REPORT_BUGS_TEXI)" > $@
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
2014-10-19 21:31 ` [Bug ipa/63587] " mliska at suse dot cz
2014-10-20 6:49 ` trippels at gcc dot gnu.org
@ 2014-10-20 7:54 ` rguenther at suse dot de
2014-10-20 12:53 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenther at suse dot de @ 2014-10-20 7:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 19 Oct 2014, mliska at suse dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>
> --- Comment #2 from Martin Liška <mliska at suse dot cz> ---
> Following two functions are merged:
> static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
> boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
> ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
> LeftExprT = int; RightT = boost::log::attribute_actor<int,
> boost::log::value_extractor, void, boost::actor>; ValueT = int;
> boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
> boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
> boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
>
>
> static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
> boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
> ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
> LeftExprT = int; RightT = boost::log::attribute_actor<{anonymous}::my_class,
> boost::log::value_extractor, void, boost::actor>; ValueT = int;
> boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
> boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
> boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
>
> with following body:
> {
> struct type D.3826;
> struct to_log_fun D.3825;
> struct attribute_name D.3824;
> int SR.9;
> struct actor left;
>
> <bb 2>:
> left = left;
> SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
> MEM[(struct attribute_name *)&D.3824] = SR.9_4;
> boost::log::attribute_output_terminal<boost::actor<int>,
> boost::log::to_log_fun>::attribute_output_terminal<int> (&D.3826, left, D.3824,
> D.3825, 0);
> D.3826 ={v} {CLOBBER};
> return;
>
> }
>
>
>
> As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
> template arguments: attribute_actor<int,...> vs.
> attribute_actor<{anonymous}::my_class,...>.
> What do you think Richard about these record_types from alias set perspective:
>
> (gdb) p debug_tree(t1)
> <mem_ref 0x7ffff6ab4000
> type <integer_type 0x7ffff6c33690 int public type_6 SI
> size <integer_cst 0x7ffff6c51048 constant 32>
> unit size <integer_cst 0x7ffff6c51060 constant 4>
> align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
> 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
> 2147483647>
> pointer_to_this <pointer_type 0x7ffff6c55738>>
>
> arg 0 <ssa_name 0x7ffff6aae678
> type <reference_type 0x7ffff6e20d20 type <record_type 0x7ffff6de7dc8
> attribute_actor>
> unsigned DI
> size <integer_cst 0x7ffff6c2fdf8 constant 64>
> unit size <integer_cst 0x7ffff6c2fe10 constant 8>
> align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20d20>
> visited var <parm_decl 0x7ffff6e1eb00 right>def_stmt GIMPLE_NOP
>
> version 2
> ptr-info 0x7ffff6a7e3d8>
> arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
> constant 0>>
> $1 = void
> (gdb) p debug_tree(t2)
> <mem_ref 0x7ffff6aa1ac8
> type <integer_type 0x7ffff6c33690 int public type_6 SI
> size <integer_cst 0x7ffff6c51048 constant 32>
> unit size <integer_cst 0x7ffff6c51060 constant 4>
> align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
> 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
> 2147483647>
> pointer_to_this <pointer_type 0x7ffff6c55738>>
>
> arg 0 <ssa_name 0x7ffff6a77dc8
> type <reference_type 0x7ffff6e20540 type <record_type 0x7ffff6ddd888
> attribute_actor>
> unsigned DI
> size <integer_cst 0x7ffff6c2fdf8 constant 64>
> unit size <integer_cst 0x7ffff6c2fe10 constant 8>
> align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20540>
> visited var <parm_decl 0x7ffff6e1ea00 right>def_stmt GIMPLE_NOP
>
> version 2
> ptr-info 0x7ffff6a7e300>
> arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
> constant 0>>
>
> these types are called for alias_set comparison, with following record_types:
> (gdb) p debug_tree((tree_node*)0x7ffff6de7dc8)
> <record_type 0x7ffff6de7dc8 attribute_actor needs-constructing type_5 type_6
> SI
> size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
> bitsizetype> constant 32>
> unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
> sizetype> constant 4>
> align 32 symtab 0 alias set 17 canonical type 0x7ffff6de7dc8
> fields <field_decl 0x7ffff6de4ed8 D.2798
> type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
> SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
> 4>
> align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
> <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
> boost>
> full-name "struct boost::actor<boost::log::attribute_terminal>"
> needs-constructor X() X(constX&) this=(X&) n_parents=0
> use_template=1 interface-unknown
> pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
> <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
> ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
> 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
> align 32 offset_align 128
> offset <integer_cst 0x7ffff6c2fe28 constant 0>
> bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
> 0x7ffff6de7dc8 attribute_actor>
> chain <type_decl 0x7ffff6de4da8 attribute_actor type <record_type
> 0x7ffff6de80a8 attribute_actor>
> external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
> line 168 col 1
> align 8 context <record_type 0x7ffff6de7dc8 attribute_actor> result
> <record_type 0x7ffff6de7dc8 attribute_actor>
> chain <type_decl 0x7ffff6de4e40 value_type>>> context
> <namespace_decl 0x7ffff6dbec78 log>
> full-name "class boost::log::attribute_actor<int,
> boost::log::value_extractor, void, boost::actor>"
> needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
> interface-unknown
> pointer_to_this <pointer_type 0x7ffff6de81f8> reference_to_this
> <reference_type 0x7ffff6e20d20> chain <type_decl 0x7ffff6de4d10
> attribute_actor>>
> $3 = void
> (gdb) p debug_tree((tree_node*)0x7ffff6ddd888)
> <record_type 0x7ffff6ddd888 attribute_actor needs-constructing type_5 type_6
> SI
> size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
> bitsizetype> constant 32>
> unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
> sizetype> constant 4>
> align 32 symtab 0 alias set 14 canonical type 0x7ffff6ddd888
> fields <field_decl 0x7ffff6de0b48 D.2756
> type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
> SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
> 4>
> align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
> <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
> boost>
> full-name "struct boost::actor<boost::log::attribute_terminal>"
> needs-constructor X() X(constX&) this=(X&) n_parents=0
> use_template=1 interface-unknown
> pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
> <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
> ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
> 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
> align 32 offset_align 128
> offset <integer_cst 0x7ffff6c2fe28 constant 0>
> bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
> 0x7ffff6ddd888 attribute_actor>
> chain <type_decl 0x7ffff6de0a18 attribute_actor type <record_type
> 0x7ffff6de12a0 attribute_actor>
> external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
> line 168 col 1
> align 8 context <record_type 0x7ffff6ddd888 attribute_actor> result
> <record_type 0x7ffff6ddd888 attribute_actor>
> chain <type_decl 0x7ffff6de0ab0 value_type>>> context
> <namespace_decl 0x7ffff6dbec78 log>
> full-name "class boost::log::attribute_actor<{anonymous}::my_class,
> boost::log::value_extractor, void, boost::actor>"
> needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
> interface-unknown
> pointer_to_this <pointer_type 0x7ffff6de13f0> reference_to_this
> <reference_type 0x7ffff6e20540> chain <type_decl 0x7ffff6dd2ed8
> attribute_actor>>
>
> If the alias sets can be considered to be equal, we must face some latent bug
> in inliner?
Maybe. Btw, I see some issues in func_checker::compare_operand with
regard to it doing redundant checks:
if (!func_checker::compatible_types_p (TREE_TYPE (x1), TREE_TYPE
(x2)))
return return_false ();
Redundant with the following
if (!compare_operand (x1, x2))
return return_false_with_msg ("");
...
if (get_alias_set (TREE_TYPE (y1)) != get_alias_set (TREE_TYPE
(y2)))
return return_false_with_msg ("alias set for MEM_REF offsets are
different");
Redundant with the following
ao_ref r1, r2;
ao_ref_init (&r1, t1);
ao_ref_init (&r2, t2);
if (ao_ref_alias_set (&r1) != ao_ref_alias_set (&r2)
|| ao_ref_base_alias_set (&r1) != ao_ref_base_alias_set (&r2))
return return_false_with_msg ("ao alias sets are different");
/* Type of the offset on MEM_REF does not matter. */
return wi::to_offset (y1) == wi::to_offset (y2);
Use tree_int_cst_equal (y1, y2).
case COMPONENT_REF:
{
x1 = TREE_OPERAND (t1, 0);
x2 = TREE_OPERAND (t2, 0);
y1 = TREE_OPERAND (t1, 1);
y2 = TREE_OPERAND (t2, 1);
ret = compare_operand (x1, x2)
&& compare_operand (y1, y2);
comparing FIELD_DECLs like you do looks dangerous to me (and it looks
redundant with the get_addr_base_and_unit_offset you do - which btw
also defeats the ao_ref alias checks as you effectively drop the
get_alias_set () compare).
IMHO folding memory access comparison and general operand comparison
into one function makes it very much less clear what is going on...
So - can you please split this into the general compare_operand
and a compare_memory_access function?
>From gcc-bugs-return-464483-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 20 07:54:13 2014
Return-Path: <gcc-bugs-return-464483-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3660 invoked by alias); 20 Oct 2014 07:54:13 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3644 invoked by uid 55); 20 Oct 2014 07:54:09 -0000
From: "jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/63589] find_addr2line does not consider last PATH component
Date: Mon, 20 Oct 2014 08:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jb at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jb at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63589-4-sr80iGMFO0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63589-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63589-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01504.txt.bz2
Content-length: 779
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc589
--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Author: jb
Date: Mon Oct 20 07:53:37 2014
New Revision: 216449
URL: https://gcc.gnu.org/viewcvs?rev!6449&root=gcc&view=rev
Log:
PR 63589 Fix splitting of PATH in find_addr2line.
2014-10-20 Janne Blomqvist <jb@gcc.gnu.org>
PR libfortran/63589
* configure.ac: Check for strtok_r.
* runtime/main.c (gfstrtok_r): Fallback implementation of
strtok_r.
(find_addr2line): Use strtok_r to split PATH.
* config.h.in: Regenerated.
* configure: Regenerated.
Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/runtime/main.c
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (2 preceding siblings ...)
2014-10-20 7:54 ` rguenther at suse dot de
@ 2014-10-20 12:53 ` rguenth at gcc dot gnu.org
2014-10-23 13:14 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-10-20 12:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |5.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (3 preceding siblings ...)
2014-10-20 12:53 ` rguenth at gcc dot gnu.org
@ 2014-10-23 13:14 ` marxin at gcc dot gnu.org
2014-10-23 13:22 ` rguenther at suse dot de
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2014-10-23 13:14 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 15123 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #5 from marxin at gcc dot gnu.org ---
(In reply to rguenther@suse.de from comment #4)
> On Sun, 19 Oct 2014, mliska at suse dot cz wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
> >
> > --- Comment #2 from Martin Liška <mliska at suse dot cz> ---
> > Following two functions are merged:
> > static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
> > boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
> > ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
> > LeftExprT = int; RightT = boost::log::attribute_actor<int,
> > boost::log::value_extractor, void, boost::actor>; ValueT = int;
> > boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
> > boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
> > boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
> >
> >
> > static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
> > boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
> > ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
> > LeftExprT = int; RightT = boost::log::attribute_actor<{anonymous}::my_class,
> > boost::log::value_extractor, void, boost::actor>; ValueT = int;
> > boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
> > boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
> > boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
> >
> > with following body:
> > {
> > struct type D.3826;
> > struct to_log_fun D.3825;
> > struct attribute_name D.3824;
> > int SR.9;
> > struct actor left;
> >
> > <bb 2>:
> > left = left;
> > SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
> > MEM[(struct attribute_name *)&D.3824] = SR.9_4;
> > boost::log::attribute_output_terminal<boost::actor<int>,
> > boost::log::to_log_fun>::attribute_output_terminal<int> (&D.3826, left, D.3824,
> > D.3825, 0);
> > D.3826 ={v} {CLOBBER};
> > return;
> >
> > }
> >
> >
> >
> > As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
> > template arguments: attribute_actor<int,...> vs.
> > attribute_actor<{anonymous}::my_class,...>.
> > What do you think Richard about these record_types from alias set perspective:
> >
> > (gdb) p debug_tree(t1)
> > <mem_ref 0x7ffff6ab4000
> > type <integer_type 0x7ffff6c33690 int public type_6 SI
> > size <integer_cst 0x7ffff6c51048 constant 32>
> > unit size <integer_cst 0x7ffff6c51060 constant 4>
> > align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
> > 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
> > 2147483647>
> > pointer_to_this <pointer_type 0x7ffff6c55738>>
> >
> > arg 0 <ssa_name 0x7ffff6aae678
> > type <reference_type 0x7ffff6e20d20 type <record_type 0x7ffff6de7dc8
> > attribute_actor>
> > unsigned DI
> > size <integer_cst 0x7ffff6c2fdf8 constant 64>
> > unit size <integer_cst 0x7ffff6c2fe10 constant 8>
> > align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20d20>
> > visited var <parm_decl 0x7ffff6e1eb00 right>def_stmt GIMPLE_NOP
> >
> > version 2
> > ptr-info 0x7ffff6a7e3d8>
> > arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
> > constant 0>>
> > $1 = void
> > (gdb) p debug_tree(t2)
> > <mem_ref 0x7ffff6aa1ac8
> > type <integer_type 0x7ffff6c33690 int public type_6 SI
> > size <integer_cst 0x7ffff6c51048 constant 32>
> > unit size <integer_cst 0x7ffff6c51060 constant 4>
> > align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
> > 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
> > 2147483647>
> > pointer_to_this <pointer_type 0x7ffff6c55738>>
> >
> > arg 0 <ssa_name 0x7ffff6a77dc8
> > type <reference_type 0x7ffff6e20540 type <record_type 0x7ffff6ddd888
> > attribute_actor>
> > unsigned DI
> > size <integer_cst 0x7ffff6c2fdf8 constant 64>
> > unit size <integer_cst 0x7ffff6c2fe10 constant 8>
> > align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20540>
> > visited var <parm_decl 0x7ffff6e1ea00 right>def_stmt GIMPLE_NOP
> >
> > version 2
> > ptr-info 0x7ffff6a7e300>
> > arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
> > constant 0>>
> >
> > these types are called for alias_set comparison, with following record_types:
> > (gdb) p debug_tree((tree_node*)0x7ffff6de7dc8)
> > <record_type 0x7ffff6de7dc8 attribute_actor needs-constructing type_5 type_6
> > SI
> > size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
> > bitsizetype> constant 32>
> > unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
> > sizetype> constant 4>
> > align 32 symtab 0 alias set 17 canonical type 0x7ffff6de7dc8
> > fields <field_decl 0x7ffff6de4ed8 D.2798
> > type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
> > SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
> > 4>
> > align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
> > <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
> > boost>
> > full-name "struct boost::actor<boost::log::attribute_terminal>"
> > needs-constructor X() X(constX&) this=(X&) n_parents=0
> > use_template=1 interface-unknown
> > pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
> > <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
> > ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
> > 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
> > align 32 offset_align 128
> > offset <integer_cst 0x7ffff6c2fe28 constant 0>
> > bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
> > 0x7ffff6de7dc8 attribute_actor>
> > chain <type_decl 0x7ffff6de4da8 attribute_actor type <record_type
> > 0x7ffff6de80a8 attribute_actor>
> > external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
> > line 168 col 1
> > align 8 context <record_type 0x7ffff6de7dc8 attribute_actor> result
> > <record_type 0x7ffff6de7dc8 attribute_actor>
> > chain <type_decl 0x7ffff6de4e40 value_type>>> context
> > <namespace_decl 0x7ffff6dbec78 log>
> > full-name "class boost::log::attribute_actor<int,
> > boost::log::value_extractor, void, boost::actor>"
> > needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
> > interface-unknown
> > pointer_to_this <pointer_type 0x7ffff6de81f8> reference_to_this
> > <reference_type 0x7ffff6e20d20> chain <type_decl 0x7ffff6de4d10
> > attribute_actor>>
> > $3 = void
> > (gdb) p debug_tree((tree_node*)0x7ffff6ddd888)
> > <record_type 0x7ffff6ddd888 attribute_actor needs-constructing type_5 type_6
> > SI
> > size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
> > bitsizetype> constant 32>
> > unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
> > sizetype> constant 4>
> > align 32 symtab 0 alias set 14 canonical type 0x7ffff6ddd888
> > fields <field_decl 0x7ffff6de0b48 D.2756
> > type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
> > SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
> > 4>
> > align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
> > <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
> > boost>
> > full-name "struct boost::actor<boost::log::attribute_terminal>"
> > needs-constructor X() X(constX&) this=(X&) n_parents=0
> > use_template=1 interface-unknown
> > pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
> > <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
> > ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
> > 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
> > align 32 offset_align 128
> > offset <integer_cst 0x7ffff6c2fe28 constant 0>
> > bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
> > 0x7ffff6ddd888 attribute_actor>
> > chain <type_decl 0x7ffff6de0a18 attribute_actor type <record_type
> > 0x7ffff6de12a0 attribute_actor>
> > external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
> > line 168 col 1
> > align 8 context <record_type 0x7ffff6ddd888 attribute_actor> result
> > <record_type 0x7ffff6ddd888 attribute_actor>
> > chain <type_decl 0x7ffff6de0ab0 value_type>>> context
> > <namespace_decl 0x7ffff6dbec78 log>
> > full-name "class boost::log::attribute_actor<{anonymous}::my_class,
> > boost::log::value_extractor, void, boost::actor>"
> > needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
> > interface-unknown
> > pointer_to_this <pointer_type 0x7ffff6de13f0> reference_to_this
> > <reference_type 0x7ffff6e20540> chain <type_decl 0x7ffff6dd2ed8
> > attribute_actor>>
> >
> > If the alias sets can be considered to be equal, we must face some latent bug
> > in inliner?
>
> Maybe. Btw, I see some issues in func_checker::compare_operand with
> regard to it doing redundant checks:
>
> if (!func_checker::compatible_types_p (TREE_TYPE (x1), TREE_TYPE
> (x2)))
> return return_false ();
>
> Redundant with the following
>
> if (!compare_operand (x1, x2))
> return return_false_with_msg ("");
>
> ...
>
> if (get_alias_set (TREE_TYPE (y1)) != get_alias_set (TREE_TYPE
> (y2)))
> return return_false_with_msg ("alias set for MEM_REF offsets are
> different");
>
> Redundant with the following
>
> ao_ref r1, r2;
> ao_ref_init (&r1, t1);
> ao_ref_init (&r2, t2);
> if (ao_ref_alias_set (&r1) != ao_ref_alias_set (&r2)
> || ao_ref_base_alias_set (&r1) != ao_ref_base_alias_set (&r2))
> return return_false_with_msg ("ao alias sets are different");
>
>
> /* Type of the offset on MEM_REF does not matter. */
> return wi::to_offset (y1) == wi::to_offset (y2);
>
> Use tree_int_cst_equal (y1, y2).
>
> case COMPONENT_REF:
> {
> x1 = TREE_OPERAND (t1, 0);
> x2 = TREE_OPERAND (t2, 0);
> y1 = TREE_OPERAND (t1, 1);
> y2 = TREE_OPERAND (t2, 1);
>
> ret = compare_operand (x1, x2)
> && compare_operand (y1, y2);
>
> comparing FIELD_DECLs like you do looks dangerous to me (and it looks
> redundant with the get_addr_base_and_unit_offset you do - which btw
> also defeats the ao_ref alias checks as you effectively drop the
> get_alias_set () compare).
>
> IMHO folding memory access comparison and general operand comparison
> into one function makes it very much less clear what is going on...
>
> So - can you please split this into the general compare_operand
> and a compare_memory_access function?
Hello Richard.
I agree with suggested refactoring, I've got almost working version that I need
to regtest.
Anyway, the problem of the issue is that the pass creates a thunk:
static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actor<{anonymous}::my_class,
boost::log::value_extractor, void, boost::actor>; ValueT = int;
boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
{
struct type <retval>;
<bb 2>:
<retval> = boost::log::make_output_actor<boost::actor<int>,
boost::log::attribute_actor<int, boost::log::value_extractor, void,
boost::actor>, int>::make (left, right_2(D)); [tail call]
return <retval>;
}
At cgraphunit.c:1547 (expand_thunk) we add result_decl to local_decl:
add_local_decl (cfun, restmp);
Remapping code in add_local_variable contains predicate DECL_HAS_DEBUG_EXPR_P
(var), where TREE_CODE(var) == RESULT_DECL.
Question is if either local_decl should never contain RESULT_DECL or just
addition of TREE_CODE(var) == VAR_DECL to the problematic condition would be
enough?
Thanks,
Martin
>From gcc-bugs-return-464743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 23 13:14:57 2014
Return-Path: <gcc-bugs-return-464743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1918 invoked by alias); 23 Oct 2014 13:14:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1450 invoked by uid 48); 23 Oct 2014 13:14:49 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
Date: Thu, 23 Oct 2014 13:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63587-4-qPalFzWlrI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01764.txt.bz2
Content-length: 213
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc587
--- Comment #6 from marxin at gcc dot gnu.org ---
Created attachment 33794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id3794&actioníit
PR63587.patch
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (4 preceding siblings ...)
2014-10-23 13:14 ` marxin at gcc dot gnu.org
@ 2014-10-23 13:22 ` rguenther at suse dot de
2014-10-23 17:17 ` marxin at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenther at suse dot de @ 2014-10-23 13:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>
> --- Comment #5 from marxin at gcc dot gnu.org ---
> (In reply to rguenther@suse.de from comment #4)
> > On Sun, 19 Oct 2014, mliska at suse dot cz wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
> > >
> > > --- Comment #2 from Martin Liška <mliska at suse dot cz> ---
> > > Following two functions are merged:
> > > static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
> > > boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
> > > ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
> > > LeftExprT = int; RightT = boost::log::attribute_actor<int,
> > > boost::log::value_extractor, void, boost::actor>; ValueT = int;
> > > boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
> > > boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
> > > boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
> > >
> > >
> > > static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
> > > boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
> > > ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
> > > LeftExprT = int; RightT = boost::log::attribute_actor<{anonymous}::my_class,
> > > boost::log::value_extractor, void, boost::actor>; ValueT = int;
> > > boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
> > > boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
> > > boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
> > >
> > > with following body:
> > > {
> > > struct type D.3826;
> > > struct to_log_fun D.3825;
> > > struct attribute_name D.3824;
> > > int SR.9;
> > > struct actor left;
> > >
> > > <bb 2>:
> > > left = left;
> > > SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
> > > MEM[(struct attribute_name *)&D.3824] = SR.9_4;
> > > boost::log::attribute_output_terminal<boost::actor<int>,
> > > boost::log::to_log_fun>::attribute_output_terminal<int> (&D.3826, left, D.3824,
> > > D.3825, 0);
> > > D.3826 ={v} {CLOBBER};
> > > return;
> > >
> > > }
> > >
> > >
> > >
> > > As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
> > > template arguments: attribute_actor<int,...> vs.
> > > attribute_actor<{anonymous}::my_class,...>.
> > > What do you think Richard about these record_types from alias set perspective:
> > >
> > > (gdb) p debug_tree(t1)
> > > <mem_ref 0x7ffff6ab4000
> > > type <integer_type 0x7ffff6c33690 int public type_6 SI
> > > size <integer_cst 0x7ffff6c51048 constant 32>
> > > unit size <integer_cst 0x7ffff6c51060 constant 4>
> > > align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
> > > 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
> > > 2147483647>
> > > pointer_to_this <pointer_type 0x7ffff6c55738>>
> > >
> > > arg 0 <ssa_name 0x7ffff6aae678
> > > type <reference_type 0x7ffff6e20d20 type <record_type 0x7ffff6de7dc8
> > > attribute_actor>
> > > unsigned DI
> > > size <integer_cst 0x7ffff6c2fdf8 constant 64>
> > > unit size <integer_cst 0x7ffff6c2fe10 constant 8>
> > > align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20d20>
> > > visited var <parm_decl 0x7ffff6e1eb00 right>def_stmt GIMPLE_NOP
> > >
> > > version 2
> > > ptr-info 0x7ffff6a7e3d8>
> > > arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
> > > constant 0>>
> > > $1 = void
> > > (gdb) p debug_tree(t2)
> > > <mem_ref 0x7ffff6aa1ac8
> > > type <integer_type 0x7ffff6c33690 int public type_6 SI
> > > size <integer_cst 0x7ffff6c51048 constant 32>
> > > unit size <integer_cst 0x7ffff6c51060 constant 4>
> > > align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
> > > 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
> > > 2147483647>
> > > pointer_to_this <pointer_type 0x7ffff6c55738>>
> > >
> > > arg 0 <ssa_name 0x7ffff6a77dc8
> > > type <reference_type 0x7ffff6e20540 type <record_type 0x7ffff6ddd888
> > > attribute_actor>
> > > unsigned DI
> > > size <integer_cst 0x7ffff6c2fdf8 constant 64>
> > > unit size <integer_cst 0x7ffff6c2fe10 constant 8>
> > > align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20540>
> > > visited var <parm_decl 0x7ffff6e1ea00 right>def_stmt GIMPLE_NOP
> > >
> > > version 2
> > > ptr-info 0x7ffff6a7e300>
> > > arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
> > > constant 0>>
> > >
> > > these types are called for alias_set comparison, with following record_types:
> > > (gdb) p debug_tree((tree_node*)0x7ffff6de7dc8)
> > > <record_type 0x7ffff6de7dc8 attribute_actor needs-constructing type_5 type_6
> > > SI
> > > size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
> > > bitsizetype> constant 32>
> > > unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
> > > sizetype> constant 4>
> > > align 32 symtab 0 alias set 17 canonical type 0x7ffff6de7dc8
> > > fields <field_decl 0x7ffff6de4ed8 D.2798
> > > type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
> > > SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
> > > 4>
> > > align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
> > > <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
> > > boost>
> > > full-name "struct boost::actor<boost::log::attribute_terminal>"
> > > needs-constructor X() X(constX&) this=(X&) n_parents=0
> > > use_template=1 interface-unknown
> > > pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
> > > <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
> > > ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
> > > 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
> > > align 32 offset_align 128
> > > offset <integer_cst 0x7ffff6c2fe28 constant 0>
> > > bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
> > > 0x7ffff6de7dc8 attribute_actor>
> > > chain <type_decl 0x7ffff6de4da8 attribute_actor type <record_type
> > > 0x7ffff6de80a8 attribute_actor>
> > > external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
> > > line 168 col 1
> > > align 8 context <record_type 0x7ffff6de7dc8 attribute_actor> result
> > > <record_type 0x7ffff6de7dc8 attribute_actor>
> > > chain <type_decl 0x7ffff6de4e40 value_type>>> context
> > > <namespace_decl 0x7ffff6dbec78 log>
> > > full-name "class boost::log::attribute_actor<int,
> > > boost::log::value_extractor, void, boost::actor>"
> > > needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
> > > interface-unknown
> > > pointer_to_this <pointer_type 0x7ffff6de81f8> reference_to_this
> > > <reference_type 0x7ffff6e20d20> chain <type_decl 0x7ffff6de4d10
> > > attribute_actor>>
> > > $3 = void
> > > (gdb) p debug_tree((tree_node*)0x7ffff6ddd888)
> > > <record_type 0x7ffff6ddd888 attribute_actor needs-constructing type_5 type_6
> > > SI
> > > size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
> > > bitsizetype> constant 32>
> > > unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
> > > sizetype> constant 4>
> > > align 32 symtab 0 alias set 14 canonical type 0x7ffff6ddd888
> > > fields <field_decl 0x7ffff6de0b48 D.2756
> > > type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
> > > SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
> > > 4>
> > > align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
> > > <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
> > > boost>
> > > full-name "struct boost::actor<boost::log::attribute_terminal>"
> > > needs-constructor X() X(constX&) this=(X&) n_parents=0
> > > use_template=1 interface-unknown
> > > pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
> > > <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
> > > ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
> > > 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
> > > align 32 offset_align 128
> > > offset <integer_cst 0x7ffff6c2fe28 constant 0>
> > > bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
> > > 0x7ffff6ddd888 attribute_actor>
> > > chain <type_decl 0x7ffff6de0a18 attribute_actor type <record_type
> > > 0x7ffff6de12a0 attribute_actor>
> > > external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
> > > line 168 col 1
> > > align 8 context <record_type 0x7ffff6ddd888 attribute_actor> result
> > > <record_type 0x7ffff6ddd888 attribute_actor>
> > > chain <type_decl 0x7ffff6de0ab0 value_type>>> context
> > > <namespace_decl 0x7ffff6dbec78 log>
> > > full-name "class boost::log::attribute_actor<{anonymous}::my_class,
> > > boost::log::value_extractor, void, boost::actor>"
> > > needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
> > > interface-unknown
> > > pointer_to_this <pointer_type 0x7ffff6de13f0> reference_to_this
> > > <reference_type 0x7ffff6e20540> chain <type_decl 0x7ffff6dd2ed8
> > > attribute_actor>>
> > >
> > > If the alias sets can be considered to be equal, we must face some latent bug
> > > in inliner?
> >
> > Maybe. Btw, I see some issues in func_checker::compare_operand with
> > regard to it doing redundant checks:
> >
> > if (!func_checker::compatible_types_p (TREE_TYPE (x1), TREE_TYPE
> > (x2)))
> > return return_false ();
> >
> > Redundant with the following
> >
> > if (!compare_operand (x1, x2))
> > return return_false_with_msg ("");
> >
> > ...
> >
> > if (get_alias_set (TREE_TYPE (y1)) != get_alias_set (TREE_TYPE
> > (y2)))
> > return return_false_with_msg ("alias set for MEM_REF offsets are
> > different");
> >
> > Redundant with the following
> >
> > ao_ref r1, r2;
> > ao_ref_init (&r1, t1);
> > ao_ref_init (&r2, t2);
> > if (ao_ref_alias_set (&r1) != ao_ref_alias_set (&r2)
> > || ao_ref_base_alias_set (&r1) != ao_ref_base_alias_set (&r2))
> > return return_false_with_msg ("ao alias sets are different");
> >
> >
> > /* Type of the offset on MEM_REF does not matter. */
> > return wi::to_offset (y1) == wi::to_offset (y2);
> >
> > Use tree_int_cst_equal (y1, y2).
> >
> > case COMPONENT_REF:
> > {
> > x1 = TREE_OPERAND (t1, 0);
> > x2 = TREE_OPERAND (t2, 0);
> > y1 = TREE_OPERAND (t1, 1);
> > y2 = TREE_OPERAND (t2, 1);
> >
> > ret = compare_operand (x1, x2)
> > && compare_operand (y1, y2);
> >
> > comparing FIELD_DECLs like you do looks dangerous to me (and it looks
> > redundant with the get_addr_base_and_unit_offset you do - which btw
> > also defeats the ao_ref alias checks as you effectively drop the
> > get_alias_set () compare).
> >
> > IMHO folding memory access comparison and general operand comparison
> > into one function makes it very much less clear what is going on...
> >
> > So - can you please split this into the general compare_operand
> > and a compare_memory_access function?
>
> Hello Richard.
>
> I agree with suggested refactoring, I've got almost working version that I need
> to regtest.
> Anyway, the problem of the issue is that the pass creates a thunk:
>
> static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
> boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
> ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
> LeftExprT = int; RightT = boost::log::attribute_actor<{anonymous}::my_class,
> boost::log::value_extractor, void, boost::actor>; ValueT = int;
> boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
> boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
> boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
> {
> struct type <retval>;
>
> <bb 2>:
> <retval> = boost::log::make_output_actor<boost::actor<int>,
> boost::log::attribute_actor<int, boost::log::value_extractor, void,
> boost::actor>, int>::make (left, right_2(D)); [tail call]
> return <retval>;
>
> }
>
> At cgraphunit.c:1547 (expand_thunk) we add result_decl to local_decl:
> add_local_decl (cfun, restmp);
>
> Remapping code in add_local_variable contains predicate DECL_HAS_DEBUG_EXPR_P
> (var), where TREE_CODE(var) == RESULT_DECL.
> Question is if either local_decl should never contain RESULT_DECL or just
> addition of TREE_CODE(var) == VAR_DECL to the problematic condition would be
> enough?
local_decl should never contain RESULT_DECL.
Richard.
>From gcc-bugs-return-464746-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 23 13:22:49 2014
Return-Path: <gcc-bugs-return-464746-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9884 invoked by alias); 23 Oct 2014 13:22:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9849 invoked by uid 48); 23 Oct 2014 13:22:45 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/12742] Type alignment is lost if const is added to typedef
Date: Thu, 23 Oct 2014 13:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 3.2.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-12742-4-WyJ2C1lGmu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-12742-4@http.gcc.gnu.org/bugzilla/>
References: <bug-12742-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01767.txt.bz2
Content-length: 535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id\x12742
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |mpolacek at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
This has been fixed a long time ago.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (5 preceding siblings ...)
2014-10-23 13:22 ` rguenther at suse dot de
@ 2014-10-23 17:17 ` marxin at gcc dot gnu.org
2014-10-23 21:09 ` mliska at suse dot cz
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2014-10-23 17:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
I added assert to cgraphunit.c (expand_thunk):1547:
/* Build call to the function being thunked. */
if (!VOID_TYPE_P (restype))
{
if (DECL_BY_REFERENCE (resdecl))
restmp = gimple_fold_indirect_ref (resdecl);
else if (!is_gimple_reg_type (restype))
{
restmp = resdecl;
gcc_assert (TREE_CODE (restmp) == VAR_DECL);
add_local_decl (cfun, restmp);
BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
}
else
restmp = create_tmp_reg (restype, "retval");
}
It's triggered quite often, one example of a thunk created by IPA ICF:
std::basic_streambuf<_CharT, _Traits>::pos_type std::basic_streambuf<_CharT,
_Traits>::seekpos(std::basic_streambuf<_CharT, _Traits>::pos_type,
std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>;
std::basic_streambuf<_CharT, _Traits>::pos_type = std::fpos<__mbstate_t>;
std::ios_base::openmode = std::_Ios_Openmode] (struct basic_streambuf * const
this, struct pos_type D.23077, openmode D.23078)
{
struct pos_type <retval>;
<bb 2>:
<retval> = std::basic_streambuf<wchar_t>::seekpos (this_2(D), D.23077,
_3(D)); [tail call]
return <retval>;
}
where std::basic_streambuf<_CharT, _Traits>::pos_type is:
<result_decl 0x7ffff4eec708 D.39821
type <record_type 0x7ffff59c2150 pos_type sizes-gimplified asm_written used
needs-constructing type_1 type_5 TI
size <integer_cst 0x7ffff6c2fe40 constant 128>
unit size <integer_cst 0x7ffff6c2fe58 constant 16>
align 64 symtab -164402368 alias set -1 canonical type 0x7ffff614adc8
fields <field_decl 0x7ffff51cd850 _M_off type <integer_type
0x7ffff678c738 streamoff>
used private nonlocal decl_3 DI file
/home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/postypes.h
line 115 col 33
size <integer_cst 0x7ffff6c2fdf8 constant 64>
unit size <integer_cst 0x7ffff6c2fe10 constant 8>
align 64 offset_align 128
offset <integer_cst 0x7ffff6c2fe28 constant 0>
bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context
<record_type 0x7ffff614adc8 fpos> chain <field_decl 0x7ffff51cd8e8 _M_state>>
context <namespace_decl 0x7ffff6c4c098 std>
full-name "std::basic_streambuf<char>::pos_type"
needs-constructor X() has-type-conversion X(constX&) this=(X&)
n_parents=0 use_template=1 interface-unknown
pointer_to_this <pointer_type 0x7ffff5224e70> chain <type_decl
0x7ffff6146da8 fpos>>
ignored TI file
/home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/streambuf
line 602 col 7 size <integer_cst 0x7ffff6c2fe40 128> unit size <integer_cst
0x7ffff6c2fe58 16>
align 64 context <function_decl 0x7ffff5797948 seekoff>>
Is there a bug in expand_thunk or do I miss something?
Thanks,
Martin
>From gcc-bugs-return-464861-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 23 17:17:05 2014
Return-Path: <gcc-bugs-return-464861-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11468 invoked by alias); 23 Oct 2014 17:17:05 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11414 invoked by uid 48); 23 Oct 2014 17:16:57 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63632] [4.9/5 Regression] bootstrap-lto/profiledbootstrap broken by r216566
Date: Thu, 23 Oct 2014 17:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on target_milestone everconfirmed
Message-ID: <bug-63632-4-QQ4SAhwBvr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63632-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63632-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01882.txt.bz2
Content-length: 728
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc632
Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-10-23
Target Milestone|--- |4.9.2
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
gcc passes -fno-lto to the linker. And the linker doesn't understand it:
ld: -f may not be used without -shared.
(or gold)
ld: fatal error: -f/--auxiliary may not be used without -shared
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (6 preceding siblings ...)
2014-10-23 17:17 ` marxin at gcc dot gnu.org
@ 2014-10-23 21:09 ` mliska at suse dot cz
2014-10-24 8:50 ` rguenther at suse dot de
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mliska at suse dot cz @ 2014-10-23 21:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #9 from Martin Liška <mliska at suse dot cz> ---
On 10/20/2014 09:48 AM, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>
> --- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Sun, 19 Oct 2014, mliska at suse dot cz wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>>
>> --- Comment #2 from Martin Liška <mliska at suse dot cz> ---
>> Following two functions are merged:
>> static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
>> boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
>> ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
>> LeftExprT = int; RightT = boost::log::attribute_actor<int,
>> boost::log::value_extractor, void, boost::actor>; ValueT = int;
>> boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
>> boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
>> boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
>>
>>
>> static boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type
>> boost::log::make_output_actor<ActorT<LeftExprT>, RightT,
>> ValueT>::make(ActorT<LeftExprT>, RightT&) [with ActorT = boost::actor;
>> LeftExprT = int; RightT = boost::log::attribute_actor<{anonymous}::my_class,
>> boost::log::value_extractor, void, boost::actor>; ValueT = int;
>> boost::log::make_output_actor<ActorT<LeftExprT>, RightT, ValueT>::type =
>> boost::actor<boost::log::attribute_output_terminal<boost::actor<int>,
>> boost::log::to_log_fun> >] (struct actor left, struct attribute_actor & right)
>>
>> with following body:
>> {
>> struct type D.3826;
>> struct to_log_fun D.3825;
>> struct attribute_name D.3824;
>> int SR.9;
>> struct actor left;
>>
>> <bb 2>:
>> left = left;
>> SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
>> MEM[(struct attribute_name *)&D.3824] = SR.9_4;
>> boost::log::attribute_output_terminal<boost::actor<int>,
>> boost::log::to_log_fun>::attribute_output_terminal<int> (&D.3826, left, D.3824,
>> D.3825, 0);
>> D.3826 ={v} {CLOBBER};
>> return;
>>
>> }
>>
>>
>>
>> As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
>> template arguments: attribute_actor<int,...> vs.
>> attribute_actor<{anonymous}::my_class,...>.
>> What do you think Richard about these record_types from alias set perspective:
>>
>> (gdb) p debug_tree(t1)
>> <mem_ref 0x7ffff6ab4000
>> type <integer_type 0x7ffff6c33690 int public type_6 SI
>> size <integer_cst 0x7ffff6c51048 constant 32>
>> unit size <integer_cst 0x7ffff6c51060 constant 4>
>> align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
>> 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
>> 2147483647>
>> pointer_to_this <pointer_type 0x7ffff6c55738>>
>>
>> arg 0 <ssa_name 0x7ffff6aae678
>> type <reference_type 0x7ffff6e20d20 type <record_type 0x7ffff6de7dc8
>> attribute_actor>
>> unsigned DI
>> size <integer_cst 0x7ffff6c2fdf8 constant 64>
>> unit size <integer_cst 0x7ffff6c2fe10 constant 8>
>> align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20d20>
>> visited var <parm_decl 0x7ffff6e1eb00 right>def_stmt GIMPLE_NOP
>>
>> version 2
>> ptr-info 0x7ffff6a7e3d8>
>> arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
>> constant 0>>
>> $1 = void
>> (gdb) p debug_tree(t2)
>> <mem_ref 0x7ffff6aa1ac8
>> type <integer_type 0x7ffff6c33690 int public type_6 SI
>> size <integer_cst 0x7ffff6c51048 constant 32>
>> unit size <integer_cst 0x7ffff6c51060 constant 4>
>> align 32 symtab 0 alias set 4 canonical type 0x7ffff6c33690 precision
>> 32 min <integer_cst 0x7ffff6c51000 -2147483648> max <integer_cst 0x7ffff6c51018
>> 2147483647>
>> pointer_to_this <pointer_type 0x7ffff6c55738>>
>>
>> arg 0 <ssa_name 0x7ffff6a77dc8
>> type <reference_type 0x7ffff6e20540 type <record_type 0x7ffff6ddd888
>> attribute_actor>
>> unsigned DI
>> size <integer_cst 0x7ffff6c2fdf8 constant 64>
>> unit size <integer_cst 0x7ffff6c2fe10 constant 8>
>> align 64 symtab 0 alias set 7 canonical type 0x7ffff6e20540>
>> visited var <parm_decl 0x7ffff6e1ea00 right>def_stmt GIMPLE_NOP
>>
>> version 2
>> ptr-info 0x7ffff6a7e300>
>> arg 1 <integer_cst 0x7ffff6a4ee28 type <pointer_type 0x7ffff6dbfa80>
>> constant 0>>
>>
>> these types are called for alias_set comparison, with following record_types:
>> (gdb) p debug_tree((tree_node*)0x7ffff6de7dc8)
>> <record_type 0x7ffff6de7dc8 attribute_actor needs-constructing type_5 type_6
>> SI
>> size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
>> bitsizetype> constant 32>
>> unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
>> sizetype> constant 4>
>> align 32 symtab 0 alias set 17 canonical type 0x7ffff6de7dc8
>> fields <field_decl 0x7ffff6de4ed8 D.2798
>> type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
>> SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
>> 4>
>> align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
>> <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
>> boost>
>> full-name "struct boost::actor<boost::log::attribute_terminal>"
>> needs-constructor X() X(constX&) this=(X&) n_parents=0
>> use_template=1 interface-unknown
>> pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
>> <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
>> ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
>> 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
>> align 32 offset_align 128
>> offset <integer_cst 0x7ffff6c2fe28 constant 0>
>> bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
>> 0x7ffff6de7dc8 attribute_actor>
>> chain <type_decl 0x7ffff6de4da8 attribute_actor type <record_type
>> 0x7ffff6de80a8 attribute_actor>
>> external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
>> line 168 col 1
>> align 8 context <record_type 0x7ffff6de7dc8 attribute_actor> result
>> <record_type 0x7ffff6de7dc8 attribute_actor>
>> chain <type_decl 0x7ffff6de4e40 value_type>>> context
>> <namespace_decl 0x7ffff6dbec78 log>
>> full-name "class boost::log::attribute_actor<int,
>> boost::log::value_extractor, void, boost::actor>"
>> needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
>> interface-unknown
>> pointer_to_this <pointer_type 0x7ffff6de81f8> reference_to_this
>> <reference_type 0x7ffff6e20d20> chain <type_decl 0x7ffff6de4d10
>> attribute_actor>>
>> $3 = void
>> (gdb) p debug_tree((tree_node*)0x7ffff6ddd888)
>> <record_type 0x7ffff6ddd888 attribute_actor needs-constructing type_5 type_6
>> SI
>> size <integer_cst 0x7ffff6c51048 type <integer_type 0x7ffff6c33150
>> bitsizetype> constant 32>
>> unit size <integer_cst 0x7ffff6c51060 type <integer_type 0x7ffff6c330a8
>> sizetype> constant 4>
>> align 32 symtab 0 alias set 14 canonical type 0x7ffff6ddd888
>> fields <field_decl 0x7ffff6de0b48 D.2756
>> type <record_type 0x7ffff6dddb28 actor needs-constructing type_5 type_6
>> SI size <integer_cst 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060
>> 4>
>> align 32 symtab 0 alias set 15 canonical type 0x7ffff6dddb28 fields
>> <field_decl 0x7ffff6de01c8 proto_expr_> context <namespace_decl 0x7ffff6d8d2f8
>> boost>
>> full-name "struct boost::actor<boost::log::attribute_terminal>"
>> needs-constructor X() X(constX&) this=(X&) n_parents=0
>> use_template=1 interface-unknown
>> pointer_to_this <pointer_type 0x7ffff6e03930> reference_to_this
>> <reference_type 0x7ffff6dff0a8> chain <type_decl 0x7ffff6de0098 actor>>
>> ignored decl_6 SI file ../../PR33754.c line 167 col 7 size <integer_cst
>> 0x7ffff6c51048 32> unit size <integer_cst 0x7ffff6c51060 4>
>> align 32 offset_align 128
>> offset <integer_cst 0x7ffff6c2fe28 constant 0>
>> bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context <record_type
>> 0x7ffff6ddd888 attribute_actor>
>> chain <type_decl 0x7ffff6de0a18 attribute_actor type <record_type
>> 0x7ffff6de12a0 attribute_actor>
>> external nonlocal suppress-debug decl_4 VOID file ../../PR33754.c
>> line 168 col 1
>> align 8 context <record_type 0x7ffff6ddd888 attribute_actor> result
>> <record_type 0x7ffff6ddd888 attribute_actor>
>> chain <type_decl 0x7ffff6de0ab0 value_type>>> context
>> <namespace_decl 0x7ffff6dbec78 log>
>> full-name "class boost::log::attribute_actor<{anonymous}::my_class,
>> boost::log::value_extractor, void, boost::actor>"
>> needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=1
>> interface-unknown
>> pointer_to_this <pointer_type 0x7ffff6de13f0> reference_to_this
>> <reference_type 0x7ffff6e20540> chain <type_decl 0x7ffff6dd2ed8
>> attribute_actor>>
>>
>> If the alias sets can be considered to be equal, we must face some latent bug
>> in inliner?
> Maybe. Btw, I see some issues in func_checker::compare_operand with
> regard to it doing redundant checks:
>
> if (!func_checker::compatible_types_p (TREE_TYPE (x1), TREE_TYPE
> (x2)))
> return return_false ();
>
> Redundant with the following
>
> if (!compare_operand (x1, x2))
> return return_false_with_msg ("");
>
> ...
>
> if (get_alias_set (TREE_TYPE (y1)) != get_alias_set (TREE_TYPE
> (y2)))
> return return_false_with_msg ("alias set for MEM_REF offsets are
> different");
>
> Redundant with the following
>
> ao_ref r1, r2;
> ao_ref_init (&r1, t1);
> ao_ref_init (&r2, t2);
> if (ao_ref_alias_set (&r1) != ao_ref_alias_set (&r2)
> || ao_ref_base_alias_set (&r1) != ao_ref_base_alias_set (&r2))
> return return_false_with_msg ("ao alias sets are different");
>
>
> /* Type of the offset on MEM_REF does not matter. */
> return wi::to_offset (y1) == wi::to_offset (y2);
>
> Use tree_int_cst_equal (y1, y2).
>
> case COMPONENT_REF:
> {
> x1 = TREE_OPERAND (t1, 0);
> x2 = TREE_OPERAND (t2, 0);
> y1 = TREE_OPERAND (t1, 1);
> y2 = TREE_OPERAND (t2, 1);
>
> ret = compare_operand (x1, x2)
> && compare_operand (y1, y2);
>
> comparing FIELD_DECLs like you do looks dangerous to me (and it looks
> redundant with the get_addr_base_and_unit_offset you do - which btw
> also defeats the ao_ref alias checks as you effectively drop the
> get_alias_set () compare).
>
> IMHO folding memory access comparison and general operand comparison
> into one function makes it very much less clear what is going on...
>
> So - can you please split this into the general compare_operand
> and a compare_memory_access function?
Hello.
I come up with first version of transformation (ipa-icf-gimple.c
attachment).
I would like to ask which TREE_CODE reside in the newly create function.
MEM_REF must be there
to introduce a single place where alias_set comparison will be called.
I'm wondering about get_addr_base_and_unit_offset, for which group of
operations should I call it?
If you remember a patch where I added support for volatility check,
should it be really
placed to compare_memory_access, or would be efficient handling in
gimple_call/assign check
function?
Thank you,
Martin
>
>From gcc-bugs-return-464876-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 23 21:09:10 2014
Return-Path: <gcc-bugs-return-464876-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20980 invoked by alias); 23 Oct 2014 21:09:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20947 invoked by uid 48); 23 Oct 2014 21:09:05 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63619] warning:=?UTF-8?Q? deleting ‘void*’ is undefined has no -W flag?Date: Thu, 23 Oct 2014 21:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-63619-4-FCtK6MSdFM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63619-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63619-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01897.txt.bz2
Content-length: 486
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc619
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |5.0
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (7 preceding siblings ...)
2014-10-23 21:09 ` mliska at suse dot cz
@ 2014-10-24 8:50 ` rguenther at suse dot de
2014-10-24 10:38 ` mliska at suse dot cz
2015-03-23 10:05 ` yroux at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: rguenther at suse dot de @ 2014-10-24 8:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>
> --- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
> I added assert to cgraphunit.c (expand_thunk):1547:
>
> /* Build call to the function being thunked. */
> if (!VOID_TYPE_P (restype))
> {
> if (DECL_BY_REFERENCE (resdecl))
> restmp = gimple_fold_indirect_ref (resdecl);
> else if (!is_gimple_reg_type (restype))
> {
> restmp = resdecl;
> gcc_assert (TREE_CODE (restmp) == VAR_DECL);
> add_local_decl (cfun, restmp);
> BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
> }
> else
> restmp = create_tmp_reg (restype, "retval");
> }
>
> It's triggered quite often, one example of a thunk created by IPA ICF:
Well, the bug is the add_local_decl being called with a RESULT_DECL.
Thus you should try placing an assert into add_local_decl instead
(need to move it out-of-line for that).
> std::basic_streambuf<_CharT, _Traits>::pos_type std::basic_streambuf<_CharT,
> _Traits>::seekpos(std::basic_streambuf<_CharT, _Traits>::pos_type,
> std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>;
> std::basic_streambuf<_CharT, _Traits>::pos_type = std::fpos<__mbstate_t>;
> std::ios_base::openmode = std::_Ios_Openmode] (struct basic_streambuf * const
> this, struct pos_type D.23077, openmode D.23078)
> {
> struct pos_type <retval>;
>
> <bb 2>:
> <retval> = std::basic_streambuf<wchar_t>::seekpos (this_2(D), D.23077,
> _3(D)); [tail call]
> return <retval>;
>
> }
>
> where std::basic_streambuf<_CharT, _Traits>::pos_type is:
> <result_decl 0x7ffff4eec708 D.39821
> type <record_type 0x7ffff59c2150 pos_type sizes-gimplified asm_written used
> needs-constructing type_1 type_5 TI
> size <integer_cst 0x7ffff6c2fe40 constant 128>
> unit size <integer_cst 0x7ffff6c2fe58 constant 16>
> align 64 symtab -164402368 alias set -1 canonical type 0x7ffff614adc8
> fields <field_decl 0x7ffff51cd850 _M_off type <integer_type
> 0x7ffff678c738 streamoff>
> used private nonlocal decl_3 DI file
> /home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/postypes.h
> line 115 col 33
> size <integer_cst 0x7ffff6c2fdf8 constant 64>
> unit size <integer_cst 0x7ffff6c2fe10 constant 8>
> align 64 offset_align 128
> offset <integer_cst 0x7ffff6c2fe28 constant 0>
> bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context
> <record_type 0x7ffff614adc8 fpos> chain <field_decl 0x7ffff51cd8e8 _M_state>>
> context <namespace_decl 0x7ffff6c4c098 std>
> full-name "std::basic_streambuf<char>::pos_type"
> needs-constructor X() has-type-conversion X(constX&) this=(X&)
> n_parents=0 use_template=1 interface-unknown
> pointer_to_this <pointer_type 0x7ffff5224e70> chain <type_decl
> 0x7ffff6146da8 fpos>>
> ignored TI file
> /home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/streambuf
> line 602 col 7 size <integer_cst 0x7ffff6c2fe40 128> unit size <integer_cst
> 0x7ffff6c2fe58 16>
> align 64 context <function_decl 0x7ffff5797948 seekoff>>
>
> Is there a bug in expand_thunk or do I miss something?
> Thanks,
> Martin
>
>
>From gcc-bugs-return-464894-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 08:50:31 2014
Return-Path: <gcc-bugs-return-464894-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18630 invoked by alias); 24 Oct 2014 08:50:30 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18598 invoked by uid 48); 24 Oct 2014 08:50:27 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63636] [5 Regression] gcc gets miscompiled during LTO/PGO bootstrap on ppc64
Date: Fri, 24 Oct 2014 09:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: target_milestone
Message-ID: <bug-63636-4-oZuOHYTWM1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63636-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63636-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01915.txt.bz2
Content-length: 292
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc636
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |5.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (8 preceding siblings ...)
2014-10-24 8:50 ` rguenther at suse dot de
@ 2014-10-24 10:38 ` mliska at suse dot cz
2015-03-23 10:05 ` yroux at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: mliska at suse dot cz @ 2014-10-24 10:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #12 from Martin Liška <mliska at suse dot cz> ---
On 10/24/2014 10:44 AM, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>
> --- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>>
>> --- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
>> I added assert to cgraphunit.c (expand_thunk):1547:
>>
>> /* Build call to the function being thunked. */
>> if (!VOID_TYPE_P (restype))
>> {
>> if (DECL_BY_REFERENCE (resdecl))
>> restmp = gimple_fold_indirect_ref (resdecl);
>> else if (!is_gimple_reg_type (restype))
>> {
>> restmp = resdecl;
>> gcc_assert (TREE_CODE (restmp) == VAR_DECL);
>> add_local_decl (cfun, restmp);
>> BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
>> }
>> else
>> restmp = create_tmp_reg (restype, "retval");
>> }
>>
>> It's triggered quite often, one example of a thunk created by IPA ICF:
>
> Well, the bug is the add_local_decl being called with a RESULT_DECL.
> Thus you should try placing an assert into add_local_decl instead
> (need to move it out-of-line for that).
You are right, it would be good to place assert to add_local_decl function,
attachment contains suggested patch
that I will regtest.
Problematic is that one would like to place assert to function.h, but gengtype
does not include tree.h
for gencondmd.c:
In file included from build/gencondmd.c:5:0:
../../gcc/function.h: In function ‘void add_local_decl(function*, tree)’:
../../gcc/function.h:674:27: error: ‘TREE_CODE’ was not declared in this scope
gcc_assert (TREE_CODE (d) == VAR_DECL);
Is it acceptable to put the implementation to function.c?
Thanks,
Martin
>
>> std::basic_streambuf<_CharT, _Traits>::pos_type std::basic_streambuf<_CharT,
>> _Traits>::seekpos(std::basic_streambuf<_CharT, _Traits>::pos_type,
>> std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>;
>> std::basic_streambuf<_CharT, _Traits>::pos_type = std::fpos<__mbstate_t>;
>> std::ios_base::openmode = std::_Ios_Openmode] (struct basic_streambuf * const
>> this, struct pos_type D.23077, openmode D.23078)
>> {
>> struct pos_type <retval>;
>>
>> <bb 2>:
>> <retval> = std::basic_streambuf<wchar_t>::seekpos (this_2(D), D.23077,
>> _3(D)); [tail call]
>> return <retval>;
>>
>> }
>>
>> where std::basic_streambuf<_CharT, _Traits>::pos_type is:
>> <result_decl 0x7ffff4eec708 D.39821
>> type <record_type 0x7ffff59c2150 pos_type sizes-gimplified asm_written used
>> needs-constructing type_1 type_5 TI
>> size <integer_cst 0x7ffff6c2fe40 constant 128>
>> unit size <integer_cst 0x7ffff6c2fe58 constant 16>
>> align 64 symtab -164402368 alias set -1 canonical type 0x7ffff614adc8
>> fields <field_decl 0x7ffff51cd850 _M_off type <integer_type
>> 0x7ffff678c738 streamoff>
>> used private nonlocal decl_3 DI file
>> /home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/postypes.h
>> line 115 col 33
>> size <integer_cst 0x7ffff6c2fdf8 constant 64>
>> unit size <integer_cst 0x7ffff6c2fe10 constant 8>
>> align 64 offset_align 128
>> offset <integer_cst 0x7ffff6c2fe28 constant 0>
>> bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context
>> <record_type 0x7ffff614adc8 fpos> chain <field_decl 0x7ffff51cd8e8 _M_state>>
>> context <namespace_decl 0x7ffff6c4c098 std>
>> full-name "std::basic_streambuf<char>::pos_type"
>> needs-constructor X() has-type-conversion X(constX&) this=(X&)
>> n_parents=0 use_template=1 interface-unknown
>> pointer_to_this <pointer_type 0x7ffff5224e70> chain <type_decl
>> 0x7ffff6146da8 fpos>>
>> ignored TI file
>> /home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/streambuf
>> line 602 col 7 size <integer_cst 0x7ffff6c2fe40 128> unit size <integer_cst
>> 0x7ffff6c2fe58 16>
>> align 64 context <function_decl 0x7ffff5797948 seekoff>>
>>
>> Is there a bug in expand_thunk or do I miss something?
>> Thanks,
>> Martin
>>
>>
>
>From gcc-bugs-return-464910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:38:01 2014
Return-Path: <gcc-bugs-return-464910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9660 invoked by alias); 24 Oct 2014 10:38:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9331 invoked by uid 55); 24 Oct 2014 10:37:57 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
Date: Fri, 24 Oct 2014 10:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63587-4-qMLN7SFsSg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01931.txt.bz2
Content-length: 2323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 24 Oct 2014, mliska at suse dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
>
> --- Comment #12 from Martin Liška <mliska at suse dot cz> ---
> On 10/24/2014 10:44 AM, rguenther at suse dot de wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
> >
> > --- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
> > On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
> >
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
> >>
> >> --- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
> >> I added assert to cgraphunit.c (expand_thunk):1547:
> >>
> >> /* Build call to the function being thunked. */
> >> if (!VOID_TYPE_P (restype))
> >> {
> >> if (DECL_BY_REFERENCE (resdecl))
> >> restmp = gimple_fold_indirect_ref (resdecl);
> >> else if (!is_gimple_reg_type (restype))
> >> {
> >> restmp = resdecl;
> >> gcc_assert (TREE_CODE (restmp) == VAR_DECL);
> >> add_local_decl (cfun, restmp);
> >> BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
> >> }
> >> else
> >> restmp = create_tmp_reg (restype, "retval");
> >> }
> >>
> >> It's triggered quite often, one example of a thunk created by IPA ICF:
> >
> > Well, the bug is the add_local_decl being called with a RESULT_DECL.
> > Thus you should try placing an assert into add_local_decl instead
> > (need to move it out-of-line for that).
>
> You are right, it would be good to place assert to add_local_decl function,
> attachment contains suggested patch
> that I will regtest.
>
> Problematic is that one would like to place assert to function.h, but gengtype
> does not include tree.h
> for gencondmd.c:
>
> In file included from build/gencondmd.c:5:0:
> ../../gcc/function.h: In function ‘void add_local_decl(function*, tree)’:
> ../../gcc/function.h:674:27: error: ‘TREE_CODE’ was not declared in this scope
> gcc_assert (TREE_CODE (d) == VAR_DECL);
>
> Is it acceptable to put the implementation to function.c?
Yes.
Richard.
>From gcc-bugs-return-464911-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:39:00 2014
Return-Path: <gcc-bugs-return-464911-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12353 invoked by alias); 24 Oct 2014 10:39:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12323 invoked by uid 48); 24 Oct 2014 10:38:56 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 10:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60304-4-PP4IpGDrgg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01932.txt.bz2
Content-length: 825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #5)
> Well, of course the user can always explicitly include, eg, <cstdbool>, thus
> it seems that the real underlying issue is that the system-headers machinery
> should not be fooled by things like this in a system header... or should it?
> The define is rather interesting...
>
> #define false false
>
> I'm adding in CC Dodji too...
In the case of NULL we do:
source_location loc =
expansion_point_location_if_in_system_header (input_location);
however, we do not do it in the case of 'false' (because we do not think it
should be a macro, but it actually is). Perhaps we should do it, is there a
downside to it?
>From gcc-bugs-return-464912-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:45:08 2014
Return-Path: <gcc-bugs-return-464912-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20126 invoked by alias); 24 Oct 2014 10:45:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20087 invoked by uid 48); 24 Oct 2014 10:45:04 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 10:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60304-4-CWM3jEPBjN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01933.txt.bz2
Content-length: 1098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #9)
> (In reply to Paolo Carlini from comment #5)
> > Well, of course the user can always explicitly include, eg, <cstdbool>, thus
> > it seems that the real underlying issue is that the system-headers machinery
> > should not be fooled by things like this in a system header... or should it?
> > The define is rather interesting...
> >
> > #define false false
> >
> > I'm adding in CC Dodji too...
>
> In the case of NULL we do:
>
> source_location loc =
> expansion_point_location_if_in_system_header (input_location);
>
> however, we do not do it in the case of 'false' (because we do not think it
> should be a macro, but it actually is). Perhaps we should do it, is there a
> downside to it?
BTW, this is the guideline I was asking for here:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01783.html
In this case, 'false' is one of those special macros.
>From gcc-bugs-return-464913-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:53:46 2014
Return-Path: <gcc-bugs-return-464913-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31503 invoked by alias); 24 Oct 2014 10:53:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31434 invoked by uid 55); 24 Oct 2014 10:53:42 -0000
From: "fyang at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63173] performance problem with simd intrinsics vld2_dup_* on aarch64-none-elf
Date: Fri, 24 Oct 2014 11:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fyang at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: fei.yang0953 at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63173-4-uGEBZPKRIz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63173-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63173-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01934.txt.bz2
Content-length: 2352
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc173
--- Comment #8 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Fri Oct 24 10:53:08 2014
New Revision: 216630
URL: https://gcc.gnu.org/viewcvs?rev!6630&root=gcc&view=rev
Log:
PR target/63173
* config/aarch64/arm_neon.h (__LD2R_FUNC): Remove macro.
(__LD3R_FUNC): Ditto.
(__LD4R_FUNC): Ditto.
(vld2_dup_s8, vld2_dup_s16, vld2_dup_s32, vld2_dup_f32, vld2_dup_f64,
vld2_dup_u8, vld2_dup_u16, vld2_dup_u32, vld2_dup_p8, vld2_dup_p16
vld2_dup_s64, vld2_dup_u64, vld2q_dup_s8, vld2q_dup_p8,
vld2q_dup_s16, vld2q_dup_p16, vld2q_dup_s32, vld2q_dup_s64,
vld2q_dup_u8, vld2q_dup_u16, vld2q_dup_u32, vld2q_dup_u64
vld2q_dup_f32, vld2q_dup_f64): Rewrite using builtin functions.
(vld3_dup_s64, vld3_dup_u64, vld3_dup_f64, vld3_dup_s8
vld3_dup_p8, vld3_dup_s16, vld3_dup_p16, vld3_dup_s32
vld3_dup_u8, vld3_dup_u16, vld3_dup_u32, vld3_dup_f32
vld3q_dup_s8, vld3q_dup_p8, vld3q_dup_s16, vld3q_dup_p16
vld3q_dup_s32, vld3q_dup_s64, vld3q_dup_u8, vld3q_dup_u16
vld3q_dup_u32, vld3q_dup_u64, vld3q_dup_f32, vld3q_dup_f64): Likewise.
(vld4_dup_s64, vld4_dup_u64, vld4_dup_f64, vld4_dup_s8
vld4_dup_p8, vld4_dup_s16, vld4_dup_p16, vld4_dup_s32
vld4_dup_u8, vld4_dup_u16, vld4_dup_u32, vld4_dup_f32
vld4q_dup_s8, vld4q_dup_p8, vld4q_dup_s16, vld4q_dup_p16
vld4q_dup_s32, vld4q_dup_s64, vld4q_dup_u8, vld4q_dup_u16
vld4q_dup_u32, vld4q_dup_u64, vld4q_dup_f32, vld4q_dup_f64): Likewise.
* config/aarch64/aarch64.md (define_c_enum "unspec"): Add
UNSPEC_LD2_DUP, UNSPEC_LD3_DUP, UNSPEC_LD4_DUP.
* config/aarch64/aarch64-simd-builtins.def (ld2r, ld3r, ld4r): New
builtins.
* config/aarch64/aarch64-simd.md (aarch64_simd_ld2r<mode>): New
pattern.
(aarch64_simd_ld3r<mode>): Likewise.
(aarch64_simd_ld4r<mode>): Likewise.
(aarch64_ld2r<mode>): New expand.
(aarch64_ld3r<mode>): Likewise.
(aarch64_ld4r<mode>): Likewise.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-simd-builtins.def
trunk/gcc/config/aarch64/aarch64-simd.md
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/config/aarch64/arm_neon.h
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
` (9 preceding siblings ...)
2014-10-24 10:38 ` mliska at suse dot cz
@ 2015-03-23 10:05 ` yroux at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: yroux at gcc dot gnu.org @ 2015-03-23 10:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #16 from Yvan Roux <yroux at gcc dot gnu.org> ---
Author: yroux
Date: Mon Mar 23 09:50:33 2015
New Revision: 221589
URL: https://gcc.gnu.org/viewcvs?rev=221589&root=gcc&view=rev
Log:
gcc/
2015-03-23 Yvan Roux <yvan.roux@linaro.org>
Backport from trunk r216841.
2014-10-29 Martin Liska <mliska@suse.cz>
PR ipa/63587
* cgraphunit.c (cgraph_node::expand_thunk): Only VAR_DECLs are put to local
declarations.
* function.c (add_local_decl): Implementation moved from header file,
assert
introduced for tree type.
* function.h: Likewise.
gcc/testsuite/
2015-03-23 Yvan Roux <yvan.roux@linaro.org>
Backport from trunk r216841.
2014-10-29 Martin Liska <mliska@suse.cz>
PR ipa/63587
* g++.dg/ipa/pr63587-1.C: New test.
* g++.dg/ipa/pr63587-2.C: New test.
Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr63587-1.C
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr63587-2.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cgraphunit.c
branches/gcc-4_9-branch/gcc/function.c
branches/gcc-4_9-branch/gcc/function.h
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-03-23 9:51 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-18 11:44 [Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112 trippels at gcc dot gnu.org
2014-10-19 21:31 ` [Bug ipa/63587] " mliska at suse dot cz
2014-10-20 6:49 ` trippels at gcc dot gnu.org
2014-10-20 7:54 ` rguenther at suse dot de
2014-10-20 12:53 ` rguenth at gcc dot gnu.org
2014-10-23 13:14 ` marxin at gcc dot gnu.org
2014-10-23 13:22 ` rguenther at suse dot de
2014-10-23 17:17 ` marxin at gcc dot gnu.org
2014-10-23 21:09 ` mliska at suse dot cz
2014-10-24 8:50 ` rguenther at suse dot de
2014-10-24 10:38 ` mliska at suse dot cz
2015-03-23 10:05 ` yroux at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).