Re: [EXTERNAL] Re: GCC selftest improvements

Thanks, Dave. We will work on the legal papers with FSF. -- Gaby From: David Malcolm Sent: Tuesday, February 25, 2020 2:10:59 PM To: Modi Mo ; l...@redhat.com ; Nicholas Krause ; Eric Gallager ; Pedro Alves Cc: Gabriel Dos Reis ; Andrew Dean ; gcc

RE: GCC selftest improvements

| -Original Message- | From: Andrew Pinski | Sent: Monday, October 28, 2019 2:52 PM | To: Jakub Jelinek | Cc: Jeff Law ; Segher Boessenkool | ; Gabriel Dos Reis ; | Andrew Dean ; David Malcolm | ; gcc@gcc.gnu.org; r...@cebitec.uni-bielefeld.de; | mikest...@comcast.net; ja...@redhat.com

RE: GCC selftest improvements

| -Original Message- | From: Jeff Law | Sent: Monday, October 28, 2019 12:44 PM | To: Richard Biener ; gcc@gcc.gnu.org; | Gabriel Dos Reis ; Andrew Dean | ; David Malcolm ; | r...@cebitec.uni-bielefeld.de; mikest...@comcast.net; | ja...@redhat.com; Jonathan Wakely | Subject: Re: GCC

RE: GCC selftest improvements

[Andrew] | > GCC has some rather unique requirements, in that we support a great many | > build configurations, some of which are rather primitive - for example, | > requiring just C++98 with exceptions disabled, in that we want to be able to | be | > bootstrappable on relatively "ancient" configu

Re: Dodji Seketeli appointed diagnostics framework maintainer

Gerald Pfeifer writes: | I am happy to announce Dodji Seketeli as diagnostics framework | maintainer. | | Thanks for your contributions and agreeing to fill this role, Dodji! | | And thanks to Gaby for his contributions in this area over the years | and the professional manner he has been init

Now a simple user

Hi, As you probably noticed, I relinquished my GCC maintainer privileges (including the Release Management bit which was still set.) It was a very difficult decision, but I'am taking on a new rôle that is incompatible with my continuing being a GCC maintainer or contributor. I would like to emp

Re: XNEW and consorts

On Thu, Aug 22, 2013 at 8:51 AM, Dodji Seketeli wrote: > Richard Biener a écrit: > >> Support for constructing and destructing GC objects will be another >> story of course. > > Just curious. Does supporting this take more than just defining new and > delete > operators that call ggc_alloc_*/gg

Re: XNEW and consorts

On Thu, Aug 22, 2013 at 7:23 AM, Jakub Jelinek wrote: > On Thu, Aug 22, 2013 at 02:19:39PM +0200, Richard Biener wrote: >> Gabriel Dos Reis wrote: >> >Now that we have transitioned to C++, do we still need to use >> >placebo like XNEW and XNEWVEC in GCC source code pr

XNEW and consorts

Hi, Now that we have transitioned to C++, do we still need to use placebo like XNEW and XNEWVEC in GCC source code proper? (I am not talking about uses in liberty.) Note that XNEW in particular does not work for types with non-default constructors. We introduced these macros so that they take ca

Re: fatal error: gnu/stubs-32.h: No such file

On Wed, Aug 14, 2013 at 11:23 AM, Andreas Schwab wrote: > Alexandre Oliva writes: > >> FWIW, that patch was removed at a later point, for reasons I no longer >> recall. > > See . So, we are over the 48-hour wait for complaints :-/ -- Gaby

Re: i686 elf return values

On Tue, Aug 6, 2013 at 1:46 PM, Nathan Sidwell wrote: > Hi, > i386elf.h defines: > > /* The ELF ABI for the i386 says that records and unions are returned >in memory. */ > > #define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \ > (TYPE_MODE (TYPE) == BLKmode \ > || (VECTOR_MODE_

Re: all_ones_mask_p clarification

