From: Johan K. <joh...@id...> - 2001-10-16 15:01:39
|
Yes, this is bug #436360. > int xdata Array1Glob[2]; > > void > f2 (int xdata Array1Par[2]) > > Array1Par[1] = 2; > } > > SDCC stores _f2_Array1Par_1_1 in xdata instead of data. There is no way to specify where the pointer that could be needed to pass Array1Par as a parameter should reside. Until now it used the same storage as the array itself. Now it is the default space for the port, so that --model-small can keep it registered (no storage required) and other ports aren't affected (although I don't see why --model-large still requires storage, -mds390 doesn't). > void > f3 (int Array1Par[2]) > > Array1Par[0] = 1; > } > > void > f1 (void) > > f2 (Array1Glob); > f3 (Array1Glob); > } > > No warning when calling f3. That one is tricky. The defined parameter of f3 is: "data int * data defParm" (assuming --model-small). The actual parameter when f3 is called is: "xdata int actParm[]". Now compareType() doesn't know how to handle this and bails out, saying ok: ptr, array, what the heck: castable. The whole problem is the array declarator. I don't see any reason why an array just shouldn't be a pointer with (or without) a number of elements. So that compareType() could do what it is suppost to do: check the COMPLETE type chain. If I don't hear why I shouldn't I will make it so. > Another problem: > > typedef int Array1Dim[51]; > xdata Array1Dim Array1Glob; > > void > f4 (xdata Array1Dim Array1Par) > > Array1Par[1] = 1; > } > > void > f5 (void) > > f4 (Array1Glob); > } > > error: *** two or more storage classes in declaration for 'type_specifier_list' Fixed in the typedef handling in SDCC.y. This could also fix some other bug reports, haven't checked that yet. Johan |
From: <no...@so...> - 2001-06-26 12:28:14
|
Bugs item #436360, was opened at 2001-06-26 05:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=436360&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Held (bernhardheld) Assigned to: Nobody/Anonymous (nobody) Summary: Arrays + memory modifier + parameter Initial Comment: int xdata Array1Glob[2]; void f2 (int xdata Array1Par[2]) { Array1Par[1] = 2; } void f3 (int Array1Par[2]) { Array1Par[0] = 1; } void f1 (void) { f2 (Array1Glob); f3 (Array1Glob); } SDCC stores _f2_Array1Par_1_1 in xdata instead of data. No warning when calling f3. Another problem: typedef int Array1Dim[51]; xdata Array1Dim Array1Glob; void f4 (xdata Array1Dim Array1Par) { Array1Par[1] = 1; } void f5 (void) { f4 (Array1Glob); } error: *** two or more storage classes in declaration for 'type_specifier_list' error *** storage class CANNOT be specified for bit variable 'Array1Par' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=436360&group_id=599 |
From: Bernhard H. <ber...@be...> - 2001-10-16 15:39:10
|
> Yes, this is bug #436360. :-) > So > that compareType() could do what it is suppost to do: check the COMPLETE > type chain. If I don't hear why I shouldn't I will make it so. IMHO it's necessary to compare the complete chain. This is exactly the topic, about which I planned to write my next bug report :-) Hmm, after fixing this I should try again to port the dhrystone test to the mcs51 ... Bernhard |
From: Johan K. <joh...@id...> - 2001-10-17 16:28:57
|
> > Yes, this is bug #436360. > > :-) > > > So > > that compareType() could do what it is suppost to do: check the COMPLETE > > type chain. If I don't hear why I shouldn't I will make it so. I didn't touch the ARRAY declarator but reshaped compareType() itself a little. Now the complete type chain is checked. It could use some more testing though. Bernhard, please close the bug if you agree. Unfortunatly this breaks the regression tests and malloc.c Could some one look at that? Johan |
From: Michael H. <mic...@ju...> - 2001-10-18 02:14:44
|
Fixed the regression tests. I never want to learn that much about function pointers and returning arrays of function pointers again. -- Michael On Wed, 17 Oct 2001, Johan Knol wrote: > > > > > Yes, this is bug #436360. > > > > :-) > > > > > So > > > that compareType() could do what it is suppost to do: check the COMPLETE > > > type chain. If I don't hear why I shouldn't I will make it so. > > I didn't touch the ARRAY declarator but reshaped compareType() itself a > little. Now the complete type chain is checked. It could use some more > testing though. > > Bernhard, please close the bug if you agree. > > Unfortunatly this breaks the regression tests and malloc.c > Could some one look at that? > > Johan > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Bernhard H. <ber...@be...> - 2001-10-22 08:35:40
|
> > > Yes, this is bug #436360. > > > > :-) > > > > > So > > > that compareType() could do what it is suppost to do: check the COMPLETE > > > type chain. If I don't hear why I shouldn't I will make it so. > > I didn't touch the ARRAY declarator but reshaped compareType() itself a > little. Now the complete type chain is checked. It could use some more > testing though. > > Bernhard, please close the bug if you agree. Done. After examining the code supplied with bug #436360, I understand now the remaining problem: _f2_Array1Par_1_1, declared by "f2 (int xdata Array1Par[2]) ", is in xdata space. This means, that --stack-auto is not possible: *** storage class not allowed for automatic variable 'Array1Par' in reentrant function unless static Bernhard |
From: Bernhard H. <ber...@be...> - 2001-10-18 09:51:43
|
> I didn't touch the ARRAY declarator but reshaped compareType() itself a > little. Now the complete type chain is checked. It could use some more > testing though. > > Bernhard, please close the bug if you agree. Yes, but please give me some time. > Unfortunatly this breaks the regression tests and malloc.c > Could some one look at that? In malloc.c a "MEMHEADER xdata *" is returned, while the return type is "void xdata *". I think this should go without any warning by an automatic conversion. Bernhard |
From: Johan K. <joh...@id...> - 2001-10-19 11:00:25
|
----- Original Message ----- From: Bernhard Held <ber...@be...> To: <sdc...@li...> Sent: Thursday, October 18, 2001 11:48 AM Subject: Re: [sdcc-devel] Arrays + memory modifier + parameter > > I didn't touch the ARRAY declarator but reshaped compareType() itself a > > little. Now the complete type chain is checked. It could use some more > > testing though. > > > > Bernhard, please close the bug if you agree. > > Yes, but please give me some time. > > > Unfortunatly this breaks the regression tests and malloc.c > > Could some one look at that? > > In malloc.c a "MEMHEADER xdata *" is returned, while the return type is > "void xdata *". I think this should go without any warning by an automatic > conversion. No, the MEMHEADER's unsigned char mem[] was returned. The array get's converted to a gpointer for ds390, a fpointer for model-large and a pointer for all others. The function returns a fpointer, so in model-large everything is fine. It would produce bogus code in all others. Instead of allowing this, I fixed malloc.c itself. Would be nice if someone could test malloc. Johan |
From: Bernhard H. <ber...@be...> - 2001-10-21 18:31:50
|
> > > Unfortunatly this breaks the regression tests and malloc.c > > > Could some one look at that? > > > > In malloc.c a "MEMHEADER xdata *" is returned, while the return type is > > "void xdata *". I think this should go without any warning by an > > automatic conversion. > > No, the MEMHEADER's unsigned char mem[] was returned. > The array get's converted to a gpointer for ds390, a fpointer for > model-large and a pointer for all others. The function returns a fpointer, > so in model-large everything is fine. It would produce bogus code in all > others. Instead of allowing this, I fixed malloc.c itself. Would be nice if > someone could test malloc. Sorry, I can't agree. If the structure MEMHEADER is in xdata, then all members are in xdata. It doesn't matter, if mem is an array or not. It is in xdata. This means: &mh->mem is a pointer to xdata. Anything else is a bug. void xdata *foo() { struct MEMHEADER { unsigned int len; unsigned char mem; }; struct MEMHEADER xdata *mh; return &mh->mem; } This example should compile without warning. Bernhard |
From: Johan K. <joh...@id...> - 2001-10-21 19:15:40
|
> Sorry, I can't agree. If the structure MEMHEADER is in xdata, then all members are in xdata. It doesn't matter, if mem is an array or not. It is in xdata. > This means: &mh->mem is a pointer to xdata. Anything else is a bug. > > void xdata *foo() > { > struct MEMHEADER > { > unsigned int len; > unsigned char mem; > }; > struct MEMHEADER xdata *mh; > > return &mh->mem; > } > > This example should compile without warning. Agreed. Right now the address of a structure member doesn't take into account the storage spec of the structure itself. In fact you could do something like: struct MEMHEADER { data char dataChar; code char codeChar; xdata char xdataChar; } idata mh; which would be nonsense ofcourse. I mentioned this before, so I am aware of this. This wasn't the point however. If you have an array "somewhere", you can easely cast that to a pointer to "somewhere", but you don't have control over where that pointer itself will be if it requires physical storage. Hmmm, this could be my next challange. Johan |
From: Bernhard H. <ber...@be...> - 2001-10-22 07:42:41
|
> > This means: &mh->mem is a pointer to xdata. Anything else is a bug. > > > > void xdata *foo() > > { > > struct MEMHEADER > > { > > unsigned int len; > > unsigned char mem; > > }; > > struct MEMHEADER xdata *mh; > > > > return &mh->mem; > > } > > > > This example should compile without warning. > > Agreed. Right now the address of a structure member doesn't take into > account the storage spec of the structure itself. In fact you could do > something like: > > struct MEMHEADER { > data char dataChar; > code char codeChar; > xdata char xdataChar; > } idata mh; > > which would be nonsense ofcourse. I mentioned this before, so I am aware of > this. Ok, you see the problem and I'll be happy. Bernhard |