Re: [PATCH][X86] Enable X86_TUNE_AVX256_UNALIGNED_{LOAD, STORE}_OPTIMAL for generic tune [PR target/98172]

On Thu, Feb 4, 2021 at 5:28 AM Hongtao Liu wrote: > > > >GCC11 will be the system GCC 2 years from now, and for the > > > > processors then, they shouldn't even need to split a 256-bit vector > > > > into 2 128-bits vectors. > > > >.i.e. Test SPEC2017 with the below 2 options on Zen3/ICL

[pushed] c++: No aggregate CTAD with explicit dguide [PR98802]

In my implementation of P2082R1 I missed this piece: the aggregate deduction candidate is not generated if the class has user-written deduction guides. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: PR c++/98802 * pt.c (do_class_deduction): No aggregate guide

Re: [PATCH] [AVX512] Fix ICE: Convert integer mask to vector in ix86_expand_fp_vec_cmp/ix86_expand_int_vec_cmp [PR98537]

Rebase and update patch: Fix ICE: Don't generate integer mask comparison for 128/256-bits vector when op_true/op_false are NULL or constm1_rtx/const0_rtx [PR98537] in ix86_expand_sse_cmp/ix86_expand_int_sse_cmp gcc/ChangeLog: PR target/98537 *

Re: [PATCH][X86] Enable X86_TUNE_AVX256_UNALIGNED_{LOAD, STORE}_OPTIMAL for generic tune [PR target/98172]

On Thu, Jan 28, 2021 at 9:18 PM H.J. Lu wrote: > > On Thu, Jan 28, 2021 at 1:21 AM Richard Biener via Gcc-patches > wrote: > > > > On Thu, Jan 28, 2021 at 7:32 AM Hongtao Liu via Gcc-patches > > wrote: > > > > > > Hi: > > >GCC11 will be the system GCC 2 years from now, and for the > > >

[pushed] c++: subst failure in attribute argument [PR95192]

Another SFINAE issue: we weren't propagating substitution failure in attributes back up. And tsubst_function_decl needs to check substitution before register_specialization. I thought about moving the other error returns up as well, but they aren't SFINAE cases, so they can stay where they are.

Re: [PATCH] improve detection of incompatible redeclarations (PR 97882)

