--- 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
--- 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
--- 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 t
--- 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
--- 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
--- 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 prob
--- 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&#
--- 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 tom
--- 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.
>
--- 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
--- 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 use
--- 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 se
--- 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/b
--- 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
--- 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
--- 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'
--- 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
--- 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; t
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=1
--- 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
--- 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
--- 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 expa
--- 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
--- 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
--- 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
--- 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 re
--- 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 re
--- 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
--- 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
--- 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
--- 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,
--- 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 f
--
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
--- 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'
> alt
--- 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
&g
--- 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
--- 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/i3
--- 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.
>
> Disp
--- 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
--- 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 an
--- 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
--- 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
IRMED
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.gn
--- 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/b
--- 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 _al
--- 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 som
--- 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 ne
--- 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.gn
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
sion: 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:
--- 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
--- 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
--- 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 w
--- 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
--- 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 6
--- 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 neede
--- 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
--- 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
--- 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
--- 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
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
--- 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 0xb78
--- 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)
>&&
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.4.0
http
--- 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. T
--- 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
--- 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&#
--- 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
>
> XF
--- 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.
> >
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
--- 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 ?
--
--- 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 keepi
--- 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
> libibe
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 trip
--- 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 x8
--- 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
--- 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
--- 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.
> >
> > Ch
--- 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
--- 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 ?
--- 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
ormal
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
--- 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
--- 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
--- 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
--- 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
1 - 100 of 291 matches
Mail list logo
