There has been some discussion here of GCC's reputation and of how to
classify bugs.
This bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
has gradually morphed from a compile-time issue to a space issue; if
it's not fixed for 4.4 (and it appears that it will not be fixed in
that tim
On Thu, Nov 20, 2008 at 1:24 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-11-20 at 00:39 +0100, Steven Bosscher wrote:
>> On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>> > Quality Data
>> >
>> >
>> > Priority # Change from Last
On Thu, 2008-11-20 at 00:39 +0100, Steven Bosscher wrote:
> On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > Quality Data
> >
> >
> > Priority # Change from Last Report
> > --- ---
> > P1 1
On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Quality Data
>
>
> Priority # Change from Last Report
> --- ---
> P1 13 - 4
> P2 114 - 27
> P33 +- 0
Hello
On 17.11.08, you wrote:
> Hi,
>
> I'd like to pointer that the new __optimize__ attribute doesn't work
> correctly:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
>
> Will it be fixed in 4.4?
68k amigaos target on 4.4 give no error, when type this to try to switch
optimizer of
> How does it fail? Is it related to m32c, ehm, interesting
> architectural features (24 bits addresses and only 2 address
> registers IIRC)?
I think so.
The m32c family has such a non-orthogonal register set that there's a
lot of small register classes. There are few cases where GENERAL_REGS
On Mon, Nov 17, 2008 at 12:01:45PM +0100, Jan-Benedict Glaw wrote:
> On Mon, 2008-11-17 11:34:09 +0100, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > The old register allocator hasn't been removed yet, but will be before
> > branching. There are still several targets that haven't been converted
> >
On Mon, Nov 17, 2008 at 9:33 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> What level of 'not support' is that? Is it completely unable to
>> generate code or are there only testsuite regressions?
>
> There's no definition of that macro (that we could find) that lets you
> build newlib successful
> What level of 'not support' is that? Is it completely unable to
> generate code or are there only testsuite regressions?
There's no definition of that macro (that we could find) that lets you
build newlib successfully.
I can't run the testsuite without newlib.
On Mon, Nov 17, 2008 at 1:43 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> The old register allocator hasn't been removed yet, but will be
>> before branching. There are still several targets that haven't been
>> converted to IRA, so unless they are converted soon, they will be
>> dropped. The u
> The old register allocator hasn't been removed yet, but will be
> before branching. There are still several targets that haven't been
> converted to IRA, so unless they are converted soon, they will be
> dropped. The unconverted targets are:
>
> m32c
I'd like to once again point out that des
Hi,
I'd like to pointer that the new __optimize__ attribute doesn't work
correctly:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
Will it be fixed in 4.4?
H.J.
---
On Mon, Nov 17, 2008 at 2:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Status
> ==
>
> We are now in regression and
On Mon, 2008-11-17 11:34:09 +0100, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> The old register allocator hasn't been removed yet, but will be before
> branching. There are still several targets that haven't been converted
> to IRA, so unless they are converted soon, they will be dropped. The
> un
13 matches
Mail list logo
