How gcov handles untested files, prior and after GCC 3.4
Hi! I posted a similiar thread a couple of weeks ago, but now I'm back with some more on my feet and hopefully a more clear problem description. Ok, so I have a sample application that just cout's a line of text. If I compile it with GCC 3.3.6 and run the 3.3.6 gcov on the source file I get this: Could not open data file application.da. Assuming that all execution counts are zero. 0.00% of 1 lines executed in file /usr/local/somedir/3.3.6/iostream Creating iostream.gcov. 0.00% of 4 lines executed in file application.cpp Creating application.cpp.gcov. Then I complile the exact same application with GCC 3.4.4 and I get this when using gcov on it: application.gcda:cannot open data file The 3.3.6 version assumes that the file not has been run (which is the correct behaviour in my book) whereas the 3.4.4 version just "gives up". I know that a large remake was done to gcov and it's .bb,.bbg,.da contra .gcno, gcda files when 3.4 came along, but is that the reason to change this beviour or has this been change due to some other fact? Why I ask is because I need to extract the number of lines even in untested files, and I need it to work both on 3.3.6 and on various 3.4.x versions. Thanks! Regards, Fredrik Johansson
Re: GCC missed optimization?
On 7/31/06, Devang Patel <[EMAIL PROTECTED]> wrote: >>I think this patch by Zdenek - vectorizing function calls - is related: >> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01655.html >> (would need to be extended to cover this case). Yes, extending Zdenek's patch to recognize built-in is a good idea. However, in case of compiler inserted built-in (e.g. this case) it is a good idea to delay inserting built-in function calls after vectorizer has a chance to optimize loop, specially when vectorized version of built-in function is not available. As this is canonicalization fold does, there is no chance for doing so. Now, this is again a reason to look at item # of my todo list that says 'add POW tree-code', which would make this and other things easier. Richard.
Re: if() and trailing ;
On 7/30/06, Joe Buck <[EMAIL PROTECTED]> wrote:
On Sat, Jul 29, 2006 at 07:33:03PM -0400, Simon Boulet wrote:
> After a couple hours debugging code, I figured our an if() somewhere
> had a trailing ; like this:
>
> if (memcmp(p, COMMUNITY, strlen(COMMUNITY)) != 0);
> continue; /* failed */
>
> The code above will always reach "continue" even when memcmp() == 0.
>
> I was surprised to see gcc doesn't report anything, I would expect a
> "statement has no effect" warning.
But it is common to have an empty action on a condition. You'll often
see code like
if (condition)
/* nothing */;
or more usually
if (condition) {
/* nothing */;
if()
(void)0; /* do nothing */
will make you happy.
}
or even more usually
if (condition) {
INVOKE_MACRO(...);
}
where the macro might be null on some platforms.
Empty macros have lots of other obscure failure cases.
if(...)
SOME_MACRO(with complex arguments)
do_something();
If SOME_MACRO is usually #defined to /* nothing */,
say, on your architecture, you've got a bad bug there.
Make it ((void)0) or, better yet, do {} while(0).
--
vda
Re: reduction of GP registers in MIPS backend
kernel coder wrote: Would you please give a bit more explaination of "GPRs come in pairs" and where this assumption is being checked in function override_options. It doesn't, that's why $24 gets marked as suitable for DImode in mips_hard_regno_mode_ok.
Re: Vector Extensions to C (SSE2 on X86)
Amund Fjellheim <[EMAIL PROTECTED]> writes: > GCC has some support for vector instructions through typedef'ed types > like this: > typedef int v4si __attribute__ ((vector_size (16))); > > Some normal C operators can be done on these and there are some > platform specific built in functions. The X86 functions are listed at > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/X86-Built_002din- > Functions.html#X86-Built_002din-Functions , but there are lots of > SSE2 instructions missing. Why? I don't see how it could be so hard > to implement > > v4si __builtin_ia32_pslld(v4si, int) > > and so on, when so many other SSE and SSE2 instructions are there. > Also, why aren't they available for C++ programs compiled with g++? > > Will these things be fixed in future releases of gcc? Anyone know > something about the status on this? It is a documentation failure. gcc's current goal is to implement the Intel intrinsic functions, providing mmintrin.h and friends: http://www.intel.com/cd/ids/developer/asmo-na/eng/59644.htm So, to get pslld, you would use _m_pslld or _m_pslldi, etc. Ian
Re: if() and trailing ;
"Denis Vlasenko" <[EMAIL PROTECTED]> writes:
| On 7/30/06, Joe Buck <[EMAIL PROTECTED]> wrote:
| > On Sat, Jul 29, 2006 at 07:33:03PM -0400, Simon Boulet wrote:
| > > After a couple hours debugging code, I figured our an if() somewhere
| > > had a trailing ; like this:
| > >
| > > if (memcmp(p, COMMUNITY, strlen(COMMUNITY)) != 0);
| > > continue; /* failed */
| > >
| > > The code above will always reach "continue" even when memcmp() == 0.
| > >
| > > I was surprised to see gcc doesn't report anything, I would expect a
| > > "statement has no effect" warning.
| >
| > But it is common to have an empty action on a condition. You'll often
| > see code like
| >
| > if (condition)
| > /* nothing */;
| >
| > or more usually
| >
| > if (condition) {
| >/* nothing */;
|
| if()
| (void)0; /* do nothing */
|
| will make you happy.
No, I'm not. I find it Very Silly.
-- Gaby
Re: Rainer Orth appointed IRIX and Tru64 UNIX maintainer
Gerald Pfeifer <[EMAIL PROTECTED]> writes: > It is my pleasure to announce that the steering committee has > appointed Rainer Orth IRIX and Tru64 UNIX maintainer > > Congratulations, Rainer! Thanks for taking on IRIX! It has been in severe need of a maintainer for ages. Richard
Re: if() and trailing ;
Joe Buck <[EMAIL PROTECTED]> writes: > On Sat, Jul 29, 2006 at 07:33:03PM -0400, Simon Boulet wrote: >> After a couple hours debugging code, I figured our an if() somewhere >> had a trailing ; like this: >> >> if (memcmp(p, COMMUNITY, strlen(COMMUNITY)) != 0); >> continue; /* failed */ >> >> The code above will always reach "continue" even when memcmp() == 0. >> >> I was surprised to see gcc doesn't report anything, I would expect a >> "statement has no effect" warning. > > But it is common to have an empty action on a condition. You'll often > see code like > > if (condition) > /* nothing */; Having an empty action on a condition without an else clause does not make any sense. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Vector Extensions to C (SSE2 on X86)
Anyone fixing the documentation, then? Den 1. aug. 2006 kl. 15.51 skrev Ian Lance Taylor: Amund Fjellheim <[EMAIL PROTECTED]> writes: GCC has some support for vector instructions through typedef'ed types like this: typedef int v4si __attribute__ ((vector_size (16))); Some normal C operators can be done on these and there are some platform specific built in functions. The X86 functions are listed at http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/X86-Built_002din- Functions.html#X86-Built_002din-Functions , but there are lots of SSE2 instructions missing. Why? I don't see how it could be so hard to implement v4si __builtin_ia32_pslld(v4si, int) and so on, when so many other SSE and SSE2 instructions are there. Also, why aren't they available for C++ programs compiled with g++? Will these things be fixed in future releases of gcc? Anyone know something about the status on this? It is a documentation failure. gcc's current goal is to implement the Intel intrinsic functions, providing mmintrin.h and friends: http://www.intel.com/cd/ids/developer/asmo-na/eng/59644.htm So, to get pslld, you would use _m_pslld or _m_pslldi, etc. Ian
Re: Vector Extensions to C (SSE2 on X86)
Amund Fjellheim <[EMAIL PROTECTED]> writes: > Anyone fixing the documentation, then? Volunteers are always welcome. Ian > Den 1. aug. 2006 kl. 15.51 skrev Ian Lance Taylor: > > > Amund Fjellheim <[EMAIL PROTECTED]> writes: > > > >> GCC has some support for vector instructions through typedef'ed types > >> like this: > >> typedef int v4si __attribute__ ((vector_size (16))); > >> > >> Some normal C operators can be done on these and there are some > >> platform specific built in functions. The X86 functions are listed at > >> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/X86-Built_002din- > >> Functions.html#X86-Built_002din-Functions , but there are lots of > >> SSE2 instructions missing. Why? I don't see how it could be so hard > >> to implement > >> > >> v4si __builtin_ia32_pslld(v4si, int) > >> > >> and so on, when so many other SSE and SSE2 instructions are there. > >> Also, why aren't they available for C++ programs compiled with g++? > >> > >> Will these things be fixed in future releases of gcc? Anyone know > >> something about the status on this? > > > > It is a documentation failure. gcc's current goal is to implement the > > Intel intrinsic functions, providing mmintrin.h and friends: > > http://www.intel.com/cd/ids/developer/asmo-na/eng/59644.htm > > > > So, to get pslld, you would use _m_pslld or _m_pslldi, etc. > > > > Ian
Re: Vector Extensions to C (SSE2 on X86)
Den 1. aug. 2006 kl. 20.51 skrev Ian Lance Taylor: Amund Fjellheim <[EMAIL PROTECTED]> writes: Anyone fixing the documentation, then? Volunteers are always welcome. Ian I would but I don't think I know enough about what GCC supports and not. It would be better if those who do the changes make sure the documentation fits, wouldn't it? If I did the documentation, it'd be inaccurate. Features without documentation are kind of pointless to the rest of us. Audun Den 1. aug. 2006 kl. 15.51 skrev Ian Lance Taylor: Amund Fjellheim <[EMAIL PROTECTED]> writes: GCC has some support for vector instructions through typedef'ed types like this: typedef int v4si __attribute__ ((vector_size (16))); Some normal C operators can be done on these and there are some platform specific built in functions. The X86 functions are listed at http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/X86-Built_002din- Functions.html#X86-Built_002din-Functions , but there are lots of SSE2 instructions missing. Why? I don't see how it could be so hard to implement v4si __builtin_ia32_pslld(v4si, int) and so on, when so many other SSE and SSE2 instructions are there. Also, why aren't they available for C++ programs compiled with g++? Will these things be fixed in future releases of gcc? Anyone know something about the status on this? It is a documentation failure. gcc's current goal is to implement the Intel intrinsic functions, providing mmintrin.h and friends: http://www.intel.com/cd/ids/developer/asmo-na/eng/59644.htm So, to get pslld, you would use _m_pslld or _m_pslldi, etc. Ian
Re: Vector Extensions to C (SSE2 on X86)
Amund Fjellheim <[EMAIL PROTECTED]> writes: > >> Anyone fixing the documentation, then? > > > > Volunteers are always welcome. > > > > Ian > > I would but I don't think I know enough about what GCC supports and > not. It would be better if those who do the changes make sure the > documentation fits, wouldn't it? Yes, that would be better. Meanwhile, in the real world, volunteers to get us closer to the ideal world are always welcome. It doesn't have to be you, of course. > If I did the documentation, it'd be > inaccurate. Features without documentation are kind of pointless to > the rest of us. Intel provides documentation. I don't think that documentation should be replicated in the gcc documentation. What we need in the gcc documentation is some hint that the Intel documentation is relevant, and the removal of the inaccurate existing documentation. Ian > >> Den 1. aug. 2006 kl. 15.51 skrev Ian Lance Taylor: > >> > >>> Amund Fjellheim <[EMAIL PROTECTED]> writes: > >>> > GCC has some support for vector instructions through typedef'ed > types > like this: > typedef int v4si __attribute__ ((vector_size (16))); > > Some normal C operators can be done on these and there are some > platform specific built in functions. The X86 functions are > listed at > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/X86-Built_002din- > Functions.html#X86-Built_002din-Functions , but there are lots of > SSE2 instructions missing. Why? I don't see how it could be so hard > to implement > > v4si __builtin_ia32_pslld(v4si, int) > > and so on, when so many other SSE and SSE2 instructions are there. > Also, why aren't they available for C++ programs compiled with g++? > > Will these things be fixed in future releases of gcc? Anyone know > something about the status on this? > >>> > >>> It is a documentation failure. gcc's current goal is to > >>> implement the > >>> Intel intrinsic functions, providing mmintrin.h and friends: > >>> http://www.intel.com/cd/ids/developer/asmo-na/eng/59644.htm > >>> > >>> So, to get pslld, you would use _m_pslld or _m_pslldi, etc. > >>> > >>> Ian
Re: How gcov handles untested files, prior and after GCC 3.4
On Tue, Aug 01, 2006 at 09:44:56AM +0200, Fredrik Johansson wrote: > [ gcov on a source file with no .da/.gcda file ] > The 3.3.6 version assumes that the file not has been run (which is the > correct behaviour in my book) whereas the 3.4.4 version just "gives > up". I know that a large remake was done to gcov and it's .bb,.bbg,.da > contra .gcno, gcda files when 3.4 came along, but is that the reason > to change this beviour or has this been change due to some other fact? It does seem that the old behavior is more useful, so one could argue that this is a regression. It should be easy enough for a motivated volunteer to fix, so we have the old behavior (assume all counts are zero if we have a .gcno but no .gcda file) again. Alternatively, a flag could be given to specify that missing .gcda file means all-counts-zero and that gcov should shut up about the issue.
native or cross libssp?
DJ Delorie asked (http://gcc.gnu.org/ml/gcc/2006-04/msg00479.html) whether libssp was native only? I didn't find a reply. As DJ noted, configure in libssp is trying to create an executable when building a cross-gcc. What is the resolution: build with --disable-libssp (or add it to the noconfigdirs list) or fix libssp/configure? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: native or cross libssp?
> As DJ noted, configure in libssp is trying to create an executable > when building a cross-gcc. Yes, I struck this recently myself. > What is the resolution: build with --disable-libssp (or add it to > the noconfigdirs list) or fix libssp/configure? The former will be far easier, unless you desparately want ssp support for your target. libssp's configure script checks for certain behaviour from vsnprintf and needs to run the test program to determine that. Ben
New branch: ra-improvements
I'd like to announce the opening of the ra-improvements branch. My aim with this branch is to modify the existing global register allocator with several improvements to reduce its overall memory usage, make it faster and hopefully produce some better code too. This work is not a competitor with RABLE or YARA. Hopefully, those projects might even be able to use some of the work done here. The first changes to be checked in will deal with changing the square conflict bit matrix to use a smaller lower-triangular bit matrix. That change was first posted at: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00129.html with later follow up patches extending it. Suggestions for improvements are welcome as well as critiques. I'd also welcome test cases that people think are stressing the current global allocator due to large numbers of pseudos. Peter Index: svn.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v retrieving revision 1.30 diff -u -p -r1.30 svn.html --- svn.html15 Jun 2006 20:11:01 - 1.30 +++ svn.html2 Aug 2006 03:12:03 - @@ -297,6 +297,19 @@ list therefore provides only some repres branch is maintained by mailto:[EMAIL PROTECTED]">Laurynas Biveinis. + + ra-improvements + This branch aims to implement several improvements to the + current register allocator. Examples include implenting a + lower-triangular conflict matrix and register coalescing. + It is hoped that these improvements will not only help the + current allocator, but will be useful to the other register + allocation projects such as RABLE and YARA. This branch will + be merged with the dataflow-branch from time to time. + The patches for this branch should be marked with the tag + [ra-improvements] in the subject line. The branch + is maintained by mailto:[EMAIL PROTECTED]">Peter + Bergner. Architecture-specific
Building libstdc++ for powerpc-eabi
I'm running into problems building libstdc++ for powerpc-eabi. It eventually fails with an error message saying "Link tests are not allowed after GCC_NO_EXECUTABLES" while it is checking to see if libgcc_s exists. Meanwhile, config.log for libstdc++ shows lots of compile failures. So I think that the error while looking for libgcc_s is really a red herring. The compile failures are the result of ecrti.o not being included in the link. Nick Clifton posted a message about this, with a patch (http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00039.html). After applying this patch, libstdc++ builds OK. Following the discussion on that thread, it seems like the suggestion is that one should build gcc for some other similar target, such as powerpc-eabisim, which sort of misses the goal of building powerpc-eabi. So, what is the right way to build g++ for powerpc-eabi? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] improved algorithm for gcc/expmed.c::choose_multiplier()
Denis Vlasenko wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417 > > Right now Bugzilla internal problem prevents me from creating > an attachement there. So it goes here. What problems? Please let me know. The only issue i ever see is stuff about Fh::slice. This happens when the ip address or session changes between the create attachment click and the uploading you do :)
