you can think of pack is really a special case of no alignment
Sun
2011/8/25 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
>>
>
------------------------------------------------------------------------------
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
