Hi,
This message is a bit off topic, but given the nature, I hope nobody objects.
I'm asking for help from programmers to help set up a unique open-source
project that could benefit a great many people.
The Tagmata Project's three aims are :
(1) to create a completely open-source website
(2) t
Hello,
I found that currently if a function with specific optimization flags is
inlined,
the flags are lost during compilation. This will happen much more often with
LTO (which still cannot handle it in bytecode). I wonder whether this
is the best way to do it. Maybe we just don't inline any func
On Wed, Sep 8, 2010 at 12:07 PM, Bingfeng Mei wrote:
> Hello,
> I found that currently if a function with specific optimization flags is
> inlined,
> the flags are lost during compilation. This will happen much more often with
> LTO (which still cannot handle it in bytecode). I wonder whether thi
I tried with following code.
~/work/install-x86/bin/gcc tst.c -O2 -o a.out -save-temps
foo still gets inlined into main function.
If I use -O0 in the attribute, the foo is compiled with -O0
and not inlined. I am a bit confused now.
Bingfeng
static void foo (int * __restrict__ a, int * __restric
I dug a little deeper into internal manual and source code.
I think currently only functions with target-specific attribute
are not inlinable, not with function-specific optimize attribute.
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent:
Hello,
I have noticed that at least in GCC4.3 the switch cases are ordered
somewhere in a pass, since they arrive at expand pass ordered in
increasing order.
Can anyone tell me if I can assume this always to happen and where this
is happening? I couldn't find any reference to this in the interna
On 09/08/2010 07:15 AM, Paulo J. Matos wrote:
> Hello,
>
> I have noticed that at least in GCC4.3 the switch cases are ordered
> somewhere in a pass, since they arrive at expand pass ordered in
> increasing order.
>
> Can anyone tell me if I can assume this always to happen and where this
> is h
It seems the auto-vectorizer could not recognize that this loop will roll at
most 3 times.
And it will generate quite messy code.
int a[1024], b[1024];
void foo (int n)
{
int i;
for (i = (n/4)*4; i< n; i++)
a[i] = a[i] + b[i];
}
How can we correctly estimate the number of iteratio
On Wed, Sep 8, 2010 at 3:47 PM, Richard Henderson wrote:
> Yes, you can assume this.
>
> It happens in sort_case_labels, initially called by gimplify_switch_expr.
>
>
Great, thanks.
To submit a patch for a new pass for review, is there any due date for
inclusion on the next version?
Should I disc
On 09/08/2010 02:25 PM, Paulo J. Matos wrote:
> To submit a patch for a new pass for review, is there any due date for
> inclusion on the next version?
Yes, I recall seeing a message about this.
http://gcc.gnu.org/ml/gcc/2010-08/msg00477.html
> Should I discuss it with someone?
Almost certain
I'm looking into a case where TER is forward propagating a series of
additions across a call.
extern void foo(void);
int bar(int a, int b, int c, int d, int e, int f, int g, int h) {
int ret;
ret = a + b + c + d + e + f + g + h;
foo();
return ret; /* 'ret' use replaced by rhs above */
On Mon, Sep 6, 2010 at 09:13, xie pan wrote:
> i want a a gcc
Can you be more specific?
12 matches
Mail list logo
