https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361
--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to janus from comment #16)
> This seems to be sufficient to fix the runtime error on the reduced test
> case in comment #13:
And it also does the trick for PR 67505 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361
--- Comment #16 from janus at gcc dot gnu.org ---
This seems to be sufficient to fix the runtime error on the reduced test case
in comment #13:
Index: gcc/fortran/class.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046
--- Comment #6 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Apr 10 20:28:23 2017
New Revision: 246823
URL: https://gcc.gnu.org/viewcvs?rev=246823=gcc=rev
Log:
2017-04-10 Janus Weil <ja...@gcc.gnu.org>
PR fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79553
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||compile-time-hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80291
--- Comment #6 from janus at gcc dot gnu.org ---
Here is a slightly further reduced version of the test case:
module test
implicit none
type cell_t
contains
procedure :: get_mask
end type
contains
elemental logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80291
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> I'm currently regtesting a draft patch ...
After regtesting completed successfully, it was posted for review here:
https://gcc.gnu.org/ml/fortran/2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
Known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from janus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #29 from janus at gcc dot gnu.org ---
AFAICS r246546 should fully fix this PR, so I think it can be closed. Do you
agree, Jerry?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #28 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Mar 28 17:01:05 2017
New Revision: 246546
URL: https://gcc.gnu.org/viewcvs?rev=246546=gcc=rev
Log:
2017-03-28 Janus Weil <ja...@gcc.gnu.org>
PR fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> Janus, the fix for this bug depends on your patch for pr78661. I would like
> to incorporate yours into the solution to this PR if ok with you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #25 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #24)
> I dont think the parent is suppose to emit the Object name. What if there
> are multiple components?
Huh, I'm not sure. But your sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #22 from janus at gcc dot gnu.org ---
(In reply to janus from comment #21)
> The testcase seems to be working properly by now, but unfortunately the
> patch breaks dtio_25.f90 (execution test), i.e. the test case from PR 78854.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #21 from janus at gcc dot gnu.org ---
Created attachment 40953
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40953=edit
rebased patch
Here is the rebased patch. There was one conflict in libgfortran/io/write.c.
The testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #20 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #19)
> > Here is an updated patch, which fixes all wrong-code issues AFAICS. It
> > includes improved handling of CLASS-vs-TYPE variables (ana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #13)
> Author: jakub
> Date: Sat Feb 25 10:17:31 2017
> New Revision: 245735
Works like a charm. Thanks for fixing! :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[5/6/7 Regression] ICE |[5/6/7 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79426
--- Comment #3 from janus at gcc dot gnu.org ---
Reduced test case ...
subroutine gruppe
implicit none
type :: CGruppe
class(*), dimension(:), pointer :: el
end type
type(CGruppe) :: group
select type ( p => group%e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to janus from comment #9)
> But at least clang 3.9 has some additional diagnostics:
>
> null_ref.cpp:11:5: warning: binding dereferenced null pointer to reference
> h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572
--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to Richard Biener from comment #8)
> Btw, clang behaves the same:
True. But at least clang 3.9 has some additional diagnostics:
null_ref.cpp:11:5: warning: binding dereferenced n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #2)
> You can use -fno-delete-null-pointer-checks as a workaround for this issue.
Thanks for the comment, that's very helpful.
> But
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
Please consider this simple piece of code:
#include
void f(const int ) {
if ()
std::cout << iref << std::endl;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Will check if enabling bootstrap solves the problem.
Actually this does not seem to be the case. I still see the error with the
following GCC build (on Ubu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> I'm configuring with:
>
> --program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu --with-arch=haswell -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #4)
> The preprocessed source doesn't ICE for me neither.
Huh, I guess then the problem is with me not doing a full bootstrap. I'm
configur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #3 from janus at gcc dot gnu.org ---
Created attachment 40689
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40689=edit
preprocessed source
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
Consider the following reduced test case:
#include
#include
float build(float x) {
std::shared_ptr itNodes;
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to janus from comment #15)
> r243479 shows no runtime error, r243480 does.
The dump with r243479 is identical to 6.2. So r243480 does actually improve the
situation, but fails to han
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to janus from comment #12)
> r243483:
> 2016-12-09 Janus Weil <ja...@gcc.gnu.org>
>
> PR fortran/61767
> * class.c (has_finalizer_component): Fix th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
> The problem seems located to the file evaluators_uti.f90 and occurred
> between revisions r243430 (2016-12-08, OK) and r243621 (2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Another variant, which removes the naming collision (and dimension
> attribute) in the character components, in order to make things clearer:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Or maybe we should rather call the finalization wrapper for the type
> 'data_t'
That's also what's happening to 'par_real' in the followin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
--- Comment #8 from janus at gcc dot gnu.org ---
Another variant, which removes the naming collision (and dimension attribute)
in the character components, in order to make things clearer:
program main_ut
implicit none
type :: data_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Known to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79229
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781
--- Comment #13 from janus at gcc dot gnu.org ---
Also the dump for comment 1 looks ok on trunk, showing the correct
initialization for the c_ptr variable:
{
void * c_ptr.1;
c_ptr.1 = 0B;
dsfmt_t.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> It seems like the first character is being swallowed somewhere ...
Moreover the EOF is supposed to be an EOR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #1 from janus at gcc dot gnu.org ---
It seems that this problem not only appears when reading from internal units,
but also from std input:
module t_m
implicit none
type, public :: t
character(len=:), allocatable
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
From
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/706063:
module t_m
use, intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|diagnostic |
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
janus at gcc dot gnu.org changed:
What|Removed |Added
Attachment #40357|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #4 from janus at gcc dot gnu.org ---
Another starting point could be the fact that DTIO procedures appear to work
well on internal units, as long as no namelist output is involved. This case
seems to be handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #2 from janus at gcc dot gnu.org ---
I'm afraid I have too little knowledge of the I/O parts of libgfortran to fix,
but I can at least give some pointers to where things appear to go wrong ...
In the function "nml_write_obj&quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Dec 19 10:26:04 2016
New Revision: 243794
URL: https://gcc.gnu.org/viewcvs?rev=243794=gcc=rev
Log:
2016-12-19 Janus Weil <ja...@gcc.gnu.org>
PR fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
CC
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
Found when working on PR78661:
MODULE m
IMPLICIT NONE
TYPE :: t
CHARACTER :: c
CONTAINS
PROCEDURE :: write_formatted
GENERIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659
--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #10)
> Agree, I will look further Janus, unless you are digging into it already?
I'm currently looking into PR 78661. Would be great if you could take c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
--- Comment #9 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Dec 18 13:22:13 2016
New Revision: 243784
URL: https://gcc.gnu.org/viewcvs?rev=243784=gcc=rev
Log:
2016-12-18 Janus Weil <ja...@gcc.gnu.org>
PR fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78592
--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Dec 18 11:03:41 2016
New Revision: 243783
URL: https://gcc.gnu.org/viewcvs?rev=243783=gcc=rev
Log:
2016-12-18 Janus Weil <ja...@gcc.gnu.org>
PR fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
--- Comment #8 from janus at gcc dot gnu.org ---
Created attachment 40361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40361=edit
patch
The attached patch implements what I think needs to happen (and regtests
cleanly).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[OOP] ICE on writing CLASS |[7 Regression] [OOP] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
--- Comment #5 from janus at gcc dot gnu.org ---
BTW, I suspect the ICE might be a regression introduced by r243609 (my fix for
PR 78737).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
--- Comment #4 from janus at gcc dot gnu.org ---
Sorry, actually the example in comment 3 only ICEs if the type-binding of the
DTIO is commented out:
module m
type :: t
integer :: i
contains
! procedure :: wf
! generic :: write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #16)
> I suppose that one would have to set up the namelist or the input
> stream to determine what the dynamic type is, have th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78848
--- Comment #1 from janus at gcc dot gnu.org ---
Also one can wonder what kind of code should be generated here.
When using the type-bound form of the DTIO procedure, we generate a truly
polymorphic reference to the DTIO procedure when printing
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
Here is a variant of a testcase posted by Mikael at
https://gcc.gnu.org/ml/fortran/2016-12/msg00232.html:
module m
type :: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #13)
> Why do you think that both input and output is required?
Don't know. My intuitive reaction was that comment 5 should be valid, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to janus from comment #10)
> The attached patch seems to make the original comment 0 as well as the
> polymorphic version in comment 7 work. Regtesting now ...
Regtesting was succ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78239
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #10 from janus at gcc dot gnu.org ---
Created attachment 40357
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40357=edit
draft patch
The attached patch seems to make the original comment 0 as well as the
polymorphic vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
janus at gcc dot gnu.org changed:
What|Removed |Added
Assignee|jvdelisle at gcc dot gnu.org |janus at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #8 from janus at gcc dot gnu.org ---
This patch seems to produce the correct dump for the example in comment 7:
Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #7 from janus at gcc dot gnu.org ---
So, here is a corrected test for the polymorphic case:
MODULE m
IMPLICIT NONE
TYPE :: t
CHARACTER :: c
CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Btw, this variant is wrongly rejected:
>
> [..]
>
>NAMELIST /nml/ x
>1
> Error: NAMELIST object ‘x’ in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[cleanup] replace static|[cleanup] replace static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691
janus at gcc dot gnu.org changed:
What|Removed |Added
Known to work|6.2.0, 7.0 |
Target Milestone|6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #5 from janus at gcc dot gnu.org ---
Btw, this variant is wrongly rejected:
MODULE m
IMPLICIT NONE
TYPE :: t
CHARACTER :: c
CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #4 from janus at gcc dot gnu.org ---
I think this should fix it:
Index: libgfortran/io/write.c
===
--- libgfortran/io/write.c (revision 243729)
+++ libgfortran/io
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #3 from janus at gcc dot gnu.org ---
Reduced test case:
MODULE m
IMPLICIT NONE
TYPE :: t
CHARACTER :: c
CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
END TYPE
CONTA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #18 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #17)
> There are several PRs open for translation: pr52274 and links.
Thanks of the hint. I think in particular PR 38573 is relevant for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #15)
> Some comments:
Thanks!
> 1) this still doesn't solve the translations issue in many places
> (gfc_compare_interfaces etc.);
True. I do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #14 from janus at gcc dot gnu.org ---
Created attachment 40350
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40350=edit
patch using build_message_string
So here is another patch, similar to the one in comment 5, but us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #13 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> BTW, yet another option (and I'd say much more readable) is just using
> build_message_string function
Yes, I think that's a good suggestion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
> best discuss this on the
> mailing list rather than in the PR where others can more easily see it and
> comment on it.
Agreed. Will do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78737
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #8 from janus at gcc dot gnu.org ---
In general, doesn't this whole memory issue severely limit the usefulness of
C++ as an implementation language for GCC? It seems to imply that we cannot use
*any* STL containers? Or do I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> Dunno, you can perhaps try it (put a breakpoint somewhere before you
> construct the std::string, when you reach it, put a breakpoint on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #5 from janus at gcc dot gnu.org ---
Created attachment 40346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40346=edit
draft patch
Here is a draft patch that implements what I had in mind (regtests cleanly).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> I don't know what exactly you want to clean up with std::string
Well, my main motivation was to get rid of some statically-sized buffers (u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> You would need to make sure it uses a xmalloc based allocator first or at
> least calls xmalloc_failed upon allocation failure, oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798
--- Comment #5 from janus at gcc dot gnu.org ---
Looking through gfortran.h, some more candidates which could be converted:
int gfc_at_end (void);
int gfc_at_eof (void);
int gfc_at_bol (void);
int gfc_at_eol (void);
int gfc_check_include (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798
--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Dec 15 20:54:18 2016
New Revision: 243726
URL: https://gcc.gnu.org/viewcvs?rev=243726=gcc=rev
Log:
2016-12-15 Janus Weil <ja...@gcc.gnu.org>
PR fortran
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
Several functions in interface.c use static-size char buffers for constructing
error messages, e.g.:
* gfc_compare_interfaces
* gfc_check_result_characteristics
601 - 700 of 3414 matches
Mail list logo
