Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-1841054 ] Bad compilation
|
From: SourceForge.net <no...@so...> - 2007-11-29 19:08:18
|
Bugs item #1841054, was opened at 2007-11-29 16:26 Message generated for change (Comment added) made by jkarretero_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1841054&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: Waiting User Response >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: jkarretero (jkarretero_) Assigned to: Nobody/Anonymous (nobody) Summary: Bad compilation Initial Comment: I compile bug.c (attached) saccesfully. However, the execution has a bug. The output of the program is: 1.j=1 1.k=2 2.j=1 2.k=62 When it is expected to be: 1.j=1 1.k=2 2.j=1 2.k=2 The source no_bug.c (attached) gives the expected output. The only difference between bug.c and no_bug.c is the line in wich unused variable "i" is defined. In bug.c, variable "i" is defined in line 35. In no_bug.c, variable "i" is defined in line 29. * OS version: Windows XP Professional SP2 * gcc version ( 'gcc -v' ) Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) * ld version ( 'ld -v' ): GNU ld version 2.16.91 20060119 * mingw version ( name of installer package eg/ MinGW-2.0.0-3.exe ) Don't remember, but think it was MinGW-5.1.3.exe * small test case demonstrating the bug OR I have attached file bug.c * MSDN documentation references for missing w32api or mingw-runtime features The documentation of the UuidFromString function can be found here: http://msdn2.microsoft.com/en-us/library/aa379336.aspx * mingw-runtime version ( include/_mingw.h ) The following line can be found in _mingw.h: #define __MINGW32_VERSION 3.13 * w32api version ( include/w32api.h ) The following line can be found in w32api.h: #define __W32API_VERSION 3.10 * any other detailed information pertinent to your experience with the bug I had this bug in a much bigger program. It tooks around 20 hours to me to reduce the program until get where was the problem. If you fix this bug, it will help lots of people. Thanks! ---------------------------------------------------------------------- >Comment By: jkarretero (jkarretero_) Date: 2007-11-29 20:08 Message: Logged In: YES user_id=1847057 Originator: YES Hello keithmarshall!. Yes, that's correct, the definition of UuidFromString is the following: RPCRTAPI RPC_STATUS RPC_ENTRY UuidFromString ( __in_opt RPC_CSTR StringUuid, __out UUID __RPC_FAR * Uuid ); [1] but my MinGW doesn't understand it, so I have to translate it. In my system, according to Visual Studio 2005, I have the following: RPCRTAPI = "__declspec(dllimport)" RPC_STATUS = "long" RPC_ENTRY = "__stdcall" UuidFromString = "UuidFromStringW" __in_opt = "" RPC_CSTR = "unsigned char *" __out = "" UUID = "struct _GUID" __RPC_FAR = "" So, translating: [1], I have this: __declspec(dllimport) long __stdcall UuidFromStringW(unsigned char * StringUuid, struct _GUID * Uuid); [2] However, if I declare UuidFromString as [2] I get the following error: undefined reference to `UuidFromStringW@8' And if I declare UuidFromString as __declspec(dllimport) long UuidFromStringW(unsigned char * StringUuid, struct _GUID * Uuid); or as __cdecl long UuidFromStringW(unsigned char * StringUuid, struct _GUID * Uuid); It compiles perfectly but it executes with the same bug. I don't think that the problem is the UuidFromString header. If you think so, please give me a MinGw understandable header that doesn't reproduce the bug. Thanks! ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2007-11-29 18:09 Message: Logged In: YES user_id=823908 Originator: NO Correction to my previous comment: You've incorrectly prototyped UuidFromStringW() as a function, (__cdecl by default), [returning a long], when MSDN says... The phrase in square brackets was omitted from the earlier comment. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2007-11-29 17:56 Message: Logged In: YES user_id=823908 Originator: NO At first glance, the bug appears to be in your code. You've incorrectly prototyped UuidFromStringW() as a function, (__cdecl by default), when MSDN says it should be RPC_STATUS RPC_ENTRY UuidFromString(). I haven't checked what those manifest declarations resolve to, but it's certain *not* to be `long __cdecl'. Thus, after you've called this function, your stack will have been trashed, so anything could happen. Usually, when moving declarations around changes the manifestation of a runtime bug, it's a sure sign that *you've* done something wrong, causing a corrupt stack. Does this "bug" go away, if you include the proper headers instead of defining the structures and prototypes yourself? My initial suspicion is that this is your bug, and not a compiler fault at all; I'm flagging it as `invalid', pending your correction of your test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1841054&group_id=2435 |