Re: [BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared

[Jan-Benedict Glaw]

Hi Jeff!

On Thu, 2017-07-13 14:43:52 -0600, Jeff Law  wrote:
> On 07/13/2017 02:39 PM, Jan-Benedict Glaw wrote:
> > On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka  wrote:
> >> this is second step of the profile maintenance revamp.  It implements
> >> profile_probability type which is pretty much symmetric to profile_count
> >> except that it implements fixed point arithmetics for values 0...1.
> >> It is used to maintain probabilities of edges out of basic blocks.
> >> In addition it tracks information about quality of the estimate which can
> >> later be used for optimization.
> > 
> > RISC-V (--enable-languages=c,c++ --target=riscv32-unknown-linux-gnu
> > --without-headers --disable-threads) fails to build right now,
> > probably only missing header or header order:
> [ ... ]
> I fixed that yesterday :-)

Took me a bit to look through the logs.  Great! to see you're fixing
faster than I'd search for these small break-ups. :)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: Alles wird gut! ...und heute wirds schon ein bißchen 
besser.
the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared

[Palmer Dabbelt]

On Thu, 13 Jul 2017 13:43:52 PDT (-0700), l...@redhat.com wrote:
> On 07/13/2017 02:39 PM, Jan-Benedict Glaw wrote:
>> Hi Jan,
>> hi Kito, Palmer and Andrew!
>>
>> On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka  wrote:
>>> this is second step of the profile maintenance revamp.  It implements
>>> profile_probability type which is pretty much symmetric to profile_count
>>> except that it implements fixed point arithmetics for values 0...1.
>>> It is used to maintain probabilities of edges out of basic blocks.
>>> In addition it tracks information about quality of the estimate which can
>>> later be used for optimization.
>>
>> RISC-V (--enable-languages=c,c++ --target=riscv32-unknown-linux-gnu
>> --without-headers --disable-threads) fails to build right now,
>> probably only missing header or header order:
> [ ... ]
> I fixed that yesterday :-)

Thanks!  I was just cloning a fresh version to try and reproduce it.

Re: [BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared

[Jeff Law]

On 07/13/2017 02:39 PM, Jan-Benedict Glaw wrote:
> Hi Jan,
> hi Kito, Palmer and Andrew!
> 
> On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka  wrote:
>> this is second step of the profile maintenance revamp.  It implements
>> profile_probability type which is pretty much symmetric to profile_count
>> except that it implements fixed point arithmetics for values 0...1.
>> It is used to maintain probabilities of edges out of basic blocks.
>> In addition it tracks information about quality of the estimate which can
>> later be used for optimization.
> 
> RISC-V (--enable-languages=c,c++ --target=riscv32-unknown-linux-gnu
> --without-headers --disable-threads) fails to build right now,
> probably only missing header or header order:
[ ... ]
I fixed that yesterday :-)

jeff



signature.asc
Description: OpenPGP digital signature

[BUILDROBOT] RISC-V: ‘profile_probability’ has not been declared (was: Convert profile probabilities to new type)

[Jan-Benedict Glaw]

Hi Jan,
hi Kito, Palmer and Andrew!

On Thu, 2017-06-29 14:27:41 +0200, Jan Hubicka  wrote:
> this is second step of the profile maintenance revamp.  It implements
> profile_probability type which is pretty much symmetric to profile_count
> except that it implements fixed point arithmetics for values 0...1.
> It is used to maintain probabilities of edges out of basic blocks.
> In addition it tracks information about quality of the estimate which can
> later be used for optimization.

RISC-V (--enable-languages=c,c++ --target=riscv32-unknown-linux-gnu
--without-headers --disable-threads) fails to build right now,
probably only missing header or header order:

[...]
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 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
-I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace   -o riscv.o -MT riscv.o -MMD -MP 
-MF ./.deps/riscv.TPo /home/jbglaw/repos/gcc/gcc/config/riscv/riscv.c
In file included from /home/jbglaw/repos/gcc/gcc/config/riscv/riscv.c:56:0:
/home/jbglaw/repos/gcc/gcc/dojump.h:61:10: error: ‘profile_probability’ has not 
been declared
  profile_probability prob);
  ^
/home/jbglaw/repos/gcc/gcc/dojump.h:63:5: error: ‘profile_probability’ has not 
been declared
 profile_probability);
 ^
/home/jbglaw/repos/gcc/gcc/dojump.h:66:54: error: ‘profile_probability’ has not 
been declared
 extern void jumpif (tree exp, rtx_code_label *label, profile_probability prob);
  ^
/home/jbglaw/repos/gcc/gcc/dojump.h:68:9: error: ‘profile_probability’ has not 
been declared
 profile_probability);
 ^
/home/jbglaw/repos/gcc/gcc/dojump.h:73:39: error: ‘profile_probability’ has not 
been declared
rtx_code_label *if_true_label, profile_probability prob);
   ^
/home/jbglaw/repos/gcc/gcc/dojump.h:75:28: error: ‘profile_probability’ has not 
been declared
  rtx_code_label *, profile_probability);
^
/home/jbglaw/repos/gcc/gcc/dojump.h:79:28: error: ‘profile_probability’ has not 
been declared
  rtx_code_label *, profile_probability);
^
In file included from /home/jbglaw/repos/gcc/gcc/config/riscv/riscv.c:61:0:
/home/jbglaw/repos/gcc/gcc/expr.h:291:63: error: ‘profile_probability’ has not 
been declared
 extern int try_casesi (tree, tree, tree, tree, rtx, rtx, rtx, 
profile_probability);
   ^
/home/jbglaw/repos/gcc/gcc/expr.h:292:61: error: ‘profile_probability’ has not 
been declared
 extern int try_tablejump (tree, tree, tree, tree, rtx, rtx, 
profile_probability);
 ^
In file included from /home/jbglaw/repos/gcc/gcc/config/riscv/riscv.c:63:0:
/home/jbglaw/repos/gcc/gcc/optabs.h:251:10: error: ‘profile_probability’ has 
not been declared
  profile_probability prob
  ^
/home/jbglaw/repos/gcc/gcc/optabs.h:252:8: error: ‘profile_probability’ has not 
been declared
  = profile_probability::uninitialized ());
^
Makefile:2259: recipe for target 'riscv.o' failed
make[1]: *** [riscv.o] Error 1
make[1]: Leaving directory 
'/home/jbglaw/build/riscv32-unknown-linux-gnu/build-gcc/gcc'
Makefile:4286: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: They that give up essential liberty to obtain temporary safety,
the second  : deserve neither liberty nor safety.  (Ben Franklin)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ (was: [PATCH] [ARC] Recognise add_n and sub_n in combine again)

[Jan-Benedict Glaw]

Hi Graham,

On Mon, 2017-06-12 11:40:39 +0200, Jan-Benedict Glaw  wrote:
> On Fri, 2017-05-12 20:14:23 +0100, Graham Markall 
>  wrote:
> > Since the combine pass canonicalises shift-add insns using plus and
> > ashift (as opposed to plus and mult which it previously used to do), it
> > no longer creates *add_n or *sub_n insns, as the patterns match plus and
> > mult only. The outcome of this is that some opportunities to generate
> > add{1,2,3} and sub{1,2,3} instructions are missed.
> 
> [...]
> > diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> > index 91c28e7..42730d5 100644
> > --- a/gcc/config/arc/arc.c
> > +++ b/gcc/config/arc/arc.c
> > @@ -3483,6 +3483,14 @@ arc_print_operand (FILE *file, rtx x, int code)
> >  
> >return;
> >  
> > +case 'c':
> > +  if (GET_CODE (x) == CONST_INT)
> > +fprintf (file, "%d", INTVAL (x) );
> > +  else
> > +output_operand_lossage ("invalid operands to %%c code");
> > +
> > +  return;
> > +
> 
> 
> Build robot found something (see log at
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=704773),
> seems to be introduced with the above patch fragment:
> 
> 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 arc.o -MT arc.o -MMD -MP -MF ./.deps/arc.TPo 
> /home/jbglaw/repos-configlist_mk/gcc/gcc/config/arc/arc.c
> /home/jbglaw/repos-configlist_mk/gcc/gcc/config/arc/arc.c: In function ‘void 
> arc_print_operand(FILE*, rtx, int)’:
> /home/jbglaw/repos-configlist_mk/gcc/gcc/config/arc/arc.c:3503:41: error: 
> format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long 
> int’ [-Werror=format=]
>  fprintf (file, "%d", INTVAL (x) );
>  ^
> cc1plus: all warnings being treated as errors

This still doesn't build, see the two most current builds at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=705416
(arc-elf32, --with-cpu=arc600) and
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=705415
(arceb-linux-uclibc, --with-cpu=arc700).

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  The course of history shows that as a government grows, liberty
the second  : decreases."  (Thomas Jefferson)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] No rule to make target '/home/jbglaw/repos/gcc/gcc/config/rs6000/e500.h', needed by 's-gtype' (was: [PATCH 01/14] rs6000: Remove TARGET_FPRS)

[Segher Boessenkool]

Hi!

