Re: Symbol versions for inlined symbols
On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote: > You may wish to read the proceedings from this year's GCC summit, where > another solution was presented by some gentlemen from Intel. For various > reasons, symbol versioning is not a useful solution to this problem. I hadn't seen that, thanks. It's an interesting approach but a bit confusing to somebody like me who doesn't use C++ very often: it sounded from their writeup like you'd have to modify application code, and then in other parts it sounded like actually only the libstdc++ headers would need to be modified and apps would do the right thing transparently. >From my perspective the most convenient solution would be a way to modify ELF symbol scoping (which is what symbol versioning does, in a complicated sort of way). Instead of starting lookup for a symbol in libC from app, going on through libstdc++.so.5, libA, libB, libC, libstdc++.so.6, libD: app libstdc++.so.5 libA, libB, libC, libstdc++.so.6 libD something more similar to Windows where a symbol lookup starting in libC checks libC, libstdc++.so.6, libD, app, libstdc++,so.5, libA, libB would work. That way, the GLOBAL WEAK symbols in the std namespace would always resolve to what you'd intuitively expect: the dependencies of that object. ELF compatibility would mostly be preserved as symbols could still be resolved to the parent and other objects in the image, but the chance of cross-wiring would be reduced. I think this is what the DT_1_GROUP flag is supposed to do, but for some reason it was never implemented in the glibc linker. Does anybody know why? Last time I talked about this with Michael Meeks at Novell, he seemed to think the semantics of the DT_1_GROUP flag would mess up C++ exception handling, which relies on the current ordering. Is that so? Oh, final thing - the GCC summit paper made it sound like only rare proprietary apps need the ability to mix multiple libstdc++ versions in the same image, but it's a very common thing to do for open source programs too: specifically, games. Games are why I'm asking, actually :) We already have nasty workarounds for this issue in place for NetPanzer, Lincity and a few other projects that distribute binaries and may be linked against other C++ libraries already on the system. The classic example is "C++ Game -> SDL -> SDL_audio -> libArts (for KDE audio) -> mismatched libstdc++ version -> crash in std::string". thanks -mike
Re: Symbol versions for inlined symbols
On Sun, Jul 31, 2005 at 03:53:42PM +0100, Mike Hearn wrote: > On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote: > > You may wish to read the proceedings from this year's GCC summit, where > > another solution was presented by some gentlemen from Intel. For various > > reasons, symbol versioning is not a useful solution to this problem. > > I hadn't seen that, thanks. It's an interesting approach but a bit > confusing to somebody like me who doesn't use C++ very often: it sounded > from their writeup like you'd have to modify application code, and then in > other parts it sounded like actually only the libstdc++ headers would need > to be modified and apps would do the right thing transparently. The latter is the whole point. > From my perspective the most convenient solution would be a way to modify > ELF symbol scoping (which is what symbol versioning does, in a complicated > sort of way). Instead of starting lookup for a symbol in libC from app, > going on through libstdc++.so.5, libA, libB, libC, libstdc++.so.6, libD: > > app > libstdc++.so.5 > libA, > libB, > libC, >libstdc++.so.6 >libD You've completely missed the problem here, I'm afraid. You can't use anything like symbol scoping to do this, because the generated symbols will end up in the application and in libC. Besides, what if libC ends up being a static library using libstdc++.so.5 and you want to rebuild app? Solving this little bit of the problem just isn't worth it. -- Daniel Jacobowitz CodeSourcery, LLC
Re: rfa (x86): 387<=>sse moves
Hello! With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code like double d = atof(foo); int i = d; callatof fstpl -8(%ebp) movsd -8(%ebp), %xmm0 cvttsd2si %xmm0, %eax (This is Linux, Darwin is similar.) I think the difficulty is that for This problem is similar to the problem, described in PR target/19398. There is another testcase and a small analysis in the PR that might help with this problem. Uros.
-b vs -bundle
In compiling xplor-nih under the gcc/g++ of 4.1 branch instead of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's compiler I can have a Makefile entry like... createSharedModule = $(CXX) -bundle \ -flat_namespace -undefined suppress $^ -o $@ and it compiles the shared module without error. However I see the error... g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o libswigpy-xplor.dylib -o _xplorWrap.so -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot -lintVar -lvmd -lpy -lswigpy-xplor \ -lcrypto -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ g++-4: couldn't run 'undle-gcc-4.1.0': No such file or directory with the gnu gcc compiler. I noticed that you rejected a proposed patch a few years ago... http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00655.html http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01961.html Could you revisit this issue and see if something could be done for 4.0 and 4.1 branch? I would think that either the compiler should require the -b flag to have a space before the machine name. Alternatively if the gnu gcc compiler mustn't allow -bundle to be the first argument passed to the compiler, it should at least treat that as a defined error rather than producing the cryptic one it does now. Thanks in advance for looking at this again. Jack
Replacing phpwiki with other wiki software
It has gotten to the point where people are reporting bugs in our wiki that i can't fix because the phpwiki code it too much like spaghetti. There is one main phpwiki developer, and while he's very good at php development, the codebase dwarfs him :). I'm thinking of moving us to a more actively developed and supported wiki software, such as MoinMoin or Mediawiki. My first choice is MoinMoin, since it is very actively developed *and* it's well architected, written in python, and easy to understand and modify. MediaWiki seems too abstracted and heavyweight (I'm sure you can do anything you want with it, it just seems like massive overkill for simple wikis) I've converted our pages to MoinMoin, and put up the result at http://www.dberlin.org/wiki There is still some hand editing required that i'm doing. The main difference in format syntax between phpwiki and moinmoin is in bolding/italics/verbatim, and a slightly simpler list syntax. This is actually true of phpwiki vs anything. MoinMoin and Mediawiki use the same bolding/italic/etc format. If we really like the old syntax better, i can try to add it. I can actually write a simple formatter for texinfo so you can keep texinfo pages in the wiki, edit them like you edit wiki pages, and it will display the results as texinfo converted html. The same is true of things like docbook, see http://www.dberlin.org/wiki/HelpOnXmlPages Anyhoo, unless someone has a good reason not to, i'll convert the wiki sometimes in the next few weeks. --Dan
Re: please update the gcj main page
On Fri, 15 Jul 2005, Tom Tromey wrote: >> The FAQ is badly in need of an update - in fact, it should be moved >> over to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier >> to update and maintain. > Great idea, I agree. > We've had a lot of trouble with bit-rot of the main pages over the > years. Moving to the wiki might help, at least that way folks could > more easily fix their own problems. We may to want to wait until we hear about the outcome of discussion on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc, or we may be in troubles at some point in the future when we try to move documentation around. Gerald
Re: please update the gcj main page
On Mon, 2005-08-01 at 00:30 +0200, Gerald Pfeifer wrote: > On Fri, 15 Jul 2005, Tom Tromey wrote: > >> The FAQ is badly in need of an update - in fact, it should be moved > >> over to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier > >> to update and maintain. > > Great idea, I agree. > > We've had a lot of trouble with bit-rot of the main pages over the > > years. Moving to the wiki might help, at least that way folks could > > more easily fix their own problems. > > We may to want to wait until we hear about the outcome of discussion > on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc, We are not the first nor the last project to have a wiki that needs to move documentation from the wiki to the print. They all simply take the wikipedia approach: Make it very clear right near the button necessary to submit changes that you ar enot to be submitting things you didn't write, that all pages are licensed under the GFDL, etc. > or we may be in troubles at some point in the future when we try to move > documentation around. Just like everyone else has had trouble? > > Gerald
Re: please update the gcj main page
On Sun, 31 Jul 2005, Daniel Berlin wrote: >> We may to want to wait until we hear about the outcome of discussion >> on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc, > We are not the first nor the last project to have a wiki that needs to > move documentation from the wiki to the print. We are not just any project... >> or we may be in troubles at some point in the future when we try to move >> documentation around. > Just like everyone else has had trouble? ...being an FSF project mandates stricter standards on copyright issues than "everyone else" needs to follow. Gerald
Re: please update the gcj main page
On Mon, 1 Aug 2005, Gerald Pfeifer wrote: > We may to want to wait until we hear about the outcome of discussion > on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc, > or we may be in troubles at some point in the future when we try to move > documentation around. The same sort of thing could apply regarding changes to Wiki software - we may need to make sure the authorship information for all past significant changes in the current Wiki remains available even if the past history isn't directly imported into new Wiki software. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: please update the gcj main page
On Mon, 2005-08-01 at 01:02 +0200, Gerald Pfeifer wrote: > On Sun, 31 Jul 2005, Daniel Berlin wrote: > >> We may to want to wait until we hear about the outcome of discussion > >> on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc, > > We are not the first nor the last project to have a wiki that needs to > > move documentation from the wiki to the print. > > We are not just any project... > > >> or we may be in troubles at some point in the future when we try to move > >> documentation around. > > Just like everyone else has had trouble? > > ...being an FSF project mandates stricter standards on copyright issues For code. I have never seen such claims made for documentation, since it's much easier to remove and deal with infringing docs than code. > than "everyone else" needs to follow. Other FSF projects use their Wiki for docs. See GNUStep, GNOME, etc Or are they not "FSF enough" for you? > > Gerald
Re: [patch, wwwdocs] Include "documentation" section on gfortran index.html
On Mon, 18 Jul 2005, Brooks Moses wrote: >> As per a recent conversation with Steve Kargl on the fortran list, I'm >> submitting this patch, which adds a small "Documentation" section to >> the gfortran "home page", right below the "Binaries" section. > Oh, bother. I just noticed that I failed to update the link when I cut- > and-pasted from the Binaries section! > > A corrected patch follows. I was waiting for a gfortran maintainer to comment -- if it's fine with them, it surely is fine with me. That said, what do you think about omething along the lines of http://gcc.gnu.org/java/ which a navigation bar on the left? Might that be preferrable? Gerald
Re: please update the gcj main page
On Sun, 2005-07-31 at 23:12 +, Joseph S. Myers wrote: > On Mon, 1 Aug 2005, Gerald Pfeifer wrote: > > > We may to want to wait until we hear about the outcome of discussion > > on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc, > > or we may be in troubles at some point in the future when we try to move > > documentation around. > > The same sort of thing could apply regarding changes to Wiki software - we > may need to make sure the authorship information for all past significant > changes in the current Wiki remains available even if the past history > isn't directly imported into new Wiki software. It is already.
Re: please update the gcj main page
On Sun, 31 Jul 2005, Daniel Berlin wrote: > For code. > I have never seen such claims made for documentation, since it's much > easier to remove and deal with infringing docs than code. I have seen such statements, by RMS himself. Gerald
Re: [patch, wwwdocs] Include "documentation" section on gfortran index.html
On Mon, Aug 01, 2005 at 01:19:01AM +0200, Gerald Pfeifer wrote: > On Mon, 18 Jul 2005, Brooks Moses wrote: > >> As per a recent conversation with Steve Kargl on the fortran list, I'm > >> submitting this patch, which adds a small "Documentation" section to > >> the gfortran "home page", right below the "Binaries" section. > > Oh, bother. I just noticed that I failed to update the link when I cut- > > and-pasted from the Binaries section! > > > > A corrected patch follows. > > I was waiting for a gfortran maintainer to comment -- if it's fine > with them, it surely is fine with me. The patch is fine. I was going to commit it, but real life has taken over and gfortran is way down the list of important things to do. -- Steve
Re: [patch, wwwdocs] Include "documentation" section on gfortran index.html
On Sun, 31 Jul 2005, Steve Kargl wrote: >> I was waiting for a gfortran maintainer to comment -- if it's fine >> with them, it surely is fine with me. > The patch is fine. I was going to commit it, but real life > has taken over and gfortran is way down the list of important > things to do. It's in. If you are in favor of the navigation bar idea, just tell me that/how you want it, and I'll help. Gerald
does the instruction combiner regards (foo & 0xff) as a special case?
Does the instruction combiner regards (foo & 0xff) as a special case? I have two patterns which I expect to match all the if(foo & $(constant)) patterns. They are [(set (reg:CC_Z CC_REGNUM) (compare:CC_Z (and:SI (match_operand:SI 0 "register_operand" "") (match_operand:SI 1 "" "")) (const_int 0)))] [(set (reg:CC_Z CC_REGNUM) (compare:CC_Z (zero_extract:SI (match_operand:SI 0 "register_operand" "") (const_int 1) (match_operand:SI 1 "" "")) (const_int 0)))] But I found they fails to match if(foo & 0xff) and if(foo & 0x) Did I forget something ? Thank you for your reading.
Re: please update the gcj main page
Gerald Pfeifer wrote: On Sun, 31 Jul 2005, Daniel Berlin wrote: For code. I have never seen such claims made for documentation, since it's much easier to remove and deal with infringing docs than code. I have seen such statements, by RMS himself. removing stuff is a remedy for copyright violation, for which a liability still exists. it is preferable to avoid any possible infringement in the first place.
Re: does the instruction combiner regards (foo & 0xff) as a special case?
[EMAIL PROTECTED] writes: > Does the instruction combiner regards (foo & 0xff) as a special case? > > I have two patterns which I expect to match all the > > if(foo & $(constant)) patterns. They are > > [(set (reg:CC_Z CC_REGNUM) > (compare:CC_Z > (and:SI (match_operand:SI 0 "register_operand" "") > (match_operand:SI 1 "" "")) > (const_int 0)))] > >[(set (reg:CC_Z CC_REGNUM) > (compare:CC_Z (zero_extract:SI > (match_operand:SI 0 "register_operand" "") > (const_int 1) > (match_operand:SI 1 "" "")) >(const_int 0)))] > > But I found they fails to match > > if(foo & 0xff) and if(foo & 0x) Look at the debugging dump before the combine pass to see what you need to match. Ian
std::string:;assign fail in multi-threaded program
Hi, First, thx for u all reading this mail. I have some problems when I was using std::string when I was writing my multi-threaded server. I am using libstdc++ 5.0.3. and using pthread to do multi threading. The errors are as the followings. shot 1 #0 0xbfdb3bc6 in std::__default_alloc_template::allocate(unsigned) () from /usr/lib/libstdc++.so.5 (gdb) bt #0 0xbfdb3bc6 in std::__default_alloc_template::allocate(unsigned) () from /usr/lib/libstdc++.so.5 #1 0xbfdb9bf8 in std::string::_Rep::_S_create(unsigned, std::allocator const&) () from /usr/lib/libstdc++.so.5 #2 0xbfdb641d in std::string::_M_mutate(unsigned, unsigned, unsigned) () from /usr/lib/libstdc++.so.5 #3 0x08066f8d in std::string& std::string::_M_replace_safe(__gnu_cxx::__normal_iterator, __gnu_cxx::__normal_iterator, char const*, char const*) (this=0xbd3d6bd0, __k1=0xbf8b3349 "kent", __k2=0xbf8b334d "") at basic_string.tcc:533 #4 0xbfdb6fac in std::string::assign(char const*, unsigned) () from /usr/lib/libstdc++.so.5 snap 2#0 0xbffabc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xbfbffa29 in raise () from /lib/tls/libc.so.6 #2 0xbfc01255 in abort () from /lib/tls/libc.so.6 #3 0xbfdc7537 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5 #4 0xbfdc7584 in std::terminate() () from /usr/lib/libstdc++.so.5 #5 0xbfdc76f6 in __cxa_throw () from /usr/lib/libstdc++.so.5 #6 0xbfd80ebb in std::__throw_length_error(char const*) () from /usr/lib/libstdc++.so.5 #7 0xbfdb9c25 in std::string::_Rep::_S_create(unsigned, std::allocator const&) () from /usr/lib/libstdc++.so.5 #8 0xbfdb9d29 in std::string::_Rep::_M_clone(std::allocator const&, unsigned) () from /usr/lib/libstdc++.so.5 #9 0xbfdb678d in std::string::_Rep::_M_grab(std::allocator const&, std::allocator const&) () from /usr/lib/libstdc++.so.5 #10 0xbfdb8133 in std::string::assign(std::string const&) () from /usr/lib/libstdc++.so.5 I would like to ask what is the possible reason of these errors? I am using a dual Xeon CPU as my server. Is it related to this issue? Thanks a lot. Snow Dragon ___ 想即時收到新 email 通知？ 下載 Yahoo! Messenger http://messenger.yahoo.com.hk
Re: please update the gcj main page
On Sun, 2005-07-31 at 22:50 -0400, Robert Dewar wrote: > Gerald Pfeifer wrote: > > On Sun, 31 Jul 2005, Daniel Berlin wrote: > > > >>For code. > >>I have never seen such claims made for documentation, since it's much > >>easier to remove and deal with infringing docs than code. > > > > > > I have seen such statements, by RMS himself. > > removing stuff is a remedy for copyright violation, for which > a liability still exists. it is preferable to avoid any > possible infringement in the first place. > I leave legal stuff to the FSF, and have submitted proposed text (like what Wikipedia does) to people on the SC to forward along in the hopes that will pacify these concerns. You don't really need copyright assignment (IE you can go along with just licenses) unless you plan on suing people over your documentation, which seems even less likely than suing someone over your code. As for the rest, I view the processes here as a means to an end, not an end unto themselves, and think we should go with the flow contributors want to take when it makes sense and is possible. If it would encourage people to write docs to do docs using a different process (doxygen, wikis, whatever) that has worked well for others, then let's try it in addition to our existing process and see how it turns out. I certainly don't think our current docs process (IE texinfo + patch review + cvs based docs + whatever) has encouraged the kind of contribution we really need to have great docs, for *whatever* reason. I don't blame the people currently maintaining and reviewing docs, though they seem to believe i do. I am simply trying to help find a process that enables better docs. I don't honestly care if that process ends up being people chiseling stone tablets and sending them to me for typing up and editing, along with appropriate legal waiver forms. If that's what developers find gets them to write documentation, ... Forcing people to write more documentation will only work if it's not really extra work for them. If you established a rule that for every 300 lines of code submitted, 150 lines must be added to the .texi files, i believe people would simply stop contributing at all. --Dan
Re: please update the gcj main page
You don't really need copyright assignment (IE you can go along with just licenses) unless you plan on suing people over your documentation, which seems even less likely than suing someone over your code. I don't follow. The issue is that somebody claims that the FSF documentation infringes on their copyright and claims that the disclaimers on the Wiki do not constitute a contract or license. It would be very embarassing to the FSF to be found guilty of copyright infringement and it doesn't matter whether it's in code or documentation. Forcing people to write more documentation will only work if it's not really extra work for them. Again, I don't follow. Writing documentation certainly is "extra work". Indeed it's often much more work than writing the code. But it's a very critical part of software development and if people aren't willing to do it, their contribution isn't very valuable.
Re: please update the gcj main page
On Sun, 2005-07-31 at 23:20 -0400, Richard Kenner wrote: > You don't really need copyright assignment (IE you can go along with > just licenses) unless you plan on suing people over your documentation, > which seems even less likely than suing someone over your code. > > I don't follow. The issue is that somebody claims that the FSF documentation > infringes on their copyright and claims that the disclaimers on the Wiki do > not constitute a contract or license. This is barely worth explaining, but; Such a claim would be ridiculous to press in spite of a clear and conspicuous notice to the contrary, plus affirmative action on the user to agree to such a disclaimer, such as clicking a button. The case law on this is nowadays enormous. If you want to go ask another lawyer whether they'd feel the same way, ask them. I'm sure they'd give you the same answer *for these circumstances*. In general, you don't get to claim they can't do something when they told you they were going to do it, you said "okay", and then they did it. We have verifiable logs that they clicked the submit button, submitting these changes, on such and such a day, at such and such a time. As for the rest of your views on documentation, you could have said the same thing of managing bug reports under GNATS that were fixed or affected by their code. It was extra work, and a critical part of development, yet people often didn't do it. Did that make people's code contributions "not very valuable"? And are you going to disagree that the problem with that process was not, in fact, the tool being used? Make a process use tools that people don't like, and they won't do it. You can say they aren't very valuable then, but that doesn't actually help you get your project where it wants to go. Your views seem very out of touch with what other projects have found to be useful in producing good documentation in terms of tools and processes.
SPECINT 2000 176.gcc compilation
Hi, I am trying to compile SPECINT 2000 176.gcc benchmark using GCC 4.1 April 24th build on Redhat Linux/i386. I get the following error while compiling "reorg.c": reorg.c: In function âfind_end_labelâ: reorg.c:831: error: invalid lvalue in increment reorg.c: In function âdelete_from_delay_slotâ: reorg.c:1033: error: invalid lvalue in increment reorg.c: In function âmake_return_insnsâ: reorg.c:4157: error: invalid lvalue in increment reorg.c: In function âdbr_scheduleâ: reorg.c:4237: error: invalid lvalue in increment reorg.c:4312: warning: incompatible implicit declaration of built-in function âmemsetâ make: *** [reorg.o] Error 1 Can someone tell me the right set of flags for compiling 176.gcc? I am using "-DUSG -O3" TIA, --R
Re: SPECINT 2000 176.gcc compilation
On Monday 01 August 2005 06:23, Rajkishore Barik wrote: > Hi, > I am trying to compile SPECINT 2000 176.gcc benchmark using GCC 4.1 April > 24th build on Redhat Linux/i386. > I get the following error while compiling "reorg.c": > > reorg.c: In function âfind_end_labelâ: > reorg.c:831: error: invalid lvalue in increment > reorg.c: In function âdelete_from_delay_slotâ: > reorg.c:1033: error: invalid lvalue in increment > reorg.c: In function âmake_return_insnsâ: > reorg.c:4157: error: invalid lvalue in increment > reorg.c: In function âdbr_scheduleâ: > reorg.c:4237: error: invalid lvalue in increment > reorg.c:4312: warning: incompatible implicit declaration of built-in > function âmemsetâ > make: *** [reorg.o] Error 1 > > > Can someone tell me the right set of flags for compiling 176.gcc? > I am using "-DUSG -O3" See http://www.spec.org/cpu2000/issues/, look for gcc. Gr. Steven
