use smart pointers instead of naked pointers and exceptions must not leave the destructor
Clang does not support c++ syntax (new,delete,shared_ptr) for analyze. No one c++ checker does not support opportunity to say that 'please use smart pointer instead of naked pointer'. This is good way to avoid memory leak and avoid other problems related with naked pointer. It would be very nice , if gcc could do it. Very useful to receive an error message when exceptions are leaving the destructor. Clang with own analyze tools can not say anything about this error. It would be very nice if this error is detected by gcc.
How to tell that an insn sets a call argument register in RTL-land?
Hello,
What is the correct way to see if a register is used by a call and not
used to e.g. hold the address of the callee? For example,
20: %g1:DI=high(`baz')
22: %g1:DI=[%g1:DI+low(`baz')]
23: %o0:DI=0x4
24: %o0:DI=call [%g1:DI] argc:0
In the above code (from the .210.postreload dump of the attached t.c)
insn 23 sets a call arg register for insn 24, and insn 22 loads the
call address. Using sched-deps, my analysis causes both insns to be
candidates to fill the delay slot of insn 24 (see attached DOT file,
region 5), but that's obviously not correct. In reorg.c's delay slot
scheduling, it somehow knows that insn 23 can fill the delay slot of
insn 24 while insn 22 cannot.
How can I tell whether an insn "only" sets a call arg register, and is
otherwise permutable with the call insn itself?
Thanks,
Ciao!
Steven
$ cat t.c
long bar (long) __attribute__((__pure__,__const__));
long (*baz ) (long);
long x[4];
long foo (void);
long
foo (void)
{
long a = x[0];
long b = x[1];
long c = x[2];
long d = x[3];
long e;
long f;
if (a > b)
{
e = baz (4);
a = c - b;
f = bar (a);
b = d - a;
}
if (c > d)
{
e = bar (6);
c = a - b;
f = bar (7);
d = b - c;
}
return a * b * c * d + e + f;
}
t.c.228r.sched2.dot
Description: Binary data
Re: How to tell that an insn sets a call argument register in RTL-land?
> What is the correct way to see if a register is used by a call and not > used to e.g. hold the address of the callee? For example, > >20: %g1:DI=high(`baz') >22: %g1:DI=[%g1:DI+low(`baz')] >23: %o0:DI=0x4 >24: %o0:DI=call [%g1:DI] argc:0 > > In the above code (from the .210.postreload dump of the attached t.c) > insn 23 sets a call arg register for insn 24, and insn 22 loads the > call address. Using sched-deps, my analysis causes both insns to be > candidates to fill the delay slot of insn 24 (see attached DOT file, > region 5), but that's obviously not correct. In reorg.c's delay slot > scheduling, it somehow knows that insn 23 can fill the delay slot of > insn 24 while insn 22 cannot. resource.c:mark_referenced_resources. If include_delayed_effects is true, the USEs in CALL_INSN_FUNCTION_USAGE are taken into account; if it is false, they are not. Then mark_referenced_resources is called with true or false from reorg.c depending on the context. > How can I tell whether an insn "only" sets a call arg register, and is > otherwise permutable with the call insn itself? You need to parse CALL_INSN_FUNCTION_USAGE. -- Eric Botcazou
GSoC 2013 proposal
Good afternoon, my name is Christos and I'm an MSc student in Information Security at Royal Holloway University of London. I was recently thinking of how could a kernel control flow integrity mechanism at compile time by enforcing checks on the ret instructions. I think that a good start for that would be to perform these checks to "hot-spot" data structures of the kernel which are usually subverted during an intrusion (mainly by rootkits). I don't have previous experience with the gcc project and the only big project I've worked on before is syslog-ng. As a result I really need comments upon the idea and mentoring. I have in mind that it can be a good start for an extensible control flow integrity at compile time. I'll be waiting for discussion. Cheers -- Christos Tsopokis
Simple way to pass new #pragma to GIMPLE
Is there any simple way to add support of custom pragma-directive for C/C++ = front-ends? I'm trying to avoid lots of modifications on every level from pa= rser to GIMPLE. /* With optimism, Evgeny Gavrin email : evgeny.gav...@hotmail.com */
Re: Simple way to pass new #pragma to GIMPLE
On Tue, Apr 09, 2013 at 01:21:27PM +, Evgeny Gavrin wrote:
> Is there any simple way to add support of custom pragma-directive for C/C++ =
> front-ends?
> I'm trying to avoid lots of modifications on every level from pa=
> rser to GIMPLE.
Yes, make a GCC plugin (in C++) or better yet a MELT extension (see
http://gcc-melt.org/
for more about MELT which is a high-level domain specific language to extend
GCC)
to add your pragmas.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Simple way to pass new #pragma to GIMPLE
On Tue, Apr 9, 2013 at 3:51 PM, Basile Starynkevitch
wrote:
> On Tue, Apr 09, 2013 at 01:21:27PM +, Evgeny Gavrin wrote:
>> Is there any simple way to add support of custom pragma-directive for C/C++ =
>> front-ends?
>> I'm trying to avoid lots of modifications on every level from pa=
>> rser to GIMPLE.
>
> Yes, make a GCC plugin (in C++) or better yet a MELT extension (see
> http://gcc-melt.org/
> for more about MELT which is a high-level domain specific language to extend
> GCC)
> to add your pragmas.
But note that there is no easy possible way of passing down a #pramga to
GIMPLE.
Richard.
> Cheers.
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
Run the ACATS on a ZFP runtime
Hi, I want to run the Ada Conformity Assessment Test Suite in gcc/testsuite/ada/acats on a ZFP runtime. But the ACATS uses packages such as ADA.TEXT_IO which are not available on a ZFP runtime. Is there any way to configure the ACATS for a ZFP runtime environment? I use GCC 4.5.2. Cheers.
Re: Run the ACATS on a ZFP runtime
> I want to run the Ada Conformity Assessment Test Suite in > gcc/testsuite/ada/acats on a ZFP runtime. > But the ACATS uses packages such as ADA.TEXT_IO which are not available on a > ZFP runtime. > Is there any way to configure the ACATS for a ZFP runtime environment? Not really, this wouldn't make much sense, since ZFP is a restricted environment where many ACATS tests aren't supported/relevant. Arno
Re: [Patch, testsuite] Add missing -gdwarf-2 flag in debug/dwarf2 testcase
On Fri, Apr 05, 2013 at 12:02:49AM +0530, Senthil Kumar Selvaraj wrote:
> On Thu, Apr 04, 2013 at 01:41:30PM -0400, Jason Merrill wrote:
> > On 04/04/2013 11:48 AM, Senthil Kumar Selvaraj wrote:
> > >+Common Var(dwarf_version, 4) Negative(gdwarf-)
> >
> > I don't think you need to mention the variable on this line; it's
> > already there and statically initialized for gdwarf-.
> >
> Yeah, you're right. I was originally attempting to use "value"
> directly, and that of course, didn't work as it was set to 1.
> Sorry, I should have been more careful.
>
> > >I wasn't able to get this done in a clean way. To make the gdwarf option
> > >handling code detect this error, the only I found was to make it
> > >JoinedOrMissing, and then raise the error if there was an argument
> > >provided.
> >
> > That sounds clean enough to me.
> >
>
> Ok, I thought it was odd to specify that gdwarf has an optional
> argument in the opt file, only to reject it outright when processing it.
> Will send another patch tomorrow.
I added detection and error emission if version is specified with
gdwarf. Does this look ok?
Regards
Senthil
diff --git gcc/common.opt gcc/common.opt
index e02e7ed..e3645c3 100644
--- gcc/common.opt
+++ gcc/common.opt
@@ -2308,9 +2308,13 @@ Common JoinedOrMissing
Generate debug information in default format
gcoff
-Common JoinedOrMissing Negative(gdwarf-)
+Common JoinedOrMissing Negative(gdwarf)
Generate debug information in COFF format
+gdwarf
+Common JoinedOrMissing UInteger Negative(gdwarf-)
+Generate debug information in the default DWARF version format
+
gdwarf-
Common Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
Generate debug information in DWARF v2 (or later) format
diff --git gcc/opts.c gcc/opts.c
index 45b12fe..4bfee42 100644
--- gcc/opts.c
+++ gcc/opts.c
@@ -1699,6 +1699,17 @@ common_handle_option (struct gcc_options *opts,
set_debug_level (SDB_DEBUG, false, arg, opts, opts_set, loc);
break;
+case OPT_gdwarf:
+ if (arg && strlen(arg) != 0)
+{
+ error_at (loc, "dwarf version is not allowed. "
+ "Try -gdwarf-%d or -g%d instead.", value, value);
+ break;
+}
+ else
+{
+ value = opts->x_dwarf_version;
+}
case OPT_gdwarf_:
if (value < 2 || value > 4)
error_at (loc, "dwarf version %d is not supported", value);
Re: [Patch, testsuite] Add missing -gdwarf-2 flag in debug/dwarf2 testcase
On 04/09/2013 11:55 AM, Senthil Kumar Selvaraj wrote: + error_at (loc, "dwarf version is not allowed. " + "Try -gdwarf-%d or -g%d instead.", value, value); Let's be a bit more verbose, maybe + error_at (loc, "%<-gdwarf%s> is ambiguous; " + "use %<-gdwarf-%s%> for DWARF version " + "or %<-gdwarf -g%s%> for debug level", arg, arg, arg); OK with that change, thanks. Jason
Re: If you had a month to improve gcc build parallelization, where would you begin?
How does that work? The binaries have to get the all the machines of the clusters somewhere. Does this assume you are using NFS or similar for your build directory? Won't the overhead of using that instead of local disk kill most of the parallelization benefit of a cluster over a single SMP machine? This will be true regardless of communication method. There is so little opportunity for parallelism that anything more than 4-8 local cores is pretty much wasted. On a 4-core machine, more than 50% of the wall time is spent on things that will not use more than those 4 cores regardless. If the other 40-50% or so can be cut by a factor 4 compared to 4-core execution, we still are talking about at most a 30% improvement on the total wall time. Even a small serial overhead for communicating sources and binaries will still reduce this 30%. We need to improve the Makefiles before it makes sense to use more parallelism. Otherwise we'll just keep running into Amdahl's law. Some numbers, 16-core 64-thread POWER7, c,c++,fortran bootstrap: -j6: real57m32.245s user205m51.480s sys 6m24.043s -j10: real45m55.034s user211m37.833s sys 6m33.305s -j15: real41m51.061s user237m26.174s sys 7m2.341s -j60: real38m18.583s user336m12.393s sys 11m26.717s Segher
Re: If you had a month to improve gcc build parallelization, where would you begin?
On Apr 9, 2013, at 22:19, Segher Boessenkool wrote: > Some numbers, 16-core 64-thread POWER7, c,c++,fortran bootstrap: > -j6: real57m32.245s > -j60: real38m18.583s Yes, these confirm mine. It doesn't make sense to look at more parallelization before we address the serial bottlenecks. The the -j6 parallelism level is about where current laptops are. Having a big machine doesn't do as much as having fewer, but faster cores. We should be able to do far better. I don't know how the Power7 threads compare in terms of CPU throughput, but going from -j6 to -j48 on our 48-core AMD system should easily yield a 6x speed up as all are full cores, but we get similar limited improvements to yours, and we get almost perfect scaling in many test suite runs that are dominated by compilations. The two obvious issues: 1. large sequential chains of compiling/running genattrtab followied by compiling insn-attrtab.c and linking the compiler 2. repeated serial configure steps For 1. we need to somehow split the file up in smaller chunks. For 2. we need to have efficient caching. Neither is easy... -Geert
Re: A cscope-like gcc plugin
New feature (offsetof) has been implemented to my plugin.
Consider you've got a memory address by hardware debug tool in Linux and make
sure it refers to a variable of task_struct, now you need compute the address
of tsk->mm, but it isn't easy since there're too much members before it
struct task_struct {
...
struct sched_entity se;
...
struct mm_struct *mm, *active_mm;
...
};
The feature will dump member offset and struct size to database.
./gs offsetof task_struct mm
./gs sizeof task_struct
Currently, it works on gcc 4.6.3 only.
Attachment is from
https://gccsymdb.googlecode.com/svn/trunk@43 or
https://gccsymdb.googlecode.com/svn/tags/v4
Thanks for trying:)
Yunfeng Zhang
symdb.gcc.tgz
Description: GNU Zip compressed data
