--- Comment #3 from anlauf at gmx dot de 2007-03-06 08:20 ---
(In reply to comment #2)
The value 5008 is listed in libgfortran.h as ERROR_ENDFILE. The
-1 corresponds to ERROR_END. So, the return value of 5008 is
telling you that you are trying to (initiate a?) read beyond
the end
--- Comment #4 from anlauf at gmx dot de 2007-03-06 08:42 ---
(In reply to comment #3)
All other compilers I have checked (xlf, ifort 7.x-9.x, g95)
stay at the end of file.
I stand corrected with regard to xlf. It returns a
documented recoverable error condition.
I have to find
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-03-06 08:54
---
Subject: Bug 17114
Author: rsandifo
Date: Tue Mar 6 08:54:31 2007
New Revision: 122604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122604
Log:
gcc/
PR target/23482
PR target/17114
--- Comment #7 from rsandifo at gcc dot gnu dot org 2007-03-06 08:54
---
Subject: Bug 23482
Author: rsandifo
Date: Tue Mar 6 08:54:31 2007
New Revision: 122604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122604
Log:
gcc/
PR target/23482
PR target/17114
--- Comment #8 from rsandifo at gcc dot gnu dot org 2007-03-06 08:57
---
Fixed in trunk. This particular form of the patch is too
invasive for 4.1 and 4.2.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-03-06 09:01
---
Subject: Bug 28181
Author: rsandifo
Date: Tue Mar 6 09:01:07 2007
New Revision: 122609
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122609
Log:
gcc/
PR target/28181
*
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-03-06 09:02
---
Now fixed in trunk. The patch may be too invasive to backport;
I'm not sure.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from vladimir dot sysoev at gmail dot com 2007-03-06 09:17
---
This issue causes cpu2006/447.dealII ICE too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
--- Comment #5 from anlauf at gmx dot de 2007-03-06 10:22 ---
(In reply to comment #4)
I have to find out why the code in question that lead to
the problem report does not properly recover with gfortran.
It might be an interference with BACKSPACE, as the
full code that lead me to the
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-06 10:31 ---
Fixed in 4.0.4/4.1.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-06 10:31 ---
Err, FIXED!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-06 10:42 ---
No, this is a bug, 2nd stage name-lookup should find foo(const int) as var is
dependent on the template parameter T (14.6/8, /9).
But I bet we have a dup for this.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-06 10:50 ---
Stock 4.1.1 ICEs for me on the testcase, but 4.1.2 looks fine - can you provide
the wrong assembly you are seeing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
--- Comment #2 from zuxy dot meng at gmail dot com 2007-03-06 11:26 ---
Created an attachment (id=13151)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151action=view)
Proposed patch against 4.1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29498
--- Comment #13 from manu at gcc dot gnu dot org 2007-03-06 11:41 ---
(In reply to comment #4)
This is not really fixable.
Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html
I am really ignorant on this CCP optimisaton but I am willing to learn. I guess
that we merge
--- Comment #42 from michael dot klein at fazi dot de 2007-03-06 12:07
---
Created an attachment (id=13152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13152action=view)
Testcase (generated assembly files from gcc 4.1.1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
On powerpc, current auto-vectorizer does not vectorize loops that have
conversion from float to int statement in it.
For example, in case we have the following program:
#include stdarg.h
#define N 32
int main1 ()
{
int i;
int ib[N];
float fa[N] =
--- Comment #7 from dnovillo at gcc dot gnu dot org 2007-03-06 12:55
---
Might as well take this one too.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
preprocessed source at:
http://www.cg.tuwien.ac.at/~icicle/gcc/ActionsForPolarisationImages.mi
complete output:
.m.o: ActionsForPolarisationImages
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.2/configure --enable-languages=c,objc
--- Comment #10 from JBoncek at Hunter dot Com 2007-03-06 14:44 ---
This is just a nuisance at the end of a .c or .cpp file. It is, however, a
serious error that should always be notified at the end of an included (header)
file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
--- Comment #9 from amacleod at redhat dot com 2007-03-06 15:01 ---
actually, mainline isn't working either. A closer examination shows the code
generated has an extra offset of -4 in the compare that shouldn't be there.
This patch triggers a bug in rtl's fwprop pass.
--
--- Comment #5 from manu at gcc dot gnu dot org 2007-03-06 15:09 ---
Another one.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-06 15:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
building this testcase with -O2 -march=athlon -Wall -fprefetch-loop-arrays
gives:
warning: array subscript is above array bounds
[...]
which, according to VRP, seems to be valid.
testcase is:
=== Cut ===
struct real_value
{
unsigned int cl:2;
unsigned int decimal:1;
unsigned long
--- Comment #1 from mueller at gcc dot gnu dot org 2007-03-06 15:22 ---
after prefetch-loop-arrays run, vrp2 looks like this:
L81:;
D.1885_87 = r_4(D)-sig[i_13];
D.1886_88 = D.1885_87 + 160B;
__builtin_prefetch (D.1886_88, 1);
r_4(D)-sig[i_13] = 0;
i_8 = i_13 + 1;
i_26 =
--- Comment #43 from hjl at lucon dot org 2007-03-06 15:27 ---
(In reply to comment #42)
Created an attachment (id=13152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13152action=view) [edit]
Testcase (generated assembly files from gcc 4.1.1)
I got
bash-3.1$ readelf -S -N
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-03-06 15:31 ---
(In reply to comment #1)
and so on. since it definitely writes more than 5 ints, I don't see how it
should *not* overflow the array.
since the body of the loop is never entered.
--
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-03-06 15:50 ---
Subject: Bug 31020
Author: jsm28
Date: Tue Mar 6 15:50:28 2007
New Revision: 122620
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122620
Log:
fixincludes:
* mkheaders.in: Fix headers for each multilib
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2007-03-06 15:53 ---
Subject: Re: Bad IOSTAT values when readings NAMELISTs past EOF
On Tue, Mar 06, 2007 at 08:20:23AM -, anlauf at gmx dot de wrote:
--- Comment #3 from anlauf at gmx dot de 2007-03-06
--- Comment #3 from sayle at gcc dot gnu dot org 2007-03-06 16:30 ---
Subject: Bug 30744
Author: sayle
Date: Tue Mar 6 16:30:12 2007
New Revision: 122622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122622
Log:
PR middle-end/30744
* fold-const.c (fold_binary)
--- Comment #4 from roger at eyesopen dot com 2007-03-06 16:32 ---
This should now be fixed on both mainline and the 4.2 release branch.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #44 from michael dot klein at fazi dot de 2007-03-06 16:33
---
(In reply to comment #43)
It means your gcc 4.1.1 was built with a very old binutils and it doesn't
support COMDAT group
Yes, this gcc was build with binutils 2.15 from Debian Sarge.
Thanks
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-06 17:10 ---
(In reply to comment #3)
No, this is a bug, 2nd stage name-lookup should find foo(const int) as var is
dependent on the template parameter T (14.6/8, /9).
But I bet we have a dup for this.
14.6.4.2/1 says this
Gfortran does not report an error if an allocatable array is set to an array of
larger size, for example in the code below.
program xalloc_words
! shows error with nonconformant assignment of an allocatable array
! not caught by most compilers
character (len=1), allocatable :: w(:)
integer,
-- file: error_compiling_unary_minus.adb
procedure Error_Compiling_Unary_Minus (X : Float) is
No_Problem : Float := -1.0 * X;
ERROR : Float := X * -1.0; -- this is line 3
begin
null;
end Error_Compiling_Unary_Minus;
-- end of file
$ gcc -v -c error_compiling_unary_minus.adb
Using
--- Comment #22 from paolo at gcc dot gnu dot org 2007-03-06 17:43 ---
Subject: Bug 28080
Author: paolo
Date: Tue Mar 6 17:43:27 2007
New Revision: 122628
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122628
Log:
2007-03-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-06 17:52 ---
And this is actually invalid Ada, see PR 19539.
*** This bug has been marked as a duplicate of 19539 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-06 17:52 ---
*** Bug 31060 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
Compiled this program:
http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html
without -D_GLIBCXX_DEBUG the program works ok, but with -D_GLIBCXX_DEBUG I get
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/vector:199:
error: attempt to subscript container
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-06 18:14 ---
I actually think this is a bug in the user code. the error message is correct
in that the code is acessing one past the end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31061
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-06 19:32 ---
Yes, this would be useful.
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|cannot write in |[4.3 Regression] cannot
--- Comment #2 from pcarlini at suse dot de 2007-03-06 20:17 ---
Yes, there isn't much to add, the whole point of debug-mode is catching this
kind of bug: in is_strike the vector rolls is subscripted at index 20.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #3 from pcarlini at suse dot de 2007-03-06 20:37 ---
Sorry, I misread the backtrace: the problem happens in accumulate, called by
frame_score(), called by score().
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31061
--- Comment #7 from anlauf at gmx dot de 2007-03-06 21:51 ---
Created an attachment (id=13153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13153action=view)
Revised demo
Revised demo. New namelist for this demo follows.
At some place, the input read gets garbled with gfortran,
--- Comment #8 from anlauf at gmx dot de 2007-03-06 21:52 ---
Created an attachment (id=13154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13154action=view)
Namelist
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-03-06 21:57 ---
Subject: Bug 30950
Author: dfranke
Date: Tue Mar 6 21:57:02 2007
New Revision: 122640
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122640
Log:
2007-03-06 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-03-06 21:57 ---
Subject: Bug 30950
Author: dfranke
Date: Tue Mar 6 21:57:09 2007
New Revision: 122641
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122641
Log:
2007-03-06 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-03-06 21:58 ---
Fixed in 4.2 and trunk.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from anlauf at gmx dot de 2007-03-06 22:00 ---
(In reply to comment #8)
In the new example, when I comment out the BACKSPACE
in position_nml for ios0 (EOF condition), the garbled
output goes away. But in the large program (where this
was extracted) this does not help;
// Illustrates some bugs related to __attribute__((warn_unused_result)).
struct Vector {
float x, y, z;
inline Vector() {}
inline Vector(float _x,float _y,float _z) : x(_x), y(_y), z(_z) {}
// BUG: Toggling the presence of a copy constructor (doesn't matter
which
--- Comment #1 from fletcherdunn at yahoo dot com 2007-03-06 22:26 ---
Created an attachment (id=13155)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13155action=view)
Repro code with the proper line breaks
Line breaks got messed up when pasting into bug description.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-06 22:40 ---
// If you comment out the copy constructor, the warnings do not appear.
// Note that I produced this with the Playstation (CELL) version of GCC under
// MinGW/MSys, but I don't think this is a platform specific
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 00:05 ---
Closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-03-07 00:16 ---
The change to gccspec.c was made by Franz Sirl on 2001-06-16, revision 43421.
The mail on gcc-patches is at
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01394.html. There's further
discussion at
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 00:26 ---
I should mention that with the GNU runtime, we want the shared libgcc for
exceptions so any patch that breaks the GNU runtime linking with the shared
libgcc should be rejected.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|50% slow down due to mem-ssa|[4.3 Regression] 50% slow
|merge
--- Comment #7 from ahs3 at fc dot hp dot com 2007-03-07 00:49 ---
Is this code snippet related to this bug, or a new one entirely?
#define LABEL(a, b) a##b##:
int main () {
LABEL(all,done)
return 0;
}
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-07 00:58 ---
(In reply to comment #7)
Is this code snippet related to this bug, or a new one entirely?
Actually the error message is fully correct in that case.
$ gcc -o foo.o foo.c
foo.c:4:1: error: pasting alldone and :
--- Comment #9 from geoffk at gcc dot gnu dot org 2007-03-07 01:38 ---
Confirmed.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from geoffk at gcc dot gnu dot org 2007-03-07 01:52 ---
c_types_compatible_p says the two types are compatible, but it never gets
called. I don't think the back-end is involved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
--- Comment #11 from geoffk at gcc dot gnu dot org 2007-03-07 02:01 ---
No, I take it back, the back-end is involved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
--- Output from g++ -v -save-temps ice.cc-:
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
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-03-07 03:37
---
Replying to comment #6. I am forming an opinion. Section 9.7 of the F2003
standard states:
Backspacing over records written using list-directed or namelist formatting
is prohibited.
This implies to me that
--- Comment #2 from b33fc0d3 at gmail dot com 2007-03-07 03:37 ---
I am having the exact same problem.
I've tried a few things, tried building in a stable chroot with glibc-2.4
(since my box is mainly unstable with glibc-2.5 and hashstyle) but got the
exact same error. gcc-4.2
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-03-07 03:38
---
I will take this one, but I am not confirming its a bug yet.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-03-07 04:45
---
The garbled text is because gfortran does not default initialize variable as
some compilers do. The 'line' variable is not getting read because gfortran is
getting an error on the read, so the it is not set to
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-03-07 06:40
---
AFAICT A backspace is not allowed for namelist files according to 9.7.1
I interpret this to mean this is invalid code.
Further, Note 9.54 states that if the preceding record read is the EOF record,
the
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-07 07:17 ---
gcc version 4.3.0 20061021 (experimental)
I believe this has been fixed already by PR30005 since December 5.
At least my gfortran prints:
At line 6 of file foo.f90
Fortran runtime error: Permission denied trying
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 07:23 ---
*** Bug 31059 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 07:23 ---
Confirmed, gfortran should print something like:
Rank 1 of array operand has extent 2 instead of 3
*** This bug has been marked as a duplicate of 30802 ***
--
burnus at gcc dot gnu dot org changed:
72 matches
Mail list logo
