On Thu, 3 Jan 2019 at 21:18, Joseph Howard wrote:
>
> Request for mtrace_setpath
I think you should have sent this to glibc, which is a completely
separate project to GCC.
See https://www.gnu.org/software/libc/libc.html
On Mon, 7 Jan 2019 at 15:42, nick wrote:
>
> Greetings All,
>
> I was wondering as I sent a patch before the holidays if I should resend it
> as I did not get any replies.
Which patch? I don't see any patch from you that didn't get some replies.
On Mon, 7 Jan 2019 at 15:51, nick wrote:
>
>
>
> On 2019-01-07 10:44 a.m., Jonathan Wakely wrote:
> > On Mon, 7 Jan 2019 at 15:42, nick wrote:
> >>
> >> Greetings All,
> >>
> >> I was wondering as I sent a patch before the holidays i
On Tue, 8 Jan 2019 at 13:16, Rasmus Villemoes wrote:
>
> I don't see a gcc-7_4_0-release tag in the git mirror. Is that intentional?
Tags have to be manually added to the git mirror, they don't happen as
part of the release process.
I've added it now.
On Wed, 9 Jan 2019 at 08:41, Tom de Vries wrote:
>
> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
>
> The current formulation for the description of Stage 4 here (
> https://gcc.gnu.org/develop.html ) is:
> ...
> During this period, the only (non-documentation) changes t
On Wed, 9 Jan 2019 at 09:50, Andrew Haley wrote:
> I don't agree. Sometimes vectorization is critical. It would be nice
> to have a warning which would fire if vectorization failed. That would
> surely help the OP.
Dave Malcolm has been working on something like that:
https://gcc.gnu.org/ml/gcc-pa
On Thu, 10 Jan 2019 at 09:25, Kay F. Jahnke wrote:
> Documentation is absolutely essential. If there is lots of development
> in autovectorization, not documenting this work in a way users can
> simply find is - in my eyes - a grave omission. The text
> 'Auto-vectorization in GCC' looks like it has
On Tue, 22 Jan 2019 at 18:46, Marc Glisse wrote:
>
> On Tue, 22 Jan 2019, Thomas Koenig wrote:
>
> > Hi,
> >
> > What would people think about a -Weverything option which turns on
> > every warning there is?
> >
> > I think that could be quite useful in some circumstances, especially
> > to find p
On Tue, 22 Jan 2019 at 18:56, Jonathan Wakely wrote:
>
> On Tue, 22 Jan 2019 at 18:46, Marc Glisse wrote:
> >
> > On Tue, 22 Jan 2019, Thomas Koenig wrote:
> >
> > > Hi,
> > >
> > > What would people think about a -Weverything option which t
On Wed, 23 Jan 2019 at 07:17, Thomas König wrote:
>
>
> > Am 23.01.2019 um 01:53 schrieb Martin Sebor :
>
> > I often wish GCC supported it -- not in the hopes of finding every
> > conceivable bug or transgression against known coding styles but
> > as a tool to discover warnings that have to be
There's a patch to add __builtin_dynamic_object_size to clang:
https://reviews.llvm.org/D56760
It was suggested that this could be done via a new flag bit for
__builtin_object_size, but only if GCC would support that too
(otherwise it would be done as a separate builtin).
Is there any interest in
On Wed, 23 Jan 2019 at 11:21, Franz Sirl wrote:
> The LLVM devs may hate it, but as maintainer of a multi-platform
> multi-compiler automated build framework I _love_ -Weverything. It's
> much easier to handle a compiler upgrade this way without missing any
> new warnings not enabled by -Wall -Wext
On Fri, 25 Jan 2019 at 13:48, Warren D Smith wrote:
>
> "foo" is a type that is a struct containing a uint64_t field x[4]
> (among other things).
>
> bool Proc( const foo *dog ){
>uint64_t *a, *b;
>a = dog->x; // pointer a now points to dog->x[0]
>b = something else;
>if( *a ==
On Sun, 27 Jan 2019 at 13:56, N.M. Maclaren wrote:
>
> On Jan 23 2019, Thomas König wrote:
> >
> >> Am 23.01.2019 um 12:36 schrieb Jonathan Wakely :
> >>
> >> When there are new warnings that aren't enabled by -Wall -Wextra,
> >> there's
On Thu, 7 Feb 2019 at 21:16, John Marino wrote:
>
> Hi Guys,
> I guess back in July, the release of 8.3 was expected by the end of
> 2018. Now it's February. Is the next release of the 8 series imminent?
> if not, any idea when it might come?
See https://gcc.gnu.org/ml/gcc/2019-02/msg00027.htm
On Wed, 13 Feb 2019 at 16:18, Chang-Hsin Daniel Chen
wrote:
>
> Hi GCC,
>
> This is Daniel. I use fedora 29 and have install gcc-8.2.0 into the system.
Why? Fedora 29 already has GCC 8.2.1
How did you install it? What commands did you run?
>However, I still cannot see GCC on the list what I do
Oh and this is the wrong mailing list, please use gcc-h...@gcc.gnu.org instead.
On Wed, 13 Feb 2019 at 17:11, Jonathan Wakely wrote:
>
> On Wed, 13 Feb 2019 at 16:18, Chang-Hsin Daniel Chen
> wrote:
> >
> > Hi GCC,
> >
> > This is Daniel. I use fedora 29 an
e attached patch, committed to trunk as obvious.
commit 03361e13c38ad815e6600e279eea884e520b356e
Author: Jonathan Wakely
Date: Tue Feb 19 19:12:11 2019 +
* config/gcn/gcn.c (print_operand): Fix typo.
diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index bd8ea55ec03..1dd2
On Wed, 27 Feb 2019 at 09:06, wrote:
>
> Hello,
>
> I have questions about the GCC Runtime Library Exception.
>
> When an equipment vendor distributes an update of shared gcc runtime
> libraries (e.g. libgcc_s.so, libstdc++.so) to the shipped equipment
> and when the equipment has applications whi
On Fri, 8 Mar 2019 at 11:28, Vanida Plamondon
wrote:
>
> I realise that, however, debian packages seem to use multiple build
> systems (automake, dh_automake, ninja, etc.), and have no standard
> (that is adhered to), for setting up each build environment.
> Additionally, some packages seem to thr
On Fri, 8 Mar 2019 at 22:00, Vanida Plamondon
wrote:
>
> OK, so it seems I need to give more information to clarify what I am
> trying to do.
>
> I am not invoking or configuring gcc directly.
(If you're creating a toolchain then surely you're configuring GCC.)
> I am creating debian
> source co
On Sat, 9 Mar 2019, 02:23 Eric Gallager, wrote:
> On 3/8/19, David Brown wrote:
> > On 09/03/2019 00:06, Joseph Myers wrote:
> >> On Fri, 8 Mar 2019, Joel Sherrill wrote:
> >>
> >>> Can gcc report when the parameter name in a C prototype
> >>> does not match that used in the implementation?
> >>
On Sat, 9 Mar 2019 at 17:27, Segher Boessenkool
wrote:
>
> On Sat, Mar 09, 2019 at 08:30:19AM +, Jonathan Wakely wrote:
> > On Sat, 9 Mar 2019, 02:23 Eric Gallager, wrote:
> > > How would it handle the case where the parameter name is missing
> > > entirely from
On Sat, 9 Mar 2019 at 17:51, Joel Sherrill wrote:
> And not checking system headers is reasonable in general. For RTEMS though,
> we are implementing those system headers and do follow the names in the
> standards for parameter names in the implementation.
Using exactly the names from the standa
On Sun, 17 Mar 2019, 00:21 nick, wrote:
> Greetings,
>
> I've been busy so this probably has been fixed in since I last worked on
> it:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395
>
> I was using these instructions to try and get a trace:
> https://www.gnu.org/software/gcc/bugs/segfault.
On Sat, 23 Mar 2019 at 15:15, Vinaya Dandur wrote:
>
> Dear Developers,
>
> It is unfortunate that I am facing this issue and to my bad luck, I do not
> see an answer on google as well.
>
> Problem:
>
> I have downloaded and compiled GCC 4.8.1 with the below configure options
> on SLES 12 and post
On Sat, 23 Mar 2019 at 16:25, Vinaya Dandur wrote:
>
> Hi Jonathan,
>
> Thank you. Yes it is not an issue with the GCC but the TRAP_BRKPT is defined
> in signal.h which the GCC could include but can't find the constant mentioned.
Your code doesn't include , how do you expect it to find
anything
On Mon, 25 Mar 2019 at 12:39, Nicholas Krause wrote:
>
> Not sure if this is a correct fix to this bug found here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
> comments are welcome. If a backtrace is required please
> let me know. I am just sending it to the development list
> for re
On Mon, 25 Mar 2019 at 13:26, nick wrote:
>
>
>
> On 2019-03-25 9:25 a.m., Jonathan Wakely wrote:
> > On Mon, 25 Mar 2019 at 12:39, Nicholas Krause wrote:
> >>
> >> Not sure if this is a correct fix to this bug found here:
> >> https://gcc.gnu.org/bug
On Thu, 4 Apr 2019 at 10:56, Peter Olsson wrote:
>
> Hello,
>
> I often want to link to specific compiler options in your online docs
> but the problem is that the named anchors are placed after the name of
> the option so when the link is clicked it will only show the
> description.
>
> Example:
>
On Thu, 4 Apr 2019 at 11:10, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2019 at 10:56, Peter Olsson wrote:
> >
> > Hello,
> >
> > I often want to link to specific compiler options in your online docs
> > but the problem is that the named anchors are placed afte
On Thu, 4 Apr 2019 at 13:38, Taiki Akita wrote:
>
> Currently the subversion repository and the rsync server is inaccessible.
> Please check.
>
>
> $ svnsync sync file://`pwd`
> svnsync: E170013: Unable to connect to a repository at URL
> 'svn://gcc.gnu.org/svn/gcc'
> svnsync: E210002: Network con
On Fri, 5 Apr 2019 at 04:50, Supriya Palli wrote:
> My name is Supriya Palli and I am a first-year Computer Science B.S.
> student at Florida State University. I currently finishing up a C++ course
> in Object Oriented Programming and am looking for ways to continue my
> learning in C++ and other t
For options that can be used as -foo or -foo=level we have a variety
of different styels for documenting what the default level is. See
below for several examples. I find this a bit confusing when try to
see what it means to use the option without a level.
Do we want to pick a style and try to be
On 10/04/19 08:42 -0400, Nathan Sidwell wrote:
On 4/10/19 7:13 AM, Jonathan Wakely wrote:
For options that can be used as -foo or -foo=level we have a variety
of different styels for documenting what the default level is. See
below for several examples. I find this a bit confusing when try to
On Tue, 16 Apr 2019 at 04:06, Justin Bassett wrote:
>
> The following code will emit a warning with -Wattributes:
>
> [[some_ns::some_attribute]]
> void call_me();
>
> :2:14: warning: 'some_ns::some_attribute' scoped attribute
> directive ignored [-Wattributes]
> 2 | void call_me();
> |
You're Doing It Wrong.
See https://gcc.gnu.org/lists.html#subscribe
On Thu, 25 Apr 2019 at 19:38, Jakub Jelinek wrote:
>
> Status
> ==
>
> We have reached zero P1 regressions today and branches/gcc-9-branch has
> been created; GCC 9.1-rc1 will be built and announced likely tomorrow.
> The branch is now frozen for blocking regressions and documentation
> fixes
On Fri, 26 Apr 2019 at 17:16, Jakub Jelinek wrote:
>
> The first release candidate for GCC 9.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190426/
> ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190426
>
> and shortly its mirrors. It has been generated from SVN revisi
On Tue, 30 Apr 2019 at 14:12, Jakub Jelinek wrote:
>
> The second release candidate for GCC 9.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430/
> ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430
>
> and shortly its mirrors. It has been generated from SVN revis
On Sat, 4 May 2019 at 08:42, Andrew Roberts wrote:
> 3) Stdlibc++
It's libstdc++.
> Release notes reference parallel algorithms requiring TBB 2018 or newer,
> again guess work suggests this is Thread Building Blocks. It would be
> nice to explicitly say that, and provide links to implementations.
On Sun, 12 May 2019 at 15:54, Iain Sandoe wrote:
>
> Right now, we don’t install a “cc” [we install gcc] but we do install “c++”
> [ we also install g++, of course].
Some GNU/Linux distros do install /usr/bin/cc as a sym link to GCC.
> Some configure scripts (and one or two places in the tests
I'm including gcc@gcc.gnu.org here for visibility, but the discussion
really belongs on the libstdc++ list so please limit replies to there.
I'd like to discuss deprecating (and eventually removing) the
libstdc++-v3/include/ext/pb_ds extensions. For information on them see
https://gcc.gnu.org/onl
On Wed, 15 May 2019 at 10:24, Shubham Narlawar wrote:
> I tried to send you Aligned patch and one csmith program but it bounces
> back. I don't know why it happened. Sorry for sending mail 5 times. Sure, I
> will reply to single thread.
If you're trying to send email to the GCC lists you need to u
On Sat, 8 Jun 2019 at 19:03, Akshat Garg wrote:
>
> On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou wrote:
>
> > > Makefile:2323: recipe for target 'do-check' failed
> > > make: *** [do-check] Error 2
> > > make: Target 'check' not remade because of errors.
> > >
> > > Please, can anyone let me know
On Sat, 8 Jun 2019 at 21:51, Akshat Garg wrote:
>
>
> On Sun, Jun 9, 2019 at 1:57 AM Jonathan Wakely wrote:
>>
>> On Sat, 8 Jun 2019 at 19:03, Akshat Garg wrote:
>> >
>> > On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou wrote:
>> >
>> &g
On Mon, 10 Jun 2019 at 22:54, L A Walsh wrote:
>
> On 2019/06/09 14:52, Zan Lynx wrote:
> > I am not a GCC developer, just a regular user of C. But I have some
> > comments below:
> >
> > On 6/9/2019 3:21 PM, L A Walsh wrote:
> >
> >> If I have a function returning NULL on error (including EOF).
>
On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote:
>
> Hi!
>
> We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to
> the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar'
> as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release',
> r272156) would
On Tue, 11 Jun 2019 at 16:18, Jonathan Wakely wrote:
>
> On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote:
> >
> > Hi!
> >
> > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to
> > the actual GCC 9.1 release. The GCC
On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge wrote:
>
> Hi!
>
> On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely
> wrote:
> > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge
> > wrote:
> > > We have found that the Git 'gcc-9_1_0-release' tag
On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely wrote:
>
> On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge wrote:
> >
> > Hi!
> >
> > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely
> > wrote:
> > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge
&g
On Sun, 16 Jun 2019 at 14:32, Jakub Jermář wrote:
>
> Hi Richard!
>
> On 6/13/19 1:13 PM, Richard Biener wrote:
> >
> > ia64 has no maintainer anymore so the following deprecates it
> > with the goal of eliminating the port for GCC 11 if no maintainer
> > steps up.
> >
> > OK?
>
> The HelenOS micro
On Wed, 19 Jun 2019 at 20:05, Joel Sherrill wrote:
>
> Hi
>
> I was double checking the C++17 support in GCC for someone and the text at
> this URL states
> the support is experimental and gives the impression that the support is
> incomplete. The table
> of language features now has them all impl
On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge wrote:
>
> Hi!
>
> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely
> wrote:
> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely wrote:
> > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge
> > > wrote:
>
On Thu, 20 Jun 2019 at 13:25, Vladislav Ivanishin wrote:
>
> Jonathan Wakely writes:
>
> > On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge
> > wrote:
> >>
> >> Hi!
> >>
> >> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely
> >
On Fri, 21 Jun 2019 at 11:22, Martin Liška wrote:
>
> On 6/20/19 9:53 PM, Richard Biener wrote:
> > On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška"
> > wrote:
> >> On 6/20/19 4:21 PM, David Edelsohn wrote:
> >>> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote:
>
> Hi.
>
On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> Yes, I would be fine to deprecate that for GCC 10.1
Would it be appropriate to issue a warning in GCC 10.x if the option is used?
I think in most cases the "fix" would be to simply remove the -frepo
option from your makefiles (or other build sys
On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote:
>
> On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
> wrote:
>
> > On Jun 22 2019, Akshat Garg wrote:
> >
> > > I believe I should be getting a warning like:
> > > warning: initialization from incompatible pointer type
> > > [-Wincompatible-pointer
On 24/06/19 19:42 +0200, Richard Biener wrote:
On Mon, Jun 24, 2019 at 4:35 PM Martin Sebor wrote:
On 6/24/19 6:11 AM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 7:17 PM Martin Sebor wrote:
>>
>> On 6/21/19 6:06 AM, Richard Biener wrote:
>>> On Wed, Jun 19, 2019 at 5:15 AM Martin Sebor
On Tue, 25 Jun 2019 at 15:22, Erkam Murat Bozkurt wrote:
> I am always waiting your valuable comments and contributions.
Sending the same email three times (not to mention the identical
copies you've already sent to other non-GCC lists I'm on) is not
necessary. I'm sure you want to promote your so
Jakub Jelinek wrote:
> >>>> On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> >>>>> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> >>>>>> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> >>>>>>> Yes, I woul
On Tue, 2 Jul 2019 at 08:57, Yann Droneaud wrote:
>
> Hi,
>
> I'm sometime in need to "probe" the size, the type, (and less often the
> alignment) of a field inside a structure.
>
> In such case I have to write "ugly" thing like
>
> struct A
> {
> struct
> {
> type_t t;
> } B
On Mon, 8 Jul 2019 at 11:33, wrote:
>
> There was recently a discussion with confusion regarding initialization
> with {} instead of {0} when initializing an empty array or struct. The
> former is not valid in C, but GCC permits it anyway even though it's not
> explained anywhere in the specs:
> c
On Mon, 8 Jul 2019 at 14:53, Unidef wrote:
>
> Is it possible to have c or c++ natively have multi dimensional arrays?
> Instead of using some bourgeois macro function?
This doesn't seem like a question about GCC development, so is
off-topic on this mailing list.
If you want to know if it's pos
On Mon, 8 Jul 2019 at 21:44, Unidef wrote:
> I’m really sorry, I have a medical condition heh
>
> But I meant multidimensional functions
>
This is still the wrong mailing list though.
On Tue, 9 Jul 2019 at 23:44, Alexander Kulkov wrote:
>
> I hoped it would attach to
> https://gcc.gnu.org/ml/libstdc++/2019-05/msg00107.html but it didn't happen
> :(
The links to other messages in a thread only work within the same
month, so you'll never get links between archived posts sent in
d
On Wed, 19 Jun 2019 at 20:07, Jonathan Wakely wrote:
>
> On Wed, 19 Jun 2019 at 20:05, Joel Sherrill wrote:
> >
> > Hi
> >
> > I was double checking the C++17 support in GCC for someone and the text at
> > this URL states
> > the support is experimental
Sorry for the late reply that wasn't "tomorrow".
On Tue, 9 Jul 2019 at 23:40, Alexander Kulkov wrote:
>
> Hi there! I hope, this message will go to where it's expected to go, since
> I'm not really familiar with e-mail threads.
>
> I was the one who brought https://gcc.gnu.org/bugzilla/show_bug.cg
Please don't cross-post to te gcc@ and gcc-bugs@ lists, that's never
appropriate. The gcc@ list is not for reporting bugs, and the
gcc-bugs@ list is for automated emails sent from our Bugzilla
database, also not for reporting bugs. To report a bug please see
https://gcc.gnu.org/bugs/
Thanks.
On M
On Wed, 21 Aug 2019 at 17:50, Paul Koning wrote:
>
>
>
> > On Aug 21, 2019, at 10:57 AM, Alexander Monakov wrote:
> >
> > On Wed, 21 Aug 2019, Paul Koning wrote:
> >
> >> I agree, but if the new approach generates a warning for code that was
> >> written
> >> to the old rules, that would be unfo
On Fri, 23 Aug 2019 at 08:21, Iain Sandoe wrote:
>
> Hi Jim,
>
> > On 23 Aug 2019, at 00:56, Jim Wilson wrote:
> >
> > We got a change request for the RISC-V psABI to define the atomic
> > structure size and alignment. And looking at this, it turned out that
> > gcc and clang are implementing th
On Fri, 23 Aug 2019, 11:13 Iain Sandoe, wrote:
>
>
> > On 23 Aug 2019, at 10:35, Jonathan Wakely wrote:
> >
> > On Fri, 23 Aug 2019 at 08:21, Iain Sandoe wrote:
> >>
> >> Hi Jim,
> >>
> >>> On 23 Aug 2019, at 00:56, Jim Wilson wro
On Tue, 27 Aug 2019 at 09:10, Bin.Cheng wrote:
> And couple of words to the community, we may need to be more active in
> order to attract new developers. IMHO, messages asking for information
> shouldn't need one week to be answered?
This is not really the right place to ask for information about
On Thu, 29 Aug 2019 at 10:15, Christian Schneider
wrote:
>
> Hello,
> I just discovered, that, when using enable_shared_from_this and
> inheriting it privately, this fails at runtime.
> I made a small example:
>
> #include
> #include
> #include
> #include
>
> #ifndef prefix
> #define prefix st
On Thu, 29 Aug 2019 at 11:50, Christian Schneider
wrote:
>
> Am 29.08.19 um 12:07 schrieb Jonathan Wakely:
> > On Thu, 29 Aug 2019 at 10:15, Christian Schneider
> > wrote:
> >>
> >> Hello,
> >> I just discovered, that, when using enable_shared_fro
On Thu, 29 Aug 2019 at 12:43, Jonathan Wakely wrote:
>
> On Thu, 29 Aug 2019 at 11:50, Christian Schneider
> wrote:
> >
> > Am 29.08.19 um 12:07 schrieb Jonathan Wakely:
> > > On Thu, 29 Aug 2019 at 10:15, Christian Schneider
> > > wrote:
> > >>
On Mon, 2 Sep 2019 at 04:44, Gero Peterhoff wrote:
>
> Hello gcc team,
> Thank you first for your great work.
>
> But why are there no IO-routines for u/int128_t?
Because generally, GCC doesn't provide I/O routines, the C library
does. The C library is separate from GCC.
This question would have
On Wed, 4 Sep 2019 at 09:13, Martin Liška wrote:
>
> On 7/9/19 3:00 PM, Martin Liška wrote:
> > Great. Then I'm sending patch that does the functionality removal.
>
> Hi.
>
> The GCC 9.2.0 is released and the version contains a deprecation
> warning for -frepo.
>
> Is it the right time now to remov
On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote:
>
> On 9/5/19 1:09 PM, Richard Biener wrote:
> > So, let's just remove it now?
>
> I'm all for that. May I install the patch?
To be clear, I wasn't objecting to installing the patch now, just
asking whether it would be possible to revert it later i
On Fri, 6 Sep 2019 at 04:26, Tim Rice wrote:
>
>
> I have a use case where I would like gcc to accept -Kthread
> and act as if it was passed -pthread. So -Kthread would
> be a synonym for -pthread.
For a specific target, or universally?
> I am having trouble figuring out how the option processing
On Mon, 9 Sep 2019 at 12:24, Martin Liška wrote:
>
> On 9/9/19 1:08 PM, Jakub Jelinek wrote:
> > On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> >> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> >>> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> On Fri, Sep 06, 20
Answered on gcc-help.
On Tue, 10 Sep 2019 at 08:07, Krishnakant Mehta via gcc-help
wrote:
>
>
> Hi,
>
> We are using gcc compiler toolchain for one of our
>
> ‘Red hat Enterprise Linux 8 ’ based software developmentproject
>
> We would like know whether gcc- series 7 isstill in support from for
On Thu, 12 Sep 2019 at 15:49, Jianbin Fang wrote:
>
> Hello Guys,
Please don't cross-post to gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org,
pick one list, not both.
> I am working on OpenCL for a couple of years, and would like to ask, as for
> GCC, why not taking OpenCL C as a built-in language in
On Tue, 24 Sep 2019 at 21:46, Joseph Myers wrote:
>
> Would anyone like to make any comments on this conversion from CVS to git?
It looks pretty good. I note that the author map just uses the
committer's current email address, meaning I have commits using my
@redhat.com address nearly a decade bef
On Tue, 24 Sep 2019 at 23:15, Joseph Myers wrote:
>
> On Tue, 24 Sep 2019, Jonathan Wakely wrote:
>
> > On Tue, 24 Sep 2019 at 21:46, Joseph Myers wrote:
> > >
> > > Would anyone like to make any comments on this conversion from CVS to git?
> >
> > It
On Wed, 25 Sep 2019 at 11:08, Thomas Schwinge wrote:
>
> Hi!
>
> On 2019-09-24T22:51:18-0400, Jason Merrill wrote:
> > On Tue, Sep 24, 2019 at 6:16 PM Joseph Myers
> > wrote:
> >> On Tue, 24 Sep 2019, Jonathan Wakely wrote:
> >> > On
On Thu, 26 Sep 2019, 05:10 Nicholas Krause, wrote:
>
> Greetings,
>
> I asked about moving to C/C++ 11 as it would make it easier to
>
> allow multithreading support due to having a memory model
>
> alongside other features. Jason Merill mentioned due to it
>
> being so common it may be a good ti
On Wed, 9 Oct 2019 at 08:09, Ming Cheng wrote:
>
> Hi GCC developers:
This is the wrong mailing list for your question. It would be
appropriate on the gcc-help or libstdc++ lists. Please see
https://gcc.gnu.org/lists.html and take any further discussion to one
of those lists.
> Assume I have a cl
On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:
>
> I've done the move of GCC wwwdocs to git (using the previously posted and
> discussed scripts), including setting up the post-receive hook to do the
> same things previously covered by the old CVS hooks, and minimal updates
> to the web pages dea
On Thu, 24 Oct 2019 at 21:50, Andrew Dean via gcc wrote:
>
> TLDR: I'd like to propose adding a dependency on a modern unit testing
> framework to make it easier to write unit tests within GCC. Before I spend
> much more time on it, what sort of buy-in should I get? Are there any people
> in pa
On Tue, 29 Oct 2019 at 12:15, Kumar, Dhanalakshmi
wrote:
>
> Hi Team,
>
>
>
> Could you please provide the latest market version for the Application (as
> mentioned in the below table)
>
>
>
> Business Application Name
>
> Honeywell Version Installed
> GNU COMPILER COLLECTION
> gcc-8 (SUSE Linux)
On Tue, 29 Oct 2019 at 13:02, Jonathan Wakely wrote:
>
> On Tue, 29 Oct 2019 at 12:15, Kumar, Dhanalakshmi
> wrote:
> >
> > Hi Team,
> >
> >
> >
> > Could you please provide the latest market version for the Application (as
> > mentioned in th
On Wed, 30 Oct 2019 at 18:31, Rainer Emrich wrote:
>
> svn: E170013: Unable to connect to a repository at URL
> 'svn://gcc.gnu.org/svn/gcc/trunk'
> svn: E210002: Network connection closed unexpectedly
I think the server throttles the anon svn connections, and that can
make them time out.
Authenti
On Mon, 4 Nov 2019 at 10:29, Richard Earnshaw (lists)
wrote:
>
> With the move to git fairly imminent now it would be nice if we could
> agree on a more git-friendly style of commit messages; and, ideally,
> start using them now so that the converted repository can benefit from this.
>
> Some tool
On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
>
> On Mon, 4 Nov 2019, Segher Boessenkool wrote:
>
> > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote:
> > > I've already proposed a more specific format for libstdc++:
> > > https://gcc.gnu.
On Thu, 7 Nov 2019 at 07:52, Ajumal Abdul Majeed wrote:
>
> Hi,
> I was trying to build GCC and "make all" is failing. Please find the
> config.log below and kindly help me to rectify this issue.
Please use the correct mailing list i.e. gcc-help
https://gcc.gnu.org/lists.html
When you send an em
On Tue, 19 Nov 2019 at 16:31, Segher Boessenkool wrote:
>
> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> > Yep. I don't think we need to worry about getting optimal one-line
> > summaries for ancient commits; something reasonably unique should be plenty.
>
> In that case, how ab
On Tue, 19 Nov 2019 at 23:52, Nicholas Krause wrote:
>
>
>
> On 11/19/19 6:44 PM, Joseph Myers wrote:
> > On Tue, 19 Nov 2019, Segher Boessenkool wrote:
> >
> >> Most of the time after I type "git log" I type "/\<123456\>". We need
> >> to keep a way to easily map SVN revision ids to git commits,
On Tue, 19 Nov 2019 at 23:29, Segher Boessenkool
wrote:
>
> On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote:
> > Jason Merrill :
> > > Well, I was thinking of also giving some clue of what the commit was
> > > about. One possibly cut-off line accomplishes that, a simple revision
>
On Thu, 21 Nov 2019 at 19:11, Andrew Dean via gcc wrote:
>
> I'm curious what other people are doing, because I'm never able to match the
> results that get reported to the test-results list. I created a brand new
> virtual machine running Ubuntu 18.04 (x86_64), installed the prereqs as
> liste
401 - 500 of 2285 matches
Mail list logo
