Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

On 03/10/2017 09:20 AM, Martin Sebor wrote: On 03/10/2017 05:57 AM, Rainer Orth wrote: Hi Segher, On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote: Segher Boessenkool writes: As stated in the PR, this test now passes on aarch64, ia64, powerpc, and

[PATCH 6/7 v2] i386.c: make "sorry" message more amenable to translation (PR target/79926)

On Fri, 2017-03-10 at 07:33 +0100, Jakub Jelinek wrote: > On Thu, Mar 09, 2017 at 12:45:28PM -0500, David Malcolm wrote: > > PR target/79926 notes that in: > > > > sorry ("%s instructions aren't allowed in %s service routine", > >isa, (cfun->machine->func_type == TYPE_EXCEPTION > >

Re: [PATCH, doc] Revise GCC manual section 6.11, Additional Floating Types

On Thu, 9 Mar 2017, Bill Schmidt wrote: > The one statement I've made that I'm not quite confident is that > __float128 is an alias for _Float64x on hppa HP-UX. This was not > clear in the original text, so I'd appreciate confirmation or > correction on this point. It can't simultaneously be an

Re: [PATCH 2/7] aarch64.c: tweaks to quoting in error messages (PR target/79925)

On Thu, 9 Mar 2017, David Malcolm wrote: > gcc/ChangeLog: > PR target/79925 > * config/aarch64/aarch64.c (aarch64_validate_mcpu): Quote the > full command-line argument, rather than just "str". > (aarch64_validate_march): Likewise. > (aarch64_validate_mtune):

Re: [PATCH 0/7] Various i18n fixes (and questions)

On Thu, 9 Mar 2017, David Malcolm wrote: > However, we're deep in stage 4 of the development cycle. Looking at > our development plan > https://gcc.gnu.org/develop.html > it's not clear to me how such changes fit into our schedule: the plan > seems to make no mention of how i18n and

Re: C PATCH to tidy implicit_decl_warning

On Mon, 6 Mar 2017, Marek Polacek wrote: > I didn't like that the function implicit_decl_warning is > a) missing a comment, > b) missing braces in an if were confusing, > b) wrongly formatted, >else > if () >is ugly. > > This patches fixes the above. > > Bootstrapped/regtested on

Re: [PATCH 3/7] Remove trailing period from various diagnostic messages (PR translation/79923)

On Fri, 2017-03-10 at 09:24 +, Kyrill Tkachov wrote: > On 10/03/17 06:24, Jakub Jelinek wrote: > > On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote: > > > gcc/ChangeLog: > > > PR translation/79923 > > > * auto-profile.c (get_combined_location): Convert leading > > >

Combiner fix for PR79910

In this PR, we have a few insns involved in two instruction combinations: insn 16: set r100 insn 27: some calculation insn 28: some calculation insn 32: using r100 insn 33: using r100 insn 35: some calculation Then we combine insns 27, 28 and 33, producing two output insns, As a result, insn

Re: [C++ Patch/RFC] PR 77752

Hi, On 10/03/2017 16:57, Jason Merrill wrote: On Fri, Mar 10, 2017 at 9:58 AM, Paolo Carlini wrote: As such, the broken declaration cannot be rejected by the code we have in finish_struct, something must happen earlier than that. It seems to me that xref_tag_1 can be

Re: stabilize store merging

On Mar 10, 2017, Alexandre Oliva wrote: > Now, if there's something you dislike about maps, we could make it a > doubly-linked list, or maybe even a singly-linked list. Scratch that, there's a use that may remove after a lookup by base_addr, so a singly-linked list would

Re: Fix IRA issue, PR79728

Ping (minus the require-effective-target line, as Uros pointed out). Bernd On 03/03/2017 02:51 PM, Bernd Schmidt wrote: This is an ICE where setup_pressure_classes fails if xmm0 is a global reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only SSE_FIRST_REG as the third register class.

Re: stabilize store merging

On Mar 10, 2017, Richard Biener wrote: >>> So - if we fix this can we fix it by properly sorting things? >> I don't see a way to do better, considering there's no real ID we could >> use for sorting. Do you? > Just use the ID you use but instead of maintaining a

[PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

Hello. As briefly discussed in the PR, there are BB that do not correspond to a real line in source code. profile.c emits locations for all BBs that have a gimple statement belonging to a line. I hope these should be marked in gcov utility and not added in --all-block mode to counts of lines.

Re: [PATCH 1/7] Add missing punctuation to message (PR driver/79875)

On Thu, 2017-03-09 at 21:12 -0700, Martin Sebor wrote: > On 03/09/2017 10:45 AM, David Malcolm wrote: > > gcc/ChangeLog: > > PR driver/79875 > > * opts.c (parse_sanitizer_options): Add missing question mark > > to > > "did you mean" message. > > --- > > gcc/opts.c | 2 +- > > 1 file

Re: [PATCH] Improve VRP for IMAGPART_EXPR of ATOMIC_COMPARE_EXCHANGE ifn (PR tree-optimization/79981)

On March 10, 2017 6:56:40 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The following patch teaches VRP that IMAGPART_EXPR of >ATOMIC_COMPARE_EXCHANGE ifn call is always 0 or 1. We cast it to bool >afterwards, but this hint allows VRP to: >--- pr79981.c.103t.vrp1_ 2017-03-10

[PATCH] Build crt*vr.S with AltiVec enabled

These files won't build on targets that do not have AltiVec enabled, breaking the build, unless we tell GAS that Altivec insns are fine. The alternative is to not build these files in that case, which is much more complicated. Tested on powerpc64-linux {-m64,-m32}, powerpc64le-linux, and on

Re: [PATCH, rs6000] Remove orphaned VMUL*_UNS built-ins

Thanks! Committed in revision 246046. > On Mar 10, 2017, at 1:14 PM, Segher Boessenkool > wrote: > > On Fri, Mar 10, 2017 at 12:16:31PM -0600, Bill Schmidt wrote: >> Jakub observed that these built-ins are no longer reachable (and >> haven't been for quite a

Re: [PATCH, rs6000] Remove orphaned VMUL*_UNS built-ins

On Fri, Mar 10, 2017 at 12:16:31PM -0600, Bill Schmidt wrote: > Jakub observed that these built-ins are no longer reachable (and > haven't been for quite a while). Time to chuck them out. > > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with > (surprise!) no regressions. Is this ok

Re: [PATCH] Fix out-of-bounds write in RTL function reader (PR bootstrap/79952)

On 03/10/2017 08:03 PM, David Malcolm wrote: print-rtl.c:rtx_writer::print_rtx_operand_code_0 has some special -casing for SYMBOL_REF, but if I'm reading things right we don't yet dump SYMBOL_REF_BLOCK and SYMBOL_REF_BLOCK_OFFSET, so we'd need to dump these somehow. Yeah. Perhaps as an extra

Re: [PATCH] Fix out-of-bounds write in RTL function reader (PR bootstrap/79952)

On Fri, 2017-03-10 at 00:36 +0100, Bernd Schmidt wrote: > On 03/09/2017 08:28 PM, David Malcolm wrote: > > The root cause is an out-of-bounds memory write in the RTL dump > > reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO > > set. > > > > Such SYMBOL_REFs are normally created by

Re: [PATCH] Decrease compile time memory with heavy find_base_{value,term} on i?86/x86_64 (PR rtl-optimization/63191)

On Fri, Mar 10, 2017 at 07:52:37PM +0100, Bernd Schmidt wrote: > On 03/10/2017 06:53 PM, Jakub Jelinek wrote: > > + > > +template > > +static inline rtx > > +ix86_delegitimize_address_tmpl (rtx x) > > { > > Why is this a template and not a function arg? That was just an attempt to ensure that

Re: [PATCH] Decrease compile time memory with heavy find_base_{value,term} on i?86/x86_64 (PR rtl-optimization/63191)

On 03/10/2017 06:53 PM, Jakub Jelinek wrote: + +template +static inline rtx +ix86_delegitimize_address_tmpl (rtx x) { Why is this a template and not a function arg? Bernd

[patch, libgfortran] PR78854 [F03] DTIO namelist output not working on internal unit

Hi all, The attached patch fixes this PR by properly stashing the internal unit created by parent so that it may be correctly accessed by the child DTIO procedure. Note the included test case. The Fortran Standard requires that the iotype be passed to the child routine so that it is aware of

[PATCH, rs6000] Remove orphaned VMUL*_UNS built-ins

Hi, Jakub observed that these built-ins are no longer reachable (and haven't been for quite a while). Time to chuck them out. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with (surprise!) no regressions. Is this ok for trunk? Thanks, Bill 2017-03-10 Bill Schmidt

[PATCH] Improve VRP for IMAGPART_EXPR of ATOMIC_COMPARE_EXCHANGE ifn (PR tree-optimization/79981)

Hi! The following patch teaches VRP that IMAGPART_EXPR of ATOMIC_COMPARE_EXCHANGE ifn call is always 0 or 1. We cast it to bool afterwards, but this hint allows VRP to: --- pr79981.c.103t.vrp1_2017-03-10 15:39:29.0 +0100 +++ pr79981.c.103t.vrp1 2017-03-10 15:48:15.051608067 +0100

[PATCH] rs6000: float128 on BE and 32-bit

This fixes float128 on BE and on 32-bit. The configure tests need to use -mabi=altivec for 32-bit, since it is not the default there. That also enables the "vector" keyword, used by the tests. To do this it temporarily adds a few flags to the CFLAGS variable. It also fixes a syntax error in

[PATCH] Decrease compile time memory with heavy find_base_{value,term} on i?86/x86_64 (PR rtl-optimization/63191)

Hi! On the testcase in the PR (too large for our testsuite) we waste several gigabytes of memory from allocations in ix86_delegitimize_address called from find_base_{value,term}. E.g. for find_base_term (plus:SI (value:SI 1:1 @0x2c60f50/0x2c50f40) (const:SI (plus:SI (unspec:SI [

[PATCH] [ADA] Fix bootstrap failure on mips64el-linux-gnuabi64

Hi, This patch fixes an error caused by my changing of the signal constants on MIPS in r244026. While that patch worked on mipsel, ada fails to bootstrap with it on mips64el with the error: s-osinte.ads:610:07: component "sa_flags" overlaps "sa_handler" at line 608 ../gcc-interface/Makefile:297:

C++ PATCH for c++/79960, partial ordering with alias template

The semantics of alias templates are still pretty unclear, but this testcase looks like it ought to work. I decided to make it work by treating partial ordering specially; while normally a use of a non-transparent alias template compares as distinct from its expansion, as necessary for proper

Re: [PING 6, PATCH] Remove xfail from thread_local-order2.C.

On Mar 10, 2017, at 8:22 AM, Jiong Wang wrote: > > I am seeing this failure on arm and aarch64 bare-metal environment where > newlib are used. > > This patch also XFAIL this testcase on newlib. > > OK for trunk? That's fine, if you want. The other solution is to

Re: [PATCH] [PATCH, rs6000] Fix pr79941 (v2)

Just so there's no duplication of effort -- I'll follow up with a patch to remove the outdated built-in. -- Bill Bill Schmidt, Ph.D. GCC for Linux on Power Linux on Power Toolchain IBM Linux Technology Center wschm...@linux.vnet.ibm.com > On Mar 10, 2017, at 8:24 AM, Bill Schmidt

Re: [PING 6, PATCH] Remove xfail from thread_local-order2.C.

On 07/02/17 16:01, Mike Stump wrote: On Feb 7, 2017, at 2:20 AM, Rainer Orth wrote: No. In fact, I'd go for something like this: 2017-02-07 Dominik Vogt Rainer Orth *

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

On 03/10/2017 05:57 AM, Rainer Orth wrote: Hi Segher, On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote: Segher Boessenkool writes: As stated in the PR, this test now passes on aarch64, ia64, powerpc, and s390x. This patch disables the xfails for

Re: [PATCH] PR libstdc++/79789 fix non-reserved names in headers

On Fri, Mar 10, 2017 at 10:20 AM, Jonathan Wakely wrote: > On 09/03/17 19:46 +, Jonathan Wakely wrote: >> >> On 03/03/17 10:47 -0500, David Edelsohn wrote: >>> >>> This patch caused a new regression on AIX. >> >> >> I'm unable to bootstrap on either gcc111 or gcc119 so I

Re: [C++ Patch/RFC] PR 77752

On Fri, Mar 10, 2017 at 9:58 AM, Paolo Carlini wrote: > As such, the broken declaration cannot be rejected by the code we have in > finish_struct, something must happen earlier than that. It seems to me that > xref_tag_1 can be a good place, per the below patchlet, which

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

On Fri, Mar 10, 2017 at 01:57:31PM +0100, Rainer Orth wrote: > I just noticed that nothing has happened at all in a month, so anything > is better than the tests XPASSing on a number of targets. > > So the patch is ok for mainline with sparc*-*-* added to the target > lists and a reference to PR

Re: [v3 PATCH] Make optional's comparisons be two-parameter templates.

On 19/02/17 17:53 +0200, Ville Voutilainen wrote: This has not been adopted by LEWG/LWG yet, but was submitted as a proposed resolution for a new LWG issue; optional can't current be compared to a T, and an optional can't be compared to something non-T that is comparable to a T. This approach

Re: [C++ PATCH] Fix error-recovery in maybe_thunk_body (PR c++/79899)

OK. On Tue, Mar 7, 2017 at 2:03 PM, Jakub Jelinek wrote: > Hi! > > Apparently in error recovery, populate_clone_array can't return fns > with all NULLs. maybe_thunk_body used to handle that fine, but > the newly added ctor_omit_inherited_parms call ICEs. > > Fixed thusly,

Re: [PATCH] PR libstdc++/79789 fix non-reserved names in headers

On 09/03/17 19:46 +, Jonathan Wakely wrote: On 03/03/17 10:47 -0500, David Edelsohn wrote: This patch caused a new regression on AIX. I'm unable to bootstrap on either gcc111 or gcc119 so I can't test the fix. export CONFIG_SHELL=/usr/bin/bash PATH=/opt/freeware/bin:$PATH

Re: C++ PATCH to fix segv with [[noreturn]] (PR c++/79967)

OK. On Fri, Mar 10, 2017 at 6:48 AM, Marek Polacek wrote: > Not sure of the validity of the test, but clang accepts it and so do we, > with this patch. We shouldn't attempt to dereference a pointer that > could be NULL without checking it first. > > Bootstrapped/regtested on

Re: [C++ PATCH] Fix error-recovery for invalid enumerators (PR c++/79896)

OK. On Tue, Mar 7, 2017 at 2:00 PM, Jakub Jelinek wrote: > Hi! > > Doing copy_node on error_mark_node doesn't work too well, lots of spots > in the compiler assume there is just a single error_mark_node and compare > it using pointer comparison, rather than checking for

[PR 77333] Fix fntypes of calls calling clones

Hi, PR 77333 is a i686-windows target bug, which however has its root in our general mechanism of adjusting gimple statements when redirecting call graph edge. Basically, these three things trigger it: 1) IPA-CP figures out that the this parameter of a C++ class method is unused and because

[C++ Patch/RFC] PR 77752

Hi, if you like, this ICE is closely related to c++/60848, but occurs when we don't have (yet) a broken definition of std::initializer_list, only a declaration, which is nonetheless able to cause an ICE at the beginning of build_list_conv, as called by implicit_conversion for the testcase at

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

On Fri, Mar 10, 2017 at 03:31:39PM +0100, Rainer Orth wrote: > Hi Toma, > > >> I just noticed that nothing has happened at all in a month, so anything > >> is better than the tests XPASSing on a number of targets. > >> > >> So the patch is ok for mainline with sparc*-*-* added to the target > >>

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

Hi Toma, >> I just noticed that nothing has happened at all in a month, so anything >> is better than the tests XPASSing on a number of targets. >> >> So the patch is ok for mainline with sparc*-*-* added to the target >> lists and a reference to PR testsuite/79356 in the comment. >> >> I'd

Re: [PATCH] [PATCH, rs6000] Fix pr79941 (v2)

Jumping in so we can continue the Will/Bill confusion: ;) The official prototypes from the original AltiVec PIM are: vector unsigned short vec_mule (vector unsigned char, vector unsigned char); vector signed short vec_mule (vector signed char, vector signed char); vector unsigned int vec_mule

Re: [PATCH] [PATCH, rs6000] Fix pr79941 (v2)

On Fri, Mar 10, 2017 at 08:08:06AM -0600, Will Schmidt wrote: > > > --- /dev/null > > > +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c > > > @@ -0,0 +1,61 @@ > > > +/* PR target/79941 */ > > > + > > > +/* { dg-do run } */ > > > +/* { dg-require-effective-target powerpc_vsx_ok } */ > >

RE: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

> > I just noticed that nothing has happened at all in a month, so anything > is better than the tests XPASSing on a number of targets. > > So the patch is ok for mainline with sparc*-*-* added to the target > lists and a reference to PR testsuite/79356 in the comment. > > I'd still be very

Re: [PATCH rs6000] Fix PR79907

On 03/09/2017 04:26 PM, Segher Boessenkool wrote: > That looks correct. Okay for trunk, thanks! Does it need backporting > as well? The -mupper-regs-di support is new in GCC 7 and I verified the testcase compiles fine with GCC 5/6, so no backporting necessary. -Pat

Re: [PATCH] [PATCH, rs6000] Fix pr79941 (v2)

On Thu, 2017-03-09 at 17:24 -0600, Segher Boessenkool wrote: > Hi Will, > > On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote: > > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those > > entries were added to the intrinsics-to-be-folded list where the generic > >

[PATCH] MPX: fix PR middle-end/79753

Hello. Currently, __builtin_ia32_bndret is used for all functions that have non-void return type. I think the right fix is to return bounds just for a bounded type. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Martin >From

Re: [PATCH] MPX: Fix option handling.

On Fri, Mar 10, 2017 at 02:09:20PM +0100, Martin Liška wrote: > Hello. > > This is follow-up patch which I agreed on with Jakub. > It enables CHKP with LSAN and majority of UBSAN options. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? >

[PATCH] MPX: Fix option handling.

Hello. This is follow-up patch which I agreed on with Jakub. It enables CHKP with LSAN and majority of UBSAN options. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Martin >From a410d5e4e028d34dc00b4aa637cdcd3986b971d8 Mon Sep 17 00:00:00 2001

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

Hi Segher, > On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote: >> Segher Boessenkool writes: >> >> > As stated in the PR, this test now passes on aarch64, ia64, powerpc, >> > and s390x. This patch disables the xfails for those targets. >> >> As I'd

Re: [libstdc++-v3] Fix detection of obsolete isnan

On 10/03/17 12:12 +, Richard Sandiford wrote: libstdc++-v3 configure checks whether old glibc inline definitions of isnan would conflict with the libstdc++-v3 definitions and works around them if so. But if g++ 6.x build A is used to build another g++ 6.x B, the configure step for B will

[libstdc++-v3] Fix detection of obsolete isnan

libstdc++-v3 configure checks whether old glibc inline definitions of isnan would conflict with the libstdc++-v3 definitions and works around them if so. But if g++ 6.x build A is used to build another g++ 6.x B, the configure step for B will pick up the math.h installed alongside A instead of

Re: [PATCH] Remove __gnu_pbds::detail::binary_heap::is_heap (PR libstdc++/62045) [resend]

On 10/03/17 19:36 +0800, Xi Ruoyao wrote: Hi, This was resent to be in both libstdc++ and gcc-patches list. Thanks. The ill-formed checking in binary_heap::push_heap has made it O(n). Remove this checking. The checking certainly looks redundant, I wouldn't say ill-formed though (that's a

C++ PATCH to fix segv with [[noreturn]] (PR c++/79967)

Not sure of the validity of the test, but clang accepts it and so do we, with this patch. We shouldn't attempt to dereference a pointer that could be NULL without checking it first. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2017-03-10 Marek Polacek PR

[PATCH] Remove __gnu_pbds::detail::binary_heap::is_heap (PR libstdc++/62045) [resend]

Hi, This was resent to be in both libstdc++ and gcc-patches list. The ill-formed checking in binary_heap::push_heap has made it O(n). Remove this checking. Since assert_valid also checks if (*this) is a legal heap, we can remove is_heap and the assertions using it completely. Bootstrapped and

Re: [PATCH] Remove __gnu_pbds::detail::binary_heap::is_heap (PR libstdc++/62045)

On Fri, Mar 10, 2017 at 07:18:24PM +0800, Xi Ruoyao wrote: > Hi, > > The ill-formed checking in binary_heap::push_heap has made it > O(n). Remove this checking. > > Since assert_valid also checks if (*this) is a legal heap, we can > remove is_heap and the assertions using it completely. I think

[PATCH] Remove __gnu_pbds::detail::binary_heap::is_heap (PR libstdc++/62045)

Hi, The ill-formed checking in binary_heap::push_heap has made it O(n). Remove this checking. Since assert_valid also checks if (*this) is a legal heap, we can remove is_heap and the assertions using it completely. Bootstrapped and tested on x86_64-linux-gnu. 2017-03-09  Xi Ruoyao  

Re: fix spurious error from switch-conversion on overaligned types

> On Mar 10, 2017, at 10:20 , Richard Biener wrote: > >> Is this one OK ? > > Ok. Committing, thanks!

Re: stabilize store merging

On Fri, Mar 10, 2017 at 12:02 AM, Alexandre Oliva wrote: > On Mar 8, 2017, Richard Biener wrote: > >> On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva wrote: >>> Don't let pointer randomization change the order in which we

Re: [PATCH 3/7] Remove trailing period from various diagnostic messages (PR translation/79923)

On 10/03/17 09:30, Jakub Jelinek wrote: On Fri, Mar 10, 2017 at 09:24:18AM +, Kyrill Tkachov wrote: On 10/03/17 06:24, Jakub Jelinek wrote: On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote: gcc/ChangeLog: PR translation/79923 * auto-profile.c

Re: [PATCH 3/7] Remove trailing period from various diagnostic messages (PR translation/79923)

On Fri, Mar 10, 2017 at 09:24:18AM +, Kyrill Tkachov wrote: > > On 10/03/17 06:24, Jakub Jelinek wrote: > > On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote: > > > gcc/ChangeLog: > > > PR translation/79923 > > > * auto-profile.c (get_combined_location): Convert leading > > >

Re: [PATCH 3/7] Remove trailing period from various diagnostic messages (PR translation/79923)

On 10/03/17 06:24, Jakub Jelinek wrote: On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote: gcc/ChangeLog: PR translation/79923 * auto-profile.c (get_combined_location): Convert leading character of diagnostics to lower case and remove trailing period.

Re: fix spurious error from switch-conversion on overaligned types

On Thu, Mar 9, 2017 at 10:24 PM, Olivier Hainque wrote: >> Yes, unconditionally. > > Here's an adjusted patch, pleasantly simpler indeed > (thanks again for the suggestion). > > Test passes fine as well. > > Is this one OK ? Ok. Richard. > Olivier > > *