Re: RFC: Introduce -fhardened to enable security-related flags

Hans-Peter Nilsson writes: >> From: Sam James >> Date: Sun, 17 Sep 2023 05:00:37 +0100 > >> Hans-Peter Nilsson via Gcc-patches writes: >> >> >> Date: Tue, 29 Aug 2023 15:42:27 -0400 >> >> From: Marek Polacek via Gcc-patches >> > >> >> Surely, there must be no ABI impact, the option cannot

Re: RFC: Introduce -fhardened to enable security-related flags

Hans-Peter Nilsson via Gcc-patches writes: >> Date: Tue, 29 Aug 2023 15:42:27 -0400 >> From: Marek Polacek via Gcc-patches > >> Surely, there must be no ABI impact, the option cannot cause >> severe performance issues, > >> Currently, -fhardened enables: > ... >>

Re: [PATCH] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11 [PR 111050]

François Dumont via Gcc-patches writes: > Following confirmation of the fix by TC here is the patch where I'm > simply adding a 'constexpr' on _M_next(). > > Please let me know this ChangeLog entry is correct. I would prefer > this patch to be assigned to 'TC' with me as co-author but I don't

Re: [PATCH] LoongArch: Fix unintentional bash-ism in r14-3665.

Yang Yujie writes: > gcc/ChangeLog: > > * config.gcc: remove non-POSIX syntax "<<<". > --- Thanks, I was just about to report this. > gcc/config.gcc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/config.gcc b/gcc/config.gcc > index

Re: RFC: Introduce -fhardened to enable security-related flags

Marek Polacek via Gcc-patches writes: > Improving the security of software has been a major trend in the recent > years. Fortunately, GCC offers a wide variety of flags that enable extra > hardening. These flags aren't enabled by default, though. And since > there are a lot of hardening

Re: [PATCH] Add clang's invalid-noreturn warning flag

Julian Waters via Gcc-patches writes: > Anyone? Please see https://gcc.gnu.org/contribute.html#patches, specifically the "Pinging patches, Getting patches applied" section.

Re: [PATCH] Collect both user and kernel events for autofdo tests and autoprofiledbootstrap

Richard Biener via Gcc-patches writes: > On Fri, Jun 30, 2023 at 7:28 AM Eugene Rozenfeld via Gcc-patches > wrote: >> >> When we collect just user events for autofdo with lbr we get some events >> where branch >> sources are kernel addresses and branch targets are user addresses. Without >>

Re: [PATCH] c++: provide #include hint for missing includes [PR110164]

> On 15 Jun 2023, at 12:54, David Malcolm wrote: > > On Thu, 2023-06-15 at 01:43 +0100, Sam James wrote: >> >> Eric Gallager via Gcc-patches writes: >> >>> On Wed, Jun 14, 2023 at 8:29 PM David Malcolm via Gcc-patches >>> wrote: PR c++/110164 notes that in cases where we have

Re: [PATCH] c++: provide #include hint for missing includes [PR110164]

Eric Gallager via Gcc-patches writes: > On Wed, Jun 14, 2023 at 8:29 PM David Malcolm via Gcc-patches > wrote: >> >> PR c++/110164 notes that in cases where we have a forward decl >> of a std library type such as: >> >> std::array x; >> >> we omit this diagnostic: >> >> error: aggregate

Re: [PATCH] Turn on LRA on all targets

"Maciej W. Rozycki" writes: > On Sun, 23 Apr 2023, Segher Boessenkool wrote: > >> > There are extra ICEs in regression testing and code quality is poor; cf. >> > . >> >> Do you have something you can show for this? Maybe

Re: [PATCH] c++: NSDMI instantiation from template context [PR109506]

FWIW, we'd love to be able to backport this to GCC 13 (maybe 12, but no big deal there) in Gentoo so we can continue doing large testing builds with a lot of checking enabled, given this affects Chromium. But it's no big deal if it's too invasive. signature.asc Description: PGP signature

[PATCH v2] testsuite: Add testcase for sparc ICE [PR105573]

