[Bug bootstrap/39454] [4.4 Regression] Bootstrap failure on sparcv9-linux with profiledbootstrap
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-14 08:11 --- Subject: Bug 39454 Author: jakub Date: Sat Mar 14 08:10:55 2009 New Revision: 144857 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144857 Log: PR bootstrap/39454 * cse.c (fold_rtx): Don't modify original const_arg1 when canonicalizing SHIFT_COUNT_TRUNCATED shift count, do it on a separate variable instead. * rtlanal.c (nonzero_bits1) : Don't assume anything from out of range shift counts. (num_sign_bit_copies1) : Similarly. Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/rtlanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39454
[Bug bootstrap/39454] [4.4 Regression] Bootstrap failure on sparcv9-linux with profiledbootstrap
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-14 08:12 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39454
[Bug libstdc++/39405] [4.3 regression] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts
--- Comment #22 from d dot frey at gmx dot de 2009-03-14 08:52 --- (In reply to comment #21) > Now I think I know the conservative way we want to go for the branch: just > change shared_ptr<>::operator* to always use something with the same semantics > of std::tr1::add_reference. For mainline, we'll see if there is still > something > to tweak, also in relation to 39310... Sounds good to me. I was trying to figure out why it seems so hard to understand what is wrong with the current code. Here's what I'm currently thinking: a) __is_abstract (and maybe others) accept incomplete types. They should IMHO reject them instead of reporting wrong results. Combined with template instantiations, the result can be really strange. I'll add an attachment which you can play with to experience some of the problems first hand :) b) some type_traits should work on incomplete types. is_const, remove_const, add_lvalue_reference are good examples. But this also means that they may not use type_traits that require complete types within their implementation. I think this is what happened initially: shared_ptr does not need T to be complete, it uses add_lvalue_reference (should be OK), which in turn uses is_function (OK?) which uses is_abstract - which is NOT OK. I've checked N2800, in 20.5.4.3/3 it clearly talks about these points. The table in N2800 is clear on is_const to not require a complete type T (and not to instantiate T), and it is clear on is_abstract to require a complete type (and to instantiate it). I haven't found anything similar for add_lvalue_reference, as 20.5.6 (Transform traits) seems to ignore the topic. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
[Bug libstdc++/39405] [4.3 regression] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts
--- Comment #23 from d dot frey at gmx dot de 2009-03-14 08:53 --- Created an attachment (id=17463) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17463&action=view) show inconsistency with is_abstract -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
[Bug middle-end/39460] strange aliasing warnings compiling pymol under gcc 4.4
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-03-14 09:32 --- You can work around it in a gcc specific way by doing typedef int my_aliased_int __attribute__((may_alias)); and using my_aliased_int *data = (int *) v; my_aliased_int *N; This forces TBAA not to be applied to references through data and N. Otherwise it is hard to do without knowing the original object types (basically you would need to make sure to do the memory accesses using the original type). Or you can do all the memory accesses via memcpy like memcpy (&t0, &N[0], 4); (which the compiler will optimize to the may_alias variant). That would be even portable to non-GCC compilers. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39460
[Bug middle-end/39460] strange aliasing warnings compiling pymol under gcc 4.4
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-14 09:32 --- Invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39460
[Bug fortran/38273] Cray pointers: Document that pointers cannot be function return values
--- Comment #1 from pault at gcc dot gnu dot org 2009-03-14 09:58 --- There is no reason at all why this cannot be fixed. Adding non-standard on non-standard doesn't seem too bad:-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38273
[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON
--- Comment #4 from pault at gcc dot gnu dot org 2009-03-14 09:56 --- Helps to confirm it:-) -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-14 09:56:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39239
[Bug libstdc++/39405] [4.3 regression] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts
--- Comment #24 from paolo dot carlini at oracle dot com 2009-03-14 12:06 --- I agree with your analysis. Can you please open a separate PR about __is_abstract (which would be a C++ report): currently, we are trying to complete the types, but we do not error out in case of incompleteness. Apparently, according to your testcase, in order to obtain a consistent behaviour we should require completeness (unless array or void), for __is_abstract and all the other builtins for which it is a precondition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
--- Comment #16 from hjl dot tools at gmail dot com 2009-03-14 15:01 --- There is pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1 PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by revision 144857. Does revision 144857 fix this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug target/39064] libiberty md5.h needs uintptr_t
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 15:46 --- http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00638.html -- nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
[Bug other/39062] libssp/ssp.c needs malloc.h for mingw
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 15:49 --- http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00636.html -- nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-14 15:51 --- Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1 > There is > > pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1 > > PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by revision 144857. > Does revision 144857 fix this bug? It's a possibility. I've started some builds. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug target/39397] libiberty/pex-*, inconsistent/incorrect pid_t usage
--- Comment #3 from nightstrike at gmail dot com 2009-03-14 15:52 --- http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00634.html -- nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot ||com, ktietz at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39397
[Bug target/39066] DO_GLOBAL_CTORS_BODY needs uintptr_t
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 15:54 --- http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00641.html -- nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
[Bug target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t
--- Comment #5 from nightstrike at gmail dot com 2009-03-14 15:57 --- http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00640.html -- nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug target/39063] libgcc2.c:mprotect() for mingw, incompatible pointer type warning
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 16:00 --- http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00639.html -- nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-14 16:15 --- Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1 > The ICE doesn't occur if I replace parser.o. I messed up in testing the above. The problem is actually in libcpp/expr.o. The ICE doesn't occur with stage1-libcpp. It also doesn't occur if I replace libcpp/expr.o with the stage1 version. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug middle-end/39460] strange aliasing warnings compiling pymol under gcc 4.4
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-03-14 16:24 --- Thanks. One last question. Is the presence of the 'does break' warning from tree-ssa-structalias.c considered to be more likely to indicate actual code breakage than the 'will break' warning from c-common.c? I was puzzled by the change in verbiage in the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39460
[Bug target/39461] New: [4.3] ICE in output_460, at config/rs6000/rs6000.md:11495
[forwarded from https://launchpad.net/bugs/342335 seen with 4.3 20090313, not seen on the trunk, not seen with -O1, or -O2 -fno-optimize-sibling-calls. $ g++-4.3 -c -g -pthread -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -fPIC qstring-minimal.ii tools/qstring-minimal.cpp: In function 'int qFindString(const QChar*, int, int, const QChar*, int, Qt::CaseSensitivity)': tools/qstring-minimal.cpp:56: internal compiler error: in output_460, at config/rs6000/rs6000.md:11495 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3] ICE in output_460, at config/rs6000/rs6000.md:11495 Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39461
[Bug target/39461] [4.3] ICE in output_460, at config/rs6000/rs6000.md:11495
--- Comment #1 from doko at ubuntu dot com 2009-03-14 16:54 --- Created an attachment (id=17464) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17464&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39461
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |ayers at gcc dot gnu dot org |org | Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #9 from ayers at gcc dot gnu dot org 2009-03-14 17:05 --- Fixed for 4.4.0 -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug objc/27377] [4.2/4.3/4.4 Regression] false compiler warnings generated in Objective-C code
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug objc/27377] [4.2/4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-14 17:11 --- Created an attachment (id=17465) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17465&action=view) patch for build_conditional_expr This patch for build_conditional_expr is modeled after build_binary_op in that it skips the diagnostic if the objc_compare_types verifies that the types are compatible. If the maintainers wish, I can follow up with a little optimization for the C front end for both build_conditional_expr and build_binary_op in that objc_compare_types will only be called for c_dialect_objc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug middle-end/39460] strange aliasing warnings compiling pymol under gcc 4.4
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-03-14 17:15 --- In 4.5 this warning indicates that the load/store will be simply eliminated. For 4.4 a miscompilation is less likely. Note that this warning is designed to have zero false positives (so either you discovered a wrong-code bug in the compiler or your code). This also means that a lot of cases may not be warned that in the end result in a miscompilation. The change in the wording was also done to distinguish the origins of the warning, but indeed it is absolutely sure that there is something wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39460
[Bug c++/39462] New: check assert() at compile time if possible
I have a lot of cases where it would be possible (more or less trivial, depending on the situation/code) to check if an assert() would fail at compile time. In such cases, I would want that GCC gives a warning (or an error). I understand that it's not possible to catch all cases but on such cases where it is easy for GCC to do such a check, I would like that GCC does it and reports it if it would fail. For the warning itself: The warning should point out the line where the problem is really caused (or all lines which could cause that problem). E.g., if I have an inline function where the assert depends on the function argument, I would like to get the line-nr where I call that function, not the line-nr of the assert() itself. (Just to avoid confusion: I am aware of static asserts but these are different things and not an option in most cases where I use assert(). Also, I don't want to make things harder for myself to figure out always when I can use an static assert and when not. And anyway, there are still a lot of trivial cases where a static assert is not possible but it would be still trivial for the compiler to see that it would fail.) -- Summary: check assert() at compile time if possible Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ich at az2000 dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug target/39461] ICE in output_460, at config/rs6000/rs6000.md:11495
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-14 17:20 --- Is this a dup of PR39175? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3] ICE in output_460, at |ICE in output_460, at |config/rs6000/rs6000.md:1149|config/rs6000/rs6000.md:1149 |5 |5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39461
[Bug target/34299] [avr] ICE on function attribute syntax for main()
-- aesok at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aesok at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug c++/39462] check assert() at compile time if possible
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-14 17:33 ---
You should be able to do this already with something like
void do_the_warning (void) __attribute__((warning("assertion always false")));
#define assert(X) \
if (__builtin_constant_p (X) \
&& !(X)) \
do_the_warning (); \
if (!(X)) abort ();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug target/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7
--- Comment #4 from vapier at gentoo dot org 2009-03-14 18:48 --- i think this is a dupe of PR35964 ... and that bug indicates that this is a regression from gcc-4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209
[Bug c++/39462] check assert() at compile time if possible
--- Comment #2 from ich at az2000 dot de 2009-03-14 19:48 --- Really thanks a lot for that hint. I did a small assert-implementation by my own: http://openlierox.svn.sourceforge.net/viewvc/openlierox/include/cassert?view=markup Btw., it seems that Apples GCC (even 4.2) does not support that attribute. Any alternative? But I guess you (GCC devs) are not responsible for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug c++/39462] check assert() at compile time if possible
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-14 20:25 --- The attribute is new in GCC 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug c++/39463] New: The type a std::vector cannot work with classes with the protected copy-constructors
The type a std::vector cannot work with classes with the protected
copy-constructors.
class A{
public:
explicit A(const A&){};
};
std::vector v;
A a;
v.push_back(a); // an error
Copy protection deleting solves a question.
class B{
public:
B(const B&){};
};
std::vector w;
B b;
w.push_back(b); // good
What is the matter?
--
Summary: The type a std::vector cannot work with classes with the
protected copy-constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lisp2d at lisp2d dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39463
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
--- Comment #6 from rogerpack2005 at gmail dot com 2009-03-14 21:14 --- anybody know if this bug is related to this post? http://www.gamedev.net/community/forums/topic.asp?topic_id=482230 Thanks! -=roger -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-14 21:31 --- Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1 On Tue, 10 Mar 2009, jakub at gcc dot gnu dot org wrote: > You can start with trying if -O2 -fno-inline -fno-inline-small-functions is > still miscompiled and if -O0 works, then you can add > __attribute__((__optimized__([02]))) to suspected functions. -O2 -fno-inline -fno-inline-small-functions and -O0 both work. However, I couldn't get the attribute to work, or find any documentation for it. I did find that the ICE doesn't occur with the following change to libcpp/expr.c: Index: expr.c === --- expr.c (revision 144529) +++ expr.c (working copy) @@ -39,7 +39,7 @@ /* Some simple utility routines on double integers. */ #define num_zerop(num) ((num.low | num.high) == 0) #define num_eq(num1, num2) (num1.low == num2.low && num1.high == num2.high) -static bool num_positive (cpp_num, size_t); +static bool num_positive (cpp_num, size_t) __attribute__((noinline)); static bool num_greater_eq (cpp_num, cpp_num, size_t); static cpp_num num_trim (cpp_num, size_t); static cpp_num num_part_mul (cpp_num_part, cpp_num_part); So, it seems quite likely that this is a shift issue. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug middle-end/39460] strange aliasing warnings compiling pymol under gcc 4.4
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-03-14
22:50 ---
Interestingly the suggestion in Comment 6 introduces the new warning...
endianswap.h: In function 'swap4_aligned':
endianswap.h:113: warning: pointer targets in initialization differ in
signedness
endianswap.h: In function 'swap8_aligned':
endianswap.h:130: warning: pointer targets in initialization differ in
signedness
which I am able to suppress with the change...
--- endianswap.h.org2009-03-14 18:40:23.0 -0400
+++ endianswap.h2009-03-14 18:40:59.0 -0400
@@ -110,7 +110,7 @@
/* Only works with aligned 4-byte quantities, will cause a bus error */
/* on some platforms if used on unaligned data. */
static void swap4_aligned(void *v, long ndata) {
- my_aliased_int *data = (int *) v;
+ my_aliased_int *data = (my_aliased_int *) v;
long i;
my_aliased_int *N;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=39460
[Bug c++/39463] The type a std::vector cannot work with classes with the protected copy-constructors
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-14 23:36 --- According to the current C++ Standard, elements of std::vector must be CopyConstructible (20.1.3) and such a type cannot have an explicit copy constructor. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39463
[Bug c++/39462] check assert() at compile time if possible
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-14 23:41 --- Also - I admit not having studied in detail all your requirements, sorry about that - I suppose you would be interested in static_assert, available with -std=c++0x, in gcc4.3.x (and 4.4.x, of course): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug c++/39462] check assert() at compile time if possible
--- Comment #5 from ich at az2000 dot de 2009-03-15 00:10 --- (In reply to comment #4) > Also - I admit not having studied in detail all your requirements, sorry about > that - I suppose you would be interested in static_assert, available with > -std=c++0x, in gcc4.3.x (and 4.4.x, of course): > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html > Thanks, but static_assert is not an option. It would make things only more complicated and can not cover a lot of cases. I also don't really understand why there is something like a static_assert (I am not sure how much I really would use an assert outside of a function). If a compiler would be intelligent enough to check asserts at compile time if possible, to differ between static_assert and assert only makes it more complicated - mostly for the programmer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug c++/39462] check assert() at compile time if possible
--- Comment #6 from paolo dot carlini at oracle dot com 2009-03-15 00:31 --- Hey, no problem really, just wanted to let you aware that the next Standard will deliver an assert checked at compile time. In general, if you want something special for the next releases of the C++ Standard, I would suggest making sure people in the appropriate places hear your voice. In general, we (GCC Project) are mostly interested in features already standardized or designed with that in mind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug libstdc++/39405] [4.3 regression] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts
--- Comment #25 from paolo at gcc dot gnu dot org 2009-03-15 00:44 --- Subject: Bug 39405 Author: paolo Date: Sun Mar 15 00:43:46 2009 New Revision: 144867 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144867 Log: 2009-03-14 Paolo Carlini PR libstdc++/39405 * include/std/type_traits (__add_lvalue_reference_helper, __add_rvalue_reference_helper): Avoid is_function. * testsuite/20_util/shared_ptr/cons/39405.cc: New. * testsuite/tr1/2_general_utilities/shared_ptr/cons/39405.cc: Likewise. Added: branches/gcc-4_3-branch/libstdc++-v3/testsuite/20_util/shared_ptr/cons/39405.cc branches/gcc-4_3-branch/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/39405.cc Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/include/std/type_traits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
[Bug c++/39462] check assert() at compile time if possible
--- Comment #7 from ich at az2000 dot de 2009-03-15 00:58 --- Hm yea, I thought already about that. But I cannot think of a good (and easy) definition when an assert() should be checked at compile time and whether not. And thus, I am not sure if that is something which belongs into the C++ standard itself. That is why I thought it would be the best to let the compiler do such a check if possible (and that pretty much depends on the cleverness of the compiler) and to just accept the situation that there could be cases where the value could be known in theory already at compile time but the compiler doesn't catch that. static asserts are different again (and I don't think there are of no use). There is a common intersection between what I want and what static asserts would offer but this intersection is small and they will not really solve the issue that it would be still very nice if the compiler could check asserts at compile time if possible (and in that case, I think that static asserts are only of little use; but it's of course hard to tell that, also because if not all compiler supports compile-time checks on asserts, a lot of people will use static asserts as a semi-alternative). But I could also just be wrong with these thoughts. I am not really into the GCC development and even after about 5 years of C++ development, I still see more and more new and different ways of doing stuff in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
[Bug libstdc++/39405] [4.3 regression] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts
--- Comment #26 from paolo dot carlini at oracle dot com 2009-03-15 00:54 --- This specific issue is fixed in 4_3-branch. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #9 from jason at gcc dot gnu dot org 2009-03-15 01:45 --- I was planning to wait until 4.4 branches. If you'd rather have it in 4.4, I can commit it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #10 from paolo dot carlini at oracle dot com 2009-03-15 02:07 --- (In reply to comment #9) > I was planning to wait until 4.4 branches. If you'd rather have it in 4.4, I > can commit it now. Well, if you ask me, yes, I would like to see it in 4.4. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-15 02:22 --- Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1 > --- Comment #16 from hjl dot tools at gmail dot com 2009-03-14 15:01 > --- > There is > > pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1 > > PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by revision 144857. > Does revision 144857 fix this bug? No. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug bootstrap/33200] install fails when trying to install fix-header since fix-header wasn't built
--- Comment #8 from vapier at gentoo dot org 2009-03-15 05:27 --- this has been fixed for gcc-4.4 ... time to close the bug ? http://gcc.gnu.org/viewcvs?view=rev&revision=136783 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200
