Re: Auto-generated .rodata contents and __attribute__((section))
On 05/23/2018 02:55 PM, Michael Matz wrote: On Fri, 18 May 2018, Richard Biener wrote: Interesting. Do they allow merging across such sections? Consider a 8 byte entity 0x12345678 and 4 byte entities 0x1234 0x5678, will the 4 byte entities share the rodata with the 8 byte one? There's no language to forbid this (as long as the alignments are respected), but at least GNU ld currently only merges same-sized entities. I'm not entirely sure if this is valid for C, particularly if the objects have the same address, but not the same type. There is a discussion on the generic-abi list about providing information to the linker about when it is safe to do such merging: https://groups.google.com/forum/#!topic/generic-abi/MPr8TVtnVn4 Thanks, Florian
--3334--3991微/电 -----zgbwp
公 司 可 对 外 开 发 票 ，正 规 可 查 验 。 点 水 优 惠 。 Q Q ：160一852一5627 - 灿烂的群星在整个宇宙中静静地看着他们 在院子里血流了一圈……
Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP
On Wed, 2018-05-16 at 22:11 +0100, Richard Sandiford wrote: > > TARGET_HARD_REGNO_CALL_PART_CLOBBERED is the only current way > of saying that an rtl instruction preserves the low part of a > register but clobbers the high part. We would need something like > Alan H's CLOBBER_HIGH patches to do it using explicit clobbers. > > Another approach would be to piggy-back on the -fipa-ra > infrastructure > and record that vector PCS functions only clobber Q0-Q7. If -fipa-ra > knows that a function doesn't clobber Q8-Q15 then that should > override > TARGET_HARD_REGNO_CALL_PART_CLOBBERED. (I'm not sure whether it does > in practice, but it should :-) And if it doesn't that's a bug that's > worth fixing for its own sake.) > > Thanks, > Richard Alan, I have been looking at your CLOBBER_HIGH patches to see if they might be helpful in implementing the ARM SIMD Vector ABI in GCC. I have also been looking at the -fipa-ra flag and how it works. I was wondering if you considered using the ipa-ra infrastructure for the SVE work that you are currently trying to support with the CLOBBER_HIGH macro? My current thought for the ABI work is to mark all the floating point / vector registers as caller saved (the lower half of V8-V15 are currently callee saved) and remove TARGET_HARD_REGNO_CALL_PART_CLOBBERED. This should work but would be inefficient. The next step would be to split get_call_reg_set_usage up into two functions so that I don't have to pass in a default set of registers. One function would return call_used_reg_set by default (but could return a smaller set if it had actual used register information) and the other would return regs_invalidated by_call by default (but could also return a smaller set). Next I would add a 'largest mode used' array to call_cgraph_rtl_info structure in addition to the current function_used_regs register set. Then I could turn the get_call_reg_set_usage replacement functions into target specific functions and with the information in the call_cgraph_rtl_info structure and any simd attribute information on a function I could modify what registers are really being used/invalidated without being saved. If the called function only uses the bottom half of a register it would not be marked as used/invalidated. If it uses the entire register and the function is not marked as simd, then the register would marked as used/invalidated. If the function was marked as simd the register would not be marked because a simd function would save both the upper and lower halves of a callee saved register (whereas a non simd function would only save the lower half). Does this sound like something that could be used in place of your CLOBBER_HIGH patch? Steve Ellcey sell...@cavium.com
Must TYPE_MODE of a UNION_TYPE be of MODE_INT class?
I've written a patch to fix the transparent_union attribute when the first field in a union is MODE_PARTIAL_INT, but I noticed that the current code only allows the TYPE_MODE of a UNION_TYPE to be of MODE_INT class. See stor-layout.c (compute_record_mode), particularly this section: /* If we only have one real field; use its mode if that mode's size matches the type's size. This only applies to RECORD_TYPE. This does not apply to unions. */ if (TREE_CODE (type) == RECORD_TYPE && mode != VOIDmode && tree_fits_uhwi_p (TYPE_SIZE (type)) && known_eq (GET_MODE_BITSIZE (mode), tree_to_uhwi (TYPE_SIZE (type ; else mode = mode_for_size_tree (TYPE_SIZE (type), MODE_INT, 1).else_blk (); Is there a reason the type of the union must be of MODE_INT class but a RECORD_TYPE with one field can have the class of it's single field? If the else clause is changed to the following, then transparent_union unions with a first field of double (e.g. gcc/testsuite/g++.dg/ext/transparent-union.C) no longer error. mode = mode_for_size_tree (TYPE_SIZE (type), (GET_MODE_CLASS (mode) != MODE_RANDOM ? GET_MODE_CLASS (mode) : MODE_INT), 1).else_blk (); Could anyone provide some insight on whether the TYPE_MODE of a union should stay as a MODE_INT class or if it would be acceptable for the TYPE_MODE to be other classes e.g. MODE_FLOAT?
Re: How do I stop gcc from loading data into registers when that's not needed?
On Wed, May 23, 2018 at 08:33:13PM -0400, Paul Koning wrote: > > On May 23, 2018, at 5:46 AM, Richard Biener > > wrote: > >> 2. The reported costs for the various insns are > >> r22:HI=['x']6 > >> cmp(r22:HI,r23:HI) 4 > >> cmp(['x'],['y'])16 > >>so the added cost for the memory argument in the cmp is 6 -- the same > >> as the whole cost for the mov. That certainly explains the behavior. It > >> isn't what I want it to be. Which target hook(s) are involved in these > >> numbers? I don't see them in my rtx_costs hook. > > > > The rtx_cost hook. I think the costs above make sense. There's also a > > new insn_cost hook but you have to dig whether combine uses that. > > Otherwise address_cost might be involved. > > Thanks. For a pdp11, those costs aren't right because mov and cmp and > a memory reference each have about the same cost. So 8, 4, 12 would be > closer. But the real question for me at this point is where to find > the knobs that adjust these choices. > > The various cost hooks have me confused, and the GCCINT manual is not > really enlightening. There is rtx_costs, insn_cost, and addr_cost. > It sort of feels like insn_cost and addr_cost together would provide > roughly the same information that rtx_costs gives. In the existing > platforms, I see rtx_costs everywhere, addr_cost in a fair number of > targets, and insn_cost in just one (rs6000). Can someone explain the > interaction of these various cost hooks, and what happens if you define > various combinations of the three? rtx_costs computes the cost for any rtx (an insn, a set, a set source, any random piece of one). set_src_cost, set_rtx_cost, etc. are helper functions that use that. Those functions do not work for parallels. Also, costs are not additive like this simplified model assumes. Also, more complex backends tend to miss many cases in their rtx_costs function. Many passes that want costs want to know the cost of a full insn. Like combine. That's why I created insn_cost: it solves all of the above problems. I'll hopefully make most passes use insn_cost for GCC 9. All of the very easy ones already do. Segher
Re: Must TYPE_MODE of a UNION_TYPE be of MODE_INT class?
> See stor-layout.c (compute_record_mode), particularly this section: > >/* If we only have one real field; use its mode if that mode's size > matches the type's size. This only applies to RECORD_TYPE. This > does not apply to unions. */ >if (TREE_CODE (type) == RECORD_TYPE && mode != VOIDmode >&& tree_fits_uhwi_p (TYPE_SIZE (type)) >&& known_eq (GET_MODE_BITSIZE (mode), tree_to_uhwi (TYPE_SIZE >(type >; >else > mode = mode_for_size_tree (TYPE_SIZE (type), MODE_INT, 1).else_blk (); > > Is there a reason the type of the union must be of MODE_INT class but a > RECORD_TYPE with one field can have the class of it's single field? Yes, ABIs that pass structures or unions in registers traditionally pass the unions always in integer registers, whereas for structures it's dependent on the types of the fields. > Could anyone provide some insight on whether the TYPE_MODE of a union should > stay as a MODE_INT class or if it would be acceptable for the TYPE_MODE to > be other classes e.g. MODE_FLOAT? No, I don't think we want to change that. -- Eric Botcazou
[PATCH] tighten up -Wclass-memaccess for ctors/dtors (PR 84851)
A fix for 84851 - missing -Wclass-memaccess for a memcpy in a copy
ctor with a non-trivial member was implemented but disabled for GCC
8 but because it was late, with the expectation we would enable it
for GCC 9. The attached removes the code that guards the full fix
to enable it.
Martin
PR c++/84851 - missing -Wclass-memaccess for a memcpy in a copy ctor with a non-trivial member
gcc/cp/ChangeLog:
PR c++/84851
* call.c (maybe_warn_class_memaccess): Tighten up.
gcc/testsuite/ChangeLog:
PR c++/84851
* g++.dg/Wclass-memaccess-4.C: Remove XFAIL.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7aadd64..6a8ff6b 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8535,15 +8535,6 @@ maybe_warn_class_memaccess (location_t loc, tree fndecl,
bool special = same_type_ignoring_top_level_qualifiers_p (ctx, desttype);
tree binfo = TYPE_BINFO (ctx);
- /* FIXME: The following if statement is overly permissive (see
- bug 84851). Remove it in GCC 9. */
- if (special
- && !BINFO_VTABLE (binfo)
- && !BINFO_N_BASE_BINFOS (binfo)
- && (DECL_CONSTRUCTOR_P (current_function_decl)
- || DECL_DESTRUCTOR_P (current_function_decl)))
- return;
-
if (special
&& !BINFO_VTABLE (binfo)
&& !first_non_trivial_field (desttype))
diff --git a/gcc/testsuite/g++.dg/Wclass-memaccess-4.C b/gcc/testsuite/g++.dg/Wclass-memaccess-4.C
index 8c33421..69b8c78 100644
--- a/gcc/testsuite/g++.dg/Wclass-memaccess-4.C
+++ b/gcc/testsuite/g++.dg/Wclass-memaccess-4.C
@@ -29,7 +29,7 @@ struct C
C::C (const C &c)
{
- memcpy (this, &c, sizeof c);// { dg-warning "\\\[-Wclass-memaccess]" "pr84851" { xfail *-*-*} }
+ memcpy (this, &c, sizeof c);// { dg-warning "\\\[-Wclass-memaccess]" }
}
C& C::operator= (const C &c)
Account Over Due Gcc, hanson brenda beneath lissajous
aldrich [4
gcc-7-20180524 is now available
Snapshot gcc-7-20180524 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180524/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 260697 You'll find: gcc-7-20180524.tar.xzComplete GCC SHA256=19a344865b725953665d4794930e95f875a28f5359843215ebb66afcf1e19471 SHA1=2bae79e6b1072545e338c8f959de62a405efda1a Diffs from 7-20180517 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
virtual-stack-vars reference not resolved in vregs
I'm doing cleanup on the pdp11 back end to get rid of a
number of ICE in the test suite. One is in
gcc.c-torture/compile/20001221.c -- it works in GCC 4 but
fails in GCC 5 and later.
In the dumps, I see in the output from the expand phase a
large number of memory reference via the "virtual-stack-vars"
pseudo-register. In vregs those all become frame pointer
references in V4, but in V5 and later, about 10% of them
remain pseudo-register references all the way through final
assembly output generation. There things blow up because
it's an invalid base register.
Here are some snippets:
static void
foo ()
{
long maplength;
int type;
{
const long nibbles = 8;
char buf1[nibbles + 1];
...
V4, expand output:
;; nibbles_18 = 8;
(insn 7 6 0 (set (mem/c:SI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
(const_int 8 [0x8]))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:8
-1
(nil))
;; _19 = (sizetype) nibbles_18;
(insn 8 7 0 (set (mem/c:HI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -10 [0xfff6])) [0 D.1480+0 S2 A16])
(subreg:HI (mem/c:SI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
0))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:9
-1
(nil))
The second insn is picking up the low order half of "nibbles"
to use as the index; note that Pmode is HI for this target.
The vregs pass turns it into this:
(insn 7 6 8 2 (set (mem/c:SI (plus:HI (reg/f:HI 14 fp)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
(const_int 8 [0x8]))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:8
12 {movsi}
(nil))
(insn 8 7 9 2 (set (mem/c:HI (plus:HI (reg/f:HI 14 fp)
(const_int -10 [0xfff6])) [0 D.1480+0 S2 A16])
(subreg:HI (mem/c:SI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
0))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:9
14 {movhi}
(nil))
which is what I would expect.
In V5, the expand output is the same:
(insn 7 6 0 (set (mem/c:SI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
(const_int 8 [0x8]))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:8
-1
(nil))
;; _19 = (sizetype) nibbles_18;
(insn 8 7 0 (set (mem/c:HI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -10 [0xfff6])) [0 D.1480+0 S2 A16])
(subreg:HI (mem/c:SI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
0))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:9
-1
(nil))
but now vregs doesn't convert the virtual-stack-vars reference
in the subreg operand:
(insn 7 6 8 2 (set (mem/c:SI (plus:HI (reg/f:HI 14 fp)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
(const_int 8 [0x8]))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:8
12 {movsi}
(nil))
(insn 8 7 9 2 (set (mem/c:HI (plus:HI (reg/f:HI 14 fp)
(const_int -10 [0xfff6])) [0 D.1480+0 S2 A16])
(subreg:HI (mem/c:SI (plus:HI (reg/f:HI 17 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 nibbles+0 S4 A16])
0))
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/20001221-1.c:9
14 {movhi}
(nil))
Is this something the back end is responsible for getting right, for example
via the machine description file? If so, any hints where to start?
paul
Re: virtual-stack-vars reference not resolved in vregs
> Is this something the back end is responsible for getting right, for example > via the machine description file? If so, any hints where to start? The SUBREG of MEM is invalid at this stage. -- Eric Botcazou
about update gcc
Hi: My wind river kernel version is 4.1 and the gcc version is 5.2.0 in it.how can I update the gcc tool to 6.0 or upper version?
