[Bug target/105753] New: [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[Bug target/105753] New: [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[filip.hejsek at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

            Bug ID: 105753
           Summary: [avr] ICE: in add_clobbers, at
                    config/avr/avr-dimode.md:2705
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: filip.hejsek at gmail dot com
  Target Milestone: ---
            Target: avr

GCC fails when compiling the following C program for AVR (with at least -O1):

int digit_sum(unsigned long n) {
  int sum = 0;

  do {
    int x = n % 10;
    n /= 10;
    sum += x;
  } while(n);

  return sum;
}

I have tested both GCC 12.1.0 form Arch Linux and a development version (GCC
13.0.0) compiled from git sources.

Here is the compiler output:

$ ~/avr_gcc_install/bin/avr-gcc -c -O1 bug.c
during RTL pass: combine
bug.c: In function ‘digit_sum’:
bug.c:13:1: internal compiler error: in add_clobbers, at
config/avr/avr-dimode.md:2705
   13 | }
      | ^
0x770d30 add_clobbers(rtx_def*, int)
        ../../gcc/gcc/config/avr/avr-dimode.md:2705
0x1645c94 recog_for_combine_1
        ../../gcc/gcc/combine.cc:11422
0x164979e recog_for_combine
        ../../gcc/gcc/combine.cc:11622
0x165aef7 try_combine
        ../../gcc/gcc/combine.cc:3543
0x165e72f combine_instructions
        ../../gcc/gcc/combine.cc:1266
0x165e72f rest_of_handle_combine
        ../../gcc/gcc/combine.cc:14976
0x165e72f execute
        ../../gcc/gcc/combine.cc:15021
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ ~/avr_gcc_install/bin/avr-gcc -v
Using built-in specs.
Reading specs from
/home/filiph/avr_gcc_install/lib/gcc/avr/13.0.0/device-specs/specs-avr2
COLLECT_GCC=/home/filiph/avr_gcc_install/bin/avr-gcc
COLLECT_LTO_WRAPPER=/home/filiph/avr_gcc_install/libexec/gcc/avr/13.0.0/lto-wrapper
Target: avr
Configured with: ../gcc/configure --prefix=/home/filiph/avr_gcc_install
--target=avr --enable-languages=c --with-as=/usr/bin/avr-as --with-gnu-as
--with-ld=/usr/bin/avr-ld --with-gnu-ld
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220525 (experimental) [master -gda2c56ee6] (GCC) 

$ avr-gcc -c -O1 bug.c
during RTL pass: combine
bug.c: In function 'digit_sum':
bug.c:13:1: internal compiler error: in add_clobbers, at
config/avr/avr-dimode.md:2705
   13 | }
      | ^
0x140115b diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
        ???:0
0x140209d internal_error(char const*, ...)
        ???:0
0x5bafbc fancy_abort(char const*, int, char const*)
        ???:0
0x5b1839 add_clobbers(rtx_def*, int) [clone .cold]
        ???:0
0x1213b97 recog_for_combine_1(rtx_def**, rtx_insn*, rtx_def**)
        ???:0
0x1215e8e recog_for_combine(rtx_def**, rtx_insn*, rtx_def**)
        ???:0
0x1228da5 try_combine(rtx_insn*, rtx_insn*, rtx_insn*, rtx_insn*, int*,
rtx_insn*)
        ???:0
0x122c0a4 (anonymous namespace)::pass_combine::execute(function*)
        ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/12.1.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/12.1.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-12.1.0/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC) 

