--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-04-16
05:14 ---
The DECL_ASSEMBLER_NAMES of these stdcall virtaul methods do not get
decorated in time for cp/method.c:make_alias_for_thunk.
(cf this comment in varasm.c: find_decl_and_mark_needed:
/* We can&#
--- Comment #5 from dannysmith at users dot sourceforge dot net 2006-05-22
21:19 ---
This is a dllimport bug. Dllimports do not have constant address. Hence class
vtable cannot contain a method with dllimport attribute
I am working on a patch.
Here is reduced testcase
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Product: gcc
Version: 4.2.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
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-05-29
22:23 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-05-30
22:33 ---
Working on it.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-06-04
11:02 ---
In my local tree (and in the 3.4.x mingw tree), I have added a modification and
extension of this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02296.html
I plan to follow up in stage 1 of 4.3
ity: normal
Priority: P3
Component: c
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-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-06-08
10:29 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00389.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27789
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-06-08
22:32 ---
(In reply to comment #1)
> Can you get me the size of that structure according to MS VC?
With version 12.00.8804 of MS cl.exe, sizeof (struct six) == 8, as tested in
the testcase.
Da
--- Comment #5 from dannysmith at users dot sourceforge dot net 2006-06-23
08:27 ---
Patch committed to trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-06-26
21:21 ---
I think you may be running into a compiler (MSVC vs GNUC) difference between
handling of __stdcall (==JNICALL) symbols.
For a function void __stdcall foo (int),
both MSVC and GNUC generate an
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-06-26
22:26 ---
(In reply to comment #3)
> I think you may be running into a compiler (MSVC vs GNUC) difference between
> handling of __stdcall (==JNICALL) symbols.
Um, and this should all be taken care of
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-06-28
09:52 ---
The mingw runtime library now has a gettimeofday function which should give
resolution to usec. When libgfortran is configured with the latest mingw
runtime package, gettimeofday is found and used
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-06-30
02:29 ---
Confirming
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-06-30
02:31 ---
... and closing.
Fixed by
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01511.html
Thanks Jason.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #11 from dannysmith at users dot sourceforge dot net
2006-06-30 02:42 ---
On today's trunk, your example no longer gives warnings. Instead it compiles,
then fails with:
C:\tmp>G++ -Wall -W test.cpp
c:\tmp/ccOGb2M9.o:test.cpp:(.text+0x1e): undefined refe
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #17 from dannysmith at users dot sourceforge dot net
2006-07-06 01:06 ---
On mingw32 the testcase will succeed on trunk if libstdc++ (and libgcc) are
built as dlls. Wouldn't that be the preferred solution? It also solves very
similar problems with EH data.
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-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
--- 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-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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
>
: 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.
--- 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 #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 #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 #9 from dannysmith at users dot sourceforge dot net 2005-11-04
09:15 ---
Hello,
mingw has an implementation of _IO_ldtoa() and _IO_ldtostr(), based on Stephen
Moshier's ioldoubl package, that could be used. Currently, the ldtoa function
is not exposed, but there
7;__FUNCTION__' is greater than
maximum object file alignment.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-07-20
02:31 ---
The bug appears to be that subtarget is just too mean with MAX_OFILE_ALIGNMENT.
Testing some (much) larger values.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-07-20
08:06 ---
config/i386/i386.c: ix86_data_alignment uses the magic number 256 as max_align
(except with -Os). However, MAX_OFILE_ALIGNMENT defaulted to BIGGEST_ALIGNMENT
windows32 targets. The PE COFF spec (and
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-08-02
09:56 ---
--disable-sjlj-exceptions in your configure options will cause serious problems
on cygwin unless you also provide support for enabling Dwarf2 EH frame.
Danny
--
http://gcc.gnu.org/bugzilla
rity: P3
Component: target
AssignedTo: dannysmith at users dot sourceforge dot net
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28627
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-08-07
21:04 ---
(In reply to comment #2)
> (In reply to comment #0)
> precisely, the bug can be reproduced with a combination of --march=pentium-m
> (or --march=pentium3 -msse2), -mfpmath=sse,387
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
Component: target
AssignedTo: dannysmith at users dot sourceforge dot net
ReportedBy: dannysmith at users dot sourceforge dot net
GCC host triplet: i386-pc-mingw32
http://
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-08-08
09:08 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00200.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28648
ity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gn
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-08-14
23:29 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00473.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28287
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-08-15
21:48 ---
Assigning to self so...
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #8 from dannysmith at users dot sourceforge dot net 2006-08-15
21:49 ---
Fixed on trunk
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-08-18
04:48 ---
Also, removing the space between '-x' and 'c++' works, eg,
g++ -fsyntax-only -xc++ stdio.h
but I get warning
warning: #pragma system_header ignored outside include file
ditt
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-08-20
08:48 ---
Fixed on trunk.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-08-22
00:37 ---
(In reply to comment #8)
> patch to prevent searching of configured path with relocated toolchain
Are you aware of this discussion
http://gcc.gnu.org/ml/gcc/2006-07/msg00313.html
and t
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-08-24
01:10 ---
This is my bad. Sorry. Should be fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2006-08/msg00514.html
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #11 from dannysmith at users dot sourceforge dot net
2006-08-25 00:27 ---
Fixed on mainline.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #14 from dannysmith at users dot sourceforge dot net
2006-08-27 21:14 ---
(In reply to comment #12)
> This happens with Qt4 Win32 as well - lot of warnings - "warning: inline
> function... attribute ignored". All that's needed is a -Wno-inline-dllimp
--- Comment #13 from dannysmith at users dot sourceforge dot net
2006-09-11 19:47 ---
In my sources for David Gay's gdtoa implemntation it say this:
/* On a machine with IEEE extended-precision registers, it is
* necessary to specify double-precision (53-bit) rounding prec
--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-09-12
23:36 ---
The problem is that although all 'regular' files are opened as O_BINARY,
preconnected files stderr and stdout are already opened as default O_TEXT.
The simplest fix is just to force the mod
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-09-13
03:59 ---
(In reply to comment #5)
> This is not DLL-related, the following code doesn't have the expected
> behaviour
> (although it works fine on i686-linux, even in the static case):
With gcc
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-13
10:10 ---
(In reply to comment #5)
> This is not DLL-related, the following code doesn't have the expected
> behaviour
> (although it works fine on i686-linux, even in the static case):
&g
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/b
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-09-15
03:34 ---
(In reply to comment #1)
> Is TARGET_C99_FUNCTIONS set for the mingw32 target?
It is set in my local development tree, and I was planning to set it in
mingw32.h config file, but I may be a
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-09-15
03:51 ---
(In reply to comment #3)
>
> If you are defining expf with TARGET_C99_FUNCTIONS set to 1, then you have to
> use -fno-builtin-exp.
> So just to make sure this is with TARGET_C99_FUNCTI
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-20
09:52 ---
(In reply to comment #6)
> I think this is fixed on 4.2:
Its still broken on my machine
Try after compiling the testcase with optimization turned on.
Danny
--
http://gcc.gnu.org/bugzi
--- Comment #11 from dannysmith at users dot sourceforge dot net
2006-09-20 23:37 ---
Fixed on trunk.
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 #12 from dannysmith at users dot sourceforge dot net
2006-09-23 02:00 ---
Fixed on trunk
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-09-23
06:34 ---
(In reply to comment #2)
> In a way this is a dup of bug 27537. Though there is an attribute to realign
> the stack in 4.2.0 so using that might just fix this issue instead.
Indeed,
5c5
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-27
03:23 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> Imagine building gcc itself with regparm 3. You probably don't want
> to mark up the gcc source
tex init vs
__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
Re
--- Comment #12 from dannysmith at users dot sourceforge dot net
2006-10-11 20:54 ---
(In reply to comment #4)
> - __gnu_cxx::__recursive_mutex static_mutex;
> + static __gnu_cxx::__recursive_mutex static_mutex;
I tried thaty before I submitted bug report. No dice.
(In re
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-01-26
00:24 ---
CVS mingw runtime header _mingw.h has this, which avoids the problem:
# if ( __MINGW_GNUC_PREREQ(4, 3) && __STDC_VERSION__ >= 199901L)
# define __CRT_INLINE extern inline __
--- Comment #10 from dannysmith at users dot sourceforge dot net
2007-01-27 10:06 ---
(In reply to comment #9)
> (In reply to comment #8)
> > So I still say we should just require makeinfo when building from
> > SVN/snapshot.
> > There is no reason not reall
--- Comment #9 from dannysmith at users dot sourceforge dot net 2007-02-02
19:31 ---
Created an attachment (id=12997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12997&action=view)
Patch for Vista/CreateFileMapping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335
--- Comment #10 from dannysmith at users dot sourceforge dot net
2007-02-02 19:32 ---
It seems strange to me that CreateFileMapping puts _unnamed_ object into Global
namespace. Can you point me to documentation for this feature?
If CreateFileMapping functionality has changed, maybe
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-02-22
01:32 ---
This testcase and the one in 27924 now compile successfully on
gcc version 4.2.0 20070218 (prerelease)
and
gcc version 4.3.0 20070218 (experimental)
on i686-pc-mingw32
Danny
--
http
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-02-25
03:39 ---
On trunk and 4.2.0 (target i686-pc-mingw32), invalid code is diagnosed
correctly:
fribidi_utils.c: In function 'fribidi_map_range':
fribidi_utils.c:72: error: 'fribidi_map_range&
--- Comment #10 from dannysmith at users dot sourceforge dot net
2007-03-10 01:51 ---
In dlls buit by MS windows native toolchain (eg the win32api system
libraries), exported functions are built with __stdcall calling
convention, but are exported without any decoration, eg, WinFooFoo
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-03-14
05:57 ---
This is a duplicate of PR 19774
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-03-20
08:21 ---
This is a dup of PR 29826.
The testcase (and 29826) succeeds on gcc version 4.2.0 20070319 (prerelease)
and on gcc version 4.3.0 20070318 (experimental) with mingw32
Danny
--
http://gcc.gnu.org
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-03-25
11:12 ---
http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
--
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 2007-04-03
09:54 ---
Duplicate of 29826 which is fixed on 4.2.0 and trunk.
Danny
*** This bug has been marked as a duplicate of 29826 ***
--
dannysmith at users dot sourceforge dot net changed:
What
--- Comment #10 from dannysmith at users dot sourceforge dot net
2007-04-03 09:54 ---
*** Bug 31457 has been marked as a duplicate of this bug. ***
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #14 from dannysmith at users dot sourceforge dot net
2007-04-20 07:49 ---
(In reply to comment #13)
> I'm going to try again since it seems my last post was just ignored.
> The test case works fine on 4.2 but it still occurs under some circumstances.
If
--- Comment #16 from dannysmith at users dot sourceforge dot net
2007-04-22 02:01 ---
Created an attachment (id=13403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13403&action=view)
Patch for testcase in 31636
Could you please test the attached patch to tree-ssa-ad
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-04-25
09:57 ---
Testing a patch.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-04-25
11:17 ---
Fixed.
Author: dannysmith
Date: Wed Apr 25 11:06:28 2007
New Revision: 124149
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124149
Log:
* config/i386/winnt.c (i386_pe_file_end
1 - 100 of 342 matches
Mail list logo
