public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/106582] New: Wrong code generation resulting in HardFault
@ 2022-08-11 8:47 jankowski938 at gmail dot com
2022-08-11 9:49 ` [Bug c/106582] " rguenth at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: jankowski938 at gmail dot com @ 2022-08-11 8:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
Bug ID: 106582
Summary: Wrong code generation resulting in HardFault
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jankowski938 at gmail dot com
Target Milestone: ---
It makes -Ofast, -O3 unusable.
1154 pQueryChunk->pSrcDriver =
pParser->pSourceDriver;
080157f4: ldr.w r3, [r9, #20]
080157f8: str.w r3, [r11, #12]
080157fc: b.n 0x801556e <httpG4WebPage+1130>
080157fe: movs r3, #0
08015800: ldr.w r2, [r9, #20]
08015804: str r2, [r3, #12]
08015806: udf #255 ; 0xff <---------- obviously wrong
if (pQueryChunk && ioIsValid(pRawChunk))
{
pQueryChunk->pSrcDriver =
pRawChunk->pSrcDriver;
}
else if (pParser)
{
pQueryChunk->pSrcDriver =
pParser->pSourceDriver;
}
GNU C11 (GNU Tools for STM32 10.3-2021.10.20211105-1100) version 10.3.1
20210824 (release) (arm-none-eabi)
compiled by GNU C version 7.3-win32 20180312, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-std=gnu11' '-g3' '-D' '_GNU_SOURCE=1'
'-D' 'USE_HAL_DRIVER' '-D' '_DEBUG=1' '-D' 'DEBUG_RUN_WITHOUT_CHECKS=1' '-D'
'DEBUGFILEWRITE=0' '-D' 'DEBUG=0' '-D' 'SLOWSPIDEBUG=0' '-D' 'USE_FULL_ASSERT'
'-D' '__USE_SIMPLE_SWO=0' '-D' 'USE_SWOTRACE=1' '-D' 'AMD64' '-D'
'HSE_VALUE=16000000UL' '-D' 'USE_FULL_LL_DRIVER=0' '-D' 'BOOTLOADER_VERSION=1'
'-D' 'ALLOW_SOFTWARE_BKPTS=1' '-D' 'ARM_MATH_CM4' '-D' 'FORCE_CUBE_USB' '-D'
'USE_EMBEDDED_PHY=1' '-D' 'USE_USB_OTG_FS=1' '-D' 'BITMAP_LCD_ALLOWED=0' '-D'
'LCDGUI_ALLOWED=0' '-D' 'LCD_ALLOWED=0' '-D' 'GPS_ALLOWED=0' '-D' 'STM32L4S9xx'
'-D' 'STM32L' '-D' 'INCLUDE_SLEEP_FUNCTIONS=1' '-D' 'COMPILE_FOR_EWB=1' '-D'
'COMPILE_USE_PL4S=1' '-c' '-Ofast' '-ffunction-sections' '-fdata-sections'
'-Wall' '-v' '-fstack-usage' '-MMD' '-MP' '-MF' '-MT' '-specs=nano.specs'
'-mfpu=fpv4-sp-d16' '-mfloat-abi=hard' '-mthumb' '-o' '-mlibarch=armv7e-m+fp'
'-march=armv7e-m+fp'
-march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -meabi=5 -o
Libraries/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_pwr.o
C:\Users\Piotr\AppData\Local\Temp\ccHP5ygN.s
GNU assembler version 2.36.1 (arm-none-eabi) using BFD version (GNU Tools for
STM32 10.3-2021.10.20211105-1100) 2.36.1.20210621
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
@ 2022-08-11 9:49 ` rguenth at gcc dot gnu.org
2022-08-11 10:17 ` jankowski938 at gmail dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-08-11 9:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |arm-none-eabi
Last reconfirmed| |2022-08-11
Version|10.3.0 |10.3.1
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you provide preprocessed source of the file where the crash occurs and the
compiler commandline? Can you also try GCC 10.4 (or a compiler built from
the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
reproduces there?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
2022-08-11 9:49 ` [Bug c/106582] " rguenth at gcc dot gnu.org
@ 2022-08-11 10:17 ` jankowski938 at gmail dot com
2022-08-11 10:19 ` jankowski938 at gmail dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jankowski938 at gmail dot com @ 2022-08-11 10:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #2 from Piotr <jankowski938 at gmail dot com> ---
Created attachment 53434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53434&action=edit
Preprocessed file
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
2022-08-11 9:49 ` [Bug c/106582] " rguenth at gcc dot gnu.org
2022-08-11 10:17 ` jankowski938 at gmail dot com
@ 2022-08-11 10:19 ` jankowski938 at gmail dot com
2022-08-11 14:43 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jankowski938 at gmail dot com @ 2022-08-11 10:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #3 from Piotr <jankowski938 at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> Can you provide preprocessed source of the file where the crash occurs and
> the compiler commandline? Can you also try GCC 10.4 (or a compiler built
> from
> the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
> reproduces there?
Attached preprocessed file.
The compiler comes with STMCubeIDE and I would not manually change it. Full
command line is in the original post (excluding include and library files and
paths)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
` (2 preceding siblings ...)
2022-08-11 10:19 ` jankowski938 at gmail dot com
@ 2022-08-11 14:43 ` pinskia at gcc dot gnu.org
2022-08-11 21:10 ` [Bug middle-end/106582] " jankowski938 at gmail dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-11 14:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>
080157fe: movs r3, #0
08015800: ldr.w r2, [r9, #20]
08015804: str r2, [r3, #12]
This is doing a store at the address 12 which is invalid normally.
I suspect for your code you need -fno-delete-null-pointer-checks .
Or you are missing a null pointer check.
The code does:
if (pQueryChunk && ioIsValid(pRawChunk))
{
pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
}
else
{
if (pParser)
{
pQueryChunk->pSrcDriver = pParser->pSourceDriver;
}
}
But the store for "pQueryChunk->pSrcDriver" is not checked to see if
pQueryChunk was a non-null pointer before doing the store after the check that
pParser was a non-null pointer.
That is I don't think this is a bug in GCC.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
` (3 preceding siblings ...)
2022-08-11 14:43 ` pinskia at gcc dot gnu.org
@ 2022-08-11 21:10 ` jankowski938 at gmail dot com
2022-08-11 21:29 ` jankowski938 at gmail dot com
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jankowski938 at gmail dot com @ 2022-08-11 21:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #5 from Piotr <jankowski938 at gmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> >
> 080157fe: movs r3, #0
> 08015800: ldr.w r2, [r9, #20]
> 08015804: str r2, [r3, #12]
>
> This is doing a store at the address 12 which is invalid normally.
> I suspect for your code you need -fno-delete-null-pointer-checks .
>
> Or you are missing a null pointer check.
>
> The code does:
> if (pQueryChunk && ioIsValid(pRawChunk))
> {
> pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
> }
> else
> {
> if (pParser)
> {
> pQueryChunk->pSrcDriver = pParser->pSourceDriver;
> }
> }
>
> But the store for "pQueryChunk->pSrcDriver" is not checked to see if
> pQueryChunk was a non-null pointer before doing the store after the check
> that pParser was a non-null pointer.
>
>
> That is I don't think this is a bug in GCC.
Thank you for debugging our code :)
1. that chunk was vetted earlier in this function, so there is no need to check
it again here.
2. Offset 12 is not invalid as it is a 32bits (not 64) platform and it is
natively aligned
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
` (4 preceding siblings ...)
2022-08-11 21:10 ` [Bug middle-end/106582] " jankowski938 at gmail dot com
@ 2022-08-11 21:29 ` jankowski938 at gmail dot com
2022-08-11 21:49 ` pinskia at gcc dot gnu.org
2022-08-12 6:37 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jankowski938 at gmail dot com @ 2022-08-11 21:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
Piotr <jankowski938 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Piotr <jankowski938 at gmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> >
> 080157fe: movs r3, #0
> 08015800: ldr.w r2, [r9, #20]
> 08015804: str r2, [r3, #12]
>
> This is doing a store at the address 12 which is invalid normally.
> I suspect for your code you need -fno-delete-null-pointer-checks .
>
> Or you are missing a null pointer check.
>
> The code does:
> if (pQueryChunk && ioIsValid(pRawChunk))
> {
> pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
> }
> else
> {
> if (pParser)
> {
> pQueryChunk->pSrcDriver = pParser->pSourceDriver;
> }
> }
>
> But the store for "pQueryChunk->pSrcDriver" is not checked to see if
> pQueryChunk was a non-null pointer before doing the store after the check
> that pParser was a non-null pointer.
>
>
> That is I don't think this is a bug in GCC.
Thank you for debugging our code :)
1. that chunk was vetted earlier in this function, so there is no need to check
it again here.
2. Offset 12 is not invalid as it is a 32bits (not 64) platform and it is
natively aligned
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
` (5 preceding siblings ...)
2022-08-11 21:29 ` jankowski938 at gmail dot com
@ 2022-08-11 21:49 ` pinskia at gcc dot gnu.org
2022-08-12 6:37 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-11 21:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It is address 12, that is offset 12 from address 0.
And yes there is a path where pQueryChunk can still be null pointer.
If pPage->dwOptions & (0x20000000) is false and (pQuery is nulll or *pQuery !=
'?'), pQueryChunk can be a null pointer when pParser it true.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106582] Wrong code generation resulting in HardFault
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
` (6 preceding siblings ...)
2022-08-11 21:49 ` pinskia at gcc dot gnu.org
@ 2022-08-12 6:37 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-08-12 6:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106582
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Piotr from comment #3)
> (In reply to Richard Biener from comment #1)
> > Can you provide preprocessed source of the file where the crash occurs and
> > the compiler commandline? Can you also try GCC 10.4 (or a compiler built
> > from
> > the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
> > reproduces there?
>
> Attached preprocessed file.
>
> The compiler comes with STMCubeIDE and I would not manually change it. Full
> command line is in the original post (excluding include and library files
> and paths)
Just to note besides the conversation with Andrew - if you got the compiler
from some vendor and are not willing to try a plain version from upstream it
might be useful to report it to the vendor - those often apply changes to GCC
we do not know about and of course those might also introduce bugs (and I hope
they are interested in such bugreports).
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-08-12 6:37 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-11 8:47 [Bug c/106582] New: Wrong code generation resulting in HardFault jankowski938 at gmail dot com
2022-08-11 9:49 ` [Bug c/106582] " rguenth at gcc dot gnu.org
2022-08-11 10:17 ` jankowski938 at gmail dot com
2022-08-11 10:19 ` jankowski938 at gmail dot com
2022-08-11 14:43 ` pinskia at gcc dot gnu.org
2022-08-11 21:10 ` [Bug middle-end/106582] " jankowski938 at gmail dot com
2022-08-11 21:29 ` jankowski938 at gmail dot com
2022-08-11 21:49 ` pinskia at gcc dot gnu.org
2022-08-12 6:37 ` rguenth at gcc dot gnu.org
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).