Trouble trying to test GCC on a simulator
Hello, I would like to test a GCC patch on the platform it is supposed to affect (PowerPC). In order to to this, I'm using the following documentation: https://gcc.gnu.org/simtest-howto.html However, after fresh CVS checkouts (even without my changes on the GCC tree) and the corresponding combined tree creation, I cannot manage to get a build: $ ../combined/configure --prefix=$TOP/install --enable-languages=c,c++ --target=powerpc-eabisim --build=i686-pc-linux-gnu --enable-checking [runs fine] $ make [...] make[4]: Entering directory `/.../build/binutils' gcc -DHAVE_CONFIG_H -I. -I../../combined/binutils -I. -I../../combined/binutils -I../bfd -I../../combined/binutils/../bfd -I../../combined/binutils/../include -DLOCALEDIR="\"/.../install/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o ../../combined/binutils/bucomm.c ../../combined/binutils/bucomm.c:130:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'VPARAMS' ../../combined/binutils/bucomm.c:141:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'VPARAMS' make[4]: *** [bucomm.o] Error 1 The use of an undefined macro (VPARAMS) looks quite strange to me: is it a known issue? Or maybe is the documentation obsolete? Thanks in advance! -- Pierre-Marie de Rodat
Re: Trouble trying to test GCC on a simulator
On 08 Sep 2014, at 12:01, Pierre-Marie de Rodat wrote: > Hello, > > I would like to test a GCC patch on the platform it is supposed to affect > (PowerPC). In order to to this, I'm using the following documentation: > >https://gcc.gnu.org/simtest-howto.html > > However, after fresh CVS checkouts (even without my changes on the GCC tree) > and the corresponding combined tree creation, I cannot manage to get a build: CVS ? Binutils (and gdb) are now using git: If you plan to do active work on GNU binutils, you can access the development source tree by anonymous git: git clone git://sourceware.org/git/binutils-gdb.git Tristan.
How to identify object of a class defined in library file
How to identify object of a class which is defined in the library file? For e.g. struct basic_ostream & D.2782; Variable D.2782 is object of class which is part of the library file. How can we identify such a variable? Regards, Swati
Re: How to identify object of a class defined in library file
On 8 September 2014 11:53, Swati Rathi wrote: > > How to identify object of a class which is defined in the library file? > > For e.g. > struct basic_ostream & D.2782; > > > Variable D.2782 is object of class which is part of the library file. > How can we identify such a variable? Repeating the question three times doesn't make it any clearer, what exactly are you asking? What are you referring to as "the library file"? libstdc++.so? Or some library of your own? Please give more context for your question.
Re: How to identify object of a class defined in library file
I am referring to C++ standard library files. Statement : cout << "\tB:f" << endl; is translated as : struct basic_ostream & D.2782; struct basic_ostream & D.2781; : D.2782_1 = operator<< (&cout, "\tB:f"); D.2781_2 = D.2782_1; operator<< (D.2781_2, endl); I want to ignore variables D.2782 and D.2781 as they are object of class defined in standard library file. On Monday 08 September 2014 05:12 PM, Jonathan Wakely wrote: On 8 September 2014 11:53, Swati Rathi wrote: How to identify object of a class which is defined in the library file? For e.g. struct basic_ostream & D.2782; Variable D.2782 is object of class which is part of the library file. How can we identify such a variable? Repeating the question three times doesn't make it any clearer, what exactly are you asking? What are you referring to as "the library file"? libstdc++.so? Or some library of your own? Please give more context for your question.
Re: Trouble trying to test GCC on a simulator
On 09/08/2014 12:26 PM, Tristan Gingold wrote: CVS ? Binutils (and gdb) are now using git: Huh! I knew this, but not being a daily CVS user, I though the commands in the documentation would get a binutils version that was somehow tailored for GCC's needs. Anyway, here is what I just tried instead: # Get newlib and the simulator cvs -d :pserver:anon...@sourceware.org:/cvs/src co newlib sim # Get binutils git clone git://sourceware.org/git/binutils-gdb.git # Create the combined tree rm -rf combined mkdir combined cd src && find . -print | cpio -pdlm ../combined && cd .. cd binutils-gdb && find . -print | cpio -pdlmu ../combined && cd .. cd gcc && find . -print | cpio -pdlmu ../combined && cd .. # Same build/test procedure... It seems to work fine! (I'm running tests, now...) So thank you very much, Tristan. I'm going to submit a website patch to update the documentation according to this. -- Pierre-Marie de Rodat
Re: Trouble trying to test GCC on a simulator
On 08 Sep 2014, at 16:51, Pierre-Marie de Rodat wrote: > On 09/08/2014 12:26 PM, Tristan Gingold wrote: >> CVS ? Binutils (and gdb) are now using git: > > Huh! I knew this, but not being a daily CVS user, I though the commands in > the documentation would get a binutils version that was somehow tailored for > GCC's needs. Anyway, here is what I just tried instead: > ># Get newlib and the simulator >cvs -d :pserver:anon...@sourceware.org:/cvs/src co newlib sim Note that sim is considered as part of gdb, so ... [..] > It seems to work fine! (I'm running tests, now...) So thank you very much, > Tristan. I'm going to submit a website patch to update the documentation > according to this. ... you should use sim from binutils-gdb.git
RE: ICE in bitmap routines with LRA and inline assembly language
Hi,
It appears that the current program point was not incremented when an early
clobber pseudo register was marked as dead.
The patch below solves the problem for both testcases. I'll post the patch
along with a testcase to gcc-patches mailing list after running
the regression on, at least, x86_64-linux-gnu.
Regards,
Robert
diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
index f34517d..f9a0b45 100644
--- a/gcc/lra-lives.c
+++ b/gcc/lra-lives.c
@@ -680,9 +680,9 @@ process_bb_lives (basic_block bb, int &curr_point)
/* Mark early clobber outputs dead. */
for (reg = curr_id->regs; reg != NULL; reg = reg->next)
if (reg->type == OP_OUT && reg->early_clobber && ! reg->subreg_p)
- need_curr_point_incr = mark_regno_dead (reg->regno,
- reg->biggest_mode,
- curr_point);
+ need_curr_point_incr |= mark_regno_dead (reg->regno,
+ reg->biggest_mode,
+ curr_point);
for (reg = curr_static_id->hard_regs; reg != NULL; reg = reg->next)
if (reg->type == OP_OUT && reg->early_clobber && ! reg->subreg_p)
> -Original Message-
> From: Steve Ellcey
> Sent: 05 September 2014 22:49
> To: Vladimir Makarov
> Cc: Robert Suchanek
> Subject: Re: ICE in bitmap routines with LRA and inline assembly language
>
> On Thu, 2014-09-04 at 20:32 -0400, Vladimir Makarov wrote:
> > On 2014-09-04, 2:04 PM, Steve Ellcey wrote:
> > >
> > > I was wondering if anyone has seen this bug involving LRA and inline
> > > assembly code. On MIPS, I am getting the attached ICE. Somehow
> > > the 'first' pointer in the live_reload_and_inheritance_pseudos bitmap
> > > structure is either getting clobbered or is not being correctly
> > > initialized to begin with. I am not sure which yet.
> > >
> > >
> >
> > Sorry, I am on vacation now. I'll investigate this next week.
>
> Here is some more information I found while investigating this problem,
> maybe it will help when you get back.
>
> I see the bug with -O1, but not with -O0 and if I add
> '-fno-forward-propagate -fno-if-conversion' to -O1, then I can also
> make the ICE go away.
>
> I also have a second (similar) test case:
>
> int foo(const unsigned char* a, const unsigned char* b) {
>int count;
>int tmp;
>__asm__ volatile("mult $zero, $zero\n\t"
> "mflo %[count]\n\t" : [tmp]"=&r"(tmp),
> [count]"=&r"(count) :
> [a]"r"(a), [b]"r"(b) : "memory", "hi" , "lo");
>return count;
> }
>
> The interesting thing I noticed is that 'tmp' is not used in the inline
> assembly code (because I cut the test case down). But if I remove 'tmp'
> from the output list completely, the test case compiles. Likewise,
> if I leave it in but put 'count' in front of 'tmp' in the output list
> then the test case also compiles.
>
> So I think something, maybe forward propagation, maybe if-conversion,
> maybe LRA, is not looping through all the elements in the output list
> of an inline assembly language instruction when calculating register
> uses or dependencies or clobbers.
>
> Steve Ellcey
> sell...@mips.com
>
RE: [PATCH] RE: gcc parallel make check
Attached is an extended version of the patch, it brings a 100% improvement in
make -j32 -k check-gcc (down from 20min to <10min) by modification of
check_gcc_parallelize.
It includes one non-trivial part, namely a split of the target exps. They are
now all split using a common choice (based on i386), which I believe is
reasonable as it is the target with most tests, and the patterns will be
somewhat similar for other targets (e.g. split of p(rxxx)). The implementation
of this in the makefile uses an odd looking technique to substitute spaces with
commas in a variable, if this can be done more elegantly, I'm happy to make the
change.
Bootstrap and testing revealed one issue, i386.exp hard-codes a loop for the
testcase 'vect-args.c' in order to test 10 different combinations of options.
With the current split (i.e. target x4) this test will thus be executed 4
times. There are two easy options
1) keep the current setup, overhead is small
2) keep the .exp file simple and just replicate this test 10x
I've selected 1), but I can update a patch with 2). Ideally dg-options in the
testcase file itself could be repeated, but I haven't found an example of this.
The script now includes sorting and compression of the ranges, and an
additional sanity check on the input, i.e. that file names start with
[0-9A-Za-z]. Some (few) files seem to start with _ or # (in ./gcc.dg/cpp/).
I'll follow up with a separate patch to improve check_g++_parallelize.
Full 'make -j k32 check' is now dominated by libstdc++ testing, which contains
single goals that run ~1100s (e.g. regex related tests). These uses a slightly
different syntax (see gcc/libstdc++-v3/testsuite/Makefile.am) and I'm not yet
sure how to deal with the .am files.
current patch OK for trunk ?
Joost
patch-speedup-checkfortran-v05.CL
Description: patch-speedup-checkfortran-v05.CL
Index: contrib/generate_tcl_patterns.sh
===
--- contrib/generate_tcl_patterns.sh (revision 0)
+++ contrib/generate_tcl_patterns.sh (revision 0)
@@ -0,0 +1,114 @@
+#! /bin/sh
+
+#
+# based on a list of filenames as input, starting with [0-9A-Za-z],
+# generate regexps that match subsets trying to not exceed a
+# 'maxcount' parameter. Most useful to generate the
+# check_LANG_parallelize assignments needed to split
+# testsuite directories, defining prefix appropriately.
+#
+# Example usage:
+# cd gcc/gcc/testsuite/gfortran.dg
+# ls -1 | ../../../contrib/generate_tcl_patterns.sh 300 "dg.exp=gfortran.dg/"
+#
+# the first parameter is the maximum number of files.
+# the second parameter the prefix used for printing.
+#
+
+# Copyright (C) 2014 Free Software Foundation
+# Contributed by Joost VandeVondele
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING. If not, write to
+# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+
+gawk -v maxcount=$1 -v prefix=$2 '
+BEGIN{
+ # list of allowed starting chars for a file name in a dir to split
+ achars="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
+ ranget="112233"
+}
+{
+ if (index(achars,substr($1,1,1))==0){
+ print "file : " $1 " does not start with an allowed character."
+ _assert_exit = 1
+ exit 1
+ }
+ nfiles++ ; files[nfiles]=$1
+}
+END{
+ if (_assert_exit) exit 1
+ for(i=1; i<=length(achars); i++) count[substr(achars,i,1)]=0
+ for(i=1; i<=nfiles; i++) {
+ if (length(files[i]>0)) { count[substr(files[i],1,1)]++ }
+ };
+ asort(count,ordered)
+ countsingle=0
+ groups=0
+ label=""
+ for(i=length(achars);i>=1;i--) {
+countsingle=countsingle+ordered[i]
+for(j=1;j<=length(achars);j++) {
+ if(count[substr(achars,j,1)]==ordered[i]) found=substr(achars,j,1)
+}
+count[found]=-1
+label=label found
+if(i==1) { val=maxcount+1 } else { val=ordered[i-1] }
+if(countsingle+val>maxcount) {
+ subset[label]=countsingle
+ print "Adding label: ", label, "matching files:" countsingle
+ groups++
+ countsingle=0
+ label=""
+}
+ }
+ print "patterns:"
+ asort(subset,ordered)
+ for(i=groups;i>=1;i--) {
+for(j in subset){
+ if(subset[j]==ordered[i]) found=j
+}
+subset[found]=-1
+if (length(found)==1) {
+ printf("%s%s* \\\n",prefix,found)
+} else {
+ sortandcompress()
+ pri
