=== asr (all)
cc -O -pipe -funroll-loops -march=pentium3 -Werror
-D_KERNEL -DKLD_MODULE -nostdinc -I-
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/IBsec/opt_global.h -I. -I@
-I@/contrib/altq -I@/../include -finline-limit=8000
-fno-common -I/usr/obj/usr/src/sys/IBsec
--- Comment #4 from raj dot khem at gmail dot com 2006-04-10 07:38 ---
I am unable to compile glibc 2.3.6 with GCC 4.1 on all mips-linux architecture
because of this ICE.
--
raj dot khem at gmail dot com changed:
What|Removed |Added
--- Comment #17 from rguenther at suse dot de 2006-04-10 08:10 ---
Subject: Re: loop header should also be pulled
out of the inner loop too
On Mon, 9 Apr 2006, rakdver at gcc dot gnu dot org wrote:
(In reply to comment #14)
(In reply to comment #11)
I updated the patch for
I have configured gcc-4.1.0 with the following command:
configure --enable-threads --enable-languages=c,c++ --enable-bootstrap
--with-gnu-as --with-gnu-ld
The system has GNU binutils 2.16 installed and when running gmake bootstrap
it compiles all 3 stage but fails during the compare stage with:
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-04-10 08:50
---
I have configured gcc-4.1.0 with the following command:
configure --enable-threads --enable-languages=c,c++ --enable-bootstrap
--with-gnu-as --with-gnu-ld
Do not use --enable-bootstrap, it has not been
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-10 09:00 ---
We go via expand_builtin_memset which expands strlen at
len_rtx = expand_normal (len);
but then, expand via setmem fails, so we bail out
else if (!set_storage_via_setmem(dest_mem, len_rtx,
--- Comment #12 from sebastian dot pop at cri dot ensmp dot fr 2006-04-10
09:14 ---
Created an attachment (id=11235)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11235action=view)
proposed fix
This patch fixes the problem, but probably it is a more general optimization
fix than
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-10 10:24 ---
Subject: Re: loop header should also be pulled out of the inner loop too
actually, thinking about it again, it should suffice to teach
invariant_without_guard_p about invariant memory
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-10 11:34
---
Confirmed. Reduced testcase
(compile with g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0):
=
struct A
{
~A();
};
struct B : A
{
B();
};
templateint struct C
{
--- Comment #2 from sagar dot indalkar at ge dot com 2006-04-10 11:45
---
Created an attachment (id=11236)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11236action=view)
Config log of gcc-4.0.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
--- Comment #3 from sagar dot indalkar at ge dot com 2006-04-10 11:46
---
Hi,
As per suggestion given, I have downloaded the gcc compiler version 4.0.3 and
uploaded to the box. When started configuring the using the command given
below.
../gcc-4.0.3/configure
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-10 11:54
---
Probably related to PR 26626.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-10 11:56
---
So it is indeed chicken and egg ;) load-PRE does not PRE the loads if the loop
is not in do-while form, and we won't hoist the loop header copies until the
loads are PREd. As to comment #13, if we are able to
--- Comment #2 from andy at trojanfoe dot servebeer dot com 2006-04-10
12:01 ---
If I configure without --enable-bootstrap I get this error quite early on
during the build:
config.status: creating libada-mk
config.status: creating auto-host.h
config.status: executing default commands
--- Comment #16 from jakub at gcc dot gnu dot org 2006-04-10 12:02 ---
Subject: Bug 24685
Author: jakub
Date: Mon Apr 10 12:02:55 2006
New Revision: 112819
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112819
Log:
PR libgfortran/24685
* io/write.c
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-10 13:18 ---
Subject: Bug 27057
Author: jakub
Date: Mon Apr 10 13:18:19 2006
New Revision: 112820
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112820
Log:
PR debug/27057
* dwarf2out.c (is_symbol_die):
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-10 13:21 ---
Subject: Bug 27057
Author: jakub
Date: Mon Apr 10 13:21:13 2006
New Revision: 112821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112821
Log:
PR debug/27057
* dwarf2out.c (is_symbol_die):
The compiler segfaults on the following valid code snippet when invoked
with g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0:
struct A
{
friend void foo() {}
friend void foo();
};
The error message on mainline is:
This is probably a duplicate of something that has been filed before,
but my cursory search failed to turn up any similar tickets.
GCJ rejects code that both Sun and Eclipse compilers accept.
Here's the test case:
| $ cat Reluctant.java
| public class Reluctant {
| private Reluctant
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-10 13:58
---
Confirmed. One can also use the following for t1.cc:
=
#include t.hh
void foo() {}
=
--
reichelt at gcc dot gnu dot org changed:
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-10
14:19 ---
The peculiar code turns out to be a result of the way in which I kludged my way
past the ICE. In sorting the out, I found that there is a double fault:
The implicit result version of the above
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-04-10
14:35 ---
(In reply to comment #5)
(In reply to comment #4)
A little further reduced:
Actually that is a different bug.
Anyways the reduced testcase looks like:
FUNCTION reallocate_hnv(p,n,LEN)
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-10
14:48 ---
A patch (not regtested yet, nor tested on tonto) and testcase for this and
PR25597:
Index: gcc/fortran/trans-decl.c
===
---
gcc gives segmenation fault on the following code:
template class T
void T::foo() {
}
--
Summary: Semgmentation Fault on Template
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component:
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-04-10 15:01
---
Confirmed.
We had a similar problem with template classes in PR18731.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-10 15:03
---
Btw, the ICE is a segfault on the 4.0 branch.
On the 4.1 branch and mainline we get:
bug.cc:2: internal compiler error: in is_ancestor, at cp/name-lookup.c:
--
--- Comment #14 from paul dot richard dot thomas at cea dot fr 2006-04-10
15:07 ---
(In reply to comment #13)
PR23634 does not affect this PR. So only two bugs left. I checked by
commenting out the lines effecting compiling.
I have submitted 2 PRs for tonto-2.2; PR25597 and
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-10 15:31
---
I wonder if it helps placing this between cunroll and ivopts...
void foo(int n, int m, int stridex, int stridey, int stridex2, int stridey2,
double *x, double *y)
{
for (int k=0; km; ++k)
for (int j=0; jn;
--- Comment #24 from edmar at freescale dot com 2006-04-10 15:42 ---
I am sorry, but the patches on comments 17, 18, 21, and 22 are no good without
the
patch on comment 5, which seems, it was never commited into the repository...
Can you double check this. Thanks.
Edmar
--
edmar
--- Comment #14 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-10 15:53 ---
Subject: Re: IVs with the same evolution not eliminated
I wonder if it helps placing this between cunroll and ivopts...
void foo(int n, int m, int stridex, int stridey, int stridex2, int
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-04-10 15:55
---
config.status: creating libada-mk
config.status: creating auto-host.h
config.status: executing default commands
Bootstrapping the compiler
gmake[1]: Entering directory `/tmp/gcc-4.1.0/gcc'
gmake[1]: *** No
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-10 16:22 ---
Here is another testcase (which was reduced from the same source and gives a
similar error message but does not have inheritance in it):
templatetypename _Tp struct allocator
{
~allocator() throw() { }
};
struct
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-10 16:28 ---
*** This bug has been marked as a duplicate of 11813 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-10 16:28
---
*** Bug 27098 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-04-10 16:30 ---
Please next time if you going to put the testcase inline don't put stuff in
front of the testcase so it can be easy to access.
Anyways confirmed.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 16:34 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-10 16:35 ---
It is a dup, Daniel asked me yesterday to close it as one but I did not get
around to it til today.
*** This bug has been marked as a duplicate of 26626 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-04-10 16:35
---
*** Bug 27085 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-10 16:40 ---
That error should not effect compiling of GCC unless you need a fortran
compiler and then you need to read:
http://gcc.gnu.org/install/
AND:
http://gcc.gnu.org/install/prerequisites.html
People build all the time
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #5 from sagar dot indalkar at ge dot com 2006-04-10 16:49
---
Hi,
Thanks for quick response. I am not installing Fortran compiler, I am only
installing the gcc compiler. After your mail I have tried running the make
command. make command still giving the error. The error
--- Comment #2 from polite at itd dot nrl dot navy dot mil 2006-04-10
17:25 ---
I tried the same thing with gcc 4.1.0 and I got the same result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26066
--- Comment #2 from vnasardinov at gmail dot com 2006-04-10 18:12 ---
Tom Fitzsimmons stopped complaining about my pipe-quoting technique
after I told him about M-x delete-rectangle a.k.a. C-x r d. Takes
about 5 seconds in Emacs to fix this up. One, if you type really fast :)
Thanks
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-10 18:12 ---
Well really more like:
int f(int *a)
{
int t = *a;
unsigned *b = (unsigned *)a;
int *c = (int*)b;
return *c + t;
}
Which should be the same as:
int f(int *a)
{
return *a * 2;
}
--
--- Comment #13 from sje at cup dot hp dot com 2006-04-10 18:22 ---
Putting the size of pad back seems OK on IA64 in both ILP32 and LP64 modes. In
ILP32 mode I get:
The DTP
Size of p: 136
Size of pad: 200
Size of char *: 4
Size if int: 4
In LP64 mode, both on HP-UX and Linux, I get:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-10 18:24 ---
(In reply to comment #2)
Tom Fitzsimmons stopped complaining about my pipe-quoting technique
after I told him about M-x delete-rectangle a.k.a. C-x r d. Takes
about 5 seconds in Emacs to fix this up. One, if you
[ forwarded from http://bugs.debian.org/361814 ]
[EMAIL PROTECTED]:/tmp% cat test.c
typedef struct { int size; } gnutls_datum;
typedef struct gnutls_cert { gnutls_datum raw; } gnutls_cert;
typedef struct { } gnutls_privkey;
int _gnutls_log_level;
void _gnutls_log(void);
void
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 18:43 ---
Related to PR 26490.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE: tree check: expected
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 18:45 ---
This works with 4.2.0 20060409.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-04-10
18:53 ---
(In reply to comment #2)
This works with 4.2.0 20060409.
Hmm. I get the ICE with 4.2.0 20060407. Will try a newer one...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
All of the compiler versions are the same as in bug 27101.
Sun's compiler:
| $ javac UnwelcomeGuest.java
| UnwelcomeGuest.java:9: variable USER_ID might already have been assigned
| USER_ID = GUEST_USER_ID;
| ^
| 1 error
The Eclipse compiler:
| $ ecj
--- Comment #1 from vnasardinov at gmail dot com 2006-04-10 19:02 ---
Created an attachment (id=11237)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11237action=view)
the test case
This comes from http://www.javapuzzlers.com/java-puzzlers.zip with minor
modifications.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 19:04 ---
And I already filed this once before too :).
Anyways this is a dup of bug 24835.
*** This bug has been marked as a duplicate of 24835 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 19:04 ---
*** Bug 27104 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from vnasardinov at gmail dot com 2006-04-10 19:15 ---
Thanks. It would help to have the words definite assignment
and/or definitely unassigned and/or
http://java.sun.com/docs/books/jls/third_edition/html/defAssign.html
somewhere in the summary or comments, so people can
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:49 ---
Boooiinngg...
Or, is anyone working on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:57 ---
GCC 3.4 did better, said the reporter in comment #0.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-04-10
20:17 ---
Subject: Re: gcc pessimized 64-bit % operator on hppa2.0
Boooiinngg...
Or, is anyone working on this?
I'm not. Note that the HP code is using 64-bit registers and instructions
in 32-bit
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-10 20:18 ---
The resulting code for -march=opteron:
test_bit:
.LFB2:
leal63(%rsi), %edx
testl %esi, %esi
movl%esi, %eax
cmovns %esi, %edx
sarl$31, %eax
shrl$26,
--- Comment #3 from steven at gcc dot gnu dot org 2006-04-10 20:31 ---
This is what the i386 machine description has to say about BT and friends:
;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation. When
I tried the last (gcc-4.2-20060408) snapshot.
When I compile the preprocessed source t.ii the compiler segfaults.
/usr/local/gcc42h/bin/g++42h -O3 -ftree-loop-linear -S t.ii
g++42h -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2-20060408/configure
--- Comment #1 from micis at gmx dot de 2006-04-10 20:33 ---
Created an attachment (id=11238)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11238action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 20:49 ---
Yes, it is known that -ftree-loop-linear is buggy. There might already be a
dup of this bug too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from andy at trojanfoe dot servebeer dot com 2006-04-10
23:18 ---
Thanks, I thought I had read that pretty well. Am I being stupid?
Andy
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
When revising libgfortran/io/io.h by itself, make does not recompile source
files that include io.h causing erroneous builds. To get files recompiled that
depend on io.h one must 'touch' the sourcefiles.
--
Summary: Make dependency on io/io.h broken
Product: gcc
--- Comment #25 from amodra at gcc dot gnu dot org 2006-04-11 00:33 ---
Subject: Bug 26459
Author: amodra
Date: Tue Apr 11 00:33:29 2006
New Revision: 112843
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112843
Log:
PR target/26459
* config/rs6000/e500-double.h
--- Comment #26 from amodra at gcc dot gnu dot org 2006-04-11 00:36 ---
Subject: Bug 26459
Author: amodra
Date: Tue Apr 11 00:36:50 2006
New Revision: 112844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112844
Log:
PR target/26459
* config/rs6000/e500-double.h
When compiling this (after cpp):
# 1 test.c
# 1 built-in
# 1 command line
# 1 test.c
# 1 /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h 1 3 4
# 43 /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h 3 4
typedef __builtin_va_list __gnuc_va_list;
# 105
--- Comment #27 from amodra at bigpond dot net dot au 2006-04-11 00:37
---
Sorry! My apologies for closing this bug without checking that the original
problem had been fixed. I was focusing on the code generation problems.
--
amodra at bigpond dot net dot au changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 01:06 ---
This is not a bug as foo is now a variable decl and not a typedef one so foo
a; would fail also.
Now if this was C++ you could use ::foo to get the typedef version of foo but
this is C and there is no way to access
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-11 01:21 ---
Just a note VN.2 should really have not been created (maybe there is no way
around this because it is just equivalant to VN.0). This actually gets fixed
by a real tree combiner since fold is able to fix up
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-11 01:33 ---
So I talked to Daniel about this and he said a new Number value system or the
tree combiner so basicially there is nothing can be done currently. Guess
maybe it is time for you Richard to stop hacking on fowardprop
--- Comment #6 from aldyh at gcc dot gnu dot org 2006-04-11 01:38 ---
Patch that fixes the problem.
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00380.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
Kinda like PR 14490 but for the -fwrapv and unsigned cases:
void bar (void);
void
foo (unsigned a)
{
if (a 100)
return;
if (200 a)
return;
if (a - 10 150)
bar ();
}
--
Summary: Simplify a - 10 150 into a 160 when range of a
is known (in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
--- Comment #3 from amodra at bigpond dot net dot au 2006-04-11 02:10
---
The same issue applies to VMX (Altivec) registers. With lazy fp/vmx task
switching, the first use of fp/vmx regs in a task can be expensive.
--
amodra at bigpond dot net dot au changed:
What
when compiling newlib with mcore-unknown-elf-gcc (v4.1.0) I get an internal
compiler error.
Compiler configure line
../gcc-4.1.0/configure --target=mcore-unknown-elf --disable-libssp
--enable-languages=c
The command line that triggers the bug is
mcore-unknown-elf-gcc
--- Comment #1 from peter dot jansen at aad dot gov dot au 2006-04-11
02:34 ---
Created an attachment (id=11239)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11239action=view)
Here is the preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27110
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 02:45 ---
*** This bug has been marked as a duplicate of 25690 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-11 02:45 ---
*** Bug 27110 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-11 02:49 ---
Altivec can be done with -mno-altivec and it is not really a real pain because
if you are going to use altivec registers in your program, you want to use them
more rather than less. And for the functions you don't
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 03:00 ---
It should be something like what XLC does at:
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/topic/com.ibm.xlcpp8l.doc/compiler/ref/ruprpdir.htm#RUPRPDIR
Which is actually much better than what is even in
--- Comment #5 from csm at gnu dot org 2006-04-11 04:21 ---
The original issue seems to be fixed; on gcj version `gcj (GCC) 4.2.0 20060410
(experimental)' I get this output from the `seed' testcase:
Byte difference in a seeded PRNG: 64
Seed data
--- Comment #6 from peter dot jansen at aad dot gov dot au 2006-04-11
04:32 ---
Its ok in gcc-3.4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
--- Comment #6 from david at jpackage dot org 2006-04-11 04:34 ---
I was saying something slightly different, since I did not test the program
across multiple runs. I did test nextBytes() within the same program run, and
this produced identical bytes with each successive call to
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-11 04:40 ---
Subject: Bug 26257
Author: pault
Date: Tue Apr 11 04:40:33 2006
New Revision: 112848
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112848
Log:
2006-04-11 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-11 04:42 ---
Sorry, I forgot about closing out this one on 4.1.
Fixed on trunk and 4.1.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
In the following program, generic procedure foo can be distinguished
between two procedure foo1 and foo2 by keywords of arguments.
But gfortran cannot compile this source code and output the same message
twice.
I think it is wrong behavior.
$ cat test.f90
module m1
implicit none
interface
Compiling tonto-2.2 reveals that structure components cannot be used in array
constructors:
subroutine complex_constructor
type BASIS_TYPE
character(len=512) :: label
end type
type(BASIS_TYPE), dimension(:), pointer :: var
call read_library_data_((/var%label/))
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-04-11 05:02
---
Intel agrees with gfortran:
fortcom: Error: foofoo.f90, line 25: The type/rank/keyword signature for this
specific procedure matches another specific procedure that shares the same
generic-spec. [FOO2]
use
--- Comment #5 from =?ISO-8859-15?Q?=22Thomas_Bj=F6rkman_=28=C4S/EAB=29=22?=
thomas dot bjorkman at ericsson dot com 2006-04-11 05:10 ---
Subject: Re: Should be able to not use fp moves for functions
that don't implicted use float points
Hej !
How come the slogan on Bug
--- Comment #2 from iguchi at coral dot t dot u-tokyo dot ac dot jp
2006-04-11 05:15 ---
(In reply to comment #1)
Intel does NOT agree with gfortran.
I think such discussion is not fruitful.
$ ifort --version
ifort (IFORT) 9.0 20060222
Copyright (C) 1985-2006 Intel Corporation. All
--- Comment #3 from law at redhat dot com 2006-04-11 05:41 ---
The problem is that may_propagate_copy and merge_alias_info are inconsistent.
ie, DOM properly calls may_propagate_copy to determine if a particular copy
propagation is valid. may_propagate_copy returns true indicating the
--- Comment #4 from law at redhat dot com 2006-04-11 05:56 ---
Subject: Re: [4.1/4.2 regression] ICE in
merge_alias_info
On Sat, 2006-04-08 at 23:16 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:16
97 matches
Mail list logo
