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 > ------------------------------------------------------------------------------ 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
