On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> The tricky bit is that although both the host and target are always
> x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
> much older systems than the one I build it on.
>
> I have a sysroot I've created (downloading RPMs from
On Wed, 11 Mar 2020 at 16:46, Paul Smith wrote:
>
> On Wed, 2020-03-11 at 14:17 +, Jonathan Wakely wrote:
> > On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> > > The tricky bit is that although both the host and target are always
> > > x86_64/i686 GNU/Linux systems, I need the generated
On Thu, 16 Apr 2020 at 21:02, Baumanns via Gcc wrote:
>
> Hello gcc Team,
>
> currently I work on some very modern c++ projects based on c++20. For my
> tests I would like to compile my code with all three major compilers: g++,
> msvc and llvm/clang to test the latest features (like co_yield).
>
On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc wrote:
> And can certainly score a positive though not a definite rating in spam
> qualification. I don't think we ought to encourage bad IT management
> practices by trying to adapt to them too hard and hurting ourselves (our
> workflow)
On Mon, 16 Mar 2020 at 14:13, Martin Liška wrote:
>
> On 3/16/20 2:54 PM, Alexander Monakov wrote:
> > Are you trying to copy from the raw message representation?
>
> Exactly.
That's never been reliable.
On Wed, 25 Mar 2020 at 20:29, Bernd Edlinger wrote:
>
> -On 3/25/20 7:55 PM, Christopher Faylor wrote:
> > On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
> >> I believe the canonical place for the "Linux suff" mailing lists these
> >> days is
> >> lore.kernel.org, powered by
On Wed, 25 Mar 2020 at 22:38, Andrew Briand wrote:
>
> Hello,
>
> I am an undergrad interested in extending GCC’s static analysis pass for GSoC
> 2020. In particular, I’m interested in adding C++ support.
>
> The selected project ideas list mentions adding new/delete checking and
> exception
On Fri, 3 Apr 2020 at 18:54, Bernd Edlinger wrote:
>
> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
> >>
> >> Hi,
> >>
> >> I have a question about the gcc-testresults mailing list,
> >> that is I see everyone using:
> >>
> >> [releases/gcc-9
On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger wrote:
>
>
>
> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
> >>
> >> Hi,
> >>
> >> I have a question about the gcc-testresults mailing list,
> >> that is I see everyone using:
> >>
> >>
On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
>
> Hi,
>
> I have a question about the gcc-testresults mailing list,
> that is I see everyone using:
>
> [releases/gcc-9 revision
> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839]
>
> or
>
> [master revision
>
On Fri, 3 Apr 2020 at 19:40, Bernd Edlinger wrote:
>
>
>
> On 4/3/20 7:56 PM, Jonathan Wakely wrote:
> > On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger
> > wrote:
> >>
> >>
> >>
> >> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> >>> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
>
>
On Wed, 1 Apr 2020 at 23:54, Joseph Myers wrote:
>
> On Wed, 1 Apr 2020, Bernd Edlinger wrote:
>
> > PS: I have a discovered a very serious problem with the mailing lists
> > that must be fixed by our overseers.
> >
> > That is the scubbed attachments.
> >
> > As an example please look at this
On Wed, 1 Apr 2020 at 21:30, Bernd Edlinger wrote:
> @overseeers: PLEASE STOP IMMEDIATELY THAT SCRUBBING
You're emailing the gcc list about the gdb-patches mailing list, and
haven't CC'd the overseers list or the gdb list.
> can you act now, or do you need a CVE number first ?
That doesn't
On Thu, 2 Apr 2020 at 04:35, Bernd Edlinger wrote:
> Regarding the overseers, they repeatedly spoke up on this list,
> but all the time they use an e-mail that bounces.
No. ONE of the overseers replies from a personal email address that
bounces, because as the address clearly says, you should
Please don't cross-post to both the gcc and gcc-help mailing lists.
Either your question is about GCC development, or it's about help
using GCC, not both. Pick one list.
On Thu, 26 Mar 2020 at 08:44, MAHDI LOTFI via Gcc wrote:
>
> Hello
> I am a researcher from Jam Petrochemical company I want
On Wed, 25 Mar 2020 at 05:51, Fangrui Song wrote:
> It is really difficult for a non-subscriber to comment now.
> There are no To: or Cc: fields on Pipermail.
Yes, that's a pain. You can click on the sender's address at the top
of the archived mail (or use
On Wed, 25 Mar 2020 at 04:48, Bernd Edlinger wrote:
>
> Hi,
>
> I do not want to start a flame war.
>
> I just am curious what was the reason why
> the old system cannot be used any more?
The software it ran on hasn't been maintained for years.
> Would there be a possibility to get the old
On Mon, 27 Apr 2020 at 04:54, Laleh Aghababaie via Gcc wrote:
>
> Hi all,
N.B. this is the wrong mailing list for such a question, you should
have used the gcc-help list instead.
> I have a question about the constexpr variable specifications and how the
> compiler handles them. The constexpr
On Thu, 23 Apr 2020 at 12:47, Segher Boessenkool
wrote:
>
> Hi!
>
> On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > but trains for GCC Will likely be very short because of Changelog conflicts.
>
> Why that? Your patches should *not* touch changelog files, ever.
>
> For CI it
On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote:
>
> * Tamar Christina:
>
> > A bit late to the party, but this really doesn't work that well
> > because until recent version of gitlab there was no fairness
> > guarantee. another patch could be approved after mine (with hours
> > in between
On Thu, 23 Apr 2020 at 16:46, Christopher Faylor via Gcc
wrote:
>
> On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote:
> >Hi Frank,
> >
> >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote:
> >>
> >> Hi -
> >>
> A re-subscription attempt to the gcc mailing list just
>
On Thu, 30 Apr 2020 at 19:20, Jakub Jelinek via Gcc wrote:
>
> Status
> ==
>
> We have reached zero P1 regressions today and releases/gcc-10 branch has
> been created; GCC 10.1-rc1 will be built and announced later tonight
> or tomorrow.
> The branch is now frozen for blocking regressions
On Tue, 28 Apr 2020 at 02:26, luo alvin via Gcc wrote:
>
> Dear gnu:
>Here is code:
Please do not report bugs to this mailing list. Bug reports belong in
our Bugzilla database, see https://gcc.gnu.org/bugs/
But this is not a bug anyway, your code has undefined behaviour. You
cannot use
Please move this discussion to the gcc-help mailing list where it
belongs. I'll reply on that list instead.
On Tue, 28 Apr 2020 at 07:07, luo alvin wrote:
>
> Thank you very much for replying me. I also think it not bug,because I test
> this code in the lower version(lower than 8.3.1-3) of
On Thu, 23 Apr 2020 at 18:02, Jonathan Wakely wrote:
>
> On Thu, 23 Apr 2020 at 16:46, Christopher Faylor via Gcc
> wrote:
> >
> > On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote:
> > >Hi Frank,
> > >
> > >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote:
> > >>
> > >> Hi -
>
On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote:
>
> On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote:
> > You're talking about C++ exceptions in general, but the problems you
> > mention seems to be issues with specific implementation properties.
>
> Possibly true, but this argument -
On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote:
> On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote:
> > Anyway... If you have to recompile the toolchain, the problem is still
> > there. Most of the people (like 99,666%) will not do that for various
> > reasons. Some don't know how, some use
On Tue, 12 May 2020 at 09:17, Freddie Chopin wrote:
> The problem with C++ exceptions is that even in the most
> trivial of the programs and even if you don't explicitly
> use/catch/throw them, they instantly eat around 60 kB of ROM and quite
> a lot of RAM. With some hacking you can get down to
On Tue, 12 May 2020 at 11:48, Freddie Chopin wrote:
> To summarize. Current C++ exceptions have very huge, mostly "one-time"
> kind, cost on the size, even if not used at all by the user, mosly due
> to std::terminate() and all the string handling code inside it, as well
> as the unwind tables.
On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc wrote:
>
> I've changed the subject to match the 2015, 2017 and 2018 email threads.
>
> On May 13, 2020, at 3:26 AM, Thomas Schwinge wrote:
> >
> > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > vs. "new") that ought
On Tue, 5 May 2020 at 15:42, Victor Rodriguez via Gcc wrote:
> Has someone found issues on common packages that require patches for GCC 10?
Yes, several. See https://gcc.gnu.org/gcc-10/porting_to.html for the
known issues (the first one being a problem with "common" packages!)
On Thu, 7 May 2020 at 07:28, Uros Bizjak via Gcc wrote:
>
> On Thu, May 7, 2020 at 8:16 AM Richard Biener
> wrote:
> >
> > On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc
> > wrote:
> > >Hello!
> > >
> > >I wonder, if the build process really needs to build all multilibs in
> >
On Mon, 18 May 2020 at 13:34, Hongyi Zhao via Gcc wrote:
>
> Hi,
>
> I want to compile qt4 on Ubuntu 20.04 which shipped with the following
> gcc version:
>
> $ gcc --version
> gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
>
> But I'm not sure whether this gcc version is suitable for qt4. Any
> hints for
On Thu, 14 May 2020 at 07:45, Christophe Lyon wrote:
>
> On Wed, 13 May 2020 at 19:44, Jonathan Wakely via Gcc wrote:
> >
> > On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc wrote:
> > >
> > > I've changed the subject to match the 2015, 2017 and 2018 email
On Tue, 12 May 2020, 10:15 Oleg Endo, wrote:
>
> On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote:
> >
> > I actually have to build my own toolchain instead of the one provided
> > by ARM, because to really NOT use C++ exceptions, you have to recompile
> > the whole libstdc++ with
On Sat, 9 May 2020 at 19:56, John Paul Adrian Glaubitz
wrote:
>
> On 5/9/20 12:31 PM, Arseny Solokha wrote:
> > I'd also like to nominate the following two:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
> >
> > which I also
On Sat, 9 May 2020 at 09:56, John Paul Adrian Glaubitz
wrote:
>
> On 5/9/20 10:31 AM, Jonathan Wakely wrote:
> > If you mean for PR reasons or good apeparances, no. But it's wrong to
> > have bugs left open that only refer to unsupported versions of GCC. If
> > none of the supported releases has
On Wed, 18 Mar 2020 at 21:54, Jim Wilson wrote:
>
> I'm one of the old timers that likes our current work flow, but even I
> think that we are risking our future by staying with antiquated tools.
> One of the first things I need to teach new people is now to use email
> "properly". It is a
On Wed, 18 Mar 2020 at 22:45, Joseph Myers wrote:
>
> On Wed, 18 Mar 2020, Jonathan Wakely via Gcc wrote:
>
> > > Some git based projects are using gerrit.
> >
> > Which I looked into previously and decided I didn't like it. If I
> > recall correctly, gerrit has
N.B. the CC list has got too big and is causing posts to this thread
to be held for moderator approval.
On Fri, 20 Mar 2020 at 07:16, jf wrote:
>
> Hi all,
>
> I'm a printf-like function lover. I always found that better than doing
> something like out << "blabla : " << var1 << ", blabla" << etc.
>
> Now, I use a lot of different platforms and to be portable, I'm supposed
> to use PRIxxx constants
On Sat, 21 Mar 2020 at 15:24, PRIYANSHU ARYA via Gcc wrote:
>
> Dear Sir/ma'am:
>
> I'm a new learner wanted to contribute in your open source project so i
> want to know how to start contributing in your open source projects and
> want to know all the requirements for contributing in your
On Mon, 16 Mar 2020 at 21:15, David Korczynski wrote:
>
> Hi!
>
> My name is David Korczynski and I have been doing some work on
> integrating fuzzing by way of OSS-Fuzz into the gcc project. This came
> out of fuzzing libiberty within the binutils project where we found
> several bugs within
On Sat, 9 May 2020 at 08:15, John Paul Adrian Glaubitz
wrote:
>
> Hi!
>
> On 5/9/20 12:15 AM, Segher Boessenkool wrote:
> > I can do both, if you want, or just the first group? Your choice.
> >
> > But let's hear other opinions first.
>
> These bugs document the current issues with the backend
On Tue, 19 May 2020 at 17:19, Gerald Pfeifer wrote:
>
> I hope the offer by some of you to support people like me who Git
> appears to hate with a fervor still stands? ;-)
>
> And I volunteer to enhance our documentation if it appears useful.
>
>
> Usecase: I've got a patch approved and pushed to
On Tue, 19 May 2020 at 17:36, Jonathan Wakely wrote:
>
> On Tue, 19 May 2020 at 17:19, Gerald Pfeifer wrote:
> >
> > I hope the offer by some of you to support people like me who Git
> > appears to hate with a fervor still stands? ;-)
> >
> > And I volunteer to enhance our documentation if it
N.B. I've redirected this to gcc-help where it's on-topic. Please
answer there instead.
On Wed, 20 May 2020 at 22:35, Ted Toth via Gcc wrote:
>
> I work on a project with a large code base some of which is pretty old. We
> are discussing adding -std=gnu++11 to our g++ compiles to be able to use
On Tue, 19 May 2020 at 09:26, Jakub Jelinek via Gcc wrote:
>
> On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
> > > I find this format more helpful for the reasons below so unless your
> > > script can be tweaked to do something similar I'd like to be able to
> > > continue to use
On Tue, 19 May 2020 at 11:44, Martin Liška wrote:
>
> Hello.
>
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison
On Tue, 19 May 2020 at 17:13, Joseph Myers wrote:
>
> On Tue, 19 May 2020, Martin Liška wrote:
>
> > On 5/19/20 10:11 AM, Martin Liška wrote:
> > > Can you please share how do you do it? It would be easy to add it.
> >
> > I added the feature via --fill-up-bug-titles option. It uses common
> >
On Tue, 19 May 2020 at 23:19, Jonathan Wakely wrote:
>
> On Tue, 19 May 2020 at 11:44, Martin Liška wrote:
> >
> > Hello.
> >
> > We've just installed server git hooks that verify git messages
> > for a correct ChangeLog format. For a limited time period, please
> > still apply ChangeLog changes
On Fri, 22 May 2020 at 06:54, Haoxin Tu via Gcc wrote:
>
> Hi, there!
>
> I am new for using GCC mail list, please forgive me if something is wrong.
You're using the wrong mailing list, see
https://gcc.gnu.org/lists.html which says this question should be on
the gcc-help list. Please send any
On Sun, 6 Sep 2020 at 16:23, Iain Sandoe wrote:
>
> Hi
>
> g++.dg/abi/guard3.C
>
> has:
>
> extern "C" int __cxa_guard_acquire();
>
> Which might not be a suitable declaration, depending on how the ‘extern
> “C”’ is supposed to affect the function signature generated.
>
> IF, the extern C should
Sorry for the slow reply to this.
On Fri, 7 Aug 2020 at 22:14, Michael Meissner wrote:
>
> One issue with doing the transition is what mangling should be used with the
> new long double.
>
> At the moment, the current mangling is:
> long double "g"
> __float128
On Mon, 7 Sep 2020 at 23:53, Bruce Korb via Gcc wrote:
>
> On Mon, Sep 7, 2020 at 3:45 PM Florian Weimer wrote:
> >
> > * Bruce Korb via Gcc:
> >
> > > I don't write a lot of code anymore, but this sure seems like a
> > > gratuitous irritation to me. I've been using
> > >
> > > // FALLTHRU
On Tue, 8 Sep 2020 at 17:33, Bruce Korb wrote:
>
> On Tue, Sep 8, 2020 at 7:36 AM Jakub Jelinek wrote:
> > > The fall through comment was polluted with a colon that I hadn't noticed,
> > > as in:
> > >
> > > /* FALLTHROUGH: */
> > >
> > > and your fall through regex doesn't allow for that.
On Mon, 7 Sep 2020 at 09:18, Iain Sandoe wrote:
>
> Perhaps the PR should be reopened with “accepts invalid”?
My impression from the PR is that the reporter was using a different
ABI, where the name isn't reserved. Maybe the testcase should only be
accepted with -fno-threadsafe-statics or
On Mon, 7 Sep 2020, 10:34 Jakub Jelinek, wrote:
> On Mon, Sep 07, 2020 at 10:27:13AM +0100, Jonathan Wakely via Gcc wrote:
> > On Mon, 7 Sep 2020 at 09:18, Iain Sandoe wrote:
> > >
> > > Perhaps the PR should be reopened with “accepts invalid”?
> &
On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc wrote:
> However, it might be good that someone starts a page called
> 'type_qualifiers(7)' or something like that.
Who is this for? Who is trying to learn C from man pages? Should
somebody stop them?
On Fri, 2 Oct 2020 at 13:19, Joel Brobecker wrote:
>
> > > I can confirm I was able to delete a branch on remove server:
> > >
> > > $ git push origin --delete refs/users/marxin/heads/gfc-trailing-spec
> > > To git+ssh://gcc.gnu.org/git/gcc.git
> > > - [deleted]
On Fri, 2 Oct 2020 at 08:14, Martin Liška wrote:
>
> On 10/2/20 2:52 AM, Joel Brobecker wrote:
> >>> I wonder I can get the branch moved, so I can do the benchmarking :)
> >>> Any suggestions how to do that?
> >
> > I just installed a small patch, hot-fix style which I am hoping will
> > fix your
On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages)
wrote:
>
> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote:
> >
> > On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc
> > wrote:
> > > However, it might be good that someone starts a page called
> > > 'type_qualifiers(7)' or
On Fri, 2 Oct 2020 at 09:36, Alejandro Colomar via Gcc wrote:
>
> Hi Paul,
>
> On 2020-10-01 19:38, Paul Eggert wrote:
> > On 10/1/20 7:35 AM, Alejandro Colomar via Libc-alpha wrote:
> >> +The narrowest signed integer type
> >> +of a width of at least N bits,
> >
> > Motivation is missing
On Thu, 1 Oct 2020 at 16:51, Alejandro Colomar via Gcc wrote:
>
> Hi Michael,
>
> On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote:
> > Hello Alex,
> >
> > On 10/1/20 5:06 PM, Alejandro Colomar wrote:
> >> Hello Michael,
> >>
> >> This type is very special,
> >> so I will probably have
On Fri, 2 Oct 2020 at 14:20, Alejandro Colomar wrote:
>
>
>
> On 2020-10-02 15:06, Jonathan Wakely wrote:
> > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages)
> > wrote:
> >>
> >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely
> wrote:
> >>>
> >>> On Fri, 2 Oct 2020 at 09:28,
On Mon, 5 Oct 2020 at 17:12, Stefan Kanthak wrote:
>
> The implementation of the functions __absv?i2(), __addv?i3() etc. for
> trapping integer overflow provided in libgcc2.c is rather bad.
> Same for __cmp?i2() and __ucmp?i2()
>
> GCC creates awful to horrible code for them (at least for AMD64
On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote:
>
> Hi
>
> being deprecated for nearly 20 years of C++ standards has
> always been a bit baffling to me. I'm used to thingis being deprecated and
> then removed a bit faster than that.
>
> It is still deprecated in C++17 but does not appear in
On Fri, 9 Oct 2020 at 15:13, Joel Sherrill wrote:
>
>
>
> On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely wrote:
>>
>> On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote:
>> >
>> > Hi
>> >
>> > being deprecated for nearly 20 years of C++ standards has
>> > always been a bit baffling to me. I'm
On Wed, 19 Aug 2020 at 15:24, Bernd Eggen via Gcc wrote:
>
> Hello,
>
> I've come across an internal compiler error (in GFortran), concerning the
> function NINT(),
Then you should be reporting it to Bugzilla, not to this mailing list.
> Please submit a full bug report,
> with preprocessed
On Mon, 24 Aug 2020 at 15:39, Philip R Brenan via Gcc wrote:
>
> Hi *GCC*:
>
> Given the example for *alloca*() at:
>
> https://www.gnu.org/software/libc/manual/html_mono/libc.html#Alloca-Example
>
> May I recommend that the code below portrays the use of alloca() more
> completely in that it
On Mon, 28 Sep 2020 at 23:15, Joseph Myers wrote:
>
> On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:
>
> > > I'm not sure which patch in the series is supposed to be implementing
> > > that, but C requires that long double and _Float128 are distinct types (so
> > > you can use _Generic to
On 21/09/20 23:52 +0200, Alejandro Colomar via Libstdc++ wrote:
I have developed this draft code, the C++ part being based on what you
wrote.
I am a C programmer, and my C++ is very basic, and I tend to write
C-compatible code when I need C++, so I can't really write the C++
part.
I tested
On 22/09/20 11:10 +0200, Alejandro Colomar via Libstdc++ wrote:
[[ CC += LKML ]]
Thanks for all your input. I learned some C++ :)
The following code works for all C and C++ standards:
g++ --std={c++98, c++03, c++11, c++14, c++17, c++20}
gcc --std={c89, c99, c11, c18, c2x}
With `-Wall -Wextra
On Wed, 23 Sep 2020 at 16:55, Christophe Lyon via Gcc wrote:
>
> On Wed, 23 Sep 2020 at 14:33, David Edelsohn wrote:
> >
> > On Wed, Sep 23, 2020 at 8:26 AM Christophe Lyon via Gcc
> > wrote:
> > >
> > > On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
> > > wrote:
> > > >
> > > > On 23/09/2020
On 25/09/20 16:10 +0200, Alejandro Colomar wrote:
On 2020-09-25 15:20, Alejandro Colomar wrote:
'nitems()' calculates the length of an array in number of items.
It is safe: if a pointer is passed to the macro (or function, in C++),
the compilation is broken due to:
- In >= C11:
On 25/09/20 18:30 +0200, Alejandro Colomar via Libstdc++ wrote:
I have a similar number of ARRAY_SIZE() and ARRAY_SSIZE().
I could have '#define snitems(arr) ((ptrdiff_t)nitems(arr))' in my projects,
but is it really necessary?
The barrier for adding something to glibc headers should be a LOT
On 25/09/20 18:30 +0200, Alejandro Colomar via Libstdc++ wrote:
Hello Jonathan,
On 2020-09-25 16:48, Jonathan Wakely wrote:
Do you really need to provide snitems?
Users can use (ptrdiff_t)nitems if needed, can't they?
They can, but that adds casts in the code,
which makes longer lines that
On 22/09/20 12:25 -0400, Rich Felker wrote:
Is there really a reason to want a nonstandard macro like this to do
something that's already trivial to do in the base language and has a
standard idiom (sizeof x / sizeof *x)?
IMHO no.
On Thu, 1 Oct 2020 at 12:15, Alejandro Colomar wrote:
>
>
>
> On 2020-10-01 13:07, Jonathan Wakely wrote:
> [...]
> >> +Notes:
> >> +Some of these types may be optimized for size
> >> +instead of raw performance.
> >
> > I'm not sure what this tells me as a programmer. What does "raw
> >
On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc wrote:
>
> Hi,
>
> I'm documenting the system data types in the man-pages,
> and I was writing now about these types.
>
> I'm showing below both the rendered output and the source I have right now.
>
> Would you add anything to it?
>
> And I
On Thu, 1 Oct 2020 at 14:22, Alejandro Colomar wrote:
>
>
>
> On 2020-10-01 14:54, Szabolcs Nagy wrote:
> > The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
> >> Here is the rendered intmax_t:
> >>
> >> intmax_t
> >>Include: . Alternatively, .
> >>
> >>A signed integer
On Thu, 1 Oct 2020 at 11:25, Alejandro Colomar via Gcc wrote:
>
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 76
> 1 file changed, 76 insertions(+)
>
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index
On Thu, 1 Oct 2020 at 12:24, Alejandro Colomar wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 12:50, Jonathan Wakely wrote:
> >> Ok, I thought that GCC is part of the GNU project, but I don't know how
> >> much...
> >> I'll use "When using GCC," :)
> >
> > It is, but the GNU project is a large
You get a nasty error like:
$ git push origin -d refs/users/redi/heads/calendar
remote: *** Update rejected by this repository's hooks.update-hook script
remote: *** (/git/gcc.git/hooks-bin/update_hook):
remote: *** fatal: bad object
remote: *** Traceback
On Thu, 1 Oct 2020 at 11:14, Alejandro Colomar wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 11:57, Jonathan Wakely wrote:
> > On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc
> wrote:
> >>
> >> Hi,
> >>
> >> I'm documenting the system data types in the man-pages,
> >> and I was writing
On Thu, 1 Oct 2020 at 18:38, Joseph Myers wrote:
>
> On Thu, 1 Oct 2020, Jonathan Wakely via Gcc wrote:
>
> > The problem is that the script doesn't check whether the new_object is
> > 0.
> >
> > I think we want something like this:
> >
> >
Your question is inappropriate on this mailing list, and I already
answered it on the gcc-help list anyway.
On Thu, 28 May 2020 at 18:22, kiran kumar vangara via Gcc
wrote:
>
> Team,
>
> We have been compiling cpp files with g++ compiler on Redhat Linux OS
> machine and as part of this -mt
On Sat, 30 May 2020 at 21:09, Harald Anlauf wrote:
>
> Dear experts,
>
> let's assume I need to backport a series of commits on master to a release
> branch.
> In the release branch, this series of commits should become a single commit.
>
> With bare git, there is "cherry-pick -n" that seems to
On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc wrote:
>
> Hi -
>
> > git pull from the GCC and Glibc repos is failing for me with the error
> > below. It worked fine last week and I haven't made any changes to my
> > ssh keys.
>
> And are you logging in from the same workstation with
On Mon, 1 Jun 2020 at 20:16, Martin Sebor via Gcc wrote:
>
> On 6/1/20 12:10 PM, Frank Ch. Eigler wrote:
> > Hi -
> >
> >> git pull from the GCC and Glibc repos is failing for me with the error
> >> below. It worked fine last week and I haven't made any changes to my
> >> ssh keys.
> >
> > And
On Mon, 25 May 2020 at 23:50, Jakub Jelinek via Gcc wrote:
>
> Hi!
>
> I've turned the strict mode of Martin Liška's hook changes,
> which means that from now on no commits to the trunk or release branches
> should be changing any ChangeLog files together with the other files,
> ChangeLog entry
On Mon, 1 Jun 2020 at 12:56, Thomas Koenig wrote:
>
> Hi Martin,
>
> > For now, I would recommend doing 1:1 backports. Otherwise, you'll need
> > to merge
> > all ChangeLog entries in a format the server hook accepts. That can
> > require some
> > work.
>
> If the first commit caused a
On Mon, 1 Jun 2020 at 13:25, Thomas Koenig wrote:
>
> Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
> > It will only "keep" it for a matter of seconds, between that
> > backported commit and the backported fix. And unless you push the
> > first com
On Mon, 1 Jun 2020 at 20:46, Martin Sebor wrote:
>
> On 6/1/20 1:25 PM, Jonathan Wakely wrote:
> > On Mon, 1 Jun 2020 at 20:16, Martin Sebor via Gcc wrote:
> >>
> >> On 6/1/20 12:10 PM, Frank Ch. Eigler wrote:
> >>> Hi -
> >>>
> git pull from the GCC and Glibc repos is failing for me with
On Fri, 22 May 2020 at 19:15, Thomas Koenig via Gcc wrote:
>
> Hi,
>
> what's currently in trunk (as of a few hours ago) fails for me with
>
>File "contrib/mklog.py", line 36, in
> from unidiff import PatchSet
> ModuleNotFoundError: No module named 'unidiff'
>
> I think this is an error
On Wed, 20 May 2020 at 09:44, Rasmus Villemoes wrote:
>
> Hi
>
> The condition variable implementation added in commit 806dd0472f56fd
> seems to fall into the trap(s) pointed out in the paper
>
> http://birrell.org/andrew/papers/ImplementingCVs.pdf
>
> in particular, the "if no thread is
On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer wrote:
>
> On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> > The libstdc++ manual is written in Docbook XML, but we commit both the
> > XML and generated HTML pages to Git. Sometimes a small XML file can
> > result
On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely wrote:
>
> On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
> >
> > On 6/2/20 1:48 PM, Martin Liška wrote:
> > > I tend to this approach. Let me prepare a patch candidate for it.
> >
> > There's a patch for it. Can you please Jonathan take a look?
>
>
On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
>
> On 6/2/20 1:48 PM, Martin Liška wrote:
> > I tend to this approach. Let me prepare a patch candidate for it.
>
> There's a patch for it. Can you please Jonathan take a look?
Looks great, thanks!
+if name not in
On Tue, 2 Jun 2020 at 07:44, Martin Liška wrote:
>
> On 6/1/20 7:24 PM, Jonathan Wakely wrote:
> > On Mon, 25 May 2020 at 23:50, Jakub Jelinek via Gcc wrote:
> >>
> >> Hi!
> >>
> >> I've turned the strict mode of Martin Liška's hook changes,
> >> which means that from now on no commits to the
1 - 100 of 4472 matches
Mail list logo
