asm_fprintf inefficiency?
so..I was bemaining to self extra #ifs, extra autoconf..
the checking for puts_locked...
the fact that asm_fprintf calls putc one character at a time,
which probably benefits from _unlocked.
1) asm_fprintf probably should skip from % to %, calling
puts on each span, instead of putc one at a time.
Granted, its input strings tend to be short.
2) But more so..
given, e.g.:
asm_fprintf(file, "%Rfoo");
one could instead say
#ifndef REGISTER_PREFIX
#define REGISTER_PREFIX ""
#endif
fprintf(file, "%sfoo", REGISTER_PREFIX);
That works for all of asm_fprintf (I, L, R, U) except %O, and %O appears
little used or unused. And it doesn't handle {.
jbook2:gcc jay$ grep asm_fprintf */*/* | grep { | wc -l
33
jbook2:gcc jay$ grep asm_fprintf */*/* | wc -l
318
Maybe something else could be done for those 10%?
like:
before:
asm_fprintf (file, "\t{l|lwz} %s,", reg_names[0]);
after:
fprintf (file, "\t%s %s,", dialect_number ? "lwz" : "l", reg_names[0]);
or bigger/faster:
fprintf (file, dialect_number ? "\tlwz %s," : \tl %s,", reg_names[0]);
(Really I'd rather gcc just output .o files directly...)
- Jay
GCC trunk revision 166285 passes SPEC CPU 2000/2006
FYI, GCC trunk revision 166285 passes SPEC CPU 2000/2006. It is the first time in a month. -- H.J.
Re: GCC trunk revision 166285 passes SPEC CPU 2000/2006
On Fri, Nov 5, 2010 at 1:43 PM, H.J. Lu wrote: > FYI, GCC trunk revision 166285 passes SPEC CPU 2000/2006. > It is the first time in a month. Ship it! Richard.
mach pass
Hello all Can anyone please give me a two line description about mach pass in GCC or any source reference for that. Regards Abdul
Re: asm_fprintf inefficiency?
Jay K writes: > 1) asm_fprintf probably should skip from % to %, calling > puts on each span, instead of putc one at a time. > Granted, its input strings tend to be short. And putc_unlocked is a macro which appends to a buffer. puts is not. It's not clear that your proposal would actually make gcc run any faster. Fortunately, this is amenable to a small benchmark program, so you could try it out. > given, e.g.: > > > asm_fprintf(file, "%Rfoo"); > > > one could instead say > > > #ifndef REGISTER_PREFIX > #define REGISTER_PREFIX "" > #endif > > > fprintf(file, "%sfoo", REGISTER_PREFIX); Sure, it's just less convenient, harder to read, and requires passing an extra argument. > (Really I'd rather gcc just output .o files directly...) It would be an interesting project, but it's not a major component of optimizing compilation time. I would certainly encourage any interested party to tackle this, but it's a huge effort with relatively small payoff. Ian
Re: mach pass
Abdul Wahid Memon writes: > Can anyone please give me a two line description about mach pass in > GCC or any source reference for that. I don't know what you mean by "mach pass". Ian
Re: mach pass
On 11/05/10 09:01, Ian Lance Taylor wrote: Abdul Wahid Memon writes: Can anyone please give me a two line description about mach pass in GCC or any source reference for that. I don't know what you mean by "mach pass". I'd hazard a guess Abdul is referring to the machine dependent reorg pass, which has the .mach debugging dump file. The machine dependent reorg pass is a late optimization pass (runs just prior to delay slot filling) that is entirely machine dependent. It is generally frowned upon to implement optimizations in the machine dependent reorganization pass, though several ports now implement such optimizations, including: alpha, arm, avr, bfin, frv, h8300, x86, ia64, m68hc11, mcore, mep, mips, mmix, pa, pico, s390, sh, spu, xstormy16, v850. jeff
Re: GCC vector extensions
Hi Ian, Thanks for your help. I switched to mainline and the vector extract works a treat. When i tried vector set, it was still generating suboptimal code. Is this bit of code still work in progress? Cheers Hari On 04/11/10 19:23, Ian Lance Taylor wrote: Hariharan Sandanagobalane writes: Is it possible to use rtl vector patterns like vec_extractm, vec_setm from C code? It looks like C subscipting for vector variables was allowed at some point and then removed. So, can these rtl patterns only be used from languages other than C? They were just recently added and have not been removed. Also answered on gcc-help. Ian
Re: GCC vector extensions
On Fri, Nov 5, 2010 at 5:25 PM, Hariharan Sandanagobalane wrote: > Hi Ian, > Thanks for your help. > > I switched to mainline and the vector extract works a treat. When i tried > vector set, it was still generating suboptimal code. Is this bit of code > still work in progress? I expect so. If you have small testcases then a bugreport would be appreciated. Richard. > Cheers > Hari > > On 04/11/10 19:23, Ian Lance Taylor wrote: >> >> Hariharan Sandanagobalane writes: >> >>> Is it possible to use rtl vector patterns like vec_extractm, vec_setm >>> from C code? It looks like C subscipting for vector variables was >>> allowed at some point and then removed. So, can these rtl patterns >>> only be used from languages other than C? >> >> They were just recently added and have not been removed. >> >> Also answered on gcc-help. >> >> Ian >> >
Re: Stage 3 question
On Nov 3, 2010, at 4:02 PM, Paul Koning wrote: > Question on what's appropriate... More on the same topic: sometimes the words are "bug fixes" and sometimes "regressions". I tend to think of regressions as "it worked in version x-1 but it's broken in x". Are long-standing bugs also fair game in stage 3? Does a bug need to be in bugz to be considered? paul
Re: Stage 3 question
On Fri, 5 Nov 2010, Paul Koning wrote: > On Nov 3, 2010, at 4:02 PM, Paul Koning wrote: > > > Question on what's appropriate... > > More on the same topic: sometimes the words are "bug fixes" and > sometimes "regressions". I tend to think of regressions as "it worked > in version x-1 but it's broken in x". Are long-standing bugs also fair > game in stage 3? Does a bug need to be in bugz to be considered? Stage 3 is for bug fixes (whether or not in Bugzilla), it's stage 4 that's regression fixes only. When you maintain a back end that is not a primary or secondary target in gcc-4.6/criteria.html, or a front end other than the C and C++ front ends considered in the criteria, you have essentially free rein to decide what goes in your part of the compiler during Stages 3 and 4, whether or not bug or regression fixes - the other side of that is that if you make major changes that destabilise such a back end or front end then we won't delay branching to allow for them to be fixed, and non-bug-fix front-end changes that break the default build for a primary or secondary target are liable to be reverted. -- Joseph S. Myers jos...@codesourcery.com
I propose Ralf Wildenhues for build machinery maintainer
To the steering committee: I propose Ralf Wildenhues as a new maintainer for the build machinery. Ralf often has useful comments for proposed patches to the configure scripts. He has done good work in upgrading to new versions of autoconf and libtool. As an autoconf maintainer himself he has experience with acting as a maintainer. Ian
Re: I propose Ralf Wildenhues for build machinery maintainer
On 05/11/2010 18:00, Ian Lance Taylor wrote: > To the steering committee: I propose Ralf Wildenhues as a new maintainer > for the build machinery. Seconded, for all the same reasons. Ralf's contributions have been invaluable. cheers, DaveK
Tweaking the pathname for __FILE__
The full pathname in __FILE__ is sometimes more than is desirable. For example, if multiple people may be building software in different working directories, you end up with binaries that have lots of differences in them that obscure "real" changes. Or it may be that rebuilding "the bits we had back in SVN rev 12345" is made harder this way, which can hurt debugging. It would be useful to be able to have __FILE__ be a portion of the full path name. I tried makefile magic that undefines and redefines __FILE__, but that runs into the issue that the compiler is protective about that name and makes it a warning to try this. And with -Werror, that kills the compile... -w appears to avoid that, but that's not a good solution. It occurred to me that this might be an issue others have run into. Would it be useful for gcc to provide some way to have the __FILE__ value trimmed? Perhaps something analogous to the -p switch in the "patch" utility? I can easily make something like this a private change, of course, but if there is interest in this as a common feature I can do it that way instead. paul
Re: Tweaking the pathname for __FILE__
Paul Koning writes: > The full pathname in __FILE__ is sometimes more than is desirable. For > example, if multiple people may be building software in different working > directories, you end up with binaries that have lots of differences in them > that obscure "real" changes. Or it may be that rebuilding "the bits we had > back in SVN rev 12345" is made harder this way, which can hurt debugging. __FILE__ expands to the file name you pass to gcc, so if you don't want a full path don't pass a full path. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: I propose Ralf Wildenhues for build machinery maintainer
On Fri, Nov 5, 2010 at 14:42, Dave Korn wrote: > > On 05/11/2010 18:00, Ian Lance Taylor wrote: > > To the steering committee: I propose Ralf Wildenhues as a new maintainer > > for the build machinery. > > Seconded, for all the same reasons. Ralf's contributions have been > invaluable. I agree as well. Diego.
Re: I propose Ralf Wildenhues for build machinery maintainer
> To the steering committee: I propose Ralf Wildenhues as a new > maintainer for the build machinery. > > Ralf often has useful comments for proposed patches to the configure > scripts. He has done good work in upgrading to new versions of > autoconf and libtool. As an autoconf maintainer himself he has > experience with acting as a maintainer. If Ralf needs a fourth, count on me. He has been de facto build maintainer for quite awhile anyway. -benjamin
Changing PR to ASSIGNED doesn't assign to me automatically
I've noticed an annoying change of behaviour in current Bugzilla compared to the old installation. If I changed a PR to ASSIGNED, it was automatically assigned to me. Now, the state does change to ASSIGNED alright, but the PR still remains assigned to unassig...@gcc.gnu.org, which doesn't seem to make sense to me. Am I doing something wrong here? If not, it would be extremely helpful to restore the old 2.x behaviour. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Tweaking the pathname for __FILE__
Paul Koning writes: > It occurred to me that this might be an issue others have run into. > Would it be useful for gcc to provide some way to have the __FILE__ > value trimmed? Perhaps something analogous to the -p switch in the > "patch" utility? I think it is useful to have a way to set __FILE__ in general. There already is a way: use a #line directive. It's not clear to me that it's necessary to have a command line option. foo.o: $(srcdir)/foo.c (echo '#line 1 "foo.c"'; cat $(srcdir)/foo.c) | $(CC) -c -x c - -o $@ Ian
Re: Changing PR to ASSIGNED doesn't assign to me automatically
On Fri, Nov 5, 2010 at 12:54 PM, Rainer Orth wrote: > I've noticed an annoying change of behaviour in current Bugzilla > compared to the old installation. If I changed a PR to ASSIGNED, it was > automatically assigned to me. Now, the state does change to ASSIGNED > alright, but the PR still remains assigned to unassig...@gcc.gnu.org, > which doesn't seem to make sense to me. Am I doing something wrong > here? If not, it would be extremely helpful to restore the old 2.x > behaviour. > I noticed that if I upload a patch, I have the option to take the bug. -- H.J.
value initialization and array data member
Hi Jason,
I'm looking into std::bitset with respect to constexpr issue.
My understanding has always been that one can use the
syntax `member()' to value-initialize an array data member
`member'. However, std/biset uses the notation
`member({ })'. Is that required? Especially for a mem-initializer
in a constexpr constructor definition?
-- Gaby
RE: asm_fprintf
> And putc_unlocked is a macro which appends to a buffer. puts is not. I *assumed* there is puts_unlocked like all the other *_unlocked. Maybe not. > (Really I'd rather gcc just output .o files directly...) > It would be an interesting project, but it's not a major component of > optimizing compilation time. I would certainly encourage any interested Perhaps when not optimizing? Eh, but I've taken no measurement. There is the possible fork() cost on Cygwin. But maybe spawn is used, much faster. - Jay
Re: value initialization and array data member
On 11/05/2010 09:03 PM, Gabriel Dos Reis wrote: I'm looking into std::bitset with respect to constexpr issue. My understanding has always been that one can use the syntax `member()' to value-initialize an array data member `member'. I believe so. Jason
Re: value initialization and array data member
Hi,
> On 11/05/2010 09:03 PM, Gabriel Dos Reis wrote:
>> I'm looking into std::bitset with respect to constexpr issue.
>> My understanding has always been that one can use the
>> syntax `member()' to value-initialize an array data member
>> `member'.
> I believe so.
Thanks Gaby and Jason.
I wanted to apply the below patch, which seems correct to me in the
light of your exchange and triggered ICEs, for
23_containers/bitset/cons/constexpr.cc for example I got:
In file included from
/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/23_containers/bitset/cons/constexpr.cc:21:0:
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bitset:
In constructor 'constexpr std::_Base_bitset<_Nw>::_Base_bitset() [with
long unsigned int _Nw = 4ul]':
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bitset:814:7:
instantiated from 'constexpr std::bitset<_Nb>::bitset() [with long
unsigned int _Nb = 256ul]'
/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h:627:20:
instantiated from 'void
__gnu_test::constexpr_default_constructible::operator()()::_Concept::__constraint()
[with _Tp = std::bitset<256ul>]'
/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h:631:17:
instantiated from 'void
__gnu_test::constexpr_default_constructible::operator()() [with _Tp =
std::bitset<256ul>]'
/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/23_containers/bitset/cons/constexpr.cc:29:38:
instantiated from here
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bitset:76:18:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5499
Can you have a look?
Thanks,
Paolo.
//
Index: include/std/bitset
===
--- include/std/bitset (revision 166384)
+++ include/std/bitset (working copy)
@@ -72,9 +72,10 @@
/// 0 is the least significant word.
_WordT _M_w[_Nw];
-#ifdef __GXX_EXPERIMENTAL_CXX0X__
- constexpr _Base_bitset() : _M_w({ }) { }
+ _GLIBCXX_CONSTEXPR _Base_bitset()
+ : _M_w() { }
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
constexpr _Base_bitset(unsigned long long __val)
: _M_w({ _WordT(__val)
#if __SIZEOF_LONG_LONG__ > __SIZEOF_LONG__
@@ -82,14 +83,9 @@
#endif
}) { }
#else
- _Base_bitset()
- { _M_do_reset(); }
-
_Base_bitset(unsigned long __val)
- {
- _M_do_reset();
- _M_w[0] = __val;
- }
+ : _M_w()
+ { _M_w[0] = __val; }
#endif
static _GLIBCXX_CONSTEXPR size_t
Re: value initialization and array data member
... oh well, this is enough:
struct A
{
int arr[1];
constexpr A()
: arr() { }
};
Paolo.
Re: asm_fprintf
Jay K writes: > > And putc_unlocked is a macro which appends to a buffer. puts is not. > > > I *assumed* there is puts_unlocked like all the other *_unlocked. > Maybe not. There is an fputs_unlocked. But it's still a function, not a simple macro. > > (Really I'd rather gcc just output .o files directly...) > > It would be an interesting project, but it's not a major component of > > optimizing compilation time. I would certainly encourage any interested > > > Perhaps when not optimizing? > Eh, but I've taken no measurement. I have (on GNU/Linux). > There is the possible fork() cost on Cygwin. > But maybe spawn is used, much faster. As of just a couple of days ago we use spawnve on cygwin. Ian