r11-10018-g33914983cf3734c2f8079963ba49fcc117499ef3 fixed PR105312 and added a test case for target/arm but the duplicate PR105573 has a test case for target/sparc that was uncommitted until now. 2023-04-21 Sam James PR tree-optimization/105312 PR target/105573 *

Re: [PATCH] testsuite: Add testcase for sparc ICE [PR105573]

Richard Biener writes: > On Fri, 21 Apr 2023, Sam James wrote: > >> r11-10018-g33914983cf3734c2f8079963ba49fcc117499ef3 fixed PR105312 and added >> a test case for target/arm but the duplicate PR105573 has a test case for >> target/sparc that was uncommitted until now. > > OK. But see below

[PATCH] testsuite: Add testcase for sparc ICE [PR105573]

r11-10018-g33914983cf3734c2f8079963ba49fcc117499ef3 fixed PR105312 and added a test case for target/arm but the duplicate PR105573 has a test case for target/sparc that was uncommitted until now. 2023-04-21 Sam James PR tree-optimization/105312 PR target/105573 *

Re: [PATCH v5] gcc: Drop obsolete INCLUDE_PTHREAD_H

Jeff Law writes: > On 4/2/23 15:33, Sam James wrote: >> gcc/ChangeLog: >> * system.h: Drop unused INCLUDE_PTHREAD_H. > THanks. I've pushed this to the trunk. Cheers Jeff! > jeff best, sam signature.asc Description: PGP signature

[PATCH v5] gcc: Drop obsolete INCLUDE_PTHREAD_H

