Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Maciej W. Rozycki]

On Sun, 1 Dec 2024, Georg-Johann Lay wrote:

> > (I don't see this on gcc-patches and not subscribed to gcc-cvs so can't
> > bounce it.)
> 
> I got a
> 
>    >>> DATA (EOM)
>    <<< 550 5.7.1 rejected by DMARC policy for gjlay.de
> 
> Reporting-MTA: DNS; mo4-p00-ob.smtp.rzone.de
> Received-From-MTA: DNS; [192.168.2.102] (92.217.178.60)
> Arrival-Date: Sat, 30 Nov 2024 10:56:26 +0100 (CET)
> 
> Final-Recipient: RFC822; gcc-patches@gcc.gnu.org
> Action: failed
> Status: 5.7.1
> Remote-MTA: DNS; gcc.gnu.org [8.43.85.97:25]
> Diagnostic-Code: SMTP; 550 5.7.1 rejected by DMARC policy for gjlay.de
> Last-Attempt-Date:
> Final-Log-ID: xd5faa0AU9uVhK8
> 
> ForwardedMessage.eml
> Betreff:
> [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c
> ...
> 
> I don't know what's going wrong there, why it has been rejected and
> how to fix that.  I never got that error before.

 Have you asked the overseers (cc-ed now)?

  Maciej

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Mark Wielaard]

Hi,

On Mon, 2024-12-02 at 12:28 +0000, Maciej W. Rozycki via Overseers
wrote:
> On Sun, 1 Dec 2024, Georg-Johann Lay wrote:
> 
> > > (I don't see this on gcc-patches and not subscribed to gcc-cvs so can't
> > > bounce it.)
> > 
> > I got a
> > 
> >    >>> DATA (EOM)
> >    <<< 550 5.7.1 rejected by DMARC policy for gjlay.de
> > 
> > Reporting-MTA: DNS; mo4-p00-ob.smtp.rzone.de
> > Received-From-MTA: DNS; [192.168.2.102] (92.217.178.60)
> > Arrival-Date: Sat, 30 Nov 2024 10:56:26 +0100 (CET)
> > 
> > Final-Recipient: RFC822; gcc-patches@gcc.gnu.org
> > Action: failed
> > Status: 5.7.1
> > Remote-MTA: DNS; gcc.gnu.org [8.43.85.97:25]
> > Diagnostic-Code: SMTP; 550 5.7.1 rejected by DMARC policy for gjlay.de
> > Last-Attempt-Date:
> > Final-Log-ID: xd5faa0AU9uVhK8
> > 
> > ForwardedMessage.eml
> > Betreff:
> > [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c
> > ...
> > 
> > I don't know what's going wrong there, why it has been rejected and
> > how to fix that.  I never got that error before.
> 
>  Have you asked the overseers (cc-ed now)?

gjlay.de uses a string dmarc policy:
$ host -t txt _dmarc.gjlay.de
_dmarc.gjlay.de descriptive text "v=DMARC1;p=reject;"
And no SPF policy. That means that if the message doesn't pass dkim it
gets rejected.

We didn't used to reject such messages but just passed them on to the
list, but that caused the list members that checked the dmarc policy
the reject and bounce such messages, causing massive unsubscribes.

So we changed the settings to immediately reject such messages:
https://inbox.sourceware.org/gcc-patches/e137cda184f7c54a91bb3966c1d067c92095eda6.camel@klomp.org/
https://fosstodon.org/@sourceware/113432586649968904

Cheers,

Mark

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Georg-Johann Lay]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

Am 02.12.24 um 13:28 schrieb Maciej W. Rozycki:
> On Sun, 1 Dec 2024, Georg-Johann Lay wrote:
> 
>>> (I don't see this on gcc-patches and not subscribed to gcc-cvs so can't
>>> bounce it.)
>>
>> I got a
>>
>>     >>> DATA (EOM)
>>     <<< 550 5.7.1 rejected by DMARC policy for gjlay.de
>>
>> Reporting-MTA: DNS; mo4-p00-ob.smtp.rzone.de
>> Received-From-MTA: DNS; [192.168.2.102] (92.217.178.60)
>> Arrival-Date: Sat, 30 Nov 2024 10:56:26 +0100 (CET)
>>
>> Final-Recipient: RFC822; gcc-patches@gcc.gnu.org
>> Action: failed
>> Status: 5.7.1
>> Remote-MTA: DNS; gcc.gnu.org [8.43.85.97:25]
>> Diagnostic-Code: SMTP; 550 5.7.1 rejected by DMARC policy for gjlay.de
>> Last-Attempt-Date:
>> Final-Log-ID: xd5faa0AU9uVhK8
>>
>> ForwardedMessage.eml
>> Betreff:
>> [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c
>> ...
>>
>> I don't know what's going wrong there, why it has been rejected and
>> how to fix that.  I never got that error before.
> 
>   Have you asked the overseers (cc-ed now)?
> 
>    Maciej

Not yet, but it just happened again, and I don't know what to do.
Just send the same email again until it succeeds.

For reference, here is the attachment; I don't see anything offensive
there...

Johann

--
*** MAILVERSAND FEHLERBERICHT ***

Die E-Mail wurde eingeliefert am Mittwoch, 4. Dezember 2024 16:37:58 
+0100 (CET)
von Host [192.168.2.102]   .

Betreff: [patch,avr] PR107957 - Split multi-byte loads and stores.
Absender: avr@gjlay.de

Der Mailversand zum folgenden Empfänger ist endgültig gescheitert:

gcc-patches@gcc.gnu.org
    Letzter Fehler: 550 5.7.1
    Erklärung: host gcc.gnu.org [8.43.85.97:25] said: rejected by DMARC 
policy for
               gjlay.de

    Auszug aus dem Session-Protokoll:
    ... während der Kommunikation mit dem Mailserver gcc.gnu.org 
[8.43.85.97:25]:
    >>> DATA (EOM)
    <<< 550 5.7.1 rejected by DMARC policy for gjlay.de

--

This patch splits multi-byte loads and stores into single-byte
ones provided:

-  New option -msplit-ldst is on (e.g. -O2 and higher), and
-  The memory is non-volatile, and
-  The address space is generic, and
-  The split addresses are natively supported by the hardware.

Passes without regressions.  Ok for trunk?

Johann

-- 

AVR: target/107957 - Split multi-byte loads and stores.

This patch splits multi-byte loads and stores into single-byte
ones provided:

-  New option -msplit-ldst is on (e.g. -O2 and higher), and
-  The memory is non-volatile, and
-  The address space is generic, and
-  The split addresses are natively supported by the hardware.

gcc/
     PR target/107957
     * config/avr/avr.opt (-msplit-ldst, avropt_split_ldst):
     New option and associated var.
     * common/config/avr/avr-common.cc (avr_option_optimization_table)
     [OPT_LEVELS_2_PLUS]: Turn on -msplit_ldst.
     * config/avr/avr-passes.cc (splittable_address_p)
     (avr_byte_maybe_mem, avr_split_ldst): New functions.
     * config/avr/avr-protos.h (avr_split_ldst): New proto.
     * config/avr/avr.md (define_split) [avropt_split_ldst]: Run
     avr_split_ldst().




[-- Attachment #2: split-ldst.diff --]
[-- Type: text/x-patch, Size: 6358 bytes --]

diff --git a/gcc/common/config/avr/avr-common.cc b/gcc/common/config/avr/avr-common.cc
index 7473429fa36..9059e7d2b48 100644
--- a/gcc/common/config/avr/avr-common.cc
+++ b/gcc/common/config/avr/avr-common.cc
@@ -39,6 +39,7 @@ static const struct default_options avr_option_optimization_table[] =
     { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_mfuse_move_, NULL, 3 },
     { OPT_LEVELS_2_PLUS, OPT_mfuse_move_, NULL, 23 },
     { OPT_LEVELS_2_PLUS, OPT_msplit_bit_shift, NULL, 1 },
+    { OPT_LEVELS_2_PLUS, OPT_msplit_ldst, NULL, 1 },
     // Stick to the "old" placement of the subreg lowering pass.
     { OPT_LEVELS_1_PLUS, OPT_fsplit_wide_types_early, NULL, 1 },
     /* Allow optimizer to introduce store data races. This used to be the
diff --git a/gcc/config/avr/avr-passes.cc b/gcc/config/avr/avr-passes.cc
index 7be5ec25fbc..5ad20c46238 100644
--- a/gcc/config/avr/avr-passes.cc
+++ b/gcc/config/avr/avr-passes.cc
@@ -5462,6 +5462,112 @@ avr_split_fake_addressing_move (rtx_insn * /*insn*/, rtx *xop)
 }
 
 
