How to identify the type of the object being created using the new operator?
Hello, Statement : A *a = new B; gets translated in GIMPLE as 1. void * D.2805; 2. struct A * a; 3. D.2805 = operator new (20); 4. a = D.2805; A is the base class and B is the derived class. In statement 3, new operator is creating an object of derived class B. By analyzing the RHS of the assignment statement 3, how can we identify the type (in this case B) of the object being created? Regards, Swati
Re: How to identify the type of the object being created using the new operator?
On Mon, 6 Oct 2014, Swati Rathi wrote: Statement : A *a = new B; gets translated in GIMPLE as 1. void * D.2805; 2. struct A * a; 3. D.2805 = operator new (20); 4. a = D.2805; A is the base class and B is the derived class. In statement 3, new operator is creating an object of derived class B. By analyzing the RHS of the assignment statement 3, how can we identify the type (in this case B) of the object being created? I strongly doubt you can. It is calling B's constructor that will turn this memory region into a B, operator new is the same as malloc, it only returns raw memory. (If A and B don't have the same size, the argument 20 can be a hint) -- Marc Glisse
Re: How to identify the type of the object being created using the new operator?
On Monday 06 October 2014 02:28 PM, Marc Glisse wrote: On Mon, 6 Oct 2014, Swati Rathi wrote: Statement : A *a = new B; gets translated in GIMPLE as 1. void * D.2805; 2. struct A * a; 3. D.2805 = operator new (20); 4. a = D.2805; A is the base class and B is the derived class. In statement 3, new operator is creating an object of derived class B. By analyzing the RHS of the assignment statement 3, how can we identify the type (in this case B) of the object being created? I strongly doubt you can. It is calling B's constructor that will turn this memory region into a B, operator new is the same as malloc, it only returns raw memory. (If A and B don't have the same size, the argument 20 can be a hint) Argument 20 is the size of class B. This was obtained only if we knew that object B is created here. Is this information not stored anywhere else?
Re: Autotuning parameters/heuristics within gcc - best place to start?
Hello, Actually MILEPOST link is quite outdated. We now have a new python-based Collective Mind framework which includes universal multi-dimensional multi-objective auto-tuner with a web-based interface. If you are interested, you may find some optimization flags and parameters for different versions of GCC in JSON format for this framework here: http://c-mind.org/repo/?cm_menu=browse&browse_module_uoa=ctuning.compiler The framework itself and our long-term vision is available here: http://c-mind.org By the way, we are not advertising this framework much since it became quite large in the past few years and includes many different proof-of-concept plugins for our current work on reproducible experimentation and predictive modeling - therefore it's in our plans to release a lighter and simpler version at some point ;) ... Hope it's of any help and take care, Grigori -Original Message- From: Andrew Bennett Sent: Thursday, October 02, 2014 12:11 PM To: Gary Funck ; Andi Kleen Cc: Robert Stevenson ; gcc@gcc.gnu.org Subject: RE: Autotuning parameters/heuristics within gcc - best place to start? -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Gary Funck Sent: 28 September 2014 20:02 To: Andi Kleen Cc: Robert Stevenson; gcc@gcc.gnu.org Subject: Re: Autotuning parameters/heuristics within gcc - best place to start? On 09/26/14 07:47:05, Andi Kleen wrote: > One example of an existing autotuner is the gccflags tuner in opentuner. Although dated, ACOVEA might offer up some ideas. http://stderr.org/doc/acovea/html/acovea_4.html The Milepost project might also be of interest: http://ctuning.org/wiki/index.php/CTools:MilepostGCC Regards, Andrew
bug report - libsanitizer compilation fail
Hi, I am sending this bug report here because I can't register an account in bugzilla... gcc version: gcc-linaro-4.9-2014.09 (I checked also the main repo git, the code is the same) kernel: 2.6.37 "home/daniel/Downloads/.build/src/gcc-custom/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:675:43: error: 'EVIOCGPROP' was not declared in this scope" This happens when compiling with kernel 2.6.37 headers. #if EV_VERSION > (0x01) unsigned IOCTL_EVIOCGKEYCODE_V2 = EVIOCGKEYCODE_V2; unsigned IOCTL_EVIOCGPROP = EVIOCGPROP(0); unsigned IOCTL_EVIOCSKEYCODE_V2 = EVIOCSKEYCODE_V2; #else unsigned IOCTL_EVIOCGKEYCODE_V2 = IOCTL_NOT_PRESENT; unsigned IOCTL_EVIOCGPROP = IOCTL_NOT_PRESENT; unsigned IOCTL_EVIOCSKEYCODE_V2 = IOCTL_NOT_PRESENT; #endif although in kernel 2.6.37 the EV_VERSION is indeed > (0x01) the EVIOCGPROP define is missing and only appears in 2.6.38 onwards. Daniel.
Re: [RFD] Using the 'memory constraint' trick to avoid memory clobber doesn't work
On Fri, Oct 3, 2014 at 8:41 AM, David Wohlferd wrote:
>
>> You want
>>
>> "=m" (*( struct foo { char x[8]; } __attribute__((may_alias)) *)Dest)
>
>
> Thank you. With your help, that worse-than-useless sample in the docs is
> getting closer to something people can actually use.
>
> Except for one last serious problem: This trick only works for very
> specific (and very small) sizes of x (something else the existing docs fail
> to mention).
>
> On x64: Sizes of 1/2/4/8/16 correctly clobber Dest (and only Dest) as
> expected. Trying to use any other values (5, 12, 32, etc) seem to force a
> full memory clobber. This is the case REGARDLESS of the actual size of the
> underlying structure. For example clobbering 16 bytes of a 12 byte struct
> only clobbers the 12 bytes of Dest (as expected), but clobbering 12 bytes of
> a 12 byte struct performs a full memory clobber. This presents a problem
> for general purpose routines like memset, where the actual size of the block
> cannot be hardcoded into the struct.
>
> glibc (which uses this trick to avoid using the memory clobber) uses a size
> of 0xfff. Being larger than 16, this always causes a full memory
> clobber, not the "memory constraint" clobber I assume they were expecting.
> OTOH, since they don't use may_alias, this is may actually be a good
> thing...
>
> While I really like the idea of using memory constraints to avoid all out
> memory clobbers, 16 bytes is a pretty small maximum memory block, and x32
> only supports a max of 8. Unless there's some way to use larger sizes (say
> SSIZE_MAX), this feature hardly seems worth documenting.
I wonder how you figured out that a 12 byte clobber performs a full
memory clobber? I'm quite sure it does not.
Richard.
> dw
