--- 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.00
--- 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
--
--- 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=revision&revision=148199
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Rem
--- 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 #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=releas
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-11-29
17:36 ---
see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c9
and discussion of
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html
I think that patch should go into 4.5
Danny
--
http
--- 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
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
CC||dannysmith at users 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:_ZNK2D1
--- 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 #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
--- 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
--- 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 Releas
--- 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 cross
--- 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.
: 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 #6 from dannysmith at users dot sourceforge dot net 2009-05-28
08:26 ---
(In reply to comment #4)
> Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables
> __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it
>
--- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-13
08:12 ---
(In reply to comment #5)
> Also, I don't think this is necessarily an either-or situation; we could add
> my patch and have the typeinfo exported from the DLL, and also add yours so
>
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-05-10
05:01 ---
(In reply to comment #3)
> Created an attachment (id=17841)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view) [edit]
> inherit dllexport from class to typeinfo
>
--- Comment #12 from dannysmith at users dot sourceforge dot net
2009-05-01 19:48 ---
(In reply to comment #11)
> (In reply to comment #9, comment #10)
> I did not build MinGW 4.3.0. I got it from the official MinGW site
> (gcc-4.3.0-20080502-mingw32-alpha). I have also foun
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Component|target |libgomp
Target Milestone
--- Comment #10 from dannysmith at users dot sourceforge dot net
2009-04-30 21:07 ---
(In reply to comment #9)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Your libpthreads is doing something wrong.
> > > Re. comment 5
> > The comm
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-04-30
20:57 ---
(In reply to comment #6)
> (In reply to comment #4)
> > Your libpthreads is doing something wrong.
> > Re. comment 5
> The command was actually
> gcc -fopemnp test.c -lgomp -o test
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29
07:29 ---
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
--
dannysmith at users dot sourceforge dot net ch
--- Comment #15 from dannysmith at users dot sourceforge dot net
2009-04-21 07:01 ---
(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 experime
--- Comment #53 from dannysmith at users dot sourceforge dot net
2009-04-16 02:59 ---
This thread is alos relevant.
http://gcc.gnu.org/ml/gcc/2009-04/msg00462.html
Adding Dave Korn to cc:
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-08
08:12 ---
Fixed.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-04-02
04:20 ---
(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
--- Comment #13 from dannysmith at users dot sourceforge dot net
2009-03-28 07:24 ---
(In reply to comment #12)
> Both the dg-error clauses now fail; previously (4.3.2), only the second one
> failed. Reverting the patch causes the first dg-error (line 21) to pass again
> by
--- Comment #11 from dannysmith at users dot sourceforge dot net
2009-03-23 22:10 ---
(In reply to comment #10)
> Note that C++ objects need not be larger than 8 bytes to qualify for returning
> on the stack (and thus subject to this cleanup problem). Any class with
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-21
01:03 ---
(In reply to comment #7)
> The proposed patch works for plain C code, but also affects C++. Since
> libstdc++ contains code that returns aggregates or calls code that does,
An example, please
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-16
02:13 ---
(In reply to comment #7)
> The following patch solves this problem and prevents the name collision for 32
> and 64 bits win32 systems.
>
> ChangeLog
>
> * c
--- Comment #1 from dannysmith at users dot sourceforge dot net 2009-03-11
02:41 ---
This is fixed in 4.3.x by
2006-11-20 Carlos O'Donell
Mark Mitchell
* cppdefault.c: Define cpp_PREFIX, cpp_PREFIX_len, and
gcc_exec_prefix.
(cpp_relo
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-09
07:52 ---
>From gcc.info:
*Warning:* the `-fpack-struct' switch causes GCC to generate code
that is not binary compatible with code generated without that
switch. Additionally, it makes
--- Comment #13 from dannysmith at users dot sourceforge dot net
2009-03-09 07:46 ---
(In reply to comment #12)
> Was this broken in 4.3 compilers? Is it a 4.4 regression?
>
This is not a new bug in the compiler (the same multiple definition will occur
with 3.4.5) , but
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-28
02:38 ---
Created an attachment (id=17376)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17376&action=view)
testcase executable built on mingw32
testcase executable built on mingw32 attached
--
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-02-25
02:28 ---
I get this with your testcase on mingw32, DW@ build:
GNU C (GCC) version 4.4.0 20090221 (experimental) (mingw32)
gcc -fexceptions -g u.c
foo:enter
bar:enter
zoo:enter
boom!
signalHandler:enter
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-03
02:02 ---
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -quiet -v -D__CYGWIN32__
> -D__CYGWIN__ -Dunix -
> D__unix__ -D__unix -idirafter
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../inclu
--- Comment #7 from dannysmith at users dot sourceforge dot net 2009-01-29
01:57 ---
(In reply to comment #6)
> This bug is fixed and should be closed now. A new PR, bug 37660, has been
> created for the separate issue in comment 4.
>
Closing
--
dannysmith at
--- Comment #7 from dannysmith at users dot sourceforge dot net 2009-01-26
03:30 ---
AFAICT DW2 unwind has never worked on x86_64-mingw32, which is why Kai made
sjlj the default EH model for that target.
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00273.html
--
dannysmith at users
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-01-23
18:53 ---
There is an alternative patch at
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00044.html
which i had forgotten about. It has been tested on i686-pc-mingw32 and
i686-pc-linux
--
http://gcc.gnu.org
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-01-20
06:07 ---
libstdc++ also needs to be built and linked in as dll.
Search mingw archive lists for other examples and approaches.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-19
04:22 ---
(In reply to comment #7)
> Created an attachment (id=17132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> Move _ctors* and _chkstk* to import lib
>
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-01-16
07:14 ---
(In reply to comment #4)
> I've just run into this problem too.
> In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
> chkstk.o and placed them whole
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-01-15
02:39 ---
I believe that this failure reflects the fact that PE_COFF dll's do not allow
undefined symbols. Because of that, the rule to decide shared vs static libgcc
in gcc.c init_gcc_spec, namely the
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-13
07:43 ---
Fixed on trunk.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-01-12
02:07 ---
(In reply to comment #8)
> still unfixed?
Please provide a compilable self-contained testcase.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-01-08
08:41 ---
Created an attachment (id=17052)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17052&action=view)
Replace execvp with pex_one in process_command
Patch uses pex_one as per Ian Taylor sug
--- Comment #11 from dannysmith at users dot sourceforge dot net
2009-01-07 07:47 ---
Fixedd on 4.3 branch
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from dannysmith at users dot sourceforge dot net 2009-01-06
03:49 ---
Confirmed on SVN head.
This also avoids the bug.
//
class E
{
};
class Test
{
public:
__fastcall bool ernie(bool b) throw(E)
{
}
__fastcall bool bert(bool b
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-02
04:19 ---
Hello John,
This patch:
Index: gcc/config/i386/winnt-cxx.c
===
--- gcc/config/i386/winnt-cxx.c (revision 142383)
+++ gcc/config/i386
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-12-19
23:01 ---
Patch for this was submitted 4 months ago:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01143.html
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #9 from dannysmith at users dot sourceforge dot net 2008-12-14
05:54 ---
(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 al
--- Comment #13 from dannysmith at users dot sourceforge dot net
2008-12-04 07:16 ---
Fixed in 4.3.3
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #11 from dannysmith at users dot sourceforge dot net
2008-12-02 08:05 ---
I have committed a patch to 4.4.0 to fix bug in compilation of desktop.cpp
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #33 from dannysmith at users dot sourceforge dot net
2008-11-24 06:41 ---
(In reply to comment #32)
> I've been told that this is related to the test case I just attached
Your testcase is more closely related to PR 38054.
Danny
--
http://gcc.gnu.org/
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-21
05:51 ---
(In reply to comment #4)
> Creating library file: .libs/libssp.dll.a
> .libs/ssp.o: In function `fail':
> /home/vmk/gccdev/gcctr11/gcc/libssp/ssp.c:109: undefined reference to
> `_
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-18
06:26 ---
Hello Murali,
Does the patch for PR 38130 fix the build of libstdc++ on cygwin?
http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713&action=view
Danny
--
dannysmith at users dot sourceforge
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-18
05:55 ---
(In reply to comment #4)
> Created an attachment (id=16713)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713&action=view) [edit]
> gcc44-pr38130.patch
>
> I've talked
ailures on mingw32
Product: gcc
Version: 4.4.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 tr
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-11
06:27 ---
(In reply to comment #3)
> Patch at:
> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html
>
That patch also fixes the FAIL of testsuite\g++.old-deja\g++.dg\other>g++
pr35504.C .
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-09
08:24 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-09
08:20 ---
This a target bug (stdcall symbol name decorati0on on windows targets)
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-04
02:21 ---
Fixed by Mikael's patch
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-03
07:45 ---
Created an attachment (id=16614)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16614&action=view)
revised patch to quard with ENABLE_SHARED_LIBGCC
Hi Mikael,
I have modified your patch s
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #41 from dannysmith at users dot sourceforge dot net
2008-10-06 20:18 ---
(In reply to comment #35)
> As I suspected. The PE/COFF file format does not provide for specifying
> the alignment of commons.
>
> Hmm, I wonder if gcc should complain if it finds ali
--- Comment #10 from dannysmith at users dot sourceforge dot net
2008-10-02 08:47 ---
Fixed on mingw32 at revision 140803.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-10-02
00:20 ---
In reply to comment #4)
> xgcc: error trying to exec
> '/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe': execv:
> Permission denied
>
This may be related to:
htt
--- Comment #27 from dannysmith at users dot sourceforge dot net
2008-10-01 10:22 ---
(In reply to comment #13)
> Created an attachment (id=16425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425&action=view) [edit]
> Revised patch with correct section switching
--- Comment #26 from dannysmith at users dot sourceforge dot net
2008-10-01 01:33 ---
(In reply to comment #14)
> Hi Guys,
>
> I am not able to reproduce the build problems that were reported with the
> first version of my patch, but then again I do not have a native
--- Comment #19 from dannysmith at users dot sourceforge dot net
2008-09-29 18:43 ---
Created an attachment (id=16427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16427&action=view)
Nick's aligned common testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-26
03:15 ---
This is duplicate of 34749
*** This bug has been marked as a duplicate of 34749 ***
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-09-26
03:15 ---
*** Bug 37652 has been marked as a duplicate of this bug. ***
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-24
03:12 ---
This bug is linker related. It is fixed on 32-bit windows by this patch
http://sourceware.org/ml/binutils-cvs/2007-10/msg2.html
Have you tried with recent binutils and explict -Wl,--enable-auto
--- 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++&#
--- 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
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- 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
--- 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 ap
--- 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 t
--- 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 #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
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 #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
--- 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-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&#x
--- 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\incl
--- 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
--- 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
--- 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-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 #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'
--- 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=15702&action=view) [edit]
> Minimal testcase for vtable issue
>
> I
--- 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 #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
res
--- 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
1 - 100 of 342 matches
Mail list logo