+/* Given memory reference mem(ADDR), return true when it can be split into
+   single-byte moves, and all resulting addresses are natively supported.
+   ADDR is in addr-space generic.  */
+
+static bool
+splittable_address_p (rtx addr, int n_bytes)
+{
+  if (CONSTANT_ADDRESS_P (addr)
+      || GET_CODE (addr) == PRE_DEC
+      || GET_CODE (addr) == POST_INC)
+    return true;
+
+  if (! AVR_TINY)
+    {
+      rtx base = select<rtx>()
+	: REG_P (addr) ? addr
+	: GET_CODE (addr) == PLUS ? XEXP (addr, 0)
+	: NULL_RTX;
+
+      int off = select<int>()
+	: REG_P (addr) ? 0
+	: GET_CODE (addr) == PLUS ? (int) INTVAL (XEXP (addr, 1))
+	: -1;
+
+      return (base && REG_P (base)
+	      && (REGNO (base) == REG_Y || REGNO (base) == REG_Z)
+	      && IN_RANGE (off, 0, 64 - n_bytes));
+    }
+
+  return false;
+}
+
+
+/* Like avr_byte(), but also knows how to split POST_INC and PRE_DEC
+   memory references.  */
+
+static rtx
+avr_byte_maybe_mem (rtx x, int n)
+{
+  rtx addr, b;
+  if (MEM_P (x)
+      && (GET_CODE (addr = XEXP (x, 0)) == POST_INC
+	  || GET_CODE (addr) == PRE_DEC))
+    b = gen_rtx_MEM (QImode, copy_rtx (addr));
+  else
+    b = avr_byte (x, n);
+
+  if (MEM_P (x))
+    gcc_assert (MEM_P (b));
+
+  return b;
+}
+
+
+/* Split multi-byte load / stores into 1-byte such insns
+   provided non-volatile, addr-space = generic, no reg-overlap
+   and the resulting addressings are all natively supported.
+   Returns true when the  XOP[0] = XOP[1]  insn has been split and
+   false, otherwise.  */
+
+bool
+avr_split_ldst (rtx *xop)
+{
+  rtx dest = xop[0];
+  rtx src = xop[1];
+  machine_mode mode = GET_MODE (dest);
+  int n_bytes = GET_MODE_SIZE (mode);
+  rtx mem, reg_or_0;
+
+  if (MEM_P (dest) && reg_or_0_operand (src, mode))
+    {
+      mem = dest;
+      reg_or_0 = src;
+    }
+  else if (register_operand (dest, mode) && MEM_P (src))
+    {
+      reg_or_0 = dest;
+      mem = src;
+    }
+  else
+    return false;
+
+  rtx addr = XEXP (mem, 0);
+
+  if (MEM_VOLATILE_P (mem)
+      || ! ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (mem))
+      || ! IN_RANGE (n_bytes, 2, 4)
+      || ! splittable_address_p (addr, n_bytes)
+      || reg_overlap_mentioned_p (reg_or_0, addr))
+    return false;
+
+  const int step = GET_CODE (addr) == PRE_DEC ? -1 : 1;
+  const int istart = step > 0 ? 0 : n_bytes - 1;
+  const int iend = istart + step * n_bytes;
+
+  for (int i = istart; i != iend; i += step)
+    {
+      rtx di = avr_byte_maybe_mem (dest, i);
+      rtx si = avr_byte_maybe_mem (src, i);
+      emit_move_ccc (di, si);
+    }
+
+  return true;
+}
+
+
 \f
 // Functions  make_<pass-name> (gcc::context*)  where <pass-name> is
 // according to the pass declaration in avr-passes.def.  GCC's pass
diff --git a/gcc/config/avr/avr-protos.h b/gcc/config/avr/avr-protos.h
index 4aa8554000b..5329d29702e 100644
--- a/gcc/config/avr/avr-protos.h
+++ b/gcc/config/avr/avr-protos.h
@@ -173,6 +173,7 @@ extern int n_avr_fuse_add_executed;
 extern bool avr_shift_is_3op ();
 extern bool avr_split_shift_p (int n_bytes, int offset, rtx_code);
 extern bool avr_split_shift (rtx xop[], rtx xscratch, rtx_code);
+extern bool avr_split_ldst (rtx xop[]);
 
 extern int avr_optimize_size_level ();
 
diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md
index e343fb23d07..42f41891a90 100644
--- a/gcc/config/avr/avr.md
+++ b/gcc/config/avr/avr.md
@@ -1000,15 +1000,24 @@ (define_split
                    (match_operand:MOVMODE 1 "general_operand"))
               (clobber (reg:CC REG_CC))])]
   "reload_completed
-   && avropt_fuse_add > 0
-   // Only split this for .split2 when we are before
-   // pass .avr-fuse-add (which runs after proep).
-   && ! epilogue_completed
    && (MEM_P (operands[0]) || MEM_P (operands[1]))"
   [(scratch)]
   {
-    if (avr_split_fake_addressing_move (curr_insn, operands))
+    if (avropt_fuse_add > 0
+        // Only split fake addressing for .split2 when we are before
+        // pass .avr-fuse-add (which runs after proep).
+        && ! epilogue_completed
+        && avr_split_fake_addressing_move (curr_insn, operands))
       DONE;
+
+    // Splitting multi-byte load / stores into 1-byte such insns
+    // provided non-volatile, addr-space = generic, no reg-overlap
+    // and the resulting addressings are natively supported.
+    if (avropt_split_ldst
+        && GET_MODE_SIZE (<MODE>mode) > 1
+        && avr_split_ldst (operands))
+      DONE;
+
     FAIL;
   })
 
diff --git a/gcc/config/avr/avr.opt b/gcc/config/avr/avr.opt
index 7770c278d40..6c86d2bb42a 100644
--- a/gcc/config/avr/avr.opt
+++ b/gcc/config/avr/avr.opt
@@ -98,6 +98,10 @@ msplit-bit-shift
 Target Var(avropt_split_bit_shift) Init(0) Optimization
 Optimization. Split shifts of 4-byte values into a byte shift and a residual bit shift.
 
