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
