but it's my be too aggressive. as you said, you mean "base,ofst" rule is enough,
a more safe method is "base,ofst, lenght" rule. p still can point to
pair.b if p is update by
assignment or other ways.
we should ensure *p will never exceed the length, otherwilse it will
fail to do alias analysis.
Has anyone gone through Polyhedron ICEs with -ftree-vectorize? I see
aermod, air, doduc, linpk, mdbx, rnflow and test_fpu ICE on i686 and
additionally induct and tfft on x86_64. (-O3 -ffast-math -funroll-loops
otherwise)
Richard.
On Mar 29, 2006, at 12:15 AM, Tianwei Sheng wrote:
but it's my be too aggressive. as you said, you mean "base,ofst"
rule is enough,
a more safe method is "base,ofst, lenght" rule.
Right. I didn't mean to exclude length, just that I didn't expound
on the idea, as I wanted to get the simple
Hi,
For sh4-unknown-linux target, libgcc_s.so is not symbolic link but linker script
that is
GROUP ( libgcc_s.so.1 libgcc.a )
I hear this is because some functions are not included in libgcc_s.so.1 and
they are
only in libgcc.a.
But now, "gcc -v -o hello hello.c" gives following output on link
SUGIOKA Toshinobu <[EMAIL PROTECTED]> wrote:
> But now, "gcc -v -o hello hello.c" gives following output on linking phase.
>
> /usr/libexec/gcc/sh4-unknown-linux/4.1.0/collect2 --eh-frame-hdr -m
> shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o hello
> /usr/lib/gcc/sh4-unknown-linux/4.1.0/../
On Tue, Mar 28, 2006 at 03:10:30PM +0200, Clifford Wolf wrote:
> /tmp/cc9Aywrx.s: Assembler messages:
> /tmp/cc9Aywrx.s:1256: Error: can't resolve `.text.unlikely' {.text.unlikely
> section} - `.LCFI70' {.text section}
The assembly is wrong. File a GCC bug. Two subtracted symbols should
gen
On Wed, 2006-03-29 at 15:03 +0800, Tianwei Sheng wrote:
> I need the field_info to help in alias analysis. for example:
> int *p = &pair.a;
> int *q = &pair.b;
>
> then if I can set length of "*p" to 4,ofset is '0' . for "*q" to
> "8,4". also I know that p definitly points to pair.a and q points t
On Wed, Mar 29, 2006 at 10:18:31PM +0900, SUGIOKA Toshinobu wrote:
> Hi,
>
> For sh4-unknown-linux target, libgcc_s.so is not symbolic link but linker
> script
> that is
>
> GROUP ( libgcc_s.so.1 libgcc.a )
>
> I hear this is because some functions are not included in libgcc_s.so.1 and
> they
Hi,
well too bad some news sites pick this mail up as rather bad news for
the GCC compiler and project as it.
However the opposite is the truth, I'm a long term system integrator
contributing to ROCK Linux since 1998 and nowadays leading the
T2 SDE fork of it. It is a development environment allo
I'm confused...
While working with tools for a PowerPC 8xx I've run into a problem
loading SO's:
/bin/hello.x: error while loading shared libraries:
/lib/libgcc_s.so.1: R_PPC_REL24 relocation at 0x0ff6c384 for symbol
`__pthread_mutex_lock' out of range
I'm using gcc-4.0.2+ (i686-pc-linux-gnu x pow
I'm fiddling around with a GCC 4 front-end tutorial that would be more
detailed and hands-on than anything I've found so far on the web. It's
a bit like the blind leading the blind, but it makes me learn better and
while I'm learning it I don't mind writing it up, but after I learn it
I've got bet
On 3/29/06, Dustin Laurence <[EMAIL PROTECTED]> wrote:
> I'm fiddling around with a GCC 4 front-end tutorial that would be more
> detailed and hands-on than anything I've found so far on the web. It's
> a bit like the blind leading the blind, but it makes me learn better and
> while I'm learning i
On Tue, 2006-03-28 at 17:23, Diego Novillo wrote:
> Oh, excellent. Coincidentally, we have been thinking about developing
> some kind of plugin/extension framework to allow these classes of
> analyses. One of the goals is to provide an extensibility mechanism
> that will not require rebuilding GC
> "Duncan" == Duncan Sands <[EMAIL PROTECTED]> writes:
Duncan> That still leaves the problem of how the Ada front-end tells the
Duncan> middle-end that a variable is known to be in a certain range. Due
Duncan> to the way the language works, the front-end often does know a useful
Duncan> range
On Wed, Mar 29, 2006 at 01:53:31PM -0500, James Lemke wrote:
> The generated asm makes the reference as:
> bl [EMAIL PROTECTED] # 141 *call_value_nonlocal_sysv/1 [length = 4]
>
> And for this, gas generates:
> R_PPC_REL24 __pthread_mutex_lock
>
> Can anyone help clarify what is / shoul
> "Dustin" == Dustin Laurence <[EMAIL PROTECTED]> writes:
Dustin> The question is, which front ends are regarded as being good
Dustin> exemplars of style in GCC 4 and which are burdened with legacy
Dustin> code that shouldn't be duplicated in a new project? I gather
Dustin> that at one time t
Matthias Klose wrote:
> Summary:
>
> GCC 4.1 itself appears to be very stable, both on MIPS and AMD64.
Thank you for doing this, and for reporting the results, and for filing
the bugs!
This is, in my opinion, pretty good news for GCC.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(6
On Wed, Mar 29, 2006 at 05:10:25PM -0300, Rafael Espíndola wrote:
> Two friends and I have started to write a toy scheme front end.
You know, I've always wondered why there wasn't a lisp-family front end
for GCC, the roots of GNU and RMS being where they are (and didn't RMS
promise way back when
18 matches
Mail list logo
