program test
implicit none
type A
integer, allocatable :: j(:)
end type A
type(A):: x
x=f()
contains
function f()
type(A):: f
print *,"I'm only called once in the fortran!"
f = A((/1,2/))
end function f
end program
calls the function twice!
The code produced shows that
--- Comment #7 from gschafer at zip dot com dot au 2006-10-11 06:18 ---
The root cause of this bug is obvious after studying gcc.c. Essentially, the
user specified specs are read _way_ too late in the process. The sequence is
roughly this:
1 - search for default specs file, if found
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-10-11 06:11 ---
Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work
FX,
>
>That's because of F95 13.14.53:
>
>Case (i): For an array section or for an array expression other than a whole
>array or array structure component, LBOUND(ARRA
--- Comment #6 from igodard at pacbell dot net 2006-10-11 05:36 ---
Done
--
igodard at pacbell dot net changed:
What|Removed |Added
Status|NEW
class foo {
public:
template
foo(int i) : j(i) {}
template
void bar(int i) { j = i; }
template
static
void baz(int i) {}
int j;
};
int main() {
foo::baz(3);
foo* p; p->bar(3);
new foo(3);
return 0;
}
gets you:
~/ootbc/chips$ g++ foo.cc
f
--- Comment #4 from bangerth at dealii dot org 2006-10-11 03:43 ---
Confirmed. 12.5/4 reads to me as if myclass::operator delete[] should be
called. Indeed icc doesn't call either user defined operator in the
array case. I think that's just a convergence of bugs, though.
This appears to
--- Comment #5 from bangerth at dealii dot org 2006-10-11 03:35 ---
Um, the error message says
`foo' is not a template
which is about as accurate as can be.
That said, the request for a warning for constructors that can't be called
is ok. Would you mind opening a new report only abou
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-11 03:12
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-11 03:10 ---
Subject: Bug 28450
Author: pinskia
Date: Wed Oct 11 03:10:25 2006
New Revision: 117627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117627
Log:
2006-10-10 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Summary|static __recursive_mutex|[4.2 Regressi
The concurrence.h mutex lock/unlock changes of 13 Sept have caused
failure of all C++ testcases using std::cout on mingw32, iff -mthreads
(enabling __gthread_active_p) option is added to RUNTESTFLAGS.
Originally, the failures were of the form"
"terminate called after throwing an instance of 'std:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 02:50 ---
I think this is related to PR 27657.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 02:48 ---
Reduced testcase:
template
struct lambda_functor
{
lambda_functor() {}
};
namespace {
lambda_functor<2 > free2;
lambda_functor<3 > free3;
lambda_functor<3 > & _3 = free3;
}
int main (void){}
--
pinskia at gcc
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-10-11 02:46 ---
I've verified my fix for the other two bugs will fix this (sorry that one is
taking so long).
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-10-11 02:43 ---
Actually, AFAICT this is a variant of the struct aliasing bug zdenek reported.
The real problem is that we eliminate the false aliases and because their is no
real addressable variable here, the asm's miss out on the
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-11 02:37 ---
(In reply to comment #5)
> (In reply to comment #4)
> > asm("stw%X0 %1,%0" ::"r"(a->t) :"r"(3) : "memory");
> This is what I get for making a runtime testcase in the bug report.
> That asm should be:
> asm("stw%X
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-11 02:35 ---
(In reply to comment #4)
> asm("stw%X0 %1,%0" ::"r"(a->t) :"r"(3) : "memory");
This is what I get for making a runtime testcase in the bug report.
That asm should be:
asm("stw%X0 %1,%0" ::"r"(a->t) ,"r"(3) : "mem
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-11 01:21 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 01:05 ---
(In reply to comment #3)
> No, that's perfectly valid, you can't jump out of an asm or jump into it,
> but if you enter the asm and exit it, it doesn't matter what branches or calls
> were used inside it (of course i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |tree-optimization
Keywords||ali
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|tree-optimization |middle-end
h
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-10-11 00:43
---
*** Bug 29425 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-11 00:43 ---
Fixed for 4.2.0. This is also a dup of bug 9737.
*** This bug has been marked as a duplicate of 9737 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-11 00:42 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Maybe you've got this already but I don't see it. The following fails
to compile (reports an ambiguity) in g++ 4.0.3:
#include
template
class two { };
template
struct print {
void operator()(void) const
{ std::cout << "1" << std::endl; }
};
template class T,
Executing on host:
/home/dave/gcc-4.2/objdir/hppa-linux/libjava/testsuite/../lib
tool --silent --tag=GCJ --mode=link /home/dave/gcc-4.2/objdir/gcc/gcj
-B/home/da
ve/gcc-4.2/objdir/hppa-linux/libjava/ -B/home/dave/gcc-4.2/objdir/gcc/
--encodin
g=UTF-8 -B/home/dave/gcc-4.2/objdir/hppa-linux/libjava/t
--- Comment #4 from danglin at gcc dot gnu dot org 2006-10-10 23:00 ---
This bug is still present on trunk:
-bash-2.05b$ /test/gnu/gcc/objdir/gcc/g++ -B/test/gnu/gcc/objdir/gcc/ -S -O2 p>
pr29209.cc: In member function 'void
DataOutputStream_impl::_ZTv0_n12_N21DataOutputStream_impl16wri
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 ---
Update your source directory and rebuild in a clean obj directory.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #28 from danglin at gcc dot gnu dot org 2006-10-10 22:26
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 -w -O0
-L/test/g
nu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
--- Comment #18 from aesok at gcc dot gnu dot org 2006-10-10 22:18 ---
Subject: Bug 26504
Author: aesok
Date: Tue Oct 10 22:18:06 2006
New Revision: 117616
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117616
Log:
* config/avr/predicates.md: New file.
* config/a
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-10 22:04
---
(In reply to comment #3)
> Are you sure that this renormalization of the bounds is required? After all:
> (i) indices should always be realtive to lbound, whatever it is; and
> (ii) why would anybody be interested
The following code (derived from allocatable_1.f90)
Type drv
Integer::i
Integer,allocatable::arr(:)
End type drv
print *, fun1()
contains
Function fun1 ()
Type(drv)::fun1
Fun1%i=10
end function fun1
end
gives
allocatable_1_db.f90: In function MAIN__:
allocatable_1_db.f90:12:
--- Comment #2 from mtrudel at gmx dot ch 2006-10-10 21:20 ---
Fixed... The path separator was set to ":" on all platforms instead of ";" for
windows.
--
mtrudel at gmx dot ch changed:
What|Removed |Added
---
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-10 20:49 ---
Created an attachment (id=12406)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12406&action=view)
A development of the previous patch (ie. it works!).
This now regtests, apart from alloc_comp_basics_1.f90, which
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-10-10 20:07 ---
adding ABI keyword as implementing this may change mangling for "C" functions.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--
FAIL: gcc.dg/tree-ssa/ivopts-2.c scan-tree-dump-not \n candidates
.*,.*,.*\n[^\n]*\nFinal cost
appeared on mainline between 20060924 and 20060925 on hppa64-hp-hpux11.11 (this
is a new test assertion so probably not a regression).
--
Summary: gcc.dg/tree-ssa/ivopts-2.c scan-tree-dump
--- Comment #9 from tromey at gcc dot gnu dot org 2006-10-10 19:39 ---
I checked this in.
I'd still appreciate a review from Chris though.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from tromey at gcc dot gnu dot org 2006-10-10 19:38 ---
Subject: Bug 29362
Author: tromey
Date: Tue Oct 10 19:37:52 2006
New Revision: 117613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117613
Log:
PR classpath/29362:
* gnu/xml/transform/Transfo
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-10 19:36 ---
(In reply to comment #2)
> One last comment: I'm not sure the stride shouldn't be set to one. The patch
> above regtests fine, and can compile correctly everything I threw at it, but
> maybe I have not been clever eno
--- Comment #7 from jjohnstn at redhat dot com 2006-10-10 19:35 ---
I am confirming that the patch does fix the problem. With patch, the original
Eclipse CDT problems have gone away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #6 from tromey at gcc dot gnu dot org 2006-10-10 19:32 ---
Subject: Bug 29362
Author: tromey
Date: Tue Oct 10 19:31:56 2006
New Revision: 117612
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117612
Log:
PR classpath/29362:
* gnu/xml/transform/Transfo
--- Comment #3 from jakub at gcc dot gnu dot org 2006-10-10 18:55 ---
No, that's perfectly valid, you can't jump out of an asm or jump into it,
but if you enter the asm and exit it, it doesn't matter what branches or calls
were used inside it (of course if the function you call inside it
--- Comment #5 from tromey at gcc dot gnu dot org 2006-10-10 18:45 ---
I've checked in the fix on the trunk.
Do we need this in 4.1? I assume not on the theory that
now the file names won't clash...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
--- Comment #4 from tromey at gcc dot gnu dot org 2006-10-10 18:44 ---
Subject: Bug 29205
Author: tromey
Date: Tue Oct 10 18:44:06 2006
New Revision: 117610
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117610
Log:
PR libgcj/29205:
* Makefile.in: Rebuilt.
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-10-10
18:25 ---
r117410 is the first version showing the failure.
r117410 | mmitchel | 2006-10-03 20:06:00 +0200 (Di, 03 Okt 2006) | 12 lines
PR c++/29138
* decl2.c (grokfield): Don't handle access declara
--- Comment #5 from debian-gcc at lists dot debian dot org 2006-10-10
18:04 ---
20060928 works
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
--- Comment #3 from tromey at gcc dot gnu dot org 2006-10-10 17:19 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-10 16:46 ---
__asm __volatile ( "call *_dl_sysinfo\n\t" : "=a" (__status) : "0" (240), "b"
(&mutex->__data.__lock), "S" (0), "c" (0), "d" (_val), "i" (__builtin_offsetof
(tcbhead_t, sysinfo)) : "memory");
I think what you are d
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnosti
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-10 16:35 ---
Why do you think this is a GCC bug and not a GNUStep bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-10 16:33
---
*** Bug 29411 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-10 16:33 ---
This is really a dup of bug 2316. I forgot to mention that in PR 29095.
Oh and this is not an enhancement because you can have wrong code and also
rejects valid testcases see the dup bug report about those cases.
*
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-10 16:30 ---
(In reply to comment #3)
> It's at least accepted by EDG and Comeau in strict-ansi mode. (so, confirmed)
Don't take EDG/Comeau as conforming to the standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-10-10 16:27
---
*** Bug 29409 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-10 16:27 ---
Already fixed for 4.1.2.
*** This bug has been marked as a duplicate of 26504 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from mark at codesourcery dot com 2006-10-10 16:23 ---
Subject: Re: [4.0/4.1/4.2 Regression] Bogus ambiguity with
templates + friend
bangerth at dealii dot org wrote:
> We've been over that before, Andrew. It has always been the case that
> bugmasters do the initial tr
--- Comment #1 from peter at chocky dot org 2006-10-10 16:17 ---
Created an attachment (id=12405)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12405&action=view)
minimal test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
This is with:
gcc (GCC) 4.2.0 20061007 (experimental)
On x86 Debian and under Fedora Core 3.
Using the lamba part of the boost library, the following is seen:
/tmp/ccNdhcXx.o:(.debug_info+0xec9): undefined reference to
`boost::lambda::(anonymous namespace)::free2'
/tmp/ccNdhcXx.o:(.debug_info+
--- Comment #1 from christophe at saout dot de 2006-10-10 15:40 ---
Created an attachment (id=12404)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12404&action=view)
preprocessed pthread_mutex_lock.c causing the miscompiled code
Call with "gcc -O2 -o test.o -c pthread_mutex_lock.c
Using gcc 4.2 snapshot 20061007 on x86, the compiler is miscompiling glibc 2.5
(see http://sourceware.org/bugzilla/show_bug.cgi?id=3328)
What is happening is that a test of a variable after an inline asm block is
moved around so that the load of the struct member is moved above the asm block
even
--- Comment #13 from bangerth at dealii dot org 2006-10-10 15:18 ---
(In reply to comment #12)
> In comment #9: shouldn't be too hard.
> In comment #11: No, it will actually take significant time
It's a long and boring process. It's not complicated, it just takes time.
> If the explan
--- Comment #12 from mi at aldan dot algebra dot com 2006-10-10 15:13
---
In comment #9: shouldn't be too hard.
In comment #11: No, it will actually take significant time
If the explanation for the above discrepancy is simply not having access to a
FreeBSD machine, such an access can b
--- Comment #11 from bangerth at dealii dot org 2006-10-10 14:56 ---
(In reply to comment #10)
> For you, the developers, it is, probably, indeed faster, than writing another
> explanation, why you "have no resources" to do it...
No, it will actually take significant time, since one has
--- Comment #10 from mi at aldan dot algebra dot com 2006-10-10 14:52
---
(In reply to comment #9)
> finding the relevant patch using a binary search of the subversion archive
> between the revision numbers of the 3.4 branchpoint and the 4.0 release
That's the problem -- how can I, who
--- Comment #7 from uros at kss-loka dot si 2006-10-10 14:48 ---
(In reply to comment #6)
> Confirmed (as in comment #1). With -Os instead of -O2 we even produce
>
> .L3:
> movl%ebx, -4(%edx)
The -4(...) part comes from PR 24669.
--
http://gcc.gnu.org/bugzilla/show_bu
Issues building GNU java on Solaris2.10 X64:
Configured to use: GNU as, SUN linker, pthreads, java-awt=xlib
* SUN's /bin/sh is broken... set CONFIGURE_SHELL to /bin/ksh or /bin/bash
* SUN tools like sed, grep, tar, find are also deficit. Use GNU tools.
* the java build requires a version of jar
--
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 #17 from rguenth at gcc dot gnu dot org 2006-10-10 14:32
---
No, it's extract_range_from_binary_expr operating on [0, +INF] + [0, 65535] and
blindly using int_const_binop to compute the resulting range...
I believe the following is completely bogus and we cannot ignore over
--- Comment #6 from bangerth at dealii dot org 2006-10-10 14:25 ---
(In reply to comment #5)
> foo should not have been injected by the friend.
True, but that's irrelevant here. We get a tentative declaration that we
simply have to unify with the later real declaration.
> Note the Pri
--- Comment #4 from igodard at pacbell dot net 2006-10-10 14:17 ---
Yes, there IS something you can do about it. The compiler already checks
whether a
template is resolved by its data arguments (the message is something like
"nothing
of foo depends on any template argument and so ..."
$ mips-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE
#define MIPSEB 1
#define __MIPSEB__ 1
#define _MIPSEB 1
#define __MIPSEB 1
$ mipsel-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE
#define __MIPSEL__ 1
#define MIPSEL 1
#define _MIPSEL 1
#define __MIPSEL 1
$ mips64el-linux-gcc -EB -dM
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-10 14:06 ---
Confirmed (as in comment #1). With -Os instead of -O2 we even produce
.L3:
movl%ebx, -4(%edx)
incl%eax
.L2:
addl$4, %edx
cmpl%ecx, %eax
jb .L3
(because
--- Comment #14 from amacleod at redhat dot com 2006-10-10 14:03 ---
TER acts only within a basic block, and that will probably not change. Its
primary function is simply to mash trees back together so the expander gets a
better look.
This is more likely to handled by the RABLET work
--- Comment #5 from patchapp at dberlin dot org 2006-10-10 13:55 ---
Subject: Bug number PR25519
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00542.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from vincent at vinc17 dot org 2006-10-10 13:53 ---
(In reply to comment #2)
> What's worrying me a bit is the versioning of MPFR.
Note that GMP is similar.
> Vincent, would it be possible that some version number is increased every
> time a patch is posted, so that the
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-10 12:48 ---
(In reply to comment #3)
> Paul,
>
> I'm not sure, but I think PR29394 is related to that one.
>
Yes, I already verified that yesterday but forgot to make a note of it. I'm
just gearing up to an afternoon of gfortra
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-10 12:47 ---
(In reply to comment #4)
> Created an attachment (id=12403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12403&action=view) [edit]
> Fix for the problem
Sorry, I should have said that this gets rid of the TWO p
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-10 12:41 ---
Created an attachment (id=12403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12403&action=view)
Fix for the problem
Regtested on FC5/Athlon
Will submit asap.
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-10 12:40 ---
Created an attachment (id=12402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12402&action=view)
Fix for this PR
Regtested on FC5/Athlon
Will submit asap.
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-10-10 11:58
---
On mainline we now have
f:
xorl%eax, %eax
movla, %edx
cmpl$0, 4(%esp)
movlb, %ecx
jne .L4
movl%edx, %eax
sarl$31, %edx
id
--- Comment #41 from rguenth at gcc dot gnu dot org 2006-10-10 11:19
---
We're still 100% slower than 4.0.3 on the mainline:
Execution times (seconds)
callgraph construction: 0.21 ( 0%) usr 0.03 ( 2%) sys 0.23 ( 0%) wall
11563 kB (13%) ggc
callgraph optimization: 0.01 ( 0%)
Recently I upgraded gcc from 3.3.2(really outdated!) to 3.4.6 on HPUX 11.23
June 2006 update. This build on both ia64 and pa-risc machines.
This gcc is built on HPUX 11.23 by using the native ANSI C compiler.
# what /opt/ansic/bin/cc
/opt/ansic/bin/cc:
HP aC++/C for Integrity Servers B391
--- Comment #27 from bkoz at gcc dot gnu dot org 2006-10-10 10:14 ---
Subject: Bug 29118
Author: bkoz
Date: Tue Oct 10 10:14:13 2006
New Revision: 117600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117600
Log:
2006-10-09 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-10-10 10:09 ---
This would be an enhancement to both g++ and the IA64 C++ ABI.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
---
>From comment #7 in 29095 we have:
The technical issue is that in the following code:
extern "C" {
typedef void (*p1)();
}
typedef void (*p2)();
p1 and p2 are distinct types, and, in fact, you can overload based on that.
G++ doesn't implement that distinction; we don't keep track of l
--- Comment #26 from bkoz at gcc dot gnu dot org 2006-10-10 09:54 ---
Ok. I think I'll put this in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-10 09:50 ---
FX,
There are two problems here; one is specific to LEN and the other is generic to
intrinsics and array valued actual arguments:
The LEN specific problem is that there is no need to call the function at all,
in the
--- Comment #13 from jakub at gcc dot gnu dot org 2006-10-10 09:47 ---
Subject: Bug 29272
Author: jakub
Date: Tue Oct 10 09:46:59 2006
New Revision: 117599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117599
Log:
PR middle-end/29272
* builtins.c (var_decl_compo
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
The following code:
program chop
integer ix, iy
real x, y
x = 1.
y = x
ix = transfer(x,ix)
iy = transfer(y,iy)
print '(2z20.8)', ix, iy
if (ix /= iy) call abort
end program chop
when compiled with -O1 (or below) on PPC OSX 10.3, gives the correct result:
3F80
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-10 08:52 ---
It's at least accepted by EDG and Comeau in strict-ansi mode. (so, confirmed)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-10 08:27 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-10 08:27 ---
Subject: Bug 29323
Author: rguenth
Date: Tue Oct 10 08:27:02 2006
New Revision: 117598
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117598
Log:
2006-10-10 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 08:13
---
I'm very interested in that. I think it would really benefit the compiler: the
Fortran front-end would gain much in stability (and ease of installation) and
the C front-end could also benefit from this (as mention
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:56
---
Paul,
I'm not sure, but I think PR29394 is related to that one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:31
---
For the TRANSPOSE case, the generated code shows that the {u,l}bounds simply
aren't set right:
$ cat pr29391.f90
integer :: i(-1:1,-1:1)=0, j(2)
j = lbound(transpose(i))
end
$ cat pr29391.f90.003t.original
98 matches
Mail list logo
