Question about Doloop
Hello,
Doloop optimization fails to be applied on the following inner loop
when compiling for PowerPC (GCC -r162294) due to:
Doloop: number of iterations too costly to compute.
I do not understand why as the number of iterations is max_cols and I
appreciate an explanation.
Thanks,
Revital
11 while (--max_rows >= 0)
12 {
13 inptr = *inbuf++;
14 outp = outbuf[0][rows];
15 rows++;
16
17 for (y = 0; y < max_cols; y++)
18 {
19 k = ((int) (inptr[0]));
20 inptr += 3;
21
22 outp[y] = (unsigned char) ((inarr[k]) >> 16);
23 }
24 }
>From Doloop dump:
Analyzing operand (reg/f:DI 246 [ D.2082 ]) of insn (insn 118 116 119 5
test1.c:17 (set (reg:CC 272)
(compare:CC (reg/v/f:DI 199 [ inptr ])
(reg/f:DI 246 [ D.2082 ]))) 535 {*cmpdi_internal1}
(expr_list:REG_DEAD (reg/f:DI 246 [ D.2082 ])
(nil)))
invariant (reg/f:DI 246 [ D.2082 ]) (in DI)
Loop 2 is simple:
simple exit 5 -> 6
number of iterations: (mult:DI (plus:DI (minus:DI (reg/f:DI 246
[ D.2082 ])
(reg/v/f:DI 199 [ inptr ]))
(const_int -3 [0xfffd]))
(const_int -6148914691236517205 [0xaaab]))
upper bound: -1
Doloop: number of iterations too costly to compute.
(See attached file: test1.c)
test1.c
Description: Binary data
DFP regression on FreeBSD
Between September 2nd http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00197.html and September 3rd http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00282.html DFP support broke quite a bit on FreeBSD. Failures happen at link time. The following is a typical example for FAIL: g++.dg/compat/decimal/pass-1 cp_compat_x_tst.o-cp_compat_y_tst.o link Executing on host: /usr/nabil-files/pfeifer/OBJ-0905-0148/gcc/testsuite/g++/../../g++ -B/usr/nabil-files/pfeifer/OBJ-0905-0148/gcc/testsuite/g++/../../ cp_compat_main_tst.o cp_compat_x_tst.o cp_compat_y_tst.o -nostdinc++ -I/usr/nabil-files/pfeifer/OBJ-0905-0148/i386-unknown-freebsd8.1/libstdc++-v3/include/i386-unknown-freebsd8.1 -I/usr/nabil-files/pfeifer/OBJ-0905-0148/i386-unknown-freebsd8.1/libstdc++-v3/include -I/usr/test/gcc/libstdc++-v3/libsupc++ -I/usr/test/gcc/libstdc++-v3/include/backward -I/usr/test/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -L/usr/nabil-files/pfeifer/OBJ-0905-0148/i386-unknown-freebsd8.1/./libstdc++-v3/src/.libs -B/usr/nabil-files/pfeifer/OBJ-0905-0148/i386-unknown-freebsd8.1/./libstdc++-v3/src/.libs -L/usr/nabil-files/pfeifer/OBJ-0905-0148/i386-unknown-freebsd8.1/./libstdc++-v3/src/.libs -L/usr/nabil-files/pfeifer/OBJ-0905-0148/i386-unknown-freebsd8.1/./libiberty -lm -o g++-dg-compat-decimal-pass-1-01.exe(timeout = 300) cp_compat_x_tst.o(.text+0x15): In function `checkd32(decimal32, decimal32)': : undefined reference to `__dpd_addsd3' cp_compat_x_tst.o(.text+0x24): In function `checkd32(decimal32, decimal32)': : undefined reference to `__dpd_nesd2' cp_compat_x_tst.o(.text+0xbbb): In function `checkd64(decimal64, decimal64)': : undefined reference to `__dpd_a3' cp_compat_x_tst.o(.text+0xbd5): In function `checkd64(decimal64, decimal64)': : undefined reference to `__dpd_nedd2' If filed this as PR 45547. Not sure where to start looking for a root cause / fix. Andreas, perhaps your changes around configure? Any other ideas what to look into? Gerald
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 9/4/2010 9:23 PM, NightStrike wrote: > We would like x86_64-w64-mingw32 to become a secondary target for 4.6. Who is "we" in this context? > What has to be checked off for that to happen? It's not so much a matter of "checking off". It's a combination of the SC's perception of the importance of the target and the technical stats of the port. I can raise the issue with the SC, if you like, but, personally, I'm not sure that 64-bit Windows is significant enough as a target platform for GCC to merit that status. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Sun, Sep 5, 2010 at 2:03 PM, Mark Mitchell wrote: > On 9/4/2010 9:23 PM, NightStrike wrote: > >> We would like x86_64-w64-mingw32 to become a secondary target for 4.6. > > Who is "we" in this context? Sorry, that would be Kai Tietz, myself, and the entire mingw-w64.sf.net project. >> What has to be checked off for that to happen? > > It's not so much a matter of "checking off". It's a combination of the > SC's perception of the importance of the target and the technical stats > of the port. I can raise the issue with the SC, if you like, but, > personally, I'm not sure that 64-bit Windows is significant enough as a > target platform for GCC to merit that status. Ouch. What criteria do you use for that analysis? I will endeavor to prove our importance :) Note that 32-bit windows is already a secondary platform.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 9/5/2010 11:23 AM, NightStrike wrote: >> It's not so much a matter of "checking off". It's a combination of the >> SC's perception of the importance of the target and the technical stats >> of the port. I can raise the issue with the SC, if you like, but, >> personally, I'm not sure that 64-bit Windows is significant enough as a >> target platform for GCC to merit that status. > > Ouch. What criteria do you use for that analysis? I can't say what criteria the SC uses; I don't know what basis other SC members use to decide. I use my own instincts (which, I admit, is not a scientific basis) for deciding. I spend much of my life talking to various stakeholders in GCC, and so I have a reasonable feel for where people are presently using GCC, and where they would like to use it. Thus far, I've certainly heard of some interest in 64-bit Windows, but nowhere near as much as 32-bit Windows or Cygwin. I certainly don't mind raising the issue, if you want me to do that; I'm happy to carry messages to the SC independent of my own opinions. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Sun, Sep 5, 2010 at 2:29 PM, Mark Mitchell wrote: > On 9/5/2010 11:23 AM, NightStrike wrote: > >>> It's not so much a matter of "checking off". It's a combination of the >>> SC's perception of the importance of the target and the technical stats >>> of the port. I can raise the issue with the SC, if you like, but, >>> personally, I'm not sure that 64-bit Windows is significant enough as a >>> target platform for GCC to merit that status. >> >> Ouch. What criteria do you use for that analysis? > > I can't say what criteria the SC uses; I don't know what basis other SC > members use to decide. > > I use my own instincts (which, I admit, is not a scientific basis) for > deciding. I spend much of my life talking to various stakeholders in > GCC, and so I have a reasonable feel for where people are presently > using GCC, and where they would like to use it. Thus far, I've > certainly heard of some interest in 64-bit Windows, but nowhere near as > much as 32-bit Windows or Cygwin. > > I certainly don't mind raising the issue, if you want me to do that; I'm > happy to carry messages to the SC independent of my own opinions. Yes, definitely bring it up. I'm just trying to get more cards stacked in our favor :)
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 9/5/2010 11:34 AM, NightStrike wrote: >> I certainly don't mind raising the issue, if you want me to do that; I'm >> happy to carry messages to the SC independent of my own opinions. > > Yes, definitely bring it up. I'm just trying to get more cards > stacked in our favor :) OK, I've asked the SC to consider it. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
gcc-4.3-20100905 is now available
Snapshot gcc-4.3-20100905 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100905/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 163880 You'll find: gcc-4.3-20100905.tar.bz2 Complete GCC (includes all of below) MD5=1f6d3a527b1e8ece246e85e461ea3e03 SHA1=e91e493e248af991df9688b5765e1cb653f13440 gcc-core-4.3-20100905.tar.bz2C front end and core compiler MD5=a42a3e8daa5d59d5898095dc82d2a971 SHA1=2f538dad2e40f5568d962dc76ec4ec1dc6dc6ae0 gcc-ada-4.3-20100905.tar.bz2 Ada front end and runtime MD5=7af2ff25ee70ed404090b6ffec260681 SHA1=80fef0f9a790bfaf2d448bc9028aa4870ca9e5f4 gcc-fortran-4.3-20100905.tar.bz2 Fortran front end and runtime MD5=fea0a6a7269155e789e5ddb2ba95be95 SHA1=b71b9b41f15e47058e8917b62994d151262babdc gcc-g++-4.3-20100905.tar.bz2 C++ front end and runtime MD5=cbce9fc66ad07beafcb2188b548807be SHA1=8a985d0bc124735872e0a4883e0bfea693b39740 gcc-java-4.3-20100905.tar.bz2Java front end and runtime MD5=f7a2a47df477eb61d7d7ca88cde95228 SHA1=35a0a72ab1ea834f146626577c8dc56be8bca373 gcc-objc-4.3-20100905.tar.bz2Objective-C front end and runtime MD5=c8909b2606aca59321990487855ad5f6 SHA1=8f707135bff9649b50f98f734980683eb1aff3e1 gcc-testsuite-4.3-20100905.tar.bz2 The GCC testsuite MD5=6004dddffc4962d1cde09afc31030f25 SHA1=530cf7de2b4c1a63e3ec0b7f05d8b5ed0fcbfde8 Diffs from 4.3-20100829 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Sun, 5 Sep 2010, NightStrike wrote: > Yes, definitely bring it up. I'm just trying to get more cards > stacked in our favor :) Do you have a pointer to testresults you'd like us to use for reference? >From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. Gerald
Re: End of GCC 4.6 Stage 1: October 27, 2010
Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html === g++ Summary === # of expected passes24917 # of unexpected failures18 # of expected failures 150 # of unsupported tests 587 === gcc Summary === # of expected passes66682 # of unexpected failures49 # of unexpected successes 3 # of expected failures 199 # of unresolved testcases 3 # of unsupported tests 1311 === gfortran Summary === # of expected passes35917 # of unexpected failures36 # of expected failures 40 # of unsupported tests 101 === obj-c++ Summary === # of expected passes489 # of unexpected failures54 # of expected failures 3 # of unsupported tests 15 === objc Summary === # of expected passes658 # of unexpected failures84 # of unsupported tests 20
on how to compile gcc-4.6 correctly?
Hi, all, I'm using gentoo distribution (including gmp/mpfr/mpc) that could compile gcc-4.5.0, 4.5.1, and many snapshots correctly, including the recent one gcc-4.5-20100902, but when I tried to compile gcc-4.6, any snapshot version, even recent gcc-4.6-20100904, it always failed, the recent one failure compiling is: ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokdeclarator': ../../gcc-4.6-20100904/gcc/c-decl.c:5533: warning: format not a string literal and no format arguments ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokparms': ../../gcc-4.6-20100904/gcc/c-decl.c:6194: warning: format not a string literal and no format arguments ../../gcc-4.6-20100904/gcc/c-decl.c:7025:64: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_struct': ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: 'ggc_alloc_cleared_lang_type' undeclared (first use in this function) ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: (Each undeclared identifier is reported only once ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: for each function it appears in.) ../../gcc-4.6-20100904/gcc/c-decl.c:7308:62: error: macro "ggc_alloc_cleared_lang_type" passed 1 arguments, but takes just 0 ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_enum': ../../gcc-4.6-20100904/gcc/c-decl.c:7308: error: 'ggc_alloc_cleared_lang_type' undeclared (first use in this function) make: *** [c-decl.o] Error 1 I don't know what happened with that? When I search the 'ggc_alloc_cleared_lang_type' macro, it really doesn't exist in the gcc-4.6-20100904 source, nor under /usr/include, so what is that macro real dependency? the prerequisites page seems not help me, http://gcc.gnu.org/install/prerequisites.html Who have successfully build gcc-4.6 please help me, or have any clue, I have searched that ggc_alloc_cleared_lang_type through google, but didn't find out any meaningful results, please make sure have my email address on cc-list that I can receive your email, because I didn't subscribe such high volume mailing list, Thank you very much, -- Dennis, from Singapore
Re: structures & param_structures in gengtype
2010/9/2 Basile Starynkevitch : > Hello Laurynas, Diego & all the list. > > A precise question about gengtype (the current trunk one) > > I have the impression that every member of the 'param_structs' variable > in gengtype.c (viewed as a linked list of types linked thru their next > field) is also a member of the 'structures' variable in gengtype.c > > Could you confirm that impression? That's my recollection too. > Bonus question, why? IIRC, the shared data structures are created once, and just have incoming pointers from both these two variables. IMHO that's intuitive. Somebody else might have a better explanation, and if they do, bonus points for you if you turn it into a comment inside gengtype.c ;) -- Laurynas
Re: structures & param_structures in gengtype
On Mon, 6 Sep 2010 06:36:48 +0300
Laurynas Biveinis wrote:
> 2010/9/2 Basile Starynkevitch :
> > Hello Laurynas, Diego & all the list.
> >
> > A precise question about gengtype (the current trunk one)
> >
> > I have the impression that every member of the 'param_structs' variable
> > in gengtype.c (viewed as a linked list of types linked thru their next
> > field) is also a member of the 'structures' variable in gengtype.c
> >
> > Could you confirm that impression?
>
> That's my recollection too.
>
Thanks for the prompt reply. Do you have a more precise understanding of how
does that happen? I was not fully able to understand that. What routines are
adding to both lists?
And I am asking because I think this is the remaining bug in the
gengtype-state.c file which would effectively make gengtype state persistent.
> > Bonus question, why?
>
> IIRC, the shared data structures are created once, and just have
> incoming pointers from both these two variables. IMHO that's
> intuitive. Somebody else might have a better explanation, and if they
> do, bonus points for you if you turn it into a comment inside
> gengtype.c ;)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
