I am still porting gcc v4.1.2 to a new risc architecture, and this
time my problem is that when compiling with -O2 turned on, every insn
with a (use ..) side effect expression, eg.
(define_expand sibcall
[(parallel [(call (match_operand 0 )
(match_operand 1 ))
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for
Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs...
Hello,
Apologies if this has already been covered; I've searched the archives
and not found anything.
I have some code that needs to perform signed division by a power of two
with rounding towards minus infinity, i.e. it requires an arithmetic
right shift. Now in the C specification, right
Bernd Schmidt wrote:
Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths
Christopher Key wrote:
I have some code that needs to perform signed division by a power of two
with rounding towards minus infinity, i.e. it requires an arithmetic
right shift. Now in the C specification, right shifting a signed
integer is implementation defined.
Because C may be compiled
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I meant gcc_no_link = yes.
Jie
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I meant gcc_no_link = yes.
Stupid double negatives. Okay, so then your problem is that
On Tue, Sep 18, 2007 at 03:27:18PM +0200, Bernd Schmidt wrote:
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I meant gcc_no_link =
Rask Ingemann Lambertsen wrote:
On Tue, Sep 18, 2007 at 07:55:45PM +0800, Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
From config.log:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
cannot open
On Tue, Sep 18, 2007 at 07:55:45PM +0800, Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
From config.log:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
cannot open linker script file bf532.ld: No such
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are
avoided.
Oops, I meant gcc_no_link = yes.
Stupid double
Hello,
I assume that this is the correct mailing list to ask this, as opposed
to a Cpp list, since it appears to me that this is compiler-related.
1)
class foo
{
int priv;
public:
void bar();
};
Supposing i am writing the definition of foo::bar, and i want to change
the private
Daniel Jacobowitz wrote:
On Tue, Sep 18, 2007 at 03:27:18PM +0200, Bernd Schmidt wrote:
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I
On 18 September 2007 14:59, Ioannis Gyftos wrote:
Hello,
I assume that this is the correct mailing list to ask this, as opposed
to a Cpp list, since it appears to me that this is compiler-related.
But this isn't a mailing list for general how-to-use-the compiler questions,
this is a
Bernd Schmidt wrote:
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I meant gcc_no_link = yes.
Stupid double negatives. Okay, so then
I have investigated it further, and thought I'd add it to my question.
I have tried compiling with all optimization flags turned on manually
(list included below) and that compiles just fine. That leads me to
think that what is causing the bug is some undocumented optimization,
triggered only if
Tomas Svensson [EMAIL PROTECTED] writes:
I am still porting gcc v4.1.2 to a new risc architecture, and this
time my problem is that when compiling with -O2 turned on, every insn
with a (use ..) side effect expression, eg.
(define_expand sibcall
[(parallel [(call (match_operand 0 )
Bernd Schmidt wrote:
Jie Zhang wrote:
bfin-elf-gcc -mfdpic failed to link a simple test case because code is
put into L1 instruction sram and data is put into L1 data sram, but
Blackfin immediate offset load instruction cannot access GOT since the
gap between instruction sram and data sram is
Hello,
I have a bunch of command line programs and I am trying to support
Windows, Linux and an older version of Solaris.
I got the same version of gcc working on all 3 platforms.
Now the problem is that I can't get getopt_long to work which is
provided by getopt.h.
I don't know much about how
I saw getopt.h, getopt.c, and getopt1.c in my gcc directory under
libiberty. What are these for?
Those are for building gcc itself. They're not normally used by
applications, unless you want to import all of libiberty into your
application. Normally, glibc provides the getopt family of
Frederich, Eric P21322 [EMAIL PROTECTED] writes:
I have a bunch of command line programs and I am trying to support
Windows, Linux and an older version of Solaris.
I got the same version of gcc working on all 3 platforms.
Now the problem is that I can't get getopt_long to work which is
On Tue, Sep 18, 2007 at 10:19:37PM +0800, Jie Zhang wrote:
Rask Ingemann Lambertsen wrote:
The file bf532.ld is nowhere to be found in gcc or newlib/libgloss.
I have not pushed out our recent newlib/libgloss changes to upstream
yet. Currently you could get latest blackfin port
Tim Prince wrote:
Christopher Key wrote:
I have some code that needs to perform signed division by a power of two
with rounding towards minus infinity, i.e. it requires an arithmetic
right shift. Now in the C specification, right shifting a signed
integer is implementation defined.
Tomas Svensson wrote:
I have tried compiling with all optimization flags turned on manually
(list included below) and that compiles just fine. That leads me to
think that what is causing the bug is some undocumented optimization,
triggered only if optimize 0.
There is no optimization at all
On Tue, Sep 18, 2007 at 06:09:18PM +0200, Rask Ingemann Lambertsen wrote:
On Tue, Sep 18, 2007 at 10:19:37PM +0800, Jie Zhang wrote:
Rask Ingemann Lambertsen wrote:
The file bf532.ld is nowhere to be found in gcc or newlib/libgloss.
I have not pushed out our recent newlib/libgloss
Kenneth Zadeck [EMAIL PROTECTED] writes:
Richard Sandiford wrote:
I think this is a latent bug in var-tracking.c. It's getting confused
by the negative offsets in:
(insn:HI 17 47 19 4 /tmp/foo.c:11 (set (reg:DI 26 26 [orig:124 tmp+-7 ]
[124])
(lshiftrt:DI (reg:DI 31 31 [orig:141
Richard,
There seems to be a small problem with the MIPS atomic memory operations
patch I recently committed
(http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a
dual CPU machine it does not quite work.
You can look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33479#c3
On Tue, Sep 18, 2007 at 05:12:48PM -0700, David Daney wrote:
I guess my basic question is: Should MIPS_COMPARE_AND_SWAP have a 'sync'
after
the 'sc'? I would have thought that 'sc' made the write visible to all CPUs,
but on the SB1 it appears not to be the case.
Yes, a barrier of some
Rask Ingemann Lambertsen wrote:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
crt532.o: No such file: No such file or directory
I sorted that out by using your config/bfin/elf.h, but there's something
weird. The first time configure runs, it will complain about
GCC_NO_EXECUTABLES
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-18 06:34 ---
Subject: Bug 33231
Author: burnus
Date: Tue Sep 18 06:34:30 2007
New Revision: 128570
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128570
Log:
2007-09-18 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-18 06:34 ---
FIXED on the trunk (4.3).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinakee dot b at xius dot com 2007-09-18 07:05 ---
Created an attachment (id=14218)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14218action=view)
The attachment is the zip of preprocessed file of the source file.
Since the file size was more than that
--- Comment #23 from rask at gcc dot gnu dot org 2007-09-18 07:14 ---
configure:10398: error: unrecognizable insn:
(insn 105 104 106 2 (set (subreg:QI (reg/f:HI 52) 0)
(subreg:QI (label_ref:HI 57) 0)) -1 (nil))
configure:10398: internal compiler error: in extract_insn, at
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-18 08:26
---
This is because, in gfc_use_derived (symbol.c), when checking whether a derived
type is in the current unit or a parent unit, we check (sym-components !=
NULL) and if it's true, we take it to mean that the
--- Comment #11 from rguenther at suse dot de 2007-09-18 08:44 ---
Subject: Re: [4.1/4.2/4.3 Regression] g++-4.1: out of memory
with -O1/-O2
On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:
--- Comment #10 from alexander at kogan dot nnov dot ru 2007-09-18 04:58
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-18 08:46 ---
Subject: Bug 33340
Author: rguenth
Date: Tue Sep 18 08:46:23 2007
New Revision: 128571
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128571
Log:
2007-09-18 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from alexander at kogan dot nnov dot ru 2007-09-18 09:07
---
What do u mean 'not completely'?
Can I try this fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #13 from rguenther at suse dot de 2007-09-18 09:11 ---
Subject: Re: [4.1/4.2/4.3 Regression] g++-4.1:
out of memory with -O1/-O2
On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:
--- Comment #12 from alexander at kogan dot nnov dot ru 2007-09-18 09:07
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-18 09:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Gcc's friend-mechanism seems to expand to nested classes as well, although
the C++ standard explicitly tells differently.
The following example is almost straight from the C++ standard (11.4/2). The
only change is that inheritance is commented out for class X (in order to
remove the first error
Following a discussion on IRC with FX Coudert, I think the number of digits
printed by default in formatted output should be increased by one. Otherwise
the logic of the test case large_real_kind_form_io_2.f90 is flawed as shown by
the attached code. Its output on AMD64 is
real(4)
default
--- Comment #14 from alexander at kogan dot nnov dot ru 2007-09-18 09:55
---
Ok. Do you mean the attached test doesn't work even with this fix? But are
there plans to eliminate this problem completely?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-18 09:47 ---
Created an attachment (id=14219)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14219action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33469
The following code compiles cleanly with 4.2.1. The expected output is C but
the executable outputs B.
#include iostream
using namespace std;
struct A
{
virtual ~A() { }
virtual void f() { cout A; }
};
struct B : public A
{
virtual void f() { cout B; }
};
struct C :
--- Comment #1 from pcarlini at suse dot de 2007-09-18 10:55 ---
Janis, is it possible to have a regression hunt? Thanks in advance.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from rguenther at suse dot de 2007-09-18 10:58 ---
Subject: Re: [4.1/4.2/4.3 Regression] g++-4.1:
out of memory with -O1/-O2
On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:
--- Comment #14 from alexander at kogan dot nnov dot ru 2007-09-18 09:55
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-09-18 11:22
---
Subject: Bug 31863
Author: rguenth
Date: Tue Sep 18 11:22:47 2007
New Revision: 128573
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128573
Log:
2007-09-18 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-18 11:31
---
(In reply to comment #2)
One thing that comes to mind is the following patch. It allows derived types
with zero components to be accepted, but I fear that it might make us accept
invalid code with empty
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-18 11:00 ---
No, B is correct.
A Aref = Binst;
Aref = Cinst;
is the same as:
Binst = (A)Cinst;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-09-18 11:58
---
Note that the double virtual inheritance in the Serializer template creates the
exponential behavior. You can fix this at the source level by instead
doing
template class Key, class Head
class SerializerKey,
--- Comment #2 from photon at seznam dot cz 2007-09-18 12:01 ---
(In reply to comment #1)
No, B is correct.
A Aref = Binst;
Aref = Cinst;
is the same as:
Binst = (A)Cinst;
Binst = (A)Cinst would not compile (C is not derived from B).
--
photon at seznam
--- Comment #1 from bero at arklinux dot org 2007-09-18 12:26 ---
Created an attachment (id=14220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14220action=view)
bzip2-ed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33471
Granted, the compiler flags I've used for testing are asking for trouble...
$ gcc -march=pentium4 -mfpmath=sse,387 -o mplayer.o mplayer.i
mplayer.c: In function 'main':
mplayer.c:3750: error: unrecognizable insn:
(insn 5170 5169 5171 674 mplayer.c:3552 (set (reg:SF 258 [ D.19380 ])
This bug happens on a cross-compiler targetting x86_64-pc-mingw32, but not on a
native x86_64-linux compiler. Both compilers are built with SVN trunk from the
same revision (128540).
Witn -m64, it doesn't error out at -O0, there is an ICE at -O1 and a different
error at -O2. With -m32,
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-18 12:56 ---
We substitute into the invariant address retval.a[0] *this, which results
in a non-invariant address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-09-18 13:16
---
I can still see the ICE with -O2 -ftree-loop-linear and the testcase from
comment
2 on trunk (x86_64):
t.i: In function 'lsp_weight_quant':
t.i:3: internal compiler error: in lambda_loopnest_to_gcc_loopnest, at
--- Comment #2 from rask at gcc dot gnu dot org 2007-09-18 13:26 ---
Fixed as of revision 128577.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-18 13:02 ---
Still fails.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-09-18 13:17
---
Sebastian, can you have a look at this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-18 13:25 ---
Subject: Bug 33388
Author: rask
Date: Tue Sep 18 13:24:44 2007
New Revision: 128577
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128577
Log:
PR target/33388
PR target/33397
*
--- Comment #1 from rask at gcc dot gnu dot org 2007-09-18 13:25 ---
Subject: Bug 33397
Author: rask
Date: Tue Sep 18 13:24:44 2007
New Revision: 128577
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128577
Log:
PR target/33388
PR target/33397
*
--- Comment #4 from rask at gcc dot gnu dot org 2007-09-18 13:28 ---
Fixed with revision 128577.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-18 13:34 ---
With bug 33388 and bug 33397 fixed, the fix for bug 32154 fixes this one as
well (as of revision 128577).
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rswan at signetic dot ca 2007-09-18 13:38 ---
Created an attachment (id=14221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14221action=view)
testcase archive
Extract archive. Invoke make within gch_bug directory. Bug seen in generated
main.d dependency
--- Comment #3 from ubizjak at gmail dot com 2007-09-18 13:48 ---
Insn constraint for following insn should be fixed:
(define_insn *floatdimode2_i387
[(set (match_operand:MODEF 0 register_operand =f,f)
(float:MODEF
(match_operand:DI 1 nonimmediate_operand m,?r)))]
Hello;
GCC does not correctly generate dependencies correctly with g++ -MD when
precompiled headers are used. I've attached an example which generates main.d
while compiling main.cpp. main.cpp includes include/bink.h. When the include
path contains the precompiled bink.h.gch (only), main.d does
--- Comment #2 from ubizjak at gmail dot com 2007-09-18 13:40 ---
Caused by X86_USE_VECTOR_CONVERTS or X86_TUNE_INTER_UNIT_CONVERSIONS patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-09-18 14:03 ---
Sorry, this is already fixed in latest SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from paolo at gcc dot gnu dot org 2007-09-18 14:35 ---
Subject: Bug 33464
Author: paolo
Date: Tue Sep 18 14:35:42 2007
New Revision: 128578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128578
Log:
/cp
2007-09-18 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #2 from pcarlini at suse dot de 2007-09-18 14:36 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #3 from photon at seznam dot cz 2007-09-18 15:12 ---
(In reply to comment #1)
No, B is correct.
A Aref = Binst;
Aref = Cinst;
is the same as:
Binst = (A)Cinst;
The compiler treats this case as Ainst = (A) Cinst.
--
photon at seznam dot cz
--- Comment #1 from paolo at gcc dot gnu dot org 2007-09-18 15:38 ---
Subject: Bug 33463
Author: paolo
Date: Tue Sep 18 15:38:02 2007
New Revision: 128582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128582
Log:
/cp
2007-09-18 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #2 from pcarlini at suse dot de 2007-09-18 15:40 ---
Fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini
--- Comment #1 from jakub at gcc dot gnu dot org 2007-09-18 15:34 ---
--- gcc/cp/error.c.jj 2007-09-11 12:43:28.0 +0200
+++ gcc/cp/error.c 2007-09-18 17:25:14.0 +0200
@@ -2054,6 +2054,15 @@ dump_expr (tree t, int flags)
dump_type (t, flags);
break;
--- Comment #2 from pcarlini at suse dot de 2007-09-18 15:39 ---
Thanks a lot Jakub, I'm going to do exactly that but as part of
cxx_pretty_print.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33462
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2007-09-18
15:59 ---
Confirmed.
Also breaks bootstrap if CFLAGS is set to -O3.
I couldn't reproduce this with 4.1 so reported against = 4.1.0 is probably
typo.
Can be reproduced in a cross compiler.
--
belyshev at depni
Build failure in target libiberty:
/home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-bfin-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include
On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
+case VA_ARG_EXPR:
+ pp_cxx_identifier (cxx_pp, __builtin_va_arg);
I would not use __builtin_va_arg here since this diagnostic, I would
just use va_arg.
Thanks,
Andrew Pinski
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-18 16:40 ---
Subject: Re: [4.1/4.2/4.3 regression] Broken diagnostic: 'va_arg_expr' not
supported by dump_expr
On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
+case VA_ARG_EXPR:
+
--- Comment #3 from william dot adams at dot dot state dot fl dot us
2007-09-18 17:24 ---
4.2.1 had other build problems.
but this particular one appeared after i upgraded binutils to 2.18.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-18 17:56 ---
confirmed.
The problem is found in decl.c(top_val_list) at lines 404-411, which
are
signed int tmp;
msg = gfc_extract_int (expr, tmp);
gfc_free_expr (expr);
if (msg != NULL)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-18 17:56 ---
A compiler comparison:
real(4) gfortran g95 NAGf95 ifort sunf95 openf95
default 808 0808 808 0 0
1PG20.6 18811881 1881 1881 18811881
1PG20.7 808 808808 808 808
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
--- Comment #4 from paolo at gcc dot gnu dot org 2007-09-18 18:05 ---
Subject: Bug 33462
Author: paolo
Date: Tue Sep 18 18:05:40 2007
New Revision: 128584
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128584
Log:
/cp
2007-09-18 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from pcarlini at suse dot de 2007-09-18 18:06 ---
Fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
--- Comment #1 from pcarlini at suse dot de 2007-09-18 18:29 ---
*** This bug has been marked as a duplicate of 33477 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-09-18 18:29 ---
*** Bug 33478 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33477
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 18:02 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 05:56:36PM -, kargl at gcc dot gnu dot org wrote:
The problem is found in decl.c(top_val_list) at
As noted in:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00818.html
With this configuration:
../trunk/configure --prefix=/home/ddaney/gccsvn/trunk-install
--target=mipsel-linux --build=mipsel-linux --host=mipsel-linux
--with-gmp=/home/ddaney/mp --with-mpfr=/home/ddaney/mp --with-arch=sb1
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** This bug has been marked as a duplicate of 33475 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** Bug 33476 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:59 ---
Confirmed.
A simpler to understand testcase is this one (all crud removed):
-
class A {
class B { };
friend class X;
};
class X {
A::B mx;
class Y : A::B {
A::B my;
};
};
1 - 100 of 154 matches
Mail list logo
