Maybe it's not a proper place to put this message. I just noticed a
mistake when I read the paper of gcc summit 2003 named "The finite
state automaton based pipeline hazard recognizer and instruction
scheduler in GCC". The first cycle multi-pass instruction scheduling
algorithm:
...
if n > 0 ||
Klaus:
Perhaps your problem is related to PR 26854:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
See in particular comment 70, which has some statistics.
If you're building your own gcc, configure gcc with --enable-gather-
detailed-mem-stats and compile your program with -ftime-report -f
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> > to its language tree.def and gimplify this. Before I embark on
> > this I'd like to ask whether using
> > __builtin_longjmp/__builtin_setjmp is definitely the wrong way to
> > go?
>
> Definitely. You will be not able to handle/throw exceptions
> > This doesn't look HPPA specific but I haven't seen anything in the
> > mailing lists. HPPA is/was having other problems but this doesn't seem
> > to be related to them. Is anyone else seeing these messages?
>
> This was reported as PR 37380.
As a work around, revert this change:
2008-09-03
On Mon, Sep 8, 2008 at 2:00 PM, <[EMAIL PROTECTED]> wrote:
>
> I just got back from vacation and I see the HPPA bootstrap is failing
> with:
>
> cc1: warnings being treated as errors
> /proj/opensrc/nightly/src/trunk/gcc/c-common.c: In function
> 'c_warn_unused_result':
> /proj/opensrc/nightly/sr
I just got back from vacation and I see the HPPA bootstrap is failing
with:
cc1: warnings being treated as errors
/proj/opensrc/nightly/src/trunk/gcc/c-common.c: In function
'c_warn_unused_result':
/proj/opensrc/nightly/src/trunk/gcc/c-common.c:7540: error: 'i.745.ptr' is used
uninitialized in
Peter O'Gorman wrote:
> On Mon, Sep 08, 2008 at 08:29:37PM +0200, Paolo Bonzini wrote:
>>> Well, libtool-2.2.6 is finally released (twice even).
>>>
Actual approval depends on your answer to this question, but the patch is
technically okay. Can you commit it to the src repository too? T
Diego Novillo wrote:
On Sun, Sep 7, 2008 at 15:27, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
Yes, absolutely. The problem, as usual, is lack of time. Our
standards for internal documentation are pretty bad and the set of
people writing the documentation is always different than the set
Andreas Schwab wrote:
Jeff Law <[EMAIL PROTECTED]> writes:
Strange as I didn't trip this at all. I wonder if I've got something
out-of-date in my tree
I've only seen the crash during native testing. Since it's accessing an
array beyond its bounds it depends on the surrounding da
On Sun, Sep 7, 2008 at 15:27, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Given that passes are central to the middle end in GCC, shouldn't we want
> each of them (without exception!) be described by at least a simple
> paragraph. I'm sure that is a small effort for each pass writer (he/she
Jeff Law <[EMAIL PROTECTED]> writes:
> Strange as I didn't trip this at all. I wonder if I've got something
> out-of-date in my tree
I've only seen the crash during native testing. Since it's accessing an
array beyond its bounds it depends on the surrounding data on how the
error manifests.
Andreas Schwab wrote:
Jeff Law <[EMAIL PROTECTED]> writes:
Andreas Schwab wrote:
I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
process_regs_for_copy. It is called with
(insn 22 17 28 4 /cvs/gcc/libgcc/../gcc/
Jeff Law <[EMAIL PROTECTED]> writes:
> Andreas Schwab wrote:
>> I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
>> GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
>> process_regs_for_copy. It is called with
>>
>> (insn 22 17 28 4 /cvs/gcc/libgcc/../gcc/libgcc2.c:169 (set
On Mon, Sep 08, 2008 at 08:29:37PM +0200, Paolo Bonzini wrote:
>
> > Well, libtool-2.2.6 is finally released (twice even).
> >
> >> Actual approval depends on your answer to this question, but the patch is
> >> technically okay. Can you commit it to the src repository too? There is
> >> some r
Andreas Schwab wrote:
I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
process_regs_for_copy. It is called with
(insn 22 17 28 4 /cvs/gcc/libgcc/../gcc/libgcc2.c:169 (set (reg/i:SI 0 %d0)
(subreg:SI (reg/v:DI 30 [
From: Rainer Orth <[EMAIL PROTECTED]>
Date: Mon, 8 Sep 2008 17:18:50 +0200 (MEST)
> Eric Botcazou writes:
>
> > Confirmed (on Solaris 9). Would you mind opening a PR? There is already
> > one
> > for Linux (37344) but the failure is a little different. Thanks in advance.
>
> Sure, done: PR
> Well, libtool-2.2.6 is finally released (twice even).
>
>> Actual approval depends on your answer to this question, but the patch is
>> technically okay. Can you commit it to the src repository too? There is
>> some regeneration to do there too.
>
> I know that GCC is now in stage 3, and th
Hi Paolo,
On Thu, Aug 21, 2008 at 04:29:26PM +0200, Paolo Bonzini wrote:
> Peter O'Gorman wrote:
>> On Mon, Aug 11, 2008 at 03:02:05PM -0500, Peter O'Gorman wrote:
>>> Yes, I tried it also -
>>> http://pogma.com/misc/gcc-libtool-git20080810.patch (Slight change to
>>> ltgcc.m4, otherwise git libto
Thomas A.M. Bernard wrote:
> Hi,
>
> Is there a way to order the compiler to output only virtual registers
> within the assembly code ? (pointers to GCC code sections in back-end or
> in MD files are welcome) Hence the result assembly code would not have a
> conventional register allocation. It wo
Hi,
Is there a way to order the compiler to output only virtual registers
within the assembly code ? (pointers to GCC code sections in back-end or
in MD files are welcome) Hence the result assembly code would not have a
conventional register allocation. It would be using an unlimited number
o
Diego Novillo wrote:
On Mon, Sep 8, 2008 at 11:04, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
I understood that all prettyprinting is systematically using an obstack as a
buffer (actually, I renamed the FILE* field to something else, and it does
not appear a lot).
I wouldn't oppose a pat
On Mon, Sep 8, 2008 at 11:04, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Do you mean that the trend is to have both dump_* routines (writing to
> FILE*) and prettyprinting routines? Except of course the historical
> existence of code, I don't understand why both are needed (unless dumping i
Eric Botcazou writes:
> Confirmed (on Solaris 9). Would you mind opening a PR? There is already one
> for Linux (37344) but the failure is a little different. Thanks in advance.
Sure, done: PR bootstrap/37424.
Rainer
Diego Novillo wrote:
<[EMAIL PROTECTED]> wrote:
I am correct in assuming that pretty printing & debug dumping in GCC tend to
go thru the pretty printer abstraction of gcc/pretty-printer.h hence that
the old way of printing directly to a file (like e.g. dump_bb or debug_bb in
gcc/cfg.c for prin
On Mon, Sep 8, 2008 at 10:13, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Hello All,
>
> I am correct in assuming that pretty printing & debug dumping in GCC tend to
> go thru the pretty printer abstraction of gcc/pretty-printer.h hence that
> the old way of printing directly to a file (lik
Hello All,
I am correct in assuming that pretty printing & debug dumping in GCC
tend to go thru the pretty printer abstraction of gcc/pretty-printer.h
hence that the old way of printing directly to a file (like e.g. dump_bb
or debug_bb in gcc/cfg.c for printing basic_block-s) is deprecated, o
Jeff Law wrote:
H.J. Lu wrote:
My understanding is PowerPC is quite sensitive to choice of register
as shown in PR 28690. IRA merge may make fixes for PR 28690
ineffective. There are a few small testcases in PR 28690. You can
check if those problems in PR 28690 come back due to IRA merge.
Also,
I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
process_regs_for_copy. It is called with
(insn 22 17 28 4 /cvs/gcc/libgcc/../gcc/libgcc2.c:169 (set (reg/i:SI 0 %d0)
(subreg:SI (reg/v:DI 30 [ w ]) 4)) 36 {*movsi_m68k
On Mon, Sep 8, 2008 at 12:56 PM, Klaus Grue <[EMAIL PROTECTED]> wrote:
> On Mon, 8 Sep 2008, Andrew Haley wrote:
>
>> Klaus Grue wrote:
>>
>>> Is this a known problem:
>>>
>>> After upgrading to gcc 4.3.1, I can no longer compile a function whose
>>> source code is 0.7 Megabyte before preprocessing
On Mon, 8 Sep 2008, Andrew Haley wrote:
Klaus Grue wrote:
Is this a known problem:
After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
preprocessing.
The function (named "testsuite") is just a long lis
Klaus Grue wrote:
> Is this a known problem:
>
> After upgrading to gcc 4.3.1, I can no longer compile a function whose
> source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
> preprocessing.
>
> The function (named "testsuite") is just a long list of statements
> essentially
Hi All,
Is this a known problem:
After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
preprocessing.
The function (named "testsuite") is just a long list of statements
essentially of form if(!condition)
32 matches
Mail list logo
