Re: Power/PowerPC RIOS/RIOS2 obsolescence
On Fri, Jul 2, 2010 at 9:55 AM, Segher Boessenkool wrote: > [I proposed removing RIOS support, since it heavily gets in the way > for my project exposing the XER[CA] flag]. > >> My argument is simply this, sorry if it wasn't clear in the last >> email, bottom line up front: >> - It can just as easily be removed in the future if it is broken for >> more than one release rather than evicting support. > > I can guarantee you that the changes I am trying to make _will_ break > RIOS support. RIOS handles the carry flag quite differently from > PowerPC and Power Architecture, and I have no way to test RIOS either. > Since there is no significant community using these chips anymore, > removing RIOS support seemed like the best course of action. > >> - It shouldn't add unwieldy maintenance overhead. > > It already HAS been unwieldy maintenance overhead for years. > >> The old stuff can >> be walled off, conditionally built, and otherwise removed from the >> main focus. > > You obviously haven't looked at the code in detail, if you think this. > >> - The code is already written and just needs a maintainer. >> - I have the hardware and desire to maintain it. > > Feel free to split off a new backend then. The current intertwined > mess cannot be maintained properly. > > > Segher > Hi Segher, David explained some of his points in an off-list email. For whatever it's worth I withdraw my objections. Per David and your suggestion, I will attempt to import the older back end code in my own private tree as newer front ends become desirable for building common applications. I don't think this is ideal but it is clear there is mutual exclusion between the work you need to do (which has greater impact) and my limited hobby interests. Although my usage is impractical and merely for fun, the current back ends seem intuitively fragile. By being vertically intertwined in a giant c file to the OS and species of arch, I can't help but feel this may cause continued headaches in the future. There may be more legitimate reasons for supporting older platforms, especially with heavy embedded use of archs with vastly different species like mips, ppc, and i386. Of course, this may be well known (I'm sure there is historical background) and I have no solution to offer. Regards, Kevin Bowling
How to use __versa_string as std::string implementation?
Do I understand correctly that the current GCC implementation of std::string is non-conforming, because it does ref-counting + copy-on-write? If so, is there some compiler flag to switch to a conforming (non-ref-counting) std::string implementation? If I understand well, the Versatile String, __versa_string from provides such an implementation, right? Is there an easy way to recompile existing user code that uses std::string, in order to switch to a non-ref-counting implementation? Apologies for my ignorance, Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Re: How to use __versa_string as std::string implementation?
On 07/04/2010 04:19 PM, nielsdek...@xs4all.nl wrote: > Do I understand correctly that the current GCC implementation of > std::string is non-conforming, because it does ref-counting + > copy-on-write? If you mean by non-conforming "non-conforming to the not existing yet new C++ standard, so far known as C++0x", the answer is yes. > If so, is there some compiler flag to switch to a conforming > (non-ref-counting) std::string implementation? Nope. > If I understand well, the Versatile String, __versa_string from > provides such an implementation, right? Is there an > easy way to recompile existing user code that uses std::string, in > order to switch to a non-ref-counting implementation? Nothing special, no. And of course that code is just a starting point. Before advertising is a "conforming" (in the sense above) implementation has to be reviewed, some optimizations added, etc... Paolo.
Re: How to use __versa_string as std::string implementation?
[Oops, I shot myself in the foot by using a mail address that I'd rather keep spam free, in my previous message! I'm surprised the message was forwarded straight to the mailing list, because it wasn't the address I used when I subscribed.] Do I understand correctly that the current GCC implementation of std::string is non-conforming, because it does ref-counting + copy-on-write? Paolo Carlini wrote: If you mean by non-conforming "non-conforming to the not existing yet new C++ standard, so far known as C++0x", the answer is yes. Thanks, that's what I meant indeed. (In fact I got the word "conforming" from gcc.gnu.org/gcc-4.1/changes.html which says that __versa_string provides "facilities conforming to the standard requirements for basic_string". But indeed, C++03 does allow COW implementations of std::string.) If I understand well, the Versatile String, __versa_string from provides such an implementation, right? Is there an easy way to recompile existing user code that uses std::string, in order to switch to a non-ref-counting implementation? Nothing special, no. And of course that code is just a starting point. Before advertising is a "conforming" (in the sense above) implementation has to be reviewed, some optimizations added, etc... Okay, so basically __versa_string is a starting point for the std::string implementation of the future, right? Is there any target date or target GCC release version for this new implementation to be included as the new std::basic_string? Thanks again, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Re: How to use __versa_string as std::string implementation?
On 07/04/2010 10:02 PM, Niels Dekker - address until 2010-10-10 wrote: > Thanks, that's what I meant indeed. (In fact I got the word > "conforming" from gcc.gnu.org/gcc-4.1/changes.html which says that > __versa_string provides "facilities conforming to the standard > requirements for basic_string". But indeed, C++03 does allow COW > implementations of std::string.) As a matter of fact, if you really meant the very old 4.1 release series, back in those times the C++0x working paper still allowed reference counting. If I remember correctly the decision dates circa the Sophia Antipolis meeting. > Okay, so basically __versa_string is a starting point for the > std::string implementation of the future, right? Is there any target > date or target GCC release version for this new implementation to be > included as the new std::basic_string? Not yet, I'm sorry. As far as I can see - but I know somebody is still trying to figure out alternate strategies - rolling in a new implementation means breaking the ABI. Nasty issues. Paolo.
Re: [x86]: Allow @GOTOFF in non-memory context?
On Fri, 2010-06-25 at 10:48 -0700, Richard Henderson wrote: > > ; Current assemblers are broken and do not allow @GOTOFF in > > ; ought but a memory context. > > > > Code, following this comment disables or special-cases > > "pic_symbolic_operands". > > > > I'm investigating, which "current assemblers" are broken, since my > > assembler from binutils-2.20 happily assembles: > > > > addl x...@gotoff(%ebx), %eax > > > > in 32bit mode, as well as > > > > addq x...@gotpcrel(%rip), %rax > > > > in 64bit mode. > > Note that this *is* a memory context. The problematic cases were > > addl $...@gotoff, %eax > > which needed to be written as > > lea x...@gotoff(%eax), %eax > > to satisfy the memory context requirement of the broken assemblers. gas 2.13.1 (the oldest supported version as required by documentation) also handles the first form without problems. Uros.
gcc-4.3-20100704 is now available
Snapshot gcc-4.3-20100704 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100704/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 161812 You'll find: gcc-4.3-20100704.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100704.tar.bz2 C front end and core compiler gcc-ada-4.3-20100704.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100704.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100704.tar.bz2 C++ front end and runtime gcc-java-4.3-20100704.tar.bz2 Java front end and runtime gcc-objc-4.3-20100704.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100704.tar.bz2The GCC testsuite Diffs from 4.3-20100627 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
