--- 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 __attribute__((__gnu_inline__
--- Comment #7 from dannysmith at users dot sourceforge dot net 2007-01-01
01:53 ---
I am not in position to test this on Vista until next week. Can you please
indicate how you tested.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-11-24
07:43 ---
This works for me too, using same cygwin distro of gcc-3.4.4, same command line
(g++ -Wall -o Employee.h Employee.h -mno-cygwin), cygwin version 1.5.22.
Could it be a mmap vs .pch problem
--- 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
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 #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
--- 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
--
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 #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
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-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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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-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
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
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
--- 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
] 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 #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
--- 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 #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
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 #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
--- 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 #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 #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 #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
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 #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
--- 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 #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
: 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 #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
--- 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 #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
--- Comment #7 from dannysmith at users dot sourceforge dot net 2005-10-31
04:30 ---
This is an i386 bug, not specific to MS windows target. However, it is only a
problem with -mtune=i386 -mrtd.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
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/show_bug.cgi?id=24439
--- Comment #18 from dannysmith at users dot sourceforge dot net
2005-10-15 22:43 ---
(In reply to comment #17)
Danny, is it possible to have a less invadent fix for the 4.0 branch?
Something
hackish that can get the bug fixed just for the branch...
I'll have a look when I have
--- Comment #18 from dannysmith at users dot sourceforge dot net
2005-10-12 20:56 ---
Fixed in trunk.
http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00474.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21081
--- Comment #15 from dannysmith at users dot sourceforge dot net
2005-10-12 20:58 ---
Fixed on trunk.
http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00474.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Comment #31 from dannysmith at users dot sourceforge dot net
2005-10-12 20:58 ---
Fixed on trunk.
http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00474.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
--- Comment #6 from dannysmith at users dot sourceforge dot net 2005-10-12
20:59 ---
Fixed on trunk.
http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00474.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23589
--- Comment #7 from dannysmith at users dot sourceforge dot net 2005-10-12
21:03 ---
Now fixed on trunk for C++ too.
http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00474.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19704
--- Comment #29 from dannysmith at users dot sourceforge dot net
2005-10-11 08:01 ---
Updated patch here.
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00565.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
--- Comment #7 from dannysmith at users dot sourceforge dot net 2005-10-12
01:01 ---
(In reply to comment #6)
Is this still broken?
No.
It was fixed by this:
2005-07-13 H.J. Lu [EMAIL PROTECTED]
* config/alpha/linux.h (TARGET_HAS_F_SETLKW): Renamed
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-09-14 23:53 ---
(In reply to comment #0)
mingw sets the USERNAME environment variable, we should use it to provide a
getlog procedure.
NT and later set USERNAME by default. win95, win98 do not. The var may
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-08-27 04:44 ---
Thisis a dllimport bug. In this case the template member
template class pointIterator
Point::Point(pointIterator ptStart, pointIterator ptStop)
is being marked as dllimport. Later
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-08-14 07:29 ---
I don't know why you say that MingW claims to have a HAVE_TIMES. It doesn't.
To get process times on mingw we need to use the win32api function
GetProcessTimes. This is available on NT4
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-08-14 20:56 ---
From my libgfortran/config.h, configured with --host=mingw32 --target=mingw32
and mingw runtime as distributed by mingw.org
/* Define to 1 if you have the `getrusage' function. */
/* #undef
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-07-31 00:56 ---
This may be the problem:
In mk-kinds-h.sh:
case $largest_ctype in
float) echo #define GFC_REAL_LARGEST_FORMAT \\ ;;
double) echo #define GFC_REAL_LARGEST_FORMAT \l\ ;;
long double) echo
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-07-09 23:11 ---
mingw runtime does not have struct stat64 or fstat64(), so this define is not
correct. In fact the native build of libstdc++ fails the _GLIBCXX_USE_LFS
configure test.
(mingwt does have
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-07-07 07:56 ---
Duplicate of PR 20654
libtool patch at:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02804.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22338
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-07-02 02:49 ---
A workaround is to specify the full path to as in configure script, eg
--with-as=/mingw/bin/as.exe --with-ld=/mingw.bin/ld.exe --
with /nm=/mingw/bin/ld.exe
Danny
--
http://gcc.gnu.org
--- 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
--- 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-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-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-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-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-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-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-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-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-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-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
: 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-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
--- 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-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-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-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-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-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-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
201 - 300 of 340 matches
Mail list logo