+msplit-ldst
+Target Var(avropt_split_ldst) Init(0) Optimization
+Optimization. Split most of the load and store instructions into byte load and stores.
+
 mstrict-X
 Target Var(avropt_strict_X) Init(0) Optimization
 Optimization. When accessing RAM, use X as imposed by the hardware, i.e. just use pre-decrement, post-increment and indirect addressing with the X register.  Without this option, the compiler may assume that there is an addressing mode X+const similar to Y+const and Z+const and emit instructions to emulate such an addressing mode for X.

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Frank Ch. Eigler]

Hi -

> [...]
> gcc-patches@gcc.gnu.org
>    Letzter Fehler: 550 5.7.1
>    Erklärung: host gcc.gnu.org [8.43.85.97:25] said: rejected by DMARC
> policy for
>               gjlay.de
> 
>    Auszug aus dem Session-Protokoll:
>    ... während der Kommunikation mit dem Mailserver gcc.gnu.org
> [8.43.85.97:25]:
>    >>> DATA (EOM)
>    <<< 550 5.7.1 rejected by DMARC policy for gjlay.de

In the opendmarc logs, it shows a number of passes, but also intermittently this:

Dec 04 15:38:02 server2.sourceware.org opendmarc[2740756]: D2EAE3858C41: SPF(mailfrom): gjlay.de none
Dec 04 15:38:02 server2.sourceware.org opendmarc[2740756]: D2EAE3858C41: gjlay.de fail

And in dittoish in opendkim logs:

Dec 03 15:08:19 server2.sourceware.org opendkim[913875]: 07B223858C56: message has signatures from gjlay.de, gjlay.de
Dec 03 15:08:19 server2.sourceware.org opendkim[913875]: 07B223858C56: bad signature data

Does this help?

- FChE

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Mark Wielaard]

Hi Johann,

On Wed, 2024-12-04 at 17:15 +0100, Georg-Johann Lay via Overseers
wrote:
> Not yet, but it just happened again, and I don't know what to do.
> Just send the same email again until it succeeds.
> 
> For reference, here is the attachment; I don't see anything offensive
> there...
> 
> --
> *** MAILVERSAND FEHLERBERICHT ***
> 
> Die E-Mail wurde eingeliefert am Mittwoch, 4. Dezember 2024 16:37:58 
> +0100 (CET)
> von Host [192.168.2.102]   .
> 
> Betreff: [patch,avr] PR107957 - Split multi-byte loads and stores.
> Absender: avr@gjlay.de
> 
> Der Mailversand zum folgenden Empfänger ist endgültig gescheitert:
> 
> gcc-patches@gcc.gnu.org
>     Letzter Fehler: 550 5.7.1
>     Erklärung: host gcc.gnu.org [8.43.85.97:25] said: rejected by DMARC 
> policy for
>                gjlay.de
> 
>     Auszug aus dem Session-Protokoll:
>     ... während der Kommunikation mit dem Mailserver gcc.gnu.org 
> [8.43.85.97:25]:
>     >>> DATA (EOM)
>     <<< 550 5.7.1 rejected by DMARC policy for gjlay.de

Well as said before, the failure message is pretty clear. Your gjlay.de
domain has a strict DMARC policy (and no SPF, so it all depends on DKIM
signing on your end).

$ host -t txt _dmarc.gjlay.de
_dmarc.gjlay.de descriptive text "v=DMARC1;p=reject;"

There is something wrong with the DKIM headers or body signing, so your
message gets rejected (as requested).

To know what is really wrong we would have to see the full (original)
message with headers.

I don't know when/how your provider adds these DKIM headers, but I
would contact them with these failure messages and ask them about their
dmarc policy and dkim signing.

Cheers,

Mark

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Georg-Johann Lay]

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

Am 04.12.24 um 17:52 schrieb Mark Wielaard:
> Hi Johann,
> 
> On Wed, 2024-12-04 at 17:15 +0100, Georg-Johann Lay via Overseers
> wrote:
>> Not yet, but it just happened again, and I don't know what to do.
>> Just send the same email again until it succeeds.
>>
>> For reference, here is the attachment; I don't see anything offensive
>> there...
>>
>> --
>> *** MAILVERSAND FEHLERBERICHT ***
>>
>> Die E-Mail wurde eingeliefert am Mittwoch, 4. Dezember 2024 16:37:58
>> +0100 (CET)
>> von Host [192.168.2.102]   .
>>
>> Betreff: [patch,avr] PR107957 - Split multi-byte loads and stores.
>> Absender: avr@gjlay.de
>>
>> Der Mailversand zum folgenden Empfänger ist endgültig gescheitert:
>>
>> gcc-patches@gcc.gnu.org
>>      Letzter Fehler: 550 5.7.1
>>      Erklärung: host gcc.gnu.org [8.43.85.97:25] said: rejected by DMARC
>> policy for
>>                 gjlay.de
>>
>>      Auszug aus dem Session-Protokoll:
>>      ... während der Kommunikation mit dem Mailserver gcc.gnu.org
>> [8.43.85.97:25]:
>>      >>> DATA (EOM)
>>      <<< 550 5.7.1 rejected by DMARC policy for gjlay.de
> 
> Well as said before, the failure message is pretty clear. Your gjlay.de
> domain has a strict DMARC policy (and no SPF, so it all depends on DKIM
> signing on your end).

Well, I am only starting to get a faint idea what's it all about...

I attached the email which I got from Thunderbird -> show source.

Thunderbird is my local mail client, and I am using smtp.strato.de to
send mails.  I found 
https://www.strato.de/faq/mail/wie-kann-ich-fuer-meine-domain-die-dkim-einstellungen-aendern/

It says: Für Kunden, die ausschließlich unsere Mail-Server nutzen (per 
„smtp.strato.de“ versenden), signieren wir bereits seit Jahren alle 
ausgehenden E-Mails mit DKIM.

Translated by me: "For customers who are using exclusively our
mail server (send per smtp.strato.de), we are already signing
all outgoing e-mails with DKIM for years."

What's strange is that I re-sent the mail again some minutes
later, and it arrived at gcc-patches@

https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670836.html

So it seems to be random glitches somewhere, and the fix is to
re-send the e-mail?

Johann


> $ host -t txt _dmarc.gjlay.de
> _dmarc.gjlay.de descriptive text "v=DMARC1;p=reject;"
> 
> There is something wrong with the DKIM headers or body signing, so your
> message gets rejected (as requested).
> 
> To know what is really wrong we would have to see the full (original)
> message with headers.

Attached as text file.

> I don't know when/how your provider adds these DKIM headers, but I
> would contact them with these failure messages and ask them about their
> dmarc policy and dkim signing.
> 
> Cheers,
> 
> Mark

