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
