Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1547495 - Incorrect branching in postgresql on ppc64 when compiled with -O3
Summary: Incorrect branching in postgresql on ppc64 when compiled with -O3
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 28
Hardware: ppc64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-21 12:48 UTC by Petr Kubat
Modified: 2018-02-28 15:28 UTC (History)
12 users (show)

Fixed In Version: gcc-8.0.1-0.16.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-28 15:28:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
reproducer (4.24 KB, text/x-csrc)
2018-02-21 12:48 UTC, Petr Kubat
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 84503 0 None None None 2018-02-21 16:41:37 UTC
Red Hat Bugzilla 1544349 0 unspecified CLOSED GCC -O1 -ftree-slp-vectorize miscompilation [ppc64][ppc64le] 2022-05-16 11:32:56 UTC

Internal Links: 1544349

Description Petr Kubat 2018-02-21 12:48:18 UTC
Created attachment 1398709 [details]
reproducer

Description of problem:

When postgresql is compiled with the -O3 option on ppc64 using gcc version 8 it quickly runs into out-of-memory issues due to postgresql trying to allocate more memory for its cache even though the cache is not yet fully used.

It seems that when using -O3 on ppc64 postgresql does not even look at the important part of the cache to see if it is indeed full and just reallocates the cache outright.

I have tried reducing the issue to a simple reproducer (attached).

Version-Release number of selected component (if applicable):
gcc-8.0.1-0.14.fc28.ppc64

How reproducible:
Always

Steps to Reproduce:
1. gcc -O3 oom-reproducer.c -o oom-reproducer
2. run oom-reproducer

Actual results:
Doubles the cache size with each call, runs out of memory quickly.

Expected results:
Doubles the cache size only when all of the cache is used.

Additional info:
If postgresql is compiled with gcc version 7 it works correctly.
Also works correctly when compiling with -O2 instead.

The reproducer is able to reproduce the same issue even on different architectures (x86_64) and gcc versions (7.3) when compiled using -O3. This might be because the reproducer is just smallest set of necessary code pulled from postgresql and run inside a simple never-ending loop.
It does not reproduce the issue when compiled with -O2, however.

Comment 1 Jakub Jelinek 2018-02-21 13:49:15 UTC
The MemSet macro is clearly invalid, violates aliasing; for GCC changing
-            long *_start = (long *) _vstart; \
+            long __attribute__((__may_alias__)) *_start = (long *) _vstart; \
should cure that though.  Wonder why you just don't use memset instead though, gcc does inline memset with constant and reasonably small sizes.

That said, that doesn't help in this case, so looking into it.

Comment 2 Tom Lane 2018-02-21 14:56:05 UTC
(In reply to Jakub Jelinek from comment #1)
> Wonder why you just don't use memset instead

The MemSet macro is circa 20 years old, far predating compilers that would optimize memset() calls by themselves (or that would have aliasing concerns).  There have been a few discussions about changing it to plain memset(), but inertia has won out so far.  PG uses -fno-strict-aliasing because there's been no vetting of the code base for aliasing problems, so it's unsurprising that we've seen no concrete problems from the existing coding of MemSet.

Comment 3 Jakub Jelinek 2018-02-21 15:10:01 UTC
Started with http://gcc.gnu.org/r241789, work-around would be -O3 -fno-store-merging or just using memset unconditionally.  I'll try to reduce it further and debug.

Comment 4 Jakub Jelinek 2018-02-28 15:28:13 UTC
Should be fixed in gcc-8.0.1-0.16.fc28.


Note You need to log in before you can comment on or make changes to this bug.