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 105850 has been marked as a duplicate of this bug. ***

This is a regression, 10.1 compiled this program without problem. Using git bisect, i found this was broken in 3ba781d3b5c8efadb60866c9743b657e8f0eb222.

g:3ba781d3b5c8efadb60866c9743b657e8f0eb222

Created attachment 53561 [details]
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 107035 has been marked as a duplicate of this bug. ***

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;
}
```

Created attachment 54054 [details]
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.

I forgot to mention that my test case requires -flto to be present.

Created attachment 54342 [details]
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;
    }
  }
}

I can also tell the bug occurs regardless of the -flto flag is present or not.

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.

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.

(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?

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.

...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.

Created attachment 54899 [details]
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.

(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.

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.

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.

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.

Fixed in v12.4 and v13.2+.