On Mon, Aug 5, 2013 at 11:44 AM, Mike Stump wrote: > It is the intent for all_ones_mask_p to return true when 64 bits of ones in > an unsigned type of width 64 when size is 64, right? Currently the code uses > a signed type for tmask, which sets the upper bits to 1, when the value > includes t

Re: resurrecting automatic dependencies

On Sat, Aug 3, 2013 at 4:11 PM, Richard Henderson wrote: > I hope we can merge this soon. Seconded. -- Gaby

Re: New file extension

On Tue, Jul 30, 2013 at 7:42 AM, Marek Polacek wrote: > On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote: >> On 07/30/2013 08:27 AM, Marek Polacek wrote: >> >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: >> >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: >>

Re: New file extension

On Tue, Jul 30, 2013 at 7:28 AM, Martin Jambor wrote: > As far as newbies are concerned, I think that grasping that .c files > are C++ files is one of the easy things to learn about GCC compared to > other necessary knowledge (which is something we should work on). One more oddities compared to

Re: New file extension

On Tue, Jul 30, 2013 at 6:51 AM, Joseph S. Myers wrote: > On Tue, 30 Jul 2013, Basile Starynkevitch wrote: > >> I think it is a good idea now (except perhaps for the very few source files >> which could still be compiled by a plain C, not C++, compiler; maybe we >> don't have anymore them...). > >

Re: New file extension

On Tue, Jul 30, 2013 at 4:04 AM, Marek Polacek wrote: > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >> I do not care very much but I disagree. Having some files with .c >> suffix and some with .cc suffix would imply some sort of difference >> where there is going to be none. >

Re: New file extension

On Tue, Jul 30, 2013 at 6:13 AM, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: >> On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >>> I do not care very much but I disagree. Having some files with .c >>> suffix and some with .cc suffix would imply so

Re: New file extension

On Mon, Jul 29, 2013 at 3:08 PM, Martin Jambor wrote: > On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: >> Hi, >> >> I would like to suggest that new implementation files have >> the '.cc' extension, unless they are meant to be proce

Re: New file extension

On Mon, Jul 29, 2013 at 11:11 AM, Marek Polacek wrote: > On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: >> Hi, >> >> I would like to suggest that new implementation files have >> the '.cc' extension, unless they are meant to be proce

Re: fatal error: gnu/stubs-32.h: No such file

On Sat, Jul 27, 2013 at 6:10 PM, David Starner wrote: >> If the >> latter, did you try spelling it correctly, --disable-multilib >> (singular)? > > I'm sorry, I didn't realize I was misspelling it. Do not feel alone on this one. -- Gaby

Re: fatal error: gnu/stubs-32.h: No such file

On Sat, Jul 27, 2013 at 2:23 PM, Jonathan Wakely wrote: > On 27 July 2013 14:56, David Starner wrote: >> On Fri, Jul 26, 2013 at 2:01 AM, Andrew Haley wrote: >>> GCC can detect at configure time that it will fail. It is clearly >>> a computable problem. It's a matter of someone doing it rather

New file extension

Hi, I would like to suggest that new implementation files have the '.cc' extension, unless they are meant to be processed with a C compiler. (I am not proposing wholesale renaming.) -- Gaby

Re: fatal error: gnu/stubs-32.h: No such file

On Wed, Jul 24, 2013 at 8:44 AM, Andrew Haley wrote: > On 07/24/2013 01:36 PM, Gabriel Dos Reis wrote: >>> There is no resistance whatsoever to making it work with real systems >>> and real workloads. >> >> It does not sound or look like that way. >> >&

Re: fatal error: gnu/stubs-32.h: No such file

> There is no resistance whatsoever to making it work with real systems > and real workloads. It does not sound or look like that way. > The problem is that you don't know that people > running on 64-bit hardware often choose to compile -32 and run -32 > locally. But we know people are running

Re: fatal error: gnu/stubs-32.h: No such file

On Tue, Jul 16, 2013 at 10:11 AM, Jonathan Wakely wrote: > On 16 July 2013 16:04, Gabriel Dos Reis wrote: >> Agreed. It is surprising that we allowed ourselves to >> break the most common target this way. > > It isn't broken, we just don't list one of the prerequis

Re: fatal error: gnu/stubs-32.h: No such file

On Tue, Jul 16, 2013 at 9:35 AM, Bruce Korb wrote: > On Tue, Jul 16, 2013 at 7:25 AM, Andrew Pinski wrote: >>> GCC sources could contain a gnu/stubs-32.h header with an #error and >>> ensure that the right directory to find it is searched when building >>> the target libraries, but only after all

Re: fatal error: gnu/stubs-32.h: No such file

On Tue, Jul 16, 2013 at 4:39 AM, Florian Weimer wrote: > On 07/08/2013 05:39 PM, Bruce Korb wrote: > >> Any solution other than an explanation-less "fatal error: >> gnu/stubs-32.h: No such file" >> is fine. There is no way to translate that message into >> "Either --disable-multilib or else insta

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Thu, Jul 11, 2013 at 12:42 AM, Ryan Hill wrote: > On Wed, 10 Jul 2013 07:49:18 -0500 > Gabriel Dos Reis wrote: > >> If we include a warning in -Wall then it is because we believe it to be >> generally useful and likely to uncover common bugs/mistakes. It is therefore &g

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Wed, Jul 10, 2013 at 4:37 PM, Manuel López-Ibáñez wrote: > To be honest, I agree with Gabriel here. And I would go a step > forward, I would say that we are too timid with the warnings we enable > by default or by -Wall. We should warn more agressively, and let users > disable the warnings tha

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li wrote: > There are two fundamental problems: > 1) uninit warning has false positives. > 2) people disagree what is the expected behavior of -Wall. > > 1) can only be solved by improving the analysis. I think we should focus on this. While we can

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Wed, Jul 10, 2013 at 2:27 PM, Xinliang David Li wrote: > On Wed, Jul 10, 2013 at 12:05 PM, Gabriel Dos Reis > wrote: >> On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li >> wrote: >>> What about introducing a new blanket warning kind that excludes >&g

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li wrote: > What about introducing a new blanket warning kind that excludes > anything with false positives? something like -WALL ? I am doubtful "more ropes" is the answer. -- Gaby

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Wed, Jul 10, 2013 at 9:42 AM, Andi Kleen wrote: > Andrew Haley writes: > >> On 07/09/2013 12:59 PM, Andreas Arnez wrote: >>> With this situation at hand, I wonder whether it's a good idea to keep >>> maybe-uninitialized included in -Wall. Projects which have been using >>> "-Wall -Werror" suc

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Tue, Jul 9, 2013 at 4:57 PM, Jeff Law wrote: > I personally like -Wall -Werror. While we do run into false positives and > the set of false positives does change from release to release as a result > of optimizations, I believe there's been an overall improvement in the > quality of the codeb

