[Bug tree-optimization/103860] New: wrong code at -O3 with -fPIC on x86_64-linux-gnu

[Bug tree-optimization/103860] New: wrong code at -O3 with -fPIC on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 103860
           Summary: wrong code at -O3 with -fPIC on x86_64-linux-gnu
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from GCC 5.4, and impact GCC 6.1 and later. 

[591] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211228 (experimental) (GCC) 
[592] % 
[592] % gcctk -O3 small.c; ./a.out
[593] % gcctk -O2 -fPIC small.c; ./a.out
[594] % 
[594] % gcctk -O3 -fPIC small.c
[595] % ./a.out
Segmentation fault
[596] % 
[596] % cat small.c
char a(char b, char c) { return b + c; }
static int d, *e;
int f;
int main() {
  char l = -1;
  for (; l; l = a(l, 1)) {
    while (d < 0)
      ;
    if (d > 0) {
      f = 0;
      *e = 0;
    }
  }
  d = 0;
  return 0;
}

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-12-29
            Summary|wrong code at -O3 with      |[9/10/11/12 Regression]
                   |-fPIC on x86_64-linux-gnu   |wrong code at -O3 with
                   |                            |-fPIC on x86_64-linux-gnu
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org
          Component|tree-optimization           |rtl-optimization
     Ever confirmed|0                           |1
   Target Milestone|---                         |9.5
            Version|unknown                     |12.0
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r6-5224-g82ad51444ff2a9faf3e019b07c98fbae0e753a0f

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This seems to be clearly a shrink-wrapping bug.
Before pro_and_epilogue we have in RTL:
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 3 2 NOTE_INSN_FUNCTION_BEG)
(insn 3 2 34 2 (set (reg/v:QI 0 ax [orig:84 l ] [84])
        (const_int -1 [0xffffffffffffffff])) "pr103860.c":14:10 83
{*movqi_internal}
     (expr_list:REG_EQUAL (const_int -1 [0xffffffffffffffff])
        (nil)))

(code_label 34 3 6 3 7 (nil) [1 uses])
(note 6 34 7 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note 7 6 10 3 NOTE_INSN_DELETED)
(insn 10 7 11 3 (set (reg:CCGOC 17 flags)
        (compare:CCGOC (mem/c:SI (symbol_ref:DI ("d") [flags 0x2]  <var_decl
0x7f8ba5c9ac60 d>) [1 d+0 S4 A32])
            (const_int 0 [0]))) 7 {*cmpsi_ccno_1}
     (nil))
(jump_insn 11 10 13 3 (set (pc)
        (if_then_else (ge (reg:CCGOC 17 flags)
                (const_int 0 [0]))
            (label_ref 16)
            (pc))) 873 {*jcc}
     (int_list:REG_BR_PROB 118111604 (nil))
 -> 16)

(code_label 13 11 12 5 5 (nil) [1 uses])
(note 12 13 52 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 52 12 53 5 (set (pc)
        (label_ref 13)) 874 {jump}
     (nil)
 -> 13)

(barrier 53 52 16)

