Possible endless loop in lto-wrapper
Hi, in gcc-4.5 lto-wrapper may end up in an endless loop in case of error: if for example a 'maybe_unlink_file' call from 'lto_wrapper_exit' fails it calls 'fatal_perror' which in turn calls 'lto_wrapper_exit' again causing an infinity of lto-wrapper: deleting LTRANS file /tmp/ccWjXUv8.lto.o: No such file or directory error messages on the console. I've solved this by substituting 'maybe_unlink_file' with 'unlink_if_ordinary' whithin the 'lto_wrapper_exit' function. Not sure if this is the best fix but hope it helps. Best Regards, Leandro -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it: http://www.email.it/f Sponsor: Vinci subito fantastici premi, partecipando al gioco "alla faccia degli amici" crea la faccia di chi vuoi tu e gioca! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=9867&d=20091122
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
* Steven Rostedt wrote: > Ingo, Thomas and Linus, > > I know Thomas did a patch to force the -mtune=generic, but just in > case gcc decides to do something crazy again, this patch will catch > it. > > Should we try to get this in now? Very nice example of defensive coding - i like this. I've queued it up for .33 (unless anyone objects) as i think it's too late for .32. Ingo
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote: > Steven Rostedt wrote: >> Ingo, Thomas and Linus, >> >> I know Thomas did a patch to force the -mtune=generic, but just in case >> gcc decides to do something crazy again, this patch will catch it. >> >> Should we try to get this in now? > > I'm sure this makes sense, but a gcc test case would be even better. > If this can be detected in the gcc test suite it'll be found and > fixed long before y'all in kernel land get to see it. That's the > only way to guarantee this never bothers you again. > > H.J., who wrote the code in question, is hopefully looking at why > this odd code is being generated. Once he's done I can put a > suitable test case in the gcc test suite. > See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7 -- H.J.
copyright assignment
Hello. I would like to get the necessary forms for copyright assignment to GCC for future work on GNAT. I was told this is the way to kick off the process. Thanks for the help. - John Nowak
mis-set value for trial in function fill_simple_delay_slots?
Hi : In function fill_simple_delay_slots, there is following codes: >starts here /* If there are slots left to fill and our search was stopped by an unconditional branch, try the insn at the branch target. We can redirect the branch if it works. Don't do this if the insn at the branch target is a branch. */ if (slots_to_fill != slots_filled && trial && JUMP_P (trial) && simplejump_p (trial) && (target == 0 || JUMP_LABEL (trial) == target) && ...)
Re: Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
Hi M, On Wed, 18 Nov 2009, g...@coreland.ath.cx wrote: > I'm now doing regular builds/tests from SVN of GCC, G++ and GNAT on > FreeBSD x86_64 and publishing the build logs at: > > http://gcc.coreland.ath.cx would you mind submitting your test results to gcc-testresu...@gcc.gnu.org going forward? This is the canonical point for gathering all of these, and developers check that one for results and particular failures or passes. (See http://gcc.gnu.org/lists.html for an overview of all lists, see http://gcc.gnu.org/install/test.html for instructions.) Thanks, Gerald
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
H.J. Lu wrote: > On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote: >> Steven Rostedt wrote: >>> Ingo, Thomas and Linus, >>> >>> I know Thomas did a patch to force the -mtune=generic, but just in case >>> gcc decides to do something crazy again, this patch will catch it. >>> >>> Should we try to get this in now? >> I'm sure this makes sense, but a gcc test case would be even better. >> If this can be detected in the gcc test suite it'll be found and >> fixed long before y'all in kernel land get to see it. That's the >> only way to guarantee this never bothers you again. >> >> H.J., who wrote the code in question, is hopefully looking at why >> this odd code is being generated. Once he's done I can put a >> suitable test case in the gcc test suite. >> > > See: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7 I saw that, but does it mean you're going to investigate? There is no obvious reason why -mtune=generic should affect code generation in this way, but it does. Andrew.
How to define PSImode for a target?
Hi, While working on a port for my custom target I'm looking for some advice on how to define a smaller-than-integer scalar mode. I'd like to use it together with __attribute__((__libgcc_cmp_return__)) mode attribute. In my target xx-modes.def file I have PARTIAL_MODE_INT(SI) defined. And my TARGET_LIBGCC_CMP_RETURN_MODE hook is set to a function returning PSImode. However, compilation of the libgcc fails in libgcc2.h at line 172 with an error message: no data type for mode libgcc_cmp_return (the gcc version I'm working on is 4.4.1). PARTIAL_MODE_INT seems to be kind of undocumented feature. Can anybody suggest the steps required to use it properly? Sincerely, -- Lev.
Re: Impressively difficult to compile code for GNAT
> The code is available here: > > http://git.coreland.ath.cx/gitweb.cgi?p=pfseudo/.git;a=summary > $ git clone http://git.coreland.ath.cx/pfseudo/.git See http://gcc.gnu.org/bugs for instructions on how to report bugs. -- Eric Botcazou
gcc-4.3-20091122 is now available
Snapshot gcc-4.3-20091122 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20091122/ 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 154425 You'll find: gcc-4.3-20091122.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20091122.tar.bz2 C front end and core compiler gcc-ada-4.3-20091122.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20091122.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20091122.tar.bz2 C++ front end and runtime gcc-java-4.3-20091122.tar.bz2 Java front end and runtime gcc-objc-4.3-20091122.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20091122.tar.bz2The GCC testsuite Diffs from 4.3-20091115 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: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote: > H.J. Lu wrote: >> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote: >>> Steven Rostedt wrote: Ingo, Thomas and Linus, I know Thomas did a patch to force the -mtune=generic, but just in case gcc decides to do something crazy again, this patch will catch it. Should we try to get this in now? >>> I'm sure this makes sense, but a gcc test case would be even better. >>> If this can be detected in the gcc test suite it'll be found and >>> fixed long before y'all in kernel land get to see it. That's the >>> only way to guarantee this never bothers you again. >>> >>> H.J., who wrote the code in question, is hopefully looking at why >>> this odd code is being generated. Once he's done I can put a >>> suitable test case in the gcc test suite. >>> >> >> See: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7 > > I saw that, but does it mean you're going to investigate? There is > no obvious reason why -mtune=generic should affect code generation > in this way, but it does. > Why not, there is static const unsigned int x86_accumulate_outgoing_args = m_AMD_MULTIPLE | m_ATOM | m_PENT4 | m_NOCONA | m_PPRO | m_CORE2 | m_GENERIC; -mtune=generic turns on -maccumulate-outgoing-args. -- H.J.