Re: fatal error: gnu/stubs-32.h: No such file

On Mon, Jul 8, 2013 at 3:43 AM, Andrew Haley wrote: > On 07/08/2013 07:33 AM, Gabriel Dos Reis wrote: >> I strongly disagree. We (GCC) are at fault here. We implicitly >> enable a feature at configure time without knowing its builds >> will succeed (despite having repeated

Re: fatal error: gnu/stubs-32.h: No such file

On Mon, Jul 8, 2013 at 2:13 AM, Jakub Jelinek wrote: > On Mon, Jul 08, 2013 at 12:55:15AM -0500, Gabriel Dos Reis wrote: >> Personally, I don't see anything broken with that. The world we are >> in today is very different from a decade ago. More than a decade ago, >> a

Re: fatal error: gnu/stubs-32.h: No such file

On Mon, Jul 8, 2013 at 12:59 AM, Andrew Pinski wrote: > On Sun, Jul 7, 2013 at 10:55 PM, Gabriel Dos Reis > wrote: >> On Mon, Jul 8, 2013 at 12:19 AM, Andrew Pinski wrote: >>> On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis >>> wrote: >>>> On Su

Re: fatal error: gnu/stubs-32.h: No such file

On Mon, Jul 8, 2013 at 12:19 AM, Andrew Pinski wrote: > On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis > wrote: >> On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely >> wrote: >>> On 7 July 2013 21:33, Gabriel Dos Reis wrote: >>>> How about not enabling m

Re: fatal error: gnu/stubs-32.h: No such file

On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely wrote: > On 7 July 2013 21:33, Gabriel Dos Reis wrote: >> How about not enabling multi lib build by default on targets we now that >> will fail anyway? I have the suspicion this problem is unique to openSUSE, >> so we can take

Re: fatal error: gnu/stubs-32.h: No such file

On Sun, Jul 7, 2013 at 12:44 PM, Jonathan Wakely wrote: > On 7 July 2013 15:00, Bruce Korb wrote: >> On 07/06/13 11:53, Andreas Schwab wrote: >>> >>> Bruce Korb writes: >>> Why is it that configure worked but stubs-32.h was not found? >>> >>> >>> This is testing the host compiler which does

Re: fatal error: gnu/stubs-32.h: No such file

On Sun, Jul 7, 2013 at 9:00 AM, Bruce Korb wrote: > On 07/06/13 11:53, Andreas Schwab wrote: >> >> Bruce Korb writes: >> >>> Why is it that configure worked but stubs-32.h was not found? >> >> >> This is testing the host compiler which doesn't need that file. You >> need to build the target comp

Re: Remove the __GXX_EXPERIMENTAL_CXX0X__?

On Wed, Jul 3, 2013 at 4:39 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote: > While thinking about C++ n3694 feature test macros I noticed we still define > __GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c. > We got rid of all uses of it in libstdc++. > I propose we get rid of it here t

Re: Plan for removing global state from GCC's internals

On Tue, Jul 2, 2013 at 3:25 PM, Joseph S. Myers wrote: > On Mon, 1 Jul 2013, Aaron Gray wrote: > >> I started to do this starting with the C++ parser class'izing it but >> no one was interested. > > The C++ parser types such as cp_parser and cp_lexer already do a good job > of avoiding global stat

Re: Macro for C++14 support

On Tue, Apr 23, 2013 at 9:47 AM, Jonathan Wakely wrote: > But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway, yes, this was a great move; kudos to whoever did it. > we > check __cplusplus >= 201103L, and so within those chunks we could > additionally check for some C++14 macro. Ag

Re: Macro for C++14 support

On Tue, Apr 23, 2013 at 9:29 AM, Paolo Carlini wrote: > Hi, > > Gabriel Dos Reis ha scritto: > >>There appear to be two targets: C++14 and C++17. Personally, I am >>inclined >>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target. > > This c

Re: Macro for C++14 support

On Tue, Apr 23, 2013 at 9:01 AM, Piotr Wyderski wrote: > Gabriel Dos Reis wrote: > >> C++03 was essentially bug fixes to C++98 so we did not make the >> distinction. >> C++14 is more than bug fixes to C++11, it contains many new extensions. >> So I am unsure the sit

Re: Macro for C++14 support

On Tue, Apr 23, 2013 at 8:15 AM, Allan Sandfeld Jensen wrote: > On Sunday 21 April 2013, Jonathan Wakely wrote: >> I'm starting to implement some new library features voted into C++14 >> at the Bristol meeting and am wondering what feature check to use. >> >> Will there be a macro like _GXX_EXPERI

Re: Macro for C++14 support

On Sun, Apr 21, 2013 at 12:12 PM, Jonathan Wakely wrote: > On 21 April 2013 18:05, Paolo Carlini wrote: >> Hi, >> >> Jonathan Wakely ha scritto: >> >>>I'm starting to implement some new library features voted into C++14 >>>at the Bristol meeting and am wondering what feature check to use. >>> >>>

Re: Macro for C++14 support

On Sun, Apr 21, 2013 at 12:05 PM, Paolo Carlini wrote: > Hi, > > Jonathan Wakely ha scritto: > >>I'm starting to implement some new library features voted into C++14 >>at the Bristol meeting and am wondering what feature check to use. >> >>Will there be a macro like _GXX_EXPERIMENTAL_CXX1Y__ to c

Re: Macro for C++14 support

On Sun, Apr 21, 2013 at 9:52 AM, Jonathan Wakely wrote: > I'm starting to implement some new library features voted into C++14 > at the Bristol meeting and am wondering what feature check to use. > > Will there be a macro like _GXX_EXPERIMENTAL_CXX1Y__ to correspond to > -std=c++1y? > > Alternativ

Re: Compiling gcc473-RC-20130404 with -Wextra

On Sat, Apr 6, 2013 at 6:51 AM, Дилян Палаузов wrote: > Hello, > > I compile gcc473-RC-20130404 with > > CFLAGS='-pipe -O3 -march=native -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 > -Wl,-z,relro -flto -Wall -Wextra' > ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var > --enable-threads=pos

Re: GCC build on darwin12.3

On Thu, Mar 28, 2013 at 12:29 PM, Nenad Vukicevic wrote: > Are you using Mac ports for gmp/mpfr/mpc libraries? I see that > you have "-L/opt/local/lib" on you path. yes, I was using macports -- it was one of the first things I installed on this machine since I wanted to write programs. > > I ha

Re: gengtype and inheritance

On Thu, Mar 28, 2013 at 7:49 AM, Diego Novillo wrote: > On 2013-03-28 07:57 , Gabriel Dos Reis wrote: >> >> Does gengetype works with inheritance now? I could not >> find anything to that effect in the documentation. >> > No. The plan is to get rid of gengtype

GCC build on darwin12.3

Hi, Do we still support GCC on recent versions of mac os x? The reason I am asking is that I have been unable to build GCC, both 4.8 branch and trunk, for about 2 weeks now. The failure as of this morning is: g++ -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall

Re: gengtype and inheritance

On Thu, Mar 28, 2013 at 7:53 AM, Richard Biener wrote: > On Thu, Mar 28, 2013 at 1:49 PM, Diego Novillo wrote: >> On 2013-03-28 07:57 , Gabriel Dos Reis wrote: >>> >>> Does gengetype works with inheritance now? I could not >>> find anything to that effect i

gengtype and inheritance

Hi Diego, Does gengetype works with inheritance now? I could not find anything to that effect in the documentation. Thanks, -- Gaby

Re: Debugging C++ Function Calls

On Tue, Mar 26, 2013 at 3:02 PM, Tom Tromey wrote: > Richard> Did you consider using clang? > Richard> > > We may look at it after re-examining g++. > I think there are some reasons to prefer gcc. Yes, obviously :-) -- Gaby

