Re: GCC with formal testing docs
Hi: Thank you very much for your suggestion. 2007/7/24, Dave Korn <[EMAIL PROTECTED]>: > On 24 July 2007 07:42, ?? wrote: > > > Hi: > >I know GCC is a wonderful compiler collection. I like it and trust > > it. But, I can't find any formal docs about Testing GCC, both unit > > testing and integrat testing. I think, as a software, GCC should be > > tested and own a test report. > > > >Can someone give me some infomation about how the GCC workteam test > > it? Lexical analysis, syntactical analysis, RTL generation ... or > > testing from other aspects. > > > >Maybe I ask a strange question, maybe it isn't worth thinking:). > > There's no such thing as strange questions, just strange people asking them. > Err... wait a minute, that doesn't sound quite right! > > > I'm interested about it. Also I need your help. Thank you! ^_^ > > Quick summary: GCC does not have any formal unit testing. There are a lot > of run-time consistency checks that can be compiled in by configuring with > --enable-checking, and these cover a lot of the same basic > are-things-doing-what-we-expect-them-to ground that unit tests would. > > Apart from that, GCC also has a vast regression testsuite. (It's slightly > misnamed; some of the testcases are more like unit tests, but most of them are > real code snippets that have uncovered bugs in GCC in the past, so we'll see > if the same bug ever recurs). This is one of the main metrics most people use > to test GCC. Many of the tests are cleverly designed to probe at some of the > inner workings of the compiler, by examining tree-dumps and assembler outputs. Indeed, I should study the testsuite carefully, especially the tests examining tree-dumps, RTL generator outputs and assembler outputs. As Anitha B assumed, my " formal docs " referr to the testing phase of a project life cycle ( GCC project ), ^_^ . GCC is LARGE/HUGE/... project, so it is a good thing if there exists such " formal docs ", not only to the development of GCC, but to all the programmers in the world. > See >http://gcc.gnu.org/onlinedocs/gccint/Testsuites.html > for the internal documentation on the testsuite framework. See also the GCC > wiki page on the subject: >http://gcc.gnu.org/wiki/TestingGCC > > Also, as described at http://gcc.gnu.org/testing/, there are a number of > individuals and teams running continuous integration tests, including > regression tests. There are also projects which measure and track gcc > performance in terms of time and memory usage and generated code time and > memory usage over the long term; see http://gcc.gnu.org/benchmarks/ for CSiBE > and others. > > >cheers, > DaveK > -- > Can't think of a witty .sigline today > > Best regards KevyLong
Re: Rebuild GCC 4.2
On 25/07/07, S.SRIDHAR <[EMAIL PROTECTED]> wrote: Hi... Now i am working on GCC v3.3.2 and kernel 2.4,i want to upgrade both to the latest version GCC v4.2 and kernel 2.6,i don't know how to do so can u help me That depends on which flavour of GNU/Linux you are using. This mailing list is for gcc development. Sorry, we cannot help you upgrading your GCC and much less upgrading your kernel. If you have a support question I recommend you to read the documentation of your GNU/Linux distribution or, if your system is too critical to play with it, contact their support service. To everybody else: Would it be possible to implement a filter such the first mail ever from someone gets bounced back with a message about what the list is about and suggesting sending the mail again if the sender is sure that it is relevant? Cheers, Manuel.
URGENT : elf_update - low performance with large files ? (fwd)
Hi, Firstly, I would say my message is somewhere completely off the topic on either of the lists. But I dont know where to ask for help. I searched and searched for all pointers on libelf. Now, I use an age-old version probably - libelf.so.0.8.2. I donno from where I got it, but probably from mr511 site only. So this libelf, I use, in reading and writing elf object files. While library appears doing the work smartly for smaller files (elf object files), it sucks at rather too large files ( ~ 100,000). Profiling shows 98% of the time is spent only in elf_update(). ( took nearly 2 hours for creating objectfile of an 500,000 lined assembly file ) Does anyone have any idea where should I find some tips for avoiding this ? Is it something really to do with libelf only ? Any pointers are really helpful. This kinda ASAP for me. Incase required, please mail me removing cc list so as not to spam every one (Please see the message below for further details). Thanks! -- Regards, Anitha B @S A N K H Y A -- Forwarded message -- Date: Wed, 25 Jul 2007 15:15:24 +0530 (IST) From: Anitha Boyapati <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: URGENT : elf_update - low performance with large files ? Hi, I am a user of libelf. I am using libelf to create and update elf object files by an assembler. Now the biggest problem is - elf_update. For an assembly file of about 50 lines, the performance is unusually low. Profiling shows 98% of the timespent in elf_update ! I use a memory image update (ELF_C_NULL) so as to defer writing to actual file until much later. What I would like to know is : * elf_update() depends on memory size of the object file being written ? * are there any leaks at that point in libelf ? * Where can I get performance aspects of libelf - like it slows down if for a large memory image of an object file Btwn, I am also rather much suprised for not finding anything related to libelf other than documenatation ( some mailing list-open..I expected). Maybe I shouldnot have expected something like GCC. Sorry if I have sounded rude. Nice to have a tool, but having used it I am struck at some unknown place which left me with nothing much to contemplate - an awkward situation :( Any help appreciated deeply. Thanks -- Regards, Anitha B @S A N K H Y A
Re: GCC with formal testing docs
Ben Elliston wrote: On Tue, 2007-07-24 at 10:48 +0100, Manuel López-Ibáñez wrote: GCC is thoroughly tested. None the less, there is always room for improvement, so if you have time to implement your ideas or write documentation, you are welcome to contribute. If you build the compiler with coverage instrumentation and run the testsuite, you might get a shock. It's not as well tested as you might think. If it gave anyone a shock to find out that the test suite did not provide 100% coverage, then that person is not very familiar with compiler technology. It is by no means SOP to try to get 100% coverage testing of a compiler, and in practice for many reasons, very difficult (compilers often contain a lot of deactivated code that comes from defensive programming against errors, since compilers more than many programs routinely expect to be fed rubbish, and work hard to behave nicely when mistreated in this way :-) Ben
Re: g++ 4.3, troubles with C++ indexing idioms
On 7/25/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote: > For performance small arrays should be the same as individual members > (I can see the annoying fact that initialization is a headache - this has > annoyed me as well). For larger arrays (>4 members), aliasing will > make a difference possibly, making the array variant slower. Any union > variant is expected to be slower for aliasing reasons (we do not do > field-sensitive aliasing for unions). I wonder if the fabled "union as VIEW_CONVERT_EXPR" patch would help... Richi, do you know? I don't think so. As long as our memory optimizers are weak and only work well if they are faced with single SFT.xx VUSEs and VDEFs then using a union will be hit by create_variable_info_for not creating field variables for unions at all (and thus memory optimizers not be able to tell apart fields). Richard.
Re: Rebuild GCC 4.2
[EMAIL PROTECTED] wrote: On 25/07/07, S.SRIDHAR <[EMAIL PROTECTED]> wrote: Hi... Now i am working on GCC v3.3.2 and kernel 2.4,i want to upgrade both to the latest version GCC v4.2 and kernel 2.6,i don't know how to do so can u help me That depends on which flavour of GNU/Linux you are using. This mailing list is for gcc development. [EMAIL PROTECTED] could assist with upgrading gcc, after you read the instructions.
Re: URGENT : elf_update - low performance with large files ? (fwd)
On Wed, Jul 25, 2007 at 03:51:57PM +0530, Anitha Boyapati wrote: > Firstly, I would say my message is somewhere completely off the topic on > either of the lists. But I dont know where to ask for help. I searched and > searched for all pointers on libelf. The fact remains that it is off-topic. This list is one of the main tools the gcc developers use to produce the compiler, and to allow it to become a general-purpose help list would harm gcc. That's why you'll get replies like this one, asking you to go elsewhere. Also, if you "searched and searched", I'm surprised that you didn't find http://directory.fsf.org/libs/misc/libelf.html which would point you to the developers' forum and the help list. Google isn't that hard to use.
Re: GCC with formal testing docs
Ben Elliston wrote: > >If you build the compiler with coverage instrumentation and run the > >testsuite, you might get a shock. It's not as well tested as you might > >think. > On Wed, Jul 25, 2007 at 07:05:36AM -0400, Robert Dewar wrote: > If it gave anyone a shock to find out that the test suite did not > provide 100% coverage, then that person is not very familiar with > compiler technology. It is by no means SOP to try to get 100% > coverage testing of a compiler, and in practice for many reasons, > very difficult (compilers often contain a lot of deactivated code > that comes from defensive programming against errors, since > compilers more than many programs routinely expect to be fed > rubbish, and work hard to behave nicely when mistreated in > this way :-) Right. However, some coverage-oriented methodologies explicitly mark code that is expected to be unreachable, and produce unit tests to exercise at least some of the defensive code that no longer gets run by the compiler as a whole. If any volunteers would like to take on the job of improving and tracking coverage (by a combination of more tests, unit tests, and marking code that is currently unreachable but should remain for safety purposes) that could be helpful.
RE: URGENT : elf_update - low performance with large files ? (fwd)
On 25 July 2007 18:00, Joe Buck wrote: > On Wed, Jul 25, 2007 at 03:51:57PM +0530, Anitha Boyapati wrote: >> Firstly, I would say my message is somewhere completely off the topic on >> either of the lists. But I dont know where to ask for help. I searched and >> searched for all pointers on libelf. > > The fact remains that it is off-topic. And, JFTR, it's not "URGENT" either. Not in the least. Doesn't matter one little bit to me or anyone else on this list. cheers, DaveK -- Can't think of a witty .sigline today
Re: URGENT : elf_update - low performance with large files ? (fwd)
2007/7/25, Joe Buck <[EMAIL PROTECTED]> wrote: On Wed, Jul 25, 2007 at 08:32:33PM +0200, J.C. Pizarro wrote: > Patch it to investigate it a little bit more. > > After runned it, see "quickdirty.log" and post here your report's summary. No, please do not. This is not the libelf list; use that list. Dear Joe, why not? It's more meaningful to see this kind of related information than to divert it to nowhere. Is ELF related to GCC? Then!!! ;)
gcc-4.2.1 pointer questions?
This:
/* Internal convenience typedefs */
typedef GLvoid (*_GLUfuncptr)(GLvoid);
Produces this:
../.././include/libinc/GL/glu.h:259: error: '' has incomplete
type
../.././include/libinc/GL/glu.h:259: error: invalid use of 'GLvoid'
What am I missing???
-brian
Brian D. McGrew{ [EMAIL PROTECTED] ||
[EMAIL PROTECTED] }
--
> Do not read this email while waxing that cat!
Re: gcc-4.2.1 pointer questions?
Hi Brian, > This: > > /* Internal convenience typedefs */ > typedef GLvoid (*_GLUfuncptr)(GLvoid); > > Produces this: > > ../.././include/libinc/GL/glu.h:259: error: '' has incomplete type > ../.././include/libinc/GL/glu.h:259: error: invalid use of 'GLvoid' > > What am I missing??? See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278 Regards, Volker
Re: PATCH: Add myself as libbid maintainer
On Mon, 23 Jul 2007, H.J. Lu wrote: > Here is a patch. We are working on an external libbid open source > website. I will update it when it is up and running. Thanks! I believe you'd ment the first sentence to read "The master sources come from the Intel BID library..."? The patch is fine with this, or a similar patch. Gerald
Re: Rebuild GCC 4.2
On Wed, 2007-07-25 at 09:02 +0100, Manuel López-Ibáñez wrote: > To everybody else: Would it be possible to implement a filter such the > first mail ever from someone gets bounced back with a message about > what the list is about and suggesting sending the mail again if the > sender is sure that it is relevant? Do you really think that would make any difference? :-) Cheers, Ben
GCC 4.2.1 : bootstrap fails at stage 2. Anyone know why ?
System is Solaris 8 Sparc. Totally up to date. Vendor provided compiler is Sun ONE Studio 8 also patched up to date. My boot strap of GCC 4.2.1 fails at stage 2. Here is what I know. My approach with GCC has always been to bootstrap at least twice and then run the testsuites to verify that what I made was good. I didn't even get to the first bootstrap before I hit a problem. I make my own tool path and then build entirely with that toolpath. Within reason. No need to create a new kernel and I do use libiconv from Blastwave.org. Only because I forgot to build it and at the last minute I was too tired and it was too late so I put in --with-libiconv-prefix=/opt/csw on the configure line. So here is what I did I checked that I had sources to all the prerequisites : http://gcc.gnu.org/install/prerequisites.html Thus I built and tested clean with : gmp 4.2.1 gzip 1.3.12 make 3.81 bison 2.3 m4 1.4.10 mpfr 2.2.1 Each one of those passes all its tests with the exception of bison which skipped 7 that required root level access or some such minutia. Each of those was built with Sun ONE Studio 8 and I had the following environment variables set : TERM=vt100 SHELL=/usr/xpg4/bin/sh CPPFLAGS=-I/export/home/dclarke/local/include OLDPWD=/opt/build LD_OPTIONS=-R/export/home/dclarke/local/lib -L/export/home/dclarke/local/lib LC_ALL=C COLUMNS=80 PATH=/export/home/dclarke/local/bin:/opt/SUNWspro/bin:/usr/xpg4/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ccs/bin PWD=/opt/build/gcc-4.2.1-build EDITOR=/usr/xpg4/bin/vi LANG=C TZ=Canada/Eastern LINES=24 SHLVL=1 HOME=/export/home/dclarke LOGNAME=dclarke CC=cc _=/usr/xpg4/bin/env I am using the bash shell and more specifically I am using the latest release of bash. The configure line for GCC 4.2.1 looks like so : bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/configure --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local --with-local-prefix=/export/home/dclarke/local --enable-shared --with-libiconv-prefix=/opt/csw --enable-languages=c,c++,objc,fortran --with-gmp=/export/home/dclarke/local --with-mpfr=/export/home/dclarke/local --enable-bootstrap Note that I am not using gas or gld and this is the way I have done this for years. However, it has been years since I built GCC so who knows what error I have made. Also note that I restrict the languages to c,c++,objc,fortran for this initial bootstrap. It should not make a whole lot of difference but I am only interested in those. For now. The process seems to run fine and configure does what it does. I issue make ( which is really GNU make that I built previously ) and things grind away for a long long time until this appears : checking for msgmerge... no checking for sparc-sun-solaris2.8-gcc... /opt/build/gcc-4.2.1-build/./prev-gcc/xgcc -B/opt/build/gcc-4.2.1-build/./prev-gcc/ -B/export/home/dclarke/local/sparc-sun-solaris2.8/bin/ checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 1 make[2]: Leaving directory `/opt/build/gcc-4.2.1-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/opt/build/gcc-4.2.1-build' make: *** [all] Error 2 bash-3.2$ see this for all the details that follow : http://www.blastwave.org/dclarke/gcc-4.2.1/gcc-4.2.1-failure-details.txt Note that I do get a compiler from stage 1 but it seems unable to continue onto stage 2 : bash-3.2$ /opt/build/gcc-4.2.1-build/./prev-gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /export/home/dclarke/build/gcc-4.2.1/configure --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local --with-local-prefix=/export/home/dclarke/local --enable-shared --with-libiconv-prefix=/opt/csw --enable-languages=c,c++,objc,fortran --with-gmp=/export/home/dclarke/local --with-mpfr=/export/home/dclarke/local --enable-bootstrap Thread model: posix gcc version 4.2.1 bash-3.2$ So any thoughts there from anyone ? Dennis
Re: Bug 32346
On Wednesday 25 July 2007 14:40, David A. Greene wrote: > Has anyone had a chance to look at bug 32346 yet? The fact that its status > is still UNCONFIRMED and unassigned leads me to think not. Forgot to add that this bug still exists on trunk. -Dave
Bug 32346
Has anyone had a chance to look at bug 32346 yet? The fact that its status is still UNCONFIRMED and unassigned leads me to think not. -Dave
Re: GCC for Symbian
On Mon, 2007-07-23 at 00:52 +0300, Evgeniy Filatov wrote: > I am programmer, i am writing C/C++ programs for Nokia Series 60 > devices, and often i need to run some parts of code directly on > device. I think, not only me, but other symbian developers got same > problem. There are no C compiler, that runs directly on such devices. > That's why i want to ask: is there any version of gcc under Symbian > already exist or planned. If second, i can help to develope it. Why do you need to run the compiler directly on the device? That seems slow and probably very difficult. You should cross-compile applications from a faster general-purpose machine. Ben -- Ben Elliston <[EMAIL PROTECTED]> Australia Development Lab, IBM
Re: URGENT : elf_update - low performance with large files ? (fwd)
On Wed, Jul 25, 2007 at 08:50:13PM +0200, J.C. Pizarro wrote: > 2007/7/25, Joe Buck <[EMAIL PROTECTED]> wrote: > >On Wed, Jul 25, 2007 at 08:32:33PM +0200, J.C. Pizarro wrote: > >> Patch it to investigate it a little bit more. > >> > >> After runned it, see "quickdirty.log" and post here your report's > >summary. > > > >No, please do not. This is not the libelf list; use that list. > > Dear Joe, > > why not? > > It's more meaningful to see this kind of related information than to > divert it to nowhere. I didn't say to divert it to nowhere. I said to divert it to the libelf developers' list (or the libelf help list). We do the same when there's an issue with binutils, or glibc. Use the correct list. I gave a pointer earlier in the thread.
Re: URGENT : elf_update - low performance with large files ? (fwd)
On Wed, Jul 25, 2007 at 08:32:33PM +0200, J.C. Pizarro wrote: > Patch it to investigate it a little bit more. > > After runned it, see "quickdirty.log" and post here your report's summary. No, please do not. This is not the libelf list; use that list.
Re: GCC with formal testing docs
Joe Buck wrote: Right. However, some coverage-oriented methodologies explicitly mark code that is expected to be unreachable, and produce unit tests to exercise at least some of the defensive code that no longer gets run by the compiler as a whole. If any volunteers would like to take on the job of improving and tracking coverage (by a combination of more tests, unit tests, and marking code that is currently unreachable but should remain for safety purposes) that could be helpful. Absolutely, doing systematic coverage work of this kind would indeed be very helpful! I am not sure though that we want unit tests per se, much more useful are tests that excercise the code in the context of a complete gcc build.
Re: URGENT : elf_update - low performance with large files ? (fwd)
Patch it to investigate it a little bit more. After runned it, see "quickdirty.log" and post here your report's summary. ;) libelf-0.8.2_quickdirtyprint.patch Description: Binary data
Re: GCC with formal testing docs
On Wed, 2007-07-25 at 07:05 -0400, Robert Dewar wrote: > > If you build the compiler with coverage instrumentation and run the > > testsuite, you might get a shock. It's not as well tested as you might > > think. > > If it gave anyone a shock to find out that the test suite did not > provide 100% coverage, then that person is not very familiar with > compiler technology. It is by no means SOP to try to get 100% I guess I should have been more specific. The point I was trying to make is that the GCC testsuite was never intended to be a coverage testsuite. It is primarily a regression testsuite. I have run the testsuite under an instrumented compiler and, if I recall, the coverage averaged over all the files was about 40%. > coverage testing of a compiler, and in practice for many reasons, > very difficult (compilers often contain a lot of deactivated code > that comes from defensive programming against errors, since > compilers more than many programs routinely expect to be fed > rubbish, and work hard to behave nicely when mistreated in > this way :-) If you're determined enough, it is possible to test all of that code, too. Ben
