Re: PowerPC long double Mangling

[Jakub Jelinek via Gcc]

On Tue, Sep 15, 2020 at 01:37:20AM -0400, Michael Meissner wrote:
> > What's the benefit of having __float128 and IEEE long double be
> > distinct types? That complicates things for libraries like libstdc++.
> > If we want to support using "__float128" with C++ iostreams then we
> > need yet another set of I/O routines, even though it's identical to
> > one of the types we already handle. Why not just keep __float128 and
> > __ieee128 and "long double when long double is IEEE" as three
> > different aliases for the same type, so that C++ code like
> > _Z4funcu9__ieee128 works for all of them, instead of needing to also
> > define _Z4funcu12__ieee128_ld?
> 
> The Boost library has methods that have both long double and __float128 in it.
> My main concern is not to break user code like Boost that the users may added
> __float128.  Obviously with glibc and libstdc++ we have people who understand
> the issues, but who knows what other libraries people have come up with.

So it will need some changes, we can describe what needs to change in
gcc-11/porting_to.html.  Boost already needs code not to enable it if
__float128 doesn't exist, so the condition would just change to __float128
does not exist or long double is the same thing (e.g. mangles the same) as
__float128). But trying to mangle __float128 and long double
differently when they are the same thing is much bigger pain, for libraries
that want to support all that would mean having to export not 5 sets of
floating point entrypoints, but 6 (float, double, long double same as
double, long double same as __ibm128, long double same as __float128,
__float128).

Jakub

Question about instrumenting gimple

[Erick Ochoa]

Hi,

I am trying to instrument gimple so that "hello world" is printed after 
each call to malloc. I've tried instrumenting using the following code


static void
// G points to the gcall which corresponds to malloc
call_hello_world(gimple* g)
{
  gimple_stmt_iterator gsi = gsi_start(g);

  // create string constant "hello world\n"
  const char* _string = "hello world\n";
  // plus 1 for the null char
  const unsigned _size = strlen(_string) + 1;
  tree _string_cst = build_string (_size, _string);

  // create char*
  tree _char_ptr = build_pointer_type(char_type_node);

  // create variable hello_string
  tree _var_decl = build_decl(UNKNOWN_LOCATION, VAR_DECL, 
get_identifier("hellostring"), _char_ptr);


  // char* hello_string = "hello world\n";
  gassign *assign_stmt = gimple_build_assign(_var_decl, _string_cst);
  gsi_insert_after(&gsi, assign_stmt, GSI_NEW_STMT);
  update_stmt(assign_stmt);

  gcall *call_stmt = 
gimple_build_call(builtin_decl_explicit(BUILT_IN_PRINTF), 1, _var_decl);

  gsi_insert_after(&gsi, call_stmt, GSI_NEW_STMT);

  update_stmt(call_stmt);
}

but when GCC is compiled with these changes it segfaults in the 
following place:



0xcca9ff crash_signal
/home/eochoa/code/ipa-dlo/gcc/gcc/toplev.c:327
0x9b99c0 useless_type_conversion_p(tree_node*, tree_node*)
/home/eochoa/code/ipa-dlo/gcc/gcc/gimple-expr.c:71
0xd1a5a7 verify_gimple_assign_single
/home/eochoa/code/ipa-dlo/gcc/gcc/tree-cfg.c:4440
0xd1a5a7 verify_gimple_assign
/home/eochoa/code/ipa-dlo/gcc/gcc/tree-cfg.c:4667
0xd1a5a7 verify_gimple_stmt
/home/eochoa/code/ipa-dlo/gcc/gcc/tree-cfg.c:4932
0xd2126b verify_gimple_in_cfg(function*, bool)
/home/eochoa/code/ipa-dlo/gcc/gcc/tree-cfg.c:5418
0xbd6ca3 execute_function_todo
/home/eochoa/code/ipa-dlo/gcc/gcc/passes.c:1992
0xbd7a63 do_per_function
/home/eochoa/code/ipa-dlo/gcc/gcc/passes.c:1647
0xbd7ae3 execute_todo
/home/eochoa/code/ipa-dlo/gcc/gcc/passes.c:2046

This tells me that gimple was ill formed and that there's likely a bad 
type conversion... and that the type conversion was ill formed during 
the assign statement... but nothing is immediately obvious why the 
assignment statement is ill formed. Do I have to update something or 
make sure to have push_cfun the function that I'm modifying?


Thanks!