[Bug libstdc++/111353] New: bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[Bug libstdc++/111353] New: bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

            Bug ID: 111353
           Summary: bits/new_allocator.h: No such file or directory in
                    freestanding C++ toolchain
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-elf/x86_64-elf/include/c++/14.0.0/x86_64-elf/bits/c++allocator.h:33:10:
fatal error: bits/new_allocator.h: No such file or directory
   33 | #include <bits/new_allocator.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~


As I reported to wg21 before, there is no way to allocate memory in constexpr
context for freestanding. clang provides __builtin_operator_new and
__builtin_operator_delete. Maybe gcc needs that too?

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-09-09
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
https://gcc.gnu.org/bugs/

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is not a proper bug report. What are you reporting, that you get an error
for some code (what code? where is the testcase? where is the `gcc -v` output?)
or that you want a new feature to support something that isn't currently
supported?

Just pasting a compiler error with no context IS USELESS. Try harder, or just
stop bothering us with your terrible attempts at bug reports.

You can allocate memory in freestanding anyway, so what are you talking about?


#include <new>
constexpr bool f()
{
  delete new int(0);
  return true;
}
static_assert( f() );

This compiles fine with -std=c++20 -ffreestanding


Maybe you mean you can't use operator new(size_t), but you didn't say that,
because as usual your bug reports are terrible and force people to guess what
the problem is.

Try harder, or go away.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
what i am talking about is uninitialized memory for later initialization like
implementing containers for example

________________________________
From: redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Saturday, September 9, 2023 9:08
To: unlvsur@live.com <unlvsur@live.com>
Subject: [Bug libstdc++/111353] bits/new_allocator.h: No such file or directory
in freestanding C++ toolchain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is not a proper bug report. What are you reporting, that you get an error
for some code (what code? where is the testcase? where is the `gcc -v` output?)
or that you want a new feature to support something that isn't currently
supported?

Just pasting a compiler error with no context IS USELESS. Try harder, or just
stop bothering us with your terrible attempts at bug reports.

You can allocate memory in freestanding anyway, so what are you talking about?


#include <new>
constexpr bool f()
{
  delete new int(0);
  return true;
}
static_assert( f() );

This compiles fine with -std=c++20 -ffreestanding


Maybe you mean you can't use operator new(size_t), but you didn't say that,
because as usual your bug reports are terrible and force people to guess what
the problem is.

Try harder, or go away.

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #3)
> what i am talking about is uninitialized memory for later initialization
> like implementing containers for example

So then say that, don't show an expected error message about a file that is
intentionally not present in freestanding.

Not a bug, this is by design, it's how the current versions of C++ are supposed
to work, whether you like it or not.

There is already bug reports suggesting that __builtin_operator_new would be
useful (although I'm unconvinced it should be usable in freestanding, since
::operator new(size_t) isn't usable in freestanding). This PR adds nothing
useful.


> ________________________________
> From: redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>

Do you really need to quote the full history when you reply?

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
It's evident that there's a flaw in the standard, making it impossible to
allocate uninitialized memory for freestanding environments. That's precisely
why I reported it as a potential issue for future proposals. Unfortunately,
some individuals, including yourself, mistook my intent for trolling. The truth
is, we can't have features that rely on compiler magic to be implemented by
users; this necessitates reporting it as a Defect Report (DR) to WG21.

While std::addressof still had a workaround via __builtin_addressof, you're
currently left without such an alternative.

Perhaps it would be beneficial for the standard to introduce specialized
functions like constexpr_allocate_at and constexpr_deallocate_at, similar to
construct_at. These functions could offer a constexpr-compatible means of
allocating memory without involving allocators or operator new.


see this issue:

https://github.com/microsoft/STL/issues/4002

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Defect reports to WG21 do not go to GCC's bugzilla though.

And it's not a defect, it's the intended design, working as intended and
approved by the committee. Just because you don't like it, doesn't make it a
defect. Changing it requires a proposal submission, not a DR.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And there are a number of proposals related to increasing how much of the
standard library is available for freestanding, which might eventually meet
your needs. But it would help if you stop publicly insulting the people doing
that work, complaining about their work, and generally acting like a child.