On Thu, Jun 20, 2019 at 4:58 PM H.J. Lu wrote:
> > > > > >> > > +/* Register pair. */
> > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 2); /* P2QI */
> > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 4); /* P2HI P4QI */
> > > > > >> > >
> > > > > >> > > I think
> > > > > >> > >
> > > > > >>
Hi,
The attached patch tries to fix PR88833.
For the following test-case:
subroutine foo(x)
real :: x(100)
x = x + 10
end subroutine foo
Assembly with -O3 -march=armv8.2-a+sve:
foo_:
.LFB0:
.cfi_startproc
mov w2, 100
mov w3, w2
mov x1, 0
wh
Hi.
The patch is about a new ELF section that will contain information
about LTO version. And for the future, used compression will be stored
here. The patch removes streaming of the version into each section.
Disadvantage is a format change that will lead to following errors when
LTO bytecode is
The following fixes the case where we're vectorizing the inner loop
of an if-converted scalar version of a outer loop. In this case
we cannot re-use the if-conversion version because the not vectorized
path would fall into the code intended for outer loop vectorization.
Bootstrapped and tested
Hi Richard. Hi folks.
In order to unify the APIs for value_range and irange, we'd like to make
some minor changes to value_range. We believe most of these changes
could go in now, and would prefer so, to get broader testing and
minimize the plethora of changes we drag around on our branch.
Hi!
On Wed, 05 Jun 2019 11:25:07 +0200, I wrote:
> I [...] had a look at what OpenMP 5.0
> is saying about Fortran 'allocatable' in 'map' clauses [...]
Will you (Jakub, and/or Fortran guys), please have a look at the attached
test case.
If I disable the '!$omp declare target (ar)', then this wo
On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
>> Yes, I would be fine to deprecate that for GCC 10.1
>
> Would it be appropriate to issue a warning in GCC 10.x if the option is used?
Sure. With the patch attached one will see:
$ gcc -frepo /tmp/ma
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> > On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> >> Yes, I would be fine to deprecate that for GCC 10.1
> >
> > Would it be appropriate to issue a warning in GCC 10.x if the option is
On Thu, Jun 20, 2019 at 4:16 PM Jan Hubicka wrote:
>
> Hi,
> as discussed earlier this patch drops ref2_is_decl from
> aliasing_component_refs. This parameter makes it to assume that all
> access path may not continue by reference to DECL which is not true
> because in gimple memory model we allo
On Fri, Jun 21, 2019 at 1:13 AM Jeff Law wrote:
> On 6/20/19 3:53 AM, JiangNing OS wrote:
> > Hi Jeff,
> >
> > Appreciate your effort to review my patch! I've updated my patch as
> attached. See my answers below.
> >
> >> in current function, so the store speculation can be avoided.
> >> So at a
On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>
> As outlined in the BZ, our alias analysis code is context insensitive.
> So when we copy-propagate pointers, we can can and do copy PTA
> information from members to the representative pointer in the copy-of
> chain (we do this when the represen
On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
>
> Hi.
>
> The patch is about a new ELF section that will contain information
> about LTO version. And for the future, used compression will be stored
> here. The patch removes streaming of the version into each section.
I'd like each section
On 6/21/19 2:34 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
>>
>> Hi.
>>
>> The patch is about a new ELF section that will contain information
>> about LTO version. And for the future, used compression will be stored
>> here. The patch removes streaming of the
> On 6/21/19 2:34 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is about a new ELF section that will contain information
> >> about LTO version. And for the future, used compression will be stored
> >> here. The patch removes s
Currently variables with the AUTOMATIC attribute can not appear in an
EQUIVALENCE statement. However its counterpart, STATIC, can be used in
an EQUIVALENCE statement.
Where there is a clear conflict in the attributes of variables in an
EQUIVALENCE statement an error message will be issued as i
This series of patches tweaks the IRA handling of matched constraints
and earlyclobbers. The main explanations are in the individual patches.
Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
I also tried building at least one target per CPU directory and
comparing the eff
add_insn_allocno_copies and its subroutines used HARD_REG_SET to
represent a bitmask of alternatives. There's not really any connection
between the number of registers and the maximum number of alternatives,
so this patch uses alternative_mask instead (which wasn't around when
this code was added)
ira_setup_alts has its own code to calculate the start of the
constraint string for each operand/alternative combination,
but preprocess_constraints now provides that information in (almost)
constant time for non-asm instructions. Using it here should speed
up the common case at the cost of potent
SVE has a prefix instruction (MOVPRFX) that acts as a move but is
designed to be easily fusible with the following instruction. The SVE
port therefore has lots of patterns with constraints of the form:
A: operand 0: =w,?w
...
operand n: 0, w
where the first alternative is a single i
ira_get_dup_out_num punted on operands that are matched to
earlyclobber outputs:
/* It is better ignore an alternative with early clobber. */
else if (*str == '&')
goto fail;
But I'm not sure why this is the right thing to do. At this stage
we've establishe
make_early_clobber_and_input_conflicts records allocno conflicts
between inputs and earlyclobber outputs. It (rightly) avoids
doing this for inputs that are explicitly allowed to match the
output due to matching constraints.
The problem is that whether this matching is allowed varies
between alte
The following fixes PR90914, we cannot keep local exten declarations
unmarked since they will be re-created when instantiating the function
BLOCKs later. And that causes issues if by that means new types get
materialized which should not happen at that point.
Bootstrapped / tested on x86_64-unk
On 6/21/19 2:57 PM, Jan Hubicka wrote:
> This looks like good step (and please stream it in host independent
> way). I suppose all these issues can be done one-by-one.
So there's a working patch for that. However one will see following errors
when using an older compiler or older LTO bytecode:
$
On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
>> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
>>> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
Yes, I would be fine to deprecate that for GCC 10.1
>>>
>>> Would it be appropriate to is
These functions are using TREE_PURPOSE to get the attribute name,
which is breaking now that we preserve the C++11-style attribute
format past decl_attributes. So use get_attribute_name which can
handle both formats of attributes.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-06-21
On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
> Currently variables with the AUTOMATIC attribute can not appear in an
> EQUIVALENCE statement. However its counterpart, STATIC, can be used in
> an EQUIVALENCE statement.
>
> Where there is a clear conflict in the attributes of va
Hi!
On Fri, 21 Jun 2019 13:46:09 +0200, I wrote:
> On Wed, 05 Jun 2019 11:25:07 +0200, I wrote:
> > I [...] had a look at what OpenMP 5.0
> > is saying about Fortran 'allocatable' in 'map' clauses [...]
>
> Will you (Jakub, and/or Fortran guys), please have a look at the attached
> test case.
>
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> >> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> >>> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote:
> Yes, I would be f
The following fixes a quadraticness in reassoc.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-06-21 Richard Biener
PR tree-optimization/90930
* tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
flag on new stmts to avoid re-proces
This Go patch by Cherry Zhang open codes string slice expressions.
Currently a string slice expression is implemented with a runtime call
__go_string_slice. Change it to open code it, which is more
efficient, and allows the backend to further optimize it. Also omit
the write barrier for length-on
On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> > On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> > > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> > >> On 6/21/19 1:47 PM, Jonathan Wakely wrote:
> > >>> On Fri,
On 6/21/19 8:09 AM, Marek Polacek wrote:
> These functions are using TREE_PURPOSE to get the attribute name,
> which is breaking now that we preserve the C++11-style attribute
> format past decl_attributes. So use get_attribute_name which can
> handle both formats of attributes.
>
> Bootstrapped/
This Go frontend patch by Cherry Zhang omits write barriers for
assignments to *(convert(&local)). Assignments to local variables
don't need a write barrier. But currently the compiler inserts a
write barrier if the LHS is a local variable with type converted, as
*(convert(&local)). Let the comp
On 6/20/19 8:09 PM, Martin Sebor wrote:
> On 6/20/19 4:23 PM, Jeff Law wrote:
>> As outlined in the BZ, our alias analysis code is context insensitive.
>> So when we copy-propagate pointers, we can can and do copy PTA
>> information from members to the representative pointer in the copy-of
>> chain
On 6/21/19 6:28 AM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>>
>> As outlined in the BZ, our alias analysis code is context insensitive.
>> So when we copy-propagate pointers, we can can and do copy PTA
>> information from members to the representative pointer in t
On Thu, Jun 20, 2019 at 05:24:15PM -0400, Matthew Beliveau wrote:
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-06-20 Matthew Beliveau
>
> PR c++/90875 - added -Wswitch-outside-range option
> * doc/invoke.texi (Wswitch-outside-range): Document.
>
> * c-war
On June 21, 2019 4:43:10 PM GMT+02:00, Jeff Law wrote:
>On 6/21/19 6:28 AM, Richard Biener wrote:
>> On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>>>
>>> As outlined in the BZ, our alias analysis code is context
>insensitive.
>>> So when we copy-propagate pointers, we can can and do copy PTA
On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
>
> The following fixes a quadraticness in reassoc.
>
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
build_and_add_sum has several other callers, don't they need a similar
change (or better do the gimple_set_visited (sum
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet (12.2)). His modules branch now diagnoses
those violations, so we need a fix.
Looking at the history (r114044 by Paolo) I believe the idea was in
On 6/21/19 6:23 AM, Richard Biener wrote:
>
> That looks like a pretty easy form to analyze. I'd suggest looking
> through tree-ssa-phiopt.c closely. There's several transformations
> in there that share similarities with yours.
>
>
> More specifically there is the conditional store eliminati
On June 21, 2019 5:50:45 PM GMT+02:00, Jakub Jelinek wrote:
>On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
>>
>> The following fixes a quadraticness in reassoc.
>>
>> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>
>build_and_add_sum has several other callers, don't
On 6/21/19 6:28 AM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 12:24 AM Jeff Law wrote:
>>
>> As outlined in the BZ, our alias analysis code is context insensitive.
>> So when we copy-propagate pointers, we can can and do copy PTA
>> information from members to the representative pointer in t
Hi!
Now that the inclusive/exclusive scan support is pretty much done in simd,
it is time to implement it also in the OpenMP worksharing-loop and in
the combined worksharing-loop SIMD constructs, so that the scan computation
is not just vectorized, but also parallelized.
There are some parallel a
On 6/21/19 12:01 PM, Jonathan Wakely wrote:
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet (12.2)). His modules branch now diagnoses
those violations, so we need a fix.
Looking at the history
This PR was submitted on 2012-01-25. It seems that I
posted a patch in comment #9 on 2012-01-25. But the
patch was never submitted to fortran@ and patches@. The
patch is straight forward in that it suppresses a bogus
error message which then allows gfortran to issue a
more suitable error messag
On 21/06/19 13:01 -0400, Nathan Sidwell wrote:
On 6/21/19 12:01 PM, Jonathan Wakely wrote:
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet (12.2)). His modules branch now diagnoses
those viola
On 21/06/19 18:08 +0100, Jonathan Wakely wrote:
On 21/06/19 13:01 -0400, Nathan Sidwell wrote:
On 6/21/19 12:01 PM, Jonathan Wakely wrote:
Nathan noticed that the 'static inline' functions in
cause ODR violations when used from inline functions or templates (see
[basic.def.odr] p12 bullet (12.
On Fri, Jun 21, 2019 at 06:20:35PM +0200, Richard Biener wrote:
> On June 21, 2019 5:50:45 PM GMT+02:00, Jakub Jelinek wrote:
> >On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
> >>
> >> The following fixes a quadraticness in reassoc.
> >>
> >> Bootstrap / regtest running on x86_
On 13/06/19 17:09 +0100, Jonathan Wakely wrote:
The C++17 library was rebased on C11 by https://wg21.link/p0063r3 so
these nine macros are needed for C++17 conformance.
gcc:
* ginclude/float.h (FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, LDBL_DECIMAL_DIG)
(FLT_HAS_SUBNORM, DBL_HAS_SUBNORM
On 20/06/19 00:00 +0100, Jonathan Wakely wrote:
The change in r263433 broke the contract of the __rotate functions, by no
longer accepting empty ranges. That means that callers which inlined the
old version of std::rotate (without checks) that end up linking to a new
definition of std::__rotate (
Richard Sandiford writes:
> This series of patches tweaks the IRA handling of matched constraints
> and earlyclobbers. The main explanations are in the individual patches.
>
> Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
>
> I also tried building at least one target pe
On Fri, 21 Jun 2019, Jakub Jelinek wrote:
> On Fri, Jun 21, 2019 at 06:20:35PM +0200, Richard Biener wrote:
> > On June 21, 2019 5:50:45 PM GMT+02:00, Jakub Jelinek
> > wrote:
> > >On Fri, Jun 21, 2019 at 04:17:13PM +0200, Richard Biener wrote:
> > >>
> > >> The following fixes a quadraticness
OK.
On Fri, Jun 21, 2019 at 1:24 PM Jonathan Wakely wrote:
>
> On 13/06/19 17:09 +0100, Jonathan Wakely wrote:
> >The C++17 library was rebased on C11 by https://wg21.link/p0063r3 so
> >these nine macros are needed for C++17 conformance.
> >
> >gcc:
> >
> > * ginclude/float.h (FLT_DECIMAL_D
On Thu, Jun 20, 2019 at 11:51 PM Hongtao Liu wrote:
>
> On Fri, Jun 21, 2019 at 1:56 PM Uros Bizjak wrote:
> >
> > On Fri, Jun 21, 2019 at 4:21 AM Hongtao Liu wrote:
> > >
> > > On Thu, Jun 20, 2019 at 10:58 PM H.J. Lu wrote:
> > > >
> > > > On Thu, Jun 20, 2019 at 3:54 AM Hongtao Liu wrote:
>
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check that
we have now in place (fixed c++/67184) doesn't work correctly for the
below reproducer, which involves a pure virtual: we de-virtualize and
the build fails at link-time. To cur
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the below reproducer, which involves a pure virtual: we
de-virtu
There are two issues with the Darwin14 (SDK) headers in which unguarded
advanced syntax elements causes any code including these headers to fail.
tested on several Darwin versions and x86-64-linux-gnu.
applied to mainline,
thanks
Iain
2019-06-21 Iain Sandoe
* inclhack.def: Guard __has
Darwin has had long long functions for some considerable time and these are
exposed in Darwin8 and Darwin11+ headers. However, for some reason it was
elected to hide them behind __STRICT_ANSI__ and __STDC_VERSION__ on
Darwin9/10. This is a problem for g++/libstdc++ that expects the functions to
b
Hi,
On 21/06/19 21:27, Paolo Carlini wrote:
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the below reproduce
On 6/17/19 1:44 PM, Marek Polacek wrote:
+// { dg-options "-Wno-pedantic -Wno-switch-outside-range" }
(You can also use __extension__ so that you don't need -Wno-pedantic.)
Using dg-options overrides the default -pedantic-errors, so you don't
need __extension__ either.
If you don't mean to
and...
By the way, if S1:.f is not pure virtual, just a virtual declaration -
all the rest being the same - the code doesn't link: undefined
references to vtable and typeinfo for S1. The same happens with
current clang and icc. I don't know if this detail helps us in the
short term
... t
On 6/20/19 10:46 AM, Marek Polacek wrote:
The first test is rejected because build_noexcept_spec first converts
a TARGET_EXPR using a user-defined conversion, creating
R::operator bool (&TARGET_EXPR )
which then fails when instantiating ("taking address of rvalue").
The second test ICEs in
On Fri, Jun 21, 2019 at 04:06:50PM -0400, Jason Merrill wrote:
> On 6/20/19 10:46 AM, Marek Polacek wrote:
> > The first test is rejected because build_noexcept_spec first converts
> > a TARGET_EXPR using a user-defined conversion, creating
> >
> >R::operator bool (&TARGET_EXPR )
> >
> > whic
On 6/19/19 8:18 PM, Marek Polacek wrote:
We are wrongly accepting invalid code like:
struct alignas(16 S2 { }; // missing )
The reason is that cp_parser_type_specifier uses tentative parsing to see if
we're dealing with a class-specifier, and if that doesn't work, it looks for
an elaborated-
On 6/18/19 11:54 AM, Marek Polacek wrote:
Here we ICE on
template // #1
struct A {};
template void foo(A) {}
void bar() { foo(A()); }
when deducing T in the non-type template parameter, because unify didn't
expect a CONSTRUCTOR:
default:
/* An unresolved overload is a
I've committed the attached patch. Read the test case
for an explanation.
2019-06-21 Steven G. Kargl
PR fortran/67884
* resolve.c (deferred_requirements) : Check only the result variable.
(resolve_fl_procedure): Check deferred requirements on functions.
2019-06-21 St
On 6/17/19 5:43 PM, Marek Polacek wrote:
[class.friend]/6 says that when we define a function in a friend declaration,
the function name must be unqualified. But we never made sure that's so.
For good measure, I'm also improving the location of the related diagnostic.
Bootstrapped/regtested on
On 6/14/19 4:54 PM, Marek Polacek wrote:
On Tue, Jun 11, 2019 at 11:46:05PM -0400, Jason Merrill wrote:
On 6/3/19 9:01 PM, Marek Polacek wrote:
I sort of ended up going down a rathole, but then I realized we don't need to
delay parsing of noexcept-specifiers of member friend function declarati
Hi!
Now that GCC supports inclusive/exclusive scans (like ICC 19.0 so far in
simd constructs only), we can enable it in PSTL as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested
with
#include
#include
auto
foo (std::vector &ca, std::vector &co)
{
return std::in
On Fri, Jun 21, 2019 at 04:47:46PM -0400, Jason Merrill wrote:
> On 6/14/19 4:54 PM, Marek Polacek wrote:
> > On Tue, Jun 11, 2019 at 11:46:05PM -0400, Jason Merrill wrote:
> > > On 6/3/19 9:01 PM, Marek Polacek wrote:
> > >
> > > > I sort of ended up going down a rathole, but then I realized we d
Hi!
The following testcases weren't vectorized, because the simd lane accesses
weren't recognized there.
Usually SIMD lane accesses look like:
_22 = .GOMP_SIMD_LANE (simduid.0_14(D), ??);
...
MEM [(struct S *)&D.2456][_22].s = _25;
but on these two testcases we ended up with:
_18 = .GOMP_SI
... so, now that I see the issue more clearly, I'm adding to the
testsuite the below too.
Thanks, Paolo.
Index: final7.C
===
--- final7.C(nonexistent)
+++ final7.C(working copy)
@@ -0,0 +1,11 @@
+
This Go patch by Cherry Zhang open codes some type assertions. Now
that type equality is just simple pointer equality, we can open code
some type assertions instead of making runtime calls. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofron
On Wed, Jun 19, 2019 at 12:49 PM Martin Sebor wrote:
>
>
> gcc-wformat-diag-checker.diff
>
> gcc/c-family/ChangeLog:
>
> * c-format.c (function_format_info::format_type): Adjust type.
> (function_format_info::is_raw): New member.
> (decode_for
This libgo patch by Cherry Zhang inlines and remove eqtype. Now that
type equality is just a pointer equality, inline and remove the eqtype
function. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
This Go patch by Cherry Zhang lets the Go frontend recognize some
math/bits functions and turn them into intrinsics. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
2019-06-21 Cherry Zhang
* go-gcc.cc (Gcc_backend::Gcc_backend): Define math/bits
builtins
On 6/21/19 4:16 PM, Ian Lance Taylor wrote:
On Wed, Jun 19, 2019 at 12:49 PM Martin Sebor wrote:
gcc-wformat-diag-checker.diff
gcc/c-family/ChangeLog:
* c-format.c (function_format_info::format_type): Adjust type.
(function_format_info::is_raw): New member.
(decode_format
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing
On 6/21/19 5:29 PM, Marek Polacek wrote:
On Fri, Jun 21, 2019 at 04:47:46PM -0400, Jason Merrill wrote:
On 6/14/19 4:54 PM, Marek Polacek wrote:
On Tue, Jun 11, 2019 at 11:46:05PM -0400, Jason Merrill wrote:
On 6/3/19 9:01 PM, Marek Polacek wrote:
I sort of ended up going down a rathole, but
On 6/13/19 9:21 PM, Marek Polacek wrote:
As Jon points out in the PR, emitting -Wunused warnings in unevaluated contexts
doesn't make a whole lot of sense, because in such contexts, we're not reading
the values in any case. Disabling this particular warning is trivial. There
are likely other wa
On 6/13/19 8:12 PM, Paolo Carlini wrote:
Hi,
should all be rather straightforward but I spent quite a bit of time on
the testsuite changes... Tested x86_64-linux, as usual.
OK.
PS: at some point we should start talking about all the error, error_at,
etc, which are *never* exercised by our t
81 matches
Mail list logo
