https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Mikael Morin changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Mikael Morin changed:
What|Removed |Added
CC||kimwooyoung at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Mikael Morin changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #31 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #30 from Mikael Morin ---
*** Bug 56674 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #29 from Mikael Morin ---
Author: mikael
Date: Tue Apr 14 12:23:30 2015
New Revision: 222086
URL: https://gcc.gnu.org/viewcvs?rev=222086&root=gcc&view=rev
Log:
PR fortran/56674
PR fortran/58813
PR fortran/59016
PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #28 from Mikael Morin ---
Author: mikael
Date: Tue Apr 14 09:18:15 2015
New Revision: 222078
URL: https://gcc.gnu.org/viewcvs?rev=222078&root=gcc&view=rev
Log:
PR fortran/56674
PR fortran/58813
PR fortran/59016
PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #26 from drikosev at otenet dot gr ---
Hello,
It was my impression that small changes can be accepted by FSF without a
copyright disclaimer or a copyright assignment on file, according to:
https://gcc.gnu.org/contribute.html#legal
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #24 from Dominique d'Humieres ---
Created attachment 35240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35240&action=edit
Cleaned patch
I have cleaned the patch along the Mikael's comment and fixed the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #23 from Dominique d'Humieres ---
*** Bug 65469 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #22 from drikosev at otenet dot gr ---
Created attachment 35234
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35234&action=edit
cleanup if a declaration type spec is erroneous
Let's see if the function names are properly printe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #21 from drikosev at otenet dot gr ---
Created attachment 35232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35232&action=edit
cleanup if a declaration type spec is erroneous
Finally, I've sent for review to the recommended re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #20 from Dominique d'Humieres ---
> Also, I think that the additional test could be: "( m != MATCH_OK )"
I don't think so: the block in the patch will be reached for (m == MATCH_NO)
and I think this leads to the regressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #19 from drikosev at otenet dot gr ---
Ok, I'll send a patch to the recommended addresses as soon as I read the GNU
coding standards.
Yet, my impression is that perhaps the patch should be a bit more complex; in
example, I think tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #18 from Dominique d'Humieres ---
With an additional filtering on (m == MATCH_ERROR), i.e. with the following
patch, the ICEs are fixed without regression
--- ../_clean/gcc/fortran/decl.c2015-03-25 14:07:04.0 +0100
+++ gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #17 from Dominique d'Humieres ---
I have forgotten to give a sample of the failing tests with the patch in
comment 15:
FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=single -O2 -latomic
(test for excess errors)
FAIL: gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #16 from Dominique d'Humieres ---
> As it seems the problem with the program bug.f90 is that the generic
> attribute is set in a symbol as the parser tries to match a declaration
> type specification; but finally, the statement isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #15 from drikosev at otenet dot gr ---
Created attachment 35230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35230&action=edit
altered patch for the regressions reported in comment 11
Hi,
As it seems the problem with the prog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #14 from drikosev at otenet dot gr ---
Indeed, the new patch in comment 10 does not prevent the ICEs with the the
first example bug.f90 (in Description before comment 1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #13 from drikosev at otenet dot gr ---
Hi Dominiq,
The new patch (gcc-4.8.4) worked as the older one but since the locus is
corrupted I'm not surprised that a test case you tried failed. Could you post
it here please?
The corrupted l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Dominique d'Humieres changed:
What|Removed |Added
CC||daniel.price at monash dot edu
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #11 from Dominique d'Humieres ---
> In a slightly altered patched, I've added a precondition which examines
> first the locus of the current symbol and finally the error reported seems
> to comply with the testsuites.
Indeed, however
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #10 from drikosev at otenet dot gr ---
Created attachment 35226
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35226&action=edit
altered patch for the regressions reported in comment 9
Hi Dominiq,
In a slightly altered patched,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #9 from Dominique d'Humieres ---
I have tested on trunk (5.0) the following variant
--- ../_clean/gcc/fortran/interface.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/interface.c2015-03-30 10:05:08.0 +0200
@@ -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #8 from drikosev at otenet dot gr ---
When gfortran reports the error, it expects that the name 'atomic_kind_type' is
likely a procedure or function; but the syntax of the access-stmt is:
access-stmt ::= access-spec [ [ :: ] access-i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #7 from drikosev at otenet dot gr ---
Hi,
The reduced test case which has been posted by janus (comment 1) crashes also
4.8.4 and gcc 5.0 (the latter was copied from trunc a few days ago).
The backtrace I get agrees with that of Domi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
drikosev at otenet dot gr changed:
What|Removed |Added
CC||drikosev at otenet dot gr
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2013-11-17 00:00:00 |2014-12-6
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #4 from Dominique d'Humieres ---
Backtrace is
Program received signal SIGSEGV, Segmentation fault.
error_print(const char *, const char *, typedef __va_list_tag __va_list_tag *)
(type=, format0=, argp=)
at ../../work/gcc/fortran/e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #3 from Dominique d'Humieres ---
With the test in comment 1, I get on x86_64-apple-darwin13:
TYPE(atomic_kind_type), pointer :: atomic_kind
1
Error: Derived type 'atomic_kind_type' at (1) is being used be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
32 matches
Mail list logo
