> From: Martin Liška
> Date: Tue, 29 Jun 2021 12:09:23 +0200
> Cc: GCC Development , gcc-patc...@gcc.gnu.org
>
> On 6/28/21 5:33 PM, Joseph Myers wrote:
> > Are formatted manuals (HTML, PDF, man, info) corresponding to this patch
> > version also available for review?
>
> I've just uploaded them
> Date: Tue, 29 Jun 2021 19:57:11 +0300
> From: Eli Zaretskii via Gcc
> Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, jos...@codesourcery.com
>
> Or how about this:
>
> `Overall Options'
>
>See Options Controlling the Kind of Output.
>
>
> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška
> Date: Wed, 30 Jun 2021 12:11:03 +0200
>
> > (Admittedly, Emacs by default hides some of the text of a
> > cross-reference, but not hiding them in this case produces an even
> > less legible text.)
>
>
> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška
> Date: Wed, 30 Jun 2021 15:28:40 +0200
>
> >‘@`file'’
> >
> > Read command-line options from ‘`file'’. The options read are
> > inserted in place of the original ‘@`file'’ option.
> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška
> Date: Wed, 30 Jun 2021 16:04:32 +0200
>
> > Thanks, but does that mean @var will no longer stand out in the
> > produced Info format? That'd be sub-optimal, I think, because a clear
> > reference to a
> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 14:44:10 +0200
>
> > It helps some, but not all of the issues disappear. For example,
> > stuff like this is still hard to read:
> >
> >To select this standard in GCC, use on
> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 16:14:30 +0200
>
> >> If I understand the notes correct, the '.' should be also hidden by e.g.
> >> Emacs.
> >
> > No, it doesn't. The actual text in the Info file is:
> >
> >
> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 18:04:24 +0200
>
> > Emacs doesn't hide the period. But there shouldn't be a period to
> > begin with, since it's the middle of a sentence. The correct way of
> > writing this in
> Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> From: Martin Liška
> Date: Fri, 2 Jul 2021 11:30:02 +0200
>
> > So the purpose of having the comma there is to avoid having a period
> > in the middle of a sentence, which is added by makeinfo (because the
> > Info readers
> Cc: Eli Zaretskii , gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org,
> jos...@codesourcery.com
> From: Martin Liška
> Date: Fri, 2 Jul 2021 11:40:06 +0200
>
> > It must
> > look sensible without that. In this case it seems that already the
> > generated .texinfo input to makeinfo is bad, where does
> From: Richard Sandiford
> Cc: Eli Zaretskii , gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org,
> jos...@codesourcery.com
> Date: Mon, 05 Jul 2021 10:17:38 +0100
>
> Hans-Peter Nilsson writes:
> > I've read the discussion downthread, but I seem to miss (a recap
> > of) the benefits of moving to Sp
> Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, jos...@codesourcery.com
> From: Martin Liška
> Date: Mon, 12 Jul 2021 15:25:47 +0200
>
> Let's make it a separate sub-thread where we can discuss motivation why
> do I want moving to Sphinx format.
Thanks for starting this discussion.
> Benefits:
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 14:53:44 +0100
> Cc: Martin Liška ,
> "gcc@gcc.gnu.org" , gcc-patches
> ,
> "Joseph S. Myers"
>
> For me, these items are enough justification to switch away from
> texinfo, which produces crap HTML pages with crap anchors.
If we w
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 15:05:11 +0100
> Cc: Martin Liška ,
> "gcc@gcc.gnu.org" , gcc-patches
> ,
> "Joseph S. Myers"
>
> To be clear, I give links to users frequently (several times a week,
> every week, for decades) and prefer to give them a link to spec
> From: Matthias Kretz
> Date: Mon, 12 Jul 2021 16:54:50 +0200
>
> On Monday, 12 July 2021 16:30:23 CEST Martin Liška wrote:
> > On 7/12/21 4:12 PM, Eli Zaretskii wrote:
> > > I get it that you dislike the HTML produced by Texinfo, but without
> > > some examples of such bad HTML it is impossible
> Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, jos...@codesourcery.com
> From: Martin Liška
> Date: Mon, 12 Jul 2021 16:34:11 +0200
>
> > "Texinfo must go" is one possible conclusion from your description.
> > But it isn't the only one. An alternative is "the Texinfo source of
> > the GCC manua
> Cc: h...@bitrange.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org,
> jos...@codesourcery.com
> From: Martin Liška
> Date: Mon, 12 Jul 2021 16:37:00 +0200
>
> > 4) The need to learn yet another markup language.
> > While this is not a problem for simple text, it does require a
> > ser
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 15:54:49 +0100
> Cc: Martin Liška ,
> "gcc@gcc.gnu.org" , gcc-patches
> ,
> "Joseph S. Myers"
>
> You like texinfo. We get it.
Would you please drop the attitude?
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 18:15:26 +0100
> Cc: Matthias Kretz , "gcc@gcc.gnu.org"
>
> > Gavin Smith, the GNU Texinfo maintainer, responded in detail to that
> > list. However, his message didn't get through to the list, for some
> > reason.
>
> It did:
> https://gcc.gnu.
> From: Richard Biener
> Date: Tue, 13 Jul 2021 08:24:17 +0200
> Cc: Eli Zaretskii , "gcc@gcc.gnu.org"
>
> I actually like texinfo (well, because I know it somewhat, compare to sphinx).
> I think it produces quite decent PDF manuals. I never use the html
> output (in fact I read our manual usin
> From: Richard Biener
> Date: Tue, 13 Jul 2021 14:46:33 +0200
> Cc: Jonathan Wakely , GCC Development
> I can very well understand the use of the html manual when you want
> to share pointers to specific parts of the documentation in communications.
In the Emacs community, we have a notation fo
> Date: Sun, 20 Nov 2022 13:53:48 +0100
> From: Pali Rohár via Gcc
>
> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to li
> Date: Sun, 20 Nov 2022 16:04:11 +0100
> From: Pali Rohár
> Cc: gcc@gcc.gnu.org, mingw-w64-pub...@lists.sourceforge.net
>
> On Sunday 20 November 2022 16:45:55 Eli Zaretskii wrote:
> > > Date: Sun, 20 Nov 2022 13:53:48 +0100
> > > From: Pali Rohár via Gcc
> > >
> > Linking a program against a
> Date: Sun, 20 Nov 2022 16:44:08 +0100
> From: Pali Rohár
> Cc: gcc@gcc.gnu.org, mingw-w64-pub...@lists.sourceforge.net
>
> > Installing a redistributable is a nuisance, and dependence on non-system
> > libraries might make the program non-free.
>
> On new windows versions they may be preinstal
> From: Björn Schäpers
> Date: Fri, 20 Jan 2023 11:54:08 +0100
>
> @@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor,
> + (sections[i].offset - min_offset));
> }
>
> - if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_
> Date: Fri, 20 Jan 2023 17:46:59 +0100
> Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Gabriel Ravier
>
> On 1/20/23 14:39, Eli Zaretskii via Gcc wrote:
> >> From: Björn Schäpers
> >> Date: Fri, 20 Jan 2023 11:54:08 +0100
> >>
> >> @@
> Date: Fri, 20 Jan 2023 21:39:56 +0100
> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Gabriel Ravier
>
> >> - using wide APIs with Windows is generally considered to be a best
> >> practice, even when not strictly needed (and in this case I can't see
> >> any problem wit
> Date: Sat, 21 Jan 2023 17:18:14 +0800
> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: LIU Hao
>
> 在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道:
> > I'm not sure I follow the logic. A program that calls
> > GetModuleHandleW will refuse
> Date: Sat, 21 Jan 2023 11:47:42 +0100
> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Gabriel Ravier
>
>
> On 1/21/23 05:05, Eli Zaretskii wrote:
> >> Date: Fri, 20 Jan 2023 21:39:56 +0100
> >> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> >> From: Gab
> Date: Mon, 23 Jan 2023 15:00:56 -0800
> Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Ian Lance Taylor via Gcc
>
> > +#ifdef HAVE_WINDOWS_H
> > +
> > +static char *
> > +windows_get_executable_path (char *buf, backtrace_error_callback
> > error_callback,
> > +
> From: Ian Lance Taylor
> Date: Tue, 24 Jan 2023 06:35:21 -0800
> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
>
> > > On Windows it seems that MAX_PATH is not
> > > a true limit, as an extended length path may be up to 32767 bytes.
> >
> > The limit of 32767 characters (not byt
> From: Ian Lance Taylor
> Date: Tue, 24 Jan 2023 09:58:10 -0800
> Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
>
> I'd rather that the patch look like the appended. Can someone with a
> Windows system test to see what that builds and passes the tests?
ENOPATCH
> 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 must be made an error. Florian's initial post d
> From: Sam James
> Cc: Arsen Arsenović , d...@killthe.net,
> jwakely@gmail.com, gcc@gcc.gnu.org
> Date: Tue, 09 May 2023 18:05:09 +0100
>
> Eli Zaretskii via Gcc writes:
>
> >> Cc: Jonathan Wakely , gcc@gcc.gnu.org
> >> Date: Tue, 09 May 2023 18:38:
> From: Jonathan Wakely
> Date: Tue, 9 May 2023 18:15:59 +0100
> Cc: Arsen Arsenović , gcc@gcc.gnu.org
>
> On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
> >
> > No one has yet explained why a warning about this is not enough, and
> > why it must be made an error. Florian's initial post doesn
> Date: Tue, 9 May 2023 21:07:07 +0200
> From: Jakub Jelinek
> Cc: Jonathan Wakely , ar...@aarsen.me, gcc@gcc.gnu.org
>
> On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
> > > From: Jonathan Wakely
> > > Date: Tue, 9 May 2023 18:15:59 +010
> From: Florian Weimer
> Cc: Jakub Jelinek , Eli Zaretskii ,
> jwakely@gmail.com, ar...@aarsen.me
> Date: Tue, 09 May 2023 22:57:20 +0200
>
> * Eli Zaretskii via Gcc:
>
> >> Date: Tue, 9 May 2023 21:07:07 +0200
> >> From: Jakub Jelinek
>
> From: Arsen Arsenović
> Cc: Eli Zaretskii , Jakub Jelinek ,
> jwakely@gmail.com, gcc@gcc.gnu.org
> Date: Tue, 09 May 2023 22:21:03 +0200
>
> > The concern is using the good will of the GNU Toolchain brand as the tip of
> > the spear or battering ram to motivate software packages to fix the
> From: Jonathan Wakely
> Date: Wed, 10 May 2023 09:04:12 +0100
> Cc: Florian Weimer , "gcc@gcc.gnu.org" ,
> Jakub Jelinek , Arsen Arsenović
>
> void foo(int);
> void bar() { foo("42"); }
>
> Why should this compile?
Because GCC is capable of compiling it.
> You keep demanding better r
> 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 who are well aware of the
> > warnings
> From: Arsen Arsenović
> Cc: dje@gmail.com, ja...@redhat.com, jwakely@gmail.com,
> gcc@gcc.gnu.org
> Date: Wed, 10 May 2023 10:36:23 +0200
>
> Eli Zaretskii writes:
>
> > It is not GCC's business to force developers of packages to get their
> > act together.
>
> Why not? Compilers a
> 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 on all
> 3 of these at once, we stagger
> From: Neal Gompa
> Date: Wed, 10 May 2023 06:56:32 -0400
> Cc: Eric Gallager , Jonathan Wakely
> , j...@rtems.org,
> David Edelsohn , Eli Zaretskii , Jakub
> Jelinek ,
> Arsen Arsenović , gcc@gcc.gnu.org,
> c-std-port...@lists.linux.dev
>
> On Wed, May 10, 2023 at 6:48 AM
> From: Jonathan Wakely
> Date: Wed, 10 May 2023 12:49:52 +0100
> Cc: David Brown , gcc@gcc.gnu.org
>
> > If some developers want to ignore warnings, it is not the business of
> > GCC to improve them, even if you are right in assuming that they will
> > not work around errors like they work aroun
> From: Jonathan Wakely
> Date: Wed, 10 May 2023 12:56:48 +0100
> Cc: Arsen Arsenović , dje@gmail.com,
> ja...@redhat.com, gcc@gcc.gnu.org
>
> On Wed, 10 May 2023 at 12:51, Eli Zaretskii wrote:
> > Once again, it is not GCC's business to clean up the packages which
> > use GCC as the c
> Date: Wed, 10 May 2023 14:03:01 +0200
> From: Jakub Jelinek
> Cc: Jonathan Wakely , fwei...@redhat.com,
> gcc@gcc.gnu.org, ar...@aarsen.me
>
> > > Why should this compile?
> >
> > Because GCC is capable of compiling it.
>
> That is not a good argument. GCC is capable of compiling any
> From: Neal Gompa
> Date: Wed, 10 May 2023 08:10:48 -0400
> Cc: s...@gentoo.org, eg...@gwmail.gwu.edu, jwakely@gmail.com,
> j...@rtems.org, dje@gmail.com, ja...@redhat.com, ar...@aarsen.me,
> gcc@gcc.gnu.org, c-std-port...@lists.linux.dev
>
> On Wed, May 10, 2023 at 8:05 AM
> From: Jonathan Wakely
> Date: Wed, 10 May 2023 13:30:10 +0100
> Cc: ar...@aarsen.me, dje@gmail.com, ja...@redhat.com, gcc@gcc.gnu.org
>
> People are still using C to write new programs, and they are still
> making avoidable mistakes. The default for new code using new -std
> modes should be
> From: Sam James
> Cc: David Brown , gcc@gcc.gnu.org
> Date: Wed, 10 May 2023 13:32:08 +0100
>
> > I'm okay with making it harder, but without making it too hard for
> > those whose reasons for not changing the code are perfectly valid.
> > This proposal crosses that line, IMNSHO.
>
> Could you
> Date: Wed, 10 May 2023 14:41:27 +0200
> Cc: jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org,
> ar...@aarsen.me
> From: Gabriel Ravier
>
> >>> Because GCC is capable of compiling it.
> >> That is not a good argument. GCC is capable of compiling any code in all
> >> the reported acce
> From: Marcin Jaczewski
> Date: Wed, 10 May 2023 14:41:40 +0200
>
> Did you even check if the compiler outpost is still correct?
Yes.
> You mention "validations and verifications", do you do the same
> with the new compiler?
Yes. But that is a fraction of the effort needed when the source
ch
> Date: Wed, 10 May 2023 15:30:02 +0200
> From: David Brown via Gcc
>
> >>> If some developers want to ignore warnings, it is not the business of
> >>> GCC to improve them, even if you are right in assuming that they will
> >>> not work around errors like they work around warnings (and I'm not at
> Date: Wed, 10 May 2023 16:22:26 +0200
> From: Jakub Jelinek
> Cc: Gabriel Ravier , jwakely@gmail.com,
> fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me
>
> > > Are you seriously saying that no accepts-invalid bug should ever be
> > > fixed under any circumstances on the basis
> Date: Wed, 10 May 2023 16:31:23 +0200
> From: Thomas Koenig via Gcc
>
> On 10.05.23 14:03, Jakub Jelinek via Gcc wrote:
> > We do such changes several times a year, where we reject something that has
> > been previously accepted in older standards, admittedly mostly in C++.
>
> ... and in Fort
> Date: Wed, 10 May 2023 17:58:16 +0200
> From: David Brown via Gcc
>
> > In any case, I was not not talking about bug-compatibility, I was
> > talking about being able to compile code which GCC was able to compile
> > in past versions. Being able to compile that code is not a bug, it's
> > a fe
> Date: Wed, 10 May 2023 18:02:53 +0200
> From: Jakub Jelinek
> Cc: gabrav...@gmail.com, jwakely@gmail.com, fwei...@redhat.com,
> gcc@gcc.gnu.org, ar...@aarsen.me
>
> > If some program is plainly invalid, not just because the criteria of
> > validity have shifted, then yes, such a pro
> Date: Wed, 10 May 2023 18:20:50 +0200
> From: David Brown via Gcc
>
> > Adding a flag to a Makefile is infinitely easier than fixing old
> > sources in a way that they produce the same machine code.
>
> The suggestion has been - always - that support for old syntaxes be
> retained. But that
> From: Richard Biener
> Date: Wed, 10 May 2023 18:33:53 +0200
> Cc: Jakub Jelinek , gabrav...@gmail.com,
> jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me
>
>
>
> > Am 10.05.2023 um 18:31 schrieb Eli Zaretskii via Gcc :
> > The
> Date: Wed, 10 May 2023 17:08:18 +
> From: Joseph Myers
> CC: Jakub Jelinek , ,
> , , ,
>
>
> 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
> Date: Wed, 10 May 2023 14:37:50 -0400
> From: "James K. Lowden"
> Cc: Jonathan Wakely
>
> 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
> > > wi
> 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 old features, you
draw users away from GCC and towards proprietary compilers.
One of the
> Date: Thu, 11 May 2023 00:46:23 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc
>
> > And remember that `-traditional' DID exist for a certain amount of time.
> > Then it was removed. So in addition to annoying a lot of people, what
> > guarantees that -Wno-implicit will not be remove
> From: David Brown
> Date: Thu, 11 May 2023 08:52:03 +0200
>
> > But we are not talking about some random code that just happened to
> > slip through cracks as a side effect of the particular implementation.
> > We are talking about code that was perfectly valid, had well-defined
> > semantics,
> Cc: Jonathan Wakely , gcc@gcc.gnu.org
> Date: Thu, 11 May 2023 10:44:47 +0200
> From: Arsen Arsenović via Gcc
>
> the current default of accepting this code in C is harmful to those
> who are writing new code, or are learning C.
People who learn C should be advised to turn on all the warnings,
> Date: Thu, 11 May 2023 18:30:20 -0400
> Cc: luang...@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz
>
> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
> >
> > He is telling you that removing support for these old features, you
> > draw users away from GCC and towards proprietary compilers.
> >
> >
> Date: Thu, 11 May 2023 18:43:32 -0400
> Cc: luang...@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz
>
> On 5/11/23 2:24 AM, Eli Zaretskii wrote:
>
> > Back to the subject: the guarantees I would personally like to have is
> > that the current GCC development team sees backward compatibility a
> From: Jason Merrill
> Date: Thu, 11 May 2023 22:55:07 -0400
> Cc: Eli Schwartz , Eli Zaretskii ,
> gcc@gcc.gnu.org
>
> > Because now people will have to go through dozens and dozens of
> > Makefiles, configure.in, *.m4
>
> You shouldn't have to change any of those, just configure with CC="gcc
> Date: Thu, 11 May 2023 23:07:55 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc
>
> > Being sceptical about the future is perfectly reasonable.
>
> My opinion on this is (still) that if your argument is that you don't
> want -fpermissive or -std=c89 to be removed, you are more than we
> From: Arsen Arsenović
> Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org
> Date: Thu, 11 May 2023 21:25:53 +0200
>
> >> This seems like a good route to me - it facilitates both veterans
> >> maintaining code and beginners just learning how to write C.
> >
> > No, it prefers beginn
> From: Jonathan Wakely
> Date: Fri, 12 May 2023 08:28:00 +0100
> Cc: Eli Schwartz , Po Lu ,
> "gcc@gcc.gnu.org"
>
> It is on topic because there doesn't seem to be anything in the
> arguments brought up for this current proposal that couldn't be
> brought up in favor of removing -fper
> Date: Fri, 12 May 2023 10:15:45 +0200
> From: Jakub Jelinek
> Cc: Arsen Arsenović , luang...@yahoo.com,
> jwakely@gmail.com, gcc@gcc.gnu.org
>
> On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> >
> > Let's keep in mind th
Dear GCC developers,
Emacs 29, to be released soon, will come with a built-in client for
the LSP protocol. This allows to enhance important Emacs features,
such as at-point documentation, on-the-fly diagnostic annotations,
finding definitions and uses of program identifiers, enhanced
completion o
> Date: Mon, 20 Nov 2023 20:57:38 +0100
> Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Björn Schäpers
>
> +#ifndef NOMINMAX
> +#define NOMINMAX
> +#endif
Why is this part needed?
Otherwise, LGTM, thanks. (But I'm don't have the approval rights, so
please wait for Ian to chime in.)
> Date: Thu, 30 Nov 2023 11:53:54 -0800
> Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Ian Lance Taylor via Gcc
>
> Also starting with a module count of 1000 seems like a lot. Do
> typical Windows programs load that many modules?
Unlikely. I'd start with 100.
> Cc: Jonathan Yong <10wa...@gmail.com>, Jan Hubicka , Nathan
> Sidwell
> Date: Fri, 01 Dec 2023 09:02:55 +0100
> X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
> DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
> RCVD_IN_MSPIKE_H3, RCVD_IN_
> Date: Sat, 6 Jan 2024 23:15:24 +0100
> From: Björn Schäpers
> Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
>
> This patch adds libraries which are loaded after backtrace_initialize, like
> plugins or similar.
>
> I don't know what style is preferred for the Win32 typedefs, should the code
>
[I re-added the other addressees, as I don' think you meant to make
this discussion private between the two of us.]
> Date: Sun, 7 Jan 2024 12:58:29 +0100
> From: Björn Schäpers
>
> Am 07.01.2024 um 07:50 schrieb Eli Zaretskii:
> >> Date: Sat, 6 Jan 2024 23:15:24 +0100
> >> From: Björn Schäpers
> Date: Sun, 7 Jan 2024 17:07:06 +0100
> Cc: i...@google.com, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Björn Schäpers
>
> > That was about GetModuleHandle, not about GetModuleHandleEx. For the
> > latter, all Windows versions that support it also support "wide" APIs.
> > So my suggestion
> Date: Tue, 9 Jan 2024 21:02:44 +0100
> Cc: i...@google.com, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Björn Schäpers
>
> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
> > In that case, you an call either GetModuleHandeExA or
> > GetModuleHandeExW, the difference is minor.
>
> Here an up
> From: Ian Lance Taylor
> Date: Mon, 29 Jul 2024 09:46:46 -0700
> Cc: Eli Zaretskii , gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
>
> On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
> >
> > Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> > >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> > >> Cc: i
> Date: Wed, 16 Oct 2024 17:12:29 + (UTC)
> From: Joseph Myers via Gcc
>
> One issue that showed up as test failures with a default of -std=gnu23 is
> that -std=gnu23 -Wtraditional produces a "traditional C rejects ISO C
> style function definitions" warning for function definitions with em
> Date: Wed, 20 Nov 2024 16:11:16 -0500
> From: David Malcolm via Gcc
>
> 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:
> https://tracker.debian.org/
82 matches
Mail list logo
