Re: [PATCH][4.3] Deprecate -ftrapv

> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes: Mark> Do we need functionality like this for Ada or Java? It is not needed for Java. Tom

RE: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

> -Original Message- > From: Brian Dessent [mailto:[EMAIL PROTECTED] > Sent: Friday, February 29, 2008 10:12 PM > To: Weddington, Eric > Cc: gcc@gcc.gnu.org; Ralf Wildenhues; dju > Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13 > in windows XP > > I'm fairly sure it has b

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

"Weddington, Eric" wrote: > You're definitely the expert on this. Has MSYS always done this? Or was > there an older version that didn't that the OP might be using? I'm fairly sure it has been implemented like that since the beginning. One possible reason why you might need to force cp to be use

RE: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

> -Original Message- > From: Brian Dessent [mailto:[EMAIL PROTECTED] > Sent: Friday, February 29, 2008 9:35 PM > To: Weddington, Eric > Cc: Ralf Wildenhues; dju; gcc@gcc.gnu.org > Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13 > in windows XP > > "Weddington, Eric" wrote:

Re: GCC wiki very slow?

On 2/29/08, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > On 29/02/2008, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > > I use the exact same trick when I edit CompileFarm. The save button very > > rarely returns (it happens less than 10% of the time) but always > > work when I check in the seco

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

"Weddington, Eric" wrote: > This is a very old issue. MinGW/MSYS does not support links. The easiest > way around this is to just copy the file. But MSYS's 'ln -s' command makes copies of files for exactly this reason, so the question remains why it's necessary to hack it to be cp. Brian

Re: Draft SH uClinux FDPIC ABI

On Feb 29, 2008, "Joseph S. Myers" <[EMAIL PROTECTED]> wrote: > Thanks - there were lots more typos in the original (spell-checking it > might be a good idea). Indeed :-( Thanks. >> I've just fixed it in FR-V FDPIC 1.0b. > Is there a more recent location to reference than >

RE: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

> -Original Message- > From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] > Sent: Friday, February 29, 2008 11:33 AM > To: dju > Cc: gcc@gcc.gnu.org > Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13 > in windows XP > > * dju wrote on Fri, Feb 29, 2008 at 03:19:45AM CET: > > p

Re: birthpoints in rtl.

Diego Novillo wrote: > What if you treated subregs as total writes (like we do arrays) and > libcalls as clobbering points? Though I guess that may not be > sufficient. > > it is more productive to spend the cycles getting rid of the libcalls rather than figuring out the edge cases. as steven

Re: birthpoints in rtl.

On Fri, Feb 29, 2008 at 20:39, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > I personally dislike the fact that the middle end keeps the phi's separate. Six of one, half a dozen of the other. If you put the PHIs in the IL stream, then you need to be careful about not moving anything before or in

Re: [PATCH][4.3] Deprecate -ftrapv

Joseph S. Myers wrote: On Fri, 29 Feb 2008, Robert Dewar wrote: Well no one "needs" anything in this sense, any interfaced is Turing complete so there is *always* a work around deficiencies in the back end. But right now, the "do this itself" is really horribly inefficient: You can see the C

Re: [PATCH][4.3] Deprecate -ftrapv

On Fri, 29 Feb 2008, Robert Dewar wrote: > Well no one "needs" anything in this sense, any interfaced is Turing > complete so there is *always* a work around deficiencies in the back end. But > right now, the "do this itself" is really horribly inefficient: You can see the C code in libgcc2.c (__

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

Jack Howarth wrote: Mark, One other question. Does the bug fixed by the offending patch... http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01010.html ...merit breaking even a secondary target? Wouldn't it be better to regress that patch out for gcc 4.3.0 (to be reintroduced in gcc 4.3.1 when th

Re: [PATCH][4.3] Deprecate -ftrapv

David Daney wrote: Mark Mitchell wrote: Richard Guenther wrote: This is a request to depcrecate -ftrapv which has numerous problems making it not work as expected since a long time. As nobody seems to have the energy to ensure it is working I propose to deprecate it for GCC 4.3 to make it poss

Re: [PATCH][4.3] Deprecate -ftrapv

Richard Kenner wrote: Why doesn't it work? Can it be made to work relatively easily? Do we need functionality like this for Ada or Java? Ada currently has to do this itself, precisely because -ftrapv doesn't work, so it's not the case that Ada "needs" it. Well no one "needs" anything in thi

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

Mark, One other question. Does the bug fixed by the offending patch... http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01010.html ...merit breaking even a secondary target? Wouldn't it be better to regress that patch out for gcc 4.3.0 (to be reintroduced in gcc 4.3.1 when the problems that it cau

Re: [PATCH][4.3] Deprecate -ftrapv

Richard Guenther wrote: This is a request to depcrecate -ftrapv which has numerous problems making it not work as expected since a long time. As nobody seems to have the energy to ensure it is working I propose to deprecate it for GCC 4.3 to make it possible to remove it during 4.4 (and not bloc

Re: [PATCH][4.3] Deprecate -ftrapv

Joseph S. Myers wrote: You also need to deal with fold, which will optimize away potentially trapping computations with -ftrapv and runs before gimplification (possibly in association with making fold run at gimplification time and not before). Indeed. However, errors missed due to fold eli

Re: [PATCH][4.3] Deprecate -ftrapv

On Fri, 29 Feb 2008, Mark Mitchell wrote: > Thanks for the explanations. It seems like tree-ssa should in theory make it > easier to implement this; for example, at the point of gimplification one > could insert checks, and then just let everything else do its thing. I don't > see how libcalls a

Re: birthpoints in rtl.

Diego Novillo wrote: > On 2/29/08 7:04 PM, Steven Bosscher wrote: > >> I am not sure what would happen if GCC would start using FUD chains. >> Is it like in SSA that every register is assigned only once? > > But this would only affect the UD chains built by the DF code. My > idea is to build the s

Re: Issues stopping us from removing libcall notes

Steven Bosscher wrote: > Hello, > > Every time someone brings up the idea to remove libcall notes, people > have to think really hard why GCC still has them. It seemed like a > good idea to record and collect these issues in a meta-bug. Thus, see > PR35413. Please open a new bug report (enhanceme

Re: [PATCH][4.3] Deprecate -ftrapv

Richard Guenther wrote: The tree optimizers do not recognize +-* of singed integers as possibly trapping which causes functions to become const/pure that should not and causes 'dead' code to be removed that should not. Thanks for the explanations. It seems like tree-ssa should in theory make

Re: [PATCH][4.3] Deprecate -ftrapv

On Sat, 1 Mar 2008, Richard Guenther wrote: > I seriously doubt anyone has used it for anything useful since at least > the advent of tree-ssa. I see we for example warn for -fforce-mem > in 4.2, but that is a no-op there. Do we have an option to disable > such warnings? After all it would brea

Re: [PATCH][4.3] Deprecate -ftrapv

On Sat, 1 Mar 2008, Joseph S. Myers wrote: > On Sat, 1 Mar 2008, Richard Guenther wrote: > > > This is a request to depcrecate -ftrapv which has numerous problems > > making it not work as expected since a long time. As nobody seems > > to have the energy to ensure it is working I propose to dep

Re: [PATCH][4.3] Deprecate -ftrapv

Mark Mitchell wrote: Richard Guenther wrote: This is a request to depcrecate -ftrapv which has numerous problems making it not work as expected since a long time. As nobody seems to have the energy to ensure it is working I propose to deprecate it for GCC 4.3 to make it possible to remove it du

Re: [PATCH][4.3] Deprecate -ftrapv

On Fri, 29 Feb 2008, Mark Mitchell wrote: > Richard Guenther wrote: > > This is a request to depcrecate -ftrapv which has numerous problems > > making it not work as expected since a long time. As nobody seems > > to have the energy to ensure it is working I propose to deprecate it > > for GCC 4.

Re: [PATCH][4.3] Deprecate -ftrapv

On Sat, 1 Mar 2008, Richard Guenther wrote: > This is a request to depcrecate -ftrapv which has numerous problems > making it not work as expected since a long time. As nobody seems > to have the energy to ensure it is working I propose to deprecate it > for GCC 4.3 to make it possible to remove

Re: [PATCH][4.3] Deprecate -ftrapv

> Why doesn't it work? Can it be made to work relatively easily? Do we > need functionality like this for Ada or Java? Ada currently has to do this itself, precisely because -ftrapv doesn't work, so it's not the case that Ada "needs" it.

Re: birthpoints in rtl.

On 2/29/08 7:04 PM, Steven Bosscher wrote: I am not sure what would happen if GCC would start using FUD chains. Is it like in SSA that every register is assigned only once? But this would only affect the UD chains built by the DF code. My idea is to build the same UD chains, but make them sp

Re: [PATCH][4.3] Deprecate -ftrapv

Richard Guenther wrote: This is a request to depcrecate -ftrapv which has numerous problems making it not work as expected since a long time. As nobody seems to have the energy to ensure it is working I propose to deprecate it for GCC 4.3 to make it possible to remove it during 4.4 (and not bloc

Re: birthpoints in rtl.

On Fri, Feb 29, 2008 at 11:51 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > If we are not going to use a rewriting SSA form, I believe that the > original problems we had with RTL-SSA can be avoided. The nice thing about birth points would be that most RTL optimizers can look through NOPs (amaz

Re: [PATCH][4.3] Deprecate -ftrapv

On Sat, 1 Mar 2008, Richard Guenther wrote: > > This is a request to depcrecate -ftrapv which has numerous problems > making it not work as expected since a long time. As nobody seems > to have the energy to ensure it is working I propose to deprecate it > for GCC 4.3 to make it possible to remo

Re: birthpoints in rtl.

On 2/28/08 8:03 AM, Kenneth Zadeck wrote: The big difference between what i am proposing with birthpoints and a full blown ssa implementation is that i plan to do no rewriting since there are no operands of the phis to support this. You don't need to do a rewriting SSA implementation to have P

Re: birthpoints in rtl.

On 2/28/08 8:59 AM, Jan Hubicka wrote: Yes, I do believe that wast majority of DU/UD code can stay as it is. We just need to introduce the PHI nodes, either in a way Gimple does that in separate section of CFG or as real RTL noop moves (or we can even have RTL PHI code that would behave same way

Re: birthpoints in rtl.

On 2/27/08 6:15 PM, Kenneth Zadeck wrote: Comments? Volunteers? How about adding FUD chains instead of the dense UD chains we have today? FUD chains are almost trivial to port from gimple-ssa into RTL. We already overlay a use-def web on the RTL representation using the new dataflow bits.

Re: birthpoints in rtl.

On 2/28/08 8:32 AM, Paolo Bonzini wrote: FUD chains are basically SSA without subscripts -- and hence, without overlapping live ranges. No, they have subscripts. They just do not have OLRs. Diego.

[PATCH][4.3] Deprecate -ftrapv

This is a request to depcrecate -ftrapv which has numerous problems making it not work as expected since a long time. As nobody seems to have the energy to ensure it is working I propose to deprecate it for GCC 4.3 to make it possible to remove it during 4.4 (and not block removing libcall notes

Issues stopping us from removing libcall notes

Hello, Every time someone brings up the idea to remove libcall notes, people have to think really hard why GCC still has them. It seemed like a good idea to record and collect these issues in a meta-bug. Thus, see PR35413. Please open a new bug report (enhancement request, probably) for things t

gcc-4.4-20080229 is now available

Snapshot gcc-4.4-20080229 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080229/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

Re: Some help with fold_convert() on RECORD_TYPEs

Works for me. Ok if that passes bootstrap / regtest and with a proper changelog entry. Committed as rev. 132780 with the following ChangeLog, thanks! 2008-02-29 Francois-Xavier Coudert <[EMAIL PROTECTED]> * fold-const.c (fold_convertible_p): Correct the logic to follow th

Re: GCC wiki very slow?

On 29/02/2008, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > I use the exact same trick when I edit CompileFarm. The save button very > rarely returns (it happens less than 10% of the time) but always > work when I check in the second tab. Brilliant minds think alike. ;-) Is that a saying or I jus

Re: GCC wiki very slow?

On Fri, 2008-02-29 at 22:22 +0100, Manuel López-Ibáñez wrote: > On 29/02/2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > > Hello > > > > Is it only me, or not: I'm finding the GCC wiki very slow and > > unresponsive... Apparently, much more than a couple of months ago > > I experienc

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

On 29/02/2008, Ben Elliston <[EMAIL PROTECTED]> wrote: > > I added a small note on http://gcc.gnu.org/wiki/SvnMerge > > > As I was replying, I knew that this should have been going into the > wiki. Thanks for paying your dues. :-) > The seach function of the wiki is crap. Do use google site:htt

Re: GCC wiki very slow?

On 29/02/2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Hello > > Is it only me, or not: I'm finding the GCC wiki very slow and > unresponsive... Apparently, much more than a couple of months ago I experience the same, even worse, after saving the page I always get an error but then

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

> I added a small note on http://gcc.gnu.org/wiki/SvnMerge As I was replying, I knew that this should have been going into the wiki. Thanks for paying your dues. :-) Ben

GCC wiki very slow?

Hello Is it only me, or not: I'm finding the GCC wiki very slow and unresponsive... Apparently, much more than a couple of months ago It seems so slow (and I'm using the same PC, the same network, ...) that sometimes I click twice on the Save button (hence overloading the HTTP server whi

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

Hello All, Diego Novillo wrote: I personally prefer to use svnmerge.py. It Just Works. I suppose that svnmerge.py is the /usr/bin/svnmerge (at least, it seems to be last time I checked) And Ben Elliston wrote: > From time to time, you will run svnmerge merge. That is what I think I did.

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

> What is the best tool to use, svnmerge or the merge subcommand of svn? I have never used svn merge, but instead learned to use svnmerge right from the outset, from advice given to me at the time. > I'm quite confused actually. I tried to use svnmerge but I tend to think > it didn't do what I e

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

On 2/29/08 3:35 PM, Basile STARYNKEVITCH wrote: Ideally either a reference or the full sequence of commands to run would be helpful (assuming I can restart from pristine MELT branch & trunk) I personally prefer to use svnmerge.py. It Just Works. There is a short tutorial on the GCC wiki som

merging trunk into MELT branch: svn merge or svnmerge merge?

Hello All, I'm trying to have the MELT branch following as closely as possible the GCC trunk. I'm on Debian/Sid/AMD64 and have both svn (version 1.4.6dfsg1-1 of package subversion) and svnmerge (in package subversion-tools of same version) which is coded in Python (I've got version 2.4.4) B

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

Jack Howarth wrote: Mark, I can understand the FSF gcc developers' frustration at the lack of participation by the darwin developers. However I still think it merits at least understanding why r131198 is breaking the linkage on darwin. It may well be that darwin to exposing a latent bug in the

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

Mark, I can understand the FSF gcc developers' frustration at the lack of participation by the darwin developers. However I still think it merits at least understanding why r131198 is breaking the linkage on darwin. It may well be that darwin to exposing a latent bug in the use of install-leaf.

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

Jack Howarth wrote: Richard, This problem appears to be caused by... Author: rsandifo Date: Thu Dec 27 11:26:06 2007 New Revision: 131198 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131198 Log: libgcc/ * Makefile.in (all): Use install-leaf rather than install. (ins

Re: A few questions on XFmode for x86

> i386-modes.def has > > --- > /* In ILP32 mode, XFmode has size 12 and alignment 4. >In LP64 mode, XFmode has size and alignment 16. */ > ADJUST_FLOAT_FORMAT (XF, (TARGET_128BIT_LONG_DOUBLE > ? &ieee_extended_intel_128_format > : TARGET_96_

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

* dju wrote on Fri, Feb 29, 2008 at 03:19:45AM CET: > platform : microsoft windowsXP(32) sp2 intel core duo > > i managed to build gcc-4.2.3 using MinGW-5.1.3 candidate with gcc 3.4.5 and binutils-2.17.50 in MSYS-1.0.10 [...] > > only one change in gcc-4.2.3 source : > in /work/src/gcc-4.2.3/libad

Re: Draft SH uClinux FDPIC ABI

On Thu, 28 Feb 2008, Alexandre Oliva wrote: > It was the need for using the atomic 64-bit load/store instructions > that motivated us to use 64-bit alignment for function descriptors on > FR-V. Since SH doesn't have 64-bit load/store instructions, there's > no need for function descriptors to be

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

Richard, This problem appears to be caused by... Author: rsandifo Date: Thu Dec 27 11:26:06 2007 New Revision: 131198 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131198 Log: libgcc/ * Makefile.in (all): Use install-leaf rather than install. (install): Split most of t

A few questions on XFmode for x86

i386-modes.def has --- /* In ILP32 mode, XFmode has size 12 and alignment 4. In LP64 mode, XFmode has size and alignment 16. */ ADJUST_FLOAT_FORMAT (XF, (TARGET_128BIT_LONG_DOUBLE ? &ieee_extended_intel_128_format : TARGET_96_ROUND_53_LONG_DO

Re: GCC loop optimizations

Hi, > I'd like to know your experiences with the gcc loop optimizations. > > What loop optimizations (in your opinion) can be applied to a large > number of programs and yield a (significant) improvement of the > program run-time? in general, I would say invariant motion, load/store motion, stre

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

On Fri, Feb 29, 2008 at 3:14 PM, Jack Howarth <[EMAIL PROTECTED]> wrote: >Current gcc 4.3 branch incorrectly links all of its > shared libraries against the system libgcc instead of > the copy it builds and installs (PR35401). It appears > that the fix applied for PR30572 may have been > di

Re: Some help with fold_convert() on RECORD_TYPEs

On Fri, Feb 29, 2008 at 3:07 PM, FX <[EMAIL PROTECTED]> wrote: > > Yeah, it should return false for some classes of types, RECORD_TYPE, > > UNION_TYPE, > > ARRAY_TYPE come to my mind here. Patch welcome ;) > > I'd suggest: Works for me. Ok if that passes bootstrap / regtest and with a prope

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

Benchmarks: 7z, bzip2 & gzip.

Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 & 4.4.0-20080222. -- # User's time is taken, machine is Ath64 3200+ 2.0 GHz x1, 64+64K

PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

Current gcc 4.3 branch incorrectly links all of its shared libraries against the system libgcc instead of the copy it builds and installs (PR35401). It appears that the fix applied for PR30572 may have been disturbed since it is no longer working. Shouldn't PR35401 be escalated to a release b

Re: Some help with fold_convert() on RECORD_TYPEs

> Yeah, it should return false for some classes of types, RECORD_TYPE, > UNION_TYPE, > ARRAY_TYPE come to my mind here. Patch welcome ;) I'd suggest: Index: fold-const.c === --- fold-const.c(revision 131974) +++ fold-cons

Re: Some help with fold_convert() on RECORD_TYPEs

On Fri, Feb 29, 2008 at 2:48 PM, FX <[EMAIL PROTECTED]> wrote: > > Another workaround is to use a VIEW_CONVERT_EXPR in case > > fold_convertible_p () returns false but you still think you are ok. > > I'm trying that, but fold_convertible_p () return true and it still > ICEs in in fold_convert,

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: Some help with fold_convert() on RECORD_TYPEs

> Another workaround is to use a VIEW_CONVERT_EXPR in case > fold_convertible_p () returns false but you still think you are ok. I'm trying that, but fold_convertible_p () return true and it still ICEs in in fold_convert, at fold-const.c:2643! Basically, fold_convert() can't handle RECORD_TYPEs

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

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. OK. We will make necessary changes in the patches to include the removal

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

Re: Some help with fold_convert() on RECORD_TYPEs

On Fri, Feb 29, 2008 at 1:01 PM, FX <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm going forward on my patch to remove the multiple decls emitted by > the Fortran front-end for a single function. The problem is that doing > so yields quite a few type mismatch issues that were hidden by it. > Some

Some help with fold_convert() on RECORD_TYPEs

Hi all, I'm going forward on my patch to remove the multiple decls emitted by the Fortran front-end for a single function. The problem is that doing so yields quite a few type mismatch issues that were hidden by it. Some of them can be corrected in the front-end, and for some of them I just don't

[Fwd: Re: GCC 4.3 target deprecation proposals]

--- Begin Message --- Hi Joseph, > The following target architectures have seen no test results posted in > the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11, > score, stormy16, vax. Please do not deprecate the "crx" target. We are actively working on to update this target and

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