[LTO, RFA] Re: [PATCH] Fix PR42531: lto generates invalid assembler ".section" directives.
[ Redirecting to the main list. Are any of the LTO maintainers able to comment on this? ] Background: We have a problem on non-ELF platforms, because LTO generates section names with asterisks in them (based on the DECL_ASSEMBLER_NAME of various decls), which may be OK for section names within ELF format containers, but isn't allowed on (at least some) non-ELF platform(s) for the name of the section (in the native object format) containing the ELF data. H.J. Lu wrote: > On Wed, Dec 30, 2009 at 9:02 AM, Dave Korn >> gcc/ChangeLog: >> >>* lto-streamer-out.c (produce_asm): Skip any leading asterisk when >>using DECL_ASSEMBLER_NAME to generate a section name. >>(copy_function): Likewise. >> >> >> Bootstrapped and tested on i686-pc-cygwin; no new FAILs and resolves four >> FAILs arising from gcc.c-torture/compile/2009-1.c. Ok? >> > > The fix is wrong/incomplete. See my comments in > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42531 Ah, I think "incomplete" is the most likely option. Sorry for not noticing this; the test FAILs on all non-ELF platforms either way, because it requires symbol visibility support, which doesn't exist elsewhere. Looking at the code the issue with asterisks seems to have been handled in an ad-hoc fashion, so there is perhaps yet another place generating section names, this time as reference rather than definition, that needs to skip asterisks. Rather than continue tracking them down one by one, I will try modifying lto_get_section_name() itself to skip a leading asterisk, which might have been the better approach to try in the first place. I'll bootstrap it on a linux system and see if it solves these new FAILs. I don't mind reverting the patch I applied, if anyone wants; if the new approach works it would obviate the need for it. However it shouldn't be harmful once the new patch is applied, which shouldn't take too long to determine, so I won't revert it immediately unless anyone specifically asks. cheers, DaveK
gcc-4.5-20091231 is now available
Snapshot gcc-4.5-20091231 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091231/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 155540 You'll find: gcc-4.5-20091231.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20091231.tar.bz2 C front end and core compiler gcc-ada-4.5-20091231.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20091231.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20091231.tar.bz2 C++ front end and runtime gcc-java-4.5-20091231.tar.bz2 Java front end and runtime gcc-objc-4.5-20091231.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20091231.tar.bz2The GCC testsuite Diffs from 4.5-20091224 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
gcc-2.95 OK, gcc-{3,4}.X not OK
I've got a bit of a quandry here and would like the advice of people who are more experienced than I am at C programming and debugging. We've got a legacy application that compiles and runs fine using the following compilers/platforms: HP-UX 11.23 (PA-RISC) ANSI-C and aC++ C.11.23.04 HP-UX 11.31 (ia64)HP C/aC++ B3910B A.06.23 [May 18, 2009] Debian "squeeze" i686 gcc-2.95 Here is some debugging output during a runtime parse of the application's custom scripting language after compiling with gcc-2.95: 'encountered _endif_; leaving gen_if() '*cmd->cmd' is '134523664' ' cmd->op' is '200' ' flags'is '0' ' pc' is '200' 'tokenbuf' is 'endif' ' pcptr ' is '155572084' '*pcptr ' is '0' ' pcptr->code' is '155572068' '*pcptr->code' is '200' ' pc' is '155572068' '*pc' is '200' ' pcptr->code->op' is '200' calling '[while]parse_cmd' in parse_body in parse_cmd(): 'tokenbuf [before tokenize()]' is 'end' 'tokenbuf [after tokenize()]' is 'end' Database ready 20:53:08 The problem is that gcc-3.X and gcc-4.X compilers generate code (no matter the optimization level) that fails at runtime like this: 'encountered _endif_; leaving gen_if() '*cmd->cmd' is '134523035' ' cmd->op' is '200' ' flags'is '0' ' pc' is '200' 'tokenbuf' is 'endif' ' pcptr ' is '160593780' '*pcptr ' is '0' ' pcptr->code' is '0' Segmentation fault If the bug was a basic programming error, one would expect a runtime failure (dereferencing a NULL pointer) no matter which compiler was used. The application compiles cleanly with no warnings using "-Wall". Were there any transition issues with the newer gcc compilers of which I may not be aware? Thanks, Andris