On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote: > +/* Return true of T1 and T2 are matching types for the purposes of > + redeclaring a variable or a function without a prototype (i.e., > + considering just its return type). */ I think this comment is confusing (it suggests it's

[PATCH] c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

Since most of volatile is deprecated in C++20, we are required to warn for compound assignments to volatile variables and so on. But here we have volatile int x, y, z; (b ? x : y) = 1; and we shouldn't warn, because simple assignments like x = 24; should not provoke the warning when they

[PATCH] improve detection of incompatible redeclarations (PR 97882)

The test case in the bug report shows that the C front end is too permissive in accepting invalid redeclarations that involve an incomplete enum and an otherwise compatible integer type as return types of a function without a prototype, or as types of an ordinary variable. For example, the

Re: [PATCH] adjust "partly out of bounds" warning (PR 98503)

On 2/3/21 2:57 PM, Jeff Law wrote: On 1/28/21 4:03 PM, Martin Sebor wrote: The GCC 11 -Warray-bounds enhancement to diagnose accesses whose leading offset is in bounds but whose trailing offset is not has been causing some confusion.  When the warning is issued for an access to an in-bounds

Re: [PATCH] libcpp: Fix up -fdirectives-only preprocessing [PR98882]

On 1/29/21 4:01 PM, Jakub Jelinek via Gcc-patches wrote: > Hi! > > GCC 11 ICEs on all -fdirectives-only preprocessing when the files don't end > with a newline. > > The problem is in the assertion, for empty TUs buffer->cur == buffer->rlimit > and so buffer->rlimit[-1] access triggers UB in the

Re: [PATCH] adjust "partly out of bounds" warning (PR 98503)

On 1/28/21 4:03 PM, Martin Sebor wrote: > The GCC 11 -Warray-bounds enhancement to diagnose accesses whose > leading offset is in bounds but whose trailing offset is not has > been causing some confusion.  When the warning is issued for > an access to an in-bounds member via a pointer to a

Re: [PATCH] doc: mention -mprefer-vector-width in target attrs

On 2/3/21 8:15 AM, Martin Liška wrote: > The patch documents -mprefer-vector-width which is a valid target > attribute/pragma. > > Ready for master? > Thanks, > Martin > > gcc/ChangeLog: > > * doc/extend.texi: Mention -mprefer-vector-width in target > attributes. > >

[committed] libphobos: Merge upstream druntime 9d0c8364, phobos 9d575282e.

Hi, This patch merges the D runtime library with upstream druntime 9d0c8364, and the standard library with upstream phobos 9d575282e. Adds bindings to libdruntime to replace extern(C) declarations found in the phobos part of the library, and fixes an issue with the locale bindings being

[wwwdocs] Mention C++23 flags and addition of size_t literals.

I pushed this patch to update changes to mention the C++23 flags and the size_t literals. Ed commit bfc68f3f88406a07757d111a0f894426a6bc4522 Author: Ed Smith-Rowland <3dw...@verizon.net > Date: Wed Feb 3 14:23:00 2021 -0500 Mention C++23 flags and P0330R8,

Re: [PATCH 2/2] RISC-V: Add riscv{32, 64}be with big endian as default

Kito Cheng writes: > Yeah, but I'd like to include following 2 lines too: > > %{mbig-endian:-EB} \ > %{mlittle-endian:-EL} \ > > I saw it's just the same among 3 files. Ah, I see. Then it becomes a little more of a mixed grab bag. I see that SuperH has a spec "subtarget_link_spec" which

Re: [PATCH] c++: Mark member functions as const [PR98951]

On 2/3/21 12:31 PM, Marek Polacek wrote: These member functions look like they could be marked const, since they don't modify any (non-mutable) class members. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK, I guess this is trivial enough for stage4. PR c++/98951

[AArch64] Fix vector multiplication costs

This patch introduces a vect.mul RTX cost and decouples the vector multiplication costing from the scalar one. After Wilco's "AArch64: Add cost table for Cortex-A76" patch we saw a regression in vector codegen. Reproduceable with the small test added in this patch. Upon further investigation

Re: Merge from trunk to gccgo branch

I merged trunk revision 530203d6e3244c25eda4124f0fa5756ca9a5683e to the gccgo branch. Ian

[pushed] c++: Fix alias comparison [PR98926]

The comparison of dependent aliases wasn't working here because processing_template_decl wasn't set, so dependent_alias_template_spec_p was always returning false. Tested x86_64-pc-linux-gnu (with the strict-gc parms below), applying to trunk. gcc/cp/ChangeLog: PR c++/98926 PR

[PATCH] c++: Mark member functions as const [PR98951]

These member functions look like they could be marked const, since they don't modify any (non-mutable) class members. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/98951 * call.c (struct z_candidate): Mark rewritten and reversed as const. (struct

Re: [PATCH] document BLOCK_ABSTRACT_ORIGIN et al.

On 2/3/21 5:01 AM, Richard Biener wrote: On Mon, Feb 1, 2021 at 5:20 PM Martin Sebor wrote: I have pushed the tree.h comments in g:6a2053773b8. I will wait for an approval of the changes to the manual. Sorry for not looking earlier. Sorry, I thought you were fine with the text after your

libgo patch committed: Install new packages

In the update of libgo to the Go 1.16 beta and release candidate, I forgot to update the Makefile to actually install new packages. This patch does that. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian 8e6839059d52c02acb52a4ba1ea6a5fcda88d16b diff --git

[PATCH] Fix Ada bootstrap failure on Cygwin since switch to C++11 (PR98590)

This fixes the bootstrap failure with Ada on Cygwin since the switch to C++11. The configure checks detect that fileno_unlocked () is present, but when Ada's cstreams.c is compiled in C++11 mode, does not declare it, causing a hard error. Fixed by defining _GNU_SOURCE before including . Ok for

[committed] testsuite: Add test for already fixed PR [PR97804]

Hi! This testcase got fixed with the PR98463 r11-6895-g94ff4c9dd98f39280fba22d1ad0958fb25a5363b fix. Regtested on x86_64-linux, committed to trunk and 10 branch. 2021-02-03 Jakub Jelinek PR c++/97804 * g++.dg/cpp2a/no_unique_address11.C: New test. ---

RE: [PATCH] arm: Fix up neon_vector_mem_operand [PR97528]

> -Original Message- > From: Andre Vieira (lists) > Sent: 03 February 2021 13:58 > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org > Cc: ja...@redhat.com > Subject: Re: [PATCH] arm: Fix up neon_vector_mem_operand [PR97528] > > Same patch applies cleanly on gcc-8, bootstrapped >

Re: [PATCH 00/16] stdx::simd fixes and testsuite improvements

On 27/01/21 21:36 +0100, Matthias Kretz wrote: As promised on IRC ... Matthias Kretz (15): Support skip, only, expensive, and xfail markers Fix NEON intrinsic types usage Support -mlong-double-64 on PPC Fix simd_mask on POWER w/o POWER8 Fix several check-simd interaction issues Fix

[committed] libstdc++: Fix incorrect test for std::error_code comparisons

The tests for std::error_code comparisons assumed that a default constructed object uses std::generic_category(). That's true for a default constructed std::error_condition, but not std::error_code. Fix the three-way comparisons to correctly depend on the result of comparing the categories, and

Re: [PATCH] doc: mention -mprefer-vector-width in target attrs

On Wed, Feb 03, 2021 at 04:15:24PM +0100, Martin Liška wrote: > The patch documents -mprefer-vector-width which is a valid target > attribute/pragma. > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index 8daa1c67974..a14875cec37 100644 > --- a/gcc/doc/extend.texi > +++

[PATCH] doc: mention -mprefer-vector-width in target attrs

The patch documents -mprefer-vector-width which is a valid target attribute/pragma. Ready for master? Thanks, Martin gcc/ChangeLog: * doc/extend.texi: Mention -mprefer-vector-width in target attributes. gcc/testsuite/ChangeLog: *

Re: [RFC] test builtin ratio for loop distribution

On Feb 3, 2021, Richard Biener wrote: > So I think we should try to match what __builtin_memcpy/memset > expansion would do here, taking advantage of extra alignment > and size knowledge. In particular, > a) if __builtin_memcpy/memset would use setmem/cpymem optabs > see if we can have

