Re: Deprecation/removal of nios2 target support

On 4/18/24 13:41, Arnd Bergmann wrote: On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove support from all toolchain components after the release is made. I'm not sure the

Re: Deprecation/removal of nios2 target support

On 4/18/24 8:41 PM, Arnd Bergmann wrote: On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove support from all toolchain components after the release is made. I'm not sure ther

Re: Deprecation/removal of nios2 target support

On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote: > On Wed, 17 Apr 2024, Sandra Loosemore wrote: > >> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove >> support from all toolchain components after the release is made. I'm not >> sure >> there is an established process f

Re: Deprecation/removal of nios2 target support

On 4/18/24 10:06, Jeff Law wrote: ACK.  Just one more note to the wider audience.  I looked at QEMU's user mode support for nios2 on/off over the last couple years.  It never seemed to work well enough be able to run the GCC testsuite reliably. I looked at the problems with the nios2 user-mo

Re: Deprecation/removal of nios2 target support

On 4/18/24 9:57 AM, Joel Sherrill wrote: On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers > wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > support from all toolchai

Re: Deprecation/removal of nios2 target support

On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers wrote: > On Wed, 17 Apr 2024, Sandra Loosemore wrote: > > > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > > support from all toolchain components after the release is made. I'm > not sure > > there is an established proce

Re: Deprecation/removal of nios2 target support

On Wed, 17 Apr 2024, Sandra Loosemore wrote: > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > support from all toolchain components after the release is made. I'm not sure > there is an established process for obsoleting/removing support in other > components; besides

Re: Deprecation/removal of nios2 target support

On 4/18/24 7:53 AM, Thomas Huth wrote: On 18/04/2024 05.27, Sandra Loosemore wrote: Tomorrow I plan to push patches to mark the nios2 target as obsolete in GCC 14. Background: Intel has EOL'ed the Nios II processor IP and is now directing their FPGA customers to a RISC-V platform instead. h

Re: Deprecation/removal of nios2 target support

On 18/04/2024 05.27, Sandra Loosemore wrote: Tomorrow I plan to push patches to mark the nios2 target as obsolete in GCC 14. Background: Intel has EOL'ed the Nios II processor IP and is now directing their FPGA customers to a RISC-V platform instead. https://www.intel.com/content/www/us/en/co

Deprecation/removal of nios2 target support

Tomorrow I plan to push patches to mark the nios2 target as obsolete in GCC 14. Background: Intel has EOL'ed the Nios II processor IP and is now directing their FPGA customers to a RISC-V platform instead. https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-i

Re: Upcoming removal of legacy ranges and conversion to wide_ints.

Hi, On Tue, Apr 25 2023, Aldy Hernandez via Gcc wrote: > After GCC 13 is released we will remove legacy range support from the > compiler, and convert irange's to wide_ints. I want to give everyone > a heads up, to help understand what's involved and what the end result is. > [...] > > 1. Conve

Upcoming removal of legacy ranges and conversion to wide_ints.

After GCC 13 is released we will remove legacy range support from the compiler, and convert irange's to wide_ints. I want to give everyone a heads up, to help understand what's involved and what the end result is. Legacy ranges are basically the value_range type (int_range<1>) where the internal

Linker removal of trampolines on Microsoft Windows targets

Hi all, Microsoft's Visual C++ compiler has the ability to remove trampolines generated by the linker (which ultimately calls __imp_SymbolName from the DLL import address table) when linking with code that is intended to be loaded from a DLL if link time optimization on their compiler was specifie

Re: Protest against removal of RMS from GCC Steering Committee

On Thu, 2021-04-01 at 17:23 +0200, Andrea G. Monaco wrote: > > I strongly disagree with the removal of Dr. Stallman from the > Steering > Committee. RMS was not removed from the GCC Steering Committee; his name was removed from the *web page* of the steering committee. Based on th

Re: Protest against removal of RMS from GCC Steering Committee

On April 1, 2021 5:23:25 PM GMT+02:00, "Andrea G. Monaco" wrote: > >I strongly disagree with the removal of Dr. Stallman from the Steering >Committee. > >Not only RMS wrote the GCC initially, but I think he is the best person >by far who can guarantee the values of f