Re: anonymous namespaces in GCC source code

Jason Merrill writes: | On 03/18/2013 10:57 AM, Gabriel Dos Reis wrote: | > I have been having discussion with Andrew about uses of anonymous | > namespaces in GCC source code. I seem to remember that they used to | > cause troubles when doing binary diff during bootsrap becau

anonymous namespaces in GCC source code

Hi Jason, Lawrence, I have been having discussion with Andrew about uses of anonymous namespaces in GCC source code. I seem to remember that they used to cause troubles when doing binary diff during bootsrap because we use random names to ensure uniqueness of names; but are we still doing that?

Re: Default -fabi-version=0 for 4.9

On Tue, Mar 5, 2013 at 1:43 PM, Jason Merrill wrote: > On 03/05/2013 02:28 PM, Lawrence Crowl wrote: >> >> Are you planning for C++11 ABI stability in 4.9? > > > Yes. But if mangling bugs are discovered after 4.9, I propose to just fix > them (as I believe EDG and Clang do) rather than hold them

Re: gcc : c++11 : full support : eta?

On Thu, Jan 24, 2013 at 1:59 PM, Jeff Law wrote: > On 01/24/2013 12:55 PM, Diego Novillo wrote: >> >> >> I do see, however, a few areas where Clang/LLVM have gone that I do >> not think GCC is currently thinking of entering: "toolability" (for >> the lack of a better term). Clang's design follows

