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