[committed] amdgcn: Add gfx908 support

This patch adds a new -march option and multilib configuration to the amdgcn GPU target. The patch does not attempt to support any of the new features of the gfx908 devices, but does set the correct ELF flags etc. that are expected by the ROCm runtime. The GFX908 devices are not generally

RE: [PATCH] aarch64: Use RTL builtins for [su]mlsl_high_lane[q] intrinsics

> -Original Message- > From: Jonathan Wright > Sent: 03 February 2021 12:43 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] aarch64: Use RTL builtins for [su]mlsl_high_lane[q] > intrinsics > > Hi, > > As subject, this patch rewrites [su]mlsl_high_lane[q] Neon

Re: [PATCH] arm: Fix up neon_vector_mem_operand [PR97528]

Same patch applies cleanly on gcc-8, bootstrapped arm-none-linux-gnueabihf and ran regressions also clean. Can I also commit it to gcc-8? Thanks, Andre On 02/02/2021 17:36, Kyrylo Tkachov wrote: -Original Message- From: Andre Vieira (lists) Sent: 02 February 2021 17:27 To:

RE: [PATCH] aarch64: Use RTL builtins for [su]mlal_high_lane[q] intrinsics

> -Original Message- > From: Jonathan Wright > Sent: 03 February 2021 12:39 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] aarch64: Use RTL builtins for [su]mlal_high_lane[q] > intrinsics > > Hi, > > As subject, this patch rewrites [su]mlal_high_lane[q] Neon