[-- Attachment #2: email-error.txt --]
[-- Type: text/plain, Size: 18672 bytes --]

From - Wed Dec  4 16:45:45 2024
X-Account-Key: account3
X-UIDL: 1839374fba3f2375fe6a86c3b7994f90
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
X-Envelope-From: <>
X-Envelope-To: <avr@gjlay.de>
X-Delivery-Time: 1733326682
X-UID: 338828
Return-Path: <>
ARC-Seal: i=1; a=rsa-sha256; t=1733326682; cv=none;
    d=strato.com; s=strato-dkim-0002;
    b=fg+Hm0i8CquuiW3lHhUV67LpQ0GSVmrbSfGH+Bz/cqluJa3puQGQG4m2N8sHUGwJto
    tTSw4hxVoRCV1v8hw+apBPZgQP4GZEGfJWSR9XcJpZhRKTVXqx0iUmdn8T8yy4nTfMV9
    AS2vEwiOkTgmWTEiE9fLI9GrgRZNHmBuL9/MVm5UzJyG53bIoAClgL1++WRSn/S8pqas
    LXWSzhJHw2IqiH70YXu5UQ6GVJ+NA1IccXRk/hY7bWUJubEwlNIM6SgqimbbRK3NGnOB
    wJ8PiSeSq6PaLtI3VCILaD55M8IWZukp7xD4mKCpwc5d1sBehqwGspEJ/qdPaqJg+Y+1
    sYjw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1733326682;
    s=strato-dkim-0002; d=strato.com;
    h=Subject:Message-ID:From:To:Date:Cc:Date:From:Subject:Sender;
    bh=QhumsJ6MXY2GTdH1g61r221RUlSq0i2cd1KdU5JJKTU=;
    b=U4t9EB+1y9NMNd+vwYxyy3qRL9W0jLH2RitNaSzx1Axi9Ge/9sE93UtHTLRWMeXtY0
    9a7fv7bILYBTuth/Km1t/1sMp8SCSU6MQ6Eii28j2t6YhOkG4FJHeWzWWl0JCk5QoXLc
    EWPfnMYLKqjNmYL0s3v/1PUySvFJ3aEfTG4vbLvoNd6rswnOVsH0BiGIZT99o3I9g7bs
    /LJVdmi1YVxwYL6vD+08Qtqr5YFtE8RYOhB+FxLaUPxgSKE2KJOXF+Krp7cynQ/9nmag
    8RsLpAa3sIObyKhRW99I3VIMiqlhcPn9xGxDCfgTFMA/ksxnbOKSIEP20/HmMunXbmyu
    ltWQ==
ARC-Authentication-Results: i=1; strato.com;
    dmarc=pass (p=NONE sp=NONE) header.from="smtp.strato.de";
    arc=none smtp.remote-ip=81.169.146.160;
    dkim=pass header.d="smtp.strato.de" header.s="strato-dkim-0002" header.a="rsa-sha256";
    dkim-adsp=pass;
    spf=pass smtp.helo="mo4-p00-ob.smtp.rzone.de"
Authentication-Results: strato.com;
    dmarc=pass (p=NONE sp=NONE) header.from="smtp.strato.de";
    arc=none smtp.remote-ip=81.169.146.160;
    dkim=pass header.d="smtp.strato.de" header.s="strato-dkim-0002" header.a="rsa-sha256";
    dkim-adsp=pass;
    spf=pass smtp.helo="mo4-p00-ob.smtp.rzone.de"
X-RZG-Expurgate: clean/bounce
X-RZG-Expurgate-ID: 149500::1733326682-77A18F38-DEF281CA/18/0
X-RZG-CLASS-ID: mi00
Received-SPF: pass
    (strato.com: domain _spf.strato.com designates 81.169.146.160 as permitted sender)
    mechanism=ip4;
    client-ip=81.169.146.160;
    helo="mo4-p00-ob.smtp.rzone.de";
    envelope-from="";
    receiver=smtpin.rzone.de;
    identity=helo;
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.160])
    by smtpin.rzone.de (RZmta 51.2.11 OK)
    with ESMTPS id vcee2f0B4Fc2rIG
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
    (Client CN "*.smtp.rzone.de", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK (+EmiG)))
        (Client hostname verified OK)
    for <avr@gjlay.de>;
    Wed, 4 Dec 2024 16:38:02 +0100 (CET)
Received: from localhost
	by mo4-p00-ob.smtp.rzone.de (RZmta 51.2.11 OK am=1)
	with ESMTPS id xd5faa0B4Fc22Rd
	for <avr@gjlay.de>;
	Wed, 4 Dec 2024 16:38:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1733326682;
    s=strato-dkim-0002; d=smtp.strato.de;
    h=Subject:Message-ID:From:To:Date:Cc:Date:From:Subject:Sender;
    bh=QhumsJ6MXY2GTdH1g61r221RUlSq0i2cd1KdU5JJKTU=;
    b=kNKEzOVZ19xuKadL6hSjZjwHr2ITcmdvarL/u9rlnv1mWzrScHx6NFQan2DmIJhPLg
    nSN7vKt9keIQ8kVEb7zQxnLVTSuqLfyizL9Wwj9ia3yKBwImxGptDWrCZz52LMOqA2CF
    Mrgf+mEimPtfoEAlzacjONhnLCKbZ6Wd+83K7s/qS8qgK+o6CdW8FQYRCOMKyGev+Sk8
    TLU/N+fpCG6BjjU0FIwuSxdE4a8iHrSB9HtAJ0MgvfsLiWGmNLxxYPD6nviSzanLtnsk
    dZvs8fqydOzVBTe3w8Ns16aBJzf7/uPH9hgy6lWHATmLnI33x4IjBFO3p8M0lzG6/dV3
    TO/w==
Date: Wed, 4 Dec 2024 16:38:02 +0100 (CET)
To: <avr@gjlay.de>
From: "Strato Mail" <MAILER-DAEMON@smtp.strato.de>
Message-ID: <xd5faa0B4Fc22Rd@smtp.strato.de>
Subject: Returned Mail:
 [patch,avr] PR107957 - Split multi-byte loads and stores.
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
	boundary="xd5faa0B4Fc22Rd/mo4-p00-ob.smtp.rzone.de"
Auto-Submitted: auto-replied (failure)

This is a MIME-encapsulated message

--xd5faa0B4Fc22Rd/mo4-p00-ob.smtp.rzone.de
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

*** MAILVERSAND FEHLERBERICHT ***

Die E-Mail wurde eingeliefert am Mittwoch, 4. Dezember 2024 16:37:58 +0100=
 (CET)
von Host [192.168.2.102]=20=20 .

Betreff: [patch,avr] PR107957 - Split multi-byte loads and stores.
Absender: avr@gjlay.de

Der Mailversand zum folgenden Empf=C3=A4nger ist endg=C3=BCltig gescheiter=
t:

gcc-patches@gcc.gnu.org
=20=20 Letzter Fehler: 550 5.7.1=20
=20=20 Erkl=C3=A4rung: host gcc.gnu.org [8.43.85.97:25] said: rejected by =
DMARC policy for=20
=20=20=20=20=20=20=20=20=20=20=20=20=20 gjlay.de

=20=20 Auszug aus dem Session-Protokoll:
=20=20 ... w=C3=A4hrend der Kommunikation mit dem Mailserver gcc.gnu.org [=
8.43.85.97:25]:
=20=20 >>> DATA (EOM)
=20=20 <<< 550 5.7.1 rejected by DMARC policy for gjlay.de

--xd5faa0B4Fc22Rd/mo4-p00-ob.smtp.rzone.de
Content-Type: message/delivery-status
Content-Disposition: attachment

Reporting-MTA: DNS; mo4-p00-ob.smtp.rzone.de
Received-From-MTA: DNS; [192.168.2.102] (92.217.178.60)
Arrival-Date: Wed, 4 Dec 2024 16:37:58 +0100 (CET)

Final-Recipient: RFC822; gcc-patches@gcc.gnu.org
Action: failed
Status: 5.7.1
Remote-MTA: DNS; gcc.gnu.org [8.43.85.97:25]
Diagnostic-Code: SMTP; 550 5.7.1 rejected by DMARC policy for gjlay.de
Last-Attempt-Date: 
Final-Log-ID: xd5faa0B4Fc22Rd

