> 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: T
> 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 differ
> 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
> 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 chang
> 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 te
> 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
> 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
ed, May 10, 2023 at 8:05 AM Eli Zaretskii wrote:
> >
> > > From: Neal Gompa
> > > Date: Wed, 10 May 2023 06:56:32 -0400
> > > Cc: Eric Gallager , Jonathan Wakely
> > > , j...@rtems.org,
> > > David Edelsohn , Eli Zaretskii ,
> > > Jaku
> 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 pack
> 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
>
> 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 swit
> 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
> >
> 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 motiva
> 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
> 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...@gc
> 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
>
> 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
> ou
> 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
> > >
> 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
>
> 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 inp
> 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
> Date: Sat, 31 Jan 2015 01:55:29 +
> From: Jonathan Wakely
> Cc: Andrew Pinski , "gcc@gcc.gnu.org" ,
> Jonny Grant
>
> These files are only compiled by GCC's own build system, with GCC's
> own makefiles, so we know we invoke the C++ compiler and so the
> language isn't inferred from the fi
> From: DJ Delorie
> Cc: gcc@gcc.gnu.org, Jonny Grant
> Date: Fri, 30 Jan 2015 16:39:51 -0500
>
> However, we should avoid relying on case-sensitive file systems
> (Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
> name character on Windows, so we can't use .c++).
Actually,
> Date: Tue, 4 Jun 2013 09:45:10 -0700
> From: Ian Lance Taylor
> Cc: gcc@gcc.gnu.org
>
> I know very little about how these things work on Windows. However,
> it is fairly likely that full support for throwing exceptions across
> shared libraries on Windows does require using a shared libgcc.
> Date: Tue, 21 May 2013 21:19:24 +0300
> From: Eli Zaretskii
> CC: gcc@gcc.gnu.org
>
> > Date: Mon, 20 May 2013 06:37:31 -0700
> > From: Ian Lance Taylor
> > Cc: gcc@gcc.gnu.org
> >
> > On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii wrote:
>
> Date: Mon, 20 May 2013 12:18:29 +0200
> From: Kai Tietz
> Cc: Ian Lance Taylor , gcc Mailing List
>
> The issue is there that after an unload of libgcc on pe-coff, the
> function __decregister_frame_info_bases might be not called.
That's probably true (assuming that cygming-crtbegin.c decided
> Date: Mon, 20 May 2013 06:37:31 -0700
> From: Ian Lance Taylor
> Cc: gcc@gcc.gnu.org
>
> On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii wrote:
> >> I don't see any obvious bug in the code. Evidently
> >> something is going wrong, but the e-mail mes
> Date: Sun, 19 May 2013 17:48:06 -0700
> From: Ian Lance Taylor
> Cc: gcc@gcc.gnu.org
>
> It is not a fundamental bug to depend on libgcc as a shared library.
> The libgcc code is trying to do the right thing when the library is
> unloaded. I don't see any obvious bug in the code. Evidently
>
[Please CC me on replies, as I'm not a subscriber.]
Would someone on the developers' team please comment on this problem:
http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00413.html
In a nutshell, loading a GnuTLS DLL by a MinGW compiled Emacs causes
libintl DLL to be loaded, and if th
> X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
> FORGED_RCVD_HELO autolearn=ham version=3.1.0
> From: Andreas Schwab
> Cc: Dave Korn , i...@google.com,
> gcc@gcc.gnu.org
> Date: Sun, 05 Jul 2009 10:30:35 +0200
>
> Eli Zaretskii writes:
>
&g
> Date: Sun, 05 Jul 2009 00:33:44 +0100
> From: Dave Korn
> CC: Eli Zaretskii , gcc@gcc.gnu.org
>
> >> e...@fencepost:~$ gcc -print-prog-name=cpp
> >> cpp
> >
> > Yeah, that's a clear doc bug. It used to work wi
Some of the -print-* command-line switches either don't work as
advertised or their documentation should be made more clear.
All of the examples below are with the following version of GCC:
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
This
The current documentation of these two functions is misleading, and can
easily cause off-by-one bugs, if one follows it to the letter and
doesn't double-check with what the source actually does.
I tried to be more accurate in the patch below.
OK?
2009-05-23 Eli Zare
y about "libiberty
configuration for DJGPP"). But in principle, some build that has all
of the required functions in the system library can potentially fail
in the same way, no?
So how about the following patch?
2009-04-14 Eli Zaretskii
* Makefile.in (needed-list): Add "
y about "libiberty
configuration for DJGPP"). But in principle, some build that has all
of the required functions in the system library can potentially fail
in the same way, no?
So how about the following patch?
2009-04-14 Eli Zaretskii
* Makefile.in (needed-list): Add "
e required functions.
2009-04-14 Eli Zaretskii
* configure.ac (setobjs, msdosdjgpp): Move a-priori setting of
existing and required library functions to with_target_subdir
section, so that the native build does detect them at configure
time.
--- configure.a~0
97 matches
Mail list logo
