Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: SourceForge.net <noreply@so...> - 2008-12-29 22:43:38
|
Bugs item #2472264, was opened at 2008-12-28 03:42 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2472264&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: linker Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Borley (sjborley) Assigned to: Nobody/Anonymous (nobody) Summary: linking fails due to an assert added at #5292 Initial Comment: I'm getting what appear to be getting a related problem to #2466950 (in sdcc rev #5303). ... /Users/sdcc-builder/build/sdcc-build/orig/sdcc/as/link/mcs51/../lkaomf51.c:575: failed assertion `res == buff' Looks like an assert was added after an an fgets() in rev #5292 and this is breaking the linking. In sdcc/as/link/mcs51/../lkaomf51.c we have ... while(!feof(CDBin)) { char *res; res = fgets(buff, sizeof(buff)-1, CDBin); assert(res == buff); if(!feof(CDBin)) switch(buff[0]) { .... } } ... Looks to me that the assert triggers for a quite valid, natural exit of this loop when eof is reached. I think the assert should be removed, or perhaps changed to... assert(ferror(CDBin) == 0); which should pick up error conditions but not eof (not tested). ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2008-12-29 23:43 Message: > If they are just copies, there is no need to merge anything ;-) . And if > they cause problems, should we not attempt to fix them? They were just copies, but they are not any more, so they have to be merged from now on :( And they don't cause problems. If they would, they should be fixed in gcc too, so the proper way wold be to report the bug to gcc team and then marge (copy) the fix back to sdcc (at least in theory ;) ) > This partially depends on ones definition of "being broken". > My "fix" was an attempt to catch more error conditions early rather than > silently ignore them, and an interrupted, short write resulting in some > broken output file could be a rare but annoying compiler bug. I admit that > the asserts fire more often than I hoped and that they should be removed, > but on the long run, we should properly check the return values. Maybe we > need another set of wrappers Safe_fgets, Safe_fwrite, ...? I understand your intent and agree with you. The problem is that even things that seems trivial often need to be well considered. It happened many times to me too and I'm sure it will happen again ;) > What I do not quite understand: I ran the regression tests on my box and > the compile farm runs them as well---successfully. Do they not use the > linker, possibly due to them consisting of only one source file each? It seems that this happens only with -z "Produce SDCdb debug as file[cdb]" command line option > The warnings occur using unmodified sdcc Makefiles on my fully patched > Ubuntu 8.10 with gcc 4.3.2 (I guess) and a recent glibc (>= 2.3 according > to others having the same problems): the libc-headers included in that > release add __attribute__((warn_unused_result)) to many functions, whose > result we choose to ignore. gcc 4.3.2 is used for cross-compiling windows binaries on snapshot build machine, but I haven't seen such warnings. I'll do some further investigations... Raphael, I hope I didn't offend you. It definitely wasn't my intent. If I did, please accept my apologies. Borut ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2008-12-29 14:28 Message: I agree with Borut as to revert the changes (I will try to get it done this evening, but feel free to do it if you want to), but ... > which are just copies of GCC's cpp, which make > merging from GCC to SDCC mode difficult. If they are just copies, there is no need to merge anything ;-) . And if they cause problems, should we not attempt to fix them? > "If It's Not Broken, Don't Fix It!" This partially depends on ones definition of "being broken". My "fix" was an attempt to catch more error conditions early rather than silently ignore them, and an interrupted, short write resulting in some broken output file could be a rare but annoying compiler bug. I admit that the asserts fire more often than I hoped and that they should be removed, but on the long run, we should properly check the return values. Maybe we need another set of wrappers Safe_fgets, Safe_fwrite, ...? What I do not quite understand: I ran the regression tests on my box and the compile farm runs them as well---successfully. Do they not use the linker, possibly due to them consisting of only one source file each? > Which compiler (version) are you using? > Any special command line options? The warnings occur using unmodified sdcc Makefiles on my fully patched Ubuntu 8.10 with gcc 4.3.2 (I guess) and a recent glibc (>= 2.3 according to others having the same problems): the libc-headers included in that release add __attribute__((warn_unused_result)) to many functions, whose result we choose to ignore. Casting to (void) does not help to remove the warning (as it seems by intention of the gcc guys; assigning it to a variable does, but provokes an "unused variable" warning unless the variable is used, e.g., as in the untested '(void)temp = fwrite(...)'). Regretful regards, Raphael ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2008-12-28 12:26 Message: Raphael, I propose to revert all changes you made 2008-12-20 for "quieten most compiler warnings", since they brought a lot of troubles and little benefit. I also don't like that you changed files support/cpp/c-ppoutput.c and support/cpp/libcpp/lex.c, which are just copies of GCC's cpp, which make merging from GCC to SDCC mode difficult. The golden rule "If It's Not Broken, Don't Fix It!" is valid for most cases, specially if you don't exactly know what and why you are doing ;-) In order to get rid of "ignore return values" warnings you can just replace fgets(...) calls with (void) fgets(...). At least I think this should help... Which compiler (version) are you using? Any special command line options? Borut ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2472264&group_id=599 |