From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6FF0F3858C66; Sun, 23 Apr 2023 10:58:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6FF0F3858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1682247523; bh=v6GnKqeb8WLFidptvOdIwSw5dXDcf+FVaRNys17YxCk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iJoQMBL5wMphN8jrycfuWhfHR26ZNXzVEUt7d4usmgun2/TRlEQiqXmP6r7egNJy2 Iq0lv2KjOV/4pQtav2KIKSh4qSnzHdpykU2ErgTahdI53Ra0Ge4US/U/j4R+9LQL73 gCNDo2+OwOr7ZwSxRF3f4zYnKpvHM9QoA/D1X9rs= From: "gjl at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705 Date: Sun, 23 Apr 2023 10:58:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: gjl at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105753 --- Comment #18 from Georg-Johann Lay --- (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 (yo= ur > > code snippet is not self-contained valid C code; [...] >=20 > I failed? Yepp. As your test case works without LTO, all you have to do to get a val= id test case is to=20 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 specif= ics of avr-g++ like its version are also interesting. These are all printed wi= th -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 comman= ds 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 fi= gure 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 pe= ople 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 w= ere > 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 o= ne translation unit. Provide the pre-processed source *.ii and the command th= at operates on it as described above. LTO: By all means, try to find a test case that does not require LTO and th= us 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 bu= g. 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=3Datmega8 -Os -flto -fpreprocessed module1.ii -o module1.o $ avr-g++ -mmcu=3Datmega8 -Os -flto -fpreprocessed module2.ii -o module2.o $ avr-g++ -mmcu=3Datmega8 -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 ca= se.=20 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.=20 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 wi= ll be inverstigated. It's necessary for investigation, but not sufficient. The avr backend is plagued by a lack of supporters and people that are will= ing to work on it and have the resources to do that.=