Bug?

Bug?

[Brian]

Whenever I try to insert a label before the 
"EPILOGUE_BEGIN" NOTE of a function that contains
a switch statement, I get an internal compiler error.

Again...It only happens when I process a function where
there is a SWITCH statement.

For now I can't allow any code with switch statements.
Ideas?  

Brian

Re: bug?

[skaller]

On Mon, 2007-10-22 at 06:05 -0500, John Love-Jensen wrote:
> Hi skaller,
> 
> > This looks like a bug:
> 
> Definitely a bug!
> 
> It's a bug to use C <x.h> headers in C++ code.  C++ code should use the C++
> <x> headers.

That isn't possible: many headers (eg Posix) are C only (*.h files).
gcc takes care to allow mixing them. C form of C++ header works too.
This is implementation dependent, but gcc implements it very well
IMHO: magically symbols are both ::symbol and std::symbol... :)

What actually happened was me being stupid:

	namespace X { 
	#include <cstddef>
	}

woops! It would be cool if there were some magic to
warn about this, eg:

	#pragma SHOULD_BE_GLOBAL
	#pragma SHOULD_BE_GLOBAL_OR_STD



-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: bug?

[John Love-Jensen]

Hi skaller,

> This looks like a bug:

Definitely a bug!

It's a bug to use C <x.h> headers in C++ code.  C++ code should use the C++
<x> headers.

> Can anyone see any way this could happen (C++ code,
> using both <x.h> and <x> in various places).

Yes, I can see how that could happen.

C++ code should not use <x.h>, since those are C header files.

Mixing C <x.h> header files in C++ programs can incur all sorts of
interesting subtle side effects.

Use C <x.h> headers for C code.

Use C++ <x> headers for C++ code.

HTH,
--Eljay

bug?

[skaller]

This looks like a bug:

In file included from ./lpsrc/flx_pthread.pak:208,
                 from ./lpsrc/flx_pthread.pak:160,
                 from ./lpsrc/flx_pthread.pak:1507,
                 from ./lpsrc/flx_pthread.pak:1553:
/usr/include/c++/4.2/cstddef:55: error: ‘::ptrdiff_t’ has not been
declared

Can anyone see any way this could happen (C++ code,
using both <x.h> and <x> in various places).


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: bug?

[Eljay Love-Jensen]

Hi Alexey,

>bug?

Yes, the code has a bug in it.

--Eljay

Re: bug?

[corey taylor]

Alexey,

Array bounds checks are not performed in C or C++.

You are writing to memory outside of the array, and it is an error in
the code.  You probably do not crash because the program is simple.

cout does not know the size of the array.  It only sees a char* and
keeps looking forward 1 byte at a time until a 0 is found.

corey

On 8/25/05, Alexey Sokolov <sokolhacker@mail.ru> wrote:
> Hallo!
> /**************************/
> //example file "example.cpp"
> //begin
> #include <iostream.h>
> 
> main()
> {
>          char name[1]; //1 byte(!)
>          name[0]='1';
>          name[1]='2';
>          name[2]='3';
>          name[3]='4';
>          name[4]='\0';
>          cout << name << "\n";
> }
> //end
> /**************************/
> 
> $g++ example.cpp
> $./a.out
> 1234
> 
> 1,2,3,4 and '\0' = 5 byte!
> 5 byte != 1 byte (char name[1];)!
> 
> But why? Forgive for English, I am simple Russian =)
> 
> --
> #gcc --version
> gcc (GCC) 3.4.2 [FreeBSD] 20040728
> 
>

bug?

[Alexey Sokolov]

Hallo!
/**************************/
//example file "example.cpp"
//begin
#include <iostream.h>

main()
{
         char name[1]; //1 byte(!)
         name[0]='1';
         name[1]='2';
         name[2]='3';
         name[3]='4';
         name[4]='\0';
         cout << name << "\n";
}
//end
/**************************/

