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).