On Mon, Jun 12, 2017 at 12:01:34PM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2017-06-06 15:56:17 +, Segher Boessenkool 
>  wrote:
> > Since rs6000 no longer supports SPE, TARGET_FPRS now always is true.
> > 
> > This makes TARGET_{SF,DF}_SPE always false.  Many patterns in spe.md
> > can now be deleted; which makes it possible to merge e.g. negdd2 with
> > *negdd2_fpr.
> > 
> > Finally, e500.h is deleted (it isn't used).
> 
> A Buildrobot build from today for powerpc-rtems still seems to use it,
> see build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=704903:

Yeah, I forgot to delete it from some targets in config.gcc.  Will fix.

Thanks,


Segher

[BUILDROBOT] No rule to make target '/home/jbglaw/repos/gcc/gcc/config/rs6000/e500.h', needed by 's-gtype' (was: [PATCH 01/14] rs6000: Remove TARGET_FPRS)

[Jan-Benedict Glaw]

Hi Segher!

On Tue, 2017-06-06 15:56:17 +, Segher Boessenkool 
 wrote:
> Since rs6000 no longer supports SPE, TARGET_FPRS now always is true.
> 
> This makes TARGET_{SF,DF}_SPE always false.  Many patterns in spe.md
> can now be deleted; which makes it possible to merge e.g. negdd2 with
> *negdd2_fpr.
> 
> Finally, e500.h is deleted (it isn't used).

A Buildrobot build from today for powerpc-rtems still seems to use it,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=704903:

g++ -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 -fno-common  
-DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild 
-I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/build 
-I/home/jbglaw/repos/gcc/gcc/../include  
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  \
-DBASEVER="\"8.0.0\"" -DDATESTAMP="\" 20170611\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\" (experimental)\"" -DPKGVERSION="\"(GCC) \"" \
-DBUGURL="\"<https://gcc.gnu.org/bugs/>\"" -o build/version.o 
/home/jbglaw/repos/gcc/gcc/version.c
g++   -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 -fno-common  
-DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc   -o 
build/gengtype \
build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o 
build/gengtype-state.o build/version.o 
../build-x86_64-pc-linux-gnu/libiberty/libiberty.a
LC_ALL=C ; export LC_ALL ; \
gawk -f /home/jbglaw/repos/gcc/gcc/opt-gather.awk 
/home/jbglaw/repos/gcc/gcc/ada/gcc-interface/lang.opt 
/home/jbglaw/repos/gcc/gcc/brig/lang.opt 
/home/jbglaw/repos/gcc/gcc/fortran/lang.opt 
/home/jbglaw/repos/gcc/gcc/go/lang.opt /home/jbglaw/repos/gcc/gcc/lto/lang.opt 
/home/jbglaw/repos/gcc/gcc/c-family/c.opt /home/jbglaw/repos/gcc/gcc/common.opt 
/home/jbglaw/repos/gcc/gcc/config/g.opt 
/home/jbglaw/repos/gcc/gcc/config/fused-madd.opt 
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000-tables.opt 
/home/jbglaw/repos/gcc/gcc/config/rs6000/rs6000.opt 
/home/jbglaw/repos/gcc/gcc/config/rtems.opt 
/home/jbglaw/repos/gcc/gcc/config/rs6000/sysv4.opt > tmp-optionlist
/bin/bash /home/jbglaw/repos/gcc/gcc/../move-if-change tmp-optionlist optionlist
echo timestamp > s-options
gawk -f /home/jbglaw/repos/gcc/gcc/opt-functions.awk -f 
/home/jbglaw/repos/gcc/gcc/opt-read.awk \
   -f /home/jbglaw/repos/gcc/gcc/opth-gen.awk \
   < optionlist > tmp-options.h
/bin/bash /home/jbglaw/repos/gcc/gcc/../move-if-change tmp-options.h options.h
echo timestamp > s-options-h
make[1]: *** No rule to make target 
'/home/jbglaw/repos/gcc/gcc/config/rs6000/e500.h', needed by 's-gtype'.  Stop.
make[1]: Leaving directory '/home/jbglaw/build/powerpc-rtems/build-gcc/gcc'
Makefile:4223: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2


MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: "really soon now":  an unspecified period of time, 
likly to
the second  : be greater than any reasonable 
definition
  of "soon".


signature.asc
Description: Digital signature

[BUILDROBOT] error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ (was: [PATCH] [ARC] Recognise add_n and sub_n in combine again)

[Jan-Benedict Glaw]

On Fri, 2017-05-12 20:14:23 +0100, Graham Markall  
wrote:
> Since the combine pass canonicalises shift-add insns using plus and
> ashift (as opposed to plus and mult which it previously used to do), it
> no longer creates *add_n or *sub_n insns, as the patterns match plus and
> mult only. The outcome of this is that some opportunities to generate
> add{1,2,3} and sub{1,2,3} instructions are missed.

[...]
> diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> index 91c28e7..42730d5 100644
> --- a/gcc/config/arc/arc.c
> +++ b/gcc/config/arc/arc.c
> @@ -3483,6 +3483,14 @@ arc_print_operand (FILE *file, rtx x, int code)
>  
>return;
>  
> +case 'c':
> +  if (GET_CODE (x) == CONST_INT)
> +fprintf (file, "%d", INTVAL (x) );
> +  else
> +output_operand_lossage ("invalid operands to %%c code");
> +
> +  return;
> +


Build robot found something (see log at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=704773),
seems to be introduced with the above patch fragment:

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 arc.o -MT arc.o -MMD -MP -MF ./.deps/arc.TPo 
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/arc/arc.c
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/arc/arc.c: In function ‘void 
arc_print_operand(FILE*, rtx, int)’:
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/arc/arc.c:3503:41: error: 
format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ 
[-Werror=format=]
 fprintf (file, "%d", INTVAL (x) );
 ^
cc1plus: all warnings being treated as errors


MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: God put me on earth to accomplish a certain number of
the second  :things. Right now I am so far behind I will never die.


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Maybe uninitialized warnings in mips targets

[Jeff Law]

On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote:

Hi Richard, Catherine, Matthew

On Thu, 2017-03-02 14:40:46 +0100, Richard Biener  wrote:
[...]

On IRC we decided to wait&see for the TREE_NO_WARNING issue.  So the
following is what I committed.

Bootstrapped / tested on x86_64-unknown-linux-gnu.

[...]

2017-03-02  Richard Biener  

PR tree-optimization/79345
PR c++/42000
* tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
param and abort the walk, returning -1 if it is hit.
(walk_aliased_vdefs): Take a limit param and pass it on.
* tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
defaulting to 0 and return a signed int.
* tree-ssa-uninit.c (struct check_defs_data): New struct.
(check_defs): New helper.
(warn_uninitialized_vars): Use walk_aliased_vdefs to warn
about uninitialized memory.

* fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
bogus uninitialized warning.
(fixed_convert_from_real): Likewise.

* g++.dg/warn/Wuninitialized-7.C: New testcase.
* c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
* gcc.dg/uninit-pr19430-2.c: Add expected warning.


When building with config-list.mk, it seems to break for all of the
listed MIPS targets, but not on any other architecture:
I finally got around to installing the fixes to the MIPS backend for 
this problem.


Jeff

Re: [BUILDROBOT] Maybe uninitialized warnings in mips targets

[Jeff Law]

On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote:

Hi Richard, Catherine, Matthew

On Thu, 2017-03-02 14:40:46 +0100, Richard Biener  wrote:
[...]

On IRC we decided to wait&see for the TREE_NO_WARNING issue.  So the
following is what I committed.

Bootstrapped / tested on x86_64-unknown-linux-gnu.

[...]

2017-03-02  Richard Biener  

PR tree-optimization/79345
PR c++/42000
* tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
param and abort the walk, returning -1 if it is hit.
(walk_aliased_vdefs): Take a limit param and pass it on.
* tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
defaulting to 0 and return a signed int.
* tree-ssa-uninit.c (struct check_defs_data): New struct.
(check_defs): New helper.
(warn_uninitialized_vars): Use walk_aliased_vdefs to warn
about uninitialized memory.

* fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
bogus uninitialized warning.
(fixed_convert_from_real): Likewise.

* g++.dg/warn/Wuninitialized-7.C: New testcase.
* c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
* gcc.dg/uninit-pr19430-2.c: Add expected warning.


When building with config-list.mk, it seems to break for all of the
listed MIPS targets, but not on any other architecture:
Yes.  The improved uninitialized memory warnings are catching some 
things that were previously missed.


I've got fixes for all the MIPS thingies in a local tree, but haven't 
submitted them (yet).


jeff

[BUILDROBOT] Maybe uninitialized warnings in mips targets (was: [PATCH] Fix PR79345, better uninit warnings for memory)

[Jan-Benedict Glaw]

Hi Richard, Catherine, Matthew

On Thu, 2017-03-02 14:40:46 +0100, Richard Biener  wrote:
[...]
> On IRC we decided to wait&see for the TREE_NO_WARNING issue.  So the
> following is what I committed.
> 
> Bootstrapped / tested on x86_64-unknown-linux-gnu.
[...]
> 2017-03-02  Richard Biener  
> 
>   PR tree-optimization/79345
>   PR c++/42000
>   * tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
>   param and abort the walk, returning -1 if it is hit.
>   (walk_aliased_vdefs): Take a limit param and pass it on.
>   * tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
>   defaulting to 0 and return a signed int.
>   * tree-ssa-uninit.c (struct check_defs_data): New struct.
>   (check_defs): New helper.
>   (warn_uninitialized_vars): Use walk_aliased_vdefs to warn
>   about uninitialized memory.
> 
>   * fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
>   bogus uninitialized warning.
>   (fixed_convert_from_real): Likewise.
> 
>   * g++.dg/warn/Wuninitialized-7.C: New testcase.
>   * c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
>   * gcc.dg/uninit-pr19430-2.c: Add expected warning.

When building with config-list.mk, it seems to break for all of the
listed MIPS targets, but not on any other architecture:

[...]
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/scratch/4/jbglaw/configlist/repos/gcc/gcc 
-I/scratch/4/jbglaw/configlist/repos/gcc/gcc/. 
-I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../include 
-I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  
-I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libdecnumber 
-I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libbacktrace  
 -o mips.o -MT mips.o -MMD -MP -MF ./.deps/mips.TPo 
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c
In file included from 
/scratch/4/jbglaw/configlist/repos/gcc/gcc/hash-table.h:236:0,
 from 
/scratch/4/jbglaw/configlist/repos/gcc/gcc/coretypes.h:369,
 from 
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c:26:
/scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h: In function 
‘mips_multi_member* mips_multi_add()’:
/scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
   *slot = obj;
   ^
/scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h: In function ‘void 
mips_process_sync_loop(rtx_insn*, rtx_def**)’:
/scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
   *slot = obj;
   ^
/scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
   *slot = obj;
   ^
/scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
   *slot = obj;
   ^
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c: In function 
‘bool mips_expand_vec_perm_const(rtx_def**)’:
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c:21362:10: error: 
‘orig_perm’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
   memcpy (d.perm, orig_perm, MAX_VECT_LEN);
   ~~~^
cc1plus: all warnings being treated as errors
make[2]: *** [mips.o] Error 1


See eg. all the most recent builds:
mips64el-st-linux-gnu:  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699675
mips64orion-elf:
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699678
mipsisa32r2-linux-gnu:  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699702
mipsisa32-elfoabi:  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699701
mipsisa64sb1-elf:   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699724
mipsisa64sr71k-elf: 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699726
mips-netbsd:
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699750

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: God put me on earth to accomplish a certain number of
the second  :things. Right now I am so far behind I will never die.


signature.asc
Description: Digital signature

Re: [BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

[Jan-Benedict Glaw]

On Mon, 2017-02-27 09:19:51 +0100, Richard Biener  wrote:
> On Mon, 27 Feb 2017, Jan-Benedict Glaw wrote:
> > On Wed, 2017-01-11 16:28:33 +0100, Richard Biener  wrote:
> > > On Wed, 11 Jan 2017, Richard Biener wrote:
> > > > LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > > > 
> > > > (most "gross" are still TS_LIST having a type and TS_VEC having type
> > > > and chain, but that's been hard to fix with the C++ FE in place)
> > > 
> > > Forgot the tree-core.h part.
> > > 
> > > Re-bootstrapping testing on x86_64-unknown-linux-gnu.
> > > 
> > > Richard.
> > > 
> > > 2017-01-11  Richard Biener  
> > > 
> > >   * tree.c (initialize_tree_contains_struct): Make TS_OPTIMIZATION
> > >   and TS_TARGET_OPTION directly derive from TS_BASE.
> > >   * tree-core.h (tree_optimization_option): Derive from tree_base.
> > >   (tree_target_option): Likewise.
> > 
> > This caused (or uncovered) a self-test issue on arm-netbsdelf (as run
> > by config-list.mk), like in this build:
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565
[...]
> > Reverting your patch from current HEAD lets the self-test pass. Do you
> > spot something obvious?
> 
> No, can you see which collect call in the self-test is involved?
> That is, a better backtrace, eventually when compiling the testcase
> with -O0?

Starting with selftest::run_tests(), these tests need to be run to
trigger it, all others can be omitted:

ggc_tests_c_tests ();
input_c_tests ();
gimple_c_tests ();
rtl_tests_c_tests ();
read_rtl_function_c_tests ();
--> forcibly_ggc_collect ();

In this constellation, we have on the stack:

(gdb) bt full
#0  0x008aad77 in lookup_page_table_entry (p=0x7) at 
../../gcc/gcc/ggc-page.c:635
base = 0x23649c0
L1 = 246
L2 = 320
table = 0x0
high_bits = 0
#1  0x008abe72 in ggc_set_mark (p=0x7) at ../../gcc/gcc/ggc-page.c:1532
entry = 0x76140228
bit = 23
word = 0
mask = 7730548
__FUNCTION__ = "ggc_set_mark"
#2  0x00782d27 in gt_ggc_mx_lang_tree_node (x_p=0x76140228) at 
./gt-c-c-decl.h:49
x = 0x76140228
xlimit = 0x7
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#3  0x00784b7a in gt_ggc_mx_lang_tree_node (x_p=0x76472000) at 
./gt-c-c-decl.h:401
i1 = 8
l1 = 252
x = 0x76472000
xlimit = 0x0
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#4  0x007849e2 in gt_ggc_mx_lang_tree_node (x_p=0x764695e8) at 
./gt-c-c-decl.h:382
x = 0x764695e8
xlimit = 0x0
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#5  0x00782e29 in gt_ggc_mx_lang_tree_node (x_p=0x7646b6c0) at 
./gt-c-c-decl.h:68
x = 0x7646b6c0
xlimit = 0x0
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#6  0x00af4520 in ggc_mark_root_tab (rt=0x1a19c40 
) at ../../gcc/gcc/ggc-common.c:77
i = 0
#7  0x00af45b1 in ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:94
rt = 0x1990db8 
rtp = 0x0
rti = 0x1998850 
i = 360777445376
#8  0x008ad064 in ggc_collect () at ../../gcc/gcc/ggc-page.c:2202
allocated_last_gc = 4194304
min_expand = 1258291.25
#9  0x00afa314 in selftest::forcibly_ggc_collect () at 
../../gcc/gcc/ggc-tests.c:36
No locals.
#10 0x0181357d in selftest::run_tests () at 
../../gcc/gcc/selftest-run-tests.c:103
start_time = 28000
finish_time = 0
elapsed_time = 9164999
#11 0x00ea352c in toplev::run_self_tests (this=0x7fffe190) at 
../../gcc/gcc/toplev.c:2048
No locals.
#12 0x00ea36d3 in toplev::main (this=0x7fffe190, argc=20, 
argv=0x7fffe298)
at ../../gcc/gcc/toplev.c:2125
__FUNCTION__ = "main"
#13 0x018565b2 in main (argc=20, argv=0x7fffe298) at 
../../gcc/gcc/main.c:39
toplev = {m_use_TV_TOTAL = true, m_init_signals = true}

Just for the moment, maybe more tonight.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:   Wenn ich wach bin, träume ich.
  the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

[Richard Biener]

On Mon, 27 Feb 2017, Jan-Benedict Glaw wrote:

> Hi Richard,
> 
> On Wed, 2017-01-11 16:28:33 +0100, Richard Biener  wrote:
> > On Wed, 11 Jan 2017, Richard Biener wrote:
> > > LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > > 
> > > (most "gross" are still TS_LIST having a type and TS_VEC having type
> > > and chain, but that's been hard to fix with the C++ FE in place)
> > 
> > Forgot the tree-core.h part.
> > 
> > Re-bootstrapping testing on x86_64-unknown-linux-gnu.
> > 
> > Richard.
> > 
> > 2017-01-11  Richard Biener  
> > 
> > * tree.c (initialize_tree_contains_struct): Make TS_OPTIMIZATION
> > and TS_TARGET_OPTION directly derive from TS_BASE.
> > * tree-core.h (tree_optimization_option): Derive from tree_base.
> > (tree_target_option): Likewise.
> 
> This caused (or uncovered) a self-test issue on arm-netbsdelf (as run
> by config-list.mk), like in this build:
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565
> 
> /home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/xgcc
>  
> -B/home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/
>  -nostdinc -x c /dev/null -S -o /dev/null 
> -fself-test=/home/jbglaw/repos-configlist_mk/gcc/gcc/testsuite/selftests
> cc1: internal compiler error: Segmentation fault
> 0xaf7fdf crash_signal
> /home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:333
> 0x6739b3 lookup_page_table_entry
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:635
> 0x6739b3 ggc_set_mark(void const*)
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:1532
> 0x571bff gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:49
> 0x57242a gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:401
> 0x572fae gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:382
> 0x571e61 gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:391
> 0x83ed15 ggc_mark_root_tab
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:77
> 0x83ef70 ggc_mark_roots()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:94
> 0x674417 ggc_collect()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:2202
> 0x842dff selftest::forcibly_ggc_collect()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-tests.c:36
> 0x11d0491 selftest::run_tests()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/selftest-run-tests.c:103
> 0xaf9742 toplev::run_self_tests()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:2046
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> Makefile:1932: recipe for target 's-selftest' failed
> 
> 
> Reverting your patch from current HEAD lets the self-test pass. Do you
> spot something obvious?

No, can you see which collect call in the self-test is involved?
That is, a better backtrace, eventually when compiling the testcase
with -O0?

Richard.

> MfG, JBG
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

[Jan-Benedict Glaw]

Hi Richard,

On Wed, 2017-01-11 16:28:33 +0100, Richard Biener  wrote:
> On Wed, 11 Jan 2017, Richard Biener wrote:
> > LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > 
> > (most "gross" are still TS_LIST having a type and TS_VEC having type
> > and chain, but that's been hard to fix with the C++ FE in place)
> 
> Forgot the tree-core.h part.
> 
> Re-bootstrapping testing on x86_64-unknown-linux-gnu.
> 
> Richard.
> 
> 2017-01-11  Richard Biener  
> 
>   * tree.c (initialize_tree_contains_struct): Make TS_OPTIMIZATION
>   and TS_TARGET_OPTION directly derive from TS_BASE.
>   * tree-core.h (tree_optimization_option): Derive from tree_base.
>   (tree_target_option): Likewise.

This caused (or uncovered) a self-test issue on arm-netbsdelf (as run
by config-list.mk), like in this build:
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565

/home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/xgcc
 
-B/home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/
 -nostdinc -x c /dev/null -S -o /dev/null 
-fself-test=/home/jbglaw/repos-configlist_mk/gcc/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
0xaf7fdf crash_signal
/home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:333
0x6739b3 lookup_page_table_entry
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:635
0x6739b3 ggc_set_mark(void const*)
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:1532
0x571bff gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:49
0x57242a gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:401
0x572fae gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:382
0x571e61 gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:391
0x83ed15 ggc_mark_root_tab
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:77
0x83ef70 ggc_mark_roots()
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:94
0x674417 ggc_collect()
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:2202
0x842dff selftest::forcibly_ggc_collect()
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-tests.c:36
0x11d0491 selftest::run_tests()
/home/jbglaw/repos-configlist_mk/gcc/gcc/selftest-run-tests.c:103
0xaf9742 toplev::run_self_tests()
/home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:1932: recipe for target 's-selftest' failed


Reverting your patch from current HEAD lets the self-test pass. Do you
spot something obvious?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: They that give up essential liberty to obtain temporary safety,
the second  : deserve neither liberty nor safety.  (Ben Franklin)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] dwarf2out.c:22452:14: error: variable ‘origin_die’ set but not used [-Werror=unused-but-set-variable]

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 11:34:08PM +0100, Jan-Benedict Glaw wrote:
> Hi Jakub!
> 
> Seems this patch caused some breakage when building via
> config-list.mk with a recent compiler (ie. with itself) :
> 
> +2016-11-01  Jakub Jelinek  
> +
> +   * dwarf2out.c (add_name_and_src_coords_attributes): Add 
> NO_LINKAGE_NAME
> +   argument, don't call add_linkage_name if it is true.
> +   (gen_variable_die): For C++ inline static data members, consider the
> +   initial call when old_die is NULL to be declaration and call
> +   add_name_and_src_coords_attributes in that case with true as
> +   NO_LINKAGE_NAME.  Add DW_AT_inline attribute if needed.
> +   (gen_member_die): For C++ inline static data members, emit a
> +   definition DIE right away in DW_TAG_compile_unit context.

Sorry, fixed thusly, committed as obvious:

2016-11-01  Jakub Jelinek  

* dwarf2out.c (gen_variable_die): Remove again origin_die variable
and its initialization.

--- gcc/dwarf2out.c (revision 241758)
+++ gcc/dwarf2out.c (working copy)
@@ -22451,7 +22451,6 @@ gen_variable_die (tree decl, tree origin
   tree ultimate_origin;
   dw_die_ref var_die;
   dw_die_ref old_die = decl ? lookup_decl_die (decl) : NULL;
-  dw_die_ref origin_die = NULL;
   bool declaration = (DECL_EXTERNAL (decl_or_origin)
  || class_or_namespace_scope_p (context_die));
   bool specialization_p = false;
@@ -22627,7 +22626,7 @@ gen_variable_die (tree decl, tree origin
 var_die = new_die (DW_TAG_variable, context_die, decl);
 
   if (origin != NULL)
-origin_die = add_abstract_origin_attribute (var_die, origin);
+add_abstract_origin_attribute (var_die, origin);
 
   /* Loop unrolling can create multiple blocks that refer to the same
  static variable, so we must test for the DW_AT_declaration flag.

Jakub

Re: [BUILDROBOT] [Ada] error: alignment of array elements is greater than element size (was: [PATCH] GIMPLE store merging pass)

[Markus Trippelsdorf]

On 2016.10.29 at 19:56 +0200, Jan-Benedict Glaw wrote:
> Hi Kyrill!
> 
> On Mon, 2016-10-24 15:56:48 +0100, Kyrill Tkachov 
>  wrote:
> > This is a slight update over [1] with Richard's feedback addressed.
> > In terminate_all_aliasing_chains we now terminate the chain early if
> > the destination is writing to a base offset by a variable amount.
> > This avoids walking the store chain and performing more alias checks.
> [...]
> > Bootstrapped and tested on aarch64, arm, x86_64.
> 
> I'm getting build failures when Ada is enabled (ie. --disable-multilib
> --enable-languages=all,ada,go), my build robot found it (see build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=648226
> for example):

This is already fixed by Jakub's r241679.

-- 
Markus

[BUILDROBOT] [Ada] error: alignment of array elements is greater than element size (was: [PATCH] GIMPLE store merging pass)

[Jan-Benedict Glaw]

Hi Kyrill!

On Mon, 2016-10-24 15:56:48 +0100, Kyrill Tkachov  
wrote:
> This is a slight update over [1] with Richard's feedback addressed.
> In terminate_all_aliasing_chains we now terminate the chain early if
> the destination is writing to a base offset by a variable amount.
> This avoids walking the store chain and performing more alias checks.
[...]
> Bootstrapped and tested on aarch64, arm, x86_64.

I'm getting build failures when Ada is enabled (ie. --disable-multilib
--enable-languages=all,ada,go), my build robot found it (see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=648226
for example):

[...]
/home/jbglaw/src/toolchain/build/./gcc/xgcc 
-B/home/jbglaw/src/toolchain/build/./gcc/ 
-B/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/bin/ 
-B/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/lib/ -isystem 
/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/include -isystem 
/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/sys-include-c -g -O2 
 -fpic  -W -Wall -gnatpg -nostdinc   a-teioed.adb -o a-teioed.o
a-teioed.adb: In function ‘Ada.Text_Io.Editing.Format_Number’:
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb: In function ‘Ada.Text_Io.Editing.To_Picture’:
a-teioed.adb:2724:4: error: alignment of array elements is greater than element 
size
a-teioed.adb: In function ‘Ada.Text_Io.Editing.Valid’:
a-teioed.adb:2751:4: error: alignment of array elements is greater than element 
size
make[7]: *** [a-teioed.o] Error 1
make[7]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2
make[6]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[5]: *** [gnatlib-shared-default] Error 2
make[5]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[4]: *** [gnatlib-shared-dual] Error 2
make[4]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory 
`/home/jbglaw/src/toolchain/build/x86_64-pc-linux-gnu/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/home/jbglaw/src/toolchain/build'
make: *** [all] Error 2


I bisected it down to this commit, though I don't know if it caused or
uncovered the issue.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[Thomas Schwinge]

Hi!

On Wed, 5 Oct 2016 16:36:01 +0200, Bernd Schmidt  wrote:
> On 10/05/2016 04:14 PM, David Malcolm wrote:
> > Thanks.  I'm not able to formally approve these changes, but FWIW these
> > patches look good to me (assuming usual testing).
> 
> LGTM too, so OK.

Without changes, committed to trunk in r241043 and r241044:

commit 441751466e69eaf8d8da7c0d388055509b35bc63
Author: tschwinge 
Date:   Wed Oct 12 13:09:06 2016 +

In gcc/Makefile.in, factor out SELFTEST_FLAGS

gcc/
* Makefile.in (SELFTEST_FLAGS): New variable.
(s-selftest, selftest-gdb, selftest-valgrind): Use it.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241043 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   |  3 +++
 gcc/Makefile.in | 11 ---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index e57438e..003316f 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,5 +1,8 @@
 2016-10-12  Thomas Schwinge  
 
+   * Makefile.in (SELFTEST_FLAGS): New variable.
+   (s-selftest, selftest-gdb, selftest-valgrind): Use it.
+
* vmsdbgout.c (vmsdbg_debug_hooks): Add filename parameter to
early_finish hook.
 
diff --git gcc/Makefile.in gcc/Makefile.in
index 2914605..02d0c45 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1877,6 +1877,10 @@ endif
 # This does the things that can't be done on the host machine.
 rest.cross: specs
 
+# GCC's selftests.
+# Specify a dummy input file to placate the driver.
+SELFTEST_FLAGS = -x c /dev/null -S -fself-test
+
 # Run the selftests during the build once we have a driver and a cc1,
 # so that self-test failures are caught as early as possible.
 # Use "s-selftest" to ensure that we only run the selftests if the
@@ -1884,18 +1888,19 @@ rest.cross: specs
 .PHONY: selftest
 selftest: s-selftest
 s-selftest: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS)
$(STAMP) $@
 
 # Convenience method for running selftests under gdb:
 .PHONY: selftest-gdb
 selftest-gdb: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test -wrapper gdb,--args
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
+ -wrapper gdb,--args
 
 # Convenience method for running selftests under valgrind:
 .PHONY: selftest-valgrind
 selftest-valgrind: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test \
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
  -wrapper valgrind,--leak-check=full
 
 # Recompile all the language-independent object files.

commit c2d86129ef8141bb214958ca90be15fbeb42f4b1
Author: tschwinge 
Date:   Wed Oct 12 13:09:17 2016 +

Make GCC selftests work for *-wrs-vxworks-* targets

gcc/
* Makefile.in (SELFTEST_FLAGS): Add -nostdinc.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241044 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   | 2 ++
 gcc/Makefile.in | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 003316f..d6880d9 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,5 +1,7 @@
 2016-10-12  Thomas Schwinge  
 
+   * Makefile.in (SELFTEST_FLAGS): Add -nostdinc.
+
* Makefile.in (SELFTEST_FLAGS): New variable.
(s-selftest, selftest-gdb, selftest-valgrind): Use it.
 
diff --git gcc/Makefile.in gcc/Makefile.in
index 02d0c45..f1ff782 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1879,7 +1879,9 @@ rest.cross: specs
 
 # GCC's selftests.
 # Specify a dummy input file to placate the driver.
-SELFTEST_FLAGS = -x c /dev/null -S -fself-test
+# Specify -nostdinc to work around missing WIND_BASE environment variable
+# required for *-wrs-vxworks-* targets.
+SELFTEST_FLAGS = -nostdinc -x c /dev/null -S -fself-test
 
 # Run the selftests during the build once we have a driver and a cc1,
 # so that self-test failures are caught as early as possible.


Grüße
 Thomas

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[Bernd Schmidt]

On 10/05/2016 04:14 PM, David Malcolm wrote:

Thanks.  I'm not able to formally approve these changes, but FWIW these
patches look good to me (assuming usual testing).


LGTM too, so OK.


Bernd

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[David Malcolm]

On Wed, 2016-10-05 at 14:34 +0200, Thomas Schwinge wrote:
> Hi!
> 
> I've now also run into this issue, during contrib/config-list.mk
> testing;
> log/arm-wrs-vxworks-make.out, log/i686-wrs-vxworks-make.out,
> log/i686-wrs-vxworksae-make.out, log/mips-wrs-vxworks-make.out,
> log/powerpc-wrs-vxworks-make.out, log/powerpc-wrs-vxworksae-make.out,
> log/powerpc-wrs-vxworksmils-make.out, log/sh-wrs-vxworks-make.out,
> log/sparc-wrs-vxworks-make.out:
> 
> [...]/build-multi/arm-wrs-vxworks/./gcc/xgcc -B[...]/build
> -multi/arm-wrs-vxworks/./gcc/ -xc -S -c /dev/null -fself-test
> xgcc: fatal error: environment variable 'WIND_BASE' not defined
> compilation terminated.
> make[2]: *** [s-selftest] Error 1
> [...]
> make[1]: *** [all-gcc] Error 2
> 
> On Thu, 30 Jun 2016 16:09:23 -0400, David Malcolm <
> dmalc...@redhat.com> wrote:
> > On Thu, 2016-06-30 at 08:38 -0400, Nathan Sidwell wrote:
> > > [...] WIND_BASE is expected to point at a vxworks install [...]
> 
> > [...]
> > 
> > Hence it appears that passing "-nostdinc" as a param will avoid the
> > error: [...]
> > 
> > Presumably if you're explicitly building for vxworks you have a
> > vxworks
> > install, so there is a meaningful value to set WIND_BASE to,
> > whereas if
> > you don't have a vxworks install (and are merely building
> > everything as
> > a smoketest), you presumably only want to build the "gcc" subdir,
> > since
> > AFAIK you can't run then driver.
> > 
> > So there are at least 2 ways of fixing this:
> > 
> > (a) add "-nostdinc" when running the selftests i.e. to the
> > invocations
> > of GCC_FOR_TARGET in the "s-selftest" and "selftest-gdb" clauses of
> > gcc/Makefile.in.
> > I've verified that this fixes the issue for --target=i686-wrs
> > -vxworks.
> 
> OK to apply the following two patches?  First, a little bit of
> refactoring:
> 
> commit 0b124fda378c9dc726bd709f805dd52a7dc7c78a
> Author: Thomas Schwinge 
> Date:   Wed Oct 5 08:06:00 2016 +0200
> 
> In gcc/Makefile.in, factor out SELFTEST_FLAGS
> 
>   gcc/
>   * Makefile.in (SELFTEST_FLAGS): New variable.
>   (s-selftest, selftest-gdb, selftest-valgrind): Use it.
> ---
>  gcc/Makefile.in | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git gcc/Makefile.in gcc/Makefile.in
> index 15c48bc..08b96a6 100644
> --- gcc/Makefile.in
> +++ gcc/Makefile.in
> @@ -1876,6 +1876,10 @@ endif
>  # This does the things that can't be done on the host machine.
>  rest.cross: specs
>  
> +# GCC's selftests.
> +# Specify a dummy input file to placate the driver.
> +SELFTEST_FLAGS = -x c /dev/null -S -fself-test
> +
>  # Run the selftests during the build once we have a driver and a
> cc1,
>  # so that self-test failures are caught as early as possible.
>  # Use "s-selftest" to ensure that we only run the selftests if the
> @@ -1883,18 +1887,19 @@ rest.cross: specs
>  .PHONY: selftest
>  selftest: s-selftest
>  s-selftest: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
> - $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test
> + $(GCC_FOR_TARGET) $(SELFTEST_FLAGS)
>   $(STAMP) $@
>  
>  # Convenience method for running selftests under gdb:
>  .PHONY: selftest-gdb
>  selftest-gdb: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
> - $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test -wrapper
> gdb,--args
> + $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
> +   -wrapper gdb,--args
>  
>  # Convenience method for running selftests under valgrind:
>  .PHONY: selftest-valgrind
>  selftest-valgrind: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
> - $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test \
> + $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
> -wrapper valgrind,--leak-check=full
>  
>  # Recompile all the language-independent object files.
> 
> ..., and then the real change:
> 
> commit 8ab49582c42809b385eb957c20b84d21a90e041a
> Author: Thomas Schwinge 
> Date:   Wed Oct 5 08:08:37 2016 +0200
> 
> Make GCC selftests work for *-wrs-vxworks-* targets
> 
>   gcc/
>   Makefile.in (SELFTEST_FLAGS): Add -nostdinc.
> ---
>  gcc/Makefile.in | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git gcc/Makefile.in gcc/Makefile.in
> index 08b96a6..23623ac 100644
> --- gcc/Makefile.in
> +++ gcc/Makefile.in
> @@ -1878,7 +1878,9 @@ rest.cross: specs
>  
>  # GCC's selftests.
>  # Specify a dummy input file to placate the driver.
> -SELFTEST_FLAGS = -x c /dev/null -S -fself-test
> +# Specify -nostdinc to work around missing WIND_BASE environment
> variable
> +# required for *-wrs-vxworks-* targets.
> +SELFTEST_FLAGS = -nostdinc -x c /dev/null -S -fself-test
>  
>  # Run the selftests during the build once we have a driver and a
> cc1,
>  # so that self-test failures are caught as early as possible.

Thanks.  I'm not able to formally approve these changes, but FWIW these
patches look good to me (assuming usual testing).

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[Thomas Schwinge]

Hi!

I've now also run into this issue, during contrib/config-list.mk testing;
log/arm-wrs-vxworks-make.out, log/i686-wrs-vxworks-make.out,
log/i686-wrs-vxworksae-make.out, log/mips-wrs-vxworks-make.out,
log/powerpc-wrs-vxworks-make.out, log/powerpc-wrs-vxworksae-make.out,
log/powerpc-wrs-vxworksmils-make.out, log/sh-wrs-vxworks-make.out,
log/sparc-wrs-vxworks-make.out:

[...]/build-multi/arm-wrs-vxworks/./gcc/xgcc 
-B[...]/build-multi/arm-wrs-vxworks/./gcc/ -xc -S -c /dev/null -fself-test
xgcc: fatal error: environment variable 'WIND_BASE' not defined
compilation terminated.
make[2]: *** [s-selftest] Error 1
[...]
make[1]: *** [all-gcc] Error 2

On Thu, 30 Jun 2016 16:09:23 -0400, David Malcolm  wrote:
> On Thu, 2016-06-30 at 08:38 -0400, Nathan Sidwell wrote:
> > [...] WIND_BASE is expected to point at a vxworks install [...]

> [...]
> 
> Hence it appears that passing "-nostdinc" as a param will avoid the
> error: [...]
> 
> Presumably if you're explicitly building for vxworks you have a vxworks
> install, so there is a meaningful value to set WIND_BASE to, whereas if
> you don't have a vxworks install (and are merely building everything as
> a smoketest), you presumably only want to build the "gcc" subdir, since
> AFAIK you can't run then driver.
> 
> So there are at least 2 ways of fixing this:
> 
> (a) add "-nostdinc" when running the selftests i.e. to the invocations
> of GCC_FOR_TARGET in the "s-selftest" and "selftest-gdb" clauses of
> gcc/Makefile.in.
> I've verified that this fixes the issue for --target=i686-wrs-vxworks.

OK to apply the following two patches?  First, a little bit of
refactoring:

commit 0b124fda378c9dc726bd709f805dd52a7dc7c78a
Author: Thomas Schwinge 
Date:   Wed Oct 5 08:06:00 2016 +0200

In gcc/Makefile.in, factor out SELFTEST_FLAGS

gcc/
* Makefile.in (SELFTEST_FLAGS): New variable.
(s-selftest, selftest-gdb, selftest-valgrind): Use it.
---
 gcc/Makefile.in | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git gcc/Makefile.in gcc/Makefile.in
index 15c48bc..08b96a6 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1876,6 +1876,10 @@ endif
 # This does the things that can't be done on the host machine.
 rest.cross: specs
 
+# GCC's selftests.
+# Specify a dummy input file to placate the driver.
+SELFTEST_FLAGS = -x c /dev/null -S -fself-test
+
 # Run the selftests during the build once we have a driver and a cc1,
 # so that self-test failures are caught as early as possible.
 # Use "s-selftest" to ensure that we only run the selftests if the
@@ -1883,18 +1887,19 @@ rest.cross: specs
 .PHONY: selftest
 selftest: s-selftest
 s-selftest: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS)
$(STAMP) $@
 
 # Convenience method for running selftests under gdb:
 .PHONY: selftest-gdb
 selftest-gdb: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test -wrapper gdb,--args
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
+ -wrapper gdb,--args
 
 # Convenience method for running selftests under valgrind:
 .PHONY: selftest-valgrind
 selftest-valgrind: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test \
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
  -wrapper valgrind,--leak-check=full
 
 # Recompile all the language-independent object files.

..., and then the real change:

commit 8ab49582c42809b385eb957c20b84d21a90e041a
Author: Thomas Schwinge 
Date:   Wed Oct 5 08:08:37 2016 +0200

Make GCC selftests work for *-wrs-vxworks-* targets

gcc/
Makefile.in (SELFTEST_FLAGS): Add -nostdinc.
---
 gcc/Makefile.in | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git gcc/Makefile.in gcc/Makefile.in
index 08b96a6..23623ac 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1878,7 +1878,9 @@ rest.cross: specs
 
 # GCC's selftests.
 # Specify a dummy input file to placate the driver.
-SELFTEST_FLAGS = -x c /dev/null -S -fself-test
+# Specify -nostdinc to work around missing WIND_BASE environment variable
+# required for *-wrs-vxworks-* targets.
+SELFTEST_FLAGS = -nostdinc -x c /dev/null -S -fself-test
 
 # Run the selftests during the build once we have a driver and a cc1,
 # so that self-test failures are caught as early as possible.


Grüße
 Thomas

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

[Jason Merrill]

OK.

On Sat, Oct 1, 2016 at 4:30 PM, Jakub Jelinek  wrote:
> On Fri, Sep 30, 2016 at 08:59:52PM +0200, Jakub Jelinek wrote:
>> Ok if it passes bootstrap/regtest?
>
> Passed bootstrap/regtest on x86_64-linux and i686-linux.
>>
>> 2016-09-30  Jakub Jelinek  
>>
>>   * dwarf2out.c (output_fde, output_call_frame_info,
>>   dwarf2out_do_cfi_startproc, set_indirect_string,
>>   gen_internal_sym, output_die, output_line_info): Use
>>   MAX_ARTIFICIAL_LABEL_BYTES as char array sizes for
>>   ASM_GENERATE_INTERNAL_LABEL output.
>
> Jakub

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

[Jakub Jelinek]

On Fri, Sep 30, 2016 at 08:59:52PM +0200, Jakub Jelinek wrote:
> Ok if it passes bootstrap/regtest?

Passed bootstrap/regtest on x86_64-linux and i686-linux.
> 
> 2016-09-30  Jakub Jelinek  
> 
>   * dwarf2out.c (output_fde, output_call_frame_info,
>   dwarf2out_do_cfi_startproc, set_indirect_string,
>   gen_internal_sym, output_die, output_line_info): Use
>   MAX_ARTIFICIAL_LABEL_BYTES as char array sizes for
>   ASM_GENERATE_INTERNAL_LABEL output.

Jakub

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

[Jakub Jelinek]

On Fri, Sep 30, 2016 at 07:07:22PM +0200, Jan-Benedict Glaw wrote:
> 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?

I think sparc-leon-elf uses "*.L%s%ld" format, so for string of length 6
and int cast to long int it needs theoretically up to 21 bytes (3 + 6 + 11 + 1)
byt that would only trigger if the counters overflow from INT_MAX to
INT_MIN (so wouldn't be valid assembly anyway).

That said, most of spots in dwarf2out.c use the MAX_ARTIFICIAL_LABEL_BYTES
macro for sizing such buffers, so instead of changing the [20] to [21] if
the prefix can be 6 bytes I think it is cleaner to switch to using that
macro everywhere.

Ok if it passes bootstrap/regtest?

2016-09-30  Jakub Jelinek  

* dwarf2out.c (output_fde, output_call_frame_info,
dwarf2out_do_cfi_startproc, set_indirect_string,
gen_internal_sym, output_die, output_line_info): Use
MAX_ARTIFICIAL_LABEL_BYTES as char array sizes for
ASM_GENERATE_INTERNAL_LABEL output.

--- gcc/dwarf2out.c.jj  2016-09-29 22:53:14.0 +0200
+++ gcc/dwarf2out.c 2016-09-30 20:41:00.839532467 +0200
@@ -567,7 +567,7 @@ output_fde (dw_fde_ref fde, bool for_eh,
 {
   const char *begin, *end;
   static unsigned int j;
-  char l1[20], l2[20];
+  char l1[MAX_ARTIFICIAL_LABEL_BYTES], l2[MAX_ARTIFICIAL_LABEL_BYTES];
 
   targetm.asm_out.emit_unwind_label (asm_out_file, fde->decl, for_eh,
 /* empty */ 0);
@@ -722,7 +722,8 @@ output_call_frame_info (int for_eh)
   unsigned int i;
   dw_fde_ref fde;
   dw_cfi_ref cfi;
-  char l1[20], l2[20], section_start_label[20];
+  char l1[MAX_ARTIFICIAL_LABEL_BYTES], l2[MAX_ARTIFICIAL_LABEL_BYTES];
+  char section_start_label[MAX_ARTIFICIAL_LABEL_BYTES];
   bool any_lsda_needed = false;
   char augmentation[6];
   int augmentation_size;
@@ -966,7 +967,7 @@ dwarf2out_do_cfi_startproc (bool second)
 
   if (crtl->uses_eh_lsda)
 {
-  char lab[20];
+  char lab[MAX_ARTIFICIAL_LABEL_BYTES];
 
   enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/0, /*global=*/0);
   ASM_GENERATE_INTERNAL_LABEL (lab, second ? "LLSDAC" : "LLSDA",
@@ -4128,7 +4129,7 @@ AT_string (dw_attr_node *a)
 static void
 set_indirect_string (struct indirect_string_node *node)
 {
-  char label[32];
+  char label[MAX_ARTIFICIAL_LABEL_BYTES];
   /* Already indirect is a no op.  */
   if (node->form == DW_FORM_strp || node->form == DW_FORM_GNU_str_index)
 {
@@ -7076,7 +7077,7 @@ is_template_instantiation (dw_die_ref di
 static char *
 gen_internal_sym (const char *prefix)
 {
-  char buf[256];
+  char buf[MAX_ARTIFICIAL_LABEL_BYTES];
 
   ASM_GENERATE_INTERNAL_LABEL (buf, prefix, label_num++);
   return xstrdup (buf);
@@ -9382,7 +9383,7 @@ output_die (dw_die_ref die)
 
case dw_val_class_fde_ref:
  {
-   char l1[20];
+   char l1[MAX_ARTIFICIAL_LABEL_BYTES];
 
ASM_GENERATE_INTERNAL_LABEL (l1, FDE_LABEL,
 a->dw_attr_val.v.val_fde_index * 2);
@@ -10710,7 +10711,8 @@ output_one_line_info_table (dw_line_info
 static void
 output_line_info (bool prologue_only)

Re: [BUILDROBOT] tic6x-uclinux: undefined reference to `gnu_libc_printf_pointer_format(tree_node*, char const**)' (was: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905))

[Segher Boessenkool]

On Tue, Sep 27, 2016 at 12:08:46AM +0200, Jan-Benedict Glaw wrote:
> Hi Martin,
> 
> On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor  wrote:
> > Attached is another update to the patch to address the last round
> > of comments and suggestions, most notably to:
> [...]
> 
> with the currently committed version, the tic6x-uclinux target fails,
> see ie.
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=630308 :

[ snip ]

The same happens for bfin-uclinux:

g++ -no-pie   -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   -DHAVE_CONFIG_H 
-static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o c-family/stub-objc.o 
attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o 
c/c-objc-common.o c/c-parser.o c/c-array-notation.o c/c-fold.o 
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o 
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o 
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o 
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o 
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o 
c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o default-c.o 
\
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a 
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a 
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -lmpc -lmpfr -lgmp 
-rdynamic -ldl  -L./../zlib -lz
bfin.o:(.data.rel+0x778): undefined reference to 
`gnu_libc_printf_pointer_format(tree_node*, char const**)'

(that symbol would be defined in linux.o, but that file is not built for
uclinux).


Segher

Re: [BUILDROBOT] tic6x-uclinux: undefined reference to `gnu_libc_printf_pointer_format(tree_node*, char const**)'

[Martin Sebor]

On 09/26/2016 04:08 PM, Jan-Benedict Glaw wrote:

Hi Martin,

On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor  wrote:

Attached is another update to the patch to address the last round
of comments and suggestions, most notably to:

[...]

with the currently committed version, the tic6x-uclinux target fails,
see ie.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=630308 :

g++-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 -fno-common  
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o 
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o 
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o 
c/c-array-notation.o c/c-fold.o c-family/c-common.o c-family/c-cppbuiltin.o 
c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o 
c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o 
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o 
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o 
c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o 
c-family/c-ubsan.o default-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a 
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a 
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -lmpc -lmpfr -lgmp 
-rdynamic -ldl  -L./../zlib -lz
c6x.o:(.data+0x778): undefined reference to 
`gnu_libc_printf_pointer_format(tree_node*, char const**)'
collect2: error: ld returned 1 exit status
/home/jbglaw/repos/gcc/gcc/c/Make-lang.in:84: recipe for target 'cc1' failed
make[1]: *** [cc1] Error 1
make[1]: Leaving directory '/home/jbglaw/build/tic6x-uclinux/build-gcc/gcc'
Makefile:4252: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2


Add another one for uClibc?


Thanks.  There must be something wrong with the target hook I added.
This is a new area for me so please bear with me while I debug and
fix it.

Martin

[BUILDROBOT] tic6x-uclinux: undefined reference to `gnu_libc_printf_pointer_format(tree_node*, char const**)' (was: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905))

[Jan-Benedict Glaw]

Hi Martin,

On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor  wrote:
> Attached is another update to the patch to address the last round
> of comments and suggestions, most notably to:
[...]

with the currently committed version, the tic6x-uclinux target fails,
see ie.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=630308 :

g++-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 -fno-common  
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o 
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o 
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o 
c/c-array-notation.o c/c-fold.o c-family/c-common.o c-family/c-cppbuiltin.o 
c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o 
c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o 
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o 
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o 
c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o 
c-family/c-ubsan.o default-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a 
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a 
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -lmpc -lmpfr -lgmp 
-rdynamic -ldl  -L./../zlib -lz
c6x.o:(.data+0x778): undefined reference to 
`gnu_libc_printf_pointer_format(tree_node*, char const**)'
collect2: error: ld returned 1 exit status
/home/jbglaw/repos/gcc/gcc/c/Make-lang.in:84: recipe for target 'cc1' failed
make[1]: *** [cc1] Error 1
make[1]: Leaving directory '/home/jbglaw/build/tic6x-uclinux/build-gcc/gcc'
Makefile:4252: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2


Add another one for uClibc?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:  Zensur im Internet? Nein danke!
  the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

[Jeff Law]

On 09/19/2016 04:24 PM, Bernd Edlinger wrote:

On 09/19/16 23:51, Jeff Law wrote:

On 09/17/2016 05:29 PM, Bernd Edlinger wrote:

On 09/17/16 22:29, Jan-Benedict Glaw wrote:

On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger
 wrote:

Hi,

I think it is time to remove support for
INITIAL_FRAME_POINTER_OFFSET, which is no longer
used by any target today.  This removes a bunch of conditional code,
and fixes a few bits
in the documentation.  I'd say that part of the documentation is
quite out of sync, but I just
have to stop somewhere.


Bootstrapped and reg-tested on x86_64-pc-linux.gnu


The vax backend doesn't yet define ELIMINABLE_REGS.



Oh, yes.  I see.  What a hack.

Then we should define it.

But simply returning zero for the fp to sp offset is not ok,
and even if the offset is not used for register eliminations
it should still be correct for rtx_addr_can_trap_p
to know the safe stack frame offset ranges.

I would assume a small performance improvement, when
rtx_addr_can_trap_p has correct data available.

How about this patch, it should at least fix the bootstrap.
Is it OK for trunk?

OK.
jeff


Jeff,  I am sorry.

But I think I got the sign of the elimination offset wrong,
because I peeked at a stack-grows-upward target (hppa).
And the doc/tm.texi is not a big help either.

Funny, I almost called that out as something to double check :-)




With my limited testing this did not make any difference.

Actually I have not touched any vax since I was a student.

And that is already quite a while ago...

I hope you don't mind when I commit it this way:
+#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
+  ((OFFSET) = get_frame_size ())

That's fine.

jeff

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

[Bernd Edlinger]

On 09/19/16 23:51, Jeff Law wrote:
> On 09/17/2016 05:29 PM, Bernd Edlinger wrote:
>> On 09/17/16 22:29, Jan-Benedict Glaw wrote:
>>> On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger
>>>  wrote:
 Hi,

 I think it is time to remove support for
 INITIAL_FRAME_POINTER_OFFSET, which is no longer
 used by any target today.  This removes a bunch of conditional code,
 and fixes a few bits
 in the documentation.  I'd say that part of the documentation is
 quite out of sync, but I just
 have to stop somewhere.


 Bootstrapped and reg-tested on x86_64-pc-linux.gnu
>>>
>>> The vax backend doesn't yet define ELIMINABLE_REGS.
>>>
>>
>> Oh, yes.  I see.  What a hack.
>>
>> Then we should define it.
>>
>> But simply returning zero for the fp to sp offset is not ok,
>> and even if the offset is not used for register eliminations
>> it should still be correct for rtx_addr_can_trap_p
>> to know the safe stack frame offset ranges.
>>
>> I would assume a small performance improvement, when
>> rtx_addr_can_trap_p has correct data available.
>>
>> How about this patch, it should at least fix the bootstrap.
>> Is it OK for trunk?
> OK.
> jeff

Jeff,  I am sorry.

But I think I got the sign of the elimination offset wrong,
because I peeked at a stack-grows-upward target (hppa).
And the doc/tm.texi is not a big help either.

With my limited testing this did not make any difference.

Actually I have not touched any vax since I was a student.

And that is already quite a while ago...

I hope you don't mind when I commit it this way:
+#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
+  ((OFFSET) = get_frame_size ())


Thanks
Bernd.

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

[Jeff Law]

On 09/17/2016 05:29 PM, Bernd Edlinger wrote:

On 09/17/16 22:29, Jan-Benedict Glaw wrote:

On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger  
wrote:

Hi,

I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which is 
no longer
used by any target today.  This removes a bunch of conditional code, and fixes 
a few bits
in the documentation.  I'd say that part of the documentation is quite out of 
sync, but I just
have to stop somewhere.


Bootstrapped and reg-tested on x86_64-pc-linux.gnu


The vax backend doesn't yet define ELIMINABLE_REGS.



Oh, yes.  I see.  What a hack.

Then we should define it.

But simply returning zero for the fp to sp offset is not ok,
and even if the offset is not used for register eliminations
it should still be correct for rtx_addr_can_trap_p
to know the safe stack frame offset ranges.

I would assume a small performance improvement, when
rtx_addr_can_trap_p has correct data available.

How about this patch, it should at least fix the bootstrap.
Is it OK for trunk?

OK.
jeff

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

[Bernd Edlinger]

On 09/17/16 22:29, Jan-Benedict Glaw wrote:
> On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger  
> wrote:
>> Hi,
>>
>> I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which 
>> is no longer
>> used by any target today.  This removes a bunch of conditional code, and 
>> fixes a few bits
>> in the documentation.  I'd say that part of the documentation is quite out 
>> of sync, but I just
>> have to stop somewhere.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux.gnu
>
> The vax backend doesn't yet define ELIMINABLE_REGS.
>

Oh, yes.  I see.  What a hack.

Then we should define it.

But simply returning zero for the fp to sp offset is not ok,
and even if the offset is not used for register eliminations
it should still be correct for rtx_addr_can_trap_p
to know the safe stack frame offset ranges.

I would assume a small performance improvement, when
rtx_addr_can_trap_p has correct data available.

How about this patch, it should at least fix the bootstrap.
Is it OK for trunk?


Thanks
Bernd.
2016-09-17  Bernd Edlinger  

	* config/var/vax.h (ELIMINABLE_REGS): Define.
	(INITIAL_ELIMINATION_OFFSET): Define.

Index: gcc/config/vax/vax.h
===
--- gcc/config/vax/vax.h	(revision 240215)
+++ gcc/config/vax/vax.h	(working copy)
@@ -333,6 +333,16 @@
 }\
   while (0)
 
+/* This macro specifies a table of register pairs used to eliminate
+   unneeded registers that point into the stack frame.  */
+#define ELIMINABLE_REGS {{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
+
+/* On the VAX, FRAME_POINTER_REQUIRED is always 1, so the definition of this
+   macro doesn't matter for register eliminations, but it should still
+   give realistic data for rtx_addr_can_trap_p.  */
+#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
+  ((OFFSET) = -get_frame_size ())
+
 /* EXIT_IGNORE_STACK should be nonzero if, when returning from a function,
the stack pointer does not matter.  The value is tested only in
functions that have frame pointers.

[BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope (was: [PATCH] Remove support for INITIAL_FRAME_POINTER_OFFSET)

[Jan-Benedict Glaw]

On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger  
wrote:
> Hi,
> 
> I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which 
> is no longer
> used by any target today.  This removes a bunch of conditional code, and 
> fixes a few bits
> in the documentation.  I'd say that part of the documentation is quite out of 
> sync, but I just
> have to stop somewhere.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux.gnu

The vax backend doesn't yet define ELIMINABLE_REGS.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   Warum ist Scheiße braun? ...weil braun schon immer scheiße 
ist!
the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] x86_64: Segmentation fault during -fself-test (was: Implement C _FloatN, _FloatNx types [version 6]

[Joseph Myers]

On Mon, 22 Aug 2016, Jan-Benedict Glaw wrote:

> Between dee8cef0c1c1ebf85fceb5c37996ed12a2bec352 (Fri Aug 19 15:42:11
> 2016 +) and 82c85aba845985e55c27a7a9c448810d433adb17 (Fri Aug 19
> 17:43:26 2016 +), a new build regression for
> x86_64-{linux,rtems,elf} showed up and I think this patch caused it.

I do not see this in my x86_64-pc-linux-gnu tests (and the logs show those 
builds do run the self-tests as expected).

-- 
Joseph S. Myers
jos...@codesourcery.com

[BUILDROBOT] x86_64: Segmentation fault during -fself-test (was: Implement C _FloatN, _FloatNx types [version 6]

[Jan-Benedict Glaw]

Hi Joseph!

On Wed, 2016-08-17 20:17:07 +, Joseph Myers  wrote:
[...]
> ISO/IEC TS 18661-3:2015 defines C bindings to IEEE interchange and
> extended types, in the form of _FloatN and _FloatNx type names with
> corresponding fN/FN and fNx/FNx constant suffixes and FLTN_* / FLTNX_*
>  macros.  This patch implements support for this feature in
> GCC.

Between dee8cef0c1c1ebf85fceb5c37996ed12a2bec352 (Fri Aug 19 15:42:11
2016 +) and 82c85aba845985e55c27a7a9c448810d433adb17 (Fri Aug 19
17:43:26 2016 +), a new build regression for
x86_64-{linux,rtems,elf} showed up and I think this patch caused it.
It occurs during GCC's self-test while it's setting up it's FP types:


/scratch/4/jbglaw/regular/build/x86_64-elf/build-gcc/./gcc/xgcc 
-B/scratch/4/jbglaw/regular/build/x86_64-elf/build-gcc/./gcc/ -xc -S -c 
/dev/null -fself-test
: internal compiler error: Segmentation fault
0xb7803f crash_signal
/scratch/4/jbglaw/regular/repos/gcc/gcc/toplev.c:335
0x687952 tree_class_check
/scratch/4/jbglaw/regular/repos/gcc/gcc/tree.h:3145
0x687952 c_register_builtin_type(tree_node*, char const*)
/scratch/4/jbglaw/regular/repos/gcc/gcc/c-family/c-common.c:3876
0xeb6b36 ix86_init_builtin_types
/scratch/4/jbglaw/regular/repos/gcc/gcc/config/i386/i386.c:33351
0xeb6b36 ix86_init_builtins
/scratch/4/jbglaw/regular/repos/gcc/gcc/config/i386/i386.c:33366
0x6a8006 c_define_builtins
/scratch/4/jbglaw/regular/repos/gcc/gcc/c-family/c-common.c:5282
0x6a8006 c_common_nodes_and_builtins()
/scratch/4/jbglaw/regular/repos/gcc/gcc/c-family/c-common.c:5750
0x5ef719 c_init_decl_processing()
/scratch/4/jbglaw/regular/repos/gcc/gcc/c/c-decl.c:4097
0x63caf8 c_objc_common_init()
/scratch/4/jbglaw/regular/repos/gcc/gcc/c/c-objc-common.c:58
0x5de4c2 lang_dependent_init
/scratch/4/jbglaw/regular/repos/gcc/gcc/toplev.c:1766
0x5de4c2 do_compile
/scratch/4/jbglaw/regular/repos/gcc/gcc/toplev.c:1989
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [s-selftest] Error 1



See eg. build 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=608741


MfG, JBG


-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:   Wenn ich wach bin, träume ich.
  the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] avr broken

[Jan-Benedict Glaw]

On Tue, 2016-08-16 14:26:38 -0400, Nathan Sidwell  wrote:
> On 08/16/16 13:04, Jan-Benedict Glaw wrote:
> 
> > That'll probably work. But after all, I'm not an AVR maintainer
> > (not even an user), but just running the Build Robot.
> 
> Does your robot approve? :)

Ohoooh! See there! :)

http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=602648

The Robot has an answer. I guess that means he's okay with the patch
(of which, unfortunately, both versions didn't make it to the list.)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  The course of history shows that as a government grows, liberty
the second  : decreases."  (Thomas Jefferson)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] avr broken

[Martin Liška]

On 08/17/2016 09:20 AM, Denis Chertykov wrote:
> 2016-08-16 21:26 GMT+03:00 Nathan Sidwell :
>> On 08/16/16 13:04, Jan-Benedict Glaw wrote:
>>
>>> That'll probably work. But after all, I'm not an AVR maintainer (not
>>> even an user), but just running the Build Robot.
>>
>>
>> Does your robot approve? :)
>>
> 
> I'm an AVR maintainer.
> The patch does not have any AVR port modifications.
> I can't approve it.
> 

Based on Nathan's ACK, I've installed the patch as r239522.

Martin

Re: [BUILDROBOT] avr broken

[Denis Chertykov]

2016-08-16 21:26 GMT+03:00 Nathan Sidwell :
> On 08/16/16 13:04, Jan-Benedict Glaw wrote:
>
>> That'll probably work. But after all, I'm not an AVR maintainer (not
>> even an user), but just running the Build Robot.
>
>
> Does your robot approve? :)
>

I'm an AVR maintainer.
The patch does not have any AVR port modifications.
I can't approve it.

Re: [BUILDROBOT] avr broken

[Nathan Sidwell]

On 08/16/16 13:04, Jan-Benedict Glaw wrote:


That'll probably work. But after all, I'm not an AVR maintainer (not
even an user), but just running the Build Robot.


Does your robot approve? :)

Re: [BUILDROBOT] avr broken

[Jan-Benedict Glaw]

On Tue, 2016-08-16 10:31:41 -0400, Nathan Sidwell  wrote:
> On 08/16/16 10:23, Martin Liška wrote:
> > On 08/16/2016 03:36 PM, Nathan Sidwell wrote:
> > > On 08/16/16 08:49, Martin Liška wrote:
> > > > On 08/13/2016 02:14 PM, Jan-Benedict Glaw wrote:
> > > > > This doesn't work for AVR since their LONG_LONG_TYPE_SIZE
> > > > > depents on target flags (see eg. build
> > > > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=602648)
> > > > Sorry for the breakage, I haven't tried to build avr target
> > > > for the patch.  I'm sending a candidate patch which survives
> > > > regression tests on ppc64le-redhat-linux.  Apart from that,
> > > > cc1 can be built with --target=avr-linux.
> > >
> > > is LONG_LONG_TYPE_SIZE something not suitable for a #if on avr?
> >
> > Exactly that's causing the problem.
> 
> ok.  good.  There's  nothing particularly AVRish in the patch, so
> I'd  say commit if you don't hear from JB in a timely manner

That'll probably work. But after all, I'm not an AVR maintainer (not
even an user), but just running the Build Robot.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Don't believe in miracles: Rely on them!
 the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] avr broken

[Nathan Sidwell]

On 08/16/16 10:23, Martin Liška wrote:

On 08/16/2016 03:36 PM, Nathan Sidwell wrote:

On 08/16/16 08:49, Martin Liška wrote:

On 08/13/2016 02:14 PM, Jan-Benedict Glaw wrote:

This doesn't work for AVR since their LONG_LONG_TYPE_SIZE depents on
target flags (see eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=602648)


Hello.

Sorry for the breakage, I haven't tried to build avr target for the patch.
I'm sending a candidate patch which survives regression tests on 
ppc64le-redhat-linux.
Apart from that, cc1 can be built with --target=avr-linux.

Ready to be installed?
Martin



is LONG_LONG_TYPE_SIZE something not suitable for a #if on avr?


Exactly that's causing the problem.


ok.  good.  There's  nothing particularly AVRish in the patch, so I'd  say 
commit if you don't hear from JB in a timely manner


nathan

Re: [BUILDROBOT] avr broken

[Nathan Sidwell]

On 08/16/16 08:49, Martin Liška wrote:

On 08/13/2016 02:14 PM, Jan-Benedict Glaw wrote:

This doesn't work for AVR since their LONG_LONG_TYPE_SIZE depents on
target flags (see eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=602648)


Hello.

Sorry for the breakage, I haven't tried to build avr target for the patch.
I'm sending a candidate patch which survives regression tests on 
ppc64le-redhat-linux.
Apart from that, cc1 can be built with --target=avr-linux.

Ready to be installed?
Martin



is LONG_LONG_TYPE_SIZE something not suitable for a #if on avr?

presuming that's the problem, I think this approach is fine.  I did have a think 
about putting the 32/64 bit check in one place rather than the two places it is. 
 But (a) that's overkill and (b) it's in 2 places already.


So this is ok, of it's ok from AVR's POV.

nathan

[BUILDROBOT] avr broken (was: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch)

[Jan-Benedict Glaw]

On Fri, 2016-08-05 15:43:02 +0200, Martin Liška  wrote:
[...]
> Great, attaching install candidate.

> >From 0b3ac8636ef34b02e301f22c86dde0602f9969ef Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Thu, 28 Jul 2016 14:32:47 +0200
> Subject: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9
>  branch
> 
> gcc/ChangeLog:
> 
> 2016-08-05  Martin Liska  
> 
>   Cherry picked (and modified) from google-4_7 branch
>   2012-12-26  Rong Xu  
>   * common.opt (fprofile-update): Add new flag.
>   * coretypes.h: Define enum profile_update.
>   * doc/invoke.texi: Document -fprofile-update.
>   * gcov-io.h: Declare GCOV_TYPE_ATOMIC_FETCH_ADD and
>   GCOV_TYPE_ATOMIC_FETCH_ADD_FN.
>   * tree-profile.c (gimple_init_edge_profiler): Generate
>   also atomic profiler update.
>   (gimple_gen_edge_profiler): Likewise.
[...]
> --- a/gcc/gcov-io.h
> +++ b/gcc/gcov-io.h
> @@ -164,6 +164,14 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
>  If not, see
>  #ifndef GCC_GCOV_IO_H
>  #define GCC_GCOV_IO_H
>  
> +#if LONG_LONG_TYPE_SIZE > 32
> +#define GCOV_TYPE_ATOMIC_FETCH_ADD_FN __atomic_fetch_add_8
> +#define GCOV_TYPE_ATOMIC_FETCH_ADD BUILT_IN_ATOMIC_FETCH_ADD_8
> +#else
> +#define GCOV_TYPE_ATOMIC_FETCH_ADD_FN __atomic_fetch_add_4
> +#define GCOV_TYPE_ATOMIC_FETCH_ADD BUILT_IN_ATOMIC_FETCH_ADD_4
> +#endif
> +
>  #ifndef IN_LIBGCOV
>  /* About the host */
>  

This doesn't work for AVR since their LONG_LONG_TYPE_SIZE depents on
target flags (see eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=602648)



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 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
-I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace   -o auto-profile.o -MT 
auto-profile.o -MMD -MP -MF ./.deps/auto-profile.TPo 
/home/jbglaw/repos/gcc/gcc/auto-profile.c
In file included from ./tm.h:19:0,
 from /home/jbglaw/repos/gcc/gcc/backend.h:28,
 from /home/jbglaw/repos/gcc/gcc/auto-profile.c:26:
./options.h:261:36: error: token "." is not valid in preprocessor expressions
 #define target_flags global_options.x_target_flags
^
./options.h:5153:23: note: in expansion of macro ‘target_flags’
 #define TARGET_INT8 ((target_flags & MASK_INT8) != 0)
   ^
/home/jbglaw/repos/gcc/gcc/config/avr/avr.h:138:24: note: in expansion of macro 
‘TARGET_INT8’
 #define INT_TYPE_SIZE (TARGET_INT8 ? 8 : 16)
^
/home/jbglaw/repos/gcc/gcc/config/avr/avr.h:141:30: note: in expansion of macro 
‘INT_TYPE_SIZE’
 #define LONG_LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 32 : 64)
  ^
/home/jbglaw/repos/gcc/gcc/gcov-io.h:167:5: note: in expansion of macro 
‘LONG_LONG_TYPE_SIZE’
 #if LONG_LONG_TYPE_SIZE > 32
 ^
Makefile:1096: recipe for target 'auto-profile.o' failed
make[1]: *** [auto-profile.o] Error 1
make[1]: Leaving directory '/home/jbglaw/build/avr/build-gcc/gcc'


MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[Jan-Benedict Glaw]

On Thu, 2016-06-30 16:09:23 -0400, David Malcolm  wrote:
> On Thu, 2016-06-30 at 08:38 -0400, Nathan Sidwell wrote:
> > > I haven't given it any additional manual testing so far. It's
> > > pre-installation though. Maybe I'd just set WIND_BASE to some
> > > arbitrary value, just to make xgcc pass it's initial start-up
> > > test so that it can continue with self-testing? Or shall we set
> > > some value in gcc/Makefile.in for running the self-test?
> > 
> > As I recall, WIND_BASE is expected to point at a vxworks install
> > to pick up header files.  It is an error not to have it set
> > (silently skipping it leads to user confusion).
> > 
> > If that's irrelevant for this testing environment, then setting it
> > to something (probably just "", but safer might be
> > "/These.are.not.the.dirs.you.are.looking.for") should be fine.
> 
> Sorry about the breakage.

You just uncovered it :)

> The error message appears to affect a few other targets within
> gcc/Makefile.in.

[...]
> 
> So there are at least 2 ways of fixing this:
> 
> (a) add "-nostdinc" when running the selftests i.e. to the invocations
> of GCC_FOR_TARGET in the "s-selftest" and "selftest-gdb" clauses of
> gcc/Makefile.in.
> I've verified that this fixes the issue for --target=i686-wrs-vxworks.
> 
> (b) set WIND_BASE to a dummy value in contrib/config-list.mk (if not
> already set) so that the vxworks targets are able to at least build all
> of "gcc" without needing a vxworks install.

I'd probably just do (b) and go for it. Easy, non-invasive fix.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Don't believe in miracles: Rely on them!
 the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[David Malcolm]

On Thu, 2016-06-30 at 08:38 -0400, Nathan Sidwell wrote:
> Jan-Benedict,
> 
> > I haven't given it any additional manual testing so far. It's
> > pre-installation though. Maybe I'd just set WIND_BASE to some
> > arbitrary value, just to make xgcc pass it's initial start-up test
> > so
> > that it can continue with self-testing? Or shall we set some value
> > in gcc/Makefile.in for running the self-test?
> 
> As I recall, WIND_BASE is expected to point at a vxworks install to
> pick up 
> header files.  It is an error not to have it set (silently skipping
> it leads to 
> user confusion).
> 
> If that's irrelevant for this testing environment, then setting it to
> something 
> (probably just "", but safer might be 
> "/These.are.not.the.dirs.you.are.looking.for") should be fine.

Sorry about the breakage.

The error message appears to affect a few other targets within
gcc/Makefile.in.

For example:

$ make s-macro_list 
echo |  ./xgcc -B./ -B/usr/local/i686-wrs-vxworks/bin/ -isystem
/usr/local/i686-wrs-vxworks/include -isystem /usr/local/i686-wrs
-vxworks/sys-include -L/home/david/archive/huge/gcc-git-all
-configs/selftest-multi-mk/i686-wrs-vxworks/gcc/../ld -E -dM - | \
  sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
 -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
  sort -u > tmp-macro_list
xgcc: fatal error: environment variable ‘WIND_BASE’ not defined
compilation terminated.
/bin/sh /home/david/coding-3/gcc-git-unittests/src/gcc/../move-if
-change tmp-macro_list macro_list
cmp: EOF on tmp-macro_list
echo timestamp > s-macro_list


However the above issue doesn't fail the build:

$ echo $?
0

It can be trivially reproduced like this:

$ ./xgcc -B. -E -
xgcc: fatal error: environment variable ‘WIND_BASE’ not defined
compilation terminated.


It happens due to evaluating this spec function:
  "getenv(WIND_BASE /target/h)"
from this within gcc/config/vxworks.h:

/* Since we provide a default -isystem, expand -isystem on the command
   line early.  */
#undef VXWORKS_ADDITIONAL_CPP_SPEC
#define VXWORKS_ADDITIONAL_CPP_SPEC \
 "%{!nostdinc:  \
%{isystem*} -idirafter  \
%{mrtp: %:getenv(WIND_USR /h)   \
  ;:%:getenv(WIND_BASE /target/h)}}"


Hence it appears that passing "-nostdinc" as a param will avoid the
error:

$ echo | ./xgcc -B. -E - -nostdinc
# 1 ""
# 1 ""
# 1 ""
# 1 ""

$ echo $?
0

Presumably if you're explicitly building for vxworks you have a vxworks
install, so there is a meaningful value to set WIND_BASE to, whereas if
you don't have a vxworks install (and are merely building everything as
a smoketest), you presumably only want to build the "gcc" subdir, since
AFAIK you can't run then driver.

So there are at least 2 ways of fixing this:

(a) add "-nostdinc" when running the selftests i.e. to the invocations
of GCC_FOR_TARGET in the "s-selftest" and "selftest-gdb" clauses of
gcc/Makefile.in.
I've verified that this fixes the issue for --target=i686-wrs-vxworks.

(b) set WIND_BASE to a dummy value in contrib/config-list.mk (if not
already set) so that the vxworks targets are able to at least build all
of "gcc" without needing a vxworks install.


Thoughts?

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[Nathan Sidwell]

Jan-Benedict,


I haven't given it any additional manual testing so far. It's
pre-installation though. Maybe I'd just set WIND_BASE to some
arbitrary value, just to make xgcc pass it's initial start-up test so
that it can continue with self-testing? Or shall we set some value
in gcc/Makefile.in for running the self-test?


As I recall, WIND_BASE is expected to point at a vxworks install to pick up 
header files.  It is an error not to have it set (silently skipping it leads to 
user confusion).


If that's irrelevant for this testing environment, then setting it to something 
(probably just "", but safer might be 
"/These.are.not.the.dirs.you.are.looking.for") should be fine.


nathan

[BUILDROBOT] Selftest failed for i686-wrs-vxworks

[Jan-Benedict Glaw]

Hi Nathan!

The recent self-testing fails for i686-wrs-vxworks:

/home/jbglaw/build-configlist_mk/i686-wrs-vxworks/build-gcc/mk/i686-wrs-vxworks/./gcc/xgcc
 
-B/home/jbglaw/build-configlist_mk/i686-wrs-vxworks/build-gcc/mk/i686-wrs-vxworks/./gcc/
 -xc -S -c /dev/null -fself-test
xgcc: fatal error: environment variable ‘WIND_BASE’ not defined
compilation terminated.
Makefile:1877: recipe for target 's-selftest' failed
make[2]: *** [s-selftest] Error 1


That's straight out of config-list.mk, see eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=567929

I haven't given it any additional manual testing so far. It's
pre-installation though. Maybe I'd just set WIND_BASE to some
arbitrary value, just to make xgcc pass it's initial start-up test so
that it can continue with self-testing? Or shall we set some value
in gcc/Makefile.in for running the self-test?

MfG, JBG
 
-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: 17:44 <@uschebit> Evangelist ist doch ein Vertriebler
the second  :   für unverkäufliche Produkte, oder? (#korsett, 20120821)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

[David Edelsohn]

On Sat, Jun 18, 2016 at 9:56 AM, David Malcolm  wrote:
> On Sat, 2016-06-18 at 15:06 +0200, Jan-Benedict Glaw wrote:
>> Hi David, Segher, Aldy!
>>
>> Davids new selftest code found something for the rs6000-ibm-aix4.3
>> target, maybe you're interested:
>>
>> /home/jbglaw/src/toolchain/build/./gcc/xgcc
>> -B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c /dev/null -fself
>> -test
>> : internal compiler error: in altivec_init_builtins, at
>> config/rs6000/rs6000.c:16675
>> 0xe0ed04 altivec_init_builtins
>> ../../gcc/gcc/config/rs6000/rs6000.c:16675
>> 0xe0ed04 rs6000_init_builtins
>> ../../gcc/gcc/config/rs6000/rs6000.c:15935
>> 0x643c7e c_define_builtins
>> ../../gcc/gcc/c-family/c-common.c:5208
>> 0x643c7e c_common_nodes_and_builtins()
>> ../../gcc/gcc/c-family/c-common.c:5656
>> 0x590c49 c_init_decl_processing()
>> ../../gcc/gcc/c/c-decl.c:3934
>> 0x5dd7e8 c_objc_common_init()
>> ../../gcc/gcc/c/c-objc-common.c:58
>> 0x580cc1 lang_dependent_init
>> ../../gcc/gcc/toplev.c:1757
>> 0x580cc1 do_compile
>> ../../gcc/gcc/toplev.c:1975
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
>> make[1]: *** [s-selftest] Error 1
>>
>>
>>
>> See eg. build
>> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=572874
>> ,
>> which is as simple as .../configure --enable-languages=c,c++
>> --target=rs6000-ibm-aix4.3 --without-headers --disable-threads
>>
>
> I looks like PR target/71375 ("Failure on startup on rs6000-ibm
> -aix{4.3|5.1.0}"), which I believe is a pre-existing issue, and
> unrelated to -fself-test.

I fixed this, but we probably should remove AIX 4.3 and AIX 5.1 from
config-list.mk.  And we should add AIX 7.1.

- David

Re: [BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

[David Malcolm]

On Sat, 2016-06-18 at 15:06 +0200, Jan-Benedict Glaw wrote:
> Hi David, Segher, Aldy!
> 
> Davids new selftest code found something for the rs6000-ibm-aix4.3
> target, maybe you're interested:
> 
> /home/jbglaw/src/toolchain/build/./gcc/xgcc 
> -B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c /dev/null -fself
> -test
> : internal compiler error: in altivec_init_builtins, at
> config/rs6000/rs6000.c:16675
> 0xe0ed04 altivec_init_builtins
> ../../gcc/gcc/config/rs6000/rs6000.c:16675
> 0xe0ed04 rs6000_init_builtins
> ../../gcc/gcc/config/rs6000/rs6000.c:15935
> 0x643c7e c_define_builtins
> ../../gcc/gcc/c-family/c-common.c:5208
> 0x643c7e c_common_nodes_and_builtins()
> ../../gcc/gcc/c-family/c-common.c:5656
> 0x590c49 c_init_decl_processing()
> ../../gcc/gcc/c/c-decl.c:3934
> 0x5dd7e8 c_objc_common_init()
> ../../gcc/gcc/c/c-objc-common.c:58
> 0x580cc1 lang_dependent_init
> ../../gcc/gcc/toplev.c:1757
> 0x580cc1 do_compile
> ../../gcc/gcc/toplev.c:1975
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[1]: *** [s-selftest] Error 1
> 
> 
> 
> See eg. build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=572874
> ,
> which is as simple as .../configure --enable-languages=c,c++
> --target=rs6000-ibm-aix4.3 --without-headers --disable-threads
> 

I looks like PR target/71375 ("Failure on startup on rs6000-ibm
-aix{4.3|5.1.0}"), which I believe is a pre-existing issue, and
unrelated to -fself-test.

Dave

[BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

[Jan-Benedict Glaw]

Hi David, Segher, Aldy!

Davids new selftest code found something for the rs6000-ibm-aix4.3
target, maybe you're interested:

/home/jbglaw/src/toolchain/build/./gcc/xgcc 
-B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c /dev/null -fself-test
: internal compiler error: in altivec_init_builtins, at 
config/rs6000/rs6000.c:16675
0xe0ed04 altivec_init_builtins
../../gcc/gcc/config/rs6000/rs6000.c:16675
0xe0ed04 rs6000_init_builtins
../../gcc/gcc/config/rs6000/rs6000.c:15935
0x643c7e c_define_builtins
../../gcc/gcc/c-family/c-common.c:5208
0x643c7e c_common_nodes_and_builtins()
../../gcc/gcc/c-family/c-common.c:5656
0x590c49 c_init_decl_processing()
../../gcc/gcc/c/c-decl.c:3934
0x5dd7e8 c_objc_common_init()
../../gcc/gcc/c/c-objc-common.c:58
0x580cc1 lang_dependent_init
../../gcc/gcc/toplev.c:1757
0x580cc1 do_compile
../../gcc/gcc/toplev.c:1975
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [s-selftest] Error 1



See eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=572874,
which is as simple as .../configure --enable-languages=c,c++
--target=rs6000-ibm-aix4.3 --without-headers --disable-threads

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Alles sollte so einfach wie möglich gemacht sein.
the second  :  Aber nicht einfacher.  (Einstein)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] MPS430 build problem due to new enum

[Martin Liška]

On 06/13/2016 10:46 AM, Jan Hubicka wrote:
> Hmm, namespace conflict.  I guess renaming enum items to REASON_* should 
> solve it easily.
> Or we can add a namespace.
> 
> Martin, both variants of fix are pre-approved.
> Honza

OK, I've just installed (r237370) a patch that prefixes all enum values.

Martin

Re: [BUILDROBOT] MPS430 build problem due to new enum (was: [PATCH 2/2] Add edge predictions pruning)

[Jan Hubicka]

> Hi Martin,
> 
> On Thu, 2016-06-09 13:24:10 +0200, Martin Liška  wrote:
> > On 06/08/2016 02:41 PM, Jan Hubicka wrote:
> > > Adding hash for this prupose is bit of an overkill (there are
> > > definitly cheaper ways of solving so), but it will hardly affect compile
> > > time, so the pathc is OK.
> > 
> > Sending the final version where I added comments and I also changed
> > dump scanning to cover the new dump format.
> 
> I just noticed a build problem my Build Robot found
> (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=569576):
> 
> 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 -fno-common  -DHAVE_CONFIG_H -I. -I. 
> -I/scratch/4/jbglaw/regular/repos/gcc/gcc 
> -I/scratch/4/jbglaw/regular/repos/gcc/gcc/. 
> -I/scratch/4/jbglaw/regular/repos/gcc/gcc/../include 
> -I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libcpp/include  
> -I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libdecnumber 
> -I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libdecnumber/dpd 
> -I../libdecnumber -I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libbacktrace   
> -o predict.o -MT predict.o -MMD -MP -MF ./.deps/predict.TPo 
> /scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c
> /scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c:62:3: error: redeclaration 
> of ‘NONE’
>NONE,

Hmm, namespace conflict.  I guess renaming enum items to REASON_* should solve 
it easily.
Or we can add a namespace.

Martin, both variants of fix are pre-approved.
Honza

Re: [BUILDROBOT] MPS430 build problem due to new enum

[Martin Liška]

On 06/12/2016 01:55 PM, Jan-Benedict Glaw wrote:
> The new `NONE' from your enum clashes with a NONE used in a MSP430
> private enum.
> 
> MfG, JBG

Hi.

Thanks for having heads up, I've been testing following patch. The patch
survives with --target=msp430-elf.

Ready after it finishes?
Thanks,
Martin

>From 540c82e618ef6b38b69160c77533705d4e160895 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 13 Jun 2016 09:20:10 +0200
Subject: [PATCH] Change enum value to not to clash with a MSP430 private enum

gcc/ChangeLog:

2016-06-13  Martin Liska  

	* predict.c (enum predictor_reason): Rename NONE to VALID.
	(combine_predictions_for_insn): Likewise.
	(combine_predictions_for_bb): Likewise.
---
 gcc/predict.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/predict.c b/gcc/predict.c
index 0fa8c5b..e1d161a 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -59,7 +59,7 @@ along with GCC; see the file COPYING3.  If not see
 
 enum predictor_reason
 {
-  NONE,
+  VALID,
   IGNORED,
   SINGLE_EDGE_DUPLICATE,
   EDGE_PAIR_DUPLICATE
@@ -739,7 +739,7 @@ invert_br_probabilities (rtx insn)
 
 static void
 dump_prediction (FILE *file, enum br_predictor predictor, int probability,
-		 basic_block bb, enum predictor_reason reason = NONE,
+		 basic_block bb, enum predictor_reason reason = VALID,
 		 edge ep_edge = NULL)
 {
   edge e = ep_edge;
@@ -864,9 +864,9 @@ combine_predictions_for_insn (rtx_insn *insn, basic_block bb)
   else
 {
   dump_prediction (dump_file, PRED_DS_THEORY, combined_probability,
-		   bb, !first_match ? NONE : IGNORED);
+		   bb, !first_match ? VALID : IGNORED);
   dump_prediction (dump_file, PRED_FIRST_MATCH, best_probability,
-		   bb, first_match ? NONE: IGNORED);
+		   bb, first_match ? VALID : IGNORED);
 }
 
   if (first_match)
@@ -883,7 +883,7 @@ combine_predictions_for_insn (rtx_insn *insn, basic_block bb)
 
 	  dump_prediction (dump_file, predictor, probability, bb,
 			   (!first_match || best_predictor == predictor)
-			   ? NONE : IGNORED);
+			   ? VALID : IGNORED);
 	  *pnote = XEXP (*pnote, 1);
 	}
   else
@@ -1150,9 +1150,9 @@ combine_predictions_for_bb (basic_block bb, bool dry_run)
   else
 {
   dump_prediction (dump_file, PRED_DS_THEORY, combined_probability, bb,
-		   !first_match ? NONE : IGNORED);
+		   !first_match ? VALID : IGNORED);
   dump_prediction (dump_file, PRED_FIRST_MATCH, best_probability, bb,
-		   first_match ? NONE : IGNORED);
+		   first_match ? VALID : IGNORED);
 }
 
   if (first_match)
@@ -1168,7 +1168,7 @@ combine_predictions_for_bb (basic_block bb, bool dry_run)
 
 	  dump_prediction (dump_file, predictor, probability, bb,
 			   (!first_match || best_predictor == predictor)
-			   ? NONE : IGNORED, pred->ep_edge);
+			   ? VALID : IGNORED, pred->ep_edge);
 	}
 }
   clear_bb_predictions (bb);
-- 
2.8.3

[BUILDROBOT] MPS430 build problem due to new enum (was: [PATCH 2/2] Add edge predictions pruning)

[Jan-Benedict Glaw]

Hi Martin,

On Thu, 2016-06-09 13:24:10 +0200, Martin Liška  wrote:
> On 06/08/2016 02:41 PM, Jan Hubicka wrote:
> > Adding hash for this prupose is bit of an overkill (there are
> > definitly cheaper ways of solving so), but it will hardly affect compile
> > time, so the pathc is OK.
> 
> Sending the final version where I added comments and I also changed
> dump scanning to cover the new dump format.

I just noticed a build problem my Build Robot found
(http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=569576):

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 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/scratch/4/jbglaw/regular/repos/gcc/gcc 
-I/scratch/4/jbglaw/regular/repos/gcc/gcc/. 
-I/scratch/4/jbglaw/regular/repos/gcc/gcc/../include 
-I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libcpp/include  
-I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libdecnumber 
-I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/scratch/4/jbglaw/regular/repos/gcc/gcc/../libbacktrace   -o predict.o -MT 
predict.o -MMD -MP -MF ./.deps/predict.TPo 
/scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c
/scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c:62:3: error: redeclaration of 
‘NONE’
   NONE,
   ^
In file included from ./options.h:8:0,
 from ./tm.h:16,
 from /scratch/4/jbglaw/regular/repos/gcc/gcc/backend.h:28,
 from /scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c:33:
/scratch/4/jbglaw/regular/repos/gcc/gcc/config/msp430/msp430-opts.h:25:3: note: 
previous declaration ‘msp430_hwmult_types NONE’
   NONE,
   ^
/scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c:743:23: error: could not 
convert ‘NONE’ from ‘msp430_hwmult_types’ to ‘predictor_reason’
edge ep_edge = NULL)
   ^
/scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c: In function ‘void 
combine_predictions_for_insn(rtx_insn*, basic_block)’:
/scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c:863:32: error: cannot convert 
‘msp430_hwmult_types’ to ‘predictor_reason’ for argument ‘5’ to ‘void 
dump_prediction(FILE*, br_predictor, int, basic_block, predictor_reason, edge)’
combined_probability, bb);
^
/scratch/4/jbglaw/regular/repos/gcc/gcc/predict.c:867:36: warning: enumeral 
mismatch in conditional expression: ‘msp430_hwmult_types’ vs ‘predictor_reason’ 
[-Wenum-compare]
  bb, !first_match ? NONE : IGNORED);
^
[...]


The new `NONE' from your enum clashes with a NONE used in a MSP430
private enum.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: They that give up essential liberty to obtain temporary safety,
the second  : deserve neither liberty nor safety.  (Ben Franklin)


signature.asc
Description: Digital signature

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Moore, Catherine]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Thursday, December 17, 2015 1:06 PM
> To: Jan-Benedict Glaw
> Cc: Moore, Catherine; Denis Chertykov; Eric Christopher; Matthew Fortune;
> David Edelsohn; Alexandre Oliva; Kaz Kojima; Oleg Endo; Jonathan Wakely;
> gcc-patches
> Subject: Re: [BUILDROBOT] "error: null argument where non-null required"
> on multiple targets
> 
> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> > On Tue, 2015-12-15 10:43:58 -0700, Jeff Law  wrote:
> >> On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:
> >>> On Mon, 2015-12-14 18:54:28 +, Moore, Catherine
>  wrote:
> >>>> Is there an easy way to reproduce the MIPS problems that you
> >>>> reported?  I don't seem to be able to do it with a cross-compiler
> >>>> targeting mipsel-elf.
> >>>
> >>> What's your build compiler? For these builds, where it showed up,
> >>> I'm using a freshly compiles HEAD/master version. So basically,
> >>> compile a current GCC for your build machine:
> >> Right.  This is something that only shows up when using the trunk to
> >> build the crosses.
> >>
Thanks -- I have now reproduced the problem. 

config-list.mk and obsoleted configurations (was: [BUILDROBOT] "error: null argument where non-null required" on multiple targets)

[Jan-Benedict Glaw]

On Thu, 2015-12-17 11:05:42 -0700, Jeff Law  wrote:
> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> > Shall I bisect one of the cases anew, with the "Test value of
> > _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that
> > uncovered it, applied? Starting with some arbitrary old revision?
> Yes.  I'd really like to see config-list.mk working again.  The
> first step is always building a test the developers can easily work
> with.

Will do. Have a good starting point?

  Oh, there are some targets that were obsoleted today. I think the
OpenBSD3 and the two knetbsd configurations will need an
--enable-obsolete. I suggest this (untested) patch:

contrib/
2015-12-17  Jan-Benedict Glaw  

* config-list.mk (LIST): Add --enable-obsolete to recently obsoleted
targets x86_64-knetbsd-gnu, i686-knetbsd-gnu and i686-openbsd3.0 .

diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index 8d39e68..ab8060b 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2015-12-17  Jan-Benedict Glaw  
+
+   * config-list.mk (LIST): Add --enable-obsolete to recently obsoleted
+   targets x86_64-knetbsd-gnu, i686-knetbsd-gnu and i686-openbsd3.0 .
+
 2015-12-06  Tobias Burnus  
 
* download_prerequisites: Download ISL 0.15 instead of 0.14.
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index f0e39d6..0f15464 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -28,7 +28,8 @@ LIST = aarch64-elf aarch64-linux-gnu \
   hppa64-hpux11.0OPT-enable-sjlj-exceptions=yes hppa2.0-hpux11.9 \
   i686-pc-linux-gnu i686-apple-darwin i686-apple-darwin9 i686-apple-darwin10 \
   i486-freebsd4 i686-freebsd6 i686-kfreebsd-gnu \
-  i686-netbsdelf9 i686-knetbsd-gnu i686-openbsd i686-openbsd3.0 \
+  i686-netbsdelf9 i686-knetbsd-gnuOPT-enable-obsolete \
+  i686-openbsd i686-openbsd3.0OPT-enable-obsolete \
   i686-elf i686-kopensolaris-gnu i686-symbolics-gnu i686-pc-msdosdjgpp \
   i686-lynxos i686-nto-qnx \
   i686-rtems i686-solaris2.10 i686-wrs-vxworks \
@@ -74,7 +75,7 @@ LIST = aarch64-elf aarch64-linux-gnu \
   vax-netbsdelf vax-openbsd visium-elf x86_64-apple-darwin \
   x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \
-  x86_64-knetbsd-gnu x86_64-w64-mingw32 \
+  x86_64-knetbsd-gnuOPT-enable-obsolete x86_64-w64-mingw32 \
   x86_64-mingw32OPT-enable-sjlj-exceptions=yes xstormy16-elf xtensa-elf \
   xtensa-linux \
   i686-interix3OPT-enable-obsolete



MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: 23:53 <@jbglaw> So, ich kletter' jetzt mal ins Bett.
the second  : 23:57 <@jever2> .oO( kletter ..., hat er noch Gitter vorm Bett, 
wie früher meine Kinder?)
  00:00 <@jbglaw> jever2: *patsch*
  00:01 <@jever2> *aua*, wofür, Gedanken sind frei!
  00:02 <@jbglaw> Nee, freie Gedanken, die sind seit 1984 doch aus!
  00:03 <@jever2> 1984? ich bin erst seit 1985 verheiratet!


signature.asc
Description: Digital signature

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jeff Law]

On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:

On Tue, 2015-12-15 10:43:58 -0700, Jeff Law  wrote:

On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:

On Mon, 2015-12-14 18:54:28 +, Moore, Catherine 
 wrote:

avr-rtems   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
mipsel-elf  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
mipsisa64r2-sde-elf 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
mipsisa64sb1-elf
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
mips-rtems  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
powerpc-eabialtivec 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
powerpc-eabispe 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
powerpc-rtems   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
ppc-elf 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
sh-superh-elf   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077


Is there an easy way to reproduce the MIPS problems that you
reported?  I don't seem to be able to do it with a cross-compiler
targeting mipsel-elf.


What's your build compiler? For these builds, where it showed up, I'm
using a freshly compiles HEAD/master version. So basically, compile a
current GCC for your build machine:

Right.  This is something that only shows up when using the trunk to build
the crosses.

When I looked, I thought I bisected it to the delayed folding work.


Shall I bisect one of the cases anew, with the "Test value of
_GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that uncovered
it, applied? Starting with some arbitrary old revision?
Yes.  I'd really like to see config-list.mk working again.  The first 
step is always building a test the developers can easily work with.



jeff

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jan-Benedict Glaw]

On Tue, 2015-12-15 10:43:58 -0700, Jeff Law  wrote:
> On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:
> >On Mon, 2015-12-14 18:54:28 +, Moore, Catherine 
> > wrote:
> >>>avr-rtems  
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
> >>>mipsel-elf 
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
> >>>mipsisa64r2-sde-elf
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
> >>>mipsisa64sb1-elf   
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
> >>>mips-rtems 
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
> >>>powerpc-eabialtivec
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
> >>>powerpc-eabispe
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
> >>>powerpc-rtems  
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
> >>>ppc-elf
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
> >>>sh-superh-elf  
> >>>http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077
> >>
> >>Is there an easy way to reproduce the MIPS problems that you
> >>reported?  I don't seem to be able to do it with a cross-compiler
> >>targeting mipsel-elf.
> >
> >What's your build compiler? For these builds, where it showed up, I'm
> >using a freshly compiles HEAD/master version. So basically, compile a
> >current GCC for your build machine:
> Right.  This is something that only shows up when using the trunk to build
> the crosses.
> 
> When I looked, I thought I bisected it to the delayed folding work.

Shall I bisect one of the cases anew, with the "Test value of
_GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that uncovered
it, applied? Starting with some arbitrary old revision?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  GDB has a 'break' feature; why doesn't it have 'fix' too?
the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jeff Law]

On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:

On Mon, 2015-12-14 18:54:28 +, Moore, Catherine 
 wrote:

avr-rtems   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
mipsel-elf  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
mipsisa64r2-sde-elf 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
mipsisa64sb1-elf
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
mips-rtems  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
powerpc-eabialtivec 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
powerpc-eabispe 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
powerpc-rtems   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
ppc-elf 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
sh-superh-elf   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077


Is there an easy way to reproduce the MIPS problems that you
reported?  I don't seem to be able to do it with a cross-compiler
targeting mipsel-elf.


What's your build compiler? For these builds, where it showed up, I'm
using a freshly compiles HEAD/master version. So basically, compile a
current GCC for your build machine:
Right.  This is something that only shows up when using the trunk to 
build the crosses.


When I looked, I thought I bisected it to the delayed folding work.

jeff

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jan-Benedict Glaw]

On Mon, 2015-12-14 18:54:28 +, Moore, Catherine 
 wrote:
> > avr-rtems   
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
> > mipsel-elf  
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
> > mipsisa64r2-sde-elf 
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
> > mipsisa64sb1-elf
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
> > mips-rtems  
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
> > powerpc-eabialtivec 
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
> > powerpc-eabispe 
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
> > powerpc-rtems   
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
> > ppc-elf 
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
> > sh-superh-elf   
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077
> 
> Is there an easy way to reproduce the MIPS problems that you
> reported?  I don't seem to be able to do it with a cross-compiler
> targeting mipsel-elf.

What's your build compiler? For these builds, where it showed up, I'm
using a freshly compiles HEAD/master version. So basically, compile a
current GCC for your build machine:

.../configure --prefix=/tmp/foo --disable-multilib \
--enable-languages=all,ada,go
make
make install

...and then put that compiler into your $PATH and build a cross compiler:

.../configure --target=mipsel-elf --enable-werror-always \
--enable-languages=all,ada,go
make all-gcc

(This is how contrib/config-list.mk does its test builds, which is
what I'm calling.)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Alles sollte so einfach wie möglich gemacht sein.
the second  :  Aber nicht einfacher.  (Einstein)


signature.asc
Description: Digital signature

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Moore, Catherine]

> -Original Message-
> From: Jan-Benedict Glaw [mailto:jbg...@lug-owl.de]
> Sent: Sunday, December 06, 2015 4:49 PM
> To: Denis Chertykov; Moore, Catherine; Eric Christopher; Matthew Fortune;
> David Edelsohn; Alexandre Oliva; Kaz Kojima; Oleg Endo
> Cc: Jonathan Wakely; gcc-patches
> Subject: [BUILDROBOT] "error: null argument where non-null required" on
> multiple targets
> 
> Hi!
> 
> I'm not 100% sure, but I *think* that this patch
> 
>   2015-11-15  Jonathan Wakely  
> 
>   PR libstdc++/68353
>   * include/bits/basic_string.h: Test value of
> _GLIBCXX_USE_C99_WCHAR
>   not whether it is defined.
>   * include/ext/vstring.h: Likewise.
> 
> uncovered errors like this:
> 
> /---
> | g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -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. -Ic-family -I../../../gcc/gcc -
> I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -
> I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -
> I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -
> I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o c-family/c-common.o -
> MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo
> ../../../gcc/gcc/c-family/c-common.c
> | In file included from ../../../gcc/gcc/c-family/c-common.c:31:0:
> | ../../../gcc/gcc/c-family/c-common.c: In function ‘void
> c_common_nodes_and_builtins()’:
> | ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null
> required (argument 1) [-Werror=nonnull]
> |  ? get_identifier_with_length ((str), strlen (str))  \
> |  ^
> |
> | ../../../gcc/gcc/c-family/c-common.c:5501:22: note: in expansion of macro
> ‘get_identifier’
> |char32_type_node = get_identifier (CHAR32_TYPE);
> |   ^~
> |
> | cc1plus: all warnings being treated as errors
> | Makefile:1085: recipe for target 'c-family/c-common.o' failed
> \---
> 
> Shows up when using a newly build compiler to build the contrib/config-
> list.mk targets. So these targets probably need some small touch-ups.
> 
> avr-rtems http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478544
> mipsel-elfhttp://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478844
> mipsisa64r2-sde-elf   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478855
> mipsisa64sb1-elf  http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478865
> mips-rtemshttp://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478877
> powerpc-eabialtivec   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478922
> powerpc-eabispe   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478932
> powerpc-rtems http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478956
> ppc-elf   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478968
> sh-superh-elf http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=479077
> 

Is there an easy way to reproduce the MIPS problems that you reported?  I don't 
seem to be able to do it with a cross-compiler targeting mipsel-elf.
Thanks,
Catherine

Re: [BUILDROBOT] ./insn-flags.h:342:7: error: ‘operands’ was not declared in this scope

[Kaz Kojima]

Jan-Benedict Glaw  wrote:
> shle-linux breaks with:
> 
> 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 -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc 
> -I../../gcc/gcc/. -I../../gcc/gcc/../include 
> -I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber 
> -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../gcc/gcc/../libbacktrace   -o insn-opinit.o -MT insn-opinit.o -MMD -MP 
> -MF ./.deps/insn-opinit.TPo insn-opinit.c
> In file included from ./tm.h:60:0,
>  from ../../gcc/gcc/backend.h:28,
>  from insn-opinit.c:7:
> insn-opinit.c: In function ‘void init_all_optabs(target_optabs*)’:
> ./insn-flags.h:342:7: error: ‘operands’ was not declared in this scope
> && operands[1] == CONST1_RTX (SFmode))
>^
> insn-opinit.c:359:14: note: in expansion of macro ‘HAVE_rsqrtsf2’
>ena[137] = HAVE_rsqrtsf2;
>   ^
> make[2]: *** [insn-opinit.o] Error 1

I've just committed a fix for this as revision 231343.

Regards,
kaz

[BUILDROBOT] ./insn-flags.h:342:7: error: ‘operands’ was not declared in this scope (was: Add an rsqrt_optab and IFN_RSQRT internal function)

[Jan-Benedict Glaw]

On Thu, 2015-12-03 09:21:03 +, Richard Sandiford 
 wrote:
> All current uses of builtin_reciprocal convert 1.0/sqrt into rsqrt.
> This patch adds an rsqrt optab and associated internal function for
> that instead.  We can then pick up the vector forms of rsqrt automatically,
> fixing an AArch64 regression from my internal_fn patches.
[...]
> Two other ports define rsqrt patterns: sh and v850.  AFAICT these
> patterns aren't currently used, but I think the patch does what the
> authors of the patterns would have expected.  There's obviously some
> risk of fallout though.

shle-linux breaks with:

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 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o insn-opinit.o -MT 
insn-opinit.o -MMD -MP -MF ./.deps/insn-opinit.TPo insn-opinit.c
In file included from ./tm.h:60:0,
 from ../../gcc/gcc/backend.h:28,
 from insn-opinit.c:7:
insn-opinit.c: In function ‘void init_all_optabs(target_optabs*)’:
./insn-flags.h:342:7: error: ‘operands’ was not declared in this scope
&& operands[1] == CONST1_RTX (SFmode))
   ^
insn-opinit.c:359:14: note: in expansion of macro ‘HAVE_rsqrtsf2’
   ena[137] = HAVE_rsqrtsf2;
  ^
make[2]: *** [insn-opinit.o] Error 1




See eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479005 .

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:  Zensur im Internet? Nein danke!
  the second  :


signature.asc
Description: Digital signature

[BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jan-Benedict Glaw]

Hi!

I'm not 100% sure, but I *think* that this patch

2015-11-15  Jonathan Wakely  

PR libstdc++/68353
* include/bits/basic_string.h: Test value of 
_GLIBCXX_USE_C99_WCHAR
not whether it is defined.
* include/ext/vstring.h: Likewise.

uncovered errors like this:

/---
| g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -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. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace   -o c-family/c-common.o -MT 
c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo 
../../../gcc/gcc/c-family/c-common.c
| In file included from ../../../gcc/gcc/c-family/c-common.c:31:0:
| ../../../gcc/gcc/c-family/c-common.c: In function ‘void 
c_common_nodes_and_builtins()’:
| ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null 
required (argument 1) [-Werror=nonnull]
|  ? get_identifier_with_length ((str), strlen (str))  \
|  ^
| 
| ../../../gcc/gcc/c-family/c-common.c:5501:22: note: in expansion of macro 
‘get_identifier’
|char32_type_node = get_identifier (CHAR32_TYPE);
|   ^~
| 
| cc1plus: all warnings being treated as errors
| Makefile:1085: recipe for target 'c-family/c-common.o' failed
\---

Shows up when using a newly build compiler to build the
contrib/config-list.mk targets. So these targets probably need some
small touch-ups.

avr-rtems   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
mipsel-elf  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
mipsisa64r2-sde-elf 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
mipsisa64sb1-elf
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
mips-rtems  
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
powerpc-eabialtivec 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
powerpc-eabispe 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
powerpc-rtems   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
ppc-elf 
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
sh-superh-elf   
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Don't believe in miracles: Rely on them!
 the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Bootstrap broken in Ada

[Jan Hubicka]

> On 10/11/2015 02:58 PM, Jan-Benedict Glaw wrote:
> >On Thu, 2015-10-08 09:37:03 -0400, Andrew MacLeod  
> >wrote:
> >[...]
> >>Heres the patch for reordered headers.  Building as we speak.  Hard to fully
> >>verify since Ada doesn't seem to bootstrap on trunk at the moment:
> >>
> >>+===GNAT BUG DETECTED==+
> >>| 6.0.0 20151008 (experimental) (x86_64-pc-linux-gnu) GCC error:   |
> >>| in gen_lowpart_common, at emit-rtl.c:1399|
> >>| Error detected around s-regpat.adb:1029:22   |
> >>
> >><...>
> >>raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
> >>../gcc-interface/Makefile:311: recipe for target 's-regpat.o' failed
> >
> >Bulid log (native build on gcc76.fsffrance.org) can be found at
> >http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=4292383
> >for build
> >http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=472655 .
> >
> >So it's probably one of these two commits:
> >
> > r228586 = 54ac7405ce75c141dae33532d491d5793fb583e3
> > Jan Hubicka  
> > Do not use TYPE_CANONICAL in useless_type_conversion
> It's one of Jan's patches.  I've got them reverted locally and Ada
> builds fine.

A proposed patch is https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01011.html

Honza
> 
> jeff

Re: [BUILDROBOT] Bootstrap broken in Ada

[Jeff Law]

On 10/11/2015 02:58 PM, Jan-Benedict Glaw wrote:

On Thu, 2015-10-08 09:37:03 -0400, Andrew MacLeod  wrote:
[...]

Heres the patch for reordered headers.  Building as we speak.  Hard to fully
verify since Ada doesn't seem to bootstrap on trunk at the moment:

+===GNAT BUG DETECTED==+
| 6.0.0 20151008 (experimental) (x86_64-pc-linux-gnu) GCC error:   |
| in gen_lowpart_common, at emit-rtl.c:1399|
| Error detected around s-regpat.adb:1029:22   |

<...>
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
../gcc-interface/Makefile:311: recipe for target 's-regpat.o' failed


Bulid log (native build on gcc76.fsffrance.org) can be found at
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=4292383
for build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=472655 .

So it's probably one of these two commits:

r228586 = 54ac7405ce75c141dae33532d491d5793fb583e3
Jan Hubicka  
Do not use TYPE_CANONICAL in useless_type_conversion
It's one of Jan's patches.  I've got them reverted locally and Ada 
builds fine.


jeff

[BUILDROBOT] Bootstrap broken in Ada (was: [patch] header file re-ordering.)

[Jan-Benedict Glaw]

On Thu, 2015-10-08 09:37:03 -0400, Andrew MacLeod  wrote:
[...]
> Heres the patch for reordered headers.  Building as we speak.  Hard to fully
> verify since Ada doesn't seem to bootstrap on trunk at the moment:
> 
> +===GNAT BUG DETECTED==+
> | 6.0.0 20151008 (experimental) (x86_64-pc-linux-gnu) GCC error:   |
> | in gen_lowpart_common, at emit-rtl.c:1399|
> | Error detected around s-regpat.adb:1029:22   |
> 
> <...>
> raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
> ../gcc-interface/Makefile:311: recipe for target 's-regpat.o' failed

Bulid log (native build on gcc76.fsffrance.org) can be found at
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=4292383
for build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=472655 .

So it's probably one of these two commits:

r228586 = 54ac7405ce75c141dae33532d491d5793fb583e3
Jan Hubicka  
Do not use TYPE_CANONICAL in useless_type_conversion

r228585 = 5b4ada2a11ab19842d77296fc4b75971ddb07434
Jeff Law 
[PATCH] Improve DOM's optimization of control statements

Haven't looked at the patches or what they're doing, but maybe you two
instantly recognize the issue?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:   Wenn ich wach bin, träume ich.
  the second  :


signature.asc
Description: Digital signature

[commit, spu] Re: [BUILDROBOT] spu: left shift of negative value

[Ulrich Weigand]

Jan-Benedict Glaw wrote:

> I just noticed that (for config_list.mk builds), current GCC errors
> out at spu.c, see eg. build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=3D469639 :
> 
> g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-excep=
> tions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrit=
> e-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -peda=
> ntic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -f=
> no-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. =
> -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/c=
> farm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../=
> libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o =
> spu.o -MT spu.o -MMD -MP -MF ./.deps/spu.TPo ../../../gcc/gcc/config/spu/sp=
> u.c
> ../../../gcc/gcc/config/spu/spu.c: In function =E2=80=98void spu_expand_ins=
> v(rtx_def**)=E2=80=99:
> ../../../gcc/gcc/config/spu/spu.c:530:46: error: left shift of negative val=
> ue [-Werror=3Dshift-negative-value]
>maskbits =3D (-1ll << (32 - width - start));
>   ^
> ../../../gcc/gcc/config/spu/spu.c:536:46: error: left shift of negative val=
> ue [-Werror=3Dshift-negative-value]
>maskbits =3D (-1ll << (64 - width - start));
>   ^
> cc1plus: all warnings being treated as errors
> Makefile:2092: recipe for target 'spu.o' failed
> make[2]: *** [spu.o] Error 1
> make[2]: Leaving directory '/home/jbglaw/build-configlist_mk/spu-elf/build-=
> gcc/mk/spu-elf/gcc'

I've now checked in the following fix.

Thanks,
Ulrich


ChangeLog:

* config/spu/spu.c (spu_expand_insv): Avoid undefined behavior.

Index: gcc/config/spu/spu.c
===
*** gcc/config/spu/spu.c(revision 227968)
--- gcc/config/spu/spu.c(working copy)
*** spu_expand_insv (rtx ops[])
*** 472,478 
  {
HOST_WIDE_INT width = INTVAL (ops[1]);
HOST_WIDE_INT start = INTVAL (ops[2]);
!   HOST_WIDE_INT maskbits;
machine_mode dst_mode;
rtx dst = ops[0], src = ops[3];
int dst_size;
--- 472,478 
  {
HOST_WIDE_INT width = INTVAL (ops[1]);
HOST_WIDE_INT start = INTVAL (ops[2]);
!   unsigned HOST_WIDE_INT maskbits;
machine_mode dst_mode;
rtx dst = ops[0], src = ops[3];
int dst_size;
*** spu_expand_insv (rtx ops[])
*** 527,541 
switch (dst_size)
  {
  case 32:
!   maskbits = (-1ll << (32 - width - start));
if (start)
!   maskbits += (1ll << (32 - start));
emit_move_insn (mask, GEN_INT (maskbits));
break;
  case 64:
!   maskbits = (-1ll << (64 - width - start));
if (start)
!   maskbits += (1ll << (64 - start));
emit_move_insn (mask, GEN_INT (maskbits));
break;
  case 128:
--- 527,541 
switch (dst_size)
  {
  case 32:
!   maskbits = (~(unsigned HOST_WIDE_INT)0 << (32 - width - start));
if (start)
!   maskbits += ((unsigned HOST_WIDE_INT)1 << (32 - start));
emit_move_insn (mask, GEN_INT (maskbits));
break;
  case 64:
!   maskbits = (~(unsigned HOST_WIDE_INT)0 << (64 - width - start));
if (start)
!   maskbits += ((unsigned HOST_WIDE_INT)1 << (64 - start));
emit_move_insn (mask, GEN_INT (maskbits));
break;
  case 128:


-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: [BUILDROBOT] Go runtime: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe

[Jeff Law]

On 08/03/2015 08:48 AM, Martin Sebor wrote:

On 08/03/2015 05:55 AM, Jan-Benedict Glaw wrote:

On Sun, 2015-08-02 17:15:27 -0600, Martin Sebor  wrote:

OK for the trunk.  Sorry for the delay.


Thank you. Committed in revision 226480.


...und breaks native builds. When doing builds using config-list.mk, I
first build a GCC for the build machine, then re-build a
cross-configured GCC with that.


I don't know if pragma GCC diagnostic is valid in Go (still waiting
for my build to finish to confirm) but disabling the warning in
cases where the calls are known to be safe should fix the compilation
error.
My understanding is the runtime is shared across gcc-go and golang.  So 
the push/pop diagnostics may not be appropriate.


Ian Taylor should have the final say about the best way forward.

Jeff

Re: [BUILDROBOT] Go runtime: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe

[Martin Sebor]

On 08/03/2015 05:55 AM, Jan-Benedict Glaw wrote:

On Sun, 2015-08-02 17:15:27 -0600, Martin Sebor  wrote:

OK for the trunk.  Sorry for the delay.


Thank you. Committed in revision 226480.


...und breaks native builds. When doing builds using config-list.mk, I
first build a GCC for the build machine, then re-build a
cross-configured GCC with that.


I don't know if pragma GCC diagnostic is valid in Go (still waiting
for my build to finish to confirm) but disabling the warning in
cases where the calls are known to be safe should fix the compilation
error.

Index: runtime/mprof.goc
===
--- runtime/mprof.goc(revision 226505)
+++ runtime/mprof.goc(working copy)
@@ -404,10 +404,15 @@
 func Stack(b Slice, all bool) (n int) {
 byte *pc, *sp;
 bool enablegc;
-
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wframe-address"
+
 sp = runtime_getcallersp(&b);
 pc = (byte*)(uintptr)runtime_getcallerpc(&b);

+#pragma GCC diagnostic pop
+
 if(all) {
 runtime_semacquire(&runtime_worldsema, false);
 runtime_m()->gcing = 1;

Martin



   While building GCC targeting the build=host machine, I get ie:

http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=459572

/bin/bash ./libtool --tag=CC   --mode=compile 
/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/build-gcc/native-compiler-build/./gcc/xgcc
 
-B/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/build-gcc/native-compiler-build/./gcc/
 
-B/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/bin/
 
-B/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/lib/
 -isystem 
/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/include
 -isystem 
/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I/home/jbglaw/repos-configlist_mk/gcc/libgo  -I 
/home/jbglaw/repos-configlist_mk/gcc/libgo/runtime 
-I/home/jbglaw/repos-configlist_mk/gcc/libgo/../libffi/include 
-I../libffi/include -pthread  -fexceptions -fnon-call-exceptions 
-fplan9-extensions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual 
-Werror -minline-all-stringops -D_GNU_SOURCE -D_LAR

GEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I 
/home/jbglaw/repos-configlist_mk/gcc/libgo/../libgcc -I 
/home/jbglaw/repos-configlist_mk/gcc/libgo/../libbacktrace -I ../../gcc/include 
-g -O2 -MT mprof.lo -MD -MP -MF .deps/mprof.Tpo -c -o mprof.lo mprof.c

libtool: compile:  
/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/build-gcc/native-compiler-build/./gcc/xgcc
 
-B/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/build-gcc/native-compiler-build/./gcc/
 
-B/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/bin/
 
-B/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/lib/
 -isystem 
/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/include
 -isystem 
/home/jbglaw/build-configlist_mk/rs6000-ibm-aix5.1.0/_install_/x86_64-pc-linux-gnu/sys-include
 -DHAVE_CONFIG_H -I. -I/home/jbglaw/repos-configlist_mk/gcc/libgo -I 
/home/jbglaw/repos-configlist_mk/gcc/libgo/runtime 
-I/home/jbglaw/repos-configlist_mk/gcc/libgo/../libffi/include 
-I../libffi/include -pthread -fexceptions -fnon-call-exceptions 
-fplan9-extensions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual 
-Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BIT

S=64 -I /home/jbglaw/repos-configlist_mk/gcc/libgo/../libgcc -I 
/home/jbglaw/repos-configlist_mk/gcc/libgo/../libbacktrace -I ../../gcc/include 
-g -O2 -MT mprof.lo -MD -MP -MF .deps/mprof.Tpo -c mprof.c  -fPIC -DPIC -o 
.libs/mprof.o

/home/jbglaw/repos-configlist_mk/gcc/libgo/runtime/mprof.goc: In function 
‘runtime_Stack’:
/home/jbglaw/repos-configlist_mk/gcc/libgo/runtime/mprof.goc:408:5: error: 
calling ‘__builtin_frame_address’ with a nonzero argument is unsafe 
[-Werror=frame-address]
   sp = runtime_getcallersp(&b);
  ^
cc1: all warnings being treated as errors
Makefile:2613: recipe for target 'mprof.lo' failed
make[4]: *** [mprof.lo] Error 1



Seems Go's runtime uses that feature.

MfG, JBG

Re: [BUILDROBOT]

[Andreas Krebbel]

On 06/05/2015 01:04 AM, Jan-Benedict Glaw wrote:
> Hi Andreas,
> 
> On Mon, 2015-05-11 15:23:33 +0200, Andreas Krebbel 
>  wrote:
>> gcc/
>>  * config/s390/constraints.md (j00, jm1, jxx, jyy, v): New
>>  constraints.
>>  * config/s390/predicates.md (const0_operand, constm1_operand)
>>  (constable_operand): Accept vector operands.
>>  * config/s390/s390-modes.def: Add supported vector modes.
>>  * config/s390/s390-protos.h (s390_cannot_change_mode_class)
> [...]
> 
> Starting with this patch, it seems my buildrobot won't be able to
> build a s390{,x}-linux compiler:
> 
> g++   -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 -fno-common  
> -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc   
> -o build/genattrtab \
> build/genattrtab.o build/rtl.o build/read-rtl.o build/ggc-none.o 
> build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o 
> build/hash-table.o build/read-md.o build/errors.o 
> ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
> build/genattrtab /home/jbglaw/repos/gcc/gcc/common.md 
> /home/jbglaw/repos/gcc/gcc/config/s390/s390.md insn-conditions.md \
> -Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-latencytab.c
> genattrtab: invalid alternative specified for pattern number 1015
> Makefile:2167: recipe for target 's-attrtab' failed
> make[1]: *** [s-attrtab] Error 1
> make[1]: Leaving directory '/home/jbglaw/build/s390x-linux/build-gcc/gcc'
> Makefile:4119: recipe for target 'all-gcc' failed
> make: *** [all-gcc] Error 2
> 
> The above error is taken from this build:
> 
>   http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=444690

This has been reported by Jakub already. He also proposed a fix in his email:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00012.html

Bye,

-Andreas-

Re: [BUILDROBOT] arc-elf: match_code "REG" matches nothing

[Richard Sandiford]

Jan-Benedict Glaw  writes:
> On Fri, 2015-05-22 16:42:44 +0100, Richard Sandiford
>  wrote:
>> This patch adjusts the fix for PR target/65689 along the lines suggested
>> in https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01559.html.  The idea
>> is to reuse the existing gensupport.c routine to work out the codes
>> accepted by constraints.
>> 
>> I'd originally done this with an eye to using compute_test_codes for
>> the problem that Andreas found on s390.  I don't think it's going to
>> be useful for that after all, but it seems worth having for its on sake.
>> 
>> Bootstrapped & regression-tested on x86_64-linux-gnu.  OK to install?
>
> I'm also getting fallout for arc-elf, see eg. build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=442948

Sorry, think this message must have been caught by a filter so it didn't
reach my inbox.

Tested on mmix and arc-elf and applied as obvious.

Thanks,
Richard


gcc/
* config/arc/constraints.md: Use lower-case names in match_code.
* config/mmix/constraints.md: Likewise.

Index: gcc/config/arc/constraints.md
===
--- gcc/config/arc/constraints.md   2015-06-01 21:07:51.418630361 +0100
+++ gcc/config/arc/constraints.md   2015-06-01 21:07:51.571631855 +0100
@@ -335,7 +335,7 @@ (define_constraint "Rcq"
Cryptic q - for short insn generation while not affecting register 
allocation
Registers usable in ARCompact 16-bit instructions: @code{r0}-@code{r3},
@code{r12}-@code{r15}"
-  (and (match_code "REG")
+  (and (match_code "reg")
(match_test "TARGET_Rcq
&& !arc_ccfsm_cond_exec_p ()
&& IN_RANGE (REGNO (op) ^ 4, 4, 11)")))
@@ -347,7 +347,7 @@ (define_constraint "Rcq"
 (define_constraint "Rcw"
   "@internal
Cryptic w - for use in early alternatives with matching constraint"
-  (and (match_code "REG")
+  (and (match_code "reg")
(match_test
"TARGET_Rcw
 && REGNO (op) < FIRST_PSEUDO_REGISTER
@@ -357,7 +357,7 @@ (define_constraint "Rcw"
 (define_constraint "Rcr"
   "@internal
Cryptic r - for use in early alternatives with matching constraint"
-  (and (match_code "REG")
+  (and (match_code "reg")
(match_test
"TARGET_Rcw
 && REGNO (op) < FIRST_PSEUDO_REGISTER
@@ -367,13 +367,13 @@ (define_constraint "Rcr"
 (define_constraint "Rcb"
   "@internal
Stack Pointer register @code{r28} - do not reload into its class"
-  (and (match_code "REG")
+  (and (match_code "reg")
(match_test "REGNO (op) == 28")))
 
 (define_constraint "Rck"
   "@internal
blink (usful for push_s / pop_s)"
-  (and (match_code "REG")
+  (and (match_code "reg")
(match_test "REGNO (op) == 31")))
 
 (define_constraint "Rs5"
@@ -381,7 +381,7 @@ (define_constraint "Rs5"
sibcall register - only allow one of the five available 16 bit isnsn.
Registers usable in ARCompact 16-bit instructions: @code{r0}-@code{r3},
@code{r12}"
-  (and (match_code "REG")
+  (and (match_code "reg")
(match_test "!arc_ccfsm_cond_exec_p ()")
(ior (match_test "(unsigned) REGNO (op) <= 3")
(match_test "REGNO (op) == 12"
@@ -389,7 +389,7 @@ (define_constraint "Rs5"
 (define_constraint "Rcc"
   "@internal
   Condition Codes"
-  (and (match_code "REG") (match_test "cc_register (op, VOIDmode)")))
+  (and (match_code "reg") (match_test "cc_register (op, VOIDmode)")))
 
 
 (define_constraint "Q"
Index: gcc/config/mmix/constraints.md
===
--- gcc/config/mmix/constraints.md  2015-06-01 21:07:51.418630361 +0100
+++ gcc/config/mmix/constraints.md  2015-06-01 21:07:51.572631864 +0100
@@ -89,8 +89,8 @@ (define_constraint "R"
   (and (not (match_code "const_int,const_double"))
(match_test "mmix_constant_address_p (op)")
(ior (match_test "!TARGET_BASE_ADDRESSES")
-   (match_code "LABEL_REF")
-   (and (match_code "SYMBOL_REF")
+   (match_code "label_ref")
+   (and (match_code "symbol_ref")
 (match_test "SYMBOL_REF_FLAG (op)")
 
 ;; FIXME: L (or S) is redundant.

Re: [BUILDROBOT] RFA: RL78: Add support for G13 and G14 multiply and divide

[Nicholas Clifton]

Hi Jan-Benedict.


../../../gcc/gcc/config/rl78/rl78.c:390:14: error: enumeration value ‘MUL_RL78’ 
not handled in switch [-Werror=switch]
switch (rl78_mul_type)



../../../gcc/gcc/config/rl78/rl78.c:4649:34: error: unused parameter ‘x’ 
[-Werror=unused-parameter]
  rl78_preferred_reload_class (rtx x, reg_class_t rclass)


These are now fixed.

Cheers
  Nick

Re: [BUILDROBOT] tilepro-linux/tilegx-linux fallout from flattening

[Prathamesh Kulkarni]

On 12 January 2015 at 11:19, Michael Collison
 wrote:
> The issue is that tilegx includes expr.h which includes tree-core.h. A
> simple solution is to include "symtab.h" before "expr.h" in tilegx.c. The
> port has a unrelated link error after this change.
Yes, I am seeing this link error after building expr.h too -;(
tmp/ccQsq9tJ.o: In function `main':
gen-mul-tables.cc:(.text.startup+0x3d0): undefined reference to
`std::_Rb_tree_increment(std::_Rb_tree_node_base*)'
/tmp/ccQsq9tJ.o:(.eh_frame+0x44f): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
>
> The second possiblity is to resolve this using Prathmesh latest patch
> (submitted today) for flattening expr.h which removes the dependency on
> tree-core.h. Thoughts?
I retained tree-core.h in expr.h, so I guess flattening won't remove
the dependency on tree-core.h ?
>
> On 01/11/2015 08:36 PM, Jan-Benedict Glaw wrote:
>>
>> On Sat, 2015-01-10 01:50:42 +0530, Prathamesh Kulkarni
>>  wrote:
>>>
>>> On 9 January 2015 at 16:21, Richard Biener 
>>> wrote:

 On Fri, Jan 9, 2015 at 10:39 AM, Michael Collison
  wrote:
>
> This patch flattens tree.h and tree-core.h. This is a revised
> patch that does not include tree-core.h as a result of
> flattening.
>
> Version 3 of the patch adds the header files removed from
> tree-core.h to gcc-plugin.h in order to allow ggc-common.c to
> compile. This is a recent issue seen on trunk.
>>
>> [...]
>>>
>>> Committed as r219402 on behalf of Michael.
>>
>> Great work! Almost no fallout.
>>
>> Though I see some fallout for tilepro-linux, see eg. these builds:
>> tilegx:
>> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=396528
>> tilepro:
>> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=397033
>>
>> [...]
>> g++ -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
>> -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc
>> -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include
>> -I/home/jbglaw/repos/gcc/gcc/../libcpp/include
>> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber
>> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
>> -I/home/jbglaw/repos/gcc/gcc/../libbacktrace   -o tilepro.o -MT tilepro.o
>> -MMD -MP -MF ./.deps/tilepro.TPo
>> /home/jbglaw/repos/gcc/gcc/config/tilepro/tilepro.c
>> In file included from /home/jbglaw/repos/gcc/gcc/expr.h:38:0,
>>   from
>> /home/jbglaw/repos/gcc/gcc/config/tilepro/tilepro.c:31:
>> /home/jbglaw/repos/gcc/gcc/tree-core.h:1139:24: error: field ‘id’ has
>> incomplete type
>> make[1]: *** [tilepro.o] Error 1
>>
>>
>> #include "symtab.h" is there, so probably too late? Fails for both,
>> tilepro and tilegx.
>>
>> MfG, JBG
>>
>
> --
> Michael Collison
> Linaro Toolchain Working Group
> michael.colli...@linaro.org
>

Re: [BUILDROBOT] tilepro-linux/tilegx-linux fallout from flattening

[Michael Collison]

The issue is that tilegx includes expr.h which includes tree-core.h. A 
simple solution is to include "symtab.h" before "expr.h" in tilegx.c. 
The port has a unrelated link error after this change.


The second possiblity is to resolve this using Prathmesh latest patch 
(submitted today) for flattening expr.h which removes the dependency on 
tree-core.h. Thoughts?


On 01/11/2015 08:36 PM, Jan-Benedict Glaw wrote:

On Sat, 2015-01-10 01:50:42 +0530, Prathamesh Kulkarni 
 wrote:

On 9 January 2015 at 16:21, Richard Biener  wrote:

On Fri, Jan 9, 2015 at 10:39 AM, Michael Collison  
wrote:

This patch flattens tree.h and tree-core.h. This is a revised
patch that does not include tree-core.h as a result of
flattening.

Version 3 of the patch adds the header files removed from
tree-core.h to gcc-plugin.h in order to allow ggc-common.c to
compile. This is a recent issue seen on trunk.

[...]

Committed as r219402 on behalf of Michael.

Great work! Almost no fallout.

Though I see some fallout for tilepro-linux, see eg. these builds:
tilegx:  http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=396528
tilepro: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=397033

[...]
g++ -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 -fno-common  
-DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
-I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace   -o tilepro.o -MT tilepro.o -MMD 
-MP -MF ./.deps/tilepro.TPo /home/jbglaw/repos/gcc/gcc/config/tilepro/tilepro.c
In file included from /home/jbglaw/repos/gcc/gcc/expr.h:38:0,
  from /home/jbglaw/repos/gcc/gcc/config/tilepro/tilepro.c:31:
/home/jbglaw/repos/gcc/gcc/tree-core.h:1139:24: error: field ‘id’ has 
incomplete type
make[1]: *** [tilepro.o] Error 1


#include "symtab.h" is there, so probably too late? Fails for both, tilepro and 
tilegx.

MfG, JBG



--
Michael Collison
Linaro Toolchain Working Group
michael.colli...@linaro.org

[BUILDROBOT] tilepro-linux/tilegx-linux fallout from flattening (was: [PATCH] Flatten tree.h and tree-core.h (Version 3))

[Jan-Benedict Glaw]

On Sat, 2015-01-10 01:50:42 +0530, Prathamesh Kulkarni 
 wrote:
> On 9 January 2015 at 16:21, Richard Biener  wrote:
> > On Fri, Jan 9, 2015 at 10:39 AM, Michael Collison 
> >  wrote:
> > > This patch flattens tree.h and tree-core.h. This is a revised
> > > patch that does not include tree-core.h as a result of
> > > flattening.
> > >
> > > Version 3 of the patch adds the header files removed from
> > > tree-core.h to gcc-plugin.h in order to allow ggc-common.c to
> > > compile. This is a recent issue seen on trunk.
[...]
> Committed as r219402 on behalf of Michael.

Great work! Almost no fallout.

Though I see some fallout for tilepro-linux, see eg. these builds:
tilegx:  http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=396528
tilepro: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=397033

[...]
g++ -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 -fno-common  
-DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
-I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace   -o tilepro.o -MT tilepro.o -MMD 
-MP -MF ./.deps/tilepro.TPo /home/jbglaw/repos/gcc/gcc/config/tilepro/tilepro.c
In file included from /home/jbglaw/repos/gcc/gcc/expr.h:38:0,
 from /home/jbglaw/repos/gcc/gcc/config/tilepro/tilepro.c:31:
/home/jbglaw/repos/gcc/gcc/tree-core.h:1139:24: error: field ‘id’ has 
incomplete type
make[1]: *** [tilepro.o] Error 1


#include "symtab.h" is there, so probably too late? Fails for both, tilepro and 
tilegx.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:Don't believe in miracles: Rely on them!
 the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT, PATCH] config-list.mk: Extract target name correctly

[Jeff Law]

On 12/29/14 13:02, Jan-Benedict Glaw wrote:

Hi!

With my last change, `sed' is used to cut out the target name from a listed
target. Since there may be additional OPTions encoded in the "target", I tried
to get only the first submatch before an `OPT'. However, `sed' uses longest
match, so I'm re-writing this using awk.

   If anybody is like using `gawk' or anything different, please feel free to
drop another patch. Since this is usually called by hand or by robots under
review, I don't see much of a problem here.

2014-12-29  Jan-Benedict Glaw  

contrib/
* config-list.mk: Use shortest match for OPT to find the actual
target name.

OK.

Jeff

[BUILDROBOT, PATCH] config-list.mk: Extract target name correctly

[Jan-Benedict Glaw]

Hi!

With my last change, `sed' is used to cut out the target name from a listed
target. Since there may be additional OPTions encoded in the "target", I tried
to get only the first submatch before an `OPT'. However, `sed' uses longest
match, so I'm re-writing this using awk.

  If anybody is like using `gawk' or anything different, please feel free to
drop another patch. Since this is usually called by hand or by robots under
review, I don't see much of a problem here.

2014-12-29  Jan-Benedict Glaw  

contrib/
   * config-list.mk: Use shortest match for OPT to find the actual
   target name.
---
 contrib/ChangeLog  | 5 +
 contrib/config-list.mk | 3 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index f2d21db..d49f3e2 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2014-12-29  Jan-Benedict Glaw  
+
+   * config-list.mk: Use shortest match for OPT to find the actual
+   target name.
+
 2014-12-17  Sergio Durigan Junior  
 
* dg-extract-results.sh: Use --text with grep to avoid issues with
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 16900e1..db2bad0 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -97,8 +97,7 @@ $(LIST): make-log-dir
-mkdir $@
(   
\
cd $@ &&
\
-   echo $@ &&  
\
-   TGT=`echo $@ | sed -e 's/^\(.*\)OPT.*$$/\1/'` &&
\
+   TGT=`echo $@ | awk 'BEGIN { FS = "OPT" }; { print $$1 }'` &&
\
TGT=`../../gcc/config.sub $$TGT` && 
\
case $$TGT in   
\
*-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*)  
\
-- 
1.8.3.2



signature.asc
Description: Digital signature

Re: [BUILDROBOT, PATCH] MSP430: Fix unused arg warning

[Jan-Benedict Glaw]

Hi Nick,

On Wed, 2014-12-17 17:05:09 +, Nicholas Clifton  wrote:
> > 2014-12-17  Jan-Benedict Glaw  
> >
> > * config/msp430/msp430.c (msp430_asm_output_addr_const_extra): Fix
> > unused argument warning.
> 
> Approved - please apply.

Thanks. Committed as r218828.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: They that give up essential liberty to obtain temporary safety,
the second  : deserve neither liberty nor safety.  (Ben Franklin)


signature.asc
Description: Digital signature

Re: [BUILDROBOT, PATCH] MSP430: Fix unused arg warning

[Nicholas Clifton]

Hi Jan-Benedict,


2014-12-17  Jan-Benedict Glaw  

* config/msp430/msp430.c (msp430_asm_output_addr_const_extra): Fix
unused argument warning.


Approved - please apply.

Cheers
  Nick

[BUILDROBOT, PATCH] MSP430: Fix unused arg warning

[Jan-Benedict Glaw]

Hi!

The build robot found this:

g++ -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../../../gcc/gcc -I../../../gcc/gcc/. 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace   -o msp430.o -MT msp430.o -MMD -MP -MF 
./.deps/msp430.TPo ../../../gcc/gcc/config/msp430/msp430.c
../../../gcc/gcc/config/msp430/msp430.c:979:43: error: unused parameter ‘file’ 
[-Werror=unused-parameter]
 msp430_asm_output_addr_const_extra (FILE *file, rtx x)
   ^
cc1plus: all warnings being treated as errors
make[2]: *** [msp430.o] Error 1

(See for example this build:
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=384666)


Ok for this one?


2014-12-17  Jan-Benedict Glaw  

* config/msp430/msp430.c (msp430_asm_output_addr_const_extra): Fix
unused argument warning.

 
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index fe97f27..bf29e18 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -976,7 +976,7 @@ msp430_asm_integer (rtx x, unsigned int size, int aligned_p)
 #undef  TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA
 #define TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA msp430_asm_output_addr_const_extra
 static bool
-msp430_asm_output_addr_const_extra (FILE *file, rtx x)
+msp430_asm_output_addr_const_extra (FILE *file ATTRIBUTE_UNUSED, rtx x)
 {
   debug_rtx(x);
   return false;

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  [Nach Firefox-Update gibt es Empfehlungen, wenn man einen 
neuen Tab aufmacht.]
the second  :   13:26 <@jbglaw> "Hide the new 
tab page"
13:27 <@jbglaw> Warum zum Teufel sind gerade Kacheln so 
ungeheuer angesagt?!
  13:57 <@andrel> die Mozilla Foundation hat eine LKW Ladung 
Fugenkitt gespendet bekommen?


signature.asc
Description: Digital signature

[BUILDROBOT] Fallout for aarch64_be-elf (was: [PATCH] Rename gimple_build_assign_with_ops to gimple_build_assign and swap the first two arguments of it)

[Jan-Benedict Glaw]

On Mon, 2014-12-01 14:52:05 +0100, Jakub Jelinek  wrote:
> On Fri, Nov 28, 2014 at 08:02:23PM +0100, Jakub Jelinek wrote:
> > As possible follow-up, I wonder if gimple_build_assign_with_ops
> > isn't too long and too verbose either, couldn't we just
> > use overloads of gimple_build_assign instead?
> > Either with the argument order of gimple_build_assign_with_ops,
> > i.e. tree_code, lhs, operands... , or perhaps swap the lhs and
> > tree_code, so lhs, tree_code, operands... In either case, I'd
> > find it to be pretty much unambiguous with the current two operand
> > gimple_build_assign which takes lhs, treeop, the presence of
> > enum tree_code would make it obvious that you are supplying ops for it
> > rather than building it from what is extracted from the tree.
> 
> The following patch implements that.  Bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk?

Seems this caused some fallout for aarch64_be-elf, see eg.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=380617 :

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
-I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
-I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include 
-I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o aarch64.o -MT aarch64.o -MMD 
-MP -MF ./.deps/aarch64.TPo /home/jbglaw/repos/gcc/gcc/config/aarch64/aarch64.c
/home/jbglaw/repos/gcc/gcc/wide-int.h: In function ‘bool 
aarch64_float_const_representable_p(rtx_def*)’:
/home/jbglaw/repos/gcc/gcc/wide-int.h:798: warning: array subscript is above 
array bounds
/bin/bash /home/jbglaw/repos/gcc/gcc/config/aarch64/geniterators.sh \
/home/jbglaw/repos/gcc/gcc/config/aarch64/iterators.md > \
aarch64-builtin-iterators.h
g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
-I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
-I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include 
-I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace-I. -I. 
-I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
-I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include 
-I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace   \
/home/jbglaw/repos/gcc/gcc/config/aarch64/aarch64-builtins.c
/home/jbglaw/repos/gcc/gcc/config/aarch64/aarch64-builtins.c: In function ‘bool 
aarch64_gimple_fold_builtin(gimple_stmt_iterator*)’:
/home/jbglaw/repos/gcc/gcc/config/aarch64/aarch64-builtins.c:1329: error: 
‘gimple_build_assign_with_ops’ was not declared in this scope
make[1]: *** [aarch64-builtins.o] Error 1
make[1]: Leaving directory `/home/jbglaw/build/aarch64_be-elf/build-gcc/gcc'
make: *** [all-gcc] Error 2



MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   ...und wenn Du denkst, es geht nicht mehr,
the second  :  kommt irgendwo ein Lichtlein her.


signature.asc
Description: Digital signature

Re: [BUILDROBOT] nios2: build breakage

[Sandra Loosemore]

On 11/19/2014 09:34 PM, Jan Hubicka wrote:

[snip]
I see three possible fixes:
  1) extend the AWk script to recognize arrays and stream them specially
 (it already recognizes string so it is not hard to do, just bit wasteful)
  2) add attribute to .opt file allowing user to specify his own
 compare/hash/stream-in/stream-out functions
  3) avoid using arrays in the backend.  I think it is doable - the target
 structure contains string representation of the arrays
 (nios2_custom_fpu_cfg_string) and therefore saved_custom_code_status/
 saved_custom_code_index does not really need to hit the LTO stream
 at all. Question is where to place them and I think target specific
 part of cfun is probably resonable choice.


Just to clarify here, nios2_custom_fpu_cfg_string doesn't hold the 
complete state information.  That option is used to specify some sets of 
predefined custom instructions that can be augmented with various 
-mcustom-foo= options for individual instructions foo (or you can just 
use the -mcustom-foo= options).  The arrays are used to hold the 
combined state of all these different options for error-checking and 
lookup purposes.  I think it is true that we could rewrite this code to 
reconstruct the arrays from the original options, but it's not something 
I'd really want to undertake if the generic streaming code can be fixed 
instead.



As for AWk-fu, 2 is probably easier than 1, but both are not hard - one just
need to follow what is already done for strings and introduce third type of
variable.

Unless someone beats me, I will probably go for 1 since I am not very familiar
with the backend and array support may come handy in future.

As for timeline, I have a workshop next week and need to prepare draft for it.
So ideally I would like to work on this only after the workshop (ending
November 28). I would be also happy to help anyone interested to help (I am
just bit slow on portable AWK hacking).


OK.  I'm not so worried about getting this fixed by a certain date as 
about having a plan for fixing it.


-Sandra

Re: [BUILDROBOT] nios2: build breakage

[Jan Hubicka]

Sandra,
> >
> >I can explain why this is needed, at least.
> >
> >The Nios II architecture optionally allows "custom instructions" that
> >are typically used to implement floating-point operations.  The nios2
> >GCC backend knows to generate these instructions if the user tells it
> >what opcodes implement these instructions.  This is typically done by
> >command-line options, but can also be done on a per-function basis by
> >means of target attributes or pragmas -- see
> >gcc/testsuite/gcc.target/nios2/custom-fp-* for examples.  The
> >command-line options, attribute, and pragma support was a requirement
> >from Altera, so yes, this is really needed.
> 
> Ping.  Do we have any strategy or timeline for fixing this yet?  At
> the very least, if it is determined to impose a new restriction
> against using arrays in the saved option state, there must be a
> patch to clearly document what is permissible.  Otherwise I think
> the generic code must be fixed to support what the nios2 back end is
> already doing and which previously worked per the existing
> documentation.

I see three possible fixes:
 1) extend the AWk script to recognize arrays and stream them specially
(it already recognizes string so it is not hard to do, just bit wasteful)
 2) add attribute to .opt file allowing user to specify his own
compare/hash/stream-in/stream-out functions
 3) avoid using arrays in the backend.  I think it is doable - the target
structure contains string representation of the arrays
(nios2_custom_fpu_cfg_string) and therefore saved_custom_code_status/
saved_custom_code_index does not really need to hit the LTO stream
at all. Question is where to place them and I think target specific
part of cfun is probably resonable choice.

As for AWk-fu, 2 is probably easier than 1, but both are not hard - one just
need to follow what is already done for strings and introduce third type of
variable.

Unless someone beats me, I will probably go for 1 since I am not very familiar
with the backend and array support may come handy in future.

As for timeline, I have a workshop next week and need to prepare draft for it.
So ideally I would like to work on this only after the workshop (ending
November 28). I would be also happy to help anyone interested to help (I am
just bit slow on portable AWK hacking).

Honza
> 
> -Sandra

Re: [BUILDROBOT] nios2: build breakage

[Sandra Loosemore]

On 11/15/2014 06:46 PM, Sandra Loosemore wrote:

On 11/15/2014 04:49 PM, Jan-Benedict Glaw wrote:

Hi,

On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka  wrote:

Yep, it is because my code does not handle streaming of arrays
into the target optimization nodes.  I will take a look on why
that array is really needed. It seems like a overkill?


I am looking into the nios2_register_custom_code and I do not quite
understand what it is good for?  If it tracks customs codes function
wide, then perhaps target part of cfun would be better place to home
it.  It it is unit wide, then saving/restoring does not seem to make
much sense.

Can you, please, explain me why this needs to be stored into target
option structure?  If this is really needed, then we can always add
a support for streaming arrays, but I would preffer keeping that
structure small and simple ;)


Port maintainers Cc'ed.


I can explain why this is needed, at least.

The Nios II architecture optionally allows "custom instructions" that
are typically used to implement floating-point operations.  The nios2
GCC backend knows to generate these instructions if the user tells it
what opcodes implement these instructions.  This is typically done by
command-line options, but can also be done on a per-function basis by
means of target attributes or pragmas -- see
gcc/testsuite/gcc.target/nios2/custom-fp-* for examples.  The
command-line options, attribute, and pragma support was a requirement
from Altera, so yes, this is really needed.


Ping.  Do we have any strategy or timeline for fixing this yet?  At the 
very least, if it is determined to impose a new restriction against 
using arrays in the saved option state, there must be a patch to clearly 
document what is permissible.  Otherwise I think the generic code must 
be fixed to support what the nios2 back end is already doing and which 
previously worked per the existing documentation.


-Sandra

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

[Jan-Benedict Glaw]

On Mon, 2014-11-17 19:17:34 +0300, Ilya Enkovich  wrote:
> On 17 Nov 16:12, Jan-Benedict Glaw wrote:
> > On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf 
> >  wrote:
> > > On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > > > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich 
> > > >  wrote:
> > [...]
> i386 target mode is used instead of a hook.  Here is a fix.  Checked
> it fixes ARM cross build.  Committed as obvious fix.

Thanks a lot!  The first non-x86 build already succeeded:
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376848

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  The course of history shows that as a government grows, liberty
the second  : decreases."  (Thomas Jefferson)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

[Ilya Enkovich]

On 17 Nov 16:12, Jan-Benedict Glaw wrote:
> On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf 
>  wrote:
> > On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich  
> > > wrote:
> [...]
> > > It seems this part of the patch series causes some build breakage
> > > right now, see eg. build
> > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376804 :
> > > 
> > > g++ -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 -fno-common  -DHAVE_CONFIG_H -I. -I. 
> > > -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
> > > -I/home/jbglaw/repos/gcc/gcc/../include 
> > > -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
> > > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> > > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> > > -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o builtins.o -MT 
> > > builtins.o -MMD -MP -MF ./.deps/builtins.TPo 
> > > /home/jbglaw/repos/gcc/gcc/builtins.c
> > > /home/jbglaw/repos/gcc/gcc/builtins.c: In function ???rtx_def* 
> > > expand_builtin_memcpy_with_bounds(tree, rtx)???:
> > > /home/jbglaw/repos/gcc/gcc/builtins.c:3300:25: error: ???BNDmode??? was 
> > > not declared in this scope
> > > rtx bnd = force_reg (BNDmode,
> > >  ^
> > > /home/jbglaw/repos/gcc/gcc/builtins.c: In function ???rtx_def* 
> > > expand_builtin_mempcpy_with_bounds(tree, rtx, machine_mode)???:
> > > /home/jbglaw/repos/gcc/gcc/builtins.c:3357:25: error: ???BNDmode??? was 
> > > not declared in this scope
> > > rtx bnd = force_reg (BNDmode,
> > >  ^
> > > /home/jbglaw/repos/gcc/gcc/builtins.c: In function ???rtx_def* 
> > > expand_builtin_memset_with_bounds(tree, rtx, machine_mode)???:
> > > /home/jbglaw/repos/gcc/gcc/builtins.c:3763:25: error: ???BNDmode??? was 
> > > not declared in this scope
> > > rtx bnd = force_reg (BNDmode,
> > >  ^
> > > make[1]: *** [builtins.o] Error 1
> > > make[1]: Leaving directory `/home/jbglaw/build/mips-linux/build-gcc/gcc'
> > 
> > Also happens on ppc64 and probably on all the other non x86
> > architectures.
> 
> I just took that single build as an example. If you look at the
> timeline view (http://toolchain.lug-owl.de/buildbot/timeline.php),
> you'll see that every build started after ~ 14:49 CET (= 13:49 UTC)
> except a x86_64-linux build failed. (Ignore builds of gcc20, it got
> some HDD issues.)
> 
> MfG, JBG
> 
> -- 
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:  What we do for ourselves dies with us. What we do 
> for
> the second  : others and the world remains and is immortal. (Albert 
> Pine)


i386 target mode is used instead of a hook.  Here is a fix.  Checked it fixes 
ARM cross build.  Committed as obvious fix.

Thanks,
Ilya
--
2014-11-17  Ilya Enkovich  

* builtins.c (expand_builtin_memcpy_with_bounds): Use target hook
instead of BNDmode.
(expand_builtin_mempcpy_with_bounds): Likewise.
(expand_builtin_memset_with_bounds): Likewise.


diff --git a/gcc/builtins.c b/gcc/builtins.c
index 7ec2d5f..f48745e 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3297,7 +3297,7 @@ expand_builtin_memcpy_with_bounds (tree exp, rtx target)
   /* Return src bounds with the result.  */
   if (res)
{
- rtx bnd = force_reg (BNDmode,
+ rtx bnd = force_reg (targetm.chkp_bound_mode (),
   expand_normal (CALL_EXPR_ARG (exp, 1)));
  res = chkp_join_splitted_slot (res, bnd);
}
@@ -3354,7 +3354,7 @@ expand_builtin_mempcpy_with_bounds (tree exp, rtx target, 
machine_mode mode)
   /* Return src bounds with the result.  */
   if (res)
{
- rtx bnd = force_reg (BNDmode,
+ rtx bnd = force_reg (targetm.chkp_bound_mode (),
   expand_normal (CALL_EXPR_ARG (exp, 1)));
  res = chkp_join_splitted_slot (res, bnd);
}
@@ -3760,7 +3760,7 @@ expand_builtin_memset_with_bounds (tree exp, rtx target, 
machine_mode mode)
   /* Return src bounds with the result.  */
   if (res)
{
- rtx bnd = force_reg (BNDmode,
+ rtx bnd = force_reg (targetm.chkp_bound_mode (),
   expand_normal (CALL_EXPR_ARG (exp, 1)));
  res = chkp_join_splitted_slot (res, bnd);
}

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

[Jan-Benedict Glaw]

On Mon, 2014-11-17 15:59:41 +0100, Markus Trippelsdorf  
wrote:
> On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> > On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich  
> > wrote:
[...]
> > It seems this part of the patch series causes some build breakage
> > right now, see eg. build
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376804 :
> > 
> > g++ -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 
> > -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
> > -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
> > -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
> > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> > -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o builtins.o -MT 
> > builtins.o -MMD -MP -MF ./.deps/builtins.TPo 
> > /home/jbglaw/repos/gcc/gcc/builtins.c
> > /home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
> > expand_builtin_memcpy_with_bounds(tree, rtx)’:
> > /home/jbglaw/repos/gcc/gcc/builtins.c:3300:25: error: ‘BNDmode’ was not 
> > declared in this scope
> > rtx bnd = force_reg (BNDmode,
> >  ^
> > /home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
> > expand_builtin_mempcpy_with_bounds(tree, rtx, machine_mode)’:
> > /home/jbglaw/repos/gcc/gcc/builtins.c:3357:25: error: ‘BNDmode’ was not 
> > declared in this scope
> > rtx bnd = force_reg (BNDmode,
> >  ^
> > /home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
> > expand_builtin_memset_with_bounds(tree, rtx, machine_mode)’:
> > /home/jbglaw/repos/gcc/gcc/builtins.c:3763:25: error: ‘BNDmode’ was not 
> > declared in this scope
> > rtx bnd = force_reg (BNDmode,
> >  ^
> > make[1]: *** [builtins.o] Error 1
> > make[1]: Leaving directory `/home/jbglaw/build/mips-linux/build-gcc/gcc'
> 
> Also happens on ppc64 and probably on all the other non x86
> architectures.

I just took that single build as an example. If you look at the
timeline view (http://toolchain.lug-owl.de/buildbot/timeline.php),
you'll see that every build started after ~ 14:49 CET (= 13:49 UTC)
except a x86_64-linux build failed. (Ignore builds of gcc20, it got
some HDD issues.)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  What we do for ourselves dies with us. What we do for
the second  : others and the world remains and is immortal. (Albert 
Pine)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

[Markus Trippelsdorf]

On 2014.11.17 at 15:52 +0100, Jan-Benedict Glaw wrote:
> On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich  
> wrote:
> > Hi,
> > 
> > This patch adds support of instrumented builtin calls in expand.
> > Calls are mostly expanded as calls.  But some of them reuse existing
> > string function calls expand functions (memcpy expand was slightly
> > refactored for that).
> > 
> > This is the last enabling patch in this series.  Remaining two
> > patches are performance ones.
> > 
> > 2014-11-06  Ilya Enkovich  
> > 
> > * builtins.c (expand_builtin_memcpy_args): New.
> > (expand_builtin_memcpy): Call expand_builtin_memcpy_args.
> > (expand_builtin_memcpy_with_bounds): New.
> > (expand_builtin_mempcpy_with_bounds): New.
> > (expand_builtin_mempcpy_args): Add orig_exp arg. Support
> > BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK
> > (expand_builtin_memset_with_bounds): New.
> > (expand_builtin_memset_args): Support BUILT_IN_CHKP_MEMSET_NOBND_NOCHK.
> > (expand_builtin_with_bounds): New.
> > * builtins.h (expand_builtin_with_bounds): New.
> > * expr.c (expand_expr_real_1): Support instrumented builtin calls.
> 
> It seems this part of the patch series causes some build breakage
> right now, see eg. build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376804 :
> 
> g++ -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 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
> -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
> -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o builtins.o -MT builtins.o 
> -MMD -MP -MF ./.deps/builtins.TPo /home/jbglaw/repos/gcc/gcc/builtins.c
> /home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
> expand_builtin_memcpy_with_bounds(tree, rtx)’:
> /home/jbglaw/repos/gcc/gcc/builtins.c:3300:25: error: ‘BNDmode’ was not 
> declared in this scope
> rtx bnd = force_reg (BNDmode,
>  ^
> /home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
> expand_builtin_mempcpy_with_bounds(tree, rtx, machine_mode)’:
> /home/jbglaw/repos/gcc/gcc/builtins.c:3357:25: error: ‘BNDmode’ was not 
> declared in this scope
> rtx bnd = force_reg (BNDmode,
>  ^
> /home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
> expand_builtin_memset_with_bounds(tree, rtx, machine_mode)’:
> /home/jbglaw/repos/gcc/gcc/builtins.c:3763:25: error: ‘BNDmode’ was not 
> declared in this scope
> rtx bnd = force_reg (BNDmode,
>  ^
> make[1]: *** [builtins.o] Error 1
> make[1]: Leaving directory `/home/jbglaw/build/mips-linux/build-gcc/gcc'

Also happens on ppc64 and probably on all the other non x86 architectures.

-- 
Markus

[BUILDROBOT] Build breakage in builtin.c (was: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls)

[Jan-Benedict Glaw]

On Thu, 2014-11-06 15:24:59 +0300, Ilya Enkovich  wrote:
> Hi,
> 
> This patch adds support of instrumented builtin calls in expand.
> Calls are mostly expanded as calls.  But some of them reuse existing
> string function calls expand functions (memcpy expand was slightly
> refactored for that).
> 
> This is the last enabling patch in this series.  Remaining two
> patches are performance ones.
> 
> 2014-11-06  Ilya Enkovich  
> 
>   * builtins.c (expand_builtin_memcpy_args): New.
>   (expand_builtin_memcpy): Call expand_builtin_memcpy_args.
>   (expand_builtin_memcpy_with_bounds): New.
>   (expand_builtin_mempcpy_with_bounds): New.
>   (expand_builtin_mempcpy_args): Add orig_exp arg. Support
>   BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK
>   (expand_builtin_memset_with_bounds): New.
>   (expand_builtin_memset_args): Support BUILT_IN_CHKP_MEMSET_NOBND_NOCHK.
>   (expand_builtin_with_bounds): New.
>   * builtins.h (expand_builtin_with_bounds): New.
>   * expr.c (expand_expr_real_1): Support instrumented builtin calls.

It seems this part of the patch series causes some build breakage
right now, see eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376804 :

g++ -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 -fno-common  
-DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
-I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o builtins.o -MT builtins.o 
-MMD -MP -MF ./.deps/builtins.TPo /home/jbglaw/repos/gcc/gcc/builtins.c
/home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
expand_builtin_memcpy_with_bounds(tree, rtx)’:
/home/jbglaw/repos/gcc/gcc/builtins.c:3300:25: error: ‘BNDmode’ was not 
declared in this scope
rtx bnd = force_reg (BNDmode,
 ^
/home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
expand_builtin_mempcpy_with_bounds(tree, rtx, machine_mode)’:
/home/jbglaw/repos/gcc/gcc/builtins.c:3357:25: error: ‘BNDmode’ was not 
declared in this scope
rtx bnd = force_reg (BNDmode,
 ^
/home/jbglaw/repos/gcc/gcc/builtins.c: In function ‘rtx_def* 
expand_builtin_memset_with_bounds(tree, rtx, machine_mode)’:
/home/jbglaw/repos/gcc/gcc/builtins.c:3763:25: error: ‘BNDmode’ was not 
declared in this scope
rtx bnd = force_reg (BNDmode,
 ^
make[1]: *** [builtins.o] Error 1
make[1]: Leaving directory `/home/jbglaw/build/mips-linux/build-gcc/gcc'

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   Warum ist Scheiße braun? ...weil braun schon immer scheiße 
ist!
the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] nios2: build breakage

[Sandra Loosemore]

On 11/15/2014 04:49 PM, Jan-Benedict Glaw wrote:

Hi,

On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka  wrote:

Yep, it is because my code does not handle streaming of arrays
into the target optimization nodes.  I will take a look on why
that array is really needed. It seems like a overkill?


I am looking into the nios2_register_custom_code and I do not quite
understand what it is good for?  If it tracks customs codes function
wide, then perhaps target part of cfun would be better place to home
it.  It it is unit wide, then saving/restoring does not seem to make
much sense.

Can you, please, explain me why this needs to be stored into target
option structure?  If this is really needed, then we can always add
a support for streaming arrays, but I would preffer keeping that
structure small and simple ;)


Port maintainers Cc'ed.


I can explain why this is needed, at least.

The Nios II architecture optionally allows "custom instructions" that 
are typically used to implement floating-point operations.  The nios2 
GCC backend knows to generate these instructions if the user tells it 
what opcodes implement these instructions.  This is typically done by 
command-line options, but can also be done on a per-function basis by 
means of target attributes or pragmas -- see 
gcc/testsuite/gcc.target/nios2/custom-fp-* for examples.  The 
command-line options, attribute, and pragma support was a requirement 
from Altera, so yes, this is really needed.


-Sandra

[BUILDROBOT] nios2: build breakage (was: Rerog streaming of OPTIMIZATION_NODE)

[Jan-Benedict Glaw]

Hi,

On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka  wrote:
> > Yep, it is because my code does not handle streaming of arrays
> > into the target optimization nodes.  I will take a look on why
> > that array is really needed. It seems like a overkill?
> 
> I am looking into the nios2_register_custom_code and I do not quite
> understand what it is good for?  If it tracks customs codes function
> wide, then perhaps target part of cfun would be better place to home
> it.  It it is unit wide, then saving/restoring does not seem to make
> much sense.
> 
> Can you, please, explain me why this needs to be stored into target
> option structure?  If this is really needed, then we can always add
> a support for streaming arrays, but I would preffer keeping that
> structure small and simple ;)

Port maintainers Cc'ed.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   http://www.eyrie.org/~eagle/faqs/questions.html
the second  :


signature.asc
Description: Digital signature

Re: [BUILDROBOT] error: �??cl_target_option_stream_in�?? was not declared in this scope (was: LTO streaming of TARGET_OPTIMIZE_NODE)

[Jan-Benedict Glaw]

On Fri, 2014-11-14 19:53:33 +0100, Jan Hubicka  wrote:
> > Breaks build:
> > 
> > g++ -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 
> > -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
> > -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
> > -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
> > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> > -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o tree-streamer-in.o -MT 
> > tree-streamer-in.o -MMD -MP -MF ./.deps/tree-streamer-in.TPo 
> > /home/jbglaw/repos/gcc/gcc/tree-streamer-in.c
> > /home/jbglaw/repos/gcc/gcc/tree-streamer-in.c: In function ‘void 
> > unpack_value_fields(data_in*, bitpack_d*, tree)’:
> > /home/jbglaw/repos/gcc/gcc/tree-streamer-in.c:527:180: error: 
> > ‘cl_target_option_stream_in’ was not declared in this scope
> > make[1]: *** [tree-streamer-in.o] Error 1
> > 
> > 
> > See eg. these builds:
> > 
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376049
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376050
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376051
> 
> I managed to do a partial commit (mistyping lto-streamer.h). It should be 
> fixed by the followup commit
> a minute later.  Does it works for you now?

Looks good. Thanks!

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: They that give up essential liberty to obtain temporary safety,
the second  : deserve neither liberty nor safety.  (Ben Franklin)


signature.asc
Description: Digital signature

Re: [BUILDROBOT] error: �??cl_target_option_stream_in�?? was not declared in this scope (was: LTO streaming of TARGET_OPTIMIZE_NODE)

[Jan Hubicka]

> 
> Breaks build:
> 
> g++ -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 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
> -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
> -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o tree-streamer-in.o -MT 
> tree-streamer-in.o -MMD -MP -MF ./.deps/tree-streamer-in.TPo 
> /home/jbglaw/repos/gcc/gcc/tree-streamer-in.c
> /home/jbglaw/repos/gcc/gcc/tree-streamer-in.c: In function ‘void 
> unpack_value_fields(data_in*, bitpack_d*, tree)’:
> /home/jbglaw/repos/gcc/gcc/tree-streamer-in.c:527:180: error: 
> ‘cl_target_option_stream_in’ was not declared in this scope
> make[1]: *** [tree-streamer-in.o] Error 1
> 
> 
> See eg. these builds:
> 
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376049
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376050
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376051

I managed to do a partial commit (mistyping lto-streamer.h). It should be fixed 
by the followup commit
a minute later.  Does it works for you now?

Honza
> 
> MfG, JBG
> 
> -- 
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:  What we do for ourselves dies with us. What we do 
> for
> the second  : others and the world remains and is immortal. (Albert 
> Pine)

[BUILDROBOT] error: ‘cl_target_option_stream_in’ was not declared in this scope (was: LTO streaming of TARGET_OPTIMIZE_NODE)

[Jan-Benedict Glaw]

On Fri, 2014-11-14 01:37:14 +0100, Jan Hubicka  wrote:
> Hi,
> here is upated version with bitfields and also tested on PPC64-linux/aix.
> I hacked configury to use system awk instead of gawk, so the changes are 
> hopefully safe.
> 
> OK?
> Honza
> 
>   * optc-save-gen.awk: Output cl_target_option_eq,
>   cl_target_option_hash, cl_target_option_stream_out,
>   cl_target_option_stream_in functions.
>   * opth-gen.awk: Output prototypes for
>   cl_target_option_eq and cl_target_option_hash.
>   * lto-streamer.h (cl_target_option_stream_out,
>   cl_target_option_stream_in): Declare.
>   * tree.c (cl_option_hash_hash): Use cl_target_option_hash.
>   (cl_option_hash_eq): Use cl_target_option_eq.
>   * tree-streamer-in.c (unpack_value_fields): Stream in
>   TREE_TARGET_OPTION.
>   * lto-streamer-out.c (DFS::DFS_write_tree_body): Follow
>   DECL_FUNCTION_SPECIFIC_TARGET.
>   (hash_tree): Hash TREE_TARGET_OPTION; visit
>   DECL_FUNCTION_SPECIFIC_TARGET.
>   * tree-streamer-out.c (streamer_pack_tree_bitfields): Skip
>   TS_TARGET_OPTION.
>   (streamer_write_tree_body): Output TS_TARGET_OPTION.

Breaks build:

g++ -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 -fno-common  
-DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
-I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o tree-streamer-in.o -MT 
tree-streamer-in.o -MMD -MP -MF ./.deps/tree-streamer-in.TPo 
/home/jbglaw/repos/gcc/gcc/tree-streamer-in.c
/home/jbglaw/repos/gcc/gcc/tree-streamer-in.c: In function ‘void 
unpack_value_fields(data_in*, bitpack_d*, tree)’:
/home/jbglaw/repos/gcc/gcc/tree-streamer-in.c:527:180: error: 
‘cl_target_option_stream_in’ was not declared in this scope
make[1]: *** [tree-streamer-in.o] Error 1


See eg. these builds:

http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376049
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376050
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376051

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  What we do for ourselves dies with us. What we do for
the second  : others and the world remains and is immortal. (Albert 
Pine)


signature.asc
Description: Digital signature

Re: [PATCH, BUILDROBOT] SH: Fix unused variable warning (was: [SH][committed] PR 53513 - Add __builtin_sh_get_fpscr, __builtin_sh_set_fpscr)

[Jan-Benedict Glaw]

On Tue, 2014-11-04 13:21:24 +0100, Oleg Endo  wrote:
> On 4 Nov 2014, at 11:50, Jan-Benedict Glaw  wrote:
> >
> > 2014-11-04  Jan-Benedict Glaw  
> > 
> >* config/sh/sh.c (emit_fpu_switch): Drop unused automatic variable.
[...]
> > This should fix it, ok for mainline?
> 
> Yes, OK.  Thanks for catching it.

Thanks.  Committed as r217082.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Fortschritt bedeutet, einen Schritt so zu machen,
the second  :   daß man den nächsten auch noch machen kann.


signature.asc
Description: Digital signature

Re: [PATCH, BUILDROBOT] SH: Fix unused variable warning (was: [SH][committed] PR 53513 - Add __builtin_sh_get_fpscr, __builtin_sh_set_fpscr)

[Oleg Endo]

On 4 Nov 2014, at 11:50, Jan-Benedict Glaw  wrote:

> On Sat, 2014-10-18 12:54:33 +0200, Oleg Endo  wrote:
>> Hi,
>> 
>> As discussed in the PR, this adds two new SH built-in functions
>> __builtin_sh_get_fpscr __builtin_sh_set_fpscr.  Tested on r216173 with  
>> 
>> make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m4/-ml,-m4/-mb}"
>> 
>> and no new failures.  Committed as r216424.
>> 
>> Cheers,
>> Oleg
>> 
>> gcc/ChangeLog:
>>PR target/53513
>>* config/sh/sh-modes.def (PSI): Remove.
>>* config/sh/sh-protos.h (get_fpscr_rtx): Remove.
>>* config/sh/sh.c (fpscr_rtx, get_fpscr_rtx): Remove.
>>(sh_reorg): Remove commented out FPSCR code.
>>(fpscr_set_from_mem): Use SImode instead of PSImode.  Emit lds_fpscr
>>insn instead of move insn.
>>(sh_hard_regno_mode_ok): Return SImode for FPSCR.
>>(sh_legitimate_address_p, sh_legitimize_reload_address): Remove PSImode
>>handling.
>>(sh_emit_mode_set): Emit lds_fpscr and sts_fpscr insns.
>>(sh1_builtin_p): Uncomment.
>>(SH_BLTIN_UV 25, SH_BLTIN_VU 26): New macros.
>>(bdesc): Add __builtin_sh_get_fpscr and __builtin_sh_set_fpscr.
> 
> Change to emit_fpu_switch() is missing here.
> 
>> Index: gcc/config/sh/sh.c
>> ===
>> --- gcc/config/sh/sh.c(revision 216350)
>> +++ gcc/config/sh/sh.c(working copy)
> 
> This chunk is in emit_fpu_switch(), which drops every reference to
> `dst':
>> @@ -10055,13 +10032,12 @@
>>   emit_move_insn (scratch, XEXP (src, 0));
>>   if (index != 0)
>>emit_insn (gen_addsi3 (scratch, scratch, GEN_INT (index * 4)));
>> -  src = adjust_automodify_address (src, PSImode, scratch, index * 4);
>> +  src = adjust_automodify_address (src, SImode, scratch, index * 4);
>> }
>>   else
>> -src = adjust_address (src, PSImode, index * 4);
>> +src = adjust_address (src, SImode, index * 4);
>> 
>> -  dst = get_fpscr_rtx ();
>> -  emit_move_insn (dst, src);
>> +  emit_insn (gen_lds_fpscr (src));
>> }
>> 
>> static rtx get_free_reg (HARD_REG_SET);
> 
> ...which in turn results in fall-out when simply building it with
> config-list.mk, see eg.
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372472 :
> 
> [...]
> g++ -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../../../gcc/gcc -I../../../gcc/gcc/. 
> -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
> -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
> -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../../gcc/gcc/../libbacktrace-o sh.o -MT sh.o -MMD -MP -MF 
> ./.deps/sh.TPo ../../../gcc/gcc/config/sh/sh.c
> ../../../gcc/gcc/config/sh/sh.c: In function ‘void emit_fpu_switch(rtx, int)’:
> ../../../gcc/gcc/config/sh/sh.c:10027:7: error: unused variable ‘dst’ 
> [-Werror=unused-variable]
>   rtx dst, src;
>   ^
> cc1plus: all warnings being treated as errors
> make[2]: *** [sh.o] Error 1
> 
> This should fix it, ok for mainline?

Yes, OK.  Thanks for catching it.

Cheers,
Oleg


> 
> 2014-11-04  Jan-Benedict Glaw  
> 
>* config/sh/sh.c (emit_fpu_switch): Drop unused automatic variable.
> 
> 
> diff --git a/gcc/config/sh/sh.c b/gcc/config/sh/sh.c
> index 3a4f5e9..be944da 100644
> --- a/gcc/config/sh/sh.c
> +++ b/gcc/config/sh/sh.c
> @@ -10024,7 +10024,7 @@ static GTY(()) tree fpscr_values;
> static void
> emit_fpu_switch (rtx scratch, int index)
> {
> -  rtx dst, src;
> +  rtx src;
> 
>   if (fpscr_values == NULL)
> {
> 
> 
> 
> MfG, JBG
> 
> -- 
>  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> the second  :

[PATCH, BUILDROBOT] SH: Fix unused variable warning (was: [SH][committed] PR 53513 - Add __builtin_sh_get_fpscr, __builtin_sh_set_fpscr)

[Jan-Benedict Glaw]

On Sat, 2014-10-18 12:54:33 +0200, Oleg Endo  wrote:
> Hi,
> 
> As discussed in the PR, this adds two new SH built-in functions
> __builtin_sh_get_fpscr __builtin_sh_set_fpscr.  Tested on r216173 with  
> 
> make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m4/-ml,-m4/-mb}"
> 
> and no new failures.  Committed as r216424.
> 
> Cheers,
> Oleg
> 
> gcc/ChangeLog:
>   PR target/53513
>   * config/sh/sh-modes.def (PSI): Remove.
>   * config/sh/sh-protos.h (get_fpscr_rtx): Remove.
>   * config/sh/sh.c (fpscr_rtx, get_fpscr_rtx): Remove.
>   (sh_reorg): Remove commented out FPSCR code.
>   (fpscr_set_from_mem): Use SImode instead of PSImode.  Emit lds_fpscr
>   insn instead of move insn.
>   (sh_hard_regno_mode_ok): Return SImode for FPSCR.
>   (sh_legitimate_address_p, sh_legitimize_reload_address): Remove PSImode
>   handling.
>   (sh_emit_mode_set): Emit lds_fpscr and sts_fpscr insns.
>   (sh1_builtin_p): Uncomment.
>   (SH_BLTIN_UV 25, SH_BLTIN_VU 26): New macros.
>   (bdesc): Add __builtin_sh_get_fpscr and __builtin_sh_set_fpscr.

Change to emit_fpu_switch() is missing here.

> Index: gcc/config/sh/sh.c
> ===
> --- gcc/config/sh/sh.c(revision 216350)
> +++ gcc/config/sh/sh.c(working copy)

This chunk is in emit_fpu_switch(), which drops every reference to
`dst':
> @@ -10055,13 +10032,12 @@
>emit_move_insn (scratch, XEXP (src, 0));
>if (index != 0)
>   emit_insn (gen_addsi3 (scratch, scratch, GEN_INT (index * 4)));
> -  src = adjust_automodify_address (src, PSImode, scratch, index * 4);
> +  src = adjust_automodify_address (src, SImode, scratch, index * 4);
>  }
>else
> -src = adjust_address (src, PSImode, index * 4);
> +src = adjust_address (src, SImode, index * 4);
>  
> -  dst = get_fpscr_rtx ();
> -  emit_move_insn (dst, src);
> +  emit_insn (gen_lds_fpscr (src));
>  }
>  
>  static rtx get_free_reg (HARD_REG_SET);

...which in turn results in fall-out when simply building it with
config-list.mk, see eg.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372472 :

[...]
g++ -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../../../gcc/gcc -I../../../gcc/gcc/. 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace-o sh.o -MT sh.o -MMD -MP -MF 
./.deps/sh.TPo ../../../gcc/gcc/config/sh/sh.c
../../../gcc/gcc/config/sh/sh.c: In function ‘void emit_fpu_switch(rtx, int)’:
../../../gcc/gcc/config/sh/sh.c:10027:7: error: unused variable ‘dst’ 
[-Werror=unused-variable]
   rtx dst, src;
   ^
cc1plus: all warnings being treated as errors
make[2]: *** [sh.o] Error 1

This should fix it, ok for mainline?

2014-11-04  Jan-Benedict Glaw  

* config/sh/sh.c (emit_fpu_switch): Drop unused automatic variable.

 
diff --git a/gcc/config/sh/sh.c b/gcc/config/sh/sh.c
index 3a4f5e9..be944da 100644
--- a/gcc/config/sh/sh.c
+++ b/gcc/config/sh/sh.c
@@ -10024,7 +10024,7 @@ static GTY(()) tree fpscr_values;
 static void
 emit_fpu_switch (rtx scratch, int index)
 {
-  rtx dst, src;
+  rtx src;
 
   if (fpscr_values == NULL)
 {



MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
the second  :


signature.asc
Description: Digital signature

RE: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

[Zhenqiang Chen]

Sorry for breaking the build. The patch was reverted.

I will rework on it.

Thanks!
-Zhenqiang

> -Original Message-
> From: Jan-Benedict Glaw [mailto:jbg...@lug-owl.de]
> Sent: Monday, November 03, 2014 6:16 PM
> To: Zhenqiang Chen; Hartmut Penner; Ulrich Weigand; Andreas Krebbel
> Cc: 'Richard Henderson'; gcc-patches@gcc.gnu.org
> Subject: Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, 
> ifcvt]
> Allow CC mode if HAVE_cbranchcc4)
> 
> On Mon, 2014-11-03 11:06:06 +0100, Jan-Benedict Glaw 
> wrote:
> > On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen
>  wrote:
> > > Hi,
> > >
> > > The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
> > >
> > > Bootstrap and no make check regression on X86-64.
> > > Will add new test cases after ccmp is enabled.
> > >
> > > Ok for trunk?
> >
> > This seems to uncover something for s390x-linux, see
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372394
> >
> > [...]
> > g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-
> exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -
> Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -
> I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -
> I/home/jbglaw/repos/gcc/gcc/../libcpp/include  -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -
> MP -MF ./.deps/ifcvt.TPo /home/jbglaw/repos/gcc/gcc/ifcvt.c
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1456:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1788:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:2370:5: error: token "." is not
> > valid in preprocessor expressions
> > make[1]: *** [ifcvt.o] Error 1
> >
> > It's choking on the HAVE_cbranchcc4 macro itself there.
> 
> Oh, and with the most recent ifcvt.c changes, this boils down to:
> 
> g++ -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../../../gcc/gcc -
> I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
> -I../../../gcc/gcc/../libcpp/include
> -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -
> I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I../../../gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -MP -
> MF ./.deps/ifcvt.TPo ../../../gcc/gcc/ifcvt.c
> In file included from ./tm.h:19:0,
>  from ../../../gcc/gcc/ifcvt.c:23:
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1467:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1799:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>

RE: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

[Zhenqiang Chen]

> -Original Message-
> From: Jan-Benedict Glaw [mailto:jbg...@lug-owl.de]
> Sent: Monday, November 03, 2014 6:16 PM
> To: Zhenqiang Chen; Hartmut Penner; Ulrich Weigand; Andreas Krebbel
> Cc: 'Richard Henderson'; gcc-patches@gcc.gnu.org
> Subject: Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, 
> ifcvt]
> Allow CC mode if HAVE_cbranchcc4)
> 
> On Mon, 2014-11-03 11:06:06 +0100, Jan-Benedict Glaw 
> wrote:
> > On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen
>  wrote:
> > > Hi,
> > >
> > > The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
> > >
> > > Bootstrap and no make check regression on X86-64.
> > > Will add new test cases after ccmp is enabled.
> > >
> > > Ok for trunk?
> >
> > This seems to uncover something for s390x-linux, see
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372394
> >
> > [...]
> > g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-
> exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -
> Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -
> I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -
> I/home/jbglaw/repos/gcc/gcc/../libcpp/include  -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -
> MP -MF ./.deps/ifcvt.TPo /home/jbglaw/repos/gcc/gcc/ifcvt.c
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1456:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1788:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:2370:5: error: token "." is not
> > valid in preprocessor expressions
> > make[1]: *** [ifcvt.o] Error 1
> >
> > It's choking on the HAVE_cbranchcc4 macro itself there.
> 
> Oh, and with the most recent ifcvt.c changes, this boils down to:
> 
> g++ -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../../../gcc/gcc -
> I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
> -I../../../gcc/gcc/../libcpp/include
> -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -
> I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I../../../gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -MP -
> MF ./.deps/ifcvt.TPo ../../../gcc/gcc/ifcvt.c
> In file included from ./tm.h:19:0,
>  from ../../../gcc/gcc/ifcvt.c:23:
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1467:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1799:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cb

Re: [PATCH] [BUILDROBOT] RX: Mark unused argument

[Nicholas Clifton]

Hi Jan-Benedict,


2014-11-03  Jan-Benedict Glaw  

* config/rx/rx.c (rx_handle_func_attribute): Mark unused argument.


Approved - please apply.

Cheers
  Nick