RE: [PATCH] aarch64: Use RTL builtins for [su]mlsl_high_n intrinsics

> -Original Message- > From: Jonathan Wright > Sent: 03 February 2021 12:35 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] aarch64: Use RTL builtins for [su]mlsl_high_n intrinsics > > Hi, > > As subject, this patch rewrites [su]mlsl_high_n Neon intrinsics to

Re: [PATCH] c++: ICE with late parsing of noexcept in nested class [PR98899]

On 2/2/21 5:09 PM, Marek Polacek wrote: Here we crash with a noexcept-specifier in a nested template class, because my handling of such deferred-parse noexcept-specifiers was gronked when we need to instantiate a DEFERRED_PARSE before it was actually parsed at the end of the outermost class. In

Re: c++: cross-module __cxa_atexit use [PR 98531]

[Dropping Richard, as I don't think his input is necessary further] Hi Rainer, here are two patches, to be applied in sequence (replacing earlier versions of the patch). The first is merely a testsuite correction of the earlier patch to inhibit the cxa_atexit-specific tests where it matters.

[PATCH] aarch64: Use RTL builtins for [su]mlsl_high_lane[q] intrinsics

Hi, As subject, this patch rewrites [su]mlsl_high_lane[q] Neon intrinsics to use RTL builtins rather than inline assembly code, allowing for better scheduling and optimization. Regression tested and bootstrapped on aarch64-none-linux-gnu and aarch64_be-none-elf - no issues. Ok for master?

[PATCH] aarch64: Use RTL builtins for [su]mlal_high_lane[q] intrinsics

Hi, As subject, this patch rewrites [su]mlal_high_lane[q] Neon intrinsics to use RTL builtins rather than inline assembly code, allowing for better scheduling and optimization. Regression tested and bootstrapped on aarch64-none-linux-gnu and aarch64_be-none-elf - no issues. Ok for master?

[PATCH] aarch64: Use RTL builtins for [su]mlsl_high_n intrinsics

Hi, As subject, this patch rewrites [su]mlsl_high_n Neon intrinsics to use RTL builtins rather than inline assembly code, allowing for better scheduling and optimization. Regression tested and bootstrapped on aarch64-none-linux-gnu and aarch64_be-none-elf - no issues. Ok for master? Thanks,

RE: [PATCH] aarch64: Use RTL builtins for [su]mlal_high_n intrinsics

> -Original Message- > From: Jonathan Wright > Sent: 03 February 2021 12:29 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] aarch64: Use RTL builtins for [su]mlal_high_n intrinsics > > Hi, > > As subject, this patch rewrites [su]mlal_high_n Neon intrinsics to

RE: [PATCH] aarch64: Use RTL builtins for [su]mlal_high intrinsics

> -Original Message- > From: Jonathan Wright > Sent: 03 February 2021 12:20 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] aarch64: Use RTL builtins for [su]mlal_high intrinsics > > Hi, > > As subject, this patch rewrites [su]mlal_high Neon intrinsics to use

[PATCH] aarch64: Use RTL builtins for [su]mlal_high_n intrinsics

Hi, As subject, this patch rewrites [su]mlal_high_n Neon intrinsics to use RTL builtins rather than inline assembly code, allowing for better scheduling and optimization. Regression tested and bootstrapped on aarch64-none-linux-gnu and aarch64_be-none-elf - no issues. Ok for master? Thanks,

[PATCH] aarch64: Use RTL builtins for [su]mlal_high intrinsics

Hi, As subject, this patch rewrites [su]mlal_high Neon intrinsics to use RTL builtins rather than inline assembly code, allowing for better scheduling and optimization. Regression tested and bootstrapped on aarch64-none-linux-gnu - no issues. Ok for master? Thanks, Jonathan ---

Re: [PATCH] Fill up padding in lto_section struct.

On Wed, Feb 03, 2021 at 12:58:12PM +0100, Martin Liška wrote: > The patch is about filling a padding byte that is later > streamed with memcpy. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > > gcc/ChangeLog: > >

