--- 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:
--- 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 #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 #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 #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 #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
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(
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
Status|UNCONFIRMED |
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:23 ---
Yes.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- 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: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 #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 #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 #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 #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
--
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 #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
-
--- 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 #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 #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 #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 #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
---
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 #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
--- 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 #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 #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 #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 #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 #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
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 #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,
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 #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
--- 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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
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 #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
--- 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 #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
--
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 #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
--- 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 #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 #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 #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 #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
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 #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=
--- 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 #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 #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 #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 #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
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 #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
--- 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
+++ 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 #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
-
--- 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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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
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 #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
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 #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
--- 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 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 #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 #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 #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 #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 #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 #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 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 #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
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 #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
--
96 matches
Mail list logo