(This bug seems to be similar to bug 88051, but that one was on i386.)

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[filip.hejsek at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #1 from Filip Hejsek <filip.hejsek at gmail dot com> ---
Not that i would really understand the machine description files, but the
problem seems to be caused by this instruction definition:

(define_insn_and_split "udivmodsi4"
  [(parallel [(set (match_operand:SI 0 "pseudo_register_operand" "")
                   (udiv:SI (match_operand:SI 1 "pseudo_register_operand" "")
                           (match_operand:SI 2 "pseudo_register_operand" "")))
              (set (match_operand:SI 3 "pseudo_register_operand" "")
                   (umod:SI (match_dup 1) (match_dup 2)))
              (clobber (reg:SI 18))
              (clobber (reg:SI 22))
              (clobber (reg:HI 26))
              (clobber (reg:HI 30))])]
  ""
  "this udivmodsi4 pattern should have been splitted;"
  ""
  [(set (reg:SI 22) (match_dup 1))
   (set (reg:SI 18) (match_dup 2))
   (parallel [(set (reg:SI 18) (udiv:SI (reg:SI 22) (reg:SI 18)))
              (set (reg:SI 22) (umod:SI (reg:SI 22) (reg:SI 18)))
              (clobber (reg:HI 26))
              (clobber (reg:HI 30))])
   (set (match_dup 0) (reg:SI 18))
   (set (match_dup 3) (reg:SI 22))])

Just as in bug 88051, the instruction is missing from the generated switch in
add_clobbers and removing pararllel from the definition fixes the problem. (I
don't understand enough to know if it's the correct fix though.)

There are 4 instructions with parallel in the definition: divmodpsi4,
udivmodpsi4, divmodsi4, udivmodsi4.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jm.premesnil at free dot fr

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 105850 has been marked as a duplicate of this bug. ***

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[filip.hejsek at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Filip Hejsek <filip.hejsek at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |12.1.0
      Known to work|                            |10.1.0

--- Comment #3 from Filip Hejsek <filip.hejsek at gmail dot com> ---
This is a regression, 10.1 compiled this program without problem. Using git
bisect, i found this was broken in 3ba781d3b5c8efadb60866c9743b657e8f0eb222.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
g:3ba781d3b5c8efadb60866c9743b657e8f0eb222

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[triffid.hunter at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Triffid Hunter <triffid.hunter at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |triffid.hunter at gmail dot com

--- Comment #5 from Triffid Hunter <triffid.hunter at gmail dot com> ---
Created attachment 53561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53561&action=edit
patch based on comment 1

I ran into this issue yesterday (with gcc-13.0.0-20220904).

I made the attached patch based on Comment 1, and it does seem to solve the
issue.

I had some odd lto-related crashes afterwards, but wasn't able to reproduce
them after a clean rebuild of my project - so I suspect there was some odd
interaction with stale/cached object files.

lto crash backtrace in case it's relevant:

avr-gcc -Wall -Wextra -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections
-mmcu=atmega2560 -fno-stack-protector -o
/tmp/arduino_build_820599/sketch_sep10a.ino.elf
/tmp/arduino_build_820599/sketch/sketch_sep10a.ino.cpp.o
/tmp/arduino_build_820599/libraries/SD/File.cpp.o
/tmp/arduino_build_820599/libraries/SD/SD.cpp.o
/tmp/arduino_build_820599/libraries/SD/utility/Sd2Card.cpp.o
/tmp/arduino_build_820599/libraries/SD/utility/SdFile.cpp.o
/tmp/arduino_build_820599/libraries/SD/utility/SdVolume.cpp.o
/tmp/arduino_build_820599/libraries/SPI/SPI.cpp.o
/tmp/arduino_build_820599/../arduino_cache_495395/core/core_arduino_avr_mega_cpu_atmega2560_0535ac2d4e0500949a67f524c7f20d71.a
-L/tmp/arduino_build_820599 -lm
lto1: internal compiler error: Segmentation fault
0x135b2a8 internal_error(char const*, ...)
???:0
0x675125 bp_unpack_string(data_in*, bitpack_d*)
???:0
0x986c9e cl_optimization_stream_in(data_in*, bitpack_d*, cl_optimization*)
???:0
0xc3bf60 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*)
???:0
0x904fad lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
???:0
0x9053d7 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*, bool)
???:0
0x5e9fc8 read_cgraph_and_symbols(unsigned int, char const**)
???:0
0x5d7222 lto_main()
???:0

Note: stopped happening after clean project rebuild, but ideally it should
throw a proper error rather than a segfault?

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kovy3 at seznam dot cz

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107035 has been marked as a duplicate of this bug. ***

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[rainer-gcc at wwad dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

rainer-gcc at wwad dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rainer-gcc at wwad dot de

--- Comment #7 from rainer-gcc at wwad dot de ---
Have the same problem (avr-gcc 12.1.0).

It happens, as soon as I change this code:

```
const uint8_t NumOutputs;  // initialized in class constructor
uint32_t delayMs;  // initialized dynamically in code before

uint32_t threshold = (0xffffffff) / NumOutputs;
if(delayMs > threshold)
{
    delayMs = threshold;
}
```

to this:

```
const uint8_t NumOutputs;  // initialized in class constructor via arg
uint32_t delayMs; // initialized dynamically in code before
uint32_t initialDelayMs; // initalized dynamically in code before

uint32_t threshold = (0xffffffff-initialDelayMs) / NumOutputs;
if(delayMs > threshold)
{
    delayMs = threshold;
}
```

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[fiesh at zefix dot tv]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

fiesh at zefix dot tv changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fiesh at zefix dot tv

--- Comment #8 from fiesh at zefix dot tv ---
Created attachment 54054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54054&action=edit
Two preprocessed files reproducing the issue only at -O3

I seem to also have run into this bug, but maybe my test case is different.

Compiling like this results in the same ICE:

% avr-g++ -O3 -o pheat pheat-IPAddress.ii pheat-Print.ii -flto -mmcu=atmega2560

A lower optimization level does not suffice to trigger it.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[fiesh at zefix dot tv]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #9 from fiesh at zefix dot tv ---
I forgot to mention that my test case requires -flto to be present.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

User99627 <user99627 at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |user99627 at gmx dot com

--- Comment #10 from User99627 <user99627 at gmx dot com> ---
Created attachment 54342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54342&action=edit
Complete Arduino compile trace after compiling the sample sketch (see comment)

I'm running Manjaro and I cannot chose which version of avr-gcc I run on my
system. It currently is avr-gcc 12.2.0. As a consequence I cannot run most
Arduino sketches either, so long as I'm using the system AVR compiler.

Here's a sample sketch that exhibits the error (see attachments):

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  enum { OPEN, CLOSE };

  static uint32_t prevMillis;  // Unsigned long, not int! ;)
  static uint16_t interval;
  static uint8_t state;        // Defaults to OPEN

  uint32_t currentMillis = millis();
  if (currentMillis - prevMillis >= interval)
  {
    prevMillis = currentMillis;
    // Could use a switch/case here:
    if (state == OPEN)
    {
      interval = random(3000, 10000);
      Serial.print("interval blink : ");
      Serial.println(interval);
      state = CLOSE;
    }
    if (state == CLOSE)
    {
      interval = 300;
      Serial.println("open");
      state = OPEN;
    }
  }
}

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #11 from User99627 <user99627 at gmx dot com> ---
I can also tell the bug occurs regardless of the -flto flag is present or not.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #12 from User99627 <user99627 at gmx dot com> ---
Here's some feedback.

I asked in Manjaro Forums to make it so that avr-gcc is capped to version
10.1.0. The answer has been "Manjaro uses Arch application tree".

So I created an account to Arch bugzilla and asked the same question. The bug
report was almost immediately closed ("not our problem, it's upstream").
Upstream of what? I wonder.

Asking here doesn't seem to make things budge any farther.

So I wonder what's the point in lecturing users about contributing and
reporting bugs when the people responsible for packaging such a critical,
dysfunctional application are blatantly ignoring those reports and leave users
to themselves.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[fiesh at zefix dot tv]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #13 from fiesh at zefix dot tv ---
User99627, a few points:

* My test case does require lto to be present.  There's nothing to be gained
from your statement that the bug doesn't require lto, there are test cases for
either case.  The reason I included it is that it may exhibit different
behavior which may or may not stem from a separate bug, so it's worth checking
if both test cases are resolved by a resolution to this issue.

* While this appears to be of life or death importance to you, this may not be
the same for everyone working on gcc, as reflected by its P3 importance.

* Why do you use "dysfuctional software?"  You should avoid doing that.

* Attacking people usually does not improve their willingness to help you,
especially when you don't pay them to help you.

* While you failed to provide anything meaningful to the bug report (your code
snippet is not self-contained valid C code;  no one here will care about your
attempts to get package maintainers of software distributions to do something
stupid and restrict the versions of software they include based on your
preferences), you are still welcome to fix the bug in gcc and provide a patch
yourself.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #14 from User99627 <user99627 at gmx dot com> ---
(In reply to fiesh from comment #13)
> User99627, a few points:
> 
> * My test case does require lto to be present.  There's nothing to be gained
> from your statement that the bug doesn't require lto, there are test cases
> for either case.  The reason I included it is that it may exhibit different
> behavior which may or may not stem from a separate bug, so it's worth
> checking if both test cases are resolved by a resolution to this issue.

That's why I added information about the *very* same error message from avr-gcc
in which link time optimizations don't matter.


> * While this appears to be of life or death importance to you, this may not
> be the same for everyone working on gcc, as reflected by its P3 importance.

No, it doesn't.

That's your (false) interpretation, probably trying to ridicule my
investigation (let's fancy a little about intentions). Or you're just
(intentionally?) conflating "losing patience" with "life and death matters".
See my longer comment below...


> * Why do you use "dysfunctional software?"  You should avoid doing that.

Why do some distribution maintainers keep dysfunctional software? They should
avoid that, don't you think.

You're resorting to a common fallacy called "reversing the burden of proof".
Well tried.

We could go in circles like this for a long, long while...


> * Attacking people usually does not improve their willingness to help you,
> especially when you don't pay them to help you.

Is a forced standby and rejecting righteous clues patiently collected by users
going to gain respect? I'm not attacking people, if you read carefully again.
I'm attacking an *attitude* that looks like disdain (confirmed by this comment,
which I'm replying to) and carelessness. Difference.


> * While you failed to provide anything meaningful to the bug report (your
> code snippet is not self-contained valid C code;  no one here will care
> about your attempts to get package maintainers of software distributions to
> do something stupid and restrict the versions of software they include based
> on your preferences),

I failed?

Nothing meaningful?

So installing the Arduino IDE on your machine and test the sketch I provided
with avr-gcc 11 or above is asking too much, obviously...

That is hypocritical, I mean the attitude and the comment.

Shall I post the complete Arduino library, plus the complete set of make and
build commands (which I did!) to finally get some attention? What if it were a
very complex case of internal bug that only requires a complex set of files for
the bug to show itself?

It's really, *really* easy to ditch my investigation and researches, pretending
I brought nothing useful.

Mind you, I DID provide *all* the information strictly required to reproduce
the bug. Yet, this is judged insufficient.

I've been banging my head against a wall for months now, wondering what to do
because nobody would budge and the responsibility appears left upon users to
find themselves a workaround while, obviously, avr-gcc crashes in specific
cases, the investigation of which is completely denied and trashed by such
comments.

> [...] you are still welcome to fix the bug in gcc and provide a patch yourself.

Oh, that's really low. Is that all of your argumentation? Adding insult to
injury?

Please, stop this hypocrisy, really.

Besides, if you're really careful, you'll realize some user posted the actual
regression and GIT commit that caused the regression (see comment #4). So
basically you're admitting you're ignoring that and asking me to redo the work.
It has already been done and yet ignored, so your suggestion is at best an
insult.

Just tell me: when you find a hole in the street that causes motorcycles to
break their wheel (including yours), do you accept the administration to tell
you that you haven't brought insufficient proof and to tell you to repair the
hole yourself?

Because that's exactly what you're doing.

_____


Now, trying to be constructive. What do you expect from me? Is there a limit to
the number of files required to exhibit the bug? If I post a complete makefile
with build instructions, will this bug be investigated?

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-04-20
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization

--- Comment #15 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
The error is in the combine pass.

Prior to combine, we have the followng insn for divmod (from -da init-regs
dump):

(insn 9 7 11 3 (parallel [
            (set (reg:SI 50)
                (udiv:SI (reg/v:SI 47 [ n ])
                    (reg:SI 51)))
            (set (reg:SI 49)
                (umod:SI (reg/v:SI 47 [ n ])
                    (reg:SI 51)))
            (clobber (reg:SI 18 r18))
            (clobber (reg:SI 22 r22))
            (clobber (reg:HI 26 r26))
            (clobber (reg:HI 30 r30))
        ]) "bug.c":6:15 403 {udivmodsi4}
     (expr_list:REG_UNUSED (reg:HI 30 r30)
        (expr_list:REG_UNUSED (reg:HI 26 r26)
            (expr_list:REG_UNUSED (reg:SI 22 r22)
                (expr_list:REG_UNUSED (reg:SI 18 r18)
                    (nil))))))

This basically encodes a transparent libgcc call to __udivmodsi4 (insn
"*udivmodsi4_call").

The combine dump however reads:

(insn 9 7 11 3 (set (reg:SI 49)
        (umod:SI (reg/v:SI 47 [ n ])
            (reg:SI 51))) "bug.c":6:15 403 {udivmodsi4}
     (expr_list:REG_UNUSED (reg:HI 30 r30)
        (expr_list:REG_UNUSED (reg:HI 26 r26)
            (expr_list:REG_UNUSED (reg:SI 22 r22)
                (expr_list:REG_UNUSED (reg:SI 18 r18)
                    (nil))))))
(insn 11 9 14 3 (set (reg/v:SI 45 [ n ])
        (reg/v:SI 47 [ n ])) 119 {*movsi_split}
     (expr_list:REG_DEAD (reg/v:SI 47 [ n ])
        (nil)))
(insn 14 11 15 3 (set (reg/v:SI 47 [ n ])
        (udiv:SI (reg/v:SI 47 [ n ])
            (reg:SI 51))) "bug.c":7:7 119 {*movsi_split}
     (expr_list:REG_DEAD (reg:SI 50)
        (nil)))

These udiv and umod insn do not exist and are unrecognizable.  Combine should
never have split the original udivmodsi4.

I used the original test case from comment #0 with 

$ avr-gcc bug.c -S -O1 -mmcu=atmega8 -da 

where avr-gcc is from 2023-03-03 master (future v13).

With -fdisable-rtl-combine no ICE occurs.

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |13.1.0
                 CC|                            |gjl at gcc dot gnu.org

--- Comment #16 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
...also from the combine dump, combine hallucinates about an insn that does not
exist:

Trying 11 -> 15:
   11: {r54:SI=udiv(r49:SI,r56:SI);r55:SI=umod(r49:SI,r56:SI);clobber
r18:SI;clobber r22:SI;clobber r26:HI;clobber r30:HI;}
      REG_UNUSED r30:HI
      REG_UNUSED r26:HI
      REG_UNUSED r22:SI
      REG_UNUSED r18:SI
   15: r49:SI=r54:SI
      REG_DEAD r54:SI
Successfully matched this instruction:
(parallel [
        (set (reg/v:SI 49 [ n ])
            (udiv:SI (reg/v:SI 49 [ n ])
                (reg:SI 56)))
        (set (reg:SI 55)
            (umod:SI (reg/v:SI 49 [ n ])
                (reg:SI 56)))
    ])

EMERGENCY DUMP:

Such an insn does not exist, because only versoins with hard-reg clobbers exist
which represent the transparent libcall to __udivmodsi4.

The "emergency dump" then shows the non-existing udiv and umod insns as of
comment 15.

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53561|0                           |1
        is obsolete|                            |

--- Comment #17 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Created attachment 54899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54899&action=edit
pr105753.diff: Patch based on comment 1

This is a patch similar to that of comment 5 (based on a remark in comment 1).  

It removes the superfluous PARALELLs in [u]divmodsi4 and [u]divmodpsi4 insn
patterns. Difference to the previous patch is that it indents the RTL according
to the coding rules (basically lisp for that part).  The patch is untested. 
ChangeLog would be something like:

gcc/
        PR target/105753
        * config/avr/avr.md (divmodpsi4, udivmodpsi4, divmodsi4, udivmodsi4):
        Remove extra parallel in insn patterns.

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #18 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to User99627 from comment #14)
> (In reply to fiesh from comment #13)
> > * While you failed to provide anything meaningful to the bug report (your
> > code snippet is not self-contained valid C code;  [...]
> 
> I failed?

Yepp.  As your test case works without LTO, all you have to do to get a valid
test case is to 

1) Add -v -save-temps to the command line options.

2) Provide that one pre-complied source file *.ii which triggers the ICE.

3) Provide the one command that avr-g++ issues to compile it.  Maybe specifics
of avr-g++ like its version are also interesting.  These are all printed with
-v.

The GCC bug reporting instructions explain that, see "Reporting Bugs" in
https://gcc.gnu.org/bugs/  This link is also shown when an ICE occurs, cf. your
Arduino logs.

There is a "What we need" section and also a "What we do not want" and
"Detailed bug reporting instructions" section to guide you.

> Nothing meaningful?

It doesn't help in reproducing the bug.

> So installing the Arduino IDE on your machine [...] is asking too much,

Speaking for myself: Yes.

Arduino will complile all of its core modules, stuff them in libs, and then
link all that stuff against the user modules intermingled with other commands
like ctags, ranlib and what not.  Why should anyone go through all of this if
*one* pre-compiled file is enough.  Lest alone installing software that has
nothing to do with GCC.

If it's too compicated for you, who is experienced with Arduino, to add "-v
-save-temps" to the compilation options; how is anybody else supposed to figure
out how to distill a test case from all of that.

A reasonable solution would be to report such problems to the Arduino bug
tracker.  If the Arduino maintainers would conclude that it's a genuine GCC
problem, then they would prepare a proper GCC bug report so that the GCC people
can reproduce the problem and work on it.

> Shall I post the complete Arduino library, plus the complete set of make and
> build commands (which I did!) to finally get some attention? What if it were
> a very complex case of internal bug that only requires a complex set of
> files for the bug to show itself?

As of bug reporting instructions: Please no binaries like libs.

There are two cases:

non-LTO: This is the easy case.  The problem occurs during compilation of one
translation unit.  Provide the pre-processed source *.ii and the command that
operates on it as described above.

LTO: By all means, try to find a test case that does not require LTO and thus
requires just one translation unit to reproduce.  If that fails, provide all
involved pre-processed sources and the avr-g++ calls that get you to the bug.
For N modules, this will be generation of N objects *.o from their *.ii
preprocessed sources, together with one final link that links the modules to
the final executable. For 2 modules, it would be something like

$ avr-g++ -mmcu=atmega8 -Os -flto -fpreprocessed  module1.ii -o module1.o
$ avr-g++ -mmcu=atmega8 -Os -flto -fpreprocessed  module2.ii -o module2.o
$ avr-g++ -mmcu=atmega8 -Os -flto module1.ii module2.ii -o modules.elf

IMO it would make sense that the Arduino people had a tool that helped their
users to produce valid bug reports.  This should be easy for the non-LTO case. 
For the LTO case, one would highly prefer a testcase as simple as possible, for
example by running creduce on *all* modules while keeping the bug alive. 

https://embed.cs.utah.edu/creduce/

Most of the creduce'd modules would turn out to be empty, thus not required for
the testcase.

> If I post a complete makefile with build instructions, will this bug
> be investigated?

A proper bug report as lined out above is a prerequisiteso  that the bug will
be inverstigated. It's necessary for investigation, but not sufficient.

The avr backend is plagued by a lack of supporters and people that are willing
to work on it and have the resources to do that.

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Georg-Johann Lay <gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:80348e6aec44966e20ca1ca823247ce1381071eb

commit r14-1016-g80348e6aec44966e20ca1ca823247ce1381071eb
Author: Triffid Hunter <triffid.hunter@gmail.com>
Date:   Sat May 20 07:50:00 2023 +0200

    target/105753: Fix ICE in add_clobbers due to extra PARALLEL in insn.

    This patch removes the superfluous parallel in [u]divmod patterns in
    the AVR backend.  Effect of extra parallel is that add_clobbers reaches
    gcc_unreachable() because the clobbers for [u]divmod are missing.
    If an insn has multiple parts like clobbers, the parallel around the
    parts of the insn pattern is implicit.

    gcc/
            PR target/105753
            * config/avr/avr.md (divmodpsi, udivmodpsi, divmodsi, udivmodsi):
            Remove superfluous "parallel" in insn pattern.
            ([u]divmod<mode>4): Tidy code.  Use gcc_unreachable() instead of
            printing error text to assembly.

    gcc/testsuite/
            PR target/105753
            * gcc.target/avr/torture/pr105753.c: New test.

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
<gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:1c54f35e65c2b7f9f164b6593e288637688ff7a7

commit r13-7360-g1c54f35e65c2b7f9f164b6593e288637688ff7a7
Author: Triffid Hunter <triffid.hunter@gmail.com>
Date:   Sat May 20 07:50:00 2023 +0200

    target/105753: Fix ICE in add_clobbers due to extra PARALLEL in insn.

    This patch removes the superfluous parallel in [u]divmod patterns in
    the AVR backend.  Effect of extra parallel is that add_clobbers reaches
    gcc_unreachable() because the clobbers for [u]divmod are missing.
    If an insn has multiple parts like clobbers, the parallel around the
    parts of the insn pattern is implicit.

    gcc/
            PR target/105753
            Backport from 2023-05-20 https://gcc.gnu.org/r14-1016
            * config/avr/avr.md (divmodpsi, udivmodpsi, divmodsi, udivmodsi):
            Remove superfluous "parallel" in insn pattern.
            ([u]divmod<mode>4): Tidy code.  Use gcc_unreachable() instead of
            printing error text to assembly.

    gcc/testsuite/
            PR target/105753
            Backport from 2023-05-20 https://gcc.gnu.org/r14-1016
            * gcc.target/avr/torture/pr105753.c: New test.

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
<gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:95ca40b04cffd9e3bb8d61654c3a1f2c2d50bb15

commit r12-9627-g95ca40b04cffd9e3bb8d61654c3a1f2c2d50bb15
Author: Triffid Hunter <triffid.hunter@gmail.com>
Date:   Sat May 20 07:50:00 2023 +0200

    target/105753: Fix ICE in add_clobbers due to extra PARALLEL in insn.

    This patch removes the superfluous parallel in [u]divmod patterns in
    the AVR backend.  Effect of extra parallel is that add_clobbers reaches
    gcc_unreachable() because the clobbers for [u]divmod are missing.
    If an insn has multiple parts like clobbers, the parallel around the
    parts of the insn pattern is implicit.

    gcc/
            PR target/105753
            Backport from 2023-05-20 https://gcc.gnu.org/r14-1016
            * config/avr/avr.md (divmodpsi, udivmodpsi, divmodsi, udivmodsi):
            Remove superfluous "parallel" in insn pattern.
            ([u]divmod<mode>4): Tidy code.  Use gcc_unreachable() instead of
            printing error text to assembly.

    gcc/testsuite/
            PR target/105753
            Backport from 2023-05-20 https://gcc.gnu.org/r14-1016
            * gcc.target/avr/torture/pr105753.c: New test.

[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Known to work|                            |12.4.0, 13.2.0
             Status|NEW                         |RESOLVED

--- Comment #22 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Fixed in v12.4 and v13.2+.