Re: Experimental Patchwork setup
On Wed, 09 Jun 2010 08:13:02 +0200 Paolo Bonzini wrote: > Another point about (1): I believe patchwork should *not* track most of > the branch patches, and the commit detection shouldn't care about > release branch commits, only trunk. This is because those are 99% of > the time for trunk too, and whether the patches went on the release > branches is effectively already tracked via bugzilla. It would be very nice, though, to be able to easily get a list of patches that have been committed to a release branch since the last version. I know it's already possible, but trolling through gcc-bugs, gcc-patches, svn logs and bugzilla gets a bit time consuming. -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
ARM FLOOR_MOD_EXPR?
Do FLOOR_DIV_EXPR and FLOOR_MOD_EXPR work on ARM, for 64bit signed integer? I have a front end (sort of), using gcc 4.3, generates trees, doesn't work. type_for_mode(TImode) is NULL and that is dereferenced. I realize TRUNC_* would be far more "normal", but I can't change that. I guess I'll just go back to generating function calls. - Jay
Re: GCC plugin support when using Ada
On Fri, Jun 18, 2010 at 10:32 PM, PeteGarbett wrote: > > I see nothing in the GCC 4.5 release notes about > plugin support being language specific, and yet if I using the treehydra > plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra > notes), I get this > > gnat1: warning: command line option > "-fplugin=/home/linux/gcc-dehydra/dehydra/gcc_treehydra.so" is valid for > C/C++ but not for Ada > > I assume the plan is to have something in the GCC 4 series be agnostic > about what front end has generated your GIMPLE. Is this correct? > I'd like to be able to analyse GIMPLE structures generated from gnat. In GCC 4.5 plugin support is not language specific. This must be a "patched GCC 4.3.4 as per the dehydra notes" issue. Richard. > > > > > > > > > > >
Re: GCC plugin support when using Ada
Hi PeteGarbett, I see nothing in the GCC 4.5 release notes about plugin support being language specific, and yet if I using the treehydra plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra notes), I get this I use plugins with Ada all the time, with gcc-4.5, and it works fine for me. Ciao, Duncan.
gcc-4.6-20100619 is now available
Snapshot gcc-4.6-20100619 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100619/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 161038 You'll find: gcc-4.6-20100619.tar.bz2 Complete GCC (includes all of below) gcc-core-4.6-20100619.tar.bz2 C front end and core compiler gcc-ada-4.6-20100619.tar.bz2 Ada front end and runtime gcc-fortran-4.6-20100619.tar.bz2 Fortran front end and runtime gcc-g++-4.6-20100619.tar.bz2 C++ front end and runtime gcc-java-4.6-20100619.tar.bz2 Java front end and runtime gcc-objc-4.6-20100619.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.6-20100619.tar.bz2The GCC testsuite Diffs from 4.6-20100612 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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: Can GCC emit debug information to support debug uninitialized local variables
asmwarrior writes: > My question is: Is there any possible that GCC can emit some debug > information to indicate that one variable is initialed or not.(at > least in the DEBUG build mode) You didn't mention which version of gcc you are testing. With current gcc see if the -fvar-tracking option helps. Ian
Re: Can GCC emit debug information to support debug uninitialized local variables
On 2010-6-20 14:18, Ian Lance Taylor wrote: asmwarrior writes: My question is: Is there any possible that GCC can emit some debug information to indicate that one variable is initialed or not.(at least in the DEBUG build mode) You didn't mention which version of gcc you are testing. With current gcc see if the -fvar-tracking option helps. Ian Thanks for your time and help. I'm currently using two versions of GCC under Windows. (MinGW GCC 4.4.4 and MinGW GCC 4.5). The gdb I built was (gdb cvs 20100613 and gdb cvs 20100618, both with python support), but both of the gdb will get crash when I run the "info locals" command. I'm not sure I have catch the core idea about my question, because I found an old post here: http://gcc.gnu.org/ml/gcc/2007-04/msg00138.html ,there, you suggest add the DW_AT_start_scope somewhere. As you said, if I add the "-fvar-tracking" option, there will have debug information included. Then, GDB can use this information to avoid to print the uninitialized local variables? Thanks. Asmwarrior ollydbg from codeblocks' forum.