--xd5faa0B4Fc22Rd/mo4-p00-ob.smtp.rzone.de
Content-Type: message/rfc822
Content-Disposition: attachment

ARC-Seal: i=1; a=rsa-sha256; t=1733326678; cv=none;
    d=strato.com; s=strato-dkim-0002;
    b=iuHXJNX18uDFekXGUBmcqbL2NG7ZygZk7LIMaQDoWyAcmOyr5hyRThbIfX04YGTScN
    DwO3SSzfmslIWrYlOFyP/EPEU1kOvkxeLsrdAv+43YoIhih3PWlO6Gyk5fQWRFlQxVNk
    Xnx11sOoOA9jpwftzTFL4+aRE8OarBseL1bmcegMPpAqS/UWn5eVb8yXtAypk6RiHQdd
    i2CYVlpU5ATHHVfFTeihGigScW8+rKy7OKDnI4a9sQbRtY+MaQ/qNdLVq7LfMmtuajQX
    1WCIJPQfYDdU1rhc4vc2A5iOgC2XAK2Xm3ycOlafHxKDl4nsmvNmiOug4rZiVGtu05hH
    ek+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1733326678;
    s=strato-dkim-0002; d=strato.com;
    h=Subject:To:From:Date:Message-ID:Cc:Date:From:Subject:Sender;
    bh=KHY/8KwFA6Qtb7a+IQpT6zRo+w6wPWR/8dG4gJpGm/4=;
    b=JDD8M/yLdowRxpD1brMC+FmDil+VkgBbGqaciRErIx0u/lYmYSUTlE+hdOz5T9m0lx
    QFgGDHdpUbzVp7BPjGkte8NkOK8AaH4LBfJtUO3IAqp1av5IpXwPtGgKP8sSeICxfnmU
    A/3F/a+0jtxeoMtA5rfrueTdo8aDc/CBVrBItQhvsVoJ+nPxtBNgbgVAvCKtAu5xBto6
    nt6KlTf/c7oyKyEMI2p4IUHySD42wI7EZiTHkSxM5xnXduOvuUYELskJr63Y1DPJuc43
    8drvxi2H2eMlDvkhbNLvRXbvYZWb4oNEqhAgeSrxyF1Zju9PCGYjrryNAbw37CU7MK/+
    FRaA==
ARC-Authentication-Results: i=1; strato.com;
    arc=none;
    dkim=none
X-RZG-CLASS-ID: mo00
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1733326678;
    s=strato-dkim-0002; d=gjlay.de;
    h=Subject:To:From:Date:Message-ID:Cc:Date:From:Subject:Sender;
    bh=KHY/8KwFA6Qtb7a+IQpT6zRo+w6wPWR/8dG4gJpGm/4=;
    b=mmRwpEygUuqgEWvX82rxRTRNaDOQknCE27JNNlHtCSRx3RB4ha82PINb7j3t6I6uUe
    4p9emg1+bcsuLd5eMRZoyWtYvNlDUCiHQOAkIH7hm0mHufBF9k0P48OnuMkAxk/ya7dw
    vNjGbKeqRwKCcG/tax/AeHSEmaVrKfrUsFygvQPl1NjK7pnU18cG75oZXuHQKz4d6XPP
    GBo4eI3cKSR8oimS3JxbGO48GWAFr1M1AgbKaxqsk91V4j4ObBwXB0coSlqeCxNb1z6B
    4sPO6ElPXagElxxNBTuf5ewH35aIgKBs+5PyK4pN8EWW37/NHtg+Fg45FdZi61Jf03k2
    Pdig==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1733326678;
    s=strato-dkim-0003; d=gjlay.de;
    h=Subject:To:From:Date:Message-ID:Cc:Date:From:Subject:Sender;
    bh=KHY/8KwFA6Qtb7a+IQpT6zRo+w6wPWR/8dG4gJpGm/4=;
    b=z5zbZEe2hLDynPCt7hqpvwaV0So95UU05/cvITfplSuoHAffAQoOw+9eH4ra4m+FaG
    LAaFmUPcjDk8twQvU+Aw==
X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKXKoq0dKoR0vVqyQb0R7G22gRW+Qr5Q=="
Received: from [192.168.2.102]
    by smtp.strato.de (RZmta 51.2.11 AUTH)
    with ESMTPSA id xd5faa0B4Fbw2Ra
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Wed, 4 Dec 2024 16:37:58 +0100 (CET)
Content-Type: multipart/mixed; boundary="------------vuyozE9yyl7zes7F7kk1Z7Kf"
Message-ID: <3ea9193f-388a-47ed-be8c-d71778b38c84@gjlay.de>
Date: Wed, 4 Dec 2024 16:37:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Georg-Johann Lay <avr@gjlay.de>
Content-Language: en-US
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
 Denis Chertykov <chertykov@gmail.com>
Subject: [patch,avr] PR107957 - Split multi-byte loads and stores.
Content-Transfer-Encoding: 7bit

This is a multi-part message in MIME format.
--------------vuyozE9yyl7zes7F7kk1Z7Kf
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

This patch splits multi-byte loads and stores into single-byte
ones provided:

-  New option -msplit-ldst is on (e.g. -O2 and higher), and
-  The memory is non-volatile, and
-  The address space is generic, and
-  The split addresses are natively supported by the hardware.

Passes without regressions.  Ok for trunk?

Johann

--

AVR: target/107957 - Split multi-byte loads and stores.

This patch splits multi-byte loads and stores into single-byte
ones provided:

-  New option -msplit-ldst is on (e.g. -O2 and higher), and
-  The memory is non-volatile, and
-  The address space is generic, and
-  The split addresses are natively supported by the hardware.

gcc/
	PR target/107957
	* config/avr/avr.opt (-msplit-ldst, avropt_split_ldst):
	New option and associated var.
	* common/config/avr/avr-common.cc (avr_option_optimization_table)
	[OPT_LEVELS_2_PLUS]: Turn on -msplit_ldst.
	* config/avr/avr-passes.cc (splittable_address_p)
	(avr_byte_maybe_mem, avr_split_ldst): New functions.
	* config/avr/avr-protos.h (avr_split_ldst): New proto.
	* config/avr/avr.md (define_split) [avropt_split_ldst]: Run
	avr_split_ldst().
