--- Comment #3 from dougsemler at gmail dot com 2010-07-11 15:11 ---
Does anyone know if pr43538 affects this as well (cxx flags fir target
inheriting from cxxflags on Linux targets)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44433
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44525
--- Comment #1 from dougsemler at gmail dot com 2010-05-17 17:46 ---
This is the offender:
Node(const T v,NodeT* Tparent=NULL) {_parent=Tparent;_data=v;}
It looks like you have transposed the * (it should be the following, right?
Node(const T v,NodeT* Tparent=NULL) {_parent=Tparent
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC target triplet: x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
--- Comment #1 from dougsemler at gmail dot com 2010-05-16 14:23 ---
Created an attachment (id=20672)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20672action=view)
Assembly that shows unsupported registry saves
This assembly is made from:
/opt/build/x86_64-pc-linux/x86_64-w64
: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC target triplet: x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
--- Comment #1 from dougsemler at gmail dot com 2010-05-16 17:40 ---
Created an attachment (id=20673)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20673action=view)
Test failure example
Testsuite i386.exp=func-spec*.c
Shows test failures in -4 and -8 due to excess warnings
--- Comment #2 from dougsemler at gmail dot com 2010-05-16 17:42 ---
Created an attachment (id=20674)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20674action=view)
Test success example
Runtest with the warning removed from config/i386/cygming.h
Shows that the tests will succeed
--- Comment #8 from dougsemler at gmail dot com 2010-05-15 13:03 ---
Done
cf. http://sourceware.org/bugzilla/show_bug.cgi?id=11603
(note to self, pay more attention to specs and less attention to de facto
behavior of toolsets ;-))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC target triplet: i686-pc-mingw32 x86_64-*-mingw32 i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #28 from dougsemler at gmail dot com 2010-05-14 15:49 ---
I tried adding -nostdinc++ via --enable-cxx-flags configure option, but those
aren't passed through to the pch compilation...and I'm not sure that it's
appropriate to pass all the --enable-cxx-flags to the pch
--- Comment #10 from dougsemler at gmail dot com 2010-05-10 17:18 ---
Well, is it really invalid code with -std=c++0x?
The virutal destructor seems to be causing the issue.
With gcc 4.4.3 (after changing virtual ~base() to virtual void func()):
$ g++ gcc_bug.cc
gcc_bug.cc
--- Comment #7 from dougsemler at gmail dot com 2010-05-09 16:24 ---
Reduced test case:
# 1 gcc_bug2.cc
# 1 built-in
# 1 command-line
# 1 gcc_bug2.cc
struct base
{
virtual ~base() { }
};
int main()
{
base ptr_array[1];
ptr_array = { base() };
}
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from dougsemler at gmail dot com 2010-05-09 23:25 ---
(In reply to comment #9)
A good example of seemingly normal code is following:
switch (whatever)
{
case 1:
int i=0;
i
--- Comment #3 from dougsemler at gmail dot com 2010-04-16 14:53 ---
Right now in a cross environment, the target libraries, when built as DLLs, are
also installed in the host's bindir, due to the -bindir flag now being passed
to libtool. While this may be appropriate in a native
--- Comment #2 from dougsemler at gmail dot com 2010-04-15 12:53 ---
*** Bug 43749 has been marked as a duplicate of this bug. ***
--
dougsemler at gmail dot com changed:
What|Removed |Added
--- Comment #3 from dougsemler at gmail dot com 2010-04-15 12:53 ---
You're right. When I searched for it, it reported no bugs found (sigh).
And I see my solution is exactly the same as 38493.
*** This bug has been marked as a duplicate of 38493 ***
--
dougsemler at gmail dot com
ReportedBy: dougsemler at gmail dot com
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43749
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http
--- Comment #2 from dougsemler at gmail dot com 2010-04-12 20:44 ---
FWIW:
I realized that I have been playing around with newer ppl and the compiler is
dynamically linking against ppl 0.11 and gmp 5 rather than ppl 0.10 and gmp 4.
When I get rid of the experimental libs in my link
-gnu CXXFLAGS_FOR_TARGET
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC build
: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41482
23 matches
Mail list logo