Re: [PATCH] Adjust build requirement docs for GCC 4.8

On Tue, Dec 11, 2012 at 4:14 AM, Richard Biener wrote: > > This brings the build-requirements up-to-date with us now requiring > a C++ host compiler. I optimistically increased the minimum required > GCC version listed from 2.95 to 3.4 as that is the earliest version > that could reasonably be ca

Re: RFC - Remove support for PCH post 4.8

On Thu, Nov 29, 2012 at 12:12 PM, Benjamin Kosnik wrote: > > > >> Assuming that the new implementation will be available in time for 4.9, my >> primary concern is that in the meanwhile running the libstdc++ testsuite >> will be quite noticeably slower. Do you have some numbers? > > > Just use th

Re: RFC - Remove support for PCH post 4.8

On Wed, Nov 28, 2012 at 7:07 PM, Lawrence Crowl wrote: > On 11/28/12, Gabriel Dos Reis wrote: >> On Nov 28, 2012 Miles Bader wrote: >> > 2012/11/29 Gabriel Dos Reis : >> > > My understanding from attending the last C++ standards >> > > committe

Re: RFC - Remove support for PCH post 4.8

On Wed, Nov 28, 2012 at 6:41 PM, Miles Bader wrote: > 2012/11/29 Gabriel Dos Reis : >> My understanding from attending the last C++ standards committee is >> that we are still way far from having something that gets consensus of >> good enough proposal on modules to coal

