https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #20 from Pedro Alves ---
And in addition, since GCC is already using new/new[] to heap allocate its own
classes, GCC is _already_ inconsistent with allocation failure -- if one of
those currently fails, you'll end up with a C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
Pedro Alves changed:
What|Removed |Added
CC||palves at redhat dot com
--- Comment #19
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 our
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #17 from Dominique d'Humieres ---
There are several PRs open for translation: pr52274 and links.
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 don't wanna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #15 from Jakub Jelinek ---
Comment on attachment 40350
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40350
patch using build_message_string
Some comments:
1) this still doesn't solve the translations issue in many places
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 using
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. Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #12 from Jakub Jelinek ---
Oh, and yet another thing, if these messages is something you pass to the user,
then the fact that you mix up the diagnostic text with expanded arguments
precludes translation. With using std::stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #11 from Jakub Jelinek ---
BTW, yet another option (and I'd say much more readable) is just using
build_message_string function, so
snprintf (errmsg, err_len, "Rank mismatch in argument '%s' (%i/%i)",
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=78822
--- Comment #9 from Jakub Jelinek ---
(In reply to janus from comment #8)
> 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*
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 malloc and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #6 from Jakub Jelinek ---
Comment on attachment 40346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40346
draft patch
Dunno, you can perhaps try it (put a breakpoint somewhere before you construct
the std::string, when you
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 (used
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #3 from Jakub Jelinek ---
I have no idea what the Go FE is doing, in the middle-end there are indeed 3-4
spots that use std::string in one file, but I'd just call it a mistake.
The reason for ensuring xmalloc_failed is used is to get
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, otherwise it will be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
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|
21 matches
Mail list logo
