--- 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 |
--- 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 m
--- 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 cal
--- 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/bug
--- 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. Y
--- 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 th
gcc
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: i
--- 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=17623&action=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=3091795&forum_id=723797), it
> works only with "-O0". I can&#x
--- 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 yo
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-13 10:12 ---
Committed to 4.5 as revision 145999.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-13 10:37 ---
Subject: Bug 39062
Author: ktietz
Date: Mon Apr 13 10:37:17 2009
New Revision: 146000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146000
Log:
2009-04-13 Ozkan Sezer
PR targ
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-13 10:38 ---
Applied to 4.5 at revision 146000.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-13 10:46 ---
Subject: Bug 39397
Author: ktietz
Date: Mon Apr 13 10:45:58 2009
New Revision: 146001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146001
Log:
2009-04-13 Ozkan Sezer
PR targ
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-04-13 10:51 ---
Applied to gcc's 4.5 (trunk at revision 146001) and binutils/gdb's head.
--
ktietz at gcc dot gnu dot org changed:
What|Removed
--- 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.
--- 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 ?
> >
>
--- Comment #17 from ktietz at gcc dot gnu dot org 2009-04-21 08:49 ---
Ah, C++ makes here the trouble. We found the same issue about math.h. Here I
fixed it by avoiding to define the inline functions for C++.
I assumed it was fixed already, but this doesn't seem so. It seems that
--- 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 (
--- 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 fi
--- Comment #18 from ktietz at gcc dot gnu dot org 2009-08-18 11:03 ---
This bug is fixed by a recent change to our runtime headers. We support now the
NO_INLINE feature for platform headers, too. So, even intrinsic functions
aren't emitted anymore, when __NO_INLINE__ is de
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-08-18 11:05 ---
Ok, as I can't reproduce this anymore, and I got no reply on my question, I
close this issue.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-08-18 11:32 ---
Is there a way to make %I32 accepting both types?
Something like FMT_LEN_z?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40786
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-08-21 07:18 ---
Hello, this issue is new to us. But please report this kind of link failures to
mingw-w64 project itself. This bug is unrelated to gcc itself.
It would be interesting, if you report to mingw-w64 project, which
--
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 #4 from ktietz at gcc dot gnu dot org 2009-08-21 19:22 ---
As to see on Wiki
http://en.wikipedia.org/wiki/Printf#printf_format_placeholders
%I32 means, for integer types, causes to expect a 32-bit (double word) integer
argument. May tests have shown that long type and int
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-08-22 10:07 ---
Created an attachment (id=18412)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18412&action=view)
Suggested patch
This patch can solve this. There are two possible ways to solve this.
First)
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-08-22 17:30 ---
Created an attachment (id=18414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18414&action=view)
Patch using format_length_info member variable
Ok, here is the version using format_length_info to mar
--
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 #8 from ktietz at gcc dot gnu dot org 2009-08-24 06:20 ---
Patch fixed for 4.5 at revision 151047.
I would like to backport this patch to 4.4 and possibly to 4.3 branch, too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40786
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-08-25 10:36 ---
Ok I fixed at revision 151077 the issues about gthr-win32.h, the objective-c
library warnings aren't fixed by this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-08-29 12:33 ---
This bug is reasoned by ix86_expand_epilogue. At one place frame.padding0
wasn't added to pro_epilogue_adjust_stack.
Following patch fixes this. It has to applied to 4.4 branch, too.
I'll post it to ML
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-08-29 18:01 ---
Committed to head at revision 151204.
Committed to 4.4 branch at revision 151203.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-08-30 08:27 ---
(In reply to comment #7)
> x86_64-pc-mingw32 is not a primary or secondary platform, moving to P4.
> Please restore to P3 if this also appears on i686-mingw32 or another
> primary or secondary platform.
>
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-08-30 08:33 ---
(In reply to comment #8)
> (In reply to comment #7)
> > AFAICT DW2 unwind has never worked on x86_64-mingw32, which is why Kai made
> > sjlj the default EH model for that target.
> > http
--- Comment #17 from ktietz at gcc dot gnu dot org 2009-08-30 08:35 ---
(In reply to comment #16)
> (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 th
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-08-30 17:34 ---
(In reply to comment #2)
> (In reply to comment #1)
> > These were added by HJ. Either we need to fixinclude stdlib.h or not define
> > these based on a configure test (I guess the former is
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-08-31 19:29 ---
Created an attachment (id=18457)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18457&action=view)
Remove cast warnings for target with sizeof (void *)>sizeof(long)
If define __INTPTR_TYPE__ is pre
--- Comment #12 from ktietz at gcc dot gnu dot org 2009-08-31 19:49 ---
(In reply to comment #11)
> Created an attachment (id=17259)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17259&action=view) [edit]
> Kai's attempt
>
> This patch has a few caveats
--- Comment #13 from ktietz at gcc dot gnu dot org 2009-08-31 19:52 ---
As the change is already applied to head, I close this.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 ---
I verified it by myself and it is a duplicate of 41184
*** This bug has been marked as a duplicate of 41184 ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 ---
*** Bug 39356 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 16:20 ---
As the initial reason of this bug is solved, I close it. In fact is the
__chkstk function here incompatible to VC version, but this should be part of a
feature request.
--
ktietz at gcc dot gnu dot org changed
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 ---
*** This bug has been marked as a duplicate of 41184 ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 ---
*** Bug 39112 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-01 18:26 ---
I can't reproduce this failure. Neither for msys, linux, and linux64, nor for
cygwin. Does it still exists for you?
Which host and build environment you are using?
--
ktietz at gcc dot gnu dot org ch
--- Comment #16 from ktietz at gcc dot gnu dot org 2009-09-01 18:38 ---
(In reply to comment #15)
> GCC 4.5 [Trunk], SVN Revision 149872. Because Win64 testing is so hard to come
> by, I took the initiative of deleting the entire tree, re-checking it out, and
> building from s
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-09-01 18:59 ---
(In reply to comment #4)
> Works for me with a crosscompiler from linux to mingw:
>
> Target: x86_64-pc-mingw32
> Configured with: ../gcc-svn/trunk/configure --target=x86_64-pc-mingw32
> Thread mod
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-03 08:36 ---
The getlogin function is getting prototyped in headers only, if the _POSIX
define was set. So a bug-fix here would be for w64 to define before including
headers the _POSIX macro.
Cheers,
Kai
--
http
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-03 09:24 ---
This issue is solved for mingw-w64 runtime. It uses no more the mingwm10.dll
mechanism. Instead it uses TLS callbacks to implement it. By this reason the
Cleaning of Exception Contexts is always present for this
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-09-04 13:27 ---
(In reply to comment #4)
> (In reply to comment #2)
>
> >
> > Is it possible that it triggers the exception trying to write in
> > text.unlikely
> > which is READONLY?
> >
&g
--- Comment #14 from ktietz at gcc dot gnu dot org 2009-09-05 09:17 ---
(In reply to comment #13)
> > This looks like a target bug.
>
> This looks also like a problem with the way arguments and results are handled
> (this is why I have suggested an alignement proble
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-09-05 09:57 ---
Yes, I close it.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-09-05 10:02 ---
(In reply to comment #1)
> It's because of this in gcc/config/i386/mingw-w64.h:
>
> #define ASM_SPEC "%{v:-V} %{n} %{T} %{Ym,*} %{Yd,*} \
> %{Wa,*:%*} %{m32:--32} %{m64:--64}"
>
>
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-05 11:20 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Ok, could you sent a patch for it. It is pre-approved by me.
>
> I can't test it, have you?
>
I am retesting it. I think {v:-v} is be
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-09-05 13:14 ---
> I am retesting it. I think {v:-v} is better here.
This patch works fine. Could you post a patch for it. It is pre-approved.
Thanks,
Kai
Index: mingw-w6
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-09-06 08:52 ---
I tested a i686 mingw bootstrap for 4.4.x and it works for me.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-09-06 18:07 ---
I think I found the issue within gfortran for mingw. The issue is that off_t is
for mingw defined as 'long' (like _off_t). There is a 64-bit off64_t, which
holds in fact 64-bits and can be used with the fte
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-06 18:52 ---
(In reply to comment #7)
> (In reply to comment #6)
> > I think I found the issue within gfortran for mingw.
>
> I think you have this backwards. "the issue within mingw
> for gfor
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-06 20:05 ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > I think I found the issue within gfortran for mingw.
>
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-09-08 15:35 ---
Fixed by revision 151515 for 4.5 version.
As this bug depends to new config/stdint.m4 and 2.64 support in gcc configure,
this won't be backported to 4.4.x
--
ktietz at gcc dot gnu dot org ch
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-*-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41315
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-09 08:48 ---
I am preparing a patch for this for 4.4.x and for trunk. At the moment
bootstrap is running for them. I'll sent them to ML.
Kai
--
ktietz at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-09-09 13:43 ---
Passed regression tests. Sent patch to ML at
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00593.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41315
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-09-09 19:10 ---
Applied to 4.4.x branch at revision 151571, and to trunk at revision 151570.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-09-10 09:33 ---
This feature was added to 4.4.0 and there are now format specifiers for ms and
gnu printf/scanf styles.
As this feature won't be backported to 3.4.0, this bug should be closed.
Danny any objections about
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-09-12 09:54 ---
I tested this bug for 4.5 and here it seems to be solved for i686-pc-mingw32.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-09-12 10:55 ---
I added you to this thread, as you merged new pseudo-relocation code to
mingw.org's runtime.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |
--- Comment #13 from ktietz at gcc dot gnu dot org 2009-09-13 08:19 ---
(In reply to comment #12)
> > > Well, in fact it is MS here. But we on mingw-w64 think at the moment
> > > about
> > > to add an override option for this by defining _LARGE_FILES
&g
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-09-13 17:43 ---
(In reply to comment #2)
> (In reply to comment #1)
> > You didn't say how you configured it.
> > As with bug 40950, you might need --enable-stage1-languages=c,c++
>
> Sorry, it was
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-19 14:32 ---
(In reply to comment #7)
> I recompile the whole toolchain using today's newest code, the same result,
> cross compiler runs fine, native compiler runs crash.
>
I retested your example with current t
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-20 09:24 ---
Fixed on trunk at revision 151895.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-20 11:24 ---
(In reply to comment #3)
> Will have to be tested again once PR 39886 is done with; hopefully, should
> then
> be gone.
>
As 39886 is fixed on trunk. Could you please verify if it was an duplic
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-20 17:26 ---
*** Bug 40364 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-09-20 17:26 ---
I tested your attachment against patched trunk and fix of PR/39886 resolved it.
So I mark it as duplicate.
*** This bug has been marked as a duplicate of 39886 ***
--
ktietz at gcc dot gnu dot org changed
--
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-09-21 17:36 ---
By using this code and compiling with gcc test.c -O2 I can reproduce this for
i686-pc-linux, x86_64-pc-linux, x86_64-pc-mingw32, and for i686-pc-mingw32.
--
ktietz at gcc dot gnu dot org changed:
What
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-09-27 09:25 ---
The new attribute "basetype_mode" (see
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
provide a way to solve this, as it makes sure that it is associated to the base
type, inst
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-27 09:28 ---
(In reply to comment #7)
> The new attribute "basetype_mode" (see
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
> provide a way to solve this, as it makes sure that
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-27 09:59 ---
Closed this bug. As it is solved. At least provide testcase doesn't ice with
native gcc for w64 anymore.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-27 10:03 ---
I tested given scenario and g++ could find the headers in Stage 2 (using msys
make). So this seems to be a configure/environment setup issue, if it still
exists for you.
--
ktietz at gcc dot gnu dot org changed
--
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=18882&action=view)
Patch for enable for mingw32 targets -fset-stack-executable
Changelog
* config/i386/mi
--- 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 |
--- 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 cu
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-03-05 10:04 ---
(In reply to comment #5)
This patch has a problem about the printf formatter definitions in
libgfortran.h header. So I suggest to use the following patch instead.
I am current on to bootstrap it completely and test
--- Comment #7 from ktietz at gcc dot gnu dot org 2010-03-05 10:34 ---
(In reply to comment #6)
As by this patch libgfortran.h defines _POSIX, some additional features (at
least for mingw-w64) getting active about localtime_r and gmtime_r (which
getting implemented by defines, if
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-03-06 07:21 ---
Created an attachment (id=20034)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20034&action=view)
Patch about printf and POSIX float conversion
2010-03-06 Kai TIetz
PR/42950
* libgfo
--- Comment #10 from ktietz at gcc dot gnu dot org 2010-03-08 08:03 ---
(In reply to comment #9)
> Kai,
>
> Patch in Comment #8 is OK to commit. Thanks!
>
> (I also regression tested on x86-64-linux-gnu.)
>
Ok, applied at revision 157271.
Patch for enumerat
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-03-12 08:57 ---
The follow-up patch about those collision in enumerator names is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00427.html to gcc's patch-ML.
The only issue remaining open for mingw/cygwin targets
NCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43356
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-03-13 14:26 ---
Created an attachment (id=20100)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20100&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43356
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-03-14 08:20 ---
Correct, the fmod-family was marked as pure, which is obviously wrong.
Thanks,
Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-03-23 12:32 ---
(In reply to comment #7)
> An updated patch is at
>
> http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00937.html
>
Patch is fine. It is absolutely necessary to support gcc's intrinsic heade
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-03-26 12:14 ---
The assert here is just in respect to comment "Only valid for Win32.". Just
win32 targets are providing for gcc a __chkstk implementation. So I think it
was the reason for this assert. But AFAICS there i
--- Comment #7 from ktietz at gcc dot gnu dot org 2010-04-05 09:17 ---
(In reply to comment #6)
> I added you to this thread, as you merged new pseudo-relocation code to
> mingw.org's runtime.
>
As cygwin and mingw.org are supporting now new linker generated
runtime-pse
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-04-09 14:26 ---
Suggested fix for this issue posted to ML at
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00426.html
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
101 - 200 of 291 matches
Mail list logo
