--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-20 17:44 ---
Regarding comment 0: I believe the program is valid
Regarding proc_decl_8.f90 and interface_21.f90: The programs are obviously
invalid - and the error message is OK.
* * *
In case of proc_decl_8.f90/interface_21
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-20 18:07 ---
Subject: Bug 40452
Author: burnus
Date: Sat Jun 20 18:07:10 2009
New Revision: 148750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148750
Log:
2009-06-20 Tobias Burnus
PR fortr
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-22 11:51 ---
(In reply to comment #9)
> At revision 148777 (but not at r148732) [...] Segmentation fault
Does not segfault here, but I get with valgrind:
==23187== Use of uninitialised value of size 8
==23187==at 0x52A2
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-22 11:55 ---
Jerry's patch: http://gcc.gnu.org/ml/fortran/2009-06/msg00233.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40508
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-22 14:21 ---
Patch
Index: simplify.c
===
--- simplify.c (revision 148777)
+++ simplify.c (working copy)
@@ -5117,7 +5117,14 @@ gfc_simplify_spread (gfc_expr
--- Comment #13 from burnus at gcc dot gnu dot org 2009-06-22 14:32 ---
> + else
> +mpz_set_si (size, 1);
Too quick. That should be: mpz_init_set_si or mpz_init_set_ui; the _init_ was
missing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-22 20:15 ---
Thomas, I think your patch does not help.
(In reply to comment #2)
> This patchlet avoids the ICE:
>gfc_array_size (source, &size);
> - if (mpz_get_si (size)*ncopies > gfc_option.flag_max_a
--- Comment #16 from burnus at gcc dot gnu dot org 2009-06-22 20:24 ---
Subject: Bug 40472
Author: burnus
Date: Mon Jun 22 20:24:18 2009
New Revision: 148814
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148814
Log:
2009-06-22 Tobias Burnus
PR fortr
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-22 20:31 ---
FIXED on the trunk (4.5) with the patch of PR 40472 comment 19.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-23 08:34 ---
(In reply to comment #3)
> This patch gives the correct error messages for comment #1
> + && actual->ts.derived && actual->ts.derived->ts.is_iso_c
> + &
.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40541
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-24 12:59 ---
(In reply to comment #3)
Regarding the implicit typing: I think it would be easiest to apply the
implicit typing for
module m
external foo
end module m
at resolution time, such that "foo" is
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-24 13:45 ---
I think the problem relates to what is regarded as TRUE and what is regarded as
FALSE by the compilers (the following output has been produced by
transfer(.true.,0), transfer(.false.,0)):
gfortran has: .true. = 1
e 1:
...
default:
__builtin_unreachable(); /* Or through an error here. */
}
--
Summary: compile warnings in libgfortran
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40545
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-24 17:59 ---
Alexander, I just filled Issue 553679 at premier.intel.com as associated bug. I
realized that the issue is even bigger:
C99's 6.3.1.2 has "When any scalar value is converted to _Bool, the result is 0
if
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-24 18:11 ---
> > It would be nice to have an option to turn off that fast inversion, at least
> > for compatibility. Or at least to make -O0 case compatible.
> How do other vendor's (Sun, Pathscale, Absoft,
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-24 21:53 ---
Created an attachment (id=18062)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18062&action=view)
Initial patch, somewhat working, but still many failures
Draft patch for item 1 and item 2 - still inc
ity: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40549
assumed-size dummy
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gc
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-25 13:32 ---
Fails with 4.3.x to 4.5.0
(In 4.1.x/4.2.x it also fails, but there no return value is set at all, i.e.
one gets "warning: Function does not return a value" - and four times "-42".)
--
burnu
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-25 15:06 ---
Another example. The following two subroutines are essentially identical,
except that one has an explicit interface and one an implicit interface. The
only extra information the explicit interface provides is that
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-25 15:43 ---
(In reply to comment #3)
> Another example.
Which is invalid. Mea culpa:
"A procedure ... shall have an explicit interface if ... (3) The procedure has
a result that (a) is an array"
(That is somet
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-25 16:04 ---
I think I would go for option (b) of creating a new array descriptor, which is
then used for copy out. The place where currently the creation of a temporary
is prevented is:
gfc_trans_arrayfunc_assign
If the
in the wrong scope
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569
: ISO_FORTRAN_ENV: Missing constants
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-27 19:44 ---
Do not forget to update intrinsic.texi!
For the missing constants in ISO_FORTRAN_ENV, see PR 40571
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-28 17:57 ---
Subject: Bug 34112
Author: burnus
Date: Sun Jun 28 17:56:41 2009
New Revision: 149036
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149036
Log:
2009-06-28 Tobias Burnus
Francoi
--- Comment #13 from burnus at gcc dot gnu dot org 2009-06-28 19:51 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-29 07:49 ---
Can this be backported to 4.4? If so, it should happen soonish to be in 4.4.1.
Paul, shall I do it for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
oduct: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40580
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40581
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 12:27 ---
Hmm, the following works here on x86_64-openSUSE (the -4.x are the ones of
openSUSE; the last one is today's vanilla trunk build):
gcc-4.2 -c aa.F90; gcc-4.3 -c aa.F90; gcc-4.4 -c aa.F90; gcc -c aa.F90
gfortra
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 12:41 ---
> The automatism works fine for .f90 files, so I suppose it is supposed to
> work for .f95, too?
>
> I guess a fix is simple (making that file suffix known). I am rather wondering
> why our instal
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 15:17 ---
I agree that
&& (gfc_option.flag_dollar_ok && c != '$'))
is wrong and is should either be
&& !(gfc_option.flag_dollar_ok && c == '$'))
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 16:23 ---
Mine. I have a patch.
PR 29616 is related, but goes beyond by checking also assignments to pointers
and undefined pointers (not only for unassociated pointers). (For -std=f95 one
can also check assignments to
0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code, rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus a
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 17:40 ---
Hmm, something else goes wrong, too, my fix for PR 40580 does not generate a
check (for procpointer results), it does for pointer function results and it
does for normal proc pointers. Thus, it either gets fixed
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-29 21:00 ---
PR 40580 added an argument checking for pointer/proc-pointer/allocatable, i.e.
the example "call foo(r)" of comment 0 is now detected via -fcheck=pointer.
TODO:
a) call sub( uninit_alloc_returning_functio
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-29 21:00 ---
-fcheck=pointer (remaining issues/features) is now tracked at PR 40593
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40593
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-29 21:02 ---
Subject: Bug 40580
Author: burnus
Date: Mon Jun 29 21:02:17 2009
New Revision: 149063
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149063
Log:
2009-06-29 Tobias Burnus
PR fortr
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-29 21:02 ---
FIXED on the trunk (4.5). Follow up is PR 29616
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-30 05:21 ---
> -fcheck=pointer (remaining issues/features) is now tracked at PR 40593
Ignore - that should have gone to PR 40580
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40593
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-30 09:46 ---
array(:,1) = 0
would then become
ARRAY_RANGE_REF = { }
and
array(:,1) = [1,2,3]
would then become
ARRAY_RANGE_REF = { 1,2,3 }
If I recall correctly, using memcopy/memset causes alias analysis problems as
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-01 07:51 ---
(In reply to comment #4)
Here, I do not get any segfault/problem with valgrind (for gfortran and a.out).
> tmp = build4 (ARRAY_RANGE_REF, TREE_TYPE (dest), dest,
> build_i
tus: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40605
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-01 13:02 ---
*** Bug 40604 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-01 13:02 ---
Yours was there first, but still I make it as duplicate of my PR. Note there is
also a fix needed for the run-time check, also due to OPTIONAL.
Thanks for the report.
*** This bug has been marked as a duplicate of
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-01 13:40 ---
But of cause also the run-time test fails; for absent arguments a NULL is
passed.
We need to check:
a) optional pointer actual to non-optional dummy
b) optional pointer actual to optional dummy
The -fcheck=pointer
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-01 14:37 ---
The generic interface problem should be fixed by the following, which includes
the bits from the others patches:
--- trans-expr.c(revision 149129)
+++ trans-expr.c(working copy)
@@ -2778 +2778
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-01 16:09 ---
Another failure - this time for __convert_i4_r4 (a EXPR_FUNCTION) as actual
argument, which does not set sym->result ...
Test case:
SUBROUTINE plotdop(amat)
IMPLICIT NONE
REAL,INTENT
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-02 12:36 ---
> > call output (p1, p2, p3, p4)
> > That still clobbers p1, p2, p3, and p4 as they are passed by reference so
> > is it really undefined code if output changes the values for
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-02 15:07 ---
Restricting can be done via casting to volatile - then it is only
*(volatile int *)&i
That needs then to be applies in all expressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-02 14:44 ---
Michael Matz fixed that for allocatable arrays, but the patch needs to be
extended to nonallocatable arrays, cf.
http://gcc.gnu.org/ml/fortran/2009-07/msg4.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #9 from burnus at gcc dot gnu dot org 2009-07-03 06:40 ---
(In reply to comment #8)
> Please try with a newer version of gfortran. Literally, hundreds of
> bugs and changes have occurred since version 4.3.0 was released.
> I believe this bug is a duplicate o
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40628
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-03 10:13 ---
Confirmed. One first gets the error message from gfc_get_sym_tree (already been
host associated), followed by the segfault, which happens at
==12785== Use of uninitialised value of size 8
==12785==at 0x500F17
onent: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40632
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-03 11:33 ---
> Michael Matz fixed that for allocatable arrays, but the patch needs to be
> extended to nonallocatable arrays, cf.
> http://gcc.gnu.org/ml/fortran/2009-07/msg4.html
Actually, there it already works
--- Comment #24 from burnus at gcc dot gnu dot org 2009-07-03 12:40 ---
> One issue is that
> ISET = MINLOC (DTEMP)
> will cause GCC to assume that DTEMP is clobbered.
The problem is that while "MINLOC" is pure, we cannot use DECL_PURE_P as the
result is
--- Comment #26 from burnus at gcc dot gnu dot org 2009-07-03 13:07 ---
> has a superfluous check || (pos.0 == 0 && (*D.1568)[S.3 + D.1569] == limit.2)
> at least for flag_finite_math_only. If the array cannot contain Inf or NaN
> then it either has all elements == FLT
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-03 14:19 ---
> gfortran 4.3.1. Attached 15 line test program reproduces the effect
Can you attach the program?
I assume you compiled it with "gfortran -Wall testfile.f" and no further option
such a -malign-doub
t org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40643
ED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40646
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-04 12:45 ---
The problem is:
gcc_assert (expr2->value.function.isym
|| (!comp && gfc_return_by_reference (expr2->value.function.esym)
which assumes that "esym" is set. However
oduct: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.or
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-07 12:47 ---
> You were right - contiguous does need initializing. Not for this case but
> some of the other uses that I referred to.
Paul, what is the plan? You had a 4.4 and 4.5 check in, contiguous is not
initialized
--- Comment #13 from burnus at gcc dot gnu dot org 2009-07-07 15:27 ---
(In reply to comment #12)
> > You were right - contiguous does need initializing. Not for this case but
> > some of the other uses that I referred to.
> Paul, what is the plan? You had a 4.4 a
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-08 07:36 ---
I can reproduce the ICE with 4.1, 4.2 and 4.3 - but it no longer gives an ICE
with 4.4 or 4.5.
* * *
However, there is also a bug in 4.4: It simply compiles.
Expected: Either an error of the form (NAG f95
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-08 08:00 ---
I think one can consider supporting non-signed zeros as extension, similar to
ifort which has:
-assume nominus0The compiler uses Fortran 90/77 standard
semantics in
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-08 12:37 ---
(In reply to comment #4)
> It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and
> Intel64(?), see
I can - somewhat - reproduce it. It does not fail but valgrind shows
(x86-64-linux an
--- Comment #11 from burnus at gcc dot gnu dot org 2009-07-08 14:55 ---
Created an attachment (id=18158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158&action=view)
Patch - lightly tested
Attached patch fixes the problem [independent of
"-f(no-)signed-zeros&
--- Comment #15 from burnus at gcc dot gnu dot org 2009-07-08 19:35 ---
Subject: Bug 40675
Author: burnus
Date: Wed Jul 8 19:34:49 2009
New Revision: 149390
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149390
Log:
2009-07-08 Tobias Burnus
PR fortr
--- Comment #16 from burnus at gcc dot gnu dot org 2009-07-08 20:55 ---
Close as FIXED (on the trunk [= 4.5]).
Greg, thanks for the report. Using a 4.5/trunk build (e.g. one of the nightly
builds) gfortran will offer the option -fno-sign-zero which allows your
program to work
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-09 09:42 ---
Subject: Bug 40604
Author: burnus
Date: Thu Jul 9 09:42:34 2009
New Revision: 149405
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149405
Log:
2009-07-09 Tobias Burnus
PR fortr
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-09 09:57 ---
FIXED on the trunk (4.5). The commit message only made it to PR 40604 as I
forgot about PR 40605 ...
Subject: Bug 40604
Author: burnus
Date: Thu Jul 9 09:42:34 2009
New Revision: 149405
URL: http://gcc.gnu.org
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-09 14:48 ---
> However, there is also a bug in 4.4: It simply compiles.
But if one adds a "print *, there_is", one sees that it does not work (wrong
result, independent of sunshine()!)
--
burnus at gcc dot gnu do
--- Comment #22 from burnus at gcc dot gnu dot org 2009-07-10 11:46 ---
For z a complex number: Patch for tan(z), sinh(z), cosh(z), tanh(z) - see at
http://gcc.gnu.org/ml/fortran/2009-07/msg00071.html
Remark: atan(z), asin(z) and acos(z) are also missing besides a{sin,cos,tan}h
--- Comment #23 from burnus at gcc dot gnu dot org 2009-07-10 15:45 ---
Created an attachment (id=18173)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18173&action=view)
Test implementation in C for complex arc{tan,sin,cos}{,h}
> Fallback implementations via complex
--- Comment #24 from burnus at gcc dot gnu dot org 2009-07-10 16:17 ---
Regarding expressions with Inf with x being finite according to Mathematica 7:
ArcSin (+/-Inf,x) = (0, -/+Inf)
ArcSin (x,+/-Inf) = (0, +/-Inf)
ArcCos (+/-Inf,x) = (0, +/-Inf)
ArcCos (x,+/-Inf) = (0, -/+Inf)
ArcTan
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-10 19:02 ---
Created an attachment (id=18175)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18175&action=view)
Results for the testcase with ifort, sunf95, NAG f95, openf95, g95
> Is this the behavior we
--- Comment #25 from burnus at gcc dot gnu dot org 2009-07-11 00:03 ---
Subject: Bug 33197
Author: burnus
Date: Sat Jul 11 00:03:07 2009
New Revision: 149503
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149503
Log:
2009-07-09 Tobias Burnus
PR fortr
: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40727
(1)"
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid, diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-12 22:19 ---
Created an attachment (id=18181)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18181&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
--- Comment #24 from burnus at gcc dot gnu dot org 2009-07-13 06:26 ---
Subject: Bug 22423
Author: burnus
Date: Mon Jul 13 06:26:38 2009
New Revision: 149545
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149545
Log:
2009-07-12 Tobias Burnus
Philippe Ma
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-13 06:26 ---
Subject: Bug 40588
Author: burnus
Date: Mon Jul 13 06:26:38 2009
New Revision: 149545
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149545
Log:
2009-07-12 Tobias Burnus
Philippe Ma
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-13 06:28 ---
FIXED on the trunk (4.5). Thanks for the report and patch!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from burnus at gcc dot gnu dot org 2009-07-13 06:31 ---
Fixed (cf. comment 24) the warning of comment 21 and comment 23. If a new
warning is spotted, feel free to open a new PR or reopen this PR.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-13 15:29 ---
(Not restricted to Darwin, happens also on x86-64-linux.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from burnus at gcc dot gnu dot org 2009-07-14 07:43 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00739.html
- MPC compile-time evaluation of complex tan and sinh/cosh/tanh
- Run-time complex a(sin,cos,tan)(h) with C99 fallback (for finite values only)
TODO
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-14 07:50 ---
Confirm (kind of) with GCC 4.3.2 on i686-linux. With -DBIGMOD one gets:
/tmp/ccmoM1rS.o: In function `tf_ad_splitting_driver_plane_':
t.F90:(.text+0xad): undefined reference to `span.1'
t.F90:(.
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-14 09:46 ---
> Probably due (or uncovered) by revision 149586
That's: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149586
2009-07-13 Janus Weil
PR fortran/40646
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-14 09:47 ---
> [ibook-dhum] f90/bug% gfc -c iso_varying_string.f95
I assume that's the file: http://www.fortran.com/iso_varying_string.f95
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40756
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 06:08 ---
> In a quick scan of the patch, I note that the mpfr versions
> of the simplifications weren't in the patch.
MPFR or MPC? The MPFR version should be there since years; the MPC version of
tan/sinh/cosh/
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|sparc-unknown-linux-gnu |
GCC host triplet|sparc-unknown-linux-gnu |
GCC target triplet
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-15 07:42 ---
> I pointed this out to Paul already, but appearantly it is still stuck in his
> whole-file patch queue.
Last incarnation of that patch (containing this fix) is at:
http://gcc.gnu.org/ml/fortran/2009-07/ms
301 - 400 of 4285 matches
Mail list logo
