For the given case when add option Align_aggregate=8 it works. This is because
struct obs_kernel_param var1
__attribute__ ((aligned ((sizeof (long))))) =
{str1};
for var1, the user defined align is 8, and we can get the st from .B,
the alignment below is always right.
52]: var1 <1,52> Variable of type obs_kernel_param (#54,
KIND_STRUCT)
Address: 0(var1<1,52>) Alignment: 8 bytes
Flags: 0x00000008 initialized
Sclass: DGLOBAL
If we change the attribute of var1 to __attribute__ ((aligned (1))) ,
the alignment changed to 1 byte accordingly.
The problem exists at stblock of Adjusted_Alignment, the st's
alignment will be changed according to following code , if the orignal
align is equal or larger than Aggregate_Alignment, there is no any
problems, otherwise, the align is changed to Aggregate_Alignment. So
for above case, when change Aggregate_Alignment to 8, align will equal
to Aggregate_Alignment, then problem cleared. But this is not a
solution for all cases, if we change user defined align of var1 to 1,
then problem still exists.
>align = MAX(align, Aggregate_Alignment);
So we should avoid this align adjustment for the special "user defined align".
Thanks
zhuqing
在 2011年8月25日 下午9:46，Sun Chan <sun.c...@gmail.com> 写道：
> All these are valid to me. I have another question for Zqing. Why does
> Align_aggregate=8 work? What is changed?
> Sun
>
> 2011/8/25 Stephen Clarke <stephen.cla...@st.com>:
>> I really don't have strong opinions on this issue, but it is
>> something that I have needed to think about from time to
>> time for our target, so I can at least give my thoughts.
>> Disclaimer: this is just based on working with the code and
>> documentation, I don't have any particular insights, and I may
>> well misinterpret something.
>>
>> My understanding of the align information in the ty_idx
>> is that it is, initially, a "summary" of the required alignment,
>> given the alignment requirements of the ABI, the type,
>> and the decl (including any gnu attributes). For the
>> output of the frontend, this is the "intended alignment".
>>
>> After the frontend, an optimization phase should be allowed
>> to change the alignment of objects, for code improvement
>> purposes, where such a change is legal. (By "legal" I mean,
>> it doesn't break the language semantics, or the ABI.)
>> And in the implementation this is done by rewriting the align
>> information in the ty_idx.
>>
>> But now it's necessary to support a gcc attribute which forbids
>> optimizing the alignment of an object. It's a new
>> "language semantics" rule that the alignment optimizer needs
>> to follow. Somehow, the alignment optimizer needs to know
>> when this rule applies to an object.
>>
>> What I don't have a very strong idea of, is how to consider
>> the Aggregate_Alignment variable, which is treated by
>> Adjusted_Alignment(). I think of it as an optimization, i.e.
>> it doesn't change language or ABI rules, so Adjusted_Alignment()
>> is just like an optimization phase performing an alignment
>> optimization.
>>
>> Rgds,
>> Steve.
>>
>> Sun Chan wrote:
>>> you are always welcome to give opinion, why not!
>>> I am forgetting a lot of the details, why can't the bit in ty_idx to
>>> specify the "intended" alignment? If one can specify a larger
>>> alignment, the reverse is possible too, right? When we did the
>>> alignment bit, I don't believe we were thinking of just increasing
>>> alignment.
>>> Sun
>>>
>>> 2011/8/25 Stephen Clarke <stephen.cla...@st.com>:
>>>> Ok. I deliberately avoided giving an opinion on where
>>>> the "user aligned" information should be stored.
>>>>
>>>> But I can think of three possibilities:
>>>> 1. A flag in the ST (i.e. the proposal).
>>>> 2. A bit in the TY_IDX (the same place as the align).
>>>> 3. A flag in the TY.
>>>>
>>>> For #2, there is some issue that it is a fixed 32-bit
>>>> entity, and there are no free bits. So a bit needs to be stolen,
>>>> either from the (currently 24-bit) index into the type table,
>>>> or else from the (currently 5-bit) alignment value.
>>>> I worry about stealing a bit from the alignment, leaving only
>>>> 4 bits, so I suppose it would have to come from the index field.
>>>>
>>>> Rgds,
>>>> Steve.
>>>>
>>>> Sun Chan wrote:
>>>>> I am not disputing that. I am objecting to two ways (and in diff
>>>>> places) to handle that
>>>>>
>>>>> 2011/8/25 Stephen Clarke <stephen.cla...@st.com>:
>>>>>> Gcc behaviour for attribute aligned has changed a little in the
>>>>>> last few years. Previously it used to state:
>>>>>>
>>>>>> "The `aligned' attribute can only increase the alignment; but you
>>>>>> can decrease it by specifying `packed' as well."
>>>>>>
>>>>>> and so it used to be okay for Adjust_Alignment to always
>>>>>> increase the alignment.
>>>>>>
>>>>>> But in most gcc recent versions, it allows for attribute aligned
>>>>>> to decrease alignment also, and so to match gcc behaviour,
>>>>>> Adjust_Alignment ought not to increase the alignment in that case.
>>>>>> So there needs to be some way to detect the case. The proposal is
>>>>>> to handle that by adding a boolean flag indicating that the
>>>>>> alignment was user-specified.
>>>>>>
>>>>>> (Ok, I'm just repeating what Jian-Xin Lai has already said... but
>>>>>> with some explanation for why there used not to be a problem here.)
>>>>>>
>>>>>> Rgds,
>>>>>> Steve.
>>>>>>
>>>>>> Sun Chan wrote:
>>>>>>> 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
>>>>
>>
>>
>
> ------------------------------------------------------------------------------
> 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
