Build of GCC 4.0.0 successful
I've bootstrap built GCC 4.0.0 on Fedora Core 3. [EMAIL PROTECTED] ~]$ gcc -v Using built-in specs. Target: athlon-fedora-linux Configured with: ../configure --prefix=/opt2/gcc4 --enable-shared --enable-threads=posix --disable-checking --with-system-zlib--enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=athlon-fedora-linux Thread model: posix gcc version 4.0.0 I did not run the reqressions, but I did something equally interesting (or stupid depending on your point of view). I built kernel 2.6.11.7 and booted back into it. [EMAIL PROTECTED] ~]$ cat /proc/version Linux version 2.6.11.7 ([EMAIL PROTECTED]) (gcc version 4.0.0) #2 Fri Apr 22 14:12:12 EDT 2005 The kernel source failed to build in one file. I made the following changes in order to get a module to build. Changed include/linux/i2c.h: line 58 extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],int num); to extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,int num); line 197 int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[], to int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs, Once those two changes were made everything built. I did see kernel build warnings go flying by, but I did not bother with those (yet). I'm very impressed. I'm looking forward to poking at the C++, f9x, and java bits. Thanks a lot guys.
Re: Is there a way to generate a cross reference listing for a c/c++ program using gcc?
If you want that kind of cross referencing, then you shouild look at Doxygen (http://www.stack.nl/~dimitri/doxygen/). It will produce excellent cross references for HTML, Latex, RTF, and XML. There are pre-built binaries for Linux distributions, Solaris, and Windows, and Doxygen is usually in most current Linux distributions. On 5/13/05, Paul Albrecht <[EMAIL PROTECTED]> wrote: > Is there a way to generate a cross reference listing for a c/c++ program > using gcc? > >
Re: Is there a way to generate a cross reference listing for a c/c++ program using gcc?
And I'll say it again. If you want what LXR provides (and yes, I looked it up) then get Doxygen. It runs on every platform, comes bundled with many distributions, and it will give you an output in HTML that will give you every cross-reference you care to name. If you want something that you can further process it will give you an output in pure XML. There are already many other good solutions to your problem. If you're so hot to re-invent the LXR wheel and you feel the burning need for cross reference output from gcc, then why don't you write that cross-reference output feature? On 5/15/05, Paul Albrecht <[EMAIL PROTECTED]> wrote: > William Beebe writes: > > > > >If you want that kind of cross referencing, then you shouild look at > Doxygen (http://www.stack.nl/~dimitri/doxygen/) > > > > I need the cross-reference output from the compiler because I want to write > a source code browser like LXR. That's why I asked the question. Again, is > there a way to generate a cross-reference listing for a c/c++ program using > gcc? If not, the has anyone considered adding a gcc compiler option to > output cross-reference information? > >
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
On 5/28/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > Brainstorming there may be, but certain folk in the GCC community simply > like being annoying, perhaps to feed their own sense of self-importance. > It is quite possible to disagree with someone without be disagreeable, > as exemplified by Evandro Menezes recently. > > ..Scott It's called polite constructive criticism. Unfortunately, the lack of civility when offering important judgement isn't limited to this newsgroup. For example, whenever I feel the temperature rising a bit too high, I just wonder over to the lkml and lurk awhile until I realize once more what wonderfully sainted individuals the gcc developers are.
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
On 29 May 2005 11:37:00 +0200, Kai Henningsen <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Scott Robert Ladd) wrote on 28.05.05 in > > In my experience, people don't file Bugzilla reports because it feels > > impersonal and unresponsive. The form is not very user-friendly (as in > > friendly to users of GCC, not its developers.) > > This is pretty much incomprehensible to me (NOT a gcc developer, but a gcc > user - that is, a programmer). > > "Feels impersonal"? And this is supposed to be a *problem* with a bug > reporting system?! > > We're not talking about a trouble ticket system for a matchmaking agency > here, are we? I certainly don't expect technology in general to feel > personal. And in fact I thought the problem with the mailing lists *was* > that they got too personal. > > Unresponsive? I thought the whole point was to avoid responses (in the > mailing list)? > > Sorry, but this really does not make any sense to me. > > As for the user friendlyness of the forms, well, all I can say is that > they're certainly not optimal, but they're at least in the upper 30% of > forms in general one encounters on the web - and that includes non- > technical stuff. In fact, forms for non-technical stuff are usually > especially bad - presumably because the authors have less understanding of > the technology involved. > > MfG Kai OK, then let me explain it to you. The problem with the GCC Bugzilla reporting system is that it's a system that only other developers can tolerate, let alone love. The entire GCC website (of which GCC Bugzilla is a part) could be the poster child for why developers should never be allowed to design user interfaces, especially web user interfaces. I'm sure I'll get flamed for wanting style over substance or about the proliferation of eye candy, but the GCC web site and it's attendent support pages can only be charitably described as eye trash. Yes, you can find the bug link if you read the main page long enough and move down the page slowly enough, or if, like me, you fire up Firefox's find and use that to go quickly to the bug link. But that's beside the point. At the very least the design of the GCC web site makes the whole project look like someone who has just discovered the web and decided to build a few pages. And please don't harp on making it standards compliant and viewable by every browser in existance. There are plenty of well-designed and excellent sites that follow those same rules. You just need to be willing to put in the effort to look a little more professional and polished. And just to stir the pot further, a web site is an important marketing tool. It's the first thing that a lot of people will see when they go looking for help. If you want to have more people participate, then make the tools more inviting.
Re: What is wrong with Bugzilla?
On 5/29/05, Russ Allbery <[EMAIL PROTECTED]> wrote: > Setting aside for the moment that GCC is a software package *targetted* at > developers, and hence the above is not necessarily a serious problem, I > agree that the Bugzilla interface isn't exactly my favorite UI. However, > I haven't figured out a better one either, so I don't have a firm platform > on which to stand and complain. > > Bug reporting interfaces appear to be a hard problem. Then I would like you to review and contrast GCC Bugzilla (http://gcc.gnu.org/bugzilla) with at least two others: Mozilla's (https://bugzilla.mozilla.org) and Redhat's (https://bugzilla.redhat.com/bugzilla/index.cgi). Mozilla's is a bit more organized than GCC's (but not much) and it is organized as a two-column page with a resonably lucid, short and sweet explaination on the right. It shares the same ant picture with GCC's, which makes me wonder if that image isn't part of some core page that comes with the Bugzilla package. The best of the two is the Redhat page. Instead of lots of controls on the page, it has one to start with (search for a bug), with the more detailed (and powerful) options located at the top of the page as menu items. It's also good in that it has both expository information on the page as well as news that someone looking for bugs might want to read. The only problem with the Redhat page is that its news section is somewhat dated. And yes, I know that Redhat is a 'real' company and that the designer(s) are probably paid. It would be interesting to ask if Redhat could provide some gcc site support. And if bugzilla is not working out, or if you want some ideas on how to build better interfaces, there seem to be plenty of open bug tracking packages on Sourceforge. A quick search for bugzilla produces a nice long list, and at random I picked phpBugTracker (http://phpbt.sourceforge.net). > Well, unless you have some user interface designers lined up and > volunteering to help, this isn't really the most useful thing to say. GCC > is a volunteer project; it uses the labor that it has available. And I understand and appreciate that. But when the UI heavy hitters aren't beating your doors down you either have to appeal to them in the coummunity or else go and do what I do; look at what's out there and (re)use design elements. I know that there's got to be somebody out there doing good volunteer UI work. For example, I look at the Savannah project (http://savannah.gnu.org) which is at the least reasonably organized and easy to read. Then there's Fedora (http://fedora.redhat.com) and Gentoo (http://www.gentoo.org). I'm sure there're others. As I mentioned before, have you thought to ask for help from Redhat? If everybody looks to gcc as an important core tool, then perhaps those power users could help with the site. I would say to go and talk to Apple, that paragon of UI design, but I have no idea how Apple would react or if it would be a complete waste of time and energy. > > You just need to be willing to put in the effort to look a little more > > professional and polished. > > The people maintaining the GCC web site put a great deal of effort into > it. If there is a problem, lack of effort isn't the cause of it. Maintenence is not design. And when that maintenence is the last thing you do after everything else, it shows. What triggered this diatribe was the apparent hard-core attitude that the GCC bugzilla (warts and all) was the way it was and it was going to stay that way, so live with it. You can't have that kind of an attitude with the site or the tool. You've pointed out the lack of bandwidth to improve it, and I am sympathetic (believe me, I really am). However, if someone makes a comment on the look and feel of the site then you should make the diplomatic equivalent to the comment "do you have a patch" when someone makes a comment about some "questionable" issue with the compiler. > You seem to be arguing that the people maintaining the web site have the > wrong skill set to do a good job at it. Personally, the site looks great > to me, but then I'm a developer, so... :) However, this is all just noise > on a mailing list in the absence of someone with different ideas who is > willing to do the work, just as with any other part of GCC. The people do have the wrong skill set. And let me be the first to tell you that when it comes to truly creative design, I suck. I would certainly be willing to help someone who doesn't suck. > If you feel there is a better way to do the web site, propose patches, > volunteer to help maintain it, and demonstrate why it's better. Just like > with the rest of GCC. If you don't have time to do that, you could try to > convince someone else to do it, or you could pay someone to do it. Just > like with the rest of GCC. In the absence of such a contribution, you > (and the web site) are at the mercy of the people who *are* willing to put > the effort into it. OK. Let's see where we go with tha
GCC 4.0.1 RC1 successful build
GCC 4.0.1 was successfully built on Fedora Core 3 using 3.4.4 as the starting compiler. [EMAIL PROTECTED] opt2]$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/opt2/gcc401 --enable-threads=posix --with-system-zlib -enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,objc Thread model: posix gcc version 4.0.1 20050608 (prerelease) Please note that I did not build java nor ada. GCC was built with 'make bootstrap'. The machine in question is an older Athlon XP 2500+ Barton with 512MB and 1.5GB swap. Swap stays around 192MB on my machine, and did not grow during compilation. [EMAIL PROTECTED] opt2]$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 2500+ ... [EMAIL PROTECTED] opt2]$ cat /proc/version Linux version 2.6.11.11 ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #1 Sun May 29 13:35:04 EDT 2005 Build time was approximately 30 minutes. Later this evening I will be rebuild and boot my kernel for testing and the latest announced ACE/TAO beta, 5.4.6. This will exercise the C and C++ portions of GCC.
Re: gcc 4.0.1 regressions with friend injection
Which leads me to the old saying that friends don't let friends use friends. On 26 Jul 2005 03:07:49 +0200, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > Mike Stump <[EMAIL PROTECTED]> writes: > > | We are seeing tons of regressions (9 of 2377 for fink, over 100 or so > | out of 8000 was it for internal projects) in the build state of > | projects with code like: > | > | class bar { > |friend class foo; > |void baz(foo *x) {} > | }; > | > | from 4.0.0 in 4.0.1. This is really unfortunate. What we really > | need is a warning (that can be easily turned off with a -Wno- switch) > | for the next 2 years, and then an error, if you must. Doing this > | from x.0.0 to x.0.1 is, uhm, well, more costly than if it had been > | done in 4.0.0. :-( > | > | Thoughts? > > This area has been a historical weakness of GCC, causing us to reject > valid-code or accept valid-code-with-wrong-semantics. As you point > out above, it can can the overload set and such. Because the point of > declaration is far away from the point of possible overload > resolution, it is not all clear when an "invalid declaration accepted > for past bug compayibility" should be or not be part of the overload > set. You can warn, but it you turn it off, it is not obvious what the > semantics should be. > > (This reminds me of the "implicit typename" stuff) > > -- Gaby >