--------------vuyozE9yyl7zes7F7kk1Z7Kf
Content-Type: text/x-patch; charset=UTF-8; name="split-ldst.diff"
Content-Disposition: attachment; filename="split-ldst.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL2djYy9jb21tb24vY29uZmlnL2F2ci9hdnItY29tbW9uLmNjIGIvZ2Nj
L2NvbW1vbi9jb25maWcvYXZyL2F2ci1jb21tb24uY2MKaW5kZXggNzQ3MzQyOWZhMzYuLjkw
NTllN2QyYjQ4IDEwMDY0NAotLS0gYS9nY2MvY29tbW9uL2NvbmZpZy9hdnIvYXZyLWNvbW1v
bi5jYworKysgYi9nY2MvY29tbW9uL2NvbmZpZy9hdnIvYXZyLWNvbW1vbi5jYwpAQCAtMzks
NiArMzksNyBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IGRlZmF1bHRfb3B0aW9ucyBhdnJfb3B0
aW9uX29wdGltaXphdGlvbl90YWJsZVtdID0KICAgICB7IE9QVF9MRVZFTFNfMV9QTFVTX05P
VF9ERUJVRywgT1BUX21mdXNlX21vdmVfLCBOVUxMLCAzIH0sCiAgICAgeyBPUFRfTEVWRUxT
XzJfUExVUywgT1BUX21mdXNlX21vdmVfLCBOVUxMLCAyMyB9LAogICAgIHsgT1BUX0xFVkVM
U18yX1BMVVMsIE9QVF9tc3BsaXRfYml0X3NoaWZ0LCBOVUxMLCAxIH0sCisgICAgeyBPUFRf
TEVWRUxTXzJfUExVUywgT1BUX21zcGxpdF9sZHN0LCBOVUxMLCAxIH0sCiAgICAgLy8gU3Rp
Y2sgdG8gdGhlICJvbGQiIHBsYWNlbWVudCBvZiB0aGUgc3VicmVnIGxvd2VyaW5nIHBhc3Mu
CiAgICAgeyBPUFRfTEVWRUxTXzFfUExVUywgT1BUX2ZzcGxpdF93aWRlX3R5cGVzX2Vhcmx5
LCBOVUxMLCAxIH0sCiAgICAgLyogQWxsb3cgb3B0aW1pemVyIHRvIGludHJvZHVjZSBzdG9y
ZSBkYXRhIHJhY2VzLiBUaGlzIHVzZWQgdG8gYmUgdGhlCmRpZmYgLS1naXQgYS9nY2MvY29u
ZmlnL2F2ci9hdnItcGFzc2VzLmNjIGIvZ2NjL2NvbmZpZy9hdnIvYXZyLXBhc3Nlcy5jYwpp
bmRleCA3YmU1ZWMyNWZiYy4uNWFkMjBjNDYyMzggMTAwNjQ0Ci0tLSBhL2djYy9jb25maWcv
YXZyL2F2ci1wYXNzZXMuY2MKKysrIGIvZ2NjL2NvbmZpZy9hdnIvYXZyLXBhc3Nlcy5jYwpA
QCAtNTQ2Miw2ICs1NDYyLDExMiBAQCBhdnJfc3BsaXRfZmFrZV9hZGRyZXNzaW5nX21vdmUg
KHJ0eF9pbnNuICogLyppbnNuKi8sIHJ0eCAqeG9wKQogfQogCiAKKy8qIEdpdmVuIG1lbW9y
eSByZWZlcmVuY2UgbWVtKEFERFIpLCByZXR1cm4gdHJ1ZSB3aGVuIGl0IGNhbiBiZSBzcGxp
dCBpbnRvCisgICBzaW5nbGUtYnl0ZSBtb3ZlcywgYW5kIGFsbCByZXN1bHRpbmcgYWRkcmVz
c2VzIGFyZSBuYXRpdmVseSBzdXBwb3J0ZWQuCisgICBBRERSIGlzIGluIGFkZHItc3BhY2Ug
Z2VuZXJpYy4gICovCisKK3N0YXRpYyBib29sCitzcGxpdHRhYmxlX2FkZHJlc3NfcCAocnR4
IGFkZHIsIGludCBuX2J5dGVzKQoreworICBpZiAoQ09OU1RBTlRfQUREUkVTU19QIChhZGRy
KQorICAgICAgfHwgR0VUX0NPREUgKGFkZHIpID09IFBSRV9ERUMKKyAgICAgIHx8IEdFVF9D
T0RFIChhZGRyKSA9PSBQT1NUX0lOQykKKyAgICByZXR1cm4gdHJ1ZTsKKworICBpZiAoISBB
VlJfVElOWSkKKyAgICB7CisgICAgICBydHggYmFzZSA9IHNlbGVjdDxydHg+KCkKKwk6IFJF
R19QIChhZGRyKSA/IGFkZHIKKwk6IEdFVF9DT0RFIChhZGRyKSA9PSBQTFVTID8gWEVYUCAo
YWRkciwgMCkKKwk6IE5VTExfUlRYOworCisgICAgICBpbnQgb2ZmID0gc2VsZWN0PGludD4o
KQorCTogUkVHX1AgKGFkZHIpID8gMAorCTogR0VUX0NPREUgKGFkZHIpID09IFBMVVMgPyAo
aW50KSBJTlRWQUwgKFhFWFAgKGFkZHIsIDEpKQorCTogLTE7CisKKyAgICAgIHJldHVybiAo
YmFzZSAmJiBSRUdfUCAoYmFzZSkKKwkgICAgICAmJiAoUkVHTk8gKGJhc2UpID09IFJFR19Z
IHx8IFJFR05PIChiYXNlKSA9PSBSRUdfWikKKwkgICAgICAmJiBJTl9SQU5HRSAob2ZmLCAw
LCA2NCAtIG5fYnl0ZXMpKTsKKyAgICB9CisKKyAgcmV0dXJuIGZhbHNlOworfQorCisKKy8q
IExpa2UgYXZyX2J5dGUoKSwgYnV0IGFsc28ga25vd3MgaG93IHRvIHNwbGl0IFBPU1RfSU5D
IGFuZCBQUkVfREVDCisgICBtZW1vcnkgcmVmZXJlbmNlcy4gICovCisKK3N0YXRpYyBydHgK
K2F2cl9ieXRlX21heWJlX21lbSAocnR4IHgsIGludCBuKQoreworICBydHggYWRkciwgYjsK
KyAgaWYgKE1FTV9QICh4KQorICAgICAgJiYgKEdFVF9DT0RFIChhZGRyID0gWEVYUCAoeCwg
MCkpID09IFBPU1RfSU5DCisJICB8fCBHRVRfQ09ERSAoYWRkcikgPT0gUFJFX0RFQykpCisg
ICAgYiA9IGdlbl9ydHhfTUVNIChRSW1vZGUsIGNvcHlfcnR4IChhZGRyKSk7CisgIGVsc2UK
KyAgICBiID0gYXZyX2J5dGUgKHgsIG4pOworCisgIGlmIChNRU1fUCAoeCkpCisgICAgZ2Nj
X2Fzc2VydCAoTUVNX1AgKGIpKTsKKworICByZXR1cm4gYjsKK30KKworCisvKiBTcGxpdCBt
dWx0aS1ieXRlIGxvYWQgLyBzdG9yZXMgaW50byAxLWJ5dGUgc3VjaCBpbnNucworICAgcHJv
dmlkZWQgbm9uLXZvbGF0aWxlLCBhZGRyLXNwYWNlID0gZ2VuZXJpYywgbm8gcmVnLW92ZXJs
YXAKKyAgIGFuZCB0aGUgcmVzdWx0aW5nIGFkZHJlc3NpbmdzIGFyZSBhbGwgbmF0aXZlbHkg
c3VwcG9ydGVkLgorICAgUmV0dXJucyB0cnVlIHdoZW4gdGhlICBYT1BbMF0gPSBYT1BbMV0g
IGluc24gaGFzIGJlZW4gc3BsaXQgYW5kCisgICBmYWxzZSwgb3RoZXJ3aXNlLiAgKi8KKwor
Ym9vbAorYXZyX3NwbGl0X2xkc3QgKHJ0eCAqeG9wKQoreworICBydHggZGVzdCA9IHhvcFsw
XTsKKyAgcnR4IHNyYyA9IHhvcFsxXTsKKyAgbWFjaGluZV9tb2RlIG1vZGUgPSBHRVRfTU9E
RSAoZGVzdCk7CisgIGludCBuX2J5dGVzID0gR0VUX01PREVfU0laRSAobW9kZSk7CisgIHJ0
eCBtZW0sIHJlZ19vcl8wOworCisgIGlmIChNRU1fUCAoZGVzdCkgJiYgcmVnX29yXzBfb3Bl
cmFuZCAoc3JjLCBtb2RlKSkKKyAgICB7CisgICAgICBtZW0gPSBkZXN0OworICAgICAgcmVn
X29yXzAgPSBzcmM7CisgICAgfQorICBlbHNlIGlmIChyZWdpc3Rlcl9vcGVyYW5kIChkZXN0
LCBtb2RlKSAmJiBNRU1fUCAoc3JjKSkKKyAgICB7CisgICAgICByZWdfb3JfMCA9IGRlc3Q7
CisgICAgICBtZW0gPSBzcmM7CisgICAgfQorICBlbHNlCisgICAgcmV0dXJuIGZhbHNlOwor
CisgIHJ0eCBhZGRyID0gWEVYUCAobWVtLCAwKTsKKworICBpZiAoTUVNX1ZPTEFUSUxFX1Ag
KG1lbSkKKyAgICAgIHx8ICEgQUREUl9TUEFDRV9HRU5FUklDX1AgKE1FTV9BRERSX1NQQUNF
IChtZW0pKQorICAgICAgfHwgISBJTl9SQU5HRSAobl9ieXRlcywgMiwgNCkKKyAgICAgIHx8
ICEgc3BsaXR0YWJsZV9hZGRyZXNzX3AgKGFkZHIsIG5fYnl0ZXMpCisgICAgICB8fCByZWdf
b3ZlcmxhcF9tZW50aW9uZWRfcCAocmVnX29yXzAsIGFkZHIpKQorICAgIHJldHVybiBmYWxz
ZTsKKworICBjb25zdCBpbnQgc3RlcCA9IEdFVF9DT0RFIChhZGRyKSA9PSBQUkVfREVDID8g
LTEgOiAxOworICBjb25zdCBpbnQgaXN0YXJ0ID0gc3RlcCA+IDAgPyAwIDogbl9ieXRlcyAt
IDE7CisgIGNvbnN0IGludCBpZW5kID0gaXN0YXJ0ICsgc3RlcCAqIG5fYnl0ZXM7CisKKyAg
Zm9yIChpbnQgaSA9IGlzdGFydDsgaSAhPSBpZW5kOyBpICs9IHN0ZXApCisgICAgeworICAg
ICAgcnR4IGRpID0gYXZyX2J5dGVfbWF5YmVfbWVtIChkZXN0LCBpKTsKKyAgICAgIHJ0eCBz
aSA9IGF2cl9ieXRlX21heWJlX21lbSAoc3JjLCBpKTsKKyAgICAgIGVtaXRfbW92ZV9jY2Mg
KGRpLCBzaSk7CisgICAgfQorCisgIHJldHVybiB0cnVlOworfQorCisKIAwKIC8vIEZ1bmN0
aW9ucyAgbWFrZV88cGFzcy1uYW1lPiAoZ2NjOjpjb250ZXh0KikgIHdoZXJlIDxwYXNzLW5h
bWU+IGlzCiAvLyBhY2NvcmRpbmcgdG8gdGhlIHBhc3MgZGVjbGFyYXRpb24gaW4gYXZyLXBh
c3Nlcy5kZWYuICBHQ0MncyBwYXNzCmRpZmYgLS1naXQgYS9nY2MvY29uZmlnL2F2ci9hdnIt
cHJvdG9zLmggYi9nY2MvY29uZmlnL2F2ci9hdnItcHJvdG9zLmgKaW5kZXggNGFhODU1NDAw
MGIuLjUzMjlkMjk3MDJlIDEwMDY0NAotLS0gYS9nY2MvY29uZmlnL2F2ci9hdnItcHJvdG9z
LmgKKysrIGIvZ2NjL2NvbmZpZy9hdnIvYXZyLXByb3Rvcy5oCkBAIC0xNzMsNiArMTczLDcg
QEAgZXh0ZXJuIGludCBuX2F2cl9mdXNlX2FkZF9leGVjdXRlZDsKIGV4dGVybiBib29sIGF2
cl9zaGlmdF9pc18zb3AgKCk7CiBleHRlcm4gYm9vbCBhdnJfc3BsaXRfc2hpZnRfcCAoaW50
IG5fYnl0ZXMsIGludCBvZmZzZXQsIHJ0eF9jb2RlKTsKIGV4dGVybiBib29sIGF2cl9zcGxp
dF9zaGlmdCAocnR4IHhvcFtdLCBydHggeHNjcmF0Y2gsIHJ0eF9jb2RlKTsKK2V4dGVybiBi
b29sIGF2cl9zcGxpdF9sZHN0IChydHggeG9wW10pOwogCiBleHRlcm4gaW50IGF2cl9vcHRp
bWl6ZV9zaXplX2xldmVsICgpOwogCmRpZmYgLS1naXQgYS9nY2MvY29uZmlnL2F2ci9hdnIu
bWQgYi9nY2MvY29uZmlnL2F2ci9hdnIubWQKaW5kZXggZTM0M2ZiMjNkMDcuLjQyZjQxODkx
YTkwIDEwMDY0NAotLS0gYS9nY2MvY29uZmlnL2F2ci9hdnIubWQKKysrIGIvZ2NjL2NvbmZp
Zy9hdnIvYXZyLm1kCkBAIC0xMDAwLDE1ICsxMDAwLDI0IEBAIChkZWZpbmVfc3BsaXQKICAg
ICAgICAgICAgICAgICAgICAobWF0Y2hfb3BlcmFuZDpNT1ZNT0RFIDEgImdlbmVyYWxfb3Bl
cmFuZCIpKQogICAgICAgICAgICAgICAoY2xvYmJlciAocmVnOkNDIFJFR19DQykpXSldCiAg
ICJyZWxvYWRfY29tcGxldGVkCi0gICAmJiBhdnJvcHRfZnVzZV9hZGQgPiAwCi0gICAvLyBP
bmx5IHNwbGl0IHRoaXMgZm9yIC5zcGxpdDIgd2hlbiB3ZSBhcmUgYmVmb3JlCi0gICAvLyBw
YXNzIC5hdnItZnVzZS1hZGQgKHdoaWNoIHJ1bnMgYWZ0ZXIgcHJvZXApLgotICAgJiYgISBl
cGlsb2d1ZV9jb21wbGV0ZWQKICAgICYmIChNRU1fUCAob3BlcmFuZHNbMF0pIHx8IE1FTV9Q
IChvcGVyYW5kc1sxXSkpIgogICBbKHNjcmF0Y2gpXQogICB7Ci0gICAgaWYgKGF2cl9zcGxp
dF9mYWtlX2FkZHJlc3NpbmdfbW92ZSAoY3Vycl9pbnNuLCBvcGVyYW5kcykpCisgICAgaWYg
KGF2cm9wdF9mdXNlX2FkZCA+IDAKKyAgICAgICAgLy8gT25seSBzcGxpdCBmYWtlIGFkZHJl
c3NpbmcgZm9yIC5zcGxpdDIgd2hlbiB3ZSBhcmUgYmVmb3JlCisgICAgICAgIC8vIHBhc3Mg
LmF2ci1mdXNlLWFkZCAod2hpY2ggcnVucyBhZnRlciBwcm9lcCkuCisgICAgICAgICYmICEg
ZXBpbG9ndWVfY29tcGxldGVkCisgICAgICAgICYmIGF2cl9zcGxpdF9mYWtlX2FkZHJlc3Np
bmdfbW92ZSAoY3Vycl9pbnNuLCBvcGVyYW5kcykpCiAgICAgICBET05FOworCisgICAgLy8g
U3BsaXR0aW5nIG11bHRpLWJ5dGUgbG9hZCAvIHN0b3JlcyBpbnRvIDEtYnl0ZSBzdWNoIGlu
c25zCisgICAgLy8gcHJvdmlkZWQgbm9uLXZvbGF0aWxlLCBhZGRyLXNwYWNlID0gZ2VuZXJp
Yywgbm8gcmVnLW92ZXJsYXAKKyAgICAvLyBhbmQgdGhlIHJlc3VsdGluZyBhZGRyZXNzaW5n
cyBhcmUgbmF0aXZlbHkgc3VwcG9ydGVkLgorICAgIGlmIChhdnJvcHRfc3BsaXRfbGRzdAor
ICAgICAgICAmJiBHRVRfTU9ERV9TSVpFICg8TU9ERT5tb2RlKSA+IDEKKyAgICAgICAgJiYg
YXZyX3NwbGl0X2xkc3QgKG9wZXJhbmRzKSkKKyAgICAgIERPTkU7CisKICAgICBGQUlMOwog
ICB9KQogCmRpZmYgLS1naXQgYS9nY2MvY29uZmlnL2F2ci9hdnIub3B0IGIvZ2NjL2NvbmZp
Zy9hdnIvYXZyLm9wdAppbmRleCA3NzcwYzI3OGQ0MC4uNmM4NmQyYmI0MmEgMTAwNjQ0Ci0t
LSBhL2djYy9jb25maWcvYXZyL2F2ci5vcHQKKysrIGIvZ2NjL2NvbmZpZy9hdnIvYXZyLm9w
dApAQCAtOTgsNiArOTgsMTAgQEAgbXNwbGl0LWJpdC1zaGlmdAogVGFyZ2V0IFZhcihhdnJv
cHRfc3BsaXRfYml0X3NoaWZ0KSBJbml0KDApIE9wdGltaXphdGlvbgogT3B0aW1pemF0aW9u
LiBTcGxpdCBzaGlmdHMgb2YgNC1ieXRlIHZhbHVlcyBpbnRvIGEgYnl0ZSBzaGlmdCBhbmQg
YSByZXNpZHVhbCBiaXQgc2hpZnQuCiAKK21zcGxpdC1sZHN0CitUYXJnZXQgVmFyKGF2cm9w
dF9zcGxpdF9sZHN0KSBJbml0KDApIE9wdGltaXphdGlvbgorT3B0aW1pemF0aW9uLiBTcGxp
dCBtb3N0IG9mIHRoZSBsb2FkIGFuZCBzdG9yZSBpbnN0cnVjdGlvbnMgaW50byBieXRlIGxv
YWQgYW5kIHN0b3Jlcy4KKwogbXN0cmljdC1YCiBUYXJnZXQgVmFyKGF2cm9wdF9zdHJpY3Rf
WCkgSW5pdCgwKSBPcHRpbWl6YXRpb24KIE9wdGltaXphdGlvbi4gV2hlbiBhY2Nlc3Npbmcg
UkFNLCB1c2UgWCBhcyBpbXBvc2VkIGJ5IHRoZSBoYXJkd2FyZSwgaS5lLiBqdXN0IHVzZSBw
cmUtZGVjcmVtZW50LCBwb3N0LWluY3JlbWVudCBhbmQgaW5kaXJlY3QgYWRkcmVzc2luZyB3
aXRoIHRoZSBYIHJlZ2lzdGVyLiAgV2l0aG91dCB0aGlzIG9wdGlvbiwgdGhlIGNvbXBpbGVy
IG1heSBhc3N1bWUgdGhhdCB0aGVyZSBpcyBhbiBhZGRyZXNzaW5nIG1vZGUgWCtjb25zdCBz
aW1pbGFyIHRvIFkrY29uc3QgYW5kIForY29uc3QgYW5kIGVtaXQgaW5zdHJ1Y3Rpb25zIHRv
IGVtdWxhdGUgc3VjaCBhbiBhZGRyZXNzaW5nIG1vZGUgZm9yIFguCg==

