--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-30 16:50 ---
Works with 4.2.1 (x86_64-suse-linux). Valgrind shows:
==27337== Invalid read of size 1
==27337==at 0x4752E2: resolve_symbol (resolve.c:9311)
==27337==by 0x482726: traverse_ns (symbol.c:3127)
==27337==by
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-05 14:18 ---
If one compares the dumps, one finds an additional
+ extern character(kind=1) testchar[1:80];
in the failing version. Thus while the working version accesses
&testcommon1.testchar[1]{lb: 1 sz: 1}
the fai
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-05 13:35 ---
I checked my old trunk builds:
2007-11-05-r129891 - works
2007-11-20-r130310 - fails
(= 25 fortran/ commits)
Assuming no local problems and a clean tree (looks like), the following commit
might have caused the
words: ice-on-invalid-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=38813
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-12 13:34 ---
> I think NAG f95 is right by rejecting it with:
> Error: line 9: The argument to C_LOC must not be an array pointer
Or maybe not: "15.1.2.5 C_LOC(X)" has for the result value:
"(2) If X is
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:39 ---
For quick reading, skip next part and continue below the * * *.
---
I think this applies still (at least partially) as libgfortran/config/fpu*.h's
set_cpu() still has the line. For GLIBC one
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:59 ---
For the diagnostics: I think it works, but we are checking in case of
C_LOC(Type%Comp) the symbol Type instead of Comp. Assume that Type is a
pointer and Comp is not then "gfc_is_data_pointer()" return
Status: 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=38822
properly
Product: gcc
Version: 4.4.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
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-13 16:33 ---
The problem is the following in arith.c:
if (op == INTRINSIC_POWER && op2->ts.type != BT_INTEGER)
goto runtime;
Thus it is only run-time evaluated. gfc_arith_power deals so far only with
(n
--- Comment #4 from burnus at gcc dot gnu dot org 2009-01-13 16:35 ---
I wonder whether this should be fixed together with PR 38823.
Currently, (x)**(non-integer) is never be simplified at compile time - and the
simplification would be an obvious place to do the checking.
--
http
-
Summary: Bogus BIND(C) error message
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-13 20:31 ---
Needed for legacy code; internal I/O allows the same (and more powerful) albeit
a bit lengthier.
Cf. http://gcc.gnu.org/ml/fortran/2009-01/msg00167.html
and
http://coding.derkeiler.com/Archive/Fortran
--- Comment #12 from burnus at gcc dot gnu dot org 2009-01-13 21:41 ---
> Add a runtime check that x in x**y is not < 0
I'm actually against a run time check which is based on -std=, -pedantic, -W*
or similar compile time diagnostic flags. I regard such trickery behind th
: normal
Priority: P3
Component: regression
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=38838
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-14 15:07 ---
Example:
subroutine test() bind(c, name=trim("Hello "))
end
Error: Syntax error in NAME= specifier for binding label at (1)
Per the R509 cited above this is valid. It is also accepted by other
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 15:13 ---
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d977a668b0316119
by James Van Buskirk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38838
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 15:30 ---
Before closing, please also check the two longer cases:
http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9
and the older (partially incorrect?) one at
http://groups.google.com/group
s: 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=38839
--- Comment #3 from burnus at gcc dot gnu dot org 2009-01-14 16:00 ---
The following seems to be rejected as well:
subroutine test() bind(c, name=1_"name")
I don't see why this is rejected. The standard has:
C540 (R509) The scalar-char-initialization-expr shal
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-14 16:00 ---
And for the universal-character-name, the following compiles with Intel's icc
void \u01ac(void) {
}
and should be valid C99. ICC generates the identifier "_u01ac". Using "gcc
-fextended-identif
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 16:09 ---
For UCN see also PR 9449.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38839
FIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
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=38846
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 18:45 ---
The culprit is -floop-block (which is already enabled by default in the
graphite branch with -O2). Using only -floop-interchange -floop-strip-mine I
get a run time inbetween (16.5s, single run). Using only -fgraphite
--- Comment #3 from burnus at gcc dot gnu dot org 2009-01-14 21:16 ---
> Thanks for this report. Please also test with the code of graphite
> branch that contains a patch that schedules several scalar optimizations
> that can improve the quality of the code generated.
--- Comment #4 from burnus at gcc dot gnu dot org 2009-01-14 21:26 ---
> @@ -2451 +2451 @@ gfc_conv_function_call (gfc_se * se, gfc
> - && fsym->as->type != AS_ASSUMED_SHAPE;
> + && fsym->as && fsym->as->typ
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-15 20:04 ---
Confirm. This is a regression with regards to 4.2.1; it fails at least since
20071008 (my oldest 4.3 trunk version).
Thanks for the report!
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-15 20:10 ---
ida = lbound(a%i)
if (any(ida /= (/1,1/))) print *, 'lbound', ida
Here, gfortran prints:
lbound 0 2
Correct would be
lbound 1 1
ida = ubound(a)
>>>>>>
--- Comment #9 from burnus at gcc dot gnu dot org 2009-01-16 06:50 ---
> Can we still get this into 4.4? In a way the ICE is a regression, since 4.3
> just gave an error message (stating that procedure pointers are not
> implemented) but no ICE.
I think one could; the p
--- Comment #4 from burnus at gcc dot gnu dot org 2009-01-16 19:32 ---
I will check, but if I recall correctly, procedure pointer were not implemented
at the time when it was removed, i.e. it could not possibly be called. When
they got implemented, no casting was needed as they were
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-16 19:43 ---
(In reply to comment #4)
> I will check, but if I recall correctly, procedure pointer were not
> implemented
> at the time when it was removed
The function was not even referred in trans*.c as far as I can
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-16 21:38 ---
Confirm.
Working: 4.4.0 20081029 (experimental) [trunk revision 141421]
Failing: 4.4.0 20081103 (experimental) [trunk revision 141544]
(assuming that my tree was clean back then)
--
burnus at gcc dot gnu dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-16 21:48 ---
Confirm. Thanks for reporting.
Backtrace:
#0 0x2b4a4645 in raise () from /lib64/libc.so.6
#1 0x2b4a5c33 in abort () from /lib64/libc.so.6
#2 0x2ad69c00 in *_gfortrani_internal_unpack_4 (d
t org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894
--- Comment #7 from burnus at gcc dot gnu dot org 2009-01-17 09:18 ---
(In reply to comment #6)
> I'd say re-adding that symbol until you change libgfortran ABI wouldn't hurt
> anything, but if you can prove no program could ever use it except for
> referencing dire
--- Comment #8 from burnus at gcc dot gnu dot org 2009-01-17 09:37 ---
> However, I just saw that due to missing argument checking the following works
> in gfortran 4.3:
>
> call c_f_funpointer(fun,bar) ! <<< Invalid; should be C_F_POINTER
That's actually no
--- Comment #9 from burnus at gcc dot gnu dot org 2009-01-17 09:58 ---
Patch http://gcc.gnu.org/ml/fortran/2009-01/msg00209.html
or one can close it as WONTFIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-17 10:46 ---
The example was wrong as the name is c_f_PROCpointer (no -fun- only in
type(c_funptr) and c_FUNloc). Working example:
use iso_c_binding
type(c_ptr) :: fun
procedure(), pointer :: bar
call c_f_procpointer(fun,bar
--- Comment #13 from burnus at gcc dot gnu dot org 2009-01-17 13:25 ---
Close as FIXED based on Dominique's remark.
--
burnus at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-17 15:45 ---
> shouldn't this be fixed for 4.3.3?
Too late - the release is too soon (freeze; release-candidate build is
running). Regarding 4.4.0: Do you plan to submit a patch soonish?
--
http://gcc.gnu.org/
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-17 22:20 ---
Created an attachment (id=17130)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17130&action=view)
Difference of the dump
The problem is the call
_gfortran_internal_unpack (&parm.2, D.1572);
sinc
--- Comment #23 from burnus at gcc dot gnu dot org 2009-01-17 22:51 ---
Program of comment 19 works here (x86-64) with all options I tried, incl. -m32,
-fgraphite-identity etc. - valgrind shows no problems.
For the program in attachment 17125 / commment 13: I get the same valgrind
--- Comment #31 from burnus at gcc dot gnu dot org 2009-01-18 13:24 ---
(In reply to comment #27)
> Further reduced test case:
Using gfortran on x86-64-linux, I see with -m64 and all -O* a line which ends
in " xyz'". However, with -m32 and -O (n >= 2) I only see:
--- Comment #32 from burnus at gcc dot gnu dot org 2009-01-18 13:25 ---
Created an attachment (id=17134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17134&action=view)
Assembler diff on x86-64-openSUSE Factory with -m32 -O1 (working) and -m32 -O2
(failing)
Attac
--- Comment #3 from burnus at gcc dot gnu dot org 2009-01-18 14:28 ---
Slightly reduced test case below. If the FROM= and TO= arguments ("A()%I") are
not the same, the program does not ICE. Neither does it if one changes the
bound "N2" to "2" (but it
--- Comment #4 from burnus at gcc dot gnu dot org 2009-01-18 19:16 ---
Some more data: Using
printf("Node: tmp = %s\n", tree_code_name[TREE_CODE (tmp)]);
printf("Node: desc = %s\n",
tree_code_name[TREE_CODE (gfc_get_element_type (TREE_TYPE (desc)))]
--- Comment #3 from burnus at gcc dot gnu dot org 2009-01-18 22:27 ---
Confirm. Thanks for the report!
Valgrind shows:
==20941== Conditional jump or move depends on uninitialised value(s)
==20941==at 0x46C602: gfc_resolve_expr (resolve.c:4353)
==20941==by 0x46BC22
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-19 18:49 ---
Confirm. ICE with 4.1.x and 4.2.x and wrong code with 4.3.x and 4.4.
Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-20 07:25 ---
Confirm. Thanks for the report.
R532 data-stmt-constant is ...
or null-init
R507 null-init is function-reference
C506 (R507) The function-reference shall be a reference to the NULL
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-20 07:26 ---
Confirm. Thanks for the report.
R532 data-stmt-constant is ...
or null-init
R507 null-init is function-reference
C506 (R507) The function-reference shall be a reference to the NULL
--- Comment #12 from burnus at gcc dot gnu dot org 2009-01-20 07:28 ---
Close as WONTFIX based on the general judgment that this is the right or at
least an acceptable solution.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-22 10:53 ---
> Thus: '(1pD24.15)' is valid
Fully agreed - that version is valid and accepted with gfortran, ifort, NAG f95
etc.
> While: '(1pD24.15e4)' is invalid
It is, but as written sunf95/open
144
--
Summary: F2003: ASSOCIATE construct
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.3 |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-24 19:41 ---
(In reply to comment #4)
> After adding the the missing checks to gfc_check_cshift() and
> gfc_check_eoshift() respectively, I get a couple of errors for
> gfortran.dg/zero_sized_1.f90 [...]
Thanks! The er
t: 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=38979
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-26 18:42 ---
Note: The standard does not allow this, see
http://www.openmp.org/mp-documents/spec30.pdf, page 94: Section "2.9.2
threadprivate Directive" has under "Restrictions":
"A variable can only
--- Comment #10 from burnus at gcc dot gnu dot org 2009-01-28 07:11 ---
Someone (Toon?) mentioned a plan to make the GOMP backend infrastructure usable
for shared memory. I also found the following paper: "Prototyping the automatic
generation of MPI code from OpenMP programs in GC
ong result for array(:,ny:1:-1)) as actual argument
(inverting order by negative strides)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P3
Component: fo
s: wrong-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=39030
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-05 09:07 ---
Mark as regression based on Dominique's comment.
--
burnus at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-06 10:26 ---
(In reply to comment #0)
> The same warnings are given if the arguments of ABS/MAX are of default-real
> kind, so this not related to implicit typing.
I have to admit that I don't fully understand that se
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-06 10:29 ---
NAG f95 5.1 gives the following error:
Error: line 21: Dummy proc F arg 1 has different INTENT from actual proc FUNC
arg
Error: line 21: Incompatible procedure argument for F (no. 2) of A
After fixing this (intent
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-06 14:28 ---
> Btw, adding "REAL ABS,MAX" doesn't help either, so it's not related to the
> function's types.
Well, exactly that should trigger the warning! Thus it shall not help silencing
the war
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-06 14:39 ---
Regarding the segfault, valgrind shows:
==14376== Invalid read of size 1
==14376==by 0x616A4F7: fprintf (in /lib64/libc-2.9.so)
==14376==by 0x4B4BF1: show_typebound (dump-parse-tree.c:693)
The line is
e-on-valid-code
Severity: normal
Priority: P3
Component: libgomp
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=40047
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|unknown |4.5.0
http
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-06 15:45 ---
Subject: Bug 40041
Author: burnus
Date: Wed May 6 15:44:18 2009
New Revision: 147183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147183
Log:
2009-05-06 Tobias Burnus
PR fortr
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-06 15:46 ---
FIXED on the trunk (4.5). Thanks for reporting it.
Crossref: The warning was added by Daniel Franke with Rev. 126153 for PR 20373.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-06 16:40 ---
(In reply to comment #2)
> The GDB patch now assembles the symbol name from its parent DW_TAG_module as
> `__modulename_MOD_varname'. As GDB also has to know the C++ mangling rules I
> believe this Fo
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-07 08:07 ---
In the standard:
R602 variable is designator
or expr
C602 (R602) expr shall be a reference to a function that has a pointer
result."
Which can then be used in assig
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-07 14:39 ---
Confirmed. I need to understand what MIPS_DEBUGGING_INFO means - and why it is
not present in 4.4 - but maybe reverting it and suggesting in PR fortran/39791
to use 4.4/4.5 is be safer/better alternative. - Thanks
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-07 14:51 ---
Stupid but working fix: Reverting the patch for PR 39791 on MIPS_DEBUGGING_INFO
only. I think that's the safest to do - even if it is not the most elegant way
of doing it. I don't like backporting Rev. 13
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-08 11:25 ---
> > As a matter of curiosity, do other compilers catch this?
> Intel does not.
Sure? If I look at the assembler of ifort 11.1 with -O3, I only see:
call __intel_new_
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-11 08:07 ---
Without heavily thinking about it:
> print *,public_var_with_private_type%i
Seems to be valid in Fortran 2003 (but not in 2003). The components are not
PRIVATE and thus accessibly, even if the TYPE declaration
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-11 09:17 ---
The patch caused a regression, see PR 40061
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39791
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-11 10:20 ---
> && !gfc_check_access (c->ts.derived->attr.access,
> c->ts.derived->ns->default_access))
> {
> - gfc_notify_std (GFC_STD_
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-11 22:56 ---
Now tracked as official Interpretation Request.
Request: http://www.j3-fortran.org/doc/year/09/09-236.txt (answer = proposed
answer by me).
Submitted for: J3 MEETING 189 LAS VEGAS, NEVADA, August 10 - 14, 2009
http
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=40110
2008: Type-bound procedure: allow list after PROCEDURE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at g
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-12 19:27 ---
Subject: Bug 40061
Author: burnus
Date: Tue May 12 19:26:46 2009
New Revision: 147445
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147445
Log:
2009-05-12 Tobias Burnus
PR bootstr
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-12 19:42 ---
FIXED on the 4.3 branch. Thanks for reporting the problem and sorry for the
breakage.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-12 21:10 ---
I have a patch for this. Note, however, that the compiler - even with default
options - (too) aggressively optimizes your program, i.e. the assignment is
optimized away even with -O0 and thus for your program the
--- Comment #12 from burnus at gcc dot gnu dot org 2009-05-12 22:05 ---
Some more data:
==16952== Conditional jump or move depends on uninitialised value(s)
==16952==at 0x4470FC: write_atom (module.c:1339)
==16952==by 0x4472DD: mio_integer (module.c:1450)
==16952==by
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-12 22:43 ---
Subject: Bug 40110
Author: burnus
Date: Tue May 12 22:42:45 2009
New Revision: 147452
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147452
Log:
2009-05-12 Tobias Burnus
PR fortr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-12 22:44 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from burnus at gcc dot gnu dot org 2009-05-13 13:47 ---
For 4.4 the equivalent diff should be the following (untested). I don't see ad
hoc whether the "sfree" can be removed as well or not.
Index: libgfortra
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-13 14:53 ---
Subject: Bug 34153
Author: burnus
Date: Wed May 13 14:52:54 2009
New Revision: 147477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147477
Log:
2009-05-13 Tobias Burnus
PR fortr
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-13 16:14 ---
FIXED on the trunk (4.5). Thanks for the bug report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-14 06:28 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00163.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39352
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-15 06:53 ---
Subject: Bug 39352
Author: burnus
Date: Fri May 15 06:52:41 2009
New Revision: 147559
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147559
Log:
2009-05-15 Tobias Burnus
PR fortr
--- Comment #6 from burnus at gcc dot gnu dot org 2009-05-15 06:57 ---
Fixed on the trunk (4.5). Thanks for reporting HJ and thanks to Steve E. for
providing an initial patch, which pointed into the right direction.
--
burnus at gcc dot gnu dot org changed:
What
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-15 10:32 ---
Proc-pointer fun as written by Malcolm Cohen,
http://j3-fortran.org/pipermail/j3/2009-May/002755.html
If I understood his arguments correctly, even the following Fortran 90 program
might be affected:
module m
y
Product: gcc
Version: unknown
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=40158
: 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
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-15 20:23 ---
(In reply to comment #1)
> I disagree with you as does the F95 standard
Sorry, I cannot find anywhere in the standard that one has to emit four
warnings. First, I think that one warning for a real loop variable
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-18 06:41 ---
I can reproduce the problem with GCC 4.2.1,
but it works with 4.3.3 [gcc-4_3-branch revision 144878]. Thus it seems to be
fixed in newer 4.3 versions than your 4.3.0 2008-03-05. And it works in 4.4.x
and 4.5. Please
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-18 08:51 ---
(In reply to comment #4)
> Sorry for this useless bug report
Well, the quality of gfortran relies on bug reports. As long as the
signal-to-noise ratio does not fall too much, it is better to have one bug
invalid
--- Comment #7 from burnus at gcc dot gnu dot org 2009-05-18 16:52 ---
Issue brought up by Jakub:
do you require all equivalenced vars to be either threadprivate
or non-threadprivate?
or, does a single threadprivate var make all vars equivalenced somehow to
it threadprivate
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-18 21:12 ---
Confirm. I looked at the source code, but I don't see why it can happen, but it
does.
--
burnus at gcc dot gnu dot org changed:
What|Removed |
101 - 200 of 4285 matches
Mail list logo
