> Date: Thu, 17 Jul 2025 05:23:50 -0700 (PDT)
> Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com
> From: ken...@adacore.com (Richard Kenner)
>
> > I don't see how distributing in the same tarball would solve the
> > problem.
> >
> > Suppose I'd decide to distribute a Windows bui
> Date: Thu, 17 Jul 2025 03:43:29 -0700 (PDT)
> Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com
> From: ken...@adacore.com (Richard Kenner)
>
> > > Yes, but the discussion wasn't about "as a separate file", but as a file
> > > that's part of the distribution of another program.
> Date: Thu, 17 Jul 2025 02:28:36 -0700 (PDT)
> Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com
> From: ken...@adacore.com (Richard Kenner)
>
> > That's not what RMS told me when I asked him some time ago. He said
> > that, since libgcc DLL and libstdc++ DLL are basically separ
> Date: Wed, 16 Jul 2025 19:03:21 +0200
> Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org
> From: David Brown
>
> >> Well they didn't ask about distributing the DLLs :-)
> >
> > They did, indirectly: programs compiled by MinGW GCC are linked
> > against libgcc and libstdc++ import libraries, and thu
> Date: Wed, 16 Jul 2025 17:44:41 +0200
> From: Dennis Luehring via Gcc
>
> Am 16.07.2025 um 17:37 schrieb Eli Zaretskii via Gcc:
> > Unless the Windows loader can find them on
> > the end-user's machine, it will refuse to run the program.
>
> the initial q
> From: Jonathan Wakely
> Date: Wed, 16 Jul 2025 16:12:01 +0100
> Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org
>
> On Wed, 16 Jul 2025 at 15:59, Eli Zaretskii wrote:
> >
> > > Please stop giving bad advice and direct people to read the
> > > appropriate documentation.
> >
> > Why the animosity?
> From: Jonathan Wakely
> Date: Wed, 16 Jul 2025 15:08:50 +0100
> Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org
>
> > > AFAIU, this is accurate if libgcc and libstdc++ are linked statically,
> > > but not if the program is linked to their DLL versions (and therefore
> > > the DLLs must be distribut
> Date: Wed, 16 Jul 2025 06:49:23 -0700 (PDT)
> Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com
> From: ken...@adacore.com (Richard Kenner)
>
> > Not if we are talking about Windows binaries intended to be used by
> > people who don't have GCC installed. (The OP asked about Min
> Date: Wed, 16 Jul 2025 06:20:42 -0700 (PDT)
> Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com
> From: ken...@adacore.com (Richard Kenner)
>
> > AFAIU, this is accurate if libgcc and libstdc++ are linked statically,
> > but not if the program is linked to their DLL versions (an
> Date: Wed, 16 Jul 2025 11:12:44 +0100
> Cc: gcc , gcc-help
> From: Jonathan Wakely via Gcc
>
> On Wed, 16 Jul 2025 at 10:06, Qifan.Zhou via Gcc wrote:
> >
> > Dear GCC Team,
>
> Please don't email both gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org, pick
> the appropriate one. You're not discussin
> 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/
> 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
> 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: 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
> 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
[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: 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
>
> 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: 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.
> 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.)
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: 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
> 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
> 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
> 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: 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 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
> 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.
> >
> >
> 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,
> 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,
> 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
> 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: 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 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
> 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 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
> 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 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 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 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 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
> 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 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: 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
> 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: 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
> 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: 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
> 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: 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: 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: 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
> 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: 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
> 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: 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
>
> 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: 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
> 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:
> 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: 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
> 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
> 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,
> > +
> 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: 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: 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: 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
> >>
> >> @@
> 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: 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
> 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 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
> 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
> 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: 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: 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?
> 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
> 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
> 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
> 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: 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
> 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: 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: 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
> 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: 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: 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 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: 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: 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 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.)
>
>
> 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.
>
>
> 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
92 matches
Mail list logo
