On 3/22/2010 7:46 PM, Rayne wrote:
Hi all,
I'm interested in knowing how GCC differs from Intel's ICC in terms of the
optimization levels and catering to specific processor architecture. I'm using
GCC 4.1.2 20070626 and ICC v11.1 for Linux.
How does ICC's optimization levels (O1 to O3) differ
Hi all,
I'm interested in knowing how GCC differs from Intel's ICC in terms of the
optimization levels and catering to specific processor architecture. I'm using
GCC 4.1.2 20070626 and ICC v11.1 for Linux.
How does ICC's optimization levels (O1 to O3) differ from GCC, if they differ
at all?
T
Massimo Nazaria writes:
> I need to get the array size from a declaration like "int v[100]" (here the
> size is "100").
>
> For example:
> if (TREE_CODE (TREE_TYPE (var))) == ARRAY_TYPE) {
> int array_size = // ...here I want to get the size
> }
Quoting gcc/tree.def:
/* Types of arrays
Hi everyone!
I need to get the array size from a declaration like "int v[100]" (here the
size is "100").
For example:
if (TREE_CODE (TREE_TYPE (var))) == ARRAY_TYPE) {
int array_size = // ...here I want to get the size
}
How can I do?
Thank you
Max
On Mon, Mar 22, 2010 at 5:48 PM, Ian Lance Taylor wrote:
>
> See, e.g., LIB2FUNCS_STATIC_EXTRA in config/arm/t-bpabi, and
> config/arm/fp16.c, and the calls to set_conv_libfunc in
> arm_init_libfuncs in config/arm/arm.c.
>
> Ian
>
Thanks for the refs once again Ian, that's extremelly helpful.
Ch
"Paulo J. Matos" writes:
> After looking into the arm code I am quite confused since even though
> it uses HF (at least I found references to it in gcc4.5, but not in
> gcc4.3 or gcc4.4), I can't see how it's importing floatunsihf. In
> fact, I can't find any reference to a function called floatu
> Enabling BB-reorder only if profile info is available, is not the
> right way to go. The compiler really doesn't place blocks in sane
> places without it -- and it shouldn't have to, either. For example if
> you split an edge at some point, the last thing you want to worry
> about, is where the n
On 03/18/10 08:30, Frank Isamov wrote:
From the h file:
#define REG_CLASS_CONTENTS \
{
\
{0x, 0x, 0x}, /* NO_REGS*/ \
{0x, 0x, 0x}, /* D_REGS*/ \
{0x000
On 03/22/2010 12:43 PM, Robert Dewar wrote:
> the code for computing the hash has to be taken into account, but
> nothing else than actual benchmarks will give an accurate
> comparison.
I agree. I'd also like to point out that as it is not very difficult
to do these benchmarks, the proponent(s)
Hi,
I am writing a pass in which I need to insert a call to a library
function. Specifically I need to call the function
"pthread_mutex_lock" from the library "pthread". I am working on
GIMPLE, specifically after the "build_cfg" pass.
Looking around the documentation, what I found is I will have
Unruh, Erwin wrote:
Hi,
the discussion so far did omit one specific aspect. When comparing two
implementations for a switch, you have to compare the full code. For the hash
you have to include the code to calculate the hash function. This might be more
code than a simple tree lookup.
The exam
Hi,
the discussion so far did omit one specific aspect. When comparing two
implementations for a switch, you have to compare the full code. For the hash
you have to include the code to calculate the hash function. This might be more
code than a simple tree lookup.
The example function:
>public
On Thu, Mar 18, 2010 at 5:10 PM, Ian Lance Taylor wrote:
>
> Unlikely. The question here is whether your target uses HFmode. If
> it does, you have to arrange to provide the HFmode libgcc functions.
> That does not happen automatically. HFmode is a 16-bit floating point
> mode; currently the on
On Thu, Mar 18, 2010 at 5:10 PM, Ian Lance Taylor wrote:
>
> Unlikely. The question here is whether your target uses HFmode. If
> it does, you have to arrange to provide the HFmode libgcc functions.
> That does not happen automatically. HFmode is a 16-bit floating point
> mode; currently the on
14 matches
Mail list logo
