On 9/6/24 11:19 AM, Patrick Palka wrote:
On Thu, 5 Sep 2024, Jason Merrill wrote:
On 9/5/24 2:28 PM, Patrick Palka wrote:
On Thu, 5 Sep 2024, Jason Merrill wrote:
On 9/5/24 1:26 PM, Patrick Palka wrote:
On Thu, 5 Sep 2024, Jason Merrill wrote:
On 9/5/24 10:54 AM, Patrick Palka wrote
On 9/6/24 8:56 AM, Jonathan Wakely wrote:
On 05/09/24 21:44 -0400, Jason Merrill wrote:
On 9/4/24 11:02 AM, Marek Polacek wrote:
+handle_flag_enum_attribute (tree *node, tree ARG_UNUSED(name), tree
args,
+ int ARG_UNUSED (flags), bool *no_add_attrs)
+{
+ if (args)
+ warning
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This test appeared to be passing, but only because the warning was
suppressed by #pragma system_header.
PR tree-optimization/107919
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wuninitialized-pr107919-1.C: Add -Wsystem-headers a
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We were silently accepting the pr65923.C specialization of std::swap with
the wrong exception specification; it should be declared noexcept. Let's
limit ignoring mismatch with system headers to extern "C" functions so we
get a diagnostic fo
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
Ever since the c_global and c_compatibility directories were added in
r122533, the include guards have been oddly late in the files, with no
comment about why that might be either in the commit message or the files
themselves. I don't see any ju
On 9/10/24 6:10 AM, Alex Coplan wrote:
On 27/08/2024 10:55, Alex Coplan wrote:
Hi,
This is a v3 that hopefully addresses the feedback from both Jason and
Jakub. v2 was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660191.html
Gentle ping on this C++ patch:
https://gcc.gn
On 8/29/24 12:23 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
Pre r14-4793, we'd call warn_tautological_cmp -> operand_equal_p
with operands wrapped in NON_DEPENDENT_EXPR, which works, since
o_e_p bails for codes it doesn't know. But now we p
On 8/29/24 4:15 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
OK.
-- >8 --
Here we wrongly mark the reference temporary for g TREE_READONLY,
so it's put in .rodata and so we can't modify its subobject even
when the subobject is marked mutable. Th
On 9/7/24 6:45 AM, Iain Sandoe wrote:
As noted in the PR the action of the existing implementation was to
treat a false value from await_suspend () as equivalent to "do not
suspend". Actually it needs to be the equivalent of "resume" - and
we need to restart the dispatcher - since the await_susp
On 9/6/24 2:38 PM, Jakub Jelinek wrote:
On Wed, Sep 04, 2024 at 10:31:48PM +0200, Franz Sirl wrote:
Hmm, it just occured to me, how about adding !NONVIRTUAL here? When
NONVIRTUAL is true, there is no conditional stmt at all, or?
Yeah, that makes sense, the problem doesn't happen in that case.
On 9/11/24 10:53 AM, Patrick Palka wrote:
On Wed, 11 Sep 2024, Patrick Palka wrote:
On Wed, 11 Sep 2024, Patrick Palka wrote:
On Wed, 4 Sep 2024, Marek Polacek wrote:
On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote:
On 9/3/24 6:12 PM, Marek Polacek wrote:
Bootstrapped
On 9/10/24 8:35 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/backports?
OK, though you might combine the new STMT_EXPR case with the existing
LAMBDA_EXPR case; the principle is the same for both.
-- >8 --
r8-7538 for PR84968 made s
On 9/11/24 12:54 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR points out the we're not implementing [dcl.fct.def.default]
properly. Consider e.g.
struct C {
C(const C&&) = default;
};
where we wrongly emit an error, but the
On 9/11/24 8:51 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
My last fix for this issue (PR c++/114947, r15-810) didn't go far
enough; I had assumed that the issue where we lost track of partial
specialisations we would need to walk
On 9/11/24 7:26 AM, Simon Martin wrote:
We currently ICE upon the following code while building the "[...] is
private within this context" error message
=== cut here ===
class A { enum Enum{}; };
template class Alloc>
class B : private Alloc, private A {};
template class Alloc>
int B::foo (Enum
On 9/11/24 4:36 PM, Marek Polacek wrote:
On Wed, Sep 11, 2024 at 11:26:56AM -0400, Jason Merrill wrote:
On 9/11/24 10:53 AM, Patrick Palka wrote:
On Wed, 11 Sep 2024, Patrick Palka wrote:
On Wed, 11 Sep 2024, Patrick Palka wrote:
On Wed, 4 Sep 2024, Marek Polacek wrote:
On Wed, Sep 04
On 9/11/24 4:08 PM, Marek Polacek wrote:
On Wed, Sep 11, 2024 at 01:19:53PM -0400, Jason Merrill wrote:
On 9/11/24 12:54 PM, Marek Polacek wrote:
+ auto_diagnostic_group d;
+ /* We used to emit a hard error, so this uses 0 rather than
+OPT_Wpedantic
On 9/12/24 10:23 AM, Marek Polacek wrote:
On Wed, Sep 11, 2024 at 11:26:35PM +0200, Jakub Jelinek wrote:
Hi!
On the following testcase, we emit false positive warnings/errors about using
the deprecated or unavailable methods when creating thunks for them, even
when nothing (in the testcase so f
On 9/12/24 7:23 AM, Simon Martin wrote:
Hi,
While looking at more open PRs, I have discovered that the problem
reported in PR109790 is very similar to that in PR100632, so I’m
combining both in a single patch attached here. The fix is similar to
the one I initially submitted, only more general
On 9/12/24 4:49 AM, Jonathan Wakely wrote:
Tested x86_64-linux. OK for trunk?
-- >8 --
The standard says that std::launder is ill-formed for function pointers
and cv void pointers, so there's no reason for __builtin_launder to
accept them. This change allows implementations of std::launder to d
Tested x86_64-pc-linux-gnu. Thoughts about the remaining warnings discussed
below? Any other comments?
-- 8< --
The use of #pragma GCC system_header in libstdc++ has led to bugs going
undetected for a while due to the silencing of compiler warnings that would
have revealed them promptly, and al
On 9/13/24 6:17 AM, Jakub Jelinek wrote:
Hi!
Another spot where we mark_used a function (in this case ctor or dtor)
even when it is just artificially used inside of thunks (emitted on mingw
with -Os for the testcase).
Bootstrapped/regtested on x86_64-linux and i686-linux and tested with
a cross
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
PR116696 expressed surprise that explicit 'constexpr' was needed on one
function; this was because the function isn't 'inline', and
-fimplicit-constexpr doesn't try to promote non-inline functions. Let's be
more helpful in that situation, a
On 9/12/24 3:12 PM, Marek Polacek wrote:
On Wed, Sep 11, 2024 at 10:25:34PM -0400, Jason Merrill wrote:
On 9/11/24 4:08 PM, Marek Polacek wrote:
@@ -6503,10 +6504,17 @@ check_bases_and_members (tree t)
bool fn_const_p = (copy == 2);
if (fn_const_p && !imp
On 9/13/24 1:31 PM, Simon Martin wrote:
We currently ICE upon the following testcase when using -ftime-report
=== cut here ===
template < int> using __conditional_t = int;
template < typename _Iter >
concept random_access_iterator = requires { new _Iter; };
template < typename _Iterator >
struct
Tested x86_64-pc-linux-gnu and armv8l-unknown-linuxgnueabihf, applying to
trunk.
-- 8< --
The Linaro CI runs of this testcase pointed out that I need to check for DFP
support, as well.
gcc/testsuite/ChangeLog:
* c-c++-common/pragma-diag-17.c: Handle !dfp targets.
---
gcc/testsuite/c-c+
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We don't want a warning about a reserved init_priority in a system header
even with -Wsystem-headers.
gcc/cp/ChangeLog:
* tree.cc (handle_init_priority_attribute): Check
in_system_header_at.
---
gcc/cp/tree.cc | 3 ++-
1 f
On 9/13/24 11:06 AM, Simon Martin wrote:
Hi Jason,
On 12 Sep 2024, at 16:48, Jason Merrill wrote:
On 9/12/24 7:23 AM, Simon Martin wrote:
Hi,
While looking at more open PRs, I have discovered that the problem
reported in PR109790 is very similar to that in PR100632, so I’m
combining both in
On 9/12/24 1:32 PM, Patrick Palka wrote:
On Mon, 12 Aug 2024, Seyed Sajad Kahani wrote:
When deducing auto for `adc_return_type`, `adc_variable_type`, and
`adc_decomp_type` contexts (at the usage time), we try to resolve the outermost
template arguments to be used for satisfaction. This is done
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
It seems more useful for a conversion to have the location of the source
expression rather than the enclosing expression, such as a call that might
convert multiple arguments in different ways.
As a result, in srcloc17.C the recorded locati
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When we're explicitly choosing GCC extensions, we similarly shouldn't
complain about optional features that GCC provides. This particular pattern
of cast between function and object pointer is used by gthr-posix.h on some
targets, including
OK.
Jason
On 08/22/2013 05:59 AM, Jan Hubicka wrote:
+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
+#define TYPE_FINAL_P(NODE) \
+ (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
How about if we put this flag on the BINFO rather than the type itself?
Jason
OK.
Jason
On 08/22/2013 12:05 PM, Paolo Carlini wrote:
Sorry if I'm saying something rather vague: I suppose you mean
BINFO_FLAG_6? Because it's the last one.
No, that's a language-specific flag.
Jason
On 08/22/2013 11:22 AM, Jan Hubicka wrote:
This option did not occured to me and of course I would be bit fearing of C++ FE
not having binfos ready all the time it wants to touch the type. But probably
you know if that can happen ;)
Classes (including struct and union) always have binfos.
Jas
On 08/23/2013 09:57 AM, Jan Hubicka wrote:
Ok, I will prepare variant using public_flag of BINFO that seeems unused.
I.e. having BINFO_FINAL_P and C++ specific macro
CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)).
Sounds good.
Jason
On 08/23/2013 10:51 AM, Jan Hubicka wrote:
Sadly we ICE here because BINFO of type is not built yet.
I tried to move the code after xref_binfos and it does seem to lead to errors
while building libstdc++ PCH. Any idea what to do here?
If it's causing trouble, let's just put the flag on the typ
On 08/24/2013 05:18 AM, Jan Hubicka wrote:
In the next step I would like to introduce the DECL_CPP_CONSTRUCTOR/DESTRUCTOR
macro.
The catch I run into is that these flags are tested on TEMPLATE_DECL so the
middle-end
macro bombs on type checking. I wonder what is best approach here.
I think f
OK.
Jason
On 08/22/2013 12:45 PM, Gabriel Dos Reis wrote:
If the user-supplied operator new returns &a, then it must
also ensure that 'a' is not used anywhere else -- e.g. I you can't
do lvalue-to-value conversion on 'a' to see what is written there.
Because its storage has been reused. That is, aliasing
On 08/26/2013 11:21 AM, Jan Hubicka wrote:
Our default behaviour special case inline functions that are always
AVAIL_AVAILABLE and, via decl_replaceable_p, also any COMDAT (that may be for
functions since all COMDATs are also inlines, but makes difference for
variables I think).
Not all COMDAT
OK.
Jason
On 08/26/2013 03:57 PM, Jan Hubicka wrote:
While analyzing the relocations of libreoffice I noticed that I can play
the same game w/o LTO at linker level. Making those symbols hidden truns
external relocations to internal and should improve runtime, too: comdat
sharing by dynamic linker is expen
On 08/26/2013 10:45 AM, Gabriel Dos Reis wrote:
Hmm, let's not make it a default. Replacing global operator new (e.g. for
tracing purposes) is a valid C++ programming idiom.
Absolutely. What strikes me as vanishingly unlikely is the idea that
the replacement operator new would expose pointer
On 08/22/2013 09:19 AM, Jan Hubicka wrote:
- I tried to track functions that lead to terminate() and not mark them
as ECF_LEAF. This is because user can set handler. If the handler
can resonably expect the static vars defined in its unit to be
in the final form, we can not conside
This patch doesn't seem to depend on the others; go ahead and apply it.
Jason
On 08/27/2013 02:46 PM, Adam Butcher wrote:
Okay. As it stands, it means that you get an additional 'const' in
diagnostics for lambda's not declared 'mutable'.
Hmm, I guess it would be preferable to use 'mutable' or nothing when
printing the lambda just like when declaring one.
Jason
Looks good.
Jason
OK.
Jason
On 08/29/2013 11:24 AM, Paolo Carlini wrote:
+ if ((complain & tf_error)
+ && (flags & LOOKUP_DELEGATING_CONS)
+ && name == complete_ctor_identifier
+ && TREE_CODE (ret) == CALL_EXPR
+ && (DECL_ABSTRACT_ORIGIN (TREE_OPERAND (CALL_EXPR_FN (ret), 0))
+ == current_functi
On 08/30/2013 05:06 AM, Paolo Carlini wrote:
I should have explained some of that in better detail. The main issue I
had yesterday, is that the pattern matching can easily become very
difficult if not impossible: if you look at the second half of
expand_default_init, in some cases we wrap the ret
On 08/19/2013 10:01 AM, Jan Hubicka wrote:
+ /* All equivalent types, if more than one. */
+ vec *types;
+ /* Set of all equivalent types, if NON-NULL. */
+ pointer_set_t * GTY((skip)) types_set;
Why do you need both a vector and a pointer set? Can't you drop the
vector and use poin
On 08/27/2013 03:42 PM, Adam Butcher wrote:
Unfortunately, due to errors being thrown 'early' in grokdeclarator, I
haven't been able to get 'auto...' (or reference/qualified variants)
working yet. I think I need to defer processing the parameter pack
internals of grokdeclarator until I have the
On 08/27/2013 03:42 PM, Adam Butcher wrote:
+ vec_safe_push (argvec, arg);
I bet we want convert_from_reference in the non-generic lambda case, too.
OK with that change.
Jason
On 08/27/2013 03:42 PM, Adam Butcher wrote:
+ if (FUNCTION_PARAMETER_PACK_P (src))
+ return;
Yeah, in the case of a parameter pack we want to pass a pack expansion.
Jason
On 08/27/2013 03:42 PM, Adam Butcher wrote:
+ else // extend current template parameter list
+ // pop the innermost template parms into tparms
Most comments should start with a capital letter and end with a period.
+ for (size_t n = 0, end = TREE_VEC_LENGTH (inner_vec); n < end; ++
On 09/01/2013 03:50 PM, Jan Hubicka wrote:
I was mostly worried about ordering issues. pointer_set is not stable
across memory layout changes and we may end up outputting warnings/merging
binfos in random orders. This seemed uncool. Maybe the final form is quite
safe, since we do everything with
OK.
Jason
On 09/02/2013 02:30 PM, Adam Butcher wrote:
I think I had made that change originally to keep the two impls the same
and I hit issues with non-generic lambdas. But I can't remember the
details. I'll try again. If it works with convert_from_reference in
both cases should I push or should I sort
On 09/02/2013 02:27 PM, Adam Butcher wrote:
Bug 41933 is specifically about lambda capture; I think you're
running into something else.
The problem is in expanding the 'ts' capture from the 5.1.2.5. It
looks like this:
1 auto vglambda = [](auto printer) {
2 return [=](auto&& ... ts) {
On 09/02/2013 05:18 PM, Adam Butcher wrote:
Will assume, for now, that the convert_from_reference call is not wanted
in the non-generic case (maybe something to do with using 'build_call_a'
instead of 'build_nt_call_vec' or the convert_from_reference on the call
itself?)
Ah, yes; we are passing
On 09/03/2013 03:50 PM, Adam Butcher wrote:
Problem is that no RTL is set for the incoming parms in the
instantiation of the expansion. It ICEs in gimple_expand_cfg because
'DECL_RTL_IF_SET
(var)' returns nullptr for the incoming parms resulting in a failed assertion
that
SA.partition_to_pseud
On 09/03/2013 11:10 AM, Paolo Carlini wrote:
ToBeDeprecated();
I'd rather handle this case in build_functional_cast.
Jason
OK.
Jason
It looks to me like this will result in duplicate diagnostics for
invalid members in a nested anonymous union. Maybe make the recursive
part only handle access setting?
Jason
On 09/03/2013 11:01 AM, Andrew Sutton wrote:
Attached is a patch for constrained class templates. It's the 3rd time
I've sent it.
Please feel free to ping me if you're waiting for a patch review; once a
week is not too much.
1. Type constraints are checked on lookup rather than instantiatio
On 09/04/2013 11:59 AM, Andrew Sutton wrote:
It's not supposed to be different. Checking constraints in
instantiate_template is actually too late. We want to check before
instantiation, at the point of use.
Right, what I was getting at is that instantiate_template actually only
instantiates th
On 09/03/2013 06:03 AM, Tom de Vries wrote:
* semantics.c (finish_transaction_stmt, build_transaction_expr): Handle
flag_exceptions.
I'd rather handle this at a lower level, by making
build_must_not_throw_expr return its argument if -fno-exceptions.
Jason
On 09/04/2013 10:42 AM, Paolo Carlini wrote:
Indeed. I think the recursive part already does that, because only the
first time is called complain == true (thus does exactly what the
current code does), then when the recursion proper starts, complain ==
false.
Ah yes, I see.
Or you mean someth
On 09/04/2013 01:33 PM, Andrew Sutton wrote:
Ah. The goal is to check after we've deduced/coerced template
arguments into a valid substitution. With functions, that's in
fn_type_unification (hopefully called from instantiate_template)
Actually fn_type_unification calls instantiate_template, but
OK, thanks.
Jason
On 09/05/2013 10:50 AM, Joern Rennecke wrote:
(vector_types_compatible_elements_p): New function.
Why do we need this as well as vector_types_convertible_p? For that
matter, why do we need both vector_types_convertible_p and
vector_targets_convertible_p?
Jason
On 09/07/2013 06:13 AM, Paolo Carlini wrote:
Actually this kind of change makes a lot of sense to me (cmp clang too): since at that point we do
*not* really know the location of the "required from" bit, just plainly admit it. Would
it be possible in such cases to have a conditional in the diagn
OK.
Jason
On 09/06/2013 08:58 PM, Joern Rennecke wrote:
vector_targets_convertible_p is used for pointer types. The callers
do a hop, skip and dance to check that the qualifiers are satisfactory,
while OTOH vector_targets_convertible_p ignores the number of elements
in the vectors. That's fine with vecto
OK.
Jason
On 09/06/2013 12:03 PM, Andrew Sutton wrote:
+// Returns the template type of the class scope being entered. If we're
+// entering a constrained class scope. TMPL is the most general template
+// of the scope being entered, and TYPE is its type.
TMPL is not part of the interface of fixup_templa
On 09/05/2013 06:44 PM, Paolo Carlini wrote:
+ && warning (0, "possible problem detected in invocation of "
+ "delete [] operator:"))
The warning should probably be suppressible by some flag.
Jason
OK, thanks.
Jason
On 09/09/2013 03:22 AM, Adam Butcher wrote:
I've attached a patch that handles parameter packs in the conversion
op. I thought it best to get this reviewed independently before rolling
up into the 'Support lambda templates' patch.
Do you think it's the right idea? It seems to work okay but I'v
OK.
Jason
On 09/11/2013 03:38 AM, Adam Butcher wrote:
This is not a complete enough description. It only ICEs instantiating
the call op through the decltype return of the conversion op if the
return type of the call op is a deduced one (i.e. unspecified or
specified explicitly as 'auto'). If the lambda c
On 09/11/2013 10:42 AM, Jason Merrill wrote:
Sounds like the problem is that the compiler is trying to instantiate a
function while cp_unevaluated_operand is set. But that shouldn't be an
issue because push_to_top_level clears cp_unevaluated_operand. How does
it come to be set
On 09/09/2013 10:19 PM, Adam Butcher wrote:
+ if (current_class_type && LAMBDA_TYPE_P (current_class_type))
+ {
+ if (cxx_dialect < cxx1y)
+ pedwarn (location_of (type), 0,
+"use of % in lambda parameter declaration "
+
OK.
Jason
On 09/11/2013 02:22 PM, Adam Butcher wrote:
Okay for the attached to go to trunk with suitable changelog?
Yes.
Jason
OK.
Jason
On 09/12/2013 06:26 AM, Jacek Caban wrote:
+@deftypefn {C Target Hook} bool TARGET_CXX_IMPLICIT_EXTERN_C (const
char*@var{})
+Define this hook to add target-specific C++ implicit extern C functions. An
example of such function is WinMain on Win32 targets.
+@end deftypefn
Let's clarify this a
Just the pedwarn, I think.
Jason
A simple cut-and-paste error. When I copied
any_value_dependent_elements_p to any_type_dependent_elements_p, I
should have changed the body of the function as well...
Tested x86_64-pc-linux-gnu, applying to trunk, 4.8, 4.7.
commit 0515f1a9424ba750c345826d5504aecb6e23b8e0
Author: Jason Merrill
On 09/15/2013 06:22 AM, Adam Butcher wrote:
[PATCH 1/5] Fix uninitialized variables causing breakage with -Werror.
[PATCH 2/5] Don't accept 'auto' as the 'type' of a template parameter.
OK.
[PATCH 3/5] Fix location diagnostics by returning to the deprecated
'input_location' global; m
64-pc-linux-gnu, applying to trunk.
commit 85cb3c43f2b8aa7897b499e125a5d77e7a8a5a3c
Author: Jason Merrill
Date: Sun Sep 15 08:56:42 2013 -0700
Core DR 904
PR c++/41933
* parser.c (cp_parser_lambda_introducer): Handle variadic capture.
* lambda.c (add_capture): Handle variadic ca
Looks good.
Jason
On 09/16/2013 05:28 AM, Richard Biener wrote:
which exhibits exactly the behavior you quote - return x is considered throwing
an exception. The C++ FE doesn't arrange for TREE_THIS_NOTRAP to be
set here (maybe due to this issue you quote?).
I haven't been aware of TREE_THIS_NOTRAP, but we coul
OK.
Jason
OK.
Jason
On 09/12/2013 04:55 AM, Jakub Jelinek wrote:
- if (t1 != t2)
+ if (t1 != t2 && !DECL_OMP_DECLARE_REDUCTION_P (newdecl))
return 0;
What's the theory here? Why should decls_match return true for
reductions with mismatching templates?
+ && ! (DECL_OMP_DECLARE_REDUCTI
On 09/19/2013 02:37 PM, Adam Butcher wrote:
+ static int i = 0;
I think this needs to be global and GTY so that it works properly with PCH.
Jason
Why is canonical_type_parameter not doing the right thing here? I don't
see a reason we should need to treat these differently from normal
template parms.
Jason
1301 - 1400 of 11982 matches
Mail list logo
