l.
==5331== For more details, rerun with: -v
==5331==
GNU F95 (GCC) version 4.3.0 20070902 (experimental) [trunk revision 128023]
(i386-pc-linux-gnu)
compiled by GNU C version 4.3.0 20070902 (experimental) [trunk revision
128023], GMP version 4.2.1, MPFR version 2.2.1.
GGC heuristics:
--- Comment #6 from kargl at gcc dot gnu dot org 2007-09-03 03:58 ---
(In reply to comment #3)
> (In reply to comment #1)
>> This is assuming that an asymmetric range is permitted in Fortran which
>> I think
>> it is not. You can use -fno-range-check to disable this check.
>>
>
> In t
--- Comment #5 from kargl at gcc dot gnu dot org 2007-09-03 03:43 ---
(In reply to comment #4)
> (In reply to comment #2)
> > The number 2147483648 is too big. The minus sign is a unary operator.
> > Either use the compiler option that Jerry mentioned or use 'k = - huge(k) -
> > 1'
> >
--- Comment #4 from jlaw at uoguelph dot ca 2007-09-03 02:32 ---
(In reply to comment #2)
> The number 2147483648 is too big. The minus sign is a unary operator.
> Either use the compiler option that Jerry mentioned or use 'k = - huge(k) - 1'
>
option: -fno-range-check is supposed to b
--- Comment #3 from jlaw at uoguelph dot ca 2007-09-03 01:50 ---
(In reply to comment #1)
> This is assuming that an asymmetric range is permitted in Fortran which I
> think
> it is not. You can use -fno-range-check to disable this check.
>
In the IBM XL Fortran 90 manual:
pg 19
I qu
--- Comment #5 from pcarlini at suse dot de 2007-09-02 23:29 ---
Humm, too tricky.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #4 from pcarlini at suse dot de 2007-09-02 23:00 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot g
class C1
{
public:
C1();
static int x;
};
#if 1
namespace C1
{
int x;
};
#else
int C1::x;
#endif
class C2
{
public:
C2();
C1 c; // ! error here
};
when the static field is defined inside the namespace block, the definition of
the C1 class is no longer
--- Comment #2 from kargl at gcc dot gnu dot org 2007-09-02 21:04 ---
The number 2147483648 is too big. The minus sign is a unary operator.
Either use the compiler option that Jerry mentioned or use 'k = - huge(k) - 1'
--
kargl at gcc dot gnu dot org changed:
What|Re
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-09-02 20:57
---
This is assuming that an asymmetric range is permitted in Fortran which I think
it is not. You can use -fno-range-check to disable this check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
All exception related tests fail on this target. For example,
Executing on host: /home/gnu/gcc/objdir/gcc/xgcc -B/home/gnu/gcc/objdir/gcc/
/xx
x/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-5.c -fexceptions -fno-show-column
-lm -o ./cleanup-5.exe(timeout = 300)
PASS: gcc.dg/cleanup-5.c (test
--- Comment #3 from michelin60 at gmail dot com 2007-09-02 18:57 ---
Well here it is for interfering with Mr Guenther doing the reasonable thing.
This arbitrariness and unwarranted interference led me to do this.
It is also interesting to look a the GCC.mailing.list for June and July t
--- Comment #6 from tobi at gcc dot gnu dot org 2007-09-02 18:48 ---
(In reply to comment #5)
> (In reply to comment #4)
> > > if the first item after the "(" is a default-char-expression
> > > (constant or not) and there is no "...=" (e.g. "fmt=") in there, then it
> > > is
> > > also
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-02 18:42 ---
(In reply to comment #4)
> > if the first item after the "(" is a default-char-expression
> > (constant or not) and there is no "...=" (e.g. "fmt=") in there, then it is
> > also a "READ format" statement.
>
> This i
--- Comment #2 from rainy6144 at gmail dot com 2007-09-02 18:38 ---
Thank you. The bug appears to have been fixed in the latest 4.3.0 snapshot
(r128023).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
--- Comment #26 from marcus at jet dot franken dot de 2007-09-02 18:35
---
btw, this went latent again with commit r127834:
+2007-08-27 Daniel Berlin <[EMAIL PROTECTED]>
+
+ Fix PR tree-optimization/33173
+ * tree-ssa-alias.c (find_used_portions): Fix reversed test
--- Comment #4 from tobi at gcc dot gnu dot org 2007-09-02 18:27 ---
(In reply to comment #3)
> No, the syntax is:
> READ format[, io-list]
> and ('f.3.3') as a constant-string expression for the format; this is similar
> to "PRINT ('f3.3'), a".
> This should be distinguished from:
>
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-02 18:12 ---
Could you try with GCC gfortran 4.3.0? I can reproduce the problem with
gfortran 4.2.x but not with gfortran 4.3.0 which indicates that this has been
fixed meanwhile.
If you don't want to build GCC yourself (as you s
On Mandriva 2008 beta 2
[EMAIL PROTECTED] Ftest]$ gcc -v
Using built-in specs.
Target: x86_64-mandriva-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release
--enable-languages=c,
I think the following is invalid, but not rejected:
SUBROUTINE a
intrinsic cos
entry cos(x)
real x
x = 0
end subroutine
end
NAG f95 shows:
Error: a.f90, line 5: Multiply defined symbol COS
Ifort shows:
fortcom: Error: a.f90, line 2: Conflicting attributes or multiple declaration
of name. [C
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 ---
*** Bug 33277 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 ---
I just filed a new bug without any of the extra crap: PR 33283.
*** This bug has been marked as a duplicate of 33283 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 ---
This shows up on both powerpc-linux-gnu and powerpc-darwin. Confirmed because
it shows up in many different testresults.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
[18:22] < apinski>
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5:
error: could not split insn^M
[18:22] < apinski> new failure
[18:23] < apinski> on ppc-linux-gnu
[18:23] < apinski> between 127935 and 128000
[18:32] < Rhyolite> I guess it could be due to my predicat
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-09-02 17:49 ---
Lets see, IBMers working on GCC: more than 11.
Intel folks working on GCC: ~3 or so.
AMDers working on GCC: at least 4 but growing (includes Michael Meissner).
Googlers: who knows any more :) (but at least 10).
Redha
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-09-02 17:19
---
As mentioned by Richard and I, this bug is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pcarlini at suse dot de 2007-09-02 17:12 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot g
The following Fortran 90 program crashes gfortran-4.2.1:
program test
real(kind=8),parameter :: beta0(3) = (/ 1.0, 1.0, 1.0 /)
integer :: i(3)
real(kind=8) :: beta(3), beta_coef
i = (/ 1, 2, 3 /)
beta_coef = 1.0
beta = beta0(i) * beta_coef
end program test
(Workarou
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-02 16:38 ---
See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/11acfc0d9e65566e/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-09-02 16:08
---
Well, it has not been on my top burner. Looking at -fdump-tree-original the
problem can be seen easily. Fixing is not so straight forward. This will
probably not happen until 4.4.
--
http://gcc.gnu.org/bug
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyw
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-02 15:55 ---
I see this as well from time to time. SLES10-SP1 x86_64.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from yakov at emc dot com 2007-09-02 15:44 ---
Subject: Re: impossible constraint in asm
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-01 19:51
> ---
> -msoft-float disables the floating register stack so thi
--- Comment #2 from pcarlini at suse dot de 2007-09-02 15:23 ---
Currently 4_2-branch and 4_1-branch also give the same.
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #5 from michelin60 at gmail dot com 2007-09-02 15:23 ---
I am beginning to enjoy this:
There are about 34 hours between the first indication of failure on regress an
my report. There are about 8 hours between my report and the first
acknowledgment by GCC. This came by maste
I'm trying to run gfortran under Windows Vista. I ran into "ld: crt2.o: No such
file". I've found several reports on this, but no solution... Is there a
solution available already?
--
Summary: gfortran crt2.o not found under Vista
Product: gcc
Version: 4.2.2
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gcc-4.3/objdi
r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/990404-1.c
-w
-O3 -fomit-frame-pointer -fno-show-column -lm -o
/home/dave/gcc-4.3/objdir
/gcc/testsuite/gcc/990404-1.x3(timeout = 300)
PASS:
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-02 14:03 ---
"What does bar get back to? Are you saying if a pointer is passed to bar,
it can get back to any original struct where the pointer is a field?"
No, but if you pass a pointer to a field of a struct the callee may der
--- Comment #8 from pinskia at gmail dot com 2007-09-02 14:02 ---
Subject: Re: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:58:23 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
>
> If you can write such a function, I can pass you a pointer and your function
> wi
On 2 Sep 2007 13:58:23 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
>
> If you can write such a function, I can pass you a pointer and your function
> will be wrong.
yes so but that call would be undefined, not the one we are talking
about currently.
--Pinski
--- Comment #7 from pinskia at gmail dot com 2007-09-02 14:01 ---
Subject: Re: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:56:13 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
> What does bar get back to? Are you saying if a pointer is passed to bar,
> it can g
On 2 Sep 2007 13:56:13 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
> What does bar get back to? Are you saying if a pointer is passed to bar,
> it can get back to any original struct where the pointer is a field?
It only matters at the context at the point bar is called with the
struct
--- Comment #6 from hjl at lucon dot org 2007-09-02 13:58 ---
(In reply to comment #5)
>
> What does bar get back to? Are you saying if a pointer is passed to bar,
> it can get back to any original struct where the pointer is a field?
>
If you can write such a function, I can pass yo
--- Comment #5 from hjl at lucon dot org 2007-09-02 13:56 ---
(In reply to comment #4)
> bar (frame.value);
> That call to bar causes the whole frame struct escapes here, not just the
> array
> element.
>
> void bar (mpz_t);
> is really:
> void bar(int*);
>
> because of array deca
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-02 13:50 ---
Subject: Re: [4.3 Regression] Bootstrap check failures ICE's
On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #3 from dominiq at lps dot ens dot fr 2007-
On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42
> ---
> > [18:23] < apinski> between 127935 and 128000
>
> Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results f
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-02 13:43 ---
bar (frame.value);
That call to bar causes the whole frame struct escapes here, not just the array
element.
void bar (mpz_t);
is really:
void bar(int*);
because of array decaying in parameters.
Again with poin
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42 ---
> [18:23] < apinski> between 127935 and 128000
Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from
"regress", it can be narrowed between 127961 (working) and 127997 (non
working). Note that the
--- Comment #3 from hjl at lucon dot org 2007-09-02 13:37 ---
> Subject: Re: New: Failed to warn uninitialized stack variable
>
>
> Not really because this is the same as
> bar (&frame.value[0]);
>
> Where bar can do pointer tricks to get back to original struct and
> then change prev
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 13:32 ---
As mentioned by me in comment #1, we cannot warn about this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gmail dot com 2007-09-02 13:26 ---
Subject: Re: New: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:19:45 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] uninit-2]$ cat x.c
> typedef int mpz_t[1];
> typedef struct
On 2 Sep 2007 13:19:45 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] uninit-2]$ cat x.c
> typedef int mpz_t[1];
> typedef struct iterator_stack
> {
> struct iterator_stack *prev;
> mpz_t value;
> } iterator_stack;
> iterator_stack *x;
> void bar (mpz_t);
> void
> fo
[EMAIL PROTECTED] uninit-2]$ cat x.c
typedef int mpz_t[1];
typedef struct iterator_stack
{
struct iterator_stack *prev;
mpz_t value;
} iterator_stack;
iterator_stack *x;
void bar (mpz_t);
void
foo ()
{
iterator_stack frame;
bar (frame.value);
x = frame.prev;
}
[EMAIL PROTECTED] uninit-2]$
--- Comment #11 from pcarlini at suse dot de 2007-09-02 13:03 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from paolo at gcc dot gnu dot org 2007-09-02 13:02 ---
Subject: Bug 33208
Author: paolo
Date: Sun Sep 2 13:02:31 2007
New Revision: 128025
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128025
Log:
/cp
2007-09-02 Paolo Carlini <[EMAIL PROTECTED]>
PR c
--- Comment #4 from hjl at lucon dot org 2007-09-02 12:36 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED |
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2007-09-02
12:28 ---
(In reply to comment #1)
>> doesn't look robust either; what about
>
> gcjversion=`cat $srcdir/../gcc/BASE-VER`
>
Agreed, that's much better. To be even more robust, add quotes:
gcjversion=`cat "$sr
--- Comment #3 from hjl at gcc dot gnu dot org 2007-09-02 12:23 ---
Subject: Bug 33276
Author: hjl
Date: Sun Sep 2 12:23:04 2007
New Revision: 128024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128024
Log:
gcc/fortran/
2007-09-02 H.J. Lu <[EMAIL PROTECTED]>
PR fo
--- Comment #14 from guillaume dot melquiond at ens-lyon dot fr 2007-09-02
11:56 ---
Created an attachment (id=14150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14150&action=view)
Implements folding of "(&function & 1)"
I encountered the same issue with some heavy template cod
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from manfred99 at gmx dot ch 2007-09-02 11:53 ---
Jerry, any news on this?
I have seen this pattern many times in legacy fortran77 code,
and the code authors seem to assume that ridiculously large loop
stop values do not compromize performance.
After all, in fortran77 yo
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 11:41 ---
[18:22] < apinski>
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5:
error: could not split insn^M
[18:22] < apinski> new failure
[18:23] < apinski> on ppc-linux-gnu
[18:23] < apinski> be
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-02 11:36 ---
I saw this also asn asked about it on IRC. Note please don't CC anyone unless
you know that they caused the bug. They don't want to be getting all bug
reports.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #18 from bonzini at gnu dot org 2007-09-02 11:29 ---
*** Bug 32161 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from bonzini at gnu dot org 2007-09-02 11:29 ---
*** This bug has been marked as a duplicate of 32009 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from doko at ubuntu dot com 2007-09-02 11:21 ---
Subject: Re: New: [4.3 Regression] libjava fails to compile
if configure argument contains "version"
belyshev at depni dot sinp dot msu dot ru schrieb:
> When gcc is configured with, for example, "--without-pkgversion",
When gcc is configured with, for example, "--without-pkgversion", this part of
libjava configure script parses "gcj -v" output incorrectly, thus encoding
garbage as preprocessor macro and failing:
gcjversion=`$GCJ -v 2>&1 | sed -n 's/^.*version \([[^ ]]*\).*$/\1/p'`
An obvious fix would be:
Inde
--- Comment #4 from tbm at gcc dot gnu dot org 2007-09-02 09:27 ---
Created an attachment (id=14149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14149&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
--- Comment #3 from tbm at gcc dot gnu dot org 2007-09-02 09:26 ---
This happens with 4.0 - 4.3. gcc 3.4 didn't have the -msym32 option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
--- Comment #2 from tbm at gcc dot gnu dot org 2007-09-02 09:08 ---
I can confirm this with FSF gcc 4.1.3 20070902
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tbm at cyrius dot com 2007-09-02 08:40 ---
I can reproduce this with
gcc-4.1 -c -mabi=64 -msym32 -mno-abicalls -O
using Debian's gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-09-02
08:24 ---
sorry for the noise, seems to be something else, closing the report.
Matthias
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O0 execution test
WARNING: program timed out.
FAIL: libgomp.for
74 matches
Mail list logo
