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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
ReportedBy: dannysmith at users dot sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35054
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
--- 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
--- 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 #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 #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 #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
--- 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
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 #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
--- 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-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 #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
: 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 #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
--- 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
: 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 #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
--- 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
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 #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
--- 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 #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 #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
at users dot sourceforge dot net
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33946
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
--- 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
--- 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
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-08
08:12 ---
Fixed.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #53 from dannysmith at users dot sourceforge dot net
2009-04-16 02:59 ---
This thread is alos relevant.
http://gcc.gnu.org/ml/gcc/2009-04/msg00462.html
Adding Dave Korn to cc:
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29
07:29 ---
The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc
Danny
--
dannysmith at users dot sourceforge dot net changed
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-04-30
20:57 ---
(In reply to comment #6)
(In reply to comment #4)
Your libpthreads is doing something wrong.
Re. comment 5
The command was actually
gcc -fopemnp test.c -lgomp -o test.exe
That command works
--- Comment #10 from dannysmith at users dot sourceforge dot net
2009-04-30 21:07 ---
(In reply to comment #9)
(In reply to comment #6)
(In reply to comment #4)
Your libpthreads is doing something wrong.
Re. comment 5
The command was actually
gcc -fopemnp test.c -lgomp -o
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Component|target |libgomp
Target Milestone
--- Comment #12 from dannysmith at users dot sourceforge dot net
2009-05-01 19:48 ---
(In reply to comment #11)
(In reply to comment #9, comment #10)
I did not build MinGW 4.3.0. I got it from the official MinGW site
(gcc-4.3.0-20080502-mingw32-alpha). I have also found
--- 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=17841action=view) [edit]
inherit dllexport from class to typeinfo
Now testing
--- 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
that clients
--- 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
does not know those
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-11-29
17:36 ---
see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c9
and discussion of
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html
I think that patch should go into 4.5
Danny
--
http
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-24
03:12 ---
This bug is linker related. It is fixed on 32-bit windows by this patch
http://sourceware.org/ml/binutils-cvs/2007-10/msg2.html
Have you tried with recent binutils and explict -Wl,--enable-auto
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-09-26
03:15 ---
*** Bug 37652 has been marked as a duplicate of this bug. ***
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-26
03:15 ---
This is duplicate of 34749
*** This bug has been marked as a duplicate of 34749 ***
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #19 from dannysmith at users dot sourceforge dot net
2008-09-29 18:43 ---
Created an attachment (id=16427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16427action=view)
Nick's aligned common testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #26 from dannysmith at users dot sourceforge dot net
2008-10-01 01:33 ---
(In reply to comment #14)
Hi Guys,
I am not able to reproduce the build problems that were reported with the
first version of my patch, but then again I do not have a native cygwin build
--- Comment #27 from dannysmith at users dot sourceforge dot net
2008-10-01 10:22 ---
(In reply to comment #13)
Created an attachment (id=16425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view) [edit]
Revised patch with correct section switching
That patch
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-10-02
00:20 ---
In reply to comment #4)
xgcc: error trying to exec
'/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe': execv:
Permission denied
This may be related to:
http://gcc.gnu.org/ml/gcc-bugs
--- Comment #10 from dannysmith at users dot sourceforge dot net
2008-10-02 08:47 ---
Fixed on mingw32 at revision 140803.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
--- Comment #41 from dannysmith at users dot sourceforge dot net
2008-10-06 20:18 ---
(In reply to comment #35)
As I suspected. The PE/COFF file format does not provide for specifying
the alignment of commons.
Hmm, I wonder if gcc should complain if it finds aligned commons
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-03
07:45 ---
Created an attachment (id=16614)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16614action=view)
revised patch to quard with ENABLE_SHARED_LIBGCC
Hi Mikael,
I have modified your patch slightly
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-04
02:21 ---
Fixed by Mikael's patch
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |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 #2 from dannysmith at users dot sourceforge dot net 2008-11-09
08:20 ---
This a target bug (stdcall symbol name decorati0on on windows targets)
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-09
08:24 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-11
06:27 ---
(In reply to comment #3)
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html
That patch also fixes the FAIL of testsuite\g++.old-deja\g++.dg\otherg++
pr35504.C . Currently it fails
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-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla
--- 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=16713action=view) [edit]
gcc44-pr38130.patch
I've talked about this with Honza on IRC
--- 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=16713action=view
Danny
--
dannysmith at users dot sourceforge dot
--- 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
`___chkstk'
.libs/gets
--- 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/bugzilla
--- 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 all tests you are doing
--- 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
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-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
--- 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 #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-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 #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 #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 #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
201 - 300 of 340 matches
Mail list logo
