> 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:
> 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
> 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
[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,
> 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.)
> Date: Tue, 29 Aug 2023 17:45:20 +0200
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org,
> binut...@sourceware.org
> From: Jakub Jelinek via Gdb-patches
>
> On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nick Clifton via Gcc-patches wrote:
> > Currently the top level configure.ac file
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
> 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 that
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> > >
> 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 explaine
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> >
> 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
> 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
> 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
> 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
> 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 09:58:10 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@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
> From: Ian Lance Taylor
> Date: Tue, 24 Jan 2023 06:35:21 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@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
> 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: Mon, 23 Jan 2023 15:00:56 -0800
> Cc: gcc-patches@gcc.gnu.org, g...@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:
> Date: Sat, 21 Jan 2023 11:47:42 +0100
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@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-patches@gcc.gnu.org, g...@gcc.gnu.org
> >> From:
> 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 to st
> Date: Sat, 21 Jan 2023 17:18:14 +0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@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 to st
> 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
> Date: Fri, 20 Jan 2023 21:39:56 +0100
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@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
> Date: Fri, 20 Jan 2023 17:46:59 +0100
> Cc: gcc-patches@gcc.gnu.org, g...@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 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,
> 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,
> 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
> 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
> From: Andrew Pinski
> Date: Wed, 4 Aug 2021 11:57:47 -0700
> Cc: Jonathan Wakely , GCC Bugs ,
> Andreas Schwab
>
> > > https://gcc.gnu.org/bugs/ instead.
> >
> > Which points to GCC Bugzilla, which doesn't have a "libiberty"
> > component. So I suggest to add such a component on the
> Date: Wed, 4 Aug 2021 15:41:30 +0100
> From: Jonathan Wakely
> Cc: gcc-bugs@gcc.gnu.org, e...@gnu.org
>
> > The libiberty README says to report bugs to gcc-bugs@gcc.gnu.org.
>
> Well that needs to be fixed. It should point to
> https://gcc.gnu.org/bugs/ instead.
Which points to GCC Bugzilla,
> From: Andreas Schwab
> Cc: Richard Sandiford , Eli Zaretskii
>
> Date: Wed, 04 Aug 2021 15:35:04 +0200
>
> On Aug 04 2021, Eli Zaretskii via Gcc-bugs wrote:
>
> > I'd love to, but please tell me where. I couldn't find any
> > information about reporting
> Date: Wed, 4 Aug 2021 14:03:21 +0100
> From: Jonathan Wakely
> Cc: gcc-bugs@gcc.gnu.org
>
> In GCC's bugzilla.
That's what I tried originally, but there's no libiberty there among
the various "components". So I decided the GCC Bugzilla was not the
right place. If it is the right place,
> From: Richard Sandiford
> Cc: Eli Zaretskii
> Date: Wed, 04 Aug 2021 13:04:24 +0100
>
> Eli Zaretskii via Gcc-bugs writes:
> > The version of rust-demangle.c included with Binutils 2.37 doesn't
> > compile with MinGW:
> >
> > mingw32-gcc -c -D
The version of rust-demangle.c included with Binutils 2.37 doesn't
compile with MinGW:
mingw32-gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -I.
-I../../binutils-2.37/libiberty/../include -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE
> 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
> 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
> 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:
>
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 15:54:49 +0100
> Cc: Martin Liška ,
> "g...@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 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
> >
> Cc: h...@bitrange.com, g...@gcc.gnu.org, gcc-patches@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
> >
> Cc: g...@gcc.gnu.org, gcc-patches@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
> 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
> 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
> 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
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 15:05:11 +0100
> Cc: Martin Liška ,
> "g...@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
> 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
> From: Jonathan Wakely
> Date: Mon, 12 Jul 2021 14:53:44 +0100
> Cc: Martin Liška ,
> "g...@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
> Cc: g...@gcc.gnu.org, gcc-patches@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.
>
> 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
> From: Richard Sandiford
> Cc: Eli Zaretskii , g...@gcc.gnu.org,
> gcc-patches@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
> Cc: Eli Zaretskii , g...@gcc.gnu.org, gcc-patches@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
> 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, g...@gcc.gnu.org, gcc-patches@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
> 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
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@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
> 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, g...@gcc.gnu.org, gcc-patches@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:
> >
>
1 - 100 of 112 matches
Mail list logo
