Re: Bug in gcc: assignment to non-lvalue
Michiel de Bondt wrote: Using strings to show my point was not a good idea. You can add a field "int number" to the struct and perform similar operations (with = instead of strcpy). But even with strings, gcc should give an error like: "strcpy(const char*, const char*) does not exists". In case of a "typedef char string100[100]", gcc behaves correctly by ringing alarm bells. So it seems to be the . operator that behaves incorrectly. You should distill a minimum and complete testcase that uses = to demonstrate the bug. The example you gave does not assign to an r-value at all, as near as I can tell. As Andrew points out, the array reference will decay to a pointer, which is passed to strcpy. You may want to confirm on comp.lang.c++ or with another C++ compiler that the code is, in fact, invalid. Thanks for looking into this. :)
Bootstrap comparison failure on sparc64/sparc linux
For quite some time now, I've been getting bootstrap comparison failures with trunk on sparc64/sparc linux I kind of guess that they might be related to other big endian bootstrap comparison failures. Would you benefit from me posting something specific from my failures or do you suggest that I just sit still and await some more generic approach being worked on? -- Cheers, /ChJ
Re: Stack parameter - pass by value - frame usage
Ian Lance Taylor wrote: Hariharan Sandanagobalane <[EMAIL PROTECTED]> writes: I looked at an inefficient code sequence for a simple program using GCC's picochip port (not yet submitted to mainline). Are you working with mainline sources? I was not. I tried the same with gcc 4.3 branch and it does fix most of the problems. There are still corner cases where it produces unoptimal code. I will try to figure out whats wrong in those and get back to you. Regards Hari Note that the parameter is being written to the frame in the last 2 instructions above. This, i am guessing is the reason for the get_frame_size() returning 4 later on, though the actual save of the struct parameter value on the stack is being eliminated at later optimization phases (CSE and DCE, i believe). Why does the compiler do this? I vaguely remember x86 storing all parameter values on stack. Is that the reason for this behaviour? Is there anything i can do in the port to get around this problem? At a guess, it's because the frontend decided that the struct was addressable and needed to be pushed on the stack. I thought this got cleaned up recently, though. Ian This email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom they are addressed. If you have received this email in error please notify the sender and delete the message from your system immediately.
Re: porting problem again: ICE in add_clobbers
On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > gcse will never convert a recognizable insn into an unrecognizable > insn. Ok. Do you know of any other reasons why this particular optimization switch would cause this problem? > You still haven't showed us the actual insn which failed to match. > > The problem is that whatever that insn looks like, there is no > define_insn which matches it. For purposes of matching, a > define_expand does not count. One example is (define_expand "bleu" [(use (match_operand 0 "" ""))] "" "expand_branch (LEU, operands[0]); DONE;") which is heavily inspired by the or32 port of version 3.4.4, as is expand_branch(). But this should not need a matching insn, since it ends in a DONE;, right? Or am I missing something again?
RE: function overloading and variadic arguments
On 20 September 2007 20:30, Peter A. Felvegi wrote: > i'd like to hear your comments. Is va_list a typedef for char* on your system, then? What ever happened to it being an alias for __builtin_va_list via __gnuc_va_list? cheers, DaveK -- Can't think of a witty .sigline today
Re: function overloading and variadic arguments
>> i'd like to hear your comments. > > Is va_list a typedef for char* on your system, then? What ever happened to > it being an alias for __builtin_va_list via __gnuc_va_list? i don't know what happened, but it seems like a char*. my system is a debian i636 etch, here are compiler versions: $ gcc-4.3-exp -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --program-suffix=-4.3-exp Thread model: posix gcc version 4.3.0 20070914 (experimental) (GCC) gives 'warning: deprecated conversion from string constant to ‘char*’' $ gcc-4.2 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --program-suffix=-4.2 Thread model: posix gcc version 4.2.1 gives the same warning $ gcc-4.1 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) no warning $ gcc-3.3 -v Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/specs Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug i486-linux-gnu Thread model: posix gcc version 3.3.6 (Debian 1:3.3.6-15) no warning regards, p
Re: porting problem again: ICE in add_clobbers
On Fri, Sep 21, 2007 at 04:53:38PM +0200, Tomas Svensson wrote: > (define_expand "bleu" > [(use (match_operand 0 "" ""))] > "" > "expand_branch (LEU, operands[0]); DONE;") > > which is heavily inspired by the or32 port of version 3.4.4, as is > expand_branch(). > But this should not need a matching insn, since it ends in a DONE;, > right? Wrong. Everything emitted by an expander needs to be matched by an insn pattern. > Or am I missing something again? The construct (define_insn "name_not_beginning_with_asterix" ... probably should have been (define_expand_and_insn "name_not_beginning_with_asterix" ... for clarity. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: porting problem again: ICE in add_clobbers
On Tue, Sep 18, 2007 at 12:54:17PM +0200, Tomas Svensson wrote: > > I have looked at it in gdb and it fails on reaching the > gcc_unreachable() in add_clobbers, which happens because add_clobbers > is called (at combine.c:9576) with an insn_code_number that it does > not recognize. Odd, since add_clobbers() is only called with an insn_code_number that it knows. What is the insn pattern (use "call debug_rtx (pattern)" in gdb) and insn_code_number? > Everything works fine when optimization is turned off. What is it that > gcc does differently when optimizing, that might cause this to happen? Combine only runs when optimization is enabled. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
[RFC] failures found while pounding on GCC trunk
In http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01702.html I describe tools to generate sets of GCC command-line options used to find combinations that don't work together. Using those tools and a setup to build and run (with short test input) individual tests from SPEC CPU2000, I've found the following 7 wrong-code failures and 15 ice-on-valid-code failures on powerpc64-linux. A few of them have several options, but many are just a single change from -O2 or -Os. Before I start minimizing test cases and filing bugs I'd like some feedback about failures that aren't likely to be investigated so I can ignore those for now. There might be combinations that we'd want to disallow. ### # Failures in SPEC CPU2000 tests on powerpc64-linux found by using # command lines generated by GENOPTS. #-- # Run/miscompare failures (wrong-code) #-- # gcc, perlbmk run fails; -m32 -O2 -ftrapv -Os -ftrapv # perlbmk run fails; -m32 # (documented as experimental) -O2 -fsched2-use-superblocks # perlbmk run fails; -m32 -O2 -fno-trapping-math -Os -fno-trapping-math # perlbmk run fails; -m32 -Os -funroll-all-loops # perlbmk run fails; -m32 -Os -funroll-loops -fno-tree-copyrename -fno-tree-dce # gap, gcc, vortex run fails; -m64 -fpack-struct # perlbmk run fails; -m64 -Os -fno-forward-propagate -fforce-addr -fpack-struct #-- # Build failures (mostly ice-on-valid-code) #-- # all tests fail with unrecognizable insn, segfault; -m32/-m64 -O2 -frtl-abstract-sequences -Os -frtl-abstract-sequences # all tests fail with ICE in verify_ssa; -m32/-m64 -O2 -fipa-pta -Os -fipa-pta # all tests fail with ICE in verify_curr_properties; -m32/-m64 -O2 -fno-tree-salias -Os -fno-tree-salias # all tests fail with ICE in verify_curr_properties; -m32/-m64 # (-ftree-scev-cprop is not documented) -O2 -fno-tree-ch -fno-tree-scev-cprop # almost all tests fail with ICE in verify_flow_info; m32/-m64 -O2 -fmodulo-sched -freorder-blocks-and-partition -Os -fmodulo-sched -freorder-blocks-and-partition # almost all tests fail with vector VEC index domain error; -m32/-m64 -O2 -fno-tree-ch -fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-store-copy-prop -fno-tree-vrp # ten tests fail with missing barrier after block with -O2; -m64 # fourteen tests fail with missing barrier after block with -Os; -m64 # (documented as experimental) # failures might be somewhat intermittent -O2 -fsched2-use-superblocks -Os -fsched2-use-superblocks # mesa fails with invalid rtl sharing; -m64 -O2 -fno-trapping-math -Os -fno-trapping-math # crafty fails with ICE in local_cprop_pass; -m32/-m64 -O2 -ftrapv -Os -ftrapv # crafty, vortex fail with multiple or missing defs; -m32/-m64 -O2 -fno-unit-at-a-time # gcc fails with ICE in verify_flow_info; -m32 -Os -fno-forward-propagate -fno-guess-branch-probability -fno-move-loop-invariants -fno-tree-dominator-opts -fno-tree-loop-optimize # gcc fails with missing defs; -m32 -Os -fno-unit-at-a-time # gzip fails with ICE in build_polynomial_chrec; -m32/-m64 -Os -fno-tree-ch -fno-tree-scev-cprop # ammp, gap, gcc, perlbmk, twolf, vortex fail with ICE in # vrp_evaluate_conditional_warnv; -m32/-m64 -Os -fno-tree-copy-prop -fno-tree-dce -fipa-cp # twolf fails with ICE (segfault); -m64 -Os -fsched-stalled-insns # eon build fails with (valid?) error; -m32/-m64 -fpack-struct #-- Janis
Re: [RFC] failures found while pounding on GCC trunk
On 9/21/07, Janis Johnson <[EMAIL PROTECTED]> wrote: > # gap, gcc, vortex run fails; -m64 > -fpack-struct > # eon build fails with (valid?) error; -m32/-m64 > -fpack-struct These above failures are kinda of expected as -fpack-struct does change the ABI. Thanks, Andrew Pinski
gcc-4.3-20070921 is now available
Snapshot gcc-4.3-20070921 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070921/ 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/trunk revision 128656 You'll find: gcc-4.3-20070921.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070921.tar.bz2 C front end and core compiler gcc-ada-4.3-20070921.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070921.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070921.tar.bz2 C++ front end and runtime gcc-java-4.3-20070921.tar.bz2 Java front end and runtime gcc-objc-4.3-20070921.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070921.tar.bz2The GCC testsuite Diffs from 4.3-20070914 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: porting problem again: ICE in add_clobbers
Tomas Svensson wrote: On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: gcse will never convert a recognizable insn into an unrecognizable insn. Ok. Do you know of any other reasons why this particular optimization switch would cause this problem? There are millions of reasons why there might be a problem. You need to do some debugging to analyze the problem. I think the fact that gcse create an insn that caused combine to choke is probably not relevant. Step through combine to see what is going on. add_clobbers should only be called for an insn number that contains clobbers. This is conditional on num_clobbers_to_add, which is set in a recog() call. So step through recog to see why it is being set. This is the variable pnum_clobbers in recog, in the file insn-recog.c. insn-recog.c is created by genrecog.c, but you want to look there only as a last resort. No one else can do this analysis for you as no one else has a copy of your port. But this should not need a matching insn, since it ends in a DONE;, right? Or am I missing something again? This is correct. You need a define_insn to match all RTL emitted during the RTL expansion phase. However, when you have a define_expand which uses a minimal RTL template just to indicate the number of operands, and which does not actually emit this RTL template into any insn, then you do not need a define_insn to match this RTL template. You do need a define_insn to match the RTL emitted by the expand_branch function though. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
