--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.4 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.4 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-02-01 22:54
---
I've tried the following trivial patch (which should handle both common
blocks and equivalences):
Index: trans-common.c
===
--- trans-common.c
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2008-01-31 10:38
---
(In reply to comment #8)
I'll respond to Jakub's latest comments before trying DJ's more recent patch.
Running getconf ARG_MAX on my IRIX box, returns 20480, which is 20K.
I believe this is the default, out
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-01-31 15:36
---
That one is not a regression. It happens because, when the a argument is an
assumed-shape array, gfc_return_by_reference() return 0 because
sym-attr.always_explicit is set for the function.
There are two
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-01-30 09:52
---
This is fixed in current trunk, the patch has been applied at some point.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-30 10:04
---
(In reply to comment #4)
Author: ktietz
Date: Wed Jan 2 10:46:17 2008
New Revision: 131255
Kai, did the patch fully fix the issue? If so, could you close this PR?
--
fxcoudert at gcc dot gnu dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2008-01-31 00:26
---
(In reply to comment #8)
As I see it, gfortran never knows it does syntax checking only?!
Exactly.
What exactly do you mean by #file headers? Preprocessor include directives
as
`#include foo.inc`?
Yes
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-01-29 10:56
---
Confirmed, also fails on 4.3.0.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-01-29 10:26
---
PR34742 is also related to documentation of our ABI/calling conventions
(whatever the correct term is). I agree we should document them, as well as
some other gfortran-specific non-portable stuff like how do
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-01-29 10:26
---
See PR34528 also.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-01-29 16:15
---
(In reply to comment #2)
Andrew, you mentioned the two-decl per function elsewhere as well. Where can
one learn more about this? why do we have two decls at all? where do they come
from, where do they go? How
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-01-29 19:45
---
(In reply to comment #3)
will it make it into 4.2.3?
No way: the release process for 4.2.3 has started:
http://gcc.gnu.org/ml/gcc/2008-01/msg00477.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34719
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-24 13:57
---
(In reply to comment #1)
If it is an extension of something as old as F66 and g77 didn't implement it,
I
think gfortran does not need to implement it either. IMO, take the notes from
g77 and be done
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-23 10:56
---
*** Bug 34933 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-23 10:56
---
We chose not to implement it (I remember discussing it with Jerry and someone
else on IRC, and I think I asked for opinions on the mailing-list before
closing the bugreport as WONTFIX), because of the potential
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:12
---
(In reply to comment #4)
Reply to comment #2: I will update and see if that fixes it. Thanks Danny
I'm closing this: I have built new binaries and I still don't this it. Jerry,
if updating doesn't fix
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:20
---
Works for me with a more recent version (version 4.3.0 20071231), on my MacOS
10.4.11/Intel Core Duo, so I'm closing this as fixed.
Could you try to update your compiler (see
http://gcc.gnu.org/wiki
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:25
---
(In reply to comment #5)
I do not have a strong feeling about it, and I would accept it if you
propose to close this issue.
[...]
A -ffake-lack-of-integer-kind-1 option would have made it easier to
resolve
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:33
---
Reproduced on powerpc-apple-darwin9.1.0, both with -m32 and -m64. It happens
with stabs, but not with dwarf.
$ gfortran -gstabs test.f -g -m32
can't find atom for N_GSYM stabs nrange:G(0,5) in /var/tmp
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34854
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-01-16 23:47
---
(In reply to comment #3)
You need C to support libgfortran so my question here is still valid. What is
sizeof(char) for your target?
Seriously if the target does not define sizeof(char) as 1, it is broken
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-09 16:41
---
I've just built fresh binaries and It Works For Me(TM):
$ cat a.f90
program bug
double precision x
x=7.0
print *, x
end
$ gfortran.exe -v
Using built-in specs.
Target: i386-pc
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34669
: unknown
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-12-11 00:58
---
FAIL: gfortran.dg/proc_decl_1.f90 -O (test for errors, line 74)
FAIL: gfortran.dg/proc_decl_1.f90 -O (test for excess errors)
It'd be interesting to know why it fails to match the error at line 74 (which
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34420
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-12-08 15:45
---
Not standard and probably requires quite some work to get it working; closing
as WONTFIX, as per http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html. If
someone comes up with a patch, it'll be of course
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-12-08 21:30
---
(In reply to comment #7)
we could make specific versions of all those intrinsic that
currently use memcpy(), including pack.
Thomas, your patch for this bug produces warnings when building libgfortran
(see
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34324
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-11-30 09:27
---
This time it can probably be marked as fixed. Please reopen it if the problem
persists.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2007-11-29 11:25:01 |2007-11-29 11
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-28 18:03
---
I consider this a bug. I have to check, but I think that the IEEE rules are
clear, even though they are not mandatory until we introduce the corresponding
standard modules. The calculation of y does overflow
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-28 19:23
---
(In reply to comment #7)
a) Do other compilers have an equivalent to -fno-range-check?
Most compilers have a behaviour similar to -fno-range-check by default, only
warning about range problems (Intel, Sun, g95
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-11-27 21:51
---
(In reply to comment #20)
OK, I've found the problem. tgammaf has not been added to
gfortran.map.
Yuck. I should have remembered that :(
I don't know
enough about symbol versioning to determine
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-26 17:58
---
(In reply to comment #10)
Bug 33942 was marked as a duplicate of this one, but it is not fixed
PR33942 contains two different issues: first, that using GAMMA in your main
program is calling the system gamma
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-22 08:56
---
Erik, Paul, as authors of the original patch and testcases, can you confirm my
conclusion that the code in comment #4 (and thus, the
gfortran.dg/alloc_comp_constructor_1.f90 testcase) is not legal, for the reason
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-22 09:09
---
It's not even MERGE-related:
$ cat a.f90
integer :: i(1) = 0
write(*,*) foo([1]+i)
end
$ gfortran a.f90
a.f90: In function MAIN__:
a.f90:1: internal compiler error: in gfc_trans_create_temp_array
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-21 12:25
---
The following (doesn't need to be compiled with -fdefault-integer-8):
character (len=5) :: c
integer(kind=8) :: i
i = 3
c(i:i) = 'a'
if (c(i:i) /= 'a') call abort ()
end
gives the tree code below
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-21 13:51
---
I think this is valid code. The reduced testcase is:
$ cat y.f90
program testCode
implicit none
type vec
real, dimension(1) :: coords
end type
integer :: i
real, dimension(1,1), parameter :: vy = 1
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-21 13:53
---
It's fixed by the simple patch below:
Index: resolve.c
===
--- resolve.c (revision 130234)
+++ resolve.c (working copy)
@@ -740,6 +740,8
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-21 18:58
---
$ cat z.f
subroutine warn_character(d)
character c, d
d = c
end
$ gfortran -O2 -Wall z.f -c
z.f: In function warn_character:
z.f:3: warning: c[1]{lb: 1 sz: 1} is used uninitialized
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-21 18:32
---
Subject: Bug 34083
Author: fxcoudert
Date: Wed Nov 21 18:32:40 2007
New Revision: 130332
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130332
Log:
PR fortran/34083
* resolve.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-21 18:34
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-20 13:03
---
The Intel and Sun compilers complain that this code is not legal, because you
can't do x = mytype(yy, bar) if yy is not allocated.
Otherwise, a reduced testcase on x86_64-linux is:
type t
integer
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-20 13:10
---
(In reply to comment #1)
The problem is that you end up in the wrong file. If you enter break 3 you
are debugging the wrapping program not the Fortran program test, which is
the
reason that there is no i
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-20 18:03
---
Here is a minimal testcase that reproduces the unclear error message:
subroutine prirelval(nobs, dataset)
type ped_data
integer :: maxsiz
end type ped_data
integer, dimension(dataset%maxsiz) :: nobs
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-19 16:54
---
EXPONENT is implemented in libgfortran with frexpf. Can you tell us what the
following gives:
int main() {
float x = 5.87747175E-39;
int i;
__builtin_frexpf (x, i);
__builtin_printf (%d\n, i
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-19 17:18
---
OK, so you need to file a bug report to Apple. We probably should consider
XFAILing that testcase.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2007-11-17 13:49
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2007-11-17 13:47
---
Subject: Bug 30285
Author: fxcoudert
Date: Sat Nov 17 13:46:53 2007
New Revision: 130257
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130257
Log:
PR fortran/30285
* module.c (struct
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-11-17 16:55
---
Mine, I have posted a patch.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-17 17:10
---
First, a question: what are the math functions that should be used for DFmode
on sh with -m2e? For example, what function should we use for copysign(DFmode,
DFmode): is that copysignl?
After talking about
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-11-17 17:49
---
Subject: Bug 25252
Author: fxcoudert
Date: Sat Nov 17 17:49:45 2007
New Revision: 130259
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130259
Log:
PR fortran/25252
* interface.c
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2007-11-17 17:54
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-17 22:42
---
It's 64-bit only, and it appears to be a glibc bug: with glibc on x86_64,
sinf((float) integer_variable) is slower than (float)sin((double)
integer_variable). Paul Brook looked into it a bit, and said that while
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:20
---
Subject: Bug 34084
Author: fxcoudert
Date: Fri Nov 16 22:20:44 2007
New Revision: 130244
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130244
Log:
PR fortran/33739
PR fortran/34084
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:20
---
Subject: Bug 33739
Author: fxcoudert
Date: Fri Nov 16 22:20:44 2007
New Revision: 130244
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130244
Log:
PR fortran/33739
PR fortran/34084
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:24
---
Regression fixed by reverting the patch, sorry for the breakage.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:24
---
Reopening, since the fix cause a regression (PR 34084). Please remember to fix
both problems at the same time. The other problem is:
INCLUDE 'anything'
PROGRAM test_cg
END PROGRAM test_cg
The INCLUDE file can
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:31
---
Subject: Bug 33698
Author: fxcoudert
Date: Fri Nov 16 22:31:28 2007
New Revision: 130245
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130245
Log:
PR libfortran/33583
PR libfortran/33698
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:31
---
Subject: Bug 33583
Author: fxcoudert
Date: Fri Nov 16 22:31:28 2007
New Revision: 130245
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130245
Log:
PR libfortran/33583
PR libfortran/33698
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:38
---
Subject: Bug 33957
Author: fxcoudert
Date: Fri Nov 16 22:38:21 2007
New Revision: 130246
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130246
Log:
PR fortran/33957
* gfortran.dg
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:40
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:46
---
I hope it's now fixed. If there is something more to it, please reopen the PR
or file a new one.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:46
---
I hope it's now fixed. If there is something more to it, please reopen the PR
or file a new one.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-16 23:29
---
I submitted a patch that removes the ICE and adds a better error message.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-11-16 23:42
---
(In reply to comment #6)
Yes. When -m2e is specified on SH, DOUBLE_TYPE_SIZE is set to
32 and double_type_node has the SF type.
Perhaps all targets which set DOUBLE_TYPE_SIZE to other than 64
might have
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-17 00:07
---
While I'm trying to understand what happens, I should say that a simply
workaround is to make your calculation happen in double precision (change
3.14159 into 3.14159d0; after all, you want a double-precision
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-17 00:10
---
Subject: Bug 34108
Author: fxcoudert
Date: Sat Nov 17 00:10:00 2007
New Revision: 130249
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130249
Log:
PR fortran/34108
* io.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-17 00:22
---
Fixed. Thanks for the bug report.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-15 16:40
---
Confirmed on x86_64-linux, where it triggers (with valgrind):
==2841== Conditional jump or move depends on uninitialised value(s)
==2841==at 0x43550B: next_char (io.c:141)
==2841==by 0x435616
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-13 12:28
---
(In reply to comment #4)
__builtin_copysign has got SFmode(*)(SFmode, SFmode) prototype and is invoked
on DFmode arguments.
copysign takes doubles and returns a double. Does the SH double have SF mode
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-13 13:55
---
Confirmed on x86_64-linux.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-13 21:18
---
(In reply to comment #1)
FX, can you have a look? I would not be surprised if one of your debug patches
caused the regression
Me neither. A simple workaround is to simply add a blank line before the
INCLUDE
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-12 10:27
---
(In reply to comment #2)
according the manual the later (no abort) should be equivalent to the former
(abort), but is not
The manual only says -On turns on the following optimization flags, but it
does a few
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-11 14:34
---
(In reply to comment #1)
Could you try the attached patch?
I am rebulding and will test it, but it takes quite some time...
By the way, I have posted the test results of mainline on mips-sgi-irix6.5 at
http
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-11 16:56
---
(In reply to comment #2)
I am rebulding and will test it, but it takes quite some time...
Less than I thought! It fixes it, and no other regression has appeared.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-11 22:30
---
There's only one non-trivial Fortran change in the 130037-130081 range: it's
rev. 130072. I don't see how it could be realted, but if you could revert this
patch and confirm, then it's probably an optimizer
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-11-12 00:18
---
Reduced further:
$ cat m.f90
logical :: a(1)
a = .true.
write(*,*) foo(merge((/ 1 /), 1, a))
end
$ gfortran m.f90
m.f90: In function MAIN__:
m.f90:2: internal compiler error
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-11-12 01:14
---
I don't see how this can be a regression wrt g77, which doesn't have
assumed-shape arrays or even UBOUND!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-10 18:02
---
Subject: Bug 33592
Author: fxcoudert
Date: Sat Nov 10 18:02:18 2007
New Revision: 130072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130072
Log:
PR fortran/33592
* trans.c
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-11-10 18:09
---
(In reply to comment #20)
I would love to test it with a i586/i686-compatible build. (f951 should
be sufficient that can be used as a replacement in one of those regular
builds provided on FX's web page
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-11-09 12:36
---
I think the problem starts with:
module mod0
integer mpi_bottom
common /mpipriv/ mpi_bottom
end module mod0
module mod1
use mod0
end module mod1
module mod2
use mod0
use mod1
end module mod2
601 - 700 of 3175 matches
Mail list logo
