* [Bug c++/106241] compiler can't handle large array of strings
2022-07-09 11:33 [Bug c++/106241] New: compiler can't handle large array of strings robert.durkacz at gmail dot com
@ 2022-07-09 11:55 ` schwab@linux-m68k.org
2022-07-09 16:20 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: schwab@linux-m68k.org @ 2022-07-09 11:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
That's the OOM killer.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/106241] compiler can't handle large array of strings
2022-07-09 11:33 [Bug c++/106241] New: compiler can't handle large array of strings robert.durkacz at gmail dot com
2022-07-09 11:55 ` [Bug c++/106241] " schwab@linux-m68k.org
@ 2022-07-09 16:20 ` redi at gcc dot gnu.org
2022-07-10 1:32 ` robert.durkacz at gmail dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2022-07-09 16:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Robert Durkacz from comment #0)
> My personal interest in reporting this as a
> bug, whether it is or not, is to get any advice what is a better way to do
> what I am trying to do.
Get more memory, and use const char* in your structs, not std::string.
It compiles easily if you have an array with trivial types.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/106241] compiler can't handle large array of strings
2022-07-09 11:33 [Bug c++/106241] New: compiler can't handle large array of strings robert.durkacz at gmail dot com
2022-07-09 11:55 ` [Bug c++/106241] " schwab@linux-m68k.org
2022-07-09 16:20 ` redi at gcc dot gnu.org
@ 2022-07-10 1:32 ` robert.durkacz at gmail dot com
2022-07-10 9:56 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: robert.durkacz at gmail dot com @ 2022-07-10 1:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
--- Comment #3 from Robert Durkacz <robert.durkacz at gmail dot com> ---
The suggestions from Johnathon Wakely would work but it is changing the
problem. Rather than using simple types, the application is aimed at using more
elaborate types (std:multimap).
My reason for thinking that the compiler "should" be able to handle it somehow,
is that the full array or multimap can be built up at runtime by reading the
data in from a text file very similar to the source code file. So I guess the
compiler just does not address this particular kind of use case but it seems to
me that, on the contrary, there should be a compilation capability to do this
kind of thing.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/106241] compiler can't handle large array of strings
2022-07-09 11:33 [Bug c++/106241] New: compiler can't handle large array of strings robert.durkacz at gmail dot com
` (2 preceding siblings ...)
2022-07-10 1:32 ` robert.durkacz at gmail dot com
@ 2022-07-10 9:56 ` redi at gcc dot gnu.org
2022-07-10 9:59 ` robert.durkacz at gmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2022-07-10 9:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, like https://wg21.link/p1967r7
But in the meantime, you can create a static array of trivial types (not
std::string) and then iterate over it at runtime to copy the values into the
data structure you want to use (a multimap containing strings, or whatever).
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/106241] compiler can't handle large array of strings
2022-07-09 11:33 [Bug c++/106241] New: compiler can't handle large array of strings robert.durkacz at gmail dot com
` (3 preceding siblings ...)
2022-07-10 9:56 ` redi at gcc dot gnu.org
@ 2022-07-10 9:59 ` robert.durkacz at gmail dot com
2022-07-10 20:39 ` pinskia at gcc dot gnu.org
2022-07-11 11:00 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: robert.durkacz at gmail dot com @ 2022-07-10 9:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
--- Comment #5 from Robert Durkacz <robert.durkacz at gmail dot com> ---
That is a good idea.
On Sun, 10 Jul 2022 at 19:56, redi at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
>
> --- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> Yes, like https://wg21.link/p1967r7
>
> But in the meantime, you can create a static array of trivial types (not
> std::string) and then iterate over it at runtime to copy the values into
> the
> data structure you want to use (a multimap containing strings, or
> whatever).
>
> --
> You are receiving this mail because:
> You reported the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/106241] compiler can't handle large array of strings
2022-07-09 11:33 [Bug c++/106241] New: compiler can't handle large array of strings robert.durkacz at gmail dot com
` (4 preceding siblings ...)
2022-07-10 9:59 ` robert.durkacz at gmail dot com
@ 2022-07-10 20:39 ` pinskia at gcc dot gnu.org
2022-07-11 11:00 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-07-10 20:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 105838 (and there might be others).
*** This bug has been marked as a duplicate of bug 105838 ***
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/106241] compiler can't handle large array of strings
2022-07-09 11:33 [Bug c++/106241] New: compiler can't handle large array of strings robert.durkacz at gmail dot com
` (5 preceding siblings ...)
2022-07-10 20:39 ` pinskia at gcc dot gnu.org
@ 2022-07-11 11:00 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2022-07-11 11:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Robert Durkacz from comment #3)
> So I guess the compiler just does not address this particular kind of use
> case but it seems to me that, on the contrary, there should be a compilation
> capability to do this kind of thing.
The problem is that "this kind of thing" is completely unreasonable. The
element type of the array (Form_map) has a non-trivial destructor that needs to
deallocate the strings' memory. That means that the initializer for the array
compiles to code like:
try {
form_array[0] = {"ADP", {"ADP", "s{NGDAILV}|mq_"}};
try {
form_array[1] = {"ADP", {"ADP", "s{NGDAILV}|mq_"}};
try {
form_array[2] = {"ADP", {"ADP", "s{NGDAILV}|mq_"}};
// ... 5.2 million more try-catch blocks
} catch (...) {
form_array[2].~Form_map();
throw;
}
} catch (...) {
form_array[1].~Form_map();
throw;
}
} catch (...) {
form_array[0].~Form_map();
throw;
}
The code to do that 5.2 million times is not easy to compile. And it's not
really a sensible thing to try to compile. Just because all the construction
and destruction is hidden inside std::string ctors and dtors doesn't make it a
good idea. You're still asking for all that work to be done in a global
initializer before main() even starts.
Creating a trivial type that just holds a const char* is easy, there is no
allocation, no non-trivial destructor, so no exceptions possible and so nothing
needs to be caught or rethrown.
^ permalink raw reply [flat|nested] 8+ messages in thread