[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335 --- Comment #15 from Jason Merrill --- On 11/28/19 12:58 PM, jakub at gcc dot gnu.org wrote: > Now, the issues: > 1) (so far ignored); the standard says that classes where all virtual members > are immediate are still polymorphic, > but I

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 --- Comment #17 from Jason Merrill --- On Wed, Jan 31, 2018 at 9:45 PM, msebor at gcc dot gnu.org wrote: > Jason, I'm only starting to look into it but if I understand your suggestion > correctly, I don't think the bug

[Bug c++/79583] ICE (internal compiler error) upon instantiation of class template with `auto` template parameter containing inner class template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79583 --- Comment #6 from Jason Merrill --- FAIL: g++.dg/cpp0x/pr79583.C -std=c++1z (test for errors, line 3) On Thu, May 25, 2017 at 5:33 AM, paolo at gcc dot gnu.org wrote: >

[Bug c++/68782] [6 regression] bad reference member formed with constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68782 --- Comment #3 from Jason Merrill --- On 12/14/2015 01:45 PM, jakub at gcc dot gnu.org wrote: > I think the problem is constexpr.c creates invalid trees, in particular > CONSTRUCTORs that have non-TREE_CONSTANT elements, yet they have

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071 --- Comment #7 from Jason Merrill jason at redhat dot com --- On 08/14/2014 07:13 PM, Jan Hubicka wrote: On 08/14/2014 02:10 PM, Jan Hubicka wrote: I wonder what we should do with both external and comdat here. Jason, can we devirtualize

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071 --- Comment #5 from Jason Merrill jason at redhat dot com --- On 08/14/2014 02:10 PM, Jan Hubicka wrote: I wonder what we should do with both external and comdat here. Jason, can we devirtualize? No, we're setting comdat now to avoid

[Bug c++/54161] sizeof(void) expressions are accepted

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161 --- Comment #5 from Jason Merrill jason at redhat dot com 2012-08-03 14:19:58 UTC --- Makes sense to me. Jason

[Bug c++/53792] [C++11][constexpr] improving compiler-time constexpr evaluation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53792 --- Comment #5 from Jason Merrill jason at redhat dot com 2012-07-27 15:06:31 UTC --- On 07/27/2012 06:47 AM, vincenzo.innocente at cern dot ch wrote: is __attribute__((always_inline)) not making foo to transform in foo2 in a very early

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761 --- Comment #4 from Jason Merrill jason at redhat dot com 2012-01-05 14:03:22 UTC --- OK. Jason

[Bug debug/51262] [4.7 Regression] ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51262 --- Comment #4 from Jason Merrill jason at redhat dot com 2011-12-09 03:25:17 UTC --- On 12/08/2011 11:46 AM, rguenth at gcc dot gnu.org wrote: Dodji, Jason, can such anonymous name types ever have TYPE_DECL_ALIAS_P set? They can't

[Bug c++/51107] [C++11] Accepts invalid literal operator with void argument list.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51107 --- Comment #2 from Jason Merrill jason at redhat dot com 2011-11-12 20:54:02 UTC --- On 11/12/2011 02:10 PM, 3dw4rd at verizon dot net wrote: But is there a test for when you're looking at a template specialization

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976 --- Comment #18 from Jason Merrill jason at redhat dot com 2011-11-10 19:07:44 UTC --- On 11/10/2011 10:53 AM, 3dw4rd at verizon dot net wrote: Potentail patch #2a. + t = TREE_VALUE (argtype); + if (!argtype

[Bug c++/50810] c++0x-compat does not warn about narrowing conversions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50810 --- Comment #9 from Jason Merrill jason at redhat dot com 2011-10-23 02:06:56 UTC --- I think that makes sense, yes. People can always specify -Wno-narrowing if they don't want it. paolo.carlini at oracle dot com gcc-bugzi...@gcc.gnu.org wrote

[Bug c++/38174] Missing some built-in candidates for operator overloading

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38174 --- Comment #6 from Jason Merrill jason at redhat dot com 2011-10-13 14:27:12 UTC --- Just use composite_pointer_type. :) Jason

[Bug libstdc++/45228] [C++0x] Can't copy-construct tupleint,int,int from const tupleint,int,int rvalue

--- Comment #3 from jason at redhat dot com 2010-08-09 13:22 --- Subject: Re: [C++0x] Can't copy-construct tupleint,int,int from const tupleint,int,int rvalue For tuple_m, you have a variadic template constructor that can take *any* arguments whatsoever, and will therefore

[Bug libstdc++/45228] [C++0x] Can't copy-construct tupleint,int,int from const tupleint,int,int rvalue

--- Comment #5 from jason at redhat dot com 2010-08-09 13:38 --- Subject: Re: [C++0x] Can't copy-construct tupleint,int,int from const tupleint,int,int rvalue On 08/09/2010 09:31 AM, paolo dot carlini at oracle dot com wrote: I'm also thinking that the weird constructor tuple

[Bug c++/44969] [C++0x] type_traits std::is_constructible broken for fundamental types.

--- Comment #7 from jason at redhat dot com 2010-07-18 22:33 --- Subject: Re: [C++0x] type_traits std::is_constructible broken for fundamental types. On 07/17/2010 03:14 PM, paolo dot carlini at oracle dot com wrote: I attached a draft which fixes the original testcase as a SFINAE

[Bug c++/44969] [C++0x] type_traits std::is_constructible broken for fundamental types.

--- Comment #5 from jason at redhat dot com 2010-07-17 20:53 --- Subject: Re: [C++0x] type_traits std::is_constructible broken for fundamental types. irrespective of complain. Jason, should complete_type_or_else be something different when tf_none? Perhaps, but we shouldn't

[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions

--- Comment #12 from jason at redhat dot com 2010-04-03 21:12 --- Subject: Re: [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions On 04/03/2010 05:10 PM, rguenther at suse dot de wrote: But the initial patch also regresses g++.dg/opt/inline8.C

[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions

--- Comment #4 from jason at redhat dot com 2010-04-01 15:55 --- Subject: Re: [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions On 04/01/2010 09:39 AM, rguenth at gcc dot gnu dot org wrote: The issue seems to be the C++ frontend marking inline functions

[Bug c++/28584] Cast to pointer from integer of different size

--- Comment #3 from jason at redhat dot com 2010-02-20 20:15 --- Subject: Re: Cast to pointer from integer of different size On 02/20/2010 01:19 PM, manu at gcc dot gnu dot org wrote: Jason, do we want this? Sure. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28584

[Bug c++/35669] NULL (__null) not considered different from 0 with C++

--- Comment #25 from jason at redhat dot com 2010-02-16 18:43 --- Subject: Re: NULL (__null) not considered different from 0 with C++ On 02/16/2010 01:27 PM, manu at gcc dot gnu dot org wrote: I guess you mean Wconversion-null instead of Wconversion-nul. Fine. OK with that change

[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function

--- Comment #18 from jason at redhat dot com 2010-01-12 19:45 --- Subject: Re: [4.5 Regression] ICE with pointer-to-member-function argument in template function On 01/10/2010 06:42 PM, hubicka at gcc dot gnu dot org wrote: In general I am not sure plan of doing all datastructure

[Bug c++/42033] libstdc++ seems to miss std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_stringchar*(char*, char*, std::allocatorchar const)

--- Comment #8 from jason at redhat dot com 2009-11-13 23:18 --- Subject: Re: libstdc++ seems to miss std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_stringchar*(char*, char*, std::allocatorchar const) On 11/13/2009 04:16 PM, hubicka at ucw dot cz wrote: I

[Bug c++/28293] ICE on invalid typedef

--- Comment #6 from jason at redhat dot com 2009-09-09 21:52 --- Subject: Re: ICE on invalid typedef On 09/09/2009 12:25 PM, paolo dot carlini at oracle dot com wrote: Jason, any chance you can have a look to the old patch of mine for this PR? The patch is OK. Jason -- http

[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc

--- Comment #16 from jason at redhat dot com 2009-08-28 13:03 --- Subject: Re: FAIL: ext/pb_ds/regression/hash_data_map_rand.cc On 08/28/2009 06:59 AM, rguenth at gcc dot gnu dot org wrote: Jason - might there be any reason this is not correct? Looks fine to me. -- http

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

--- Comment #10 from jason at redhat dot com 2009-08-05 13:42 --- Subject: Re: Error message about no matching function for call with derived class arguments could be improved On 08/04/2009 06:42 PM, manu at gcc dot gnu dot org wrote: I don't even know if we have different codepaths

[Bug c++/40357] [4.5 Regression] compiler hang for C++ code

--- Comment #6 from jason at redhat dot com 2009-07-15 07:51 --- Subject: Re: [4.5 Regression] compiler hang for C++ code On 07/15/2009 09:44 AM, dcb314 at hotmail dot com wrote: I tried the code on snapshot 20090709 and it still hangs. The patch wasn't in that snapshot; it wasn't

[Bug c++/40595] [C++0x] ICE trying to use sfinae with variadic template pack expansion

--- Comment #8 from jason at redhat dot com 2009-07-01 20:01 --- Subject: Re: [C++0x] ICE trying to use sfinae with variadic template pack expansion On 07/01/2009 06:53 AM, mikpe at it dot uu dot se wrote: Is this an inherent limitation in 4.3 or just another unfixed bug? I'm

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

--- Comment #6 from jason at redhat dot com 2009-06-18 16:26 --- Subject: Re: [c++0x] rvalue-references no longer bind to lvalues On 06/18/2009 11:39 AM, jwakely dot gcc at gmail dot com wrote: Yes, I was just pointing out that the WP currently doesn't have the changes to std

[Bug c++/40389] optimizer bug (possibly)

--- Comment #23 from jason at redhat dot com 2009-06-14 15:39 --- Subject: Re: optimizer bug (possibly) On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote: * gimple.c (walk_stmt_load_store_addr_ops): The LHS of a call has its address taken if NRV

[Bug c++/40389] optimizer bug (possibly)

--- Comment #24 from jason at redhat dot com 2009-06-14 15:40 --- Subject: Re: optimizer bug (possibly) On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote: (handle_rhs_call): Use it to mark the return slot escaped if it is addressable and NRV was applied

[Bug c++/40389] optimizer bug (possibly)

--- Comment #17 from jason at redhat dot com 2009-06-12 17:30 --- Subject: Re: optimizer bug (possibly) On 06/10/2009 05:27 PM, jakub at gcc dot gnu dot org wrote: Yes, as I said earlier, I think we should handle D.2249 = baz (); [return slot optimization] as taking address of D

[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248

--- Comment #4 from jason at redhat dot com 2009-04-14 14:07 --- Subject: Re: [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248 I wonder if it only works on 4.4 because tree checking is disabled on release branches. Jason

[Bug c++/25185] deep typedef substitution in error message

--- Comment #30 from jason at redhat dot com 2009-04-09 02:10 --- Subject: Re: deep typedef substitution in error message dave at boost-consulting dot com wrote: I can't see why you wouldn't use -fno-deep-typedef-substitution. Because that isn't at all what the option controls. We

[Bug c++/25185] deep typedef substitution in error message

--- Comment #24 from jason at redhat dot com 2009-04-06 15:32 --- Subject: Re: deep typedef substitution in error message dave at boostpro dot com wrote: I'm confused as to why you think you need to give a still-dependent type in the signature Because the signature we're printing

[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions

--- Comment #13 from jason at redhat dot com 2009-04-06 15:39 --- Subject: Re: C++ ABI needs clarification on mangling of complex expressions hjl dot tools at gmail dot com wrote: /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry, unimplemented: mangling

[Bug c++/25185] deep typedef substitution in error message

--- Comment #21 from jason at redhat dot com 2009-04-04 03:45 --- Subject: Re: deep typedef substitution in error message dave at boostpro dot com wrote: Well, I find that a little confusing. Why is it explaining to me what typename boost::result_ofCalcSize()::type is? I

[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

--- Comment #5 from jason at redhat dot com 2009-03-10 16:41 --- Subject: Re: [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die jakub at gcc dot gnu dot org wrote: What's the point in generating the DIE in gen_tagged_type_instantiation_die? It seems

[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const

--- Comment #6 from jason at redhat dot com 2009-03-03 13:08 --- Subject: Re: T const assumed to be compatible with int (A::*) (void) const paolo dot carlini at oracle dot com wrote: it seems real strange to me that we cannot implement anymore the is_member_pointer trait

[Bug c++/25185] deep typedef substitution in error message

--- Comment #10 from jason at redhat dot com 2009-03-02 20:35 --- Subject: Re: deep typedef substitution in error message dave at boost-consulting dot com wrote: Please assume I know what I'm asking for and stop turning it into a different problem. I know what you're asking for. I

[Bug c++/25185] deep typedef substitution in error message

--- Comment #11 from jason at redhat dot com 2009-03-02 20:43 --- Subject: Re: deep typedef substitution in error message jason at redhat dot com wrote: I figured you could apply the patch, rebuild GCC and see if the output was more to your liking. But I suppose it's easier

[Bug c++/39095] [4.4 Regression] Mangling changes break ABI

--- Comment #4 from jason at redhat dot com 2009-02-04 15:57 --- Subject: Re: [4.4 Regression] Mangling changes break ABI OK. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39095

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

--- Comment #7 from jason at redhat dot com 2009-01-28 16:29 --- Subject: Re: [4.4 Regression] g++.dg/init/const7.C XFAILed rguenther at suse dot de wrote: Why do it in the FE? This seems like a language-independent optimization. Do it in the FE if the FE wants it to be optimized

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

--- Comment #5 from jason at redhat dot com 2009-01-27 23:25 --- Subject: Re: [4.4 Regression] g++.dg/init/const7.C XFAILed rguenth at gcc dot gnu dot org wrote: I just found this, I tried to fix this in fold but in the end agreed with Andrew that the C++ FE should do what the C FE

[Bug c++/38577] [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000

--- Comment #9 from jason at redhat dot com 2008-12-19 17:28 --- Subject: Re: [4.4 Regression] ICE: tree check: expected call_expr, have compound_expr in build_new_method_call, at cp/call.c:6000 jakub at gcc dot gnu dot org wrote: Another alternative would be not to create

[Bug c++/36410] [4.2/4.3 Regression] ICE with transparent union

--- Comment #8 from jason at redhat dot com 2008-11-25 17:35 --- Subject: Re: [4.2/4.3 Regression] ICE with transparent union rguenth at gcc dot gnu dot org wrote: IMHO a backport is not needed for error-recovery bugs. This is not an error-recovery bug, the patch makes us accept

[Bug libstdc++/25191] exception_defines.h #defines try/catch

--- Comment #73 from jason at redhat dot com 2008-11-23 00:02 --- Subject: Re: exception_defines.h #defines try/catch pinskia at gcc dot gnu dot org wrote: I think this patch will not handle: int main(void) { try { }catch (int a) { a = 1; } } Ah yes, I probably

[Bug libstdc++/25191] exception_defines.h #defines try/catch

--- Comment #65 from jason at redhat dot com 2008-11-20 15:14 --- Subject: Re: exception_defines.h #defines try/catch No, it doesn't make any sense to use try/catch in a program that you're planning to build with -fno-exceptions. It does, however, make sense to use try/catch

[Bug libstdc++/25191] exception_defines.h #defines try/catch

--- Comment #68 from jason at redhat dot com 2008-11-20 18:10 --- Subject: Re: exception_defines.h #defines try/catch mmitchel at gcc dot gnu dot org wrote: If I recall correctly, unwinding into a frame with no EH data will cause a runtime abort, so programs will not silently skip

[Bug c++/34269] [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted

--- Comment #5 from jason at redhat dot com 2008-11-11 17:45 --- Subject: Re: [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted jakub at gcc dot gnu dot org wrote: Another possibility would be add support for queing error messages during tentative parsing

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

--- Comment #13 from jason at redhat dot com 2008-10-20 19:01 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always Could you (Dodji) try building libstdc++ with -femit-class-debug-always, and see how much it affects the size

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

--- Comment #14 from jason at redhat dot com 2008-10-20 19:02 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always Building Firefox or OpenOffice with/without the flag would also be a good test. Jason -- http://gcc.gnu.org

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

--- Comment #4 from jason at redhat dot com 2008-10-17 15:18 --- Subject: Re: DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine These bits should not be generated: 28c: Abbrev Number: 8 (DW_TAG_lexical_block) 38d: Abbrev Number: 8

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

--- Comment #2 from jason at redhat dot com 2008-10-16 18:22 --- Subject: Re: DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine xuepeng dot guo at intel dot com wrote: Hello Jason, I posted the whole debug_info section of of the binary file of your

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

--- Comment #10 from jason at redhat dot com 2008-10-16 18:40 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always mark at codesourcery dot com wrote: The library is provided to us in binary form and stripped, and if it does have

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

--- Comment #8 from jason at redhat dot com 2008-10-15 22:23 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always mmitchel at gcc dot gnu dot org wrote: /* Make sure we didn't eliminate casted types because we thought they were

[Bug libstdc++/37718] Demangling of variadic functions

--- Comment #1 from jason at redhat dot com 2008-10-03 02:27 --- Subject: Re: New: Demangling of variadic functions I've been working on a bunch of mangling/demangling issues lately, this among them. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718

[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block

--- Comment #6 from jason at redhat dot com 2008-10-01 18:01 --- Subject: Re: DW_TAG_imported_module is not in its DW_TAG_lexical_block Please send patches to gcc-patches for review (and CC me) rather than attaching them to the PR. (It would be nice if a bot would notice relevant

[Bug libstdc++/25191] exception_defines.h #defines try/catch

--- Comment #60 from jason at redhat dot com 2008-09-26 21:57 --- Subject: Re: exception_defines.h #defines try/catch l dot lunak at suse dot cz wrote: But only in your perfect world. This bug and its silent discarding of exception handling code (and an unintended -fno-exception

[Bug libstdc++/25191] exception_defines.h #defines try/catch

--- Comment #58 from jason at redhat dot com 2008-09-24 19:21 --- Subject: Re: exception_defines.h #defines try/catch l dot lunak at suse dot cz wrote: --- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 --- (In reply to comment #55) It seems reasonable to me

[Bug tree-optimization/37568] [4.4 regression] ICE returning a struct

--- Comment #2 from jason at redhat dot com 2008-09-19 18:14 --- Subject: Re: [4.4 regression] ICE returning a struct jakub at gcc dot gnu dot org wrote: IMHO either we relax the checking, allowing DECL_INITIAL to be error_mark_node even for !TREE_STATIC, or finalize_nrv_r would

[Bug c++/35782] support for standard layout types

--- Comment #5 from jason at redhat dot com 2008-09-10 03:37 --- Subject: Re: support for standard layout types bkoz at gcc dot gnu dot org wrote: Specifically the qualities that I am looking for are: 1) be able to inherit from C POD and be standard layout 2) be able to have

[Bug c++/36944] [4.4 Regression]: Revision 138123 breaks constructors with default arguments

--- Comment #7 from jason at redhat dot com 2008-07-26 21:41 --- Subject: Re: [4.4 Regression]: Revision 138123 breaks C++ hjl dot tools at gmail dot com wrote: + if (skip_artificial_parms_for (fn, DECL_ARGUMENTS (fn)) + == NULL_TREE) + return true

[Bug c++/33486] namespace association doesn't handle parallel namespaces

--- Comment #8 from jason at redhat dot com 2008-04-07 17:29 --- Subject: Re: namespace association doesn't handle parallel namespaces bkoz at gcc dot gnu dot org wrote: Hey Jason, can we get this fixed on 4_3-branch? (Could probably get away with just gcc/cp/name-lookup.c fix

[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates

--- Comment #12 from jason at redhat dot com 2008-04-04 18:10 --- Subject: Re: [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates jakub at gcc dot gnu dot org wrote: Actually, to clarify #c10, attributes on parameter packs just make things harder

[Bug c++/33911] attribute deprecated vs. templates

--- Comment #3 from jason at redhat dot com 2008-01-04 22:23 --- Subject: Re: attribute deprecated vs. templates niemayer at isg dot de wrote: I can second that problem for template member functions - in contrast to non-template member functions, where the attribute works

[Bug c++/5305] wrong constructor called -- default argument in constructor not seen

--- Comment #7 from jason at redhat dot com 2007-09-24 17:05 --- Subject: Re: wrong constructor called -- default argument in constructor not seen rguenth at gcc dot gnu dot org wrote: Looks like non-regression wrong-code bugs get no attention :/ Actually, I've fixed several

[Bug c++/33342] [4.3 Regression] ICE in dependent_type_p, at cp/pt.c:15081

--- Comment #4 from jason at redhat dot com 2007-09-08 03:52 --- Subject: Re: [4.3 Regression] ICE in dependent_type_p, at cp/pt.c:15081 This patch seems to fix the bug, but I haven't had a chance to regression test it or reduce the testcase, and may not get a chance for a bit

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

--- Comment #17 from jason at redhat dot com 2007-04-15 19:01 --- Subject: Re: C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL) hhinnant at apple dot com wrote: This makes clean up / rethrow during cancellation

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

--- Comment #15 from jason at redhat dot com 2007-04-13 20:13 --- Subject: Re: C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL) Howard's example seems to me like an argument for not necessarily using thread

[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol

--- Comment #39 from jason at redhat dot com 2006-12-06 19:14 --- Subject: Re: Can't use __attribute__ ((visibility (hidden))) to hide a symbol mmitchel at gcc dot gnu dot org wrote: Jason, are you actively working on this? (We are motivated to fix the problem, so if you're

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

--- Comment #19 from jason at redhat dot com 2006-11-15 02:07 --- Subject: Re: [4.1 regression] ICE in extract_insn, at recog.c:2084 OK, now I've really reverted the patch. Silly svn resolved... Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825

[Bug target/29009] [4.2 Regression] ice in kernel build

--- Comment #5 from jason at redhat dot com 2006-09-10 22:46 --- Subject: Re: [4.2 Regression] ice in kernel build This will be fixed by H.J.'s patch to always use the larger stack alignment. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29009

[Bug c++/27371] [4.1 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))

--- Comment #8 from jason at redhat dot com 2006-09-07 22:50 --- Subject: Re: [4.1 Regression] Does not warn about unused function result (__attribute__((warn_unused_result))) Whoops, I checked the patch in disabled. Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371

[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces

--- Comment #10 from jason at redhat dot com 2006-09-07 00:14 --- Subject: Re: [4.2 Regression] libstdc++ vs. anonymous namespaces bkoz at gcc dot gnu dot org wrote: This is precisely one reason why anonymous namespaces are useful. It provides a very viceral way to sanity check

[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot

--- Comment #8 from jason at redhat dot com 2006-08-21 22:04 --- Subject: Re: [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot I think this patch fixes the bug, but don't have time to test before going out for the evening. Index: decl2.c

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

--- Comment #11 from jason at redhat dot com 2006-08-01 07:10 --- Subject: Re: C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL) drow at gcc dot gnu dot org wrote: Just making sure I understand - catch (...) { foo

[Bug c++/28438] Anon namespace pointers in exported classes

--- Comment #2 from jason at redhat dot com 2006-07-19 20:02 --- Subject: Re: New: Anon namespace pointers in exported classes Yes, this is an ODR violation. However, the patch I'm working on will allow it to compile (as a side effect of other desired changes). Jason -- http

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static

--- Comment #17 from jason at redhat dot com 2006-07-17 15:10 --- Subject: Re: [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static Agreed; if we try to explicitly force a load of a volatile non-POD we should call force_rvalue on it. Jason -- http

[Bug c++/28407] [4.2 regression] Issue with anonymous namespace

--- Comment #3 from jason at redhat dot com 2006-07-17 19:53 --- Subject: Re: [4.2 regression] Issue with anonymous namespace gdr at integrable-solutions dot net wrote: I have always warned people that the unnamed namespace transformation to static should happen in the *back-end

[Bug c++/28407] [4.2 regression] Issue with anonymous namespace

--- Comment #5 from jason at redhat dot com 2006-07-17 20:08 --- Subject: Re: [4.2 regression] Issue with anonymous namespace Or globalize_decl could just do nothing if the assembler name contains a reference to the anonymous namespace. -- http://gcc.gnu.org/bugzilla

[Bug c++/10591] use ODR rules to make C++ objects not be TREE_PUBLIC

--- Comment #20 from jason at redhat dot com 2006-03-21 19:19 --- Subject: Re: use ODR rules to make C++ objects not be TREE_PUBLIC Sorry I wasn't clear; I agree that this is an important bug. I meant that fixing the unique anonymous namespace name in the presence of PCH

[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code

--- Comment #23 from jason at redhat dot com 2006-02-12 07:58 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE on throw code I think I have a better patch that I'll check in soon. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996

[Bug libstdc++/24660] versioning weak symbols in libstdc++

--- Comment #13 from jason at redhat dot com 2005-11-17 22:39 --- Subject: Re: versioning weak symbols in libstdc++ I think nesting _6 within std makes sense in the abstract as well, as it is properly part of the standard library space, not a separate entity. The debug mode headers

[Bug c++/21764] visibility attributes on namespace scope

--- Comment #8 from jason at redhat dot com 2005-11-18 06:15 --- Subject: Re: visibility attributes on namespace scope bkoz at gcc dot gnu dot org wrote: What do you mean, less or equal visibility to their enclosing scope? Where default protected hidden internal, if a class

[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly

--- Comment #42 from jason at redhat dot com 2005-10-04 21:05 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly mark at codesourcery dot com wrote: So, I guess maybe we agree on the right plan. In particular: 1. When we see T* or T, use

[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly

--- Additional Comments From jason at redhat dot com 2005-09-29 17:19 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly mark at codesourcery dot com wrote: What I meant by lying (an admittedly overly contentious choice of word

[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly

--- Additional Comments From jason at redhat dot com 2005-09-28 19:39 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly mmitchel at gcc dot gnu dot org wrote: I think this is a hack so that later, when we use the COMPONENT_REFs, we don't

[Bug c++/16782] Accepts qualified member function declaration in class

--- Additional Comments From jason at redhat dot com 2005-09-15 14:23 --- Subject: Re: Accepts qualified member function declaration in class I wouldn't mind turning this diagnostic on by default as a pedwarn. As usual, people who want their code to build anyway can use

[Bug c++/16782] Accepts qualified member function declaration in class

--- Additional Comments From jason at redhat dot com 2005-09-15 17:50 --- Subject: Re: Accepts qualified member function declaration in class dank at kegel dot com wrote: gcc-4.1 had a stated goal of giving every warning a name, and letting them be turned on and off individually

[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot

--- Additional Comments From jason at redhat dot com 2005-05-18 21:17 --- Subject: Re: [4.1 Regression] removing a temporary return value when we cannot On 18 May 2005 20:45:22 -, bernie at develer dot com [EMAIL PROTECTED] wrote: My backtrace looks suspiciously similar

[Bug c++/21603] C++ front-end accepts new with VLAs

--- Additional Comments From jason at redhat dot com 2005-05-16 20:28 --- Subject: Re: New: C++ front-end accepts new with VLAs On 16 May 2005 02:16:51 -, mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] wrote: Steve Adamczyk has indicated that he feels that permitting dynamic

[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads

--- Additional Comments From jason at redhat dot com 2005-04-18 18:28 --- Subject: Re: local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads On 18 Apr 2005 09:07:00 -, adah at netstd dot com [EMAIL

[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads

--- Additional Comments From jason at redhat dot com 2005-04-14 07:38 --- Subject: Re: local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads DCL with explicit memory barriers is safe. That's what I'm

[Bug c++/20949] [4.0/4.1 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...

--- Additional Comments From jason at redhat dot com 2005-04-12 07:00 --- Subject: Re: [4.0/4.1 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ... On 11 Apr 2005 22:38:59 -, pluto at pld-linux dot org [EMAIL PROTECTED] wrote: What kind of debug info do

[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot

--- Additional Comments From jason at redhat dot com 2005-04-11 07:49 --- Subject: Re: [4.1 Regression] removing a temporary return value when we cannot Have you tested the 4.0 branch with the temporary fix I applied? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317

[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot

--- Additional Comments From jason at redhat dot com 2005-04-11 12:48 --- Subject: Re: [4.1 Regression] removing a temporary return value when we cannot On 11 Apr 2005 08:59:58 -, pluto at pld-linux dot org [EMAIL PROTECTED] wrote: Have you tested the 4.0 branch

[Bug c++/19317] [4.0/4.1 Regression] removing a temporary return value when we cannot

--- Additional Comments From jason at redhat dot com 2005-03-18 00:34 --- Subject: Re: [4.0/4.1 Regression] removing a temporary return value when we cannot This hack should work around the bug, pending a better fix. *** calls.c.~1~ 2005-02-01 10:53:24.0 -0500 --- calls.c

[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368

--- Additional Comments From jason at redhat dot com 2005-03-08 06:47 --- Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs On Thu, 03 Mar 2005 23:26:04 -0800, Mark Mitchell [EMAIL PROTECTED] wrote: Your reading is logical, but it depends on exactly what

  1   2   >