Tested with gcc 14.2 and the Linux kernel compiling for amd64. This is
at Linux next-20241127. This was already the case on gcc 13 (no idea
about earlier versions), I tested 14 to see if the problem is gone.
In the particular case I ran into a prediction concerning the return
value of __access_ok
Dear GCC Gurus,
We are compiling a GCC using "pre-existing" GCC and
we want to have control over the order of the system directories that are
searched
particularly we want /usr/include to be searched before others. We are not
in a position to keep adding -I/usr/include to our build scripts.
> On 11/24/24 11:49 AM, Bradley M. Kuhn wrote:
> > One size doesn't necessarily fit all. Perhaps if you're changing the DCO
> > text for the toolchain projects at this moment, it might be a good time to
> > consider if the Linux DCO text suits your project perfectly.
Carlos O'Donell wrote:
> This
On Thu, 2024-11-28 at 03:56 +, Sam James wrote:
> David Malcolm via Gcc writes:
>
> > I merged libdiagnostics to GCC trunk on Monday:
> > https://gcc.gnu.org/wiki/libdiagnostics
> >
> > Unfortunately I've since discovered there's at least one
> > libdiagnostics
> > .so already in Debian:
>
Snapshot gcc-13-20241129 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20241129/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 11/24/24 11:49 AM, Bradley M. Kuhn wrote:
> One size doesn't necessarily fit all. Perhaps if you're changing the DCO
> text for the toolchain projects at this moment, it might be a good time to
> consider if the Linux DCO text suits your project perfectly.
This is not a change of the DCO text.
