Re: [CAULDRON] Topics for the Toolchain and Linux kernel BoF

"Jose E. Marchesi via Gcc" writes: > Hello people! > > This year we will be having a kernel BoF at Cauldron. It is scheduled > for Saturday from 15:30 to 16:30. There will be several kernel > maintainers and hackers in attendance, and the goal of the BoF is to > discuss and collect feedback abo

Re: On pull request workflows for the GNU toolchain

Carlos O'Donell writes: > On 9/19/24 11:51 AM, Joseph Myers wrote: >> 1. Introduction > > Thanks for writing this up! > > [...] > Agreed. > I just want to say the same. My sentiments match Carlos.

Re: x86_64 regression tests arbitrary failing?

Arsen Arsenović via Gcc writes: > Hi, > > Georg-Johann Lay writes: > >> For a trivial change that I'd like to bootstrap + regtest, I am >> am getting FAILs like: >> >> $ diff xxx/gcc/testsuite/gcc/gcc.sum yyy/gcc/testsuite/gcc/gcc.sum >> 164656c164656 >> < PASS: c-c++-common/tsan/atomic_stack.c

Re: Fixing dormant bugs in obstack code

Andrew Pinski via Gcc writes: > On Wed, Aug 28, 2024 at 2:37 PM David Malcolm via Gcc wrote: >> >> I've been debugging a use-immediately-after-free bug involving obstacks >> (the bug isn't in trunk; I found it whilst testing one of my patches). >> >> It was only visible as a crash when it happen

Re: gcc-regression script build fail info

sounds good to me, although I was hoping someone might speak up ;) I will keep an eye on the failures afterwards and then see if it looks OK too. (Sorry if you were waiting on me, I may have misunderstood.) > Thx, > Haochen > >> -Original Message- >> From: Jia

RFC: Changing Bugzilla updates at release time

Hi! This came out of some discussion with Arsen and prompted by some other comments on IRC. At the moment, during release time, maintainer-scripts/branch_changer.py is run by release managers and causes a large amount of bugmail to be sent both to CCs/assignees but also to the gcc-bugs ML. The ac

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 for

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

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 >> user

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 committer

[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 i

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 sco

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 isn't

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

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 to

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 defaul

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 a

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 GCC

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. >> * Unli

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 sh

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: 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: 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 20

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 >>> *

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 compatibi

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: 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 i

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

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 whi

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 whi

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 those

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

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 C

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 0

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 need

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 mu

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 into

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 looki

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 m

Re: GCC 13 release date

ld never be released.) I hope that helps. TL;DR: GCC 13 is coming out in a week, if everything goes OK. And it will be called '13.1' officially. > > Regards, > Mayank > > -Original Message- > From: Sam James > Sent: Wednesday, April 19, 2023 11:02 AM >

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 jus

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 to

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 ago

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 sp

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 signature.asc

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: > >/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512er

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 instead

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 >>> CFL

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 the

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 m

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 / -5.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 somet

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 a

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

> On 10 Nov 2022, at 17:16, Zack Weinberg wrote: > > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable

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 a

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

> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote: > > On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote: >> >> Nobody has a whole lot of time to work on Autoconf at present, but I >> would like to ask, anyway, what Autoconf could potentially do to make >> this transition easier. > > Wh

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

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: http

Re: New "Diving into GCC internals" section in newbies guide

> On 10 Jun 2022, at 22:58, David Malcolm via Gcc wrote: > > I've written a large new chunk of documentation for my GCC newbies > guide, called "Diving into GCC internals", which can be seen at: > > https://gcc-newbies-guide.readthedocs.io/en/latest/diving-into-gcc-internals.html > > Hope thi