[Bug c/106582] New: Wrong code generation resulting in HardFault

[Bug c/106582] New: Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com]

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

[Bug c/106582] Wrong code generation resulting in HardFault

[rguenth at gcc dot gnu.org]

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?

[Bug c/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com]

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

[Bug c/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com]

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)

[Bug c/106582] Wrong code generation resulting in HardFault

[pinskia at gcc dot gnu.org]

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.

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com]

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

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com]

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

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[pinskia at gcc dot gnu.org]

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.

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[rguenth at gcc dot gnu.org]

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).