[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-11-16 09:03 --- This problem exists also for x86_64 based mingw. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-11-23 20:41 --- Patch for this problem Index: calls.c === --- calls.c (revision 142122) +++ calls.c (working copy) @@ -2077,7 +2077,7 @@ } #ifdef REG_PARM_STACK_SPACE - reg_parm_stack_space = REG_PARM_STACK_SPACE (fndecl); + reg_parm_stack_space = REG_PARM_STACK_SPACE (!fndecl ? fntype : fndecl); #endif if (! OUTGOING_REG_PARM_STACK_SPACE ((!fndecl ? NULL_TREE : TREE_TYPE (fndecl))) Index: config/i386/i386.c === --- config/i386/i386.c (revision 142122) +++ config/i386/i386.c (working copy) @@ -4547,9 +4547,11 @@ /* For libcalls it is possible that there is no fndecl at hand. Therefore assume for this case the default abi of the target. */ if (!fndecl) -call_abi = DEFAULT_ABI; +call_abi = (cfun ? cfun->machine->call_abi : DEFAULT_ABI); + else if (TREE_CODE (fndecl) == FUNCTION_DECL) +call_abi = ix86_function_abi (fndecl); else -call_abi = ix86_function_abi (fndecl); +call_abi = ix86_function_type_abi (fndecl); if (call_abi == 1) return 32; return 0; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #5 from ktietz at gcc dot gnu dot org 2008-11-25 10:22 --- Created an attachment (id=16766) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16766&action=view) improved patch file this fixes the callabi issues from sysv_abi->ms_abi. As Lankhorst told me, that there seems to be still problems in sysv_abi environment to call sysv_abi out of a ms_abi. Most of those problems are related to the problem, that get_callee_fn (in tree.c) isn't able to detect calls via pointer variables (VAR_DECL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-11-26 10:28 --- Fix on trunk at revision 142215. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug target/38366] gcc doesn't call functions that are struct arguments correctly
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-12-02 11:37 --- Created an attachment (id=16809) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16809&action=view) Patch file I can reproduce it and the patch here should solve it. The main reason is in i386 target ix86_reg_parm_stack_space(), which defaults for NULL_TREE fndecl to cfun, which is wrong in this context. Additionally init_cumulative_args() should verify first the fndecl and just when not present the fntype. In middle-end there is compute_argument_addresses() (calls.c), which needs as fallback the fntype passed for proper call of aggregate_value_p(). The part in function.c could be superflous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38366
[Bug target/38366] gcc doesn't call functions that are struct arguments correctly
--- Comment #4 from ktietz at gcc dot gnu dot org 2008-12-02 11:51 --- (In reply to comment #2) > This seems to work for me with r141893 which means this broke recently. The subject is that here a ms_abi function is calling via a variable an sysv_abi function on linux64. This problem happens just on linux and not on w64. I tested the testcase. What happens is that the seventh argument is stored on wrong stack position (the w64 reserved stack area is added here). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38366
[Bug target/38294] Enable multilib support for mingw
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-12-08 20:16 --- >From my point of view this patch seems to be ok. Multilib is just enabled for 64-bit default target, what makes sende at the moment. Just about the point of multilib library specifier, I am not sure. Shouldn't it separated by comman. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-08 20:16:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug target/38294] Enable multilib support for mingw
--- Comment #5 from ktietz at gcc dot gnu dot org 2008-12-13 21:46 --- 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? -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug target/38294] Enable multilib support for mingw
--- Comment #10 from ktietz at gcc dot gnu dot org 2008-12-14 07:50 --- (In reply to comment #9) > (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. Yes, this bug is reasoned by preparations to support multilib in w64 crt. Now we generate the target specific object files for 64-bit into the 'lib64' folder. This reasoned the problem we talking about. In the past we put our object (and library) files into /lib folder, which has hidden the problem. But for me it is ok to fix this for 4.5 (beside we need to work-a-round this for version before 4.5). > (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 Yes, just make out of this '#define STANDARD_INCLUDE_DIR "/mingw/include"' Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug target/38366] gcc doesn't call functions that are struct arguments correctly
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-01-08 09:22 --- By the last patches Honza and I did, this bug is fixed. See http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00520.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38366
[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-01-09 09:55 --- (In reply to comment #4) > Created an attachment (id=17052) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17052&action=view) [edit] > 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 Ok, I agree that the error message shouldn't be here a big problem. Your patch works for mingw-w64, so I have no objections. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #20 from ktietz at gcc dot gnu dot org 2009-01-29 12:21 --- (In reply to comment #19) > Anyone else could test it, please? I am currently on to test it for w64. We noticed a regression reasoned by this for this target, too (sadly we found it pretty late). This patch seems fine, but I guess that in ix86_expand_epilogue also the checks for frame.nregs should be altered to (frame.nregs + frame.nsseregs), too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #21 from ktietz at gcc dot gnu dot org 2009-01-29 12:27 --- Created an attachment (id=17210) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17210&action=view) Alternative patch suggested This is the patch I test at the moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #22 from ktietz at gcc dot gnu dot org 2009-01-29 12:52 --- (In reply to comment #21) > Created an attachment (id=17210) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17210&action=view) [edit] > Alternative patch suggested > This is the patch I test at the moment. The patch I posted works for w64 without any regressions. For linux64 it needs to be tested, too. I have here at work no linux64 box. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #24 from ktietz at gcc dot gnu dot org 2009-01-29 13:45 --- (In reply to comment #23) > I don't see why ix86_expand_epilogue should be changed. Do you have some > testcase which shows where your change improves generated code? > I can certainly test on Linux, but as frame.nsseregs is always 0 there, it > should make zilch difference. It is the same testcase for w64. Just the option -fno-omit-frame-pointer has to be added. This leads on w64 to an ICE (internal abort) without this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #26 from ktietz at gcc dot gnu dot org 2009-01-29 14:04 --- (In reply to comment #25) > Can't reproduce that with a cross compiler. You are right, I changed something else, too. Sorry. But this patch to expand_epilogue is proper IIUC Comment tells "If we're only restoring one register and sp is not valid then using a move instruction to restore the register since it's less work than reloading sp and popping the register." ... for w64 the can be more then one register in use but the check in the if doesn't verify this, and produces therefore slower code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #28 from ktietz at gcc dot gnu dot org 2009-01-30 08:54 --- (In reply to comment #19) > Anyone else could test it, please? ok, I tested it for linux64 and and for w64 without any new problems. I applied the patch (see rev. #143780). Just the testcase is missing. Do you apply it and set then the bug as fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #24 from ktietz at gcc dot gnu dot org 2009-01-31 17:21 --- (In reply to comment #21) > 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 tested it for w64, too. And it solved most EH/SjLj issue we had for this target. Btw w64 has it as default mechanism, too. The regression runs are complete and shown no new bug. So for me this patch is ok. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug c++/22007] New testsuite failure on Tru64 UNIX V4.0F: g++.dg/eh/cleanup1.C
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-01-31 18:56 --- This case fails for the target x86_64-pc-mingw32 for the same reason. It seems to be a recursion issue in gimplifier. On w64 it produces a stack overflow with a call deepth of about #16600 frames. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-31 18:56:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22007
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-06-08 07:51 --- Hi, to define UNICODE is absolutely correct. The define _UNICODE is fiction (but I agree it is in use). We can discuss about to define _UNICODE, too. But the UNICODE defines is for the w64 runtime the proper thing to define here. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-06-08 08:31 --- Ok, it is no fiction, but a issue for tchar.h in CRT headers. See http://blogs.msdn.com/oldnewthing/archive/2004/02/12/71851.aspx so, we define UNICODE for PSDK, but _UNICODE is user defined AFAIU. But possibly we could add the _UNICODE define for CRT's sake, too. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-06-08 09:09 --- As further research has shown, is the definition of _UNICODE a thing the user has to take care. The _UNICODE define is used in tchar.h and documentation for this can be found on msdn. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-09 06:52 ---
(In reply to comment #4)
> Subject: Re: GCC defines UNICODE instead of _UNICODE
> for -municode
>
> UNICODE is in the user's namespace; it should not be predefined if
> flag_iso (if you have to use specs rather than hooks, you need
> %{!ansi:%{!std=i*:%{!std=c*:-DUNICODE}}} to detect the various conformance
> options). We should not add to the instances of bug 545 that are still
> present. If the MinGW headers use a macro in the user's namespace as a
> feature test macro of some sort, they are buggy and should be fixed (with
> fixincludes if necessary for existing installations).
>
It is right that _UNICODE and UNICODE are in user name space defined and are
controlling which API (wide/or ascii) has to be used.
UNICODE is used in windows headers itself (see msdn for documentation).
_UNICODE is used in CRT (and inspecial in tchar.h header) only. (This is also
documented in msdn).
I agree, that these two different macro names are a bit annoying, but for sure
they are platform specific stuff and are for sure absolutely unrelated to ISO.
Therefore to introduce a relationship to ISO defines is contradictive and
wrong. Those macros are controling behaviour of runtime. By the windows
specific switch -municode the windows runtime is controlled.
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug other/35151] Combine mingw names
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-14 10:56 --- (In reply to comment #3) > Subject: Bug 35151 > > Author: nickc > Date: Fri Apr 4 11:16:10 2008 > New Revision: 133892 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133892 > Log: > PR other/35151 > * configure.ac: Combine rules for mingw32 and mingw64. > * configure: Regenerate. > > Modified: > trunk/ChangeLog > trunk/configure > trunk/configure.ac > Was fixed. Therefore close it -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35151
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-24 10:11 --- This bug is fixed within ld (by using pseudo-relocation) and within startup code. For new runtimes this bug is fixed also for 32-bit mingw. There is no limit about const variables exported without dllimport anymore present for mingw targets -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-06-24 10:17 --- Does this issue appears also, when using builtin alloca version? As I noticed does the switch -fno-builtin shows explict broken _alloca for x64. The call-save area isn't adjusted and compiler seems not to take care here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #25 from ktietz at gcc dot gnu dot org 2009-06-24 10:28 --- This bug was fixed for 4.4 version. The real issue here was the changes happend to ira and specifying one register via the constrains "=a" or "+a". Both variant don't work anymore. By expanding the stack_allocator methods (for 32-bit and 64-bit) by one input and one output contrain, it solves the issue. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug target/37120] g++ failed to compile code "dVolume *= 1 + pow(10.0, -5.0);"
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-06-24 11:57 --- I tried to reproduce this with 4.4 and 4.5 and it seems to work for me. Do you still have this issue? Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37120
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
--- Comment #12 from ktietz at gcc dot gnu dot org 2009-06-24 12:05 --- As I read this. Would it make sense to use for x86-mingw the callabi feature (as we do for the x64 variant)? This would be useful for 32-bit based multilib version, too (but this is more a side-note for this). Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-06-27 16:05 --- I noticed for version 4.4 (x86_64-*-mingw* and i686-*-mingw*) this issue still exist. On 4.5 branch it is fixed. I would like that it the patch is getting applied on the 4.4.1 branch, too. It fixed a crash in emutls_destroy, we get for 4.4 branch. Any chance? Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-27 17:50 --- Subject: Bug 40024 Author: ktietz Date: Sat Jun 27 17:50:20 2009 New Revision: 149015 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149015 Log: 2009-06-27 Kai Tietz Merged from trunk rev/148061 2009-06-01 Jakub Jelinek PR other/40024 * emutls.c (__emutls_get_address): Change arr->size to mean number of allocated arr->data entries instead of # of slots + 1. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/emutls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-06-27 17:52 --- Subject: Bug 40024 Author: ktietz Date: Sat Jun 27 17:52:29 2009 New Revision: 149016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149016 Log: 2009-06-27 Kai Tietz Merged from trunk rev/148061 2009-06-01 Jakub Jelinek PR other/40024 * emutls.c (__emutls_get_address): Change arr->size to mean number of allocated arr->data entries instead of # of slots + 1. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/emutls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-06-27 17:56 --- I did regression test for 4.3 and 4.4 branches and it was successful. I committed the patch for PR other/40024 to both branches. Committed revision 149015 for 4.3 branch and committed revision 149016 for 4.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-06-29 11:54 --- Well, I see. A redefinition issue. Does the following patch fixes your issue? Index: gcc/gcc/ada/adaint.h === --- gcc.orig/gcc/ada/adaint.h 2009-06-22 15:57:24.0 +0200 +++ gcc/gcc/ada/adaint.h2009-06-29 13:52:18.896879700 +0200 @@ -48,6 +48,12 @@ large files. For now we just list the platforms we have manually tested. */ +#undef FOPEN +#undef STAT +#undef FSTAT +#undef LSTAT +#undef STRUCT_STAT + #if defined (__GLIBC__) || defined (sun) || defined (__sgi) #define FOPEN fopen64 #define STAT stat64 -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-06-29 12:45 --- Yeah, this would be the best way to solve this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-07-06 10:33 --- (In reply to comment #5) > Perhaps there are two bugs, not one, as my more elaborate testcases show. > Though they are seemingly equivalent, one triggers the bug, while another > don't. > Ok, is the same issue occurring, when the attributes are set separately in different __attribute__ statements? Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-07-06 11:54 ---
Ok, I think I found the issue. The following patch solved the ICE here. The ebx
register wasn't allowed for sibcall_1 in i386.md, but for fastcall it can be
used for sibcalling.
I have to do a regression test for it, but it seems to work well.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 149152)
+++ config/i386/i386.md (working copy)
@@ -15536,7 +15536,7 @@
[(set_attr "type" "call")])
(define_insn "*sibcall_1"
- [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a"))
+ [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a,b"))
(match_operand 1 "" ""))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
@@ -22183,7 +22183,7 @@
(define_insn "*sibcall_value_1"
[(set (match_operand 0 "" "")
- (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a"))
+ (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a,b"))
(match_operand:SI 2 "" "")))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2009-05-13 20:04:31 |2009-07-06 11:54:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-06 11:54:21 |2009-07-06 12:38:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-07-06 13:17 --- (In reply to comment #8) > This cannot be correct in the general case as %ebx is call-saved, you cannot > clobber it through a function call. A solution could be to disparage the 'c' > alternative, but a x86 maintainer will know better. > Well, why? For save or called saved registers the functions epilogue/prologue takes care. The reason why gcc tries to choose ebx for call address register here, is exactly this reason, as it can be sure that after the sibcall, the register is still valid. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-07-06 16:12 --- (In reply to comment #10) > > Well, why? For save or called saved registers the functions > > epilogue/prologue > > takes care. The reason why gcc tries to choose ebx for call address register > > here, is exactly this reason, as it can be sure that after the sibcall, the > > register is still valid. > > What's the assembly code generated with your patch? > Compiling the test case with -O2 .file "c_impfast.c" .text .p2align 4,,15 .globl _f .def_f; .scl2; .type 32; .endef _f: pushl %ebp movl$2, %ecx movl%esp, %ebp pushl %ebx subl$4, %esp movl__i...@h@4, %ebx call*%ebx addl$4, %esp movl$1, %ecx popl%ebx popl%ebp jmp *%ebx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #12 from ktietz at gcc dot gnu dot org 2009-07-06 16:13 --- And this is pretty wrong :} -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #13 from ktietz at gcc dot gnu dot org 2009-07-06 16:41 ---
By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that c
is last element, produced code is ok and no ICE I've seen. The ebx issue is
pretty wrong here.
Index: gcc/gcc/config/i386/i386.md
===
--- gcc.orig/gcc/config/i386/i386.md2009-07-06 18:14:36.15567 +0200
+++ gcc/gcc/config/i386/i386.md 2009-07-06 18:36:54.453670100 +0200
@@ -15536,7 +15536,7 @@
[(set_attr "type" "call")])
(define_insn "*sibcall_1"
- [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a"))
+ [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,d,a,c"))
(match_operand 1 "" ""))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
@@ -22183,7 +22183,7 @@
(define_insn "*sibcall_value_1"
[(set (match_operand 0 "" "")
- (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a"))
+ (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,d,a,c"))
(match_operand:SI 2 "" "")))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #15 from ktietz at gcc dot gnu dot org 2009-07-06 17:02 ---
(In reply to comment #14)
> > By simply re-ording of arguments fos sibcall_1 and sibcall_value_1, so that
> > c
> > is last element, produced code is ok and no ICE I've seen.
>
> Disparaging it ("s,!c,d,a") would be even more robust I think.
>
yeah, this works, too. But the d needs the !, too. As when I alter my testcase
by giving the dllimport'ed fastcall a second argument, it ICEs again.
$ /usr/local/bin/i686-pc-mingw32-gcc.exe -o t.s -S c_impfast2.c -O2
c_impfast2.c: In function 'f':
c_impfast2.c:7:1: error: unable to find a register to spill in class 'DREG'
c_impfast2.c:7:1: error: this is the insn:
(call_insn/j 12 10 13 2 c_impfast2.c:6 (call (mem:QI (reg/f:SI 3 bx [58]) [0 S1
A8])
(const_int 0 [0x0])) 462 {*sibcall_1} (expr_list:REG_DEAD (reg/f:SI 3
bx [58])
(expr_list:REG_DEAD (reg:SI 2 cx)
(expr_list:REG_DEAD (reg:SI 1 dx)
(nil
(expr_list:REG_DEP_TRUE (use (reg:SI 2 cx))
(expr_list:REG_DEP_TRUE (use (reg:SI 1 dx))
(nil
c_impfast2.c:7:1: internal compiler error: in spill_failure, at reload1.c:2094
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
So with both c and d changed to !c and !d for sibcall_1 and sibcall_value_1 it
translates without ICE to:
.file "c_impfast2.c"
.text
.p2align 4,,15
.globl _f
.def_f; .scl2; .type 32; .endef
_f:
pushl %ebp
movl$1, %edx
movl%esp, %ebp
movl$2, %ecx
pushl %ebx
subl$4, %esp
movl__i...@h@8, %ebx
call*%ebx
addl$4, %esp
movl$2, %edx
movl$1, %ecx
movl%ebx, %eax
popl%ebx
popl%ebp
jmp *%eax
New patch for i386.md (and you are right the !c,!d is more robust here) is:
Index: gcc/gcc/config/i386/i386.md
===
--- gcc.orig/gcc/config/i386/i386.md2009-07-06 18:14:36.15567 +0200
+++ gcc/gcc/config/i386/i386.md 2009-07-06 18:53:10.459670100 +0200
@@ -15536,7 +15536,7 @@
[(set_attr "type" "call")])
(define_insn "*sibcall_1"
- [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,c,d,a"))
+ [(call (mem:QI (match_operand:SI 0 "sibcall_insn_operand" "s,!c,!d,a"))
(match_operand 1 "" ""))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
@@ -22183,7 +22183,7 @@
(define_insn "*sibcall_value_1"
[(set (match_operand 0 "" "")
- (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,c,d,a"))
+ (call (mem:QI (match_operand:SI 1 "sibcall_insn_operand" "s,!c,!d,a"))
(match_operand:SI 2 "" "")))]
"SIBLING_CALL_P (insn) && !TARGET_64BIT"
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug bootstrap/39610] ICE in libstdc++-v3/include in stage 3
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-07-17 10:35 --- Seems to be fixed by side-effect. Thanks, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39610
[Bug target/40786] Windows %I32 format confusion
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-07-19 08:55 --- I agree, that the behavior isn't correct here. %I32 is treated at the moment as equivalent for %l width specifier. But in fact is the type __int32 specifying an integer scalar with 32-bit width. For x86 and x64, where sizeof(long)==sizeof(int), the %I32 should be valid for both, or just for integer. That it is interpreted as equivalent to %l is indeed a bug. Cheers, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-19 08:55:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40786
[Bug driver/39356] assembler isn't called
--- Comment #16 from ktietz at gcc dot gnu dot org 2009-07-22 16:06 --- (In reply to comment #15) > Is there a chance that we get this fixed soon? > > Rainer > Well, I would like to fix this. Better now then later. But I couldn't find the real reason for this issue. The patch above solved the problem on 4.4.0 branch some time ago, but now it seems to be a different issue. But AFAICT is is related to chkstk/alloca here. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-07-30 08:38 --- Hmm, possibly this is a bug in our inline functions of mingw-w64. Does the switch -fno-strict-aliasing solves this issue, too? We have here struct casts, which maybe are reasoning here strict aliasing issues. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug middle-end/41001] New: alloca broken for -fno-builtin
The function alloca (for cygwin/mingw target _alloca) is broken or not available (for linux64), when using option -fno-builtin. The linux and win32 targets the symbol alloca isn't present. For windows targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm present. But when using this, the stack layout is broken after calling alloca. The attached example shows the failure for i?86 and x86_64 windows targets pretty well. -- Summary: alloca broken for -fno-builtin Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC host triplet: x86_64-pc-linux GCC target triplet: x86_64-*-* i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001
[Bug middle-end/41001] alloca broken for -fno-builtin
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-08-07 15:38 --- Created an attachment (id=18324) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18324&action=view) Testcase for alloca/_alloca to be compiled with option -fno-builtins -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001
[Bug middle-end/41001] alloca broken for -fno-builtin
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-08-07 21:05 --- (In reply to comment #2) > Subject: Re: New: alloca broken for -fno-builtin > > On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote: > > > The function alloca (for cygwin/mingw target _alloca) is broken or not > > available (for linux64), when using option -fno-builtin. > > It is in the nature of alloca that it needs to be built in to the compiler > for an effective implementation, and the lack of a library emulation > (using malloc) is nothing to do with the compiler. Why do you think there > is a bug here? > > > The linux and win32 targets the symbol alloca isn't present. For windows > > targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm > > present. But when using this, the stack layout is broken after calling > > alloca. > > I do not believe _alloca is meant to be an implementation of the C alloca > function; if it was, it would be alloca not _alloca. Do you have any > reason to believe _alloca does not follow its specification of making > stack space available when called implicitly by the compiler (*not* an > explicit C function call - it has its own special ABI so you can't call it > explicitly from C)? > Well, if so. It makes no sense that -fno-builtins tries to call a function which isn't present. But for other compilers, alloca can be invoked as function, too. The compiler builtin part in all cases is, to be aware that stack frame changes (hot-region, call save-area, and co are adjusted after calling it). IIRC it is even mentioned as function in K&R, but well I could mix-up here something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001
[Bug middle-end/41001] alloca broken for -fno-builtin
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-08-08 08:43 --- (In reply to comment #4) > -fno-builtin means more or less exactly that the compiler *should not* > assume anything special about a function from its name (unless the name > starts __builtin or some similar reserved-namespace cases such as __sync) > - that is, you declare alloca and because of -fno-builtin the compiler > assumes this is your own function with no special semantics whatever. By > -fno-builtin you are declaring that alloca, and all other normally > built-in functions, are normal functions with no special semantics the > compiler needs to know about. So of course it generates a call like it > would to any other random function you might have defined in another > translation unit. > > If you want to use alloca with its traditional memory allocation semantics > with -fno-builtin, you'll need to use a malloc-based emulation such as > that in libiberty, not something that uses the stack. > Well, IMHO it is the same for alloca, as for setjmp, or longjmp. Even some code for detecting alloca semanices is present (in a slightly broken way), see calls.c (special_function_p). So, if it is really the intention that by -fno-builtin all function have standard calling convention, then this special cases in calls.c would be a bug. But well, I assume it isn't. I think the best thing to do here is, as written within this function commment, to have a function-declaration attribute, which indicated alloca behavior. Or, do I mis-read here something. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001
[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-08-13 06:08 ---
(In reply to comment #1)
> Even the target-specific i686-mingw32/bin directory contains host
> applications,
> i.e. the non-$target-prefixed versions of the binutils.
>
> So since these DLLs are never going to be used on the host, we could put them
> in $target/lib. That might end up altering the link order a bit, since ld
> supports linking directly against dlls but $prefix/bin isn't usually in the
> link path; however as long as the compiler's private directory
> $prefix/lib/gcc/$target/$version is first in the list, the dll's related
> import
> lib will always be found first.
>
> The other place to install them would be in GCC's private dir. I'm not sure
> yet which might be preferable.
>
I would vote for the $prefix/lib/gcc/$target/$version directory. There is the
bug 38294 for multilib install, which has same reason.
Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
----------------
CC||ktietz at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125
[Bug fortran/33561] Wrong code for single precision math functions on x86_64-pc-mingw32
--- Comment #3 from ktietz at gcc dot gnu dot org 2007-09-26 12:52 --- This doesn't seems to be an error in gcc. The w64 crt currently does not implement some math functions proper. May somebody can assist to port the assemble coded function for this target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
[Bug ada/37641] FILE_WRITE_PROPERTIES is deprecated
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-09-24 17:32 --- FILE_WRITE_PROPERTIES is deprecated and even the documentation is removed from msdn. So I agree that FILE_WRITE_EA should be used instead. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 17:32:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37641
[Bug bootstrap/25502] I64d format Werror problem in build
--- Comment #21 from ktietz at gcc dot gnu dot org 2008-10-13 10:39 --- Fix on trunk on revision 141087. See http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00428.html for the patch. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug target/17717] SH4 internal compiler error: in emit_move_insn
--- Comment #13 from ktietz at gcc dot gnu dot org 2008-10-13 10:41 --- See comment above -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17717
[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-10-17 12:25 --- For target x86_64-pc-mingw32 it is the same In file included from /vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc++-v3/include/ostream:572, from ../../../../libstdc++-v3/src/ostream-inst.cc:35: /vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc++-v3/include/bits/ostream.tcc: In member function 'std: :basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::_M_insert(_ValueT) [with _ValueT = long double, _C harT = char, _Traits = std::char_traits]': /vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc++-v3/include/bits/ostream.tcc:92: internal compiler err or: in vt_add_function_parameters, at var-tracking.c:3176 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37815
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #24 from ktietz at gcc dot gnu dot org 2008-10-20 11:24 --- This bug is reasoned by some problems in ira. IIUC, mingw 32-bit has the same issue here. This bug can be worked around by disable ira optimization via -fno-ira. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug target/34013] callee-save register value sometimes corrupted when __stkchk called
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-01-30 11:34 --- The issue is solved. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34013
[Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc.
The method _alloca assemble implementation is written that way, that it does not return the stack pointer. I just reserves and probes the stack space. The MSVCRT variant declares it as a synonym for POSIX alloca(). Here are three problems by the gcc variant: 1) The stack pointer isn't returned in (eax/rax). 2) If the _alloca function is called by a value not equal to the stack boundary, the stack pointer (esp/rsp) gets unaligned and OS will raise an exception for the next instruction pushing to the stack. 3) For target x86_64-pc-mingw32 the calling convention is treated correctly. For ms abi, the argument gets reserved room on stack, too. Like for the 32 bit variant. For the x86_64-pc-mingw32 target I attached a patch for this. Index: gcc/gcc/config/i386/cygwin.asm === --- gcc.orig/gcc/config/i386/cygwin.asm +++ gcc/gcc/config/i386/cygwin.asm @@ -72,15 +72,44 @@ Ldone: pushl %eax ret #else -/* __alloca is a normal function call, which uses %rcx as the argument. */ +/* __alloca is a normal function call, which uses %rcx as the argument. And stack space + for the argument is saved. */ __alloca: movq%rcx, %rax - /* FALLTHRU */ + addq$0x7, %rax + andq$0xfff8, %rax + popq%rcx/* pop return address */ + popq%r10/* Pop the reserved stack space. */ + movq%rsp, %r10 /* get sp */ + cmpq$0x1000, %rax /* > 4k ?*/ + jb Ldone_alloca + +Lprobe_alloca: + subq$0x1000, %r10 /* yes, move pointer down 4k*/ + orq $0x0, (%r10)/* probe there */ + subq$0x1000, %rax /* decrement count */ + cmpq$0x1000, %rax + ja Lprobe_alloca /* and do it again */ + +Ldone_alloca: + subq%rax, %r10 + orq $0x0, (%r10)/* less than 4k, just peek here */ + movq%r10, %rax + subq$0x8, %r10 /* Reserve argument stack space. */ + movq%r10, %rsp /* decrement stack */ + + /* Push the return value back. Doing this instead of just + jumping to %rcx preserves the cached call-return stack + used by most modern processors. */ + pushq %rcx + ret /* ___chkstk is a *special* function call, which uses %rax as the argument. We avoid clobbering the 4 integer argument registers, %rcx, %rdx, %r8 and %r9, which leaves us with %rax, %r10, and %r11 to use. */ ___chkstk: + addq$0x7, %rax /* Make sure stack is on alignment of 8. */ + andq$0xfff8, %rax popq%r11/* pop return address */ movq%rsp, %r10 /* get sp */ cmpq$0x1000, %rax /* > 4k ?*/ -- Summary: Method _alloca is defined different by MSVCRT as by gcc. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC build triplet: *-*-mingw32 GCC host triplet: *-*-mingw32 GCC target triplet: *-*-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
[Bug c++/35159] g++ inoperable with no error message
--- Comment #2 from ktietz at gcc dot gnu dot org 2008-02-11 14:57 --- It is 4.3.0. I modified the bug report for that. Cheers, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-02-14 09:00 --- I agree, that the havoc for 32-bit backward compatibility is to avoid. But the havoc for windows sources using -fno-builtin and using _alloca () for stack allocation produces in future even more troubles IMHO. We allready defined the macro _alloca as 32-bit mingw does. The next source tarball will inherit this patch. But if we simply add a return type in eax for 32-bit world, does this really harm anybody? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
[Bug c++/35159] g++ inoperable with no error message
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-02-14 09:07 --- Hello, I tracked the problems down. Stack probing in builtin_alloca is the reason for this. As I found, in some cases the input %rax argument isn't got set at all or got clobbered before call to __chkstk. The work-a-round for this, is to disable stack probing. So I assume the reason is to be searched in optimization or in the builtin function itself. AFAICS the implementation in the i386.md file seems to be ok. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug c++/35159] g++ inoperable with no error message
--- Comment #8 from ktietz at gcc dot gnu dot org 2008-02-14 09:26 --- I tested this already and it didn't solved the problem. But may +a is more correct. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug c++/35159] g++ inoperable with no error message
--- Comment #11 from ktietz at gcc dot gnu dot org 2008-02-14 10:03 --- May I find a point, where things aren't treated for 64-bit correctly for Windows. In i386.c ix86_expand_prologue() there are stack pointer manipulation operations using 4 byte offset for both targets (32 and 64). I am currently rebuild and test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #15 from ktietz at gcc dot gnu dot org 2008-02-16 19:50 --- (In reply to comment #10) > (In reply to comment #8) > > I tested this already and it didn't solved the problem. But may +a is more > > correct. > Perhaps setting RTX_FRAME_RELATED_P is needed? Or gen_blockage() at some > point? As far as I saw there is a bug in ix86_expand_prologue, but it hasn't to do something with this problem. The code expansion for inlined static methods, seems to be broken. If I write small test programs using alloca (and so indirect ___chkstk) every thing works fine and the assembly is proven correct. But if the methods getting more complex like in cp/pt.c the code gets broken. If I use the target by disabling the stack probing most problems are gone, but still there seems to be a stack corruption in c++ and fortan compiler. These compilers make more use of stack allocation method alloca. For the stack probing I am certain, that if the a linux x86_64 would enable it, things get here broken, too. But there seems to be a issue with inline expansion in general. So for this bug may it the best to disable for now the stack probing at all. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-02-16 20:46 --- Yes, for the x86_64-pc-mingw32 the %ld printing exists, but it is for long, not for long long. For this target long is 32-bit scalar, so the printf formatters are wrong. in gthr-win32.h there seems to be a more serious bug. The cast of an integer with less size to a pointer can be seriously wrong. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315
[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666
--- Comment #7 from ktietz at gcc dot gnu dot org 2008-04-06 18:20 --- Created an attachment (id=15436) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15436&action=view) Patch for i386.c:7666 fixing dllimport symbol handling This patch is a try for fixing the new ICE. It is currently be tested. If works, I will post a patch for this to gcc-patches -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35842
[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666
--- Comment #8 from ktietz at gcc dot gnu dot org 2008-04-06 18:29 --- Ok, the patch fixes the ICE by test without any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35842
[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666
--- Comment #9 from ktietz at gcc dot gnu dot org 2008-04-07 13:35 --- Committed revision 133981. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35842
[Bug c++/39179] New: Wrong code in c++ for const members initialized in external file
It seems so that for optimization levels one or higher, gcc produces wrong code
for the two test files below.
If I compile the same test with -O or -Os everything works fine.
On taking a look into produced assembly, it seems that it wrongly assumes the
assert alway have to raise.
File 1: t1.cpp
//class.h
struct K {
static const unsigned k;
};
#include
int main() {
assert ( K::k == 1 );
return 1;
}
File 2: t2.cpp
struct K {
static const unsigned k;
};
//class.cpp
const unsigned K::k = 1;
Then compile both file g++ -o tst t1.cpp t2.cpp -O2
--
Summary: Wrong code in c++ for const members initialized in
external file
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-02-14 20:10 ---
(In reply to comment #2)
> The problem is that targetm.binds_local_p returns true for
>
> type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0xb785edd0 precision 32
> min max >
> readonly used public static unsigned external nonlocal decl_3 decl_5
> decl_6
> SI file t.ii line 2 col 27 size unit size
>
> align 32 context
> chain >
>
> though probably nobody thought of handling TREE_STATIC && DECL_EXTERNAL being
> true at the same time. Thus, this looks like a possible C++ FE problem to me?
>
> A simple fix would be for i386_pe_binds_local_p to return false if
> DECL_EXTERNAL is set, as this is what default_binds_local_p_1 does.
> Or better, it should dispatch to default_binds_local_p_1 and only
> adjust the shlib flag according to DECL_DLLIMPORT_P.
>
Right in winnt.c (i386_pe_bind_local_p) should be something like this patch,
but sadly we get then emitted @GOTPCREL, which aren't handled proper by COFF
targets.
Index: gcc/gcc/config/i386/winnt.c
===
--- gcc.orig/gcc/config/i386/winnt.c
+++ gcc/gcc/config/i386/winnt.c
@@ -321,13 +321,14 @@ i386_pe_encode_section_info (tree decl,
bool
i386_pe_binds_local_p (const_tree exp)
{
+ bool flag = true;
/* PE does not do dynamic binding. Indeed, the only kind of
non-local reference comes from a dllimport'd symbol. */
if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
&& DECL_DLLIMPORT_P (exp))
-return false;
+flag = false;
- return true;
+ return flag && default_binds_local_p_1 (exp, flag_shlib);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-14 21:25 --- (In reply to comment #7) > What happens if you just use > > return default_binds_local_p_1 (exp, (TREE_CODE (exp) == VAR_DECL || TREE_CODE > (exp) == FUNCTION_DECL) >&& DECL_DLLIMPORT_P (exp)); > > ? > Same issue @GOTPCREL code gets emitted. ... movq__zn1k...@gotpcrel(%rip), %rax cmpl$1, (%rax) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39179] Wrong code in c++ for const members initialized in external file
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-02-18 08:18 --- (In reply to comment #1) > I think long double on w64 is the same as double. I am not sure if > gcc.dg/callabi/func-1.c is a valid test. > the long double is supported as 96-bit floating point for gcc. This isn't as ms_abi declares it, but I follow here the 32-bit port. So we allow higher precision, and by vendor specific headers it has not much affects, beside that the vendor specific scanf/printf functions can't print it proper. Therefore the mingw runtime provides C99 compliant (and gnu-style compiant) alternatives to print/scan them. I am verifying it at the moment for w64 target, if we have here same issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-02-18 08:47 --- (In reply to comment #2) > I am verifying it at the moment for w64 target, if we have here same issues. > Yes, on w64 targets we have the same issue. By adding print methods, it seems that the return value of the foreign abi is passed/treated wrong. This testcases were run by me last time about beginning of January this year and they seem to work fine at this date. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-18 08:47:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-02-18 10:45 --- ok, I found the issue, which causes here the problem. The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack variable as 96 bits, but the upper 32-bits (which have to be zero initialized) aren't set. For w64 there are stored 128-bit in this case as desired. So the compare of those two results is failing, because on x86_64 abi the upper 32-bits have random values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-02-18 12:11 --- (In reply to comment #5) > (In reply to comment #4) > > ok, I found the issue, which causes here the problem. > > The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack > > XFmode > right, sorry I meant XFmode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-18 14:23 --- (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > ok, I found the issue, which causes here the problem. > > > > The x86_64 abi returns TFmode in rax,edx which is stored in aligned > > > > stack > > > > > > XFmode > > > > > > > right, sorry I meant XFmode > > > > w64 ABI doesn't cover XFmode. Why do you use integer registers for > XFmode? It doesn't make any senses to me. > As I said above there are two reasons. First 32-bit code supports XFmode, too. Also the vendor specific library supports 96-bit floating point, too. But not as native type, they use a struct for this (what is the current implementation in gcc to pass them as memory reference). So there is no good reason for not supporting XFmode types for w64 IMHO. This issue here seems to be more the store size in x86_64 abi. Hasn't x86_64 also the need to have those types store 16-bytes aligned? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug other/39062] libssp/ssp.c needs malloc.h for mingw
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-21 09:50:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
[Bug target/39063] libgcc2.c:mprotect() for mingw, incompatible pointer type warning
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-21 09:52:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug target/39064] libiberty md5.h needs uintptr_t
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-21 09:53:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
[Bug target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-21 09:55:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug target/39066] DO_GLOBAL_CTORS_BODY needs uintptr_t
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-21 09:56:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-28 17:48 --- I can't test your precompiled code, because c++ has changed in an incompatible way. Could you attach a current precompiled version using gcc4.4 of it? Is the problem still present on 4.4.0 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug driver/39356] assembler isn't called
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-03-06 15:12 --- Well, the issues in driver seems to be related to pexecute in protoize.c. On a first glance, I noticed that here for pid's an 'int' type is used (btw in libiberty a 'long' is used for keeping the pids, which is for w64 incorrect, too). The problem is, that pid_t has to have a scalar size on w64 of 64-bits. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC| |ktietz at gcc dot gnu dot | |org AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-06 15:12:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug driver/39356] assembler isn't called
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-03-07 10:46 --- (In reply to comment #3) > Well, the issues in driver seems to be related to pexecute in protoize.c. On a > first glance, I noticed that here for pid's an 'int' type is used (btw in > libiberty a 'long' is used for keeping the pids, which is for w64 incorrect, > too). > The problem is, that pid_t has to have a scalar size on w64 of 64-bits. > Sorry, pex_run & co aren't the reason for this issue. By further debugging I found that for bigger functions using alloca with variable sizes wrong code is generated for optimizations bigger then -O0. By this reason the driver gcc.c in execute is broken. The interesting issue about this is, when trying to make a smaller testcase out of it, code is produced correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug middle-end/39421] New: Wrong code for optimizition on 64-bit scalar integers
All of these problems are adisappearing when the code is compiled without the
-O2 flag.
I have tried to reproduce the problems using simple code fragments, but I have
only succeeded in doing this for 2 of these problems (t1 and t3 in the attached
testcase). I cannot reproduce the other problem (t2 in the following code).
Running the program (with -O2) produced the following:
$ ~/a.exe
w is 8000
, V is 8000
t1 Wrong!
v != w
t2 Correct!
t3: w = 8000
t3 Wrong!
In our actual code corresponding to t2, we do the same comparison of
if ((uword) w > (uword) MX_S_W))
and the comparison fails when w was originally negative.
For t1 and t3, I can see why some optimisation might reason away the actual
tests, if it does not consider overflow of the signed word. Curiously, removing
the printf before if (w <= 0) ... line in t3 cause the
if (w <= 0) test to fail -- I don't see why this happens.
(in our original code, we don't have the printf, but w <= 0 does succeed, it is
the w == MN_S_W test that fails as in t3).
--
Summary: Wrong code for optimizition on 64-bit scalar integers
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39421
[Bug middle-end/39421] Wrong code for optimizition on 64-bit scalar integers
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-03-10 09:46 --- Created an attachment (id=17436) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17436&action=view) testcase C file Test case for this problem. It can be reproduce AFAI tested on x86_64-pc-linux and on x86_64-pc-mingw32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39421
[Bug driver/39356] assembler isn't called
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-03-15 20:08 --- This bug was reasoned by duplicate existance of function __chkstk. For targets mingw/cygwin this symbol allocates and probes stack (see /gcc/config/i386/cygwin.asm). The VC variant export the same symbol name in kernel32, ntdll, and ntoskernl. But the MS variant just probes the stack and does not allocates stack space. I temporary removed the exports from our .def files in mingw-w64 and this solves the issue so far. The bad side of this fix is, that libraries generated by VC can't be linked proper, if they reference the ms __chkstk variant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug driver/39356] assembler isn't called
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-03-15 20:13 --- The following patch solves this problem and prevents the name collision for 32 and 64 bits win32 systems. ChangeLog * config/i386/i386.md (allocate_stack_worker_32): Use ___gnu_chkstk. (allocate_stack_worker_64): Likewise. * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca. (___chkstk): Renamed to ___gnu_chkstk. Index: gcc/gcc/config/i386/cygwin.asm === --- gcc.orig/gcc/config/i386/cygwin.asm +++ gcc/gcc/config/i386/cygwin.asm @@ -40,11 +40,11 @@ increments is necessary to ensure that the guard pages used by the OS virtual memory manger are allocated in correct sequence. */ - .global ___chkstk - .global __alloca #ifndef _WIN64 -___chkstk: -__alloca: + .global ___gnu_chkstk + .global ___gnu_alloca +___gnu_chkstk: +__gnu_alloca: pushl %ecx/* save temp */ leal8(%esp), %ecx /* point past return addr */ cmpl$0x1000, %eax /* > 4k ?*/ @@ -72,9 +72,11 @@ Ldone: pushl %eax ret #else + .global ___gnu_chkstk + .global __gnu_alloca /* __alloca is a normal function call, which uses %rcx as the argument. And stack space for the argument is saved. */ -__alloca: +__gnu_alloca: movq%rcx, %rax addq$0x7, %rax andq$0xfff8, %rax @@ -107,7 +109,7 @@ Ldone_alloca: /* ___chkstk is a *special* function call, which uses %rax as the argument. We avoid clobbering the 4 integer argument registers, %rcx, %rdx, %r8 and %r9, which leaves us with %rax, %r10, and %r11 to use. */ -___chkstk: +___gnu_chkstk: addq$0x7, %rax /* Make sure stack is on alignment of 8. */ andq$0xfff8, %rax popq%r11/* pop return address */ Index: gcc/gcc/config/i386/i386.md === --- gcc.orig/gcc/config/i386/i386.md +++ gcc/gcc/config/i386/i386.md @@ -20297,7 +20297,7 @@ (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 1))) (clobber (reg:CC FLAGS_REG))] "!TARGET_64BIT && TARGET_STACK_PROBE" - "call\t___chkstk" + "call\t___gnu_chkstk" [(set_attr "type" "multi") (set_attr "length" "5")]) @@ -20310,7 +20310,7 @@ (clobber (reg:DI R11_REG)) (clobber (reg:CC FLAGS_REG))] "TARGET_64BIT && TARGET_STACK_PROBE" - "call\t___chkstk" + "call\t___gnu_chkstk" [(set_attr "type" "multi") (set_attr "length" "5")]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug driver/39356] assembler isn't called
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-03-16 09:15 --- (In reply to comment #8) > (In reply to comment #7) > > The following patch solves this problem and prevents the name collision for > > 32 > > and 64 bits win32 systems. > > > > ChangeLog > > > > * config/i386/i386.md (allocate_stack_worker_32): Use > > ___gnu_chkstk. > > (allocate_stack_worker_64): Likewise. > > * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca. > > (___chkstk): Renamed to ___gnu_chkstk. > > > No. This breaks backward compatibility. Static libraries and objects built > with current and older versions of gcc will not be able to resolve references > to __alloca or ___chkstk.Why not add labels with the new names as aliases > rather than replace. > > Danny > Ok, for 32-bits this makes sense to keep the old symbol names. Beside there is still a chance that a user uses the manually the chkstk.o file, which can lead to undefined behaviour (at least if the user code references __chkstk). For 64-bit I prefer to avoid those old names and simply rename it. Is this ok for you? I'll file then a patch for it? Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug target/39472] Add -mabi=[ms|sysv]
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-03-17 09:43 --- This feature would be fine. But at the moment we are in Stage 4. So it can be implemented on 4.5 and then after 4.4 is reopened merged back. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
[Bug target/39476] Typo in ix86_function_regparm in i386.c
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-03-17 09:39 ---
(In reply to comment #1)
> It is
> if (TARGET_64BIT)
> {
> if (ix86_function_type_abi (type) == DEFAULT_ABI)
> return regparm;
> return DEFAULT_ABI != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
> }
> Shouldn't it be
> return DEFAULT_ABI == SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
No, it shouldn't. The old test checks first if the calling abi specified via
type is the default one. As you noticed, regparm is never changed for 64-bit.
The second check is for *foreign* abi and has to return in inverse logic.
The patch in comment #2 is ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug driver/39356] assembler isn't called
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-03-19 14:33 --- (In reply to comment #9) Patch sent. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug target/39518] New: Missing documentation of cygwin and mingw target options
In gcc/doc/invoke.texi all the cygwin/mingw specific target -m options aren't documented. -- Summary: Missing documentation of cygwin and mingw target options Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: *-*-mingw32 *-*-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39518
[Bug target/39518] Missing documentation of cygwin and mingw target options
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-03-22 10:02 --- Created an attachment (id=17513) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17513&action=view) Patch file Patch to add some missing documentation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39518
[Bug target/39518] Missing documentation of cygwin and mingw target options
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-03-22 11:20 --- Sent patch. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00997.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-22 11:20:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39518
[Bug target/39518] Missing documentation of cygwin and mingw target options
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-03-25 17:44 --- Committed at revision 145070. PR/39518 * doc/invoke.texi (-mconsole): New. (-mcygwin): New. (-mno-cygwin): New. (-mdll): New. (-mnop-fun-dllimport): New. (-mthread): New. (-mwin32): New. (-mwindows): New. (sub section "i386 and x86-64 Windows Options"): New. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39518
[Bug pch/39492] [4.3/4.4/4.5 Regression] Parallel compilation fail using PCH on Windows NT>= 5.0
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-03-31 12:30 --- Patch sent. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01752.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-03-19 18:47:00 |2009-03-31 12:30:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39492
