Re: c++0x {g++}4.4, =default definition outside template class fails{ to link}.
Simon Hill wrote: Sorry Paolo, that definitely should have been. no problem. Is this a bug? I think so. I opened c++/37234, you may want to add yourself to the CC list of the PR. Paolo.
Re: Better GCC diagnostics
> My point is that if the rest of the compiler extends diagnostics.c to > handle caret and ranges and all other features, Ada would need carry > all that around even if gnat has its own diagnostics machinery. But > perhaps that is OK. Certainly OK, what possible (noticeable) issue would you foresee ? > I am not trying to force anything just make you > aware of the situation. Well, it's not like there's a choice anyway. As Robert and myself explained, GNAT's machinery is much more powerful in terms of diagnostic compared to libcpp (or even compared to what's planned), and this machinery is used in other non GCC contexts anyway, so has its own life cycle and raison d'être. > I see that as very unrealistic, GCC development is already complex > enough, so we will have to live with the duplication. That was of course a semi joke :-) Only semi because it would make a lot of sense to write a code generator from scratch in Ada, but of course it does not make much sense to rewrite GCC in Ada. > I just wanted to > make you notice that even if location_t is moved out of libcpp, GNAT > will still link with diagnostic.c and whatever other diagnostics > features that will be implemented. The burden of the duplication would > be on GNAT executable, the other front-ends do not carry GNAT's code. > Probably the effect of it is negligible, anyway. Right, effect is clearly negligible, if noticeable at all. > Again, my point is that even if GNAT has all these features already, > GNAT should be interested in this since it means moving stuff out of > libcpp which will allow to break that dependency. C/C++ could very > well implement caret diagnostics and everything else within libcpp, so > the dependency of GNAT with libcpp would be actually harder to break. > My fear is that if the other FEs do not care about this issue "because > we have it already", then this is exactly what will happen. Well, if other GCC developers do not see the obvious advantages in splitting libcpp in several logical pieces, then so be it, what can I say. Arno
broken svn commit logs and how to fix them
Dear all, If you mess up a commit log, not everything is lost. You can edit the commit log of a particular revision by doing: svn propedit -r REVISION --revprop svn:log Note that this change is not versioned: whatever was the log before is completely overwritten by the new one. I have fixed the log of revision 138275, which was a diff dump until a moment ago, with the correct one. Some more broken commits logs follow. Please fix them: revision committer problem 129905 dgregor a diff 129888 pinskia a diff 139317 jakubthe commit log mentions files that were not committed 138154 meissner this should mention the files modified 138141 hubicka this should mention the files modified 138140 hubicka the commit log mentions changes that were not committed If you spot an obviously wrong commit log message, please fix it yourself or bug the committer to fix it. Thanks, Manuel.
Re: new file for testsuite gcc.dj
On Sun, 2008-08-24 at 16:41 +0530, Niklaus wrote: > i ran with this file under testsuite/gcc.dj and it aborted with -O2. > It is for the optimization bug that i reported few days back. If we > don't have this test can someone add ths. File a bug report, if you haven't already, and include the test case in the bug report. When the bug is fixed the patch will include a new test, which will either be the one you provided or something based on it. Janis
Re: \testsuite\ext\stdio_filebuf\char\10063-1.cc
On Sun, 2008-08-24 at 14:27 -0700, Karl Lindstrom wrote: > Hello, > > I am trying to port the testsuite to an embedded environment. > I have gotten all of the needed tests to compile, and am debugging > those test that fail at runtime now. > > \ext\stdio_filebuf\char\10063-1.cc fails. This test is part of the libstdc++ testsuite. You're more likely to get a response from mail to [EMAIL PROTECTED] Janis
Re: broken svn commit logs and how to fix them
I'm seeing messages on this list repeating over and over (several minutes apart, maybe as much as 15 minutes or so). I'm not sure if the are just messages from Manuel or also from others. Is it just me? It seems to be specific to this list... paul
Re: broken svn commit logs and how to fix them
Paul Koning wrote: I'm seeing messages on this list repeating over and over (several minutes apart, maybe as much as 15 minutes or so). I'm not sure if the are just messages from Manuel or also from others. Is it just me? It seems to be specific to this list... It seems that all the repeats are generated by gmail.com. You will note that NightStrike's messages are repeated as well. David Daney
Re: broken svn commit logs and how to fix them
Am Dienstag 26 August 2008 schrieb Paul Koning: > I'm seeing messages on this list repeating over and over (several > minutes apart, maybe as much as 15 minutes or so). I'm not sure if > the are just messages from Manuel or also from others. > > Is it just me? It seems to be specific to this list... > >paul Manuel's Message just apears once for me, but at the libstdc++ ML Sebastian's message regarding std::equal appears ten times. -- Maik PS: I'm subscribed via gmail
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Richard Henderson wrote: > H.J. Lu wrote: >> Can we declare that Linux/ia32 generates i486 insn by default? > > We the gcc team? I'm not sure. For now I'll say no. > > We an individual linux distributor? Certainly. > In fact I would be surprised if i586 wasn't a > decent minimum these days. I agree. We the GCC team have to accept that some CPUs may not have the ability to do this. That might be old x86 CPUs; it might also be brand-new embedded CPUs. Obviously, distributors can do whatever they please, but the C++ run-time library needs to tolerate CPUs without this feature. It can of course offer reduced functionality (at compile-time or at run-time) on CPUs without the necessary support. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Why --with-gmp doesn't default to --prefix for GCC-4.3.* ?
If you build and install binutils (for instance in $HOME), I think GCC build will use them when using --prefix to build GCC. But for GMP and MPFR, you need to set --with-gmp to the same path as --prefix. Would it be simpler to use the same --prefix to build binutils, GMP, MPFR and GCC - so defaults --with-gmp to --prefix when present? _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Mark Mitchell wrote: Obviously, distributors can do whatever they please, but the C++ run-time library needs to tolerate CPUs without this feature. It can of course offer reduced functionality (at compile-time or at run-time) on CPUs without the necessary support. As far as I'm concerned, I totally agree on both accounts. Maybe was not clear in this thread, but I sent the original message to point-out a *bug*, which had to be fixed, and quickly. To be safe, while waiting for the fix, I even reverted completely the new feature. Now the C++0x feature is back in, provided only for target implementing the atomic builtins unconditionally: it works that the corresponding declarations do *not exist* in if the prerequisites are not met. Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Mark Mitchell: Richard Henderson wrote: H.J. Lu wrote: Can we declare that Linux/ia32 generates i486 insn by default? We the gcc team? I'm not sure. For now I'll say no. We an individual linux distributor? Certainly. In fact I would be surprised if i586 wasn't a decent minimum these days. I agree. We the GCC team have to accept that some CPUs may not have the ability to do this. That might be old x86 CPUs; it might also be brand-new embedded CPUs. Setting the default to -march=i486 will still let people who target i386 to use -march=i386. The problem, from the point of view of a library such as boost::shared_ptr, is that there is no way to distinguish between user A, who just types g++ foo.cpp and expects to get a program that works well on a typical machine, and user B, who types g++ -march=i386 foo.cpp, with the explicit intent to run the result on a 386. Since A users outnumber B users, boost::shared_ptr assumes A and uses 486 atomic instructions even though __i486__ is not defined. Has the default been 486, I'd be able to recognize user B's intent and not use 486 instructions. (Not that I've ever received a bug report about shared_ptr not working on 386.)
Repeat messages (was Re: broken svn commit logs and how to fix them)
On 8/26/08, David Daney <[EMAIL PROTECTED]> wrote: > Paul Koning wrote: > > I'm seeing messages on this list repeating over and over (several > > minutes apart, maybe as much as 15 minutes or so). I'm not sure if > > the are just messages from Manuel or also from others. > > Is it just me? It seems to be specific to this list... > > > > > > It seems that all the repeats are generated by gmail.com. You will note > that NightStrike's messages are repeated as well. > > David Daney > Really? I don't see that in the archives.