Re: [PATCH] document BLOCK_ABSTRACT_ORIGIN et al.

On Mon, Feb 1, 2021 at 5:20 PM Martin Sebor wrote: > > I have pushed the tree.h comments in g:6a2053773b8. I will wait > for an approval of the changes to the manual. Sorry for not looking earlier. +/* The scope enclosing the scope NODE, or FUNCTION_DECL for the "outermost" + function scope.

[PATCH] Fill up padding in lto_section struct.

The patch is about filling a padding byte that is later streamed with memcpy. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ChangeLog: PR lto/98912 * lto-streamer-out.c (produce_lto_section): Fill up missing

[PATCH v2] c++: fix string literal member initializer bug [PR90926]

Update of https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562259.html build_aggr_conv did not correctly handle string literal member initializers. Extended can_convert_array to handle this case. For the additional check of compatibility of character types, factored out code from

Re: [PATCH] Add unordered containers heterogeneous lookup

On 03/02/21 11:23 +, Jonathan Wakely wrote: On 25/01/21 19:21 +0100, François Dumont via Libstdc++ wrote: I think I never got a clear answer that we'll wait for stage 1 to consider this patch so here is a ping. My concern with this patch is that it alters the existing code used for

Re: [PATCH] Add unordered containers heterogeneous lookup

On 25/01/21 19:21 +0100, François Dumont via Libstdc++ wrote: I think I never got a clear answer that we'll wait for stage 1 to consider this patch so here is a ping. My concern with this patch is that it alters the existing code used for non-heterogeneous lookups in C++11/14/17. I think if

Re: [RFC] Feedback on approach for adding support for V8QI->V8HI widening patterns

> Do you mean a v8qi->v8hi widening subtract or a v16qi->v8hi widening > subtract? I mean the latter, that seemed to be what richi was suggesting previously. > The problem with the latter is that we need to fill the > extra unused elements with something and remove them later. That's fair

Re: [RFC] Feedback on approach for adding support for V8QI->V8HI widening patterns

Joel Hutton writes: >>> So emit a v4qi->v8qi gimple conversion >>> then a regular widen_lo/hi using the existing backend patterns/optabs? >> >>I was thinking of using a v8qi->v8hi convert on each operand followed >>by a normal v8hi subtraction. That's what we'd generate if the target >>didn't

[Ada] Fix regression with partial rep clause on variant record type

It is present on the mainline, 10 and 9 branches, and can yield an incorrect layout when there is a partial representation clause on a discriminated record type with a variant part. Tested on x86-64/Linux, applied on mainline, 10 and 9 branches. 2021-02-03 Eric Botcazou *

Re: [RFC] Feedback on approach for adding support for V8QI->V8HI widening patterns

>> So emit a v4qi->v8qi gimple conversion >> then a regular widen_lo/hi using the existing backend patterns/optabs? > >I was thinking of using a v8qi->v8hi convert on each operand followed >by a normal v8hi subtraction. That's what we'd generate if the target >didn't define the widening patterns.

Re: [PATCH 2/4] openacc: Use class_pointer instead of pointer attribute for class types

On 02.02.21 14:28, Julian Brown wrote: Elsewhere in the Fortran front-end, the class_pointer attribute is used for BT_CLASS entities instead of the pointer attribute. [...]This patch follows suit for OpenACC. I couldn't actually come up with a test case where this makes a difference (i.e.,

[Ada] Assorted LTO fixes

This polishes a few rough edges visible in LTO mode. Tested on x86-64/Linux, applied on mainline, 10 and 9 branches. 2021-02-03 Eric Botcazou * gcc-interface/decl.c (gnat_to_gnu_entity) : Make the two fields of the fat pointer type addressable, and do not make the

Re: [RFC] Feedback on approach for adding support for V8QI->V8HI widening patterns

Joel Hutton writes: In practice this will only affect targets that choose to use mixed vector sizes, and I think it's reasonable to optimise only for the case in which such targets support widening conversions. So what do you think about the idea of emitting separate

Re: [RFC] Feedback on approach for adding support for V8QI->V8HI widening patterns

>>> In practice this will only affect targets that choose to use mixed >>> vector sizes, and I think it's reasonable to optimise only for the >>> case in which such targets support widening conversions. So what >>> do you think about the idea of emitting separate conversions and >>> a normal

Re: [PATCH] i386, df: Fix up gcc.c-torture/compile/20051216-1.c -O1 -march=cascadelake

Richard Biener writes: > On Tue, 2 Feb 2021, Richard Sandiford wrote: > >> Richard Biener writes: >> > On January 30, 2021 11:52:20 AM GMT+01:00, Jakub Jelinek >> > wrote: >> >>On Sat, Jan 30, 2021 at 11:47:24AM +0100, Richard Biener wrote: >> >>> OK, so I'd prefer we simply unset the flag

Re: [RFC] Feedback on approach for adding support for V8QI->V8HI widening patterns

Richard Biener writes: > On Tue, Feb 2, 2021 at 5:19 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Tue, Feb 2, 2021 at 4:03 PM Richard Sandiford >> > wrote: >> >> >> >> Richard Biener writes: >> >> > On Mon, Feb 1, 2021 at 6:54 PM Joel Hutton wrote: >> >> >> >> >> >> Hi

[PATCH] more memory leak fixes

This fixes more memory leaks as discovered by building 521.wrf_r. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-02-03 Richard Biener * lto-streamer.c (lto_get_section_name): Free temporary buffer. * tree-loop-distribution.c

[PATCH] rs6000: Convert the vector element register to SImode [PR98914]

v[k] will also be expanded to IFN VEC_SET if k is long type when built with -Og. -O0 didn't exposed the issue due to v is TREE_ADDRESSABLE, -O1 and above also didn't capture it because of v[k] is not optimized to VIEW_CONVERT_EXPR(v)[k_1]. vec_insert defines the element argument type to be signed

Re: [arm/testsuite]: Skip pr97969.c if -mthumb is not compatible [PR target/97969]

Ping? I guess that's obvious enough? On Wed, 27 Jan 2021 at 10:03, Christophe Lyon wrote: > > Depending on how the toolchain is configured or how the testsuite is > executed, -mthumb may not be compatible. Like for other tests, skip > pr97969.c in this case. > > For instance arm-linux-gnueabihf

Re: [RFC] test builtin ratio for loop distribution

On Tue, Feb 2, 2021 at 6:14 PM Alexandre Oliva wrote: > > On Jan 28, 2021, Richard Biener wrote: > > > That would allow turning back the memset into the original loop (but > > with optimal IVs, etc.). > > Is this sort of what you had in mind? > > I haven't tested the inline expansion of memset

Re: [PATCH] release pointer_query cache when done (PR 98937)

On Wed, Feb 3, 2021 at 1:15 AM Martin Sebor wrote: > > On 2/2/21 2:29 PM, David Malcolm wrote: > > On Tue, 2021-02-02 at 12:57 -0700, Martin Sebor via Gcc-patches wrote: > >> The strlen pass initializes its pointer_query member object with > >> a cache consisting of a couple of vec's. Because

Re: [PATCH]middle-end slp: Split out patterns away from using SLP_ONLY into their own flag

On Tue, 2 Feb 2021, Tamar Christina wrote: > Hi All, > > Previously the SLP pattern matcher was using STMT_VINFO_SLP_VECT_ONLY as a way > to dissolve the SLP only patterns during SLP cancellation. However it seems > like the semantics for STMT_VINFO_SLP_VECT_ONLY are slightly different than >

Re: [RFC] Feedback on approach for adding support for V8QI->V8HI widening patterns

On Tue, Feb 2, 2021 at 5:19 PM Richard Sandiford wrote: > > Richard Biener writes: > > On Tue, Feb 2, 2021 at 4:03 PM Richard Sandiford > > wrote: > >> > >> Richard Biener writes: > >> > On Mon, Feb 1, 2021 at 6:54 PM Joel Hutton wrote: > >> >> > >> >> Hi Richard(s), > >> >> > >> >> I'm just