Re: Explicitly list all tree codes in gcc/tree-streamer.c:record_common_node (was: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types)

2016-09-30 Thread Richard Biener
On Thu, Sep 29, 2016 at 4:48 PM, Thomas Schwinge
 wrote:
> Hi Richard!
>
> On Mon, 19 Sep 2016 13:25:01 +0200, Richard Biener 
>  wrote:
>> On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
>>  wrote:
>> > On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener 
>> >  wrote:
>> >> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
>> >>  wrote:
>> >> > --- gcc/tree-streamer.c
>> >> > +++ gcc/tree-streamer.c
>> >> > @@ -278,9 +278,23 @@ record_common_node (struct streamer_tree_cache_d 
>> >> > *cache, tree node)
>> >> >streamer_tree_cache_append (cache, node, cache->nodes.length ());
>> >> >
>> >> >if (POINTER_TYPE_P (node)
>> >> > -  || TREE_CODE (node) == COMPLEX_TYPE
>> >> >|| TREE_CODE (node) == ARRAY_TYPE)
>> >> >  record_common_node (cache, TREE_TYPE (node));
>> >> > +  else if (TREE_CODE (node) == COMPLEX_TYPE)
>> >> > [...]
>> >> >else if (TREE_CODE (node) == RECORD_TYPE)
>
>> [looks to me we miss handling of vector type components alltogether,
>> maybe there are no global vector type trees ...]
>
> Looks like it, yes.  Would a patch like the following be reasonable,
> which explicitly lists/handles all expected tree codes, or is something
> like that not feasible?  (That's a subset of tree codes I gathered by a
> partial run of the GCC testsuite, and libgomp testsuite; not claiming
> this is complete.)

I think it would be a nice thing to have indeed.

So -- I'm inclined to approve this patch ;)

Thanks,
Richard.

> commit f28dd9618be8a26c6a75ee089f1755e4e0281106
> Author: Thomas Schwinge 
> Date:   Thu Sep 29 16:35:19 2016 +0200
>
> Explicitly list all tree codes in gcc/tree-streamer.c:record_common_node
> ---
>  gcc/tree-streamer.c | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git gcc/tree-streamer.c gcc/tree-streamer.c
> index 6ada89a..8567a81 100644
> --- gcc/tree-streamer.c
> +++ gcc/tree-streamer.c
> @@ -303,17 +303,32 @@ record_common_node (struct streamer_tree_cache_d 
> *cache, tree node)
>   in the cache as hash value.  */
>streamer_tree_cache_append (cache, node, cache->nodes.length ());
>
> -  if (POINTER_TYPE_P (node)
> -  || TREE_CODE (node) == ARRAY_TYPE)
> -record_common_node (cache, TREE_TYPE (node));
> -  else if (TREE_CODE (node) == COMPLEX_TYPE)
> +  switch (TREE_CODE (node))
>  {
> +case ERROR_MARK:
> +case FIELD_DECL:
> +case FIXED_POINT_TYPE:
> +case IDENTIFIER_NODE:
> +case INTEGER_CST:
> +case INTEGER_TYPE:
> +case POINTER_BOUNDS_TYPE:
> +case REAL_TYPE:
> +case TREE_LIST:
> +case VOID_CST:
> +case VOID_TYPE:
> +  /* No recursion.  */
> +  break;
> +case POINTER_TYPE:
> +case REFERENCE_TYPE:
> +case ARRAY_TYPE:
> +  record_common_node (cache, TREE_TYPE (node));
> +  break;
> +case COMPLEX_TYPE:
>/* Verify that a complex type's component type (node_type) has been
>  handled already (and we thus don't need to recurse here).  */
>verify_common_node_recorded (cache, TREE_TYPE (node));
> -}
> -  else if (TREE_CODE (node) == RECORD_TYPE)
> -{
> +  break;
> +case RECORD_TYPE:
>/* The FIELD_DECLs of structures should be shared, so that every
>  COMPONENT_REF uses the same tree node when referencing a field.
>  Pointer equality between FIELD_DECLs is used by the alias
> @@ -322,6 +337,9 @@ record_common_node (struct streamer_tree_cache_d *cache, 
> tree node)
>  nonoverlapping_component_refs_of_decl_p).  */
>for (tree f = TYPE_FIELDS (node); f; f = TREE_CHAIN (f))
> record_common_node (cache, f);
> +  break;
> +default:
> +  gcc_unreachable ();
>  }
>  }
>
>
>
> Grüße
>  Thomas


[BUILDROBOT] dwarf2out_do_cfi_startproc(bool)’: may write a terminating nul past the end of the destination

2016-09-30 Thread Jan-Benedict Glaw
Hi!

When building for --target=sparc-leon-elf (using config-list.mk) with
a current GCC, I get this error message (cf.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=632317):

g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos-configlist_mk/gcc/gcc 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/. 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../include 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libbacktrace   
-o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo 
/home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c
/home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c: In function ‘void 
dwarf2out_do_cfi_startproc(bool)’:
/home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c:942:1: error: may write a 
terminating nul past the end of the destination [-Werror=format-length=]
 dwarf2out_do_cfi_startproc (bool second)
 ^~
/home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c:973:36: note: format 
output between 10 and 21 bytes into a destination of size 20
current_function_funcdef_no);
^
cc1plus: all warnings being treated as errors
Makefile:1102: recipe for target 'dwarf2out.o' failed

I haven't really tracked down since when that error/warning shows up
and whether or not it's valid, but maybe you might want to have a look?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: "Debugging is twice as hard as writing the code in the first 
place.
the second  :  Therefore, if you write the code as cleverly as possible, you 
are,
   by definition, not smart enough to debug it." - Brian W. 
Kernighan


signature.asc
Description: Digital signature