[gcc r15-2388] testsuite: fix PR111613 test

https://gcc.gnu.org/g:5e5d7a88932b132437069f716160f8b20862890b commit r15-2388-g5e5d7a88932b132437069f716160f8b20862890b Author: Sam James Date: Mon Jul 29 21:47:16 2024 +0100 testsuite: fix PR111613 test PR ipa/111613 * gcc.c-torture/pr111613.c: Rename to..

[gcc r15-2383] testsuite: make PR115277 test an execute one

https://gcc.gnu.org/g:ca255ca2760a5e6176031ea62a9c29c7bb92c212 commit r15-2383-gca255ca2760a5e6176031ea62a9c29c7bb92c212 Author: Sam James Date: Mon Jul 29 16:47:09 2024 +0100 testsuite: make PR115277 test an execute one PR middle-end/115277 *

[gcc r15-2371] testsuite: fix dg-add-options vs. dg-options ordering

https://gcc.gnu.org/g:542e3c4f0551f9a239163d09d98527d8d7d0200d commit r15-2371-g542e3c4f0551f9a239163d09d98527d8d7d0200d Author: Sam James Date: Sat Jul 27 00:31:54 2024 +0100 testsuite: fix dg-add-options vs. dg-options ordering Per gccint, dg-add-options must be placed after

[gcc r15-2370] testsuite: fix dg-do ordering wrt dg-require-*

https://gcc.gnu.org/g:0ac0e640a7f86ba45b7e13ed018826177197f3ce commit r15-2370-g0ac0e640a7f86ba45b7e13ed018826177197f3ce Author: Sam James Date: Sat Jul 27 00:17:03 2024 +0100 testsuite: fix dg-do ordering wrt dg-require-* Per gccint, dg-do must precede

[gcc r15-2349] testsuite: Add dg-do run to even more tests

https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used

[gcc r15-2338] MAINTAINERS: Add myself to write after approval

https://gcc.gnu.org/g:7ad6b912d9ebd1f85afb725c8de05b27a97674ea commit r15-2338-g7ad6b912d9ebd1f85afb725c8de05b27a97674ea Author: Sam James Date: Fri Jul 26 16:57:42 2024 +0100 MAINTAINERS: Add myself to write after approval ChangeLog: * MAINTAINERS: Add myself.

Re: [Linaro-TCWG-CI] gcc-15-2165-g01c095ab77f8: FAIL: 1 regressions on arm

FAIL: gcc.dg/pr116003.c (test for excess errors) Excess errors: /home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/pr116003.c:4:1: sorry, unimplemented: '_BitInt(5)' is not supported on this target

Re: master branch: commit r15-2116 failed to bootstrap on Linux/x86_64 (commit r15-2111 builds)!

Hi! For future reports, would it be possible to change the grep to something like: grep -E "(error:|Error)" or just grep -rsin "error" -w or something. This would allow catching the actual compile error in libbacktrace if it's not going to fit in the last N lines from make. (Not needed here

Re: master branch: commit r15-2116 failed to bootstrap on Linux/x86_64 (commit r15-2111 builds)!

Hi! For future reports, would it be possible to change the grep to something like: grep -E "(error:|Error)" or just grep -rsin "error" -w or something. This would allow catching the actual compile error in libbacktrace if it's not going to fit in the last N lines from make. (Not needed here

Re: [RFC] MAINTAINERS: require a BZ account field

Richard Sandiford writes: > Sam James writes: >> Richard Sandiford writes: >> >>> Sam James via Gcc writes: >>>> Hi! >>>> >>>> This comes up in #gcc on IRC every so often, so finally >>>> writing an RFC. >>>>

Re: [RFC] MAINTAINERS: require a BZ account field

