[Bug testsuite/36057] struct-layout-1_generate.c uses non-ISO C '%n$' operand number formats
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-27 06:03 --- Changed summary to be more precise about non-standard. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Summary|struct-layout-1_generate.c |struct-layout-1_generate.c |uses non-standard '%n$'|uses non-ISO C '%n$' |operand number formats |operand number formats http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36057
[Bug target/35661] __attribute__((cold)) generates wrong code
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-05-11 21:09 --- Fixed on 4_3 branch -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35661
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-05-11 22:46 --- Following is with mingw but it applies to cygwin as well This is the command line from log for FAILing 22_locale/locale/cons/unicode.cc Executing on host: /develop/svn/trunk/build/./gcc/g++ -shared-libgcc -B/develop/svn/trunk/build/./gcc -nostdinc++ -L/develop/svn/trunk/build/mingw32/libstdc++-v3/src -L/develop/svn/trunk/build/mingw32/libstdc++-v3/src/.libs -L/develop/svn/trunk/build/mingw32/winsup/mingw -L/develop/svn/trunk/build/mingw32/winsup/w32api/lib -isystem /develop/svn/trunk/src/winsup/mingw/include -isystem /develop/svn/trunk/src/winsup/w32api/include -B/mingw/mingw32/bin/ -B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem /mingw/mingw32/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/develop/svn/trunk/build/mingw32/libstdc++-v3/include/mingw32 -I/develop/svn/trunk/build/mingw32/libstdc++-v3/include -I/develop/svn/trunk/src/libstdc++-v3/libsupc++ -I/develop/svn/trunk/src/libstdc++-v3/include/backward -I/develop/svn/trunk/src/libstdc++-v3/testsuite/util -Wl,--gc-sections /mingw/lib/libiconv.a /develop/svn/trunk/src/libstdc++-v3/testsuite/22_locale/locale/cons/unicode.cc -include bits/stdc++.h ./libtestc++.a -lm -o ./unicode.exe(timeout = 600) Note that although the correct libiconv /mingw/lib/libiconv.a is passed to linker, it is passed *before* the objects and libraries that reference libiconv symbols. With PE-COFF, the order of objects really does matter and since the libiconv symbols have not yet been referenced when the linker looks at the lib, the symbols are not resolved. They are not resolved lazily as is possible in ELF Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libgcj/36218] [4.4 regression] libgcj causes stack overflow in jc1.exe
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-05-13 03:52 --- (In reply to comment #0) What negative consequences does increasing the default [stack] allocation have? Minimal really, for a single threaded program like jc1.exe. We are just reserving address space not actual memory. In a multithreaded app, each thread reserves the same amount of address space as the primary thread (by default, but the default can be overiden), so too high a stack reserve for main thread can limit what is available for others. Is it possible to adjust this limit at runtime, perhaps as needed? No, not for main thread. It is built into the program header on MS windows. GNAT also bumps stack reserve to 32 MB for non-tasking apps. See system-mingw.ads. In old days, 32 MB was default for win32 in gnu ld. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-05-17 07:27 --- Is this related to PR35493? A possibly related cygwin failure was also reported here. http://gcc.gnu.org/ml/gcc/2008-03/msg00681.html. My last successful build of Ada on mingw was: gcc version 4.4.0 20080312 (experimental) (GCC) Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-05-29 21:00 --- (In reply to comment #7) Created an attachment (id=15702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15702action=view) [edit] Minimal testcase for vtable issue I'm not sure whether this is related, but the effect is similar so I'm adding it to this same bug. Basically, we get an undefined reference to the vtable for a dllimport-ed struct with a single inner-defined virtual function. Uhh, if you declare a struct as dllimport, then you are declaring that it's vtable is defined in a dll. So why is this a bug? Of course if you allow compiler to actually inline the virtual function in your example, the vtable should not be needed. Anyway, thanks for reminding me of this bug. I'll backport 4.4 patch to 4.3.2 once branch reopens. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug driver/36417] On Vista, driver can't find collect2
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-03 03:17 --- Although config/mh-mingw has BOOT_CFLAGS += -D__USE_MINGW_ACCESS as a fix for PR33281, CFLAGS_FOR_TARGET for mingw32 also requires this define, else libiberty's make_relative_prefix won't work on Vista. make_relative_prefix is used by driver to determine and set environment variable GCC_EXEC_PREFIX. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 03:17:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36417
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #11 from dannysmith at users dot sourceforge dot net 2008-06-04 08:22 --- This fixes for me on Vista host. Can someone confirm? config/ChangeLog PR35916 * mh-mingw (CFLAGS): Add -D__USE_MINGW_ACCESS. Index: config/mh-mingw === --- config/mh-mingw (revision 136350) +++ config/mh-mingw (working copy) @@ -1,3 +1,4 @@ # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows # Vista (see PR33281 for details). BOOT_CFLAGS += -D__USE_MINGW_ACCESS +CFLAGS += -D__USE_MINGW_ACCESS -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|NEW |ASSIGNED Last reconfirmed|2008-06-03 04:31:48 |2008-06-04 08:22:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #13 from dannysmith at users dot sourceforge dot net 2008-06-05 06:23 --- Closing, as this is fixed on trunk. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #11 from dannysmith at users dot sourceforge dot net 2008-06-07 00:46 --- Fix backported to branch. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug target/40722] New: ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls.h
These defines in ia32intrin.h #define _lrotl(a,b) __rold((a), (b)) #define _lrotr(a,b) __rord((a), (b)) ... #define _rotl(a,b) __rold((a), (b)) #define _rotr(a,b) __rord((a), (b)) conflict with mingw32 stdlib.h which declares those names as functions _CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotl(unsigned int, int) __MINGW_ATTRIB_CONST; _CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotr(unsigned int, int) __MINGW_ATTRIB_CONST; _CRTIMP unsigned long __cdecl __MINGW_NOTHROW _lrotl(unsigned long, int) __MINGW_ATTRIB_CONST; _CRTIMP unsigned long __cdecl __MINGW_NOTHROW _lrotr(unsigned long, int) __MINGW_ATTRIB_CONST; This is caught by g++.dg/other/i386-[23456].C -- Summary: ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls.h Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
[Bug target/40905] GCC creates invalid executable with auto-imported DLL and __attribute__((cold))
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-07-30 08:00 --- (In reply to comment #2) Is it possible that it triggers the exception trying to write in text.unlikely which is READONLY? Exactly. This is a linker, not a compiler issue. If you are using a relatively recent binutils and mingw run time, the addition of the switch -Wl,--enable-runtime-pseudo-reloc-v2 should get around the READONLY problem. Otherwise, you could always just add __declspec (dllimport) to extern int foo[2]; and so retain portability with the rest of the PE-COFF world. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40905
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-07-31 04:18 --- (In reply to comment #0) I was not able to reproduce the bug on Linux, so I assume this is a Windows-specific. If an exception is generated inside shared library (DLL), then crosses the DLL-boundary and gets caught in some other module, the std::uncaught_exception will always return wrong (inverted) value from now on. Here's a small test case. You need to link against a shared libgcc and a shared libstdc++ for this to work. Shared libgcc is part of standard build now for mingw Shared libstdc++ is close. http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01042.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-08-02 08:57 --- (In reply to comment #3) I'm linking using g++ driver, so shared libgcc is enabled by default in 4.4.0. I've just tried to enabled shared libstdc++ as described in the Release Notes to the MinGW GCC 4.4.0 release, which made no difference. More over, I modified the test case the following way: I got rid of std::cout in favor of printf(), added -nodefaultlibs option to the linker and specified all the required libraries manually. Now libstdc++ is not linked at all (neither static nor dynamic), the bug is still here. I cannot comment on the build of libsdc++.dll in the mingw 4.4.0 release since I have not looked at that source. However, your revised testcase -- linking against a static libsupc++ -- would be expected to fail. We can have only one instance of the eh_globals structure defined in libsupc++/eh_globals.cc. This is accomplished by linking both the .exe and the .dll against a shared libstdc++. Applying Dave Korn's patch mentioned in Comment #2, and linking against libstdc++.dll, I get this with your original testcaase: Expecting 'true', got 'true' Expecting 'false', got 'false' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-08-05 04:55 --- (In reply to comment #6) (In reply to comment #5) Applying Dave Korn's patch mentioned in Comment #2, and linking against libstdc++.dll, I get this with your original testcaase: Expecting 'true', got 'true' Expecting 'false', got 'false' Where this patch is supposed to be applied to? trunk? Yes, it against trunk. I have looked through the patches you are referring to and through the source in repository. As far as I can see, libsupc++ is still static only, and eh_globals.cc is a part of libsupc++, not libstdc++. libsupc++ is a convenience lib that is included in libstdc++ The fact that test-case works correctly for you could be just a coincidence. The more reliable way to check for the problem would be to compare the value returned by the __cxa_get_globals() when being from the main executable and from the dll respectively. I'll prepare the new test case. The new test case succeeds when I link against a shared libstdc++. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40333] g++ does not align static variables properly
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-08-24 06:15 --- (In reply to comment #2) (In reply to comment #0) The following SSE2 code crashes because the non-static global variable breaks the alignment of the static data section. Is this fixed if you use 4.5.0? This is fixed with 4.5.0 and a recent binutils (Nick Clifton's patch to GAS was commuitted on 2008-09-03) Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40333
[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library
--- Comment #30 from dannysmith at users dot sourceforge dot net 2009-09-07 04:01 --- (In reply to comment #24) Subject: Re: [4.5 Regression] crashed compile Qt4 gui library On Sun, 6 Sep 2009, t7 at gmail dot com wrote: --- Comment #22 from t7 at gmail dot com 2009-09-06 22:20 --- (In reply to comment #16) Try building without the patch but with unlimited stack (ulimit -s unlimited) and see if the same error appears. You mean cross compile the native compiler from linux by setting the shell with command ulimit -s unlimited ? Or you want me to build the cross compiler and native compiler then try and build qt4? Just the same way as you reported the bug (I understand that this was a native compiler issue?). There surely must be a way to increase the maximum stack size with windows? To increase the stack size on windows, add -Wl,--stack=0x2000 (for eg 32 Mb stack). This hard codes the exe's stack size into the program header. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41254
[Bug c++/41512] dllexport broken on cygwin
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-10-03 21:47 --- (In reply to comment #0) These new FAILs have been appearing on trunk since some time between 20090820 and 20090903: FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D12vfEv FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D22vfEv FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK3MI12vfEv FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZTV2D1,data FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZN2D2C2ERKS_ FAIL: g++.dg/ext/dllexport1.C scan-assembler -export:_ZN3Bar10inline_barEi (Refs: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02276.html http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00356.html ) They seem to represent serious breakage of dllexport with cygwin as the latest testrun with my libstdc-as-dll patch is showing even more fails on top of these, but didn't fail before they appeared, and a quick investigation shows that the executables generated during the testsuite fail to import anything from the libstdc DLL! This could be either a target or a C++ problem since they both co-operate to manage the dllexport attribute. I couldn't find any changes in that area of the backend in the relevant date range, so I've marked it C++ for now. I'll attach preprocessed source for the testcase shortly. The problem appears to be that DECL_CONTEXT is no longer set for class members with link-once semantixcs (inline methods, vtables). Is that intended? It breaks dllexport of these symbols when they inherit the attribute of their of their containing type. The breakage can be fixed in target backend i386/winnt-cxx.c i386_pe_adjust_class_at_definition, by propagating the dllexport attribute there, rather than relying on DECL_CONTEXT later. I am testing that patch now. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug c++/41512] dllexport broken on cygwin
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-03 21:49:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug target/41512] dllexport broken on cygwin
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|NEW |ASSIGNED Component|c++ |target Last reconfirmed|2009-10-03 21:49:33 |2009-10-07 02:41:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug target/41512] dllexport broken on cygwin
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-10-07 03:06 --- Fixed at revision 152511. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #11 from dannysmith at users dot sourceforge dot net 2008-06-14 10:01 --- (In reply to comment #6) Note that a native build should be done to verify that my patch increases the stack limit enough to fix this bug, before marking it fixed. With this patch (8 mb stack reserve), native mingw32 jc1.exe (built with -O2) is able to compile all libgcj objects on trunk and 4_3-branch. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug bootstrap/36541] Make failed with error about system headers
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-06-15 05:31 --- (In reply to comment #0) make[3]: Leaving directory `/f/_Builds/gcc-4.3.1-build/gcc' It appears that you are building on drive F:. I'd guess that /mingw/include (== F:\mingw\include to the OS) does not exist. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36541
[Bug target/36603] Use \r\n for generated *.s files on Windows
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-23 02:54 --- Using \r\n will cause problems with pch files. This is why I made this change 2004-06-05 Danny Smith [EMAIL PROTECTED] * toplev.c (init_asm_output): Add explicit 'b' to mode when opening asm_out_file. This is the first complaint I've heard since that patch. Don't use Notepad for anything. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-23 02:54:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36603
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #12 from dannysmith at users dot sourceforge dot net 2008-06-28 07:53 --- *** Bug 36654 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug c++/36654] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-28 07:53 --- This is duplicate of 35921 and is fixed on 4.3.2 and trunk. *** This bug has been marked as a duplicate of 35921 *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
[Bug target/36834] New: structure return ABI for windows targets differs from nbative MSVC
Like i386-netware, the native MS Windows compiler assumes that the CALLER pops the stack for the implicit arguments pointing to aggregate return value. This differs from the default i386 ABI which assumes the CALLEE pops the stack. This is documented at http://www.angelcode.com/dev/callconv/callconv.html in the section on __cdecl calling convention. The bug was reported to mingw users list by Magnus Christensson at: http://www.nabble.com/Problem-returning-C-struct-from-MinGW-to-MSVC-td18444899.html This report contains a testcase demostrating the problem. Danny -- Summary: structure return ABI for windows targets differs from nbative MSVC Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug target/36834] structure return ABI for windows targets differs from nbative MSVC
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-07-15 09:29 --- Testing a patch to add a new switch for windows targets. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.2.0 4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-07-15 09:29:57 date|| Summary|structure return ABI for|structure return ABI for |windows targets differs from|windows targets differs from |nbative MSVC|nbative MSVC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-07-17 08:16 --- Patch submitted http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01250.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug libfortran/36857] Non-English locale breaks gfortran float formatting (printf is broken)
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-07-20 09:58 --- (In reply to comment #3) This is untested, but you get the idea. + setlocale(LC_ALL, POSIX); mingw's setlocale doesn't believe in POSIX ; it does however go to the ISO C89 church, and has setlocale(LC_ALL, C); in its liturgy. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36857
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-08-01 04:34 --- This kind of path '--prefix=/c/_GccBuilds/gcc-4.3.1-install/mingw-32-i686' may be understood by your shell, but won't be found by the xgcc driver or cc1.exe which are native windows apps. Search the mingw site for a build script that will work with the msys shell. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-15 02:57 --- I guess the solution is to make libstdc++ use _vsnwprintf instead of vswprintf on *-mingw32. I think that is the most expedient solution. Would an inline redirection of vswprintf to _vsnwprintf in config/os/mingw32/os_define.h (later, if it gets fixed in mingw runtime that could be made conditional on mingw version) work? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|NEW |ASSIGNED Last reconfirmed|2008-09-16 07:20:01 |2008-09-22 03:04:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-09-22 03:09 --- Fixed at revision 140541. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-09-22 03:23 --- I have run into what I believe is the same bug in build of of cc1plus.exe, with miscompilation of cp/pt.c When exercising cp/pt.c:process_partial_specialization (eg, when compiling libstdc++'s mt_allocator.cc) I get a segfault in cygwin.asm (used in w32 implementation of __builtin_alloca) Adding -fno-tree-ch to CFLAGS for pt.c fixes build of libstdc++ and testsuite results I will try to reduce a testcase when time permits. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-22 03:23:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #13 from dannysmith at users dot sourceforge dot net 2010-04-04 08:20 --- (In reply to comment #11) (In reply to comment #10) And while the compilation time change alone How did you configure 4.5? Did you use --enable-checking=release ? If not then the compile time numbers are not comparable at all. snip gcc version 4.5.0 20100311 (experimental) (GCC) This will cause defau;t checks for experimental DEV-PHASE to be enabled. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #6 from dannysmith at users dot sourceforge dot net 2010-04-15 07:54 --- (In reply to comment #1) FIONREAD is defined by winsock header How come your build of basic_file_stdio includes winsock api headers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #7 from dannysmith at users dot sourceforge dot net 2010-04-26 08:19 --- This is fixed in 4.5.0 release. http://gcc.gnu.org/viewcvs?view=revisionrevision=148199 Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Known to work|4.2.1 |4.2.1 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #15 from dannysmith at users dot sourceforge dot net 2010-04-30 03:02 --- (In reply to comment #13) Kai, what about the GetTempPath? Cf. the rough draft in attachment 20460 [edit] ? Compare choose_tmpdir() in libiberty/make_temp_file.c Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #17 from dannysmith at users dot sourceforge dot net
2010-05-18 22:43 ---
(In reply to comment #14)
Index: gcc/gcc/varasm.c
===
--- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
+++ gcc/gcc/varasm.c2010-05-18 17:10:11.385445300 +0200
@@ -403,6 +403,8 @@ emutls_decl (tree decl)
int foo() { return i; }
__thread int i = 1;
in which I goes from external to locally defined and initialized. */
+ DECL_DLLIMPORT_P (to) = DECL_DLLIMPORT_P (decl);
+ DECL_ATTRIBUTES (to) = targetm.merge_decl_attributes (decl, to);
TREE_STATIC (to) = TREE_STATIC (decl);
TREE_USED (to) = TREE_USED (decl);
I like this approach better too. It would be even cleaner (here and elswhere)
if we had a decl_with_vis.dllexport_flag and DECL_DLLEXPORT_P. 14 spare bits
left in decl_with_vis. Are they too precious??
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
