--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-27
06:03 ---
Changed summary to be more precise about non-standard.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-05-11
21:09 ---
Fixed on 4_3 branch
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-05-11
22:46 ---
Following is with mingw but it applies to cygwin as well
This is the command line from log for FAILing 22_locale/locale/cons/unicode.cc
Executing on host: /develop/svn/trunk/build/./gcc/g++ -shared
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-05-13
03:52 ---
(In reply to comment #0)
What negative consequences does increasing the default [stack]
allocation have?
Minimal really, for a single threaded program like jc1.exe. We are just
reserving address
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-05-17
07:27 ---
Is this related to PR35493?
A possibly related cygwin failure was also reported here.
http://gcc.gnu.org/ml/gcc/2008-03/msg00681.html.
My last successful build of Ada on mingw was:
gcc version 4.4.0
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-05-29
21:00 ---
(In reply to comment #7)
Created an attachment (id=15702)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15702action=view) [edit]
Minimal testcase for vtable issue
I'm not sure whether
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-03
03:17 ---
Although config/mh-mingw has
BOOT_CFLAGS += -D__USE_MINGW_ACCESS
as a fix for PR33281,
CFLAGS_FOR_TARGET for mingw32 also requires this define, else libiberty's
make_relative_prefix won't work
--- Comment #11 from dannysmith at users dot sourceforge dot net
2008-06-04 08:22 ---
This fixes for me on Vista host. Can someone confirm?
config/ChangeLog
PR35916
* mh-mingw (CFLAGS): Add -D__USE_MINGW_ACCESS.
Index: config/mh-mingw
--- Comment #13 from dannysmith at users dot sourceforge dot net
2008-06-05 06:23 ---
Closing, as this is fixed on trunk.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #11 from dannysmith at users dot sourceforge dot net
2008-06-07 00:46 ---
Fix backported to branch.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-07-30
08:00 ---
(In reply to comment #2)
Is it possible that it triggers the exception trying to write in text.unlikely
which is READONLY?
Exactly. This is a linker, not a compiler issue. If you are using
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-07-31
04:18 ---
(In reply to comment #0)
I was not able to reproduce the bug on Linux, so I assume this is a
Windows-specific.
If an exception is generated inside shared library (DLL), then crosses the
DLL
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-08-02
08:57 ---
(In reply to comment #3)
I'm linking using g++ driver, so shared libgcc is enabled by default in 4.4.0.
I've just tried to enabled shared libstdc++ as described in the Release Notes
to the MinGW
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-08-05
04:55 ---
(In reply to comment #6)
(In reply to comment #5)
Applying Dave Korn's patch mentioned in Comment #2, and linking against
libstdc++.dll, I get this with your original testcaase:
Expecting
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-08-24
06:15 ---
(In reply to comment #2)
(In reply to comment #0)
The following SSE2 code crashes because the non-static global variable
breaks
the alignment of the static data section.
Is this fixed if you
--- Comment #30 from dannysmith at users dot sourceforge dot net
2009-09-07 04:01 ---
(In reply to comment #24)
Subject: Re: [4.5 Regression] crashed compile Qt4 gui
library
On Sun, 6 Sep 2009, t7 at gmail dot com wrote:
--- Comment #22 from t7 at gmail dot
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-10-03
21:47 ---
(In reply to comment #0)
These new FAILs have been appearing on trunk since some time between 20090820
and 20090903:
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D12vfEv
FAIL: g
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
CC||dannysmith at users dot
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-10-07
03:06 ---
Fixed at revision 152511.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #11 from dannysmith at users dot sourceforge dot net
2008-06-14 10:01 ---
(In reply to comment #6)
Note that a native build should be done to verify that my patch increases the
stack limit enough to fix this bug, before marking it fixed.
With this patch (8 mb stack
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-06-15
05:31 ---
(In reply to comment #0)
make[3]: Leaving directory `/f/_Builds/gcc-4.3.1-build/gcc'
It appears that you are building on drive F:. I'd guess that /mingw/include
(== F:\mingw\include to the OS) does
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-23
02:54 ---
Using \r\n will cause problems with pch files.
This is why I made this change
2004-06-05 Danny Smith [EMAIL PROTECTED]
* toplev.c (init_asm_output): Add explicit 'b' to mode when
--- Comment #12 from dannysmith at users dot sourceforge dot net
2008-06-28 07:53 ---
*** Bug 36654 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-28
07:53 ---
This is duplicate of 35921 and is fixed on 4.3.2 and trunk.
*** This bug has been marked as a duplicate of 35921 ***
--
dannysmith at users dot sourceforge dot net changed:
What
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-07-15
09:29 ---
Testing a patch to add a new switch for windows targets.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-07-17
08:16 ---
Patch submitted
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01250.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-07-20
09:58 ---
(In reply to comment #3)
This is untested, but you get the idea.
+ setlocale(LC_ALL, POSIX);
mingw's setlocale doesn't believe in POSIX ; it does however go to the ISO
C89 church, and has
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-08-01
04:34 ---
This kind of path
'--prefix=/c/_GccBuilds/gcc-4.3.1-install/mingw-32-i686' may be understood by
your shell, but won't be found by the xgcc driver or cc1.exe which are native
windows apps. Search
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-15
02:57 ---
I guess the solution is to make libstdc++ use _vsnwprintf instead of vswprintf
on *-mingw32.
I think that is the most expedient solution. Would an inline redirection of
vswprintf
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-09-22
03:09 ---
Fixed at revision 140541.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-09-22
03:23 ---
I have run into what I believe is the same bug in build of of cc1plus.exe, with
miscompilation of cp/pt.c
When exercising cp/pt.c:process_partial_specialization (eg, when compiling
libstdc++'s
--- Comment #13 from dannysmith at users dot sourceforge dot net
2010-04-04 08:20 ---
(In reply to comment #11)
(In reply to comment #10)
And while the compilation time change alone
How did you configure 4.5? Did you use --enable-checking=release ? If not
then the compile
--- Comment #6 from dannysmith at users dot sourceforge dot net 2010-04-15
07:54 ---
(In reply to comment #1)
FIONREAD is defined by winsock header
How come your build of basic_file_stdio includes winsock api headers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #7 from dannysmith at users dot sourceforge dot net 2010-04-26
08:19 ---
This is fixed in 4.5.0 release.
http://gcc.gnu.org/viewcvs?view=revisionrevision=148199
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #15 from dannysmith at users dot sourceforge dot net
2010-04-30 03:02 ---
(In reply to comment #13)
Kai, what about the GetTempPath? Cf. the rough draft in attachment 20460
[edit] ?
Compare choose_tmpdir() in libiberty/make_temp_file.c
Danny
--
http://gcc.gnu.org
--- Comment #17 from dannysmith at users dot sourceforge dot net
2010-05-18 22:43 ---
(In reply to comment #14)
Index: gcc/gcc/varasm.c
===
--- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
+++ gcc
301 - 340 of 340 matches
Mail list logo
