See, Thx!

在 2011年8月26日 下午7:06,Stephen Clarke <stephen.cla...@st.com>写道:

> But Jian-Xin Lai proposed to change TY_IDX, not TY.
>
> The TY_IDX value for a symbol is in the ST, and is not shared with
> other symbols.
>
> Steve.
>
> ruifen Shen wrote:
> >
> > Setting alignment to TY will change all this type data.
> > But sometimes, we just want to change one data of this type.
> > PS: this case works well for SL target.
> > 在 2011年8月26日 下午1:19,Jian-Xin Lai <laij...@gmail.com
> > <mailto:laij...@gmail.com>>写道:
> >
> >     Understand. We'll make a new change and keep this info in TY_IDX,
> >     instead of in ST.
> >
> >     在 2011年8月25日 下午4:01,Sun Chan <sun.c...@gmail.com
> >     <mailto: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
> >         <mailto: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
> >         <mailto:sun.c...@gmail.com>>写道:
> >          >>
> >          >> How would you classify "pack" data?
> >          >> Sun
> >          >>
> >          >> 2011/8/25 Jian-Xin Lai <laij...@gmail.com
> >         <mailto: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
> >         <mailto: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
> >         <mailto:zqing1...@gmail.com>]
> >          >> >> Sent: Wednesday, August 24, 2011 10:53 PM
> >          >> >> To: Mike Murphy
> >          >> >> Cc: Sun Chan; open64-devel@lists.sourceforge.net
> >         <mailto: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 <mailto: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
> >         <mailto:sun.c...@gmail.com>]
> >          >> >> > Sent: Wednesday, August 24, 2011 7:51 PM
> >          >> >> > To: 朱庆
> >          >> >> > Cc: open64-devel@lists.sourceforge.net
> >         <mailto: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
> >         <mailto:zqing1...@gmail.com>>:
> >          >> >> >> Hi Sun,
> >          >> >> >>
> >          >> >> >> Attached symtab_defs.h.
> >          >> >> >>
> >          >> >> >> Thanks
> >          >> >> >> zhuqing
> >          >> >> >> 2011/8/24 Sun Chan <sun.c...@gmail.com
> >         <mailto: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 <mailto: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
> >         <mailto: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
> >         <mailto: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
> >         <mailto: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
> >         <mailto:Open64-devel@lists.sourceforge.net>
> >          >> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >          >> >
> >          >> >
> >          >
> >          >
> >          >
> >          > --
> >          > 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
> >     <mailto:Open64-devel@lists.sourceforge.net>
>  >     https://lists.sourceforge.net/lists/listinfo/open64-devel
> >
> >
> >
> >
> > --
> > Best Regards.
> >
> > Shen Ruifen
> >
> > tel: 010-51266989-226
> >
>
>


-- 
Best Regards.

Shen Ruifen

tel: 010-51266989-226
------------------------------------------------------------------------------
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

Reply via email to