alignment is not just for performance, and the compiler does alignment for all kinds of reasons. What Mike said is that the alignment should have been set in the TY. Adding alignment in symbol will only confuse things. Sun
2011/8/25 Jian-Xin Lai <laij...@gmail.com>: > This case comes from kernel. It requires a strict alignment for the data. > In Adjust_Alignment, we trend to increase the alignment (for example, to 16 > byte) for better performance. Usually, it is OK. But if the code specifies a > special alignment like this example, we need to follow it. > > 在 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