Richard Sandiford writes: > Sam James via Gcc writes: >> Hi! >> >> This comes up in #gcc on IRC every so often, so finally >> writing an RFC. >> > [...] >> TL;DR: The proposal is: >> >> 1) MAINTAINERS should list a field containing either t

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Jonathan Wakely via Gcc writes: > On Fri, 5 Jul 2024 at 17:02, Xi Ruoyao via Gcc wrote: >> >> On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote: >> > At least, I hope there's consensus that while current GCC doesn't warn >> > about this, ideally it should, which means it should warn

Re: [RFC] MAINTAINERS: require a BZ account field

Sam James via Gcc writes: > Gerald Pfeifer writes: > >> On Mon, 24 Jun 2024, Jonathan Wakely via Gcc wrote: >>>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org >>>> email in full, or their gcc username (bikeshedding semi-welcome); >&g

Re: [RFC] MAINTAINERS: require a BZ account field

Gerald Pfeifer writes: > On Wed, 3 Jul 2024, Sam James wrote: >>> Now, a bigger question: Why would anyone need to know my gcc.gnu.org >>> username (or e-mail address) in the Bugzilla context? >> Isn't it answered in the original proposal? It makes CCing the committer >> of a bisect result

Re: [RFC] MAINTAINERS: require a BZ account field

Gerald Pfeifer writes: > On Mon, 24 Jun 2024, Jonathan Wakely via Gcc wrote: >>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org >>> email in full, or their gcc username (bikeshedding semi-welcome); >> I like the proposal. I'd say it should be fine to just put the gcc >>

Re: [RFC] MAINTAINERS: require a BZ account field

"Richard Earnshaw (lists)" writes: > On 24/06/2024 22:34, Sam James via Gcc wrote: >> Hi! >> >> This comes up in #gcc on IRC every so often, so finally >> writing an RFC. >> >> What? >> --- >> >> I propose that MAINTAINERS be

Re: [RFC] MAINTAINERS: require a BZ account field

Arsen Arsenović writes: > Hi, > > Richard Biener writes: > >> [snip] >>> I was also proposing (and would like to re-air that here) enforcing >>> that the committer field of each commit is a (valid) @gcc.gnu.org >>> email. This can be configured repo-locally via: >>> >>> $ git config

[RFC] MAINTAINERS: require a BZ account field

Hi! This comes up in #gcc on IRC every so often, so finally writing an RFC. What? --- I propose that MAINTAINERS be modified to be of the form, adding an extra field for their GCC/sourceware account: Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org Further,

Re: Building libgccjit with -fno-semantic-interposition? ( was Re: 1.76% performance loss in VRP due to inlining)

Andrea Corallo via Gcc writes: >> FWIW I've no idea if any libgccjit users are using semantic >> interposition; I suspect the answer is "no one is using it". >> >> Antoyo, Andrea [also CCed]: are either of you using semantic >> interposition of symbols within libgccjit? > > Hi David, > > AFAIU

Re: What is the purpose of these two fixincludes?

