From: Luke D. <cod...@ho...> - 2002-06-18 09:16:05
|
The problem is in shared.cc:53 (shared_name): *(strchr(buf2, '\\')) = '\0'; I suggest that all calls to strchr() should be checked for returning a NULL pointer. Earnie? There are also two unchecked calls to strrchr() in msys.cc. The real problem, though is that these functions assume a lot about the path to the MSYS DLL. The first step in __AbsDllPath() to remove the filename part should always work (though I am not 100% sure). The code to remove the "c:\" part is a suspicious: strcpy(buf2, &buf2[3]); Firstly, strcpy() is undefined for overlapping memory blocks. Also, I think the string could be a UNC path like "\\server\foo\bin", and according to the docs: "Windows NT/2000/XP: The path can have the prefix "\\?\", depending on how the module was loaded." But this is probably not relevant because I think that prefix is for Unicode APIs only, and it disables the MAX_PATH length limitation. Luke Dunstan ----- Original Message ----- From: "terry" <te...@nc...> To: <min...@li...> Sent: Tuesday, June 18, 2002 7:41 AM Subject: [Mingw-msys] MSYS problem with "non-standard" installation > I know this is not the standard installation, but until the lastest > release > (MSYS-1.0.8-i686-2002.06.16-1.exe), it worked. I copy the files from > the > c:\msys\1.0\bin directory to c:\msys_1.0.8_bin. With this setup, C:\ > is mounted on /; c:\etc on /etc; c:\home on /home; etc. The latest > release works fine when run from c:\msys\1.0\bin but gives the following > error when run from c:\msys_1.0.8_bin: > > 0 [main] us 0 open_stackdumpfile: Dumping stack trace to > us.stackdump > > The us.stackdump file contains: > > Exception: STATUS_ACCESS_VIOLATION at eip=710587DF > eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=0022FC7C > edi=710589B5 > ebp=0022FC40 esp=0022FC28 program=us > cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023 > Stack trace: > Frame Function Args > 0022FC40 710587DF (710589B5, 0022FC7C, 0000B804, 0A000000) > 0022FD90 71058A79 (0022FEA0, 00000000, 001307D8, 00007200) > 0022FE70 71004165 (00000000, 00000000, 001307D8, 00000000) > 0022FF40 71004741 (00401BB0, 001307D8, 810CA240, 80065530) > 0022FF60 71004DBC (00000000, 00000000, 00000000, 810CA270) > 0022FF90 00405E60 (00401BB0, 810CA0E0, FFFFFFFF, 8043071C) > 0022FFC0 0040103D (001307D8, 77F82BEA, 7FFDF000, 00000000) > 0022FFF0 77E8D326 (00401000, 00000000, 000000C8, 00000100) > End of stack trace > > > Terry |
From: Danny S. <dan...@cl...> - 2002-06-20 21:37:22
|
----- Original Message ----- From: "Casper Hornstrup" <ch...@it...> To: <min...@li...> Sent: Friday, 21 June 2002 03:37 Subject: [MinGW-dvlpr] Bug in gcc fastcall support > 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 > In config/i386/i386.c, a function checks for mismatched types. TARGET_RTD refers to the -mrtd flag which makes all functions stdcall without explicitly adding the stdcall attribute: static int ix86_comp_type_attributes (type1, type2) tree type1; tree type2; { /* Check for mismatch of non-default calling convention. */ const char *const rtdstr = TARGET_RTD ? "cdecl" : "stdcall"; if (TREE_CODE (type1) != FUNCTION_TYPE) return 1; /* Check for mismatched fastcall types */ if (lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type1)) != lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type2))) return 0; /* Check for mismatched return types (cdecl vs stdcall). */ if (!lookup_attribute (rtdstr, TYPE_ATTRIBUTES (type1)) != !lookup_attribute (rtdstr, TYPE_ATTRIBUTES (type2))) return 0; return 1; } Can send me (privately) a preprocessed file that shows the bug. Small is nice but not necessary. Danny > > > > ------------------------------------------------------- > Bringing you mounds of caffeinated joy > >>> http://thinkgeek.com/sf <<< > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Casper H. <ch...@it...> - 2002-06-20 22:34:43
|
tor, 2002-06-20 kl. 23:33 skrev Danny Smith: > > ----- Original Message ----- > From: "Casper Hornstrup" <ch...@it...> > To: <min...@li...> > Sent: Friday, 21 June 2002 03:37 > Subject: [MinGW-dvlpr] Bug in gcc fastcall support > > In config/i386/i386.c, a function checks for mismatched types. > TARGET_RTD refers to the -mrtd flag which makes all functions stdcall > without explicitly adding the stdcall attribute: > > static int > ix86_comp_type_attributes (type1, type2) > tree type1; > tree type2; > { > /* Check for mismatch of non-default calling convention. */ > const char *const rtdstr = TARGET_RTD ? "cdecl" : "stdcall"; > > if (TREE_CODE (type1) != FUNCTION_TYPE) > return 1; > > /* Check for mismatched fastcall types */ > if (lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type1)) > != lookup_attribute ("fastcall", TYPE_ATTRIBUTES (type2))) > return 0; > > /* Check for mismatched return types (cdecl vs stdcall). */ > if (!lookup_attribute (rtdstr, TYPE_ATTRIBUTES (type1)) > != !lookup_attribute (rtdstr, TYPE_ATTRIBUTES (type2))) > return 0; > return 1; > } > > Can send me (privately) a preprocessed file that shows the bug. Small > is nice but not necessary. > > Danny Thanks Danny. I think the bug is in this function. I have sent a patch, but because my ISP is currently replacing their mail system my mail are delayed as much a whole day ;o( The patch should have gotten onto the list when you read this. Casper |
From: Danny S. <dan...@cl...> - 2002-06-22 20:31:43
|
----- Original Message ----- From: "Danny Smith" <dan...@cl...> To: <min...@li...> Sent: Friday, 21 June 2002 12:13 Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > > ----- 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, I've checked in this patch into gcc-3_1-cygwin-mingw branch of FSF CVS repository. It is still a bug in mingw's GCC-2.95.3-x. Do we need a maintenance release of 2.95.4 for mingw users? Danny |
From: Earnie B. <ear...@ya...> - 2002-06-23 20:54:26
|
--- Danny Smith <dan...@cl...> wrote: > > Thanks, I've checked in this patch into gcc-3_1-cygwin-mingw branch of > FSF CVS repository. > It is still a bug in mingw's GCC-2.95.3-x. Do we need a maintenance > release of 2.95.4 for mingw users? > IMO, no. Earnie. ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Wu Y. <ad...@ne...> - 2002-06-24 01:58:56
|
(Sorry for the previous wrong message to mingw-users.) I like this idea. We could also fix the isspace problem in g++-3/std/straits.h (and possibly other bugs?). I'd love to see a bug-free (or nearly so) GCC 2.x there. Best regards, Wu Yongwei --- Original Message from Danny Smith --- Thanks, I've checked in this patch into gcc-3_1-cygwin-mingw branch of FSF CVS repository. It is still a bug in mingw's GCC-2.95.3-x. Do we need a maintenance release of 2.95.4 for mingw users? Danny |
From: Danny S. <dan...@cl...> - 2002-06-25 11:22:01
|
----- Original Message ----- From: "Wu Yongwei" <ad...@ne...> To: <min...@li...> Sent: Monday, 24 June 2002 13:58 Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > (Sorry for the previous wrong message to mingw-users.) > > I like this idea. We could also fix the isspace problem in > g++-3/std/straits.h (and possibly other bugs?). What other bugs have been fixed since 2.95.3-7? Many of the outstanding bugs in 2.95 have been fixed in 3.1. Backporting these fixes to 2.95 would be very time consuming. IMO, that time would be better spent getting the new compiler stable, fixing regressions and laying foundation for 3.2 and 3.3 .... Anyway, that is how I choose to spend my time. Danny > I'd love to see a bug-free > (or nearly so) GCC 2.x there. > > Best regards, > > Wu Yongwei > > --- Original Message from Danny Smith --- |
From: Wu Y. <ad...@ne...> - 2002-06-26 02:13:47
|
Hi, Danny and Earnie, You hit me in the right open-source way. Yes, you have the right to do what you think appropriate and I have the right to ... but.... It is really a shame of me to confess that I did not succeed in building gcc yet. I started to do so yesterday (a shame, too, not having tried to do it earlier). As I argued bitterly earlier, Danny "might" easily spend one day incorporating most of the fixes, while I was still struggling for the right build. OK, it is my problem. I will dig more into the GNU auto* tools and so on when the current project of our company is over. We do things on Windows and Linux, and I often test code with every compiler in hand, MSVC, GCC, and sometimes Borland C++ Compiler 5.5.1. We don't use auto* tools. In fact, I don't like them very much. I think supporting multiple platforms directly in code like STLport is a better idea. And I do not have many platforms to support and test. -- Though, I will spend time on the GNU tools later. I have been frustrated enough by them. It's time to conquer them. Danny, is it possible that you limit the time to fix the old gcc (say, one day) and then release an enhanced version? It is not necessary that ALL bugs are fixed. It is meaningful that it is a more stable and more bug-free version than all previous ones. Of course, if it is not as stable as GCC 3.1, do not do it. Best regards (and forgive my follies), Wu Yongwei |
From: Luke D. <cod...@ho...> - 2002-06-26 07:45:14
|
Luke ----- Original Message ----- From: "Wu Yongwei" <ad...@ne...> To: <min...@li...> Sent: Wednesday, June 26, 2002 10:12 AM Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > Hi, Danny and Earnie, > > You hit me in the right open-source way. Yes, you have the right to do what > you think appropriate and I have the right to ... but.... > > It is really a shame of me to confess that I did not succeed in building gcc > yet. I started to do so yesterday (a shame, too, not having tried to do it > earlier). Did you try building GCC under Cygwin or MSYS? I just tried building gcc-2.95.3-20011106 under MSYS and I came to a problem with symbolic links (sigh). The problem is that the configure script does this (in <build_dir>/gcc/cp): ln -s ../stage1 stage1 Since ../stage1 does not exist yet at this point, MSYS ln fails (but unfortunately the configure script ignores the error). Apparently the build process has other mechanisms for systems that don't have symbolic links, but configure thinks that "ln -s" works so it doesn't attempt any alternatives. I guess I could temporarily remove the 'ln' command but is there a nicer way to make this work? The reason I haven't noticed this before is because the GCC 3.1 build process doesn't use symlinks in this way. > As I argued bitterly earlier, Danny "might" easily spend one day > incorporating most of the fixes, while I was still struggling for the right > build. You'll only learn by trying :). > > OK, it is my problem. I will dig more into the GNU auto* tools and so on > when the current project of our company is over. We do things on Windows and > Linux, and I often test code with every compiler in hand, MSVC, GCC, and > sometimes Borland C++ Compiler 5.5.1. We don't use auto* tools. In fact, I > don't like them very much. I think supporting multiple platforms directly in > code like STLport is a better idea. And I do not have many platforms to > support and test. -- Though, I will spend time on the GNU tools later. I > have been frustrated enough by them. It's time to conquer them. If your problem is not the same as mine, you should probably explain it in case it is a simple mistake that you will waste time investigating. > > Danny, is it possible that you limit the time to fix the old gcc (say, one > day) and then release an enhanced version? It is not necessary that ALL bugs > are fixed. It is meaningful that it is a more stable and more bug-free > version than all previous ones. Of course, if it is not as stable as GCC > 3.1, do not do it. > > Best regards (and forgive my follies), > > Wu Yongwei BTW, what bugs have been fixed since the latest Mingw release of GCC 2.95, apart from this new fastcall one? I assume you are talking about Mingw-specific bugs. Luke |
From: Earnie B. <ear...@ya...> - 2002-06-26 11:19:09
|
Luke Dunstan wrote: > > Luke > > ----- Original Message ----- > From: "Wu Yongwei" <ad...@ne...> > To: <min...@li...> > Sent: Wednesday, June 26, 2002 10:12 AM > Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > > > Hi, Danny and Earnie, > > > > You hit me in the right open-source way. Yes, you have the right to do > what > > you think appropriate and I have the right to ... but.... > > > > It is really a shame of me to confess that I did not succeed in building > gcc > > yet. I started to do so yesterday (a shame, too, not having tried to do it > > earlier). > > Did you try building GCC under Cygwin or MSYS? I just tried building > gcc-2.95.3-20011106 under MSYS and I came to a problem with symbolic links > (sigh). The problem is that the configure script does this (in > <build_dir>/gcc/cp): > > ln -s ../stage1 stage1 > Did you try this with the latest snapshot? It should work with MSYS. I'll give the same ago here shortly. Earnie. |
From: Luke D. <cod...@ho...> - 2002-06-27 01:37:07
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Wednesday, June 26, 2002 7:16 PM Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > Luke Dunstan wrote: > > > > > > Did you try building GCC under Cygwin or MSYS? I just tried building > > gcc-2.95.3-20011106 under MSYS and I came to a problem with symbolic links > > (sigh). The problem is that the configure script does this (in > > <build_dir>/gcc/cp): > > > > ln -s ../stage1 stage1 > > > > Did you try this with the latest snapshot? It should work with MSYS. > I'll give the same ago here shortly. > > Earnie. I just tried it with 2002.06.25-1 and I still get: $ ln -s ../stage1 stage1 ln: creating symbolic link `stage1' to `../stage1': No such file or directory The same happens with: $ ln -s ../stage1 . ln: creating symbolic link `./stage1' to `../stage1': No such file or directory It was my understanding that creating a symbolic link under MSYS simply copies the source to the destination, so I don't understand why this command should work, because as I said the _source_ directory does not exist. The only way for this to work would be to use real symlinks or to let configure know that real symlinks are not supported. Luke |
From: Jerry v. D. <jv...@at...> - 2002-06-27 09:22:04
|
Luke Dunstan writes: > I just tried it with 2002.06.25-1 and I still get: > > $ ln -s ../stage1 stage1 > ln: creating symbolic link `stage1' to `../stage1': No such file or > directory If I remember correctly, during configure it first tries if symbolic links work, then is hard links work, and if both fail, it uses 'cp' for 'ln'. Worth a check (although this might not be in the 2.95.x configure). -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Earnie B. <ear...@ya...> - 2002-06-27 10:44:08
|
Jerry van Dijk wrote: > > Luke Dunstan writes: > > > I just tried it with 2002.06.25-1 and I still get: > > > > $ ln -s ../stage1 stage1 > > ln: creating symbolic link `stage1' to `../stage1': No such file or > > directory > > If I remember correctly, during configure it first tries if symbolic links > work, then is hard links work, and if both fail, it uses 'cp' for 'ln'. > Worth a check (although this might not be in the 2.95.x configure). > Oh, that might explain why it works for me and not Luke. NTFS vs FAT. Earnie. |
From: Earnie B. <ear...@ya...> - 2002-06-27 10:46:27
|
Earnie Boyd wrote: > > Jerry van Dijk wrote: > > > > Luke Dunstan writes: > > > > > I just tried it with 2002.06.25-1 and I still get: > > > > > > $ ln -s ../stage1 stage1 > > > ln: creating symbolic link `stage1' to `../stage1': No such file or > > > directory > > > > If I remember correctly, during configure it first tries if symbolic links > > work, then is hard links work, and if both fail, it uses 'cp' for 'ln'. > > Worth a check (although this might not be in the 2.95.x configure). > > > > Oh, that might explain why it works for me and not Luke. NTFS vs FAT. ^^ (the gcc build) Earnie. |
From: Luke D. <cod...@ho...> - 2002-06-28 03:01:12
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Thursday, June 27, 2002 6:44 PM Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > Earnie Boyd wrote: > > > > Jerry van Dijk wrote: > > > > > > Luke Dunstan writes: > > > > > > > I just tried it with 2002.06.25-1 and I still get: > > > > > > > > $ ln -s ../stage1 stage1 > > > > ln: creating symbolic link `stage1' to `../stage1': No such file or > > > > directory > > > > > > If I remember correctly, during configure it first tries if symbolic links > > > work, then is hard links work, and if both fail, it uses 'cp' for 'ln'. > > > Worth a check (although this might not be in the 2.95.x configure). > > > > > > > Oh, that might explain why it works for me and not Luke. NTFS vs FAT. > ^^ (the gcc build) > > Earnie. No, I tried it on Windows 2000 with NTFS but this can't be relevant because as Jerry pointed out, configure tries symbolic links first and _succeeds_, so it doesn't consider hard links or 'cp'. If building exactly the same source package (i.e. not the MSYS compiler) works for you under MSYS, then I suppose it could be a problem with my installation. If you don't mind, is there a 'stage1' subdirectory/link in the 'gcc/cp' language subdirectory after configuring (before 'make bootstrap')? Also, what are @symbolic_link@ and @cc_set_by_configure@ set to in gcc/config.status? For me they are "ln -s" and "$(CC)". Note that this is separate from the @LN_S@ variable for some reason. I know it is obvious, but I would also ask you to confirm that you enabled the C++ language driver. If the build directory is not clean then that may also cause it to succeed. P.S.: I do not NEED to build this compiler, but I would just like to make sure it works for all MSYS users out of the box. Luke |
From: Wu Y. <ad...@ne...> - 2002-06-27 01:55:13
|
Oh, is it that difficult? My original thought is that it is easy to incorporate the fastcall fix and similar fixes. I did not mean to backport all the 3.1 fixes. To be honest, I do not mind bugs that are seldom encountered, but the fastcall bug seems something easier to encounter. In fact, I thought of using half a day or even two hours instead of the "one day" in my original message. I meant some easy job for you. Best regards, Wu Yongwei --- Original Messag from Danny Smith --- ----- Original Message ----- From: "Wu Yongwei" <ad...@ne...> To: <min...@li...> Sent: Wednesday, 26 June 2002 14:12 Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > Danny, is it possible that you limit the time to fix the old gcc (say, one > day) and then release an enhanced version? It is not necessary that ALL bugs > are fixed. It is meaningful that it is a more stable and more bug-free > version than all previous ones. Of course, if it is not as stable as GCC > 3.1, do not do it. I cannot do it in a day. If I could, I would. Danny |
From: Christopher F. <cg...@re...> - 2002-06-27 15:57:16
|
On Thu, Jun 27, 2002 at 09:54:47AM +0800, Wu Yongwei wrote: >Oh, is it that difficult? My original thought is that it is easy to >incorporate the fastcall fix and similar fixes. I did not mean to backport >all the 3.1 fixes. To be honest, I do not mind bugs that are seldom >encountered, but the fastcall bug seems something easier to encounter. > >In fact, I thought of using half a day or even two hours instead of the "one >day" in my original message. I meant some easy job for you. 3.1 and 2.95 are very different. Backporting isn't trivial. cgf |
From: Wu Y. <ad...@ne...> - 2002-06-27 02:00:58
|
I tried to build under cygwin, and used a fake ln like this: #!/bin/sh case $1 -s) shift esac cp -p $1 $2 I created an objdir under the gcc directory, and configured and made there. I choked at something about libgcc2. Maybe the same point as yours. Maybe Danny could post his method? Best regards, Wu Yongwei --- Original Message from Luke Dunstan --- Did you try building GCC under Cygwin or MSYS? I just tried building gcc-2.95.3-20011106 under MSYS and I came to a problem with symbolic links (sigh). The problem is that the configure script does this (in <build_dir>/gcc/cp): ln -s ../stage1 stage1 Since ../stage1 does not exist yet at this point, MSYS ln fails (but unfortunately the configure script ignores the error). Apparently the build process has other mechanisms for systems that don't have symbolic links, but configure thinks that "ln -s" works so it doesn't attempt any alternatives. I guess I could temporarily remove the 'ln' command but is there a nicer way to make this work? The reason I haven't noticed this before is because the GCC 3.1 build process doesn't use symlinks in this way. |
From: Wu Y. <ad...@ne...> - 2002-06-28 02:22:51
|
OK, let's forget about gcc-2.95.4. (I see no hope of persuading Danny to do it, while no one else seems willing to do it.) Danny, is it POSSIBLE that you spend an hour or so fixing the fastcall bug and similar easy-to-incorporate bugs and release a snapshot (gcc-2.95.3-8 or gcc-2.95.3-200207xx)? Danny, PLEASE consider the possibility. My computer is not fast and I do not want to use a 2-to-4-time-slower compiler for now. I know GCC 3 is better, just that I do not afford it (similar case that I prefer Netscape Communicator 4 to Netscape 6/7). At least it will be useful when compiling small C programs. Best regards, Wu Yongwei |
From: Danny S. <dan...@cl...> - 2002-06-28 03:50:36
|
----- Original Message ----- From: "Wu Yongwei" <ad...@ne...> To: <min...@li...> Sent: Friday, 28 June 2002 14:21 Subject: Re: [MinGW-dvlpr] Bug in gcc fastcall support > OK, let's forget about gcc-2.95.4. (I see no hope of persuading Danny to do > it, while no one else seems willing to do it.) Danny, is it POSSIBLE that > you spend an hour or so fixing the fastcall bug and similar > easy-to-incorporate bugs and release a snapshot (gcc-2.95.3-8 or > gcc-2.95.3-200207xx)? > > Danny, PLEASE consider the possibility. My computer is not fast and I do not > want to use a 2-to-4-time-slower compiler for now. I know GCC 3 is better, > just that I do not afford it (similar case that I prefer Netscape > Communicator 4 to Netscape 6/7). At least it will be useful when compiling > small C programs. > > Best regards, > > Wu Yongwei > I'll put it on my TODO list. It is after 3.1.1 release candidate (hopefully in mid/late July). Danny > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Bringing you mounds of caffeinated joy. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Casper H. <ch...@it...> - 2002-06-28 13:29:26
|
fre, 2002-06-28 kl. 04:21 skrev Wu Yongwei: > OK, let's forget about gcc-2.95.4. (I see no hope of persuading Danny to do > it, while no one else seems willing to do it.) Danny, is it POSSIBLE that > you spend an hour or so fixing the fastcall bug and similar > easy-to-incorporate bugs and release a snapshot (gcc-2.95.3-8 or > gcc-2.95.3-200207xx)? > > Danny, PLEASE consider the possibility. My computer is not fast and I do not > want to use a 2-to-4-time-slower compiler for now. I know GCC 3 is better, > just that I do not afford it (similar case that I prefer Netscape > Communicator 4 to Netscape 6/7). At least it will be useful when compiling > small C programs. > > Best regards, > > Wu Yongwei I'm currious as to why you need fastcall support. IIRC no Win32 APIs use the fastcall calling convention. Since you have not reported this bug before, it does not seem to affect you very much. Casper |
From: Wu Y. <ad...@ne...> - 2002-07-01 03:22:10
|
Simply put, I like fast compilers that produce fast and compact code. One of the reasons I like gcc is that it can produce the smallest code possible for C programs. I'd like to have the fastcall feature to accelerate my code. One reason I don't like BCC32 5.5.1 is that it generally produces bigger and slower code than MSVC and GCC, though it has better fastcall support. The only time I remember BCC32 produced faster code is when I once built a C++ program with STLport; without STLport it produced TERRIBLY slow (TWENTY times slower) code. Best regards, Wu Yongwei --- Original Message from Casper Hornstrup <ch...@it...> --- I'm currious as to why you need fastcall support. IIRC no Win32 APIs use the fastcall calling convention. Since you have not reported this bug before, it does not seem to affect you very much. Casper |
From: Earnie B. <ear...@ya...> - 2002-06-19 12:23:21
|
Luke Dunstan wrote: > > The problem is in shared.cc:53 (shared_name): > > *(strchr(buf2, '\\')) = '\0'; > > I suggest that all calls to strchr() should be checked for returning a NULL > pointer. Earnie? There are also two unchecked calls to strrchr() in msys.cc. > Yes, of course you're correct, I've now guarded the pointer sets; however, I probably should do something else if they're not set. > The real problem, though is that these functions assume a lot about the path > to the MSYS DLL. The first step in __AbsDllPath() to remove the filename > part should always work (though I am not 100% sure). The code to remove the > "c:\" part is a suspicious: > > strcpy(buf2, &buf2[3]); > > Firstly, strcpy() is undefined for overlapping memory blocks. Also, I think > the string could be a UNC path like "\\server\foo\bin", and according to the > docs: > > "Windows NT/2000/XP: The path can have the prefix "\\?\", depending on how > the module was loaded." > I was aware of these other patterns and chose at the time not to deal with them. Patches are welcome. Earnie. |
From: Luke D. <cod...@ho...> - 2002-06-20 01:44:52
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Wednesday, June 19, 2002 8:21 PM Subject: Re: [MinGW-dvlpr] Re: [Mingw-msys] MSYS problem with "non-standard" installation > > The real problem, though is that these functions assume a lot about the path > > to the MSYS DLL. The first step in __AbsDllPath() to remove the filename > > part should always work (though I am not 100% sure). The code to remove the > > "c:\" part is a suspicious: > > > > strcpy(buf2, &buf2[3]); > > > > Firstly, strcpy() is undefined for overlapping memory blocks. Also, I think > > the string could be a UNC path like "\\server\foo\bin", and according to the > > docs: > > > > "Windows NT/2000/XP: The path can have the prefix "\\?\", depending on how > > the module was loaded." > > > > I was aware of these other patterns and chose at the time not to deal > with them. Patches are welcome. > > Earnie. I was just thinking that since a file-mapping object name "can contain any character except the backslash character", what if we just got the entire path from AbsDllPath() and replaced backslashes with forward slashes, then used the result as part of the object name? I haven't tried it yet, but I just wanted to know what you thought. Luke |
From: Casper H. <ch...@it...> - 2002-06-20 15:59:48
|
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 |