[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://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[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*, not in the front-end using language rules, because the > language rules are slightly different in those cases. I don't remember ever seeing you mention that before, but it does seem like an interesting idea. Your comments in the PRs talk about not changing the C++ linkage (which we obviously shouldn't), but not about where to implement it. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[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/show_bug.cgi?id=28407
[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 and at cp_parser_commit_to_tentative_parse emit them. This seems right to me. It's even what the comment at the top of the file says we do: Then, while we attempt to parse the construct, the parser queues up error messages, rather than issuing them immediately, and saves the tokens it consumes. If the construct is parsed successfully, the parser "commits", i.e., it issues any queued error messages and the tokens that were being preserved are permanently discarded. The simulate_error business only works for parse errors that indicate that this line of parsing won't work; it doesn't work for code that parses fine, but violates semantic rules and therefore needs an error. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[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 in a general purpose library that you want to work with exceptions enabled or disabled, such as libstdc++. I believe Lubos is arguing that such libraries ought to use preprocessor tricks to accomplish this, but defining something like __try and __catch instead of try and catch. The difference between this approach and my patch is that it requires the library writer to jump through hoops to make their code work with exceptions enabled and disabled. I guess Lubos thinks this is good, that this is an unusual thing to want to do and so people that want to do it need to be very explicit about it so that people who don't want that but mistakenly build their code with -fno-exceptions get an error rather than a warning. Anyone else have an opinion about this? And yes, -Wexceptions is on by default in my patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[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 catch clauses that have been > compiled away. The program may fail, but at least it will not do so > silently. > Jason, is that correct? Yes. If the unwinder runs out of unwind info before it finds a handler, we call terminate(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[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 still need to push the declaration of a.
> I am working on a patch which adds -fignore-exceptions which has to be used
> with -fno-exceptions which handles this correctly.
This sounds like the wrong approach to me. libstdc++ needs to work with
or without -fno-exceptions, it shouldn't require another flag. And I
don't see the point in allowing 'throw expr;' under -fno-exceptions; I
don't think the compiler can come up with another error reporting
mechanism by itself.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[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 it.
That said, it's probably simpler to fix your code: changing
typedef union
{
int i;
} B __attribute__((transparent_union));
typedef union
{
int i;
} __attribute__((transparent_union)) B;
will work with 4.3.2. So yeah, no backport seems needed.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[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 the COMPOUND_EXPR or NOP_EXPR > if (processing_template_decl) at all, but for the destructor cast to void > that would mean the type wouldn't be void during template processing. Before > the PR37540 patch the CALL_EXPR would have void_type_node, which is wrong, but > leaving the type non-void would be IMHO worse. This patch is OK if it passes testing. But it makes me wonder if we're handling decltype of the COMPOUND_EXPR case properly. The destructor issue makes me wish again that ARM hadn't decided to mess with the ABI. Sigh. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38577
[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 does here. Why do it in the FE? This seems like a language-independent optimization. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
[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 to a constant. > Otherwise sure - it is a language-independent optimization. But fold > isn't a proper optimizer ;) I don't understand the distinction you're making; it seems to me that reducing expressions to simpler forms that are more easily optimized is exactly what fold is for. I don't see the difference between this and, say, reducing "1 + 2" to "3". The FE doesn't especially want this to be a constant; it isn't a valid constant expression in C++, because it involves a subtraction of two pointers. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
[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.2249, at least if it has TREE_ADDRESSABLE type. No; it should only do this if 'this' escapes from a constructor for the type, as in this testcase when it's passed to bar. This should be a small subset of TREE_ADDRESSABLE types. Your reduced testcase removes the copy constructor entirely, which makes the program incorrect; my earlier suggestion was to just remove its body, which would produce a link error if it's invoked (as it shouldn't, as we elide the copy) rather than invalid code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[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 was applied and it is addressable. This should check TREE_ADDRESSABLE on the type rather than the variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[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. Here too, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[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::forward and std::move - I don't know why, or what the final versions > might > look like. Because there were strong objections to those changes at the meeting. People have been working on a different solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[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 not planning to fix C++0x bugs in 4.3. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40595
[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 applied until 20090714. > By the way, how can a fix for a crash also fix a hang ? > I would have thought the two were mutually exclusive. A correction for the internal representation can fix any manner of failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40357
[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 for those! We do: if there's a conversion that seems likely but invalid, we build it up but set bad_p on it so that we can give a more helpful diagnostic when we try to use it. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979
[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 will need to be modified to work with this new requirement by moving __gnu_debug_def into std as well. Do you plan to version the debug mode containers, too? I don't think there's much compression to be done once you start inserting arbitrary namespaces. Just compressing the NTBS "basic_string" doesn't get you much to compensate for the added complexity. You might as well attach the tarball to the PR for posterity. I'm particularly interested in the discussions you mention about the relative merits of nesting or not. I note that the documentation of the feature uses a nested implementation namespace, so that seems to be what I had in mind... Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[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 or namespace has a specified visibility, nested scopes should have the same visibility or something later in the above sequence. > My meta-goal is to try and give namespace and class scope visibilty attributes > similar meanings. Do you think this is worthwhile, possible, and do you think > this is a good idea? Yes, guess I should have said that before nitpicking the examples. > Yeah, maybe default namespace with hidden nested makes more sense for the > examples. However, wouldn't both have to be supported, anyway? Both would be supported by the simplest implementation, though we could enforce rules like the above if we wanted to. Mostly I was just puzzled that the examples in both PRs seemed inside out, and wondered if I was missing some compelling use case. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[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://gcc.gnu.org/bugzilla/show_bug.cgi?id=28438
[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(); throw; } will no
> longer call foo during forced unwinding, only destructors and explicit
> forced unwinding catches will be called?
Yes. I should clarify that I'm just implementing all the different
options, in hopes that helps to move the discussion along.
> [What does this imply for throw()?]
throw() will always block unwinding. For that case "sticky"
cancellation works better. But I don't think that's actually an issue
for iostreams, is it?
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[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
===
*** decl2.c (revision 116310)
--- decl2.c (working copy)
*** min_vis_r (tree *tp, int *walk_subtrees,
*** 1547,1553
}
else if (CLASS_TYPE_P (*tp))
{
! if (!TREE_PUBLIC (TYPE_MAIN_DECL (*tp)))
{
*vis_p = VISIBILITY_ANON;
return *tp;
--- 1547,1553
}
else if (CLASS_TYPE_P (*tp))
{
! if (!TREE_PUBLIC (TYPE_NAME (*tp)))
{
*vis_p = VISIBILITY_ANON;
return *tp;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[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 an API. Make sure that the private parts > really are private, say. Yes, but there's a difference between private and internal. This is especially problematic for templates; if you give template instantiations internal linkage, we can't share them between translation units anymore and you get code bloat. Do you really want a copy of the list of primes from the hashtable policy code in each translation unit that uses it? It seems to me that Rope_constants, _Private in and the hashtable policy stuff were in special namespaces just to avoid name lookup pollution. If you really want them also to be unique to each translation unit you could insert an anonymous namespace inside the preexisting namespace and not have to mess with name lookup at all. I thought after my earlier comments you would put Rope_constants back, but now that I actually look at what you checked in I see that you just added explicit global scope to the uses. That kind of cluttering up of the global namespace seems like a mistake to me; _Tag isn't a very unique name. Changing _Private to an anonymous namespace has the same problem, except it's only cluttering up tr1 instead of the global namespace. In both cases inserting an anonymous namespace inside the named namespace seems both better and less work. > Please, let's leave out of it. You reported a problem compiling , it's hard to respond without talking about . > I think that there are good reasons to use anonymous namespaces in headers, > even if you disagree with these designs personally. Please elaborate. Why do you want _Tag, _Select, X::primes, etc. to be unique to each translation unit? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[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 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 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 cancellation to abort a task, but not for discarding the cancel
request entirely. A cancellation request is asking for a thread to go
away; if you want to send a different message use a different mechanism.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[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 awkward. Code would have to
> check for two (or more) different kinds of cancellation: Am I executing in an
> OS thread, or in a thread pool?
Well, yes. The mechanism for pthread_cancel won't necessarily work with
other forms of cancellation.
Doing clean up in a catch(...) block has always been inelegant, a
destructor will be more reliable. I don't understand why we aren't
adding finally in this round of standardization...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[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.
Index: pt.c
===
*** pt.c(revision 128240)
--- pt.c(working copy)
*** most_specialized_class (tree type, tree
*** 13646,13651
--- 13646,13653
{
int i;
+ ++processing_template_decl;
+
/* Discard the outer levels of args, and then substitute in the
template args from the enclosing class. */
partial_spec_args = INNERMOST_TEMPLATE_ARGS (partial_spec_args);
*** most_specialized_class (tree type, tree
*** 13661,13666
--- 13663,13670
for (i = TREE_VEC_LENGTH (parms) - 1; i >= 0; --i)
TREE_VEC_ELT (parms, i) =
tsubst (TREE_VEC_ELT (parms, i), outer_args, tf_none, NULL_TREE);
+
+ --processing_template_decl;
}
spec_args = get_class_bindings (parms,
partial_spec_args,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33342
[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 of those in the past few weeks. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5305
[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 "lvalue for a > bit-field" means. (Note that it does not say "lvalue *is* a bit-field"; it > says "lvalue *for* a bit-field".) In fact, there's a core issue for exactly that question; Steve's proposed wording clarifies that these expressions are lvalues for a bit-field. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[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 2005-03-17 19:33:38.931587705 -0500
*** expand_call (tree exp, rtx target, int i
*** 1994,2001
--- 1994,2003
structure_value_addr = expand_expr (return_arg, NULL_RTX,
VOIDmode, EXPAND_NORMAL);
}
+ #if 0
else if (target && MEM_P (target))
structure_value_addr = XEXP (target, 0);
+ #endif
else
{
/* For variable-sized objects, we must be called with a target
--
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 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 with the temporary fix I applied? > > I applied a temporary fix and Dirk's hack to get konqueror working but > misscompilation still exists. My patch fixes all the reduced testcases in this PR. If KDE is still broken, I think that's a separate bug and needs testcases. Can you submit another PR? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[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 You need? tree-dumps for -O0/1? We need reduced testcases that reproduce the bug(s). Preprocessed source for objects that are being miscompiled and a note showing the miscompilation on the tree dump would also work. Basically, we need to know what's going wrong before we can figure out why. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[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 using. But don't take my word for it, see the "DCL is Broken" Declaration: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html Scroll down to "Making it work with explicit memory barriers". The fast path does not use a lock. There, the only overhead compared to the old code is a function call and a read/read hoist memory barrier on targets where the memory barrier is necessary; targets that do not reorder loads have no overhead at all. It is impossible for users to implement this protection as efficiently as the compiler can. The C++ committee is working on improving thread support in C++; when this particular topic came up the other day, there was general support for having the compiler guarantee that the initialization be threadsafe, though possibly with a keyword to either enable or disable this guarantee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[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 PROTECTED]> wrote: > I would like that > > * GCC provide extensions so that GCC users can use memory barriers and > threading calls in a platform-independent way, and I'd like that too. > - Provide a command-line option (or pragma/attribute?) to disable/enable > static initialization protection. Already there: -fno-threadsafe-statics. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[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 deleted ctor/copy ctor and be standard layout > 3) able to do aggregate init when 1, 2 You can't have 2 and 3 under the current working paper. http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#845 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35782
[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 need to clear DECL_INITIAL. > I don't know what consequences the latter might have though. There is a general convention that DECL_INITIAL of error_mark_node means "this is initialized by other code". But that doesn't seem to apply to automatic variables; changing finalize_nrv_r to clear DECL_INITIAL instead of setting it to error_mark_node shouldn't break anything. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37568
[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 for try { X } catch... to mean X when
>> -fno-exceptions. We don't need to error except on throw.
>
> It seems unreasonable to me that gcc would silently modify code's behaviour,
The change I was talking about doesn't modify behavior. If there are no
exceptions, catch blocks will never be executed, so we can optimize them
away in the presence of -fno-exceptions.
> This program, IIRC, is guaranteed to call "f", as a side-effect of the
> presence of the catch-clause? Of course, the C++ FE could still process
> the "catch" clause; my only point is that we cannot literally just throw
> away the catch clause.
True, it would be more like { X } if (0) ...
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[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 from the build system) made us > release a broken package. -fno-exceptions is a big hammer. It will break exceptions trying to pass through code compiled with that flag whether or not that code has any try/catch constructs. If you might have some code that throws, you shouldn't use -fno-exceptions; that's what broke your package. Getting an error on try would have helped you find that problem, but that doesn't mean it's the right answer for all situations; if I'm writing code that may be used by other programs, I should write it to be exception-safe even if I don't throw any exceptions myself. Perhaps we could just warn once if we see try/catch outside library headers with -fno-exceptions. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[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 subject lines on gcc-patches and add a link to the PR like we do for checkins). I wouldn't limit the new IMPORTED_DECL to importing namespaces; as a backend tree code it should support importing other declarations as well even though C++ doesn't allow that usage. That is, the comment in tree.def and the name of IMPORTED_DECL_NS_DECL should be more general, and the assert in dwarf2out that the imported decl is a namespace should either go away or get a comment that a language that wants to use it for other types of decl should make sure it works properly. > + /* Get the innermost inclosing GIMPLE_BIND that has a non NULL > + BLOCK, and append an IMPORTED_DECL not to its > + BLOCK_VARS chained list. */ "not"? > --- a/gcc/cp/name-lookup.c > +++ b/gcc/cp/name-lookup.c > @@ -3493,11 +3493,6 @@ do_using_directive (tree name_space) >if (current_namespace != global_namespace) > context = current_namespace; > } > - > - /* Emit debugging info. */ > - if (!processing_template_decl) > -(*debug_hooks->imported_module_or_decl) (name_space, NULL_TREE, > - context, false); > } Seems like this will break debug info for namespace-scope using-directives. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[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/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 > >unused. */ Yes, my point was that the reason we omit the debug info in this case is not that we think the type is unused, it's that even though we know it is used, we expect it to be emitted elsewhere. > But, I think it's odd if I'm in the debugger, looking at code that says: > > return (X*)y; > > if I can't say "print (X*)y". > > If the type is coming from a library, we may not ever create objects of this > type. If the Xes are created in the library, the library should have the debug info we need. I can't imagine a use for a statement like that in a program that doesn't have a definition of the vtable for X. If no X has ever been created, then doing anything interesting with the X* will have undefined behavior, because it couldn't possibly point to an X. > Finally, we use vast amounts of space in object files for debug info, since we > emit the same debug info in multiple object files. Trying to optimize by not > emitting debug info in this case doesn't seem likely to be a big win given our > overall strategy. I don't have any data to support that claim, though. I'm not sure what overall strategy you mean. We try to avoid emitting the same info in multiple places when possible: we try to treat the debug info for classes as another vague linkage entity and put it with the vtable. Unfortunately, it isn't yet possible to use linkonce for debug info because of GDB limitations, so our opportunities for optimization are limited. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[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 example as below. I guess you mean that DW_TAG_lexical_block tags like
> those at <8c> and <8d> are unnecessary. We should avoid generating them if
> they
> contain nothing. Am I right?
No; they aren't empty, they contain a couple of variables. But they
come from an inlined function ("third"), and we shouldn't represent
inlined functions in the debug info for the abstract instance of an
inline function.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801
[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 debug info it might not have come from GCC. But, if it's > declared in a header, we can still provide debug info. In which case we need to specify -femit-class-debug-always, yes. > OK, my statement was overly strong. I was thinking particularly of C++ > templates, where the vague linkage strategy makes for lots of copies, > both in the object files, and, because we don't use COMDAT, in the final > binaries. In that kind of C++ code, this optimization doesn't save a > significant percentage of space. I wouldn't expect it to make a big difference with heavily templated code, no. It seems to me that you're arguing that -femit-class-debug-always should go back to being on by default; its only effect is to control this exact optimization. But the documentation says -- This option should be used only with debuggers that are unable to handle the way GCC normally emits debugging information for classes because using this option will increase the size of debugging information by as much as a factor of two. -- Does anyone have some recent numbers? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[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: <2><8c>: Abbrev Number: 8 (DW_TAG_lexical_block) <3><8d>: Abbrev Number: 8 (DW_TAG_lexical_block) <4><8e>: Abbrev Number: 9 (DW_TAG_variable) <8f> DW_AT_abstract_origin: <0x46> <4><93>: Abbrev Number: 9 (DW_TAG_variable) <94> DW_AT_abstract_origin: <0x51> <2>: Abbrev Number: 8 (DW_TAG_lexical_block) <3>: Abbrev Number: 8 (DW_TAG_lexical_block) <4>: Abbrev Number: 9 (DW_TAG_variable) DW_AT_abstract_origin: <0x81> <4>: Abbrev Number: 8 (DW_TAG_lexical_block) <5>: Abbrev Number: 8 (DW_TAG_lexical_block) <6>: Abbrev Number: 9 (DW_TAG_variable) DW_AT_abstract_origin: <0x46> <6>: Abbrev Number: 9 (DW_TAG_variable) DW_AT_abstract_origin: <0x51> Basically, when we're generating the debug info for the abstract instance of an inline function we shouldn't emit any information about other inline functions, as it would be redundant. We shouldn't see any DW_AT_abstract_origin attributes inside a DW_TAG_subprogram with DW_AT_inline set. Incidentally, it seems that we're also emitting these unnecessary DW_TAG_lexical_block inside the concrete instances (DW_TAG_inlined_subroutine): For instance, <3><1a5>: Abbrev Number: 14 (DW_TAG_lexical_block) <1a6> DW_AT_low_pc : 0x40046f <1ae> DW_AT_high_pc : 0x400479 should be dropped, and <4><1b6>: Abbrev Number: 9 (DW_TAG_variable) <1b7> DW_AT_abstract_origin: <0x81> should be at level 3, directly under the DW_TAG_inlined_subroutine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801
[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 of the library? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[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/bugzilla/show_bug.cgi?id=33429
[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 on the compiler side, but even in C++98 the same issue is present:
> #define vector __attribute__((__vector_size__ (16)))
>
> template void foo (int x, vector T y) { }
> void bar (vector long a, vector double b)
> {
> foo (5, a);
> foo (5, b);
> }
This functionality seems desirable, but cannot be considered a regression.
> Are there any attributes other than vector_size which affect the decls
> similarly?
I don't think so.
> If not, I'd say that the C++ FE should hardcode some knowledge about this
> attribute, e.g. know that it applies to the type, so if
> processing_template_decl
> move them from DECL_ATTRIBUTES to corresponding type's TYPE_ATTRIBUTES (either
> the parameter type such that it would be in TYPE_ARG_TYPES too, or for
> FUNCTION_TYPE/METHOD_TYPE stick it into return type's TYPE_ATTRIBUTES).
> And in type_unification_real take it into account.
This makes sense to me. Though I think that if we just push the
attribute down to the type that it actually modifies, we don't have to
think about TYPE_ARG_TYPES. That should also avoid the need for
reconstruct_complex_type.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[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, no?) Yes, only the name-lookup.c change would be necessary. But I'm not the one to ask about fixing it on the 4.3 branch; poke the release managers for permission. It should be quite safe. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
[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++/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 was explaining what GCC is doing that is giving you something other than what you want. It isn't that GCC is preserving typedefs, it's that GCC is dumping the signature of the template rather than the instantiation. > Go back and look at the original report more closely, particularly > the part that discusses boost::result_of::type. That comes from here: typedef range< Elements , Begin , End , typename result_of::type > type; template type operator()( L const& m , B const& b , E const& e , C const& s ) const That's what GCC is printing out. And then it gives the arguments for all the template parameters. To resolve the typename above GCC would have to print the instantiated signature, which it currently doesn't do. > And lastly, I don't know GCC internals, so I'm unable to interpret the result > of your proposed fix (of a problem I'm not having). I figured you could apply the patch, rebuild GCC and see if the output was more to your liking. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[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 to just show you the output: ../../../../boost/sequence/make_range.hpp:60: instantiated from ‘boost::sequence::range_::range > boost::sequence::detail::range_maker, boost::array > >::operator()(const boost::sequence::identity_property_map&, char* const&, char* const&, const boost::sequence::detail::size_difference, const boost::array >&) const [instantiated from boost::sequence::range_::range::type> boost::sequence::detail::range_maker::operator()(const L&, const B&, const E&, const C&) const with L = boost::sequence::identity_property_map, B = char*, E = char*, C = boost::sequence::detail::size_difference, const boost::array >, Elements = boost::sequence::identity_property_map, Begin = char*, End = char*, CalcSize = boost::sequence::detail::size_difference, boost::array >]’ compared to ../../../../boost/sequence/make_range.hpp:60: instantiated from ‘boost::sequence::range_::range::type> boost::sequence::detail::range_maker::operator()(const L&, const B&, const E&, const C&) const [with L = boost::sequence::identity_property_map, B = char*, E = char*, C = boost::sequence::detail::size_difference, const boost::array >, Elements = boost::sequence::identity_property_map, Begin = char*, End = char*, CalcSize = boost::sequence::detail::size_difference, boost::array >]’ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[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 as an OR of the > is_member_object_pointer and the is_member_function_pointer traits. We can still implement it that way; that part of the patch is just an optimization. I'm can drop it if you prefer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[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 to be for generating the DIE to represent the type definition in a concrete instance of an inline function. I don't know why it would be called multiple times, since it's only called when we process the stub TYPE_DECL; calling gen_decl_die multiple times for that seems surprising. But as you say, there doesn't seem to be any point in emitting such a DIE at all, since the variables will already have a type in the abstract instance. > I'd like to question if gen_tagged_type_instantiation_die shouldn't be nuked > instead. Go ahead. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[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_of::type
>
> is? I don't see that type anywhere else in there.
A bug that I've already fixed.
> Also, I'm not thrilled that
>
> boost::sequence::detail::range_maker::type
>
> is still present in the signature, even if it's explained below.
> Carried to an extreme, you get EDG's nasty nested
>
> ={...={...={...}}}
>
> type descriptions. Do you need to do that? Why not just spell out the
> return type?
Because that's the return type specified in the declaration. The
alternative would be for it to say
boost::sequence::range_::range::type>
like it used to; do you prefer that? It seemed to me that we might as
well just print the typedef in the signature and give the fully
instantiated type in the bindings list rather than give a
still-dependent type in the signature and explain any component
typenames in the bindings list, but I don't feel strongly about that.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[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 is the signature of the template, not the specialization. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[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 template_id_expr > > Is this expected? That is in fact still unimplemented, and a good reason not to close the PR. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926
[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 strip typedefs from template arguments regardless of this flag. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[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 guess for the ABI we don't want a vtable pointer there. So, I > think we want TYPE_POLYMORPHIC_P set on > those, but e.g. TYPE_CONTAINS_VPTR_P probably shouldn't be true for them; > do we want TYPE_REALLY_POLYMORPHIC_P or > similar for polymorphic types that contain at least one non-immediate > virtual function and thus need a vtable? We still need a vtable for typeinfo, so I think we don't need to worry about this. > 2) initially I thought I'd just always emit a direct call to the immediate > virtual method found by lookup and do the remapping of that during constexpr > call evaluation; unfortunately as the > v->S::bar () etc. calls show, we only want to do that if LOOKUP_NONVIRTUAL > wasn't set; unfortunately, when immediate > functions aren't in the binfo structures, DECL_VINDEX is error_mark_node and > so I think we need some hack how to > preserve the info that we are going to call a virtual consteval method; could > we e.g. abuse OBJ_TYPE_REF with > different arguments that would make it clear it is something different, or > new tree? We need to store the instance > on which it is called and the virtual consteval method originally chosen e.g. > to compare the type > 3) I'm afraid one can't use a lookup_member on the actual instance type, > because it could find all kinds of things, > static member functions, typedefs, data members etc. in derived classes, > where we actually are only interested in > in virtual methods. So, shall we use something like look_for_overrides > does, except with the fndecl from the > base rather than derived and of course don't do anything except return > the first found method (and ignore static member > functions rather than handling them)? Would it work to include them at the end of BINFO_VIRTUALS but omit them in build_vtbl_initializer? > 4) guess covariant returns need to be handled at the end too somehow Yep. Jason
[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://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[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://gcc.gnu.org/bugzilla/show_bug.cgi?id=28293
[Bug c++/42033] libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
--- Comment #8 from jason at redhat dot com 2009-11-13 23:18 --- Subject: Re: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) On 11/13/2009 04:16 PM, hubicka at ucw dot cz wrote: > I am confused why I get link error given that even my *.a exports the > symbol... Yeah, sounds more like a linker issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
[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 2011-10-13 14:27:12 UTC --- Just use composite_pointer_type. :) Jason
[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 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" wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50810 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot | |com | --- Comment #8 from Paolo Carlini 2011-10-23 00:36:25 UTC --- I have the patch essentially ready. My only remaining doubt is that currently -Wc++0x-compat is part of -Wall, and -Wnarrowing would become also part of -Wall. Are we sure about this?
[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 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) > + return false; If argtype is null, taking its TREE_VALUE will SEGV. You can also check argtype == void_list_node to test for the end of the parameter list. 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 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 compiler's stage? Fairly early, but not as early as constant expression folding. Jason
[Bug c++/54161] sizeof(void) expressions are accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54161 --- Comment #5 from Jason Merrill 2012-08-03 14:19:58 UTC --- Makes sense to me. Jason
[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 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? DECL_TEMPLATE_SPECIALIZATION (current_function_decl) 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 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, but > - else if (CLASS_TYPE_P (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t))) > + else if (CLASS_TYPE_P (t) > + && TYPE_NAME (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t))) > return CLASSTYPE_TEMPLATE_INSTANTIATION (t) > && PRIMARY_TEMPLATE_P (CLASSTYPE_TI_TEMPLATE (t)); I would reverse the sense here so that the condition is satisfied by a null TYPE_NAME, since an anonymous union is a non-alias class. Jason
[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 2012-01-05 14:03:22 UTC --- OK. Jason
[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 can be fixed by relying on attribute > exclusions. > > Based on the test cases alone (I haven't yet stepped through the code) the > underlying problem seems to be that explicit specializations "inherit" > attributes from their primary template rather than starting with a clean > slate. Often that will be correct; I don't think we want to require people to repeat all attributes on every explicit specialization. The problem here is that there's a conflicting attribute on the specialization, and we want that to win, so I'm suggesting that when we see that, we go through and remove conflicting attributes which came from the template.
[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 -fpermissive. I'm strongly opposed to adding a flag for this diagnostic; I don't want to use warning flags for things that make the code technically ill-formed. I'm not particularly sympathetic to Dan's desire to be able to make GCC exactly as pedantic as EDG. If you don't want to deal with all the warnings from -pedantic, you can also filter them out with grep. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[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. > Jason, are you also opposed to that feature of gcc-4.1? No. The difference is that this diagnostic should really be an error, we're just making it a pedwarn to allow noncompliant code to build when it's clear what it means. But I suppose if people want to be able to turn pedwarns on and off individually under the same scheme, I can accept that. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[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 > have to cast from the as-base type back to the nominal C++ type. (Of course, > this would also be cleaner with a real C++-lowering pass.) > > However, I think the right thing is to have the cast; as you've discovered, > Jason's approach is lying about what's really there. Jason? My intent was to use COMPONENT_REFs where it's close enough to the truth, and casts where it isn't. The middle/back end produced significantly better code for COMPONENT_REFs than casts when I made the change, particularly with aliasing; I'm not sure if it's gotten any better since then. And besides, my approach isn't lying at all about this testcase; since there's only one appearance of the virtual base, it appears exactly where the field lists say it will. Daniel agreed that the problem is in his code. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[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) was that the field for B-in-C is marked as having the complete B > type due to the code at the end of layout_class_type. However, the A > virtual base isn't located in that B; it's located after the data > members of C. So, the base field for B is incorrect. Nah, "lying" is fair. If you lie to the compiler, it will have its revenge. > I agree that using COMPONENT_REFs is good, but I think that the > FIELD_DECL for B should have the as-base type. Then, when you actually > form the COMPONENT_REF, you should do the equivalent of: > > *(complete B*)&c.b_base > > That will give the expression the correct type from the front-end's > point of view, but not result in inaccuracy with respect to the > TYPE_FIELDS for C. Obviously, we need to make sure that B-as-base > complete-B are in the same alias set. The problem is that when you do that kind of type punning the optimizers get lost. > (It might be even better just to have the front end consider B-as-base > and complete-B as the same type, so that the expression could have the > more-accurate B-as-base type. But, that would be a huge change to the > front end, so I think we have no choice but to use the complete-B type > for an expression like "*(B*)&c".) I think it might actually work better to use the base type for most expressions, and only use the complete type when we know the complete type of the expression. Within the compiler, we ought to be able to express the complete type as a RECORD_TYPE containing fields of the as-base type and any vbases, so that the relationship between them is clear and we shouldn't need to do any ugly casting. Of course, this would also be a significant amount of work. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[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 the as-base version of T for the type. > Therefore, for expressions like "*p" where "p" has type "T*", we would > give the expression the as-base version of T. However, for expressions > like "t" (where "t" is of type "T"), use the complete version of "t". Yep. > 2. Undo your change at the end of layout_class_type, so that base fields > have the as-base type. Agreed. > We could implement (1) either by (a) doing that directly during parsing, > etc., or (b) by handling it during genericization/gimplification. I > vote for the latter. It should be relatively simple; do a pre-order > walk of the expression tree, and adjust the types of things from the > bottom up. > > I'm not sure what else we would need to do. We need to tell the > optimizers that the as-base type can alias the complete type; I guess we > just give them the same alias set. I was suggesting that instead of making the complete type and base type essentially copies of one another, that we make the complete type a wrapper around the base type. Proper alias semantics would fall out of that. > We also need the optimizers to > understand that "*p = *q" is going to copy TYPE_SIZE (complete type) > bytes... We don't do bitwise assignment if a class has a vptr, so whenever we generate something like that the complete type and base type should be the same. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[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: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79583 > > --- Comment #3 from paolo at gcc dot gnu.org --- > Author: paolo > Date: Thu May 25 09:32:46 2017 > New Revision: 248451 > > URL: https://gcc.gnu.org/viewcvs?rev=248451&root=gcc&view=rev > Log: > 2017-05-25 Paolo Carlini > > PR c++/79583 > * g++.dg/cpp0x/pr79583.C: New. > > Added: > trunk/gcc/testsuite/g++.dg/cpp0x/pr79583.C > Modified: > trunk/gcc/testsuite/ChangeLog > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[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. > Any suggestions to give better location information in this warning? I guess > the location of null_node is useless. No real suggestions; to avoid using input_location we'd need to track locations all the way through the overload resolution code. I wonder if in 4.6 we want to start wrapping uses of shared nodes such as null_node or decls in order to retain location information. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[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 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 needed > at cp/semantics.c:3452 while the middle-end should already take care > of that in cgraph_decide_is_function_needed. Another example of why I've been thinking about reworking all the C++ front end linkage code to play better with cgraph... > The following "fixes" it, but arguably the bug must then be latent > with dllexport. The patch looks OK since cgraph_decide_is_function_needed handles flag_keep_inline_functions. I'm not sure why doing this here would be a problem, however; mark_needed ends up calling cgraph_mark_needed_node, which really ought to be a reasonable way to indicate that a function is needed... Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
[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, as for > the inline function therein DECL_EXTERNAL is set and thus the > middle-end disregards it for its -fkeep-inline-functions processing. Ah, right. We can't leave it up to cgraph as long as the front end is still playing its DECL_NOT_REALLY_EXTERN games. So yeah, I guess your third patch is the best bet for now. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
[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 --- 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 devirtualization, because we can't be confident that we'll be able to refer to the definition where it gets emitted. > The constructor is keyed to other compilation unit here, but we are provided > with a body > that we will never use (modulo the tree-ssa-pre bug that brings the reference > into code). Hmm, we might consider overriding DECL_EXTERNAL so that there's a definition available for devirtualization. Jason
[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 --- 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? >> >> No, we're setting comdat now to avoid devirtualization, because we >> can't be confident that we'll be able to refer to the definition >> where it gets emitted. > > We had issues where function body was not produced because it is not reachable > by the frontend's definition and it would be comdat otherwise. The case of > inline function whose out of line body is keyed to another unit seems bit > different... It doesn't seem that different to me. In both cases we don't have a local definition to refer to. >>> The constructor is keyed to other compilation unit here, but we are >>> provided with a body >>> that we will never use (modulo the tree-ssa-pre bug that brings the >>> reference into code). >> >> Hmm, we might consider overriding DECL_EXTERNAL so that there's a >> definition available for devirtualization. > > I can always implement logic to use it only when it is inlined, but that will > probably drag > in references to other symbols belonging to the class... I'm not too concerned about that; users should expect an inline function to be inlined. Jason
[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 TREE_CONSTANT > set on them (and possibly also TREE_SIDE_EFFECTS similarly). Hmm, any element without TREE_CONSTANT should have caused us to return the original CONSTRUCTOR. > build_constructor with NULL vals creates TREE_CONSTANT and !TREE_SIDE_EFFECTS > CONSTRUCTOR, and constexpr.c later modifies the elts without updating those > flags. > > is untested fix that cures this testcase, but the cxx_eval_bare_aggregate > changes are incomplete, there are other ways how a new elt is stored too. Or > perhaps it could just in another loop go over all elements and compute those > flags. Jason, any thoughts on this? I thought there was already a function to recompute these flags, but I'm not finding it. Jason
[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/function call conventions changes via cloning is coolest idea. Well, just pretending that a particular parameter never existed isn't acceptable from a debugging standpoint; I think we need to have a separate modified decl which points back to the original unmodified decl with DECL_ABSTRACT_ORIGIN. Beyond that, it might be possible to avoid much copying by just moving the function body over from the original decl to the modified one. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug c++/44969] [C++0x] std::is_constructible broken for fundamental types.
--- Comment #5 from jason at redhat dot com 2010-07-17 20:53 --- Subject: Re: [C++0x] 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 be dealing with template parameters there anyway; they should have been substituted away by this point. I'm investigating. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
[Bug c++/44969] [C++0x] std::is_constructible broken for fundamental types.
--- Comment #7 from jason at redhat dot com 2010-07-18 22:33 --- Subject: Re: [C++0x] 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 issue. Seems > to me rather straightforward and consistent with existing practice in > typeck.c, > just passes down complain to build_x_compound_expr_from_list. Regtests fine. Looks good. I haven't tracked down the other issue yet. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue
--- Comment #3 from jason at redhat dot com 2010-08-09 13:22 --- Subject: Re: [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue For tuple_m, you have a variadic template constructor that can take *any* arguments whatsoever, and will therefore be a better match than anything that doesn't have a specific constructor. In this case, you're trying to create a tuple_m from a const tuple_m rvalue, and therefore the variadic template is instantiated to form tuple_m(const tuple_m&&), which is a better match than either tuple_m(const tuple_m&) or tuple_m(tuple_m&&). For tuple_2, the T&& constructor requires two arguments, so this isn't an issue. This is the same issue that we had with thread; I worked around that for the non-const lvalue case by adding thread(thread&) = delete, and you could do the same here by adding a const tuple_m&& overload. But in general, I think any time you have a variadic constructor that can take a single T&&, you probably want to use SFINAE to make sure that it isn't chosen for a single argument of the enclosing class type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45228
[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue
--- Comment #5 from jason at redhat dot com 2010-08-09 13:38 --- Subject: Re: [C++0x] Can't copy-construct "tuple" from "const tuple" 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(tuple<_UElements...>& > __in), > which has been suggested at the time by Peter Dimov, falls under the same > reasoning and should be removed, the actual issue sorted out elsewhere again > through SFINAE. Removed? To be clear, I was suggesting that you keep the constructor, just prevent it from being selected when the deduced parameter type is reference-related to the enclosing class. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45228
[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. This is a parser bug: parsing the member template declaration winds up in cp_parser_init_declarator, which ignores attributes at the end of a declaration. A normal member function goes through cp_parser_member_declaration, which handles the attributes properly. You can work around this bug by moving the attribute into the decl-specifier-seq, i.e. "void __attribute ((deprecated)) foo(T&)". Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
[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; > + args = FUNCTION_FIRST_USER_PARMTYPE (fn); > + while (args && TREE_PURPOSE (args)) > + args = TREE_CHAIN (args); > + if (!args || args == void_list_node) > + return true; > Is this correct? You don't need the first three lines quoted above; the new code you added is enough. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36944
[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 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 is the right way to fix it. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
[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 allocation > of > VLAs is a mistake, in that, for example, you can't easily use the pointer > outside the scope of the containing function, unless you somehow also > pass/save > the bounds. Makes sense to me. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21603
[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 to the backtrace reported in > comment #14. Yep, yours is probably the same bug as that in comment #14, which I don't think is related to the original bug report. 20949 was opened for that bug, then closed for lack of a testcase. > Reducing a testcase isn't trivial, but I'll try. Thanks. If you do come up with one, it probably makes the most sense to attach it to 20949 and reopen it. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/19148] [4.0 Regression] ICE: gimplification failed
--- Additional Comments From jason at redhat dot com 2004-12-24 20:32 --- Subject: Re: [4.0 Regression] ICE: gimplification failed On 24 Dec 2004 20:26:38 -, "mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> wrote: > Adding a post_p parameter to gimplify_cond_expr fixes the problem (and passing > it down to gimplify_expr) fixes the problem. > > Is there any reason that's not a bad idea? Makes sense to me. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19148
[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails
--- Additional Comments From jason at redhat dot com 2005-01-01 12:16 --- Subject: Re: [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails On 31 Dec 2004 22:46:37 -, "dberlin at gcc dot gnu dot org" <[EMAIL PROTECTED]> wrote: > When we inline a C++ constructor that isn't going to be output, we get the > following stuff: > > a block for the inlined constructor, with an abstract origin of: > a decl named __comp_ctor with an abstract origin of: > a decl named bad_typeid This sounds right. The inlined constructor is an instance of a clone of a constructor. > we call gen_inlined_subroutine_die on the block, which calls > block_ultimate_origin. > block_ultimate_origin returns *the __comp_ctor* decl. But this is wrong. It seems that block_ultimate_origin needs to follow DECL_ABSTRACT_ORIGIN, too. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17924
