[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-04-16
05:14 ---
The DECL_ASSEMBLER_NAMES of these stdcall virtaul methods do not get
decorated in time for cp/method.c:make_alias_for_thunk.
(cf this comment in varasm.c: find_decl_and_mark_needed:
/* We can't mark function nodes as used after cgraph global info
is finished. This wouldn't generally be necessary, but C++
virtual table thunks are introduced late in the game and
might seem like they need marking, although in fact they
don't. */
)
Somehow we need to ensure that these methods know what their final
assembler name is. This patch fixes your testcase. Could you test on your
wxwidgets case? I suspect that there are cleaner ways of doing this but
I don't know exactly where we can first safely modify these stdcall and
fastcall names.
Danny
ChangeLog
* target.h (asm_out.change_extern_name): New hook.
* target-def.h (TARGET_ASM_CHANGE_EXTERN_NAME): New define,
defaulting to hook_void_tree. Add to struct asm_out.
* config/i386/cygming.h (TARGET_ASM_CHANGE_EXTERN_NAME): Override
default with i386_pe_decorate_assembler_name.
* config/i386/winnt.c (i386_pe_decorate_assembler_name): New function,
extracted from i386_pe_encode_section_info.
(i386_pe_encode_section_info): Call i386_pe_decorate_assembler_name.
cp/ChangeLog
* method.c (use_thunk): Call asm_out.change_extern_name before making
alias for thunked-to function.
Index: target.h
===
--- target.h(revision 112968)
+++ target.h(working copy)
@@ -206,6 +206,11 @@
/* Output a DTP-relative reference to a TLS symbol. */
void (*output_dwarf_dtprel) (FILE *file, int size, rtx x);
+ /* This target hook allows the operating system to modify the extern
assembler name
+of a DECL. For example, windows targets use this to decorate stdcall and
fastcall functions
+with a a trailing '@n'. */
+void (*change_extern_name) (tree decl);
+
} asm_out;
/* Functions relating to instruction scheduling. */
Index: target-def.h
===
--- target-def.h(revision 112968)
+++ target-def.h(working copy)
@@ -221,6 +221,10 @@
#define TARGET_ASM_OUTPUT_DWARF_DTPREL NULL
#endif
+#ifndef TARGET_ASM_CHANGE_EXTERN_NAME
+#define TARGET_ASM_CHANGE_EXTERN_NAME hook_void_tree
+#endif
+
#define TARGET_ASM_ALIGNED_INT_OP \
{TARGET_ASM_ALIGNED_HI_OP, \
TARGET_ASM_ALIGNED_SI_OP, \
@@ -265,7 +269,8 @@
TARGET_ASM_EXTERNAL_LIBCALL,\
TARGET_ASM_MARK_DECL_PRESERVED,\
TARGET_ASM_OUTPUT_ANCHOR, \
- TARGET_ASM_OUTPUT_DWARF_DTPREL}
+ TARGET_ASM_OUTPUT_DWARF_DTPREL, \
+ TARGET_ASM_CHANGE_EXTERN_NAME}
/* Scheduler hooks. All of these default to null pointers, which
haifa-sched.c looks for and handles. */
Index: config/i386/cygming.h
===
--- config/i386/cygming.h (revision 112968)
+++ config/i386/cygming.h (working copy)
@@ -296,6 +298,7 @@
extern void i386_pe_file_end (void);
extern int i386_pe_dllexport_name_p (const char *);
extern int i386_pe_dllimport_name_p (const char *);
+extern void i386_pe_decorate_assembler_name (tree);
/* For Win32 ABI compatibility */
#undef DEFAULT_PCC_STRUCT_RETURN
@@ -374,6 +377,8 @@
#define TARGET_VALID_DLLIMPORT_ATTRIBUTE_P i386_pe_valid_dllimport_attribute_p
#define TARGET_CXX_ADJUST_CLASS_AT_DEFINITION
i386_pe_adjust_class_at_definition
+#define TARGET_ASM_CHANGE_EXTERN_NAME i386_pe_decorate_assembler_name
+
#undef TREE
#ifndef BUFSIZ
Index: config/i386/winnt.c
===
--- config/i386/winnt.c (revision 112968)
+++ config/i386/winnt.c (working copy)
@@ -335,33 +335,38 @@
}
void
-i386_pe_encode_section_info (tree decl, rtx rtl, int first)
+i386_pe_decorate_assembler_name (tree decl)
{
- default_encode_section_info (decl, rtl, first);
+ tree type_attributes = TYPE_ATTRIBUTES (TREE_TYPE (decl));
+ tree newid = NULL_TREE;
- if (first && TREE_CODE (decl) == FUNCTION_DECL)
+ if (lookup_attribute ("stdcall", type_attributes))
+newid = gen_stdcall_or_fastcall_suffix (decl, false);
+ else if (lookup_attribute ("fastcall", type_attributes))
+newid = gen_stdcall_or_fastcall_suffix (decl, true);
+ if (newid != NULL_TREE)
{
- tree type_attributes = TYPE_ATTRIBUTES (TREE_TYPE (decl));
- tree newid = NULL_TREE;
+ rtx rtlname = XEXP (DECL_RTL (decl),
[Bug c++/27650] internal compiler error while compiling Gecode
--- Comment #5 from dannysmith at users dot sourceforge dot net 2006-05-22
21:19 ---
This is a dllimport bug. Dllimports do not have constant address. Hence class
vtable cannot contain a method with dllimport attribute
I am working on a patch.
Here is reduced testcase:
// dllimport_virtual.C
struct base
{
virtual void key_method();
__attribute__((dllimport)) virtual ~base(); // Does not have a const address
};
// Definition of key_method forces emmission of vtable
void base::key_method() {};
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org |sourceforge dot net
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug c++/27650] internal compiler error while compiling Gecode
-- 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 |2006-05-22 21:22:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug target/27789] New: attribute handling fallout from DECL_INITIAL changes
This revision to gcc/cp 2006-05-24 Mark Mitchell <[EMAIL PROTECTED]> PR c++/20103 * decl.c (cp_make_fname_decl): Don't set DECL_INITIAL to error_mark_node to indicate an initialization is OK. (start_decl): Likewise. Adjust call to start_decl_1. (start_decl_1): Add initialized parameter. Simplify. * except.c (initialize_handler_parm): Adjust call to setart_decl_1. (expand_start_catch_block): Let cp_finish_decl initialize catch parameters. * cp-tree.h (start_decl_1): Adjust prototype. * pt.c (tsubst_expr): Don't set DECL_INITIAL to error_mark_node. (instantiate_decl): Let cp_finish_decl handle initialization. * semantics.c (finish_compound_literal): Create a temporary variable for the literal. * typeck.c (build_unary_op): Remove COMPOUND_LITERAL_P special cases. * decl2.c (finish_static_data_member_decl): Don't set DECL_INITIAL. (grokfield): Do not try to initialize functions. has resulted in 3 new testsuite failures: FAIL: g++.dg/ext/dllimport4.C (test for errors, line 6) FAIL: g++.dg/ext/selectany1.C (test for excess errors) FAIL: g++.dg/ext/selectany2.C (test for excess errors) The dllimport failure is because handle_dllimport_atribute in tree.c uses DECL_INITIAL to disallow adding the attribute to the definition of a variable. The selectany failures are because ix86_handle_selectany_attribute in config/i386/winnt.c uses DECL_INITIAL to disallow adding the attribute to a variable that is _not_ initialized. For both attributes, the test for DECL_INITIAL still work in C testcases. Danny -- Summary: attribute handling fallout from DECL_INITIAL changes Product: gcc Version: 4.2.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=27789
[Bug target/27650] internal compiler error while compiling Gecode
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-05-29 22:23 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug target/27789] [4.2 Regression] attribute handling fallout from DECL_INITIAL changes
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-05-30 22:33 --- Working on it. 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 |2006-05-30 22:33:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27789
[Bug bootstrap/25502] Werror problem in build
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-06-04 11:02 --- In my local tree (and in the 3.4.x mingw tree), I have added a modification and extension of this patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02296.html I plan to follow up in stage 1 of 4.3 This patch silences the worst of the warnings. However, because of the -pedantic switch, I still get warnings like ../../gcc/gcc/gcov-dump.c:408: warning: ISO C does not support the 'I64' printf length modifier -Wno-pedantic-errors doesn't work for me, so --disable-werror is still necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug c/27948] New: MS -bitfield struct layout test fails
Since this revision:
2006-06-04 Eric Christopher <[EMAIL PROTECTED]>
* stor-layout.c (start_record_layout): Initialize
remaining_in_alignment.
(debug_rli): Output value for remaining_in_alignment.
(update_alignment_for_field): Unconditionalize
ms_bitfield_layout_p code. Handle non-bitfield fields. Remove
extra alignment code.
(place_field): Don't realign if ms_bitfield_layout_p. Unconditionalize
ms_bitfield_layout_p code. Rewrite handling of structure fields.
* tree.h (record_layout_info_s): Remove prev_packed.
* doc/extend.texi (ms_struct): Add documentation of format.
The ms-bitfield test gcc.dg/bf-ms-layout.c fails.
In particular, the 0-size bitfield in
struct six {
char a :8;
int :0; /* not ignored; prior field IS a bitfield, causes
struct alignment as well. */
char b;
char c;
} ;
is being ignored
I have reconfirmed that that the test does indeed pass with MS VC6 compiler.
Danny
--
Summary: MS -bitfield struct layout test fails
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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=27948
[Bug target/27789] [4.2 Regression] attribute handling fallout from DECL_INITIAL changes
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-06-08 10:29 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00389.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27789
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-06-08 22:32 --- (In reply to comment #1) > Can you get me the size of that structure according to MS VC? With version 12.00.8804 of MS cl.exe, sizeof (struct six) == 8, as tested in the testcase. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug target/27789] [4.2 Regression] attribute handling fallout from DECL_INITIAL changes
--- Comment #5 from dannysmith at users dot sourceforge dot net 2006-06-23 08:27 --- Patch committed to trunk. 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=27789
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-06-26 21:21 --- I think you may be running into a compiler (MSVC vs GNUC) difference between handling of __stdcall (==JNICALL) symbols. For a function void __stdcall foo (int), both MSVC and GNUC generate an assembler name of '[EMAIL PROTECTED]'. The underscore is prefix to all assembler names, the @4 is unique to stdcall MSVC uses the name '[EMAIL PROTECTED]' in the dll export table when exporting from a dll, but '[EMAIL PROTECTED]' when exporting from a staticly linked object. GNUC uses '[EMAIL PROTECTED]' in both. If you look in info for binutils, under dlltool, you will see --ext-prefix-alias Add aliases with . That might help. However, I don't think that similar is supported by ld. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-06-26 22:26 --- (In reply to comment #3) > I think you may be running into a compiler (MSVC vs GNUC) difference between > handling of __stdcall (==JNICALL) symbols. Um, and this should all be taken care of by the #ifdef WIN32 code in jni.cc:_Jv_LookupJNIMethod Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug libfortran/28184] time intrinsics resolution only one second
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-06-28 09:52 --- The mingw runtime library now has a gettimeofday function which should give resolution to usec. When libgfortran is configured with the latest mingw runtime package, gettimeofday is found and used. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28184
[Bug c++/20345] Warning on forward declaration of class with __dllexport__
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-06-30 02:29 --- Confirming -- 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 |2006-06-30 02:29:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20345
[Bug c++/20345] Warning on forward declaration of class with __dllexport__
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-06-30 02:31 --- ... and closing. Fixed by http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01511.html Thanks Jason. 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=20345
[Bug target/12477] Request to add ability to disable inline/dllimport warnings
--- Comment #11 from dannysmith at users dot sourceforge dot net 2006-06-30 02:42 --- On today's trunk, your example no longer gives warnings. Instead it compiles, then fails with: C:\tmp>G++ -Wall -W test.cpp c:\tmp/ccOGb2M9.o:test.cpp:(.text+0x1e): undefined reference to _imp___ZN1TC1Ev' c:\tmp/ccOGb2M9.o:test.cpp:(.text+0x3b): undefined reference to `_imp___ZN1TD1Ev' collect2: ld returned 1 exit status OK to close? Is that what you want -- 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|2005-09-30 05:37:35 |2006-06-30 02:42:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12477
[Bug c++/15774] Conflicting function decls not diagnosed
-- 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|2005-04-30 16:18:12 |2006-06-30 02:48:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15774
[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails
--- Comment #17 from dannysmith at users dot sourceforge dot net 2006-07-06 01:06 --- On mingw32 the testcase will succeed on trunk if libstdc++ (and libgcc) are built as dlls. Wouldn't that be the preferred solution? It also solves very similar problems with EH data. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
[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/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=16713&action=view) [edit] > gcc44-pr38130.patch > > I've talked about this with Honza on IRC: > 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 > 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=16713&action=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 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 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 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 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/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=16906&action=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 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 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 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 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 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=17052&action=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 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 #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 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/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 #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=17132&action=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 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 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] 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 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 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=17841&action=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 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 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/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 libfortran/23138] [mingw32] real values are printed incorrectly
--- Comment #9 from dannysmith at users dot sourceforge dot net 2005-11-04 09:15 --- Hello, mingw has an implementation of _IO_ldtoa() and _IO_ldtostr(), based on Stephen Moshier's ioldoubl package, that could be used. Currently, the ldtoa function is not exposed, but there is no reason why it couldn't be. newlib provides a ldtoa() )also based on S Moshier's package that could be used on cygwin and other newlib targets. Would a ldtoa alternative to sprintf be acceptable? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug middle-end/28427] New: warning: alignment of '__FUNCTION__' is greater than maximum object file alignment.
This
2006-07-13 Jan Hubicka <[EMAIL PROTECTED]>
* cgraphunit.c (cgraph_varpool_analyze_pending_decls): Call
align_variable.
has lead to very many warnings of the form
../../gcc/gcc/fortran/array.c:0: warning: alignment of '__FUNCTION__' is
greater than maximum object file alignment. Using 16
../../gcc/gcc/fortran/array.c:1141: warning: alignment of 'current_expand' is
greater than maximum object file alignment. Using 16
on mingw32 target and prevents building with -Werror enabled.
--
Summary: warning: alignment of '__FUNCTION__' is greater than
maximum object file alignment.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
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=28427
[Bug target/28427] warning: alignment of '__FUNCTION__' is greater than maximum object file alignment.
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-07-20 02:31 --- The bug appears to be that subtarget is just too mean with MAX_OFILE_ALIGNMENT. Testing some (much) larger values. 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 Component|middle-end |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-20 02:31:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28427
[Bug target/28427] warning: alignment of '__FUNCTION__' is greater than maximum object file alignment.
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-07-20 08:06 --- config/i386/i386.c: ix86_data_alignment uses the magic number 256 as max_align (except with -Os). However, MAX_OFILE_ALIGNMENT defaulted to BIGGEST_ALIGNMENT windows32 targets. The PE COFF spec (and native compiler) indicate that the max user specified alignement in 8192 bytes. I don't know why this hasn't caused problems before now. Fixed by defining MAX_OFILE_ALIGNMENT. 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=28427
[Bug c++/28567] [cygwin] ICE in eh_alloc.cc on 'make install'
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-08-02 09:56 --- --disable-sjlj-exceptions in your configure options will cause serious problems on cygwin unless you also provide support for enabling Dwarf2 EH frame. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28567
[Bug target/28627] New: [cygwin/mingw32] Missing dllimport diagnostic
This change caused a new testsuite regression on windows32 targets
2006-08-01 Volker Reichelt <[EMAIL PROTECTED]>
PR c++/28250
PR c++/28257
PR c++/28259
PR c++/28267
* toplev.c (compile_file): Return early on errorcount or sorrycount.
* cgraphunit.c (cgraph_finalize_compilation_unit): Likewise.
(cgraph_optimize): Likewise.
Here:
FAIL: g++.dg/ext/dllimport7.C C++ specific error (test for errors, line 24)
(see eg: <http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg00086.html>
The testcase expects error messages for each of two static data members
that are declared in a dllimport'd class and later defined out of class.
const int Bar::three = 3; // { dg-warning "redeclared without dllimport"
}
// { dg-error "definition of static data" "C++ specific error" { target
i?86-*-cygwin* i?86-*-mingw* } 21 }
const Baz Bar::null_baz;// { dg-warning "redeclared without dllimport"
}
// { dg-error "definition of static data" "C++ specific error" { target
i?86-*-cygwin* i?86-*-mingw* } 24 }
only the first "C++-specific error" is emitted, Once errorcount > 0, no
more errors are reported.
Commenting out the early return on errorcount in cgraph_optimize()
restores the expected error message at line 24
The error messages are emitted by winnt-cxx.c:i386_pe_type_dllimport_p(),
a helper routine for targetm.encode_section_info.
Changing the errors to warnings, I get all the messages. The reason they
are errors, rather than warnings is because (1) native MS compiler calls
the definition of a static data member of a dllimport'd class an error and
(2) they usually indicate a silly dll[/im/ex/]port typo in the class
definition or a serious misunderstanding of dllimport semantics.
Danny
--
Summary: [cygwin/mingw32] Missing dllimport diagnostic
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: target
AssignedTo: dannysmith at users dot sourceforge dot net
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28627
[Bug target/28629] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-08-07 21:04 --- (In reply to comment #2) > (In reply to comment #0) > precisely, the bug can be reproduced with a combination of --march=pentium-m > (or --march=pentium3 -msse2), -mfpmath=sse,387, and any optimization level > high > than or equal to -O2. gcc -c -O2 -march=pentium-m -mfpmath=sse,387 filtbank.i compiles without error on trunk with native mingw32 Target: mingw32 Configured with: ../gcc/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --with-cpu=pentium2 --disable-werror --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,objc,fortran --disable-win32-registry --disable-sjlj-exceptions Thread model: win32 gcc version 4.2.0 20060803 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug target/28648] New: [4.2.0 regression] ICE with invalid dllimport attribute
The following causes ICE on windows targets on mainline. void foo (int __attribute__ ((dllimport)) bar); dllimp_parm.c:1: internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'parm_decl' in handle_dll_attribute, at tree.c:3762 Please submit a full bug report, I believe this is a regression from 3.4.5, but that is only because tree check now picks up the bug. -- Summary: [4.2.0 regression] ICE with invalid dllimport attribute Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-checking Severity: normal Priority: P3 Component: target AssignedTo: dannysmith at users dot sourceforge dot net ReportedBy: dannysmith at users dot sourceforge dot net GCC host triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28648
[Bug target/28648] [4.2.0 regression] ICE with invalid dllimport attribute
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-08-08 09:08 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00200.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28648
[Bug c++/28705] New: ICE: in type_dependent_expression_p, at cp/pt.c:12837
As reported at:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1539256&group_id=2435
This testcase:
=
namespace N
{
struct s { };
template struct tplt { void mf(const T &) {} };
tplt &f();
}
template bool g()
{
N::s *p = 0;
N::f().mf(s(p));
return true;
}
ICES with
cfg.C: In function 'bool g()':
cfg.C:12: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:12837
This is with
GNU C++ version 4.2.0 20060808 (experimental) (mingw32)
It also ICES with gcc-3.4.5
Danny
--
Summary: ICE: in type_dependent_expression_p, at cp/pt.c:12837
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28705
[Bug c/28287] [4.1/4.2 regression] ICE with misplaced attribute weak
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-08-14 23:29 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00473.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28287
[Bug c/28287] [4.1/4.2 regression] ICE with misplaced attribute weak
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-08-15 21:48 --- Assigning to self so... -- 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|2006-08-12 00:02:25 |2006-08-15 21:48:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28287
[Bug c/28287] [4.1 regression] ICE with misplaced attribute weak
--- Comment #8 from dannysmith at users dot sourceforge dot net 2006-08-15 21:49 --- Fixed on trunk -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.1 regression] ICE with |with misplaced attribute|misplaced attribute weak |weak| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28287
[Bug driver/28528] [4.0/4.1/4.2 regression] Trouble compiling header files with "-x c++" using g++
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-08-18 04:48 --- Also, removing the space between '-x' and 'c++' works, eg, g++ -fsyntax-only -xc++ stdio.h but I get warning warning: #pragma system_header ignored outside include file ditto with g++ -c -x c++ stdio.H warning: #pragma system_header ignored outside include file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug middle-end/28648] [4.2 regression] ICE with invalid dllimport attribute
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-08-20 08:48 --- Fixed on trunk. -- 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=28648
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-08-22 00:37 --- (In reply to comment #8) > patch to prevent searching of configured path with relocated toolchain Are you aware of this discussion http://gcc.gnu.org/ml/gcc/2006-07/msg00313.html and this alternative patch, installed in a csl vendor branch http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00684.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug testsuite/28828] FAIL: gcc.dg/attr-invalid.c
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-08-24 01:10 --- This is my bad. Sorry. Should be fixed by: http://gcc.gnu.org/ml/gcc-cvs/2006-08/msg00514.html 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 |2006-08-24 01:10:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28828
[Bug driver/28528] [4.0/4.1 Regression] C language extensions override -x in C++ driver
--- Comment #11 from dannysmith at users dot sourceforge dot net 2006-08-25 00:27 --- Fixed on mainline. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Known to fail|3.4.0 4.0.0 4.1.0 4.2.0 |3.4.0 4.0.0 4.1.0 Known to work|3.3.3 |3.3.3 4.2.0 Summary|[4.0/4.1/4.2 Regression] C |[4.0/4.1 Regression] C |language extensions override|language extensions override |-x in C++ driver|-x in C++ driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug target/12477] Request to add ability to disable inline/dllimport warnings
--- Comment #14 from dannysmith at users dot sourceforge dot net
2006-08-27 21:14 ---
(In reply to comment #12)
> This happens with Qt4 Win32 as well - lot of warnings - "warning: inline
> function... attribute ignored". All that's needed is a -Wno-inline-dllimport
> type of flag to mingw to suppress these warnings.
This is current (gcc-4.2) behaviour.
What exactly is wrong with using -Wno-attributes to suppress the warnings.
Danny
// warn-inline-dllimport.c
__declspec (dllimport) void f1();
// inline definition (silently) overides earlier dllimport declaration
inline void f1() {}
// inline && dllimport in definition emits warning
// both can't be true.
inline __declspec (dllimport) void f2 () {}
void b()
{
f1();
f2();
}
compiling as:
gcc -Wall -c warn-inline-dllimport.c
produces:
warn-inline-dllimport.c:8: warning: inline function 'f2' declared as dllimport:
attribute ignored
compiling as:
gcc -Wall -Wno-attributes -c warn-inline-dllimport.c
gets rid of the attribute warning
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12477
[Bug rtl-optimization/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #13 from dannysmith at users dot sourceforge dot net 2006-09-11 19:47 --- In my sources for David Gay's gdtoa implemntation it say this: /* On a machine with IEEE extended-precision registers, it is * necessary to specify double-precision (53-bit) rounding precision * before invoking strtod or dtoa. If the machine uses (the equivalent * of) Intel 80x87 arithmetic, the call * _control87(PC_53, MCW_PC); * does this with many compilers. Whether this or another call is * appropriate depends on the compiler; for this to work, it may be * necessary to #include "float.h" or another system-dependent header * file. */ There is a variant of strtod in the gdtoa file strtodnrp.c: /* This is a variant of strtod that works on Intel ia32 systems */ /* with the default extended-precision arithmetic -- it does not */ /* require setting the precision control to 53 bits. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-09-12
23:36 ---
The problem is that although all 'regular' files are opened as O_BINARY,
preconnected files stderr and stdout are already opened as default O_TEXT.
The simplest fix is just to force the mode of these preconnected files to
O_BINARY at initialisation, as below.
This needs more testing before I submit a formal patch, but it certainly fixes
a lot of gfortran mingw32 testsuite cases where stdout results are scanned.
The alternative would be to change each
#ifdef (HAVE_CRLF)
to
if (HAVE_CRLF) && is_regular_file(fd)
Index: io/unix.c
===
*** io/unix.c (revision 116838)
--- io/unix.c (working copy)
*** input_stream (void)
*** 1289,1294
--- 1289,1297
stream *
output_stream (void)
{
+ #if defined(HAVE_CRLF) && defined(O_BINARY)
+ setmode (fileno (stdout), O_BINARY);
+ #endif
return fd_to_stream (STDOUT_FILENO, PROT_WRITE);
}
*** output_stream (void)
*** 1299,1304
--- 1302,1310
stream *
error_stream (void)
{
+ #if defined(HAVE_CRLF) && defined(O_BINARY)
+ setmode (fileno (stderr), O_BINARY);
+ #endif
return fd_to_stream (STDERR_FILENO, PROT_WRITE);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-09-13 03:59 --- (In reply to comment #5) > This is not DLL-related, the following code doesn't have the expected > behaviour > (although it works fine on i686-linux, even in the static case): With gcc version 4.2.0 20060911, the test case in Comment #5 works as expected if the app is run from a cmd.exe shell or from a bash shell. When the output is redirected to a file, I get the results you report, but with redirection, one might expect that (on windows at least) in absence of flush call. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-13
10:10 ---
(In reply to comment #5)
> This is not DLL-related, the following code doesn't have the expected
> behaviour
> (although it works fine on i686-linux, even in the static case):
> $ cat ctesti.c
> #include
> void print_from_gcc(char* txt) {
> printf("%s\n",txt);
> }
> int main(int argc, char** argv) {
> print_from_gcc ("c");
> print_from_gfortran_("f");
> print_from_gcc ("c");
> print_from_gfortran_("f");
> return 0;
> }
Changing main() in ctesti.c to start with:
int main(int argc, char** argv) {
setvbuf(stdout, NULL, _IOLBF, 0);
fixes the redirection problem.
If you stll think that this is a libgfortran bug (I don't)
you could add
setvbuf(stdout, NULL, _IOLBF, 0);
to unix.c:output_stream() so that stdout always is line-buffered even when
!isatty(fileno(stdout))
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug c/29094] New: Inline definition vs builtin function calls
This testcase:
/* f.c */
extern double exp (double);
extern float strtof(const char*, char**);
inline float expf (float x)
{return (float) exp (x);}
int main (int argc, char** argv)
{
float f;
if (argc > 1)
{
f = strtof (argv[1], (void*)0);
printf ("%g\n", expf(f));
}
return 0;
}
compiled with gcc version 4.2.0 20060913
goes into infinite loop when expf is called
Here is assembly
.file "f.c"
.text
.p2align 4,,15
.globl _expf
.def_expf; .scl2; .type 32; .endef
_expf:
pushl %ebp
movl%esp, %ebp
popl%ebp
jmp _expf
It works fine if compiled with -fno-builtin-exp
This is regression from 3.4.5.
Danny
--
Summary: Inline definition vs builtin function calls
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29094
[Bug target/29094] Inline definition vs builtin function calls
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-09-15 03:34 --- (In reply to comment #1) > Is TARGET_C99_FUNCTIONS set for the mingw32 target? It is set in my local development tree, and I was planning to set it in mingw32.h config file, but I may be a bit premature :( Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29094
[Bug target/29094] Inline definition vs builtin function calls
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-09-15
03:51 ---
(In reply to comment #3)
>
> If you are defining expf with TARGET_C99_FUNCTIONS set to 1, then you have to
> use -fno-builtin-exp.
> So just to make sure this is with TARGET_C99_FUNCTIONS set to 1?
Yes.
In build which shows this error, I have
#define TARGET_C99_FUNCTIONS 1 in mingw32.h
In mingw32 C runtime , expf is defined as:
extern __inline float __attribute__(cdecl) expf (float x)
{return (float) exp (x);}
expf is also defined in runtime library as well.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29094
[Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-20 09:52 --- (In reply to comment #6) > I think this is fixed on 4.2: Its still broken on my machine Try after compiling the testcase with optimization turned on. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539
[Bug target/27650] internal compiler error while compiling Gecode
--- Comment #11 from dannysmith at users dot sourceforge dot net 2006-09-20 23:37 --- Fixed on trunk. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug libfortran/27964] Wrong line ends on windows (XP)
-- 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|2006-06-08 19:14:51 |2006-09-23 02:00:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #12 from dannysmith at users dot sourceforge dot net 2006-09-23 02:00 --- Fixed on trunk -- 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=27964
[Bug target/28069] __m128 local variables don't get properly aligned.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-09-23 06:34 --- (In reply to comment #2) > In a way this is a dup of bug 27537. Though there is an attribute to realign > the stack in 4.2.0 so using that might just fix this issue instead. Indeed, 5c5 < void dct64_sse(float *a,float *b,float *c) --- > void __attribute__ ((force_align_arg_pointer)) dct64_sse(float *a,float > *b,float *c) fixes on 4.2. BTW, this issue has particular importance for mingw32 multithreaded programs, since Win32 API CreateThread or the corresponding CRT _beginthreadex functions do not guarantee that the stack will be 16-byte-aligned on entry to the thread start-function callback. Marking the thread start function with force_align_arg_pointer attribute fixes. Hmm should that go in gcc.info? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28069
[Bug other/29242] system headers lack a distinct default calling convention
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-27 03:23 --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > Imagine building gcc itself with regparm 3. You probably don't want > to mark up the gcc source to enable this, but marking up the system > header files is definitely not an option. Actually, om mingw32, the system headers are marked up (explicitly) with calling convention (__cdecl, __stdcall, __fastcall), to avoid the -mrtd problem. So it is an option. I think that MSVC headers also do this. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29242
[Bug libstdc++/29426] New: static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
The concurrence.h mutex lock/unlock changes of 13 Sept have caused
failure of all C++ testcases using std::cout on mingw32, iff -mthreads
(enabling __gthread_active_p) option is added to RUNTESTFLAGS.
Originally, the failures were of the form"
"terminate called after throwing an instance of 'std::runtime_error'
what(): __mutex::lock"
and resulted from the target __gthread_mutex_lock being handed an invalid
mutex.
Its a Good Thing the error checking had been turned on by the same
patchset :)
Its a Bad Thing that I haven't been testing with -mthreads
turned on more frequently :(
This patch
2006-10-09 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstdc++/29118
* src/locale_init.cc (__get_locale_mutex): New.
(locale::locale): Use it.
(locale::global): Use it.
.
got rid of those errors, but they were replaced by:
"terminate called after throwing an instance of 'std::runtime_error'
what(): __recursive_mutex::lock"
^
(mingw32 uses __GTHREAD_MUTEX_INIT_FUNCTION)
These can be fixed by reverting this part of the 13 Sept patch
* libsupc++/guard.cc (static_mutex): Subsume into and fixup for...
* include/ext/concurrence.h (__recursive_mutex): ...this.
like so:
Index: guard.cc
===
--- guard.cc(revision 117613)
+++ guard.cc(working copy)
@@ -42,8 +42,49 @@
#ifdef __GTHREADS
namespace
{
- // A single mutex controlling all static initializations.
- __gnu_cxx::__recursive_mutex static_mutex;
+ // static_mutex is a single mutex controlling all static initializations.
+ // This is a static class--the need for a static initialization function
+ // to pass to __gthread_once precludes creating multiple instances, though
+ // I suppose you could achieve the same effect with a template.
+ class static_mutex
+ {
+static __gthread_recursive_mutex_t mutex;
+
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
+static void init();
+#endif
+
+ public:
+static void lock();
+static void unlock();
+ };
+
+ __gthread_recursive_mutex_t static_mutex::mutex
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT
+ = __GTHREAD_RECURSIVE_MUTEX_INIT
+#endif
+ ;
+
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
+ void static_mutex::init()
+ {
+__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION (&mutex);
+ }
+#endif
+
+ void static_mutex::lock()
+ {
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
+static __gthread_once_t once = __GTHREAD_ONCE_INIT;
+__gthread_once (&once, init);
+#endif
+__gthread_recursive_mutex_lock (&mutex);
+ }
+
+ void static_mutex::unlock ()
+ {
+__gthread_recursive_mutex_unlock (&mutex);
+ }
}
#ifndef _GLIBCXX_GUARD_TEST_AND_ACQUIRE
@@ -144,12 +185,12 @@
bool unlock;
mutex_wrapper (): unlock(true)
{
- static_mutex.lock();
+ static_mutex::lock ();
}
~mutex_wrapper ()
{
if (unlock)
- static_mutex.unlock();
+ static_mutex::unlock ();
}
} mw;
@@ -172,7 +213,7 @@
recursion_pop (g);
#ifdef __GTHREADS
if (__gthread_active_p ())
- static_mutex.unlock();
+ static_mutex::unlock ();
#endif
}
@@ -183,7 +224,7 @@
_GLIBCXX_GUARD_SET_AND_RELEASE (g);
#ifdef __GTHREADS
if (__gthread_active_p ())
- static_mutex.unlock();
+ static_mutex::unlock ();
#endif
}
}
--
Summary: static __recursive_mutex init vs
__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
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=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #12 from dannysmith at users dot sourceforge dot net 2006-10-11 20:54 --- (In reply to comment #4) > - __gnu_cxx::__recursive_mutex static_mutex; > + static __gnu_cxx::__recursive_mutex static_mutex; I tried thaty before I submitted bug report. No dice. (In reply to comment #11) > 2006-10-11 Benjamin Kosnik <[EMAIL PROTECTED]> > PR libstdc++/29426 > * libsupc++/guard.cc (get_static_mutex): New. > (mutex_wrapper::mutex_wrapper): Use it to get properly initialized > recursive mutex without ordering issues. > * src/locale_init.cc (__get_locale_mutex): No need to > uglify. Change to get_locale_mutex. Thanks I submitted a bug report just before I went to bed and it was fixed in the morning. Wow! This fixes testsuite failures on mingw32, too. Tested with and without -mthreads. Also tested with a pending (stage 1) patch to enable __cxa_atexit like destruction on mingw32. 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=29426
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-01-26 00:24 --- CVS mingw runtime header _mingw.h has this, which avoids the problem: # if ( __MINGW_GNUC_PREREQ(4, 3) && __STDC_VERSION__ >= 199901L) # define __CRT_INLINE extern inline __attribute__((__gnu_inline__)) # else # define __CRT_INLINE extern __inline__ # endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #10 from dannysmith at users dot sourceforge dot net 2007-01-27 10:06 --- (In reply to comment #9) > (In reply to comment #8) > > So I still say we should just require makeinfo when building from > > SVN/snapshot. > > There is no reason not really. > > Yes there are reasons: for example, makeinfo does not easily build on mingw32, > and probably some other non-mainstream archs. > makeinfo does build easily using cygwin toolchain, and hence is available on windows for use with mingw. You can just download makeinfo binaries from cygwin/redhat/sourceware unless it against your religion. Or you could get makeinfo from MS as part of its POSIX emulation toolkit Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug other/30335] CreateFileMapping fails in Vista due to lack of admin privileges
--- Comment #9 from dannysmith at users dot sourceforge dot net 2007-02-02 19:31 --- Created an attachment (id=12997) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12997&action=view) Patch for Vista/CreateFileMapping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335
[Bug other/30335] CreateFileMapping fails in Vista due to lack of admin privileges
--- Comment #10 from dannysmith at users dot sourceforge dot net 2007-02-02 19:32 --- It seems strange to me that CreateFileMapping puts _unnamed_ object into Global namespace. Can you point me to documentation for this feature? If CreateFileMapping functionality has changed, maybe we should just avoid it and use VirtualAlloc throughout. Can you test attached patch with Reactos build? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-02-22 01:32 --- This testcase and the one in 27924 now compile successfully on gcc version 4.2.0 20070218 (prerelease) and gcc version 4.3.0 20070218 (experimental) on i686-pc-mingw32 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug middle-end/30956] ice on final.c
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-02-25 03:39 --- On trunk and 4.2.0 (target i686-pc-mingw32), invalid code is diagnosed correctly: fribidi_utils.c: In function 'fribidi_map_range': fribidi_utils.c:72: error: 'fribidi_map_range': definition is marked as dllimport Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #10 from dannysmith at users dot sourceforge dot net 2007-03-10 01:51 --- In dlls buit by MS windows native toolchain (eg the win32api system libraries), exported functions are built with __stdcall calling convention, but are exported without any decoration, eg, WinFooFoo is simply WinFooFoo. I believe this is a legacy of use of Pascal language way back in MS-DOS beginnings. IIRC, the old MS VisualFortran compiler also, used stdcall convention by default, but did not use the @n stdcall decoration, Now, MS has a popular language called VisualBasic, that like Pascal, uses __stdcall convention (sans decoration of symbol names). So if you want to use your gfortran dll in a VB app, the simplest thing to do is build your dll's the MS way. That is where -mrtd comes in. (And please do read the big caveat about using -mrtd in gcc.info.) The @n stdcall suffix is an extern "C" language thing. (MS compiler doesn't even use in C++, but G++ does.) To link against a stdcall function exported from a DLL (undecorated as per win32api convention) you need to map the the stdcall name expected by C to the undecorated Pascal name exported from the DLL. This is normally done by the linker when building a DLL import lib from a .def file. The GNU linker option to accomplish this is "--kill-at". Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug middle-end/30196] VLA and setjumplongjump exceptions
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-03-14 05:57 --- This is a duplicate of PR 19774 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug c/31275] ICE During Gettext Build
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-03-20 08:21 --- This is a dup of PR 29826. The testcase (and 29826) succeeds on gcc version 4.2.0 20070319 (prerelease) and on gcc version 4.3.0 20070318 (experimental) with mingw32 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31275
[Bug libfortran/31335] Calls lstat(), stat() and fstat() in libgfortran should be protected by autoconf HAVE_{L,,F}STAT macros
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-03-25 11:12 --- http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
[Bug c/31457] Internal Compiler Error
-- 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 |2007-04-03 09:52:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31457
[Bug c/31457] Internal Compiler Error
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-04-03 09:54 --- Duplicate of 29826 which is fixed on 4.2.0 and trunk. Danny *** This bug has been marked as a duplicate of 29826 *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31457
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #10 from dannysmith at users dot sourceforge dot net 2007-04-03 09:54 --- *** Bug 31457 has been marked as a duplicate of this bug. *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||henman at it dot to-be dot ||co dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #14 from dannysmith at users dot sourceforge dot net 2007-04-20 07:49 --- (In reply to comment #13) > I'm going to try again since it seems my last post was just ignored. > The test case works fine on 4.2 but it still occurs under some circumstances. If you provide preprocessed source that reproduces the circumstances , as suggested, I will not ignore it. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #16 from dannysmith at users dot sourceforge dot net 2007-04-22 02:01 --- Created an attachment (id=13403) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13403&action=view) Patch for testcase in 31636 Could you please test the attached patch to tree-ssa-address.c which is a reversal of a fragment of the reversion of the 4.2.0 TLS emulation patch. After I re-re-reverted this patch in my local tree, I see the ICE in your testcase. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug target/31680] Cannot create DLL with exported stdcall functions because compiler exports the functions without the @N decoration
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-04-25 09:57 --- Testing a patch. 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 |2007-04-25 09:57:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31680
[Bug target/31680] Cannot create DLL with exported stdcall functions because compiler exports the functions without the @N decoration
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-04-25 11:17 --- Fixed. Author: dannysmith Date: Wed Apr 25 11:06:28 2007 New Revision: 124149 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124149 Log: * config/i386/winnt.c (i386_pe_file_end): Strip only USER_LABEL_PREFIX when writing export name. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt.c -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31680
