--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 05:49 ---
I have a tentative patch for this.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 04:25 ---
Need more details? Are the 3 routines in separate files?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 04:20 ---
Details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25083
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 03:57 ---
Details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25100
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 03:56 ---
Where are the details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25101
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 03:55 ---
What's broken here? Where are the details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25102
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 03:53 ---
What's broken here? Where are the details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25103
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 03:52 ---
What broken here? Where are the details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-27 03:51 ---
So what broken here? There's no detail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25105
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-27 03:08 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01864.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Consider:
unsigned int bar (void);
void
foo (void)
{
unsigned int a = bar ();
if (a <= 3)
bar ();
}
./cc1 -quiet -O2 -fomit-frame-pointer generates
foo:
move.l %a2,-(%sp)
lea bar,%a2
jbsr (%a2)
moveq #3,%d1
cmp.l %d0,%d1
jbcs .L4
j
Consider:
unsigned int bar (void);
void
foo (void)
{
unsigned int a = bar ();
a >>= 2;
if (a == 0)
bar ();
}
./cc1 -quiet -O2 -m5200 -fomit-frame-pointer generates
foo:
move.l %a2,-(%sp)
lea bar,%a2
jbsr (%a2)
lsr.l #2,%d0
tst.l %d0
jbne
Consider:
int bar (void);
void
foo (void)
{
int a = bar ();
if (a == 1)
bar ();
}
./cc1 -quiet -O2 -m5200 -fomit-frame-pointer generates
foo:
move.l %a2,-(%sp)
lea bar,%a2
jbsr (%a2)
moveq #1,%d1
cmp.l %d0,%d1
jbne .L4
jbsr (%a2)
.
--- Comment #22 from pcarlini at suse dot de 2005-11-27 02:10 ---
I think we can close the PR now: the miscompilation is fixed and some tricks in
basic_string are well known (and not present in ext/vstring.h and basic_string
in v7-branch).
--
pcarlini at suse dot de changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-27 01:49 ---
Closing as invalid based on a private email.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-27 01:00 ---
Hmm, 3.3.x did not define __float128 at all. 3.4 and 4.0 did not ICE at -O1
-mmmx but did at -O2 -mmmx (that means it is unit-at-a-time related). I am
going to mark this as a regression as anything to an ICE should
--- Comment #1 from kazu at gcc dot gnu dot org 2005-11-27 00:52 ---
The whole story applies to XOR as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25111
Consider:
int bar (void);
int
foo (int b)
{
int a = bar ();
return a | (1 << (b & 31));
}
./cc1 -quiet -O2 -m5200 -fomit-frame-pointer generates
foo:
move.l %d2,-(%sp)
move.l 8(%sp),%d2
jbsr bar
moveq #31,%d1
and.l %d1,%d2
move.b #1,%d1
--- Comment #4 from lichtwerk dot x at laposte dot net 2005-11-27 00:40
---
Thanks alot, now it's clear - I always struggled with dependent types a while
ago, but I think I got confused by the output this time.
It's good that g++ is a lot stricter than some other compilers.
Thx
--
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-11-27 00:34
---
Confirmed, we are deafaulting BLANK = to UNSPECIFIED rather than NULL as
required by F95 Standard.
Regression testing a patch now.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-27 00:27 ---
14.2/5 and 14.2/4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25110
--- Comment #2 from lichtwerk dot x at laposte dot net 2005-11-27 00:15
---
Thanks very much, where can I find this in the standard ? 14.6.2 temp.dep ?
Bye
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25110
--- Comment #3 from brad dot finney at humboldt dot edu 2005-11-27 00:04
---
(From update of attachment 10347)
use input data
1 3 5
with inpter reads uncommented, use input data
1 3
--
brad dot finney at humboldt dot edu changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-27 00:04 ---
This is actually expected, you want:
f.template Func<0>();
Since f is dependent, we are not expecting Func to be a template so it parses
as a non template and then errors out as a<0 > () is invalid for anything
exce
Hello,
I stumbled across a somewhat strange behaviour in GCC 4.0.2. I was able to
simplify my code down to the following:
template
struct Type2Type
{
typedef T type;
};
template
class Foo
{
public:
template
void Func() { }
};
template
void Bar(const T& p1)
{
--- Comment #2 from brad dot finney at humboldt dot edu 2005-11-27 00:00
---
Created an attachment (id=10347)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10347&action=view)
test code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25109
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-26 23:53
---
Please attach an actual example of the code so we can study it. This is
probably a duplicate of pr25039, but I need to see an example to confirm.
--
jvdelisle at gcc dot gnu dot org changed:
What
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brad dot finney at humboldt dot edu
GCC build triplet: 4.2.0 20051126
GCC host
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-26 23:02 ---
*** Bug 25108 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-26 23:02 ---
This is a dup of bug 14404. The C++ code is illform with no diagnostic
required and the C++ compiler can (but does not have to) inline the constant
value in this case.
*** This bug has been marked as a duplicate of
#ifdef EXPOSE_GCC_BUG
template
class pow3 {
public:
static int const result = 3 * pow3::result;
};
template <>
class pow3<0> {
public:
static int const result = 1;
};
#else
template
class pow3 {
public:
enum { result = 3 * pow3::result };
};
template <>
class pow3<0> {
public:
enum { r
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-26 22:53 ---
Actually it is just a check for flag_wrapv which looks to be wrong as far as I
can tell.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23666
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-26 22:52 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #12 from rearnsha at gcc dot gnu dot org 2005-11-26 22:44
---
*** Bug 25044 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-26 22:44
---
*** This bug has been marked as a duplicate of 16314 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-26 22:38 ---
Actually there is two things that need to be done, first is what I said in
comment # 4 and then the second thing is for MINUS_EXPR to use those functions
instead of checking explicatly for NEGATE_EXPR.
--
http:/
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-26 22:18 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-26 22:18 ---
Subject: Bug 23669
Author: pinskia
Date: Sat Nov 26 22:18:04 2005
New Revision: 107543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107543
Log:
2005-11-26 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- Comment #16 from mark at codesourcery dot com 2005-11-26 21:48 ---
Subject: Re: Patch for ia64-hpux problems
Joseph S. Myers wrote:
> This patch fixes the ia64-hpux problems with my __floatun* patch. It adds
> a full set of C implementations of __floatunsi* which should also be
--- Comment #6 from sayle at gcc dot gnu dot org 2005-11-26 21:46 ---
Subject: Bug 21309
Author: sayle
Date: Sat Nov 26 21:46:19 2005
New Revision: 107542
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107542
Log:
PR middle-end/21309
* expmed.c (choose_mult_vari
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-26 21:43 ---
The problem here is my fault, slightly. Fold is converting -(~a) in the
NEGATE_EXPR but not in the generic functions to do the negation. I will do the
patch for this one. (I am saying that -(~a) is more complex th
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-26
21:19 ---
Subject: Re: [4.1/4.2 Regression] libobjc testsuite failures
> > > Here it is.
> >
> > Oops, the file sent had HAVE_GAS_WEAKDEF undef'd, so SUPPORTS_WEAK
> > is 0.
>
> With HAVE_GAS_WEAKDEF undef'd, we
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-26
20:25 ---
Subject: Re: [4.1/4.2 Regression] libobjc testsuite failures
> > Here it is.
>
> Oops, the file sent had HAVE_GAS_WEAKDEF undef'd, so SUPPORTS_WEAK
> is 0.
With HAVE_GAS_WEAKDEF undef'd, we have a large
--- Comment #2 from jv244 at cam dot ac dot uk 2005-11-26 20:19 ---
(In reply to comment #1)
> I think we have the right to
> accept non-default IOSTAT variable if we do it correctly ;)
not with -std=f95
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25068
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:54
---
gfortran doesn't detect that the CASEs overlap.
## g95 ##
In file foo.f90:3
CASE(.true.)
1
In file foo.f90:5
CASE(.true.)
2
Error: CASEs at (1) and (2) overlap
## Intel ##
fortcom: Error: foo.f90, lin
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:53
---
gfortran doesn't issue a correct error, and throw an ICE instead:
In file foo.f90:2
FORALL(I=1:10,T(I)) A(I)=I
1
Internal Error at (1):
free_expr0(): Bad expr type
## g95 ##
In file foo.f90:2
F
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:48
---
## g95 ##
In file foo.f90:2
CALL TST(I)
1
Error: Array argument at (1) is smaller than the dummy size
## Intel ##
fortcom: Error: foo.f90, line 2: The storage extent of the dummy argument
exceeds that o
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:47
---
gfortran doesn't catch that error at compile-time.
## g95 ##
In file foo.f90:3
CALL TST(I)
1
Error: Rank mismatch for assumed-shape array in parameter 'i' at (1)
## Intel ##
fortcom: Error: foo.f90, li
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:46
---
gfortran doesn't catch this error.
## g95 ##
In file foo.f90:8
NAMELIST/debugging/debug_area
1
Error: NAMELIST group 'debugging' at (1) is already use-associated
## Intel ##
fortcom: Error
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:41
---
Well, only g95 sees this bug. Is it really a violation of the standard? I don't
think so...
## g95 ##
In file foo.f90:1
INTEGER, PARAMETER :: C1=1
1
Error: COMMON block 'c1' at (1) is a
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:40
---
Humm... I don't think that one is bug, really. I think we have the right to
accept non-default IOSTAT variable if we do it correctly ;)
## gfortran ##
## g95 ##
In file foo.f90:3
CLOSE(10,IOSTAT=I)
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:38
---
gfortran segfaults on that one:
## gfortran ##
foo.f90:0: internal compiler error: Segmentation fault
## g95 ##
In file foo.f90:1
read(5,FMT=*,REC=10) I
1
Error: REC tag at (1) is
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:37
---
gfortran doesn't issue an error about this one:
## g95 ##
In file foo.f90:1
write(6,FMT='(I0)',SIZE=J,ADVANCE="NO") I
1
Error: SIZE tag at (1) can only appear in
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:36
---
*** This bug has been marked as a duplicate of 25064 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:36
---
*** Bug 25065 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25064
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:35
---
## g95 ##
In file foo.f90:2
write(6,nml=nml) I
1
Error: NAMELIST I/O statement at (1) must not have an I/O list
## Intel ##
fortcom: Warning: foo.f90, line 1: This name has not been give
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:34
---
gfortran doesn't catch that one:
## g95 ##
In file foo.f90:1
write(6,FMT='(I0)',EOR=999,ADVANCE="NO") I
1
Error: EOR tag at (1) can only appear in a READ stateme
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:31
---
gfortran doesn't catch that issue:
## Intel ##
fortcom: Warning: foo.f90, line 2: This name has not been given an explicit
type. [I]
SUBROUTINE S1(I)
---^
fortcom: Warning: foo.f90, line 4: This na
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:30
---
## g95 ##
In file foo.f90:3
a = 1.e0
1
Error: Can't determine UBOUND for the final dimension of assumed-size array at
(1)
## Intel ##
fortcom: Error: foo.f90, line 3: The upper bound shall not be omitted i
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:29
---
ICE on that one:
## gfortran ##
In file foo.f90:21
I=J
1
Error: Subroutine 's1' called in lieu of assignment at (1) must be PURE
foo.f90:12: internal compiler error: Segmentation fault
## g95 ##
In
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:27
---
Neither gfortran, nor g95, nor Portland see this error.
## gfortran ##
## g95 ##
## Intel ##
fortcom: Error: foo.f90, line 5: An ENTRY dummy argument is referenced in an
executable statement before it appears in
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:24
---
We currently have an ICE on that one:
## gfortran ##
foo.f90:0: internal compiler error: in gfc_assign_data_value, at
fortran/data.c:252
## g95 ##
In file foo.f90:5
DATA (D(I),I=1,2) /T1(3),T1(3)/
1
Erro
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:20
---
gfortran doesn't catch this one.
## g95 ##
In file foo.f90:15
write(6,*) J(L)
1
Error: Dummy procedure 'l' at (1) must be PURE
## Intel ##
fortcom: Warning: foo.f90, line 3: This name has not bee
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:17
---
OK, we
## g95 ##
In file foo.f90:1
STOP 001234
1
Error: Too many digits in stop/pause code at (1)
## Intel ##
## Portland ##
## Sun ##
STOP 001234
^
"foo.f90", Line = 1, Column = 6: ERROR: No m
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:13
---
## g95 ##
In file foo.f90:3
NAMELIST /NLIST/ a,b
1
Error: Variable 'b' at (1) must have constant bounds to be in a NAMELIST
## Intel ##
fortcom: Warning: foo.f90, line 2: This name has not b
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:06
---
The ice here is the same as the one in PR25049, but we shouldn't even come into
that part of the front-end. gfortran should recognize that CSHIFT is not
allowed here.
## gfortran ##
foo.f90:0: internal compiler e
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:12
---
Well, we issue an error here, but it's an Internal Error ;-)
## gfortran ##
In file foo.f90:5
END
1
Internal Error at (1):
build_dt: format with namelist
## g95 ##
In file foo.f90:4
write(6,FMT=*,NML=NL
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-11-26 19:10
---
The problem with the test case is not related to the weird dump I am getting.
Notice I also have a 'Y' in there too as well as a '\b' character. This is
really weird.
I also noticed some namelist failures in th
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:09
---
gfortran doesn't see the conflict here. As a matter of fact, neither Intel nor
Portland do issue an error.
## g95 ##
In file foo.f90:4
write(6,*) SIN(I),DCOS(J)
1
Error: COMMON block 'sin' at (1) i
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:07
---
gfortran doesn't see this code is invalid.
## g95 ##
In file foo.f90:3
a=>NULL(i)
1
Error: Unequal ranks in pointer assignment at (1) (1/2)
## Intel ##
fortcom: Error: foo.f90, line 3: The rank of the tar
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:03
---
ICE on this one, may be related to PR18769. Still a diagnostic bug too.
## g95 ##
In file foo.f90:3
integer, parameter, dimension(2,2) :: B = TRANSPOSE(A)
1
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 19:00
---
gfortran doesn't issue an error on that one, while we have:
## g95 ##
In file foo.f90:2
CALL S1((I))
1
Error: Actual argument for 'i' must be a pointer at (1)
## Intel ##
fortcom: Error: foo.f90, line
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 18:56
---
## gfortran ##
In file foo.f90:7
entry bar ()
1
Internal Error at (1):
insert_bbt(): Duplicate key found!
## g95 ##
In file foo.f90:7
entry bar ()
1
Error: EN
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 18:54
---
## gfortran ##
foo.f90: In function âs1â:
foo.f90:2: internal compiler error: Segmentation fault
## g95 ##
In file foo.f90:5
write(6,*) PRODUCT(A,B)
1
Error: 'mask' argument of 'pro
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-26 18:51
---
gfortran does not give diagnostic on that one.
## g95 ##
In file foo.f90:5
write(6,*) PRODUCT(A,N)
1
Error: 'dim' argument of 'product' intrinsic at (1) must not be OPTIONAL
## Intel ##
--- Comment #6 from smirolo at hotmail dot com 2005-11-26 18:31 ---
Created an attachment (id=10346)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10346&action=view)
output log on linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25107
--- Comment #5 from smirolo at hotmail dot com 2005-11-26 18:31 ---
Created an attachment (id=10345)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10345&action=view)
save-temps on linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25107
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-26 18:30
---
*** Bug 25107 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-26 18:30 ---
This is a dup of bug 11026 which was fixed only for 4.0.0.
The work around is to instantiated explictly.
*** This bug has been marked as a duplicate of 11026 ***
*** This bug has been marked as a duplicate of 1102
--- Comment #3 from smirolo at hotmail dot com 2005-11-26 18:30 ---
Created an attachment (id=10344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10344&action=view)
output log on macos
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25107
--- Comment #2 from smirolo at hotmail dot com 2005-11-26 18:29 ---
Created an attachment (id=10343)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10343&action=view)
save-temps on macos
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25107
--- Comment #1 from smirolo at hotmail dot com 2005-11-26 18:28 ---
Created an attachment (id=10342)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10342&action=view)
source file to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25107
I get a different behavior when compiling on powerpc/MacOSX 10.3.9 and
i686/Linux. In the first case,
the symbol is undefined while in the second case it is weak and thus link
correctly.
#include
#include "boost/dynamic_bitset.hpp"
int main( int argc, char *argv[] )
{
boost::dynamic_bitset<> a
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-26 18:12 ---
Writing a fix for this one also, we don't really need to fix PR 23669 to fix
the orginal testcase in here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
0 CONTINUE
END
--
Summary: better diagnostic needed
Product: gcc
Version: 4.1.0
Status: U
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-26 18:10 ---
(In reply to comment #2)
> That should have been i/-10.
> I am going to make this bug about -(i/-10) to i/10.
Actually -(i/10) to i/-10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24575
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
Subroutine My(n1)
Dimension myArray(n1)
Save myArray
CALL xxx(myarray)
End
Subroutine xxx(myarray)
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
INTEGER, PARAMETER :: K(2)=1
SELECT CASE(I)
CASE(MAXLOC(K,1))
END SELECT
END
--
Summary: better diagnostic needed
Pr
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
module foo
integer:: i
end module foo
program bar
use foo
integer, dimension (i)::j
end program bar
--
Summa
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
MODULE TT
TYPE data_type
INTEGER :: I
END TYPE data_type
INTERFACE ASSIGNMENT (=)
MODULE PROCEDURE set
END INTERFACE
CONTA
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-26 18:08 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01850.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
INTEGER :: A(10),J(2),I
FORALL(I=1:2:0)
A(I)=1
END FORALL
END
--
Summary: better diagnostic needed
Pr
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
integer :: I(4),J(2)
CALL S(I,J)
CONTAINS
ELEMENTAL SUBROUTINE S(I,J)
INTEGER, INTENT(IN) :: I,J
END SUBROUTINE S
END
--
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
integer :: I(2,2),J(2)
CALL S(I,J)
CONTAINS
ELEMENTAL SUBROUTINE S(I,J)
INTEGER, INTENT(IN) :: I,J
END SUBROUTINE S
END
--
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
MODULE M1
CONTAINS
SUBROUTINE S1(F)
INTERFACE
FUNCTION F()
INTEGER F
END FUNCTION F
END INTERFACE
END SUBROUTINE S1
END MOD
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
MODULE M1
TYPE T1
INTEGER :: I
END TYPE T1
CONTAINS
SUBROUTINE S1(D1)
TYPE(T1), OPTIONAL :: D1
write(6,*) PRESENT(D
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
TYPE T1
INTEGER :: I(2)
END TYPE T1
TYPE(T1) :: D(4)
DATA (D(i)%I,i=1,4) /8*0/
END
--
Summary: better diagnos
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
INTEGER :: i(10)
DATA (i(MODULO(j,5)),j=1,4) /4*0/
END
--
Summary: better diagnostic needed
Product: gcc
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
MODULE M1
TYPE T1
INTEGER :: I
END TYPE T1
INTERFACE I
MODULE PROCEDURE F1
END INTERFACE
PRIVATE :: T1,F1
PUBLIC :: I
CONTAIN
using GNU Fortran 95 (GCC) 4.1.0 20051126 (prerelease) with '-g -pedantic
-std=f95', I get a bad / no diagnostic for the following invalid code:
MODULE M1
TYPE T1
INTEGER :: I
END TYPE T1
PRIVATE :: T1
PUBLIC :: F1
CONTAINS
TYPE(T1) FUNCTION F1()
END FUNCTION
END MODULE
U
1 - 100 of 177 matches
Mail list logo
