* Bisected failure
@ 2022-02-19 17:11 Søren Holm
2022-02-20 10:34 ` Søren Holm
0 siblings, 1 reply; 2+ messages in thread
From: Søren Holm @ 2022-02-19 17:11 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Bisected failure
2022-02-19 17:11 Bisected failure Søren Holm
@ 2022-02-20 10:34 ` Søren Holm
0 siblings, 0 replies; 2+ messages in thread
From: Søren Holm @ 2022-02-20 10:34 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-02-20 10:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-19 17:11 Bisected failure Søren Holm
2022-02-20 10:34 ` Søren Holm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).