Summary: | [4.6/4.7/4.8/4.9] indirect function call with a yet undetermined callee for stdio.h functions (-O1) (was:games-emulation/zsnes fails with gcc-4.6) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | [OLD] Games | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alex, esigra, O01eg, pacho, xarthisius |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 346809 | ||
Attachments: | Build log |
Description
Diego Elio Pettenò (RETIRED)
2011-04-27 00:01:15 UTC
cannot reproduce here Ok. I did reproduce it. It does not seems to me a parallel make. It is a problem with the FORTIFY_SOURCE and the new compiler. Compiling one of the source file generated by parsegen (in zsnes) the compiler raises a lot of warning and does not generate any code. This is one of that warning /usr/include/bits/stdio2.h:96:1: sorry, unimplemented: inlining failed in call to 'fprintf': indirect function call with a yet undetermined callee cfg.c:1140:7: sorry, unimplemented: called from here you can do manually by running the following command: gcc -I. -D__UNIXSDL__ -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DNO_PNG -D__RELEASE__ -O1 -o cfg.o -c cfg.c Normally there is no problem with that ebuild as the FORTIFY SOURCE is disabled there, but I guess you have a gcc that does not respect the -U_FORTIFY_SOURCE Don't know what I could do with this bug. Assign to gcc maintainers? I reduced the code to: cfg.c: #include <stdio.h> static void w_i(void *fp, int (*outf)(void *, const char *, ...)) { outf(fp, ";%s\n", " - EOF -"); } void write_cfg() { FILE *fp = 0; w_i(fp, (int (*)(void *, const char *, ...))fprintf); } ------------------ gcc -O1 -o cfg.o -c cfg.c cfg.c: In function 'write_cfg': /usr/include/bits/stdio2.h:96:1: sorry, unimplemented: inlining failed in call to 'fprintf': indirect function call with a yet undetermined callee cfg.c:4:7: sorry, unimplemented: called from here It does compile if I switch to gcc-4.5 or I put -U_FORTIFY_SOURCE -U_FORTIFY was broken in the first 4.6 patchset but it has been fixed for p1.1 and later, so you can close this bug unless you want to fix the underlying issue. (In reply to comment #4) > -U_FORTIFY was broken in the first 4.6 patchset but it has been fixed for p1.1 > and later, so you can close this bug unless you want to fix the underlying > issue. I build again gcc and tested with the same cfg.c program. It is still failing with the same error. I guess that the problem is with inlining and not with FORTIFY. FORTIFY is just using inline for its job. You said it works with -U_FORTIFY_SOURCE, which the ebuild already uses. So it's up to you if you want to leave the workaround in or fix the bug in your package. It's not a toolchain issue. i think the example in comment #3 shows that is a toolchain issue ... Any news on this? @comment 8: well, as Ryan decided to hijack my gcc bug (PR39333) for bug 360513, I've decided to reacquire it for this bug and attached a trimmed down test case from comment 3. Now, I think, it's up to gcc upstream. You'll have to explain to me what this bug has to do with that PR, seeing as they seem to be about completely different things. @comment 10: well, it's hard to tell if this bug is the *same* problem as the PR, but honestly, the same thing can be said about the PR and bug 360513. Now, what do this bug and the PR have in common ? That's easy - something goes wrong in regard of inlining. That's a pretty general definition. There are 800 other bugs in upstream's bugzilla that it would also fit. I drew a link between bug #306513 and PR39333 when the exact same experiments that you attempted led to the same results with my testcase. This is not the same bug. OK, let's just agree we both still aren't sure what exactly is going wrong there, but... a) the original problem there *seemed* fixed with gcc 4.4.0 b) in the original problem, inlining caused "wrong code", just as (it seems) in bug 360513, while here it fails to accept proper code while inlining is forced (though) c) -fipa-cp might just be a coincidence, then again, maybe not The bottom line is that without a reduced testcase, bug 360513 won't be getting anywhere anyway, while now, there's a highly reduced testcase for this bug. (In reply to comment #13) > OK, let's just agree we both still aren't sure what exactly is going wrong > there, but... > > a) the original problem there *seemed* fixed with gcc 4.4.0 > b) in the original problem, inlining caused "wrong code", just as (it seems) in > bug 360513, while here it fails to accept proper code while inlining is forced > (though) > c) -fipa-cp might just be a coincidence, then again, maybe not > > The bottom line is that without a reduced testcase, bug 360513 won't be getting > anywhere anyway, while now, there's a highly reduced testcase for this bug. I'm not so sure it is valid code, but I don't know. ZSNES has a couple other issues that make it impossible to build with fortification enabled anyways. I would suggest opening a new PR for this. At least then someone will actually look at it. Well, as for zsnes and _FORTIFY_SOURCE, I don't recall a full list, only instance I do recall, is a minor case of abuse, where instead of array[MAX_SIZE+ind], they should have used array+(sizeof(*array)*(MAX_SIZE+ind)) (or something similar). As for the other thing, in the reduced testcase, I've attached there, nothing seems to be *obviously* wrong with the code, yet it fails. I eventually decided to follow your advice and filed a new separate bug. In the process, I've stumbled on an interesting result - this failure can be reproduced in gcc 4.5.3 - see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50506. Hmm. Strange. Compile without problems. What is the status of this with gcc-4.6.3? (In reply to comment #18) > What is the status of this with gcc-4.6.3? dunno if it counts, but for me using: gcc (Gentoo 4.6.3 p1.6, pie-0.5.2) 4.6.3 on amd64 - problem mentioned in comment 3 still exists, but it compiles fine when using -O{0,2,3,s} - games-emulation/zsnes compiles fine PS: comment3 compiles fine on gcc-4.7.1 (In reply to comment #20) > PS: comment3 compiles fine on gcc-4.7.1 Odd, cause reduced testcase still fails for me with 4.7.2 (from 12 Oct 2012) with -O1 and glibc 2.15-r3. It appears that this bug is one of the last three blocking gcc-4.6 stabilization. It's unclear from the comments if anyone understands and/or is seriously working on this since March, but the zsnes seems to be fine. If there is no ebuild that's actually broken right now, may I suggest that this be removed from the list of blockers for 4.6? I've noted something interesting. In gcc-4.7.2-patches-1.3.tar.bz2 tarball, there's 93_all_pr33763_4.7.3_extern-inline.patch. It doesn't help with this problem, but the reduced testcase in PR33763 is very much alike to the reduced testcase for this issue and commenting out '__attribute__ ((always_inline))' in the reduced testcase for this problem makes the code accepted. Anyone has idea about this ? Your testcase passes with 4.9 after this commit: http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f0d26d578d94a3fafc81d191d2168ab3517b3f0e This is the fix for bug #496216 and I hope to get it in 4.8 as well. (In reply to Ryan Hill from comment #24) > Your testcase passes with 4.9 after this commit: > http://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=f0d26d578d94a3fafc81d191d2168ab3517b3f0e > > This is the fix for bug #496216 and I hope to get it in 4.8 as well. Well, I'm honestly surprised. Thank you for still having interest in this bug, despite its corner-case nature. (In reply to Ryan Hill from comment #24) that commit is in gcc-4.9.3 which is stable now |