The TY has the "PACK" flag.
在 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
------------------------------------------------------------------------------
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
