[Bug libffi/40807] New: [4.5 Regression] : libffi.call/return_sc.c
+++ This bug was initially created as a clone of Bug #32843 +++
On Linux/ia32, this patch
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00336.html
caused
FAIL: libffi.call/return_sc.c -O0 -W -Wall execution test
FAIL: libffi.call/return_sc.c -O2 execution test
FAIL: libffi.call/return_sc.c -O3 execution test
The fix for this bug broke win32. The final patch in bug 32843 comment 17:
http://gcc.gnu.org/viewcvs?root=gccview=revrev=131343
added support for Darwin by introducing two extended return value types:
+#define FFI_TYPE_SMALL_STRUCT_1B (FFI_TYPE_LAST + 1)
+#define FFI_TYPE_SMALL_STRUCT_2B (FFI_TYPE_LAST + 2)
and code in x86/ffi.c#ffi_prep_cif_machdep to use those types in preference to
equivalent int sizes:
@@ -142,11 +146,11 @@
case FFI_TYPE_STRUCT:
if (cif-rtype-size == 1)
{
- cif-flags = FFI_TYPE_SINT8; /* same as char size */
+ cif-flags = FFI_TYPE_SMALL_STRUCT_1B; /* same as char size */
}
else if (cif-rtype-size == 2)
{
- cif-flags = FFI_TYPE_SINT16; /* same as short size */
+ cif-flags = FFI_TYPE_SMALL_STRUCT_2B; /* same as short size */
}
else if (cif-rtype-size == 4)
{
... but it didn't add any code in any of the functions in x86/win32.S to handle
the new extended return codes; right now they fall through and get mistaken for
no return value at all.
I'm working on a patch. Hmm, looking closer, it seems that win32.S doesn't
handle any of the UINT types either. Groan. I guess I'll adapt the jump table
approach as seen in sysv.S/darwin.S and fill out every case.
I notice that ffi_call_SYSV has to handle all the return types, but not
ffi_closure_SYSV nor ffi_closure_raw_SYSV. Does anyone know why that is?
--
Summary: [4.5 Regression] : libffi.call/return_sc.c
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-07-19 17:50 --- (In reply to comment #0) I notice that ffi_call_SYSV has to handle all the return types, but not ffi_closure_SYSV nor ffi_closure_raw_SYSV. Does anyone know why that is? To answer my own question: it appears to be an omission, and these functions should also handle all return types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug bootstrap/40455] gcc trunk does not bootstrap as of commit r148408
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-07-05 23:47 --- (In reply to comment #19) (In reply to comment #18) As Dave suggests in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455#c13, this is fixed, I tried it yesterday, after updating with SVN and updating my 1.7 cygwin, and got the same failure. It seems to me that he is saying that we have to wait a few days for the new binutils to make it into cygwin. Either that, or to build your own binutils from CVS, but in fact the new binutils should have reached most of the mirrors by now, so give it a go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #64 from dave dot korn dot cygwin at gmail dot com 2009-07-04 12:47 --- (In reply to comment #63) GCC still generates a segfaulting executable when used with the testcase in the report, most likely because my assembler doesn't support the 3-argument .comm directive. When using the '-mpe-aligned-commons' i get an error about this: Error: junk at end of line, first unrecognized character is `,' Of course. What were you hoping would happen? -- 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 #66 from dave dot korn dot cygwin at gmail dot com 2009-07-04 13:21 --- (In reply to comment #65) Indeed, i should have expected this, and after rereading the comments here you even mentioned this problem already. Sorry for the noise. That's OK. GCC attempts to detect at configure time if the installed toolchain supports the feature, and will configure itself to generate or not the 3-operand form according to the results of that test. The command-line option is there if you ever need to override it, but that'll only be the case if you're mixing-and-matching toolsets or doing some other kind of complex trickery that involves using GCC with a different binutils from that it was configured for. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug bootstrap/40455] gcc trunk does not bootstrap as of commit r148408
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-07-04 23:27 --- (In reply to comment #14) I am on cygwin-1.5. will these fixes get pushed to setup? or am I stuck? or is there a work around? Hi Jerry, I can't answer that question. There is a new binutils release on its way, but as you know 1.5 is dead, and I don't know if it'll be released for 1.5. You definitely can download binutils CVS and build and install it yourself on 1.5, and it'll all work for you, so you aren't stuck, no matter what happens. But you shouldn't really be wasting time trying to make gcc HEAD work on an old and outdated version of the cygwin DLL; it's not guaranteed and it will never be supported. 1.7 does actually work very well, and since you're doing GCC development you really want to move up; we're not going to go to great lengths to keep backward compatibility with obsolete versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
[Bug bootstrap/40455] gcc trunk does not bootstrap as of commit r148408
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-07-04 23:55 --- It is beta, yeah. But it's a damn good beta :) Can't promise you won't stumble across a new bug or two, but it's reliable enough for fairly heavy-duty everyday usage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-06-29 15:12 --- I think the best solution to this problem is to enable libstdc++ as a DLL, and export _S_empty_rep from it. Then every C++ DLL and EXE will link against libstdc++ and they'll all import the exact same instance. Problem solved *and* we get to keep the optimisation. The more difficult problem of windows shared-libraries not allowing undefined references (and how this interacts with RTTI and COMDATs in particular) is a larger issue which will need to be tackled separately. I'm about to test a patch based on this approach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-06-25 15:37 --- Hmm, I'm getting somewhere with this. By compiling the g++ testsuite ptrflags.C case with --save-temps, manually hacking all the superfluous typeinfo stuff out, and re-assembling and linking it, I can turn a FAIL into a PASS, with all the typeinfo and related stuff being imported from the DLL. So I think typeinfo can be made to work, and work with both __GXX_MERGED_TYPEINFO_NAMES and __GXX_TYPEINFO_EQUALITY_INLINE. All I need to do is stop the compiler from emitting comdat definitions of items with vague linkage when they are dllimported, or perhaps make the linker prefer an import over a comdat section when the same symbol could be resolved by either. Or perhaps both. I think the linker fix is what you were suggesting when you said since if we depend on auto-import than we should treat dll imports thae same as static lib imports More later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug bootstrap/40455] gcc trunk does not bootstrap as of commit r148408
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16 11:26 --- Could you re-run that with --save-temps, and attach the .i, .s, .o and .exe files to the PR please? -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
[Bug bootstrap/40456] gcc trunk does not bootstrap as of commit r148492
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16 11:40 --- Already fixed at r.148523, according to: http://gcc.gnu.org/ml/gcc/2009-06/msg00339.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40456
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-06-01 08:05 --- I checked the fix and it works. Verified. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] New: gfortran does not support static c/d-tors.
[ ref: http://gcc.gnu.org/onlinedocs/gccint/Initialization.html ] [ ref: http://gcc.gnu.org/ml/fortran/2009-05/threads.html#00440 ] gfortran does not set main_identifier_node to anything. This causes gimple_expand_cfg() in cfgexpand.c to fail to emit a call to the libgcc static init function __main, because the MAIN_NAME_P check in this conditional: /* If this function is `main', emit a call to `__main' to run global initializers, etc. */ if (DECL_NAME (current_function_decl) MAIN_NAME_P (DECL_NAME (current_function_decl)) DECL_FILE_SCOPE_P (current_function_decl)) expand_main_function (); fails. On cygwin, this means that gfortran's init() function is never set up, the units and option variables don't get initialised, and hello world fails when it tries to output the first char, with a runtime library error. The fix is to correctly initialise it somewhere in the fortran compiler's early startup, using a line as simple as: main_identifier_node = get_identifier (main); although I don't know for sure what mangled version of the name main to use for fortran, or where would be the best place in the fortran frontend to put this code. -- Summary: gfortran does not support static c/d-tors. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-30 15:01 --- It's not entirely straightforward, it seems. An earlier attempt appears to have fizzled out: http://gcc.gnu.org/ml/fortran/2007-09/threads.html#00289 I do not yet understand Andrew Pinski's objection: This is wrong as it causes the middle-end to also emitt a call to __main inside MAIN__. Now you will get two calls to __main which calls the global constructors now twice. as I don't understand what the also refers to. Right now there are precisely no calls to __main at all. Perhaps there used to be an actual C-linkage main function in libgfortran. Yes, wait a minute, this is what libgfortranbegin used to get us, is it not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-30 15:19 --- About to test this: $ svn diff -x -p fortran/trans-decl.c Index: fortran/trans-decl.c === --- fortran/trans-decl.c(revision 147949) +++ fortran/trans-decl.c(working copy) @@ -3859,7 +3859,8 @@ create_main_function (tree fndecl) tmp = build_function_type_list (integer_type_node, integer_type_node, build_pointer_type (pchar_type_node), NULL_TREE); - ftn_main = build_decl (FUNCTION_DECL, get_identifier (main), tmp); + main_identifier_node += ftn_main = build_decl (FUNCTION_DECL, get_identifier (main), tmp); DECL_EXTERNAL (ftn_main) = 0; TREE_PUBLIC (ftn_main) = 1; TREE_STATIC (ftn_main) = 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-05-30 15:34 --- (In reply to comment #3) About to test this: That was wrong. This is what I should have said: $ svn diff fortran/trans-decl.c Index: fortran/trans-decl.c === --- fortran/trans-decl.c(revision 147949) +++ fortran/trans-decl.c(working copy) @@ -3859,7 +3859,8 @@ tmp = build_function_type_list (integer_type_node, integer_type_node, build_pointer_type (pchar_type_node), NULL_TREE); - ftn_main = build_decl (FUNCTION_DECL, get_identifier (main), tmp); + main_identifier_node = get_identifier (main); + ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp); DECL_EXTERNAL (ftn_main) = 0; TREE_PUBLIC (ftn_main) = 1; TREE_STATIC (ftn_main) = 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-30 15:38 --- The patch in comment 4 works. dkad...@ubik /tmp/fortran $ ./hello-fixed.exe Hello World! dkad...@ubik /tmp/fortran $ gdb ./hello-fixed.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-cygwin... (gdb) disass main Dump of assembler code for function main: 0x0040114d main+0:push %ebp 0x0040114e main+1:mov%esp,%ebp 0x00401150 main+3:and$0xfff0,%esp 0x00401153 main+6:sub$0x10,%esp 0x00401156 main+9:call 0x401210 __main 0x0040115b main+14: mov0xc(%ebp),%eax 0x0040115e main+17: mov%eax,0x4(%esp) 0x00401162 main+21: mov0x8(%ebp),%eax 0x00401165 main+24: mov%eax,(%esp) 0x00401168 main+27: call 0x402320 *__gfortran_set_args 0x0040116d main+32: movl $0x417b00,0x4(%esp) 0x00401175 main+40: movl $0x8,(%esp) 0x0040117c main+47: call 0x4023b0 *__gfortran_set_options 0x00401181 main+52: call 0x4010e0 MAIN__ 0x00401186 main+57: mov$0x0,%eax 0x0040118b main+62: leave 0x0040118c main+63: ret 0x0040118d main+64: nop 0x0040118e main+65: nop 0x0040118f main+66: nop End of assembler dump. (gdb) I'll try a testsuite run now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-05-30 16:12 --- Groan. PASS: gfortran.dg/Wall.f90 (test for excess errors) spawn [open ...] Internal Error: insert(): Duplicate key found! FAIL: gfortran.dg/Wall.f90 execution test In other words, exactly what Andrew warned would happen. Breakpoint 1, __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993 993 do_global_ctors (user_data-ctors, false); (gdb) bt #0 __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993 #1 0x00401166 in main () (gdb) c Continuing. Breakpoint 1, __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993 993 do_global_ctors (user_data-ctors, false); (gdb) bt #0 __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993 #1 0x004010ee in MAIN__ () #2 0x00401191 in main () (gdb) For some reason though, there isn't any call to __main in MAIN__ in my original hello world testcase, only in main. I don't yet understand that. It may be to do with the usage of main_program_symbol() in parse.c, which is called from two places: case ST_PROGRAM: if (seen_program) goto duplicate_main; seen_program = 1; prog_locus = gfc_current_locus; push_state (s, COMP_PROGRAM, gfc_new_block); main_program_symbol(gfc_current_ns, gfc_new_block-name); accept_statement (st); /* Anything else starts a nameless main program block. */ default: if (seen_program) goto duplicate_main; seen_program = 1; prog_locus = gfc_current_locus; push_state (s, COMP_PROGRAM, gfc_new_block); main_program_symbol (gfc_current_ns, MAIN__); I'm not sure yet what happens when we take the first one of these clauses and create a main function that is not called MAIN__, because there is code in gfc_sym_mangled_function_id in trans-decl.c that assumes any main function has the same name: /* Main program is mangled into MAIN__. */ if (sym-attr.is_main_program) return get_identifier (MAIN__); Possibly this is an inconsistency, and if there's a named main block we create a main function but then look up what will effectively be an unrelated name. I need advice from someone who knows the fortran compiler internals better than me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug fortran/40309] gfortran does not support static c/d-tors.
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-05-30 17:09 --- http://gcc.gnu.org/ml/fortran/2009-05/msg00452.html We have two functions that both match MAIN_NAME_P, because they share the same DECL_NAME. This happens when there is a PROGRAM main directive in the fortran source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #58 from dave dot korn dot cygwin at gmail dot com 2009-05-23 11:46 --- Created an attachment (id=17906) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17906action=view) Revised patch Revised version of the patch that defines the autoconf feature test macro to 0/1 rather than to undefined/defined, so it can be used to init the target option variable correctly even when gas during configure does not support 3-option .comm format. Nearly completed bootstrap now, will post to the -patches list (minus the generated file diffs) later when testing underway. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Attachment #17895|0 |1 is obsolete|| 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 #59 from dave dot korn dot cygwin at gmail dot com 2009-05-23 14:08 --- Created an attachment (id=17909) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17909action=view) D'oh. Quick respin. Huh. Alignment is passed to the backend as number of bits, but of course the assembler wants it as the power of 2 of the number of bytes to align it to. Fortunately I spotted this in manual testing before kicking off the 48-hr testrun, so I'm restrapping the patch with one tiny change to winnt.c before I do. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Attachment #17906|0 |1 is obsolete|| 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 #57 from dave dot korn dot cygwin at gmail dot com 2009-05-20 21:16 --- Bah. In case anyone else was about to point this out to me, +gcc_GAS_CHECK_FEATURE([.comm with alignment], gcc_cv_as_comm_has_align, + [2,19,52],, + [.comm foo,1,32],, +[AC_DEFINE(HAVE_GAS_ALIGNED_COMM, 1, + [Define if your assembler supports specifying the alignment + of objects allocated using the GAS .comm command.])]) ... that won't work with ... +mpe-aligned-commons +Target Var(use_pe_aligned_common) Init(HAVE_GAS_ALIGNED_COMM) ... that, because it's undefined, not zero, when the feature isn't detected. I'll have to respin it. -- 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 #56 from dave dot korn dot cygwin at gmail dot com 2009-05-20 04:25 --- Created an attachment (id=17895) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17895action=view) Target option and autoconf test to enable aligned common support. Currently putting the attached through a bootstrap and test cycle. This adds a configure time GAS feature check for the 3-operand form aligned .comm pseudo-op, and a target-specific command-line switch -mpe-aligned-commons which is enabled or disabled by default depending on the status returned from the configure check. It doesn't yet address disabling use of commons when no alignment support is available. That can be done as a follow-on patch. -- 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 #54 from dave dot korn dot cygwin at gmail dot com 2009-05-14 06:25 --- I've started work on the binutils support for this. Work-in-progress patch at http://sourceware.org/ml/binutils/2009-05/msg00228.html Once that's complete, I could deal with the GCC end too. What should we do about backward-compatibility? If we attempt to use the new features with the old toolchain, it won't work, and the linker will issue a bunch of noisy warnings about the .drectve statements it doesn't understand. Should use of the new feature depend on a -m flag, or an assembler/linker version check of some sort? Or should we just go ahead and let users of old toolchains get a bunch of warnings? On the same lines, should we still continue to pad all COMMON symbols to a round multiple of BIGGEST_ALIGNMENT, or should we get rid of that when we're using the new feature? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-10 11:17 --- (In reply to comment #4) Hello Dave, Hi Danny! 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. I have your patch in the cygwin distro compiler where it works fine, but I am concerned about what unforeseeable problems could arise by violating ODR in this way. I don't have any concrete evidence of any problem yet, it is just a worry. 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. Or I could follow up with another patch that propagates dllimport attributes from class to typeinfo. There is of course this: /* We leave typeinfo tables alone. We can't mark TI objects as dllimport, since the address of a secondary VTT may be needed for static initialization of a primary VTT. VTT's of dllimport'd classes should always be link-once COMDAT. */ /* Do not import tinfo nodes if the class has dllimport attribute. Dllimports do not have a constant address at compile time, so static initialization of tables with RTTI fields is a problem. Set to comdat instead. */ ... but I do not see why this should be a problem in these days of auto-import and pseudo-relocs; do you know more about what the actual problem is (or was) here? Is this not basically the same situation as something like dll_A.c int foo; int __attribute__ ((dllexport)) * bar = foo; dll_B.c extern int __attribute__ ((dllexport)) * bar; int __attribute__ ((dllexport)) * baz = bar; --- the example above? If it's possible to solve either in the compiler or further down the toolchain, I would very much like to do so. Also, how come emitting the typeinfo .linkonce as we currently do isn't the same as COMDAT for these purposes? cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-10 01:11 --- Created an attachment (id=17841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841action=view) 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo.
Precisely as subject. All other class members and related data (e.g. vtables, synthetic ctors) will be tagged dllexport if the class itself is dllexport, and -export comments will be added listing their symbols in the .drectve section. Typeinfo data alone will not receive the dllexport attribute, because it is not a class member. (Theoretically, I think it counts as a static class data member of type std::type_info, but internally) It is generated as a synthetic POD data type, and hence does not appear to the i386 backend as belonging to the class it represents. The description in bug 17300 suggests that there could be a problem further down the line with dllimporting such typeinfos, but right now they simply can't be referenced outside the enclosing DLL at all, i.e. clients of a DLL can't dynamically cast class pointers to the classes it implements, only routines within the DLL which have local linkage to the typeinfo. This is a separate problem, which I think can be resolved further down the toolchain using pseudo-relocs; I don't think it's a reason not to make export work. -- Summary: GCC fails to apply dllexport attribute to typeinfo. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-08 11:53 --- Created an attachment (id=17826) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17826action=view) Simple testcase It doesn't get much more trivial than this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-05-08 11:55 --- To reproduce the bug, compile the attached testcase g++-4 -fpreprocessed -S vti.ii and view the very end of the .s file emitted: .section .drectve .ascii -export:_ZTV12XMLException,data .ascii -export:_ZN12XMLExceptionD2Ev .ascii -export:_ZN12XMLExceptionD1Ev .ascii -export:_ZN12XMLExceptionD0Ev .ascii -export:_ZN12XMLExceptionC1Ev .ascii -export:_ZN12XMLExceptionC2Ev Everything gets exported except the typeinfo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug java/38374] constant pool references have wrong types in ADDR_EXPR
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-04-27 21:39 --- I just got this failure during bootstrap: libtool: compile: /gnu/gcc/obj3/gcc/gcj -B/gnu/gcc/obj3/i686-pc-cygwin/libjava/ -B/gnu/gcc/obj3/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=/gnu/gcc/gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fsource-filename=/gnu/gcc/obj3/i686-pc-cygwin/libjava/classpath/lib/classes -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list -o .libs/gnu-CORBA.o /gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java: In class 'gnu.CORBA.Poa.gnuPOA$RefTemplate': /gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java: In constructor '(gnu.CORBA.Poa.gnuPOA)': In file included from built-in:136: /gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java:0: error: type mismatch in indirect reference struct java.lang.String[] void # VUSE .MEM_11 #slot#8#31_225 = #ref#5#2_135-length; /gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java:0: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [gnu-CORBA.lo] Error 1 I'm going to try reverting r146831 locally and see if it helps. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38374
[Bug java/38374] constant pool references have wrong types in ADDR_EXPR
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-04-28 03:30 --- (In reply to comment #4) I just got this failure during bootstrap: I'm going to try reverting r146831 locally and see if it helps. Doing so allowed the build to complete. See also bug 39932. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38374
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-04-22 11:20 --- Hi Rob, I just ran into this on i686-pc-cygwin. I think the reason you see it on some builds and not others is because of the --enable-libgcj-debug option; presumably that makes the asserts disappear when disabled, equivalent to your commenting them out. However, it would be nice to keep the debug verification in there if possible. I'm testing a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-04-22 11:22 --- Created an attachment (id=17671) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17671action=view) Fix debug asserts. Adjust the assert to test the casted pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-04-22 11:24 --- That gets me about three files further through the build, then there's another failure: In file included from /gnu/gcc/gcc/libjava/gnu/classpath/natConfiguration.cc:17: /gnu/gcc/gcc/libjava/gnu/classpath/Configuration.h:32: error: expected unqualified-id before numeric constant make[3]: *** [gnu/classpath/natConfiguration.lo] Error 1 That line says: static jboolean DEBUG; so I guess DEBUG is probably a #define somewhere and it's turning into static jboolean 1; or something like that, I'll do some digging. Meantime, there's always the --disable workaround. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #8 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:34 ---
Yep. From the .ii file:
class gnu::classpath::Configuration : public ::java::lang::Object
{
Configuration();
static ::java::lang::String * classpath_home();
static jboolean debug();
static ::java::lang::String * toolkit();
static ::java::lang::String * ecj();
public:
static ::java::lang::String * CLASSPATH_HOME;
static ::java::lang::String * CLASSPATH_VERSION;
static jboolean 1;
static const jboolean INIT_LOAD_LIBRARY = 0;
static ::java::lang::String * default_awt_peer_toolkit;
static const jboolean JAVA_LANG_SYSTEM_EXPLICIT_INITIALIZATION = 0;
static ::java::lang::String * ECJ_JAR;
static const jboolean WANT_NATIVE_BIG_INTEGER = 1;
static ::java::lang::Class class$;
};
# 18 /gnu/gcc/gcc/libjava/gnu/classpath/natConfiguration.cc 2
Will look at whether we should not #define DEBUG in the first place, or more
likely it would be best to rename Configuration.DEBUG to something else
throughout (Configuration.JDEBUG sprints to mind).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-04-22 22:38 --- Created an attachment (id=17679) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17679action=view) Part two of fix This renames the DEBUG macro to __GCJ_DEBUG throughout. It fixed the build in my tree where I had a whole bunch of local patches, now testing it in a clean tree with the extraneous changes removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug target/39578] Linkage broken for dllimport vtables
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-03-29 17:47 --- For Cygwin, we just recently made --enable-auto-import the default in CVS binutils. Now that we're moving to shared library runtimes throughout it made sense. However, I think this is a real bug, as it doesn't happen on 4.3.2; we get a direct undefined reference to the import symbol in the object file: $ g++ -g -o vttest.exe vttest.cpp libvttest.dll.a --save-temps ad...@ubik /tmp/vttest $ nm vttest.o b .bss d .data N .debug_abbrev N .debug_aranges N .debug_frame N .debug_info N .debug_line N .debug_loc N .debug_pubnames N .debug_ranges N .debug_str d .eh_frame t .text t .text$_ZN10TestObjectC1Ev T __ZN10TestObjectC1Ev U ___gxx_personality_v0 U ___main U __imp___ZN10TestObject8VirtFuncEv U __imp___ZTV10TestObject T _main ad...@ubik /tmp/vttest $ My earlier build of 4.3.3 with the patch for PR36654 reverted does the same thing. However, as soon as I reapplied the patch and rebuilt cc1plus, I got this output: /tmp/vttest $ nm vttest.olibvtt b .bss d .data N .debug_abbrev N .debug_aranges N .debug_frame N .debug_info N .debug_line N .debug_loc N .debug_pubnames N .debug_ranges N .debug_str d .eh_frame t .text t .text$_ZN10TestObjectC1Ev T __ZN10TestObjectC1Ev U __ZTV10TestObject U ___gxx_personality_v0 U ___main U __imp___ZN10TestObject8VirtFuncEv T _main /tmp/vttest $ So I think that confirms it. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39578
[Bug target/36654] [4.2 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #12 from dave dot korn dot cygwin at gmail dot com 2009-03-25
08:03 ---
Hi all.
This patch caused g++.dg/ext/dllimport7.C to regress (in one subtest) between
4.3.2 and 4.3.3 on Cygwin, although it could be that the testcase is out of
date.
// { dg-do compile { target i?86-*-cygwin* i?86-*-mingw*} }
// Report errors on definition of dllimport'd static data member .
struct Baz
{
Baz(int a_ =0) : a(a_) {}
int a;
};
class __declspec(dllimport) Bar
{
public:
enum {one = 1};
static const int two = 2;
static const int three;
static const Baz null_baz;
};
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 }
int foo()
{
Bar foobar;
const int* baz = Bar::two;
int a = foobar.two;
int b = foobar.three;
int c = foobar.null_baz.a;
return (a + b + c + *baz);
}
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?
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
CC||dave dot korn dot cygwin at
||gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
[Bug target/38904] Shared libgcc DLL violates Cygwin platform conventions.
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-31 18:53 --- Bug fixed. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-26 09:48 --- http://gcc.gnu.org/ml/gcc/2009-01/msg00367.html Confirmed by OP. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug middle-end/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-26 09:58 --- Hi HP, (In reply to comment #5) Glancing at the assembly and simulator trace (no looking at rtl or tree dumps yet), the value of p (sp after the first alloca) is somehow lost and after the __builtin_longjmp we effectively strcmp (NULL, test) which FWIW, doesn't SEGV in the simulator, but nevertheless obviously doesn't match. At the longjmp-receiver, p is retrieved for the strcmp call as move.d [$sp+8],$r10, i.e. $r10 = *((char *) $sp + 8), but that's bogus as nothing was stored there; move.d $sp,$r10 (just copying the stack-pointer) would have been correct. Sounds like this could maybe be a dup of bug 38952, where the frame pointer is incorrectly calculated when setjmp saves it in the jmp_buf, and therefore restored to an incorrect value by longjmp. For a quick test without rebuilding your compiler, see if -mpreferred-stack-boundary=2 or -mno-stackrealign fixes the failure in built-in-setjmp.c; if so there's a patch in the PR that should help. cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38609
[Bug target/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above
--- Comment #8 from dave dot korn dot cygwin at gmail dot com 2009-01-26 18:49 --- Oh, bah, I misread the Host field for Target! Guess it probably won't be TARGET_BUILTIN_SETJMP_FRAME_VALUE then. You only need it if your stack frames have unpredicatable gaps in them so that you can't eliminate one reg against another that points the other side of the gap because the offset isn't known. Unless you've got those on CRIS, I've probably just been dangling a red herring under your nose, sorry! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38609
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #21 from dave dot korn dot cygwin at gmail dot com 2009-01-26 19:03 --- Hi Joey, thanks for helping look at this bug. If you catch up with all the comments, you'll see that it's not just Cygwin, SjLj was broken on Linux too; the mechanism works the same way on both, but only Cygwin uses it as the default EH mechanism, so it doesn't get as much testing! I'm fairly confident I've analyzed the problem correctly and that the patch I'm testing (attached, and submitted to gcc-patches at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01258.html) is the right solution to the problem, and my PC is running through all the regression tests now, so what would help most is if you could just look over my analysis and tell me if you think I've got the right understanding of your code and the loophole that caused the bug. cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-25 21:36 --- Created an attachment (id=17183) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183action=view) Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE. Now testing this patch which should fix setjmp calculations of the frame base pointer without affecting the way ordinary stack local variable slots are computed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #19 from dave dot korn dot cygwin at gmail dot com 2009-01-25 23:07 --- Created an attachment (id=17184) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17184action=view) Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE *correctly*. Dur. Corrected patch for return type thinko. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Attachment #17183|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-01-24 18:12 --- Thanks for the test results and confirmation, Uros. It looks like more or less exactly the same list of FAILs as I see on Cygwin, so I think this confirms a generic issue with frame pointer elimination in the i386 backend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-01-24 18:20 --- [ David B. CC'd in for clarification requested ] I'm under the impression that the bug is fixed now, so no objections from me. I'm not sure why David B. just confirmed it though, I meant Set the bug to the NEW state from UNCONFIRMED, which Danny did some time ago. David, do you mean that you are still able to produce the bug from SVN HEAD? -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added CC||billingd at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-01-24 23:15 --- (In reply to comment #16) Just ignore my post at comment #13 to update the status. Sorry for the noise. I should have read to the bottom of the PR before acting. That's ok, thanks for clearing it up. Jakub, please feel free to close this bug RESO FIXE anytime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-24 23:22 --- (In reply to comment #17) (In reply to comment #16) Just ignore my post at comment #13 to update the status. Sorry for the noise. I should have read to the bottom of the PR before acting. That's ok, thanks for clearing it up. Jakub, please feel free to close this bug RESO FIXE anytime. Or even better, James, are you still there? As reporter you should have the requisite permissions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-01-25 05:33 --- Thanks for your help HJ. I'll do some more debugging and add notes while you're away. Happy New Year! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #12 from dave dot korn dot cygwin at gmail dot com 2009-01-25 05:56 --- Created an attachment (id=17177) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17177action=view) Correct code compiled with -mpreferred-stack-boundary=2 Adding -mpreferred-stack-boundary=2 to the compile line generates a correct, functioning executable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #13 from dave dot korn dot cygwin at gmail dot com 2009-01-25 05:58 --- Created an attachment (id=17178) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17178action=view) Diffs between good and bad versions This shows a diff between the testcase compiled with -mpreferred-stack-boundary=2 and with -mpreferred-stack-boundary=4 (the default). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #14 from dave dot korn dot cygwin at gmail dot com 2009-01-25 06:05 --- Adding -mpreferred-stack-boundary=2 to the command line generates correct code. Here are the diffs between code generated by that setting and the default (-mpreferred-stack-boundary=4) for the start of the function: --- eh-sb2.s2009-01-25 05:24:46.71875 + +++ eh-sb4.s2009-01-25 05:26:19.18750 + @@ -10,19 +10,20 @@ _main: pushl %ebp movl%esp, %ebp + andl$-16, %esp pushl %edi pushl %esi pushl %ebx - subl$68, %esp - movl$___gxx_personality_sj0, -40(%ebp) - movl$LLSDA0, -36(%ebp) - leal-32(%ebp), %eax - leal-12(%ebp), %edx + subl$84, %esp + movl$___gxx_personality_sj0, 52(%esp) + movl$LLSDA0, 56(%esp) + leal60(%esp), %eax + leal80(%esp), %edx movl%edx, (%eax) movl$L5, %edx movl%edx, 4(%eax) movl%esp, 8(%eax) - leal-64(%ebp), %eax + leal28(%esp), %eax movl%eax, (%esp) call__Unwind_SjLj_Register So I think I'm starting to grok what's happening here. Because of the larger stack alignment required, and because the incoming stack alignment is only 8, not 16, we have to use an AND to mask and align the incoming esp. Now that means then that we have a hole of unknown size in our stack frame, just below the frame pointer at the top end. So because this gap is unkown, we can't index down from the frame pointer %ebp to the rest of the stack frame any more, which is why we have to turn the elimination basis upside down and calculate all the eliminations upward from esp instead. (The gap is in fact composed of two components. The dynamic adjustment needed to align the incoming stack, which cannot be known at compile time, and then the extra space allocated to the stack frame to ensure its size is a multiple of the alignment so that the lower end of the frame is also aligned. Although this second part is known at compile-time, as long as the first part is unpredictable we have to do the eliminations from the stack base, not frame pointer). This is all fine for most stack frame contents, but it goes wrong in exactly the same-but-opposite way if we're trying to access items of the stack frame *above* the gap - and that's what's happening in my test case, because we're trying to get the address of HARD_FRAME_POINTER, aka the value in $ebp, aka 4 or 8 bytes below the ARG_POINTER (compile-time known constant offset). So the one or two items above the gap - the frame pointer and the return pc value (Does this bug affect __builtin_return_address(0) as well, by any chance? I haven't checked) - would have to still be eliminated against HARD_FRAME_POINTER and denied elimination against STACK_POINTER in the case where there is going to be stack realignment in the prologue. And that is presumably the intention of this if clause in ix86_can_eliminate: if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == STACK_POINTER_REGNUM)); else [ ... ] I'll look at why it's not doing what it's supposed to. One possibility is that stack_realign_fp isn't becoming true until after the elimination has already taken place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-01-25 06:33 --- (In reply to comment #14) And that is presumably the intention of this if clause in ix86_can_eliminate: if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == STACK_POINTER_REGNUM)); else [ ... ] I just looked twice at that and it seemed odd to me. Testing this: if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM - to == STACK_POINTER_REGNUM)); + to == HARD_FRAME_POINTER_REGNUM)); gives me this: (gdb) disass main Dump of assembler code for function main: 0x00401070 main+0:push %ebp 0x00401071 main+1:mov%esp,%ebp 0x00401073 main+3:and$0xfff0,%esp 0x00401076 main+6:push %edi 0x00401077 main+7:push %esi 0x00401078 main+8:push %ebx 0x00401079 main+9:sub$0x54,%esp 0x0040107c main+12: movl $0x4075f0,-0x34(%ebp) 0x00401083 main+19: movl $0x407bc4,-0x30(%ebp) 0x0040108a main+26: lea-0x2c(%ebp),%eax 0x0040108d main+29: lea-0x18(%ebp),%edx 0x00401090 main+32: mov%edx,(%eax) 0x00401092 main+34: mov$0x4010e2,%edx 0x00401097 main+39: mov%edx,0x4(%eax) 0x0040109a main+42: mov%esp,0x8(%eax) 0x0040109d main+45: lea-0x4c(%ebp),%eax 0x004010a0 main+48: mov%eax,(%esp) 0x004010a3 main+51: call 0x405058 _Unwind_SjLj_Register Which works, but now I suspect the address calculations accessing the jmp_buf are going to be wrong. Argh. It looks like we have to know whether there's an offset in the mem rtx relating to FRAME_POINTER_REGNUM and if it's negative we have to allow elimination against STACK_POINTER but if its zero or positive we'd have to only allow elimination against HARD_FRAME_POINTER ... ouch. Guess the next thing I'll try is simply not allowing elimination against FRAME_POINTER at all in this context. That'll mean we can't -fomit-frame-pointer in functions which have stack_realign_fp true, but it beats wrong code and maybe there's a way of avoiding it that I haven't thought of. Now testing: if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM - to == STACK_POINTER_REGNUM)); + 0)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #16 from dave dot korn dot cygwin at gmail dot com 2009-01-25 06:40 --- ./eh.C: In function 'int main()': ./eh.C:11: internal compiler error: in print_reg, at config/i386/i386.c:10466 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. LOL, no, that didn't help. Will try again tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-01-25 07:47 --- And this is what I'll try: -- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE () This target hook should return an rtx that is used to store the address of the current frame into the built in `setjmp' buffer. The default value, `virtual_stack_vars_rtx', is correct for most machines. One reason you may need to define this target hook is if `hard_frame_pointer_rtx' is the appropriate value on your machine. (The first patch fixed all the failing eh testcases, but accessing the local variables downward through %ebp would mean they'd be misaligned, not starting down at the bottom of the frame, and differently aligned according to the dynamic component of the gap, so it would be bound to go wrong in situations involving vectors or other higher-alignment datatypes.) If I leave the can_eliminate test alone but define this target hook, I figure we should still get local vars indexed upward from $esp but will get the frame pointer indexed down from $ebp, or at least that's how I read the above. So hopefully a target hook that overrides the default return value with hard_frame_pointer_rtx if stack_realign_fp is true and otherwise returns virtual_stack_vars_rtx like the default might be what we're looking for. AFAICT it's not currently defined for i386. Need sleep nowzzZZZ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug testsuite/38949] New: Link failures in new stackalign tests
failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-5.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-5.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-5.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-5.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-5.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-5.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-5.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-5.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-5.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-5.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-5.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-5.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-6.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-6.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-6.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-6.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-6.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-6.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-6.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-6.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-6.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-6.C compilation failed to produce
executable
FAIL: g++.dg/torture/stackalign/unwind-6.C (test for excess errors)
WARNING: g++.dg/torture/stackalign/unwind-6.C compilation failed to produce
executable
These all appear to be caused by the same missing symbols:
compiler exited with status 1
output is:
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc5goajS.o:unwind-0.C:(.text+0xda):
undefined reference to `g_ebp_save'
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc5goajS.o:unwind-0.C:(.text+0xe0):
undefined reference to `g_esp_save'
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc5goajS.o:unwind-0.C:(.text+0x10e):
undefined reference to `g_edi'
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc5goajS.o:unwind-0.C:(.text+0x114):
undefined reference to `g_esi'
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc5goajS.o:unwind-0.C:(.text+0x11a):
undefined reference to `g_ebx'
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc5goajS.o:unwind-0.C:(.text+0x120):
undefined reference to `g_ebp'
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc5goajS.o:unwind-0.C:(.text+0x126):
undefined reference to `g_esp'
collect2: ld returned 1 exit status
The problem arises in gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h,
which declares a number of global variables like this:
int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
int g_ebp, g_ebp_save, g_esp, g_esp_save;
int n_error;
and then attempts to reference them in asms, not as input or output operands,
but directly by hard-coding like this:
__asm__ __volatile__ (
movl %ebp, g_ebp_save\n\t
movl %esp, g_esp_save\n\t
);
try {
foo();
}
catch (...)
{
}
// Get DI/SI/BX register value after exception caught
__asm__ __volatile__ (
movl %edi, g_edi\n\t
movl %esi, g_esi\n\t
movl %ebx, g_ebx\n\t
movl %ebp, g_ebp\n\t
movl %esp, g_esp\n\t
);
This works fine on Linux platforms but fails on platforms like Cygwin that
prefix an underscore to C-level symbols when creating the corresponding
assembly-level symbol.
--
Summary: Link failures in new stackalign tests
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38949
[Bug testsuite/38949] Link failures in new stackalign tests
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23 18:10 --- Created an attachment (id=17168) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17168action=view) Force assembler labels to match. Now testing this fairly straightforward approach to making the names match precisely regardless of platform's preference for an underscore prefix or no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38949
[Bug testsuite/38949] Link failures in new stackalign tests
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23 19:02 --- Right you are. Either one should work, but I don't have any more spare time than you for testing things on Linux right now. It's non-critical, so I'll keep a patch in my local tree and maybe we should set the target milestone to 4.5.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38949
[Bug target/38952] New: [4.4 Regression] EH does not work.
SjLj EH (the default) is completely broken on Cygwin (and MinGW, confirmed by Danny in private email). The failures have been occurring since at least November: see, e.g. http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02144.html (The distro maintainers have all been so focussed recently on getting DW2 EH to work on our platforms that this flew in under our radar; sorry for not noticing sooner). A simple test case and some complicated low-level analysis will follow in comments and attachments. So far it looks like an error in frame pointer elimination caused by a miscalculation of the initial frame pointer offset. I have filed this as a target problem since elimination is driven by the backend but it could just as well be a bug in rtl-optimisation; we'll know more soon. cheers, DaveK -- Summary: [4.4 Regression] EH does not work. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:31 --- Created an attachment (id=17169) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17169action=view) Simple throw-catch testcase Test cases don't come much simpler than this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:31 --- Created an attachment (id=17170) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17170action=view) Pre-processed source of testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:32 --- Created an attachment (id=17171) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17171action=view) Generated assembler for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:44 --- The bug manifests itself as a crash on exit from main(); $eip is set to zero and we get a SEGV. On entry to main(), the registers show: esp0x22cc40 0x22cc40 ebp0x22cca8 0x22cca8 Just before the epilogue at the end of main, we see: esp0x22cc40 0x22cc40 ebp0x22cc90 0x22cc90 (gdb) x/32xw 0x22cc40 0x22cc40: 0x0022cc5c 0x0040e7e0 0x 0x004f0584 0x22cc50: 0x005005c2 0x32200060 0x0022cc78 0x 0x22cc60: 0x 0x100325b8 0x0001 0x61010173 0x22cc70: 0x0001 0x00407600 0x00407bd4 0x0022cc90 0x22cc80: 0x004010ec 0x0022cc40 0x 0x610df2c7 0x22cc90: 0x100324fa 0x 0x611021a0 0x0040546c 0x22cca0: 0x611021a0 0x0040546c 0x0022cd98 0x610060e8 0x22ccb0: 0x0001 0x100324a0 0x10030090 0x6003 (gdb) and so when we come to the ret instruction, ... (gdb) Breakpoint 2, 0x00401125 in main () at ./eh.C:11 11 } (gdb) info reg eax0x0 0 ecx0x22cb30 2280240 edx0x0 0 ebx0x0 0 esp0x22cc94 0x22cc94 ebp0x100324fa 0x100324fa esi0x611021a0 1628447136 edi0x40546c 4215916 eip0x401125 0x401125 main+181 eflags 0x202[ IF ] cs 0x1b 27 ss 0x23 35 ds 0x23 35 es 0x23 35 fs 0x38 56 gs 0x0 0 (gdb) stepi 0x in ?? () Next comment will analyze how $ebp comes to have the wrong value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-01-24
00:10 ---
Here is a disassembly of the start of the main function:
(gdb) disass main
Dump of assembler code for function main:
0x00401070 main+0:push %ebp
0x00401071 main+1:mov%esp,%ebp
0x00401073 main+3:and$0xfff0,%esp
0x00401076 main+6:sub$0x60,%esp
0x00401079 main+9:mov%ebx,0x54(%esp)
0x0040107d main+13: mov%esi,0x58(%esp)
0x00401081 main+17: mov%edi,0x5c(%esp)
0x00401085 main+21: movl $0x407600,0x34(%esp)
0x0040108d main+29: movl $0x407bd4,0x38(%esp)
0x00401095 main+37: lea0x3c(%esp),%eax
0x00401099 main+41: lea0x50(%esp),%edx
0x0040109d main+45: mov%edx,(%eax)
0x0040109f main+47: movl $0x4010ec,0x4(%eax)
0x004010a6 main+54: mov%esp,0x8(%eax)
0x004010a9 main+57: lea0x1c(%esp),%eax
0x004010ad main+61: mov%eax,(%esp)
0x004010b0 main+64: call 0x405068 _Unwind_SjLj_Register
0x004010b5 main+69: call 0x40515c __main
0x004010ba main+74: movl $0x4,(%esp)
0x004010c1 main+81: call 0x406b00 __cxa_allocate_exception
0x004010c6 main+86: movl $0x1,(%eax)
0x004010cc main+92: movl $0x0,0x8(%esp)
0x004010d4 main+100: movl $0x40e7e0,0x4(%esp)
0x004010dc main+108: mov%eax,(%esp)
0x004010df main+111: movl $0x1,0x20(%esp)
0x004010e7 main+119: call 0x4075a0 __cxa_throw
0x004010ec main+124: mov0x24(%esp),%eax
0x004010f0 main+128: mov%eax,(%esp)
0x004010f3 main+131: call 0x406da0 __cxa_begin_catch
If we set a breakpoint on every function call, and run through it:
(gdb) r
Starting program: /win/i/FSF-Gcc/obj-sjlj/gcc/testsuite/g++/eh.exe
[New thread 648.0x754]
[New thread 648.0x31c]
Breakpoint 1, main () at ./eh.C:4
4 {
(gdb) print $esp
$2 = (void *) 0x22ccac
(gdb) c
Continuing.
Breakpoint 3, 0x004010b0 in main () at ./eh.C:4
4 {
(gdb) print $esp
$3 = (void *) 0x22cc40
(gdb) print $ebp
$14 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 4, main () at ./eh.C:4
4 {
(gdb) print $ebp
$4 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 5, 0x004010c1 in main () at ./eh.C:6
6 throw 1;
(gdb) print $ebp
$5 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 6, 0x004010e7 in main () at ./eh.C:6
6 throw 1;
(gdb) print $ebp
$6 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 10, _Unwind_SjLj_RaiseException (exc=0x100325b8)
at /gnu/gcc/gcc/libgcc/../gcc/unwind-sjlj.c:148
148 if (use_fc_key 0)
Current language: auto; currently c
(gdb) print $ebp
$7 = (void *) 0x22cc18
(gdb) c
Continuing.
Breakpoint 7, 0x004010f3 in main () at ./eh.C:8
8 catch (...) {
Current language: auto; currently c++
(gdb) print $ebp
$8 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 8, 0x00401100 in main () at ./eh.C:8
8 catch (...) {
(gdb) print $ebp
$9 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 9, 0x0040110c in main () at ./eh.C:8
8 catch (...) {
(gdb) print $ebp
$10 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 11, 0x00401122 in main () at ./eh.C:11
11 }
(gdb) print $ebp
$11 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 2, 0x00401125 in main () at ./eh.C:11
11 }
(gdb) print $ebp
$12 = (void *) 0x100324fa
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb)
... we can see that $ebp is correct right up until the call to __cxa_throw at
0x004010e7, but when we return to the catch landing site at 0x004010f3, $ebp is
incorrect.
This incorrect value is calculated in the code at the start of main(), where
the code generated by sjlj_emit_function_enter calls
expand_builtin_setjmp_setup to initialise the jbuf[] member of the struct
SjLj_Function_Context that it then passes to _Unwind_SjLj_Register. From that
call:
0x004010a9 main+57: lea0x1c(%esp),%eax
0x004010ad main+61: mov%eax,(%esp)
0x004010b0 main+64: call 0x405068 _Unwind_SjLj_Register
the struct is at an offset of 0x1c on the stack. Looking at the memory dump,
just before the call:
0x22cc40: 0x0022cc5c 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd
0x22cc50: 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd
0x22cc60: 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd
0x22cc70: 0xbdbdbdbd 0x00407600 0x00407bd4 0x0022cc90
0x22cc80: 0x004010ec 0x0022cc40 0xbdbdbdbd 0xbdbdbdbd
0x22cc90: 0xbdbdbdbd 0x 0x611021a0 0x0040546c
0x22cca0: 0xbdbdbdbd 0xbdbdbdbd 0x0022cd98 0x610060e8
0x22ccb0: 0x0001 0x100324a0 0x10030090 0x6003
.. shows that the struct has been initialised like so:
OFFS:0x001c: prev = 0xbdbdbdbd, call_Site 0xbdbdbdbd
OFFS:0x0024: data[4] = { 0xbdbdbdbd, 0xbdbdbdbd, 0xbdbdbdbd, 0xbdbdbdbd }
OFFS:0x0034: personality = 0x00407600 = __gxx_personality_sj0
OFFS:0x0038: lsda = 0x00407bd4 = __DTOR_LIST__+16:0x010d00ff
OFFS
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-24
01:08 ---
Here is the RTL that is created by the .130r.eh pass: everything between note 2
and call_insn 3, was added after expand.
try_optimize_cfg iteration 2
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 46 2 NOTE_INSN_FUNCTION_BEG)
(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -28 [0xffe4])) [0 S4 A32])
(symbol_ref:SI (__gxx_personality_sj0) [flags 0x43])) -1 (nil))
(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -24 [0xffe8])) [0 S4 A32])
(symbol_ref:SI (*LLSDA0) [flags 0x2])) -1 (nil))
(insn 48 47 49 2 (parallel [
(set (reg:SI 63)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -20 [0xffec])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 54 virtual-stack-vars)) -1 (nil))
(insn 50 49 51 2 (set (reg/f:SI 64)
(label_ref:SI 56)) -1 (insn_list:REG_LABEL_OPERAND 56 (nil)))
(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 4 [0x4])) [0 S4 A8])
(reg/f:SI 64)) -1 (nil))
(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 8 [0x8])) [0 S4 A8])
(reg/f:SI 7 sp)) -1 (nil))
(insn 53 52 54 2 (parallel [
(set (reg:SI 65)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -52 [0xffcc])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 54 53 55 2 (set (mem:SI (reg/f:SI 56 virtual-outgoing-args) [0 S4 A32])
(reg:SI 65)) -1 (nil))
(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI (_Unwind_SjLj_Register)
[flags 0x43]) [0 S1 A8])
(const_int 16 [0x10])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
(call_insn 3 55 6 2 ./eh.C:4 (call (mem:QI (symbol_ref:SI (__main) [flags
0x43]) [0 S1 A8])
(const_int 0 [0x0])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
Pass 133r.vregs turns this into:
(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -28 [0xffe4])) [0 S4 A32])
(symbol_ref:SI (__gxx_personality_sj0) [flags 0x43])) 41 {*movsi_1}
(nil))
(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -24 [0xffe8])) [0 S4 A32])
(symbol_ref:SI (*LLSDA0) [flags 0x2])) 41 {*movsi_1} (nil))
(insn 48 47 49 2 (parallel [
(set (reg:SI 63)
(plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffec])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (nil))
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
(insn 50 49 51 2 (set (reg/f:SI 64)
(label_ref:SI 56)) 41 {*movsi_1} (insn_list:REG_LABEL_OPERAND 56
(nil)))
(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 4 [0x4])) [0 S4 A8])
(reg/f:SI 64)) 41 {*movsi_1} (nil))
(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 8 [0x8])) [0 S4 A8])
(reg/f:SI 7 sp)) 41 {*movsi_1} (nil))
(insn 53 52 54 2 (parallel [
(set (reg:SI 65)
(plus:SI (reg/f:SI 20 frame)
(const_int -52 [0xffcc])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (nil))
(insn 54 53 55 2 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg:SI 65)) 41 {*movsi_1} (nil))
(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI (_Unwind_SjLj_Register)
[flags 0x43]) [0 S1 A8])
(const_int 16 [0x10])) 466 {*call_0} (expr_list:REG_EH_REGION
(const_int 0 [0x0])
(nil))
(nil))
Note that insn 49 is the crucial one here that stores the (later miscalculated)
value of the frame pointer (i.e., $ebp - before elimination) into the jmp_buf.
At pass 174r.ira, this becomes:
(insn 48 47 73 2 (parallel [
(set (reg/f:SI 0 ax [63])
(plus:SI (reg/f:SI 7 sp)
(const_int 60 [0x3c])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (expr_list:REG_EQUIV (plus:SI (reg/f:SI 7 sp)
(const_int 60 [0x3c]))
(nil)))
(insn 73 48 49 2 (set (reg:SI 1 dx)
(plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))) 209 {*lea_1} (nil))
(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
And this is the point at which the incorrect offset first appears.
Ouch. I hope this isn't an IRA bug, I know nothing about that. Is it valid to
do frame pointer elimination before reload like that? Because the other
possibility is that the x86 backend is suddenly growing the frame size during
some later pass. (Well, I guess we
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-24
06:23 ---
Not IRA-related, it seems, but reload-backend interaction. -fno-ira doesn't
make any difference to the generated code to calculate the frame pointer for
the jmp_buf. In a non-IRA build, pass 172r.lreg has:
(insn 49 48 51 2 (set (mem:SI (reg/f:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
and pass 173r.greg has
(insn 73 48 49 2 (set (reg:SI 1 dx)
(plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))) 209 {*lea_1} (nil))
(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
and here we can see that it's reload doing the FP elimination:
Reloads for insn # 49
Reload 0: reload_out (SI) = (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))
reload_reg_rtx: (reg:SI 1 dx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38904] Shared libgcc DLL violates Cygwin platform conventions.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-22 16:42 --- Created an attachment (id=17163) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17163action=view) Fix shared libgcc naming scheme. Patch now in testing, fixes DLL naming scheme for both Cygwin and MinGW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-01-20 04:32 --- Created an attachment (id=17151) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17151action=view) Fill out missing syms from shared libgcc using static libgcc archive. (In reply to comment #10) (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 This patch works for Cygwin. :-) Thanks for testing that. I'm actually going to submit /this/ patch for inclusion in mainline, once it's finished bootstrapping and testing; Danny is right that this is just the simplest way to go. cheers, DaveK -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Attachment #17132|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-18 21:40 --- Fixed on HEAD by r.143487; sorry, forgot to put the PR/ reference in the SVN logfile. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-01-19 04:54 --- (In reply to comment #8) (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. I just realised that I forgot --enable-threads when I configured, I'd presumably need to do the same. 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) Ah, but nothing will be pulled in from it. However, on further thought, and specifically considering that there's no pic/non-pic difference on windows, meaning that %.o and %_s.o are completely identical, I guess I'm not worried about filling in from the static library any more. I'll roll up a new patch. cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/38862] Bootstrap failure on HEAD with static linking vs. graphite
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-18 00:17 --- This is now fixed. Will file a separate PR later for -lstdc++ problems. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38862
[Bug bootstrap/38903] New: Bootstrap failure on Cygwin vs. libiberty.
[refs: http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00060 http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00216 ] Bootstrap on cygwin is currently failing during stage 3 with: /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \ else true; fi /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for 'strsignal' /usr/include/string.h:78: note: previous declaration of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]: Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2 This happens because libiberty configure has a hard-coded hack that kicks in when building libiberty as a target library, which causes strsignal (and a couple of others) to be removed from the list of functions for configure to check against the system libraries, causing the libiberty versions to be built when they aren't needed. (They used to be required; formerly, Cygwin pulled in the object files from libiberty when linking the DLL, but this was fixed some time ago and the hack has been obsolete since then). I am testing a patch to remove the hack. -- Summary: Bootstrap failure on Cygwin vs. libiberty. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18 00:31 --- Created an attachment (id=17131) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17131action=view) Remove troublesome clause from libiberty configure Now testing vs. both src/ and gcc/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug target/38904] New: Shared libgcc DLL violates Cygwin platform conventions.
The shared libgcc DLL currently built for cygwin is named libgcc_s_1.dll, and it comes with an import library named libgcc_s.a. These both violate the Cygwin platform naming conventions. All DLLs are prefixed with 'cyg' rather than 'lib' on the Cygwin target, and the corresponding import library should be prefixed with 'lib' and use a '.dll.a' extension. Although this is a problem in a new feature, rather than a regression, I will appeal for special consideration (as a target-specific change) to apply a patch (that I will post shortly) for this issue during stage 4, so that it can be in the released GCC 4.4 series, avoiding an ABI break between 4.4 and 4.5 on the Cygwin platform. -- Summary: Shared libgcc DLL violates Cygwin platform conventions. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug target/38904] Shared libgcc DLL violates Cygwin platform conventions.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18 00:41 --- Oh, I forgot to mention a further non-standardness about the DLL's name: on the Cygwin platform, the shared library version number should be separated from the name by a hyphen, not an underscore. So for Cygwin, the DLL should be named cyggcc_s-1.dll and the import library libgcc_s.dll.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-18 05:57 --- Created an attachment (id=17132) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132action=view) 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? I'm currently testing a full bootstrap using this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16 13:41 --- (In reply to comment #5) 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]. Sorry Danny, I don't understand. I think what you're saying is that shared linking: libgcc_s.dll.a + libgcc.a supplies the same overall set of symbols as static linking: libgcc_eh.a + libgcc.a since if libgcc.a only contains stuff that is not exported from the DLL, then -static-libgcc would fail - unless everything that is exported from the DLL is available statically in libgcc_eh.a, which implies that the DLL could only export the libgcc_eh functions? I must have a misunderstanding somewhere. Also, I have been unable to verify your explanation. In my current build directory: /gnu/gcc/obj-ng-fix $ nm prev-i686-pc-cygwin/libgcc/libgcc.a | grep T | cu t -d' ' -f3 static-lib.txt /gnu/gcc/obj-ng-fix $ nm prev-i686-pc-cygwin/libgcc/shlib/libgcc_s.dll.a | gre p T | cut -d' ' -f3 import-lib.txt /gnu/gcc/obj-ng-fix $ cat static-lib.txt import-lib.txt | sort | uniq -d | wc 60 60 713 /gnu/gcc/obj-ng-fix $ cat static-lib.txt import-lib.txt | sort | uniq -u | wc 37 37 812 /gnu/gcc/obj-ng-fix $ there are 60 common functions and 37 unique ones - the unique ones are indeed the contents of libgcc_eh, plus these: ___chkstk ___eprintf ___gcc_bcmp ___gnat_default_lock ___gnat_default_unlock ___gnat_install_locks ___gthread_active_p ___gthread_mutex_lock ___gthread_mutex_unlock ___udiv_w_sdiv __alloca which are only in the static libs at all. Should I have understood you to mean that only the API-stable symbols are not duplicated? Or only the EH-related symbols? cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16 13:43 --- This bug is fixed and should be closed now. A new PR, bug 37660, has been created for the separate issue in comment 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-15 19:08 --- 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. (We want -shared-libgcc as the default, for greater unixness). In a way, there's an impedance mismatch in the libgcc build system; you can add new functions per-target to the static library, by listing them in the target makefile fragment, but there's no similar target fragment to let you define extra exports in the libgcc mapfile/version script. I'm going to prepare a patch that revises shared libgcc building. I'll put it in the cygwin-specific fragment as an override of the defaults from the shared fragment, and it's probably going to do more than just fix chkstk/ctors, so it won't be suitable for mingw, but the mingw team might or might not want to consider doing the same. BTW someone who has admin powers should set confirm this bug, it's definitely real! :) cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug bootstrap/38862] Bootstrap failure on HEAD with static linking vs. graphite
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-15 21:18 --- Created an attachment (id=17109) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17109action=view) Order BACKENDLIBS by dependencies. I'd consider this fix obvious. Verified that it resolves the link issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38862
[Bug bootstrap/38862] New: Bootstrap failure on HEAD with static linking vs. graphite
[ ref: http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00179, full details of configuration etc. ] In gcc/Makefile.in, the current definition of BACKENDLIBS says: BACKENDLIBS = $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) This is incorrect WRT dependency order. Cloog and PPL depend on GMP/MPFR, and so should be listed before it. This doesn't cause a problem for shared linking, as it just leaves undefined references to be resolved at runtime, but it is fatal for static linking, causing many fatal errors: -snip- ranlib libbackend.a gcc-4 -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy.exe c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o cygwin2.o msformat-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib -lmpfr -lgmp -L/opt/gcc-tools/lib -lcloog -L/opt/gcc-tools/lib -lppl_c -lppl -lgmpxx /opt/gcc-tools/lib/libcloog.a(domain.o): In function `debug_value': /gnu/gcc/prereq/cloog/source/ppl/domain.c:3579: multiple definition of `_debug_value' libbackend.a(graphite.o):/gnu/gcc/gcc/gcc/graphite.c:68: first defined here /opt/gcc-tools/lib/libcloog.a(clast.o): In function `insert_modulo_guard': /gnu/gcc/prereq/cloog/source/ppl/clast.c:1043: undefined reference to `__impgmpz_fdiv_r' /gnu/gcc/prereq/cloog/source/ppl/clast.c:1107: undefined reference to `__impgmpz_fdiv_r' /opt/gcc-tools/lib/libcloog.a(domain.o):domain.c:(.text+0x6d0c): undefined reference to `__impgmpz_fdiv_r' /opt/gcc-tools/lib/libcloog.a(matrix.o): In function `cloog_matrix_read': /gnu/gcc/prereq/cloog/source/ppl/matrix.c:267: undefined reference to `__impgmpz_set_str' -snip- and many many more. This can be fixed by a trivial patch which I will post as an attachment. cheers, DaveK -- Summary: Bootstrap failure on HEAD with static linking vs. graphite Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38862
[Bug middle-end/38299] internal error: segmentation fault
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-06 15:27 --- I'm not so sure (that it's cygwin specific). http://www.google.co.uk/search?q=locale_facets.tcc++internal++error:+Segmentation+faulthl=enclient=firefox-arls=org.mozilla:en-US:officialfilter=0 seems to show it as a chronic intermittent problem in early 3.x series, on a variety of platforms. Still, it could be that changes in the cygwin compiler hid/masked the problem in different revisions. These are all pretty old and obsolete versions I'm afraid and the problem isn't likely to get fixed now if it hasn't been so far. It might be worth futzing with the build flags and seeing if you can get it working with different -O options. cheers, DaveK -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38299
