On Thu, Oct 11, 2012 at 3:08 AM, Lawrence Crowl wrote:
> As part of our effort to make programming in GCC easier, we would like
> to improve the interface to bitmaps.
>
> There are three bitmap types, each with disparate operations and
> function names. This disparity causes problems
> * when cha
On Thu, Oct 11, 2012 at 5:04 AM, Uday P. Khedker wrote:
> Hi David,
>
>> This is great progress.
>
>
> Thanks.
>
>
>>
>> If I understand the experiments, your implementtion has very small
>> cost to perform the analysis, at least for the SPEC benchmarks you are
>> testing. Have you connected the
On Thu, Oct 11, 2012 at 9:01 AM, Richard Biener
wrote:
> I'd rather not mix this with any kind of further C++-ification (that is
> introduction of member functions or operator overloads).
Agreed. At first I was surprised that Lawrence had not done the
obvious operator overloads, but the introdu
On Oct 3, 2012, Jason Merrill wrote:
> int& lazy_i()
> {
> static int i = init;
> return i;
> }
> If the initialization is expensive or order-sensitive, this is a
> useful alternative to initialization on load
> An interesting property of such functions is that they only have
> side-effect
On 10/11/2012 11:14 AM, Alexandre Oliva wrote:
How about marking the singleton containing the call to the initializer
as always_inline, but not the initializer itself?
The compiler can then infer that initialized is set on the first inlined
call and optimize away subsequent tests and initializer
That's actually not true. In fact existing GCC pointer analysis is
flow-sensitive for all SSA pointers.
SSA provides partial flow sensitivity to the top level pointers. For deeper
pointers, one needs to interleave SSA and points-to analysis. Besides, it cannot
handle global pointers which ar
On 10/11/12, Richard Biener wrote:
> On Oct 11, 2012, Lawrence Crowl wrote:
>> As part of our effort to make programming in GCC easier, we would like
>> to improve the interface to bitmaps.
>>
>> There are three bitmap types, each with disparate operations and
>> function names. This disparity c
On 2012-10-11 13:26 , Lawrence Crowl wrote:
My only other concern was that the mapping between those function
names and the tasks to be done sometimes seemed less than obvious.
So, I proposed the name change. However, I think the current names
are workable, assuming an acceptable solution to th
On Oct 11, 2012, Jason Merrill wrote:
> On 10/11/2012 11:14 AM, Alexandre Oliva wrote:
>> How about marking the singleton containing the call to the initializer
>> as always_inline, but not the initializer itself?
>>
>> The compiler can then infer that initialized is set on the first inlined
>>
On Thu, Oct 11, 2012 at 11:53 AM, Uday P. Khedker wrote:
>
>>
>> That's actually not true. In fact existing GCC pointer analysis is
>> flow-sensitive for all SSA pointers.
>
>
> SSA provides partial flow sensitivity to the top level pointers. For deeper
> pointers, one needs to interleave SSA and
On 10/11/12, Diego Novillo wrote:
> On 2012-10-11 13:26 , Lawrence Crowl wrote:
>> My only other concern was that the mapping between those function
>> names and the tasks to be done sometimes seemed less than obvious.
>> So, I proposed the name change. However, I think the current names
>> are w
On 2012-10-11 16:25 , Lawrence Crowl wrote:
On 10/11/12, Diego Novillo wrote:
On 2012-10-11 13:26 , Lawrence Crowl wrote:
My only other concern was that the mapping between those function
names and the tasks to be done sometimes seemed less than obvious.
So, I proposed the name change. Howeve
this code looks bogus, i think that the "== INTEGER_CST" needs to disappear.
kenny
tree
build_newarray (int atype_value, tree length)
{
tree type_arg;
tree prim_type = decode_newarray_type (atype_value);
tree type
= build_java_array_type (prim_type,
host_integerp (len
Diego Novillo wrote, On Friday 12 October 2012 01:41 AM:
On Thu, Oct 11, 2012 at 11:53 AM, Uday P. Khedker wrote:
That's actually not true. In fact existing GCC pointer analysis is
flow-sensitive for all SSA pointers.
SSA provides partial flow sensitivity to the top level pointers. For
On Thu, Oct 11, 2012 at 9:41 PM, Uday P. Khedker wrote:
>
>
> Diego Novillo wrote, On Friday 12 October 2012 01:41 AM:
>
>> On Thu, Oct 11, 2012 at 11:53 AM, Uday P. Khedker
>> wrote:
>>>
>>>
That's actually not true. In fact existing GCC pointer analysis is
flow-sensitive for all
Andrew Pinski wrote, On Friday 12 October 2012 10:29 AM:
Here's an example:
main()
{
int **p;
int *a, *d;
int w, x;
a = &w;
f1(a);
p = &a;
a = &x;
f2(p);
d = a;
return *d;
}
It is clear that d can onl
decided to hold the address of a into a1 through function f1, let me eliminate
the
call to f1 and make the assignment a=&w live in some other way. Here's the
changed code:
Please read it as "eliminate the call passing a to f1".
Uday.
On Thu, Oct 11, 2012 at 10:41 PM, Uday P. Khedker wrote:
>
>
> Andrew Pinski wrote, On Friday 12 October 2012 10:29 AM:
>
>
>>> Here's an example:
>>>
>>> main()
>>> {
>>> int **p;
>>> int *a, *d;
>>> int w, x;
>>>
>>> a = &w;
>>> f1(a);
>>> p
Andrew Pinski wrote, On Friday 12 October 2012 11:26 AM:
Except the problem here is just about what f1 clobbers. Since a has
not escaped by the time f1 is called, f1 cannot clobber a (or d).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 for reference on why
GCC gets this incorrect. GCC
On 10/11/2012 06:59 PM, Kenneth Zadeck wrote:
> this code looks bogus, i think that the "== INTEGER_CST" needs to disappear.
>
> tree
> build_newarray (int atype_value, tree length)
> {
>tree type_arg;
>
>tree prim_type = decode_newarray_type (atype_value);
>tree type
> = build_
Hi Joseph,
I am trying to encode the relationship between Wstrict-aliasing and
Wstrict-aliasing= in the .opt files, and the same for Wstrict-overflow
and Wstrict-overflow=. However, the parameters of Alias() are taken as
strings, so we get "3" and "WARN_STRICT_OVERFLOW_CONDITIONAL". Do you
have a
21 matches
Mail list logo
