Re: RFC: Strategy for cc0 -> CCmode conversion for the AVR target.

Thank's for your response, Sunday, 5. Juni 2005 04:16 Ian Lance Taylor wrote: > > The condition-code re-use issue is the point, where, IMO, the link to the > > subreg-lowering 2.) shows up. After, e.g., breaking down a HI mode "sub" > > operation into two QI mode "sub" and "sub-with-carry"s at exp

Re: Java bootstrap fails compiling libjava

On 6/4/05, Bryce McKinlay <[EMAIL PROTECTED]> wrote: > I've just done an x86_64 build of HEAD and didn't see this error. Hm, ok - it seems changing java/parse.y:build_if_else_statement to not construct a COND_EXPR with NULL_TREE type, but void_type_node causes this. Any idea why? Thanks, Richard

Re: Ada front-end depends on signed overflow

Eric Botcazou wrote: -ftrapv is not practically usable because (1) it generates awful code and (2) it badly interacts with the RTL optimizers. please before you say this compare it with the truly awful front end code we generate, which for sure inteferes badly with the optimizers. Right, the

Re: [RFC] type safe trees

Well! I really like Zack's proposed conversion plan in the PDF, but particularly the order, and of that particularly the early stages. I see no problem with the "top level" separation into entirely distinct base classes, of the sort which require explicit work to treat as a union. And I don't see

Re: Ada front-end depends on signed overflow

> > Right, the code generated by the front end is not pretty either, but at > > least the front-end knows what it is doing Ada-wise. -ftrapv is so dumb > > at the moment that it emits checks for virtually anything. > > No, it just emits it for signed operations. Of course, it is not so dumb as to

Re: Ada front-end depends on signed overflow

Eric Botcazou wrote: Of course, it is not so dumb as to blatantly violate its specification. If we use -ftrapv, then we have to make sure that operations labeled by the front end as not requiring an overflow check are transformed into unsigned operations by gigi. I think it would be dange

Killing fixproto (possible target obsoletion)

So here are the targets using fixproto. I've attempted to classify them. Very tentatively. Fixproto is very nice in some ways, but it's only necessary on systems with quite old system headers, and it interacts in a confusing and obnoxious way with fixincludes, which prevents some highly desirable

Re: Killing fixproto (possible target obsoletion)

Nathanael Nerode wrote: Propose to stop using fixproto immediately: avr-*-* I'm not even sure exactly what fixproto is supposed to do, but I *highly* doubt that it is needed for the AVR target. The AVR target is an embedded processor that uses it's own C library, avr-libc:

Re: Killing fixproto (possible target obsoletion)

On Sun, Jun 05, 2005 at 11:36:58AM -0400, Nathanael Nerode wrote: > Probably shouldn't have been running fixproto in the first place: > powerpc-wrs-windiss* -- actually, I doubt this belongs in the FSF tree at all Why do you doubt that? The configuration probably needs some serious love&care; I

Proposed obsoletions

OK, here's my proposed obsoletion list. * arc-*-elf* (only arc port) No maintainer. Still. * alpha*-*-unicosmk* No real update since 2002. If rth, the lone alpha maintainer, is actually maintaining it, I guess it should stay; it's not in bad shape. But does it really need fixproto? *

Re: Proposed obsoletions

On Sun, 2005-06-05 12:41:43 -0400, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > * vax-*-bsd* > * vax-*-sysv* > If anyone is still using these, GCC probably doesn't run already. I > certainly haven't seen any test results. Correct me if I'm wrong! > And after some staring, I think these ar

GCC 4.0.1 Status (2005-06-05)

As of midnight, tonight, California time, the GCC 4.0 branch will be frozen, in preparation for the 4.0.1 release. After that point, all non-documentation changes will require my explicit approval. To request approval for a patch, please attach the patch or a pointer thereto to a PR, and add

Re: GCC 4.0.1 Status (2005-06-05)

On Sunday 05 June 2005 19:18, Mark Mitchell wrote: > The reason that this release is slightly ahead of schedule is because of > a relatively frequently-encountered wrong-code regression in C++. Which regression is this? And why does this regression motivate you to suddenly go release 4.0.1 where

Re: GCC 4.0.1 Status (2005-06-05)

Steven Bosscher wrote: On Sunday 05 June 2005 19:18, Mark Mitchell wrote: The reason that this release is slightly ahead of schedule is because of a relatively frequently-encountered wrong-code regression in C++. Which regression is this? The bug that caused KDE miscompilations. > And w

Re: Java bootstrap fails compiling libjava

> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes: Richard> On 6/4/05, Bryce McKinlay <[EMAIL PROTECTED]> wrote: >> I've just done an x86_64 build of HEAD and didn't see this error. Richard> Hm, ok - it seems changing java/parse.y:build_if_else_statement Richard> to not construct a C