$g++ example.cpp
$./a.out
1234

1,2,3,4 and '\0' = 5 byte!
5 byte != 1 byte (char name[1];)!

But why? Forgive for English, I am simple Russian =)

--
#gcc --version
gcc (GCC) 3.4.2 [FreeBSD] 20040728

Bug????

[kabir.patel]

Remember the strange "opcode" error messages I was getting......



Well I didn't use "gas" in the end. I just (painfully) went through the code,
and removed lines at random, in the hope that the messages

would go away. Eventually they did. I had to remove a case statement.

I tried another piece of code and got the same error messages, so decided to
remove some of the case statements again. Again the

error messages disappeared. I did some testing and have now realised that when
more that 3 case statements are put into a switch expression

the "opcode" messages appear.

Is this a bug with the c compiler? Can any of you confirm my findings?

Thanks



*******************Internet Email Confidentiality Footer*******************


Privileged/Confidential Information may be contained in this message.  If you
are not the addressee indicated in this message (or responsible for delivery of
the message to such person), you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender by
reply email. Please advise immediately if you or your employer does not consent
to Internet email for messages of this kind.  Opinions, conclusions and other
information in this message that do not relate to the official business of my
firm shall be understood as neither given nor endorsed by it.

Re: bug?

[Alexandre Oliva]

On Jun 19, 2001, Ingo Krabbe <ikrabbe@earthling.net> wrote:

> On 19 Jun 2001, Alexandre Oliva wrote:
>> > That's a kind of why I used ~(~(x^x)<<(sizeof(x)*8-n)).

>> Make the `8' `CHAR_BIT'.  BTW, did you consider what happens if x is
>> narrower than size_t (the type of sizeof(x)) for both signed and
>> unsigned integer types?

> Hmm, I considered that sizeof(x) returns the size of bytes which has a
> length of 8 though a char may be longer ?!

sizeof(char) is always 1, but there's no guarantee that 1 byte will
contain exactly 8 bits.  That's where CHAR_BIT comes into play.

> Then I considered that ~(x^x) gives a stream of '1' as long as x.

Right.  But then, the shift operation causes the result to be promoted
to a type at least as wide as size_t.  This may cause sign extension,
if x is a signed type, or zero extension, if x is unsigned.  So, you
may get different bit patterns depending on the signedness of x.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: bug?

[Ingo Krabbe]

On 19 Jun 2001, Alexandre Oliva wrote:
> > That's a kind of why I used ~(~(x^x)<<(sizeof(x)*8-n)).
>
> Make the `8' `CHAR_BIT'.  BTW, did you consider what happens if x is
> narrower than size_t (the type of sizeof(x)) for both signed and
> unsigned integer types?

Hmm, I considered that sizeof(x) returns the size of bytes which has a
length of 8 though a char may be longer ?!
Then I considered that ~(x^x) gives a stream of '1' as long as x. Anything
above x doesn't matter because thats not copied back into x ?!

With my machine this works for anything from char to unsigned long long !!

CU INGO

Re: bug?

[Alexandre Oliva]

On Jun 19, 2001, Ingo Krabbe <ikrabbe@earthling.net> wrote:

> On 19 Jun 2001, Alexandre Oliva wrote:

>> This is only well-defined if x's type is unsigned.  The behavior of
>> right-shifting negative values is undefined (or unspecified?)

> That's a kind of why I used ~(~(x^x)<<(sizeof(x)*8-n)).

Make the `8' `CHAR_BIT'.  BTW, did you consider what happens if x is
narrower than size_t (the type of sizeof(x)) for both signed and
unsigned integer types?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: bug?

[Ingo Krabbe]

On 19 Jun 2001, Alexandre Oliva wrote:

