--- 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
ditto with
g++ -c -x c
--- 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 this alternative
--- 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-dllimport
type of flag to mingw
--- 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 precision
--- 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 mode
--- 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 version 4.2.0
--- 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):
$ cat ctesti.c
#include
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/bugzilla/show_bug.cgi?id=29094
--- 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 bit
--- 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_FUNCTIONS set to 1?
Yes
--- 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/bugzilla
--- 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
void
--- 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 to enable
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc
--- 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 reply
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-02-15 06:41 ---
Q: As a (new/cautious) target co-maintainer, is this within my domain to fix
without seeking approval?
This is not a regression, so I assume it would wait until after branching.
Correct
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-01 04:49 ---
The problem appears to be that the file stage1/ada/b_gnatb.c built by the
bootstrap gnatbind doesn't define the ponter to the exception registration
structure (SEH). This :
int SEH [2
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-05 10:45 ---
Other utilities that are documented in gnat_ugn.texi
gnatpp (gnat pretty)
gnatstub
gnatmetric
are not built in FSF tree.
Nor is there any documentation on where these utilities are available
--
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
http
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-18 04:23 ---
The IS_TARGET_PE_COFF hack works on 3.4.x bit won't on trunk.
Here is a cleaner patch against trunk that replaces the preprocessor tests
with runtime tests. I have tested with nativr mingw
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-19 11:14 ---
IMO, resetting the error code set by the kernel whenever the internal Ada
tasking functions are called successfully is a bug. It can be easily fixed:
* s-osinte-mingw.ads
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-19 20:54 ---
In reply to comment #3
From gnat_ugn.texi:
@findex Stdcall
@cindex Convention Stdcall
@item Stdcall
This is relevant only to NT/Win95 implementations of GNAT,
and specifies that the Stdcall
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-20 01:26 ---
Oops, I had split up the patch into a non-critical (as far as
this bug report is concerned) part and a critical part, but messed up when
I pasted into bug report.
Following is the part
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-26 20:41 ---
-I. -I -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/
^^
This looks a lot like PR12974
See comment #19
There may be a second problem here
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-28 08:38 ---
See also PR20160
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20654
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-04-07 08:29 ---
So, what about the proposal on #4 ?
OK with me.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
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=20806
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-04-07 08:35 ---
This optimization in basic_filebuf::xsgetn() causes problems on DOS based file
sytstem when ifstreams are opened in text mode (\r\n line endings) and the
user suppled buffer length exceeds
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-04-29 06:11 ---
Here is reduced testcase:
// int attribute ((dllimport)) foo;
extern int* _imp__foo;
int a = *_imp__foo;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-04-30 09:08 ---
Oops, I reduced the code in comment #1 too much. This shows the problem.
//dllimport_array.C
// This causes 'initializer element is not constant' error in C
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-01 08:00 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-12 10:14 ---
(In reply to comment #4)
The patch for 21275 failed to take care of C++ class members which inherit a
dllimport attribute from the class type definition.
Here is a C++ testcase:
struct
: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-16 07:52 ---
The patch in comment #3 isn't sufficient for cases where C++ class members get
their dllimport status from attribute applied to class type, rather than from
explicit attribute on the member
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-20 21:17 ---
A patch was submitted here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01794.html
and a different one here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02074.html
Danny
--
http
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-26 21:01 ---
New patch submitted here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02543.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-30 02:55 ---
Hello, this is a mingw runtime bug. The mingw version of mcount does not take
enough care with saving call-clobbered registers. Please close this bug and
submit to mingw.org.
Danny
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-30 21:03 ---
I can't reproduce this with either gcc-3.4.4 or 4.0.0 on mingw
The example gives the warning
warning: 'i' might be used uninitialized in this function
iff I add -Winit-self
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-31 01:22 ---
The MKDIR_TAKES_ONE_ARG that is defined for mingw in auto-host.h is a host
define.
In jartool.c (and in libgcc files - cf PR/21597) we need a target define.
Perhap targets such as mingw
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-31 09:45 ---
Try changing --enable-shared to --disable-shared when configuring. Building
shared libgcj with libtool doesn't really work on windows targets. You could
try using Mohan Embars scripts
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-01 21:02 ---
The patch referred to in comment #9 had missing hunks.
Complete patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02945.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-09 20:33 ---
Re; comment #4
There should be no need te test for io.h for the sake of mingw
libgcov.c already includes tsystem.h
tsystem.h includes unistd.h.
On mingw, unistd.h includes io.h
Danny
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-09 20:41 ---
The patch is not right.
mingw doesn't have a NATIVE_SYSTEM_HEADER_DIR.
Header dirs are found relative to the path to the gcc.exe bin directory, so
specifying /mingw/include
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-10 03:03 ---
Re:Comment #4
Does mount win32_path_to mingw_include_dir /usr/include work with MSYS?
Or just create an empty /usr/include
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19607
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-12 05:18 ---
Hi,
I think the problem is that
st.m_i = 1;
st.m_ch[0] = 0;
causes gcc to generate a call to the library memcpy. Since the -mrtd switch is
in effect, the call is generated
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-12 09:39 ---
Hi,
This is what is says in the comments above i386/i386.c:
ix86_return_pop_args:
FUNDECL is the declaration node of the function (as a tree),
FUNTYPE is the data type of the function
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-13 22:05 ---
The patch is still not correct. It doesn't handle dllimport override semantics.
See g++.dg/ext/dllimport-3.C which fails because TREE_INVARIANT and
TREE_CONSTANT change when we lose
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-06-25 12:20 ---
The patch that was committed to fix this is wrong.
#ifdef TARGET_DLLIMPORT_DECL_ATTRIBUTES is always true. It is defined to 0 for
non-dll targets in defaults.h.
Why not make this a runtime
--- 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't
--- 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
: 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 host triplet: i686-pc
--- 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
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/show_bug.cgi?id
--- 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.
Danny
--
http
--- 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
--- 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
--- 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:\tmpG++ -Wall -W test.cpp
c:\tmp/ccOGb2M9.o:test.cpp:(.text+0x1e): undefined reference
--
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.
Danny
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=28427
--- 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
--- 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
] Missing dllimport diagnostic
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: target
AssignedTo: dannysmith at users dot sourceforge dot net
--- 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, and any optimization
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://gcc.gnu.org/bugzilla
--- 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
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.gnu.org/bugzilla
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-12-10 23:11 ---
Ugh, I see what is wrong with the patch I posted at:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02192.html
* config/i386/cygming.h (TARGET_USE_JCR_SECTION): Overide
default
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-12-12 21:03 ---
small win32 binaries do run, but when I compile my large app (which
uses swt), it still isn't recognized as a win32 app (app.exe is not a valid
win32 application) unless I 'strip' it. I
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-12-16 02:41 ---
Patch submitted.
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01184.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18997
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-12-14 19:58 ---
What happens if you revert this patch
http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00265.html
Alternatively, does adding
#define GTHREAD_USE_WEAK 0
to config/i386/cygwin.h
and
to libstdc++-v3
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-12-28 04:29 ---
Richard Hendeerson's patch in comment #26
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01983.html
fixes mingw bootstrap with -gdwarf-2
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
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=19309
--
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
http
: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-01-31 05:55 ---
Fixed on mainline.
Should this also be applied be applied to 3_4-barnch (assuming regtesting is
OK), where the bug also exists?
Danny
--
What|Removed
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-08-20 11:27 ---
Fixed on mainline.
The libiberty part of this patch had already been approved and committed on
2004-06-29.
Soory, I can't change PR status, because email ID under which I submitted this
bug
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-10-14 11:28 ---
Refreshed patch (with missing files) here:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01172.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14316
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-10-25 08:14 ---
Compiling charset.c with -O2 -fno-unit-at-a-time with newly built cc1.exe also
avoids the bug.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18139
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-10-26 02:26 ---
A data point:
Free/OpenBsd and windows targets differ drom i386-linux in defining
#define DEFAULT_PCC_STRUCT_RETURN 0
which affect aggregate_value_p and thus gimplify_return_expr.
Compiling
1 - 100 of 340 matches
Mail list logo
