gnu software bugs - shift left
Hi, Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Regards, Mischa. On 11/02/2013 07:10 PM, Dan Kegel wrote: Please don't crosspost. It would probably also help if you posted just one bug per message, and included the commandline, source, and error message for your smallest test case inline, and used a more descriptive subject line. On Sat, Nov 2, 2013 at 10:26 AM, Mischa Baars mjbaars1...@gmail.com wrote: Hi, I found these two small bugs in the gnu software. Anyone who would like to try to fix these? Regards, Mischa. 2013101700 - gnu software bugs - shift left.tar.bz2 Description: application/bzip
Re: gnu software bugs - shift left
On 11/02/2013 07:52 PM, Ian Lance Taylor wrote: On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars mjbaars1...@gmail.com wrote: Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Thanks for reporting issues with the compiler. This code is short enough that it would be simpler to just include the code inline in your e-mail message. For a case this short we don't need a makefile; just put the command line showing the problem in e-mail. Unfortunately your test case was not very clear. I think you are wondering why these two declarations uint64_t x = 1 31; uint64_t y = (uint64_t) 1 31; do not produce the same values in x and y. That is not a bug in GCC. It's how the C language works. In the first line, an integral constant without a suffix has type int. Left shifting that int value by 31 still gives you a value of type int. On a system where int is 32 bits, converting a value of type to a value of type uint64_t sign extends the int. I understand, however it seems more logical to use the destination type to determine the type of the first and second operand. Are you completely sure this is the desired behaviour? In the second line, the value is already type uint64_t, and so left shifting it and then assigning it to a variable of type uint64_t does not do any sign extension. Ian
Re: gnu software bugs - shift left
On 2 November 2013 18:57, Mischa Baars wrote: I understand, however it seems more logical to use the destination type to determine the type of the first and second operand. Are you completely sure this is the desired behaviour? It's the behaviour required by the C standard, so yes, it is absolutely desirable that GCC does that. The literal 1 has a fixed type and the literal 31 has a fixed type, and the expression (131) has a fixed type. Whether you assign the result to a different type does not alter those types involved in the expression.
Re: gnu software bugs - shift left
On 11/02/2013 08:17 PM, Jonathan Wakely wrote: On 2 November 2013 18:57, Mischa Baars wrote: I understand, however it seems more logical to use the destination type to determine the type of the first and second operand. Are you completely sure this is the desired behaviour? It's the behaviour required by the C standard, so yes, it is absolutely desirable that GCC does that. The literal 1 has a fixed type and the literal 31 has a fixed type, and the expression (131) has a fixed type. Whether you assign the result to a different type does not alter those types involved in the expression. Wow, that sounds pretty stupid for a standard again :) Thanks.
Re: gnu software bugs - shift left
Hi! On 02/11/13 19:22, Mischa Baars wrote: On 11/02/2013 08:17 PM, Jonathan Wakely wrote: On 2 November 2013 18:57, Mischa Baars wrote: *I understand, however it seems more logical to use the destination type to ** **determine the type of the first and second operand. * No. No it does not. Are you completely sure this is the desired behaviour? *It's the behaviour required by the C standard*, so yes, it is absolutely desirable that GCC does that. *The literal 1 has a fixed type and the literal 31 has a fixed type, ** **and the expression (131) has a fixed type. Whether you assign the ** **result to a different type does not alter those types involved in the ** **expression. * This Wow, that sounds pretty stupid for a standard again :) There is such a vast amount wrong with this I am not sure where to start. Please finish chapter one of whatever book you are reading. It was wrong to make you feel fit to comment on this behavior. Thanks. Alec
