the point is, I don't think you need two places to store alignment
info, user specified or not
Sun
2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
> No, there is no case with 2 different alignment. ST's alignment is saved in
> ST's TY_IDX, not in the TY. The front end will set the correct alignment for
> the ST for all cases. TY only keeps the size of the type. TY doen't have the
> alignment size.
>
> 在 2011年8月25日 下午4:19，Sun Chan <sun.c...@gmail.com>写道：
>>
>> it's not a question. I am saying, symbol of different alignment should
>> have different type. Hence, the alignment is associated at type table,
>> not symtab
>> Sim
>>
>> 2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
>> > I'm not sure if I understand your question. The TY_IDX is composed by 2
>> > parts: index to TY_TABLE and extra flags for volatile, restrict and
>> > alignment. Every symbol with the same TY has its own alignment embeded
>> > in
>> > the TY_IDX.
>> >
>> > 在 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
>> >
>
>
>
> --
> 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
