Re: [PATCH][stage 1] Fix bitmap registration of overheads.
On 2/26/19 7:48 PM, Richard Biener wrote:
> On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"
> wrote:
>> On 2/26/19 4:02 PM, Richard Biener wrote:
>>> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
Hi.
I've rewritten bitmap memory statistics which abused unsigned
type via register_overhead (map, -((int)sizeof (bitmap_head))).
I come up with a concept that each bitmap has assigned a unique ID
which is used for stats tracking. It's caused by fact that e.g. DF
>> is
heavily reallocating bitmaps that then have a different address.
Survives bootstrap with --enable-gather-detailed-mem-stats.
Ready for next stage1?
>>>
>>> + /* Get bitmap descriptor UID casted to an unsigned integer
>> pointer. */
>>> + unsigned *get_descriptor ()
>>> + {
>>> +return (unsigned *)(ptrdiff_t)alloc_descriptor;
>>> + }
>>>
>>> this one is a bit ugly and together with
>>
>> I know it's not perfect.
>>
>>>
>>> template
>>> inline hashval_t
>>> pointer_hash ::hash (const value_type &candidate)
>>> {
>>> /* This is a really poor hash function, but it is what the current
>> code uses,
>>> so I am reusing it to avoid an additional axis in testing. */
>>> return (hashval_t) ((intptr_t)candidate >> 3);
>>>
>>> will give quite some hash collisions. So I guess you should shift
>>> the descriptor << 3 at least (and then make it at most 29 bits in
>>> size?).
>>
>> That's easily doable.
>>
>>> Not sure what to do about the descriptor wrapping btw.
>>
>> Question is whether we want to invest in our internal scaffolding more
>> time?
>> Or can we live with the ugly casting?
>
> I guess we can live with it if we can avoid the hash collisions.
Great.
Then there's updated version of the patch for next stage1.
Martin
>
> Richard.
>
>> Martin
>>
>>>
>>> Richard.
>>>
Thanks,
Martin
gcc/ChangeLog:
2019-02-26 Martin Liska
* bitmap.c (bitmap_register): Come up with
alloc_descriptor_max_uid and assign it for
a new bitmap.
(register_overhead): Use get_descriptor as
a descriptor.
(release_overhead): New.
(bitmap_elem_to_freelist): Call it.
(bitmap_elt_clear_from): Likewise.
(bitmap_obstack_free): Likewise.
(bitmap_move): Sensitively release memory.
* bitmap.h (struct GTY): Add alloc_descriptor.
(bitmap_initialize): Initialize alloc_descriptor to zero.
* tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
---
gcc/bitmap.c | 39 ---
gcc/bitmap.h | 17 ++---
gcc/tree-ssa-pre.c | 2 +-
3 files changed, 43 insertions(+), 15 deletions(-)
>
>From 52615d17cc7f598855b647a70be5fafff9e56eba Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 19 Feb 2019 14:59:46 +0100
Subject: [PATCH] Fix bitmap registration of overheads.
gcc/ChangeLog:
2019-02-26 Martin Liska
* bitmap.c (bitmap_register): Come up with
alloc_descriptor_max_uid and assign it for
a new bitmap.
(register_overhead): Use get_descriptor as
a descriptor.
(release_overhead): New.
(bitmap_elem_to_freelist): Call it.
(bitmap_elt_clear_from): Likewise.
(bitmap_obstack_free): Likewise.
(bitmap_move): Sensitively release memory.
* bitmap.h (struct GTY): Add alloc_descriptor.
(bitmap_initialize): Initialize alloc_descriptor to zero.
* tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
---
gcc/bitmap.c | 39 ---
gcc/bitmap.h | 17 ++---
gcc/tree-ssa-pre.c | 2 +-
3 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/gcc/bitmap.c b/gcc/bitmap.c
index 5a8236de750..894aefa13de 100644
--- a/gcc/bitmap.c
+++ b/gcc/bitmap.c
@@ -36,18 +36,33 @@ static bitmap_element *bitmap_tree_listify_from (bitmap, bitmap_element *);
void
bitmap_register (bitmap b MEM_STAT_DECL)
{
- bitmap_mem_desc.register_descriptor (b, BITMAP_ORIGIN, false
- FINAL_PASS_MEM_STAT);
+ static unsigned alloc_descriptor_max_uid = 1;
+ gcc_assert (b->alloc_descriptor == 0);
+ b->alloc_descriptor = alloc_descriptor_max_uid++;
+
+ bitmap_mem_desc.register_descriptor (b->get_descriptor (), BITMAP_ORIGIN,
+ false FINAL_PASS_MEM_STAT);
}
/* Account the overhead. */
static void
register_overhead (bitmap b, size_t amount)
{
- if (bitmap_mem_desc.contains_descriptor_for_instance (b))
-bitmap_mem_desc.register_instance_overhead (amount, b);
+ unsigned *d = b->get_descriptor ();
+ if (bitmap_mem_desc.contains_descriptor_for_instance (d))
+bitmap_mem_desc.register_instance_overhead (amount, d);
+}
+
+/* Release the overhead. */
+static void
+release_overhead (bitmap b, size_t amount, bool remove_from_map)
+{
+ unsigned *d = b->get_descriptor ();
+ if (bitmap_mem_desc.contains_descriptor_for_instance (d))
+bitmap_mem_des
Re: [PATCH] Fix array size verification (PR c++/89507)
On Tue, 26 Feb 2019, Jakub Jelinek wrote:
> Hi!
>
> Seems valid_constant_size_p has been written with the expectation that only
> sizetype/ssizetype constants will be passed to it, otherwise it couldn't
> ever just blindly test tree_int_cst_sign_bit (size) for unsigned
> INTEGER_CSTs and complain cst_size_too_big.
> Unfortunately a recent patch started using this function even on other
> types, and the comment explicitly talk about it being done on
> pre-conversion to sizetype:
> /* The expression in a noptr-new-declarator is erroneous if it's of
> non-class type and its value before converting to std::size_t is
> less than zero. ... If the expression is a constant expression,
> the program is ill-fomed. */
> if (TREE_CODE (cst_nelts) == INTEGER_CST
> && !valid_array_size_p (input_location, cst_nelts, NULL_TREE,
> complain & tf_error))
> return error_mark_node;
> E.g. __int128 negative value could fit just fine after cast to sizetype,
> etc.
>
> So, instead of changing the C++ FE to only complain about negative cst_elts
> normally and fold_convert everything to sizetype before checking, this patch
> attempts to deal with non-{,s}sizetype constants. Negative (signed)
> constants are always rejected as before, newly constants that don't fit into
> uhwi are rejected after that check regardless of signedness and anything
> larger or equal than SIZE_MAX / 2 is also rejected as too big.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
> 2019-02-26 Jakub Jelinek
>
> PR c++/89507
> * tree.c (valid_constant_size_p): Deal with size INTEGER_CSTs
> with types other than sizetype/ssizetype.
>
> * g++.dg/other/new2.C: New test.
>
> --- gcc/tree.c.jj 2019-02-18 20:48:35.745681423 +0100
> +++ gcc/tree.c2019-02-26 18:22:23.760753681 +0100
> @@ -7533,19 +7533,16 @@ valid_constant_size_p (const_tree size,
>return false;
> }
>
> - tree type = TREE_TYPE (size);
> - if (TYPE_UNSIGNED (type))
> + if (tree_int_cst_sgn (size) < 0)
> {
> - if (!tree_fits_uhwi_p (size)
> - || tree_int_cst_sign_bit (size))
> - {
> - *perr = cst_size_too_big;
> - return false;
> - }
> + *perr = cst_size_negative;
> + return false;
> }
> - else if (tree_int_cst_sign_bit (size))
> + if (!tree_fits_uhwi_p (size)
> + || (wi::to_widest (TYPE_MAX_VALUE (sizetype))
> + < wi::to_widest (size) * 2))
> {
> - *perr = cst_size_negative;
> + *perr = cst_size_too_big;
>return false;
> }
>
> --- gcc/testsuite/g++.dg/other/new2.C.jj 2019-02-26 18:24:23.792785651
> +0100
> +++ gcc/testsuite/g++.dg/other/new2.C 2019-02-26 18:23:26.530724514 +0100
> @@ -0,0 +1,5 @@
> +// PR c++/89507
> +// { dg-do compile }
> +
> +unsigned char const n = 128;
> +int *p = new int[n]; // { dg-bogus "array exceeds maximum object size" }
>
> Jakub
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)
On Tue, 26 Feb 2019, Jakub Jelinek wrote:
> On Tue, Feb 26, 2019 at 05:18:17PM +0100, Jakub Jelinek wrote:
> > > > Shall I modify the patch for that?
> > >
> > > Might it even simplify the patch? If not the only comment on the
> > > original patch is that it would be nice to test it on a SJLJ EH
> > > target ...
> >
> > 1 file changed, 29 insertions(+), 16 deletions(-)
> > so not really simplify it, but not terrible either.
> >
> > Here is the incremental (untested) diff of what handles that.
> >
> > I don't have access to any standard SJLJ EH targets, but will try
> > --enable-sjlj-exceptions on x86_64-linux to see how far I get with that.
>
> Full updated patch that passed normal bootstrap/regtest on x86_64-linux and
> i686-linux.
>
> --enable-sjlj-exceptions bootstrap on x86_64-linux failed miserably,
> some entry-points are removed from libgcc_s.so in that case and
> make: relocation error: /lib64/libgc.so.1: symbol __gcc_personality_v0
> version GCC_3.3.1 not defined in file libgcc_s.so.1 with link time reference
> On the other side, even without SJLJ EH, the testsuite coverage is quite
> good, at least during development of the patch I made several mistakes and
> each time there were dozens to hundreds of failing tests in the testsuite,
> including __builtin_setjmp, non-local goto, etc.
>
> That said, if anybody is able to test this on some SJLJ setup, it would be
> greatly appreciated.
Patch is OK. I suppose auto-testers will pick up fallout and we
can always revert...
Richard.
> 2019-02-26 Jakub Jelinek
>
> PR tree-optimization/89280
> * tree-cfgcleanup.c (maybe_dead_abnormal_edge_p,
> builtin_setjmp_setup_bb): New functions.
> (cleanup_control_flow_pre): Ignore maybe_dead_abnormal_edge_p edges.
> When visiting __builtin_setjmp_setup block, queue in special
> setjmp_vec vector edges from .ABNORMAL_DISPATCHER to corresponding
> __builtin_setjmp_receiver. Remove .ABNORMAL_DISPATCHER basic blocks
> from visited after the loop if they don't have any visited successor
> blocks.
>
> * gcc.c-torture/compile/pr89280.c: New test.
> * gcc.dg/torture/pr57147-2.c: Don't expect a setjmp after noreturn
> function. Skip the test for -O0.
>
> --- gcc/tree-cfgcleanup.c.jj 2019-02-23 01:14:03.032266203 +0100
> +++ gcc/tree-cfgcleanup.c 2019-02-23 01:40:03.589681687 +0100
> @@ -723,6 +723,97 @@ cleanup_tree_cfg_bb (basic_block bb)
>return false;
> }
>
> +/* Return true if E is an EDGE_ABNORMAL edge for returns_twice calls,
> + i.e. one going from .ABNORMAL_DISPATCHER to basic block which doesn't
> + start with a forced or nonlocal label. Calls which return twice can
> return
> + the second time only if they are called normally the first time, so basic
> + blocks which can be only entered through these abnormal edges but not
> + normally are effectively unreachable as well. Additionally ignore
> + __builtin_setjmp_receiver starting blocks, which have one FORCED_LABEL
> + and which are always only reachable through EDGE_ABNORMAL edge. They are
> + handled in cleanup_control_flow_pre. */
> +
> +static bool
> +maybe_dead_abnormal_edge_p (edge e)
> +{
> + if ((e->flags & (EDGE_ABNORMAL | EDGE_EH)) != EDGE_ABNORMAL)
> +return false;
> +
> + gimple_stmt_iterator gsi = gsi_start_nondebug_after_labels_bb (e->src);
> + gimple *g = gsi_stmt (gsi);
> + if (!g || !gimple_call_internal_p (g, IFN_ABNORMAL_DISPATCHER))
> +return false;
> +
> + tree target = NULL_TREE;
> + for (gsi = gsi_start_bb (e->dest); !gsi_end_p (gsi); gsi_next (&gsi))
> +if (glabel *label_stmt = dyn_cast (gsi_stmt (gsi)))
> + {
> + tree this_target = gimple_label_label (label_stmt);
> + if (DECL_NONLOCAL (this_target))
> + return false;
> + if (FORCED_LABEL (this_target))
> + {
> + if (target)
> + return false;
> + target = this_target;
> + }
> + }
> +else
> + break;
> +
> + if (target)
> +{
> + /* If there was a single FORCED_LABEL, check for
> + __builtin_setjmp_receiver with address of that label. */
> + if (!gsi_end_p (gsi) && is_gimple_debug (gsi_stmt (gsi)))
> + gsi_next_nondebug (&gsi);
> + if (gsi_end_p (gsi))
> + return false;
> + if (!gimple_call_builtin_p (gsi_stmt (gsi), BUILT_IN_SETJMP_RECEIVER))
> + return false;
> +
> + tree arg = gimple_call_arg (gsi_stmt (gsi), 0);
> + if (TREE_CODE (arg) != ADDR_EXPR || TREE_OPERAND (arg, 0) != target)
> + return false;
> +}
> + return true;
> +}
> +
> +/* If BB is a basic block ending with __builtin_setjmp_setup, return edge
> + from .ABNORMAL_DISPATCHER basic block to corresponding
> + __builtin_setjmp_receiver basic block, otherwise return NULL. */
> +static edge
> +builtin_setjmp_setup_bb (basic_block bb)
> +{
> + if (EDGE_COUNT (bb->succs) != 2
> + || ((EDGE_SUCC (bb, 0)->flags
> +& (EDGE_ABNORMAL | EDGE_EH
[PATCH] Fix PR89514, -fdebug-types-section vs. LTO
This fixes inconsistencies with respect to computing DIE sizes and
abbrevs when using -fdebug-types-section and LTO where we have
external refs that are _not_ refs to comdat_type_p's. output_die
gets this correct but both size_of_die and value_format simply
key on use_debug_types which causes the LTO external refs to the
early debug represented as type signatures for DIE size accounting
and in the abbrev while then actually being output correctly.
This obviously corrupts the DWARF quite a bit.
Fixed by doing what output_die does, check AT_ref (a)->comdat_type_p
instead of use_debug_types.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
There's no way to scan ltrans assembly so no testcase.
I've refrained from "ignoring" -fdebug-types-section for the
late debug (where it doesn't make any sense), the above
inconsistency warrants fixing anyway. But a followup could
adjust the use_debug_types #define to include && !in_lto_p
like I did for want_pubnames.
Richard.
2019-02-27 Richard Biener
PR debug/89514
* dwarf2out.c (size_of_die): Key on AT_ref (a)->comdat_type_p
rather than on use_debug_types, doing what output_die does.
(value_format): Likewise.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 269204)
+++ gcc/dwarf2out.c (working copy)
@@ -9425,7 +9425,7 @@ size_of_die (dw_die_ref die)
we use DW_FORM_ref_addr. In DWARF2, DW_FORM_ref_addr
is sized by target address length, whereas in DWARF3
it's always sized as an offset. */
- if (use_debug_types)
+ if (AT_ref (a)->comdat_type_p)
size += DWARF_TYPE_SIGNATURE_SIZE;
else if (dwarf_version == 2)
size += DWARF2_ADDR_SIZE;
@@ -9869,7 +9869,12 @@ value_format (dw_attr_node *a)
return DW_FORM_flag;
case dw_val_class_die_ref:
if (AT_ref_external (a))
- return use_debug_types ? DW_FORM_ref_sig8 : DW_FORM_ref_addr;
+ {
+ if (AT_ref (a)->comdat_type_p)
+ return DW_FORM_ref_sig8;
+ else
+ return DW_FORM_ref_addr;
+ }
else
return DW_FORM_ref;
case dw_val_class_fde_ref:
[PATCH] Fix -fdebug-types-section with -flto
This makes -fdebug-types-section actually work with -flto, causing
type units to be created and referred to by early debug.
I've lightly tested the result with hello-world style examples
where before this patch gdb wasn't able to see any types
(there were signature refs but the type units were missing) and
after the patch things work as expected.
The combination with -gsplit-dwarf is still broken, but that's
a different bug (-gsplit-dwarf plus -flto is broken).
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-02-27 Richard Biener
PR debug/88878
* dwarf2out.c (output_comdat_type_unit): Add early_lto_debug
parameter, prefix section name with .gnu.debuglto_ if true.
(dwarf2out_finish): Pass false to output_comdat_type_unit.
(dwarf2out_early_finish): Pass true to output_comdat_type_unit.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 269242)
+++ gcc/dwarf2out.c (working copy)
@@ -3746,7 +3746,7 @@ static void output_die_abbrevs (unsigned
static void output_die (dw_die_ref);
static void output_compilation_unit_header (enum dwarf_unit_type);
static void output_comp_unit (dw_die_ref, int, const unsigned char *);
-static void output_comdat_type_unit (comdat_type_node *);
+static void output_comdat_type_unit (comdat_type_node *, bool);
static const char *dwarf2_name (tree, int);
static void add_pubname (tree, dw_die_ref);
static void add_enumerator_pubname (const char *, dw_die_ref);
@@ -11225,7 +11230,7 @@ output_skeleton_debug_sections (dw_die_r
/* Output a comdat type unit DIE and its children. */
static void
-output_comdat_type_unit (comdat_type_node *node)
+output_comdat_type_unit (comdat_type_node *node, bool early_lto_debug)
{
const char *secname;
char *tmp;
@@ -11252,14 +11257,16 @@ output_comdat_type_unit (comdat_type_nod
if (dwarf_version >= 5)
{
if (!dwarf_split_debug_info)
- secname = ".debug_info";
+ secname = early_lto_debug ? DEBUG_LTO_INFO_SECTION : DEBUG_INFO_SECTION;
else
- secname = ".debug_info.dwo";
+ secname = (early_lto_debug
+ ? DEBUG_LTO_DWO_INFO_SECTION : DEBUG_DWO_INFO_SECTION);
}
else if (!dwarf_split_debug_info)
-secname = ".debug_types";
+secname = early_lto_debug ? ".gnu.debuglto_.debug_types" : ".debug_types";
else
-secname = ".debug_types.dwo";
+secname = (early_lto_debug
+ ? ".gnu.debuglto_.debug_types.dwo" : ".debug_types.dwo");
tmp = XALLOCAVEC (char, 4 + DWARF_TYPE_SIGNATURE_SIZE * 2);
sprintf (tmp, dwarf_version >= 5 ? "wi." : "wt.");
@@ -31498,7 +31505,7 @@ dwarf2out_finish (const char *filename)
? dl_section_ref
: debug_skeleton_line_section_label));
- output_comdat_type_unit (ctnode);
+ output_comdat_type_unit (ctnode, false);
*slot = ctnode;
}
@@ -32189,7 +32196,7 @@ dwarf2out_early_finish (const char *file
? debug_line_section_label
: debug_skeleton_line_section_label));
- output_comdat_type_unit (ctnode);
+ output_comdat_type_unit (ctnode, true);
*slot = ctnode;
}
Re: [PATCH][AArch64] Use implementation namespace consistently in arm_neon.h
Ping.
Thanks,
Kyrill
On 2/15/19 11:52 AM, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00345.html
Thanks,
Kyrill
On 2/6/19 1:52 PM, Kyrill Tkachov wrote:
[resending with patch compressed]
Hi all,
We're somewhat inconsistent in arm_neon.h when it comes to using the
implementation namespace for local
identifiers. This means things like:
#define hash_abcd 0
#define hash_e 1
#define wk 2
#include "arm_neon.h"
uint32x4_t
foo (uint32x4_t a, uint32_t b, uint32x4_t c)
{
return vsha1cq_u32 (a, b, c);
}
don't compile.
This patch fixes these issues throughout the whole of arm_neon.h
Bootstrapped and tested on aarch64-none-linux-gnu.
The advsimd-intrinsics.exp tests pass just fine.
Don't feel sorry for me having to write the ChangeLog.
./contrib/mklog.pl automated the whole thing.
Ok for trunk?
Thanks,
Kyrill
2019-02-06 Kyrylo Tkachov
* config/aarch64/arm_neon.h (vaba_s8): Use __ in identifiers
consistenly.
(vaba_s16): Likewise.
(vaba_s32): Likewise.
(vaba_u8): Likewise.
(vaba_u16): Likewise.
(vaba_u32): Likewise.
(vabal_high_s8): Likewise.
(vabal_high_s16): Likewise.
(vabal_high_s32): Likewise.
(vabal_high_u8): Likewise.
(vabal_high_u16): Likewise.
(vabal_high_u32): Likewise.
(vabal_s8): Likewise.
(vabal_s16): Likewise.
(vabal_s32): Likewise.
(vabal_u8): Likewise.
(vabal_u16): Likewise.
(vabal_u32): Likewise.
(vabaq_s8): Likewise.
(vabaq_s16): Likewise.
(vabaq_s32): Likewise.
(vabaq_u8): Likewise.
(vabaq_u16): Likewise.
(vabaq_u32): Likewise.
(vabd_s8): Likewise.
(vabd_s16): Likewise.
(vabd_s32): Likewise.
(vabd_u8): Likewise.
(vabd_u16): Likewise.
(vabd_u32): Likewise.
(vabdl_high_s8): Likewise.
(vabdl_high_s16): Likewise.
(vabdl_high_s32): Likewise.
(vabdl_high_u8): Likewise.
(vabdl_high_u16): Likewise.
(vabdl_high_u32): Likewise.
(vabdl_s8): Likewise.
(vabdl_s16): Likewise.
(vabdl_s32): Likewise.
(vabdl_u8): Likewise.
(vabdl_u16): Likewise.
(vabdl_u32): Likewise.
(vabdq_s8): Likewise.
(vabdq_s16): Likewise.
(vabdq_s32): Likewise.
(vabdq_u8): Likewise.
(vabdq_u16): Likewise.
(vabdq_u32): Likewise.
(vaddlv_s8): Likewise.
(vaddlv_s16): Likewise.
(vaddlv_u8): Likewise.
(vaddlv_u16): Likewise.
(vaddlvq_s8): Likewise.
(vaddlvq_s16): Likewise.
(vaddlvq_s32): Likewise.
(vaddlvq_u8): Likewise.
(vaddlvq_u16): Likewise.
(vaddlvq_u32): Likewise.
(vcvtx_f32_f64): Likewise.
(vcvtx_high_f32_f64): Likewise.
(vcvtxd_f32_f64): Likewise.
(vmla_n_f32): Likewise.
(vmla_n_s16): Likewise.
(vmla_n_s32): Likewise.
(vmla_n_u16): Likewise.
(vmla_n_u32): Likewise.
(vmla_s8): Likewise.
(vmla_s16): Likewise.
(vmla_s32): Likewise.
(vmla_u8): Likewise.
(vmla_u16): Likewise.
(vmla_u32): Likewise.
(vmlal_high_n_s16): Likewise.
(vmlal_high_n_s32): Likewise.
(vmlal_high_n_u16): Likewise.
(vmlal_high_n_u32): Likewise.
(vmlal_high_s8): Likewise.
(vmlal_high_s16): Likewise.
(vmlal_high_s32): Likewise.
(vmlal_high_u8): Likewise.
(vmlal_high_u16): Likewise.
(vmlal_high_u32): Likewise.
(vmlal_n_s16): Likewise.
(vmlal_n_s32): Likewise.
(vmlal_n_u16): Likewise.
(vmlal_n_u32): Likewise.
(vmlal_s8): Likewise.
(vmlal_s16): Likewise.
(vmlal_s32): Likewise.
(vmlal_u8): Likewise.
(vmlal_u16): Likewise.
(vmlal_u32): Likewise.
(vmlaq_n_f32): Likewise.
(vmlaq_n_s16): Likewise.
(vmlaq_n_s32): Likewise.
(vmlaq_n_u16): Likewise.
(vmlaq_n_u32): Likewise.
(vmlaq_s8): Likewise.
(vmlaq_s16): Likewise.
(vmlaq_s32): Likewise.
(vmlaq_u8): Likewise.
(vmlaq_u16): Likewise.
(vmlaq_u32): Likewise.
(vmls_n_f32): Likewise.
(vmls_n_s16): Likewise.
(vmls_n_s32): Likewise.
(vmls_n_u16): Likewise.
(vmls_n_u32): Likewise.
(vmls_s8): Likewise.
(vmls_s16): Likewise.
(vmls_s32): Likewise.
(vmls_u8): Likewise.
(vmls_u16): Likewise.
(vmls_u32): Likewise.
(vmlsl_high_n_s16): Likewise.
(vmlsl_high_n_s32): Likewise.
(vmlsl_high_n_u16): Likewise.
(vmlsl_high_n_u32): Likewise.
(vmlsl_high_s8): Likewise.
(vmlsl_high_s16): Likewise.
(vmlsl_high_s32): Likewise.
(vmlsl_high_u8): Likewise.
(vmlsl_high_u16): Likewise.
(vmlsl_high_u32): Likewise.
(vmlsl_n_s16): Likewise.
(vmlsl_n_s32): Likewise.
(vmlsl_n_u16): Likewise.
(vmlsl_n_u32): Likewise.
(vmlsl_s8): Likewise.
(vmlsl_s16): Likewise.
(vmlsl_s32): Likewise.
(vmlsl_u8): Likewise.
(vmlsl_u16): Likewise.
(vmlsl_u32): Likewise.
(vmlsq_n_f32): Likewise.
(vmlsq_n_s16): Likewise.
(vmlsq_n_s32): Likewise.
(vmlsq_n_u16)
[MAINTAINERS] Add myself to MAINTAINERS
Add myself to write after approval. Alejandro Committed to trunk in r 269246 Index: MAINTAINERS === --- MAINTAINERS(revision 269244) +++ MAINTAINERS(working copy) @@ -495,6 +495,7 @@ Jose E. Marchesi Patrick Marlier Simon Martin +Alejandro Martinez Ranjit Mathew Paulo Matos Michael Matz
Re: Fix canonical types of atomic types
On Sun, Feb 10, 2019 at 6:21 PM Jan Hubicka wrote:
>
> Hi,
> build_qualified_type adjusts alignment of atomic types to one of minimal
> alignment needed for atomic operations (I think it does so). For packed
> structures this leads to type variant to be created and alignment to be
> updated later.
>
> If you call again build_qualified_type on packed structures, it won't
> reuse existing type because check_base_type will compare alignment of
> the base type (which is not atomic and has smaller alignment) and will
> end up creating new variant.
>
> When constructing a canonical types C frontned relies on types being
> shared and this eventually leads to ice in type simplification.
>
> I think it is easiest to teach check_base_type about minimal alignment.
>
> Bootstrapped/regtested x86_64-linux.
> PR lto/88585
> * tree.c (find_atomic_core_type): Forward declare.
> (check_base_type): Correctly compare alignments of atomic types.
> Index: tree.c
> ===
> --- tree.c (revision 268742)
> +++ tree.c (working copy)
> @@ -6329,18 +6329,33 @@ check_lang_type (const_tree cand, const_
>return lang_hooks.types.type_hash_eq (cand, base);
> }
>
> +static tree find_atomic_core_type (const_tree type);
> +
Just move find_atomic_core_type please.
> /* Returns true iff unqualified CAND and BASE are equivalent. */
>
> bool
> check_base_type (const_tree cand, const_tree base)
> {
> - return (TYPE_NAME (cand) == TYPE_NAME (base)
> - /* Apparently this is needed for Objective-C. */
> - && TYPE_CONTEXT (cand) == TYPE_CONTEXT (base)
> - /* Check alignment. */
> - && TYPE_ALIGN (cand) == TYPE_ALIGN (base)
> - && attribute_list_equal (TYPE_ATTRIBUTES (cand),
> - TYPE_ATTRIBUTES (base)));
> + if (TYPE_NAME (cand) != TYPE_NAME (base)
> + /* Apparently this is needed for Objective-C. */
> + || TYPE_CONTEXT (cand) != TYPE_CONTEXT (base)
> + || !attribute_list_equal (TYPE_ATTRIBUTES (cand),
> + TYPE_ATTRIBUTES (base)))
> +return false;
> + /* Check alignment. */
> + if (TYPE_ALIGN (cand) == TYPE_ALIGN (base))
> +return true;
> + /* Atomic types increase minimal alignment. We must to do so as well
> + or we get duplicated canonical types. See PR88686. */
> + if ((TYPE_QUALS (cand) & TYPE_QUAL_ATOMIC))
> +{
> + /* See if this object can map to a basic atomic type. */
> + tree atomic_type = find_atomic_core_type (cand);
build_qualified_type handles the case this function returns NULL,
I think you should as well.
> + if (TYPE_ALIGN (atomic_type) == TYPE_ALIGN (cand)
> + && TYPE_ALIGN (base) < TYPE_ALIGN (cand))
Why the second condition? build_qualified_type simply does
if (((type_quals & TYPE_QUAL_ATOMIC) == TYPE_QUAL_ATOMIC))
{
/* See if this object can map to a basic atomic type. */
tree atomic_type = find_atomic_core_type (type);
if (atomic_type)
{
/* Ensure the alignment of this type is compatible with
the required alignment of the atomic type. */
if (TYPE_ALIGN (atomic_type) > TYPE_ALIGN (t))
SET_TYPE_ALIGN (t, TYPE_ALIGN (atomic_type));
without caring for TYPE_ALIGN of the base type.
Note we seem to happily accept build_aligned_type that produce
under-aligned atomics :/
Richard.
> + return true;
> +}
> + return false;
> }
>
> /* Returns true iff CAND is equivalent to BASE with TYPE_QUALS. */
> @@ -6373,7 +6388,7 @@ check_aligned_type (const_tree cand, con
> atomic types, and returns that core atomic type. */
>
> static tree
> -find_atomic_core_type (tree type)
> +find_atomic_core_type (const_tree type)
> {
>tree base_atomic_type;
>
Re: [PATCH][stage 1] Fix bitmap registration of overheads.
On Wed, Feb 27, 2019 at 9:01 AM Martin Liška wrote:
>
> On 2/26/19 7:48 PM, Richard Biener wrote:
> > On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"
> > wrote:
> >> On 2/26/19 4:02 PM, Richard Biener wrote:
> >>> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
>
> Hi.
>
> I've rewritten bitmap memory statistics which abused unsigned
> type via register_overhead (map, -((int)sizeof (bitmap_head))).
> I come up with a concept that each bitmap has assigned a unique ID
> which is used for stats tracking. It's caused by fact that e.g. DF
> >> is
> heavily reallocating bitmaps that then have a different address.
>
> Survives bootstrap with --enable-gather-detailed-mem-stats.
>
> Ready for next stage1?
> >>>
> >>> + /* Get bitmap descriptor UID casted to an unsigned integer
> >> pointer. */
> >>> + unsigned *get_descriptor ()
> >>> + {
> >>> +return (unsigned *)(ptrdiff_t)alloc_descriptor;
> >>> + }
> >>>
> >>> this one is a bit ugly and together with
> >>
> >> I know it's not perfect.
> >>
> >>>
> >>> template
> >>> inline hashval_t
> >>> pointer_hash ::hash (const value_type &candidate)
> >>> {
> >>> /* This is a really poor hash function, but it is what the current
> >> code uses,
> >>> so I am reusing it to avoid an additional axis in testing. */
> >>> return (hashval_t) ((intptr_t)candidate >> 3);
> >>>
> >>> will give quite some hash collisions. So I guess you should shift
> >>> the descriptor << 3 at least (and then make it at most 29 bits in
> >>> size?).
> >>
> >> That's easily doable.
> >>
> >>> Not sure what to do about the descriptor wrapping btw.
> >>
> >> Question is whether we want to invest in our internal scaffolding more
> >> time?
> >> Or can we live with the ugly casting?
> >
> > I guess we can live with it if we can avoid the hash collisions.
>
> Great.
>
> Then there's updated version of the patch for next stage1.
LGTM. The << 3 in get_descriptor deserves a comment though.
Also leaving two bits in the bitfield uninitialized may generate
awkward code (you might want to check), explicitely having
a pad : 2 and initializing that to zero might allow better code
generation here (guarding the member and init with
#if might also be possible).
Richard.
> Martin
>
> >
> > Richard.
> >
> >> Martin
> >>
> >>>
> >>> Richard.
> >>>
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-02-26 Martin Liska
>
> * bitmap.c (bitmap_register): Come up with
> alloc_descriptor_max_uid and assign it for
> a new bitmap.
> (register_overhead): Use get_descriptor as
> a descriptor.
> (release_overhead): New.
> (bitmap_elem_to_freelist): Call it.
> (bitmap_elt_clear_from): Likewise.
> (bitmap_obstack_free): Likewise.
> (bitmap_move): Sensitively release memory.
> * bitmap.h (struct GTY): Add alloc_descriptor.
> (bitmap_initialize): Initialize alloc_descriptor to zero.
> * tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
> ---
> gcc/bitmap.c | 39 ---
> gcc/bitmap.h | 17 ++---
> gcc/tree-ssa-pre.c | 2 +-
> 3 files changed, 43 insertions(+), 15 deletions(-)
>
>
> >
>
Re: [PATCH] Improve arm and aarch64 casesi (PR target/70341)
On Mon, Feb 25, 2019 at 10:23:52AM +, Kyrill Tkachov wrote: > > The only bootstraps I'm doing are distro builds with > > --with-tune=generic-armv7-a --with-arch=armv7-a \ > > --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux > > I don't have setup nor experience with configuring anything else, don't > > really know what is and what isn't ABI compatible etc. > > Isn't --with-mode=arm the default with the above set of options? Can > > --with-mode=thumb be used ABI compatibly with that, or is that incompatible? > > > They are ABI-compatible. Running the testsuite with -mthumb in RUNTESTFLAGS > would also be enough in this case if you don't have the cycles for a > bootstrap. Ok, so tried to do two distro builds with the above plus --with-mode=thumb, one without the casesi patch, the other one with that. Both bootstrapped successfully, but dunno why the regtests were too slow to fit under our hard 2 days timeout limit. When I grabbed the build logs, the only difference in the grep ^FAIL | sort -u lines was one fewer go failure with the patch (but that is most likely a random failure rather than the patch actually changing anything). Is -mthumb generally slower than ARM mode? Anyway, I'm afraid this is as far as I can go in my testing. Jakub
[PATCH] PR libstdc++/89466 avoid slow xsltproc command in configure
Certain broken versions of xsltproc ignore the --nonet option and will
attempt to fetch the docbook stylesheet from the WWW when it isn't in
the local XML catalog.
This patch checks for the local stylesheet directory first, and doesn't
use xsltproc if no local stylesheets are found. Checking for the local
directory is done using xmlcatalog if available, only checking the
hardcoded list of directories if xmlcatalog fails. The right directory
for Suse is added to the hardcoded list.
This should avoid doing an xsltproc check that would need to download
the stylesheet, so no network connection is made even if a broken
xsltproc is present.
PR libstdc++/89466
* acinclude.m4 (GLIBCXX_CONFIGURE_DOCBOOK): Reorder check for local
stylesheet directories before check for xsltproc. Try to use
xmlcatalog to find local stylesheet directory before trying hardcoded
paths. Add path used by suse to hardcoded paths. Adjust xsltproc
check to look for the same stylesheet as doc/Makefile.am uses. Don't
use xsltproc if xmlcatalog fails to find a local stylesheet.
* configure.ac: Check for xmlcatalog.
* Makefile.in: Regenerate.
* configure: Likewise.
* doc/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* libsupc++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* python/Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* src/c++11/Makefile.in: Likewise.
* src/c++17/Makefile.in: Likewise.
* src/c++98/Makefile.in: Likewise.
* src/filesystem/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.
Tested x86_64-linux (with stylesheets installed) and
powerpc64le-linux (without stylesheets installed).
Committed to trunk.
commit a24bf5641e21070bd36363ef22ec4977bc0ad094
Author: Jonathan Wakely
Date: Tue Feb 26 23:30:30 2019 +
PR libstdc++/89466 avoid slow xsltproc command in configure
Certain broken versions of xsltproc ignore the --nonet option and will
attempt to fetch the docbook stylesheet from the WWW when it isn't in
the local XML catalog.
This patch checks for the local stylesheet directory first, and doesn't
use xsltproc if no local stylesheets are found. Checking for the local
directory is done using xmlcatalog if available, only checking the
hardcoded list of directories if xmlcatalog fails. The right directory
for Suse is added to the hardcoded list.
This should avoid doing an xsltproc check that would need to download
the stylesheet, so no network connection is made even if a broken
xsltproc is present.
PR libstdc++/89466
* acinclude.m4 (GLIBCXX_CONFIGURE_DOCBOOK): Reorder check for local
stylesheet directories before check for xsltproc. Try to use
xmlcatalog to find local stylesheet directory before trying
hardcoded
paths. Add path used by suse to hardcoded paths. Adjust xsltproc
check to look for the same stylesheet as doc/Makefile.am uses. Don't
use xsltproc if xmlcatalog fails to find a local stylesheet.
* configure.ac: Check for xmlcatalog.
* Makefile.in: Regenerate.
* configure: Likewise.
* doc/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* libsupc++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* python/Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* src/c++11/Makefile.in: Likewise.
* src/c++17/Makefile.in: Likewise.
* src/c++98/Makefile.in: Likewise.
* src/filesystem/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 8950e4c8872..84258d87a33 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -634,34 +634,43 @@ dnl XSL_STYLE_DIR
dnl
AC_DEFUN([GLIBCXX_CONFIGURE_DOCBOOK], [
-AC_MSG_CHECKING([for docbook stylesheets for documentation creation])
-glibcxx_stylesheets=no
-if test x${XSLTPROC} = xyes && echo '' | xsltproc --noout --nonet
--xinclude
http://docbook.sourceforge.net/release/xsl-ns/current/xhtml-1_1/docbook.xsl -
2>/dev/null; then
- glibcxx_stylesheets=yes
-fi
-AC_MSG_RESULT($glibcxx_stylesheets)
+glibcxx_docbook_url=http://docbook.sourceforge.net/release/xsl-ns/current/
AC_MSG_CHECKING([for local stylesheet directory])
glibcxx_local_stylesheets=no
-if test x"$glibcxx_stylesheets" = x"yes"; then
- if test -d /usr/share/sgml/docbook/xsl-ns-stylesheets; then
-glibcxx_local_stylesheets=yes
-XSL_STYLE_DIR=/usr/share/sgml/docbook/xsl-ns-stylesheets
- fi
- if test -d /usr/share/xml/docbook/stylesheet/docbook-xsl-ns; then
-glibcxx_local_stylesheets=yes
-XSL_STYLE_DIR=/usr/share/xml/docbook/stylesheet/docbook-xsl-ns
- fi
- if test -d /usr/share/xml/docboo
Re: [PATCH] Improve arm and aarch64 casesi (PR target/70341)
On 27/02/2019 10:56, Jakub Jelinek wrote: > On Mon, Feb 25, 2019 at 10:23:52AM +, Kyrill Tkachov wrote: >>> The only bootstraps I'm doing are distro builds with >>> --with-tune=generic-armv7-a --with-arch=armv7-a \ >>> --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux >>> I don't have setup nor experience with configuring anything else, don't >>> really know what is and what isn't ABI compatible etc. >>> Isn't --with-mode=arm the default with the above set of options? Can >>> --with-mode=thumb be used ABI compatibly with that, or is that incompatible? >> >> >> They are ABI-compatible. Running the testsuite with -mthumb in RUNTESTFLAGS >> would also be enough in this case if you don't have the cycles for a >> bootstrap. > > Ok, so tried to do two distro builds with the above plus --with-mode=thumb, > one without the casesi patch, the other one with that. > Both bootstrapped successfully, but dunno why the regtests were too slow to > fit under our hard 2 days timeout limit. When I grabbed the build logs, the > only difference in the grep ^FAIL | sort -u lines was one fewer go failure > with the patch (but that is most likely a random failure rather than the > patch actually changing anything). Is -mthumb generally slower than ARM > mode? > > Anyway, I'm afraid this is as far as I can go in my testing. > > Jakub > Thumb performance on v7-a should be nearly identical to Arm performance (sometimes a bit faster, sometimes a bit slower, depending on the precise code generated). So if you're timing out, something else is probably going wrong. R.
[PR 87525] Zero local estimated benefit for cloning extern inline function
Hi,
in the discussion in PR 87525 Honza noted that IPA-CP should not
estimate any local time benefits from cloning an extern inline function,
that any benefits this might bring about have to come from other
specializations such cloning might enable.
While the patch is only a heuristics change and so does not really fix
the issue (which itself is a part of more general set of problems with
-D_FORTIFY_SOURCE and LTO), it should make it much less likely and is
sensible change on its own.
Bootstrapped and tested on x86_54-linux, OK for trunk and the
gcc-8-branch?
Thanks,
Martin
2019-02-25 Martin Jambor
PR lto/87525
* ipa-cp.c (perform_estimation_of_a_value): Account zero time benefit
for extern inline functions.
testsuite/
* gcc.dg/ipa/ipcp-5.c: New test.
---
gcc/ipa-cp.c | 17
gcc/testsuite/gcc.dg/ipa/ipcp-5.c | 45 +++
2 files changed, 57 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/ipa/ipcp-5.c
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 442d5c63eff..59b15fa7362 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -2818,11 +2818,18 @@ perform_estimation_of_a_value (cgraph_node *node,
vec known_csts,
base_time -= time;
if (base_time > 65535)
base_time = 65535;
- time_benefit = base_time.to_int ()
-+ devirtualization_time_bonus (node, known_csts, known_contexts,
- known_aggs_ptrs)
-+ hint_time_bonus (hints)
-+ removable_params_cost + est_move_cost;
+
+ /* Extern inline functions have no cloning local time benefits because they
+ will be inlined anyway. The only reason to clone them is if it enables
+ optimization in any of the functions they call. */
+ if (DECL_EXTERNAL (node->decl) && DECL_DECLARED_INLINE_P (node->decl))
+time_benefit = 0;
+ else
+time_benefit = base_time.to_int ()
+ + devirtualization_time_bonus (node, known_csts, known_contexts,
+known_aggs_ptrs)
+ + hint_time_bonus (hints)
+ + removable_params_cost + est_move_cost;
gcc_checking_assert (size >=0);
/* The inliner-heuristics based estimates may think that in certain
diff --git a/gcc/testsuite/gcc.dg/ipa/ipcp-5.c
b/gcc/testsuite/gcc.dg/ipa/ipcp-5.c
new file mode 100644
index 000..6786c514543
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/ipcp-5.c
@@ -0,0 +1,45 @@
+/* Test that estimated local cloning time benefit of extern inline functions is
+ zero. */
+
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-ipa-cp -fno-early-inlining" } */
+/* { dg-add-options bind_pic_locally } */
+
+extern int get_int (void);
+extern void use_stuff (int);
+
+int arr[10];
+
+inline void
+f (int a)
+{
+ arr[0] += a + 5;
+ arr[1] += a + 50;
+ arr[2] += a - 3;
+ arr[3] += a;
+ arr[4] += a + 21;
+ arr[5] += a + 900;
+ arr[6] += a + 2;
+ arr[7] += a + 3456;
+ arr[8] += a + 3;
+ arr[9] += a + 32;
+ use_stuff (a);
+}
+
+
+int
+entry (void)
+{
+ int i;
+ for (i = 0; i < 100; i++)
+f (7);
+ for (i = 0; i < 100; i++)
+f (get_int ());
+ return 0;
+}
+
+
+/* { dg-final { scan-ipa-dump "loc_time: 0" "cp" } } */
+/* { dg-final { scan-ipa-dump-not "replacing param.*with const" "cp" } } */
+
+
--
2.20.1
[PATCH] More -fdebug-types-section + -flto fixes
This avoids .debug_types for the late debug where we shouldn't emit any type DIEs anyway. This follows the recent change for pubnames. Bootstrap & regtest running on x86_64-unknown-linux-gnu. 2019-02-27 Richard Biener PR debug/88878 * dwarf2out.c (use_debug_types): Disable when in_lto_p. Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 269250) +++ gcc/dwarf2out.c (working copy) @@ -2914,9 +2914,13 @@ const struct gcc_debug_hooks dwarf2_line separate comdat sections since the linker will then be able to remove duplicates. But not all tools support .debug_types sections yet. For Dwarf V5 or higher .debug_types doesn't exist any more, - it is DW_UT_type unit type in .debug_info section. */ - -#define use_debug_types (dwarf_version >= 4 && flag_debug_types_section) + it is DW_UT_type unit type in .debug_info section. For late LTO + debug there should be almost no types emitted so avoid enabling + -fdebug-types-section there. */ + +#define use_debug_types (dwarf_version >= 4 \ +&& flag_debug_types_section \ +&& !in_lto_p) /* Various DIE's use offsets relative to the beginning of the .debug_info section to refer to each other. */
[PATCH] Improve JSON format for group functions.
Hi.
The patch adds missing information into JSON intermediate format.
Before the patch one can't assign 'lines' to 'functions' in case
one has a group function (e.g. a template function).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I will install it if not objections.
Thanks,
Martin
gcc/ChangeLog:
2019-02-27 Martin Liska
* gcov.c (output_intermediate_json_line): When a line
belongs to a group of functions, print function name
for each of such line entry.
(output_json_intermediate_file): Add new argument.
* doc/gcov.texi: Document the change.
---
gcc/doc/gcov.texi | 5 +
gcc/gcov.c| 14 ++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index a128f5f4f83..bbb1941246b 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -276,6 +276,7 @@ Each @var{line} has the following form:
"count": @var{count},
"line_number": @var{line_number},
"unexecuted_block": @var{unexecuted_block}
+ "function_name": @var{function_name},
@}
@end smallexample
@@ -294,6 +295,10 @@ Fields of the @var{line} element have following semantics:
(not all statements on the line are executed)
@end itemize
+@item
+@var{function_name}: when a @var{line} contains multiple functions, each
+such @var{line} entry contains name of the function
+
Each @var{branch} has the following form:
@smallexample
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 9e27a826ea4..9c372356eb5 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -1041,17 +1041,21 @@ process_args (int argc, char **argv)
return optind;
}
-/* Output intermediate LINE sitting on LINE_NUM to JSON OBJECT. */
+/* Output intermediate LINE sitting on LINE_NUM to JSON OBJECT.
+ When FUNCTION_NAME is non null, add the name to the LINE. */
static void
output_intermediate_json_line (json::array *object,
- line_info *line, unsigned line_num)
+ line_info *line, unsigned line_num,
+ const char *function_name)
{
if (!line->exists)
return;
json::object *lineo = new json::object ();
lineo->set ("line_number", new json::number (line_num));
+ if (function_name != NULL)
+lineo->set ("function_name", new json::string (function_name));
lineo->set ("count", new json::number (line->count));
lineo->set ("unexecuted_block",
new json::literal (line->has_unexecuted_block));
@@ -1154,13 +1158,15 @@ output_json_intermediate_file (json::array *json_files, source_info *src)
for (unsigned i = 0; i < lines.size (); i++)
{
line_info *line = &lines[i];
- output_intermediate_json_line (lineso, line, line_num + i);
+ output_intermediate_json_line (lineso, line, line_num + i,
+ (*it2)->m_name);
}
}
/* Follow with lines associated with the source file. */
if (line_num < src->lines.size ())
- output_intermediate_json_line (lineso, &src->lines[line_num], line_num);
+ output_intermediate_json_line (lineso, &src->lines[line_num], line_num,
+ NULL);
}
}
RE: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during native feature detection
Ping. > -Original Message- > From: Tamar Christina > Sent: Thursday, February 7, 2019 10:43 > To: Tamar Christina ; Jakub Jelinek > > Cc: Kyrill Tkachov ; gcc-patches@gcc.gnu.org; > nd ; James Greenhalgh ; > Richard Earnshaw ; Marcus Shawcroft > > Subject: RE: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored > during native feature detection > > Hi All, > > Since this hasn't been reviewed yet anyway I've updated this patch to also fix > the memory leaks etc. > > -- > > This patch makes the feature detection code for AArch64 GCC not add > features automatically when the feature had no hwcaps string to match > against. > > This means that -mcpu=native no longer adds feature flags such as +profile. > The behavior wasn't noticed before because at the time +profile was added > a bug was preventing any feature bits from being added by native detections. > > The loop has also been changed as Jakub specified in order to avoid a > memory leak that was present in the existing code and to be slightly more > efficient. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for trunk? > > Thanks, > Tamar > > gcc/ChangeLog: > > 2019-02-07 Tamar Christina > > PR target/88530 > * config/aarch64/aarch64-option-extensions.def: Document it. > * config/aarch64/driver-aarch64.c (host_detect_local_cpu): Skip > feature > if empty hwcaps. > > gcc/testsuite/ChangeLog: > > 2019-02-07 Tamar Christina > > PR target/88530 > * gcc.target/aarch64/options_set_10.c: New test. > > > -Original Message- > > From: gcc-patches-ow...@gcc.gnu.org > On > > Behalf Of Tamar Christina > > Sent: Wednesday, January 30, 2019 14:48 > > To: Jakub Jelinek > > Cc: Kyrill Tkachov ; > > gcc-patches@gcc.gnu.org; nd ; James Greenhalgh > > ; Richard Earnshaw > > ; Marcus Shawcroft > > > > Subject: Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored > > during native feature detection > > > > Hi Jakub, > > > > On Wed, Jan 30, 2019 at 02:06:01PM +, Tamar Christina wrote: > > > > Thanks for the feedback, but I think those are changes for another > patch. > > > > > > At least the memory leak is something that should be fixed even in > > > stage4 IMNSHO. > > > > I'll provide a separate patch for this then. > > > > > Anyway, will defer to aarch64 maintainers here. > > > > > Just one question, for the *feat_string == '\0' case, is continue > > > what you want, rather than just enabled = false; and doing the > > > extension_flags &= ~(aarch64_extensions[i].flag); > > > later on? > > > > Yeah, because the feature may be on by default due to another > > extension, in which case you would erroneously turn it off. The > > absence of an HWCAPS shouldn't pro-actively disable an extension. > > > > Regards, > > Tamar
[PATCH] Fix GIMPLE FE with calls and startwith
Turns out the cgraph code isn't happy if cgraph edge (re-)building
is skipped.
Tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-02-27 Richard Biener
* passes.c (should_skip_pass_p): Do not skip cgraph-edge
building.
* gcc.dg/gimplefe-36.c: New testcase.
Index: gcc/passes.c
===
--- gcc/passes.c(revision 269247)
+++ gcc/passes.c(working copy)
@@ -2380,6 +2380,10 @@ should_skip_pass_p (opt_pass *pass)
&& pass->properties_provided != 0)
return false;
+ /* We need to (re-)build cgraph edges as needed. */
+ if (strstr (pass->name, "build_cgraph_edges") != NULL)
+return false;
+
/* Don't skip df init; later RTL passes need it. */
if (strstr (pass->name, "dfinit") != NULL)
return false;
Index: gcc/testsuite/gcc.dg/gimplefe-36.c
===
--- gcc/testsuite/gcc.dg/gimplefe-36.c (nonexistent)
+++ gcc/testsuite/gcc.dg/gimplefe-36.c (working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fgimple" } */
+
+int foo (void);
+
+void __GIMPLE (startwith("fre1"))
+d ()
+{
+ int _1;
+
+bb_2:
+ _1 = foo ();
+ return;
+}
[PATCH] Fix PR89497
CFG cleanup is now set up to perform trivial unreachable code
elimination before doing anything that would require up-to-date
SSA form. Unfortunately a pending SSA update still will cause
breakage to stmt folding triggered for example by basic-block
merging.
Fortunately it's now easy to properly "interleave" CFG cleanup
and SSA update.
Done as follows, bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-02-27 Richard Biener
PR middle-end/89497
* tree-cfgcleanup.h (cleanup_tree_cfg): Add SSA update flags
argument, defaulted to zero.
* passes.c (execute_function_todo): Pass down SSA update flags
to cleanup_tree_cfg.
* tree-cfgcleanup.c: Include tree-into-ssa.h and tree-cfgcleanup.h.
(cleanup_tree_cfg_noloop): After cleanup_control_flow_pre update SSA
form if requested.
(cleanup_tree_cfg): Get and pass down SSA update flags.
Index: gcc/tree-cfgcleanup.h
===
--- gcc/tree-cfgcleanup.h (revision 269251)
+++ gcc/tree-cfgcleanup.h (working copy)
@@ -22,7 +22,7 @@ along with GCC; see the file COPYING3.
/* In tree-cfgcleanup.c */
extern bitmap cfgcleanup_altered_bbs;
-extern bool cleanup_tree_cfg (void);
+extern bool cleanup_tree_cfg (unsigned = 0);
extern bool fixup_noreturn_call (gimple *stmt);
extern bool delete_unreachable_blocks_update_callgraph (cgraph_node *dst_node,
bool update_clones);
Index: gcc/passes.c
===
--- gcc/passes.c(revision 269251)
+++ gcc/passes.c(working copy)
@@ -1927,7 +1927,7 @@ execute_function_todo (function *fn, voi
/* Always cleanup the CFG before trying to update SSA. */
if (flags & TODO_cleanup_cfg)
{
- cleanup_tree_cfg ();
+ cleanup_tree_cfg (flags & TODO_update_ssa_any);
/* When cleanup_tree_cfg merges consecutive blocks, it may
perform some simplistic propagation when removing single
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c (revision 269251)
+++ gcc/tree-cfgcleanup.c (working copy)
@@ -44,6 +44,9 @@ along with GCC; see the file COPYING3.
#include "gimple-fold.h"
#include "tree-ssa-loop-niter.h"
#include "cgraph.h"
+#include "tree-into-ssa.h"
+#include "tree-cfgcleanup.h"
+
/* The set of blocks in that at least one of the following changes happened:
-- the statement at the end of the block was changed
@@ -943,7 +946,7 @@ mfb_keep_latches (edge e)
Return true if the flowgraph was modified, false otherwise. */
static bool
-cleanup_tree_cfg_noloop (void)
+cleanup_tree_cfg_noloop (unsigned ssa_update_flags)
{
timevar_push (TV_TREE_CLEANUP_CFG);
@@ -1023,6 +1026,8 @@ cleanup_tree_cfg_noloop (void)
/* After doing the above SSA form should be valid (or an update SSA
should be required). */
+ if (ssa_update_flags)
+update_ssa (ssa_update_flags);
/* Compute dominator info which we need for the iterative process below. */
if (!dom_info_available_p (CDI_DOMINATORS))
@@ -1125,9 +1130,9 @@ repair_loop_structures (void)
/* Cleanup cfg and repair loop structures. */
bool
-cleanup_tree_cfg (void)
+cleanup_tree_cfg (unsigned ssa_update_flags)
{
- bool changed = cleanup_tree_cfg_noloop ();
+ bool changed = cleanup_tree_cfg_noloop (ssa_update_flags);
if (current_loops != NULL
&& loops_state_satisfies_p (LOOPS_NEED_FIXUP))
Re: [PATCH][stage 1] Fix bitmap registration of overheads.
On 2/27/19 11:45 AM, Richard Biener wrote:
> On Wed, Feb 27, 2019 at 9:01 AM Martin Liška wrote:
>>
>> On 2/26/19 7:48 PM, Richard Biener wrote:
>>> On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"
>>> wrote:
On 2/26/19 4:02 PM, Richard Biener wrote:
> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
>>
>> Hi.
>>
>> I've rewritten bitmap memory statistics which abused unsigned
>> type via register_overhead (map, -((int)sizeof (bitmap_head))).
>> I come up with a concept that each bitmap has assigned a unique ID
>> which is used for stats tracking. It's caused by fact that e.g. DF
is
>> heavily reallocating bitmaps that then have a different address.
>>
>> Survives bootstrap with --enable-gather-detailed-mem-stats.
>>
>> Ready for next stage1?
>
> + /* Get bitmap descriptor UID casted to an unsigned integer
pointer. */
> + unsigned *get_descriptor ()
> + {
> +return (unsigned *)(ptrdiff_t)alloc_descriptor;
> + }
>
> this one is a bit ugly and together with
I know it's not perfect.
>
> template
> inline hashval_t
> pointer_hash ::hash (const value_type &candidate)
> {
> /* This is a really poor hash function, but it is what the current
code uses,
> so I am reusing it to avoid an additional axis in testing. */
> return (hashval_t) ((intptr_t)candidate >> 3);
>
> will give quite some hash collisions. So I guess you should shift
> the descriptor << 3 at least (and then make it at most 29 bits in
> size?).
That's easily doable.
> Not sure what to do about the descriptor wrapping btw.
Question is whether we want to invest in our internal scaffolding more
time?
Or can we live with the ugly casting?
>>>
>>> I guess we can live with it if we can avoid the hash collisions.
>>
>> Great.
>>
>> Then there's updated version of the patch for next stage1.
>
> LGTM. The << 3 in get_descriptor deserves a comment though.
>
> Also leaving two bits in the bitfield uninitialized may generate
> awkward code (you might want to check), explicitely having
> a pad : 2 and initializing that to zero might allow better code
> generation here (guarding the member and init with
> #if might also be possible).
>
> Richard.
>
>> Martin
>>
>>>
>>> Richard.
>>>
Martin
>
> Richard.
>
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2019-02-26 Martin Liska
>>
>> * bitmap.c (bitmap_register): Come up with
>> alloc_descriptor_max_uid and assign it for
>> a new bitmap.
>> (register_overhead): Use get_descriptor as
>> a descriptor.
>> (release_overhead): New.
>> (bitmap_elem_to_freelist): Call it.
>> (bitmap_elt_clear_from): Likewise.
>> (bitmap_obstack_free): Likewise.
>> (bitmap_move): Sensitively release memory.
>> * bitmap.h (struct GTY): Add alloc_descriptor.
>> (bitmap_initialize): Initialize alloc_descriptor to zero.
>> * tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
>> ---
>> gcc/bitmap.c | 39 ---
>> gcc/bitmap.h | 17 ++---
>> gcc/tree-ssa-pre.c | 2 +-
>> 3 files changed, 43 insertions(+), 15 deletions(-)
>>
>>
>>>
>>
I'm sending updated version of the patch.
Martin
>From db6f30e63d5b739375821d89791735acffeae380 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 19 Feb 2019 14:59:46 +0100
Subject: [PATCH] Fix bitmap registration of overheads.
gcc/ChangeLog:
2019-02-26 Martin Liska
* bitmap.c (bitmap_register): Come up with
alloc_descriptor_max_uid and assign it for
a new bitmap.
(register_overhead): Use get_descriptor as
a descriptor.
(release_overhead): New.
(bitmap_elem_to_freelist): Call it.
(bitmap_elt_clear_from): Likewise.
(bitmap_obstack_free): Likewise.
(bitmap_move): Sensitively release memory.
* bitmap.h (struct GTY): Add alloc_descriptor and padding.
(bitmap_initialize): Initialize alloc_descriptor to zero.
* tree-ssa-pre.c (do_hoist_insertion): Use bitmap_move.
---
gcc/bitmap.c | 39 ---
gcc/bitmap.h | 22 +++---
gcc/tree-ssa-pre.c | 2 +-
3 files changed, 48 insertions(+), 15 deletions(-)
diff --git a/gcc/bitmap.c b/gcc/bitmap.c
index 5a8236de750..894aefa13de 100644
--- a/gcc/bitmap.c
+++ b/gcc/bitmap.c
@@ -36,18 +36,33 @@ static bitmap_element *bitmap_tree_listify_from (bitmap, bitmap_element *);
void
bitmap_register (bitmap b MEM_STAT_DECL)
{
- bitmap_mem_desc.register_descriptor (b, BITMAP_ORIGIN, false
- FINAL_PASS_MEM_STAT);
+ static unsigned alloc_descriptor_max_uid = 1;
+ gcc_assert (b->alloc_descriptor == 0);
+ b->alloc_descriptor = alloc_descriptor_max_uid++;
+
+ bitmap_
Re: [PATCH] Improve arm and aarch64 casesi (PR target/70341)
Hi Jakub, On 2/27/19 10:56 AM, Jakub Jelinek wrote: On Mon, Feb 25, 2019 at 10:23:52AM +, Kyrill Tkachov wrote: The only bootstraps I'm doing are distro builds with --with-tune=generic-armv7-a --with-arch=armv7-a \ --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux I don't have setup nor experience with configuring anything else, don't really know what is and what isn't ABI compatible etc. Isn't --with-mode=arm the default with the above set of options? Can --with-mode=thumb be used ABI compatibly with that, or is that incompatible? They are ABI-compatible. Running the testsuite with -mthumb in RUNTESTFLAGS would also be enough in this case if you don't have the cycles for a bootstrap. Ok, so tried to do two distro builds with the above plus --with-mode=thumb, one without the casesi patch, the other one with that. Both bootstrapped successfully, but dunno why the regtests were too slow to fit under our hard 2 days timeout limit. When I grabbed the build logs, the only difference in the grep ^FAIL | sort -u lines was one fewer go failure with the patch (but that is most likely a random failure rather than the patch actually changing anything). Is -mthumb generally slower than ARM mode? Anyway, I'm afraid this is as far as I can go in my testing. As discussed on IRC, I've bootstrapped and tested this on arm-none-linux-gnueabihf. So from an arm perspective this looks good (but you'll need an aarch64 ok for that component). Thanks, Kyrill Jakub
Re: [PATCH] Improve arm and aarch64 casesi (PR target/70341)
On Wed, Feb 27, 2019 at 02:43:01PM +, Kyrill Tkachov wrote: > As discussed on IRC, I've bootstrapped and tested this on > arm-none-linux-gnueabihf. Thanks for doing that. I've committed the config/arm/ changes, they really don't depend on the aarch64 changes or vice versa. > So from an arm perspective this looks good (but you'll need an aarch64 ok > for that component). I'll wait for review for this part. Jakub
Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)
On Wed, Feb 27, 2019 at 12:20 AM Richard Biener wrote: > > On Tue, 26 Feb 2019, Jakub Jelinek wrote: > > > On Tue, Feb 26, 2019 at 05:18:17PM +0100, Jakub Jelinek wrote: > > > > > Shall I modify the patch for that? > > > > > > > > Might it even simplify the patch? If not the only comment on the > > > > original patch is that it would be nice to test it on a SJLJ EH > > > > target ... > > > > > > 1 file changed, 29 insertions(+), 16 deletions(-) > > > so not really simplify it, but not terrible either. > > > > > > Here is the incremental (untested) diff of what handles that. > > > > > > I don't have access to any standard SJLJ EH targets, but will try > > > --enable-sjlj-exceptions on x86_64-linux to see how far I get with that. > > > > Full updated patch that passed normal bootstrap/regtest on x86_64-linux and > > i686-linux. > > > > --enable-sjlj-exceptions bootstrap on x86_64-linux failed miserably, > > some entry-points are removed from libgcc_s.so in that case and > > make: relocation error: /lib64/libgc.so.1: symbol __gcc_personality_v0 > > version GCC_3.3.1 not defined in file libgcc_s.so.1 with link time reference > > On the other side, even without SJLJ EH, the testsuite coverage is quite > > good, at least during development of the patch I made several mistakes and > > each time there were dozens to hundreds of failing tests in the testsuite, > > including __builtin_setjmp, non-local goto, etc. > > > > That said, if anybody is able to test this on some SJLJ setup, it would be > > greatly appreciated. > > Patch is OK. I suppose auto-testers will pick up fallout and we > can always revert... > > Richard. > > > 2019-02-26 Jakub Jelinek > > > > PR tree-optimization/89280 > > * tree-cfgcleanup.c (maybe_dead_abnormal_edge_p, > > builtin_setjmp_setup_bb): New functions. > > (cleanup_control_flow_pre): Ignore maybe_dead_abnormal_edge_p edges. > > When visiting __builtin_setjmp_setup block, queue in special > > setjmp_vec vector edges from .ABNORMAL_DISPATCHER to corresponding > > __builtin_setjmp_receiver. Remove .ABNORMAL_DISPATCHER basic blocks > > from visited after the loop if they don't have any visited successor > > blocks. > > > > * gcc.c-torture/compile/pr89280.c: New test. > > * gcc.dg/torture/pr57147-2.c: Don't expect a setjmp after noreturn > > function. Skip the test for -O0. > > I got FAIL: gcc.dg/torture/pr57147-2.c -O1 scan-tree-dump-not optimized "setjmp" FAIL: gcc.dg/torture/pr57147-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-tree-dump-not optimized "setjmp" FAIL: gcc.dg/torture/pr57147-2.c -O2 scan-tree-dump-not optimized "setjmp" FAIL: gcc.dg/torture/pr57147-2.c -O3 -g scan-tree-dump-not optimized "setjmp" FAIL: gcc.dg/torture/pr57147-2.c -Os scan-tree-dump-not optimized "setjmp" with unix/-fpic on x86. Should test pass with -fPIC? -- H.J.
Re: [PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)
On Wed, Feb 27, 2019 at 07:03:06AM -0800, H.J. Lu wrote:
> I got
>
> FAIL: gcc.dg/torture/pr57147-2.c -O1 scan-tree-dump-not optimized "setjmp"
> FAIL: gcc.dg/torture/pr57147-2.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none scan-tree-dump-not optimized "setjmp"
> FAIL: gcc.dg/torture/pr57147-2.c -O2 scan-tree-dump-not optimized "setjmp"
> FAIL: gcc.dg/torture/pr57147-2.c -O3 -g scan-tree-dump-not
> optimized "setjmp"
> FAIL: gcc.dg/torture/pr57147-2.c -Os scan-tree-dump-not optimized "setjmp"
>
> with unix/-fpic on x86. Should test pass with -fPIC?
Fixed thusly, committed as obvious.
Before my patch it was testing that setjmp actually remains, but it was
after noreturn function, I've changed it to test that it is optimized away,
because the new code does optimize unreachable setjmp away.
With -fpic we assume the function can be interposed and don't consider it
noreturn though.
2019-02-27 Jakub Jelinek
PR tree-optimization/89280
* gcc.dg/torture/pr57147-2.c (SetNaClSwitchExpectations): Add static
keyword.
--- gcc/testsuite/gcc.dg/torture/pr57147-2.c.jj 2019-02-27 09:40:01.860502737
+0100
+++ gcc/testsuite/gcc.dg/torture/pr57147-2.c2019-02-27 16:20:27.957843867
+0100
@@ -10,7 +10,7 @@ extern int _setjmp (struct __jmp_buf_tag
jmp_buf g_return_jmp_buf;
-void SetNaClSwitchExpectations (void)
+static void SetNaClSwitchExpectations (void)
{
__builtin_longjmp (g_return_jmp_buf, 1);
}
Jakub
Re: [libgo] Fix alignment issue in persistent allocator
On Sat, Feb 16, 2019 at 8:26 AM Eric Botcazou wrote: > > This gets rid of a bunch of Go failures on SPARC. > > Tested on x86-64/Linux, SPARC/Solaris and SPARC64/Linux. > > > 2019-02-16 Eric Botcazou > > * go/runtime/malloc.go (persistentalloc1): Always align the offset. Thanks, committed to mainline. Also sent upstream as https://golang.org/cl/163859. Ian
Re: C++ PATCH for c++/89511 - ICE with using-declarations and unscoped enumerator
On 2/26/19 5:13 PM, Marek Polacek wrote: Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which push_using_decl can't handle. http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742 says this is well-formed (but the scoped enum case is ill-formed). Nevertheless, the DR hasn't been resolved either way yet, and trying to accept a FUNCTION_DECL as a USING_DECL_SCOPE seems like a lot of work, and ultimately maybe both cases will be deemed ill-formed. This patch fixes the ICE by giving the pre-r211479 error while simultaneously keeping using-enum-[12].C working. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2019-02-26 Marek Polacek PR c++/89511 - ICE with using-declarations and unscoped enumerator. * parser.c (cp_parser_using_declaration): For an unscoped enum only use its context if it's a namespace declaration. * g++.dg/cpp0x/using-enum-3.C: New test. diff --git gcc/cp/parser.c gcc/cp/parser.c index e976008e94d..361dc9d065e 100644 --- gcc/cp/parser.c +++ gcc/cp/parser.c @@ -19412,7 +19412,8 @@ cp_parser_using_declaration (cp_parser* parser, /*is_declaration=*/true); if (!qscope) qscope = global_namespace; - else if (UNSCOPED_ENUM_P (qscope)) + else if (UNSCOPED_ENUM_P (qscope) + && TREE_CODE (CP_TYPE_CONTEXT (qscope)) == NAMESPACE_DECL) qscope = CP_TYPE_CONTEXT (qscope); Hmm, surely we want to handle class scope enums here, too? Maybe !TYPE_FUNCTION_SCOPE_P instead. Jason
Re: [PATCH] Improve arm and aarch64 casesi (PR target/70341)
On Fri, Feb 22, 2019 at 06:20:51PM -0600, Jakub Jelinek wrote: > Hi! > > The testcase in the PR doesn't hoist any memory loads from the large switch > before the switch on aarch64 and arm (unlike e.g. x86), because the > arm/aarch64 casesi patterns don't properly annotate the memory load from the > jump table. It is created by gen_* and in RTL directly one can't specify > the needed flags (MEM_READONLY_P and MEM_NOTRAP_P). > > Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi and > aarch64-linux, ok for trunk? > > 2019-02-23 Jakub Jelinek > > PR target/70341 > * config/aarch64/aarch64.md (casesi): Create the casesi_dispatch > MEM manually here, set MEM_READONLY_P and MEM_NOTRAP_P on it. This AArch64 part is OK for trunk. Thanks, James > --- gcc/config/aarch64/aarch64.md.jj 2019-01-19 09:39:18.847831222 +0100 > +++ gcc/config/aarch64/aarch64.md 2019-02-21 15:25:27.874532191 +0100 > @@ -622,13 +622,27 @@ (define_expand "casesi" > operands[0], operands[2], operands[4])); > > operands[2] = force_reg (DImode, gen_rtx_LABEL_REF (DImode, > operands[3])); > -emit_jump_insn (gen_casesi_dispatch (operands[2], operands[0], > - operands[3])); > +operands[2] > + = gen_rtx_UNSPEC (Pmode, gen_rtvec (2, operands[2], operands[0]), > + UNSPEC_CASESI); > +operands[2] = gen_rtx_MEM (DImode, operands[2]); > +MEM_READONLY_P (operands[2]) = 1; > +MEM_NOTRAP_P (operands[2]) = 1; > +emit_jump_insn (gen_casesi_dispatch (operands[2], operands[3])); > DONE; >} > ) > > -(define_insn "casesi_dispatch" > +(define_expand "casesi_dispatch" > + [(parallel > +[(set (pc) (match_operand:DI 0 "")) > + (clobber (reg:CC CC_REGNUM)) > + (clobber (match_scratch:DI 2)) > + (clobber (match_scratch:DI 3)) > + (use (label_ref:DI (match_operand 1 "")))])] > + "") > + > +(define_insn "*casesi_dispatch" >[(parallel > [(set (pc) > (mem:DI (unspec [(match_operand:DI 0 "register_operand" "r") > @@ -637,7 +651,7 @@ (define_insn "casesi_dispatch" > (clobber (reg:CC CC_REGNUM)) > (clobber (match_scratch:DI 3 "=r")) > (clobber (match_scratch:DI 4 "=r")) > - (use (label_ref (match_operand 2 "" "")))])] > + (use (label_ref:DI (match_operand 2 "" "")))])] >"" >"* >return aarch64_output_casesi (operands); > > Jakub
Re: C++ PATCH for c++/89511 - ICE with using-declarations and unscoped enumerator
On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote:
> On 2/26/19 5:13 PM, Marek Polacek wrote:
> > Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which
> > push_using_decl can't handle.
> >
> > http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742
> > says this is well-formed (but the scoped enum case is ill-formed).
> > Nevertheless, the DR hasn't been resolved either way yet, and trying
> > to accept a FUNCTION_DECL as a USING_DECL_SCOPE seems like a lot of
> > work, and ultimately maybe both cases will be deemed ill-formed.
> >
> > This patch fixes the ICE by giving the pre-r211479 error while
> > simultaneously keeping using-enum-[12].C working.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2019-02-26 Marek Polacek
> >
> > PR c++/89511 - ICE with using-declarations and unscoped enumerator.
> > * parser.c (cp_parser_using_declaration): For an unscoped enum
> > only use its context if it's a namespace declaration.
> >
> > * g++.dg/cpp0x/using-enum-3.C: New test.
> >
> > diff --git gcc/cp/parser.c gcc/cp/parser.c
> > index e976008e94d..361dc9d065e 100644
> > --- gcc/cp/parser.c
> > +++ gcc/cp/parser.c
> > @@ -19412,7 +19412,8 @@ cp_parser_using_declaration (cp_parser* parser,
> > /*is_declaration=*/true);
> > if (!qscope)
> > qscope = global_namespace;
> > - else if (UNSCOPED_ENUM_P (qscope))
> > + else if (UNSCOPED_ENUM_P (qscope)
> > + && TREE_CODE (CP_TYPE_CONTEXT (qscope)) == NAMESPACE_DECL)
> > qscope = CP_TYPE_CONTEXT (qscope);
>
> Hmm, surely we want to handle class scope enums here, too? Maybe
> !TYPE_FUNCTION_SCOPE_P instead.
I guess so. It doesn't really make a huge difference, because
do_class_using_decl will call error_not_base_type in either case, but it
changes the error message from
error: type ‘S’ is not a base type for type ‘S’
to
error: type ‘S::E’ is not a base type for type ‘S’
and I think we want to keep the former. Thus updated patch, with more
testing:
Bootstrap/regtest running on x86_64-linux, ok for trunk if it passes?
2019-02-27 Marek Polacek
PR c++/89511 - ICE with using-declaration and unscoped enumerator.
* parser.c (cp_parser_using_declaration): For an unscoped enum
only use its context if it's not a function declaration.
* g++.dg/cpp0x/using-enum-3.C: New test.
diff --git gcc/cp/parser.c gcc/cp/parser.c
index d9824e40803..5f694033496 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -19412,7 +19412,8 @@ cp_parser_using_declaration (cp_parser* parser,
/*is_declaration=*/true);
if (!qscope)
qscope = global_namespace;
- else if (UNSCOPED_ENUM_P (qscope))
+ else if (UNSCOPED_ENUM_P (qscope)
+ && !TYPE_FUNCTION_SCOPE_P (qscope))
qscope = CP_TYPE_CONTEXT (qscope);
if (access_declaration_p && cp_parser_error_occurred (parser))
diff --git gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
new file mode 100644
index 000..edc16890cb1
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
@@ -0,0 +1,21 @@
+// PR c++/89511
+// { dg-do compile { target c++11 } }
+
+void f ()
+{
+ enum e { a };
+ using e::a; // { dg-error "not a namespace or unscoped enum" }
+}
+
+struct S {
+ enum E { A };
+ using E::A; // { dg-error "type .S. is not a base type for type .S." }
+};
+
+namespace N {
+ enum E { B };
+}
+
+struct T {
+ using N::E::B; // { dg-error "using-declaration for non-member at class
scope" }
+};
Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during native feature detection
On Thu, Feb 07, 2019 at 04:43:24AM -0600, Tamar Christina wrote: > Hi All, > > Since this hasn't been reviewed yet anyway I've updated this patch to also > fix the memory leaks etc. > > -- > > This patch makes the feature detection code for AArch64 GCC not add features > automatically when the feature had no hwcaps string to match against. > > This means that -mcpu=native no longer adds feature flags such as +profile. > The behavior wasn't noticed before because at the time +profile was added a > bug > was preventing any feature bits from being added by native detections. > > The loop has also been changed as Jakub specified in order to avoid a memory > leak that was present in the existing code and to be slightly more efficient. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for trunk? OK. Is this also desirable for a backport? Thanks, James > > Thanks, > Tamar > > gcc/ChangeLog: > > 2019-02-07 Tamar Christina > > PR target/88530 > * config/aarch64/aarch64-option-extensions.def: Document it. > * config/aarch64/driver-aarch64.c (host_detect_local_cpu): Skip feature > if empty hwcaps. > > gcc/testsuite/ChangeLog: > > 2019-02-07 Tamar Christina > > PR target/88530 > * gcc.target/aarch64/options_set_10.c: New test. >
RE: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during native feature detection
Hi James, > -Original Message- > From: James Greenhalgh > Sent: Wednesday, February 27, 2019 17:22 > To: Tamar Christina > Cc: Jakub Jelinek ; Kyrill Tkachov > ; gcc-patches@gcc.gnu.org; nd > ; Richard Earnshaw ; Marcus > Shawcroft > Subject: Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored > during native feature detection > > On Thu, Feb 07, 2019 at 04:43:24AM -0600, Tamar Christina wrote: > > Hi All, > > > > Since this hasn't been reviewed yet anyway I've updated this patch to also > fix the memory leaks etc. > > > > -- > > > > This patch makes the feature detection code for AArch64 GCC not add > > features automatically when the feature had no hwcaps string to match > against. > > > > This means that -mcpu=native no longer adds feature flags such as +profile. > > The behavior wasn't noticed before because at the time +profile was > > added a bug was preventing any feature bits from being added by native > detections. > > > > The loop has also been changed as Jakub specified in order to avoid a > > memory leak that was present in the existing code and to be slightly more > efficient. > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > > > Ok for trunk? > > OK. Is this also desirable for a backport? Yes I believe we have this problem in GCC8 as well the profile extensions. Kind regards, Tamar > > Thanks, > James > > > > > Thanks, > > Tamar > > > > gcc/ChangeLog: > > > > 2019-02-07 Tamar Christina > > > > PR target/88530 > > * config/aarch64/aarch64-option-extensions.def: Document it. > > * config/aarch64/driver-aarch64.c (host_detect_local_cpu): Skip > feature > > if empty hwcaps. > > > > gcc/testsuite/ChangeLog: > > > > 2019-02-07 Tamar Christina > > > > PR target/88530 > > * gcc.target/aarch64/options_set_10.c: New test. > >
Re: C++ PATCH for c++/89511 - ICE with using-declarations and unscoped enumerator
On Wed, Feb 27, 2019 at 11:49 AM Marek Polacek wrote: > On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote: > > On 2/26/19 5:13 PM, Marek Polacek wrote: > > > Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which > > > push_using_decl can't handle. > > > > > > http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742 > > > says this is well-formed (but the scoped enum case is ill-formed). > > > Nevertheless, the DR hasn't been resolved either way yet, and trying > > > to accept a FUNCTION_DECL as a USING_DECL_SCOPE seems like a lot of > > > work, and ultimately maybe both cases will be deemed ill-formed. > > > > > > This patch fixes the ICE by giving the pre-r211479 error while > > > simultaneously keeping using-enum-[12].C working. > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > > > 2019-02-26 Marek Polacek > > > > > > PR c++/89511 - ICE with using-declarations and unscoped enumerator. > > > * parser.c (cp_parser_using_declaration): For an unscoped enum > > > only use its context if it's a namespace declaration. OK, though you probably want to adjust the ChangeLog entry. Jason
Re: RFA: PATCH to gimple-fold.c for c++/80916, bogus "static but not defined" warning
Ping^3? On Wed, Feb 13, 2019 at 4:28 PM Jason Merrill wrote: > > Ping^2 > > On Mon, Feb 4, 2019 at 4:09 PM Jason Merrill wrote: > > > > Ping > > > > On Fri, Jan 25, 2019 at 10:06 AM Jason Merrill wrote: > > > > > > Here we warn because i::dispatch has internal linkage (because l > > > does) and is never instantiated (because the vtable is never emitted). > > > The regression happened because devirtualization started adding it to > > > cgraph as a possible target. I think the way to fix this is to avoid > > > adding an undefined internal function to cgraph as a possible target, > > > since it is not, in fact, possible for it to be the actual target. > > > > > > I think that the best place to fix this would be in > > > can_refer_decl_in_current_unit_p, since the same reasoning applies to > > > other possible references. But we could fix it only in > > > gimple_get_virt_method_for_vtable. > > > > > > First patch tested x86_64-pc-linux-gnu. > > >
Re: C++ PATCH for c++/89511 - ICE with using-declarations and unscoped enumerator
On Wed, Feb 27, 2019 at 01:43:12PM -0500, Jason Merrill wrote: > On Wed, Feb 27, 2019 at 11:49 AM Marek Polacek wrote: > > On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote: > > > On 2/26/19 5:13 PM, Marek Polacek wrote: > > > > Here we ICE because the unscoped enum's context is a FUNCTION_DECL, > > > > which > > > > push_using_decl can't handle. > > > > > > > > http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742 > > > > says this is well-formed (but the scoped enum case is ill-formed). > > > > Nevertheless, the DR hasn't been resolved either way yet, and trying > > > > to accept a FUNCTION_DECL as a USING_DECL_SCOPE seems like a lot of > > > > work, and ultimately maybe both cases will be deemed ill-formed. > > > > > > > > This patch fixes the ICE by giving the pre-r211479 error while > > > > simultaneously keeping using-enum-[12].C working. > > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > > > > > 2019-02-26 Marek Polacek > > > > > > > > PR c++/89511 - ICE with using-declarations and unscoped enumerator. > > > > * parser.c (cp_parser_using_declaration): For an unscoped enum > > > > only use its context if it's a namespace declaration. > > OK, though you probably want to adjust the ChangeLog entry. Hold on, are you acking the second version, with TYPE_FUNCTION_SCOPE_P? That has a correct ChangeLog entry I believe. Marek
Re: C++ PATCH for c++/89511 - ICE with using-declarations and unscoped enumerator
On Wed, Feb 27, 2019 at 1:48 PM Marek Polacek wrote: > > On Wed, Feb 27, 2019 at 01:43:12PM -0500, Jason Merrill wrote: > > On Wed, Feb 27, 2019 at 11:49 AM Marek Polacek wrote: > > > On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote: > > > > On 2/26/19 5:13 PM, Marek Polacek wrote: > > > > > Here we ICE because the unscoped enum's context is a FUNCTION_DECL, > > > > > which > > > > > push_using_decl can't handle. > > > > > > > > > > http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742 > > > > > says this is well-formed (but the scoped enum case is ill-formed). > > > > > Nevertheless, the DR hasn't been resolved either way yet, and trying > > > > > to accept a FUNCTION_DECL as a USING_DECL_SCOPE seems like a lot of > > > > > work, and ultimately maybe both cases will be deemed ill-formed. > > > > > > > > > > This patch fixes the ICE by giving the pre-r211479 error while > > > > > simultaneously keeping using-enum-[12].C working. > > > > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > > > > > > > 2019-02-26 Marek Polacek > > > > > > > > > > PR c++/89511 - ICE with using-declarations and unscoped > > > > > enumerator. > > > > > * parser.c (cp_parser_using_declaration): For an unscoped enum > > > > > only use its context if it's a namespace declaration. > > > > OK, though you probably want to adjust the ChangeLog entry. > > Hold on, are you acking the second version, with TYPE_FUNCTION_SCOPE_P? That > has a correct ChangeLog entry I believe. Oops, yes, quote pruning fail. :) Jason
[PATCH] Fix PR rtl-optimization/89490
Hi!
This patch fixes a P1 regression due to the recently introduced
more aggressive constant string merging, which does not work
correctly in object blocks consisting of STRING_CST w/o proper
zero-termination.
Fixed by avoiding creation of block objects for objects located
in mergeable sections.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu,
powerpc64le-linux, and powerpc64-linux (-m32/-m64)
with help from Jakub.
Is it OK for trunk?
Thanks
Bernd.
2019-02-27 Bernd Edlinger
PR rtl-optimization/89490
* varasm.c (get_block_for_section): Bail out for mergeable sections.
(default_use_anchors_for_symbol_p, output_object_block): Assert the
block section is not mergeable.
--- gcc/varasm.c.orig 2019-02-21 23:50:24.0 +0100
+++ gcc/varasm.c 2019-02-27 11:33:32.741967812 +0100
@@ -363,7 +363,11 @@ use_object_blocks_p (void)
/* Return the object_block structure for section SECT. Create a new
structure if we haven't created one already. Return null if SECT
- itself is null. */
+ itself is null. Return also null for mergeable sections since
+ section anchors can't be used in mergeable sections anyway,
+ because the linker might move objects around, and using the
+ object blocks infrastructure in that case is both a waste and a
+ maintenance burden. */
static struct object_block *
get_block_for_section (section *sect)
@@ -373,6 +377,9 @@ get_block_for_section (section *sect)
if (sect == NULL)
return NULL;
+ if (sect->common.flags & SECTION_MERGE)
+return NULL;
+
object_block **slot
= object_block_htab->find_slot_with_hash (sect, hash_section (sect),
INSERT);
@@ -7014,14 +7021,13 @@ default_asm_output_anchor (rtx symbol)
bool
default_use_anchors_for_symbol_p (const_rtx symbol)
{
- section *sect;
tree decl;
+ section *sect = SYMBOL_REF_BLOCK (symbol)->sect;
- /* Don't use anchors for mergeable sections. The linker might move
- the objects around. */
- sect = SYMBOL_REF_BLOCK (symbol)->sect;
- if (sect->common.flags & SECTION_MERGE)
-return false;
+ /* This function should only be called with non-zero SYMBOL_REF_BLOCK,
+ furthermore get_block_for_section should not create object blocks
+ for mergeable sections. */
+ gcc_checking_assert (sect && !(sect->common.flags & SECTION_MERGE));
/* Don't use anchors for small data sections. The small data register
acts as an anchor for such sections. */
@@ -7630,6 +7636,7 @@ output_object_block (struct object_block
else
switch_to_section (block->sect);
+ gcc_checking_assert (!(block->sect->common.flags & SECTION_MERGE));
assemble_align (block->alignment);
/* Define the values of all anchors relative to the current section
Re: [PATCH] Fix PR rtl-optimization/89490
On Wed, Feb 27, 2019 at 07:44:40PM +, Bernd Edlinger wrote: > This patch fixes a P1 regression due to the recently introduced > more aggressive constant string merging, which does not work > correctly in object blocks consisting of STRING_CST w/o proper > zero-termination. > > Fixed by avoiding creation of block objects for objects located > in mergeable sections. > > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu, > powerpc64le-linux, and powerpc64-linux (-m32/-m64) > with help from Jakub. > > Is it OK for trunk? > > > Thanks > Bernd. > 2019-02-27 Bernd Edlinger > > PR rtl-optimization/89490 > * varasm.c (get_block_for_section): Bail out for mergeable sections. > (default_use_anchors_for_symbol_p, output_object_block): Assert the > block section is not mergeable. Ok, thanks. Jakub
[wwwdocs] Buildstat update for 6.x
Latest results for 6.x. -tgc Testresults for 6.5.0: hppa2.0w-hp-hpux11.11 hppa64-hp-hpux11.11 powerpc64le-unknown-linux-gnu powerpc64-unknown-linux-gnu x86_64-w64-mingw32 --- /home/tgc/projects/gcc/wwwdocs/htdocs/gcc-6/buildstat.html 2019-02-27 18:33:53.555978983 +0100 +++ /tmp/tmp.lzeoOdeDcx 2019-02-27 21:33:15.747085861 +0100 @@ -25,6 +25,22 @@ +hppa2.0w-hp-hpux11.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg03879.html";>6.5.0 + + + + +hppa64-hp-hpux11.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg04150.html";>6.5.0 + + + + i386-pc-solaris2.10 Test results: @@ -61,6 +77,12 @@ powerpc64le-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg03888.html";>6.5.0, https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00368.html";>6.3.0, https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02608.html";>6.2.0, https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg02903.html";>6.1.0 @@ -71,6 +93,17 @@ powerpc64-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg03903.html";>6.5.0, https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00369.html";>6.3.0, https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02609.html";>6.2.0, https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg02913.html";>6.1.0 @@ -151,6 +184,7 @@ x86_64-w64-mingw32 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg03894.html";>6.5.0, https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg01182.html";>6.4.0, https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg02327.html";>6.3.0, https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02545.html";>6.2.0,
[wwwdocs] Buildstat update for 7.x
Latest results for 7.x. -tgc Testresults for 7.4.0: x86_64-w64-mingw32 --- /home/tgc/projects/gcc/wwwdocs/htdocs/gcc-7/buildstat.html 2019-02-27 18:33:53.559979051 +0100 +++ /tmp/tmp.fa3s1NLqiV 2019-02-27 21:38:18.452766358 +0100 @@ -126,6 +126,7 @@ x86_64-w64-mingw32 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg00222.html";>7.4.0, https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00308.html";>7.3.0, https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg01364.html";>7.2.0, https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00410.html";>7.1.0
C++ PATCH for c++/88857 - ICE with value-initialization of argument in template
build_value_init doesn't work in templates (for non-scalar/array types,
anyway), so avoid this situation, much like in build_new_method_call_1.
We're calling convert_like_real because when there's only one non-viable
candidate function, build_new_function_call calls cp_build_function_call_vec
to give errors and that calls convert_arguments. If there's a viable
candidate, build_new_function_call calls build_over_call instead, and that,
when in a template, doesn't process the arguments.
I ran the testsuite to see if we ever call build_value_init in a template
in convert_like_real and nothing turned up.
Bootstrapped/regtested on x86_64-linux, ok for trunk/8?
2019-02-27 Marek Polacek
PR c++/88857 - ICE with value-initialization of argument in template.
* call.c (convert_like_real): Don't call build_value_init in template.
* g++.dg/cpp0x/initlist-value4.C: New test.
diff --git gcc/cp/call.c gcc/cp/call.c
index c53eb582aac..fb67d905acd 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -7005,7 +7005,8 @@ convert_like_real (conversion *convs, tree expr, tree fn,
int argnum,
/* If we're initializing from {}, it's value-initialization. */
if (BRACE_ENCLOSED_INITIALIZER_P (expr)
&& CONSTRUCTOR_NELTS (expr) == 0
- && TYPE_HAS_DEFAULT_CONSTRUCTOR (totype))
+ && TYPE_HAS_DEFAULT_CONSTRUCTOR (totype)
+ && !processing_template_decl)
{
bool direct = CONSTRUCTOR_IS_DIRECT_INIT (expr);
if (abstract_virtuals_error_sfinae (NULL_TREE, totype, complain))
diff --git gcc/testsuite/g++.dg/cpp0x/initlist-value4.C
gcc/testsuite/g++.dg/cpp0x/initlist-value4.C
new file mode 100644
index 000..427147ff7f2
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/initlist-value4.C
@@ -0,0 +1,12 @@
+// PR c++/88857
+// { dg-do compile { target c++11 } }
+
+class S { int a; };
+void foo (const S &, int);
+
+template
+void
+bar ()
+{
+ foo ({}); // { dg-error "too few arguments to function" }
+}
[C++ PATCH] PR c++/86969 - ICE with constexpr if and recursive generic lambdas.
Here, the problem was that extract_local_specs wasn't seeing that we use
'self' inside the lambda in the else of the inner constexpr if, because we
don't walk into lambda bodies and we didn't capture it in the lambda because
'self' is still dependent. Marek recently changed process_outer_var_ref to
do more implicit capture in templates; this example shows that we should
always capture non-packs, so that we can continue to not walk into lambda
bodies. We do walk into lambda bodies for pack expansions, so we can delay
deciding whether we're capturing a single element or the entire pack.
Immediately capturing a VLA means we need to create a dependent VLA capture
type, and not in the context of the lambda op(), since trying to look up the
instantiation of the op() while we're substituting into the capture list
would crash. So I force TYPE_CONTEXT and the binding level out to the
enclosing function before pushtag, avoid adding a TAG_DEFN, and instead
force the type to be complete in tsubst_lambda_expr.
Tested x86_64-pc-linux-gnu, applying to trunk.
* semantics.c (process_outer_var_ref): Do capture dependent vars.
* class.c (finish_struct): Only add TAG_DEFN if T is in
current_function_decl.
* lambda.c (vla_capture_type): Force the capture type out into the
lambda's enclosing function.
(add_capture): Pass in the lambda.
* pt.c (tsubst_lambda_expr): complete_type a VLA capture type.
---
gcc/cp/class.c | 1 +
gcc/cp/lambda.c | 28 ++---
gcc/cp/pt.c | 4 +++
gcc/cp/semantics.c | 8 +++---
gcc/testsuite/g++.dg/cpp1z/constexpr-if27.C | 22
gcc/cp/ChangeLog| 11
6 files changed, 68 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if27.C
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index f44acfd62b5..830ede56af8 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -7246,6 +7246,7 @@ finish_struct (tree t, tree attributes)
error ("trying to finish struct, but kicked out due to previous parse
errors");
if (processing_template_decl && at_function_scope_p ()
+ && TYPE_CONTEXT (t) == current_function_decl
/* Lambdas are defined by the LAMBDA_EXPR. */
&& !LAMBDA_TYPE_P (t))
add_stmt (build_min (TAG_DEFN, t));
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index d178f15a4da..c25df2fbc0e 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -479,9 +479,31 @@ static GTY(()) tree max_id;
an array of runtime length. */
static tree
-vla_capture_type (tree array_type)
+vla_capture_type (tree array_type, tree lambda)
{
- tree type = xref_tag (record_type, make_anon_name (), ts_current, false);
+ tree closure = LAMBDA_EXPR_CLOSURE (lambda);
+ tree type = make_class_type (RECORD_TYPE);
+ cp_binding_level *slev = current_binding_level;
+ if (closure)
+{
+ /* If we're already inside the lambda body, force the capture type out
+into the enclosing context, so we don't crash trying to instantiate
+the capture field in tsubst_lambda_expr. We won't have a TAG_DEFN
+from finish_struct in the enclosing context, which we work around in
+tsubst_lambda_expr. */
+ TYPE_CONTEXT (type) = TYPE_CONTEXT (closure);
+ cp_binding_level *b = current_binding_level;
+ for (;; b = b->level_chain)
+ if (b->this_entity == closure)
+ {
+ while (b->this_entity == closure)
+ b = b->level_chain;
+ break;
+ }
+ current_binding_level = b;
+}
+ type = pushtag (make_anon_name (), type, ts_current);
+ current_binding_level = slev;
xref_basetypes (type, NULL_TREE);
type = begin_class_definition (type);
if (!ptr_id)
@@ -541,7 +563,7 @@ add_capture (tree lambda, tree id, tree orig_init, bool
by_reference_p,
initializer = build_constructor_va (init_list_type_node, 2,
NULL_TREE, build_address (elt),
NULL_TREE, array_type_nelts (type));
- type = vla_capture_type (type);
+ type = vla_capture_type (type, lambda);
}
else if (!dependent_type_p (type)
&& variably_modified_type_p (type, NULL_TREE))
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d678e278078..673ea8e2258 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -17989,6 +17989,10 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
if (PACK_EXPANSION_P (ofield))
ofield = PACK_EXPANSION_PATTERN (ofield);
tree field = tsubst_decl (ofield, args, complain);
+ if (DECL_VLA_CAPTURE_P (ofield))
+ /* The type of a VLA capture might not have a TAG_DEFN in the enclosing
+ context, so complete it here. */
+ complete_type (TREE_TYPE (field));
if (DECL_PACK_P (ofield) && !DECL_N
libgo patch committed: Handle function descriptors correctly
This patch changes libgo to handle function descriptors correctly.
When using PPC64 ELF ABI v1 a function address is not a PC, but is the
address of a function descriptor. The first field in the function
descriptor is the actual PC (see
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES).
The libbacktrace library knows about this, and libgo uses actual PC
values consistently except for the helper function funcPC that appears
in both runtime and runtime/pprof.
This patch fixes funcPC by recording, in the internal/cpu package,
whether function descriptors are being used. We have to check for
function descriptors using a C compiler check, because GCC can be
configured using --with-abi to select the ELF ABI to use.
This fixes GCC PR 89172.
Bootstrapped and ran Go tests on x86_64-pc-linux-gnu and
ppc64-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269258)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-c9581de3804f94c5a74ce14befce5c57368722b9
+74533ed435a1a77e6f9ec8f6cf5db1695c2568e8
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am (revision 269196)
+++ libgo/Makefile.am (working copy)
@@ -539,6 +539,7 @@ s-cpu: Makefile
rm -f cpugen.go.tmp
echo "package cpu" > cpugen.go.tmp
echo "const CacheLinePadSize = `$(SHELL) $(srcdir)/goarch.sh $(GOARCH)
cachelinesize`" >> cpugen.go.tmp
+ echo "const FunctionDescriptors = $(FUNCTION_DESCRIPTORS)" >>
cpugen.go.tmp
$(SHELL) $(srcdir)/mvifdiff.sh cpugen.go.tmp cpugen.go
$(STAMP) $@
Index: libgo/configure.ac
===
--- libgo/configure.ac (revision 269196)
+++ libgo/configure.ac (working copy)
@@ -353,6 +353,20 @@ AC_SUBST(GOARCH)
AC_SUBST(ALLGOARCH)
AC_SUBST(ALLGOARCHFAMILY)
+FUNCTION_DESCRIPTORS=false
+case ${host} in
+ rs6000*-*-* | powerpc*-*-*)
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([
+#if _CALL_ELF == 1
+#error descriptors
+#endif
+])],
+ [FUNCTION_DESCRIPTORS=false],
+ [FUNCTION_DESCRIPTORS=true])
+;;
+esac
+AC_SUBST(FUNCTION_DESCRIPTORS)
+
dnl Some files are only present when needed for specific architectures.
GO_LIBCALL_OS_FILE=
GO_LIBCALL_OS_ARCH_FILE=
Index: libgo/go/runtime/pprof/proto.go
===
--- libgo/go/runtime/pprof/proto.go (revision 269196)
+++ libgo/go/runtime/pprof/proto.go (working copy)
@@ -8,6 +8,7 @@ import (
"bytes"
"compress/gzip"
"fmt"
+ internalcpu "internal/cpu"
"io"
"io/ioutil"
"runtime"
@@ -28,7 +29,14 @@ func funcPC(f interface{}) uintptr {
data unsafe.Pointer
}
i := (*iface)(unsafe.Pointer(&f))
- return **(**uintptr)(i.data)
+ r := **(**uintptr)(i.data)
+ if internalcpu.FunctionDescriptors {
+ // With PPC64 ELF ABI v1 function descriptors the
+ // function address is a pointer to a struct whose
+ // first field is the actual PC.
+ r = *(*uintptr)(unsafe.Pointer(r))
+ }
+ return r
}
// A profileBuilder writes a profile incrementally from a
Index: libgo/go/runtime/proc.go
===
--- libgo/go/runtime/proc.go(revision 269196)
+++ libgo/go/runtime/proc.go(working copy)
@@ -446,7 +446,14 @@ func releaseSudog(s *sudog) {
//go:nosplit
func funcPC(f interface{}) uintptr {
i := (*iface)(unsafe.Pointer(&f))
- return **(**uintptr)(i.data)
+ r := **(**uintptr)(i.data)
+ if cpu.FunctionDescriptors {
+ // With PPC64 ELF ABI v1 function descriptors the
+ // function address is a pointer to a struct whose
+ // first field is the actual PC.
+ r = *(*uintptr)(unsafe.Pointer(r))
+ }
+ return r
}
func lockedOSThread() bool {
[C++ PATCH] Reject constexpr functions with function-try-block (PR c++/89513)
Hi!
C++ before 2a says that constexpr constructors may not have function-try-block
body, for other constexpr functions it instead says that the function body
can be (=delete, =default or compound-statement), but that rules out
function-try-block as well.
For ctors we were diagnostic this in
build_constexpr_constructor_member_initializers, but with worse locus, so
this patch diagnoses it for both ctors and other constexpr functions in the
same place.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or would you prefer to have P1002R1 implemented and thus make this perhaps a
pedwarn before cxx2a, similarly for the error on try block in the body and
tweak build_constexpr_constructor_member_initializers? I think constexpr
evaluation handles TRY_BLOCK already.
2019-02-27 Jakub Jelinek
PR c++/89513
* parser.c (cp_parser_ctor_initializer_opt_and_function_body):
Diagnose constexpr ctor or function with function-try-block.
Formatting fix.
* constexpr.c (build_constexpr_constructor_member_initializers):
Don't diagnose constexpr ctor with function-try-block here.
* g++.dg/cpp0x/constexpr-89513.C: New test.
--- gcc/cp/parser.c.jj 2019-02-23 11:32:45.705614155 +0100
+++ gcc/cp/parser.c 2019-02-27 14:18:26.211248671 +0100
@@ -22589,11 +22589,22 @@ cp_parser_ctor_initializer_opt_and_funct
bool in_function_try_block)
{
tree body, list;
- const bool check_body_p =
- DECL_CONSTRUCTOR_P (current_function_decl)
- && DECL_DECLARED_CONSTEXPR_P (current_function_decl);
+ const bool check_body_p
+ = (DECL_CONSTRUCTOR_P (current_function_decl)
+ && DECL_DECLARED_CONSTEXPR_P (current_function_decl));
tree last = NULL;
+ if (in_function_try_block
+ && DECL_DECLARED_CONSTEXPR_P (current_function_decl))
+{
+ if (DECL_CONSTRUCTOR_P (current_function_decl))
+ error ("body of % constructor cannot be "
+ "a function-try-block");
+ else
+ error ("body of % function cannot be "
+ "a function-try-block");
+}
+
/* Begin the function body. */
body = begin_function_body ();
/* Parse the optional ctor-initializer. */
--- gcc/cp/constexpr.c.jj 2019-02-26 15:37:06.475371073 +0100
+++ gcc/cp/constexpr.c 2019-02-27 14:17:34.434096156 +0100
@@ -627,11 +627,8 @@ build_constexpr_constructor_member_initi
}
}
else if (TREE_CODE (body) == TRY_BLOCK)
-{
- error ("body of % constructor cannot be "
-"a function-try-block");
- return error_mark_node;
-}
+/* This should have been diagnosed earlier. */
+return error_mark_node;
else if (EXPR_P (body))
ok = build_data_member_initialization (body, &vec);
else
--- gcc/testsuite/g++.dg/cpp0x/constexpr-89513.C.jj 2019-02-27
14:28:50.280033938 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-89513.C2019-02-27
14:34:51.585120108 +0100
@@ -0,0 +1,48 @@
+// PR c++/89513
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+constexpr bool foo ()
+try { // { dg-error "body of 'constexpr' function cannot be a
function-try-block" }
+ return true;
+} catch (...) {
+ return false;
+} // { dg-error "body of 'constexpr' function" "" {
target c++11_only } }
+
+#if __cplusplus > 201103L
+constexpr bool bar ()
+try { // { dg-error "body of 'constexpr' function cannot be a
function-try-block" "" { target c++14 } }
+ try {// { dg-error "'try' in 'constexpr' function"
"" { target c++14 } }
+return true;
+ } catch (int) {
+return false;
+ }
+} catch (...) {
+ return false;
+}
+
+constexpr bool baz ()
+{
+ try { return true; } catch (...) { return false; } // { dg-error "'try' in
'constexpr' function" "" { target c++14 } }
+}
+#endif
+
+struct S {
+ constexpr S () try : m (1) // { dg-error "body of 'constexpr' constructor
cannot be a function-try-block" }
+ {
+#if __cplusplus > 201103L
+try { // { dg-error "'try' in 'constexpr' function" "" {
target c++14 } }
+} catch (int) {
+}
+#endif
+ } catch (...) {
+ }
+ int m;
+};
+
+struct T {
+ constexpr T ()
+ try {// { dg-error "body of 'constexpr' constructor
cannot be a function-try-block" }
+ } catch (...) {
+ }
+};
Jakub
[PATCH] Fix convert.c ICEs on invalid builtin calls (PR c/89520)
Hi!
convert.c doesn't verify the CALL_EXPRs to builtin functions have exactly
one argument (and a scalar float one) and can ICE if that is not the case
due to K&R declarations of the library functions and passing too few
arguments.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2019-02-27 Jakub Jelinek
PR c/89520
* convert.c (convert_to_real_1, convert_to_integer_1): Punt for
builtins if they don't have a single scalar floating point argument.
Formatting fixes.
* gcc.dg/pr89520-1.c: New test.
* gcc.dg/pr89520-2.c: New test.
--- gcc/convert.c.jj2019-02-11 18:04:18.253586235 +0100
+++ gcc/convert.c 2019-02-27 21:01:19.176180131 +0100
@@ -216,12 +216,15 @@ convert_to_real_1 (tree type, tree expr,
CASE_MATHFN (FABS)
CASE_MATHFN (LOGB)
#undef CASE_MATHFN
+ if (call_expr_nargs (expr) != 1
+ || !SCALAR_FLOAT_TYPE_P (TREE_TYPE (CALL_EXPR_ARG (expr, 0
+ break;
{
tree arg0 = strip_float_extensions (CALL_EXPR_ARG (expr, 0));
tree newtype = type;
- /* We have (outertype)sqrt((innertype)x). Choose the wider mode
from
-the both as the safe type for operation. */
+ /* We have (outertype)sqrt((innertype)x). Choose the wider mode
+from the both as the safe type for operation. */
if (TYPE_PRECISION (TREE_TYPE (arg0)) > TYPE_PRECISION (type))
newtype = TREE_TYPE (arg0);
@@ -618,7 +621,8 @@ convert_to_integer_1 (tree type, tree ex
CASE_FLT_FN (BUILT_IN_ROUND):
CASE_FLT_FN_FLOATN_NX (BUILT_IN_ROUND):
/* Only convert in ISO C99 mode and with -fno-math-errno. */
- if (!targetm.libc_has_function (function_c99_misc) || flag_errno_math)
+ if (!targetm.libc_has_function (function_c99_misc)
+ || flag_errno_math)
break;
if (outprec < TYPE_PRECISION (integer_type_node)
|| (outprec == TYPE_PRECISION (integer_type_node)
@@ -641,7 +645,8 @@ convert_to_integer_1 (tree type, tree ex
CASE_FLT_FN (BUILT_IN_RINT):
CASE_FLT_FN_FLOATN_NX (BUILT_IN_RINT):
/* Only convert in ISO C99 mode and with -fno-math-errno. */
- if (!targetm.libc_has_function (function_c99_misc) || flag_errno_math)
+ if (!targetm.libc_has_function (function_c99_misc)
+ || flag_errno_math)
break;
if (outprec < TYPE_PRECISION (integer_type_node)
|| (outprec == TYPE_PRECISION (integer_type_node)
@@ -657,14 +662,20 @@ convert_to_integer_1 (tree type, tree ex
CASE_FLT_FN (BUILT_IN_TRUNC):
CASE_FLT_FN_FLOATN_NX (BUILT_IN_TRUNC):
- return convert_to_integer_1 (type, CALL_EXPR_ARG (s_expr, 0), dofold);
+ if (call_expr_nargs (s_expr) != 1
+ || !SCALAR_FLOAT_TYPE_P (TREE_TYPE (CALL_EXPR_ARG (s_expr, 0
+ break;
+ return convert_to_integer_1 (type, CALL_EXPR_ARG (s_expr, 0),
+ dofold);
default:
break;
}
- if (fn)
-{
+ if (fn
+ && call_expr_nargs (s_expr) == 1
+ && SCALAR_FLOAT_TYPE_P (TREE_TYPE (CALL_EXPR_ARG (s_expr, 0
+ {
tree newexpr = build_call_expr (fn, 1, CALL_EXPR_ARG (s_expr, 0));
return convert_to_integer_1 (type, newexpr, dofold);
}
@@ -694,7 +705,9 @@ convert_to_integer_1 (tree type, tree ex
break;
}
- if (fn)
+ if (fn
+ && call_expr_nargs (s_expr) == 1
+ && SCALAR_FLOAT_TYPE_P (TREE_TYPE (CALL_EXPR_ARG (s_expr, 0
{
tree newexpr = build_call_expr (fn, 1, CALL_EXPR_ARG (s_expr, 0));
return convert_to_integer_1 (type, newexpr, dofold);
--- gcc/testsuite/gcc.dg/pr89520-1.c.jj 2019-02-27 21:12:00.036510855 +0100
+++ gcc/testsuite/gcc.dg/pr89520-1.c2019-02-27 21:10:07.306467864 +0100
@@ -0,0 +1,13 @@
+/* PR c/89520 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -w" } */
+
+#define A(name) __typeof (__builtin_##name (0)) name (); long name##1 () {
return name (); }
+#define B(name) A(name) A(name##f) A(name##l)
+B (ceil)
+B (floor)
+B (round)
+B (trunc)
+B (nearbyint)
+B (rint)
+B (logb)
--- gcc/testsuite/gcc.dg/pr89520-2.c.jj 2019-02-27 21:17:42.753561235 +0100
+++ gcc/testsuite/gcc.dg/pr89520-2.c2019-02-27 21:17:19.607963044 +0100
@@ -0,0 +1,42 @@
+/* PR c/89520 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -w" } */
+
+#define A(name) __typeof (__builtin_##name (0)) name (); \
+ float name##1 () { return name (); } \
+ double name##2 () { return name (); }
+#define B(name) A(name) A(name##l)
+B (cosh)
+B (exp)
+B (exp10)
+B (exp2)
+B (expm1)
+B (gamma)
+B (j0)
+B (j1)
+B (lgamma)
+B (pow10)
+B (sinh)
+B (tgamma)
+B (y0)
+B (y1)
+B (acos)
+B (acosh)
+B (asin)
+B (asinh)
+B (atan)
+B (atanh)
+B (cbrt)
+B
[C PATCH] Fix -Wbuiltin-declaration-mismatch (PR c/89525)
Hi!
As the following testcase shows, with -w we don't emit
-Wbuiltin-declaration-mismatch warnings (correct), but emit weird messages:
~/src/gcc/obj46/gcc/xgcc -B ~/src/gcc/obj46/gcc/ -w pr89525.c -S
pr89525.c: In function ‘foo’:
pr89525.c:5:8: note: declared here
5 | double sqrt (); /* { dg-bogus "declared here" } */
|^~~~
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2019-02-27 Jakub Jelinek
PR c/89525
* c-typeck.c (convert_arguments): Call inform_declaration only if
the previous warning_at call returned true.
* gcc.dg/pr89525.c: New test.
--- gcc/c/c-typeck.c.jj 2019-01-24 20:15:16.913439861 +0100
+++ gcc/c/c-typeck.c2019-02-27 21:33:37.815873072 +0100
@@ -3509,12 +3509,10 @@ convert_arguments (location_t loc, vec
[PR fortran/89516, patch] - ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506
Adding -Wsurprising as option to gfortran exercised a code path
that I hadn't seen when working on simplifications for the TRANSFER
intrinsic. While regtesting, I realized that one of the checks was
too strict when the MOLD argument was scalar and of size 0 and should
only apply to array arguments. I adjusted the corresponding testcase.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Harald
2019-02-27 Harald Anlauf
PR fortran/89516
* check.c (gfc_calculate_transfer_sizes): Correct checks for cases
where storage size of elements of MOLD is 0.
2019-02-27 Harald Anlauf
PR fortran/89516
* gfortran.dg/pr89492.f90: Adjust testcase.
* gfortran.dg/transfer_check_5.f90: New test.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269264)
+++ gcc/fortran/check.c (working copy)
@@ -5487,23 +5487,29 @@
if (!gfc_element_size (mold, &result_elt_size))
return false;
- if (result_elt_size == 0 && *source_size > 0)
+ /* If the storage size of SOURCE is greater than zero and MOLD is an array,
+ * a scalar with the type and type parameters of MOLD shall not have a
+ * storage size equal to zero.
+ * If MOLD is a scalar and SIZE is absent, the result is a scalar.
+ * If MOLD is an array and SIZE is absent, the result is an array and of
+ * rank one. Its size is as small as possible such that its physical
+ * representation is not shorter than that of SOURCE.
+ * If SIZE is present, the result is an array of rank one and size SIZE.
+ */
+ if (result_elt_size == 0 && *source_size > 0 && !size
+ && mold->expr_type == EXPR_ARRAY)
{
- gfc_error ("% argument of % intrinsic at %L "
- "shall not have storage size 0 when % "
+ gfc_error ("% argument of % intrinsic at %L is an "
+"array and shall not have storage size 0 when % "
"argument has size greater than 0", &mold->where);
return false;
}
- /* If MOLD is a scalar and SIZE is absent, the result is a scalar.
- * If MOLD is an array and SIZE is absent, the result is an array and of
- * rank one. Its size is as small as possible such that its physical
- * representation is not shorter than that of SOURCE.
- */
if (result_elt_size == 0 && *source_size == 0 && !size)
{
*result_size = 0;
- *result_length_p = 0;
+ if (result_length_p)
+ *result_length_p = 0;
return true;
}
Index: gcc/testsuite/gfortran.dg/pr89492.f90
===
--- gcc/testsuite/gfortran.dg/pr89492.f90 (revision 269264)
+++ gcc/testsuite/gfortran.dg/pr89492.f90 (working copy)
@@ -19,9 +19,9 @@
integer, parameter :: n(l) = l
print *, k,i,l,m,j,n
print *, transfer(1,[''])! { dg-error "shall not have
storage size 0" }
- print *, transfer(1, '' )! { dg-error "shall not have
storage size 0" }
+ print *, transfer(1, '' )! No error
print *, size(transfer(1,[''])) ! { dg-error "shall not have
storage size 0" }
- print *, len (transfer(1, '' )) ! { dg-error "shall not have
storage size 0" }
+ print *, len (transfer(1, '' )) ! No error
print *, size(transfer([1],[bug4()])) ! { dg-error "shall not have
storage size 0" }
print *, transfer(transfer([1],[bug4()]),[1]) ! { dg-error "shall not have
storage size 0" }
end program bug4a
Index: gcc/testsuite/gfortran.dg/transfer_check_5.f90
===
--- gcc/testsuite/gfortran.dg/transfer_check_5.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/transfer_check_5.f90 (working copy)
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! { dg-options "-Wsurprising" }
+!
+! PR fortran/89516 - ICE in gfc_calculate_transfer_sizes at
gcc/fortran/check.c:5506
+! Found by Martin Liška
+
+program test
+ character(*), parameter :: n = ''
+ character(*), parameter :: o = transfer ([''], n)
+ print *, transfer(1,'',size=0) ! No warning
+ print *, transfer(1,'',size=1) ! No warning
+ print *, transfer('',1,size=0) ! No warning
+ print *, transfer('',1,size=1) ! { dg-warning "has partly undefined result" }
+end program test
Re: C++ PATCH for c++/88857 - ICE with value-initialization of argument in template
On 2/27/19 4:22 PM, Marek Polacek wrote: build_value_init doesn't work in templates (for non-scalar/array types, anyway), so avoid this situation, much like in build_new_method_call_1. We're calling convert_like_real because when there's only one non-viable candidate function, build_new_function_call calls cp_build_function_call_vec to give errors and that calls convert_arguments. If there's a viable candidate, build_new_function_call calls build_over_call instead, and that, when in a template, doesn't process the arguments. I ran the testsuite to see if we ever call build_value_init in a template in convert_like_real and nothing turned up. Bootstrapped/regtested on x86_64-linux, ok for trunk/8? 2019-02-27 Marek Polacek PR c++/88857 - ICE with value-initialization of argument in template. * call.c (convert_like_real): Don't call build_value_init in template. OK. Jason
Re: [C++ PATCH] Reject constexpr functions with function-try-block (PR c++/89513)
On 2/27/19 5:37 PM, Jakub Jelinek wrote:
Hi!
C++ before 2a says that constexpr constructors may not have function-try-block
body, for other constexpr functions it instead says that the function body
can be (=delete, =default or compound-statement), but that rules out
function-try-block as well.
For ctors we were diagnostic this in
build_constexpr_constructor_member_initializers, but with worse locus, so
this patch diagnoses it for both ctors and other constexpr functions in the
same place.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or would you prefer to have P1002R1 implemented and thus make this perhaps a
pedwarn before cxx2a, similarly for the error on try block in the body and
tweak build_constexpr_constructor_member_initializers? I think constexpr
evaluation handles TRY_BLOCK already.
That sounds better, yes.
2019-02-27 Jakub Jelinek
PR c++/89513
* parser.c (cp_parser_ctor_initializer_opt_and_function_body):
Diagnose constexpr ctor or function with function-try-block.
Formatting fix.
* constexpr.c (build_constexpr_constructor_member_initializers):
Don't diagnose constexpr ctor with function-try-block here.
* g++.dg/cpp0x/constexpr-89513.C: New test.
--- gcc/cp/parser.c.jj 2019-02-23 11:32:45.705614155 +0100
+++ gcc/cp/parser.c 2019-02-27 14:18:26.211248671 +0100
@@ -22589,11 +22589,22 @@ cp_parser_ctor_initializer_opt_and_funct
bool in_function_try_block)
{
tree body, list;
- const bool check_body_p =
- DECL_CONSTRUCTOR_P (current_function_decl)
- && DECL_DECLARED_CONSTEXPR_P (current_function_decl);
+ const bool check_body_p
+ = (DECL_CONSTRUCTOR_P (current_function_decl)
+ && DECL_DECLARED_CONSTEXPR_P (current_function_decl));
tree last = NULL;
+ if (in_function_try_block
+ && DECL_DECLARED_CONSTEXPR_P (current_function_decl))
+{
+ if (DECL_CONSTRUCTOR_P (current_function_decl))
+ error ("body of % constructor cannot be "
+ "a function-try-block");
+ else
+ error ("body of % function cannot be "
+ "a function-try-block");
+}
+
/* Begin the function body. */
body = begin_function_body ();
/* Parse the optional ctor-initializer. */
--- gcc/cp/constexpr.c.jj 2019-02-26 15:37:06.475371073 +0100
+++ gcc/cp/constexpr.c 2019-02-27 14:17:34.434096156 +0100
@@ -627,11 +627,8 @@ build_constexpr_constructor_member_initi
}
}
else if (TREE_CODE (body) == TRY_BLOCK)
-{
- error ("body of % constructor cannot be "
-"a function-try-block");
- return error_mark_node;
-}
+/* This should have been diagnosed earlier. */
+return error_mark_node;
else if (EXPR_P (body))
ok = build_data_member_initialization (body, &vec);
else
--- gcc/testsuite/g++.dg/cpp0x/constexpr-89513.C.jj 2019-02-27
14:28:50.280033938 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-89513.C2019-02-27
14:34:51.585120108 +0100
@@ -0,0 +1,48 @@
+// PR c++/89513
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+constexpr bool foo ()
+try { // { dg-error "body of 'constexpr' function cannot be a
function-try-block" }
+ return true;
+} catch (...) {
+ return false;
+} // { dg-error "body of 'constexpr' function" "" {
target c++11_only } }
+
+#if __cplusplus > 201103L
+constexpr bool bar ()
+try { // { dg-error "body of 'constexpr' function cannot be a
function-try-block" "" { target c++14 } }
+ try {// { dg-error "'try' in 'constexpr' function"
"" { target c++14 } }
+return true;
+ } catch (int) {
+return false;
+ }
+} catch (...) {
+ return false;
+}
+
+constexpr bool baz ()
+{
+ try { return true; } catch (...) { return false; } // { dg-error "'try' in 'constexpr'
function" "" { target c++14 } }
+}
+#endif
+
+struct S {
+ constexpr S () try : m (1) // { dg-error "body of 'constexpr' constructor
cannot be a function-try-block" }
+ {
+#if __cplusplus > 201103L
+try { // { dg-error "'try' in 'constexpr' function" "" {
target c++14 } }
+} catch (int) {
+}
+#endif
+ } catch (...) {
+ }
+ int m;
+};
+
+struct T {
+ constexpr T ()
+ try {// { dg-error "body of 'constexpr' constructor
cannot be a function-try-block" }
+ } catch (...) {
+ }
+};
Jakub
Re: [committed] [PR rtl-optimization/87761] Don't let trivially dead insns impede regcprop's work
On Tue, Feb 26, 2019 at 08:13:32PM -0700, Jeff Law wrote: > My point is we see this stuff all the time on common platforms with > simple -O2 optimization. It deleted something like 2k dead insns on an > x86_64 bootstrap before I added goof'd up trap_p test. What I don't > have a sense of is how often removing that trivially dead code > ultimately helped cprop on x86_64. But the amount of trivially dead > code on a standard -O2 bootstrap was a huge surprise. It is a big surprise. I wonder what causes it; I don't see it? Do you have an example maybe? Or are you talking not about the subreg thing, but just about the dead code? Most of that will be deleted a little later anyway. Maybe some more places should call delete_trivially_dead_insns (). Segher
Re: [PATCH] Fix convert.c ICEs on invalid builtin calls (PR c/89520)
On Wed, 27 Feb 2019, Jakub Jelinek wrote: > Hi! > > convert.c doesn't verify the CALL_EXPRs to builtin functions have exactly > one argument (and a scalar float one) and can ICE if that is not the case > due to K&R declarations of the library functions and passing too few > arguments. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for > trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [C PATCH] Fix -Wbuiltin-declaration-mismatch (PR c/89525)
On Wed, 27 Feb 2019, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, with -w we don't emit
> -Wbuiltin-declaration-mismatch warnings (correct), but emit weird messages:
> ~/src/gcc/obj46/gcc/xgcc -B ~/src/gcc/obj46/gcc/ -w pr89525.c -S
> pr89525.c: In function ‘foo’:
> pr89525.c:5:8: note: declared here
> 5 | double sqrt (); /* { dg-bogus "declared here" } */
> |^~~~
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Re: libgo patch committed: Run examples
On Thu, Feb 21, 2019 at 1:47 AM Andreas Schwab wrote:
>
> On Feb 20 2019, Ian Lance Taylor wrote:
>
> > if test x$hasoutput = xtrue; then
> > - echo ' {"'$n'", '$j', "'"$output"'", '$unordered'},'
> > + echo ' {"'$n'", '$j', "'"$(cat example2.txt)"'",
> > '$unordered'},'
>
> That still has a problematic echo with backslashes.
How does this version look? Does it fix the problem?
Ian
commit fb0d3e611050e5884cbe6290c6def24b8b42b23d
Author: Ian Lance Taylor
Date: Wed Feb 20 17:45:44 2019 -0800
gotest: avoid using echo inside $()
The handling of newlines is not portable between bash and ksh.
Change-Id: I31cf57c9b2bcf98e8390ab92b75565a6798872de
diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
index 06000eae..c9c14652 100755
--- a/libgo/testsuite/gotest
+++ b/libgo/testsuite/gotest
@@ -619,21 +619,25 @@ symtogo() {
# Turn pairs of spaces into " \x20", because $() will
# drop duplicate spaces.
# Drop trailing spaces, and turn newlines into \n.
- output="$(sed '1 s/\([Uu]nordered \)\?[Oo]utput:[ ]*//' <
example.txt |
+ # Remove leading and trailing \n.
+ sed '1 s/\([Uu]nordered \)\?[Oo]utput:[ ]*//' <
example.txt |
sed -e 's/\\//g' \
-e 's/"/\\"/g' \
-e 's/ /\\t/g' \
-e 's/ / \\x20/g' \
-e 's/[]*$/\\n/g' |
-tr -d '\n')"
- # Remove leading and trailing \n.
- output="$(echo "$output" | sed -e 's/^\(\\n\)*//' -e
's/\(\\n\)*$//')"
+tr -d '\n' |
+sed -e 's/^\(\\n\)*//' \
+-e 's/\(\\n\)*$//' > example2.txt
hasoutput=true
rm -f example.txt
break
done
if test x$hasoutput = xtrue; then
- echo ' {"'$n'", '$j', "'"$output"'", '$unordered'},'
+ echo ' {"'$n'", '$j','
+ sed -e 's/^/"/' -e 's/$/", /' < example2.txt
+ echo $unordered'},'
+ rm -f example2.txt
fi
done
echo '}'
libgo patch committed: Use correct go_export name on Darwin
This patch by Nikhil Benesch uses the correct go_export section name
when building on Darwin. The Darwin build doesn't actually work, but
this should make it a tiny bit better. Bootstrapped on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269266)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-74533ed435a1a77e6f9ec8f6cf5db1695c2568e8
+08f1c400ec95d70a5cf5a08b1600fa5445e42361
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am (revision 269266)
+++ libgo/Makefile.am (working copy)
@@ -13,6 +13,12 @@ if LIBGO_IS_RTEMS
subdirs = testsuite
endif
+if LIBGO_IS_DARWIN
+GO_EXPORT_SECTION_NAME = __GNU_GO.__go_export
+else
+GO_EXPORT_SECTION_NAME = .go_export
+endif
+
SUBDIRS = ${subdirs}
gcc_version := $(shell $(GOC) -dumpversion)
@@ -818,7 +824,7 @@ BUILDGOX = \
if test ! -f $$f; then \
f="$(basename $(
Add option to allow use of TPIDRURW for thread pointer on ARM.
Hi! I am looking to see if there would be any support for a patch introducing an option to the compiler for ARM to allow for generation of code using TPIDRURW (the user-writable thread ID register in CP15) as the thread ID instead of TPIDRURO. Currently, GCC claims to support using CP15 for the thread ID, however of the two registers it contains that are accessible by EL0, it only supports generating code that accesses TPIDRURO, which is not writable by the user. I'm currently working on a project to improve support for TLS within the seL4 kernel. On ARMv6 and ARMv7 architectures where there are dedicated thread ID registers available we want to use TPIDURW as the standard register for the thread ID (as tpidr_el0 is used for AARCH64). We can currently work around this with the soft method but it would be beneficial to include an option to use TPIDRURW instead of TPIDRURO as it would improve all accesses to thread-local variables. We particularly want to use the user-writable register as it is useful to processes performing green-threading as they would be able to perform context switches internally with no intervention from the kernel (and thus with drastically lower overhead). >From a cursory view of the implementation, it doesn't seem that this would be >too difficult to implement. I am interesting in putting forward a patch if it >is likely it will be fully considered. Cheers, Curtis