(code_label 16 53 17 6 4 (nil) [1 uses])
(note 17 16 19 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(jump_insn 19 17 20 6 (set (pc)
        (if_then_else (eq (reg:CCGOC 17 flags)
                (const_int 0 [0]))
            (label_ref 27)
            (pc))) "pr103860.c":18:10 873 {*jcc}
     (int_list:REG_BR_PROB 536870916 (nil))

The problem is that shrink-wrapping decides to put the
(insn/f 55 77 56 12 (parallel [
            (set (reg/f:DI 7 sp)
                (plus:DI (reg/f:DI 7 sp)
                    (const_int -8 [0xfffffffffffffff8])))
            (clobber (reg:CC 17 flags))
            (clobber (mem:BLK (scratch) [0  A8]))
        ]) "pr103860.c":12:1 -1
     (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
            (plus:DI (reg/f:DI 7 sp)
                (const_int -8 [0xfffffffffffffff8])))
        (nil)))
instruction on the edge in between bb3 and bb6, but that isn't correct, because
the flags register is live on that edge (set in insn 10, used in insns 11 and
19) and the prologue instruction clobbers it.

So we end up with:
main:
        movl    d(%rip), %edx
        movl    $-1, %eax
        testl   %edx, %edx
        jns     .L12
.L11:
        jmp     .L11
.L12:
        subq    $8, %rsp
.L4:
        je      .L6
        movq    f@GOTPCREL(%rip), %rax
        movl    $0, (%rax)
        movl    $0, 0
        ud2
.L6:
(.palign* and .cfi* directives and useless labels manually elided), which is
wrong, because je .L6 is done depending on whether %rsp was 8 before the
subtration (pretty much never), rather than depending on whether %edx is 0.

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In the:
  while (!vec.is_empty () && pro != entry)
    {
      while (pro != entry && !can_get_prologue (pro, prologue_clobbered))
        {
          pro = get_immediate_dominator (CDI_DOMINATORS, pro);

          if (bitmap_set_bit (bb_with, pro->index))
            vec.quick_push (pro);
        }

      basic_block bb = vec.pop ();
      if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size))
        while (!dominated_by_p (CDI_DOMINATORS, bb, pro))
          {
            gcc_assert (pro != entry);

            pro = get_immediate_dominator (CDI_DOMINATORS, pro);

            if (bitmap_set_bit (bb_with, pro->index))
              vec.quick_push (pro);
          }

      FOR_EACH_EDGE (e, ei, bb->succs)
        if (e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun)
            && bitmap_set_bit (bb_with, e->dest->index))
          vec.quick_push (e->dest);
    }
loop, initially we try as pro bb 7 for which can_get_prologue (pro,
prologue_clobbered) is true.
We iterate for a while, until bb_with is 3, 4, 5, 6, 7, 8, pro still 7,
and we pop bb 6, for which can_dup_for_shrink_wrapping is false.
vec at this point is empty.  As bb 6 isn't dominated by pro 7, we change
pro to the immediate dominator of bb 7 which is bb 5, and as it already is in
bb_with bitmap, we don't push anything.  bb 6 also has no successors (it traps
at the end), so we don't push there anything either.  And because vec.is_empty
() is true, the outer loop doesn't iterate any longer and so nothing checks if
can_get_prologue (pro, prologue_clobbered) (which is false for bb 5).

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52088&action=edit
gcc12-pr103860.patch

Untested fix.

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
That looks good.  But can you always set maybe_check_pro to true (and then
optimise it away of course)?

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52088|0                           |1
        is obsolete|                            |

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52089&action=edit
gcc12-pr103860.patch

Not sure I understand what you'd like to see.
But, thinking more about it, we can easily avoid all the code duplication by
moving the vec.is_empty () test out of the while loop condition, right before
we pop from the stack.  That way this can_get_prologue check is done on pro not
just before we pop something from the stack, but also after the last iteration
when there is nothing further on the stack.

If we wanted to avoid calling can_get_prologue that often (if pro doesn't
change we call it again and again already before my patch), we could also add a
var to hold the last pro we've successfully checked and only do this checking
if we get a new pro.

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 52089 [details]
> gcc12-pr103860.patch
> 
> Not sure I understand what you'd like to see.

Exactly what you did :-)  Well, I didn't see you could fold it all up like
that, wow.

> But, thinking more about it, we can easily avoid all the code duplication by
> moving the vec.is_empty () test out of the while loop condition, right
> before we pop from the stack.  That way this can_get_prologue check is done
> on pro not just before we pop something from the stack, but also after the
> last iteration
> when there is nothing further on the stack.

Yup.

> If we wanted to avoid calling can_get_prologue that often (if pro doesn't
> change we call it again and again already before my patch), we could also
> add a var to hold the last pro we've successfully checked and only do this
> checking if we get a new pro.

How can pro not change?  It is important that can_get_prologue is called at
most once for every block, so that this is O(n) for every function (in number
of edges in this case).  All of this is linear, I'd like to keep it that way!

