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