--- Comment #10 from pcarlini at suse dot de 2007-04-02 11:19 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from pcarlini at suse dot de 2007-03-31 17:52 ---
Taking care of it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #4 from fang at csl dot cornell dot edu 2007-03-27 08:52
---
Poor vectorbool, being disrespected as a second-class container once again...
:P
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2007-03-27 09:07 ---
Thanks. On the mainline and 4_2-branch we have new definitions of max_size,
taking into account, as should be, allocator::max_size. Can you please check
the vectorbool bits in this light? (well, about the status of
--- Comment #6 from gcc at severeweblint dot org 2007-03-27 20:27 ---
4.2 doesn't fix any of the problems, but it does make the max_size
issue a bit more confusing.
There is a subtle relationship between vector size and
pointers. Pointers can address only SIZE_MAX memory. But iterators
--- Comment #7 from pcarlini at suse dot de 2007-03-27 21:03 ---
Two quick replies:
4.2 doesn't fix any of the problems, but it does make the max_size
issue a bit more confusing.
Thanks, this is encouraging ;) In any case, nobody said 4.2 fixed any of those
problems. However, for
.
--
Summary: resizing bugs in std::vector
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at severeweblint dot org
--- Comment #1 from gcc at severeweblint dot org 2007-03-27 04:08 ---
Created an attachment (id=13292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13292action=view)
testcase
This little program pushes some of the boundary cases. It ought to print
nothing and exit cleanly.
. It does not incorporate the testcase attachment
into the gcc testsuite, although that surely ought to be done. (I got confused
by the makefile for the testsuite. sorry)
Note there are other approaches to fixing these bugs that might be better in
the long term:
1) It is plainly bad that vectorbool has
Summary|resizing bugs in std::vector|resizing bugs in
||std::vectorbool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
--- Comment #90 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:24
---
Closing as fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #83 from jv244 at cam dot ac dot uk 2007-03-16 11:11 ---
I upgraded trunk, and now the code compiles again with -march=native, but
crashes as follows:
Program received signal SIGILL, Illegal instruction.
0x00afa307 in __qs_resp__resp_fit ()
objdump -d gives me
--- Comment #84 from ubizjak at gmail dot com 2007-03-16 11:21 ---
(In reply to comment #83)
I upgraded trunk, and now the code compiles again with -march=native, but
crashes as follows:
Program received signal SIGILL, Illegal instruction.
0x00afa307 in __qs_resp__resp_fit
--- Comment #85 from jv244 at cam dot ac dot uk 2007-03-16 11:52 ---
(In reply to comment #84)
Could you post your cpuflags? There should be lahf_lm flag present for
opterons.
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts
--- Comment #86 from jv244 at cam dot ac dot uk 2007-03-16 12:07 ---
(In reply to comment #85)
(In reply to comment #84)
Could you post your cpuflags? There should be lahf_lm flag present for
opterons.
sorry, the previous post was of the wrong machine... these are the correct
--- Comment #87 from ubizjak at gmail dot com 2007-03-16 12:16 ---
(In reply to comment #86)
sorry, the previous post was of the wrong machine... these are the correct
flags and no (lahf_lm):
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 840
--- Comment #88 from ubizjak at gmail dot com 2007-03-16 12:43 ---
(In reply to comment #83)
I upgraded trunk, and now the code compiles again with -march=native, but
crashes as follows:
Program received signal SIGILL, Illegal instruction.
0x00afa307 in __qs_resp__resp_fit
--- Comment #89 from jv244 at cam dot ac dot uk 2007-03-16 14:16 ---
Thanks for your reports!
and you for your fixes... things are back to working now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #77 from jv244 at cam dot ac dot uk 2007-03-14 14:48 ---
Currently
GNU Fortran (GCC) 4.3.0 20070313 (experimental)
there seems to be a new gcc error on CP2K:
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
-msse2 fparser.f90
--- Comment #78 from ubizjak at gmail dot com 2007-03-14 15:01 ---
(In reply to comment #77)
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
-msse2 fparser.f90
/tmp/ccNk6D7G.s: Assembler messages:
/tmp/ccNk6D7G.s:820: Error: suffix or operands
--- Comment #79 from jv244 at cam dot ac dot uk 2007-03-14 15:14 ---
(In reply to comment #78)
Could you post the temporary asm (only lines around line 820 will be enough)
to
check what is going wrong?
.L157:
movslq %r13d,%rax
imulq %rsi, %rax
addq
--- Comment #80 from burnus at gcc dot gnu dot org 2007-03-14 15:15 ---
(In reply to comment #76)
One issue with OpenMP is that it is very easy to break an OpenMP
code (it is just comments),
This is a complaint I've heard before. I wonder if you have any suggestions
to make it more
--- Comment #81 from ubizjak at gmail dot com 2007-03-14 15:30 ---
(In reply to comment #79)
movsd %xmm2, (%rsp)
fldl(%rsp)
movsd %xmm1, (%rsp)
fldl(%rsp)
fxch%st(1)
.L120:
fprem
fnstsw %ax
sahf
--- Comment #82 from jv244 at cam dot ac dot uk 2007-03-14 16:29 ---
Huh, I somehow misread opteron for athlon. Your code is OK for x86_64, but it
looks to me that you will have to upgrade binutils.
upgrading binutils is not much of an option for me, but with -march=x86-64 I
get
--- Comment #76 from steven at gcc dot gnu dot org 2007-03-12 23:24 ---
Joost,
You wrote in comment #75:
One issue with OpenMP is that it is very easy to break an OpenMP
code (it is just comments),
This is a complaint I've heard before. I wonder if you have any suggestions to
make it
(Red Hat Linux 3.3.3-7)
--
Summary: FPE, floating point exception bugs
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:58 ---
These are all not compiler issues but glibc and/or kernel issues.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #74 from fxcoudert at gcc dot gnu dot org 2007-03-03 08:52
---
(In reply to comment #73)
I've added PR 31021 to track some performance issue with gfortran on one of
CP2K's kernels.
Thanks for your work, Joost. I wonder if you have done OpenMP testing, also (I
imagine
is that some of the mistakes one can make with openmp easily (such as a
forgotten critical section) only trigger bugs from time to time, e.g. depending
on how threads are scheduled. Anyway, many excuses to say 'not really, but
maybe soon'...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #73 from jv244 at cam dot ac dot uk 2007-03-02 08:41 ---
I've added PR 31021 to track some performance issue with gfortran on one of
CP2K's kernels.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-22 23:45 ---
The second part of this bug is recorded as PR 22156.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30913
foo tmp;
tmp = a;
bar = tmp;
}
SRA certainly should not have decided to use element copies at all, that makes
many times worse code.
--
Summary: SRA bugs with anon bitfields
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-21 15:18 ---
SRA certainly should not have decided to use element copies at all, that makes
many times worse code.
That is really unrelated to unanonymous bitfields and is a different bug and
has been filled already (I forgot
--- Comment #72 from jv244 at cam dot ac dot uk 2007-02-19 19:51 ---
I checked that gfortran yields correct results for the CP2K testsuite with the
options:
-O0 -g -fbounds-check
and
-O3 -ffast-math -funroll-loops -ftree-vectorize -fomit-frame-pointer -msse2
-march=native
I've added the
--- Comment #69 from jv244 at cam dot ac dot uk 2007-02-17 09:17 ---
(In reply to comment #68)
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local
--- Comment #70 from steven at gcc dot gnu dot org 2007-02-17 16:01 ---
The -ftree-loop-linear work is still too buggy at this time to be taken
seriously. I would strongly recommend against even considering the use of it.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #71 from jv244 at cam dot ac dot uk 2007-02-17 16:17 ---
(In reply to comment #68)
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local
--- Comment #68 from jv244 at cam dot ac dot uk 2007-02-17 07:50 ---
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local opteron.
all_cp2k_gfortran.f90:
--- Comment #64 from jvdelisle at gcc dot gnu dot org 2007-02-16 02:50
---
I now have a machine at home here running i686-pc-gnu-linux that I plan to set
up daily compile test on. Joost, does that link in coment #63 get updated
daily?
--
--- Comment #65 from jv244 at cam dot ac dot uk 2007-02-16 05:57 ---
(In reply to comment #64)
I now have a machine at home here running i686-pc-gnu-linux that I plan to set
up daily compile test on. Joost, does that link in coment #63 get updated
daily?
No, the idea is that you
--- Comment #66 from jvdelisle at gcc dot gnu dot org 2007-02-16 06:33
---
With todays trunk:
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr
--enable-languages=c,fortran --disable-libmudflap --enable-libgomp
Thread model: posix
gcc
--- Comment #67 from fxcoudert at gcc dot gnu dot org 2007-02-16 06:50
---
PR 30391 is fixed with rev. 122030, so we should close this PR. Please reopen
if we regress.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #60 from jv244 at cam dot ac dot uk 2007-02-13 09:20 ---
When you have a moment, could you confirm that all is now well with trunk,
please? Once again, I am sorry about the breakage. Now I see Daniel's
testcase, I realise that I could easily have devised a test... with
--- Comment #61 from pault at gcc dot gnu dot org 2007-02-13 13:51 ---
(In reply to comment #60)
Yes, current trunk compiles CP2K again at -O0
Great!
to time. It is very annoying to have to fight compilers, after the computer
center upgraded a machine. My hope is that CP2K being
--- Comment #62 from kargl at gcc dot gnu dot org 2007-02-13 19:50 ---
(In reply to comment #48)
Currently, there is a new ICE on CP2K (see initial comment) that happens at
any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal compiler
--- Comment #63 from jv244 at cam dot ac dot uk 2007-02-13 20:04 ---
Well, I'd add it to my testsuite if weren't a PITA to figure out how to
make it build.
wget http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz
gunzip all_cp2k_gfortran.f90.gz
gfortran -c
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-12 10:49 ---
To dect an ODR violation in this case, means a couple of things. First you
cannot compare byte for byte the function as one might be compiled with
optimizations and the other was compiled without. And then if you
--- Comment #48 from jv244 at cam dot ac dot uk 2007-02-12 15:56 ---
Currently, there is a new ICE on CP2K (see initial comment) that happens at any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal compiler error: Segmentation fault
Please
--- Comment #49 from fxcoudert at gcc dot gnu dot org 2007-02-12 16:16
---
(In reply to comment #48)
Currently, there is a new ICE on CP2K (see initial comment) that happens at
any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal
--- Comment #50 from jv244 at cam dot ac dot uk 2007-02-12 17:09 ---
I really think CP2K should be added to some nightly
tester somewhere by gfortran developers...
Well, I second that, but we first need to get it working (like, the middle-end
people have to move on PR30391).
--- Comment #51 from jv244 at cam dot ac dot uk 2007-02-12 17:12 ---
I'm pretty sure it's the same problem that was already reported here:
http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html
Of course, a confirmation wouldn't hurt, but I don't have time right now. If
you manage
--- Comment #52 from pinskia at gcc dot gnu dot org 2007-02-12 17:20
---
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #53 from jv244 at cam dot ac dot uk 2007-02-12 17:52 ---
(In reply to comment #52)
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
No, that one only happens at -O1 and above, the current ICE is at -O0
--- Comment #54 from pault at gcc dot gnu dot org 2007-02-12 18:02 ---
(In reply to comment #53)
(In reply to comment #52)
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
No, that one only happens at -O1 and
--- Comment #55 from jv244 at cam dot ac dot uk 2007-02-12 18:26 ---
Nonetheless, I do not see it being associated with my doo-doo in module.c, do
you?
I'm not an expert, but this is a traceback, leading to module.c:
Program received signal SIGSEGV, Segmentation fault.
--- Comment #56 from fxcoudert at gcc dot gnu dot org 2007-02-12 18:30
---
(In reply to comment #55)
Program received signal SIGSEGV, Segmentation fault.
gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 compare_symtree)
at
--- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 ---
Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html
for people reducing the bug, I found that it is in the module cp_fm_pool_types.
This indicates the the line number indicated in the segfault
--- Comment #58 from paulthomas2 at wanadoo dot fr 2007-02-12 22:55 ---
Subject: Re: [meta-bugs] ICEs with CP2K
jv244 at cam dot ac dot uk wrote:
--- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 ---
Yes, that's the one: http://gcc.gnu.org/ml/fortran
--- Comment #59 from pault at gcc dot gnu dot org 2007-02-13 06:56 ---
(In reply to comment #58)
Subject: Re: [meta-bugs] ICEs with CP2K
jv244 at cam dot ac dot uk wrote:
--- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18
---
Yes, that's the one
--- Comment #3 from Ivan dot Scherbakov at acronis dot com 2007-02-12
06:03 ---
The way of declaring inline functions as static is evident, but in fact, when
building large projects containing several libraries the case when the same
inline function is defined more than once in
--- Comment #2 from bangerth at dealii dot org 2007-02-11 04:11 ---
As Andrew said: this is a violation of the C++ standard. You can have
only one definition of a name and if you have more then your program is
in error. The fact that you mark your functions inline doesn't change
this:
Severity|normal |enhancement
Component|c |c++
Summary|Non-static inline functions |[ODR] Non-static inline
|cause bugs when defined more|functions cause bugs when
|than once
outputs
11.
--
Summary: Non-static inline functions cause bugs when defined more
than once in different files
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
?
By the way, I think one should leave in future this PR closed and open new PR;
this PR is a wild mixure between a meta bug (5 dependend bugs, now fixed) and a
couple of rather independent bugs reported directly here.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #47 from fxcoudert at gcc dot gnu dot org 2007-01-06 10:43
---
(In reply to comment #44)
Current gcc ICEs again on CP2K:
Reduced testcase reported as PR 30391. I appeared between 20070104 and today,
and happens on both i686-linux and x86-64 linux; I pinged the person that
--- Comment #44 from jv244 at cam dot ac dot uk 2007-01-06 06:30 ---
Current gcc ICEs again on CP2K:
gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron -fopenmp
mc_coordinates.f90
mc_coordinates.f90: In function check_for_overlap:
mc_coordinates.f90:192: internal compiler
--- Comment #45 from pinskia at gcc dot gnu dot org 2007-01-06 06:41
---
(In reply to comment #44)
gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron -fopenmp
mc_coordinates.f90
mc_coordinates.f90: In function check_for_overlap:
mc_coordinates.f90:192: internal compiler
--- Comment #43 from steven at gcc dot gnu dot org 2006-12-23 14:51 ---
Fixed in GCC 4.3.0
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #41 from pault at gcc dot gnu dot org 2006-12-21 15:05 ---
Subject: Bug 29975
Author: pault
Date: Thu Dec 21 15:05:24 2006
New Revision: 120113
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120113
Log:
2006-12-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #42 from burnus at gcc dot gnu dot org 2006-12-21 16:09 ---
I'm in faviour of closing this bug.
The patch associated to this PR is checked in into 4.3 and 4.2
And all the dependend bugs are either fixed or at least check into 4.3.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:27 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
pinskia at gcc dot gnu dot org writes:
You want -fno-inline-functions-called-once which was added in 4.2.0
IIRC (...)
I see
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:31 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
I just noticed another doc bug:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
That page says:
-O2
--- Comment #40 from jv244 at cam dot ac dot uk 2006-12-19 12:49 ---
I've now checked that gcc trunk (revision 120045) compiles CP2K (at -O3
-ftree-vectorize -ffast-math -march=opteron) and that the numerical results
seem acceptable. Great job... I hope the the original file is kept
or keywords/attributes, or something else?
Doc bugs in Info node (gcc)Inline:
(If you are writing a header file to be included in ISO C programs,
write `__inline__' instead of `inline'...)
Should now be ISO C90 programs.
Some calls cannot be integrated for various reasons (in particular
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-17 19:02 ---
You want -fno-inline-functions-called-once which was added in 4.2.0 IIRC (it is
in 4.3.0 for sure).
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
--
pinskia at gcc dot gnu dot org
--- Comment #36 from pault at gcc dot gnu dot org 2006-12-13 13:37 ---
Joost,
input_cp2k_motion.f90
input_cp2k_motion.f90: In function create_neb_section:
input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at
fold-const.c:2150
in fact, this is on a file
--- Comment #37 from jv244 at cam dot ac dot uk 2006-12-13 14:01 ---
(In reply to comment #36)
well, this was reduced, filed as PR30147, and fixed. Tobias reduced another one
and filed it as PR30190 (see dependencies).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
as FIXED as soon as everything is checked in.
(I think 4.2 is still missing, and maybe [or not] 4.1).
The rest should be handled in different bugs, but one can still link to this
bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #39 from jv244 at cam dot ac dot uk 2006-12-13 15:25 ---
I had a look at one of the failing testcases from CP2K testsuite, and under
valgrind there were a number of errors that could be reproduced in the small
testcase of PR30200
--
--- Comment #30 from jv244 at cam dot ac dot uk 2006-12-11 09:51 ---
(In reply to comment #29)
simple testcase for the segfault:
SUBROUTINE S(unit_number)
character(len=100) :: status_string
integer :: unit_number,istat
status_string=KEEP
CLOSE
--- Comment #31 from burnus at gcc dot gnu dot org 2006-12-11 10:07 ---
gcc version 4.3.0 20061210 (experimental)
simple testcase for the segfault:
I tried it with gfortran 4.3 and 4.2 (today's build) and an older 4.1 build and
neither crashes. valgrind also shows no error.
The
--- Comment #32 from jv244 at cam dot ac dot uk 2006-12-11 11:29 ---
(In reply to comment #31)
gcc version 4.3.0 20061210 (experimental)
simple testcase for the segfault:
I tried it with gfortran 4.3 and 4.2 (today's build) and an older 4.1 build
and
neither crashes. valgrind
--- Comment #33 from jv244 at cam dot ac dot uk 2006-12-11 11:54 ---
Running the CP2K regtests now results in:
number of FAILED tests 24
(these are just the runs that do not complete, I have not checked that the runs
that finish also generate the right numbers. This can be reproduced
--- Comment #34 from burnus at gcc dot gnu dot org 2006-12-11 15:56 ---
CP2k actually gives here an ICE with -O2 (PR 30147)
at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet
look at why the calculation results are wrong.
--
--- Comment #35 from jv244 at cam dot ac dot uk 2006-12-11 16:08 ---
(In reply to comment #34)
CP2k actually gives here an ICE with -O2 (PR 30147)
at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet
look at why the calculation results are wrong.
yes, I'm
--- Comment #28 from pault at gcc dot gnu dot org 2006-12-09 21:13 ---
Subject: Bug 29975
Author: pault
Date: Sat Dec 9 21:13:29 2006
New Revision: 119697
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119697
Log:
2006-12-09 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #27 from patchapp at dberlin dot org 2006-12-08 19:50 ---
Subject: Bug number PR29975
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-12/msg00560.html
--
--- Comment #26 from patchapp at dberlin dot org 2006-12-05 19:15 ---
Subject: Bug number PR29975
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-12/msg00336.html
--
--- Comment #24 from pault at gcc dot gnu dot org 2006-12-04 20:55 ---
OK, I'll put this in the pipeline for clean-up and submission.
Paul
However, one gets neither a warning nor an error for the following test case,
which can be found in the Fortran 2003 standard, Section C.11.2:
--- Comment #25 from burnus at gcc dot gnu dot org 2006-12-04 21:15 ---
OK, I'll put this in the pipeline for clean-up and submission.
Thanks. At least the generic interface patch should be completely ok; for the
other one, I'll try to dream up something which is not correctly covered
--- Comment #16 from pault at gcc dot gnu dot org 2006-12-03 13:38 ---
Created an attachment (id=12730)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12730action=view)
This fixes the INTERFACE part of the problem.
I have not regtested the full suite yet; just gfortran.dg/i*
The
--- Comment #17 from burnus at gcc dot gnu dot org 2006-12-03 14:44 ---
This fixes the INTERFACE part of the problem.
I have not regtested the full suite yet; just gfortran.dg/i*
I just regression tested it on x86_64-unknown-linux-gnu.
I also tried to compile all_cp2k_gfortran.f90 --
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-12-03 17:42 ---
Subject: Re: [meta-bugs] ICEs with CP2K
Tobias,
The patch looks good -- and the test cases as well.
Great!
Just for completeness, the relevant part of the standard is:
C1209 (R1206) A procedure-name shall
--- Comment #19 from paulthomas2 at wanadoo dot fr 2006-12-03 19:41 ---
Subject: Re: [meta-bugs] ICEs with CP2K
Tobias,
Note that this does not fix everything as gfortran rejects also
interface_y.f90
if I comment the call bl_copy(1.0, chr); if I understand the standard
correctly
--- Comment #20 from pault at gcc dot gnu dot org 2006-12-03 21:01 ---
Created an attachment (id=12733)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12733action=view)
A further development of the patch
This version now behaves in the same way as other compilers; the testcase
--- Comment #21 from burnus at gcc dot gnu dot org 2006-12-03 21:50 ---
Do you think that the error in gfortran.dg/interface_1.f90 is correct?
I have fix for the above that also stops the doubling of the error
message. However, it breaks interface_1.f90 because there is no
--- Comment #22 from burnus at gcc dot gnu dot org 2006-12-03 22:07 ---
And here is the relevant part of the standard Fortran 2003, Section 11.2.1
(USE) [cf. also F95, Sec 11.3.2]:
Two or more accessible entities, other than generic interfaces or defined
operators, may have the same
--- Comment #23 from burnus at gcc dot gnu dot org 2006-12-03 22:49 ---
(In reply to comment #20)
now gives a warning in interface_1.f90, rather than an error.
I think one can live with this - Lahey also gives only a warning. (ifort a
warning; Richard says it is invalid.)
However,
to CP2K, so FX statement might be wrt to
an older version of CP2K. I'm not sure that I can completely agree with FX,
I've never seen a gfortran compiled CP2K pass all our regtests without a
segfault. Of course, CP2K is fairly complex so there could be bugs, but it is
also quite wel tested.
--
http
--- Comment #13 from jv244 at cam dot ac dot uk 2006-12-02 13:55 ---
(In reply to comment #11)
Created an attachment (id=12724)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12724action=view) [edit]
test case for interface bl_copy
all_cp2k_gfortran.f90:418697.22:
USE
601 - 700 of 924 matches
Mail list logo