Re: RFC - Remove support for PCH post 4.8

On Wed, Nov 28, 2012 at 3:14 PM, Jonathan Wakely wrote: > On 28 November 2012 09:03, Jonathan Wakely wrote: >> On 28 November 2012 07:36, Xinliang David Li wrote: >>> What you described is the 'transitional model' right? but I don't see >>> any of those in the C++ standard working paper: >>> http:

Re: Unifying the GCC Debugging Interface

On Tue, Nov 27, 2012 at 8:54 AM, Tom Tromey wrote: >>>>>> "Gaby" == Gabriel Dos Reis writes: > > Richard> Just to add another case which seems to be not covered in the thread. > Richard> When dumping from inside a gdb session in many cases I cut

Re: Unifying the GCC Debugging Interface

On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener wrote: > Just to add another case which seems to be not covered in the thread. > When dumping from inside a gdb session in many cases I cut&paste > addresses literally. For overloading to work I'd need to write casts > in front of the inferior call

Re: Could we start accepting rich-text postings on the gcc lists?

On Sat, Nov 24, 2012 at 11:13 AM, Ian Lance Taylor wrote: > 2) The fact that Android refuses to provide a non-HTML e-mail capability > is ridiculous but does not seem to me to be a reason for us to change > our policy. Amen. Rich texts in technical conversations where people people use various

Re: Hash table iterators.

On Thu, Nov 22, 2012 at 12:18 PM, Lawrence Crowl wrote: > I have found that tree-flow.h implements iteration over htab_t, > while there is no current facility to do that with hash_table. > Unfortunately, the specific form does not match the standard C++ > approach to iterators. We have several ch

Re: Unifying the GCC Debugging Interface

On Wed, Nov 21, 2012 at 9:02 AM, Ian Lance Taylor wrote: > On Wed, Nov 21, 2012 at 3:18 AM, Gabriel Dos Reis > wrote: >> On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl wrote: >> >>> And, as a side note, highly formatted output generally is not >>> much be

Re: Unifying the GCC Debugging Interface

ter. Said, differently, the worry about IOStreams introducing unnecessary "static constructor" is either overblown or misplaced, or both. -- Gaby On Wed, Nov 21, 2012 at 8:25 AM, Gabriel Dos Reis wrote: > On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser wrote: > >> Is it correct to s

Re: Unifying the GCC Debugging Interface

