On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
> On 08/17/2009 07:40 PM, Jerry Quinn wrote:
> > On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
> >> I'm not sure why GCC sources would need to mangle function-local
> >> structs, though.
> >
> Would it be helpful to reserve a lea
Richard Guenther wrote:
gfortran.dg/reassoc_4.f, the hottest loop from calculix.
Thanks.
This example is slightly different. Graphite should be able to handle it
with loop fusion rather than pre-unrolling + cse. But I agree that the
unrolling + cse approach also makes sense (and does not dep
On 8/19/09, Joseph S. Myers wrote:
> On Wed, 19 Aug 2009, Lawrence Crowl wrote:
>
> > I am quoting from several different messages.
> >
> > On 8/17/09, Joseph S. Myers wrote:
> > > (A) Code compiled against headers from libc version X must be run
> > > with libc version X or later.
> >
> >
Jeff Law writes:
> You're right. This should have been rejected by validate_equiv_mem,
> but isn't because the two memory references are in different alias
> sets.
>
> You can see this in the mainline sources configured for
> i686-pc-linux-gnu by compiling
> libgomp/testsuite/libgomp.fortran/red
On 08/19/09 17:46, Ian Lance Taylor wrote:
My understanding is that that scenario is supposed to not happen because
update_equiv_regs is only supposed to equate a register and a memory
location in the specific cases where that is OK. It's not no_equiv that
is supposed to fix this, the equivalen
Mikael Pettersson writes:
> When browsing e.g. gcc-cvs via the web it used to be possible to click on a
> newly added file and get a 'download raw' (I think it was called) option to
> see the file without all that idiotic html formatting. That seems to be gone
> now. For me, at least, this is ext
On Wed, 19 Aug 2009, Lawrence Crowl wrote:
> I am quoting from several different messages.
>
> On 8/17/09, Joseph S. Myers wrote:
> > (A) Code compiled against headers from libc version X must be run
> > with libc version X or later.
>
> What is the symptom of failing to meet this constraint?
When browsing e.g. gcc-cvs via the web it used to be possible to click on a
newly added file and get a 'download raw' (I think it was called) option to
see the file without all that idiotic html formatting. That seems to be gone
now. For me, at least, this is extremely counterproductive.
Jeff Law writes:
> Somehow I can't help but think I'm missing something here...
>
> Given:
>
> (set (reg X) (mem Y))
>
> (...)
>
> (set (mem Y) (reg Z))
>
> (...)
>
> (use (reg X))
>
>
>
> update_equiv_regs can set an equivalence between (reg X) and (mem Y)
> which is clearly wrong as
Somehow I can't help but think I'm missing something here...
Given:
(set (reg X) (mem Y))
(...)
(set (mem Y) (reg Z))
(...)
(use (reg X))
update_equiv_regs can set an equivalence between (reg X) and (mem Y)
which is clearly wrong as (mem Y) is set to (reg Z).
99.99% of the t
I am quoting from several different messages.
On 8/17/09, Joseph S. Myers wrote:
> (A) Code compiled against headers from libc version X must be run
> with libc version X or later.
What is the symptom of failing to meet this constraint?
> (B) Code compiled against headers from libc version X mu
> Gcc only does this work in the second pass, but what's the
> point? Is it wrong or just not necessary in the first sched
> pass?
Regardless of the target architecture from the correctness point of view sched1
can be disabled. sched1 has as purpose shortening live ranges.
Short live ranges allo
"Amker.Cheng" writes:
>I'm currently studying implementation of instruction sched in gcc.
>
> it is possible to schedule insns directly from queue in case
> there is nothing better to do and there are still vacant dispatch slots
> in the current cycle.
>
> Gcc only does this work in the secon
Hi all:
I'm currently studying implementation of instruction sched in gcc.
it is possible to schedule insns directly from queue in case
there is nothing better to do and there are still vacant dispatch slots
in the current cycle.
Gcc only does this work in the second pass, but what's the point
On Wed, Aug 19, 2009 at 3:56 PM, Richard
Guenther wrote:
> On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohen wrote:
>> Albert Cohen wrote:
>>> Thanks a lot for the quick and detailed response.
>>>
>>> It is more difficult than I thought, then :-( We'll think more, and
>>> maybe come up with yet another
On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohen wrote:
> Albert Cohen wrote:
>> Thanks a lot for the quick and detailed response.
>>
>> It is more difficult than I thought, then :-( We'll think more, and
>> maybe come up with yet another pass ordering proposal, but definitely
>> this tramp3d code des
Albert Cohen wrote:
> Thanks a lot for the quick and detailed response.
>
> It is more difficult than I thought, then :-( We'll think more, and
> maybe come up with yet another pass ordering proposal, but definitely
> this tramp3d code deserves to be processed by graphite AFTER
> unrolling+cse has
HI,
I am trying to port a 32bit target in GCC 4.4.0. My target supports
big and little endian. This is selected using a target switch. So i
have defined the macro
#define WORDS_BIG_ENDIAN (TARGET_BIG_ENDIAN)
Currently i have written pattens only for SImode moves. So GCC will
synthesize DImode pa
Richard Guenther wrote:
> 2009/8/19 Albert Cohen :
>> When debugging graphite, we ran into code bloat issues due to
>> pass_complete_unrolli being called very early in the non-ipa
>> optimization sequence. Much later, the full-blown pass_complete_unroll
>> is scheduled, and this one does not do any
On Wed, Aug 19, 2009 at 08:35, David Edelsohn wrote:
> OFTC is rejecting all connections from me as well.
It seems to have dropped out of name servers. I get this from 3
different networks.
$ nslookup irc.oftc.net
;; connection timed out; no servers could be reached
Diego.
OFTC is rejecting all connections from me as well.
David
On Wed, Aug 19, 2009 at 8:33 AM, Ramana Radhakrishnan wrote:
> On Wed, Aug 19, 2009 at 1:27 PM, Diego Novillo wrote:
>> I haven't been able to connect to #gcc today. Is anyone else having
>> trouble connecting?
>
> Wonder if it is somethin
On Wed, Aug 19, 2009 at 1:27 PM, Diego Novillo wrote:
> I haven't been able to connect to #gcc today. Is anyone else having
> trouble connecting?
Wonder if it is something else . I've been connected pretty much all
day and things seem to be working.
Ramana
>
> Diego.
>
I haven't been able to connect to #gcc today. Is anyone else having
trouble connecting?
Diego.
On Wed, Aug 19, 2009 at 2:07 PM, Richard
Guenther wrote:
> 2009/8/19 Albert Cohen :
>> When debugging graphite, we ran into code bloat issues due to
>> pass_complete_unrolli being called very early in the non-ipa
>> optimization sequence. Much later, the full-blown pass_complete_unroll
>> is schedu
2009/8/19 Albert Cohen :
> When debugging graphite, we ran into code bloat issues due to
> pass_complete_unrolli being called very early in the non-ipa
> optimization sequence. Much later, the full-blown pass_complete_unroll
> is scheduled, and this one does not do any harm.
>
> Strangely, this ear
My experience is that fold-const.c requires 20 MB of memory (not
including the size of the executable) to compile with -Os. That's
the biggest.
Is that typical/expected?
It doesn't seem too big.
Because it just occurred to me that maybe the lack of a "normal"
implementation of alloca() is cau
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the full-blown pass_complete_unroll
is scheduled, and this one does not do any harm.
Strangely, this early unrolling pass (tuned to only unr
Hmm, it seems 3.2.x would *always* operate on a function-by-function
basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
recall if it was already present in 3.3). I don't think there is any
way in 3.2.3 to check whether there is a "main" function in the file
before it is process
Sergey Anosov wrote:
> Does anybody have such problem? Or mips64 platform and gcc 3.3.6 are not
> compatible?
>
If I were you, considering how old and currently completely unmaintained
it is, I would leave gcc3.3.x alone...
Paolo.
Hi all!
I've made a toolchain for mips64el - binutils 2.17.90 + gcc 3.3.6 + glibc 2.3.6.
I've successfully compile a linux 2.16.62 kernel and run it in qemu.
But when I try to execute dynamically compiled "Hello world" program - I' ve
got a SIGSEGV"
do_page_fault() #2: sending SIGSEGV to a.out f
30 matches
Mail list logo
