--- 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=17052action=view) [edit]
Replace execvp with pex_one in process_command
Patch uses pex_one as per Ian
--- 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
--- 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=17210action=view)
Alternative patch suggested
This is the patch I test at the moment.
--
http://gcc.gnu.org/bugzilla
--- 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=17210action=view) [edit]
Alternative patch suggested
This is the patch I test at the moment
--- 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
--- 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
--- 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
--- 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
--- 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
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
var_decl 0xb7866000 k
type integer_type 0xb785edd0 unsigned int readonly unsigned SI
size integer_cst 0xb778b4a4
--- 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
--
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. This isn'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't
--- 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
--- 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
--
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 ?
--
http
--- 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
--- 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
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
--- 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=17436action=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
--- 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
--- 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.
ChangeLog
* config/i386/i386.md
--- 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 ? X86_64_REGPARM_MAX
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=17513action=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
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-01 09:08 ---
Committed to 4.4 at revision 145395 and to 4.5 at revision 145395.
Didn't committed it to 4.3.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-01 10:44 ---
(In reply to comment #5)
(In reply to comment #3)
terminate called after throwing an instance of 'std::runtime_error'
what(): ouch
Yes, this is the part that's missing for me.
Well, as far as I verified
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-01 09:18 ---
(In reply to comment #2)
__gnu_cxx::__verbose_terminate_handler hasn't been called then,
doesn't the mingw runtime override __cxxabiv1::__terminate_handler
or the unwinding on mingw not call std::terminate at all
--- Comment #4 from ktietz at gcc dot gnu dot org 2008-01-02 10:48 ---
Subject: Bug 34013
Author: ktietz
Date: Wed Jan 2 10:46:17 2008
New Revision: 131255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131255
Log:
(ix86_expand_prologue): Save red-zone while stack probing.
PR
--- 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: 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
--- 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 work
--- 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 64). I
--- 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
--- 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 #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
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-05 08:39 ---
for mingw-w64 we have the same issue as cygwin.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-11 16:36 ---
Where are your headers installed? To which directory?
And of interest is the configure options you are passing to gcc's configure,
too.
Could you attach the build log?
Kai
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-04-11 17:33 ---
(In reply to comment #5)
stdio.h at system level is where it originally was:
/usr/include/stdio.h
/usr/include/c++/4.2.1/tr1/stdio.h
/usr/include/bits/stdio.h
Ok, this is what I assumed. You are building
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-04-11 19:33 ---
(In reply to comment #1)
Are you sure your entire compiler is up to date, not just the library? And the
build and install directories are clean? Because your first lines of failure
involve bits of the library
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: i686
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-04-12 19:20 ---
Created an attachment (id=17623)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17623action=view)
testcase
Reduced testcase for showing the issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39745
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-12 19:49 ---
(In reply to comment #5)
I see this bug in compiler driver is already known
(http://sourceforge.net/forum/forum.php?thread_id=3091795forum_id=723797), it
works only with -O0. I can't found report about this bug
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-04-13 08:34 ---
(In reply to comment #7)
Please make sure, that you have in your gcc source root directory the
symbolic
link winsup pointing to your prefix directory. Secondly, make sure you
have
the symbolic link mingw
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-04-13 19:25 ---
(In reply to comment #10)
I try to build gcc with latest CRT from svn (revision 764) - build is OK. It
seems, snapshot from sourceforge download page(November 15, 2008) not
compatible with gcc 4.4.
Well
--- Comment #16 from ktietz at gcc dot gnu dot org 2009-04-21 08:27 ---
(In reply to comment #15)
(In reply to comment #14)
or remove the ordinary C library function in
lib64_libmingwex_a-wininterlocked.o and just keep the inline function ?
That would be my first experiment
--- Comment #18 from ktietz at gcc dot gnu dot org 2009-04-25 19:10 ---
(In reply to comment #16)
Ok. Hopefully, before the end of this week I can tell you something
trustworthy
about binary compatibility.
Have you found a solution for it? On w64 target 4.4 (and 4.5) the problem
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-29 07:38 ---
(In reply to comment #2)
The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc
Danny
That's correct. We have to find a way to install
--- 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 to use specs rather than
--- 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=gccview=revrev=133892
Log:
PR other/35151
--- 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 care
--- 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
--- 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
--- 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=gccview=revrev=149015
Log:
2009-06-27 Kai Tietz kai.ti...@onevision.com
Merged
--- 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=gccview=revrev=149016
Log:
2009-06-27 Kai Tietz kai.ti...@onevision.com
Merged
--- 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, is the same issue
--- 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
--
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'
alternative, but a x86 maintainer
--- 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
--- 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/i386.md
--- 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
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-10-23 17:59 ---
Created an attachment (id=18882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18882action=view)
Patch for enable for mingw32 targets -fset-stack-executable
Changelog
* config/i386/mingw32.h
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-10-26 19:24 ---
Patch post at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01577.html to ML
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41799
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-10-27 17:16 ---
Applied to trunk at revision 153606.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-10-30 17:52 ---
Well, I meant of course 4.4 branch. I won't backport this. So I closed this
bug.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-10-30 17:57 ---
(In reply to comment #1)
gcc-4.5-20091008 snapshot was used. By the way, gcc-4.4.2-RC-20091008 works
fine.
Could you please give us your configuration line? We do bootstraps (until Stage
3) with current 4.5 gcc
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-12-03 21:56 ---
Would it be a solution (at least for -w64- targets) to remove the
sys-root/mingw part and default to sysroot/include sysroot/lib instead.
At least for the -w64- targets there is no real need of this /mingw subfolder
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-12-05 18:16 ---
hmm, I still don't see in gcc's root in libtool.m4 the patch for detecting
x64_64 archives. Did I miss here something?
Cheers,
Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-12-05 18:31 ---
I meant in libtool.m4, too:
We have here:
mingw* | pw32*)
# Base MSYS/MinGW do not provide the 'file' command needed by
# func_win32_libid shell function, so use a weaker test based on 'objdump',
# unless we
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-12-05 19:21 ---
(In reply to comment #4)
Subject: Re: libtool fails to detect pe-x86-64 import
library
* ktietz at gcc dot gnu dot org wrote on Sat, Dec 05, 2009 at 07:16:12PM CET:
hmm, I still don't see in gcc's root
1 - 100 of 279 matches
Mail list logo
