In SL, as for the proposed case, control does not goes to the suggested
patch.
Gang
On Fri, Nov 19, 2010 at 9:26 AM, Sun Chan <sun.c...@gmail.com> wrote:
> thx Gang!
> Can you add the proposed changes to your vers...@sl and see if it
> affects the code for you?
> Sun
>
> On Fri, Nov 19, 2010 at 9:23 AM, Gang Yu <yugang...@gmail.com> wrote:
> > It looks ok in SL.
> >
> > .section .bss
> > .org 0x0
> > .align 0
> > .type line3, @object
> > .size line3, 1
> > line3: # 0x0
> > .skip 1
> > .org 0x1
> > .align 0
> > .type line4, @object
> > .size line4, 1
> > line4: # 0x1
> >
> >
> > Gang
> >
> >
> > On Fri, Nov 19, 2010 at 12:04 AM, Sun Chan <sun.c...@gmail.com> wrote:
> >>
> >> this problem is too simple to be wrong, makes me think something
> >> really bad has happened. Can someone try the case for a different
> >> target (such as IA64, SL, Mips ...?)
> >> I'd like to know why this fails with a broader code fragment for review.
> >>
> >> Mike,
> >> What do you think?
> >>
> >> Sun
> >>
> >> On Thu, Nov 18, 2010 at 5:41 PM, 朱庆 <zqing1...@gmail.com> wrote:
> >> > Hi, All
> >> >
> >> > Can gatekeeper help review this fix?
> >> >
> >> > Case a.c:
> >> > struct line { char a[0];};
> >> > static struct line line3;
> >> > static struct line line4;
> >> > static const char a[3]={0,1,2};
> >> > int main()
> >> > {
> >> > return 0;
> >> > }
> >> >
> >> > The feature of the case is: at least two global var in .bss section
> and
> >> > the
> >> > type size of them is 0, then a var in .rodata or .data.rel.ro.local
> >> > section.
> >> >
> >> > $opencc -O0 a.c -keep
> >> > a.s: Assembler messages:
> >> > a.s:65: Error: attempt to move .org backwards
> >> >
> >> > $cat a.s
> >> > 19 .text
> >> > 20 .align 2
> >> > 21
> >> > 22 .section .bss, "wa",@nobits
> >> > 23
> >> > 24 .section .rodata, "a",@progbits
> >> > 25 .type line3, @object
> >> > 26 .size line3, 1
> >> > 27 line3: # 0x0
> >> > 28 .skip 16
> >> > 29 .type line4, @object
> >> > 30 .size line4, 1
> >> > 31 line4: # 0x10
> >> > ....
> >> > 63
> >> > 64 .section .rodata
> >> > 65 .org 0x0
> >> > 66 .align 0
> >> > 67 .type a, @object
> >> > 68 .size a, 3
> >> > 69 a: # 0x0
> >> > 70 # offset 0
> >> > 71 .byte 0
> >> > 72 # offset 1
> >> > 73 .byte 1
> >> > 74 # offset 2
> >> > 75 .byte 2
> >> > 76 # end of initialization for a
> >> >
> >> > Apperently, line25-31, should be in section .bss, so there is missing
> >> > section name emit. To fix the problem, there are many
> >> > methods(cgemit.cxx):
> >> > 1. change all size from 0 to 1 like C++ empty calss
> >> > 8090 size = TY_size(ST_type(sym));
> >> > 8091 // C++ requires empty classes to have unique
> addresses.
> >> > 8092 if (size == 0 && (pu == NULL || PU_cxx_lang(*pu)/*bug
> >> > 13826*/))
> >> > 8093 size = 1;
> >> > 2. remove the "size!=0" from the branch
> >> > 8122 if (!has_named_section && size != 0) {
> >> > 8123 Change_Section_Origin (base, ofst);
> >> > 8124 if ( !Simd_Reallocate_Objects ) {
> >> > 8125 // If Simd_Reallocate_Objects, we already
> emitted
> >> > alignment
> >> > 8126 // inside Change_Section_Origin - may be screwed
> >> > up
> >> > but we did
> >> > 3. add emit for section name:
> >> > patch:
> >> > Index: osprey/be/cg/cgemit.cxx
> >> > ===================================================================
> >> > --- osprey/be/cg/cgemit.cxx (revision 3403)
> >> > +++ osprey/be/cg/cgemit.cxx (working copy)
> >> > @@ -8167,8 +8167,13 @@
> >> > size = TY_size(ST_type(sym));
> >> > #ifdef KEY
> >> > // C++ requires empty classes to have unique
> addresses.
> >> > - if (size == 0)
> >> > + if (size == 0) {
> >> > + if (base != cur_section) {
> >> > + fprintf ( Asm_File, "\n\t%s %s\n", AS_SECTION,
> >> > ST_name(base));
> >> > + cur_section = base;
> >> > + }
> >> > Print_Label (Asm_File, sym, 1);
> >> > + }
> >> > else
> >> > #endif
> >> > Print_Label (Asm_File, sym, size);
> >> >
> >> > I prefer the last one, are there any other suggestions?
> >> >
> >> >
> >> > Best Regards,
> >> > Zhu Qing
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Beautiful is writing same markup. Internet Explorer 9 supports
> >> > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> >> > Spend less time writing and rewriting code and more time creating
> great
> >> > experiences on the web. Be a part of the beta today
> >> > http://p.sf.net/sfu/msIE9-sfdev2dev
> >> > _______________________________________________
> >> > Open64-devel mailing list
> >> > Open64-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >> >
> >> >
> >>
> >>
> ------------------------------------------------------------------------------
> >> Beautiful is writing same markup. Internet Explorer 9 supports
> >> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> >> Spend less time writing and rewriting code and more time creating great
> >> experiences on the web. Be a part of the beta today
> >> http://p.sf.net/sfu/msIE9-sfdev2dev
> >> _______________________________________________
> >> Open64-devel mailing list
> >> Open64-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >
> >
>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