--------------vuyozE9yyl7zes7F7kk1Z7Kf--

--xd5faa0B4Fc22Rd/mo4-p00-ob.smtp.rzone.de--

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Mark Wielaard]

Hi Johann,

On Wed, 2024-12-04 at 19:42 +0100, Georg-Johann Lay wrote:
> Well, I am only starting to get a faint idea what's it all about...
> 
> I attached the email which I got from Thunderbird -> show source.
> 
> Thunderbird is my local mail client, and I am using smtp.strato.de to
> send mails.  I found 
> https://www.strato.de/faq/mail/wie-kann-ich-fuer-meine-domain-die-dkim-einstellungen-aendern/
> 
> It says: Für Kunden, die ausschließlich unsere Mail-Server nutzen (per 
> „smtp.strato.de“ versenden), signieren wir bereits seit Jahren alle 
> ausgehenden E-Mails mit DKIM.
> 
> Translated by me: "For customers who are using exclusively our
> mail server (send per smtp.strato.de), we are already signing
> all outgoing e-mails with DKIM for years."
> 
> What's strange is that I re-sent the mail again some minutes
> later, and it arrived at gcc-patches@
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670836.html
> 
> So it seems to be random glitches somewhere, and the fix is to
> re-send the e-mail?

Apparently strato sometimes doesn't properly dkim-signs the message (or
sourceware doesn't accept it as properly signed). If re-sending fixes
it then you should really forward the exact bounce message you got to 
strato and ask them to investigate.

