--- Comment #2 from ramana at gcc dot gnu dot org 2009-08-24 08:44 ---
Using binutils trunk as well as r150986 I can't reproduce this with -O2 and
-march=armv7-a.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
gfortran now warns for trailing characters in format statements. However, it
does not properly work as the following test case (extracted from FLEUR,
www.flapw.de) shows:
7182 FORMAT (a3)
1
Warning: Extraneous characters in format at (1)
Due to committal:
URL: http://gcc.g
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-24 08:53 ---
Thanks for the fix, however, it causes some bogus diagnostic - see PR 41152
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-24 09:02 ---
Also the following fixed-format format looks OK to me:
WRITE (6,'(//'' icorr is not correctly transferred. icorr='',i5)
&') 42
END
But it produces:
WRITE (6,'(//'' icorr is not corr
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-24 09:08 ---
Please provide preprocessed source that can be used to reproduce the failure.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-24 09:21 ---
Seems like by design, see tree-pretty-print.c:print_call_name
Likely for printing prettier member function names. IMHO we should just
drop this function on the floor considering it prints t.w (...) for
struct
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-24 09:26 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-24 09:52 ---
Subject: Bug 41094
Author: rguenth
Date: Mon Aug 24 09:52:03 2009
New Revision: 151051
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151051
Log:
2009-08-24 Richard Guenther
PR middle-end/41094
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-24 09:56 ---
Subject: Bug 41094
Author: rguenth
Date: Mon Aug 24 09:56:30 2009
New Revision: 151052
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151052
Log:
2009-08-24 Richard Guenther
PR middle-end/41094
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-24 10:03 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-24 10:29 ---
Confirmed. Mine.
struct rgba8;
template class span_gouraud {
public:
struct coord_type { };
coord_type m_coord[3];
};
template class span_gouraud_rgba : public span_gouraud
{
typedef ColorT colo
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 11:19 ---
Another test case:
character(100), parameter :: subchapter='(79("-"),/,5("-")," ",A,/,79("-"),/)'
write(*,subchapter) 'test'
end
Here the error message is:
write(*,subchapter) 'test'
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-24 11:24 ---
(In reply to comment #0)
> Due to committal:
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151021
For me r151028 seems to work, but r151039 shows the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
tools/qdatetime.cpp: In member function 'QString
QDateTimeParser::sectionText(const QString&, int, int) const':
tools/qdatetime.cpp:4424: warning: case label value is less than minimum value
for type
tools/qdatetime.cpp:4425: warning: case label value is less than minimum value
for type
tools/qdate
--- Comment #6 from dominiq at lps dot ens dot fr 2009-08-24 11:48 ---
I just downloaded CPMD and built it under gfortran 4.4.1 and 4.5.0 (revision
151047) without trouble.
Could you post the output of "gfortran -v" and indicate your platform.
--
http://gcc.gnu.org/bugzilla/show_bug
With r151053 I get an error when I compile the following line:
2000 format (1X,1P,E14.6,3E12.4,0P)
1
Error: Comma required after P descriptor in format string at (1)
While I haven't checked in the standard if this is really valid, it was
swallowed by gfortran un
--- Comment #7 from ubizjak at gmail dot com 2009-08-24 12:40 ---
Probably duplicate of PR 40587.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-24 12:53 ---
We're layouting an array with incomplete element type and get into
if (!TYPE_SIZE (element))
/* We don't know the size of the underlying element type, so
our alignment calculations wil
--- Comment #8 from dominiq at lps dot ens dot fr 2009-08-24 13:03 ---
> Probably duplicate of PR 40587.
Could be, but the test in PR 40587 fails with 4.5 r147438:
pr40587.f90: In function 'test':
pr40587.f90:14: internal compiler error: in emit_swap_insn, at reg-stack.c:827
but not t
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-24 13:12
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-24 13:45 ---
> With r151053 I get an error when I compile the following line:
> 2000 format (1X,1P,E14.6,3E12.4,0P)
>1
> Error: Comma required after P descriptor in format string at (1)
That lo
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 13:55 ---
> However, I cannot reproduce the problem with a program consisting only of:
>
> 2000 format (1X,1P,E14.6,3E12.4,0P)
> end
Hm, funny. For me the error *does* appear already for this two-liner (at
r151053).
--
h
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-08-24 14:43 ---
Joseph - back in comment#2, you noted that the results of infinity and zero can
be ambiguous. I.e. Infinity in either part of a complex number (perhaps
infinity of either sign?) is sufficient, and a pair of zeros, exp
gcc -v says
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-inclu
--- Comment #1 from David dot Kosower at cea dot fr 2009-08-24 15:25
---
Created an attachment (id=18418)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18418&action=view)
File referred to in comment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41155
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-24 15:33 ---
Subject: Bug 41079
Author: rguenth
Date: Mon Aug 24 15:33:35 2009
New Revision: 151057
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151057
Log:
2009-08-24 Richard Guenther
PR lto/41079
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-24 15:34 ---
The bootstrap comparison issues have all been fixed. The lto sections
appearing in the final executables have been dealt with in upstream ld
following what gold does.
Thus, fixed.
--
rguenth at gcc dot gnu dot
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-24 15:40 ---
GCC 4.2.4 is no longer maintained, please update to at least GCC 4.3.4. I
suggest reporting this bug to ubuntu instead.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from hjl dot tools at gmail dot com 2009-08-24 15:48 ---
Fixed:
http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02467.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
+++ This bug was initially created as a clone of Bug #32893 +++
Gcc 4.4/4.5 can align stack properly. But it needs to assume 4 byte
incoming stack alignment instead of 16byte.
--
Summary: [4.4/4.5 Regression] zlib segfault in inflate_table()
compiled w/ -O -msse2
--- Comment #8 from ian at airs dot com 2009-08-24 16:00 ---
Over in http://gcc.gnu.org/ml/gcc/2009-06/msg00704.html you expressed the
opposite opinion, which is why I haven't taken any action.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
--- Comment #9 from mmitchel at gcc dot gnu dot org 2009-08-24 16:10
---
I think maybe it's time for me to get a brain transplant. I had totally
forgotten the previous conversation, and read through this entire issue
yesterday, and then spent some time thinking about the issue, and cle
The following code was compiled with
gfortran -g -o test_dtime test_dtime.f
The code is given by (very similar to that given in the info file for gfortran
program test_dtime
integer(8) :: i, j, k
real, dimension(2) :: tarray
real :: result
real :: accum
call d
--- Comment #8 from joseph at codesourcery dot com 2009-08-24 16:59 ---
Subject: Re: complex folding inexact
On Mon, 24 Aug 2009, ghazi at gcc dot gnu dot org wrote:
> This brings up the question that it's possible for GCC to produce a
> compile-time result (via MPC) that is different
--- Comment #4 from eric dot weddington at atmel dot com 2009-08-24 17:07
---
The cli() and sei() macros from avr-libc are volatile and generate inline
assembly, which the compiler knows nothing about. The compiler is not aware
that the load of the constant into a register can be done,
--- Comment #3 from eric dot weddington at atmel dot com 2009-08-24 17:18
---
Confirmed on 4.3.2.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2009-08-24 17:19 ---
(In reply to comment #0)
> The following code was compiled with
> gfortran -g -o test_dtime test_dtime.f
>
> The code is given by (very similar to that given in the info file for gfortran
>
> program test_dtim
--- Comment #2 from fkrogh#gcc at mathalacarte dot com 2009-08-24 17:34
---
I had thought that was the case as well. But when I started getting some
negative times by subtracting the previous value from the current one in the
first location of the array I looked at the info file and fo
--- Comment #3 from dominiq at lps dot ens dot fr 2009-08-24 17:45 ---
> dtime returns the time since the start of the process?
The manual says:
Subsequent invocations of DTIME return values accumulated since the previous
invocation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
Just trying PCH with a sample GTKmm application. The PCH is generated with
first g++ call but the compilers crashes at the second call.
Files and versions on the archive. Sorry to use achives.
How to reproduce:
§> tar -xjf gcc_segfault_case.tar.bz2
§> make
Well, i don't know how to post the fil
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-24 17:54
---
Please provide all the information outlined here:
http://gcc.gnu.org/bugs.html
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2009-08-24 18:16 ---
If I am not mistaken, the dtime behavior change between 4.2 and 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
--- Comment #10 from jv244 at cam dot ac dot uk 2009-08-24 19:05 ---
(In reply to comment #8)
>
> (Part of PR 40823 is probably a duplicate of this issue; there is another
> issue
> stated in that PR, which is not a regression (i.e. never worked correctly),
> but
> has probably a simil
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-24 19:06 ---
No obvious wrong line numbers in the '-fdump-tree-original-lineno' output for
the module:
s1 (integer(kind=4)[0:D.1561] * restrict a, integer(kind=4) & restrict n)
{
integer(kind=8) ubound.0;
integer(kind=8) ubound.
--- Comment #9 from aldyh at gcc dot gnu dot org 2009-08-24 18:34 ---
Fixed thusly
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01306.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2009-08-24 19:17 ---
but they do already appear in the bugs.f90.004t.gimple dump
[BTW, -lineno is so useful, it should be the default ;-)]
in the code that refers to
stride.2 = NON_LVALUE_EXPR ;
stride.2 = MAX_EXPR ;
(consistent with ju
4.5.0 20090824 (experimental) [lto revision 151057] (lto merged
with rev 150842)
$ ./xgcc -B. -c -O -fpic ~/ice.i -flto
$ ./xgcc -B. -flto ice.o -shared
In file included from :0:0:
/home/ryan/ice.i: In function 'acos':
/home/ryan/ice.i:660:9: internal compiler error: in insert_value_copy_o
--- Comment #1 from tkoenig at gcc dot gnu dot org 2009-08-24 19:33 ---
It would also be useful when assigning arrays with a single value:
subroutine foo(a)
integer, a(:,:) :: a
a = 0 ! See PR 41137, we could use memset
or
subroutine foo(a)
integer, a(:,:) :: a
A = 42
--
--- Comment #1 from rmansfield at qnx dot com 2009-08-24 19:34 ---
Created an attachment (id=18419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18419&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
--- Comment #5 from kargl at gcc dot gnu dot org 2009-08-24 19:40 ---
Confirmed.
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org
|dot org
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 19:44 ---
(In reply to comment #1)
> Seems like by design, see tree-pretty-print.c:print_call_name
Thanks for pointing me at the right place.
> Likely for printing prettier member function names. IMHO we should just
> drop t
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-24 20:06 ---
I don't think this PR depends on PR40632, which just provides a F2008 mechanism
to signal an assumed shape array to be contiguous (certainly a useful feature
in its own respect). The cases discussed here are rather assum
--- Comment #6 from kargl at gcc dot gnu dot org 2009-08-24 20:53 ---
Patch is here:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01311.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
--- Comment #3 from raj dot khem at gmail dot com 2009-08-24 21:17 ---
(In reply to comment #2)
> Using binutils trunk as well as r150986 I can't reproduce this with -O2 and
> -march=armv7-a.
>
I was using 2.18. I haven't tried 2.19 but it works ok with binutils from
cvs(updated from
--- Comment #3 from jason at gcc dot gnu dot org 2009-08-24 21:32 ---
Subject: Bug 41110
Author: jason
Date: Mon Aug 24 21:31:54 2009
New Revision: 151061
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151061
Log:
PR c++/41109
PR c++/41110
PR c++/41134
--- Comment #8 from jason at gcc dot gnu dot org 2009-08-24 21:32 ---
Subject: Bug 41134
Author: jason
Date: Mon Aug 24 21:31:54 2009
New Revision: 151061
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151061
Log:
PR c++/41109
PR c++/41110
PR c++/41134
--- Comment #4 from jason at gcc dot gnu dot org 2009-08-24 21:32 ---
Subject: Bug 41109
Author: jason
Date: Mon Aug 24 21:31:54 2009
New Revision: 151061
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151061
Log:
PR c++/41109
PR c++/41110
PR c++/41134
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-24 21:40 ---
Created an attachment (id=18420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18420&action=view)
WIP with test
This version fixes a bug in gcc that was preventing it to emit DWARFs for a
typedefs enclosed in a
--- Comment #3 from dodji at gcc dot gnu dot org 2009-08-24 21:42 ---
Created an attachment (id=18421)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18421&action=view)
Generated assembly for previous test
Assembly generated for the test in attachment #18420
--
http://gcc.gnu.
--- Comment #5 from steven at gcc dot gnu dot org 2009-08-24 22:35 ---
IMHO we should just not put a locus on the generated code to zero out the
variable at the start of the (sub-)program.
--
steven at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #6 from sandra at codesourcery dot com 2009-08-24 22:36 ---
This bug appears to be fixed in mainline HEAD now. Here's an excerpt showing
the generated code for the inner loop in the example program now:
addiu $21,$28,%gp_rel(AA)
addiu $10,$28,%gp_rel(A)
--- Comment #5 from bangerth at gmail dot com 2009-08-24 22:37 ---
Thanks a lot for the quick turnaround, Jason!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41109
On 08/24/2009 05:26 AM, janus at gcc dot gnu dot org wrote:
With r151053 I get an error when I compile the following line:
2000 format (1X,1P,E14.6,3E12.4,0P)
1
Error: Comma required after P descriptor in format string at (1)
While I haven't checked in the st
--- Comment #3 from jvdelisle at verizon dot net 2009-08-24 23:45 ---
Subject: Re: New: [4.5 Regression] Comma required after P
descriptor
On 08/24/2009 05:26 AM, janus at gcc dot gnu dot org wrote:
> With r151053 I get an error when I compile the following line:
>
> 2000 format (1X,
gfortran gives an error, g77 accepts it without a problem
[bda...@localhost ~/tmp]$ cat a.f
COMPLEX FUNCTION F0_HDEC*16(M1,M2,QSQ)
RETURN
END
COMPLEX FUNCTION F1_HDEC*16(M1,M2,QSQ)
RETURN
END
[bda...@localhost ~/tmp]$ /home/bdavis/g77/run/bin/g77 -c a.f
[bda.
--- Comment #11 from aldyh at gcc dot gnu dot org 2009-08-25 00:28 ---
Subject: Bug 40660
Author: aldyh
Date: Tue Aug 25 00:27:52 2009
New Revision: 151069
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151069
Log:
fortran/
PR fortran/40660
* trans-io.c (build_dt
--- Comment #1 from kargl at gcc dot gnu dot org 2009-08-25 00:36 ---
There isn't a problem with having more than 2 complex function
in a file. The problem is that your complex functions are
using a nonstandard extension.
REMOVE:kargl[242] cat > k.f90
COMPLEX FUNCTION F0_HDEC*16(
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-08-25 00:37
---
I tweaked IVOPTS a few months ago to help in similar cases on PowerPC:
2009-05-29 Eric Botcazou
* tree-ssa-loop-ivopts.c (strip_offset_1) : New case.
(force_expr_to_var_cost) : Likewise.
--- Comment #2 from kargl at gcc dot gnu dot org 2009-08-25 00:40 ---
OK. I found it. This is probably a duplicate of
PR 36234
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41160
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:03
---
Patch is simple and obvious. I will commit shortly.
Index: io.c
===
--- io.c(revision 151045)
+++ io.c(working copy)
@@ -694,7 +694
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:05
---
Subject: Bug 41154
Author: jvdelisle
Date: Tue Aug 25 01:05:11 2009
New Revision: 151070
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151070
Log:
2009-08-24 Jerry DeLisle
PR fortran/41154
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:14
---
Subject: Bug 41154
Author: jvdelisle
Date: Tue Aug 25 01:14:13 2009
New Revision: 151071
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151071
Log:
2009-08-24 Jerry DeLisle
PR fortran/41154
The following program which conforms to C++ ISO does NOT compile with G++
but compiles with no errors using Borland C++ 5.52 command line compiler.
#include
int main()
{
std::cout << "Hello World!" << std::endl;
}
The following errors are produced:
ju...@linux-wp1w:~> g++ hello_iso.cpp
h
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:21
---
Closing. By all means let me know if anything else crops up. Thanks for
catching this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:22
---
Closing, fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:24
---
Closing, fixed on trunk. Note to self. Have some locus clean-ups to do
relative to 38439. Will pick those off next.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from kargl at gcc dot gnu dot org 2009-08-25 01:47 ---
Subject: Bug 41157
Author: kargl
Date: Tue Aug 25 01:47:23 2009
New Revision: 151072
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151072
Log:
2009-08-24 Steven G. Kargl
PR fortran/41157
* dtime.c
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-08-25 02:03 ---
lets close with no action taken.
*** This bug has been marked as a duplicate of 36234 ***
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-08-25 02:03 ---
*** Bug 41160 has been marked as a duplicate of this bug. ***
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
-
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot
|dot org
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-25 02:10
---
This turns out to be the exact bug that Diego reported in his recent email. He
sent me the code off list. g77 compiles it fine. gfortran does this:
Obviously legacy code issue. I wonder how many other cases we
--- Comment #5 from kargl at gcc dot gnu dot org 2009-08-25 02:28 ---
(In reply to comment #4)
> This turns out to be the exact bug that Diego reported in his recent email. He
> sent me the code off list. g77 compiles it fine. gfortran does this:
>
> Obviously legacy code issue. I wo
--- Comment #8 from kargl at gcc dot gnu dot org 2009-08-25 03:30 ---
Subject: Bug 41157
Author: kargl
Date: Tue Aug 25 03:30:25 2009
New Revision: 151073
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151073
Log:
2009-08-24 Steven G. Kargl
PR fortran/41157
* dtime.c
--- Comment #9 from kargl at gcc dot gnu dot org 2009-08-25 03:33 ---
Fixed on trunk and 4.4.
Thanks for the bug report.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:12 ---
It looks like your terminating double quote is not the same as the
opening one. How are they encoded on your system?
--
bangerth at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:21 ---
This is the way C++ works. The copy constructor must be available.
(The compiler doesn't have to actually call it, but it must be
available.)
--
bangerth at gmail dot com changed:
What|Removed
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:23 ---
Yes.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
Status|UNCONFIRMED |
Revision 151049 gave:
gfortran -c -o chgpen.fppized.o-O2 -ffast-math -DSPEC_CPU_LP64
-ffixed-form chgpen.fppized.f
WRITE(IW,410) NV,NVA,NFLAT,ALPHA,BETA,GAMMA,CHISQ,
1
Error: FORMAT label 410 at (1) not defined
chgpen.fppized.f:2075.22:
WRITE(
--- Comment #1 from hjl dot tools at gmail dot com 2009-08-25 04:40 ---
The complete error is
chgpen.fppized.f:2107.56:
* 1X,'INITIAL VALUE OF CHISQ =',1P,E17.10,0P/
1
Error: Comma required after P descriptor in format
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-08-25 04:45 ---
This is most likely a dup of bug 41154.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41162
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-08-25 04:57
---
Its a DUP, but a different case I also did not think of. The P descriptor
requires special casing and that is what is getting us here.
I will commit a fix shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-25 05:22
---
Subject: Bug 41162
Author: jvdelisle
Date: Tue Aug 25 05:22:14 2009
New Revision: 151074
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151074
Log:
2009-08-24 Jerry DeLisle
PR fortran/41162
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-08-25 05:24
---
Fixed. I will leave this open for a bit. At the rate I am going I will break
everything by midnight. (zzz)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from reuter at physik dot uni-freiburg dot de 2009-08-25
06:56 ---
The problem arose due to a confusion about different installed versions
of the library libiconv. After disentangling those, compilation works again.
--
reuter at physik dot uni-freiburg dot de changed:
96 matches
Mail list logo