> On Jun 18, 2001, Ingo Krabbe <ikrabbe@earthling.net> wrote:
>
> > Hmm, I see that we can also do
> > x & (~(x^x)>>n) which is really easier :-)
>
> This is only well-defined if x's type is unsigned.  The behavior of
> right-shifting negative values is undefined (or unspecified?)
>
That's a kind of why I used ~(~(x^x)<<(sizeof(x)*8-n)).

CU INGO

Re: bug?

[Alexandre Oliva]

On Jun 18, 2001, Ingo Krabbe <ikrabbe@earthling.net> wrote:

> Hmm, I see that we can also do
> x & (~(x^x)>>n) which is really easier :-)

This is only well-defined if x's type is unsigned.  The behavior of
right-shifting negative values is undefined (or unspecified?)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: bug?

[Ingo Krabbe]

Oh sorry,

(x^x) = 0 because this is bitwise: x (xor) x which is definetly 0.
I use this expression because it is a null with exactly the bit
length of the type of x.

~(x^x)= ~0 is a bitwise not of 0 which is all bits set to 1.

~(x^x)<<(8*sizeof(x)-n) which is left shift ~(x^x) number of the bits of
the type of x - n. This leaves the n upper bits as 1 and all others are 0.

finally we do a ~ upon this, which sets n upper bits to 0 and all others
to 1 . Together with the & it masks out the n upper bits of number x.

Hmm, I see that we can also do
x & (~(x^x)>>n) which is really easier :-)


> I propose that:
>
> x = number to clarify upper bits,
> n = index of the first byte to clear (0 .. 2^p-1 for a type with p bytes)

I mean n is the number of upper bits to clear and x is the number.

> #define CLEAR_UPPER_BITS(n,x)\
>                                                (x&((1<<(n))-1))
>
> Simple no ?
>

