[Bug libstdc++/10606] uncaught_exception() returns false too early
--- Additional Comments From david dot moore at intel dot com 2005-02-18 17:56 --- As the person who has been working on similar problems in the Intel Compiler, Martin and I had some lengthy discussions about this during which he convinced me he was correct. The result was issue 475 in the active C++ core issues list. Its now clear that uncaught_exception should be on during the copy construction of temporary that is thrown. Thinking about the user model, it seems that this is the only model that makes sense. I believe the standard clarifications in this issue will be made but that in any case, the issue is clear enough at this point to proceed. M2CW. David Moore -- What|Removed |Added CC||david dot moore at intel dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10606
[Bug libstdc++/20431] New: Out of range float inputs to cin get spurious values
Large values (that should produce inf, produce a bogus result instead.
For example, 1.0e+309 produces 1.39065e-309 on gcc 3.4.3!
Here is the trivial program:
#include
#include
using namespace std;
int main()
{
double a,b;
cout << "Enter a (Using cin):";
cin >> a;
printf ("Enter b (Using scanf):");
scanf ("%lf",&b);
cout <<"a = "<< a << "\tb = "<< b
[Bug libstdc++/20433] New: Out of range float inputs to cin get spurious values
Large values (that should produce inf, produce a bogus result instead.
For example, 1.0e+309 produces 1.39065e-309 on gcc 3.4.3!
Here is the trivial program:
#include
#include
using namespace std;
int main()
{
double a,b;
cout << "Enter a (Using cin):";
cin >> a;
printf ("Enter b (Using scanf):");
scanf ("%lf",&b);
cout <<"a = "<< a << "\tb = "<< b
[Bug libstdc++/20433] Out of range float inputs to cin get spurious values
--- Additional Comments From david dot moore at intel dot com 2005-03-11 21:39 --- Oops - this happened when I hit refresh to see Paulo's comments. Instead it resubmitted the bug! Very strange. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20433
[Bug c++/24559] New: Incorrect definition of wcspbrk in cwchar
According to the C++ standard the declarations of wcspbrk should take two cont
pointers or a (non-const pointer and a const pointer (in that order):
The actual declarations as if gcc 4.0 and apparently since introduction of the
second declaration take either two const pointers or two non-const pointers:
const wchar_t* wcspbrk(const wchar_t* s1, const wchar_t* s2);
wchar_t* wcspbrk( wchar_t* s1, const wchar_t* s2);
As a result the following (rather artificial) program does not compile when it
should:
#include
typedef wchar_t* (*pf)(wchar_t *, const wchar_t*);
int main() {
pf p1 = std::wcspbrk; // should compile
return 0;
}
--
Summary: Incorrect definition of wcspbrk in cwchar
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot moore at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24559
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change
--- Comment #45 from david dot moore at intel dot com 2006-02-10 22:34 --- The (C99) standard says: 6.7.2.1 (10) An implementation may allocate any addressable storage unit large enough to hold a bitfield. and 6.7.2.1 (11) As a special case, a bit-field structure member with a width of 0 indicates that no further bit-field is to be packed into the unit in which the previous bit-field, if any, was placed. NB -Not into a unit required by the given type (on the :0 line) So looks like 6 is the more plausible answer and the old behavior seems to be bizarre at best. It means, in effect, that the compiler has to go back and change its mind about the size of unit in which the previous bitfield was to be allocated. (You can no doubt get around the use of the past tense in the standard by suitable invocation of an oracle, or two-pass compilation - you could also always allocate eveything in UINTS - yetch) A more compelling argument for not changing this back is that gcc has done a good job of being (C++) ABI compatible since 3.4. Changing this back to pre-3.4 behavior now will create an ABI break between 3.4 and 4.0.3. Even delaying the change till 4.1 would be bad enough. So I strongly represent that this change should not be made or, if it is made, it should only happen under control of a flag that is off by default. BTW, you may think I am arguing this because it would avoid having to change the Intel compiler but actually it looks like when we changed our behavior we did not make sure that our gcc 3.2 compatible behavior did not change, so it looks like we have work to do anyway, and the impact of this change on our work is perhaps an extra leg in a conditional. So I can claim altruism here. Actually the real reason is I have been telling people that the ABI has been very stable since 3.4 and I would rather not have egg on my face. -- david dot moore at intel dot com changed: What|Removed |Added CC||david dot moore at intel dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change
--- Comment #46 from david dot moore at intel dot com 2006-02-11 00:14 --- (Note - I had not realized the importance of pragma pack to this problem. The fact that without it the behavior has not changed weakens my case, although it probably weakens the case that it should be restored to gcc 3.2 behavior by an equal amount) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug libstdc++/19284] New: Simple type names fail to demangle - regression from 3.2
The following program works under gcc 3.2 but no longer works on 3.4. I believe
this is a regression. (its actually a regression test from a different compiler)
Expected output shown in comments in program.
Seen on EL4 Preview Candidate using gcc version 3.4.3 20041125 (Redhat 3.4.3-
5.EL4)
// Pasted in because no way to attach files is being displayed in my browser
// Check some simple type names can be demangled
// Expected output:
// i:int: 0
// c:char: 0
// f:float: 0
// d:double: 0
// Seen output with gcc version 3.4.3 20041125
// i:-2
// c:-2
// f:-2
// d:-2
#include
#include
extern "C" char *__cxa_demangle(const char *, char *, size_t *, int *);
int demangle(const char *name)
{
int s;
char *d = __cxa_demangle(name, NULL, NULL, &s);
std::cout << name << ":";
if (d) std::cout << d << ": ";
std::cout << s << std::endl;
return 0;
}
int main() {
demangle(typeid(int).name());
demangle(typeid(char).name());
demangle(typeid(float).name());
demangle(typeid(double).name());
return 0;
}
--
Summary: Simple type names fail to demangle - regression from 3.2
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot moore at intel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: IA32 EL4 Preview Candidate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19284
[Bug libstdc++/19284] Simple type names fail to demangle - regression from 3.2
--- Additional Comments From david dot moore at intel dot com 2005-01-05 23:55 --- Created an attachment (id=7881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7881&action=view) Test case attached (same as pasted version) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19284
[Bug libstdc++/19284] Simple type names fail to demangle - regression from 3.2
--- Additional Comments From david dot moore at intel dot com 2005-01-06 00:08 --- Subject: RE: Simple type names fail to demangle - regression from 3.2 Is that in gnats? Actually, my real question is should I have reported this in a different data base? Searched for demangle and did not find the one you mention in gnats. >-Original Message- >From: pcarlini at suse dot de [mailto:[EMAIL PROTECTED] >Sent: Wednesday, January 05, 2005 4:03 PM >To: Moore, David >Subject: [Bug libstdc++/19284] Simple type names fail to >demangle - regression from 3.2 > > >--- Additional Comments From pcarlini at suse dot de >2005-01-06 00:02 --- >I'm pretty sure this is a duplicate of libstdc++/16845... Ian, >can you confirm? >Thanks! (hi David...) > >-- > What|Removed |Added >--- >- > CC||ian at airs dot com > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19284 > >--- You are receiving this mail because: --- >You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19284
