top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Extending the core language via a gcc plugin possible?

0 votes
341 views

is it possible to add a private extension to the core language (C/C++) by writing a gcc plugin?

The extension in mind is something like this

[variable_definitions;]

Later I want this be possible also inside statement headers, for example

for ([double d = 1.0; bool f = false;] size_t i = 0; i < vec.size(); ++i)
 ...

The scope of the so-defined variables shall be the same scope they are in, ie. in the for-loop case just the scope of the for-loop itself, much like the case with i.

posted Jun 18, 2018 by anonymous

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+3 votes
Valgrind with dynamically linked GCC plugin

I've been using the profiling tool valgrind for a while now. It requires an executable to run, i.e.

$ valgrind ./a.out

I want to use it on a dynamically linked GCC plugin, and list the time taken and the number of calls by each function used in the plugin. I am running the GCC plugin as follows:

 $ gcc -fplugin=./plugin.so myfile.c

When I run the following command, valgrind reports the memory leaks for only gcc and not for plugin.so. I need a way to run valgrind exclusively on my plugin, which is a .so file.

 $ valgrind gcc -fplugin=./plugin.so myfile.c
 $ gcc -fplugin=./plugin.so myfile.c -wrapper valgrind

Is it even possible to do that? I've searched up on this a lot but haven't found any concrete answer on it.

0 votes
I want to get all of compile error message list of gcc about C language?

I'm studying about C compiler for increasing software quality. So I want to get all of compile error message list of gcc about C language. I was trying to find it. But I can't find it anywhere. How can I find it?

Please help?

+1 vote
Inserting named labels through a GCC plugin

I'm writing a gcc plugin to find out target basic blocks to branch instructions, and need to match instructions and basic blocks with compiled binaries, so I decided to explicitly annotate all the branch
instructions and basic blocks with named labels, then from the compiler plugin I assign named labels to branch instructions and basic blocks, and from symbol table I can get offset to these instructions
and basic blocks. Is this the right way to do it, or I shouldn't do this task in compiling phase?

When I was trying with this method, I wrote a plugin with some code like this:

unsigned int
first_rtl_exec(void)
{
 rtx insn, bb_start, bb_end;
 basic_block bb;
 FOR_EACH_BB(bb)
 {
 bb_start = gen_label_rtx();
 LABEL_NAME(bb_start) = "BB Start";
 LABEL_NUSES(bb_start) = 1;
 bb_end = gen_label_rtx();
 LABEL_NAME(bb_end) = "BB End";
 LABEL_NUSES(bb_end) = 1;

 emit_label_before(bb_start, BB_HEAD(bb));
 emit_label_after(bb_end, BB_END(bb));
 }

 return 0;
}

I insert this pass before final pass. But when compiling C program with this plugin, I got error:

foo.c:7:1: internal compiler error: in final, at final.c:1958
 }
 ^

It seems this is not the correct way to insert labels. Am I using emit_label_* in a wrong way, at wrong time, or I'm totally in the wrong direction?

+1 vote
What is the GCC C++ equivalent implementation of Windows _ MyFirst and _MyLast vector pointers?

I wanted to ask what is the GCC C++ equivalent implementation of Windows _ MyFirst and _MyLast vector pointers?

These give direct access to the vectors first and last element, but they are not present in the GCC implementation of the vector class.

0 votes
Why GCC prefers global size-unaware deallocation function?

I have the following operator delete replacements:

void operator delete[](void* p)
{
 /* Implementation does not matter. */
}

void operator delete[](void* p, std::size_t size)
{
 /* Implementation does not matter. */
}

My question is why, in the following code, GCC 6.2 calls void operator delete[](void*) and not the second replacement:

char* str = new char[14];
delete[] str;

According to 5.3.5 Delete [expr.delete]:
(10.3) If the type is complete and if, for the second alternative (delete array) only, the operand is a pointer to a class type with a non-trivial destructor or a (possibly multi-dimensional) array thereof, the function with a parameter of type std::size_t is selected.

Therefore, I believe operator delete[](void*, std::size_t) must be called, doesn't it?

...