From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 162293858421; Wed, 1 Feb 2023 10:36:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 162293858421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675247791; bh=3fRfFzDRUdOnxgR/b19iLCBrx5DrrQ5aSqginrMgxmc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Em63u6Kve1edcQUzBlRSQml2N6mIc1MILG90lX9w32EktBE0Zxndy85UpybEmr22O evR0MgxvvQX008IYkWqZdQ6gyo8aJVL9ywQgmvAV0JdaEZo0WQ3VhVhwnDzjkdf4j1 8ZAenSHfCje/FMC0kq6H4YAeRCfdJpudk8lxCfpQ= From: "user99627 at gmx dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705 Date: Wed, 01 Feb 2023 10:36:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: user99627 at gmx dot com X-Bugzilla-Status: UNCONFIRMED 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 #14 from User99627 --- (In reply to fiesh from comment #13) > User99627, a few points: >=20 > * My test case does require lto to be present. There's nothing to be gai= ned > 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 differe= nt > 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 n= ot > be the same for everyone working on gcc, as reflected by its P3 importanc= e. 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 shou= ld 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 us= ers going to gain respect? I'm not attacking people, if you read carefully agai= n. I'm attacking an *attitude* that looks like disdain (confirmed by this comm= ent, 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 ba= sed > 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 wer= e 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, preten= ding 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 you= rself. 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 actu= al 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 w= ork. 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 te= ll you that you haven't brought insufficient proof and to tell you to repair t= he hole yourself? Because that's exactly what you're doing. _____ Now, trying to be constructive. What do you expect from me? Is there a limi= t to the number of files required to exhibit the bug? If I post a complete makef= ile with build instructions, will this bug be investigated?=