--- 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,Node Tparent=NULL) {_parent=Tparent;_data=v;}
It looks like you have transposed the *> (it should be the following, right?
Node(const T& v,Node* Tparent=NULL) {_par
--- 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=20674&action=view)
Test success example
Runtest with the warning removed from config/i386/cygming.h
Shows that the tes
--- 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=20673&action=view)
Test failure example
Testsuite i386.exp=func-spec*.c
Shows test failures in -4 and -8 due to excess w
: 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 14:23 ---
Created an attachment (id=20672)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20672&action=view)
Assembly that shows unsupported registry saves
This assembly is made from:
/opt/build/x86_64-pc-linux/x86
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 #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
--- 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-f
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 target triplet: i686-pc-mingw32 x86_64-*-mingw32 i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- 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: In
--- 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;
>
--- Comment #7 from dougsemler at gmail dot com 2010-05-09 16:24 ---
Reduced test case:
# 1 "gcc_bug2.cc"
# 1 ""
# 1 ""
# 1 "gcc_bug2.cc"
struct base
{
virtual ~base() { }
};
int main()
{
base ptr_array[1];
ptr_array = { base()
--- 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 n
--- 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 do
--- 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
AssignedTo: unassigned at gcc dot gnu dot org
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
--- 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
d variable warning at -O3 -Wall
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 tr
When compiling a Win64 i686-w64-mingw32 compiler with multilib, ada fails to
build with similar errors as reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993 There is currently no
selection on the i686 side for multilib, as the gcc/gcc-interface/ada Makefile
assumes that no ix86 mingw* t
-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
4.3.1, MPFR version 2.4.2-dev.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f2c_specifics.F90: In function '_gfortran_f2c_specific__cos_c8':
f2c_specifics.F90:2: internal compiler error: in find_valid_class, at
reload.c:700
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE in libgfortran arm thumb multilib compile
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: 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
