gcc-patches@gcc.gnu.org
+
殿滓优 惠 办 理 正 规 税 票，认 证 后 付 款。
详 电：李 生，136—6075— 4190，
业 q：157— 533— 2698
---
On Fri, 10 May 2019, Ed Smith-Rowland via libstdc++ wrote:
I know people are mostly looking at release branch work but I'd like to post
this. Other projects like mppp and boost use our __float128 with C++. I use
it for specfun testing and various other projects. I'd like to offer a series
Greetings,
I know people are mostly looking at release branch work but I'd like to
post this. Other projects like mppp and boost use our __float128 with
C++. I use it for specfun testing and various other projects. I'd like
to offer a series of patches to enable this support straight from
This libgo patch by Cherry Zhang changes the runtime to set up g
early. runtime.throw needs a g to work properly. Set up g early, to
ensure that if something goes wrong in the runtime startup (e.g.
runtime.check fails), the program terminates in a reasonable way.
Bootstrapped and ran Go
On Fri, May 10, 2019 at 04:26:47PM -0400, Jason Merrill wrote:
> That is strange. That seems to go back to
>
> Surely we should only set the incr location if it doesn't already have one,
> as would have been the case before that patch.
So, like this then? Bootstrapped/regtested again on
When we have
template
struct S { };
then in
S s;
"int()" is resolved to a type-id, as per [temp.arg]/2, causing this program to
fail to compile. This can be rather confusing so I think we want to improve the
diagnostic a bit.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
On Sat, 11 May 2019 at 00:55, Jonathan Wakely wrote:
>
> On 11/05/19 00:51 +0300, Ville Voutilainen wrote:
> >On Sat, 11 May 2019 at 00:42, Jonathan Wakely wrote:
> >>
> >> A disabled specialization should not be callable, so move the function
> >> call operator into a new base class which
On 11/05/19 00:51 +0300, Ville Voutilainen wrote:
On Sat, 11 May 2019 at 00:42, Jonathan Wakely wrote:
A disabled specialization should not be callable, so move the function
call operator into a new base class which correctly implements the
disabled hash semantics. For the versioned namespace
On 10/05/19 19:57 +0100, Iain Sandoe wrote:
Hi Jonathan
On 10 May 2019, at 15:20, Iain Sandoe wrote:
On 10 May 2019, at 14:57, Jonathan Wakely wrote:
Resending as plaint text so the lists don't reject it …
In order to test what it should, we'd need to use an alternate test
function
On Sat, 11 May 2019 at 00:42, Jonathan Wakely wrote:
>
> A disabled specialization should not be callable, so move the function
> call operator into a new base class which correctly implements the
> disabled hash semantics. For the versioned namespace configuration do
> not derive from
More Doxygenation.
Tested powerpc64le-linux. Committed to trunk.
commit 5ff3d9a181fcd565a1a54b7c8bc5016cb8d71bb4
Author: Jonathan Wakely
Date: Wed May 8 00:13:39 2019 +0100
Improve API docs for and
* include/bits/shared_ptr.h: Improve docs.
*
Clang diagnoses the inconsistent noexcept-specifier on the friend
declaration of __get. Add it, and also on __get_storage.
PR libstdc++/90397
* include/std/variant (_Variant_storage::_M_storage())
(_Variant_storage::_M_reset()))
(_Variant_storage::_M_storage())):
A disabled specialization should not be callable, so move the function
call operator into a new base class which correctly implements the
disabled hash semantics. For the versioned namespace configuration do
not derive from __poison_hash in the enabled case, as the empty base
class serves no
On Thu, May 09, 2019 at 07:44:15PM +0200, Bernhard Reutner-Fischer wrote:
> On 6 May 2019 15:16:20 CEST, Stafford Horne wrote:
> >Volatile memory does not match the memory_operand predicate. This
> >causes extra extend/mask instructions instructions when reading
> >from volatile memory. On
On Fri, May 10, 2019 at 11:03 PM Iain Sandoe wrote:
>
> Hi!
>
> PR82920 is about CET fails on Darwin.
>
> Initially, this was expected to be just a testsuite issue, however it turns
> out that the indirection thunks code has inconsistent handling of the output
> of labels. Thus some of the
Hi!
PR82920 is about CET fails on Darwin.
Initially, this was expected to be just a testsuite issue, however it turns out
that the indirection thunks code has inconsistent handling of the output of
labels. Thus some of the output is missing the leading “_” on Darwin, which
breaks ABI and
On 4/26/19 11:45 AM, Jakub Jelinek wrote:
Hi!
On Fri, Apr 26, 2019 at 09:31:36AM -0600, Jeff Law wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Thanks, committed to trunk now.
I'll work on a C++ FE version of this next (needed as well).
Here is the C++ FE
On 5/6/19, Martin Liška wrote:
> On 5/6/19 3:52 PM, Jakub Jelinek wrote:
>> On Mon, May 06, 2019 at 03:47:53PM +0200, Martin Liška wrote:
>>> The patch append to target_gtfiles at 3 places instead of overwriting
>>> that.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression
On Thu, May 9, 2019 at 12:31 AM Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch fixes PR 90351 (not all prototypes were written
> to standard output with -fc-prototypes) and introduces new
> functionality to also write C prototypes for external functions,
> at the same time
Seems short enough to be committed as 'obvious'.
Ok.
On Fri, May 10, 2019 at 09:57:49PM +0200, Thomas Koenig wrote:
> Hi,
>
> ping?
>
> >> Not for me, I still get
> >>
> >> % gfc pr61968.f90 -c -O3
> >> pr61968.f90:32:0:
> >>
> >> 32 | call test_lib (a, int (sizeof (a),
Hi,
ping?
Not for me, I still get
% gfc pr61968.f90 -c -O3
pr61968.f90:32:0:
32 | call test_lib (a, int (sizeof (a), kind=c_size_t))
|
internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:1265
You're right, I will clear this up separately.
In
This patch to the Go frontend permits inlining functions with receive
expressions. This does not permit any new inlinable functions in the
standard library. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
Coming back to this. I didn't think this was suitable for GCC 9.
On Mon, Jan 07, 2019 at 10:44:37AM -0500, Jason Merrill wrote:
> On 12/19/18 3:27 PM, Marek Polacek wrote:
> > Prompted by Jon's observation in 52869, I noticed that we don't treat
> > a noexcept-specifier as a complete-class
These tests fail to build on Darwin versions with assembler support for the
insns, the addition of the shim fixes those fails. However, at present,
there’s no suitable hardware available (to the regular GCC contributors) to
test the execution.
Applied.
gcc/testsuite/
2019-05-10 Iain Sandoe
Hi Jonathan
> On 10 May 2019, at 15:20, Iain Sandoe wrote:
>
>> On 10 May 2019, at 14:57, Jonathan Wakely wrote:
>>
>> Resending as plaint text so the lists don't reject it …
>
>>> In order to test what it should, we'd need to use an alternate test
>>> function that does not strip off one
On Fri, May 10, 2019 at 01:46:07PM +, Wilco Dijkstra wrote:
> And looking at the generated code, emitting a tailcall for this case is
> actually a
> de-optimization since the large eh_return epilog must be repeated for every
> tailcall.
On x86_64, the code is shorter with the tail call
Hi Jakub,
>> That's great to hear, but all the other targets still need to be fixed
>> somehow.
>
> Not all other targets, just some. I don't see what you find wrong on
> actually fixing them. The tail call in that spot is actually very
> desirable, but only if we can do a shrink wrapping for
On 5/6/19 5:13 AM, Paolo Carlini wrote:
Hi,
one of most straightforward changes in my pending queue. Tested
x86_64-linux.
OK.
Jason
On 4/29/19 2:50 PM, Paolo Carlini wrote:
Hi,
I have a small back queue of tweaks of various kinds and sizes, this one
seems small enough to be safe wrt last minute release branch fixes.
While working on the regression c++/88969, some duplicate errors showed
up when we started giving
On 5/6/19 5:07 PM, Marek Polacek wrote:
-Wsuggest-override warns for virtual functions that could use the override
keyword. But as everyone in this PR agrees, the warning shouldn't suggest
adding "override" for "final" functions. This trivial patch implements that.
Bootstrapped/regtested on
On 5/8/19 5:02 AM, Paolo Carlini wrote:
Hi again,
one more straightforward fixlet which remained in my tree for a while.
Tested x86_64-linux.
Thanks, Paolo.
/
OK.
Jason
On Fri, May 10, 2019 at 4:35 PM Segher Boessenkool
wrote:
>
> On Fri, May 10, 2019 at 09:42:47AM +0200, Richard Biener wrote:
> > On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
> > > > But IL semantic differences based on mode is even worse. What happens
> > > > if STV then substitues a
On Fri, May 10, 2019 at 09:42:47AM +0200, Richard Biener wrote:
> On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
> > > But IL semantic differences based on mode is even worse. What happens
> > > if STV then substitues a vector register/op but you previously optimized
> > > with the
Hi,
a while ago Martin noticed that an unintended consequence of an old
tweak of mine - which avoided redundant error messages emitted from
cp_parser_init_declarator - is that, in some cases, we started accepting
ill-formed typeofs. Luckily, decltype isn't affected and that points to
the
On Fri, May 10, 2019 at 11:44:28AM +0100, Richard Earnshaw (lists) wrote:
> I was hoping to get a comment from one of the netbsd port maintainers on
> the changes to the common NetBSD code. Are they no-longer active?
Jason Thorpe said he can't contribute to GCC because of where he works.
Krister
Hi Martin,
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
However I guess some existing tests checking for mempcpy may fail on
other targets, so might need to be changed.
> @Wilco: Can you please come up with a test-case for aarch64?
A simplified version
> On 10 May 2019, at 14:57, Jonathan Wakely wrote:
>
> Resending as plaint text so the lists don't reject it …
>
>> In order to test what it should, we'd need to use an alternate test
>> function that does not strip off one indirection level from
>> native_handle_type, if the test is to
On Fri, May 10, 2019 at 01:46:07PM +, Wilco Dijkstra wrote:
> > So given this and the fact there is no real gain from emitting tailcalls in
> > eh_return
> > functions, wouldn't it make more sense to always block tailcalls in the
> > mid-end?
>
> > No. E.g. x86 handles that just fine,
>
On 5/10/19 1:08 AM, Richard Biener wrote:
> On Thu, May 9, 2019 at 6:00 PM Jeff Law wrote:
>>
>> On 5/9/19 5:52 AM, Robin Dapp wrote:
>>> Hi,
>>>
>>> while trying to improve s390 code generation for rotate and shift I
>>> noticed superfluous subregs for shift count operands. In our backend we
>>>
On 5/10/19 1:19 AM, Martin Liška wrote:
> Hi.
>
> When I did split of i386.c I forgot to rebased this patch. It caused failure
> of gcc.target/i386/fpprec-1.c execution test.
>
> Thank you Jeff for reporting that.
>
> I'm going to install the patch.
Thanks for fixing. And this is precisely
On 10/05/19 14:40 +0100, Jonathan Wakely wrote:
On Thu, 9 May 2019 at 06:49, François Dumont wrote:
Hi
Patch similar to the one I just apply for deque iterator including
NRVO copy ellision fix.
* include/bits/stl_bvector.h
(operator==(const _Bit_iterator_base&, const
Resending as plaint text so the lists don't reject it ...
On Thu, 9 May 2019, 11:37 Alexandre Oliva wrote:
> Other classes that have native_handle/typesizes.cc tests have
> native_type_handle defined as a pointer type, and the pointed-to type is
> native_handle, the type of the single data
Hi Jakub,
> So given this and the fact there is no real gain from emitting tailcalls in
> eh_return
> functions, wouldn't it make more sense to always block tailcalls in the
> mid-end?
> No. E.g. x86 handles that just fine,
That's great to hear, but all the other targets still need to be
This patch to the Go frontend permits inlining variable declaration
statements. This adds all of two inlinable functions to the standard
library: crypto/subtle.ConstantTimeLessOrEq, regexp.(*Regexp).Copy.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
PING^1
On 4/29/19 1:01 PM, marxin wrote:
> The patch makes couple of adjustements:
> 1) I changed enum values to use capital letters. It's aligned with
>our coding style and it makes the code more readable. E.g.
>profile_quality::profile_guessed_local
>vs. static profile_probability
PING^1
On 5/3/19 12:59 PM, Martin Liška wrote:
> Hi.
>
> The patch prints all values requested in multiple --help options.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-05-03 Martin Liska
On 5/9/19 10:12 AM, marxin wrote:
>
> gcc/ChangeLog:
>
> 2019-05-09 Martin Liska
>
> * gcov.c (circuit): Ignore zero count arcs.
> ---
> gcc/gcov.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
Hi.
There's second version of the patch that was confirmed by the
On Thu, 9 May 2019 at 06:49, François Dumont wrote:
>
> Hi
>
> Patch similar to the one I just apply for deque iterator including
> NRVO copy ellision fix.
>
> * include/bits/stl_bvector.h
> (operator==(const _Bit_iterator_base&, const _Bit_iterator_base&)):
> Make hidden
This seems generally OK, but ...
On Fri, 10 May 2019, 05:59 François Dumont wrote:
> I remove several _M_map != nullptr checks cause in current
> implementation it can't be null. I have several patches following this
> one to support it but in this case we will be using a different code
When poking at some dwarf bugs, which were ultimately fixed by Richard,
I made a couple of cleanups. The first two are pretty obvious comment
clarification, but the last fragment is a more invasive control flow
change. In that case we essentially repeat an inline-static-var check
in two
On Fri, May 10, 2019 at 11:38:50AM +, Wilco Dijkstra wrote:
> > __builtin_eh_return is a noreturn call, and we never tail call optimize
> > noreturn calls:
> > if (flags & ECF_NORETURN)
> > {
> > maybe_complain_about_tail_call (exp, "callee does not return");
> > return false;
>
also value_id for inserted calls was uninitialized.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied to trunk and
branch.
Richard.
2019-05-10 Richard Biener
* tree-ssa-sccvn.c (visit_reference_op_call): Initialize value-id.
(do_rpo_vn): Initialize next_value_id.
Hi Jakub,
> __builtin_eh_return is a noreturn call, and we never tail call optimize
> noreturn calls:
> if (flags & ECF_NORETURN)
> {
> maybe_complain_about_tail_call (exp, "callee does not return");
> return false;
> }
> As both the __builtin_eh_return and other tail calls are
On Fri, May 10, 2019 at 10:25:58AM +, Wilco Dijkstra wrote:
> Hi Jakub,
>
> 27ec: 912143ffadd sp, sp, #0x850
> 27f0: 8b2463ffadd sp, sp, x4
> 27f4: 1400b 23c8 <_Unwind_RaiseException>
>
> > This does a lot of register
On 10/05/2019 00:33, co...@sdf.org wrote:
> On Tue, Apr 09, 2019 at 05:36:47PM +0100, Richard Earnshaw (lists) wrote:
>>> So we're well into stage4 which means technically it's too late for
>>> something like this. However, given it's limited scope I won't object
>>> if the ARM port maintainers
Hi,
> Would a shift_truncation_mask (rtx op, machine_mode mode) as replacement
> for SHIFT_COUNT_TRUNCATED and the old hook make more sense than just
> relying on the mode? That would be a way to alleviate the first counter
> argument to SHIFT_COUNT_TRUNCATED ("not flexible enough").
Well I
Hi Jakub,
27ec: 912143ffadd sp, sp, #0x850
27f0: 8b2463ffadd sp, sp, x4
27f4: 1400b 23c8 <_Unwind_RaiseException>
> This does a lot of register saving and restoring, which is not needed but is
> not wrong-code (guess
Hi all,
This patch fixes the failing gcc.dg/vect/slp-reduc-sad-2.c testcase on
aarch64
by implementing a vec_init optab that can handle two half-width vectors
producing a full-width one
by concatenating them.
In the gcc.dg/vect/slp-reduc-sad-2.c case it's a V8QI reg concatenated
with a V8QI
Hi.
One obvious fix seen be Bernhard.
Martin
gcc/ChangeLog:
2019-05-10 Martin Liska
* params.def (PARAM_GIMPLE_FE_COMPUTED_HOT_BB_THRESHOLD):
Fix plural form.
---
gcc/params.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/params.def
On Fri, May 10, 2019 at 11:04:12AM +0200, Martin Liška wrote:
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -1906,6 +1906,9 @@ typedef struct ix86_args {
>
> #define CLEAR_RATIO(speed) ((speed) ? MIN (6, ix86_cost->move_ratio) : 2)
>
> +/* C library provides fast
>> Bit tests on x86 also truncate [1], if the bit base operand specifies
>> a register, and we don't use BT with a memory location as a bit base.
>> I don't know what is referred with "(real or pretended) bit field
>> operations" in the documentation for SHIFT_COUNT_TRUNCATED:
>>
>> However,
Hi.
This is updated version of the patch I've sent here:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00149.html
The patch is about introduction of a new target macro that will
drive how we expand mempcpy. Having a target with
TARGET_HAS_FAST_MEMPCPY_ROUTINE == 1,
we do not expand using
Hello,
this is a follow-up from a WIP patch I sent here in late December:
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01765.html
Just like the last time, the patch below is is a reimplementation of
IPA-SRA to make it a full IPA pass that can handle strictly connected
components in the
On Fri, May 10, 2019 at 9:42 AM Richard Biener
wrote:
>
> On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
> >
> > On Fri, May 10, 2019 at 9:10 AM Richard Biener
> > wrote:
> > >
> > > On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
> > > >
> > > > >> Event SHIFT_COUNT_TRUNCATED is no
Hi!
My recent patch for tail call improvement apparently affects also the
_Unwind_Resume_or_Rethrow function in libgcc:
_Unwind_Reason_Code __attribute__((optimize ("no-omit-frame-pointer")))
_Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
{
struct _Unwind_Context this_context,
On Fri, May 03, 2019 at 09:10:39AM +0200, Jakub Jelinek wrote:
> On Fri, Apr 26, 2019 at 05:45:27PM +0200, Jakub Jelinek wrote:
> > 2019-04-26 Jakub Jelinek
> >
> > PR debug/90197
> > * cp-gimplify.c (genericize_cp_loop): Emit a DEBUG_BEGIN_STMT
> > before the condition (or if
Hi!
Some arm options are unfortunately the only exception when store_merge
predicate is true even on a target with STRICT_ALIGNMENT, in which case we
can't really do what the testcase wants to test, an unaligned store covering
the 3 separate stores. There are other testcases that already have to
Committed to trunk as revision 271057.
Will do likewise with 9-branch asap.
Cheers
Paul
On Wed, 8 May 2019 at 19:40, Paul Richard Thomas
wrote:
>
> Unless there are any objections to this patch, I plan to commit to
> trunk and 9-branch tomorrow night, with the change to the testcase
> pointed
Hi!
The following testcase failed with C++ but succeeded with C.
The problem was that c-family/c-cppbuiltin.c was registered for GTY
only for C, ObjC and ObjC++, but not for C++, so
lazy_hex_fp_values[...].hex_str was garbage after reading the PCH file.
The first hunk fixes that, on the other
On 5/10/19 9:26 AM, Jakub Jelinek wrote:
> On Fri, May 10, 2019 at 09:19:54AM +0200, Martin Liška wrote:
>> Hi.
>>
>> When I did split of i386.c I forgot to rebased this patch. It caused failure
>> of gcc.target/i386/fpprec-1.c execution test.
>>
>> Thank you Jeff for reporting that.
>>
>> I'm
On Fri, May 10, 2019 at 09:32:00AM +0200, Richard Biener wrote:
> OK. Note in general canonicalization might be necessary if
> we have any DECL_VALUE_EXPRs resolved.
We only resolve DECL_VALUE_EXPRs in gimple_regimplify_operands I believe,
during copy_fn we don't have any gimple statements plus
On Fri, May 10, 2019 at 9:25 AM Uros Bizjak wrote:
>
> On Fri, May 10, 2019 at 9:10 AM Richard Biener
> wrote:
> >
> > On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
> > >
> > > >> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
> > > >> does because we always only
On Fri, 10 May 2019, Jakub Jelinek wrote:
> Hi!
>
> Based on the single testcase we had I thought the rest of parloops will
> handle the exit PHIs with non-SSA_NAME arguments just fine, but this patch
> shows that is not the case and doesn't seem trivial to fix (just punting
> on the other ICE
On Fri, 10 May 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcases are rejects-valid or wrong-code, because
> when we make copies of the function for constexpr evaluation purposes (the
> primary intent is have the functions as is, with no folding whatsoever, so
> we diagnose
Hi!
Based on the single testcase we had I thought the rest of parloops will
handle the exit PHIs with non-SSA_NAME arguments just fine, but this patch
shows that is not the case and doesn't seem trivial to fix (just punting
on the other ICE spot doesn't work). As both the testcases are about
On Fri, May 10, 2019 at 09:19:54AM +0200, Martin Liška wrote:
> Hi.
>
> When I did split of i386.c I forgot to rebased this patch. It caused failure
> of gcc.target/i386/fpprec-1.c execution test.
>
> Thank you Jeff for reporting that.
>
> I'm going to install the patch.
Ok. Have you verified
On Fri, May 10, 2019 at 9:10 AM Richard Biener
wrote:
>
> On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
> >
> > >> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
> > >> does because we always only consider the last 6 bits of a shift operand.>
> > >> Despite all the
Hi.
When I did split of i386.c I forgot to rebased this patch. It caused failure
of gcc.target/i386/fpprec-1.c execution test.
Thank you Jeff for reporting that.
I'm going to install the patch.
gcc/ChangeLog:
2019-05-10 Martin Liska
* config/i386/i386-expand.c
Hi!
The following testcases are rejects-valid or wrong-code, because
when we make copies of the function for constexpr evaluation purposes (the
primary intent is have the functions as is, with no folding whatsoever, so
we diagnose everything), the inliner used under the hood to copy the function
On Thu, May 9, 2019 at 11:59 AM Thomas Schwinge wrote:
>
> Hi!
>
> On Wed, 13 Feb 2019 14:47:36 +0100, Richard Biener
> wrote:
> > On February 13, 2019 6:53:17 AM GMT+01:00, "Martin Liška"
> > wrote:
> > >As Honza noticed, there's still some leftover from MPX removal.
> > >May I remove
On Fri, May 10, 2019 at 12:44 AM Uros Bizjak wrote:
>
> >> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
> >> does because we always only consider the last 6 bits of a shift operand.>
> >> Despite all the warnings in the other backends, most notably
> >>
On Thu, May 9, 2019 at 6:00 PM Jeff Law wrote:
>
> On 5/9/19 5:52 AM, Robin Dapp wrote:
> > Hi,
> >
> > while trying to improve s390 code generation for rotate and shift I
> > noticed superfluous subregs for shift count operands. In our backend we
> > already have quite cumbersome patterns that
On 7 May 2019 14:00:32 CEST, "Martin Liška" wrote:
/The parameters is/s/parameters/parameter/
thanks,
83 matches
Mail list logo
