Re: [PATCH 2/2] arm: Improve handling of relocations with small offsets with -mpure-code on v6m (PR96770)
On Tue, 27 Oct 2020 at 17:22, Richard Earnshaw
wrote:
>
> On 28/09/2020 10:09, Christophe Lyon via Gcc-patches wrote:
> > With -mpure-code on v6m (thumb-1), we can use small offsets with
> > upper/lower relocations to avoid the extra addition of the
> > offset.
> >
> > This patch accepts expressions symbol+offset as legitimate constants
> > when the literal pool is disabled, making sure that the offset is
> > within the range supported by thumb-1 [0..255].
> >
> > It also makes sure that thumb1_movsi_insn emits an error in case we
> > try to use it with an unsupported RTL construct.
> >
> > 2020-09-28 Christophe Lyon
> >
> > gcc/
> > * config/arm/arm.c (thumb_legitimate_constant_p): Accept
> > (symbol_ref + addend) when literal pool is disabled.
> > (arm_valid_symbolic_address_p): Add support for thumb-1 without
> > MOVT/MOVW.
> > * config/arm/thumb1.md (*thumb1_movsi_insn): Accept (symbol_ref +
> > addend) in the pure-code alternative.
> >
> > gcc/testsuite/
> > * gcc.target/arm/pure-code/pr96770.c: New test.
> > ---
> > gcc/config/arm/arm.c | 15 ---
> > gcc/config/arm/thumb1.md | 5 +++--
> > gcc/testsuite/gcc.target/arm/pure-code/pr96770.c | 21 +
> > 3 files changed, 36 insertions(+), 5 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> >
> > diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> > index abe357e..ceeb91f 100644
> > --- a/gcc/config/arm/arm.c
> > +++ b/gcc/config/arm/arm.c
> > @@ -9489,7 +9489,8 @@ thumb_legitimate_constant_p (machine_mode mode
> > ATTRIBUTE_UNUSED, rtx x)
> >we build the symbol address with upper/lower
> >relocations. */
> > || (TARGET_THUMB1
> > - && GET_CODE (x) == SYMBOL_REF
> > + && !label_mentioned_p (x)
> > + && arm_valid_symbolic_address_p (x)
> > && arm_disable_literal_pool)
> > || flag_pic);
> > }
> > @@ -31495,7 +31496,10 @@ arm_emit_coreregs_64bit_shift (enum rtx_code code,
> > rtx out, rtx in,
> > According to the ARM ELF ABI, the initial addend of REL-type relocations
> > processing MOVW and MOVT instructions is formed by interpreting the
> > 16-bit
> > literal field of the instruction as a 16-bit signed value in the range
> > - -32768 <= A < 32768. */
> > + -32768 <= A < 32768.
> > +
> > + In Thumb-1 mode, we use upper/lower relocations which have an 8-bit
> > + unsigned range of 0 <= A < 256. */
>
> I think it should be made clear that the range comes from the AAELF32
> relocation encoding for REL-type relocations (which is an unsigned value
> in this case).
>
> Otherwise, OK.
>
Thanks Richard, I've just pushed the patch with updated comment &
commit message.
Christophe
> >
> > bool
> > arm_valid_symbolic_address_p (rtx addr)
> > @@ -31519,7 +31523,12 @@ arm_valid_symbolic_address_p (rtx addr)
> >xop1 = XEXP (tmp, 1);
> >
> >if (GET_CODE (xop0) == SYMBOL_REF && CONST_INT_P (xop1))
> > - return IN_RANGE (INTVAL (xop1), -0x8000, 0x7fff);
> > + {
> > + if (TARGET_THUMB1 && !TARGET_HAVE_MOVT)
> > + return IN_RANGE (INTVAL (xop1), 0, 0xff);
> > + else
> > + return IN_RANGE (INTVAL (xop1), -0x8000, 0x7fff);
> > + }
> > }
> >
> >return false;
> > diff --git a/gcc/config/arm/thumb1.md b/gcc/config/arm/thumb1.md
> > index 3dedcae..2258a52 100644
> > --- a/gcc/config/arm/thumb1.md
> > +++ b/gcc/config/arm/thumb1.md
> > @@ -675,7 +675,7 @@ (define_insn "*thumb1_movsi_insn"
> >case 7:
> >/* pure-code alternative: build the constant byte by byte,
> >instead of loading it from a constant pool. */
> > - if (GET_CODE (operands[1]) == SYMBOL_REF)
> > + if (arm_valid_symbolic_address_p (operands[1]))
> > {
> > output_asm_insn (\"movs\\t%0, #:upper8_15:%1\", operands);
> > output_asm_insn (\"lsls\\t%0, #8\", operands);
> > @@ -686,7 +686,7 @@ (define_insn "*thumb1_movsi_insn"
> > output_asm_insn (\"adds\\t%0, #:lower0_7:%1\", operands);
> > return \"\";
> > }
> > - else
> > + else if (GET_CODE (operands[1]) == CONST_INT)
> > {
> > int i;
> > HOST_WIDE_INT op1 = INTVAL (operands[1]);
> > @@ -721,6 +721,7 @@ (define_insn "*thumb1_movsi_insn"
> > output_asm_insn ("adds\t%0, %1", ops);
> > return "";
> > }
> > + gcc_unreachable ();
> >
> >case 8: return "ldr\t%0, %1";
> >case 9: return "str\t%1, %0";
> > diff --git a/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> > b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> > new file mode 100644
> > index 000..a43d71f
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> > @@ -0,0 +1,21 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-mpure-code" } */
> > +
>
Re: ipa-cp: New debug counters for IPA-CP
On Fri, Oct 30, 2020 at 7:59 PM Martin Jambor wrote:
>
> Hi,
>
> Martin Liška has been asking me to add debug counters to the IPA-CP pass so
> that testcase reductions are easier. The pass already has one for the bit
> value propagation, so this patch adds one for value_range propagation
> and one for the actual constant propagation.
>
> Passed bootstrap and testing on x86_64-linux. OK for trunk?
OK
> Thanks,
>
> Martin
>
>
> gcc/ChangeLog:
>
> 2020-10-30 Martin Jambor
>
> * dbgcnt.def (ipa_cp_values): New counter.
> (ipa_cp_vr): Likewise.
> * ipa-cp.c (decide_about_value): Check and bump ipa_cp_values debug
> counter.
> (decide_whether_version_node): Likewise.
> (ipcp_store_vr_results):Check and bump ipa_cp_vr debug counter.
> ---
> gcc/dbgcnt.def | 2 ++
> gcc/ipa-cp.c | 12 +++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
> index 07946a85ecc..a5b6bb66a6c 100644
> --- a/gcc/dbgcnt.def
> +++ b/gcc/dbgcnt.def
> @@ -171,6 +171,8 @@ DEBUG_COUNTER (if_after_reload)
> DEBUG_COUNTER (if_conversion)
> DEBUG_COUNTER (if_conversion_tree)
> DEBUG_COUNTER (ipa_cp_bits)
> +DEBUG_COUNTER (ipa_cp_values)
> +DEBUG_COUNTER (ipa_cp_vr)
> DEBUG_COUNTER (ipa_mod_ref)
> DEBUG_COUNTER (ipa_sra_params)
> DEBUG_COUNTER (ipa_sra_retvalues)
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index f981366a345..9895548fc35 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -5462,6 +5462,9 @@ decide_about_value (struct cgraph_node *node, int
> index, HOST_WIDE_INT offset,
> _count))
> return false;
>
> + if (!dbg_cnt (ipa_cp_values))
> +return false;
> +
>if (dump_file && (dump_flags & TDF_DETAILS))
> {
>fprintf (dump_file, " - considering value ");
> @@ -5577,6 +5580,12 @@ decide_whether_version_node (struct cgraph_node *node)
>
>if (info->do_clone_for_all_contexts)
> {
> + if (!dbg_cnt (ipa_cp_values))
> + {
> + info->do_clone_for_all_contexts = false;
> + return ret;
> + }
> +
>struct cgraph_node *clone;
>vec callers = node->collect_callers ();
>
> @@ -5864,7 +5873,8 @@ ipcp_store_vr_results (void)
> ipa_vr vr;
>
> if (!plats->m_value_range.bottom_p ()
> - && !plats->m_value_range.top_p ())
> + && !plats->m_value_range.top_p ()
> + && dbg_cnt (ipa_cp_vr))
> {
> vr.known = true;
> vr.type = plats->m_value_range.m_vr.kind ();
> --
> 2.28.0
>
Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.
On Fri, Oct 30, 2020 at 1:00 AM Richard Sandiford wrote: > > I guess my main objection is that we have a special memory constraint > that isn't in fact matching a MEM (at least not directly). That seems > odd and feels like it's going to come back to bite us. > > From an RTL perspective, the MEM in the bcst_memory_operand isn't that > special. It's really just a normal memory that happens to appear in a > VEC_DUPLICATE. > > With the MIPS thing, the SIGN_EXTEND was around a register rather > than a memory, and the register constraints applied to the register > as normal. In other words, the SIGN_EXTEND was not part of the > constraint: target-independent code removed the SIGN_EXTEND Yes, that's because target-independent code can't distinguish whether SIGN_EXTEND is part of constraints. More specifically, constrain_operands will swallow the unary operator when matching constraints. Cut from recog.c - /* A unary operator may be accepted by the predicate, but it is irrelevant for matching constraints. */ /* For special_memory_operand, there could be a memory operand inside, and it would cause a mismatch for constraint_satisfied_p. */ if (UNARY_P (op) && op == extract_mem_from_operand (op)) op = XEXP (op, 0); -- But a unary operator with memory would never be accepted by the predicate unless it's corresponding to special_memory_constraint, because in IRA/LRA, CT_MEMORY would never be matched when op is false for MEM_P. > before matching against the constraints. > > I think we could view the bcst_mem_operand case in a similar way. > The constraint process ends up having two steps: an extraction > step (for the REG inside a SIGN_EXTEND for MIPS, for the MEM > inside a VEC_DUPLICATE for AVX512) and the normal matching step on > the result. This could either happen on a constraint-by-constraint > basis or (perhaps more efficiently) as a separate step before > applying the constraints. Not sure off-hand which is better, > would need to think more about it. > > But I think this extraction process should be described directly in the > .md file somehow. I've had a few ideas but I'm not happy enough with > any of them yet to post. > > Thanks, > Richard -- BR, Hongtao
Re: Avoid char[] array in tree_def
On October 31, 2020 11:35:01 PM GMT+01:00, Jan Hubicka wrote:
>> On 10/29/20 1:40 PM, Richard Biener wrote:
>> > On Thu, 29 Oct 2020, Jakub Jelinek wrote:
>> >
>> > > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
>> > > > >
>> > > > > That's ugly and will for sure defeat warning / access code
>> > > > > when we access this as char[], no? I mean, we could
>> > > > > as well use 'int str[1];' here?
>> > > >
>> > > > Well, we always get char pointer via macro that is IMO OK, but
>I am also
>> > > > not very much in love with this.
>> > >
>> > > Do we treat signed char [...]; as typeless storage too, or just
>> > > what the C++ standard requires (i.e. char, unsigned char and
>std::byte
>> > > where the last one is enum type with unsigned char underlying
>type)?
>> >
>> > All that is covered by is_byte_access_type which includes all
>> > character types (including char16_t and wchar it seems) and
>std::byte.
>>
>> Well, that's a bug, apparently from the PR94923 patch (r11-499);
>previously
>> it was char, signed char, and unsigned char. And even that is too
>much;
>> even C++98 said just char and unsigned char could be used for
>bytewise
>> access.
>>
>> When C++17 clarified this with the notion of "provides storage", it
>applied
>> to only unsigned char and std::byte, not even the full set of
>byte-access
>> types. We still need to allow bytewise access using plain char, but
>perhaps
>> we don't need to treat plain char arrays as typeless.
>>
>> Attributes to say that a particular array does or does not provide
>storage
>> for objects of other types do sound useful.
>
>Thanks a lot for explanation!
>I am adding Martin Sebor to CC. Perhaps you can fix the problem with
>std::byte, and signed char to imply typeless storage and ideally also
>add an attribute? This seem too deep into C++ FE details for me.
>
>I was thiking a bit more about all accesses to trees getting same alias
>set. This is because we allow type puning through unions. If our tree
>datastructure was a C++ class hiearchy, this would not happen since
>accesses to specialized tree node would not be through unions but
>through casted pointers.
>
>We could do that with our acessor macros, too.
>I tried to turn (NODE)->base in our accesors to ((tree_base
>*)(node))->base
>and this breaks with const_tree pointers. However the following seem to
>work and get better TBAA.
>
>I think converting other acessors should be quite easy and make our
>predicates more easy to optimize.
>
>What do you think?
Can you adjust TREE_SET_CODE to assert the corresponding tree struct doesn't
change? Otherwise sure - this would be a good change. Can we avoid the online
function though? It'll make -O0 debugging even more awkward...
Richard.
>Honza
>
>diff --git a/gcc/tree.h b/gcc/tree.h
>index 7f0aa5b8d1d..cd8146808f7 100644
>--- a/gcc/tree.h
>+++ b/gcc/tree.h
>@@ -235,13 +235,24 @@ as_internal_fn (combined_fn code)
>
> #define NULL_TREE (tree) NULL
>
>+inline tree_base *
>+as_a_tree_base (tree t)
>+{
>+ return (tree_base *)t;
>+}
>+inline const tree_base *
>+as_a_tree_base (const_tree t)
>+{
>+ return (const tree_base *)t;
>+}
>+
> /* Define accessors for the fields that all tree nodes have
>(though some fields are not used for all kinds of nodes). */
>
> /* The tree-code says what kind of node it is.
>Codes are defined in tree.def. */
>-#define TREE_CODE(NODE) ((enum tree_code) (NODE)->base.code)
>-#define TREE_SET_CODE(NODE, VALUE) ((NODE)->base.code = (VALUE))
>+#define TREE_CODE(NODE) ((enum tree_code) (as_a_tree_base
>(NODE)->code))
>+#define TREE_SET_CODE(NODE, VALUE) (as_a_tree_base (NODE)->code =
>(VALUE))
>
> /* When checking is enabled, errors will be generated if a tree node
>is accessed incorrectly. The macros die with a fatal error. */
>@@ -642,7 +653,7 @@ extern void omp_clause_range_check_failed
>(const_tree, const char *, int,
>In IDENTIFIER_NODEs, this means that some extern decl for this name
>had its address taken. That matters for inline functions.
>In a STMT_EXPR, it means we want the result of the enclosed expression.
> */
>-#define TREE_ADDRESSABLE(NODE) ((NODE)->base.addressable_flag)
>+#define TREE_ADDRESSABLE(NODE) (as_a_tree_base
>(NODE)->addressable_flag)
>
>/* Set on a CALL_EXPR if the call is in a tail position, ie. just
>before the
>exit of a function. Calls for which this is true are candidates for
>tail
>@@ -670,7 +681,7 @@ extern void omp_clause_range_check_failed
>(const_tree, const char *, int,
> /* In a VAR_DECL, nonzero means allocate static storage.
>In a FUNCTION_DECL, nonzero if function has been defined.
>In a CONSTRUCTOR, nonzero means allocate static storage. */
>-#define TREE_STATIC(NODE) ((NODE)->base.static_flag)
>+#define TREE_STATIC(NODE) (as_a_tree_base (NODE)->static_flag)
>
> /* In an ADDR_EXPR, nonzero means do not use a trampoline. */
>#define TREE_NO_TRAMPOLINE(NODE) (ADDR_EXPR_CHECK
>(NODE)->base.static_flag)
>@@ -701,7 +712,7 @@ extern
Re: [patch] Fixing ppc64 test failure after patch dealing with scratches in IRA
On 2020-10-30 7:36 p.m., Segher Boessenkool wrote:
Thanks for the patch! But it has a problem:
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 67e4f2fd037..78de85ccbbb 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -3717,7 +3717,7 @@
(vec_select:
(match_operand:VSX_EXTRACT_I 1 "gpc_reg_operand" ",v")
(parallel [(match_operand:QI 2 "const_int_operand" "n,n")])))
- (clobber (match_scratch: 3 "=,"))
+ (clobber (match_scratch: 3 "=*,&*r"))
(clobber (match_scratch:SI 4 "=X,"))]
"VECTOR_MEM_VSX_P (mode) && TARGET_VEXTRACTUB"
"#"
You add * to both alternatives here? I would expect adding it to only
the second alternative, does it work better with both?
No. It works the same. When the both alternatives use the hint, the
scratch pseudo got the class ALL_REGS. When only the 2nd use the hint,
the class is VSX_REGS. As I understand now the preferable alternative
is the 1st one (with for the scratch). In this case using the
hint only for the 2nd alternative has more sense.
That also avoids a different problem: * won't work as expected.
'*' in IRA skips one constraint character, but can be "wa", a
two-letter constraint (and we do have an "a" constraint as well,
something wholly different: "wa" means a VSX register, while "a" is an
indexed address).
case '*':
/* Ignore the next letter for this pass. */
c = *++p;
break;
I see. Thanks for pointing this out. Definitely it is better to use the
hint only for the second alternative ("&*r") then. Is this solution ok
for you?
Re: [PATCH] mixing of labels and code in C2X
Am Montag, den 14.09.2020, 20:30 + schrieb Joseph Myers:
> On Sun, 13 Sep 2020, Uecker, Martin wrote:
>
> > Hi Joseph,
> >
> > here is the (unfinished) patch to support
> > mixing of labels in C2X.
>
> I think there should be explicit tests for old standard versions
> (c11-labels-1.c etc.) that these usages are errors with -pedantic-errors
> with the old -std option, are warnings with -pedantic, and are quietly
> accepted with neither. In addition to using -pedantic-errors with the new
> standard version test to confirm it's not diagnosed, and a test with the
> new version and -Wc11-c2x-compat.
>
> By way of example of further places that I think need changing in the
> patch: at present, c_parser_label gives an error (that you correctly
> change to a pedwarn_c11) if the label is followed by a declaration - and
> then parses the declaration itself rather than leaving it to be parsed in
> the caller. So c_parser_compound_statement_nostart would parse a label
> followed by a declaration, and at that point last_label would be set to
> true, meaning that a second declaration would be rejected, when in C2x it
> should be accepted. You can see this even without the patch with a test
> such as:
>
> void
> f (void)
> {
> label : int a; int b;
> }
>
> I think that instead c_parser_label should never try to parse a
> declaration following the label; that should be left for the caller to
> handle. To avoid c_parser_label needing to return information about
> standard attributes on a following declaration, maybe it shouldn't parse
> standard attributes either (note that means that c_parser_all_labels would
> need to handle parsing and warning about and discarding standard
> attributes after each label instead - such attributes might be ones on a
> statement, or ones on the next label in a sequence of labels).
>
> Then of course the checks of last_label in
> c_parser_compound_statement_nostart would need to become checks for
> whether to pedwarn_c11 about the use of a label in a given context, once
> the code knows whether there is a declaration, rather than preventing
> parsing a declaration there at all. So probably c_parser_label would no
> longer have the pedwarn_c11 either; that would all be left to its callers.
ok, here is a new revision of the patch. Still needs some
polish...
I also made the attributes not be ignored for labels.
Or should I separate this out?
There is a new warning for the case of GNU-style
attributes between a label and a declaration. It
now applies to the label.
Best,
Martin
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index b921c4e3852..aa039db087b 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1521,7 +1521,7 @@ static void c_parser_initval (c_parser *, struct c_expr *,
struct obstack *);
static tree c_parser_compound_statement (c_parser *, location_t * = NULL);
static location_t c_parser_compound_statement_nostart (c_parser *);
-static void c_parser_label (c_parser *);
+static void c_parser_label (c_parser *, tree);
static void c_parser_statement (c_parser *, bool *, location_t * = NULL);
static void c_parser_statement_after_labels (c_parser *, bool *,
vec * = NULL);
@@ -5523,7 +5523,7 @@ c_parser_initval (c_parser *parser, struct c_expr *after,
}
/* Parse a compound statement (possibly a function body) (C90 6.6.2,
- C99 6.8.2, C11 6.8.2).
+ C99 6.8.2, C11 6.8.2, C2X 6.X.Y).
compound-statement:
{ block-item-list[opt] }
@@ -5674,7 +5674,7 @@ c_parser_compound_statement_nostart (c_parser *parser)
{
location_t loc = c_parser_peek_token (parser)->location;
loc = expansion_point_location_if_in_system_header (loc);
- /* Standard attributes may start a statement or a declaration. */
+ /* Standard attributes may start a label, statement or declaration. */
bool have_std_attrs
= c_parser_nth_token_starts_std_attributes (parser, 1);
tree std_attrs = NULL_TREE;
@@ -5685,7 +5685,6 @@ c_parser_compound_statement_nostart (c_parser *parser)
|| (c_parser_next_token_is (parser, CPP_NAME)
&& c_parser_peek_2nd_token (parser)->type == CPP_COLON))
{
- c_warn_unused_attributes (std_attrs);
if (c_parser_next_token_is_keyword (parser, RID_CASE))
label_loc = c_parser_peek_2nd_token (parser)->location;
else
@@ -5693,27 +5692,54 @@ c_parser_compound_statement_nostart (c_parser *parser)
last_label = true;
last_stmt = false;
mark_valid_location_for_stdc_pragma (false);
- c_parser_label (parser);
+ c_parser_label (parser, std_attrs);
+
+ /* Allow '__attribute__((fallthrough));'. */
+ if (c_parser_next_token_is_keyword (parser, RID_ATTRIBUTE))
+ {
+ location_t loc = c_parser_peek_token (parser)->location;
+ tree attrs =
[pushed] Darwin: Adjust the PCH area to allow for 16384byte page size.
Hi The new version of Darwin report pagesize 16384 which means that we need to adjust the aligment of the PCH area. tested across the Darwin range (32 and 64 bit hosts) and on x86_64-linux-gnu pushed to master thanks Iain gcc/ChangeLog: * config/host-darwin.c: Align pch_address_space to 16384. --- gcc/config/host-darwin.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gcc/config/host-darwin.c b/gcc/config/host-darwin.c index 0face6c450f..c862935dcf3 100644 --- a/gcc/config/host-darwin.c +++ b/gcc/config/host-darwin.c @@ -24,7 +24,10 @@ #include "config/host-darwin.h" /* Yes, this is really supposed to work. */ -static char pch_address_space[1024*1024*1024] __attribute__((aligned (4096))); +/* This allows for a pagesize of 16384, which we have on Darwin20, but should + continue to work OK for pagesize 4096 which we have on earlier versions. + The size is 1 (binary) Gb. */ +static char pch_address_space[65536*16384] __attribute__((aligned (16384))); /* Return the address of the PCH address space, if the PCH will fit in it. */ -- 2.24.1
[pushed] Objective-C : Implement SEL as a built-in typedef.
Hi The reference implementation for Objective-C provides the SEL typedef (although it is also available from ). tested on x86_64-darwin, x86_64-linux-gnu pushed thanks Iain gcc/objc/ChangeLog: * objc-act.c (synth_module_prologue): Get the SEL identifier. * objc-act.h (enum objc_tree_index): Add OCTI_SEL_NAME. (objc_selector_name): New. (SEL_TYPEDEF_NAME): New. * objc-gnu-runtime-abi-01.c (gnu_runtime_01_initialize): Initialize SEL typedef. * objc-next-runtime-abi-01.c (next_runtime_01_initialize): Likewise. * objc-next-runtime-abi-02.c gcc/testsuite/ChangeLog: * obj-c++.dg/SEL-typedef.mm: New test. * objc.dg/SEL-typedef.m: New test. --- gcc/objc/objc-act.c | 1 + gcc/objc/objc-act.h | 3 +++ gcc/objc/objc-gnu-runtime-abi-01.c | 7 +++ gcc/objc/objc-next-runtime-abi-01.c | 7 +++ gcc/objc/objc-next-runtime-abi-02.c | 7 +++ gcc/testsuite/obj-c++.dg/SEL-typedef.mm | 7 +++ gcc/testsuite/objc.dg/SEL-typedef.m | 7 +++ 7 files changed, 39 insertions(+) create mode 100644 gcc/testsuite/obj-c++.dg/SEL-typedef.mm create mode 100644 gcc/testsuite/objc.dg/SEL-typedef.m diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c index 31a2cf3753f..0393bc44500 100644 --- a/gcc/objc/objc-act.c +++ b/gcc/objc/objc-act.c @@ -2954,6 +2954,7 @@ synth_module_prologue (void) objc_object_name = get_identifier (OBJECT_TYPEDEF_NAME); objc_instancetype_name = get_identifier (INSTANCE_TYPEDEF_NAME); objc_class_name = get_identifier (CLASS_TYPEDEF_NAME); + objc_selector_name = get_identifier (SEL_TYPEDEF_NAME); /* Declare the 'id', 'instancetype' and 'Class' typedefs. */ type = lang_hooks.decls.pushdecl (build_decl (input_location, diff --git a/gcc/objc/objc-act.h b/gcc/objc/objc-act.h index 913e152fdeb..db71b6a265e 100644 --- a/gcc/objc/objc-act.h +++ b/gcc/objc/objc-act.h @@ -371,6 +371,7 @@ enum objc_tree_index OCTI_ID_NAME, OCTI_INSTANCETYPE_NAME, OCTI_CLASS_NAME, +OCTI_SEL_NAME, OCTI_CNST_STR_ID, OCTI_CNST_STR_TYPE, OCTI_CNST_STR_GLOB_ID, @@ -576,6 +577,7 @@ extern GTY(()) tree objc_global_trees[OCTI_MAX]; #define objc_object_nameobjc_global_trees[OCTI_ID_NAME] #define objc_instancetype_name objc_global_trees[OCTI_INSTANCETYPE_NAME] #define objc_class_nameobjc_global_trees[OCTI_CLASS_NAME] +#define objc_selector_name objc_global_trees[OCTI_SEL_NAME] /* Constant string classes. */ #define constant_string_id objc_global_trees[OCTI_CNST_STR_ID] @@ -614,6 +616,7 @@ extern GTY(()) tree objc_global_trees[OCTI_MAX]; #define OBJECT_TYPEDEF_NAME"id" #define INSTANCE_TYPEDEF_NAME "instancetype" #define CLASS_TYPEDEF_NAME "Class" +#define SEL_TYPEDEF_NAME "SEL" #define TAG_OBJECT "objc_object" #define TAG_CLASS "objc_class" diff --git a/gcc/objc/objc-gnu-runtime-abi-01.c b/gcc/objc/objc-gnu-runtime-abi-01.c index 25c0e01e157..ac9a8626f40 100644 --- a/gcc/objc/objc-gnu-runtime-abi-01.c +++ b/gcc/objc/objc-gnu-runtime-abi-01.c @@ -208,6 +208,13 @@ static void gnu_runtime_01_initialize (void) type = build_qualified_type (type, TYPE_QUAL_CONST); objc_selector_type = build_pointer_type (type); + /* SEL typedef. */ + type = lang_hooks.decls.pushdecl (build_decl (input_location, + TYPE_DECL, + objc_selector_name, + objc_selector_type)); + TREE_NO_WARNING (type) = 1; + /* typedef id (*IMP)(id, SEL, ...); */ ftype = build_varargs_function_type_list (objc_object_type, objc_object_type, diff --git a/gcc/objc/objc-next-runtime-abi-01.c b/gcc/objc/objc-next-runtime-abi-01.c index 233d89e75b5..7fc449bab41 100644 --- a/gcc/objc/objc-next-runtime-abi-01.c +++ b/gcc/objc/objc-next-runtime-abi-01.c @@ -277,6 +277,13 @@ static void next_runtime_01_initialize (void) objc_selector_type = build_pointer_type (xref_tag (RECORD_TYPE, get_identifier (TAG_SELECTOR))); + /* SEL typedef. */ + type = lang_hooks.decls.pushdecl (build_decl (input_location, + TYPE_DECL, + objc_selector_name, + objc_selector_type)); + TREE_NO_WARNING (type) = 1; + build_v1_class_template (); build_super_template (); build_v1_protocol_template (); diff --git a/gcc/objc/objc-next-runtime-abi-02.c b/gcc/objc/objc-next-runtime-abi-02.c index d7812ffc981..f3c285a937b 100644 --- a/gcc/objc/objc-next-runtime-abi-02.c +++ b/gcc/objc/objc-next-runtime-abi-02.c @@ -374,6 +374,13 @@ static void next_runtime_02_initialize (void) objc_selector_type
[pushed] Objective-C/C++ : Improve '@' keyword locations.
Hi When we are lexing tokens for Objective-C, we combine '@' tokens with a following keyword (when that keyword is a valid Objective-C one or, for Objective-C, one of the C++ keywords that can appear in this position). The responsibility is passed on to the parser to validate the resulting combination. The combination of tokens was being done without applying the rule to their locations - so that we get: @property ^ instead of what the user might expect: @property ^~~~ This patch combines the source range of the keyword with that of the '@' sign - which improves diagnostics (we now get the second rendering). tested on x86_64-darwin, x86_64-linux-gnu pushed thanks Iain --- gcc/c-family/ChangeLog: * c-lex.c (c_lex_with_flags): When combining '@' with a keyword for Objective-C, combine the location ranges too. --- gcc/c-family/c-lex.c | 4 1 file changed, 4 insertions(+) diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c index b1cef2345f4..e81e16ddc26 100644 --- a/gcc/c-family/c-lex.c +++ b/gcc/c-family/c-lex.c @@ -550,7 +550,11 @@ c_lex_with_flags (tree *value, location_t *loc, unsigned char *cpp_flags, returning a token of type CPP_AT_NAME and rid code RID_CLASS (not RID_AT_CLASS). The language parser needs to convert that to RID_AT_CLASS. +However, we've now spliced the '@' together with the +keyword that follows; Adjust the location so that we +get a source range covering the composite. */ +*loc = make_location (atloc, atloc, newloc); break; } /* FALLTHROUGH */ -- 2.24.1
[PATCH] Add missing gnu-versioned-namespace symbols
Several tests are failing because of those missing symbols.
I understand why we need to export symbols relying in the versioned
namespace but I don't understand why we need to do it for _GLIBCXX_DEBUG
symbols which are not version namespace dependant.
Do you want to backport the Debug symbol ?
libstdc++: Add mising gnu-versioned-namespace symbols
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu-versioned-namespace.ver:
Add __istream_extract and
_Safe_local_iterator_base::_M_attach_single
symbols.
Tested under Linux x86_64 versioned namespace.
Ok to commit ?
François
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index 0965854fbc3..3b6d7944d06 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -98,6 +98,9 @@ GLIBCXX_8.0 {
_ZNSt3__817__copy_streambufsI*;
_ZNSt3__821__copy_streambufs_eofI*;
+# std::__istream_extract(wistream&, wchar_t*, streamsize)
+_ZNSt3__817__istream_extractIwNS_11char_traitsIwvRNS_13basic_istreamIT_T0_EEPS4_[ilx];
+
# __gnu_cxx::__atomic_add
# __gnu_cxx::__exchange_and_add
_ZN9__gnu_cxx3__812__atomic_addEPV[il][il];
@@ -145,6 +148,7 @@ GLIBCXX_8.0 {
_ZN11__gnu_debug30_Safe_unordered_container_base13_M_detach_allEv;
_ZN11__gnu_debug25_Safe_local_iterator_base9_M_attachEPNS_19_Safe_sequence_baseEb;
_ZN11__gnu_debug25_Safe_local_iterator_base9_M_detachEv;
+_ZN11__gnu_debug25_Safe_local_iterator_base16_M_attach_singleEPNS_19_Safe_sequence_baseEb;
# parallel mode
_ZN14__gnu_parallel9_Settings3getEv;
Re: [PATCH] x86: Require MMX for __builtin_ia32_maskmovq
> Since "MASKMOVQ mm1, mm2" is an SSE instruction which requires MMX and > MMX/SSE ISAs are handled separately, make __builtin_ia32_maskmovq require > MMX instead of SSE. > > gcc/ > > PR target/97140 > * config/i386/i386-expand.c (ix86_expand_builtin): Require MMX > for __builtin_ia32_maskmovq. > > gcc/testsuite/ > > PR target/97140 > * gcc.target/i386/pr97140.c: New test. TBH, from your submission, it was not clear to me, what did you want to achieve with the patch. Replies to your own patches were kind of contradicting [1] and confuse the reader even more. It took me a good chunk of time to figure out what the patch does, the git comment was also of no use. I don't think a review should take that long for a simple one-liner. So, to save you and others from a year of futile pinging: Please send a clean submission of a patch, and clearly state that MASKMOVQ can't be easily emulated with SSE instructions, so it is emulated at the intrinsic level. The *builtin* that corresponds to MASKMOVQ instruction requires TARGET_MMX, otherwise MMX registers can't be instantiated ... etc, etc. All this while having in mind that __builtin_ia32_* builtins are not part of a published interface. And please Cc me on patches. [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554385.html Uros.
Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.
On 11/1/20 6:57 AM, Eduard-Mihai Burtescu wrote:
Reading the diff patch, the v0 changes look great. I wouldn't be too worried
about the "printable character" aspect, there are similar Unicode-related
issues elsewhere, e.g. the "non-control ASCII" comment in decode_legacy_escape
(I suppose we could make it also go through the "print a non-control ASCII
character or some escape sequence" logic you added, if you think that helps).
No, it's entirely fine with me! I just wasn't sure if the small
deviations in output were acceptable. It sounds like they are.
However, I'm not sure about the legacy changes. Or rather, the .llvm. one, it's
not really Rust-specific, it's only in the rustc-demangle crate for convenience,
but C++ code compiled with Clang could run into the same problem - ideally,
stripping that suffix could be done uniformly in cplus-dem.c, but I decided
against making that change myself, for now.
I'm especially not comfortable removing the fast path, since that was the
condition under which I was able to make Rust demangling be attempted first,
before C++, in order to implement the Rust legacy demangling standalone,
separately from C++ demangling, so that it could be together with the v0 one.
It should be possible to keep the fast path if stripping .llvm.* suffixes is
done before either Rust or C++ demangling is attempted, but even if that would
be nice to have, IMO it should be a separate patch and not block v0 demangling.
That makes sense. I've attached updated patches (again generating a diff
against both your original patch and trunk) without the changes to the
legacy code. I did preserve one small hunk regarding the unescaping of a
single '.' character in idents, as I believe that is just a
straightforward bug in the existing code.
I can test the patch and upload the dataset tomorrow, but if you want to get
something committed sooner (is there a deadline for the next release?), feel
free to land the v0 changes (snprintf + const values) without the legacy ones.
My understanding is that the GCC tree closes to new features on November
16 (for "GCC 11 Stage 3"), but I'm not sure whether that applies to
libiberty or whether this patch would be classified as a feature or a
bugfix.
I don't have commit rights (nor am I even a GCC developer). Just wanted
to tee things up for you and Ian this week. I'm very much looking
forward to the new demangling scheme and didn't want to be just another
+1 on the GitHub issue.
So certainly no time pressure from me. But perhaps someone from the GCC
side can confirm whether we are under a bit of time pressure here given
the GCC 11 release.
Cheers,
Nikhil
diff --git a/rust-demangle.c b/rust-demangle.c
index d604b3c..9cd8f99 100644
--- a/rust-demangle.c
+++ b/rust-demangle.c
@@ -143,6 +143,35 @@ parse_disambiguator (struct rust_demangler *rdm)
return parse_opt_integer_62 (rdm, 's');
}
+static size_t
+parse_hex_nibbles (struct rust_demangler *rdm, uint64_t *value)
+{
+ char c;
+ size_t hex_len;
+
+ hex_len = 0;
+ *value = 0;
+
+ while (!eat (rdm, '_'))
+{
+ *value <<= 4;
+
+ c = next (rdm);
+ if (ISDIGIT (c))
+*value |= c - '0';
+ else if (c >= 'a' && c <= 'f')
+*value |= 10 + (c - 'a');
+ else
+{
+ rdm->errored = 1;
+ return 0;
+}
+ hex_len++;
+}
+
+ return hex_len;
+}
+
struct rust_mangled_ident
{
/* ASCII part of the identifier. */
@@ -240,7 +269,7 @@ static void
print_uint64 (struct rust_demangler *rdm, uint64_t x)
{
char s[21];
- sprintf (s, "%" PRIu64, x);
+ snprintf (s, 21, "%" PRIu64, x);
PRINT (s);
}
@@ -248,7 +277,7 @@ static void
print_uint64_hex (struct rust_demangler *rdm, uint64_t x)
{
char s[17];
- sprintf (s, "%" PRIx64, x);
+ snprintf (s, 17, "%" PRIx64, x);
PRINT (s);
}
@@ -380,8 +409,7 @@ print_ident (struct rust_demangler *rdm, struct
rust_mangled_ident ident)
}
else
{
- /* "." becomes "-" */
- PRINT ("-");
+ PRINT (".");
len = 1;
}
}
@@ -591,6 +619,9 @@ static int demangle_path_maybe_open_generics (struct
rust_demangler *rdm);
static void demangle_dyn_trait (struct rust_demangler *rdm);
static void demangle_const (struct rust_demangler *rdm);
static void demangle_const_uint (struct rust_demangler *rdm);
+static void demangle_const_int (struct rust_demangler *rdm);
+static void demangle_const_bool (struct rust_demangler *rdm);
+static void demangle_const_char (struct rust_demangler *rdm);
/* Optionally enter a binder ('G') for late-bound lifetimes,
printing e.g. `for<'a, 'b> `, and make those lifetimes visible
@@ -1089,6 +1120,11 @@ demangle_const (struct rust_demangler *rdm)
ty_tag = next (rdm);
switch (ty_tag)
{
+/* Placeholder. */
+case 'p':
+ PRINT ("_");
+ return;
+
/* Unsigned integer
Re: [PATCH] ipa: Fix segmentation fault in function_summary::get(cgraph_node*) (PR 97660)
> Hi, > > PR 97660 occurs when cgraph_node::get returns NULL, and this NULL > cgraph_node is then passed to clone_info::get. As the original assert > prior to the regressing change in r11-4587 allowed for the cgraph_node > to be NULL, clone_info::get is now only called when cgraph_node::get > returns a nonnull value. > > Tested on x86_64-freebsd12.2 to confirm the bootstrap regression no > longer happens. OK for mainline? > > Regards > Iain > > --- > gcc/ChangeLog: > > PR ipa/97660 > * cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Don't call > clone_info::get when cgraph_node::get returns NULL. OK, thanks! Honza
[pushed] testsuite, X86 : Add target requires masm_intel to three tests.
Hi
These tests currently fail on targets without Intel assembler support.
Tested that they are now UNSUPPORTED on x86_64-darwin, which does not
have -masm=intel support.
pushed to master as trivial/obvious.
thanks
Iain
gcc/testsuite/ChangeLog:
* gcc.target/i386/amxbf16-asmintel-1.c: Require masm_intel.
* gcc.target/i386/amxint8-asmintel-1.c: Likewise.
* gcc.target/i386/amxtile-asmintel-1.c: Likewise.
---
gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c | 1 +
gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c | 1 +
gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c
b/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c
index c2d6074387a..54194e1c5b0 100644
--- a/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c
+++ b/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c
@@ -1,4 +1,5 @@
/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-require-effective-target masm_intel } */
/* { dg-options "-O2 -mamx-bf16 -masm=intel" } */
/* { dg-final { scan-assembler "tdpbf16ps\[
\\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3" } } */
#include
diff --git a/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c
b/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c
index bcfbb3fa5ed..f8c376ae6c4 100644
--- a/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c
+++ b/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c
@@ -1,4 +1,5 @@
/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-require-effective-target masm_intel } */
/* { dg-options "-O2 -mamx-int8 -masm=intel" } */
/* { dg-final { scan-assembler "tdpbssd\[
\\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3" } } */
/* { dg-final { scan-assembler "tdpbsud\[
\\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3" } } *
diff --git a/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c
b/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c
index 88ef612ed14..6c08fec516c 100644
--- a/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c
+++ b/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c
@@ -1,4 +1,5 @@
/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-require-effective-target masm_intel } */
/* { dg-options "-O2 -mamx-tile -masm=intel " } */
/* { dg-final { scan-assembler "ldtilecfg\[ \\t]" } } */
/* { dg-final { scan-assembler "sttilecfg\[ \\t]" } } */
--
2.24.1
[PATCH] ipa: Fix segmentation fault in function_summary::get(cgraph_node*) (PR 97660)
Hi,
PR 97660 occurs when cgraph_node::get returns NULL, and this NULL
cgraph_node is then passed to clone_info::get. As the original assert
prior to the regressing change in r11-4587 allowed for the cgraph_node
to be NULL, clone_info::get is now only called when cgraph_node::get
returns a nonnull value.
Tested on x86_64-freebsd12.2 to confirm the bootstrap regression no
longer happens. OK for mainline?
Regards
Iain
---
gcc/ChangeLog:
PR ipa/97660
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Don't call
clone_info::get when cgraph_node::get returns NULL.
---
gcc/cgraph.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 9f3a7284310..36bdb009bf8 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1491,9 +1491,11 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge
*e)
}
if (flag_checking && decl)
{
- cgraph_node *node = cgraph_node::get (decl);
- clone_info *info = clone_info::get (node);
- gcc_assert (!node || !info || !info->param_adjustments);
+ if (cgraph_node *node = cgraph_node::get (decl))
+ {
+ clone_info *info = clone_info::get (node);
+ gcc_assert (!info || !info->param_adjustments);
+ }
}
clone_info *callee_info = clone_info::get (e->callee);
--
2.27.0
Re: Move clone_info to summary
On Sat, Oct 31, 2020 at 2:22 AM Jan Hubicka wrote:
>
> Hi,
> this patch moves clone_info to summary.
> Bootstrapped/regtested x86_64-linux, comitted.
>
> Honza
>
> 2020-10-31 Jan Hubicka
>
> * Makefile.in: (OBJS): Add symtab-clones.o
> (GTFILES): Add symtab-clones.h
> * cgraph.c: Include symtab-clones.h.
> (cgraph_edge::resolve_speculation): Fix formating
> (cgraph_edge::redirect_call_stmt_to_callee): Update.
> (cgraph_update_edges_for_call_stmt): Update
> (release_function_body): Fix formating.
> (cgraph_node::remove): Fix formating.
> (cgraph_node::dump): Fix formating.
> (cgraph_node::get_availability): Fix formating.
> (cgraph_node::call_for_symbol_thunks_and_aliases): Fix formating.
> (set_const_flag_1): Fix formating.
> (set_pure_flag_1): Fix formating.
> (cgraph_node::can_remove_if_no_direct_calls_p): Fix formating.
> (collect_callers_of_node_1): Fix formating.
> (clone_of_p): Update.
> (cgraph_node::verify_node): Update.
> (cgraph_c_finalize): Call clone_info::release ().
> * cgraph.h (struct cgraph_clone_info): Move to symtab-clones.h.
> (cgraph_node): Remove clone_info.
> (symbol_table): Add m_clones.
> * cgraphclones.c: Include symtab-clone.h.
> (duplicate_thunk_for_node): Update.
> (cgraph_node::create_clone): Update.
> (cgraph_node::create_virtual_clone): Update.
> (cgraph_node::find_replacement): Update.
> (cgraph_node::materialize_clone): Update.
> * gengtype.c (open_base_files): Include symtab-clones.h.
> * ipa-cp.c: Include symtab-clones.h.
> (initialize_node_lattices): Update.
> (want_remove_some_param_p): Update.
> (create_specialized_node): Update.
> * ipa-fnsummary.c: Include symtab-clones.h.
> (ipa_fn_summary_t::duplicate): Update.
> * ipa-modref.c: Include symtab-clones.h.
> (update_signature): Update.
> * ipa-param-manipulation.c: Include symtab-clones.h.
> (ipa_param_body_adjustments::common_initialization): Update.
> * ipa-prop.c: Include symtab-clones.h.
> (adjust_agg_replacement_values): Update.
> (ipcp_get_parm_bits): Update.
> (ipcp_update_bits): Update.
> (ipcp_update_vr): Update.
> * ipa-sra.c: Include symtab-clones.h.
> (process_isra_node_results): Update.
> (disable_unavailable_parameters): Update.
> * lto-cgraph.c: Include symtab-clone.h.
> (output_cgraph_opt_summary_p): Update.
> (output_node_opt_summary): Update.
> (input_node_opt_summary): Update.
> * symtab-clones.cc: New file.
> * symtab-clones.h: New file.
> * tree-inline.c (expand_call_inline): Update.
> (update_clone_info): Update.
> (tree_function_versioning): Update.
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 7fc03c8d946..7b94497b6f2 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1299,6 +1299,7 @@ OBJS = \
> cfgrtl.o \
> symtab.o \
> symtab-thunks.o \
> + symtab-clones.o \
> cgraph.o \
> cgraphbuild.o \
> cgraphunit.o \
> @@ -2594,6 +2595,7 @@ GTFILES = $(CPPLIB_H) $(srcdir)/input.h
> $(srcdir)/coretypes.h \
>$(srcdir)/output.h $(srcdir)/cfgloop.h $(srcdir)/cfg.h
> $(srcdir)/profile-count.h \
>$(srcdir)/cselib.h $(srcdir)/basic-block.h $(srcdir)/ipa-ref.h
> $(srcdir)/cgraph.h \
>$(srcdir)/symtab-thunks.h $(srcdir)/symtab-thunks.cc \
> + $(srcdir)/symtab-clones.h \
>$(srcdir)/reload.h $(srcdir)/caller-save.c $(srcdir)/symtab.c \
>$(srcdir)/alias.c $(srcdir)/bitmap.c $(srcdir)/cselib.c $(srcdir)/cgraph.c
> \
>$(srcdir)/ipa-prop.c $(srcdir)/ipa-cp.c $(srcdir)/ipa-utils.h \
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 9129bcf12d2..9f3a7284310 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -66,6 +66,7 @@ along with GCC; see the file COPYING3. If not see
> #include "ipa-inline.h"
> #include "tree-nested.h"
> #include "symtab-thunks.h"
> +#include "symtab-clones.h"
>
> /* FIXME: Only for PROP_loops, but cgraph shouldn't have to know about this.
> */
> #include "tree-pass.h"
> @@ -1236,7 +1237,7 @@ cgraph_edge::resolve_speculation (cgraph_edge *edge,
> tree callee_decl)
> {
>cgraph_edge *tmp = edge;
>if (dump_file)
> -fprintf (dump_file, "Speculative call turned into direct call.\n");
> + fprintf (dump_file, "Speculative call turned into direct call.\n");
>edge = e2;
>e2 = tmp;
>/* FIXME: If EDGE is inlined, we should scale up the frequencies
> @@ -1488,38 +1489,43 @@ cgraph_edge::redirect_call_stmt_to_callee
> (cgraph_edge *e)
> return e->call_stmt;
> }
> }
> -
>if (flag_checking && decl)
> {
>cgraph_node *node = cgraph_node::get (decl);
> -
Re: Move clone_info to summary
On Sat, Oct 31, 2020 at 2:22 AM Jan Hubicka wrote: > > Hi, > this patch moves clone_info to summary. > Bootstrapped/regtested x86_64-linux, comitted. > > Honza > > 2020-10-31 Jan Hubicka > > * Makefile.in: (OBJS): Add symtab-clones.o > (GTFILES): Add symtab-clones.h > * cgraph.c: Include symtab-clones.h. > (cgraph_edge::resolve_speculation): Fix formating > (cgraph_edge::redirect_call_stmt_to_callee): Update. > (cgraph_update_edges_for_call_stmt): Update > (release_function_body): Fix formating. > (cgraph_node::remove): Fix formating. > (cgraph_node::dump): Fix formating. > (cgraph_node::get_availability): Fix formating. > (cgraph_node::call_for_symbol_thunks_and_aliases): Fix formating. > (set_const_flag_1): Fix formating. > (set_pure_flag_1): Fix formating. > (cgraph_node::can_remove_if_no_direct_calls_p): Fix formating. > (collect_callers_of_node_1): Fix formating. > (clone_of_p): Update. > (cgraph_node::verify_node): Update. > (cgraph_c_finalize): Call clone_info::release (). > * cgraph.h (struct cgraph_clone_info): Move to symtab-clones.h. > (cgraph_node): Remove clone_info. > (symbol_table): Add m_clones. > * cgraphclones.c: Include symtab-clone.h. > (duplicate_thunk_for_node): Update. > (cgraph_node::create_clone): Update. > (cgraph_node::create_virtual_clone): Update. > (cgraph_node::find_replacement): Update. > (cgraph_node::materialize_clone): Update. > * gengtype.c (open_base_files): Include symtab-clones.h. > * ipa-cp.c: Include symtab-clones.h. > (initialize_node_lattices): Update. > (want_remove_some_param_p): Update. > (create_specialized_node): Update. > * ipa-fnsummary.c: Include symtab-clones.h. > (ipa_fn_summary_t::duplicate): Update. > * ipa-modref.c: Include symtab-clones.h. > (update_signature): Update. > * ipa-param-manipulation.c: Include symtab-clones.h. > (ipa_param_body_adjustments::common_initialization): Update. > * ipa-prop.c: Include symtab-clones.h. > (adjust_agg_replacement_values): Update. > (ipcp_get_parm_bits): Update. > (ipcp_update_bits): Update. > (ipcp_update_vr): Update. > * ipa-sra.c: Include symtab-clones.h. > (process_isra_node_results): Update. > (disable_unavailable_parameters): Update. > * lto-cgraph.c: Include symtab-clone.h. > (output_cgraph_opt_summary_p): Update. > (output_node_opt_summary): Update. > (input_node_opt_summary): Update. > * symtab-clones.cc: New file. > * symtab-clones.h: New file. > * tree-inline.c (expand_call_inline): Update. > (update_clone_info): Update. > (tree_function_versioning): Update. > This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97662 -- H.J.
Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.
Reading the diff patch, the v0 changes look great. I wouldn't be too worried
about the "printable character" aspect, there are similar Unicode-related
issues elsewhere, e.g. the "non-control ASCII" comment in decode_legacy_escape
(I suppose we could make it also go through the "print a non-control ASCII
character or some escape sequence" logic you added, if you think that helps).
However, I'm not sure about the legacy changes. Or rather, the .llvm. one, it's
not really Rust-specific, it's only in the rustc-demangle crate for convenience,
but C++ code compiled with Clang could run into the same problem - ideally,
stripping that suffix could be done uniformly in cplus-dem.c, but I decided
against making that change myself, for now.
I'm especially not comfortable removing the fast path, since that was the
condition under which I was able to make Rust demangling be attempted first,
before C++, in order to implement the Rust legacy demangling standalone,
separately from C++ demangling, so that it could be together with the v0 one.
It should be possible to keep the fast path if stripping .llvm.* suffixes is
done before either Rust or C++ demangling is attempted, but even if that would
be nice to have, IMO it should be a separate patch and not block v0 demangling.
As for the dataset, it doesn't include .llvm. because it's collected by rustc
itself, before LLVM had any chance to add any suffixes. This was done in order
to have several different mangling formats dumped at once for every symbol.
(It also contains symbols for e.g. functions that LLVM would've inlined away)
I can test the patch and upload the dataset tomorrow, but if you want to get
something committed sooner (is there a deadline for the next release?), feel
free to land the v0 changes (snprintf + const values) without the legacy ones.
Thanks,
- Eddy B.
On Sun, Nov 1, 2020, at 11:18, Nikhil Benesch wrote:
>
>
> On 10/29/20 12:16 AM, Nikhil Benesch wrote:
> > On Wed, Oct 28, 2020 at 7:53 PM Eduard-Mihai Burtescu
> > wrote:
> >> I agree that landing the extra changes later on top should be fine anyway,
> >> though when I make the sprintf -> snprintf change, I could provide the
> >> extra
> >> changes as well (either as a combined patch, or as a second tiny patch).
> >>
> >> Sadly I don't think I can get to either until next week, hope that's okay.
> >
> > I can make the sprintf -> snprintf change as early as tomorrow.
> >
> > I suspect I can also make the substantive const generics change, based
> > on the Rust implementation, though that's less of a promise.
>
> Attached is an updated patch with both of the aforementioned changes.
> The demangling of constants matches the demangling in rustc-demangle
> library as best as I could manage. The strategy of demangling constant
> chars via `format!("{:?}", char)` in Rust makes life hard for us in C,
> because there is no easy way to replicate Rust's debug formatting for
> chars. (Unless GCC has a Unicode library handy somewhere.)
>
> In the course of this work I noticed several inconsistencies in how
> rustc-demangle and libiberty were demangling some legacy Rust symbols. I
> fixed those and added test cases, though the fixes required removing
> some of the fast checks for whether a given symbol is a valid Rust symbol.
>
> For ease of review, eddyb, I also attached the diff from your last diff
> to mine. Since I don't have your collection of symbols I generated my
> own by running nm on the materialized binary from
> https://github.com/MaterializeInc/materialize.
>
> Let me know how I can help. I'm happy to address review feedback myself,
> or I'm happy to hand things back over to you, eddyb.
>
> Nikhil
>
> Attachments:
> * rust-demangle-diff.patch
> * rust-demangle.patch
Re: wchar_t does not satisfy std::integral concept on DJGPP MSDOS toolchains
On 01/11/20 10:03 +, Jonathan Wakely wrote:
On 31/10/20 22:21 +, sotrdg sotrdg via Libstdc++ wrote:
Please fix it.
It's determined by the result of the GLIBCXX_ENABLE_WCHAR_T checks in
libstdc++-v3/acinclude.m4
djgpp must be missing some wchar_t library support.
This patch makes some of the type traits work without libc support for
wchar_t. This is necessary for freestanding anyway, because we almost
certainly don't have etc. in freestanding, but the standard
still requires wchar_t to exist and be an integral type.
Tested powerpc64le-linux and (briefly) avr. For avr the value of
is_integral is now true, and make_signed/unsigned work for
wchar_t.
Pushed to trunk.
commit 29e418485848c4a6943d8561cd8fb0b1abf14015
Author: Jonathan Wakely
Date: Sun Nov 1 10:56:36 2020
libstdc++: Define type traits for wchar_t even when libc support missing
This meets the requirement that std::is_integral_v is true,
even when full library support for wchar_t via specializations of
char_traits etc. is not provided. This is done by checking
__WCHAR_TYPE__ to see if the compiler knows about the type, rather than
checking the library's own _GLIBCXX_USE_WCHAR_T autoconf macro.
This assumes that the C++ compiler correctly defines wchar_t as a
distinct type, not a typedef for one of the other integeral types. This
is always true for G++ and should be true for any supported non-GNU
compilers.
Similarly, the std::make_unsigned and std::make_signed traits and the
internal helpers std::__is_integer and std::__is_char are also changed
to depend on the same macro.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_integral)
(make_unsigned, make_signed): Define based
on #ifdef __WCHAR_TYPE__ instead of _GLIBCXX_USE_WCHAR_T.
* include/bits/cpp_type_traits.h (__is_integer)
(__is_char): Likewise.
diff --git a/libstdc++-v3/include/bits/cpp_type_traits.h b/libstdc++-v3/include/bits/cpp_type_traits.h
index b48d1adc63c9..433a2d7d35bc 100644
--- a/libstdc++-v3/include/bits/cpp_type_traits.h
+++ b/libstdc++-v3/include/bits/cpp_type_traits.h
@@ -162,7 +162,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typedef __true_type __type;
};
-# ifdef _GLIBCXX_USE_WCHAR_T
+# ifdef __WCHAR_TYPE__
template<>
struct __is_integer
{
@@ -363,7 +363,7 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
typedef __true_type __type;
};
-#ifdef _GLIBCXX_USE_WCHAR_T
+#ifdef __WCHAR_TYPE__
template<>
struct __is_char
{
diff --git a/libstdc++-v3/include/std/type_traits b/libstdc++-v3/include/std/type_traits
index e9a0f55dd4a8..34e068b59523 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -269,7 +269,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct __is_integral_helper
: public true_type { };
-#ifdef _GLIBCXX_USE_WCHAR_T
+ // We want is_integral to be true (and make_signed/unsigned to work)
+ // even when libc doesn't provide working and related functions,
+ // so check __WCHAR_TYPE__ instead of _GLIBCXX_USE_WCHAR_T.
+#ifdef __WCHAR_TYPE__
template<>
struct __is_integral_helper
: public true_type { };
@@ -1742,7 +1745,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// neither signed integer types nor unsigned integer types, so must be
// transformed to the unsigned integer type with the smallest rank.
// Use the partial specialization for enumeration types to do that.
-#if defined(_GLIBCXX_USE_WCHAR_T)
+#ifdef __WCHAR_TYPE__
template<>
struct __make_unsigned
{
@@ -1868,7 +1871,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// signed integer types nor unsigned integer types, so must be
// transformed to the signed integer type with the smallest rank.
// Use the partial specialization for enumeration types to do that.
-#if defined(_GLIBCXX_USE_WCHAR_T)
+#if defined(__WCHAR_TYPE__)
template<>
struct __make_signed
{
Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.
On 10/29/20 12:16 AM, Nikhil Benesch wrote:
On Wed, Oct 28, 2020 at 7:53 PM Eduard-Mihai Burtescu wrote:
I agree that landing the extra changes later on top should be fine anyway,
though when I make the sprintf -> snprintf change, I could provide the extra
changes as well (either as a combined patch, or as a second tiny patch).
Sadly I don't think I can get to either until next week, hope that's okay.
I can make the sprintf -> snprintf change as early as tomorrow.
I suspect I can also make the substantive const generics change, based
on the Rust implementation, though that's less of a promise.
Attached is an updated patch with both of the aforementioned changes.
The demangling of constants matches the demangling in rustc-demangle
library as best as I could manage. The strategy of demangling constant
chars via `format!("{:?}", char)` in Rust makes life hard for us in C,
because there is no easy way to replicate Rust's debug formatting for
chars. (Unless GCC has a Unicode library handy somewhere.)
In the course of this work I noticed several inconsistencies in how
rustc-demangle and libiberty were demangling some legacy Rust symbols. I
fixed those and added test cases, though the fixes required removing
some of the fast checks for whether a given symbol is a valid Rust symbol.
For ease of review, eddyb, I also attached the diff from your last diff
to mine. Since I don't have your collection of symbols I generated my
own by running nm on the materialized binary from
https://github.com/MaterializeInc/materialize.
Let me know how I can help. I'm happy to address review feedback myself,
or I'm happy to hand things back over to you, eddyb.
Nikhil
diff --git a/rust-demangle.c b/rust-demangle.c
index d604b3c..5c0a917 100644
--- a/rust-demangle.c
+++ b/rust-demangle.c
@@ -143,6 +143,35 @@ parse_disambiguator (struct rust_demangler *rdm)
return parse_opt_integer_62 (rdm, 's');
}
+static size_t
+parse_hex_nibbles (struct rust_demangler *rdm, uint64_t *value)
+{
+ char c;
+ size_t hex_len;
+
+ hex_len = 0;
+ *value = 0;
+
+ while (!eat (rdm, '_'))
+{
+ *value <<= 4;
+
+ c = next (rdm);
+ if (ISDIGIT (c))
+*value |= c - '0';
+ else if (c >= 'a' && c <= 'f')
+*value |= 10 + (c - 'a');
+ else
+{
+ rdm->errored = 1;
+ return 0;
+}
+ hex_len++;
+}
+
+ return hex_len;
+}
+
struct rust_mangled_ident
{
/* ASCII part of the identifier. */
@@ -240,7 +269,7 @@ static void
print_uint64 (struct rust_demangler *rdm, uint64_t x)
{
char s[21];
- sprintf (s, "%" PRIu64, x);
+ snprintf (s, 21, "%" PRIu64, x);
PRINT (s);
}
@@ -248,7 +277,7 @@ static void
print_uint64_hex (struct rust_demangler *rdm, uint64_t x)
{
char s[17];
- sprintf (s, "%" PRIx64, x);
+ snprintf (s, 17, "%" PRIx64, x);
PRINT (s);
}
@@ -380,8 +409,7 @@ print_ident (struct rust_demangler *rdm, struct
rust_mangled_ident ident)
}
else
{
- /* "." becomes "-" */
- PRINT ("-");
+ PRINT (".");
len = 1;
}
}
@@ -591,6 +619,9 @@ static int demangle_path_maybe_open_generics (struct
rust_demangler *rdm);
static void demangle_dyn_trait (struct rust_demangler *rdm);
static void demangle_const (struct rust_demangler *rdm);
static void demangle_const_uint (struct rust_demangler *rdm);
+static void demangle_const_int (struct rust_demangler *rdm);
+static void demangle_const_bool (struct rust_demangler *rdm);
+static void demangle_const_char (struct rust_demangler *rdm);
/* Optionally enter a binder ('G') for late-bound lifetimes,
printing e.g. `for<'a, 'b> `, and make those lifetimes visible
@@ -1089,6 +1120,11 @@ demangle_const (struct rust_demangler *rdm)
ty_tag = next (rdm);
switch (ty_tag)
{
+/* Placeholder. */
+case 'p':
+ PRINT ("_");
+ return;
+
/* Unsigned integer types. */
case 'h':
case 't':
@@ -1096,6 +1132,27 @@ demangle_const (struct rust_demangler *rdm)
case 'y':
case 'o':
case 'j':
+ demangle_const_uint (rdm);
+ break;
+
+/* Signed integer types. */
+case 'a':
+case 's':
+case 'l':
+case 'x':
+case 'n':
+case 'i':
+ demangle_const_int (rdm);
+ break;
+
+/* Boolean. */
+case 'b':
+ demangle_const_bool (rdm);
+ break;
+
+/* Character. */
+case 'c':
+ demangle_const_char (rdm);
break;
default:
@@ -1103,10 +1160,8 @@ demangle_const (struct rust_demangler *rdm)
return;
}
- if (eat (rdm, 'p'))
-PRINT ("_");
- else
-demangle_const_uint (rdm);
+ if (rdm->errored)
+return;
if (rdm->verbose)
{
@@ -1118,74 +1173,121 @@ demangle_const (struct rust_demangler *rdm)
static void
demangle_const_uint (struct rust_demangler *rdm)
{
- char c;
size_t hex_len;
uint64_t value;
