On Tue, 2010-03-02 at 10:47 +, Andrew Haley wrote:
> On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
>
> >> int duff4_fails(char * dst,const char * src,const size_t n)
> >> {
> >> const size_t rem=n % 4, a=rem + (!rem)*4;
> >> char * d=dst+=a;
&
statement in the
> > for-loop (hence this *second* bug). Haven't checked the assembly
> > though...
>
> The routines are not equivalent. in _works you unconditionally
> do dst += n while in _fails you only do it for rem == 0.
That's right. And about missing warning?
>
> Richard.
>
> > Kind regards,
> >
> > Pjotr Kourzanov
> >
>
On Tue, 2010-03-02 at 10:24 +, Andrew Haley wrote:
> On 03/02/2010 09:38 AM, Peter Kourzanov wrote:
>
> > I have the following variation on Duff's device that seems to
> > mis-compile on all GCC versions I can access within a minute (that
> > is gcc-3.{3,4}, gcc-4.{1,2,3,4} on x86 and gcc
On Wed, 2009-02-11 at 18:14 -0500, Diego Novillo wrote:
> On Wed, Feb 11, 2009 at 11:46, Pjotr Kourzanov
> wrote:
>
> > Should we not have a way to specify a plugin in the source itself?
> > This could be achieved by tagging a function with a __plugin__
> > attribut
ng on...
Regards,
Pjotr Kourzanov
giving the specifier a value that does
not match the range of the enum (e.g., :1) does trigger a warning
(`e' is narrower than values of its type).
I am using Debian-packaged compilers.
Regards,
Pjotr Kourzanov
hat I am trying to
initialize a struct containing this seemingly variable-sized array.
I would like to know if its a known bug, and if possible I could file a proper
bug report if this helps...
I am using Debian-packaged compilers.
Regards,
Pjotr Kourzanov
