Re: Passing an string argument to a GIMPLE call

2020-06-28 Thread Richard Biener via Gcc 
On June 27, 2020 11:15:50 PM GMT+02:00, David Malcolm  
wrote:
>On Sat, 2020-06-27 at 21:27 +0800, Shuai Wang via Gcc wrote:
>> Dear Richard,
>> 
>> Thanks for the info. My bad, I will need to append "\0" at the end of
>> the
>> string. Also, a follow-up question which I just cannot find an
>> answer:
>> typically in the plugin entry point:
>> 
>> virtual unsigned int execute(function *fun)
>> 
>> How do I know which C files I am instrumenting? Can I somehow get the
>> name
>> of the C file? I don't find a corresponding pointer in the function
>> struct.
>
>fun->function_start_locus and fun->function_end_locus are the
>location_t for the start and end of the function; 

DECL_SOURCE_LOCATION of cfun->decl might be a more reliable source. 

Richard 

also, each gimple
>stmt has a location_t (although this isn't always set for every stmt).
>
>Given a location_t, you can use LOCATION_FILE (loc) to get the source
>file (and various other macros and accessors, see input.h)
>
>Hope this is helpful
>Dave
>
>> Best,
>> Shuai
>> 
>> On Sat, Jun 27, 2020 at 9:12 PM Richard Biener <
>> richard.guent...@gmail.com>
>> wrote:
>> 
>> > On June 27, 2020 6:21:12 AM GMT+02:00, Shuai Wang via Gcc <
>> > gcc@gcc.gnu.org>
>> > wrote:
>> > > Hello,
>> > > 
>> > > I am writing the following statement to make a GIMPLE call:
>> > > 
>> > >  tree function_fn_type =
>> > > build_function_type_list(void_type_node,
>> > > void_type_node, integer_type_node, NULL_TREE);
>> > >  tree sancov_fndecl =
>> > > build_fn_decl("my_instrumentation_function",
>> > > function_fn_type);
>> > > 
>> > > auto gcall = gimple_build_call(sancov_fndecl, 2,
>> > > build_string_literal(3, "foo"),
>> > > build_int_cst_type(integer_type_node,
>> > > 0));
>> > > 
>> > > However, when executing the GIMPLE plugin, while inducing no
>> > > internal
>> > > crash, the following function call statement is generated:
>> > > 
>> > >  my_instrumentation_function (*&"foo"[0]*, 0);
>> > > 
>> > > The first argument seems really strange. Can I somewhat just put
>> > > a
>> > > "foo"
>> > > there instead of the current form? Thank you very much.
>> > 
>> > It looks correct. You are passing the address of the string
>> > literal.
>> > 
>> > Richard.
>> > 
>> > > Best,
>> > > Shuai

atomic_load: code generation 64 bit for struct

2020-06-28 Thread Uecker, Martin 

Hi all,

the following code compiles into a mov instruction
on x86_64.  I wonder why. The struct has alignment 4,
so a mov might not be atomic if the struct is not
alligned to its full size.  For this reason,
I expected a call to libatomic instead 
(LLVM does this).  What am I missing?

The documentation implies that this should work
for all types.


typedef struct { float re; float im; } yy_t;

yy_t bar2(yy_t* x)
{
yy_t r;
__atomic_load(x, &r, __ATOMIC_SEQ_CST);
return r;
}


https://godbolt.org/z/XcDkG_

Best,
Martin

gcc-11-20200628 is now available

2020-06-28 Thread GCC Administrator via Gcc 
Snapshot gcc-11-20200628 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20200628/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision b26fd416fb0a734d3f3e56629b6dff2e3c25dd40

You'll find:

 gcc-11-20200628.tar.xz   Complete GCC

  SHA256=d4fef9327b480b852e0828d604c86b8d3fbd3b96986f713e39606fd556399351
  SHA1=c116cdc929b84d1e93e75bfee643be65e824309c

Diffs from 11-20200621 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.