[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
[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 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 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 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 target/42213] GCC chkstk clash with Microsoft version
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-11-29 17:36 --- see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c9 and discussion of http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html I think that patch should go into 4.5 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42213
[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 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 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++/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 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++/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 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 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 libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-28 08:26 --- (In reply to comment #4) Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it does not know those functions should be enabled. mingw does not yet provide ANSI (c99) compliant swprintf or vswprintf implementations. The functions it does provide, _swprintf and _vswprintf, are pre-c99 MSVCRT implementations. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-13 08:12 --- (In reply to comment #5) Also, I don't think this is necessarily an either-or situation; we could add my patch and have the typeinfo exported from the DLL, and also add yours so that clients could link a comdat copy (which would override the import stub) until we have a better solution for importing from the DLL. Yes. I was just thinking out loud. I have no objection to your patch. Perhaps MULTIPLE_SYMBOL_SPACES should be defined in terms of an -mmultiple-symbol-spaces target option , since if we depend on auto-import than we should treat dll imports thae same as static lib imports. Also, how come emitting the typeinfo .linkonce as we currently do isn't the same as COMDAT for these purposes? I'm not sure I understand your question. In earlier versions of G++, both vtables and typeinfo were always emitted with linkonce semantics, because of the MULTIPLE_SYMBOL_SPACES define. Regards Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-05-10
05:01 ---
(In reply to comment #3)
Created an attachment (id=17841)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841action=view) [edit]
inherit dllexport from class to typeinfo
Now testing a solution based on the approach of adding the dllexport attribute
to the class' typeinfo object when the class is passed to
i386_pe_adjust_class_at_definition.
Hello Dave,
Rather than use DLL linkage (and so force client to resort to auto-import
magic)
why not just always emit the RTTI with one-only comdat linkage.
* decl2.c (import_export_decl): Always emit RTTI with comdat linkage
rather than import if MULTIPLE_SYMBOL_SPACES.
Index: decl2.c
===
--- decl2.c (revision 147015)
+++ decl2.c (working copy)
@@ -2351,15 +2351,21 @@
{
class_type = type;
import_export_class (type);
- if (CLASSTYPE_INTERFACE_KNOWN (type)
- TYPE_POLYMORPHIC_P (type)
- CLASSTYPE_INTERFACE_ONLY (type)
- /* If -fno-rtti was specified, then we cannot be sure
-that RTTI information will be emitted with the
-virtual table of the class, so we must emit it
-wherever it is used. */
- flag_rtti)
- import_p = true;
+ /* Do not import typeinfo if the class might be in a DLL.
+Dllimports do not have a constant address at compile time,
+causing problems for static initialization of tables with RTTI
+fields. Set to comdat instead. */
+ if (MULTIPLE_SYMBOL_SPACES)
+ comdat_p = true;
+ else if (CLASSTYPE_INTERFACE_KNOWN (type)
+ TYPE_POLYMORPHIC_P (type)
+ CLASSTYPE_INTERFACE_ONLY (type)
+ /* If -fno-rtti was specified, then we cannot be sure
+ that RTTI information will be emitted with the
+ virtual table of the class, so we must emit it
+ wherever it is used. */
+ flag_rtti)
+import_p = true;
else
{
if (CLASSTYPE_INTERFACE_KNOWN (type)
--
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 |2009-05-10 05:01:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #12 from dannysmith at users dot sourceforge dot net 2009-05-01 19:48 --- (In reply to comment #11) (In reply to comment #9, comment #10) I did not build MinGW 4.3.0. I got it from the official MinGW site (gcc-4.3.0-20080502-mingw32-alpha). I have also found that on www.equation.com there are even newer versions (binaries), like 4.3.3 with OpenMP 2.5, 4.4.0 with OpenMP 3.0 and MinGW 4.5 compilation snapshot. They seem to work fine with OpenMP. Its a shame that www.equation.com doesn't tell us how to obtain their source code for the gcc, gdb ands make binaries. They aren't present on the official MinGW site. Why? No one has had put them there. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug target/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-04-30 20:57 --- (In reply to comment #6) (In reply to comment #4) Your libpthreads is doing something wrong. Re. comment 5 The command was actually gcc -fopemnp test.c -lgomp -o test.exe That command works for me with gcc 4.3.4, 4.4.0 and trunk In 4.4.0 and trunk, test.exe links against LIBGOMP-1.DLL which in turn resolves the pthread imports from PTHREADGCE2.DLL, which is distributed by the pthreads-win32 project http://sources.redhat.com/pthreads-win32/ My version of 4.3.4 has local mods. I'm not sure if the shared libgomp build was standard then. How did you build gcc-4.3.0? You need to add --enable-libgomp to configure and ensure that libpthread.a (note spelling) can be found. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug target/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #10 from dannysmith at users dot sourceforge dot net
2009-04-30 21:07 ---
(In reply to comment #9)
(In reply to comment #6)
(In reply to comment #4)
Your libpthreads is doing something wrong.
Re. comment 5
The command was actually
gcc -fopemnp test.c -lgomp -o test.exe
That command works for me with gcc 4.3.4, 4.4.0 and trunk
In 4.4.0 and trunk, test.exe links against LIBGOMP-1.DLL which in turn
resolves
the pthread imports from PTHREADGCE2.DLL, which is distributed by the
pthreads-win32 project
http://sources.redhat.com/pthreads-win32/
My version of 4.3.4 has local mods. I'm not sure if the shared libgomp build
was standard then.
No it wasn't. And so the problem is that libgomp.spec says:
# This spec file is read by gcc when linking. It is used to specify the
# standard libraries we need in order to link with -fopenmp.
*link_gomp: -lgomp %{static: -lpthread }
You have not specified '-static', so you must provide the '-lpthread' (again
note spelling) yourself.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|target |libgomp Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug target/39947] Shared libgcc getting clobbered for multilib builds
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29 07:29 --- The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll, libssp-x.dll, etc) that are built as part of 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=39947
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #53 from dannysmith at users dot sourceforge dot net 2009-04-16 02:59 --- This thread is alos relevant. http://gcc.gnu.org/ml/gcc/2009-04/msg00462.html Adding Dave Korn to cc: -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug bootstrap/39660] Mingw Bootstrap stops with ..host-mingw32.c:140: error: ISO C90 forbids mixed..
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-08 08:12 --- Fixed. -- 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=39660
[Bug bootstrap/39660] Mingw Bootstrap stops with ..host-mingw32.c:140: error: ISO C90 forbids mixed..
-- 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 |2009-04-07 03:39:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39660
[Bug target/39530] [4.3/4.4/4.5 regression] runtime_error text not shown
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-04-02 04:20 --- (In reply to comment #5) (In reply to comment #3) terminate called after throwing an instance of 'std::runtime_error' what(): ouch Yes, this is the part that's missing for me. With gcc-4.4.0, built from FSF sources, I get This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. terminate called after throwing an instance of 'std::runtime_error' what(): ouch With gcc-4.3.3, built from FSF sources, I get This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. terminate called after throwing an instance of 'std::runtime_error' what(): ouch I have not tested 4.3.3-dw2-tdm-1 which you report as the faulty build. Contrary to Kai Tietz assumption, it has nothing to do with mingw.org. Neither does it have anything to do with FSF gcc. Please report your bug to tdm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39530
[Bug target/36654] [4.2 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #13 from dannysmith at users dot sourceforge dot net 2009-03-28 07:24 --- (In reply to comment #12) Both the dg-error clauses now fail; previously (4.3.2), only the second one failed. Reverting the patch causes the first dg-error (line 21) to pass again by restoring the error message /gnu/gcc/release/gcc4-4.3.3-1/src/gcc-4.3.3/gcc/testsuite/g++.dg/ext/dllimport7. C:21: error: definition of static data member 'Bar::three' of dllimport'd class I'm not sure why that should be a problem in the first place, so I don't know if the underlying issue is now fixed and not an error any more. Anybody? IMO, the hard error should occur. The native MS compiler emits a similar error message. Allowing a static data member to be defined in more than one place is a bad thing. It most be defined in the dll if the class is defined there and, in the situation the testcase is testing will be defined again in the exe or dll that uses the dll. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
--- Comment #11 from dannysmith at users dot sourceforge dot net 2009-03-23 22:10 --- (In reply to comment #10) Note that C++ objects need not be larger than 8 bytes to qualify for returning on the stack (and thus subject to this cleanup problem). Any class with a copy constructor, for example, seems to be affected. Thanks. I understand your concern now. Do you think that a function __attibute__((ms-aggregate-return)) would be useful to specify individual problematic functions. I expect that this would be equivalent to (__attribute__((target(ms-aggregate-return))) which should work now, but I haven't tested, Will do so soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-21 01:03 --- (In reply to comment #7) The proposed patch works for plain C code, but also affects C++. Since libstdc++ contains code that returns aggregates or calls code that does, An example, please. The patch only affects functions that return large ( 8 bytes) aggregates by value. Danny -mms-aggregate-return will make the generated code incompatible with the C++ library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug driver/39356] assembler isn't called
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-16 02:13 --- (In reply to comment #7) The following patch solves this problem and prevents the name collision for 32 and 64 bits win32 systems. ChangeLog * config/i386/i386.md (allocate_stack_worker_32): Use ___gnu_chkstk. (allocate_stack_worker_64): Likewise. * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca. (___chkstk): Renamed to ___gnu_chkstk. No. This breaks backward compatibility. Static libraries and objects built with current and older versions of gcc will not be able to resolve references to __alloca or ___chkstk.Why not add labels with the new names as aliases rather than replace. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug driver/39424] MinGW doesn't seem to work if main disk is not C:\
--- Comment #1 from dannysmith at users dot sourceforge dot net 2009-03-11 02:41 --- This is fixed in 4.3.x by 2006-11-20 Carlos O'Donell car...@codesourcery.com Mark Mitchell m...@codesourcery.com * cppdefault.c: Define cpp_PREFIX, cpp_PREFIX_len, and gcc_exec_prefix. (cpp_relocated): New function. * cppdefault.h: Declare cpp_PREFIX, cpp_PREFIX_len, gcc_exec_prefix and cpp_relocated. * Makefile.in (PREPROCESSOR_DEFINES): Add -DPREFIX option. * c-incpath.c (add_standard_paths): Call cpp_relocated. If relocated, replace configured prefix with gcc_exec_prefix. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC target triplet||4.3.3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39424
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #13 from dannysmith at users dot sourceforge dot net 2009-03-09 07:46 --- (In reply to comment #12) Was this broken in 4.3 compilers? Is it a 4.4 regression? This is not a new bug in the compiler (the same multiple definition will occur with 3.4.5) , but an old 'feature' of the the PE-COFF linker _InterlockedIncrement is defined as an ordinary C library function in lib64_libmingwex_a-wininterlocked.o In thread.cpp, it is defined and emitted using linkonce semantics (it is put into its own .text$_InterlockedIncrement link_once sections, which is how PE-COFF implements vague linkage. The linker grabs the one and only .text$_InterlockedIncrement section in thread.o and then while resolving another symbol it needs from lib64_libmingwex_a-wininterlocked.o finds an ordinary (not .linkonce) definition InterlockedIncrement Hence the multiple definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-09 07:52 --- From gcc.info: *Warning:* the `-fpack-struct' switch causes GCC to generate code that is not binary compatible with code generated without that switch. Additionally, it makes the code suboptimal. Use it to conform to a non-default application binary interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug target/39291] _Unwind_Backtrace fails.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-28 02:38 --- Created an attachment (id=17376) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17376action=view) testcase executable built on mingw32 testcase executable built on mingw32 attached -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39291
[Bug target/39291] _Unwind_Backtrace fails.
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-02-25 02:28 --- I get this with your testcase on mingw32, DW@ build: GNU C (GCC) version 4.4.0 20090221 (experimental) (mingw32) gcc -fexceptions -g u.c foo:enter bar:enter zoo:enter boom! signalHandler:enter lookupSymbol: 00401407 lookupSymbol: 00401232 signalHandler:longjmp zoo:exit bar:exit foo:exit alive! Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39291
[Bug c++/29974] Segmentation fault on simple input file. Omission of #include string prevents error. WinXP x64, cygwin
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-03 02:02 --- /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix - D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -i dirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32ap i testFail.h -quiet -dumpbase testFail.h -mtune=pentiumpro -auxbase testFail -version -o /cyg drive/c/DOCUME~1/JAMESF~1/LOCALS~1/Temp/ccGNtP5T.s --output-pch=testFail.h.gch PCH support for cywgin was not available until 4.0 series. Your testcase compiles correctly on cygwin with recent (=4.1) gcc. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29974
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #7 from dannysmith at users dot sourceforge dot net 2009-01-29 01:57 --- (In reply to comment #6) This bug is fixed and should be closed now. A new PR, bug 37660, has been created for the separate issue in comment 4. Closing -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug other/38920] dw2 exceptions don't work.
--- Comment #7 from dannysmith at users dot sourceforge dot net 2009-01-26 03:30 --- AFAICT DW2 unwind has never worked on x86_64-mingw32, which is why Kai made sjlj the default EH model for that target. http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00273.html -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug testsuite/38949] Link failures in new stackalign tests
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-01-23 18:53 --- There is an alternative patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00044.html which i had forgotten about. It has been tested on i686-pc-mingw32 and i686-pc-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38949
[Bug other/38920] throwing ex. across dlls doesn't work.
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-01-20 06:07 --- libstdc++ also needs to be built and linked in as dll. Search mingw archive lists for other examples and approaches. 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 |2009-01-20 06:07:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-19 04:22 --- (In reply to comment #7) Created an attachment (id=17132) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132action=view) [edit] Move _ctors* and _chkstk* to import lib Danny, this is the approach that I think I'd like to take for Cygwin; what do you think about doing it this way? On mingw we would also need to copy gthr-win32.o and __main.o into implib as well. It just seems simpler to follow the logic in init_gcc_spec with the modification forced by the requirement for no-undefined-symbols when building a dll. Note that with your patch, init_gcc_spec will still link in the static libgcc when building an .exe (ie the !shared case) Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-01-16 07:14 --- (In reply to comment #4) I've just run into this problem too. In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and chkstk.o and placed them whole into the import lib. I'm not sure why he didn't do this in the committed version, but it has the effect that you have to link against the static libgcc as well as the shared one in order to let it fill out any missing references. I'm not sure I'm entirely comfortable with that, although I can't think of any obvious problem, but it seems wrong to link against such a duplicated body of code to me, and I think I'd prefer the import lib solution for cygwin's compiler. If you look at the (static) libgcc.a, when shared libs are enabled, it contains only symbols that are not exported from the shared dll. Only the 'API-stable' symbols are exported. That is a good thing. So the libgcc.a code does not duplicate any code in libgcc_s.[a|dll]. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-16 07:14:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-01-15
02:39 ---
I believe that this failure reflects the fact that PE_COFF dll's do not allow
undefined symbols. Because of that, the rule to decide shared vs static libgcc
in gcc.c init_gcc_spec, namely the case for building a shared lib:
%{shared:, shared_name, }
is not quite right. It should be (I think)
%{shared:, shared_name, , static_name }
However, since a shared libgcc is a new thing on cygwin and mingw, it may be
better for this release to actually require an explicit -shared-libgcc to get
the shared lib. That is what mingw32 does, by defining its own
REAL_LIBGCC_SPEC.
Does this patch fix the problem for you?
Index: config/i386/cygwin.h
===
--- config/i386/cygwin.h(revision 143259)
+++ config/i386/cygwin.h(working copy)
@@ -49,9 +49,17 @@
GCC without making a new CYGWIN.DLL, so we leave it. Profiling is handled
by calling the init function from main. */
-#undef LIBGCC_SPEC
-#define LIBGCC_SPEC \
- %{mno-cygwin: %{mthreads:-lmingwthrd} -lmingw32} -lgcc \
+#
+#ifdef ENABLE_SHARED_LIBGCC
+#define SHARED_LIBGCC_SPEC %{shared-libgcc:-lgcc_s}
%{!shared-libgcc:-lgcc_eh}
+#else
+#define SHARED_LIBGCC_SPEC /*empty*/
+#endif
+#undef REAL_LIBGCC_SPEC
+#define REAL_LIBGCC_SPEC \
+ %{mno-cygwin: %{mthreads:-lmingwthrd} -lmingw32} \
+ SHARED_LIBGCC_SPEC \
+ -lgcc \
%{mno-cygwin:-lmoldname -lmingwex -lmsvcrt}
/* We have to dynamic link to get to the system DLLs. All of libc, libm and
--
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=37660
[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-13 07:43 --- Fixed on trunk. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-01-12 02:07 --- (In reply to comment #8) still unfixed? Please provide a compilable self-contained testcase. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-01-08 08:41 --- Created an attachment (id=17052) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17052action=view) Replace execvp with pex_one in process_command Patch uses pex_one as per Ian Taylor suggestion , but the error reporting may need expansion. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug target/36654] [4.2/4.3 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #11 from dannysmith at users dot sourceforge dot net 2009-01-07 07:47 --- Fixedd on 4.3 branch -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|c++ |target Known to work|3.4.5 4.2.1 |3.4.5 4.2.1 4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
[Bug target/38662] __fastcall confuses a function's throw() specification
--- Comment #1 from dannysmith at users dot sourceforge dot net 2009-01-06
03:49 ---
Confirmed on SVN head.
This also avoids the bug.
//
class E
{
};
class Test
{
public:
__fastcall bool ernie(bool b) throw(E)
{
}
__fastcall bool bert(bool b);
};
// Make sure definition also has the __attribute fastcall
__fastcall bool Test::bert(bool b)
{
}
//
--
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-01-06 03:49:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38662
[Bug c++/36654] [4.2/4.3 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-02
04:19 ---
Hello John,
This patch:
Index: gcc/config/i386/winnt-cxx.c
===
--- gcc/config/i386/winnt-cxx.c (revision 142383)
+++ gcc/config/i386/winnt-cxx.c (working copy)
@@ -65,7 +65,7 @@
ignore the class attribute. */
else if (TREE_CODE (decl) == VAR_DECL
TREE_STATIC (decl) TREE_PUBLIC (decl)
- !DECL_EXTERNAL (decl))
+ DECL_NOT_REALLY_EXTERN (decl))
{
if (!DECL_VIRTUAL_P (decl))
error (definition of static data member %q+D of
fixes your testcase and causes no regressions in g++ testsuite. I have only
tested on narrow range of dll builds, to check that the patch does not break
anything. I think it may cause spurious errors with import of static data
members, but that can be fixed. Could you please test with your projects.
Thanks
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
[Bug bootstrap/38580] Bootstrap broken on mingw32
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-12-19 23:01 --- Patch for this was submitted 4 months ago: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01143.html Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-19 23:01:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug target/38294] Enable multilib support for mingw
--- Comment #9 from dannysmith at users dot sourceforge dot net 2008-12-14 05:54 --- (In reply to comment #5) Reasoned by the fact, that this patch will solve our build failures for w64, it is really more to be treated as regression. NightStrike, when all tests you are doing at the moment are passing, I'll sent it tomorrow to gcc-patches. Danny is this ok for you? I would prefer that this be left until 4.5. I don't understand how failing to add a new feature is now a regression. (In reply to comment #6) Created an attachment (id=16906) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906action=view) [edit] Third attempt There were a few lines in t-mingw32 that were commented out and shouldn't have been there. Fixed in this patch. Please also remove this unnecessary change in mingw32.h +#if TARGET_64BIT_DEFAULT #define STANDARD_INCLUDE_DIR /mingw/include +#else +#define STANDARD_INCLUDE_DIR /mingw/include #endif Nightstrike, have you completed FSF copyright assignment formality Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #13 from dannysmith at users dot sourceforge dot net 2008-12-04 07:16 --- Fixed in 4.3.3 -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.4 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #11 from dannysmith at users dot sourceforge dot net 2008-12-02 08:05 --- I have committed a patch to 4.4.0 to fix bug in compilation of desktop.cpp -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #33 from dannysmith at users dot sourceforge dot net 2008-11-24 06:41 --- (In reply to comment #32) I've been told that this is related to the test case I just attached Your testcase is more closely related to PR 38054. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-21 05:51 --- (In reply to comment #4) Creating library file: .libs/libssp.dll.a .libs/ssp.o: In function `fail': /home/vmk/gccdev/gcctr11/gcc/libssp/ssp.c:109: undefined reference to `___chkstk' .libs/gets-chk.o: In function `__gets_chk': /home/vmk/gccdev/gcctr11/gcc/libssp/gets-chk.c:66: undefined reference to `___chkstk' This is a different bug. Cygwin uses the rules in gcc.c:init_gcc_specs to Add appropriate libgcc specs to OBSTACK, taking into account various permutations of -shared-libgcc, -shared, and such. These do not quite work for Windows targets because dll's do not allow any reference to be undefined whey they are built. Thus, the static libgcc.a must generally be included to resolve, eg __chkstk.mingw works around this by defining it's own REAL_LIBGCC_SPEC in mingw32.h that does this. Perhaps cygwin should do the same. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dave dot korn at artimi dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-18 05:55 --- (In reply to comment #4) Created an attachment (id=16713) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713action=view) [edit] gcc44-pr38130.patch I've talked about this with Honza on IRC: honza I would just use 0 constraint. At least in old times with regmove, regmove was able to discover that it should use same pseudo for input and output. If you use pair of =a and a only reload sees this fact honza so patch is OK with that change. This is an updated patch which uses 0 instead of a constraint for operand 1. So, can anyone please test it? Thanks. This patch bootstraps on mingw32 (c,c++,gfortran) successfully, libstcd++ now compiles and the two testcases reported as failing now pass. A full regtest is in progress and so far looks good. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-18 06:26 --- Hello Murali, Does the patch for PR 38130 fix the build of libstdc++ on cygwin? http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713action=view 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=37915
[Bug target/38130] New: [4.4.0 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
Execution testcases c-torture/execute/920929-1.c and c-torture/execute/built-in-setjmp.c began failing on mingw32 in late August, coincident with merge of IRA into trunk. In both cases, the execution tests pass if -fno-ira is added to command line. The problem appears to be in the call of the target stack-probing code (__chkstk) in cygwin.asm from allocate_stack_worker instruction. __chkstk has unusual calling convention, with the input argument as well as the output passed in eax. From i386.md: (define_insn allocate_stack_worker_32 [(set (match_operand:SI 0 register_operand +a) (unspec_volatile:SI [(match_dup 0)] UNSPECV_STACK_PROBE)) (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 0))) (clobber (reg:CC FLAGS_REG))] !TARGET_64BIT TARGET_STACK_PROBE call\t___chkstk [(set_attr type multi) (set_attr length 5)]) The relevant part of the output of gcc -S -O -funroll-all-loops 920929-1.c -o 920929-1-IRA.s: f: pushl %ebp movl%esp, %ebp pushl %ebx subl$4, %esp movl8(%ebp), %edx call___chkstk leal15(%esp), %ecx andl$-16, %ecx testl %edx, %edx ... __chkstk allocates only 1 byte and the code segfault on the first attempt to assign a double to the allocated array. The output, with -fno-ira gcc -S -O -funroll-all-loops -fno-ira 920929-1.c -o 920929-1-NOIRA.s: _f: pushl %ebp movl%esp, %ebp pushl %ebx subl$4, %esp movl8(%ebp), %ebx leal30(,%ebx,8), %eax andl$-16, %eax call___chkstk leal15(%esp), %eax movl%eax, %edx andl$-16, %edx testl %ebx, %ebx __chkstk allocates 816 bytes A comparison of built-in-setjmp.c with amd without -fno-ira switch also shows incorrect input to __chkstk Probably related to these failure is miscompilation of the C++ compiler code cp/pt.c, which segfaults following call to alloca in process_partial_specialization when building libstdc++. If cp/pt.c is compiled with -fno-ira, libstdc++ builds successfully. Danny -- Summary: [4.4.0 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32 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=38130
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-11 06:27 --- (In reply to comment #3) Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html That patch also fixes the FAIL of testsuite\g++.old-deja\g++.dg\otherg++ pr35504.C . Currently it fails on mingw32 and cygwin with: Warning: resolving non-virtual thunk to c3::method5()@4 by linking to non-virtual thunk to c3::method5() Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups c:\tmp/ccisCRqc.o:pr35504.C:(.rdata$_ZTV2c3[vtable for c3]+0x44): undefined reference to [EMAIL PROTECTED]@4' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-09 08:20 --- This a target bug (stdcall symbol name decorati0on on windows targets) -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-09 08:24 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug middle-end/38054] Assertion failed in change_decl_assembler_name()
-- 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-11-09 00:41:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-04 02:21 --- Fixed by Mikael's patch -- 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=37989
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
-- 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-11-03 06:09:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-03 07:45 --- Created an attachment (id=16614) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16614action=view) revised patch to quard with ENABLE_SHARED_LIBGCC Hi Mikael, I have modified your patch slightly and added a ChangeLog entry. It works for me with host=build=target=mingw32. Does attached it work for you. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #41 from dannysmith at users dot sourceforge dot net 2008-10-06 20:18 --- (In reply to comment #35) As I suspected. The PE/COFF file format does not provide for specifying the alignment of commons. Hmm, I wonder if gcc should complain if it finds aligned commons with COFF backends or if we should try to generate a GNU extension to the COFF format. Aligned commons are not part of the PE COFF spec and AFAICT neither MASM nor NASM provide a way to specify aligned commons. I am afraid that a GNU extension will cause object incompatibility, so it would it need to be a non-default option. We already have -fno-common __attribute__((no_common)) #pragma gcc optimize (no_common) G++ already puts commons in .bss Perhaps a new option -fno_large_common that applies -fcommon only to objects with align = 4 bytes? A warning would be useful in any case. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
--- Comment #10 from dannysmith at users dot sourceforge dot net 2008-10-02 08:47 --- Fixed on mingw32 at revision 140803. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #27 from dannysmith at users dot sourceforge dot net
2008-10-01 10:22 ---
(In reply to comment #13)
Created an attachment (id=16425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view) [edit]
Revised patch with correct section switching
That patch causes other problems
This test case:
/* t1.c */
int i[0];
int k;
void testi (void)
{
i[0] = 0;
}
void testk (void)
{
k = 0;
}
int main (void)
{
return 0;
}
now fails with
t1.c:(.text+0x5): undefined reference to `_i'
The assembler code is
.file t1.c
.text
.p2align 4,,15
.globl _testi
.def_testi; .scl2; .type 32; .endef
_testi:
pushl %ebp
movl%esp, %ebp
movl$0, _i
popl%ebp
ret
.p2align 4,,15
.globl _testk
.def_testk; .scl2; .type 32; .endef
_testk:
pushl %ebp
movl%esp, %ebp
movl$0, _k
popl%ebp
ret
.def___main;.scl2; .type 32; .endef
.p2align 4,,15
.globl _main
.def_main; .scl2; .type 32; .endef
_main:
pushl %ebp
movl%esp, %ebp
andl$-16, %esp
call___main
xorl%eax, %eax
movl%ebp, %esp
popl%ebp
ret
.bss
.balign 4
.comm _i, 0 size of i[0]
.balign 4
.comm _k, 4
I suspect we need to add this bit, or similar, back in
- rounded = size ? size : 1;
- rounded += (BIGGEST_ALIGNMENT / BITS_PER_UNIT) - 1;
- rounded = (rounded / (BIGGEST_ALIGNMENT / BITS_PER_UNIT)
-* (BIGGEST_ALIGNMENT / BITS_PER_UNIT));
and output rounded rather than size.
Testing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-10-02 00:20 --- In reply to comment #4) xgcc: error trying to exec '/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe': execv: Permission denied This may be related to: http://gcc.gnu.org/ml/gcc-bugs/2007-05/msg00228.html Windows filesystems have woefully poor timestamp resolution, so it is easy to get in race situation with modern CPUS. I find that it helps to disable explorer.exe in the Windows TaskManager while doing a bootstrap. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #26 from dannysmith at users dot sourceforge dot net 2008-10-01 01:33 --- (In reply to comment #14) Hi Guys, I am not able to reproduce the build problems that were reported with the first version of my patch, but then again I do not have a native cygwin build system or a system in which I can bootstrap mingw32. I think that Brian may well be right however in that the patch is behaving badly when it manually switches into the .bss section. I have uploaded a revised version of the patch which uses the correct gcc function to perform the section switch, so please can anyone who is interested give this new patch a run. This latter patch, applied to R139853 [*] (just before the big IRA merge) does not cause the build problems of the prior patch but does not solve the problem either. With this patch, using your _align.c test case which I uploaded in previous comment: gcc -DHAVE_ALIGNED_COMMON _align.c a.exe fails. The assembler code, specifically the .balign 32 directive applied to the _common object looks like it should do the right thing, but doesn't (: .file _align.c .bss .balign 1 .comm _a, 1 .balign 32 .comm _common, 64 .globl _b .section.bss,w _b: .space 1 .globl _bss .align 32 _bss: .space 64 .globl _c .data _c: .byte 1 .globl _data .align 32 _data: .long 1 .space 4 .long 2 .space 4 .long 3 .space 12 .long 4 .space 28 .text .globl _test .def_test; .scl2; .type 32; .endef _test: pushl %ebp movl%esp, %ebp subl$8, %esp movl8(%ebp), %eax addl$8, %eax andl$7, %eax testl %eax, %eax jne L2 movl8(%ebp), %eax addl$16, %eax andl$15, %eax testl %eax, %eax jne L2 movl8(%ebp), %eax addl$32, %eax andl$31, %eax testl %eax, %eax je L4 L2: call_abort L4: leave ret .def___main;.scl2; .type 32; .endef .globl _main .def_main; .scl2; .type 32; .endef _main: pushl %ebp movl%esp, %ebp andl$-16, %esp subl$16, %esp call___main movl$_common, (%esp) call_test movl$_bss, (%esp) call_test movl$_data, (%esp) call_test movl$0, (%esp) call_exit .def_abort; .scl2; .type 32; .endef .def_exit; .scl2; .type 32; .endef [*] Since the IRA merge, mingw32 has been broken, failing to compile libstdc++ and raising many (500 in gcc.dg) new testcase errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #19 from dannysmith at users dot sourceforge dot net 2008-09-29 18:43 --- Created an attachment (id=16427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16427action=view) Nick's aligned common testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-09-26 03:15 --- *** Bug 37652 has been marked as a duplicate of this bug. *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||v dot haisman at sh dot cvut ||dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug target/37652] Bogus redeclaration warning for `friend __declspec(dllimport) int foo ()'
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-26 03:15 --- This is duplicate of 34749 *** This bug has been marked as a duplicate of 34749 *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37652
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-24 03:12 --- This bug is linker related. It is fixed on 32-bit windows by this patch http://sourceware.org/ml/binutils-cvs/2007-10/msg2.html Have you tried with recent binutils and explict -Wl,--enable-auto-import switch? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[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 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 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 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 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 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/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/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 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/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 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 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/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 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 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 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 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
