Re: unused variable warning
skaller <[EMAIL PROTECTED]> writes: > In gcc/g++ version 4.0 there is no way to turn off the > unused variable warning enabled by -Wall with a command > line switch. How about -Wno-unused-variable? > I think this is a bug: it should be possible to selectively > turn on or off all warnings (on the command line). There is work on progress to address that. > The advice in the documentation is to attach > > __attribute__((unused)) > > to the selected variable. This may be inappropriate for > three distinct reasons: > > (a) It is a GNU extension > (b) it clutters the code > (c) It isn't always easy to tell if a variable is unused While (a) and (b) are undeniable, (c) is not an issue; the attribute suppresses the unused warning, but does not cause any trouble if the variable is in fact used. To address (a) and (b), the gcc sources themselves do this: #ifndef ATTRIBUTE_UNUSED #define ATTRIBUTE_UNUSED __attribute__ ((__unused__)) #endif /* ATTRIBUTE_UNUSED */ int fn (int arg ATTRIBUTE_UNUSED) Ian
http://gcc.gnu.org is turning away MS Internet Explorer 5
Sirs, This web site is turning away Microsoft Internet Explorer 5. Following this link http://gcc.gnu.org from Mandriva's web site at http://www.mandriva.com/products/101/powerpack/packages?p=media-main2-gc c-3.4.1-4mdk.i586.rpm.html results in the Spam Bot page at http://sourceware.org/badspammer.html I happened across this site http://www.gnu.org/ which allows me in, so finally, after weeks I am able to tell someone about it. Incidentally, some of the links from this site also result in the Spam Bot message. Regards, Mike Ainley. auto signature: http://www.cassetta.freeserve.co.uk [EMAIL PROTECTED] Huddersfield, G.B.
parallell build on cygwin... does it work?
I just tried to bootstrap current cvs gcc trunk under cygwin on a dual cpu windows box... LAST_UPDATED: Mon Aug 29 09:44:58 UTC 2005 it barfs like this: gawk -f ../../gcc/gcc/opt-functions.awk -f ../../gcc/gcc/optc-gen.awk \ -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include ../../gcc/gcc/pointer-set.c -o pointer-set.o gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include ../../gcc/gcc/alloc-pool.c -o alloc-pool.o gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include \ ../../gcc/gcc/config/i386/host-cygwin.c In file included from ../../gcc/gcc/hooks.h:25, from ../../gcc/gcc/hosthooks-def.h:24, from ../../gcc/gcc/config/i386/host-cygwin.c:26: ../../gcc/gcc/machmode.h:26:24: insn-modes.h: No such file or directory In file included from ../../gcc/gcc/hooks.h:25, from ../../gcc/gcc/hosthooks-def.h:24, from ../../gcc/gcc/config/i386/host-cygwin.c:26: ../../gcc/gcc/machmode.h:30: error: `NUM_MACHINE_MODES' undeclared here (not in a function) In file included from ../../gcc/gcc/hooks.h:25, from ../../gcc/gcc/hosthooks-def.h:24, from ../../gcc/gcc/config/i386/host-cygwin.c:26: ../../gcc/gcc/machmode.h:81: error: syntax error before "unsigned" ../../gcc/gcc/machmode.h:136: warning: parameter has incomplete type ../../gcc/gcc/machmode.h:141: warning: parameter has incomplete type ../../gcc/gcc/machmode.h:145: error: syntax error before "unsigned" ../../gcc/gcc/machmode.h:147: warning: parameter has incomplete type In file included from ../../gcc/gcc/hosthooks-def.h:24, from ../../gcc/gcc/config/i386/host-cygwin.c:26: ../../gcc/gcc/hooks.h:30: warning: parameter has incomplete type ../../gcc/gcc/machmode.h:81: error: storage size of `mode_size' isn't known ../../gcc/gcc/machmode.h:145: error: storage size of `mode_base_align' isn't known make[2]: *** [host-cygwin.o] Error 1 make[2]: *** Waiting for unfinished jobs rm gcjh.pod gcj-dbtool.pod jcf-dump.pod grmiregistry.pod fsf-funding.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gfdl.pod jv-scan.pod cpp.pod gjnih.pod gij.pod gpl.pod gfortran.pod gcc.pod make[2]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make: *** [bootstrap] Error 2 however, If I continue with a single job make, it carries on... Do you guys see a trivial fix for this? -- Cheers, /ChJ
Re: http://gcc.gnu.org is turning away MS Internet Explorer 5
I just tried with Internet Explorer 6 (as installed by Windows XP Service Pack 2) and it worked just fine. Did you try another browser (e.g. Mozilla or Firefox)?
Global variables
Hello, I'm trying to extract global variables from a set of c++ files. I tried using: cp_namespace_decls(global_namespace); But this returns a whole set of variables which I do not want to know about now (i.e stdout, timezone, _ZTISt10ostrstream e.t.c) How do I get rid of this excess or what is the right way of accessing such variables? Thanks, Primrose
Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Walrond wrote: | Can anybody explain what this error might mean? | | /tmp/gcc-3-3.heretix/work/gcc/xgcc "" -B/tmp/gcc-3-3.heretix/work/gcc/ - -nostdinc++ - -L/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/src - -L/tmp/gcc-3-3.heretix/work/x86 | _64-unknown-linux-gnu/libstdc++-v3/src/.libs - -B/pkg/gcc-3-3/x86_64-unknown-linux-gnu/bin/ - -B/pkg/gcc-3-3/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-3-3/x86_64-unknown-linux-gnu/in | clude -I../../../../gcc-3.3.6/libstdc++-v3/../gcc - -I../../../../gcc-3.3.6/libstdc++-v3/../include - -I/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unkno | wn-linux-gnu - -I/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/include - -I../../../../gcc-3.3.6/libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE - -fno-implicit-templates -Wall | -Wno-format -W -Wwrite-strings -fdiagnostics-show-location=once - -ffunction-sections -fdata-sections -c ../../../../gcc-3.3.6/libstdc++-v3/libsupc++/guard.cc -fPIC -DPIC -o guard.o | xgcc: cannot specify -o with -c or -S and multiple compilations | make[4]: *** [guard.lo] Error 1 If you can run the libtool line above this one, with "sh -x" (e.g. sh -x ../libtool ...>& ltlog.txt) and send me the log privately, I should be able to see if current libtool still has this issue (and maybe find a workaround). Please don't send the log to this list. Thanks, Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQxMPN7iDAg3OZTLPAQIVSAQAjs/PX8FpcaFphCzfjnguP+sofbn/qsiO ZGyFpx1ut1A+7e6PJ/tlzf9Df+sG43D2zeTjylD2FPG5A7YrypwrGpB+FzTlkRFR UyKhapIYoGSnZ1cUlUh5jf1l0sM38FKc/fSKuWslT87a93x08oyWII76f2o/bVEz B/NczxtkoA8= =lLG3 -END PGP SIGNATURE-
Re: unused variable warning
On Mon, 2005-08-29 at 01:00 -0700, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> writes: > > > In gcc/g++ version 4.0 there is no way to turn off the > > unused variable warning enabled by -Wall with a command > > line switch. > > How about -Wno-unused-variable? Hmmm.. that seems to work .. Thanks! Actually the manual says: "Many options have long names starting with -f or with -W—for example, -fforce-mem, -fstrength-reduce, -Wformat and so on. Most of these have both positive and negative forms; the negative form of -ffoo would be -fno-foo. This manual documents only one of these two forms, whichever one is not the default." however this is just sloppy: the document should be explicit about which options are supported -- I grepped for 'unused' and didn't find a 'no' form.. I didn't see that section of the manual (even though I'm aware it is the convention). I was misled by the text which says "To suppress this warning use the unused attribute (see Variable Attributes)." which should have said "To suppress this warning on a per variable basis .." > > I think this is a bug: it should be possible to selectively > > turn on or off all warnings (on the command line). > > There is work on progress to address that. Yes, gcc 4.0 is quite good now. > > The advice in the documentation is to attach > > > > __attribute__((unused)) > > > > to the selected variable. This may be inappropriate for > > three distinct reasons: > > > > (a) It is a GNU extension > > (b) it clutters the code > > (c) It isn't always easy to tell if a variable is unused > > While (a) and (b) are undeniable, (c) is not an issue; the attribute > suppresses the unused warning, but does not cause any trouble if the > variable is in fact used. I found that out experimentally, and, this behaviour is in fact documented .. however it isn't all that readable to see 'unused' and be expected to guess it actually means 'possibly unused' :) > To address (a) and (b), the gcc sources themselves do this: > > #ifndef ATTRIBUTE_UNUSED > #define ATTRIBUTE_UNUSED __attribute__ ((__unused__)) > #endif /* ATTRIBUTE_UNUSED */ > > int fn (int arg ATTRIBUTE_UNUSED) Yes, I am also doing that too. I was mainly concerned that I wish my scripts to use -Wall, which wasn't possible prior to 4.0 due to the invalid-offsetof warning not being suppressible, but in 4.0 it is, so I have switched to -Wall -Wno-invalid-offsetof for checking my code .. for production scripts I want most of the warnings to be on, however unused variables are just too common it seems. Anyhow thanks! -- John Skaller signature.asc Description: This is a digitally signed message part
Re: Removing operand normalizaiton in get_expr_operands
On 08/24/05 13:40, Richard Henderson wrote: On Wed, Aug 24, 2005 at 01:22:09PM -0400, Daniel Berlin wrote: Alternatively, i can just add the "no resort" interface. (or of course, write the ugly code to keep rechecking which operands got switched after each call to update_stmt :P) I'd prefer we kill it. That'd be my preference as well.
gcc 4.0.x: MMX built-ins regression
Hi,
I am using MMX built-ins and gcc-4.0-20050825 and I am experiencing generation
of uneeded movq (at least I guess so, I am no assembler pro). I don't know
which gcc snapshot introduced this, but a I know that some pre-release gcc 4.0
didn't show this bad behaviour. (It's been some time I played with this...)
BTW, this is using gcc built-ins. The situation is much wors when using
intrinsics via mmintrin.h. (Again old pre4.0 gcc didn't have the problem;
using gcc builtins or mmintin.h intrinsics made no differnece; both generated
nice code.)
Here source + assembly mixed + my comments (compiled with -O2 -g3
-march=athlon-xp):
Just shout, if you need anything else.
typedef int v2si __attribute__ ((vector_size (8)));
typedef int di __attribute__ ((vector_size (8)));
typedef short v4hi __attribute__ ((vector_size (8)));
0320 :
void MixAudio16_MMX_T(char* src1, char* src2, char* dst)
{
320: 55 push %ebp
321: 89 e5 mov%esp,%ebp
323: 83 ec 10sub$0x10,%esp
v4hi indata;
v4hi signmask;
v2si loout;
v2si hiout;
v2si temp;
__attribute__((aligned(16))) static const short sm[4] =
{0x8000,0x8000,0x8000,0x8000};
static const v4hi *m = (v4hi*)sm;
indata = *(v4hi*)src1;
signmask = __builtin_ia32_pand(indata, *m);
326: 8b 15 04 00 00 00 mov0x4,%edx
32c: 8b 45 08mov0x8(%ebp),%eax
32f: 0f 6f 10movq (%eax),%mm2
signmask = __builtin_ia32_pcmpeqw(signmask, *m);
loout = __builtin_ia32_punpcklwd(indata, signmask);
332: 0f 6f camovq %mm2,%mm1
hiout = __builtin_ia32_punpckhwd(indata, signmask);
indata = *(v4hi*)src2;
335: 8b 45 0cmov0xc(%ebp),%eax
338: 0f 7f 55 f8 movq %mm2,0xfff8(%ebp)
33c: 0f 6f 45 f8 movq 0xfff8(%ebp),%mm0
Why not movq %mm2, %mm0 ?
340: 0f db 02pand (%edx),%mm0
343: 0f 7f 45 f0 movq %mm0,0xfff0(%ebp)
347: 0f 6f 45 f0 movq 0xfff0(%ebp),%mm0
what the heck?
34b: 0f 75 02pcmpeqw (%edx),%mm0
34e: 0f 61 c8punpcklwd %mm0,%mm1
351: 0f 69 d0punpckhwd %mm0,%mm2
354: 0f 7f 4d f8 movq %mm1,0xfff8(%ebp)
358: 0f 6f 5d f8 movq 0xfff8(%ebp),%mm3
As above, this happens throughout, as you can see:
35c: 0f 7f 55 f8 movq %mm2,0xfff8(%ebp)
360: 0f 6f 10movq (%eax),%mm2
363: 0f 6f 65 f8 movq 0xfff8(%ebp),%mm4
signmask = __builtin_ia32_pand(indata, *m);
367: 0f 7f 55 f8 movq %mm2,0xfff8(%ebp)
36b: 0f 6f 45 f8 movq 0xfff8(%ebp),%mm0
signmask = __builtin_ia32_pcmpeqw(signmask, *m);
temp = __builtin_ia32_punpcklwd(indata, signmask);
36f: 0f 6f camovq %mm2,%mm1
372: 0f db 02pand (%edx),%mm0
loout = __builtin_ia32_paddd(loout, temp); \
temp = __builtin_ia32_punpckhwd(indata, signmask);
hiout = __builtin_ia32_paddd(hiout, temp);
*(v4hi*)dst = __builtin_ia32_packssdw(loout, hiout);
375: 8b 45 10mov0x10(%ebp),%eax
378: 0f 7f 45 f0 movq %mm0,0xfff0(%ebp)
37c: 0f 6f 45 f0 movq 0xfff0(%ebp),%mm0
380: 0f 75 02pcmpeqw (%edx),%mm0
383: 0f 61 c8punpcklwd %mm0,%mm1
386: 0f 69 d0punpckhwd %mm0,%mm2
389: 0f 7f 4d f8 movq %mm1,0xfff8(%ebp)
38d: 0f fe 5d f8 paddd 0xfff8(%ebp),%mm3
Why not using MMX register directly?
391: 0f 7f 55 f8 movq %mm2,0xfff8(%ebp)
395: 0f fe 65 f8 paddd 0xfff8(%ebp),%mm4
dito
399: 0f 6b dcpackssdw %mm4,%mm3
39c: 0f 7f 18movq %mm3,(%eax)
__builtin_ia32_emms();
39f: 0f 77 emms
return;
}
3a1: c9 leave
3a2: c3 ret
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
signature.asc
Description: OpenPGP digital signature
Re: Cross Compiler Unix - Windows
I have used MinGW on Linux to compile Windows executables. I don't see why it could not be compiled on other Unix variants. Try: http://www.libsdl.org/extras/win32/cross/README.txt and http://www.mingw.org Regards, Andy --- Ivan Novick <[EMAIL PROTECTED]> wrote: > Can you recommend a solution for compiling Windows > DLLs on any > variation of UNIX? > > We currently do this with Cygwin/Windows, but would > like to go one > step further and do the builds on a UNIX machine > that produces > Windows DLLs. > > Thanks for any advice, > > Ivan > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [DEAD] APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
On Mon, 2005-08-29 at 01:33 -0400, Kevin McBride wrote: > Joe Buck wrote: > > I've looked at the bug in bugzilla; it's not marked as invalid, though > > I tend to agree with Andrew and Ian's comments in the log. > > I set the bug back to unconfirmed after I noticed that, in my opinion, > there can be more optimization done. > > > In any case, the SC doesn't get involved in cases like this. And even > > if the SC lost its sanity and decided to micromanage Bugzilla as you > > ask, it would take a 3/4 vote, and you certainly wouldn't get mine. > > I didn't realize that the SC had no control over Bugzilla. Unless there > was something I missed, all what the web site said was: > > > In April 1999 the steering committee was appointed by the FSF as the > > official GNU maintainer for GCC and changed its name to GCC steering > > committee. Yes, they control the overall direction. They don't micromanage. > > All I can now say is: > > If no one on the GCC team wants to fully investigate my bug, then > there's nothing I can do about the bug except to implement the fix in my > own code. If you want to see what's up, feel free. Nobody will stop you. If you want to propose a patch, feel free. As for "no one on the GCC team", you seem to have a misunderstanding about how GCC ends up working. It's not like we have people paid who go through all the enhancement requests or something. The fact that the bugs are in Bugzilla is just a way to track bugs. It does not in any way guarantee that your bug will be looked at, regardless of whether it is open, closed, invalid, not invalid, etc. There is no guarantee that your bug will or won't be fixed for a certain release, etc, unless *you* start submitting the patches to fix it. Certainly, there are certain classes of bugs that are more likely to be looked at than others, etc. In addition, there are some people who are more attentive to certain pieces of the compiler than others, and will go looking for enhancement requests in bugzilla to fix. This is not by stretch of the imagination something that people do across the board. In other words, the best way to get a bug attention is generally to give that bug attention yourself. The other day we had someone who believed that if we marked his bug "enhancement" instead of "minor", it was "misclassifying" and would cause havoc. The reality is that nobody was going to fix his bug anytime soon, regardless of how it was marked, because he wasn't going to, and it just wasn't high priority. > > This appeal started up over misunderstandings between Andrew Pinski, Ian > Lance Taylor, and I. I felt that Ian Lance Taylor agreed with me prior > to submitting the bug to the bug tracker, and so, felt humiliated by > Andrew Pinski's comments. At the risk of Andrew hating me (:P), this, sadly, is not the first time someone has taken offense at his comments in a bug. You shouldn't take it personally. > When Ian Lance Taylor stepped in, he made the > misunderstanding obvious to me, and so, I did what I could to see if gcc > was performing optimizations as much as possible. > > This appeal is now dead. Let's get on with our projects, regardless if > my bug report will ever be turned into a bug fix. Again, if you want a bug fix, your best course of action is to fix it :)
Re: parallell build on cygwin... does it work?
Christian Joensson <[EMAIL PROTECTED]> writes: > I just tried to bootstrap current cvs gcc trunk under cygwin on a dual > cpu windows box... > > LAST_UPDATED: Mon Aug 29 09:44:58 UTC 2005 > > it barfs like this: Looks like we need to change hosthooks-def.h to $(HOSTHOOKS_DEF_H) to the dependencies of host-cygwin.o in config/i386/x-cygwin. Can you test the patch? Thanks. Ian Index: x-cygwin === RCS file: /cvs/gcc/gcc/gcc/config/i386/x-cygwin,v retrieving revision 1.5 diff -u -r1.5 x-cygwin --- x-cygwin7 Mar 2005 22:42:42 - 1.5 +++ x-cygwin29 Aug 2005 16:41:26 - @@ -1,4 +1,4 @@ host-cygwin.o : $(srcdir)/config/i386/host-cygwin.c $(CONFIG_H) $(SYSTEM_H) \ - coretypes.h hosthooks.h hosthooks-def.h toplev.h diagnostic.h + coretypes.h hosthooks.h $(HOSTHOOKS_DEF_H) toplev.h diagnostic.h $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ $(srcdir)/config/i386/host-cygwin.c
building gcc 4.0.1 using CAS (part of the sun v8plus arch)
I modified the file: ./libstdc++-v3/config/cpu/sparc/atomicity.h to use the 32bit equivalent CAS/LD instructions from the arch64 bit in the arch32. I then built the code using the -mv8plus option in the (xxx)FLAGS and all is happy. However, the code will no longer compile without the v9 32bit CAS/LD code. What is the preferred way of doing this for GCC code? Is there a macro I can ifdef on to check to see if I can use the v8plus instructions, otherwise use the existing spinlock implementation? I would like to submit this and get it mainstreamed, but I am not sure how to proceed here. Thanks! -- Andrew
Re: help: about enum
On Aug 27, 2005, at 1:54 AM, Gaurav Gautam, Noida wrote: I WANT TO KNOW Please, stop screaming. We can hear you. This is the wrong list for such questions. Please go try gcc-help.
Re: Cross Compiler Unix - Windows
On Fri, 26 Aug 2005, Nix wrote:
> This is nonsense. I have a dozen cross-compilers on this box, all
> installed into /usr. They do not collide as long as you configure with
> --enable-version-specific-runtime-libs and
> --program-{prefix,suffix,transform-name} and make slight adjustments
> after installation (ditch libiberty.a and some locale and manpage stuff
> that doesn't get its name suitably adjusted).
mudflap is an offender as well, see Bugzilla #18244 (libmudflap
installs include/mf-runtime.h in version-independent path).
Java has libdata/pkgconfig/libgcj.pc and include/ffi.h.
And, like the man pages, the info files do not honor --program-suffix,
but for regular C, C++, Objective-C and Fortran development neither of
is a real killer, agreed.
Gerald
Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
On Sun, Aug 28, 2005 at 04:29:56PM -0700, Ian Lance Taylor wrote: > In the meantime, I think there may be a bug here, in that memset is > open coded for the i386 at -O0. That doesn't make sense to me; e.g., > it prevents setting a breakpoing on memset. This, IMO, has nothing to do with i386. If we don't want to open-code memset at -O0, we should have avoided transforming this such that we call to clear_storage in the first place. r~
Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
On Aug 28, 2005, at 3:48 PM, Kevin McBride wrote: Please take notice that I am appealing my bug (number 23605) to the steering committee of GCC on the basis that it is a legimate bug/enhancement in need of a through research. Ok, so go research it, collect data, and then report your findings back. For example, benchmark an entire linux distro with your patch in and out, and tell us what the performance is, go measure spec, tell us what the performance is, benchmark CSiBE... I am hoping that the steering committee will order a through research You have been so ordered, let us know how it goes. :-) on the bug. Another approach would be to take definitive measurements, for example, at -Os if one way is 30 bytes and the current approach gcc takes is 31 bytes, then that is a `bug'. If you can show that a testcase takes fewer clock cycles and is smaller than the current codegen, file _that_ bug, include the numbers of ticks for each, give details, a vague, I wonder if this is better, isn't going to be as persuasive as hard numbers. Failing all that you can appeal by hiring someone that will do the research, and report back their findings. I hope this helps.
Re: Global variables
On Aug 29, 2005, at 5:34 AM, [EMAIL PROTECTED] wrote: I'm trying to extract global variables from a set of c++ files. I tried using: cp_namespace_decls(global_namespace); But this returns a whole set of variables which I do not want to know about now (i.e stdout, timezone, _ZTISt10ostrstream e.t.c) How do I get rid of this excess or what is the right way of accessing such variables? Try looking ta DECL_SOURCE_FILE/DECL_SOURCE_LINE/DECL_ARTIFICIAL and you'll want to read and understand files like cp-tree.h, tree.h and tree.def.
What to do about compile time slowdowns for 4.1?
Hi, We're supposed to be getting closer to a 4.1 release branch, but just like in the past so-many releases we have succeeded again in slowing down GCC, and we've slowed it down a _lot_ compared even to GCC 4.0. Taking SPECint and CSiBE as examples: http://www.suse.de/~aj/SPEC/amd64/CINT/sandbox-britten/Total-time_big.png http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686-linux So for compiling all of SPECint with "-O2 -march=k8" on AMD64, we have slowed down from ~210s for GCC 4.0 to >250s for CVS HEAD. Another example: the cc1-i files of "4.0.0 20041202 (experimental)" on AMD64, all compilers checked out from CVS and bootstrapped with checking disabled, and compiling those 569 files with "cc1 -O2 -quiet": 3.3 user4m10.053s 3.4 user4m9.642s 4.0 user4m25.517s HEAD user4m53.167s So GCC 4.1 right now is a small compile time disaster. Are there any ideas for what can be done about it before releasing it? Gr. Steven
Re: What to do about compile time slowdowns for 4.1?
On Tue, Aug 30, 2005 at 12:20:11AM +0200, Steven Bosscher wrote: > We're supposed to be getting closer to a 4.1 release branch, but just > like in the past so-many releases we have succeeded again in slowing > down GCC, and we've slowed it down a _lot_ compared even to GCC 4.0. > > Taking SPECint and CSiBE as examples: > http://www.suse.de/~aj/SPEC/amd64/CINT/sandbox-britten/Total-time_big.png > http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686-linux > > So for compiling all of SPECint with "-O2 -march=k8" on AMD64, we have > slowed down from ~210s for GCC 4.0 to >250s for CVS HEAD. Unless we trade an improved SPECint score for this slowdown, I'd call that an RC bug. But looking at http://www.suse.de/~aj/SPEC/amd64/CINT/sandbox-britten/mean-int_big.png it seems that the scores have gotten worse lately.
Re: What to do about compile time slowdowns for 4.1?
On Tuesday 30 August 2005 01:26, Joe Buck wrote: > On Tue, Aug 30, 2005 at 12:20:11AM +0200, Steven Bosscher wrote: > > We're supposed to be getting closer to a 4.1 release branch, but just > > like in the past so-many releases we have succeeded again in slowing > > down GCC, and we've slowed it down a _lot_ compared even to GCC 4.0. > > > > Taking SPECint and CSiBE as examples: > > http://www.suse.de/~aj/SPEC/amd64/CINT/sandbox-britten/Total-time_big.png > > http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686 > >-linux > > > > So for compiling all of SPECint with "-O2 -march=k8" on AMD64, we have > > slowed down from ~210s for GCC 4.0 to >250s for CVS HEAD. > > Unless we trade an improved SPECint score for this slowdown, I'd call > that an RC bug. But looking at > > http://www.suse.de/~aj/SPEC/amd64/CINT/sandbox-britten/mean-int_big.png > > it seems that the scores have gotten worse lately. That's only because vortex started failing on that day, and that problem is not yet fixed. Gr. Steven
doloop-opt deficiency
We noticed that the simple loop here
extern int a[];
int foo(int w) {
int n = w;
while (n >= 512)
{
a[n] = 42;
n -= 256;
}
}
was being treated as ineligible for the doloop modification. I think
this is
a simple pasto; this code was evidently copied from the previous block:
Index: loop-iv.c
===
RCS file: /cvs/gcc/gcc/gcc/loop-iv.c,v
retrieving revision 2.35
diff -u -b -c -p -r2.35 loop-iv.c
cvs diff: conflicting specifications of output style
*** loop-iv.c 21 Jul 2005 07:24:07 - 2.35
--- loop-iv.c 29 Aug 2005 23:34:12 -
*** iv_number_of_iterations (struct loop *lo
*** 2417,2423
tmp0 = lowpart_subreg (mode, iv0.base, comp_mode);
tmp1 = lowpart_subreg (mode, iv1.base, comp_mode);
! bound = simplify_gen_binary (MINUS, mode, mode_mmin,
lowpart_subreg (mode, step, comp_mode));
if (step_is_pow2)
{
--- 2417,2423
tmp0 = lowpart_subreg (mode, iv0.base, comp_mode);
tmp1 = lowpart_subreg (mode, iv1.base, comp_mode);
! bound = simplify_gen_binary (PLUS, mode, mode_mmin,
lowpart_subreg (mode, step, comp_mode));
if (step_is_pow2)
{
The code as it was computed -2147483648-256 which overflows.
Still testing, but is there anything obvious wrong with this?
Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
On Sun, Aug 28, 2005 at 06:48:17PM -0400, Kevin McBride wrote: > I am hoping that the steering committee will order a through research on > the bug. Kevin, what you don't seem to understand is that the SC can't order anyone to do anything. The SC has no employees, doesn't sign paychecks. GCC is a volunteer organization. True, a number of contributors draw a salary from their companies for their GCC work, but their management, not the SC, tells them what to work on. The SC does have some powers: it can refuse to allow certain kinds of changes into GCC, approves release plans put forward by the release manager, and approves the people who will be maintainers to various parts of the compiler. Once in its entire history, the SC banned someone from its mailing lists (this was back in the egcs days, and the guy was a complete whacko who made escalating threats against the release manager, including "I'm going to force your company to fire you" and "I've found out where you live"). But even if the SC were persuaded that you are entirely correct, the most it could do would be to ask for a volunteer to research your bug. And your bug is only one of 3,114 currently open gcc bugs (according to a Bugzilla query I just did), and I am unpersuaded that it is a particularly important one.
Re: [DEAD] APPEAL to steering committee: [Bug target/23605]memset() Optimization on x86-32 bit
Daniel Berlin wrote: > There is no guarantee that your bug will or won't be fixed for a > certain release, etc, unless *you* start submitting the patches to > fix it. Actually, there's no guarantee that even if you submit patches to fix a bug that it will be fixed in any official release. Ross Ridge
Re: What to do about compile time slowdowns for 4.1?
On Tue, Aug 30, 2005 at 01:34:22AM +0200, Steven Bosscher wrote: > On Tuesday 30 August 2005 01:26, Joe Buck wrote: > > Unless we trade an improved SPECint score for this slowdown, I'd call > > that an RC bug. But looking at > > > > http://www.suse.de/~aj/SPEC/amd64/CINT/sandbox-britten/mean-int_big.png > > > > it seems that the scores have gotten worse lately. > > That's only because vortex started failing on that day, and that > problem is not yet fixed. OK. Do we have any consistent measurements for SPEC2000 on amd64 for 4.0.x vs mainline?
Re: What to do about compile time slowdowns for 4.1?
On Tuesday 30 August 2005 01:56, Joe Buck wrote: > OK. Do we have any consistent measurements for SPEC2000 on amd64 > for 4.0.x vs mainline? Some incomplete data is in http://people.redhat.com/dnovillo/spec2000.em64t/gcc/individual-build-secs_elapsed.html Gr. Steven
Re: What to do about compile time slowdowns for 4.1?
On 08/29/05 19:56, Joe Buck wrote: OK. Do we have any consistent measurements for SPEC2000 on amd64 for 4.0.x vs mainline? http://people.redhat.com/dnovillo/spec2000/
Segfault with gcc4 and LD_PRELOAD (was: Need help to fill bug report (gcc 4.0.1 and above))
Hi, I am very sorry to insist but I would really appreciate if someone could shed some light on my current problem. I really don't see why my code is only segfaulting when using gcc4.0.1 (and above). Description: I am running a program that is outputing a file. The very same program when run with LD_PRELOAD set to libGL.so, is segfaulting. The backtrace can be found here: http://www.creatis.insa-lyon.fr/~malaterre/gcc/gdb.log And I ran also strace with/ and without LD_PRELOAD set: $ export LD_PRELOAD=/usr/X11R6/lib/libGL.so $ strace /home/mathieu/Dashboards/MyTests/VTK-gcc4/bin/vtkParseOGLExt /home/mathieu/Dashboards/MyTests/VTK-gcc4/Rendering /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glxext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/wglext.h >& /tmp/log1 $ unset LD_PRELOAD $ strace /home/mathieu/Dashboards/MyTests/VTK-gcc4/bin/vtkParseOGLExt /home/mathieu/Dashboards/MyTests/VTK-gcc4/Rendering /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glxext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/wglext.h >& /tmp/log2 Those logs files can be found here: http://www.creatis.insa-lyon.fr/~malaterre/gcc/log1 and http://www.creatis.insa-lyon.fr/~malaterre/gcc/log2 --- Anyone interested in reproducing the bug need a debian testing with gcc4: (assuming gcc points to gcc 4.0.1) $ sudo apt-get install cmake $ cvs -d:pserver:[EMAIL PROTECTED]:2401/cvsroot/VTK login $ cvs -d:pserver:[EMAIL PROTECTED]:2401/cvsroot/VTK co VTK $ mkdir VTK-gcc $ cd VTK-gcc $ cmake ../VTK $ make ... Thanks for any advice on tracking down this bug, Mathieu Mathieu Malaterre wrote: Hello, I have currently a reproducable seg fault from an exe produced by gcc 4.0.1 (*). It does not appear using gcc 2.95, 3.2, 3.3, 3.4. If I run it throught gdb I get: 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x08062907 in __gnu_cxx::__mt_allocstd::string> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate (this=0x806d888, __p=0x8221f10, __n=1) at mt_allocator.h:746 ... and the structure being: static std::set< std::pair< std::string, std::string > > foo; If I try to run through valgrind 3.0 everything is fine, and it produce correct output. Any advice on a way to narrow down a simple testcase, right now it would require building VTK(**) Thanks for any help, Mathieu (*) debian testing. but I can also reproduce with gcc 4.1.0 20050726 (gcc-snapshot) (**) http://vtk.org
Re: parallell build on cygwin... does it work?
On 29 Aug 2005 09:42:15 -0700, Ian Lance Taylor wrote: > Christian Joensson <[EMAIL PROTECTED]> writes: > > > I just tried to bootstrap current cvs gcc trunk under cygwin on a dual > > cpu windows box... > > > > LAST_UPDATED: Mon Aug 29 09:44:58 UTC 2005 > > > > it barfs like this: > > Looks like we need to change hosthooks-def.h to $(HOSTHOOKS_DEF_H) to > the dependencies of host-cygwin.o in config/i386/x-cygwin. > > Can you test the patch? Thanks. > > Ian > > Index: x-cygwin That does indeed fix this problem, however, I have a new one...: rm -f needed-list; touch needed-list; \ for f in atexit calloc memchr memcmp memcpy memmove memset rename strchr strerror strncmp strrchr strstr strtol strtoul tmpnam vfprintf vprintf vfork waitpid bcmp bcopy bzero; do \ for g in ./random.o ./insque.o ./mkstemps.o ./sigsetmask.o ./stpcpy.o ./stpncpy.o ./strverscmp.o ; do \ case "$g" in \ *$f*) echo $g >> needed-list ;; \ esac; \ done; \ done echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o > required-list if [ x"" != x ]; then \ /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/regex.c -o pic/regex.o; \ else true; fi /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/regex.c -o regex.o ../../../gcc/libiberty/regex.c:130: warning: function declaration isn't a prototype ../../../gcc/libiberty/regex.c:130: warning: conflicting types for built-in function 'malloc' ../../../gcc/libiberty/regex.c:131: warning: function declaration isn't a prototype In file included from ../../../gcc/libiberty/regex.c:638: ../../../gcc/libiberty/regex.c: In function 'byte_regex_compile': ../../../gcc/libiberty/regex.c:2439: warning: implicit declaration of function 'free' ../../../gcc/libiberty/regex.c: In function 'byte_re_compile_fastmap': ../../../gcc/libiberty/regex.c:4835: warning: implicit declaration of function 'abort' ../../../gcc/libiberty/regex.c:4835: warning: incompatible implicit declaration of built-in function 'abort' ../../../gcc/libiberty/regex.c: In function 'byte_re_match_2_internal': ../../../gcc/libiberty/regex.c:7421: warning: incompatible implicit declaration of built-in function 'abort' ../../../gcc/libiberty/regex.c: In function 'xregerror': ../../../gcc/libiberty/regex.c:8078: warning: incompatible implicit declaration of built-in function 'abort' ../../../gcc/libiberty/regex.c: In function 'byte_regex_compile': ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; ../../../gcc/libiberty/reg
More NEWS on GCC?
This is probably an odd request, but I'd like to see more news articles on GCC development. Every time a minor revision of the Linux kernel comes out, there's no scarcity of news articles written about it. Indeed, any time something interesting happens, someone writes an article about it, like for instance, you may recall the time when Ingo Molnar added the O(1) scheduler and the numerous articles that followed on KernelTrap.org, osnews.com, etc. Well, to me, the compiler technology is at least as interesting as OS development or anything else for that matter. It's complicated business to design a compiler to optimize well for numerous architectures, and I'm facinated by the rare (if shallow) snippets that people manage to write about GCC. Something as relatively minor as the removal of >? and
Re: gcc 4.0.x: MMX built-ins regression
Hello! > I am using MMX built-ins and gcc-4.0-20050825 and I am experiencing generation > of uneeded movq (at least I guess so, I am no assembler pro). I don't know > which gcc snapshot introduced this, but a I know that some pre-release gcc 4.0 > didn't show this bad behaviour. (It's been some time I played with this...) > Just shout, if you need anything else. Yes, a bugreport would be nice. Please look at http://gcc.gnu.org/bugs.html . I have extracted a testcase from your source/assembly mix and with 'gcc version 4.1.0 20050716 (experimental)' the code looks OK to me: gcc -O3 -march=athlon-xp: MixAudio16_MMX_T: pushl %ebp movl%esp, %ebp movl8(%ebp), %eax movq(%eax), %mm3 movlm.1485, %eax movq%mm3, %mm4 movq(%eax), %mm1 movq%mm1, %mm0 movq(%eax), %mm2 movl12(%ebp), %eax pand%mm3, %mm0 pcmpeqw %mm2, %mm0 punpcklwd %mm0, %mm4 punpckhwd %mm0, %mm3 movq(%eax), %mm0 pand%mm0, %mm1 movl16(%ebp), %eax pcmpeqw %mm1, %mm2 movq%mm0, %mm1 punpckhwd %mm2, %mm0 punpcklwd %mm2, %mm1 paddd %mm3, %mm0 paddd %mm4, %mm1 packssdw%mm0, %mm1 movq%mm1, (%eax) femms leave ret (Sorry, I have no gcc 4.0.x here.) Uros.
