Hi all,
I made a new patch to keep user defined align info in TY_IDX, please
have a review.
the structure of TY_IDX is:
// struct TY_IDX {
// UINT index : 24;
// UINT _restrict : 1;
// UINT _volatile : 1;
// UINT _const : 1;
// UINT _user_align : 1;
// UINT _align : 4;
// };
extract 1 bit from _align to mark user defined align. and now the
maximum align is 2^15, the same as the gcc behavior.
Thanks
zhuqing
在 2011年8月26日 下午1:19，Jian-Xin Lai <laij...@gmail.com> 写道：
> Understand. We'll make a new change and keep this info in TY_IDX, instead of
> in ST.
>
> 在 2011年8月25日 下午4:01，Sun Chan <sun.c...@gmail.com>写道：
>>
>> I have problem having one attribute that have annotation in 2
>> different places. Also, the reason it is in TYPE is that symbols of
>> the same declaration but of different alignment should really be of
>> different type.
>> Sun
>>
>> 2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
>> > The TY has "packed" flag and it's detected in Adjust_Alignment:
>> > 125 align= TY_align(ty_idx);
>> > 126
>> > 127 if (Is_Structure_Type(ty) && TY_is_packed(ty))
>> > 128 {
>> > 129 return align;
>> > 130 }
>> >
>> > If the TY is packed, the BE don't change its alignment. We did the
>> > similar
>> > thing. The different is our change is applied on ST instead of TY
>> > because
>> > this is a GNU extension on variable.
>> >
>> > 在 2011年8月25日 下午3:05，Sun Chan <sun.c...@gmail.com>写道：
>> >>
>> >> How would you classify "pack" data?
>> >> Sun
>> >>
>> >> 2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
>> >> > The reason we introduce the "user align" is to separate this kind of
>> >> > case
>> >> > from the generic aggregate. So that we can do the two things well:
>> >> > If user specifies an alignment, we follow the size. Otherwise, the
>> >> > compiler
>> >> > can decide what's the proper alignment.
>> >> >
>> >> > 在 2011年8月25日 下午1:57，Mike Murphy <mmur...@nvidia.com>写道：
>> >> >>
>> >> >> So Aggregate_Alignment is a settable option (defaults to 16 in some
>> >> >> targets). What if you compile with -TENV:align_aggregates=8, or
>> >> >> don't
>> >> >> default it to 16?
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: 朱庆 [mailto:zqing1...@gmail.com]
>> >> >> Sent: Wednesday, August 24, 2011 10:53 PM
>> >> >> To: Mike Murphy
>> >> >> Cc: Sun Chan; open64-devel@lists.sourceforge.net
>> >> >> Subject: Re: [Open64-devel] Code Review request for bug832[wgen]
>> >> >>
>> >> >> The alignment is correct in .B file, but in Adjusted_Alignment there
>> >> >> are following code to modify the align. In our case we do not want
>> >> >> this happen.
>> >> >> else {
>> >> >> align = MAX(align, Aggregate_Alignment);
>> >> >> }
>> >> >>
>> >> >> Best wishes
>> >> >> zhuqing
>> >> >> 在 2011年8月25日 下午12:28，Mike Murphy <mmur...@nvidia.com> 写道：
>> >> >> > The alignment is stored in the ty_idx (see TY_align), and then
>> >> >> > there
>> >> >> > are
>> >> >> > routines like Adjusted_Alignment in stblock that can modify it. I
>> >> >> > suspect
>> >> >> > the problem here is that the alignment is being put on the object
>> >> >> > rather
>> >> >> > than the type, and then is lost (but should still be possible,
>> >> >> > because the
>> >> >> > TY_align is like qualifiers that can vary from the base type).
>> >> >> > Does
>> >> >> > the
>> >> >> > alignment show up properly in the intermediate .B file?
>> >> >> >
>> >> >> > -----Original Message-----
>> >> >> > From: Sun Chan [mailto:sun.c...@gmail.com]
>> >> >> > Sent: Wednesday, August 24, 2011 7:51 PM
>> >> >> > To: 朱庆
>> >> >> > Cc: open64-devel@lists.sourceforge.net
>> >> >> > Subject: Re: [Open64-devel] Code Review request for bug832[wgen]
>> >> >> >
>> >> >> > The reason I asked for the file is that I think there has to be
>> >> >> > some
>> >> >> > alignment attribute somewhere. I am sure data alignment has been
>> >> >> > dealt
>> >> >> > with in the compiler. That it is due to user, or just language
>> >> >> > attribute might be irrelevant from compiler point of view.
>> >> >> >
>> >> >> > Mike or Murthy,
>> >> >> > Do you remember where alignment is handled? I only found Alignment
>> >> >> > field in BLK of the symtab_defs.h
>> >> >> >
>> >> >> > Sun
>> >> >> >
>> >> >> > 2011/8/25 朱庆 <zqing1...@gmail.com>:
>> >> >> >> Hi Sun,
>> >> >> >>
>> >> >> >> Attached symtab_defs.h.
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >> zhuqing
>> >> >> >> 2011/8/24 Sun Chan <sun.c...@gmail.com>:
>> >> >> >>> can you send me the full symtab_defs.h?
>> >> >> >>> Sun
>> >> >> >>>
>> >> >> >>> On Wed, Aug 24, 2011 at 4:56 PM, 朱庆 <zqing1...@gmail.com> wrote:
>> >> >> >>>> Hi all,
>> >> >> >>>>
>> >> >> >>>> Can gatekeeper help review following fix for bug832?
>> >> >> >>>> https://bugs.open64.net/show_bug.cgi?id=832
>> >> >> >>>>
>> >> >> >>>> small case, a.c:
>> >> >> >>>> struct obs_kernel_param {
>> >> >> >>>> const char *str;
>> >> >> >>>> };
>> >> >> >>>>
>> >> >> >>>> const char str1[] = "acpi_parse_apic_instance=";
>> >> >> >>>> const char str2[] = "acpi_os_name";
>> >> >> >>>> struct obs_kernel_param var1
>> >> >> >>>> __attribute__ ((aligned ((sizeof (long))))) =
>> >> >> >>>> {str1};
>> >> >> >>>>
>> >> >> >>>> struct obs_kernel_param var2
>> >> >> >>>> __attribute__ ((aligned ((sizeof (long))))) =
>> >> >> >>>> {str2};
>> >> >> >>>>
>> >> >> >>>> when compile with opencc, nm a.o
>> >> >> >>>> 0000000000000000 D var1
>> >> >> >>>> 0000000000000010 D var2
>> >> >> >>>> compile with gcc, nm a.o
>> >> >> >>>> 0000000000000000 D var1
>> >> >> >>>> 0000000000000008 D var2
>> >> >> >>>> the offset of var1 and var2 are different, the problem with
>> >> >> >>>> opencc
>> >> >> >>>> is
>> >> >> >>>> :fixed align attribute does not work, this may cause some
>> >> >> >>>> problems
>> >> >> >>>> when mix link two files with opencc and gcc.
>> >> >> >>>>
>> >> >> >>>> The fix is to add a new ST flag to record user_defined_align.
>> >> >> >>>>
>> >> >> >>>> Thanks
>> >> >> >>>> zhuqing
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> ------------------------------------------------------------------------------
>> >> >> >>>> EMC VNX: the world's simplest storage, starting under $10K
>> >> >> >>>> The only unified storage solution that offers unified
>> >> >> >>>> management
>> >> >> >>>> Up to 160% more powerful than alternatives and 25% more
>> >> >> >>>> efficient.
>> >> >> >>>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> >> >> >>>> _______________________________________________
>> >> >> >>>> Open64-devel mailing list
>> >> >> >>>> Open64-devel@lists.sourceforge.net
>> >> >> >>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ------------------------------------------------------------------------------
>> >> >> > EMC VNX: the world's simplest storage, starting under $10K
>> >> >> > The only unified storage solution that offers unified management
>> >> >> > Up to 160% more powerful than alternatives and 25% more efficient.
>> >> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> >> >> > _______________________________________________
>> >> >> > Open64-devel mailing list
>> >> >> > Open64-devel@lists.sourceforge.net
>> >> >> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > -----------------------------------------------------------------------------------
>> >> >> > This email message is for the sole use of the intended
>> >> >> > recipient(s)
>> >> >> > and
>> >> >> > may contain
>> >> >> > confidential information. Any unauthorized review, use,
>> >> >> > disclosure
>> >> >> > or
>> >> >> > distribution
>> >> >> > is prohibited. If you are not the intended recipient, please
>> >> >> > contact
>> >> >> > the sender by
>> >> >> > reply email and destroy all copies of the original message.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > -----------------------------------------------------------------------------------
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> EMC VNX: the world's simplest storage, starting under $10K
>> >> >> The only unified storage solution that offers unified management
>> >> >> Up to 160% more powerful than alternatives and 25% more efficient.
>> >> >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> >> >> _______________________________________________
>> >> >> Open64-devel mailing list
>> >> >> Open64-devel@lists.sourceforge.net
>> >> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Lai Jian-Xin
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > EMC VNX: the world's simplest storage, starting under $10K
>> >> > The only unified storage solution that offers unified management
>> >> > Up to 160% more powerful than alternatives and 25% more efficient.
>> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> >> > _______________________________________________
>> >> > Open64-devel mailing list
>> >> > Open64-devel@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Lai Jian-Xin
>> >
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
bug832_v2.patch
Description: Binary data
------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
