Hi.
Thanks for the review. See the comments below.
I attached the updated patch.
On Thu, Oct 15, 2020 at 05:52:33PM -0400, David Malcolm wrote:
On Thu, 2020-10-15 at 13:39 -0400, Antoni Boucher wrote:
Thanks. I updated the patch with these changes.
Thanks for patch; review below. Sorry if
On Fri, Oct 09, 2020 at 12:35:44AM -0400, Michael Meissner wrote:
> This patch is revised from the first version of the patch posted.
In the future, please send a NEW series, in a NEW thread, when you have
a new series. I was waiting for a new series (because you needed
changes), and I missed
I wrote:
Regression-tested. OK for trunk?
I will remove this part
- When an actual argument list is provided, skip the absent arguments.
+ When an actual argument list is provided, skip the absent arguments
+ unless copy_type is true.
To be used together with
Hello Harald,
*ping*
OK for master / 10-branch?
OK for both (with a suitable waiting period).
Best regards
Thomas
Hello world,
here's a patch which corrects some wrong declarations (and fixes
the segfault for FINDLOC on Darwin ARM).
Regression-tested. OK for trunk?
Best regards
Thomas
Correct decls for functions which do not pass actual arguments.
A wrong decl for findloc caused segfaults at
On Thu, Sep 24, 2020 at 04:20:36PM -0400, Michael Meissner wrote:
> This series of 9 patches is an attempt to gather together all of the patches
> that are needed to be able to configure and build a little endian 64-bit
> PowerPC Linux GCC compiler where the defualt long double format uses the
AS Jakub observed in an earlier testcase (97325), when EVRP dumps the
known SSA_RANGES, it isn't expecting names to be deleted that it could
not delete, so it wasn't checking.
With the hybrid model, ranger sometimes deletes things that EVRP
calculated a range for, and the resulting dump was
In order to match evrp behaviour, adjust POINTER_PLUS_EXPR processing to
handle a zero constant plus something to return the something.
ie
[0, 0] + CONST will now return [CONST, CONST] instead of the
previous behaviour of [1, +INF].
Bootstrapped on x86_64-pc-linux-gnu, no regressions,
In the hybrid folder, range_of_stmt and range_on_edge invoke the same
routines in both evrp_folder and ranger_folder and compare results.
In implementing hybrid folder, I inherited it from evrp_folder since
EVRP has a few pre-and post statement things to do.
when the hybdrid folder calls
We were asserting that the shifts should not be negative, instead, just
return false indicating we can't tell anything about operand1 from the
result.
Bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.
Andrew
2020-10-16 Andrew Macleod
PR tree-optimization/97462
gcc/
*
Hi,
in PR 97456, IPA-SRA triggers a bug in tree-complex.c where it
converts:
a$_M_value_21 = COMPLEX_EXPR ;
(where ISRA.18 is IPA-SRA created PARM_DECL with DECL_IGNORED_P set,
which is why it only happens with IPA-SRA) into:
a$_M_value_21 = COMPLEX_EXPR ;
i.e. it replaces two
On 10/15/20 7:21 PM, Jonathan Wakely wrote:
Ed,
In commit r232377 (aka 2be75957b80b640c0aac4356ab861edd0c2f1b9d in the
git repo) you added a new header to the include/precompiled directory.
That wasn't mentioned in the ChangeLog, wasn't in the patch posted to
On Fri, Oct 16, 2020 at 11:17 AM Jakub Jelinek wrote:
>
> On Fri, Oct 16, 2020 at 10:58:34AM -0700, H.J. Lu wrote:
> > Don't set HAVE_AS_GDWARF_5_DEBUG_FLAG nor HAVE_AS_WORKING_DWARF_4_FLAG
> > if there is an extra assembly input file in debug info generated by
> > --gdwarf-5/--gdwarf-4:
> >
> >
On Linux/x86_64,
429ad0bb0d3dc77e44f95620341da4938d49168e is the first bad commit
commit 429ad0bb0d3dc77e44f95620341da4938d49168e
Author: Richard Biener
Date: Thu Oct 15 11:55:53 2020 +0200
tree-optimization/97428 - split SLP groups for loop vectorization
caused
FAIL:
On Fri, Oct 16, 2020 at 10:58:34AM -0700, H.J. Lu wrote:
> Don't set HAVE_AS_GDWARF_5_DEBUG_FLAG nor HAVE_AS_WORKING_DWARF_4_FLAG
> if there is an extra assembly input file in debug info generated by
> --gdwarf-5/--gdwarf-4:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=25878
>
Don't set HAVE_AS_GDWARF_5_DEBUG_FLAG nor HAVE_AS_WORKING_DWARF_4_FLAG
if there is an extra assembly input file in debug info generated by
--gdwarf-5/--gdwarf-4:
https://sourceware.org/bugzilla/show_bug.cgi?id=25878
https://sourceware.org/bugzilla/show_bug.cgi?id=26740
Also replace success with
My changes to friend handling meant that there are now cases where a
friend doesn't get a lang-specific object. So we need to check there
is one before looking inside it.
PR c++/97460
gcc/cp/
* pt.c (push_template_decl): Check DECL_LANG_SPECIFIC in friend
case.
cp_parser_declaration peeks at 1 or 2 tokens, when I changed it not to
peek past EOF, I set the second token to NULL. But there are paths
through the function that just look at the second token. Fixed by
setting that token to EOF rather than NULL in this case.
PR c++/96258
Hello,
The VxWorks ports come with specific crtstuff objects to cope
with the variety of possible means to load code on a target, as
kernel modules or RTPS (Real Time Processes).
Compilation of those objects is currently explicitly replicated
for the two modes, through t-vxcrtstuff:
In this testcase we weren't able to deduce b's type:
template void Task() { }
auto b = { };
because resolve_nondeduced_context doesn't iterate on the {}'s elements.
So make sure to look into {} too. We don't need to handle nested {}
here.
We could either tweak resolve_nondeduced_context
Ping (#2) the following 9 patches to add support for building a GCC toolchain
where the default long double is IEEE 128-bit floating point instead of the IBM
extended double floating point.
The first patch was revised with input from Joesph Myers. I will list that
patch in this list. Most of
Hello.
There's another version of the patch that should be based on what
I discussed with Richi and Jakub:
- the first patch introduces a new option -fbit-tests that analogue to
-fjump-tables
and will control the new if-to-switch conversion pass
- the second patch adds the pass
- I share
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 16 October 2020 14:21
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC] arm: Fix the warning -mcpu=cortex-m55 conflicting
> with -march=armv8.1-m.main (pr97327).
>
> Hello,
>
> This patch fixes
Hello,
This patch fixes (PR97327) the warning -mcpu=cortex-m55 conflicts with
-march=armv8.1-m.main
for -mfloat-abi=soft by adding the isa_bit_mve_float to clearing FP bit list.
The following combination are fixed with this patch:
$ cat bug.c
int main(){
return 0;
}
$ arm-none-eabi-gcc
This changes SLP def gathering to not fail due to mismatched
def type but instead demote the def to external. This allows the
new testcase to be vectorized in full (with GCC 10 it is not
vectorized at all and with current trunk we vectorize only the
store). This is important since with BB
On Thu, 15 Oct 2020, guojiufu wrote:
> Hi,
>
> I just had a check on below patch for PR66552.
> https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540930.html
> It seems this patch works fine now. This patch fixes PR66552 which
> request to optimizes (x shift (n mod C)) to
> (x shift (n
Status
==
GCC trunk which eventually will become GCC 11 is still open for general
development. Stage 1 will end on the end of Sunday, Nov 15th 2020
at which point we will transition into Stage 3 which allows for general
bugfixing.
We have accumulated quite a number of regressions, a lot
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 16 October 2020 12:45
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 backport] arm: [MVE] Remove illegal intrinsics (PR
> target/96914)
>
> Hello,
>
> Applied cleanly, Ok for backporting this
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 16 October 2020 12:45
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 backport] arm: [MVE] Add missing
> __arm_vcvtnq_u32_f32 intrinsic (PR 96914)
>
> Hello,
>
> Applied cleanly, Ok for
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 16 October 2020 12:45
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 backport] arm: [MVE] Add vqdmlashq intrinsics (PR
> target/96914)
>
> Hello,
>
> Applied cleanly, Ok for backporting this
Hello,
Applied cleanly, Ok for backporting this patch to GCC-10?
A few MVE intrinsics had an unsigned variant implement while they are
supported by the hardware. This patch removes them:
__arm_vqrdmlashq_n_u8
__arm_vqrdmlahq_n_u8
__arm_vqdmlahq_n_u8
__arm_vqrdmlashq_n_u16
__arm_vqrdmlahq_n_u16
Hello,
Applied cleanly, Ok for backporting this patch to GCC-10?
This patch adds:
vqdmlashq_m_n_s16
vqdmlashq_m_n_s32
vqdmlashq_m_n_s8
vqdmlashq_n_s16
vqdmlashq_n_s32
vqdmlashq_n_s8
2020-10-08 Christophe Lyon
gcc/
PR target/96914
* config/arm/arm_mve.h (vqdmlashq,
Hello,
Applied cleanly, Ok for backporting this patch to GCC-10?
__arm_vcvtnq_u32_f32 was missing from arm_mve.h, although the s32_f32 and
[su]16_f16 versions were present.
This patch adds the missing version and testcase, which are
cut-and-paste from the other versions.
2020-10-08 Christophe
This patch fixes (PR97271) the wrong code-gen for mve scatter store with
writeback intrinsics with -O2.
$cat bug.c
void
foo (uint32x4_t * addr, const int offset, int32x4_t value)
{
vstrwq_scatter_base_wb_s32 (addr, 8, value);
}
$ arm-none-eabi-gcc bug.c -S -O2 -march=armv8.1-m.main+mve
On Fri, 16 Oct 2020, Richard Biener wrote:
> On Fri, 16 Oct 2020, Richard Biener wrote:
>
> > On Fri, 16 Oct 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > I am slowly getting finished with the fn spec changes on trunk and then
> > > would like to proceed with modref. Sadly still get the
> > >
> > > 2020-10-15 Jakub Jelinek
> > >
> > > * gcc.dg/ipa/modref-1.c: Remove space between param offset: and number
> > > in scan-ipa-dump.
> > > (b): Declare return type to void.
> > > (main): Declare return type to int. Change c to array of 3 chars.
> > > *
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 07 October 2020 07:14
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC] arm: Fix wrong code generated for mve scatter store
> with writeback intrinsics with -O2 (PR97271).
>
> Hello,
>
> This patch
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 06 October 2020 15:32
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 backport] arm: Add +nomve and +nomve.fp
> options to -mcpu=cortex-m55.
>
> Backport of Joe's patch wit no changes.
>
> This
On 16/10/20 10:26 +0300, Ville Voutilainen via Libstdc++ wrote:
Tested on Linux-PPC64. I haven't tested this with clang yet,
Jonathan, can you help with that? The previous implementation
indeed made an if-constexpr branch invalid for all instantiations
of that branch, this one doesn't - now we
Hi!
This patch diagnoses delete [] new int; and delete new int[1]; in constexpr
contexts by remembering
IDENTIFIER_OVL_OP_FLAGS (DECL_NAME (fun)) & OVL_OP_FLAG_VEC
from the operator new and checking it at operator delete time.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Hello,
This is a minor update of the change proposed by
Rasmus at
https://gcc.gnu.org/pipermail/gcc/2020-May/232632.html
to help builds on vxWorks 5.
This variant refactors the code area a bit based on the
observation that __gthread_enter/leave_tls_dtor_context is
actually only relevant to
- Support expansion operator (*) in the multilib config string.
- Motivation of this patch is reduce the complexity when we deal multilib with
sub-extension, expand the combinations by hand would be very painful and
error prone, no one deserve to experience this[1] again!
[1]
On Fri, 16 Oct 2020, Richard Biener wrote:
> On Fri, 16 Oct 2020, Jan Hubicka wrote:
>
> > Hi,
> > I am slowly getting finished with the fn spec changes on trunk and then
> > would like to proceed with modref. Sadly still get the assumed_type
> > failuere and in addition to that:
> > FAIL:
- Able to configure complex multi-lib rule in configure time, without modify
any in-tree source.
- I was consider to implmenet this into `--with-multilib-list` option,
but I am not sure who will using that with riscv*-*-elf*, so I decide to
using another option name for that.
-
On 10/16/20 9:45 AM, Kito Cheng wrote:
I think it would be helpful! thanks!
Hello.
I've just installed the patches to master.
Martin
On 10/16/20 9:41 AM, Kito Cheng wrote:
I think it is still useful for other targets which are not supporting
libsanitizer yet, so in this patch I also moved related testcases from
gcc.target to gcc.dg.
All right, I can't approve the patch, but I support it.
Martin
- -march has handle implied extension for a while, so I think
multilib-generator should handle this well too.
- Currently only add rule for D imply F.
gcc/ChangeLog:
* config/riscv/multilib-generator (IMPLIED_EXT): New.
(arch_canonicalize): Update comment and handle implied
On 10/2/20 1:15 PM, Martin Liška wrote:
On 10/2/20 12:05 PM, Martin Liška wrote:
There are 2 more I've just tested.
Martin
and one more.
Martin
Adding one more.
Martin
>From afcdd7b8ff51a7df885dc3fdf38be566a4c1fdbf Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 15 Oct 2020
On 10/7/20 2:03 PM, Martin Liška wrote:
On 10/1/20 9:18 PM, Martin Liška wrote:
I'm going to install the following 3 tested backports.
Martin
One more patch that I've tested.
Martin
Adding one more.
Martin
>From afcdd7b8ff51a7df885dc3fdf38be566a4c1fdbf Mon Sep 17 00:00:00 2001
From:
This refactors the array descriptor component access tree building
to commonize code into new helpers to provide a single place to
fix correctness issues with respect to TBAA.
The only interesting part is the gfc_conv_descriptor_data_get change
to drop broken special-casing of REFERENCE_TYPE desc
On 2020/9/12 01:36, Tamar Christina wrote:
> Hi Martin,
>
>>
>> can you please confirm that the difference between these two is all due to
>> the last option -fno-inline-functions-called-once ? Is LTo necessary?
>> I.e., can
>> you run the benchmark also built with the branch compiler and
On Thu, 15 Oct 2020 at 20:10, Andrea Corallo wrote:
>
> Hi Christophe,
>
> I've spotted two very minors.
>
> Christophe Lyon via Gcc-patches writes:
>
> [...]
>
> > +/* For vceqq_p64, we rely on vceq_p64 for each of the two elements. */
> > +__extension__ extern __inline uint64x2_t
> >
On Thu, 15 Oct 2020 at 20:10, Andrea Corallo wrote:
>
> Hi Christophe,
>
> I've spotted two very minors.
>
> Christophe Lyon via Gcc-patches writes:
>
> [...]
>
> > +/* For vceqq_p64, we rely on vceq_p64 for each of the two elements. */
> > +__extension__ extern __inline uint64x2_t
> >
This refactors vect_get_and_check_slp_defs so that the ops and def_stmts
arrays are filled for all stmts and operands even when we signal failure.
This allows later changes for BB vectorization SLP discovery heuristics.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2020-10-16
On Fri, 16 Oct 2020, Jan Hubicka wrote:
> Hi,
> I am slowly getting finished with the fn spec changes on trunk and then
> would like to proceed with modref. Sadly still get the assumed_type
> failuere and in addition to that:
> FAIL: gfortran.dg/finalize_25.f90 -O2 execution test
> FAIL:
Hi,
I am slowly getting finished with the fn spec changes on trunk and then
would like to proceed with modref. Sadly still get the assumed_type
failuere and in addition to that:
FAIL: gfortran.dg/finalize_25.f90 -O2 execution test
FAIL: gfortran.dg/finalize_25.f90 -O3 -fomit-frame-pointer
Hi Martin:
> I can do it earlier if it helps for the integration and testing purpose?
I think it would be helpful! thanks!
On Fri, Oct 16, 2020 at 3:33 PM Martin Liška wrote:
>
> On 8/19/20 11:25 AM, Kito Cheng via Gcc-patches wrote:
> > Could you update that for RV32, and this patch will be
Hi Martin:
I think it is still useful for other targets which are not supporting
libsanitizer yet, so in this patch I also moved related testcases from
gcc.target to gcc.dg.
On Fri, Oct 16, 2020 at 3:34 PM Martin Liška wrote:
> Hello.
>
> I'm expecting a support for libsanitizer for RISC-V
This commit implements expansion of the CUDA_Execute pragma.
CUDA_Execute must result in multiple calls to the runtime API: calls to
the hidden functions CUDA.Push_Call_Configuration and
CUDA.Pop_Call_Configuration but also to CUDA.Launch_Kernel. Calling
these functions requires putting arguments
In particular RM10.2.1(8) states:
5 An elaborable construct is preelaborable unless its elaboration
performs any of the following actions:
...
8 The evaluation of a primary that is a name of an object, unless
the name is a static expression, or statically denotes a
Having system.ads in libgnat can cause various kinds of inconsistencies,
so we move it to gcc-interface.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* gcc-interface/Make-lang.in: Update dependencies on system.ads,
add gnatbind switch -t to avoid timestamp
When determining the legality of a generic parameter association
for a formal type derived from a type that imposes a discriminant
constraint, the compiler was incorrectly concluding that an actual
type that inherits the constraint of the formal's parent type was
not compatible with the formal
Refinement of previous patch: the root type must be used for the image
of enumeration types, because the literal map is attached to the root
type even when derivations are present.
Fixes several ACATS and fixedbugs regressions involving 'Image.
Tested on x86_64-pc-linux-gnu, committed on trunk
When a (simple) return statement in a function that returns a class-wide
result type returns a call to a function that returns a specific
result type, do not finalize that function result before returning it.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_util.adb
AI12-0262 indicates that the reducer in an attribute reference
'Reduce must be either a binary function with same types for parameters
and result, or else a procedure with an in_out parameter that serves
as an accumulator. The function case includes attributes that are
themselves funxtions: the
This is the first step in supporting [...] notation for aggregates in
-gnatX mode.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/a-numeri.ads: Remove the greek letter.diff --git a/gcc/ada/libgnat/a-numeri.ads b/gcc/ada/libgnat/a-numeri.ads
---
This patch allows parsing of qualified expressions of the form
T'[...]
where [...] is a new syntax for aggregate in Ada 2020.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* par-ch4.adb (P_Name): Allow Tok_Left_Bracket in two places to
call
Recent changes exposed that some assertions were too strong, now
relaxed.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* scil_ll.adb, sem_scil.adb: Update assertions.diff --git a/gcc/ada/scil_ll.adb b/gcc/ada/scil_ll.adb
--- a/gcc/ada/scil_ll.adb
+++ b/gcc/ada/scil_ll.adb
This patch fixes the handling of the Ada_2020 attribute Img when applied
to derived types. If the type is private it is necessary to retrieve a
non-private description of the type structure, by using an underlying
view (which crosses the privacy boundary). The underlying view is that
of the base
Type in a view conversion can be both qualified and unqualified.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_util.adb (Is_View_Conversion): Detect qualified types.
* sem_util.ads (Is_Actual_In_Out_Parameter): Fix style in
comment.diff --git
Implement changes in SPARK RM 9(1): previously an object was
'synchronized' if it was a constant, now constants are only synchronized
if they are not of an access-to-variable type.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_util.ads, sem_util.adb
A Boolean aspect Exclusive_Functions is added to the language to change
the semantic of protected functions to use a R/W lock instead of a Read
lock.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* aspects.ads, snames.ads-tmpl: Add support for
Exclusive_Functions
In some cases combining a build in place function call returning a
controlled object, part of another procedure call, if the function call
raises an exception before executing the extended return statement, the
caller would attempt to finalize the build in place result which has not
been
This introduces a new attribute Max_Integer_Size that can only be
applied to Standard and yields the size of the largest supported integer
type for the target. It is primarily intended to implement
System.{Min,Max}_Int.
This also implements a couple of internal helper functions in the
compiler
This switch has never been very useful nor used in practice, so remove
the associated code complexity.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* Makefile.rtl, gnat1drv.adb, expander.adb
doc/gnat_rm/implementation_defined_pragmas.rst,
An unconstrained array object declaration might require two itypes: for
object definition and for its initial value. Their names do not matter
for the frontend, but GNATprove requires all types to have unique names
(except private/full views).
Tested on x86_64-pc-linux-gnu, committed on trunk
This replaces the use of Long_Long_Integer by Standard'Max_Integer_Size
in the definition of Min_Int, Max_Int and Max_Binary_Modulus.
No functional changes.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/system-aix.ads: Likewise.
*
The compiler rejects a declare expression whose declarations are only
object renaming declarations, when the expression references those
local objects.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_res.adb (Resolve_Declare_Expression): Retrieve the created
Always using the primary stack when concatenating arrays can lead to a
very large stack usage. To alleviate this, if the current scope is
already using the secondary stack, then allocate the temporary object on
the secondary stack as well.
For the time being, this is for string concatenation,
SPARK Reference Manual has been updated to allow the use of volatile
types and objects without Async_Writers or Effective_Reads in more
places, as these references are not considered as external effects.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_prag.adb
There are cases involving limited class-wide allocators with an
aggregate that result in if-statements in library-level elaboration
code, where parts of the if-statement can contain a nested subprogram at
the outer level of the statement lists, and the subprogram can make
up-level references to
> > @@ -122,7 +201,8 @@ public:
> > unsigned int idx = arg_idx (i);
> > gcc_checking_assert (arg_specified_p (i));
> > return str[idx] == 'w' || str[idx] == 'W'
> > - || str[idx] == 'R' || str[idx] == 'r';
> > + || str[idx] == 'r' || str[idx] == 'R'
> > + || str[idx]
Hello.
I'm expecting a support for libsanitizer for RISC-V happening soon.
Having that, will we still need this patch?
Thanks,
Martin
On 8/19/20 11:25 AM, Kito Cheng via Gcc-patches wrote:
Could you update that for RV32, and this patch will be pending until
LLVM accepts the libsanitizer part.
Hello.
I've noticed that the libsanitizer part was accepted to LLVM. I'm planning to do
a merge upstream (for libsanitizer) and was
Tested on Linux-PPC64. I haven't tested this with clang yet,
Jonathan, can you help with that? The previous implementation
indeed made an if-constexpr branch invalid for all instantiations
of that branch, this one doesn't - now we have just a dependent static_assert
which is well-formed for
85 matches
Mail list logo