On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser wrote: > Is it correct to state that every translation unit that includes iostream > will include the iostream static constructors? C++ requires the definitions of globals such as std::cin, std::cout, and std::cerr that must be contructed (by any m

Re: Unifying the GCC Debugging Interface

On Wed, Nov 21, 2012 at 7:07 AM, Tobias Grosser wrote: > On 11/20/2012 08:32 PM, Basile Starynkevitch wrote: >> >> On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote: >> [] > > All of these functions come in two forms. > > function (FILE *, item_to_dump, forma

Re: Unifying the GCC Debugging Interface

On Wed, Nov 21, 2012 at 5:37 AM, Theodore Papadopoulo wrote: > On 11/21/2012 02:01 AM, Xinliang David Li wrote: >> >> Right -- gdb does not know the complete type of std::cout and >> std::cerr -- try the following program with -g and invoke print, or << >> in the debugger -- see what you will get:

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 7:01 PM, Xinliang David Li wrote: > Right -- gdb does not know the complete type of std::cout and > std::cerr -- try the following program with -g and invoke print, or << > in the debugger -- see what you will get: Is this because the hack we (libstdc++ folks) used to defi

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl wrote: > And, as a side note, highly formatted output generally is not > much better than printf. For any text that needs to be localized, > I recommend that we stick with what we have. I agree with Lawrence that for texts that need localization,

Re: RFC - Alternatives to gengtype

On Sat, Nov 17, 2012 at 1:33 PM, Xinliang David Li wrote: > My main point is that other main open source compilers like > clang/llvm, open64 and some main commercial compilers I know do not > use GC, which proves that GC is not a must for a compiler to be easy > to work with or to be a good open

Re: RFC - Alternatives to gengtype

On Fri, Nov 16, 2012 at 9:42 AM, Andrew MacLeod wrote: > PS I'd also prefer the term 'memory pool' or something... the term 'obstack' > still makes my skin crawl :-) Amen. -- Gaby, old enough to remember the obstack days

Re: Simplifying Gimple Generation

On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote: [...] > The method name should imply the action, e.g. 'add_stmt' or append_stmt > or the like. strongly agreed. [...] > All in all I think we can severely improve on building gimple statements > without introduction of any helper class. Basic

Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions

On Sat, Oct 20, 2012 at 10:23 PM, Richard Smith wrote: >> Allow loops and the like in constexpr functions and be done with it. See my >> comments on the C++ Extension Working Group when these (and related) >> issues where brought up. > > Yes, I completely agree, but I don't think this solves the

Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions

On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose wrote: > While throwing things out there, why not just optionally allow constexpr > functions to coexist with non-constexpr functions of the same name, like > inline and non-inline? Or remove most of the restrictions on constexpr functions that were

Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions

On Sat, Oct 20, 2012 at 12:53 AM, Chandler Carruth wrote: > On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith wrote: >> >> [Crossposted to both GCC and Clang dev lists] >> >> Hi, >> >> One issue facing library authors wanting to use C++11's constexpr feature is >> that the same implementation must

Re: Proposing switch -fsmart-pointers

On Sat, Oct 6, 2012 at 7:47 PM, _ wrote: > You will probably kill me for this. But no such patch yet exists. > I am kinda trying findout wheter there is interest in such experiment > and find some help since to me alone it would take ages. > But I love to see that you are interested. It really is

Re: Proposing switch -fsmart-pointers

On Sat, Oct 6, 2012 at 1:59 PM, _ wrote: > Now obviously you can't put stl everywhere. True. Did you send in a patch to review? -- Gaby

Re: --with-gmp, --with-mpfr and/or --with-mpc

On Sat, Sep 22, 2012 at 5:58 PM, Bruce Korb wrote: > On 09/22/12 15:02, Gabriel Dos Reis wrote: >> On Sat, Sep 22, 2012 at 4:36 PM, Marc Glisse wrote: >>> Are you looking for gcc-h...@gcc.gnu.org? >> >>> mpc-devel ? (not my platform, I don't even know if

Re: --with-gmp, --with-mpfr and/or --with-mpc

On Sat, Sep 22, 2012 at 4:36 PM, Marc Glisse wrote: > Are you looking for gcc-h...@gcc.gnu.org? > > mpc-devel ? (not my platform, I don't even know if that package exists, but > your grep pattern excludes such a package) yes, it is "mpc-devel" on suse. one needs the "-devel" packages of all the

Re: GCC stack backtraces

On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo wrote: > Alternately, we could use Richi's approach I suppose (what happened to that > patch, btw)? I was under the impression that the patch was good to go in; Richard? -- Gaby

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

On Mon, Sep 10, 2012 at 10:41 AM, Aaron Gray wrote: > What I am looking to obtain is isolating the C++ parser with no real > semantic changes, just isolating the interfaces in order that the > parser be reusable as a library component and allow migration to other > solutions. Yes, for that, you

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

On Mon, Sep 10, 2012 at 10:01 AM, Florian Weimer wrote: > On 09/10/2012 04:53 PM, Gabriel Dos Reis wrote: > >> It is not clear what the benefit is to move existing perfectly working >> internal non-member functions to being member functions a huge struct. >

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

[ I am adding back GCC mailing list in the CC: as this would be useful for other contributors. ] On Mon, Sep 10, 2012 at 9:42 AM, Aaron Gray wrote: > On 10 September 2012 15:25, Gabriel Dos Reis > wrote: >> >> On Mon, Sep 10, 2012 at 8:59 AM, Aaron Gray >> wrote: >

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray wrote: > Hi, > > I have put in three patches on the 29th of August, but have not heard > any real feedback on them :- [...] > [PATCH] C++'ization of cp/parser.c/h > > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html > > > This last patch possi

Re: Thoughts on Gengtype and Single Inheritance

On Thu, Aug 30, 2012 at 11:57 AM, Richard Henderson wrote: > On 08/27/2012 11:58 AM, Lawrence Crowl wrote: >>> > I wonder if the second discriminator support is easily generalizable >>> > to enabling any derived class being a root class on it own with its >>> > own subtree? If I understand correct

Re: GCC stack backtraces

On Wed, Aug 29, 2012 at 2:22 AM, Ian Lance Taylor wrote: > Does this seem like something we could usefully add to GCC? Emphatically, yes!. > Does anybody see any big problems with it? Can it would be a great addition to libstdc++ as a GNU extension, stached in the namespace. I do also do li

Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?

On Tue, Aug 28, 2012 at 8:45 AM, Michael Matz wrote: > Hi, > > On Tue, 28 Aug 2012, Ian Lance Taylor wrote: > >> > Or do we have a rule than any file using C++ specific feature should >> > be renamed from *.c to *.cc at the moment the C++ feature goes inside? >> >> We do not have such a rule and I

Re: Size difference in base class between GCC releases

On Mon, Aug 27, 2012 at 3:16 PM, wrote: > On Aug 27, 2012, at 4:05 PM, Gabriel Dos Reis wrote: > >> On Mon, Aug 27, 2012 at 1:48 PM, wrote: >>> I'm doing some checking of data structure layouts in different releases of >>> our code -- which were produced by

Re: Size difference in base class between GCC releases

On Mon, Aug 27, 2012 at 1:48 PM, wrote: > I'm doing some checking of data structure layouts in different releases of > our code -- which were produced by different releases of GCC (3.3.3 vs. > 4.5.4). > > One difference I'm seeing that is puzzling is in the handling of base > classes. Specifi

Re: [wwwdocs] Update links to C++ ABI (was: at exit alternative for AIX)

On Sun, Aug 26, 2012 at 11:55 AM, Ian Lance Taylor wrote: > On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer wrote: >> On Tue, 7 Aug 2012, Ian Lance Taylor wrote: >>> The official link at http://codesourcery.com/cxx-abi/ (note trailing >>> slash) still works. >> >> It used to be http://sourcery.me

Re: C++ and gather-detailed-mem-stats

On Fri, Aug 24, 2012 at 10:01 AM, Diego Novillo wrote: > On 2012-08-15 06:10 , Richard Guenther wrote: > >> Maybe have a GNU C++ builtin type >> >> struct __Gcc_call_location_pack { >>const char *file; >>const char *function; >>unsigned line; >> }; >> >> and an attribute >> >> void foo

  1   2   3   4   5   6   7   8   9   10   >