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