[Bug rtl-optimization/103860] [9/10/11/12 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1820137ba624d7eb2004a10f9632498b6bc1696a

commit r12-6150-g1820137ba624d7eb2004a10f9632498b6bc1696a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Dec 30 14:23:18 2021 +0100

    shrink-wrapping: Fix up prologue block discovery [PR103860]

    The following testcase is miscompiled, because a prologue which
    contains subq $8, %rsp instruction is emitted at the start of
    a basic block which contains conditional jump that depends on
    flags register set in an earlier basic block, the prologue instruction
    then clobbers those flags.
    Normally this case is checked by can_get_prologue predicate, but this
    is done only at the start of the loop.  If we update pro later in the
    loop (because some bb shouldn't be duplicated) and then don't push
    anything further into vec and the vec is already empty (this can happen
    when the new pro is already in bb_with bitmask and either has no successors
    (that is the case in the testcase where that bb ends with a trap) or
    all the successors are already in bb_with, then the loop doesn't iterate
    further and can_get_prologue will not be checked.

    The following simple patch makes sure we call can_get_prologue even after
    the last former iteration when vec is already empty and only break from
    the loop afterwards (and only if the updating of pro done because of
    !can_get_prologue didn't push anything into vec again).

    2021-12-30  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/103860
            * shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue
is
            called on pro even if nothing further is pushed into vec.

            * gcc.dg/pr103860.c: New test.

[Bug rtl-optimization/103860] [9/10/11 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression]     |[9/10/11 Regression] wrong
                   |wrong code at -O3 with      |code at -O3 with -fPIC on
                   |-fPIC on x86_64-linux-gnu   |x86_64-linux-gnu

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug rtl-optimization/103860] [9/10/11 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:801b2c880c8079934ac186ea1c31f3bf4af5aef3

commit r12-6202-g801b2c880c8079934ac186ea1c31f3bf4af5aef3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jan 4 10:12:17 2022 +0100

    shrink-wrapping: Don't call can_get_prologue unnecessarily [PR103860]

    On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote:
    > > The following simple patch makes sure we call can_get_prologue even
after
    > > the last former iteration when vec is already empty and only break from
    > > the loop afterwards (and only if the updating of pro done because of
    > > !can_get_prologue didn't push anything into vec again).

    During the development of the above patch I've noticed that in many cases
    we call can_get_prologue often on the same pro again and again and again,
    we can have many basic blocks pushed into vec and if most of those don't
    require pro updates, i.e.
          basic_block bb = vec.pop ();
          if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size))
            while (!dominated_by_p (CDI_DOMINATORS, bb, pro))
    isn't true, then pro is can_get_prologue checked for each bb in the vec.

    The following simple patch just remembers which bb we've verified already
    and verifies again only when pro changes.  Most of the patch is just
    reindentation.

    2022-01-04  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/103860
            * shrink-wrap.c (try_shrink_wrapping): Don't call can_get_prologue
            uselessly for blocks for which it has been called already.

[Bug rtl-optimization/103860] [9/10/11 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug rtl-optimization/103860] [9/10/11 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a4e45a579e274eef09a1f8e7251927c084097322

commit r11-9494-ga4e45a579e274eef09a1f8e7251927c084097322
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Dec 30 14:23:18 2021 +0100

    shrink-wrapping: Fix up prologue block discovery [PR103860]

    The following testcase is miscompiled, because a prologue which
    contains subq $8, %rsp instruction is emitted at the start of
    a basic block which contains conditional jump that depends on
    flags register set in an earlier basic block, the prologue instruction
    then clobbers those flags.
    Normally this case is checked by can_get_prologue predicate, but this
    is done only at the start of the loop.  If we update pro later in the
    loop (because some bb shouldn't be duplicated) and then don't push
    anything further into vec and the vec is already empty (this can happen
    when the new pro is already in bb_with bitmask and either has no successors
    (that is the case in the testcase where that bb ends with a trap) or
    all the successors are already in bb_with, then the loop doesn't iterate
    further and can_get_prologue will not be checked.

    The following simple patch makes sure we call can_get_prologue even after
    the last former iteration when vec is already empty and only break from
    the loop afterwards (and only if the updating of pro done because of
    !can_get_prologue didn't push anything into vec again).

    2021-12-30  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/103860
            * shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue
is
            called on pro even if nothing further is pushed into vec.

            * gcc.dg/pr103860.c: New test.

    (cherry picked from commit 1820137ba624d7eb2004a10f9632498b6bc1696a)

[Bug rtl-optimization/103860] [9/10 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] wrong  |[9/10 Regression] wrong
                   |code at -O3 with -fPIC on   |code at -O3 with -fPIC on
                   |x86_64-linux-gnu            |x86_64-linux-gnu

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.3 too.

[Bug rtl-optimization/103860] [9/10 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:d88dde820ae61cde3f750b03f2dc4f6e6b4c52fc

commit r10-10662-gd88dde820ae61cde3f750b03f2dc4f6e6b4c52fc
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Dec 30 14:23:18 2021 +0100

    shrink-wrapping: Fix up prologue block discovery [PR103860]

    The following testcase is miscompiled, because a prologue which
    contains subq $8, %rsp instruction is emitted at the start of
    a basic block which contains conditional jump that depends on
    flags register set in an earlier basic block, the prologue instruction
    then clobbers those flags.
    Normally this case is checked by can_get_prologue predicate, but this
    is done only at the start of the loop.  If we update pro later in the
    loop (because some bb shouldn't be duplicated) and then don't push
    anything further into vec and the vec is already empty (this can happen
    when the new pro is already in bb_with bitmask and either has no successors
    (that is the case in the testcase where that bb ends with a trap) or
    all the successors are already in bb_with, then the loop doesn't iterate
    further and can_get_prologue will not be checked.

    The following simple patch makes sure we call can_get_prologue even after
    the last former iteration when vec is already empty and only break from
    the loop afterwards (and only if the updating of pro done because of
    !can_get_prologue didn't push anything into vec again).

    2021-12-30  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/103860
            * shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue
is
            called on pro even if nothing further is pushed into vec.

            * gcc.dg/pr103860.c: New test.

    (cherry picked from commit 1820137ba624d7eb2004a10f9632498b6bc1696a)

[Bug rtl-optimization/103860] [9/10 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:5d96fb401e1c03b6b6a6ec2c5276dfdc479bb3e4

commit r9-10115-g5d96fb401e1c03b6b6a6ec2c5276dfdc479bb3e4
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Dec 30 14:23:18 2021 +0100

    shrink-wrapping: Fix up prologue block discovery [PR103860]

    The following testcase is miscompiled, because a prologue which
    contains subq $8, %rsp instruction is emitted at the start of
    a basic block which contains conditional jump that depends on
    flags register set in an earlier basic block, the prologue instruction
    then clobbers those flags.
    Normally this case is checked by can_get_prologue predicate, but this
    is done only at the start of the loop.  If we update pro later in the
    loop (because some bb shouldn't be duplicated) and then don't push
    anything further into vec and the vec is already empty (this can happen
    when the new pro is already in bb_with bitmask and either has no successors
    (that is the case in the testcase where that bb ends with a trap) or
    all the successors are already in bb_with, then the loop doesn't iterate
    further and can_get_prologue will not be checked.

    The following simple patch makes sure we call can_get_prologue even after
    the last former iteration when vec is already empty and only break from
    the loop afterwards (and only if the updating of pro done because of
    !can_get_prologue didn't push anything into vec again).

    2021-12-30  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/103860
            * shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue
is
            called on pro even if nothing further is pushed into vec.

            * gcc.dg/pr103860.c: New test.

    (cherry picked from commit 1820137ba624d7eb2004a10f9632498b6bc1696a)

[Bug rtl-optimization/103860] [9/10 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.