--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-27
06:03 ---
Changed summary to be more precise about non-standard.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-04-26
07:23 ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
What is the status on this? Does reverting the langhooks.c change
remanifest
PR27067?
No. PR27067 is fixed
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-04-26
08:24 ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
What is the status on this? Does reverting the langhooks.c change
remanifest
$'
operand number formats
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-04-26
22:29 ---
Patch submitted at
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01977.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-26
03:17 ---
(In reply to comment #1)
What is the status on this? Does reverting the langhooks.c change remanifest
PR27067?
No. PR27067 is fixed by
cp/mangle.c (mangle_decl): Call
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-04-16
01:54 ---
(In reply to comment #5)
The issue is fixed for me when applying the mentioned patch to 4.3.0, so as
far
as I'm concerned we can close this bug as soon as someone applies the fix to
4.3 SVN
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-04-13
09:39 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01048.html
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #12 from dannysmith at users dot sourceforge dot net
2008-03-19 21:35 ---
(In reply to comment #11)
(In reply to comment #10)
Still, 4.3.0 can't recoginze %I64d
And that is because it is just being added:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01109.html
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-03-13
07:08 ---
Fixed for 4.4.0
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-03-03
03:32 ---
(In reply to comment #4)
A 65,000 line testcase? Seriously?
I'll try to make a smaller one. But it most likely won't be small.
I think the bug is caused by a VERY large expression used
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35273
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-21
06:53 ---
Fix typo in summary
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-02-14
08:14 ---
And just think of the havoc that will be caused with old mingw32 and cygwin
libs that depend on the _chkstk meaning of __alloca if you change __alloca
semantics.
eg there are 69 undefined references
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-02-14
17:46 ---
(In reply to comment #6)
I agree, that the havoc for 32-bit backward compatibility is to avoid.
But the havoc for windows sources using -fno-builtin and using _alloca () for
stack allocation
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-02-14
20:10 ---
(In reply to comment #7)
If someone really wants an MSCV compatible (one underscore) _alloca they just
add this to their srcs
void *_alloca (size_t size) {return __builtin_alloca (size));
Ugh
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-02-14
21:44 ---
Fixed
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-02-14
01:43 ---
Actually, I see this as unfortunate choice of name for the undocumented
__alloca label rather than as a serious bug.
__alloca is an internal symbol that should have been named _alloca_probe
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-06
17:29 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00120.html
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-05
09:37 ---
Patch at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00118.html
danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
ReportedBy: dannysmith at users dot sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35054
--- Comment #10 from dannysmith at users dot sourceforge dot net
2008-01-26 09:41 ---
Fixed.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-01-26
00:58 ---
Confirmed. Fastcall symbols should not be prefixed with USER_LABEL_PREFIX.
This bug was introduced with
2007-03-29 Richard Henderson [EMAIL PROTECTED]
snip
* config/i386/cygming.h: Remove
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-01-26
07:17 ---
This is a 4.3.0 regression.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-01-19
08:33 ---
(In reply to comment #4)
Testing a patch.
Here it is:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00881.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-01-13
08:32 ---
Testing a patch.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-01-13
06:50 ---
(In reply to comment #1)
One could make the argument that the dllimport specifier is
a storage-class-specifier which, per 11.4/6 is not allowed on
the friend declaration. Since a friend function
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-01-09
06:14 ---
This is a dup of PR23138 which is fixed if using recent mingw runtime.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
--- Comment #22 from dannysmith at users dot sourceforge dot net
2007-12-13 08:53 ---
(In reply to comment #15)
It seems fixincl isn't supported for mingw at all, from what Danny Smith
mailed
me privately.
Sorry for breaking this thread with an inadvertent private mail
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-12-09
08:00 ---
Fixed for 4.3.0 by
http://gcc.gnu.org/viewcvs?view=revrevision=126903
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-11-16
23:09 ---
The problem with decorate is that its meaning depends on the platform. It may
decorate the name of alias with a _ prefix and @n postfix or only with a
_ prefix. Maybe one should start with STDCALL
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-11-08
19:18 ---
The newlib stdio.h puts [v]snprintf declarations within a #ifndef
__STRICT_ANSI__ block.
Likewise for cygwin's ctype.h and isblank
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34032
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-11-08
20:21 ---
Fixed on trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
accepted on typedefs
Product: gcc
Version: 4.3.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
at users dot sourceforge dot net
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33946
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-27
00:52 ---
Same error message as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18353
This works with revision 129548
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33918
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-25
20:41 ---
My reading of 18.7.5 of C++98 standard says that throwing an exeception from
a signal handler is implementation-defined, since such a signal handler is not
a POF.
Danny
--
http://gcc.gnu.org
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-10-18
21:04 ---
The native compiler MSVC++ does not limit field alignment to 64 bits, but as
documented here
Windows Data Alignment on IPF, x86, and x64
http://msdn2.microsoft.com/en-us/library/Aa290049(VS.71).aspx
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-10-15
09:00 ---
I believe this is a dup of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
The bug was closed as fixed but reappeared on 4.2.x when Richard Henderson's
TLS emulation patch was reverted on the branch
of
struct/union fields
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: dannysmith at users dot sourceforge dot net
ReportedBy: dannysmith
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-10-10
19:26 ---
Fixed.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-10-09
23:52 ---
Created an attachment (id=14334)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14334action=view)
mingw32 compatibility patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33578
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-10-09
23:54 ---
(In reply to comment #2)
Created an attachment (id=14332)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14332action=view) [edit]
Consistent use of _WIN32 define
Thats not quite right
: 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=33682
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-06
21:53 ---
The 'obvious' patch is here:
http://gcc.gnu.org/ml/libstdc++/2007-10/msg00043.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33682
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-10-05
07:03 ---
(In reply to comment #4)
However, for some reasons, the path to ld is detected as:
c:/Docume~1/gdr/Desktop/sandbox/eval-build/i686-pc-mingw32/libstdc++-v3/c:/mingw/bin/../lib/gcc/mingw32/3.4.5
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-10-04
08:26 ---
(In reply to comment #2)
While looking for collect2, I
realized the path to ld (and as) had been misdetected. Explicit
specification of the path, --with-ld=/mingw/bin/ld.exe, let me have
: 4.3.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-mingw32
GCC host triplet: i686-pc
--- Comment #8 from dannysmith at users dot sourceforge dot net 2007-09-25
00:31 ---
Fixed on trunk
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-20
21:24 ---
This testcase compiles with problem on trunk and 4.2.2. I haven't tested
4.1.x
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-20
21:36 ---
This is fixed on trunk by TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT patch
http://gcc.gnu.org/viewcvs?root=gccview=revrev=118371
Danny
--
dannysmith at users dot sourceforge dot net changed
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-09-20
21:53 ---
With 4.2 and trunk, I get the same (expected) result on C and C++.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-20
22:01 ---
The addition of
/* { dg-require-profiling -p } */
has resolved this on at least 4.2.2 and trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #11 from dannysmith at users dot sourceforge dot net
2007-09-20 23:43 ---
You can --disable-sjlj-exceptions on cygwin and mingw now.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-09-21
03:04 ---
The example produces a correct label for the vtable (_ZTV1S) with 4.2.2 and
trunk, so closing as fixed.
However we still emit the definition of the vtable even though we import it
from the dll
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-09-19
21:52 ---
With 4.1, 4.2 and trunk, there is still no diagnosis of change in calling
convention in decl, but the bug in generated code is exposed only with
-fno-unit-at-time.
Danny
--
dannysmith at users dot
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-19
00:58 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01498.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14688
Product: gcc
Version: 4.3.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 #5 from dannysmith at users dot sourceforge dot net 2007-09-07
04:21 ---
Fixed.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-05
19:00 ---
A patch is at:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00310.html
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-04
06:17 ---
The solution is to build gcc/gfortran wiith -D__USE_MINGW_ACCESS in CFLAGS;
From mingw/include/io.h
/* Some defines for _access nAccessMode (MS doesn't define them, but
* it doesn't seem to hurt
vs gdb
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build
' is wrong
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
http://gcc.gnu.org
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-08-16
05:59 ---
This executes with no stack growth on mingw32 4.3.0 with Dwarf2 EH unwind.
Ditto for 4.2.1.
I think this may be related to the deallocation problem reported in PR 19771
Danny
--
dannysmith
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-07-28
02:38 ---
(In reply to comment #3)
Subject: Bug number PR 32195
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-07
--- Comment #20 from dannysmith at users dot sourceforge dot net
2007-07-26 00:34 ---
(In reply to comment #18)
Under mingw, gfortran has some trouble. I am still experimenting and testing
on mingw which I just got installed on my test machine here. I should be able
to finish
--- Comment #17 from dannysmith at users dot sourceforge dot net
2007-07-23 08:04 ---
(In reply to comment #16)
Maybe we
should make it match con with case ignored.
No, please. con, nul, prn (with or without suffix) are reserved device
names on windows.
(eg gcc -v -dM -E nul.c
--- Comment #11 from dannysmith at users dot sourceforge dot net
2007-07-22 08:42 ---
(In reply to comment #10)
Here is a complete patch, tested on Cygwin. I need to test on mingw. Can
anyone help with that?
open(unit=29,file='CONOUT$')
write(29,100)
100 format
--- Comment #15 from dannysmith at users dot sourceforge dot net
2007-07-23 04:44 ---
(In reply to comment #13)
Created an attachment (id=13950)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13950action=view) [edit]
Patch to provide conio support
Danny, can you please check
--- Comment #15 from dannysmith at users dot sourceforge dot net
2007-07-18 11:44 ---
Fixed. I have modified Christoph's original patch to avoid problems on NT4
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-07-19
02:17 ---
Patch at
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01521.html
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-07-17
08:43 ---
(In reply to comment #4)
What name should I change 'con' to so that the write statement writes to the
console?
I think it should be CONOUT$ (ie you had it right the first time).
The following works
--- Comment #7 from dannysmith at users dot sourceforge dot net 2007-06-20
23:32 ---
(In reply to comment #6)
Anybody have enough __asm__ foo to write a inline assembly macro taking a long
double operand and returning one, which I can use to call fsqrt directly in
inline assembly
--- Comment #7 from dannysmith at users dot sourceforge dot net 2007-06-17
23:40 ---
Fixed by:
2007-06-09 Vladimir Prus [EMAIL PROTECTED]
* files.c (open_file): Account for the
fact that on windows, opening a directory gives
EACCES.
--
dannysmith at users
--- Comment #50 from dannysmith at users dot sourceforge dot net
2007-06-14 03:21 ---
(In reply to comment #37)
I think basically you are messed up untill Cygwin switches to dwarf2
exceptions.
This is now (=gcc 4.3) possible by adding --disable-sjlj-exceptions to
configure.
Can we
--- Comment #12 from dannysmith at users dot sourceforge dot net
2007-06-03 21:37 ---
(In reply to comment #11)
Hi
Now we looking at the second patch the host-mingw32.c.diff
I have not tested it in vista or windows yet. But what I can see
it using vritualalloc that mean
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-05-29
08:16 ---
Fixed on trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #17 from dannysmith at users dot sourceforge dot net
2007-05-24 11:18 ---
Fixed on trunk
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-05-17
23:59 ---
Fixed by:
2007-05-17 Danny Smith [EMAIL PROTECTED]
PR target/31965
* config/i386/mingw32.h (_INTEGRAL_MAX_BITS): Define builtin as
TYPE_PRECISION (intmax_type_node
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-05-17
23:59 ---
Closing.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #15 from dannysmith at users dot sourceforge dot net
2007-05-16 21:34 ---
(In reply to comment #13)
Subject: Re: Compile errors with multiple inheritance where
the stdcall attribute is applied to virtual functions.
rridge at csclub dot uwaterloo dot ca wrote
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-04-29
19:43 ---
Your configure options may be at fault. In particular you
'--disable-sjlj-exceptions'. Well, sjlj is the only kind of exceptions that
cygwin supports, unless you modified gcc sources.
Danny
--- 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=gccview=revrev=124149
Log:
* config/i386/winnt.c (i386_pe_file_end): Strip
--- 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=13403action=view)
Patch for testcase in 31636
Could you please test the attached patch to tree-ssa-address.c which
--- 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 you provide
--
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 #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
--- 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 #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 #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-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': definition
--- 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 #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=12997action=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 #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 really.
Yes there are reasons
101 - 200 of 340 matches
Mail list logo
