public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/113398] New: <string> no longer usable with -ffreestanding
@ 2024-01-15 13:10 redi at gcc dot gnu.org
2024-01-15 13:12 ` [Bug libstdc++/113398] " redi at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2024-01-15 13:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113398
Bug ID: 113398
Summary: <string> no longer usable with -ffreestanding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This used to work with GCC 12 when compiled with -ffreestanding
#include <string>
// Defined by the user.
void* operator new(std::size_t n);
void operator delete(void*, std::size_t n);
int main()
{
std::string s = "a string that needs to allocate from the heap";
return s.size();
}
Since GCC 13 the -ffreestanding option also selects a freestanding libstdc++,
which doesn't allow std::string to be used.
The change was done intentionally, to provide a more clearly defined and
documented freestanding library, but it removes functionality that was being
used.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/113398] <string> no longer usable with -ffreestanding
2024-01-15 13:10 [Bug libstdc++/113398] New: <string> no longer usable with -ffreestanding redi at gcc dot gnu.org
@ 2024-01-15 13:12 ` redi at gcc dot gnu.org
2024-01-15 14:06 ` redi at gcc dot gnu.org
2024-01-24 3:42 ` hp at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2024-01-15 13:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113398
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In file included from /home/jwakely/gcc/13/include/c++/13.2.1/string:38,
from free.cc:1:
/home/jwakely/gcc/13/include/c++/13.2.1/bits/requires_hosted.h:34:4: error:
#error "This header is not available in freestanding mode."
34 | # error "This header is not available in freestanding mode."
| ^~~~~
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/113398] <string> no longer usable with -ffreestanding
2024-01-15 13:10 [Bug libstdc++/113398] New: <string> no longer usable with -ffreestanding redi at gcc dot gnu.org
2024-01-15 13:12 ` [Bug libstdc++/113398] " redi at gcc dot gnu.org
@ 2024-01-15 14:06 ` redi at gcc dot gnu.org
2024-01-24 3:42 ` hp at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2024-01-15 14:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113398
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arsen at gcc dot gnu.org
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We could consider a macro that disables the <bits/require_hosted.h> error,
which would mean "give me the full library even if it might not work, give it
to me straight, like a pear cider that's made from 100% pears".
For std::string we're still missing std::allocator (in gcc-13 but not trunk),
several of the __throw_xxx functions, and the strtol, strtof etc. functions
used for std::stoi, std::stof etc.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/113398] <string> no longer usable with -ffreestanding
2024-01-15 13:10 [Bug libstdc++/113398] New: <string> no longer usable with -ffreestanding redi at gcc dot gnu.org
2024-01-15 13:12 ` [Bug libstdc++/113398] " redi at gcc dot gnu.org
2024-01-15 14:06 ` redi at gcc dot gnu.org
@ 2024-01-24 3:42 ` hp at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: hp at gcc dot gnu.org @ 2024-01-24 3:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113398
Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hp at gcc dot gnu.org
--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Huh! I found this out the hard way, and thought it was just another
clang++/gcc incompatibility; I had no idea it was this "recent". Cf.
https://github.com/ARM-software/ethos-n-driver-stack (at the moment compiling
only with ARMs clang-derivate).
The code under firmware/control_unit there (targetting a cortex-m7) uses
-ffreestanding (the clang option) but makes use of <string> enough to "break"
it.
FWIW, hacking off the --freestanding for gcc works as long as you also set up
enough of a "hosted" environment. (There's also firmware/ple for a cortex-m33,
but that code is truly freestanding AFAIU - except for using main.)
Interesting that it "worked" with gcc-12. I cooked up something with a recent
gcc+binutils+newlib though.
Just an example of live freestanding code out there, using <string>, right or
wrong.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-01-24 3:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-15 13:10 [Bug libstdc++/113398] New: <string> no longer usable with -ffreestanding redi at gcc dot gnu.org
2024-01-15 13:12 ` [Bug libstdc++/113398] " redi at gcc dot gnu.org
2024-01-15 14:06 ` redi at gcc dot gnu.org
2024-01-24 3:42 ` hp at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).