Zdenek Dvorak wrote:
...
The number of parallel "computations" in loop.
The estimated latency of the critical path of loop.
The estimated cycle length of loop body.
The max. dependence height of computations.
The max. height of memory dependencies of computations.
The max. height of control dep
> When I looked at what sparc-gcc was generating for the return
> address column, I discovered that it didn't generate anything.
At least it generates the RA column:
.section".eh_frame",#alloc,#write
.LLframe1:
.uaword .LLECIE1-.LLSCIE1 ! Length of Common Information
On 6/9/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 6/7/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> * PTR_PLUS branch.
>
> I believe that this branch should be included in GCC 4.3. Andrew,
> would you please update me as to its status?
Yes, the summary is the branch has two autovector r
> Trying to get current (last build 3,3) , I
installed
> texinfo 4.8 and make 2.81 first - I am using the
> following setup and make lines:
>
> SRC=/local/src/gnu/gcc-4.1.2; CONFIG_SHELL=/bin/ksh
> $SRC/configure --without-fast-fixincludes
--enable-languages=c,c++,java
> make CFLAGS='-O' LIBCFLA
Eric Botcazou wrote:
When I looked at what sparc-gcc was generating for the return
address column, I discovered that it didn't generate anything.
At least it generates the RA column:
The CIE says what the RA column is, but there is no initial value
location expression generated for the return
> The CIE says what the RA column is, but there is no initial value
> location expression generated for the return address. That means
> that on entry to a function, the CIE cannot be used to tell what
> the return address is.
I'm not sure I understand. The RA column is the column in the table w
Eric Botcazou wrote:
The CIE says what the RA column is, but there is no initial value
location expression generated for the return address. That means
that on entry to a function, the CIE cannot be used to tell what
the return address is.
I'm not sure I understand. The RA column is the colum
> Not by GDB.
Then an approach could be to patch the GDB unwinder to make it follow the GCC
conventions.
> You seem to be under the misapprehension that I'm talking about exception
> handling in gcc. I'm not.
Well, GCC doesn't generate 2 flavor of CIEs (on SPARC) so considerations that
apply
Eric Botcazou wrote:
Not by GDB.
Then an approach could be to patch the GDB unwinder to make it follow the GCC
conventions.
The correct approach would be to have gcc generate correct DWARF data.
Indeed, I have patch gdb to work around the inaccurate CIE.
You seem to be under the misappreh
Hi all,
From gcc documents, I know that if the condition code or comparison
result can be placed in any general register, or if there are multiple
condition registers, use a pseudo register. I want to use general
register, but I don't know how to do it. Could someone know that? And
show
Brooks Moses wrote:
>>> Several members of the GFortran team (primarily Chris Rickett and Steve
>>> Kargl) have been working on a project to add the BIND(C) functionality
>>> from the Fortran 2003 standard. This provides for a standard means of
>>> linking Fortran code with code that uses standar
> Indeed, I have patch gdb to work around the inaccurate CIE.
Great.
> No, they don't. Apparently, EH frame unwinding doesn't need
> correct CIE data.
Of course EH unwinding needs strictly correct CFI, simply not
everything is in the CIE.
> Debugging does.
I fail to see why, at least on SPARC
Eric Botcazou wrote:
Debugging does.
I fail to see why, at least on SPARC, %o7 should be good enough.
You set a breakpoint at the return address assuming that you
will reach it when you finish the function. On Sparc, if you
set it at the address in %o7, you will be setting the breakpoint
at
OK
I had make 2.81 installed from the get-go and it did
not conform to the "smart" make, but the first time I
tried to fix by installing texinfo just before "make
install" - NFG.
I installed texinfo and rebuilt the world - it worked.
Thanks - and yes I will do my bit to support GNU as
soon as i
14 matches
Mail list logo