Re: Packing booleans?
On Wed, 4 May 2005, Nathan Sidwell wrote: Sam Lauber wrote: Would it be possible to have a -fpack-bools option that packs booleans into the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register (or memory, as the case may be)? why would you want to do this? Seems to me you might save up to 7 bytes of data memory at a vastly greater expansion of code size and reduction in performance. Unless you are using an architecture with btst, bset, bclr instructions.
Re: Reporting bugs: there is nothing to gain in frustrating reporters
On Sat, 18 Jun 2005, Vincent Lefevre wrote: On 2005-06-16 17:54:03 -0400, Robert Dewar wrote: As you well know, not everyone agrees this is a bug, and this does not have to do with performance. Saying over and over again that you think it is a bug does not make it so. I haven't seen any correct argument why it could not be a bug. Saying that the x86 processor is buggy is just completely silly. Only some gcc developers think so. Don't know about you, but I consider any processor that is unable to store a register to memory and then read back the same value to be buggy. Sure, you can change rounding precision but according to my 2003 version of "IA-32 Intel(r) Architecture Software Developer's Manual - Volume 1: Basic Architecture" a) That takes at least 4 instructions. b) Only affects some instructions, and then only the result. c) Only affects the significand and not the exponent. Disclaimer: I haven't done any testing to verify that this is actually the case since I have no access to x86 hardware.
Re: Reporting bugs: there is nothing to gain in frustrating reporters
On Sat, 18 Jun 2005, Robert Dewar wrote: Mattias Karlsson wrote: Don't know about you, but I consider any processor that is unable to store a register to memory and then read back the same value to be buggy. THe x86/x87 does not violate this requirement In my Obi-Wan-Point-Of-View it does. :-) This entire debate comes from one thing: currently floating point has always type long double untill stored to memory, regardless of user-specified type. At -O1 this becomes more or less non-deterministic.
Re: Reporting bugs: there is nothing to gain in frustrating reporters
On Sat, 18 Jun 2005, Robert Dewar wrote: Mattias Karlsson wrote: On Sat, 18 Jun 2005, Robert Dewar wrote: Mattias Karlsson wrote: Don't know about you, but I consider any processor that is unable to store a register to memory and then read back the same value to be buggy. THe x86/x87 does not violate this requirement In my Obi-Wan-Point-Of-View it does. :-) Well I think it is inapprorpiate to assign erroneous points of view to Obi-Wan :-) Once again, on the x86/x87 the process IS "able to store a register to memory and then read back the same value". ANy claim to the contrary is ill-informed. This entire debate comes from one thing: currently floating point has always type long double untill stored to memory, regardless of user-specified type. At -O1 this becomes more or less non-deterministic. Yes, right, but that is a different issue from being able to store a register to memory and then read back the same value. I confess of being overly generic, and quite fuzzy about my point. Anyway my point of view is that the solution to anyone needing strict IEEE semantics are: 1) Use -float-store 2) Use sse math 3) Learn to live without it. Since the "gcc-is-buggy" solution of changing x87 rounding modes will: 1) Be a lot of work. 2) Cause a lot of regressions.
Re: Reporting bugs: there is nothing to gain in frustrating reporters
On Sun, 19 Jun 2005, Vincent Lefevre wrote: Since the "gcc-is-buggy" solution of changing x87 rounding modes will: 1) Be a lot of work. 2) Cause a lot of regressions. This remains to see. BTW, the Opteron uses SSE by default. Did you see a lot of regressions? Opteron is not an issue, when I talked about regressions above I dont mean only "My code give a diffrent answer" regressions but also "My code that uses both float/doubles is bigger and slower"
Re: Reporting bugs: there is nothing to gain in frustrating reporters
On Sun, 19 Jun 2005, Vincent Lefevre wrote: Since the "gcc-is-buggy" solution of changing x87 rounding modes will: 1) Be a lot of work. 2) Cause a lot of regressions. This remains to see. BTW, the Opteron uses SSE by default. Did you see a lot of regressions? Opteron is not an issue, when I talked about regressions above I dont mean only "My code give a diffrent answer" regressions but also "My code that uses both float/doubles is bigger and slower" Not by the proposed solution "of changing x87 rounding modes". Of course, this solution is not sufficient to completely fix the bug (due to the exponent range), but it would solve most problems. And concerning the solution with stores, then users would have to learn to use compiler options. BTW, in this way, they could even learn the existence of -ffast-math and have smaller and faster programs! :) True, more people should try -ffast-math since on x87 it can give them more precisison and not less, with the nasty non-deterministic loss of that extra precission. On the other hand, sysadmins refuse to install gcc versions past 3.3 at my institution (gcc is the default and only compiler available to students on non-windows machines) since "It's not binary compatible, and then we need an costly OS update". True, ABI changed in 3.3 but reading PR's I see that it only affects 64-bit code, and 64-bit libraries are not available anyway.
Template declaration inside function
Given:
void f(void)
{
template class A
{
};
}
g++ 4.0/3.4 gives:
bug.cpp:4: error: expected primary-expression before 'template'
Can a language lawer please confirm that this is even valid before I
create a PR?
Re: Template declaration inside function
On Tue, 21 Jun 2005, Florian Weimer wrote:
* Mattias Karlsson:
Given:
void f(void)
{
template class A
{
};
}
g++ 4.0/3.4 gives:
bug.cpp:4: error: expected primary-expression before 'template'
Can a language lawer please confirm that this is even valid before I
create a PR?
It's not valid (local template declarations are not allowed, see
14(2)), but it makes sense to create a PR. The error message is very
hard to understand.
This is now enhancement/22138.