Andi Kleen via Gcc writes: > FX Coudert via Gcc writes: > >> Hi, >> >> I am trying to reduce the number of unneeded fixincludes that are used >> on darwin (because fixincluded headers make it impossible to change >> SDK once the compiler is built, which is common practice in the macOS >> world,

Re: Sourceware mitigating and preventing the next xz-backdoor

Paul Eggert writes: > On 4/9/24 14:58, Sam James wrote: >> Meson doesn't allow user-defined functions > > Meson has ways to execute arbitrary user-defined code, so it's not > immune to this sort of exploit. To be clear - not saying it's immune. Just that it scopes the user-defined code part to

Re: Sourceware mitigating and preventing the next xz-backdoor

Jonathon Anderson writes: > On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote: > > On 4/9/24 14:40, Jeffrey Walton wrote: > > Code provenance and code integrity was not enforced. Part of the problem is > the Autotools design. It is from a > bygone era. > > No, Andreas is right. This

Re: Sourceware mitigating and preventing the next xz-backdoor

Jonathon Anderson via Gdb writes: > On Tue, 2024-04-09 at 16:11 -0400, Paul Koning wrote: >> >> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc >> <[gcc@gcc.gnu.org](mailto:gcc@gcc.gnu.org)> wrote: >> >> > CMake has its own sandbox and rules and escapes (granted, much more of >> > them).

Re: Sourceware mitigating and preventing the next xz-backdoor

Paul Eggert writes: > On 4/9/24 14:40, Jeffrey Walton wrote: >> Code provenance and code integrity was not enforced. Part of the >> problem is the Autotools design. It is from a bygone era. > > No, Andreas is right. This isn't an Autotools-vs-Meson thing. > > Most of the Autotools-based projects

Re: Help needed with maintainer-mode

Mark Wielaard writes: > Hi Christophe, Hi Mark, Christophe, et. al, > > On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote: >> > > > And it was indeed done this way because that way the files are >> > > > regenerated in a reproducible way. Which wasn't the case when using >> > >

Re: [PATCH] libstdc++: hashtable: No need to update before begin node in _M_remove_bucket_begin

Huanghui Nie writes: > Hi. Please CC the libstdc++ LM for libstdc++ patches, per https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html#list.patches. > [...]

Re: Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

Florian Weimer via Gcc writes: > [...] > On other architectures with support for GNU2 TLS descriptors, those are > used by default. > It looks like arm32 defaults to gnu, not gnu2. andrew mentioned fdpic will be an issue there but maybe we could carve that out. > Should we flip the default

Re: Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

Florian Weimer via Gcc writes: > I feel like I have asked this before. Currently, GCC uses calls to > __tls_get_addr to obtain the address of global-dynamic TLS variables. > On other architectures with support for GNU2 TLS descriptors, those are > used by default. > > Should we flip the

Re: Update on GCC 14 C type safety changes/warnings as errors

Florian Weimer via Gcc writes: > [...] > Numbers do not tally up because one package can have multiple issues. > The autoconf column counts packages where file-name based heuristics > suggest the critical errors are in autoconf-style feature probes, where > they are ignored and could silently

Re: -Wint-conversion as errors seems doable for GCC 14

Florian Weimer via Gcc writes: > I completed a Fedora rawhide rebuild with an instrumented GCC (~14,500 > packages). 156 packages failed to build with a logged -Wint-conversion > error. This number is much lower than what I expected, and I think we > should include -Wint-conversion in the

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

Jeff Law via Gcc writes: > On 9/26/23 02:28, Florian Weimer via Gcc wrote: >> My understanding of the consensus goes as follows: >> * We want to make some changes in this area for GCC 14. >> * We should do the same thing that Clang does: default to the relevant >>-Werror= options. >> *

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

Florian Weimer via Gcc writes: > My understanding of the consensus goes as follows: > > * We want to make some changes in this area for GCC 14. > * We should do the same thing that Clang does: default to the relevant > -Werror= options. > * Unlike regular warnings, these warnings-as-errors

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: How can I run xg++ from its build location?

Michael Welsh Duggan via Gcc writes: > I am attempting to debug an issue in gcc (PR 110827, if curious). In > order to do this I have built a stage 1 compiler with debugging and > without optimization as discussed here: > > https://gcc.gnu.org/wiki/DebuggingGCC#Building_a_Debuggable_Compiler

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: New version of gnu assembler

jacob navia writes: > Hi > > I have developed a new version of the gnu assembler for riscv machines. > > Abstract: > ——— > > The GNU assembler (gas) is centered on flexibility and portability. These two > objectives have quite a cost in program readability, code size and execution > time.

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: Will GCC eventually support SSE2 or SSE4.1?

"Stefan Kanthak" writes: > "Jonathan Wakely" wrote: > >> On Fri, 26 May 2023, 08:01 Andrew Pinski via Gcc, wrote: >> >>> On Thu, May 25, 2023 at 11:56?PM Stefan Kanthak >>> wrote: Hi, compile the following function on a system with Core2 processor (released January

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: More C type errors by default for GCC 14

Florian Weimer writes: > * Sam James: > >> Florian Weimer writes: >> >>> [...] >>> In summary, all these seems to be good candidates for errors by default: >>> >>> * int-conversion as errors (already raised separately >>> * -Wint-conversion for ?: >>> * parameter names in non-prototype

Re: More C type errors by default for GCC 14

Florian Weimer writes: > [...] > In summary, all these seems to be good candidates for errors by default: > > * int-conversion as errors (already raised separately > * -Wint-conversion for ?: > * parameter names in non-prototype function declarations > * the union wait function pointer

Re: More C type errors by default for GCC 14

Florian Weimer writes: > * Jason Merrill: > >> On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: >>> >>> * Joseph Myers: >>> >>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: >>> > >>> >> That is not the case we are discussing, AFAIU. Or at least no one has >>> >> yet explained why

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > Eli Schwartz writes: > >> This discussion thread is about having very good technical reasons -- as >> explained multiple times, including instances where you agreed that the >> technical reasons were good. >> >> Furthermore, even despite those technical reasons, GCC is

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > Eli Schwartz writes: > >> This discussion thread is about having very good technical reasons -- as >> explained multiple times, including instances where you agreed that the >> technical reasons were good. >> >> Furthermore, even despite those technical reasons, GCC is

Re: More C type errors by default for GCC 14

Po Lu writes: > Sam James writes: > >> And I would not want to see that happen either, nor do I think Florian >> would, or many of the other participants in this thread. >> >> Indeed, for some projects, where it's hopeless^Wlots of work, >> we're using -std=c89 or -std=gnu89 as appropriate -

Re: More C type errors by default for GCC 14

Eli Schwartz via Gcc writes: > On 5/11/23 2:12 AM, Eli Zaretskii wrote: >>> Date: Wed, 10 May 2023 23:14:20 -0400 >>> From: Eli Schwartz via Gcc >>> >>> Second of all, why is this GCC's problem? You are not a user of GCC, >>> apparently. >> >> He is telling you that removing support for these

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > jwakely@gmail.com (Jonathan Wakely) writes: > >> So let's do it. Let's write a statement saying that the GCC developers >> consider software security to be of increasing importance, and that we >> consider it irresponsible to default to accepting invalid constructs

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > dje@gmail.com (David Edelsohn) writes: > >> This seems to be the core tension. If developers cared about these issues, >> they would enable appropriate warnings and -Werror. >> >> The code using these idioms is not safe and does create security >> vulnerabilities.

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > jwakely@gmail.com (Jonathan Wakely) writes: > >> This isn't "be like Clang", this is "diagnose things that have been >> invalid C since 1999". > > Only if your definition of valid C is ``strictly conforming to the ISO > Standard''. I doubt there are many programs

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > jwakely@gmail.com (Jonathan Wakely) writes: > >> This isn't "be like Clang", this is "diagnose things that have been >> invalid C since 1999". > > Only if your definition of valid C is ``strictly conforming to the ISO > Standard''. I doubt there are many programs

Re: More C type errors by default for GCC 14

"James K. Lowden" writes: > On Tue, 9 May 2023 23:45:50 +0100 > Jonathan Wakely via Gcc wrote: > >> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote: >> > We are currently using gcc 12 and specifying C11. To experiment >> > with these stricter warnings and slowly address them, would we need

Re: More C type errors by default for GCC 14

Eli Zaretskii via Gcc writes: >> From: Eric Gallager >> Date: Wed, 10 May 2023 06:40:54 -0400 >> Cc: j...@rtems.org, David Edelsohn , Eli Zaretskii >> , >> Jakub Jelinek , Arsen Arsenović , >> "gcc@gcc.gnu.org" >> >> Idea for a compromise: What if, instead of flipping the switch

Re: Tags not allowed in user repository - Mildly urgent

Andreas Schwab writes: > On Mai 10 2023, Sam James via Gcc wrote: > >> Ondřej Kubánek via Gcc writes: >> >>> Hello, >>> >>> I have tried to push a tag to my user space /tags/ ref in the GCC repo. The >>> tag is annotated but the push was

Re: More C type errors by default for GCC 14

Eli Zaretskii via Gcc writes: >> Date: Wed, 10 May 2023 10:49:32 +0200 >> From: David Brown via Gcc >> >> > People who ignore warnings will use options that disable these new >> > errors, exactly as they disable warnings. So we will end up not >> > reaching the goal, but instead harming

Re: Tags not allowed in user repository - Mildly urgent

Ondřej Kubánek via Gcc writes: > Hello, > > I have tried to push a tag to my user space /tags/ ref in the GCC repo. The > tag is annotated but the push was rejected. Here is the command > > git push origin master:refs/users/kubaneko/tags/Thesis Thesis > > and here is the response > > Total 0

Re: More C type errors by default for GCC 14

Eric Gallager via Gcc writes: > On 5/9/23, Jonathan Wakely via Gcc wrote: >> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote: >>> We are currently using gcc 12 and specifying C11. To experiment with >>> these stricter warnings and slowly address them, would we need to build >>> with a newer

Re: More C type errors by default for GCC 14

Jason Merrill writes: > On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc > wrote: >> >> * Richard Biener: >> >> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn : >> > > >> > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc >> > > wrote: >> > > >> > > On Tue, May 09, 2023 at

Re: More C type errors by default for GCC 14

Florian Weimer writes: > * Richard Biener: > >>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc : >>> >>> TL;DR: This message is about turning implicit-int, >>> implicit-function-declaration, and possibly int-conversion into errors >>> for GCC 14. >> >> I suppose the goal is to not

Re: More C type errors by default for GCC 14

Eli Zaretskii via Gcc writes: >> Cc: Jonathan Wakely , gcc@gcc.gnu.org >> Date: Tue, 09 May 2023 18:38:05 +0200 >> From: Arsen Arsenović via Gcc >> >> You're actively dismissing the benefit. > > Which benefit? > > No one has yet explained why a warning about this is not enough, and > why it

Re: More C type errors by default for GCC 14

Jakub Jelinek writes: > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote: >> >> >> > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc : >> > >> > TL;DR: This message is about turning implicit-int, >> > implicit-function-declaration, and possibly int-conversion

Re: More C type errors by default for GCC 14

David Edelsohn via Gcc writes: > On Tue, May 9, 2023 at 8:16 AM Florian Weimer via Gcc > wrote: > >> TL;DR: This message is about turning implicit-int, >> implicit-function-declaration, and possibly int-conversion into errors >> for GCC 14. >> >> A few of you might remember that I've been

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

Re: GCC-13 Branch with RISC-V Performance-Related Backports

Palmer Dabbelt writes: > We talked about this a bit on IRC, but just to reflect it to the > mailing lists: > > On Tue, 18 Apr 2023 05:34:11 PDT (-0700), s...@gentoo.org wrote: >> >> Palmer Dabbelt writes: >> >>> Based on some discussions, it looks like a handful of vendors are >>> planning on

[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: GCC 13 release date

"Vaish, Mayank" writes: > [AMD Official Use Only - General] > Hi Mayank, > Thanks Sam for your prompt response. > > The status message https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html. > mentions GCC 13.0.1 report. Is there any stable GCC 13.0.0 tag/branch > available for general

Re: GCC 13 release date

"Vaish, Mayank via Gcc" writes: > [AMD Official Use Only - General] > > Hi, > > Looking out for GCC 13 release date. GCC Development > plan only mention about GCC 13 > Stage 4 development. > > Please comment on the formal GCC 13 release date. I'm

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

Re: GCC-13 Branch with RISC-V Performance-Related Backports

Palmer Dabbelt writes: > Based on some discussions, it looks like a handful of vendors are > planning on maintaining GCC-13 branches that include various > performance-related backports (ie, patches not suitable for the > standard GCC-13 release branch). > > I don't think we'd actually agreed

[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: Missed warning (-Wuse-after-free)

> On 17 Feb 2023, at 01:05, Alejandro Colomar via Gcc wrote: > > On 2/17/23 02:04, Alejandro Colomar wrote: >> [CC: Added those who contributed to the discussion in linux-man@, >> and also the authors of N2861 for C2x] > > [...] > >> >> There was a discussion in linux-man@ some years

Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

> On 30 Jan 2023, at 06:27, Steve Kargl via Gcc wrote: Hi Steve, > Please remove the skull and cross bones in the subject line. This is a sourceware project so I've CC'd the buildbot mailing list where we discuss these matters. Does the emoji bother you, or is it the skull and crossbones

Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

> On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote: > > I had this show up today. I have no idea what this is about. > > Please advise. > Sorry Jerry, false positive -- something went wrong with the builder. Disregard. We're still setting things up there. > Jerry Best, sam

Re: avx512erintrin.h: uninitialized variable warning (optimized build)

> On 12 Jan 2023, at 00:26, James Addison via Gcc wrote: > > Hi, > > During GCC 12.2.0 compilation of a file that includes[1] immintrin.h > with both code-optimization and uninitialized-variable-warnings > enabled, a warning is emitted: > >

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: How can Autoconf help with the transition to stricter compilation defaults?

> On 16 Nov 2022, at 15:27, Richard Biener wrote: > > On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote: >> >> Hey, >> >> On Wed, 16 Nov 2022, Alexander Monakov wrote: >> The idea is so obvious that I'm probably missing something, why autoconf can't use that idiom

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 15 Nov 2022, at 13:30, Zack Weinberg wrote: > > On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote: >>> On 13 Nov 2022, at 00:43, Paul Eggert wrote: >>> >>> Although there will be problems with people who run "./configure >>> CFLAGS='-Werror'", that sort of usage has always been

Re: C89isms in the test suite

> On 14 Nov 2022, at 08:19, Florian Weimer wrote: > > * Sam James: > >> Would you be able to backport 6be2672e4ee41c566a9e072088a263bab5f7 >> and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13 >> branches? > > Jakub, okay to backport these two (to 12, 11, 10 I presume)? (Yes

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 13 Nov 2022, at 00:43, Paul Eggert wrote: > > On 2022-11-11 07:11, Aaron Ballman wrote: >> We believe the runtime behavior is sufficiently dangerous to >> warrant a conservative view that any call to a function will be a call >> that gets executed at runtime, hence a definitive signature

Re: C89isms in the test suite

> On 21 Oct 2022, at 09:40, Florian Weimer via Gcc wrote: > > What should we do about these when they are not relevant to what's being > tested? For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c > has this: > > int main () > { >if (__builtin_copysign (1.0, func (0.0 /

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 12 Nov 2022, at 00:53, Paul Eggert wrote: > > On 2022-11-11 15:25, Sam James wrote: >> That's not a judgement on whether the changes will ultimately remain in >> autoconf, I'm just >> hesitant to allow a discussion I've kicked off to derail something that we >> were planning >> on doing

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 12 Nov 2022, at 03:40, Zack Weinberg wrote: > > Florian Weimer writes: >> based on a limited attempt to get this fixed about three years >> ago, I expect that many of the problematic packages have not had their >> configure scripts regenerated using autoconf for a decade or more. This

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 11 Nov 2022, at 03:33, Zack Weinberg wrote: > > On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote: >>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote: >>> While everyone else is discussing big ideas, it would be helpful for me >>> personally if autoconf just made a release with the

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 (>=

  1   2   >