From: Steven E. <ste...@ya...> - 2002-06-20 18:18:56
|
I think Eric Kohl wrote the fastcall support for mingw. You may want to ask this in ros-kernel also. > I currently believe that there is a type of overflow > in gcc. What do you > think? I don't think I can get any further without > looking into the gcc > sourcecode. However I have no idea where to start > looking. Can anyone > give some pointers? __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Casper H. <ch...@it...> - 2002-06-20 21:35:13
|
tor, 2002-06-20 kl. 17:37 skrev Casper Hornstrup: > I have been chasing a bug that appear to be fastcall related. The > behaviour I get is this. When including large header files, that contain > prototypes which has __attribute__((fastcall)) attached to them, gcc may > complain that the the prototypes do not match the declarations in the > source file even if they do. If __attribute__((fastcall)) is removed or > changed to the cdecl or stdcall eqvivalents, gcc will not complain. I > have tried to make a small test case, but it seems impossible. I remove > a set of prototypes, the symptoms dissapear. I add a few prototypes, the > symptoms reappear. The prototypes don't have to have the fastcall > attribute. Some tests I have performed have revealed that the number of > parameters also affect this. Eg. remove one prototype with x parameters > so gcc will not complain. Then add one prototype with x/2 parameters > (gcc will still not complain), but add one more prototype with x/2 > parameters and gcc will comlain. I don't get the feeling that this is a > general rule, but it has happened. > > I currently believe that there is a type of overflow in gcc. What do you > think? I don't think I can get any further without looking into the gcc > sourcecode. However I have no idea where to start looking. Can anyone > give some pointers? > > Casper A little more investigation reveals what parameters are necesarry for a conflict to occur. I did these tests with two different fastcall prototypes. Results are below: PARAMETERS CONFLICT CONFLICT(2) ------------------------------------------------------------ void no no char x yes yes short x yes yes int x no no long x yes yes long long x yes yes unsigned char x yes yes unsigned short x yes yes unsigned int x no no unsigned long x no no unsigned long long x yes yes void* x no no char* x yes yes short* x yes yes int* x yes yes long* x yes yes long long* x yes yes unsigned char* x yes yes unsigned short* x yes yes unsigned int* x yes yes unsigned long* x yes yes unsigned long long* x yes yes Casper |
From: Casper H. <ch...@it...> - 2002-06-20 23:56:44
Attachments:
ch-fcdecl.diff
|
tor, 2002-06-20 kl. 17:37 skrev Casper Hornstrup: > I have been chasing a bug that appear to be fastcall related. Not the simple patch I would have expected, but here is a fix. I guess it makes sense; even though two types can have same attribute, they don't necesarrily have the same instance of it. 2002-06-20 Casper S. Hornstrup <ch...@us...> * gcc/config/i386/i386.c (ix86_comp_type_attributes): Take multiple instances of fastcall attribute into consideration when comparing fastcall attributes for two types. --- i386.c.orig Thu Jun 20 21:38:56 2002 +++ i386.c Thu Jun 20 22:09:37 2002 @@ -1434,8 +1434,8 @@ return 1; /* Check for mismatched fastcall types */ - if (lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type1)) - != lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type2))) + if (!lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type1)) + != !lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type2))) return 0; /* Check for mismatched return types (cdecl vs stdcall). */ |
From: Danny S. <dan...@cl...> - 2002-06-21 00:16:57
|
----- Original Message ----- From: "Casper Hornstrup" <ch...@it...> To: <min...@li...> Sent: Friday, 21 June 2002 07:35 Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > tor, 2002-06-20 kl. 17:37 skrev Casper Hornstrup: > > I have been chasing a bug that appear to be fastcall related. > > Not the simple patch I would have expected, but here is a fix. I guess > it makes sense; even though two types can have same attribute, they > don't necesarrily have the same instance of it. > > > 2002-06-20 Casper S. Hornstrup <ch...@us...> > > * gcc/config/i386/i386.c (ix86_comp_type_attributes): Take multiple > instances of fastcall attribute into consideration when comparing > fastcall attributes for two types. > > > --- i386.c.orig Thu Jun 20 21:38:56 2002 > +++ i386.c Thu Jun 20 22:09:37 2002 > @@ -1434,8 +1434,8 @@ > return 1; > > /* Check for mismatched fastcall types */ > - if (lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type1)) > - != lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type2))) > + if (!lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type1)) > + != !lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type2))) > return 0; > > /* Check for mismatched return types (cdecl vs stdcall). */ > > Thanks, now that you see the apparent cause, can you provide a simple testcase. Please. It will help when we try to get all this fastcall support included in official FSF sources. Danny |
From: Casper H. <ch...@it...> - 2002-06-22 12:48:52
|
fre, 2002-06-21 kl. 02:13 skrev Danny Smith: > > Thanks, now that you see the apparent cause, can you provide a simple > testcase. Please. It will help when we try to get all this fastcall > support included in official FSF sources. > > Danny I'm sorry Danny. I can't reproduce this error without including large headers. Casper |
From: Luke D. <cod...@ho...> - 2002-06-22 17:30:22
|
----- Original Message ----- From: "Casper Hornstrup" <ch...@it...> To: <min...@li...> Sent: Saturday, June 22, 2002 7:54 PM Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > fre, 2002-06-21 kl. 02:13 skrev Danny Smith: > > > > Thanks, now that you see the apparent cause, can you provide a simple > > testcase. Please. It will help when we try to get all this fastcall > > support included in official FSF sources. > > > > Danny > > I'm sorry Danny. I can't reproduce this error without including large > headers. > > Casper I think Danny tried to explain that a test case is better if it is small but this is *not required*. If you can reproduce it with large headers, then bzip2 the preprocessed file and post it. If it is still large when compressed then perhaps you could send it directly to Danny rather than the mailing list. Luke |
From: Danny S. <dan...@cl...> - 2002-06-23 04:12:51
|
> > > tor, 2002-06-20 kl. 17:37 skrev Casper Hornstrup: > > > I have been chasing a bug that appear to be fastcall related. > > > > Thanks, now that you see the apparent cause, can you provide a simple > testcase. Please. It will help when we try to get all this fastcall > support included in official FSF sources. > Here is one simple case that shows a problem, fixed by your patch. From your description, the symptoms you observed arose differently, put probably are related. #ifndef CALL #define CALL __fastcall #endif int CALL foo(); /* use "unspecified parms" prototype */ int CALL foo(int x) { return (x); } > Danny > > > > > > ------------------------------------------------------- > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Casper H. <ch...@it...> - 2002-06-23 12:54:44
|
s=F8n, 2002-06-23 kl. 06:09 skrev Danny Smith: >=20 > > > > > tor, 2002-06-20 kl. 17:37 skrev Casper Hornstrup: > > > > I have been chasing a bug that appear to be fastcall related. > > > > > > > Thanks, now that you see the apparent cause, can you provide a simple > > testcase. Please. It will help when we try to get all this fastcall > > support included in official FSF sources. > > >=20 > Here is one simple case that shows a problem, fixed by your patch. > >From your description, the symptoms you observed arose differently, put > probably are related. >=20 > #ifndef CALL > #define CALL __fastcall > #endif >=20 > int CALL foo(); /* use "unspecified parms" prototype */ > int CALL foo(int x) > { > return (x); > } >=20 >=20 > > Danny Great. I never used prototypes without parameters. Actually I thought "int foo()" was the same as "int foo(void)" and that gcc was right in complaining about foo being different from the prototype. Casper |
From: Luke D. <cod...@ho...> - 2002-06-24 01:15:23
|
----- Original Message ----- From: "Casper Hornstrup" <ch...@it...> To: <min...@li...> Sent: Sunday, June 23, 2002 8:12 PM Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > Great. I never used prototypes without parameters. Actually I thought > "int foo()" was the same as "int foo(void)" and that gcc was right in > complaining about foo being different from the prototype. > > Casper In case you were wondering, "int foo()" is the same as "int foo(void)" in C++, but in C it is sort of like "int foo(...)" (though that is not valid) for compatibility with pre-ANSI C which had no prototypes. Luke |