Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| class C {
| public:
| int size() const;
many people, including "dinosaure" C++ users, wish the standard containers
did not have unsigned return type for size().
-- Gaby
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Wed, 10 May 2006, Andreas Schwab wrote:
|
| > Mike Stump <[EMAIL PROTECTED]> writes:
| >
| > > Speaking of typeof, should typeof (vla) follow the same rules as for
| > > sizeof (vla)? vla, evaluate, otherwise, no eval.
| >
| > How would typeof
Steven Bosscher <[EMAIL PROTECTED]> writes:
| Hi,
|
| A long time ago, Per added USE_MAPPED_LOCATION, but a full switch-over was
| held up by (fixable) PCH issues and by Ada maintainers who expect problems
| for GNAT if USE_MAPPED_LOCATION becomes the default.
|
| The latest discussions I could
Eric Botcazou <[EMAIL PROTECTED]> writes:
| > Actually, the Fortran and objc people play nice too, and TBQH, i
| > wouldn't mind if we were only a C/C++/F95/Objc compiler.
|
| Yeah, and I presume Objc is in the basket only because it's essentially C.
| F95 is a different case since it's a brand n
Robert Dewar <[EMAIL PROTECTED]> writes:
| Steven Bosscher wrote:
|
| > Anyway, if this can be done in gigi, then let's make a plan and work
| > on it. I'd really like to see MAPPED_LOCATION become the default, and
| > Ada is basically the major blocker right now, so we need to agree on
| > some
Richard Guenther <[EMAIL PROTECTED]> writes:
| Hi,
|
| Following RMS request of removing source copies of other projects I
| asked him if he considers it ok to have copies of the generic math
| transcendentals routines of glibc in libgcc-math and to distribute
| them under GPL + libgcc exception
Richard Guenther <[EMAIL PROTECTED]> writes:
[...]
| As far as I understand we (GCC) have to develop our own codes
| independently of glibc unless RMS agrees to have copies/forks of
| glibc code in GCC (this includes license changes to GPL + libgcc exception
| like in this case). What is fine a
the project are, given its "unconventional" way of "hiring" people.
People get inactive for some period of time for various reasons, some
of whichg are not subject of public debate.
-- Gaby
--
Steven Bosscher <[EMAIL PROTECTED]> writes:
| But is it really necessary to remove the egg too? Can we have
| it back? Pleaeaeaeaese? :-)
yes, please let's have the egg back.
-- Gaby
Devang Patel <[EMAIL PROTECTED]> writes:
| Tom Tromey wrote:
| > * Why put the optimization diary into the object file?
| > Why not just have -Wdiary and print it along with all the warnings?
| > (I'm sure there's an answer to this, it would just be nice if it
| > were in the document...)
|
Devang Patel <[EMAIL PROTECTED]> writes:
| [ Interestingly, there is a long standing request, here at Apple, to list
| command line options in object file (even when optimization is not used).
| One of our intern tried to put them in STABS string. It may be a good
| idea to use DWARF in that
On Tue, 6 Jun 2006, Daniel Jacobowitz wrote:
| On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote:
| > Devang Patel <[EMAIL PROTECTED]> writes:
| >
| > | [ Interestingly, there is a long standing request, here at Apple, to list
| > | command line options in obje
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| (b) keep the warnings of conversions that may change a value in
| Wconversion and move its original purpose (the warnings about
| prototypes causing ... in the absence of a prototype) to a new option
| (suggestions are welcome).
I prefer
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| On 10/06/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
| >
| > Here is my vote, have four options:
| > -Wconversion the same as now.
|
| This is bad idea. Currently many people are relying in undocumented
| behaviour or the false perception that
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| On 10 Jun 2006 20:07:02 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > I'll like to see a more precise definition of your understanding of
| > "coercion" versus "conversion". Last
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| My project is about "risky" coercions in general: assignments,
| operators, prototypes. You can see some (and comment and propose)
| testcases in http://gcc.gnu.org/wiki/Wcoercion .
void h2(void)
{
int i;
for(i=0; i < siz
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Typing "make" in $objdir/gcc (after a bootstrap) sometimes results in
| errors like:
|
| build/gencondmd.o: In function `VEC_rtx_heap_reserve':
| /net/sparrowhawk/scratch/mitchell/src/lto/gcc/rtl.h:195: undefined
| reference to `vec_heap_p_reserve'
|
|
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > (Which technique would you recommend to address what you refer to as
| > the "search engine" issue?)
|
| I have to ask, why do people use lynx these days when links or elinks
| are much faster and better text mode browsers?
some people don't run impe
for good?
[ the compiler for this C-dialect uses GCC/gcc as "backend" ]
Thanks,
-- Gaby
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Texas A&M University --
Andrew Pinski <[EMAIL PROTECTED]> writes:
| > while looking into a recent mismatch between GCC-4.x and a C dialect
| > EH implemented as setjmp/longjmp, I recalled there was a talk about
| > extending GNU C with __try/__finally construct:
| >
| > http://gcc.gnu.org/ml/gcc-patches/2002-11/ms
On Thu, 15 Jun 2006, Andrew Pinski wrote:
| >
| > On Thu, Jun 15, 2006 at 07:21:03PM -0400, Andrew Pinski wrote:
| > > > while looking into a recent mismatch between GCC-4.x and a C dialect
| > > > EH implemented as setjmp/longjmp, I recalled there was a talk about
| > > > extending GNU C with _
On Thu, 15 Jun 2006, Andrew Pinski wrote:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | > while looking into a recent mismatch between GCC-4.x and a C dialect
| > | > EH implemented as setjmp/longjmp, I recalled there was a talk about
| > | > extending GNU C with __try/__finally co
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
| On 6/16/06, Mike Stump <[EMAIL PROTECTED]> wrote:
| > foo() {
| >int i = 99;
| >__builtin_setjmp(A)
| >if (i) {
| > print i
| > --i;
| > __builtin_longjump(A);
| >}
| >
| > It used to not infinite loop, now it does.
| >
Andrew Haley <[EMAIL PROTECTED]> writes:
| Dustin Laurence writes:
| > On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote:
| >
| > > If every language were going to have the feature, then, moving it
| > > down into the mid-end or back-end might make sense, but I don't think
| > >
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| And, "extern template" is a GNU
| extension which says "there's an explicit instantiation elsewhere; you
| needn't bother implicitly instantiating here".
FWIW, "extern template" is now part of C++0x.
| I'm
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| Dear all,
|
| from comments in the #gcc irc channel, I understood that it is not
| advisable for gcc patches to use the const qualifier in function
| prototypes. I would like to understand why. Apart from its main
| purpose, I believed that the
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 27, 2006, at 7:58 AM, Gabriel Dos Reis wrote:
|
| > We we do have numbers that support that claim for real programs, then
| > we have a bug in the optimizers :-)
|
| Huh?
Yes.
| "Stupid" example where a const argumen
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
[...]
| I'd like to do for tree and rtx what I did for const char *, namely
| constify those tree/rtx functions that aren't supposed to modify their
| arguments. This would require introducing the const_tree and
| const_rtx typedefs Tristan suggested.
"Dave Korn" <[EMAIL PROTECTED]> writes:
| On 29 June 2006 14:44, Richard Guenther wrote:
|
| > But with C language constructs you cannot assume that an object
| > passed to a function via a const pointer is not modified. So, there
| > is no real "const" regarding to objects pointed to. Consider
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| If we're going to guarantee this stuff for the future, we'll have to
| fix the bug, make sure it's doesn't destabilize the compiler and write
| some test cases. If we're really serious about it we should make it a
| documented extension to C.
if
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Furthermore, I've read people suggesting that we are gratuitously
| > broking code. That is misleading. The code was invoking undefined
| > behaviour and, before, we did not make any explicit gua
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
[...]
| I personally don't agree that this needs to be a documented extension.
| I'm simply going on a more general rule which I tried to state above:
| I don't think we should insert a trap call for undefined code.
If it should not a documented exten
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Andrew Haley <[EMAIL PROTECTED]> writes:
|
| > If we make a change for openssh to allow this undefined behaviour,
| > then do we agree to keep it working or not? If we agree that we will,
| > then we have to at least add some test cases and we have
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Ian Lance Taylor wrote:
|
| > I realized that I am still not stating my position very clearly. I
| > don't think we should make any extra effort to make this code work:
| > after all, the code is undefined. I just think 1) we should not
| > insert a t
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| int main()
| {
| int i = NULL; // { dg-warning "" } converting NULL to non-pointer type
In many C implementations, NULL is defined as
#define NULL ((void *) 0)
which renders the above initialization ill-formed -- not just a warnin
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
[...]
| The result of calling function pointer casted to sufficiently different
| type is
| a real example an undefined behavior.
As I said earlier, it is fruitless to try to impose an ordering on
the space of undefined behaviour.
-- Gaby
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | The result of calling function pointer casted to sufficiently different
| > | type is
| > | a real example an unde
-elf.c:27 currently says
#include "libelf.h"
Should that read
#include
?
-- Gaby
--
Gabriel Dos Reis
[EMAIL PROTECTED]
onfigure should make sure the needed -I path_to_libelf_h
| is added if it is not already in the system search path.
|
| Jakub
Daniel Berlin <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Hi,
| >
| > My first attempt to compile the lto branch met with resista
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > libelf (0.8.5-35)
|
| This libelf is too old, see michael matz's message.
Which one is it?
-- Gaby
Tristan Wibberley <[EMAIL PROTECTED]> writes:
| Daniel Jacobowitz wrote:
| > On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
| >> If the programmer had intended that the type should appear to not
| >> exist. it wouldn't be defined in a header #include-able by client
| >> code. T
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
[...]
| I just don't get it. Why should it matter whether a member function is
| virtual or not in order to be able to call it from outside this shared
| object? Either you can access the public members of the class, or you
| can't. Being able to a
Tristan Wibberley <[EMAIL PROTECTED]> writes:
| Mike Stump wrote:
| > On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
| >> "the client code needs to know about the existence of this type so
| >> it can get pointers and references to instances and pass them back
| >> in later and maybe be ab
Tristan Wibberley <[EMAIL PROTECTED]> writes:
[...]
| I am suggesting that visibility attributes should *not* touch the C++
| type system in any way.
But then, at the same time you're talking of polymorphic types
(e.g. vtables).
| Since C++ doesn't have a notion of module a
| class that the C
Jason Merrill <[EMAIL PROTECTED]> writes:
[...]
| > | - I don't recall suggesting that
| > | multiple types with the same name should be able to exist.
| > then you have to consider that suggestion and come with an answer.
|
| I don't see why. The point is that visibility is orthogonal to
| lin
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| > So, -concretely- what happens to a class S (e.g. associated type info object
| > address, address of member functions, etc.) with external linkage,
| > defined in multi
Jason Merrill <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >> Joe Buck wrote:
| > Now, this being a conscious decision for ODR violation, it would
| > probably need to be documented because then we may have
| >typeinfo1 != typeinfo2
| > and yet
| >
that these two classes are both named S but
| they're different, just as if they were in different namespaces.
That would mirror how C++ handles classes in unnamed namspaces. In
other words, the visibility would have to be part of the mangled name.
| > On Thu, Jul 13, 2006 at 03:41:29PM
Geoffrey Keating <[EMAIL PROTECTED]> writes:
| Joe Buck <[EMAIL PROTECTED]> writes:
|
| > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > > > > I'm not clear about "you can't compare them".
| > > > >
| > > &
Geoffrey Keating <[EMAIL PROTECTED]> writes:
| Jason Merrill <[EMAIL PROTECTED]> writes:
|
| > Gabriel Dos Reis wrote:
| > > Jason Merrill <[EMAIL PROTECTED]> writes:
| > > So, -concretely- what happens to a class S (e.g. associated type
| > > info
Geoffrey Keating <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > Jason Merrill <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | > | - I don't recall suggesting that
| > | > | multiple types with the same name sh
rule. It makes the case defined.
| > | > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > | > > I'm not clear about "you can't compare them".
| > | > >
| > | > > Surely, I can take the address of typeid(S) and pass it
| >
Mike Stump <[EMAIL PROTECTED]> writes:
[...]
| All in all, we should just agree to not worry about non-merged
| typeinfo name, or remove support for it.
If we remove support for it, then that indeed simplifies the issue.
-- Gaby
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| > On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| > is defined in terms of the mangled names of the types. I'm unable to
| > find the mangled
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| >
| > | On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| > | > On platfoms where __GXX_MERGED_TY
Mike Stump <[EMAIL PROTECTED]> writes:
| On Jul 14, 2006, at 3:50 PM, Gabriel Dos Reis wrote:
| > I seem to remember a PR posted by Adobe people kind of related to
| > this, but maybe I'm remembering wrong. I have to dig up bugzilla.
|
| If it is a bug that describes how matc
Mike Stump <[EMAIL PROTECTED]> writes:
| On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:
| > What that concretely means is that it alienates, for example, codes
| > based on Factory desigbn pattern using typeinfo objects.
|
| I'd love some input from the MS VC++ programm
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
[...]
| I think that in stage 1, we should switch to not searching any of the
| configured paths in favor of the relocated paths. Carlos has been
| working on patches for this. I'm sure it will break a few
| unexpected configurations. When it does,
"Rafael Espíndola" <[EMAIL PROTECTED]> writes:
| I am trying to build a table with offsets of global pointers from a
| given pointer:
|
| void *fs[] = {f1 - f1, f2 - f1};
|
| where f1 and f2 are functions.
|
| GCC is able to figure out that (f1 - f1) is 0, but says "initializer
| element is not
"Denis Vlasenko" <[EMAIL PROTECTED]> writes:
| On 7/30/06, Joe Buck <[EMAIL PROTECTED]> wrote:
| > On Sat, Jul 29, 2006 at 07:33:03PM -0400, Simon Boulet wrote:
| > > After a couple hours debugging code, I figured our an if() somewhere
| > > had a trailing ; like this:
| > >
| > >
Mark Mitchell <[EMAIL PROTECTED]> writes:
| DJ Delorie wrote:
| >> And back to my original answer: it's up to each language to decide
| >> that.
| >
| > Hence my original question: is it legal or not? What did the C++
| > developers decide?
|
| The C++ standard implies that for all pointer-to-o
[EMAIL PROTECTED] writes:
| Is this version for windows or linux?
this is not a binary release; it is source release.
-- Gaby
DJ Delorie <[EMAIL PROTECTED]> writes:
| > Good! In that case, you don't need them to be pointers at all. :-)
| >
| > I think you should just declare them as integer types.
|
| That makes initializing function pointers messy.
|
| Besides, they're not integers. They're pointers. I'd *like* to
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
[...]
| > In general I think I personally am on the very conservative edge of
| > gcc developers, in that I am generally opposed to breaking existing
| > code. But this particular optimization will let us do a much better
| > job on very simple loop
Ross Ridge <[EMAIL PROTECTED]> writes:
[...]
| >>I think this is best done by linker which
| >>can much more reliably compare the contents of functions to see if they
| >>are the same.
| >
| >No it can't. It has no idea what a function consists of other than a
| >bunch of bytes, in pretty much al
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| > >No it can't. It has no idea what a function consists of other than a
| > >bunch of bytes, in pretty much all cases. ... Stupid byte
| > >comparisons of functions generally won't save you anything truly
| > >interesting.
| >
| > Microsoft's implemen
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Mon, 2 Oct 2006, Jan van Dijk wrote:
|
| > On Monday 02 October 2006 12:57, Joseph S. Myers wrote:
| > > On Mon, 2 Oct 2006, Jan van Dijk wrote:
| > > > * the C99 and C++ standards say *nothing* about the details of compex
| > > > multiplication
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Gaby
|
| > | > My question was a slightly different one. To me it is not clear
| > whether the | > standard allows the treatment of (r,0) as r in
| > complex operations. For | > example: is it allowed to handle
| > (r,0)*(x,y) as r*(x,y)?
| > | | I d
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| But, the form in the test case where we are not even starting with a
| pointer-to-member, but merely the name of a member function. I think
| that's an intentional tightening; C++ doesn't allow you to do anything
| with the name of a member funct
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| It might make the most sense to go the auto-generation route, and then
ChangeLogs entries, when properly done (by people like RTH or Roger
Sayle), carry highly valuable information about what the purpose of a
change-set is; not just the code. I'm of
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Mon, 14 Feb 2005, Matt Austern wrote:
|
| > What was the rationale behind issuing this warning? I find it rather
| > unfriendly. In this example, after all, the user isn't doing anything
wrong.
| > scalb is not defined in any standard that I c
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
| > I'm sure there are still lots of horrible bugs, which will only be
| > found with a more complete test suite. But the core functionality
| > works, and at this point I think it'll improve
Paolo Bonzini <[EMAIL PROTECTED]> writes:
| > > ISTR the name change was to avoid a switch named -fdump-rtl-rtl.
| > To invent an option name alias and use a minor repetition in it
| > as a reason for changing the old behavior is Bad.
|
| It is not merely an option name alias. It came together w
Volker Reichelt <[EMAIL PROTECTED]> writes:
| Yesterday the output of the following program changed
| (probably due to the fix for PR19076):
Thanks for raising this issue.
|
| ==
| template int ref (T&){ return
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > Actually, we do have machinery to print statement-expression. It is
| > just that calling dump_expr() is wrong.
|
| Why do we want to print them? When does that help the user debug the
| problem? The only
Neil Booth <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:-
|
| > That statement is factually false as can be verified with EDG-3.5:
|
| Oh come on Gaby, that's not printing an expression, it prints
Please, the statement was that EDG does not print expression outside
decl
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > Lower forms appear because currently we do not do a good in the
| > front-end and pretty-printer telling which level of abstraction is
| > preferred. I noted initial effort in that direction has a
Joe Buck <[EMAIL PROTECTED]> writes:
| On Wed, Feb 23, 2005 at 12:14:23PM -0500, Jason Merrill wrote:
| > On 23 Feb 2005 16:49:51 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| >
| > > Neil Booth <[EMAIL PROTECTED]> writes:
| > >
| > > | Gabrie
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > I don't think it makes sense or it serves any useful purpose removing
| > you from maintainership, although I believe you should exercise it
| > with more openness.
|
| Are we talking here
Marcin Dalecki <[EMAIL PROTECTED]> writes:
| On 2005-02-23, at 18:40, Gabriel Dos Reis wrote:
| > ndards for error messages, etc.)
| >
| > That certainly would require changing many things, e.g. Emacs support
| > and like. That is a reason why I approach this is
Jakub Jelinek <[EMAIL PROTECTED]> writes:
| On Wed, Feb 23, 2005 at 06:51:46PM +0100, Gabriel Dos Reis wrote:
| > | I think that the best solution for the long term is the caret approach,
| > | printing out the original source line that the user typed. Trying to
| > | re-generate
Tom Tromey <[EMAIL PROTECTED]> writes:
| >>>>> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| Mark> (However, I've never had the time or energy to
| Mark> work through the process of implementing the caret approach, which is
| Mark&
James E Wilson <[EMAIL PROTECTED]> writes:
| Marcin Dalecki wrote:
| > this. Every time I see gcc reporting tens of k errors after discovering a
| > serious parser error for no good reason running out of every xterm
| > scroll back
|
| The -Wfatal-errors option will make gcc exit after the first
Andreas Schwab <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > I've seen cpplib uses that format for a long time now (I think it was
| > Neil's work), but I do not seem to see emacs actively take advantage
| > of it.
|
| Emacs 22 w
Neil Booth <[EMAIL PROTECTED]> writes:
| I also suggest you stop viewing everything as a personal attack.
Thanks for the suggestion, but it would be valuable if its predicate
hold. I do not view anything as a personal attack.
-- Gaby
personal attack, but because
I can only speak for myself.
--
Gabriel Dos Reis
[EMAIL PROTECTED]
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?
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
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
Hi Diego,
Does gengetype works with inheritance now? I could not
find anything to that effect in the documentation.
Thanks,
-- Gaby
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
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
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
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
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
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
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
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.
>>>
>>>
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
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
901 - 1000 of 1308 matches
Mail list logo
