If user don't specify the alignment, the compiler has some freedom to do
some adjustment for performance or what ever.
在 2011年8月25日 下午4:35，Sun Chan <sun.c...@gmail.com>写道：
> 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
> >
>
--
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
