Re: SMS issues
Hello Alex,
On 18.07.2012 18:40, Alex Turjan wrote:
Im writing to you with respect to some strange SMS functionality.
In the code bellow there are 2 instructions (a builtin store and a builtin load)
as they appear in the program flow before SMS:
...
Issues:
1. What is the reason why (T,1) is build up? – to me it seams that (T,0)
must be enough
This looks like the issue that Roman's patch from
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01804.html should be fixing,
could you try it?
Ayal, Revital, could you again take a look at the above patch and all the
SMS improvement patches mentioned in
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01859.html? The last comments
from me are at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00478.html. At
the Cauldron, I was talking to Ramana about pushing these forward as
important for arm and Linaro, so it would be good to have them in 4.8.
Andrey
2. Looking inside generate_reg_moves it seams to me that this function
is not meant to deal with replacing memory accesses but only with
register replacements. (see inside the call to replace_rtx which in
my case trys to replace the mem accesses inside 136).
3. The (T,1) dep is assumed to take place as if before the SMS pass,
insn 136 was preceding insn 134:
(insn 136 135 137 12 tdscdma_pfu_ccdec.c:292
(set (reg/v:HI 248 [ mappingAddress_i16 ])
(unspec:HI [
(mem:HI (plus:PSI (reg/v/f:PSI 170 [ curMappingTable_pi16 ])
(reg:SI 305)) [0 S2 A16])
] 696)) 755 {INSN_BUILTIN___loadbyteofs_16} (expr_list:REG_DEAD
(reg:SI 305)
(nil)))
(insn 134 133 135 12 tdscdma_pfu_ccdec.c:289
(set (mem:HI (plus:PSI (reg/v/f:PSI 185 [ ccdecInterim_pi16 ])
(reg:SI 303)) [0 S2 A16])
(unspec:HI [
(reg/v:HI 244 [ outData_u16 ])
] 1752)) 1377 {INSN_BUILTIN___storebyteofs_16} (expr_list:REG_DEAD
(reg:SI 303)
(expr_list:REG_DEAD (reg/v:HI 244 [ outData_u16 ])
(nil
If that would be the case then between 134 and 136 there would be present
also an antidependence of distance 0. Becasue in the pipelined schedule,
134 is scheduled before 136 (SCHED_TIME (136) > SCHED_TIME (134)) the modulo
variable expansion needs to take place as explained before.
SMS decides to produce a modulo variable expansion in a case when is not
needed. However, it fails in fulfilling the whole modulo variable expansion
procedure, covering in this way the possibly incorrect behavior described above.
regards,
Alex
Re: get email addr from username (was: Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.)
On Tue, 2012-07-17 at 11:24 +0200, Richard Guenther wrote: > Note that people that patched a file are not necessary maintainers of that > file. > Maintainers are listed exclusively in the MAINTAINERS file. I was just looking for a quick and easy hack for my own convenience, based on the logic that most frequent committers are more likely to comment :-) Thanks, Dimitris
Re: get email addr from username (was: Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.)
On Mon, 2012-07-16 at 19:23 +0100, Jonathan Wakely wrote: > Add @gcc.gnu.org to it? Unfortunately this is rarely in agreement with MAINTAINERS. For now I found it easier to just grep the Changelog file. Thanks, Dimitris
Re: SMS issues
Andrey,
Thanks for the patch. I applied it and so far it seams ok.
I will run further testing and let you know if i see problems.
Back to the last part of my email, Im still wondering what happens in case
the variable modulo expanded is a memory location? because as I see
generate_reg_moves is not able to handle such situation... or perhaps there is
something which prevents the modulo scheduler from arriving to this situation?
Alex
--- On Thu, 7/19/12, Andrey Belevantsev wrote:
> From: Andrey Belevantsev
> Subject: Re: SMS issues
> To: "Alex Turjan"
> Cc: gcc@gcc.gnu.org, ayal.z...@gmail.com, revital.e...@linaro.org, "Roman
> Zhuikov"
> Date: Thursday, July 19, 2012, 11:11 AM
> Hello Alex,
>
> On 18.07.2012 18:40, Alex Turjan wrote:
> >
> > Im writing to you with respect to some strange SMS
> functionality.
> > In the code bellow there are 2 instructions (a builtin
> store and a builtin load)
> > as they appear in the program flow before SMS:
>
> ...
>
> > Issues:
> > 1. What is the reason why (T,1) is
> build up? – to me it seams that (T,0)
> > must be enough
>
> This looks like the issue that Roman's patch from
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01804.html
> should be fixing,
> could you try it?
>
> Ayal, Revital, could you again take a look at the above
> patch and all the
> SMS improvement patches mentioned in
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01859.html?
> The last comments
> from me are at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00478.html.
> At
> the Cauldron, I was talking to Ramana about pushing these
> forward as
> important for arm and Linaro, so it would be good to have
> them in 4.8.
>
> Andrey
>
> > 2. Looking inside generate_reg_moves
> it seams to me that this function
> > is not meant to deal with replacing
> memory accesses but only with
> > register replacements. (see inside
> the call to replace_rtx which in
> > my case trys to replace the
> mem accesses inside 136).
> >
> > 3. The (T,1) dep is assumed to take place as if before
> the SMS pass,
> > insn 136 was preceding insn 134:
> >
> > (insn 136 135 137 12 tdscdma_pfu_ccdec.c:292
> > (set (reg/v:HI 248 [
> mappingAddress_i16 ])
> > (unspec:HI [
> >
> (mem:HI (plus:PSI (reg/v/f:PSI 170 [
> curMappingTable_pi16 ])
> >
> (reg:SI 305)) [0 S2
> A16])
> > ] 696))
> 755 {INSN_BUILTIN___loadbyteofs_16} (expr_list:REG_DEAD
> (reg:SI 305)
> > (nil)))
> >
> > (insn 134 133 135 12 tdscdma_pfu_ccdec.c:289
> > (set (mem:HI (plus:PSI (reg/v/f:PSI
> 185 [ ccdecInterim_pi16 ])
> >
> (reg:SI 303)) [0 S2 A16])
> > (unspec:HI [
> >
> (reg/v:HI 244 [ outData_u16 ])
> > ]
> 1752)) 1377 {INSN_BUILTIN___storebyteofs_16}
> (expr_list:REG_DEAD (reg:SI 303)
> > (expr_list:REG_DEAD
> (reg/v:HI 244 [ outData_u16 ])
> > (nil
> >
> > If that would be the case then between 134 and 136
> there would be present
> > also an antidependence of distance 0. Becasue in the
> pipelined schedule,
> > 134 is scheduled before 136 (SCHED_TIME (136) >
> SCHED_TIME (134)) the modulo
> > variable expansion needs to take place as explained
> before.
> >
> > SMS decides to produce a modulo variable expansion in a
> case when is not
> > needed. However, it fails in fulfilling the whole
> modulo variable expansion
> > procedure, covering in this way the possibly incorrect
> behavior described above.
> >
> > regards,
> > Alex
> >
>
>
Re: GNU MPC 1.0 release candidate - Second call for help
On 13.07.2012 20:38, Andreas Enge wrote: Hello, thanks to those who sent us installation reports! On Sat, Jul 07, 2012 at 05:13:39PM +0200, Andreas Enge wrote: We are pleased to announce the immediate availability of the first release candidate for GNU MPC 1.0 at http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 Reports on successful installations and potential problems are very welcome; please include the configuration triple of your platform, and the gcc, gmp and mpfr versions used (these are output at the end of 'make check'). The status of successful and failed builds can be seen at http://www.multiprecision.org/index.php?prog=mpc&page=platforms Unfortunately, several primary and secondary gcc targets are still missing: mipsis64-elf, sparc-sun-solaris2.10, hppa2.0w-hp-hpux11.11, powerpc-ibm-aix5.3.0.0, s390-linux-gnu, i686-apple-darwin. Before the final release of GNU MPC 1.0, We would very much like to make sure that all important gcc target platforms are covered, so your help will be very appreciated. Solaris 10 Sparc GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.7.1 PASS: tget_version === All 64 tests passed === Solaris 8 Sparc GMP: include 5.0.1, lib 5.0.1 MPFR: include 3.0.0-p3, lib 3.0.0-p3 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.1.2 PASS: tget_version === All 64 tests passed === Regards, Rainer
bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Affected versions are 4.7.x and 4.8.0. PR 53912 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 shows the failures in stage 2 for gcc-4.8.0. Most are of the form "error: cast from 'void*' to 'long int' loses precision" or similar. AFAIK a switch to c++ mode is planned for stage 1 as well. So we are in trouble for native x86_64-w64-mingw32 builds. Any suggestions? Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAILDQACgkQoUhjsh59BL4vRwCdH5OXtUzHFGK363QhhSO5cicj IFUAoMHXWtfkL1K9MfqNZ6hNKK87Peu5 =ZtFY -END PGP SIGNATURE-
Re: bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
On Thu, Jul 19, 2012 at 8:48 AM, Rainer Emrich wrote: > > PR 53912 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 shows the failures > in stage 2 for gcc-4.8.0. Most are of the form "error: cast from 'void*' to > 'long int' loses precision" or similar. > > AFAIK a switch to c++ mode is planned for stage 1 as well. So we are in > trouble for native x86_64-w64-mingw32 builds. Any suggestions? I recommend fixing the code. In ggc-common.c change #define POINTER_HASH(x) (hashval_t)((long)x >> 3) to #define POINTER_HASH(x) ((hashval-t)((uintptr_t) x >> 3)) Ian
Re: [Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
Am 19.07.2012 18:12, schrieb redi at gcc dot gnu.org: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 > > --- Comment #5 from Jonathan Wakely 2012-07-19 > 16:12:18 UTC --- > Does changing the definition of POINTER_HASH to use intptr_t instead of long > work? > This works for ggc-common.c. Ian Lance Taylor recommended to use uintptr_t instead, but I haven't tested that. The next failure now is: /SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/./prev-gcc/g++ -B/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/./prev-gcc/ -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/x86_64-w64-mingw32/bin/ -nostdinc++ -B/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs -B/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -I/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/prev-x86_64-w64-mingw32/libstdc++-v3/include -I/SCRATCH/tmp.xipisatGtI/src/gcc-4.8.0/libstdc++-v3/libsupc++ -L/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/SCRATCH/tmp.xipisatGtI/gcc-4.8.0/gcc-4.8.0/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../../src/gcc-4.8.0/gcc -I../../../src/gcc-4.8.0/gcc/. -I../../../src/gcc-4.8.0/gcc/../include -I./../intl -I../../../src/gcc-4.8.0/gcc/../libcpp/include -I/SCRATCH/tmp.xipisatGtI/install/include -I/SCRATCH/tmp.xipisatGtI/install/include -I/SCRATCH/tmp.xipisatGtI/install/include -I../../../src/gcc-4.8.0/gcc/../libdecnumber -I../../../src/gcc-4.8.0/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_INT_GMP -I/SCRATCH/tmp.xipisatGtI/install/include -I/SCRATCH/tmp.xipisatGtI/install/include ../../../src/gcc-4.8.0/gcc/pointer-set.c -o pointer-set.o ../../../src/gcc-4.8.0/gcc/pointer-set.c: In function 'size_t hash1(const void*, long unsigned int, long unsigned int)': ../../../src/gcc-4.8.0/gcc/pointer-set.c:67:32: error: cast from 'const void*' to 'long unsigned int' loses precision [-fpermissive] return ((A * (unsigned long) p) >> shift) & (max - 1); ^ make[3]: *** [pointer-set.o] Error 1
Re: [Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
On Thu, Jul 19, 2012 at 1:32 PM, Rainer Emrich wrote: > ../../../src/gcc-4.8.0/gcc/pointer-set.c: In function 'size_t hash1(const > void*, > long unsigned int, long unsigned int)': > ../../../src/gcc-4.8.0/gcc/pointer-set.c:67:32: error: cast from 'const void*' > to 'long unsigned int' loses precision [-fpermissive] >return ((A * (unsigned long) p) >> shift) & (max - 1); Same fix. s/unsigned long/uintptr_t/ . Ian
Re: Bad gcc/gtype-desc.h generated when using sparse checkout
On 07/15/12 21:53:02, Jonathan Wakely wrote: > [...] > It took me a while to get back to this, but your suggestion worked, > this patch allows bootstrapping to get past cp/lex.o, it hasn't > finished yet so I haven't run the tests: > [...] > Presumably gengtype goes through directories alphabetically, so if it > doesn't find gcc/ada before gcc/c then it creates an invalid > gtype-desc.h We would like to see this patch, or something similar applied. Currently, we subset the GCC source distribution to include only C, C++, and UPC when we build the GUPC (GNU UPC) source code distributions. For some test systems where we port GUPC, the available disk space is restricted, and the additional 600MB or so of space required for the additional languages and test suites might exceed the available quota. If I recall correctly, there was some discussion on this list, or perhaps gcc-patches, as to whether a decision should be made regarding the ability to subset the GCC source tree. If sub-setting is not prohibited, and there are no plans to upgrade/rewrite gengtype and its infrastructure, then something like this patch seems necessary. thanks, - Gary
