From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sgh@sgh.dk>
Received: from elmo.sgh.dk (elmo.sgh.dk [139.59.133.142])
 by sourceware.org (Postfix) with ESMTPS id 4C7E83858D35
 for <gcc@gcc.gnu.org>; Sun, 20 Feb 2022 10:34:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C7E83858D35
Received: from [192.168.0.120] (5E8A5A6A.rev.sefiber.dk [94.138.90.106])
 by elmo.sgh.dk (Postfix) with ESMTPSA id 39A3C1F8036
 for <gcc@gcc.gnu.org>; Sun, 20 Feb 2022 10:34:42 +0000 (UTC)
Message-ID: <d1d0921d-d36e-c6cb-9f11-161dbf5b8eda@sgh.dk>
Date: Sun, 20 Feb 2022 11:34:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: Bisected failure
Content-Language: da
To: gcc@gcc.gnu.org
References: <9ec86f65-50dd-6780-936e-a849598911e1@sgh.dk>
From: =?UTF-8?Q?S=c3=b8ren_Holm?= <sgh@sgh.dk>
In-Reply-To: <9ec86f65-50dd-6780-936e-a849598911e1@sgh.dk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Feb 2022 10:34:45 -0000

Please ignore my previous email.

As usual after reaching out - a little light appears in the dark. My 
problem seems to be a kind of race initiated by some hardware state.

Sorry for the noise :)

Den 19.02.2022 kl. 18.11 skrev Søren Holm via Gcc:
> Hi
> 
> My application running on a stm32f7 started to behave "random" when 
> compiled with gcc 10.1 - Gcc 9.x works fine.
> 
> By random I mean this.
> 
> 1. Flash the application onto the target.
> 2. reset - the application starts up fine
> 2. reset again - the application somehow goes haywire during startup 
> effectively starting over with out a reset. That ends up leaving 
> interrups and timers enabled fireing during BSS clear.
> 3. Reset again - now the application starts up fine again.
> 4. reset again - lockup again
> 5. reset again - lockup again
> 6 .......
> 
> 
> I have bisected and verified that whatever makes my
> 
> commit 79f1d8521882de51480866fd7037199d670316bd (HEAD, refs/bisect/bad)
> Author: Jan Hubicka <hubicka@ucw.cz>
> Date:   Thu Nov 14 14:30:46 2019 +0100
> 
>      * params.opt (max-inline-insns-single-O2): Set to 70 (instead of 30).
> 
>      From-SVN: r278221
> 
> 
> Do you have any ideas to how to hunt down this bug? Besides trying to 
> isolate the place where things go wrong. I'm unsure if GCC does 
> something that the hardware does not like or my application is buggy. In 
> any case I'd like to figure out the root cause. I do not like to be 
> stuck at gcc 9 because of these kinds of issues :)
> 
> I'd appreciate any input you might have.
> 
> /Søren