Re: GCC 4.0.1 Status (2005-06-05)

On Sunday 05 June 2005 19:29, Mark Mitchell wrote: > Steven Bosscher wrote: > > On Sunday 05 June 2005 19:18, Mark Mitchell wrote: > >>The reason that this release is slightly ahead of schedule is because of > >>a relatively frequently-encountered wrong-code regression in C++. > > > > Which regress

Re: GCC 4.0.1 Status (2005-06-05)

On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote: Here are three bugs I'd really like to see fixed. * 21528: SRA and/or aliasing problem. * 21847: DCE over-eagerness. * 20928: IA32 ICE. * 19523: [4.0/4.1 Regression] DBX_USE_BINCL support broken in the C++ compiler 19523 is a nasty regr

Re: GCC 4.0.1 Status (2005-06-05)

On Jun 5, 2005, at 1:41 PM, Devang Patel wrote: On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote: Here are three bugs I'd really like to see fixed. * 21528: SRA and/or aliasing problem. * 21847: DCE over-eagerness. * 20928: IA32 ICE. * 19523: [4.0/4.1 Regression] DBX_USE_BINCL support b

Re: Proposed obsoletions

On Sun, Jun 05, 2005 at 12:41:43PM -0400, Nathanael Nerode wrote: > * mips-wrs-windiss > * powerpc-wrs-windiss > I don't think these were supposed to be in the FSF tree at all, were they? This question belongs more in this thread than in the fixproto one so I'll reask it: Why do you think this?

Re: GCC 4.0.1 Status (2005-06-05)

Steven Bosscher wrote: On Sunday 05 June 2005 19:29, Mark Mitchell wrote: Steven Bosscher wrote: On Sunday 05 June 2005 19:18, Mark Mitchell wrote: The reason that this release is slightly ahead of schedule is because of a relatively frequently-encountered wrong-code regression in C++. Wh

Re: GCC 4.0.1 Status (2005-06-05)

Andrew Pinski wrote: On Jun 5, 2005, at 1:41 PM, Devang Patel wrote: On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote: Here are three bugs I'd really like to see fixed. * 21528: SRA and/or aliasing problem. * 21847: DCE over-eagerness. * 20928: IA32 ICE. * 19523: [4.0/4.1 Regression]

Re: GCC 4.0.1 Status (2005-06-05)

On Jun 5, 2005, at 2:01 PM, Mark Mitchell wrote: I agree that these are both serious, though neither seems to rise to the level of the KDE issues, in that these both affect "only" debugging. PR 19523 affects only stabs, which I do not think is the default on any primary or secondary platform

Follow up on simulators, documentation, etc.

Following the MIPS submission (for new intrinsics, for which no hardware, simulators, or official documentation was available), I raised the following question with the GCC SC: The question is "should it be our policy to reject patches for instructions which there is no simulator, no s

Re: GCC 4.0.1 Status (2005-06-05)

Andrew Pinski wrote: On Jun 5, 2005, at 2:01 PM, Mark Mitchell wrote: I agree that these are both serious, though neither seems to rise to the level of the KDE issues, in that these both affect "only" debugging. PR 19523 affects only stabs, which I do not think is the default on any primary

Re: collab.net have a spam open relay in operation at the moment. please give them grief about it.

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote: > i came to the gcc lists looking to email people about a particular > matter [to follow] and noted that the list archives are suffering > from exactly the same problem that i am - spam that's going via > collab.net. > > can i recommend to ev

Re: Proposed obsoletions

Daniel Jacobowitz wrote: On Sun, Jun 05, 2005 at 12:41:43PM -0400, Nathanael Nerode wrote: * mips-wrs-windiss * powerpc-wrs-windiss I don't think these were supposed to be in the FSF tree at all, were they? This question belongs more in this thread than in the fixproto one so I'll reask it:

Re: collab.net have a spam open relay in operation at the moment. please give them grief about it.

>> the collab.net server in question has been utilised to forge messages >> from openoffice.org to [EMAIL PROTECTED], which i am guessing >> is a sf.net internal email-absolutely-everybody mailing list. > > We opened an internal issue at CollabNet to look into this, and found > that we don't have a

Re: GCC 4.0.1 Status (2005-06-05)

On Sun, Jun 05, 2005 at 10:18:05AM -0700, Mark Mitchell wrote: > * 21528: SRA and/or aliasing problem. > I'll take a look at this tomorrow. Diego.

Re: GCC 4.0.1 Status (2005-06-05)

Diego Novillo wrote: On Sun, Jun 05, 2005 at 10:18:05AM -0700, Mark Mitchell wrote: * 21528: SRA and/or aliasing problem. I'll take a look at this tomorrow. Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304