Cheers,

Mark

Re: [gcc r15-5810] AVR: Skip the gcc.c-torture/execute/memcpy-a*.c tests.

[Georg-Johann Lay]

Am 05.12.24 um 17:26 schrieb Mark Wielaard:
> Hi Johann,
> 
> On Wed, 2024-12-04 at 19:42 +0100, Georg-Johann Lay wrote:
>> Well, I am only starting to get a faint idea what's it all about...
>>
>> I attached the email which I got from Thunderbird -> show source.
>>
>> Thunderbird is my local mail client, and I am using smtp.strato.de to
>> send mails.  I found
>> https://www.strato.de/faq/mail/wie-kann-ich-fuer-meine-domain-die-dkim-einstellungen-aendern/
>>
>> It says: Für Kunden, die ausschließlich unsere Mail-Server nutzen (per
>> „smtp.strato.de“ versenden), signieren wir bereits seit Jahren alle
>> ausgehenden E-Mails mit DKIM.
>>
>> Translated by me: "For customers who are using exclusively our
>> mail server (send per smtp.strato.de), we are already signing
>> all outgoing e-mails with DKIM for years."
>>
>> What's strange is that I re-sent the mail again some minutes
>> later, and it arrived at gcc-patches@
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670836.html
>>
>> So it seems to be random glitches somewhere, and the fix is to
>> re-send the e-mail?
> 
> Apparently strato sometimes doesn't properly dkim-signs the message (or
> sourceware doesn't accept it as properly signed). If re-sending fixes
> it then you should really forward the exact bounce message you got to
> strato and ask them to investigate.
> 
> Cheers,
> 
> Mark

Ok, thank you so much for taking your time.

Johann