Re: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
Thank you for the very clarifying text below. Some version of it would surely be helpful in the gcc manual when introducing the -march and -mcpu/-mtune flags. Since I needed atomic read/writes of FP variables in a multi-threaded program, I have no other option than using the slow fld/fst instructions, which is still many times faster than locking/unlocking a mutex. Peter On Saturday 12 February 2005 11:42, Marcel Cox wrote: > Peter Soetens wrote: > > I was wondering why the above gcc parameter does not enable the use > > of the fst/fld opcodes for pentium processors, while -march=i686 > > does. The Intel manuals specifically say that they can be used across > > all pentium processors. > > There are 2 options to tell the compiler about your wanted processor. > The -march=xyz option tells you the instruction set to use, while the > -mcpu=xyz option tells you for which processor the program should run > fastest. > If you supply the -march option, but not the -mcpu option, then the > compiler will assume you use the same processor for both. > > The difference in the code you see are actually due to the -mcpu > option. For your first code example, you implicitly use -mcpu=586 and > for the second example, you use -mcpu=686. So your first code is > supposed to run fastest on a Pentium class processor while your second > code is supposed to run fastest on a Pentium2 class processor. > Now, an a Pentium processor, the FLD and FST instructions are > (relatively) expensive. So the compiler decides it is faster to do > load/store operations using integer registers. On Pentium2 class > processors, the FLD and FST instructions are much faster, and now the > compiler considers it worthwhile to use them. > > Now if you want to generate code that will be guaranteed to run on > Pentium processors, but runs best on Pentium2 class processors, you > have to use both the options -march=pentium and -mcpu=pentium2 (you can > also use 586 and 686 which are aliases, but I would recommend you to > use real processor names) > Of course, as Pentium2 processors are not so common any more either, > you can also tune your code for Pentium4 using -mcpu=pentium4, or for > AMD Athlon processors using -mcpu=athlon or some specific athlon model. > > Note that on newer versions of GCC (starting with 3.4.0), the -mcpu > option has been deprecated and replaced by the -mtune option to be > consistent with other processor architectures supported by GCC. -- Peter Soetens, Research Assistant http://www.orocos.org Katholieke Universiteit Leuven Division Production Engineering, tel. +32 16 322773 Machine Design and Automation fax. +32 16 322987 Celestijnenlaan 300B [EMAIL PROTECTED] B-3001 Leuven Belgium http://www.mech.kuleuven.ac.be/pma
Re: Details for svn test repository
On Sat, 2005-02-12 at 02:53, Daniel Berlin wrote: > On Fri, 2005-02-11 at 18:40 -0800, Mike Stump wrote: > > On Friday, February 11, 2005, at 05:29 PM, Daniel Berlin wrote: > > > I'll keep the last branchpoint of each branch for the initial import > > > > Won't work either... Sometimes we reuses merge labels in non-obvious > > ways. top-200501-merge and top-200502-merge both exist, the two were > > used for, say, treeprofiling, and then a random other (important) > > branch uses the first for its merge. > > > > Also, even if you could track those down (you can't), it still would > > obliterate merge auditing, which is a very useful feature to find how > > exactly how someone screwed up a past merge. > > > > I don't see the advantage of wiping those labels yet. > > > > > If you left all labels mentioned in any log entry, that would almost > > solve most instances that I know about, but, sometimes people misspell > > the tags in obvious ways in the log messages. > > > > Fine, i'll just keep all the non-snapshot tags for now. There's no reason why we have to keep all the tags in one place. The SVN book goes on about trunk, branch and tag top-level directories, but there's no reason to stick to just those. We could, for example have rel-branch and rel-tag directories for the main releases and then keep branch and tag for development work (or we could do it the other way around). For the case above, we could have non-snapshot as the top-level directory. The limit seems to be your ingenuity... R.
Add myself to MAINTAINERS (write after approval)
Index: MAINTAINERS === RCS file: /cvs/gcc/gcc/MAINTAINERS,v retrieving revision 1.394 diff -c -3 -p -r1.394 MAINTAINERS *** MAINTAINERS 10 Feb 2005 23:29:41 - 1.394 --- MAINTAINERS 14 Feb 2005 11:19:52 - *** Jeff Knaggs [EMAIL PROTECTED] *** 249,254 --- 249,255 Michael Koch [EMAIL PROTECTED] Matt Kraai[EMAIL PROTECTED] Scott Robert Ladd [EMAIL PROTECTED] + Razya Ladelsky[EMAIL PROTECTED] Aaron W. LaFramboise [EMAIL PROTECTED] Marc Lehmann [EMAIL PROTECTED] Alan Lehotsky [EMAIL PROTECTED]
Re: temp obj created by compiler
In article <[EMAIL PROTECTED]> you write: >Thanks Jon, > >Can anyone throw more light on this. > Stop telling us what you want to do, explain to us WHY you want to do it. There are lots of different reasons for which you might want to know more about temporary object generation, and we can probably give you a more detailed answer only if you tell us what you're trying to achieve. If you want to do something nasty that depends on the location where the temporary objects are generated, then you're probably going to lose, as a C++ compiler is generally permitted to optimize a lot of stuff away, and this kind of stuff will tend to vary widely from one gcc version to the next. If you want to understand the rules, then you're better off reading the C++ standard and related articles. From my point of view, discussions about expression templates and the lifetime of temporaries have been invaluable. If you just want to look at gcc output for self-teaching purposes, then that's another story entirely...
fprintf symbol in libgcc of gcc 3.3 vs 4.0
I am trying to find out if there has been some change to the internal symbol name associated with fprintf in libgcc of gcc 4.0 compared to gcc 3.3. In particular, I am concerned about being able to use the linker from gcc 4.0 to link in IBM Fortran XL code with gcc 4.0 compiled code using the libgcc.a from gcc 4.0. Specifically does the same _fprintf exist in libgcc.a on both gcc 3.3 and gcc 4.0? If not what can one do work around such symbol changes short of waiting for any update of the IBM Fortran XL compiler? Jack
Re: fprintf symbol in libgcc of gcc 3.3 vs 4.0
Jack Howarth wrote: I am trying to find out if there has been some change to the internal symbol name associated with fprintf in libgcc of gcc 4.0 compared to gcc 3.3. In particular, I am concerned about being able to use the linker from gcc 4.0 to link in IBM Fortran XL code with gcc 4.0 compiled code using the libgcc.a from gcc 4.0. Specifically does the same _fprintf exist in libgcc.a on both gcc 3.3 and gcc 4.0? If not what can one do work around such symbol changes short of waiting for any update of the IBM Fortran XL compiler? fprintf is not part of libgcc, it is part of the c runtime (libc). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: fprintf symbol in libgcc of gcc 3.3 vs 4.0
On Feb 14, 2005, [EMAIL PROTECTED] (Jack Howarth) wrote: > I am trying to find out if there has been some change to the > internal symbol name associated with fprintf in libgcc of gcc 4.0 > compared to gcc 3.3. There's no fprintf symbol in libgcc. fprintf is provided by the C library of the system, GCC just uses it. gcc-help would have been a more appropriate mailing list for this question. This mailing list is for discussion on the development *of* GCC (not *with* GCC). -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
cc1 ICEs building libiberty/sort.c if built with gcc-3.4 -g
Hi! I get a strange ICE if building (not bootstrapping) mainline with current 3.4 branch with CFLAGS="-g": /tmp/gcc-obj-checking/gcc/xgcc -B/tmp/gcc-obj-checking/gcc/ -B/i686-pc-linux-gnu/bin/ -B/i686-pc-linux-gnu/lib/ -isystem /i686-pc-linux-gnu/include -isystem /i686-pc-linux-gnu/sys-include -c -DHAVE_CONFIG_H -O2 -g -I. -I/net/alwazn/home/rguenth/src/gcc/gcc/libiberty/../include -W -Wall -Wtraditional -pedantic /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c -o sort.o /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c: In function 'sort_pointers': /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c:51: internal compiler error: in insert_aux, at tree-ssa-pre.c:1624 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. So, this is gcc 3.4.4 miscompiling HEAD with -g such that the built compiler ICEs as above. gcc-3.4 (GCC) 3.4.4 20050112 (prerelease) Is this even worth entering into the bug database? I guess nobody will do a build with just -g. What would be the appropriate testcase? Thanks, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Re: cc1 ICEs building libiberty/sort.c if built with gcc-3.4 -g
Richard Guenther <[EMAIL PROTECTED]> wrote: > I get a strange ICE if building (not bootstrapping) mainline with > current 3.4 branch with CFLAGS="-g": > > /tmp/gcc-obj-checking/gcc/xgcc -B/tmp/gcc-obj-checking/gcc/ > -B/i686-pc-linux-gnu/bin/ -B/i686-pc-linux-gnu/lib/ -isystem > /i686-pc-linux-gnu/include -isystem /i686-pc-linux-gnu/sys-include -c > -DHAVE_CONFIG_H -O2 -g -I. > -I/net/alwazn/home/rguenth/src/gcc/gcc/libiberty/../include -W -Wall > -Wtraditional -pedantic > /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c -o sort.o > /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c: In function > 'sort_pointers': > /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c:51: internal > compiler error: in insert_aux, at tree-ssa-pre.c:1624 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > So, this is gcc 3.4.4 miscompiling HEAD with -g such that the built > compiler ICEs as above. > > gcc-3.4 (GCC) 3.4.4 20050112 (prerelease) > > Is this even worth entering into the bug database? Yes, it is a miscompilation of GCC 3.4 which we should fix because we still maintain GCC. Moreover, it is possible that the same bug is latent in HEAD. > I guess nobody will do a build with just -g. That does not matter. The bug could trigger with different code. > What would be the appropriate > testcase? First, preprocess the sort.c above as a testcase for the miscompilation. Then you'd need to find out which file is miscompiled. It is possible that it is tree-ssa-pre so that would be the first thing to check (e.g. recompile only that file without -g, relink xgcc, and try running sort.i to see if it still ICEs). After that, you could try to find out which function is being miscompiled and compare the assembly / RTL dumps. A bug in Bugzilla would probably have a standalone (preprocessed) copy of the function being miscompiled and a diff of the assembly files showing the miscompilation. Others are surely more expert than me at analyzing this kind of issues, so maybe they have better solutions. -- Giovanni Bajo
Re: cc1 ICEs building libiberty/sort.c if built with gcc-3.4 -g
Ignore this - happens only when building HEAD with some local patches. Richard. On Mon, 14 Feb 2005, Richard Guenther wrote: > Hi! > > I get a strange ICE if building (not bootstrapping) mainline with > current 3.4 branch with CFLAGS="-g": > > /tmp/gcc-obj-checking/gcc/xgcc -B/tmp/gcc-obj-checking/gcc/ > -B/i686-pc-linux-gnu/bin/ -B/i686-pc-linux-gnu/lib/ -isystem > /i686-pc-linux-gnu/include -isystem /i686-pc-linux-gnu/sys-include -c > -DHAVE_CONFIG_H -O2 -g -I. > -I/net/alwazn/home/rguenth/src/gcc/gcc/libiberty/../include -W -Wall > -Wtraditional -pedantic > /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c -o sort.o > /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c: In function > 'sort_pointers': > /net/alwazn/home/rguenth/src/gcc/gcc/libiberty/sort.c:51: internal > compiler error: in insert_aux, at tree-ssa-pre.c:1624 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > So, this is gcc 3.4.4 miscompiling HEAD with -g such that the built > compiler ICEs as above. > > gcc-3.4 (GCC) 3.4.4 20050112 (prerelease) > > Is this even worth entering into the bug database? I guess > nobody will do a build with just -g. What would be the appropriate > testcase? > > Thanks, > Richard. > > -- > Richard Guenther > WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ > > -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Su e-mail fue recibido, se responderá a la brevedad, gracias
Re: GCC 4.0 Status Report (2005-02-03) - SMS improvements
> * Project Title SMS (Modulo Scheduling) Improvements. > > * Project Contributors Mostafa Hagog > > * Dependencies No dependencies. > > * Delivery Date Ready, currently committed to the autovect-branch. > > * Description > > Describe the project *in detail*. > > What will you be doing? 1. Make the tree loop-versioning usable in RTL cfg-layout mode by making it a cfg hook. 2. Move SMS to use cfg-layout mode. 3. Use loop information to detect simple loops. 4. Replace the loop versioning in SMS by using the RTL loop-versioning. 5. Several other improvements: 1. Check if the SMSed loop kernel is more efficient in means of number of cycles if not undo the changes. We do this by feeding the loop kernel into the DFA and counting the number of cycles before and after SMS - if we didn't improve (there is a chance because of the register copies we add) we prefer the original loop. 2. Ignore register anti-dependencies - use register copies instead. 3. Add backtracking to the scheduling algorithm; When failing to find a cycle within a kernel of II cycles for a given node we used to restart the whole process with kernel of II + 1. Now we try to unscheduled some of the nodes that the one we failed on depends on and schedule the failing node first, then try the other nodes. > > What parts of the compiler will be modified? tree loop-versioning, cfg-hooks, modulo scheduler (SMS). > > What will the benefits of your change be? (Be specific -- for > example, if you will be improving code quality, indicate what kind > of code, and, if possible, how great the improvement will be.) 1. More loops will be applicable to SMS. 2. SMS is undone when it is not profitable, so we don't increase code size in cases we don't gain much. 3. Better schedules - due to backtracking. > > What risks do you foresee? (If you say "none", you'll be asked to > resubmit...) What will you be doing to mitigate those risks? The only risk is to affect the tree level loop versioning and the modulo-scheduling.
Merging GNU Classpath and gcc/libgcj bug databases
Hi GCC and GNU Classpath and libgcj hackers, This is a request for comments on moving the GNU Classpath bug reports (currently on savannah.gnu.org) into the gcc bugzilla database (as a separate project). This will ease sharing information between the GNU Classpath and GCC/GCJ hackers. We have discussed the impact of this with Daniel Berlin and the rest of the GCC Bugmasters who don't see any technical or maintenance problems with this. It would solve an important problem for the GNU Classpath and gcj hackers who are now relying on two different bug databases without an easy way to move bugs between them. If there are no objections we would like to close down the savannah bug tracker for GNU Classpath and add a new "product" classpath in GCC bugzilla which contains all the current bug reports. This new 'classpath' product shall be used exclusively in the future for all core library bug reports in either GNU Classpath or libgcj as long as they are "generic" bugs. The libgcj component in the gcc bugzilla product would still be used for bugs in the runtime, as distinct from the class libraries (ie classpath), and for bugs in the few GCJ-specific classes that still exist. I will send a proposal for the module names, standard bug mailinglist and version numbers to use for this new classpath product in the database to the classpath and libgcj development mailinglists soon. The current gcc modules AWT and SWING would also move to this new product. Which should help with the issue that gcc bugzilla product currently has a lot of modules already. Some background information. GNU Classpath core class library has been mostly merged with libgcj for a couple of years now. The main technical difference between them is that libgcj is tightly integrated with the actual gcj/libffi/boehmgc runtime from GCC and GNU Classpath is explicitly kept "execution mechanism neutral". There are about 20 other runtimes and/or compilers based on GNU Classpath next to gcj. Although gcj is probably the most widely distributed one. And the "official GNU supported" one. The FSF sees libgcj and classpath as "merged". And paperwork for libgcj and GNU Classpath is handled in the same way (like the rest of GCC). GNU Classpath is hosted on http://www.gnu.org/software/classpath/ for the public webpages and uses savannah.gnu.org most developer resources (cvs, mailinglists). We have a separate development machine developer.classpath.org for dynamic content, scripts, and developer wikis, etc and http://planet.classpath.org/ for blog aggregation of the various GNU Classpath (and related project) hackers. GCC is mainly hosted on one machine gcc.gnu.org with their own cvs, wiki, mailinglists and bugzilla database separate from the savannah.gnu.org bugtracker. GNU Classpath is maturing and provides a serious free alternative to the proprietary core libraries for the java programming language. And gcj has been made a solid member of the GNU Compiler Collective that is actively being used by more and more people. We are now getting bugreports through different channels. Having multiple bug databases against which users report bugs is causing serious problems since monitoring the different bug databases and moving bugs between them is not trivial. The upcomming GCC 4.0 will have a gcj mature enough to support large free software projects written in the java programming language like Eclipse, lots of the Apache projects and java-gnome applications. So we are expecting a lot of new bug reports for classpath to be reported through the gcc bugdatase. So sharing the bug database architecture/backend with the GCC project makes a lot of sense. By having it as a separate project we hope to also facilitate the other free compilers and runtimes based on GNU Classpath. Cheers, Mark Wielaard GNU Classpath Maintainer signature.asc Description: This is a digitally signed message part
Re: Merging GNU Classpath and gcc/libgcj bug databases
On Mon, Feb 14, 2005 at 05:53:09PM +0100, Mark Wielaard wrote: > This is a request for comments on moving the GNU Classpath bug reports > (currently on savannah.gnu.org) into the gcc bugzilla database (as a > separate project). This will ease sharing information between the GNU > Classpath and GCC/GCJ hackers. I think it's a good idea; I'd like to see as much coordination between classpath and gcj development as possible.
Re: Merging GNU Classpath and gcc/libgcj bug databases
On Mon, 14 Feb 2005, Mark Wielaard wrote: > I will send a proposal for the module names, standard bug mailinglist > and version numbers to use for this new classpath product in the > database to the classpath and libgcj development mailinglists soon. The > current gcc modules AWT and SWING would also move to this new product. > Which should help with the issue that gcc bugzilla product currently has > a lot of modules already. I think we should continue to auto-cc gcc-bugs@gcc.gnu.org on all bug reports in the database, in addition to whatever extra lists are already used for Java bug reports or will be used for Classpath bugs. The merge of databases seems to make sense to me. -- 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: Details for svn test repository
On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote: Fine, i'll just keep all the non-snapshot tags for now. There's no reason why we have to keep all the tags in one place. Further, we can import them all, and then later remove, move or rename them and these things seem to be versioned(?). I can't imagine that the size of tags would matter, I think we should do that. We could even move old tags to a directory called old if we wanted to, to help sort out the chaff and reduce clutter while still allowing people doing archeology to be able to easily find them. It seems safer to import them all, and then remove them in the new system, as it seems to be trivial to restore any mistakes, while, if they go missing in the import, putting any tag back would be, uhm, hard.
Re: help regarding suif
Vivek, GCC and the GNU project have nothing to do with SUIF. If you want to ask questions about SUIF, you should do so on a more appropriate mailing list. I suggest you look here: http://www-suif.stanford.edu/mailman/listinfo/suif-talk/ Good luck. --Bob
Re: Details for svn test repository
On Mon, 2005-02-14 at 10:47 -0800, Mike Stump wrote: > On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote: > >> Fine, i'll just keep all the non-snapshot tags for now. > > > > There's no reason why we have to keep all the tags in one place. > > Further, we can import them all, and then later remove, move or rename > them and these things seem to be versioned(?). Yes. Thus, your real problem is that if you look at older revisions of the tags directory, it will be ugly as hell :) > I can't imagine that > the size of tags would matter, I think we should do that. We cou > even move old tags to a directory called old if we wanted to, to help > sort out the chaff and reduce clutter while still allowing people doing > archeology to be able to easily find them. It seems safer to import > them all, and then remove them in the new system, as it seems to be > trivial to restore any mistakes, while, if they go missing in the > import, putting any tag back would be, uhm, hard. Also realize constructing all these tags makes conversion a lot slower (it multiples the number of times we have to spawn "co" by a lot. Please don't point out the obvious way of fixing this, but i don't really have time right now to try to make a one time process much faster by not spawning co a million times and instead enumerating the plaintexts into a database) If we really want all the tags, i have no plans to make them *all* available before we switch. I have made the non-branch-point, non-snapshot, non-merge ones available in the next version of the converted repo, which is being uploaded. This actually includes apple-gcc-, since that wasn't cuaght by my exclude regex. :)
warning: conflicting types for built-in function %qD
In the C front end, when diagnose_mismatched_decls sees a declaration of a function whose name is the same as a builtin's but whose types are different, we use the declaration we see but we issue a warning. For example: [isolde:tmp]$ cat foo.c extern double scalb ( double, int ); [isolde:tmp]$ /work/root.apple/bin/gcc -c foo.c foo.c:1: warning: conflicting types for built-in function 'scalb' This warning is unconditional. As you can see from the above example, we don't even need -Wall to see it. The only way to turn it off, in fact, is to use the heavy-handed -w. What was the rationale behind issuing this warning? I find it rather unfriendly. In this example, after all, the user isn't doing anything wrong. scalb is not defined in any standard that I can see, and users have every right to declare a function called scalb with whatever types they like. Earlier versions of the compiler did not issue this warning, and the C++ front end still doesn't. I'd like to see this warning removed, or at the very least tamed. --Matt
Re: Merging GNU Classpath and gcc/libgcj bug databases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Wielaard wrote: If there are no objections we would like to close down the savannah bug tracker for GNU Classpath and add a new "product" classpath in GCC bugzilla which contains all the current bug reports. This new 'classpath' product shall be used exclusively in the future for all core library bug reports in either GNU Classpath or libgcj as long as they are "generic" bugs. What's the plan for auxiliary classpath modules such as inetlib and cp-tools? Are they still managed in the Savannah bug tracker? - -- Chris Burdess -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCEQEU6dl1DEqHgrgRAu5XAKCOJPpHjBZz3lC2+BX4BgM0h/Ro3wCfR3ym 42mdQvxBtoJ02i2SIZK+Ots= =AU3Q -END PGP SIGNATURE-
Re: warning: conflicting types for built-in function %qD
On Mon, 14 Feb 2005, Matt Austern wrote: > What was the rationale behind issuing this warning? I find it rather > unfriendly. In this example, after all, the user isn't doing anything wrong. > scalb is not defined in any standard that I can see, and users have every > right to declare a function called scalb with whatever types they like. scalb is defined in POSIX (albeit as obsolescent). Reusing an identifier with external linkage to refer to something other than the standard function with that name yield undefined behavior. We don't yet have the facility to specify to the compiler that you are using functions from a particular version of POSIX (for example), so those should be built in but other extensions should not (although -std=c89 or -std=c99 will disable built-ins outside the selected standard), and nor do we any longer have a way of distinguishing from the DECL of a built-in function whether it is one from the selected C standard or otherwise, which is one factor which could affect whether to warn, although we did used to have DECL_BUILT_IN_NONANSI and could add it back again if useful. The fine-grained way to disable this warning is by disabling the built-in function with -fno-builtin-scalb. > Earlier versions of the compiler did not issue this warning, and the C++ front > end still doesn't. I'd like to see this warning removed, or at the very > least tamed. 3.4.3 does issue the warning. If you use a function such as "abs" which is built-in in the earlier versions, they issue the warning as well (on all the versions I tested from 3.3.4 back to 2.7.2.3). Built-in function handling is naturally somewhat different for C++; there are no implicit function declarations and standard functions must be declared through use of the appropriate system header. But it would seem reasonable for the C++ compiler to warn as well for extern "C" declarations conflicting with built-in functions. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Profiling & nested functions
Hi,
Is GCC + gprof supposed to handle nested functions?
It looks like they are not properly reported.
The original problem was on Ada code with nested
functions. This is with HEAD and GNU gprof 2.15.91.0.2
on a SuSE 9.2 system.
Thanks in advance,
Laurent
$ cat cn.c
#define N 1000
static int sum=0;
void p1(void) {
int i;
for(i=1;i<=N;i++) sum+=(i+1)/i;
}
void p2(void) {
int f2(int x) {
return x;
}
int i;
for(i=1;i<=2*N;i++) sum+=f2(i+1)/i;
}
void p3(void) {
int i;
for(i=1;i<=3*N;i++) sum+=(i+1)/i;
}
int main(void) {
p1();
p2();
p3();
return 0;
}
$ gcc -pg -g cn.c
$ ./a.out
$ gprof ./a.out
[...]
Flat profile:
% cumulative self self total
time seconds secondscalls s/call s/call name
49.49 8.70 8.701 8.70 8.70 p3
34.13 14.70 6.001 6.00 6.00 p2
16.38 17.58 2.881 2.88 2.88 p1
[...]
index % timeself childrencalled name
[1]100.00.00 17.58 main [1]
8.700.00 1/1 p3 [2]
6.000.00 1/1 p2 [3]
2.880.00 1/1 p1 [4]
---
8.700.00 1/1 main [1]
[2] 49.58.700.00 1 p3 [2]
---
2000 p2 [3]
6.000.00 1/1 main [1]
[3] 34.16.000.00 1+2000 p2 [3]
2000 p2 [3]
---
2.880.00 1/1 main [1]
[4] 16.42.880.00 1 p1 [4]
---
Re: Merging GNU Classpath and gcc/libgcj bug databases
Hi Chris, On Mon, 2005-02-14 at 19:50 +, Chris Burdess wrote: > What's the plan for auxiliary classpath modules such as inetlib and > cp-tools? Are they still managed in the Savannah bug tracker? The current plan is to also move them over and assign them separate categories/modules in the new 'classpath' product. This will make it easier to just point any "GNU Classpath related product" user to the same bug database. That will also make it easier for us hackers to correctly move bugs to another module if it is determined that the bug is in some other subsystem. See my follow up email to the classpath and gcj mailinglist for the proposal of the actual module and version names to use. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: warning: conflicting types for built-in function %qD
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: | On Mon, 14 Feb 2005, Matt Austern wrote: | | > What was the rationale behind issuing this warning? I find it rather | > unfriendly. In this example, after all, the user isn't doing anything wrong. | > scalb is not defined in any standard that I can see, and users have every | > right to declare a function called scalb with whatever types they like. | | scalb is defined in POSIX (albeit as obsolescent). Reusing an identifier | with external linkage to refer to something other than the standard | function with that name yield undefined behavior. We don't yet have the But the program at issue does not invoke anything having to do with POSIX, it makes no sense to pretend it has undefined behaviour. IMO, the C++ front-end does the right thing. After all, POSIX is just a C binding, with contradictroy requirements. | facility to specify to the compiler that you are using functions from a | particular version of POSIX (for example), so those should be built in but | other extensions should not (although -std=c89 or -std=c99 will disable | built-ins outside the selected standard), and nor do we any longer have a | way of distinguishing from the DECL of a built-in function whether it is | one from the selected C standard or otherwise, which is one factor which | could affect whether to warn, although we did used to have | DECL_BUILT_IN_NONANSI and could add it back again if useful. | | The fine-grained way to disable this warning is by disabling the built-in | function with -fno-builtin-scalb. | | > Earlier versions of the compiler did not issue this warning, and the C++ front | > end still doesn't. I'd like to see this warning removed, or at the very | > least tamed. | | 3.4.3 does issue the warning. If you use a function such as "abs" which | is built-in in the earlier versions, they issue the warning as well (on | all the versions I tested from 3.3.4 back to 2.7.2.3). There is a difference between "abs" and "scalb". | | Built-in function handling is naturally somewhat different for C++; there | are no implicit function declarations and standard functions must be | declared through use of the appropriate system header. But it would seem | reasonable for the C++ compiler to warn as well for extern "C" | declarations conflicting with built-in functions. having the C++ front-end misbehaves as the C front-end does on scalb would be the wrong path. -- Gaby
RFC: Appropriate method for target-specific mode-substititutes in libgcc2
Hi, I'd like to discuss with you a topic related to a recent bootstrap failure of a couple of smaller embedded targets. The origin of the failure could be removed easily. In my opinion the question is simply, what is the best way to implement it? Root of the problem is that libgcc2 presently does not consider target dependencies properly for smaller targets: Namely, for several smaller targets double is defined to be the same as float, or there possibly might be no support for long longs (>= 64 bits). Since libgcc2 explicitly refers to DI, DF or DC modes presently, gcc runs into problems when it tries to compile functions that use modes that are not implemented by the back-ends. My suggestion in order to deal with this issue is to change libgcc2.h such that it includes the target specific tm.h . Establish a convention that, when the target machine header file defines symbols with the standard names #define TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DI SI #define TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_TI DI #define TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_XF SF #define TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF SF #define TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DC SC , the value that these macros expand to should substitute the definitions of e.g. typedef float DFtype __attribute__ ((mode (DF))); Namely, I'd suggest to change libgcc2.h such that above line would read #ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF typedef float DFtype __attribute__ ((mode (DF))); #else typedef float DFtype __attribute__ ((mode (TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF))); #endif I would be willing to implement it and present a patch for detailed discussion. However prior to starting, I'd appreciate comments. Looking forward to hearing from you. Yours, BJörn
Re: warning: conflicting types for built-in function %qD
On Mon, 14 Feb 2005, Gabriel Dos Reis wrote:
> But the program at issue does not invoke anything having to do with
> POSIX, it makes no sense to pretend it has undefined behaviour.
The GNU C dialect, which is the default, includes various built-in
functions from POSIX as well as various other miscellaneous built-in
functions.
> There is a difference between "abs" and "scalb".
One difference is incidental and historical - which GCC versions had which
built-in functions. The other - which are present in a given standard -
is now visible in builtins.def but not in the DECLs themselves.
If we resurrect some form of DECL_BUILT_IN_NONANSI to distinguish them in
the DECLs - and only warn for redeclarations of standard functions - we
should make sure there is still a warning for
int f(long double x) { return signbitl(x); }
long signbitl(void);
which calls a non-standard built-in function (where the type of the
implicit declaration is compatible with that of the built-in function)
then redeclares the function with an incompatible type: such
redeclarations should be diagnosed if the built-in function has already
been called in the translation unit.
--
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: GCC 4.0 Status Report (2005-02-03)
Mark Mitchell <[EMAIL PROTECTED]> writes: > Steven Bosscher wrote: > > Or should the development plan beupdated to reflect your new way of > > working (ie. the projects info collecting thing) and the actual > > development schedule that we seem to be working on. > > It would probably be good if the development document was updated to > reflect the new procedure -- after we're sure we like it. I'm a > little hesitant to take the 4.0 experiment and judge it "the Right > Way" at this point. Let's see how 4.1 goes. If you still think that the current development document describes "the Right Way", then we should be following it. If not, then could we have a document saying what we *are* following? Otherwise, it's really just whatever your whim is, and that goes against the spirit (and the mission statement) of the GCC project.
Re: Details for svn test repository
Daniel Berlin <[EMAIL PROTECTED]> writes: > I also plan on excluding merge tags I'd really rather that you didn't. Those tags are useful when you're looking at some old change on a branch.
Re: Details for svn test repository
On Mon, 2005-02-14 at 15:20 -0800, Geoffrey Keating wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > > I also plan on excluding merge tags > > I'd really rather that you didn't. Those tags are useful when you're > looking at some old change on a branch. I meant for the test repo. However, i'll try to make a test repo with them all in there, and see how long it takes.
Re: GCC 4.0 Status Report (2005-02-03)
Geoffrey Keating wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: Steven Bosscher wrote: Or should the development plan beupdated to reflect your new way of working (ie. the projects info collecting thing) and the actual development schedule that we seem to be working on. It would probably be good if the development document was updated to reflect the new procedure -- after we're sure we like it. I'm a little hesitant to take the 4.0 experiment and judge it "the Right Way" at this point. Let's see how 4.1 goes. If you still think that the current development document describes "the Right Way", then we should be following it. If not, then could we have a document saying what we *are* following? Otherwise, it's really just whatever your whim is, and that goes against the spirit (and the mission statement) of the GCC project. Since you and Steven seem to think that it would be helpful to update the document, I'll put that on my to-do list. I spend a lot of time thinking about how to make this process work more smoothly, and I spend a lot of time talking to people -- including you -- about how they think it should work. I don't think the current document decribes the ideal procedure; if I did, I wouldn't be soliciting project proposals. It was no secret that I planned to ask for proposals early in Stage 1 for 4.1; that was announced after the request-for-proposal experiment in GCC 4.0 worked out well. This is a relatively minor change to the development plan; it's a refinement of how things get sequenced in Stage 1, in the hopes that we can avoid the mainline becoming more unstable than necessary, and so that everyone can see -- and comment on -- what's going to be going in before it actually gets merged. I consider that to be rather more in keeping with the openness described in the GCC mission statement than simply posting a message saying "I merged in the foo branch". -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
SVN Test Repo updated
The SVN test repo has been updated. annotate should work at a reasonable speed (< 2 minutes for a file), *except* on the changelog. It spends a long time just groveling the file history. People who try to run annotate on the ChangeLog will be beaten severely. I'm building a bdb test repo to see if it's any better at this, even though it will be slightly *slower* at most other operations. The test repo now includes tags. Please note that you will have to destroy any working copies you've got checked out right now, as updating them will not work. This is due to the inclusion of tags and exclusion of unlabeled tags, so now the revision numbers will not be the same as they were before, so trying to update an existing working copy is liable to just piss off svn and tell you there is no revision 75699
Re: SVN Test Repo updated
On Mon, 2005-02-14 at 18:54 -0500, Daniel Berlin wrote: > The SVN test repo has been updated. annotate should work at a reasonable > speed (< 2 minutes for a file), *except* on the changelog. It spends a > long time just groveling the file history. People who try to run > annotate on the ChangeLog will be beaten severely. > > I'm building a bdb test repo to see if it's any better at this, even > though it will be slightly *slower* at most other operations. > > The test repo now includes tags. > > Please note that you will have to destroy any working copies you've got > checked out right now, as updating them will not work. > This is due to the inclusion of tags and exclusion of unlabeled tags, so > now the revision numbers will not be the same as they were before, so > trying to update an existing working copy is liable to just piss off svn > and tell you there is no revision 75699 > > Oh, btw, a lot of any remaining blame slowness will be cleared up in the next update, and some of it would require a server version update to the 1.2 trunk.
Re: Details for svn test repository
On 2005-02-14, at 19:47, Mike Stump wrote: On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote: Fine, i'll just keep all the non-snapshot tags for now. There's no reason why we have to keep all the tags in one place. Further, we can import them all, and then later remove, move or rename them and these things seem to be versioned(?). I can't imagine that the size of tags would matter, I think we should do that. We could even move old tags to a directory called old if we wanted to, to help sort out the chaff and reduce clutter while still allowing people doing archeology to be able to easily find them. It seems safer to import them all, and then remove them in the new system, as it seems to be trivial to restore any mistakes, while, if they go missing in the import, putting any tag back would be, uhm, hard. Hmm... What about the "trivial" strategy of automatic commit mirroring for a sufficient long time? I guess old information deflates in value pretty fast (maybe about one year?). Could be easier to implement.
Re: Details for svn test repository
On Tue, 2005-02-15 at 00:55 +0100, Marcin Dalecki wrote: > On 2005-02-14, at 19:47, Mike Stump wrote: > > > On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote: > >>> Fine, i'll just keep all the non-snapshot tags for now. > >> > >> There's no reason why we have to keep all the tags in one place. > > > > Further, we can import them all, and then later remove, move or rename > > them and these things seem to be versioned(?). I can't imagine that > > the size of tags would matter, I think we should do that. We could > > even move old tags to a directory called old if we wanted to, to help > > sort out the chaff and reduce clutter while still allowing people > > doing archeology to be able to easily find them. It seems safer to > > import them all, and then remove them in the new system, as it seems > > to be trivial to restore any mistakes, while, if they go missing in > > the import, putting any tag back would be, uhm, hard. > > Hmm... What about the "trivial" strategy of automatic commit mirroring > for a sufficient > long time? I guess old information deflates in value pretty fast (maybe > about one year?). > Could be easier to implement. > It's not easier to implement. Trying to translate cvs into changesets is not easy (though the reverse is), unless you do it the stupid way (IE not try to discover what is a copy and what isn't). So matching commit for commit won't give you good history. Especially on branches. We did convresion this way with bugzilla and it worked okay. I just translated the gnats database every so often. The more important part is that people feel comfortable using the tool. making the data all look right is the easy part :)
Using up double diskspace for working copies (Was Re: Details forsvn test repository)
Daniel Berlin wrote: > On Fri, 2005-02-11 at 15:29 +, Joern RENNECKE wrote: > > Daniel Berlin wrote: > > > > > > > > > > >>Because svn keeps an extra pristine copy for checkouts, I'll have to use > > >>svn export for > > >>automatic regression tests. > > >> > > >> > > > > > >I don't understand why. > > >Is this because of the amount of space the working copy takes up? > > > > > > > > > > Yes. Sometimes stuff breaks and you don't notice it right away (E.g. > > because the > > feature is not automatically tested, or because of noise from other test > > failures). > > So it is useful to keep several month worth of test builds around. > > Doubling the > > amount of space taken up by this is not acceptable. > > Then you are correct, the only way to do what you want is export, or cp > excluding the .svn directories. > Do you consider this a show stopper, or are you willing to export your > trees? > Because if it's a show stopper, then so will be arch, monotone, or any > of our other replacements (they all either store the entire repo on your > disk, or have stuff in the working copy), and we will be stuck with cvs > until everyone is happy to use up double/whatever disk. This is not actually true. Both ArX and tla support hardlinking the tree against the extra pristine copy. In fact, for the use case given (lots of old test builds), some or all could be linked against each other. If you are worried about hard links because you might muck all of your different versions with careless editing, ArX at least will let you get away without a pristine tree. It then builds a new one when needed, and then deletes it. Regards, Walter Landry [EMAIL PROTECTED]
Re: [Q] initialisation of variable allocated wirh alloca in 'loop.c'
Christophe Jaillet wrote: In loop.c, around line 8887, shouldn't the memory allocated by alloca be 'memseted' in some way ? Look closer, and you will see that only array values that are set are used. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: problem
Virender Kashyap wrote: I have written a small structure (function_cfg_info) to hold CFG information (defined in new file tree-cfg.h) and wanted to add this to call graph node data structure (in cgraph.h). This list isn't for people trying to learn how to write C code. It is for people trying to work on gcc development. There are better places to ask beginner questions, such as gcc-help. You should also read the instructions on reporting bugs. You didn't include the error message you got. You also apparently didn't include a full example, as you claim that you included tree-cfg.h, but there is no #include in your example. It should work with the missing #include. See http://gcc.gnu.org/bugs.html -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: SVN Test Repo updated
Another incidental observation from experiments with subversion: the output from svn diff seems to be in a fairly random order (rather than alphabetical order of filenames). Alphabetical order tends to be easier to follow when checking svn diff output to see that the changes you're about to commit are exactly those you intended to commit and that the ChangeLog entries you've written correspond to those changes (e.g. the list of files - alphabetical - in the ChangeLog entries covers all the files in the svn diff output). -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