> By the way, it's not the shift that causes problems, it's the printf that
> assumes its arguments to be ints (that's in the specs). With addition
> you would have the same problem:
>

Nope. printf assumes its arguments as you say it. %x is an integer !!!!

I have done the following to test the code:

#include <stdio.h>

#define CLEAR_UPPER_BITS(n,x) \
        ((n<sizeof(x)*8) ? x&(~((~(x^x))<<(8*sizeof(x)-n))):0)

int main(int argc, char** argv)
{
	unsigned long long y = 0xcc55cc55cc55cc55;

	printf( "%Lx\n", CLEAR_UPPER_BITS( 32, y ));
	return 0;
}

You see that the algorithm works for very long numbers. (Hope your
compiler knows long long!

CU INGO

Re: bug?

[David Berthelot]

Ingo Krabbe wrote:

> On Fri, 15 Jun 2001, Ben Kohlen wrote:
>
> > I am expecting that when I shift right, I will always
> > get zeroes in from the left, but when I use data types
> > less than 32 bits, this is not always the case.
> >
> > Example:
> > ...
> > unsigned short s = 0xcc55;
> > printf("%x\n", (s<<8)>>8);
> > ...
> > yeilds the output "cc55" where as I was expecting
> > "55".
> >
>
> I don't think thats a bug, it is more a question of flavour, of course
> it would be very nice to fill 0 into the upper bits. It may be better to
> mask them out:
> #define CLEAR_UPPER_BITS(n,x) \
>         ((n<sizeof(x)*8) ? x&(~((~(x^x))<<(8*sizeof(x)-n))):0)
>
> This is machine and (numeric) type independent masking out of n upper
> bits. For smaller types we can use a 0 instead of x^x. There may be a more
> optimized solution ? We can also give a 0 in the right length to the
> algorithm:
> #define CLEAR_UPPER_BITS(n,x,null) \
>         ((n<sizeof(x)*8) ? x&(~((~(null))<<(8*sizeof(x)-n))):0)
>
> Has anyone a better solution ?
>
> CU INGO

Ok may be I don't get it, but for me it seems rather complicated to me,
I don't even understand the x^x (x power x ?).

I propose that:

x = number to clarify upper bits,
n = index of the first byte to clear (0 .. 2^p-1 for a type with p bytes)

#define CLEAR_UPPER_BITS(n,x)\
                                               (x&((1<<(n))-1))

Simple no ?

By the way, it's not the shift that causes problems, it's the printf that
assumes its arguments to be ints (that's in the specs). With addition
you would have the same problem:

short x = 0x7fff;

printf("%x\n", x+x+x);

will display:
0x17ffd (and that's out of the bounds for a short).

David

Re: bug?

[Ingo Krabbe]

On Fri, 15 Jun 2001, Ben Kohlen wrote:

> I am expecting that when I shift right, I will always
> get zeroes in from the left, but when I use data types
> less than 32 bits, this is not always the case.
>
> Example:
> ...
> unsigned short s = 0xcc55;
> printf("%x\n", (s<<8)>>8);
> ...
> yeilds the output "cc55" where as I was expecting
> "55".
>

I don't think thats a bug, it is more a question of flavour, of course
it would be very nice to fill 0 into the upper bits. It may be better to
mask them out:
#define CLEAR_UPPER_BITS(n,x) \
	((n<sizeof(x)*8) ? x&(~((~(x^x))<<(8*sizeof(x)-n))):0)

This is machine and (numeric) type independent masking out of n upper
bits. For smaller types we can use a 0 instead of x^x. There may be a more
optimized solution ? We can also give a 0 in the right length to the
algorithm:
#define CLEAR_UPPER_BITS(n,x,null) \
	((n<sizeof(x)*8) ? x&(~((~(null))<<(8*sizeof(x)-n))):0)

Has anyone a better solution ?

CU INGO

Re: bug?

[Alexandre Oliva]

On Jun 15, 2001, Ben Kohlen <bckohlen@yahoo.com> wrote:

> I am expecting that when I shift right, I will always
> get zeroes in from the left, but when I use data types
> less than 32 bits, this is not always the case.

That's because the shift-count is int, so it causes the other argument
to be promoted to int too.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: bug?

[David Berthelot]

Hi Ben,

as far as I know, arguments are ints for printf,
so the destination 'variable' if there was one, would
be an int.
So in fact your data is 32 bits for your printf, that is
not equivalent to your lines of code which results are
stored into a short.

So I think, everything's correct.

Try:

printf("%x\n", ((unsigned short)(s<<8))>>8);

David

Ben Kohlen wrote:

> I am expecting that when I shift right, I will always
> get zeroes in from the left, but when I use data types
> less than 32 bits, this is not always the case.
>
> Example:
> ...
> unsigned short s = 0xcc55;
> printf("%x\n", (s<<8)>>8);
> ...
> yeilds the output "cc55" where as I was expecting
> "55".
>
> I was expecting this to be equivalent to:
> ...
> s = s << 8;
> s = s >> 8;
> ...
> in which you do explicit assignment, which does yeild
> "55" as the output.
>
> Is this part of C spec, unspecified by C, or actually
> a gcc bug?
>
> gcc version 2.95.3 20010315 (release) on an x86 btw.
>
> Please CC responses, as I am not on the list.
>
> Cheers,
> Ben
>
> __________________________________________________
> Do You Yahoo!?
> Spot the hottest trends in music, movies, and more.
> http://buzz.yahoo.com/

bug?

[Ben Kohlen]

I am expecting that when I shift right, I will always
get zeroes in from the left, but when I use data types
less than 32 bits, this is not always the case.

Example:
...
unsigned short s = 0xcc55;
printf("%x\n", (s<<8)>>8);
...
yeilds the output "cc55" where as I was expecting
"55".

I was expecting this to be equivalent to:
...
s = s << 8;
s = s >> 8;
...
in which you do explicit assignment, which does yeild
"55" as the output.

Is this part of C spec, unspecified by C, or actually
a gcc bug?

gcc version 2.95.3 20010315 (release) on an x86 btw.

Please CC responses, as I am not on the list.

Cheers,
Ben

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/