Bug 1645400 - gcc miscompiles bitset code in mesa
Summary: gcc miscompiles bitset code in mesa
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1645850 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-02 07:11 UTC by Dave Airlie
Modified: 2018-11-10 03:29 UTC (History)
16 users (show)

Fixed In Version: gcc-8.2.1-5.fc29 gcc-8.2.1-5.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-09 06:03:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 87859 0 P1 RESOLVED store-merging miscompilation of mesa 2020-09-25 05:34:42 UTC
Red Hat Bugzilla 1646150 0 unspecified CLOSED mesa 18.2.3 update breaks accelerated compositing in WebKitGTK+, many webpages fail to display 2021-02-22 00:41:40 UTC

Internal Links: 1646150

Description Dave Airlie 2018-11-02 07:11:56 UTC
Description of problem:

Some recent gcc push (at least 8.2.1 is broken, 8.0.1 seems okay) I can bisect further next week, breaks mesa compilation of a bunch of bitfields.

Broken asm:


   input_layout_mask.flags.q.precise = 1;
   input_layout_mask.flags.q.sample = 1;
   input_layout_mask.flags.q.smooth = 1;
   input_layout_mask.flags.q.non_coherent = 1;

   if (state->has_bindless()) {
     203:       80 ba d6 02 00 00 00    cmpb   $0x0,0x2d6(%rdx)
     20a:       48 c7 44 24 40 00 00    movq   $0x60000000,0x40(%rsp)
     211:       00 60 
     213:       c7 44 24 48 00 00 00    movl   $0x0,0x48(%rsp)
     21a:       00 
     21b:       c7 84 24 10 01 00 00    movl   $0x1e000000,0x110(%rsp)
     222:       00 00 00 1e 
     226:       c7 84 24 e0 01 00 00    movl   $0xc00000,0x1e0(%rsp)
     22d:       00 00 c0 00 
     231:       c7 84 24 b4 02 00 00    movl   $0x2000,0x2b4(%rsp)
     238:       00 20 00 00 
     23c:       48 c7 84 24 80 03 00    movq   $0x2840a5,0x380(%rsp)
     243:       00 a5 40 28 00 

Original asm:

     203:       80 ba d6 02 00 00 00    cmpb   $0x0,0x2d6(%rdx)
     20a:       48 c7 44 24 40 00 00    movq   $0x60000000,0x40(%rsp)
     211:       00 60 
     213:       c7 44 24 48 00 00 00    movl   $0x0,0x48(%rsp)
     21a:       00 
     21b:       c7 84 24 10 01 00 00    movl   $0x1e000000,0x110(%rsp)
     222:       00 00 00 1e 
     226:       c7 84 24 e0 01 00 00    movl   $0xc00000,0x1e0(%rsp)
     22d:       00 00 c0 00 
     231:       c7 84 24 b4 02 00 00    movl   $0x2000,0x2b4(%rsp)
     238:       00 20 00 00 
     23c:       48 c7 84 24 80 03 00    movq   $0x2be3e7,0x380(%rsp)
     243:       00 e7 e3 2b 00 

Note the change in 23c movq value.

The code in question is 

https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/compiler/glsl/ast_type.cpp#L254

I intend to dig a bit more next week, but I'd thought I'd at least give a headsup and file a bug.

Comment 1 Jakub Jelinek 2018-11-02 07:40:22 UTC
8.2.1-whatexactly vs. 8.0.1-whatexactly?
Can you please provide a preprocessed source + full gcc/g++ command line for the corresponding file?

Comment 2 Jakub Jelinek 2018-11-02 07:46:52 UTC
Note, as a workaround most likely -fno-store-merging should work.

Comment 3 Jakub Jelinek 2018-11-02 08:26:42 UTC
Actually, reproduced it myself even without preprocessed source:

struct S {
  union F {
    struct T {
#define A(n) unsigned n:1;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
      B(f) B(f1) B(f2) B(f3) B(f4) B(f5) A(f60) A(f61) A(f62) A(f63) A(f64) A(f65) A(f66)
    } q;
    unsigned int i[3];
  } f;
};

__attribute__((noipa)) void
bar (unsigned *x)
{
  if (x[0] != 0x002be3e7)
    __builtin_abort ();
}

__attribute__((noipa)) void
foo (unsigned char *state)
{
  struct S i;
  i.f.i[0] = 0; i.f.i[1] = 0; i.f.i[2] = 0; i.f.q.f7 = 1; i.f.q.f2 = 1; i.f.q.f21 = 1;
  i.f.q.f19 = 1; i.f.q.f14 = 1; i.f.q.f5 = 1; i.f.q.f0 = 1; i.f.q.f15 = 1; i.f.q.f16 = 1;
  i.f.q.f6 = 1; i.f.q.f9 = 1; i.f.q.f17 = 1; i.f.q.f1 = 1; i.f.q.f8 = 1; i.f.q.f13 = 1;
  i.f.q.f66 = 1;
  if (*state)
    {
      i.f.q.f37 = 1; i.f.q.f38 = 1; i.f.q.f39 = 1; i.f.q.f40 = 1; i.f.q.f41 = 1; i.f.q.f36 = 1;
    }
  bar (i.f.i);
}

int
main ()
{
  unsigned char zero = 0;
  foo (&zero);
  return 0;
}

Comment 4 Jakub Jelinek 2018-11-02 08:31:37 UTC
Started with my http://gcc.gnu.org/r264232 .

Comment 5 Jakub Jelinek 2018-11-05 10:44:47 UTC
*** Bug 1645850 has been marked as a duplicate of this bug. ***

Comment 6 Jakub Jelinek 2018-11-05 18:50:40 UTC
gcc-8.2.1-5.fc{28,29,30} which should fix this is building in koji.

Comment 7 Michael Catanzaro 2018-11-05 19:22:30 UTC
Igor, maybe you could get a buildroot override to speed up the process of releasing a fixed mesa?

Comment 8 Jakub Jelinek 2018-11-05 19:30:45 UTC
Because arm 32-bit is extremely slow, the gcc builds usually take a day or so, so should finish probably tomorrow noon in Europe or so.

Comment 9 Jakub Jelinek 2018-11-05 19:31:56 UTC
That said, f29 x86_64 rpm is built, so if somebody wants to test it out outside of koji, it is possible manually:
https://koji.fedoraproject.org/koji/taskinfo?taskID=30689762

Comment 10 Jakub Jelinek 2018-11-06 12:00:45 UTC
gcc-8.2.1-5.fc{28,29,30} built fine, is in f30 now, before filing bodhi erratas for f28/f29 I'd like to hear that it actually resolved the mesa issues.  Can anyone please verify that?

Comment 11 Robert-André Mauchin 🐧 2018-11-06 16:03:03 UTC
Recompiled Mesa 18.2.4 locally with this new GCC and the bug #1645850 is solved. Playback with mpv is fine and without shaders issues anymore.

Comment 12 Fedora Update System 2018-11-06 23:36:58 UTC
gcc-8.2.1-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-de93530d49

Comment 13 Fedora Update System 2018-11-06 23:37:37 UTC
gcc-8.2.1-5.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cd24e05681

Comment 14 Fedora Update System 2018-11-07 04:13:53 UTC
gcc-8.2.1-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-de93530d49

Comment 15 Fedora Update System 2018-11-07 04:25:17 UTC
gcc-8.2.1-5.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-cd24e05681

Comment 16 Fedora Update System 2018-11-09 06:03:27 UTC
gcc-8.2.1-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2018-11-10 03:29:28 UTC
gcc-8.2.1-5.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.


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