[Bug c/96304] New: Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[Bug c/96304] New: Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[drh at sqlite dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96304

            Bug ID: 96304
           Summary: Possible mis-compile of SQLite for ARM using gcc 8.3.0
                    and -O2
           Product: gcc
           Version: 8.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: drh at sqlite dot org
  Target Milestone: ---

Gcc 8.3.0 appears to be miscompiling SQLite for ARM when using -O2. A correct
build occurs with any other optimization setting, on X86_64, and with versions
of gcc in the 4.x.x timeframe (the only other versions tested).  The bug
originates from two Gentoo bug reports against SQLite that claim the problem
also appears on PPC and SPARC, but I do not have appropriate hardware at hand
to verify that.

Unfortunately, I do not have a concise test case for you.  However, I can
demonstrate the problem using one large C source file and one data file, as
described here: https://sqlite.org/forum/forumpost/c3e9c0edfa

We can work around the problem in SQLite by marking one particular function
using __attribute__((noinline)). You can see our work-around here:
https://www.sqlite.org/src/info/40c44d38104dfcb6

The forum post in the first link describes how to recreate the problem. I will
repeat that text here for completeness:

  1.  Download https://sqlite.org/tmp/gcc-problem-20200723/sftest.c (7.8MB) and
https://sqlite.org/tmp/gcc-problem-20200723/data1.db (252KB).
  2.  Compile using: "$GCC -O2 sftest.c"
  3.  Run like this: "./a.out run data1.db"

The expected output is "d1.db:  339 cases, 0 crashes" but the program hits an
assert() when compiled for ARM using -O2 using more recent versions of gcc
(newer than the 4.9.2 version that is the default on my raspberry PI). 
Additional analysis of the problem is in the forum post and the check-in linked
above.

[Bug target/96304] Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96304

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does -fno-strict-aliasing helps?

[Bug target/96304] Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[drh at sqlite dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96304

--- Comment #2 from D. Richard Hipp <drh at sqlite dot org> ---
(In reply to Andrew Pinski from comment #1)
> Does -fno-strict-aliasing helps?

The problem goes away if I compile with -fno-strict-aliasing. I should have
thought to try that.

But, are we violating aliasing rules here?  What am I missing?

[Bug target/96304] Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96304

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
> But, are we violating aliasing rules here?  What am I missing?

Likely you are, but I must admit it's sometimes quite difficult to find that.
>From quickly looking at the function, you may violate it here:

  MemJournal *p = (MemJournal*)pJfd;

maybe

MemJournal *p = (MemJournal*)(char*)pJfd;

can solve it.
Unfortunately I can't reproduce it on my x86_64-linux box.

[Bug target/96304] Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96304

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #3)
> > But, are we violating aliasing rules here?  What am I missing?
> 
> Likely you are, but I must admit it's sometimes quite difficult to find that.
> From quickly looking at the function, you may violate it here:
> 
>   MemJournal *p = (MemJournal*)pJfd;
> 
> maybe
> 
> MemJournal *p = (MemJournal*)(char*)pJfd;
> 
> can solve it.
> Unfortunately I can't reproduce it on my x86_64-linux box.

An intermediate cast does never solve any strict-aliasing issue.

[Bug target/96304] Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[drh at sqlite dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96304

--- Comment #5 from D. Richard Hipp <drh at sqlite dot org> ---
((In reply to Martin Liška from comment #3)
> > But, are we violating aliasing rules here?  What am I missing?
> 
> Likely you are, but I must admit it's sometimes quite difficult to find that.
> From quickly looking at the function, you may violate it here:
> 
>   MemJournal *p = (MemJournal*)pJfd;
> 

I agree.  I'll work around the problem in a different way.  Please cancel
this ticket.  And thanks for the help.

[Bug target/96304] Possible mis-compile of SQLite for ARM using gcc 8.3.0 and -O2

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96304

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
Thus marking as invalid.