On Thu, Apr 5, 2012 at 6:45 AM, Eric Botcazou wrote:
>> From developer perspective, we think that -Wall is so simple to
>> remember, because
>> in fact, we are used to handle so many complex things that this one five
>> letter is nothing. However, users aren't as sophisticated as we would like
>>
this is drifting, but since we talking about teaching (which is part of my
daytime job)
On Thu, Apr 5, 2012 at 7:33 AM, Robert Dewar wrote:
> Wouldn't it be better in a "moderately basic programming course" to
> provide standard canned scripts that set things up nicely for students
> including t
On Thu, Apr 5, 2012 at 3:24 PM, Russ Allbery wrote:
> Gabriel Dos Reis writes:
>
>> If it is the non-expert that would be caught in code so non-obvious that
>> -Wuninitialized would trip into false positives, then it is highly
>> likely that the code might in fact cont
On Thu, Apr 5, 2012 at 3:16 PM, David Edelsohn wrote:
> On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo wrote:
>> On Thu, Apr 5, 2012 at 10:24, Richard Guenther
>> wrote:
>>
>>> Which means never, because I think it's a prerequesite for switching?
>>
>> No. I was not clear. By "done", I meant t
On Sat, Apr 7, 2012 at 4:46 PM, James Cloos wrote:
>>>>>> "GDR" == Gabriel Dos Reis writes:
>
> GDR> Exactly. Our bugzilla databases has lot of requests in this spirit.
>
> If that is so, then defaulting to -Wall will just generate even more
> re
On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn wrote:
> On 05/04/2012 10:46, Gabriel Dos Reis wrote:
>> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
>> wrote:
>>
>>> Btw, it would be more reasonable to enable a subset of warnings that
>>> we enable at
On Sat, Apr 7, 2012 at 5:57 PM, Miles Bader wrote:
> Dave Korn writes:
>> IMHO we should move the -Wunused ones into -Wextra if we're going to turn
>> on
>> -Wall by default. The rest seem pretty reasonable defaults to me.
>
> How about instead adding new "-Wstandard", which will be on by def
On Sun, Apr 8, 2012 at 10:16 AM, James Cloos wrote:
>> "MB" == Miles Bader writes:
>
> MB> [Or, perhaps, not "-Wall" perse, but maybe a new option which
> MB> is a little more conservative, "-Wstandard" or something...]
>
> Sure. Making a few more of the -W flags on by default may be OK,
> d
On Sun, Apr 8, 2012 at 10:59 AM, Rick Hodgin wrote:
> What are the possibilities of adding a GCC extension to allow:
>
> switch (foo) {
> case 1:
> case 2:
> case 3 to 8:
> case 9:
> default:
> }
>
> in C/C++ case statements?
GCC used to have a range extension for case:
case 3..8
which has b
On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar wrote:
> On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
>>
>> The people who don't want -Wall (or
>> -Wstandard) enabled are likely to be the ones who know how to use
>> -Wno-all or whatever to get what they want.
>
>
> I see no evidence that supports tha
On Sun, Apr 8, 2012 at 2:53 PM, Robert Dewar wrote:
> On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote:
>>
>> On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar wrote:
>>>
>>> On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
>>>>
>>>>
>>>> Th
On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewar wrote:
> On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
>
>> Again, that also applies when people use -Wall today: a false positive
>> is unwanted even if you use -Wall, and those false positives are bugs
>> and so having them in bugzilla is good.
>
>
> Do
On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar wrote:
> On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
>> But I'd be just as happy with a -Wstandard (by any name) enabled by
>> default as I would be with -Wall on by default. Only enabling warnings
>> with very little chance of false positives would av
On Sun, Apr 8, 2012 at 3:28 PM, Robert Dewar wrote:
> On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote:
>
>> I think I agree with this. I suspect the only difference might be that
>> I do not believe the fix is necessarily to turn them off.
>
>
> Well there are three p
On Sun, Apr 8, 2012 at 3:29 PM, Robert Dewar wrote:
> On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote:
>>
>> On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar wrote:
>>>
>>> On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
>>
>>
>>>> But I'
On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer wrote:
> On Sun, 8 Apr 2012, Robert Dewar wrote:
>> Do you really want me to file hundreds of bug reports that are for
>> cases of uninitialized variables well known to everyone, and well
>> understood by everyone, and not easy to fix (or would have
On Mon, Apr 9, 2012 at 12:15 PM, Robert Dewar wrote:
> On 4/9/2012 1:08 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer
>> wrote:
>>>
>>> On Sun, 8 Apr 2012, Robert Dewar wrote:
>>>>
>>>> Do
On Mon, Apr 9, 2012 at 12:36 PM, Jonathan Wakely wrote:
> Maybe -Wstandard isn't the best name though, as "standard" usually
> means something quite specific for compilers, and the warning switch
> wouldn't have anything to do with standards conformance.
I agree.
I have been resisting to go the
On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote:
> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>
>> Maybe -Wstandard isn't the best name though, as "standard" usually
>> means something quite specific for compilers, and the warning switch
>> wouldn't have anything to do with standards conforma
On Tue, Apr 10, 2012 at 2:07 AM, Miles Bader wrote:
> 2012年4月10日15:26 Eric Botcazou :
>>> Something like -Wdefault-warnings is a reasonable choice, for the
>>> reasons already mentioned in this sub-thread.
>>
>> Purists will find that -Wdefault-warnings is redundant though, since -W is
>> supposed
On Tue, Apr 10, 2012 at 7:40 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
>
>> > To be honest, all of those sound fine to me...
>> >
>> > bike-sheddin',
>> > -miles
>>
>> at the risk of more bike sh
On Tue, Apr 10, 2012 at 7:40 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
>
>> > To be honest, all of those sound fine to me...
>> >
>> > bike-sheddin',
>> > -miles
>>
>> at the risk of more bike sh
On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn wrote:
> Also, it will be more convenient to make this change incrementally,
> but the GCC community probably will not see much benefit until the
> transition is complete. That also means developers asserting benefits
> need to be realistic and se
On Tue, Apr 10, 2012 at 11:39 AM, Jakub Jelinek wrote:
>> What is the root cause of the annoyance? Mixing macros and inline
>> functions does not sound good, but using deeply nested macros do not
>> seem to help the debugging situation either.
>
> That when stepping through code in the debugger yo
On Tue, Apr 10, 2012 at 6:27 PM, Eric Botcazou wrote:
>> In the short term, a partial conversion to C++ gains us nothing. Even
>> ignoring the bugs inevitably caused by any such project, we'll end up
>> with a strange mish-mash of styles for a very long time, which instead
>> of helping anyone can
On Wed, Apr 11, 2012 at 2:01 AM, Jakub Jelinek wrote:
> On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote:
>> > In the short term, a partial conversion to C++ gains us nothing. Even
>> > ignoring the bugs inevitably caused by any such project, we'll end up
>> > with a strange mish-mash
On Wed, Apr 11, 2012 at 2:42 AM, Eric Botcazou wrote:
>> when you say that, do you mean you would prefer and expect:
>> 1. native C++ style, or
>> 2. you would like the C-style round-about and paraphrasing to remain
>> unperturbed
>> ?
>>
>> The reason I ask is that I expect a "proper" C++ imp
On Wed, Apr 11, 2012 at 7:34 AM, Bernd Schmidt wrote:
> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
>> I have been having difficulty following the twists and the turns and
>> the goal post moving.
>> Are you essentially requiring to see GCC rewritten in C++ bef
On Wed, Apr 11, 2012 at 8:13 AM, Richard Guenther
wrote:
>> Please don't dismiss this so easily. Of course this is just an example
>> and nothing major, but I believe many people will use tab completion on
>> the shell, for example, and code completion is really similar. On the
>> shell, or wit
On Wed, Apr 11, 2012 at 8:28 AM, Jakub Jelinek wrote:
> On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
>> The reason why I am mystified is that the people who seem to argue
>> that it would be pointless to convert the existing codebase to C++ seem
>> to b
On Wed, Apr 11, 2012 at 11:35 AM, Diego Novillo wrote:
> I have created the SVN branch cxx-conversion to host all the
> mini-projects aimed at exploring the C++ conversion. Everyone is
> welcome to contribute to it.
>
> The branch has been configured to build in C++ mode by default.
>
> I have al
On Wed, Apr 11, 2012 at 1:37 PM, Basile Starynkevitch
wrote:
> On Wed, 11 Apr 2012 10:30:36 -0700
> Xinliang David Li wrote:
> [..]
>>
>> yes -- GCC is not considered old and not 'cool' -- so it is hard to
>> advertise. One criteria to see GCC's future popularity is how widely
>> it is adopted by
On Thu, Apr 12, 2012 at 5:23 AM, Dave Korn wrote:
> On 11/04/2012 09:50, Vincent Lefevre wrote:
>> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote:
>>>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>
On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar wrote:
> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
>
>>>> -W0: no warnings (equivalent to -w)
>>>> -W1: default
>>>> -W2: equivalent to the current -Wall
>>>> -W3: equivalent to the current -
On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn wrote:
> On 12/04/2012 15:43, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar wrote:
>>> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
>>>
>>>>>> -W0: no warnings (equivalent to -w)
On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn wrote:
> On 12/04/2012 15:55, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn
>> wrote:
>>> On 12/04/2012 15:43, Gabriel Dos Reis wrote:
>
>>>> People easily associates some ordering t
On Thu, Apr 12, 2012 at 10:16 AM, Robert Dewar wrote:
> On 4/12/2012 11:06 AM, Gabriel Dos Reis wrote:
>
>> What is nonsensical there?
>>
>>> But they *are* ordinal.
>>
>>
>> Now? What is the order?
>
>
> less warnings to more warnings, wh
On Thu, Apr 12, 2012 at 10:24 AM, Dave Korn wrote:
> On 12/04/2012 16:06, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn
>> wrote:
>>> On 12/04/2012 15:55, Gabriel Dos Reis wrote:
>>>> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn
&
On Thu, Apr 12, 2012 at 10:38 AM, Jonathan Wakely wrote:
> On 12 April 2012 16:33, Robert Dewar wrote:
>>
>> For warnings you put a higher number to get more warnings. Yes,
>> you may find that you get too many warnings and they are not
>> useful. Remedy: reduce the number after -W :-)
>
> It woul
On Thu, Apr 12, 2012 at 10:43 AM, Pedro Alves wrote:
> On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote:
>
>> because -Os says it optimizes for size, the expectation is clear.
>> -O3 does not necessarily give better optimization than -O2.
>
>
> No, but it does
On Thu, Apr 12, 2012 at 10:49 AM, Gabriel Dos Reis
wrote:
> On Thu, Apr 12, 2012 at 10:38 AM, Jonathan Wakely
> wrote:
>> On 12 April 2012 16:33, Robert Dewar wrote:
>>>
>>> For warnings you put a higher number to get more warnings. Yes,
>>> you may find
On Thu, Apr 12, 2012 at 2:43 PM, Jonathan Wakely wrote:
> On 12 April 2012 11:41, Jonathan Wakely wrote:
>> Two more examples, then I'll save it for a wiki page instead of the
>> mailing list:
>
> And here it is:
>
> http://gcc.gnu.org/wiki/ClangDiagnosticsComparison
Thanks; this is useful.
-- G
On Thu, Apr 12, 2012 at 3:56 PM, Dave Korn wrote:
> On 12/04/2012 17:03, Gabriel Dos Reis wrote:
>> There is
>> little ambiguity left by -Wreally-all-of-them-damn-it :-)
>
> Actually, no, as anyone could tell you who before they discovered version
> control used to
On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote:
> On 12/04/2012 16:47, Gabriel Dos Reis wrote:
>
>> I keep talking about useful *warnings*, you keep talking about *numbers*.
>
> No you don't. You said:
>
>>>>>>>> People easily associates some
On Thu, Apr 12, 2012 at 4:30 PM, Jonathan Wakely wrote:
> On 12 April 2012 16:49, Gabriel Dos Reis wrote:
>>> It would even allow -Winf for the
>>> sometimes-requested-but-probably-not-actually-useful
>>> -Wreally-really-all that turns on *all* possible warnings.
On Thu, Apr 12, 2012 at 4:38 PM, Robert Dewar wrote:
> On 4/12/2012 5:35 PM, Gabriel Dos Reis wrote:
>
>>> There's nothing more ambiguous than saying that something is final in a
>>> world where perfection is never achieved. That's why software has
>>&g
On Thu, Apr 12, 2012 at 4:42 PM, Robert Dewar wrote:
> On 4/12/2012 5:40 PM, Gabriel Dos Reis wrote:
>
>> It isn't non-sense just because you decide so or you don't like the
>> observation.
>>
>>> and
>>> nonsense now, this has nothing to do wi
On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez
wrote:
> Hi Jonathan,
>[]
> Of course, the major question is: Are the decision makers in GCC
> interested on any of this?
>
> Would some reviewer reject patches implementing them?
I suspect decisions will be based on the implementations the
On Thu, Apr 12, 2012 at 5:05 PM, Manuel López-Ibáñez
wrote:
> On 12 April 2012 23:54, Gabriel Dos Reis
> wrote:
>> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez
>> wrote:
>>> Hi Jonathan,
>>>[]
>>> Of course, the major question is: Are
On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez
wrote:
> I find the color output of Clang just beautiful and, in my opinion,
> color support in GCC would make it a bit more beautiful and attract
> new users, so it is a much better use of developer's time than fixing
> yet another obscure dia
On Fri, Apr 13, 2012 at 12:11 AM, Ian Lance Taylor wrote:
> I personally think it would be an excellent idea. Even clang's C++
> error messages can be long. A simple use of color is an excellent way
> to draw the eye to the more important parts of the message. If the
> color is not available,
On Thu, Apr 12, 2012 at 4:50 PM, Robert Dewar wrote:
> End of thread for me, remove me from the reply lists, thanks
> discussion is going nowhere, at this stage my vote is for
> no change whatever in the way warnings are handled.
I was asked "wassup with Robert?". All I can say s that
it is a de
On Fri, Apr 13, 2012 at 1:03 AM, Jakub Jelinek wrote:
> we should limit to a very small
> set of colors, because not so many colors are actually very readable and
> perhaps make the color sets configurable somehow (things might be different
> if people use normally black characters on white backg
On Fri, Apr 13, 2012 at 3:27 AM, Manuel López-Ibáñez
wrote:
> On 13 April 2012 05:36, Gabriel Dos Reis
> wrote:
>> On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez
>> wrote:
>>
>>> I find the color output of Clang just beautiful and, in my opinion,
>>
On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez
wrote:
> But I don't want to turn the diagnostics machinery upside down and
> implement a "diagnostics internal language"
I do think an internal formatting IL/IR for better representation is
needed for the
kind of things you would like to (e.
On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely wrote:
> On 13 April 2012 02:40, Joe Buck wrote:
>> I'm not interested in color output, and would turn it off if it were
>> implemented (the escape sequences would just mess things up when capturing
>> compiler output in log files).
>
> There's no r
On Fri, Apr 13, 2012 at 4:00 AM, Manuel López-Ibáñez
wrote:
> On 13 April 2012 10:46, Gabriel Dos Reis
> wrote:
>> On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez
>> wrote:
>>
>>> But I don't want to turn the diagnostics machinery upside down and
On Fri, Apr 13, 2012 at 6:36 AM, Richard Guenther
wrote:
> I suppose we'd want to make the diagnostic machinery accessible by
> plugins so that IDEs could get an easier hand on things anyway. That
> way colorization could be achieved using a plugin, too.
Indeed, we definitely want a standard wa
On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote:
> Shooting down a potentially user friendly feature to wait until some blue
> sky redesign is implemented means it might never be implemented.
This is a mischaracterization and you know it.
-- Gaby
On Fri, Apr 13, 2012 at 9:11 AM, Ludovic Courtès
wrote:
> Hello,
>
> Richard Guenther skribis:
>
>> And since yesterday GCC shows
>>
>> t.C:2:10: error: expected ';' after class definition
>> class a {}
>> ^
>> t.C:6:1: error: expected ';' after struct definition
>> }
>> ^
>>
>> as w
On Fri, Apr 13, 2012 at 10:30 AM, NightStrike wrote:
> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
> wrote:
>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek wrote:
>>
>>> Shooting down a potentially user friendly feature to wait until some blue
>>>
On Fri, Apr 13, 2012 at 10:41 AM, NightStrike wrote:
> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis
> wrote:
>> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike wrote:
>>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
>>> wrote:
>>>> On F
On Fri, Apr 13, 2012 at 10:59 AM, NightStrike wrote:
> On Fri, Apr 13, 2012 at 11:53 AM, Gabriel Dos Reis
> wrote:
>> On Fri, Apr 13, 2012 at 10:41 AM, NightStrike wrote:
>>> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis
>>> wrote:
>>>> On
On Fri, Apr 13, 2012 at 5:39 PM, Dave Korn wrote:
> On 12/04/2012 22:36, Gabriel Dos Reis wrote:
>> On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote:
>>> On 12/04/2012 16:47, Gabriel Dos Reis wrote:
>>>
>>>> I keep talking about useful *warnings*, you ke
On Sat, Apr 14, 2012 at 4:09 AM, Robert Dewar wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably,
On Sat, Apr 14, 2012 at 2:55 PM, Pedro Lamarão wrote:
> Hello,
>
> currently proposed C++ Coding Conventions imply a very strict
> weird-is-forbidden style, which I like.
>
> But if defining new templates should in general be avoided, I'm unsure what
> is the best path in converting VEC.
>
> VEC i
On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>
> I assume this is a size_t vs int type problem, but the diagnostic
> points to the function declaration, not to an actual binary
> expression, and I can't figure out what it's complaining about:
My mailer uses proportional fonts so I can't make
On Wed, May 9, 2012 at 3:27 AM, Richard Guenther
wrote:
> On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
> wrote:
>> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>>>
>>> I assume this is a size_t vs int type problem, but the diagnostic
>>> points
On Wed, May 9, 2012 at 3:41 AM, Marc Glisse wrote:
> On Wed, 9 May 2012, Richard Guenther wrote:
>
>> On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
>> wrote:
>>>
>>> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>>>>
>>>>
On Thu, May 10, 2012 at 3:33 PM, DJ Delorie wrote:
>
>> style nits: It should be size_t(__len - __pos), and not
>> (size_t)(__len - __pos). Same for the other hunk. Patch OK with
>> those changes.
>
> Committed that way. Thanks! Ok for 4.7 branch as well?
yes, it is. Thanks,
-- Gaby
On Fri, May 18, 2012 at 10:53 PM, Jay K wrote:
>
> /src/gcc-4.7.0/configure -disable-bootstrap -enable-languages=go
>
>
> book2:gccgo-4.7 jay$ g++ -v
> Using built-in specs.
> Target: i686-apple-darwin9
> Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
> -enable-werror -
On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor wrote:
> To be clear, as far as I can see the Go frontend isn't doing anything
> wrong or dubious. It just happens to #include when
> it is available but is not. It looks like in gcc 4.0
> you can not #include when using -fno-rtti.
>
> We co
On Mon, May 21, 2012 at 12:08 AM, Ian Lance Taylor wrote:
> Gabriel Dos Reis writes:
>
>> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor wrote:
>>
>>> To be clear, as far as I can see the Go frontend isn't doing anything
>>> wrong or dubious. It
On Thu, May 24, 2012 at 2:26 PM, Peter A. Felvegi
wrote:
> Hello,
this list is not the appropriate place to discuss this.
Check a C++ forum.
>
> I'm not sure whether this is standard behaviour or not; nonetheless I was
> quite surprised:
Welcome to null pointer constant madness. It is standard
On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote:
> IMO, at the /very least/, libstdc++ should go ahead and change std::string
> to be the new implementation. Once std::string is ABI-incompatible between
> the modes, there's basically no chance that anyone would think that
> linking things t
On Fri, Jun 15, 2012 at 4:23 PM, Gabriel Paubert wrote:
> Does this basically mean that compiling C++ code with GCC4.7 will be playing
> Russian roulette?
I don't think so. Let's make sure we do not overstate the case and we keep
things in perspective and accurate.
-- Gaby
I have no plan for willful obstruction in solving this recurring and
really annoying
problem that trips up users again and again, under all kinds of
reasons (both perceived
or constructed.)
On Mon, Jun 18, 2012 at 3:46 AM, Jonathan Wakely wrote:
> The problems arise when user code that uses the "inline-only" code is
> linked to other user-code that has a different definition of that
> inline-only code.
Indeed.
A related question is whether for GCC-4.8 we should still continue
to c
On Mon, Jun 18, 2012 at 7:55 AM, Jeff Law wrote:
> On 06/16/2012 12:46 PM, Michael Matz wrote:
>>>
>>>
>> A soname change for a basic system library is a _major_ PITA and should be
>> avoided even at large costs. In that light: do you have a plan of action
>> of how to never change the soname aga
On Wed, Jul 11, 2012 at 6:18 AM, Ian Lance Taylor wrote:
> My version of Cary's notes (I just wrote this on my Google+ stream):
>
> We had a useful discussion about C++11 ABI issues at the GNU Tools
> Cauldron (http://gcc.gnu.org/wiki/cauldron2012). The approach will be
> shaped over time, but th
On Tue, Aug 14, 2012 at 9:05 PM, Diego Novillo wrote:
>
> I have committed rev 190402, which merges the cxx-conversion branch into
> trunk. Thanks to everyone who provided review feedback and tested the
> branch.
>
> While we have tested the changes pretty thoroughly, we will monitor results
> fr
On Wed, Aug 15, 2012 at 4:37 AM, Richard Guenther wrote:
>
> I face an issue with replacing macros with C++ functions and the
> way we implement gather-detailed-mem-stats. Currently the
> mem-stat info is passed at the call site of functions via macros
> like
>
> #define VEC_safe_grow_cleared(T,A
On Wed, Aug 15, 2012 at 5:11 AM, Florian Weimer wrote:
> On 08/15/2012 12:07 PM, Gabriel Dos Reis wrote:
>
>> You might try to encode/package information with the
>> parameters T and A, but essentially you will hit the wall
>> that __FILE__, __LINE__, and __FUNC
On Wed, Aug 15, 2012 at 5:10 AM, 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 (int bar) __attribute__((add_location_pack));
>
> that direc
On Wed, Aug 15, 2012 at 6:01 AM, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
>
>> On Wed, Aug 15, 2012 at 5:11 AM, Florian Weimer wrote:
>> > On 08/15/2012 12:07 PM, Gabriel Dos Reis wrote:
>> >
>> >> You might
On Wed, Aug 15, 2012 at 7:52 AM, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Michael Matz wrote:
>
>> Hi,
>>
>> On Wed, 15 Aug 2012, Richard Guenther wrote:
>>
>> > Prototype below - fire away on bikeshedding names.
>>
>> Make it mirror the preprocessor names that people are used to, and do awa
On Wed, Aug 15, 2012 at 11:21 AM, Tobias Burnus wrote:
> Gabriel Dos Reis wrote:
>>
>> A few points to consider:
>> * relation of __builtin_function_location to C99 (and C++11) __func__
>>
>> * Do we want to update libcpp to
On Wed, Aug 15, 2012 at 12:03 PM, Georg-Johann Lay wrote:
> Gabriel Dos Reis schrieb:
>
>> Richard Guenther wrote:
>>>
>>> Hm, well. The following includes documentation and the old new names,
>>> __builtin_file_location, etc.
>>
>>
>&g
On Wed, Aug 15, 2012 at 5:15 PM, Lawrence Crowl wrote:
> On 8/15/12, Gabriel Dos Reis wrote:
>> On Aug 15, 2012 Richard Guenther wrote:
>> > On Wed, 15 Aug 2012, Michael Matz wrote:
>> > > On Wed, 15 Aug 2012, Richard Guenther wrote:
>> > > > Prot
On Wed, Aug 15, 2012 at 7:34 PM, Lawrence Crowl wrote:
> Would it be more productive to ensure that existing tools, like
> valgrind, are effective with gcc?
Indeed. Richard's patch strikes me as the way to go with
the issue he raised.
-- Gaby
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
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
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
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
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
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
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
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
[ 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:
>
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.
>
1101 - 1200 of 1308 matches
Mail list logo
