On Tue, 2015-04-07 at 10:31 +0200, Richard Biener wrote:
> > Is ADDR_EXPR the right way to get the address of the array instead of
> > the value in a gimple_build_assign call?
>
> ADDR_EXPR is one of the "single-rhs" tree codes so you need to build
> a GENERIC expression here:
>
> stmt = gimpl
On Thu, 9 Apr 2015, Martin Lucina wrote:
> I'm not sure what you mean by "tuples do not distinguish the possible use
> of an emulation environment in which to run code". If by "emulation
A toolchain that builds binaries that run for x86_64 GNU/Linux with the
normal glibc port and kernel has targ
On April 9, 2015 5:11:00 PM GMT+02:00, Swati Rathi
wrote:
>I have enabled the LTO infrastructure using -flto -flto-partition=none.
>
>In the LTO infrastructure, when I try to print the TYPE_UID for the
>types of variable var1 and var2, its different (as mentioned in my
>first
>post).
>
>IStream
On Thu, 9 Apr 2015, Florian Weimer wrote:
> On 04/09/2015 02:31 PM, Joseph Myers wrote:
>
> > It's C90 DR#075 that requires malloc (1) to return a pointer suitably
> > aligned for all types (including long double). (That is, all types that
> > can be defined using C90 standard syntax.)
> >
>
On Thursday, 02.04.2015 at 16:34, Joseph Myers wrote:
> On Mon, 30 Mar 2015, Martin Lucina wrote:
>
> > Regarding future possibilities, the Rump Kernel/anykernel concept is
> > applicable to other operating system kernels, not just NetBSD. So, say
> > someone does the work to use the Linux kernel
I have enabled the LTO infrastructure using -flto -flto-partition=none.
In the LTO infrastructure, when I try to print the TYPE_UID for the
types of variable var1 and var2, its different (as mentioned in my first
post).
IStream *var1;
IStream *var2;
On Thursday 09 April 2015 08:21 PM, Andr
On Thu, Apr 9, 2015 at 10:40 PM, Swati Rathi wrote:
> Even I am getting same uid's on small programs.
> I tried declaring variables across files also.
> But I am unable to replicate the problem on small programs.
>
> I am testing on SPEC CPU2006 benchmark suite, program - 453.povray
> Below is the
Even I am getting same uid's on small programs.
I tried declaring variables across files also.
But I am unable to replicate the problem on small programs.
I am testing on SPEC CPU2006 benchmark suite, program - 453.povray
Below is the information which is getting dumped using
-fdump-tree-gimple-
On Thu, Apr 09, 2015 at 02:36:01PM +0200, Florian Weimer wrote:
> On 04/09/2015 02:31 PM, Joseph Myers wrote:
>
> > It's C90 DR#075 that requires malloc (1) to return a pointer suitably
> > aligned for all types (including long double). (That is, all types that
> > can be defined using C90 stan
On 04/09/2015 02:31 PM, Joseph Myers wrote:
> It's C90 DR#075 that requires malloc (1) to return a pointer suitably
> aligned for all types (including long double). (That is, all types that
> can be defined using C90 standard syntax.)
>
>> Before C11, this was perfectly conforming. I doubt it
On Thu, 9 Apr 2015, Florian Weimer wrote:
> If I declare a type with an _Alignas specification, requiring an
> alignment which is less than _Alignof (max_align_t), that is a,
> fundamental alignment, then I can allocate such an object with malloc.
> That is, this code is valid:
>
> struct S {
>
On Thu, Apr 9, 2015 at 12:41 PM, Swati Rathi wrote:
>
> The variables are declared as you have mentioned.
>
> IStream *var1;
> IStream *var2;
>
> Also, var1 and var2 are declared in different functions.
Works for me.
class IStream;
void foo (void) { IStream *var1; }
void bar (void) { IStream *va
The variables are declared as you have mentioned.
IStream *var1;
IStream *var2;
Also, var1 and var2 are declared in different functions.
On Thursday 09 April 2015 03:30 PM, Richard Biener wrote:
On Thu, Apr 9, 2015 at 11:57 AM, Swati Rathi wrote:
We want to store all the types associated w
On 04/02/2015 06:45 PM, Joseph Myers wrote:
>> Follow-up question: Can malloc return a pointer which is not aligned to
>> _Alignof (max_align_t)?
>>
>> This happens with most mallocs on x86_64 for sizes of 8 or less, for
>> which these mallocs only provide an alignment of 8.
>>
>> DR445 does not s
On Thu, Apr 9, 2015 at 11:57 AM, Swati Rathi wrote:
>
> We want to store all the types associated with the class objects or pointer
> to a class in a program.
>
> Consider two variables var1 and var2 declared in different functions as
> below.
> class IStream *var1;
> class IStream *var2;
We want to store all the types associated with the class objects or
pointer to a class in a program.
Consider two variables var1 and var2 declared in different functions as
below.
class IStream *var1;
class IStream *var2;
We are extracting its type as below :
tree type1 = TREE_T
Dear Richard,
Is there any way to get the information about the referencing symbols out of/to
the map file?
The -cref flag does not provide useful information about the referenced symbols.
Something like this (example of an IAR linker map file).
ENTRY ADDRESS REF BY
= === ===
On Wed, Apr 8, 2015 at 5:14 PM, James Greenhalgh
wrote:
> On Thu, Apr 02, 2015 at 04:20:06AM +0100, Ekanathan, Saravanan wrote:
>> (I had sent this mail to gcc-help a week ago. Not sure, all GCC developers
>> are subscribed to gcc-help, so re-sending to GCC development mailing list)
>>
>> Hi,
>>
>
18 matches
Mail list logo