INCLUDE_PTHREAD_H was added for r13-1350-g49d508065bdd36 for a calloc poisoning issue like r13-6662-g0e6f87835ccabf. When working on r13-6662-g0e6f87835ccabf, we realised that INCLUDE_PTHREAD_H became unused as of r13-4164-g0a62889c7a155f (which was originally added for r13-1350-g49d508065bdd36

Re: [PATCH v4 2/2] gcc: Drop obsolete INCLUDE_PTHREAD_H (ping)

Jeff Law writes: > On 4/2/23 14:06, Andrew Pinski wrote: >> On Sun, Apr 2, 2023 at 12:55 PM Jeff Law via Gcc-patches >> wrote: >>> >>> >>> >>> On 3/31/23 12:44, Sam James wrote: Kito Cheng writes: > It's not the RISC-V part, so this requires a global maintainer there I

Re: [PATCH v4 2/2] gcc: Drop obsolete INCLUDE_PTHREAD_H (ping)

Kito Cheng writes: > It's not the RISC-V part, so this requires a global maintainer there I think? > Someone able to look at the system.h bit? It should be trivial, there's no uses left and it was added purely for a bug like this in the past (see commit message). > On Tue, Mar 14, 2023 at

Re: [PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

>> >> On Tue, Mar 14, 2023 at 5:07 PM Richard Biener via Gcc-patches >> wrote: >> > >> > On Tue, Mar 14, 2023 at 1:24 AM Sam James via Gcc-patches >> > wrote: >> > > >> > > This fixes errors like: >> > > ``` >&

Re: [PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

Kito Cheng writes: > RISC-V part is ok, and I assume you didn't have write access so I'm > gonna push that since the system.h change also got approved :) > > On Tue, Mar 14, 2023 at 5:07 PM Richard Biener via Gcc-patches > wrote: >> >> On Tue, Mar 14, 2023 at 1:24 A

[PATCH v4 2/2] gcc: Drop obsolete INCLUDE_PTHREAD_H

This is no longer used since 0a62889c7a155f8ed971860d68870dc9c46bb004, so let's clean it up. gcc/ChangeLog: * system.h: Drop unused INCLUDE_PTHREAD_H. Signed-off-by: Sam James --- gcc/system.h | 4 1 file changed, 4 deletions(-) diff --git a/gcc/system.h b/gcc/system.h index

[PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

This fixes errors like: ``` In file included from /usr/include/pthread.h:30, from /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35, from

[PATCH v3] gcc: Drop obsolete INCLUDE_PTHREAD_H

This is no longer used since 0a62889c7a155f8ed971860d68870dc9c46bb004, so let's clean it up. gcc/ChangeLog: * system.h: Drop unused INCLUDE_PTHREAD_H. Signed-off-by: Sam James --- gcc/system.h | 4 1 file changed, 4 deletions(-) diff --git a/gcc/system.h b/gcc/system.h index

[PATCH v2] RISC-V: Avoid calloc() poisoning on musl

This fixes errors like: ``` In file included from /usr/include/pthread.h:30, from /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35, from

[PATCH] RISC-V: Avoid calloc() poisoning on musl

This fixes errors like: ``` In file included from /usr/include/pthread.h:30, from /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35, from

Re: [PATCH] maintainer-scripts/gcc_release: compress xz in parallel

> On 8 Nov 2022, at 07:14, Sam James wrote: > > 1. This should speed up decompression for folks, as parallel xz > creates a different archive which can be decompressed in parallel. > > Note that this different method is enabled by default in a new > xz release coming shortly anyway (>=

Re: [PATCH] maintainer-scripts/gcc_release: compress xz in parallel

> On 8 Nov 2022, at 07:14, Sam James wrote: > > 1. This should speed up decompression for folks, as parallel xz > creates a different archive which can be decompressed in parallel. > > Note that this different method is enabled by default in a new > xz release coming shortly anyway (>=

Re: Announcement: Porting the Docs to Sphinx - tomorrow

> On 9 Nov 2022, at 00:00, Joseph Myers wrote: > > On Tue, 8 Nov 2022, Sam James via Gcc wrote: > >> Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899) >> even for snapshots? Pretty please? :) > > I think we want snapshots to come out weekly even if the compiler or >

Re: Announcement: Porting the Docs to Sphinx - tomorrow

> On 8 Nov 2022, at 13:55, Martin Liška wrote: > > Hi. > > Tomorrow in the morning (UTC time), I'm going to migrate the documentation > to Sphinx. The final version of the branch can be seen here: > > $ git fetch origin refs/users/marxin/heads/sphinx-final > $ git co FETCH_HEAD > > URL:

Re: [PATCH] maintainer-scripts/gcc_release: compress xz in parallel

> On 8 Nov 2022, at 08:52, Jakub Jelinek wrote: > > On Tue, Nov 08, 2022 at 07:40:02AM +, Sam James wrote: >>> On 8 Nov 2022, at 07:33, Xi Ruoyao wrote: >>> I'm wondering if running xz -T0 on different machines (with different >>> core numbers) may produce different compressed data. The

Re: [PATCH] maintainer-scripts/gcc_release: compress xz in parallel

> On 8 Nov 2022, at 07:36, Sam James wrote: > > > >> On 8 Nov 2022, at 07:34, Eric Botcazou wrote: >> >>> I build GCC regularly from the weekly snapshots >>> and so the decompression time adds up. >> >> But is very largely dwarfed by the build time of the compiler, isn't it? >> > > It

Re: [PATCH] maintainer-scripts/gcc_release: compress xz in parallel

> On 8 Nov 2022, at 07:33, Xi Ruoyao wrote: > > On Tue, 2022-11-08 at 07:14 +0000, Sam James via Gcc-patches wrote: >> 1. This should speed up decompression for folks, as parallel xz >>creates a different archive which can be decompressed in parallel. >> >

Re: [PATCH] maintainer-scripts/gcc_release: compress xz in parallel

> On 8 Nov 2022, at 07:34, Eric Botcazou wrote: > >> I build GCC regularly from the weekly snapshots >> and so the decompression time adds up. > > But is very largely dwarfed by the build time of the compiler, isn't it? > It is. It's no big deal if the patch isn't accepted, it's just

[PATCH] maintainer-scripts/gcc_release: compress xz in parallel

1. This should speed up decompression for folks, as parallel xz creates a different archive which can be decompressed in parallel. Note that this different method is enabled by default in a new xz release coming shortly anyway (>= 5.3.3_alpha1). I build GCC regularly from the weekly