Bug#408918: [powerpc] -maltivec generates AltiVec code when not asked to

2007-01-29 Thread Sam Hocevar
Package: gcc-4.1 Version: 4.1.1-21 Severity: important The way I understand the -maltivec flag is make the compiler aware of AltiVec instructions and the vector type, but only generate AltiVec code if the altivec.h intrinsics are being used, whereas -mabi=altivec means generate AltiVec code

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread pcarlini at suse dot de
--- Comment #18 from pcarlini at suse dot de 2007-01-30 00:34 --- Implementing the really trivial solution of providing what() members returning std::bad_alloc, std::bad_cast, std::bad_typeid, and std::bad_exception. -- pcarlini at suse dot de changed: What|Removed

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread pinskia at gcc dot gnu dot org
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-30 00:54 --- (In reply to comment #18) Implementing the really trivial solution of providing what() members returning std::bad_alloc, std::bad_cast, std::bad_typeid, and std::bad_exception. I don't think that is the

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread pcarlini at suse dot de
--- Comment #20 from pcarlini at suse dot de 2007-01-30 00:58 --- (In reply to comment #19) I don't think that is the correct solution as if you subclass these functions, you get the incorrect result. What do you mean by incorrect?!? If you subclass, either you provide your own

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread gdr at cs dot tamu dot edu
--- Comment #21 from gdr at cs dot tamu dot edu 2007-01-30 01:30 --- Subject: Re: std::bad_alloc::what() does not explain what happened pcarlini at suse dot de [EMAIL PROTECTED] writes: | What do you mean by incorrect?!? If you subclass, either you | provide your own what(), or you

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread pcarlini at suse dot de
--- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 --- (In reply to comment #21) I suspect Andrew Pinski's point might be that what() could return a string that represents the name of the most derived type of the exception. But, nothing so far forces to do that. A

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread gdr at cs dot tamu dot edu
--- Comment #23 from gdr at cs dot tamu dot edu 2007-01-30 02:11 --- Subject: Re: std::bad_alloc::what() does not explain what happened pcarlini at suse dot de [EMAIL PROTECTED] writes: | --- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 --- | (In reply to

[Bug java/14712] gcj - ICE in final_scan_insn, at final.c:2247

2007-01-29 Thread tromey at gcc dot gnu dot org
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-30 02:17 --- Fixed by the gcj-eclipse merge. -- tromey at gcc dot gnu dot org changed: What|Removed |Added

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread pcarlini at suse dot de
--- Comment #24 from pcarlini at suse dot de 2007-01-30 02:21 --- (In reply to comment #23) From consistency point of view I would say that the change should also be done for std::exception. Right. However, the use of typeid is very convenient in the sense that we have to

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

2007-01-29 Thread gdr at cs dot tamu dot edu
--- Comment #25 from gdr at cs dot tamu dot edu 2007-01-30 03:53 --- Subject: Re: std::bad_alloc::what() does not explain what happened pcarlini at suse dot de [EMAIL PROTECTED] writes: | However, the use of typeid is very convenient in the sense that we | have to defined what()