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 .
... oh well, this is enough:
struct A
{
int arr[1];
constexpr A()
: arr() { }
};
Paolo.
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
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
> 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
> opti
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-initializ
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 rema
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 __FIL
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
> 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 himse
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
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 t
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 ha
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
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 exp
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
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
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 yo
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:
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
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
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
Hello all
Can anyone please give me a two line description about mach pass in
GCC or any source reference for that.
Regards
Abdul
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.
FYI, GCC trunk revision 166285 passes SPEC CPU 2000/2006.
It is the first time in a month.
--
H.J.
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 tim
26 matches
Mail list logo