Protest against removal of RMS from GCC Steering Committee

I strongly disagree with the removal of Dr. Stallman from the Steering Committee. Not only RMS wrote the GCC initially, but I think he is the best person by far who can guarantee the values of free software, with unmatched integrity and lucidity. That's especially important in the SC,

Re: CC0 removal branch

On 12/15/20 10:27 AM, Segher Boessenkool wrote: > Hi! > > I have updated my CC0 removal branch I started in 2019: > refs/users/segher/heads/cc0 > (yes I know this needs some patch series work; this branch rebases). > > I have tested it all on powerpc*, and sill test it

CC0 removal branch

Hi! I have updated my CC0 removal branch I started in 2019: refs/users/segher/heads/cc0 (yes I know this needs some patch series work; this branch rebases). I have tested it all on powerpc*, and sill test it with cross-compilers to all Linux targets later today. I already know one problem

Re: Spam, bounces and gcc list removal

Hi Winfried, > [..] > > Spam bouncing is evil and often hits an innocent person > [..] > > others like me might see it different: > Spam discarding is evil and often hits an innocent person. > > Silently discarding a legal mail because of false spam-detection is > the worst case f

Re: Spam, bounces and gcc list removal

On Sun, 22 Mar 2020, Florian Weimer wrote: > > You mean as with a failure response given to the SMTP DATA command? > > This is actually equally evil as the resulting bounce (i.e. a delivery > > failure notification, or a flood of them, once other MTAs have joined in a > > response to a mass m

Re: Spam, bounces and gcc list removal

* Maciej W. Rozycki: > On Sun, 22 Mar 2020, Florian Weimer wrote: > >> > Spam bouncing is evil and often hits an innocent person whose address has >> > been faked by the sender of spam, making the source of bounces not better >> > than the originator. >> >> I expect this to be an SMTP-level re

Re: Spam, bounces and gcc list removal

On Sun, 22 Mar 2020, Florian Weimer wrote: > > Spam bouncing is evil and often hits an innocent person whose address has > > been faked by the sender of spam, making the source of bounces not better > > than the originator. > > I expect this to be an SMTP-level rejection, not a bounce. source

Re: Spam, bounces and gcc list removal

Am 21.03.20 um 21:29 schrieb Frank Ch. Eigler via Gcc: Hi - since the change to the new list management, there has been an uptick of spam getting through. Spam is bounced by my ISP, and this just resulted in a warning that there were too many bounces and that I would get removed from the list u

Re: Spam, bounces and gcc list removal

* Maciej W. Rozycki: > On Sat, 21 Mar 2020, Frank Ch. Eigler via Gcc wrote: > >> > > So, a request: Could the overseers either install more effective >> > > spam protection for the list as a whole (preferred) >> >> Heh, if only it were that easy! Spam filtering was and is distinct >> from mailin

Re: Spam, bounces and gcc list removal

Hello Maciej, On Sat, Mar 21, 2020 at 09:22:31PM +, Maciej W. Rozycki wrote: [..] > Spam bouncing is evil and often hits an innocent person [..] others like me might see it different: Spam discarding is evil and often hits an innocent person. Silently discarding a legal mail

Re: Spam, bounces and gcc list removal

On Sat, 2020-03-21 at 13:08 -0700, H.J. Lu via Gcc wrote: > On Sat, Mar 21, 2020 at 12:40 PM Thomas Koenig via Gcc < > gcc@gcc.gnu.org> wrote: > > > > Hi, > > > > > since the change to the new list management, there has been > > > an uptick of spam getting through. Spam is bounced by my ISP, > >

Re: Spam, bounces and gcc list removal

On Sat, 21 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > So, a request: Could the overseers either install more effective > > > spam protection for the list as a whole (preferred) > > Heh, if only it were that easy! Spam filtering was and is distinct > from mailing list processing, and as you

Re: Spam, bounces and gcc list removal

Hi - > > since the change to the new list management, there has been > > an uptick of spam getting through. Spam is bounced by my ISP, > > and this just resulted in a warning that there were too many > > bounces and that I would get removed from the list unless I > > confirmed it (which I then did

Re: Spam, bounces and gcc list removal

On Sat, Mar 21, 2020 at 12:40 PM Thomas Koenig via Gcc wrote: > > Hi, > > > since the change to the new list management, there has been > > an uptick of spam getting through. Spam is bounced by my ISP, > > and this just resulted in a warning that there were too many > > bounces and that I would ge

Re: Spam, bounces and gcc list removal

Hi, since the change to the new list management, there has been an uptick of spam getting through. Spam is bounced by my ISP, and this just resulted in a warning that there were too many bounces and that I would get removed from the list unless I confirmed it (which I then did). This has now ha

Spam, bounces and gcc list removal

Hi, since the change to the new list management, there has been an uptick of spam getting through. Spam is bounced by my ISP, and this just resulted in a warning that there were too many bounces and that I would get removed from the list unless I confirmed it (which I then did). So, a request: C

Re: Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

On 2/27/20 3:02 PM, David Malcolm wrote: On Thu, 2020-02-27 at 14:07 -0500, Nicholas Krause wrote: Greetings All, After doing some more research it seems that it may be time to remove the garbage collector. I'm aware of the linkage to precompiled headers but even them I think its time due to

Re: Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

On Thu, 2020-02-27 at 14:07 -0500, Nicholas Krause wrote: > Greetings All, > > After doing some more research it seems that it may be time to > remove > the garbage collector. I'm > aware of the linkage to precompiled headers but even them I think > its > time due to two reasons: > > 1. The wor

Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

Greetings All, After doing some more research it seems that it may be time to remove the garbage collector. I'm aware of the linkage to precompiled headers but even them I think its time due to two reasons: 1. The work related to multithreading gcc is working around the global state of the c

Re: Towards removal of gcc/DATESTAMP

On Tue, 14 Jan 2020, Jakub Jelinek wrote: > o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat > BASE-VER | cut -d. -f 1); b=; if git rev-parse --verify --quiet > $o/releases/gcc-$r >/dev/null; then b=origin/releases/gcc-$r; elif git > rev-parse --verify --quiet $o/rel

Re: Towards removal of gcc/DATESTAMP

On Tue, Jan 14, 2020 at 04:52:12PM +0100, Jakub Jelinek wrote: > The following command prints the same string as DATESTAMP file > contains in all gcc-7 and later based branches I've tried so far (and nothing > when > e.g. invoked from within svn checkout). Jonathan wondered on IRC about the weird

Towards removal of gcc/DATESTAMP

Hi! The following command prints the same string as DATESTAMP file contains in all gcc-7 and later based branches I've tried so far (and nothing when e.g. invoked from within svn checkout). o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat BASE-VER | cut -d. -f 1); b=

Removal

I would like all software removed from my phone.accounts. etc immediately

Re: Argument Against Removal of GCJ

On 22 February 2017 at 05:52, R0b0t1 wrote: > Many of the users of GCJ and GNU Classpath do not know they are users > and, even if they do know, are not aware that it is being considered > for removal from the GCC nor aware of this mailing list. It's not being considered for r

Re: Argument Against Removal of GCJ

se OpenJDK has full cross-compiler support. > Many of the users of GCJ and GNU Classpath do not know they are users > and, even if they do know, are not aware that it is being considered > for removal from the GCC nor aware of this mailing list. The GNU Java > frontend is often the on

Argument Against Removal of GCJ

ally broken, ..." - Linus. http: //marc dot info/?l=linux-kernel&m=142173458609850 Many of the users of GCJ and GNU Classpath do not know they are users and, even if they do know, are not aware that it is being considered for removal from the GCC nor aware of this mailing list. The GNU Java

Re: target macro removal (fwd)

I sent this discussion of how one might go about large-scale target macro removal in response to an off-list enquiry last month, but it may be of more general interest. -- Joseph S. Myers jos...@codesourcery.com -- Forwarded message -- Date: Tue, 20 Jan 2015 18:04:27 +

[RFC] PowerPC / rs6000 call glue removal

uot;nop" instruction. All versions of AIX targeting PowerPC use the PowerPC "nop" instruction. All current configurations of GCC targeting PPC64 Linux and AIX only generate the "nop" instruction. The machinery is not used for the PPC32 SVR4 ABI and eABI. With the recent re

Re: Revision 176335 (removal of #include in thr-posix.h) cause numerous compile failures

On 2 August 2011 14:08, Markus Trippelsdorf wrote: > Revisions 176335 removed the traditional "#include " from > gthr-posix.h. This breaks the build of many programs (Firefox, Chromium, > etc.) that implicitly rely on it. > I'm not sure that the gain is worth the pain in this case. The "pain" fixe

Re: Revision 176335 (removal of #include in thr-posix.h) cause numerous compile failures

On Tue, Aug 02, 2011 at 03:08:03PM +0200, Markus Trippelsdorf wrote: > Revisions 176335 removed the traditional "#include " from > gthr-posix.h. This breaks the build of many programs (Firefox, Chromium, > etc.) that implicitly rely on it. This isn't the first time the libstdc++ headers were clea

Revision 176335 (removal of #include in thr-posix.h) cause numerous compile failures

Revisions 176335 removed the traditional "#include " from gthr-posix.h. This breaks the build of many programs (Firefox, Chromium, etc.) that implicitly rely on it. I'm not sure that the gain is worth the pain in this case. -- Markus

[PATCH 0/7] Change of call graph interface - cgraph_node function removal

Hi, I'm sending this email describing the set of patches also to the gcc mailing list because quite a few people do not follow the gcc-patches mailing list (where I am sending the individual patches). The patch set changes the interface of call graph and tries to avoid lazy call graph node creati

Re: Empty loops removal (Was Re: Some extra decorations)

2009/5/4 Peter Dimov: > Jonathan Wakely: >> >> 2009/5/4 Joseph S. Myers: >> > On Mon, 4 May 2009, Jan Hubicka wrote: >> > >> >> On mainline I enabled infinite loop removal at >> >> -funsafe-loop-optimizations. I would suggest adding >

Re: Empty loops removal (Was Re: Some extra decorations)

Jonathan Wakely: 2009/5/4 Joseph S. Myers: > On Mon, 4 May 2009, Jan Hubicka wrote: > >> On mainline I enabled infinite loop removal at >> -funsafe-loop-optimizations. I would suggest adding >> -fempty-loops-terminate and make it default for C++? It does not apply >&

Re: Empty loops removal (Was Re: Some extra decorations)

On Sun, May 3, 2009 at 4:17 PM, Jonathan Wakely wrote: > > Yes, the rule is new for C++0x, and it is in the context of for, while > and do-while loops only, not recursive calls. Does this include loops form from gotos also? Because this seems like it is very limited and not useful for optimizati

Re: Empty loops removal (Was Re: Some extra decorations)

On Mon, 4 May 2009, Jan Hubicka wrote: > On mainline I enabled infinite loop removal at > -funsafe-loop-optimizations. I would suggest adding > -fempty-loops-terminate and make it default for C++? It does not apply > for C, right? You mean for C++0x (I see no such rule in C++03),

Re: Empty loops removal (Was Re: Some extra decorations)

> 2009/5/4 Joseph S. Myers: > > On Mon, 4 May 2009, Jan Hubicka wrote: > > > >> On mainline I enabled infinite loop removal at > >> -funsafe-loop-optimizations.  I would suggest adding > >> -fempty-loops-terminate and make it default for C++? It does not

Re: Empty loops removal (Was Re: Some extra decorations)

2009/5/4 Joseph S. Myers: > On Mon, 4 May 2009, Jan Hubicka wrote: > >> On mainline I enabled infinite loop removal at >> -funsafe-loop-optimizations.  I would suggest adding >> -fempty-loops-terminate and make it default for C++? It does not apply >> for C, right? &g

Empty loops removal (Was Re: Some extra decorations)

volatile objects, and > - performs no synchronization operations (1.10) or atomic operations > (Clause 29) > may be assumed by the implementation to terminate. [ Note: This is intended > to allow compiler transformations, such as removal of empty loops, even > when termination cann

Re: -fno-ira removal

Regarding ARC and MMIX we might expect some action from Joern and H-P respectively, but nobody is probably going to do the work for the others AFAIK ARC has no plans to do work on the old ARCtangent-A4 port that is currently in gcc trunk. The ARCompact code is not suitable to be integrated into

Re: Removal of -I- and the functionality of -iquote.

>In a recent upgrade, we noticed that -I- functionality is being >replaced with -iquote. This -iquote does not have the same >functionality as -I- and is removing a strong function that is needed. I wasn't around for the decision to remove the "don't search the directory containing the current fi

Removal of -I- and the functionality of -iquote.

In a recent upgrade, we noticed that -I- functionality is being replaced with -iquote. This -iquote does not have the same functionality as -I- and is removing a strong function that is needed. -I- provides the ability to have include files (.h) reference files in the same directory and yet use t

Re: -fno-ira removal

On Thu, 23 Oct 2008, Paolo Bonzini wrote: > > The following ports haven't been converted yet: > > > > arc m32c m68hc11 mmix pdp11 score vax > > DJ has reported problems on the list for m32c. > > Regarding ARC and MMIX we might expect some action from Joern and H-P > respectively, Problems for MMIX

Re: -fno-ira removal

Joseph S. Myers wrote: On Thu, 23 Oct 2008, Jakub Jelinek wrote: Hi! I think we are now almost a month past the deadline for removal of -fno-ira and ports that haven't been converted to IRA yet. The plan was to add the ports to the deprecation list (so they can be reenabled

Re: -fno-ira removal

On Thu, 23 Oct 2008, Jakub Jelinek wrote: > Hi! > > I think we are now almost a month past the deadline for removal of -fno-ira > and ports that haven't been converted to IRA yet. The plan was to add the ports to the deprecation list (so they can be reenabled by a sma

Re: -fno-ira removal

On Thu, Oct 23, 2008 at 9:10 AM, Joern Rennecke <[EMAIL PROTECTED]> wrote: >> Regarding ARC and MMIX we might expect some action from Joern and H-P >> respectively, but nobody is probably going to do the work for the others > > We've faxed the Copyright assignemnt to the FSF on the 3rd of September

RE: -fno-ira removal

>arc m32c m68hc11 mmix pdp11 score vax I'll try to get to pdp11 soon. paul

Re: -fno-ira removal

Jakub Jelinek wrote: Hi! I think we are now almost a month past the deadline for removal of -fno-ira and ports that haven't been converted to IRA yet. Vladimir, do you plan to move forward with this step any time soon? I'd rather wait for 2-3 weeks more. People are still worki

Re: -fno-ira removal

> The following ports haven't been converted yet: > > m32c I've tried and tried to get IRA for m32c working. I asked Vlad and Jeff to look at it, which they have/are, with no definite results yet.

Re: -fno-ira removal

> Regarding ARC and MMIX we might expect some action from Joern and H-P > respectively, but nobody is probably going to do the work for the others We've faxed the Copyright assignemnt to the FSF on the 3rd of September, with the physical signed copy Fedexed on the 4th and received on the 5th of Se

Re: -fno-ira removal

> > The following ports haven't been converted yet: > > > > arc m32c m68hc11 mmix pdp11 score vax > > DJ has reported problems on the list for m32c. > > Regarding ARC and MMIX we might expect some action from Joern and H-P > respectively, but nobody is probably going to do the work for the other

Re: -fno-ira removal

> The following ports haven't been converted yet: > > arc m32c m68hc11 mmix pdp11 score vax DJ has reported problems on the list for m32c. Regarding ARC and MMIX we might expect some action from Joern and H-P respectively, but nobody is probably going to do the work for the others Paolo

-fno-ira removal

Hi! I think we are now almost a month past the deadline for removal of -fno-ira and ports that haven't been converted to IRA yet. Vladimir, do you plan to move forward with this step any time soon? The following ports haven't been converted yet: arc m32c m68hc11 mmix pdp11

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

On 29/02/2008, Pompapathi V Gadad <[EMAIL PROTECTED]> wrote: > Yes. I donot have commit access. I will make a fresh request to commit > the changes on my behalf. > Thanks, > Pompa Hey Pompa, if you have your legal papers in order, you are planning to keep contributing and your patch is not ext

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

Yes. I donot have commit access. I will make a fresh request to commit the changes on my behalf. Thanks, Pompa Joseph S. Myers wrote: On Fri, 29 Feb 2008, Pompapathi V Gadad wrote: Hello Joseph S. Myers, Thanks for reply. My individual assignment process with the FSF is complete. I have su

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

On Fri, 29 Feb 2008, Pompapathi V Gadad wrote: > Hello Joseph S. Myers, > Thanks for reply. My individual assignment process with the FSF is complete. I > have submitted patches for another target CR16 and it has been reviewed. > However, it has not be committed to trunk yet. If a patch reviewer

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

removal of deprecation and post the results as soon as possible. Thanks a lot, Pompa Joseph S. Myers wrote: The question of maintainership will need to be decided by the Steering Committee, but before you can become the maintainer you should have established a record of submitting good patches to

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

The question of maintainership will need to be decided by the Steering Committee, but before you can become the maintainer you should have established a record of submitting good patches to the port that conform to the GNU Coding Standards etc.; depending on the status of any corporate assignme

4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

Hello All, Please donot deprecate crx-*-* target. We have a active team for maintaining both crx and cr16 targets. CR16 target has been submitted for the inclusion into the 4.3. I had volunteered for maintaining the crx port earlier since the original maintainer was not with the company anymor

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, 2007-10-26 at 19:41 +0100, Jonathan Wakely wrote: > On 26/10/2007, skaller <[EMAIL PROTECTED]> wrote: > > This would not be correct. When you deprecate C++2000 features, > > you should retain them in such a way that a compiler switch > > such as --std=C++2000 will ensure they're visible i

Re: Removal of pre-ISO C++ items from include/backwards

On 26/10/2007, skaller <[EMAIL PROTECTED]> wrote: > On Thu, 2007-10-25 at 22:56 +0100, Jonathan Wakely wrote: > > The plan is to also move auto_ptr and the old bind1st/bind2nd function > > binders to backward, if/when they are deprecated in C++0x, which would > > give them the same status as (depr

Re: Removal of pre-ISO C++ items from include/backwards

at 10:21:57AM +0200, Richard Guenther wrote: > I re-built openSUSE with both changes and the ext/ stuff causes 62 > build failures, while the .h header API removal causes 21 build failures. Thanks! That's some good, solid data.

Re: Removal of pre-ISO C++ items from include/backwards

and the ext/ stuff causes 62 build failures, while the .h header API removal causes 21 build failures. Richard.

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, 26 Oct 2007, skaller wrote: | | On Thu, 2007-10-25 at 20:34 -0500, Gabriel Dos Reis wrote: | > On Fri, 26 Oct 2007, skaller wrote: | > | > | I should point out retaining 'old' features can create a | > | significant maintenance burden for gcc developers, | > | > In this specific case, w

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, Oct 25, 2007 at 08:17:58PM -0700, Mark Mitchell wrote: > The maintenance burden argument always used to remove stuff. I've used > it myself plenty of times. Sometimes, it really is too painful. But, > sometimes -- and, again, I consider myself guilty -- we've ripped things > out under th

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, Oct 26, 2007 at 11:06:43AM +1000, skaller wrote: > The compiler is expected to conform to the specified standard > and the standard libraries are an intrinsic part of the > standard, and IMHO it would be good practice to allow > 'strict' conformance to an older standard, whilst still > reje

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 2007-10-25 at 20:34 -0500, Gabriel Dos Reis wrote: > On Fri, 26 Oct 2007, skaller wrote: > > | I should point out retaining 'old' features can create a > | significant maintenance burden for gcc developers, > > In this specific case, what are they? You're in a better position than me to

Re: Removal of pre-ISO C++ items from include/backwards

Gabriel Dos Reis wrote: > On Fri, 26 Oct 2007, skaller wrote: > > | I should point out retaining 'old' features can create a > | significant maintenance burden for gcc developers, > > In this specific case, what are they? The maintenance burden argument always used to remove stuff. I've used it

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, 26 Oct 2007, skaller wrote: | I should point out retaining 'old' features can create a | significant maintenance burden for gcc developers, In this specific case, what are they? -- Gaby

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 2007-10-25 at 15:49 -0700, Joe Buck wrote: > People that put out distributions are rightly irritated when we pull stuff > like this. It's not even good enough to change "ext" to "backward", now > you need an autoconf test to find the fine header, so your program > compiles with both olde

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 2007-10-25 at 22:56 +0100, Jonathan Wakely wrote: > On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > The plan is to also move auto_ptr and the old bind1st/bind2nd function > binders to backward, if/when they are deprecated in C++0x, which would > give them the same status as (d

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, Oct 25, 2007 at 02:48:09PM -0700, Mark Mitchell wrote: > Gerald Pfeifer wrote: > > On Thu, 25 Oct 2007, Andrew Pinski wrote: > >> Well technically these headers have been deprecated since at least 3.2 > >> (maybe even back in 3.0) with them producing a warning. So I don't > >> know if we s

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 25 Oct 2007, Jonathan Wakely wrote: | On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: | > On Thu, 25 Oct 2007, Andrew Pinski wrote: | > > Well technically these headers have been deprecated since at least 3.2 | > > (maybe even back in 3.0) with them producing a warning. So I don'

Re: Removal of pre-ISO C++ items from include/backwards

On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Thu, 25 Oct 2007, Andrew Pinski wrote: > > Well technically these headers have been deprecated since at least 3.2 > > (maybe even back in 3.0) with them producing a warning. So I don't > > know if we should move them or not but we have

Re: Removal of pre-ISO C++ items from include/backwards

Gerald Pfeifer wrote: > On Thu, 25 Oct 2007, Andrew Pinski wrote: >> Well technically these headers have been deprecated since at least 3.2 >> (maybe even back in 3.0) with them producing a warning. So I don't >> know if we should move them or not but we have followed our own rules >> here. > > S

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 25 Oct 2007, Andrew Pinski wrote: > Well technically these headers have been deprecated since at least 3.2 > (maybe even back in 3.0) with them producing a warning. So I don't > know if we should move them or not but we have followed our own rules > here. Sorry, I misread the Subject: wha

Re: Removal of pre-ISO C++ items from include/backwards

On 10/25/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > I have to admit I am also surprised about the use of "deprecated" in > the context of removing these headers. My previous understanding was > that we'd announce deprecation (and issue warnings) for at least one > major release before actuall

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 25 Oct 2007, Gabriel Dos Reis wrote: > 'deprecated' in the standard does not carry much semantics weight, > unless the feature is also removed. But, even then we would have to > worry about existing codes that were written using the feature. I have to admit I am also surprised about the u

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 2007-10-25 at 13:41 -0500, Gabriel Dos Reis wrote: > On Fri, 26 Oct 2007, skaller wrote: > > | > | On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote: > | > | > | I think this is the wrong idea. Deprecated does carry a lot > | > | of weight. It allows a new compiler without a leg

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, 26 Oct 2007, skaller wrote: | | On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote: | | > | I think this is the wrong idea. Deprecated does carry a lot | > | of weight. It allows a new compiler without a legacy | > | to elide the feature and specify it is ISO compliant | > | 'minu

Re: Removal of pre-ISO C++ items from include/backwards

ernight > because the ISO committee voted to deprecate things. I realize the > situation might be different in a totally different, imaginary, > perfect world. I agree, I wasn't suggesting removing support for deprecated features overnight: rather than you don't view deprecation

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, 26 Oct 2007, skaller wrote: | | On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote: | > skaller wrote: | > | > > I think this is the wrong idea. Deprecated does carry a lot | > > of weight. It allows a new compiler without a legacy | > > to elide the feature and specify it is ISO comp

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, 26 Oct 2007, skaller wrote: | | On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote: | | > 'deprecated' in the standard does not carry much semantics weight, | > unless the feature is also removed. But, even then we would have to | > worry about existing codes that were written us

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote: > skaller wrote: > > > I think this is the wrong idea. Deprecated does carry a lot > > of weight. It allows a new compiler without a legacy > > to elide the feature and specify it is ISO compliant > > 'minus' the deprecated features, which is

Re: Removal of pre-ISO C++ items from include/backwards

skaller wrote: I think this is the wrong idea. Deprecated does carry a lot of weight. It allows a new compiler without a legacy to elide the feature and specify it is ISO compliant 'minus' the deprecated features, which is quite different from 'non-compliant'. are you sure? I thought conforman

  1   2   >