gengtype & mark_hook in unions not working
Hello All,
I observed in http://gcc.gnu.org/ml/gcc/2010-07/msg00248.html that
sometimes mark_hook-s are not working (and MELT needs them strongly).
Actually, the following test case shows that mark hooks are not emitted when
indirectly inside a union member.
To be specific, with the following file tmarkh.h
/* file tmarkh.h */
#define MYUTAG 1
union GTY ((desc("%0.u_int"))) myutest_un {
int GTY((skip)) u_int;
struct mytest_st GTY ((tag("MYUTAG"))) u_mytest;
};
static GTY(()) union myutest_un *myutestptr;
static inline void mymarker(struct mytest_st*s)
{
s->myflag = 1;
}
/* eof tmarkh.h */
when running gengtype (the one from the trunk, or the gcc-4.7 one) with
gengtype -D -v -r gtype.state -P _g-tmarkh.h tmarkh.h
you can observe that the generated _g-tmarkh.h don't contain any call to
mymarker. If the static variable (here myutestptr) is declared with the
struct mytest_st* type, the marker is emitted.
I'm investigating that bug and hope to submit a patch soon.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
How much time left till phase 3?
I'll have to prepare a few more patches to (supposedly) generic code to support the ARCompact port, which we (Synopsys and Embecosm) would like contribute in time for gcc 4.8. How much time is left till we switch from phase 1 to phase 3?
Re: How much time left till phase 3?
On Tue, Oct 2, 2012 at 10:44 AM, Joern Rennecke wrote: > I'll have to prepare a few more patches to (supposedly) generic > code to support the ARCompact port, which we (Synopsys and Embecosm) > would like contribute in time for gcc 4.8. > > How much time is left till we switch from phase 1 to phase 3? I expect stage1 to close mid to end of October (after which it lasted for more than 7 months). Richard.
Re: How much time left till phase 3?
On Tue, Oct 2, 2012 at 11:34 AM, Richard Guenther wrote: > On Tue, Oct 2, 2012 at 10:44 AM, Joern Rennecke > wrote: >> I'll have to prepare a few more patches to (supposedly) generic >> code to support the ARCompact port, which we (Synopsys and Embecosm) >> would like contribute in time for gcc 4.8. >> >> How much time is left till we switch from phase 1 to phase 3? > > I expect stage1 to close mid to end of October (after which it lasted > for more than 7 months). Btw, I realize that the aarch64 port probably also wants to merge even if I didn't see a merge proposal or know whether they have patches to generic code. Anybody else with things they want to merge during stage1? Thanks, Richard. > Richard.
Re: gengtype & mark_hook in unions not working
On Tue, Oct 02, 2012 at 09:57:53AM +0200, Basile Starynkevitch wrote:
> I observed in http://gcc.gnu.org/ml/gcc/2010-07/msg00248.html that
> sometimes mark_hook-s are not working (and MELT needs them strongly).
>
> Actually, the following test case shows that mark hooks are not emitted when
> indirectly inside a union member.
[..testcase ommitted, see original message..]
>
> I'm investigating that bug and hope to submit a patch soon.
I sent a small patch http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00164.html
which corrects that bug. (I hope that small patch would be reviewed and
accepted before going into stage 3)
Should I make a bugzilla entry too?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: How much time left till phase 3?
On 10/02/2012 05:45 AM, Richard Guenther wrote: I expect stage1 to close mid to end of October (after which it lasted for more than 7 months). Btw, I realize that the aarch64 port probably also wants to merge even if I didn't see a merge proposal or know whether they have patches to generic code. Anybody else with things they want to merge during stage1? I'm fighting with some code to implement C11 atomics which I was hoping to get in, but I'm not sure yet it's going to be ready. The next few weeks will tell the tale... Andrew
inlined memcpy/memset degradation in gcc 4.6 or later
On TILE-Gx, I'm observing a degradation in inlined memcpy/memset in
gcc 4.6 and later versus gcc 4.4. Though I find the problem on
TILE-Gx, I think this is a problem for any architectures with
SLOW_UNALIGNED_ACCESS set to 1.
Consider the following program:
struct foo {
int x;
};
void copy(struct foo* f0, struct foo* f1)
{
memcpy (f0, f1, sizeof(struct foo));
}
In gcc 4.4, I get the desired inline memcpy:
copy:
ld4sr1, r1
st4 r0, r1
jrp lr
In gcc 4.7, however, I get inlined byte-by-byte copies:
copy:
ld1u_add r10, r1, 1
st1_add r0, r10, 1
ld1u_add r10, r1, 1
st1_add r0, r10, 1
ld1u_add r10, r1, 1
st1_add r0, r10, 1
ld1u r10, r1
st1 r0, r10
jrp lr
The inlining of memcpy is done in expand_builtin_memcpy in builtins.c.
Tracing through that, I see that the alignment of src_align and
dest_align, which is computed by get_pointer_alignment, has degraded:
in gcc 4.4 they are 32 bits, but in gcc 4.7 they are 8 bits. This
causes the loads generated by the inlined memcopy to be per-byte
instead of per-4-byte.
Looking further, gcc 4.7 uses the "align" field in "struct
ptr_info_def" to compute the alignment. This field appears to be
initialized in get_ptr_info in tree-ssanames.c but it is always
initialized to 1 byte and does not appear to change. gcc 4.4 computes
its alignment information differently.
I get the same byte-copies with gcc 4.8 and gcc 4.6.
I see a couple related open PRs: 50417, 53535, but no suggested fixes
for them yet. Can anyone advise on how this can be fixed? Should I
file a new bug, or add this info to one of the existing PRs?
Thanks,
Walter
libatomic failure compiling 4.8 on TILE-Gx
I'm getting the following failure trying to compile gcc 4.8 on TILE-Gx: In file included from /home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/tas_n.c:25:0: /home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/tas_n.c: In function 'libat_test_and_set_8': /home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/tas_n.c:58:20: error: 'INVERT_MASK_8' undeclared (first use in this function) shift = SIZE(INVERT_MASK); ^ /home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/libatomic_i.h:42:20: note: in definition of macro 'C3_' #define C3_(X,Y,Z) X ## Y ## Z ^ /home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/libatomic_i.h:119:18: note: in expansion of macro 'C3' #define SIZE(X) C3(X,_,N) ^ /home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/tas_n.c:58:15: note: in expansion of macro 'SIZE' shift = SIZE(INVERT_MASK); ^ /home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/tas_n.c:58:20: note: each undeclared identifier is reported only once for each function it appears in shift = SIZE(INVERT_MASK); ^ make[4]: *** [tas_8_.lo] Error 1 make[4]: Leaving directory `/home/scratch/walt/tmp/gx/2012-10-01/gcc-4.8.x/build/tilegx-unknown-linux-gnu/libatomic' It seems like libatomic_i.h might be missing definitions for MASK_8 and INVERT_MASK_8? Thanks, Walter
Re: How much time left till phase 3?
On 2012-10-02 05:45 , Richard Guenther wrote: Anybody else with things they want to merge during stage1? I have the VEC API rename finished and currently under testing. I expect to have it done by early next week. There are some gengtype changes that will improve C++ parsing that should go in during stage 1. The other gengtype changes I have in the pipeline are going to be too invasive post stage 1. Finally, I've been thinking of porting asan/tsan to replace mudflap. Dodji, you expressed interest in it recently. Jakub, Richi, Joseph, should we do this during the next stage 1? I'm not sure how much mudflap is actually used. If it isn't, maybe this work can be done after stage 1 closes, but I would like to get an explicit OK from the RMs. This is work that can be done on a branch and merge back into trunk for 4.9 at the next stage 1. Lawrence and I are planning some API cleanups in the middle end, so we will be looking at the recently proposed plugin API proposal. We will be working on defining C++ APIs. This work will be done on a branch, but we will publish proposals in the coming weeks. Diego.
Re: How much time left till phase 3?
On Tue, Oct 02, 2012 at 10:30:02AM -0400, Diego Novillo wrote: > Finally, I've been thinking of porting asan/tsan to replace mudflap. > Dodji, you expressed interest in it recently. > > Jakub, Richi, Joseph, should we do this during the next stage 1? > I'm not sure how much mudflap is actually used. If it isn't, maybe > this work can be done after stage 1 closes, but I would like to get > an explicit OK from the RMs. This is work that can be done on a > branch and merge back into trunk for 4.9 at the next stage 1. I think it would be very nice to get at least asan port for 4.8, but I guess it depends on how much work is on it. Killing mudflap would be nice. I think there is no reason to close stage 1 already mid October, that is just fortnight ahead, and the last stage3 went IMHO fine even when it started on November, 8th. So I think end of October should be fine. LRA/x86* should (if everything gets reviewed and adjusted for reviews in time) still be merged, AFAIK Kai is working on the type promotion/demotion pass which would be nice too. I still have plans for multi-bb range reassoc optimization and doing something about vectorization of conditional loads/stores. Jakub
Re: How much time left till phase 3?
On 10/02/2012 08:30 AM, Diego Novillo wrote: Finally, I've been thinking of porting asan/tsan to replace mudflap. Dodji, you expressed interest in it recently. That's further out most likely. Jeff
Re: inlined memcpy/memset degradation in gcc 4.6 or later
Hi Walter,
I faced with similar problem when I worked on optimizing memcpy
expanding for x86.
x86-specific expander also needed alignment info and it was also
incorrect (i.e. too conservative). Routine get_mem_align_offset () is
used there to determine alignment, but after some moment it started to
return 1-byte instead of 16-byte or whatever alignment, which I
expected.
I made small fix for it and it seemed to work well again:
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 9565c61..9108022 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -1516,6 +1516,14 @@ get_mem_align_offset (rtx mem, unsigned int align)
if (TYPE_ALIGN (TREE_TYPE (expr)) < (unsigned int) align)
return -1;
}
+ else if (TREE_CODE (expr) == MEM_REF)
+{
+ int al, off;
+ get_object_alignment_1 (expr, &al, &offset);
+ offset /= BITS_PER_UNIT;
+ if (al < align)
+ return -1;
+}
else if (TREE_CODE (expr) == COMPONENT_REF)
So, returning to your problem - probably routines you mentioned also
don't handle MEM_REF (and before some commit they didn't have to).
Also, you could look into routine I mentioned - probably you could
find something useful for you there.
---
Thanks, Michael
On 2 October 2012 18:19, Walter Lee wrote:
>
> On TILE-Gx, I'm observing a degradation in inlined memcpy/memset in
> gcc 4.6 and later versus gcc 4.4. Though I find the problem on
> TILE-Gx, I think this is a problem for any architectures with
> SLOW_UNALIGNED_ACCESS set to 1.
>
> Consider the following program:
>
> struct foo {
> int x;
> };
>
> void copy(struct foo* f0, struct foo* f1)
> {
> memcpy (f0, f1, sizeof(struct foo));
> }
>
> In gcc 4.4, I get the desired inline memcpy:
>
> copy:
> ld4sr1, r1
> st4 r0, r1
> jrp lr
>
> In gcc 4.7, however, I get inlined byte-by-byte copies:
>
> copy:
> ld1u_add r10, r1, 1
> st1_add r0, r10, 1
> ld1u_add r10, r1, 1
> st1_add r0, r10, 1
> ld1u_add r10, r1, 1
> st1_add r0, r10, 1
> ld1u r10, r1
> st1 r0, r10
> jrp lr
>
> The inlining of memcpy is done in expand_builtin_memcpy in builtins.c.
> Tracing through that, I see that the alignment of src_align and
> dest_align, which is computed by get_pointer_alignment, has degraded:
> in gcc 4.4 they are 32 bits, but in gcc 4.7 they are 8 bits. This
> causes the loads generated by the inlined memcopy to be per-byte
> instead of per-4-byte.
>
> Looking further, gcc 4.7 uses the "align" field in "struct
> ptr_info_def" to compute the alignment. This field appears to be
> initialized in get_ptr_info in tree-ssanames.c but it is always
> initialized to 1 byte and does not appear to change. gcc 4.4 computes
> its alignment information differently.
>
> I get the same byte-copies with gcc 4.8 and gcc 4.6.
>
> I see a couple related open PRs: 50417, 53535, but no suggested fixes
> for them yet. Can anyone advise on how this can be fixed? Should I
> file a new bug, or add this info to one of the existing PRs?
>
> Thanks,
>
> Walter
>
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
reverse bitfield patch
Here's my current patch for the bitfield reversal feature I've been
working on for a while, with an RX-specific pragma to apply it
"globally". Could someone please review this? It would be nice
to get it in before stage1 closes again...
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 192009)
+++ gcc/doc/extend.texi (working copy)
@@ -5427,12 +5427,74 @@ Note that the type visibility is applied
associated with the class (vtable, typeinfo node, etc.). In
particular, if a class is thrown as an exception in one shared object
and caught in another, the class must have default visibility.
Otherwise the two shared objects will be unable to use the same
typeinfo node and exception handling will break.
+@item bit_order
+Normally, GCC allocates bitfields from either the least significant or
+most significant bit in the underlying type, such that bitfields
+happen to be allocated from lowest address to highest address.
+Specifically, big-endian targets allocate the MSB first, where
+little-endian targets allocate the LSB first. The @code{bit_order}
+attribute overrides this default, allowing you to force allocation to
+be MSB-first, LSB-first, or the opposite of whatever gcc defaults to. The
+@code{bit_order} attribute takes an optional argument:
+
+@table @code
+
+@item native
+This is the default, and also the mode when no argument is given. GCC
+allocates LSB-first on little endian targets, and MSB-first on big
+endian targets.
+
+@item swapped
+Bitfield allocation is the opposite of @code{native}.
+
+@item lsb
+Bits are allocated LSB-first.
+
+@item msb
+Bits are allocated MSB-first.
+
+@end table
+
+A short example demonstrates bitfield allocation:
+
+@example
+struct __attribute__((bit_order(msb))) @{
+ char a:3;
+ char b:3;
+@} foo = @{ 3, 5 @};
+@end example
+
+With LSB-first allocation, @code{foo.a} will be in the 3 least
+significant bits (mask 0x07) and @code{foo.b} will be in the next 3
+bits (mask 0x38). With MSB-first allocation, @code{foo.a} will be in
+the 3 most significant bits (mask 0xE0) and @code{foo.b} will be in
+the next 3 bits (mask 0x1C).
+
+Note that it is entirely up to the programmer to define bitfields that
+make sense when swapped. Consider:
+
+@example
+struct __attribute__((bit_order(msb))) @{
+ short a:7;
+ char b:6;
+@} foo = @{ 3, 5 @};
+@end example
+
+On some targets, or if the struct is @code{packed}, GCC may only use
+one byte of storage for A despite it being a @code{short} type.
+Swapping the bit order of A would cause it to overlap B. Worse, the
+bitfield for B may span bytes, so ``swapping'' would no longer be
+defined as there is no ``char'' to swap within. To avoid such
+problems, the programmer should either fully-define each underlying
+type, or ensure that their target's ABI allocates enough space for
+each underlying type regardless of how much of it is used.
+
@end table
To specify multiple attributes, separate them by commas within the
double parentheses: for example, @samp{__attribute__ ((aligned (16),
packed))}.
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 192009)
+++ gcc/c-family/c-common.c (working copy)
@@ -310,12 +310,13 @@ struct visibility_flags visibility_optio
static tree c_fully_fold_internal (tree expr, bool, bool *, bool *);
static tree check_case_value (tree);
static bool check_case_bounds (tree, tree, tree *, tree *);
static tree handle_packed_attribute (tree *, tree, tree, int, bool *);
+static tree handle_bitorder_attribute (tree *, tree, tree, int, bool *);
static tree handle_nocommon_attribute (tree *, tree, tree, int, bool *);
static tree handle_common_attribute (tree *, tree, tree, int, bool *);
static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
static tree handle_hot_attribute (tree *, tree, tree, int, bool *);
static tree handle_cold_attribute (tree *, tree, tree, int, bool *);
static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
@@ -601,12 +602,14 @@ const unsigned int num_c_common_reswords
const struct attribute_spec c_common_attribute_table[] =
{
/* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
affects_type_identity } */
{ "packed", 0, 0, false, false, false,
handle_packed_attribute , false},
+ { "bit_order", 0, 1, false, true, false,
+ handle_bitorder_attribute , false},
{ "nocommon", 0, 0, true, false, false,
handle_nocommon_attribute, false},
{ "common", 0, 0, true, false, false,
handle_common_attribute, false },
/* FIXME: logically, noreturn attributes should be listed as
"false, true, true" and apply to function types. But implementing this
@
Re: reverse bitfield patch
[sorry, should have gone to gcc-patches]
