--- Comment #1 from herwig at gdsys dot de 2008-03-31 06:41 ---
Hi yuri,
I think, this is perfectly correct code and GCC is right in accepting it. First
of all, see "Effective C++" issue 14 about the pure virtual destructor. Then
see here:
http://en.wikipedia.org/wiki/Virtual_function#
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-31 06:30 ---
retmeN is being miscompiled by SRA, at least for powerpc-darwin with a changed
MOVE_RATIO.
retmeN (x)
{
x$i;
x$j;
long long unsigned int SR.21;
:
x$j = x.j;
x$i = x.i;
x.j = x$j;
x.i = x$i;
SR.21 =
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-31 04:48 ---
Middle end use canonical type for passing parameters to function
calls. ix86_function_arg_boundary should do the same. Otherwise,
there will be a mismatch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35767
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-31 04:46 ---
*** This bug has been marked as a duplicate of 35767 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-31 04:46 ---
*** Bug 35771 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35767
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-31 02:04 ---
useless_type_conversion_p returns true for
(gdb) call debug_tree (outer_type)
unit size
align 32 symtab -1430183552 alias set -1 canonical type 0x2ab0a6c0
precision 32
pointer_to_this
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-31 00:18 ---
That being said, I think fn_type_unification should apply the attributes but I
don't know/understand the template part of the C++ front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-31 00:16 ---
So what is happening is we are not applying the attribute while doing overload
resolution so we reject the template function then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
--- Comment #2 from danglin at gcc dot gnu dot org 2008-03-31 00:03 ---
Richard, does match_scratch now require a mode? The pattern causing
the problem was written without a mode so that it could handle both
SImode and DImode.
--
danglin at gcc dot gnu dot org changed:
W
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-30 23:58 ---
(gdb) p debug_rtx (rl->out)
(scratch)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35768
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-30 23:58 ---
The problem is __m128 shoulbn't the canonical type for unaligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35771
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 23:31 ---
This is now fixed:
add_tri:
fa $3,$3,$6
stqd$sp,-224($sp)
fa $4,$4,$7
fa $5,$5,$8
ai $sp,$sp,-224
lnop
ai $sp,$sp,224
bi
--- Comment #3 from danglin at gcc dot gnu dot org 2008-03-30 23:30 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from danglin at gcc dot gnu dot org 2008-03-30 23:24 ---
Subject: Bug 35245
Author: danglin
Date: Sun Mar 30 23:23:43 2008
New Revision: 133740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133740
Log:
PR c++/35245
* g++.dg/other/anon5.C: Skip on
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-30 23:21 ---
Subject: Bug 35245
Author: danglin
Date: Sun Mar 30 23:20:57 2008
New Revision: 133739
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133739
Log:
PR c++/35245
* g++.dg/other/anon5.C: Skip on
--- Comment #5 from schwab at suse dot de 2008-03-30 22:49 ---
No longer reproducible on the trunk.
--
schwab at suse dot de changed:
What|Removed |Added
Known to wo
--- Comment #2 from schwab at suse dot de 2008-03-30 22:44 ---
*** This bug has been marked as a duplicate of 32424 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2008-03-30 22:44 ---
*** Bug 35454 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
-
--- Comment #2 from schwab at suse dot de 2008-03-30 22:41 ---
Not reproducible, assuming fixed.
--
schwab at suse dot de changed:
What|Removed |Added
Status|
--- Comment #15 from eric dot weddington at atmel dot com 2008-03-30 22:40
---
FWIW, test case passes for avr-*-* target version 4.3.0 -O[0123s]
-frtl-abstract-sequences
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #3 from schwab at suse dot de 2008-03-30 22:36 ---
Not a bug.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from yuriry at gmail dot com 2008-03-30 22:29 ---
I believe that the main problem here is that GCC allows defining pure virtual
functions. The compiler should report an error when these two functions are
defined:
//
void Base::pvMethod
GCC compiles the code below without any error:
//--
class A {
protected:
virtual void foo() const = 0;
};
// Defining pure virtual functions should not be allowed.
void A::foo() const
{
}
//--
--
Summary: GCC allows
Call expander ignores type alignment. But caller honors type alignment.
It usually isn't a problem until the argument is passed via stack. We
have a mismatch between caller and callee:
bash-3.2$ cat x.c
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
__m128 __attribut
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 22:09
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-03-30 22:08
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-30 22:04 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 22:02
---
Subject: Bug 35578
Author: reichelt
Date: Sun Mar 30 22:02:06 2008
New Revision: 133738
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133738
Log:
PR c++/35578
* parser.c (cp_parser_decl_sp
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-30 21:59
---
Subject: Bug 35748
Author: reichelt
Date: Sun Mar 30 21:58:43 2008
New Revision: 133737
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133737
Log:
PR c/35748
* c-typeck.c (build_c_cast): Sk
--- Comment #6 from schwab at suse dot de 2008-03-30 21:58 ---
Fixed.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #10 from kst at mib dot org 2008-03-30 21:49 ---
(In reply to comment #9)
> >I'd expect the warning to be muted in one of the calls, depending on
> -f{un}signed-char.
>
> No, char is a seperate type from signed char and unsigned char so they are
> always incompatiable when it
--- Comment #9 from burnus at gcc dot gnu dot org 2008-03-30 21:37 ---
(reply to comment #8)
> I have another example of what might be the same problem, although the
> symptoms are a little different.
This test case seems to work meanwhile (both in gfortran 4.3.0 and 4.4.0, it
fails in
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 21:34 ---
Confirm. Implicit typing is too fast. It is quite similar to PR 34784.
Note: PR 34784 contains a failure which was missed.
> A procedure question. Is this the One True Way to add additional
> comments or tests abo
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-30 21:38 ---
(In reply to comment #1)
> Note: PR 34784 contains a failure which was missed.
Actually, the test case in PR 34784, comment 8 now passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35770
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-30 21:28 ---
The updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01916.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 21:27 ---
Confirm. I agree that it is valid (although bad style) code.
I think there should be no warning printed if a index-name is used in the
scalar-mask-expr. Otherwise, if it is neither used in the scalar-mask-expr nor
in
--- Comment #3 from petrosyan at gmail dot com 2008-03-30 21:23 ---
I posted the patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01639.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-30 21:18 ---
> Not all. I gave two counter examples: pvf and ifort.
Well at least ifort 9.1, 10.0 and 10.1 on Linux do not use the f2c calling
convention. Neither does NAG f95. But I agree that _ vs __ and different
calling conve
--- Comment #3 from hjl at gcc dot gnu dot org 2008-03-30 21:14 ---
Subject: Bug 35757
Author: hjl
Date: Sun Mar 30 21:13:33 2008
New Revision: 133736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133736
Log:
gcc/
2008-03-30 H.J. Lu <[EMAIL PROTECTED]>
PR target/357
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
The program gives an error message when the internal
function has an apparent character type due to the implicit
statement. Commenting out the implicit fixes it. This
looks similar to 34784 to me.
program SA0021
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revi
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 21:08 ---
Confirmed, as noted by Uros, you should submit the patch to [EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:57 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:56 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:54 ---
Confirmed, it has been failing since at least 4.2.0 20061019 .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:52 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:50 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from Georg dot Baum at post dot rwth-aachen dot de
2008-03-30 20:48 ---
Thanks for the quick reply. You where right, I mixed up the FF2C macro in the
test case. Unfortunately this was not the real problem. The problem I had in my
code was that calling BLAS zdotc from C++
The following (silly) program gives an incorrect error message.
There is only one assignment to each diagonal element of
the array. I don't feel strongly about this because FORALL
is sort of a junk feature and this is an unlikely programming
style. But, to be correct you should downgrade from ERR
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-30 20:45 ---
With -Wextra (aka -W), we get a warning now:
t.cc:1: warning: type qualifiers ignored on function return type
So closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-03-30 20:42 ---
>I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.
No, char is a seperate type from signed char and unsigned char so they are
always incompatiable when it comes to pointers to t
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35714
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-30 20:28 ---
> What do you mean by "preprocessed source."?
Please http://gcc.gnu.org/bugs.html which explains that.
Also it might be best if you try a newer version of GCC since 3.4.x is no
longer being maintained.
--
pinsk
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-30 20:26
---
Closing as invalid. Just like any other linking of shared libraries, you need
the correct LD_LIBRARY_PATH set or use static library versions.
--
pinskia at gcc dot gnu dot org changed:
What|Rem
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-30 20:19 ---
Using a sysroot or setting --prefix for both the newlib build and the GCC build
is the easiest way of getting a cross build to work.
Anyways here are the options I use to build a cross build for spu:
stage1
binuti
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:12 ---
I see them also on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 20:12 ---
This works for me with 4.2.0, 4.3.0 and the trunk on i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35676
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35019
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-30 20:04 ---
This works for me and many others so closing as worksforme.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-30 20:04 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-09-24 17:07:47 |2008-03-30 20:03:
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-30 20:00 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #14 from dje at gcc dot gnu dot org 2008-03-30 19:31 ---
Any progress on the regressions caused by the patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
Executing on host: /home/dave/gnu/gcc-4.4/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4.4/objdir/gcc/ -O0 -w -fno-show-column -c -o
20010226-1.o /home/dave/gnu/gcc
-4.4/gcc/gcc/testsuite/gcc.c-torture/compile/20010226-1.c(timeout = 300)
/home/dave/gnu/gcc-4.4/gcc/gcc/testsuite/gcc.c-torture/compil
This is the cutest web site I've ever seen. It has puppies, miniature
schnauzers!
If you like dogs, take a look at this site. I'm posting this web site to
this group for my friends to get. Sorry if you got it and didn't want it.
I'm trying to get my friend in Germany this web site.
http://sear
--- Comment #67 from baldrick at free dot fr 2008-03-30 17:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> Try first to compile it. :-)
I did! I didn't notice the compile error
after the -gnatG output. Indeed, when fixed
thusly
procedure Overflow (X : Positive
bash-3.2$ cat x.c
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
__m128 __attribute__((noinline))
iszero (__m128 x)
{
return x;
}
typedef __m128 __attribute__((aligned(1))) unaligned;
__m128 __attribute__((noinline))
foo (__m128 a1, __m128 a2, __m128 a3, __m128
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-03-30 16:36 ---
> Related program, which also fails (I thought we fixed this; this seems to be a
> libgfortran problem):
>
> integer xda(20)
> integer, volatile :: n
> n = 1
> print *, size(XDA(n:2:-3)) ! s
--- Comment #66 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:18
---
> Consider the following test case:
>
> procedure Overflow (X : Positive) return Integer is
>A : array (Positive) of Integer;
>pragma Import (Ada, A);
> begin
>A (X) := X;
> end;
>
> (for which no c
--- Comment #65 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:15
---
> So even GNAT assumes parameter values are in-range? Wouldn't that
> cause an bounded error to become an unbounded error if it were
> out-of-range?
GNAT considers that it's an unbounded error in a few specific
--- Comment #64 from baldrick at free dot fr 2008-03-30 16:02 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> > But there are no checks on the array access. It looks like the f-e
> > doesn't generate them in the first place (as opposed to fold or gigi
> > making a m
--- Comment #63 from rguenther at suse dot de 2008-03-30 15:56 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
> ---
> > Ye
--- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
---
> Yes, even with -gnato. With -gnato it checks that the
> addition doesn't overflow.
Oh, sorry, I thought we were talking about the overflow check...
> But there are no checks on the array access. It looks li
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 15:33 ---
I also see this failure on powerpc-darwin after changing MOVE_RATIO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
--- Comment #61 from baldrick at free dot fr 2008-03-30 15:16 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> > And here's a testcase that was supposed to check that
> > VRP is not removing checks that array accesses are in
> > range. Instead it shows that the Ada f
--- Comment #60 from rguenth at gcc dot gnu dot org 2008-03-30 15:09
---
function overflow (x : positive) return integer is
y : positive;
a : static array (1 .. 16#7FFF_#) of integer;
pragma import (ada, a);
begin
R4b : constant long_long_integer := long_long_integer?(a
--- Comment #59 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:03
---
> And here's a testcase that was supposed to check that
> VRP is not removing checks that array accesses are in
> range. Instead it shows that the Ada f-e is failing
> to generate checks at all!
Even with -gnat
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-30 14:57 ---
Subject: Bug 31023
Author: rguenth
Date: Sun Mar 30 14:56:28 2008
New Revision: 133731
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133731
Log:
2008-03-30 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #58 from rguenth at gcc dot gnu dot org 2008-03-30 14:55
---
Btw, can we have those testcases in gnat.dg/ with a name I can remember
(bounds-N.adb or similar)? Looking for testcases in acats is no fun ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #57 from rguenther at suse dot de 2008-03-30 14:52 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, baldrick at gcc dot gnu dot org wrote:
> --- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
> ---
> And he
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-30 14:45
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #56 from baldrick at free dot fr 2008-03-30 14:26 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> > What does "must be in the range" mean? Firstly, the program behaviour is
> > undefined if a variable is outside its range.
>
> That's not true. The refe
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-30 14:25 ---
Fixed on trunk and 4.3. Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-30 14:23 ---
Subject: Bug 35740
Author: pault
Date: Sun Mar 30 14:23:10 2008
New Revision: 133730
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133730
Log:
2008-03-30 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
---
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is failing
to generate checks at all!
function Overflow (X : P
--- Comment #54 from baldrick at gcc dot gnu dot org 2008-03-30 14:14
---
Here's a test that VRP is not eliminating
validity checks. "abort" should be called
if either X or Y is <= 0. With Richard's
latest patch (from the gcc mailing list)
applied, everything is fine: the tests are
st
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-30 14:14 ---
Subject: Bug 35740
Author: pault
Date: Sun Mar 30 14:13:21 2008
New Revision: 133729
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133729
Log:
2008-03-30 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
In C++, when theres a class with multiple inheritance and one wants to cast a
pointer to it to the type of a base class which is not the first in the list,
like in this code:
class D: public B1, B2 { . . . };
D* d = get_some_D_possibly_NULL();
B2* b = d;
the pointer must be offset according to t
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-30 13:51 ---
> -ff2c: the return value is returned in an additional argument as g77 and other
> fortran compilers do it
I want to point out that all? modern compiler use the -fno-f2c scheme which is
compatible with the default gf
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 13:40 ---
CLOSED AS INVALID.
> return type of complex functions not C compatible
While (with the default options) Fortran should be compatible with C in this
case, the proper way would be to use Fortran 2003's BIND(C) feature
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-30 13:34
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
As I understand the gfortran docs, the -ff2c/-fno-f2c switches change how
functions returning complex numbers are implemented:
-ff2c: the return value is returned in an additional argument as g77 and other
fortran compilers do it (can be seen e. g. in
http://www.pgroup.com/doc/pvfug.pdf, chapter 1
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-30 12:40 ---
This one should be straightforward, if lengthy to correct:
gfc_trans_where_2 is completely correct, as can be verified by doubling up the
line making the assignment in the WHERE block. ie:
WHERE (LDA)
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:27 ---
Really, this is a WORKSFORME, code in Comment #2 is fine everywhere.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
1 - 100 of 102 matches
Mail list logo
