public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
Date: Tue, 13 Feb 2024 15:58:38 +0000	[thread overview]
Message-ID: <bug-113907-4-7ZAXqJbNet@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113907-4@http.gcc.gnu.org/bugzilla/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, I think it is IPA-ICF.
What happens is that fnsplit splits the uprv_copyArray{16,32,64} functions,
where the
inline part does what is actually different among the functions, i.e. the
tests which among other do the early out for
length<0 || (length&1)!=0
or
length<0 || (length&3)!=0
or
length<0 || (length&7)!=0
among other things, and then the *.part.0 parts which are exactly the same for
the 3 functions IL wise, except for the unfortunately differences in the
ranges.
So, essentially just
  <bb 2> [local count: 132713219]:
  _2 = length_1(D) != 0;
  _5 = inData_3(D) != outData_4(D);
  _6 = _2 & _5;
  if (_6 != 0)
    goto <bb 3>; [33.00%]
  else
    goto <bb 4>; [67.00%]

  <bb 3> [local count: 43795362]:
  # RANGE [irange] unsigned int [N, 2147483647] MASK 0x7ffffffe VALUE 0x0
  length.43_7 = (unsigned int) length_1(D);
  # USE = anything
  # CLB = anything
  memcpy (outData_4(D), inData_3(D), length.43_7);

  <bb 4> [local count: 132713219]:

  <bb 5> [local count: 132713219]:
  # RANGE [irange] int [0, 0][N, +INF] MASK 0x7fffffff VALUE 0x0
  # _8 = PHI <length_1(D)(4)>
  return _8;
where N is 2, 4 or 8.
Now IPA-ICF comes, doesn't care about ranges, merges all 3 into one and picks
there
the most unfortunate case, the case from the copyData64 part with N 8.
Later on we inline this back into the functions, the function splitting was
useless.

So, the question is what to do in IPA-ICF.  Should we punt on range
differences, reset all ranges or try to merge the ranges from all the functions
merged together?
I think the last would be best.

  parent reply	other threads:[~2024-02-13 15:58 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13 12:49 [Bug middle-end/113907] New: " sjames at gcc dot gnu.org
2024-02-13 12:55 ` [Bug middle-end/113907] " sjames at gcc dot gnu.org
2024-02-13 13:00 ` sjames at gcc dot gnu.org
2024-02-13 13:00 ` rguenth at gcc dot gnu.org
2024-02-13 13:14 ` jakub at gcc dot gnu.org
2024-02-13 14:17 ` sjames at gcc dot gnu.org
2024-02-13 14:18 ` sjames at gcc dot gnu.org
2024-02-13 14:19 ` sjames at gcc dot gnu.org
2024-02-13 14:22 ` sjames at gcc dot gnu.org
2024-02-13 14:23 ` sjames at gcc dot gnu.org
2024-02-13 14:24 ` sjames at gcc dot gnu.org
2024-02-13 14:49 ` jakub at gcc dot gnu.org
2024-02-13 14:55 ` pinskia at gcc dot gnu.org
2024-02-13 14:56 ` sjames at gcc dot gnu.org
2024-02-13 14:58 ` sjames at gcc dot gnu.org
2024-02-13 15:11 ` jakub at gcc dot gnu.org
2024-02-13 15:17 ` pinskia at gcc dot gnu.org
2024-02-13 15:19 ` sjames at gcc dot gnu.org
2024-02-13 15:36 ` jakub at gcc dot gnu.org
2024-02-13 15:40 ` pinskia at gcc dot gnu.org
2024-02-13 15:46 ` jakub at gcc dot gnu.org
2024-02-13 15:58 ` jakub at gcc dot gnu.org [this message]
2024-02-13 16:00 ` pinskia at gcc dot gnu.org
2024-02-13 16:01 ` pinskia at gcc dot gnu.org
2024-02-13 16:07 ` jakub at gcc dot gnu.org
2024-02-13 16:30 ` jakub at gcc dot gnu.org
2024-02-14  9:16 ` jakub at gcc dot gnu.org
2024-02-14  9:24 ` rguenth at gcc dot gnu.org
2024-02-14  9:25 ` rguenth at gcc dot gnu.org
2024-02-14  9:52 ` jakub at gcc dot gnu.org
2024-02-14 10:35 ` rguenther at suse dot de
2024-02-14 15:52 ` hubicka at gcc dot gnu.org
2024-02-14 15:56 ` jakub at gcc dot gnu.org
2024-02-15 10:25 ` sjames at gcc dot gnu.org
2024-02-15 14:25 ` hubicka at gcc dot gnu.org
2024-02-15 14:36 ` jakub at gcc dot gnu.org
2024-02-15 14:36 ` jakub at gcc dot gnu.org
2024-02-15 14:43 ` rguenther at suse dot de
2024-02-15 14:45 ` rguenther at suse dot de
2024-02-15 14:55 ` hubicka at ucw dot cz
2024-02-15 14:57 ` hubicka at ucw dot cz
2024-02-15 15:02 ` jakub at gcc dot gnu.org
2024-02-16 14:40 ` hubicka at gcc dot gnu.org
2024-02-16 15:10 ` jakub at gcc dot gnu.org
2024-02-16 15:52 ` [Bug middle-end/113907] [12/13/14 " hubicka at gcc dot gnu.org
2024-02-16 15:55 ` jakub at gcc dot gnu.org
2024-02-16 16:08 ` hubicka at ucw dot cz
2024-02-16 16:27 ` jakub at gcc dot gnu.org
2024-02-16 16:45 ` hubicka at ucw dot cz
2024-02-16 17:01 ` amacleod at redhat dot com
2024-02-16 20:42 ` amacleod at redhat dot com
2024-02-22  9:22 ` sjames at gcc dot gnu.org
2024-03-08 15:34 ` jakub at gcc dot gnu.org
2024-03-09 17:10 ` law at gcc dot gnu.org
2024-03-09 21:04 ` [Bug ipa/113907] " pinskia at gcc dot gnu.org
2024-03-09 21:06 ` [Bug ipa/113907] [11/12/13/14 " pinskia at gcc dot gnu.org
2024-03-09 21:11 ` pinskia at gcc dot gnu.org
2024-03-11 11:21 ` jakub at gcc dot gnu.org
2024-03-13 14:07 ` hubicka at gcc dot gnu.org
2024-03-13 14:14 ` jakub at gcc dot gnu.org
2024-03-13 15:21 ` hubicka at ucw dot cz
2024-03-14 16:20 ` hubicka at gcc dot gnu.org
2024-03-14 16:39 ` hubicka at gcc dot gnu.org
2024-03-14 16:49 ` cvs-commit at gcc dot gnu.org
2024-03-14 16:53 ` jakub at gcc dot gnu.org
2024-03-15 23:29 ` cvs-commit at gcc dot gnu.org
2024-03-19 17:09 ` jakub at gcc dot gnu.org
2024-03-19 18:41 ` hubicka at ucw dot cz
2024-03-20  9:05 ` jamborm at gcc dot gnu.org
2024-03-20 18:13 ` jamborm at gcc dot gnu.org
2024-03-20 18:33 ` jakub at gcc dot gnu.org
2024-03-21 15:29 ` jakub at gcc dot gnu.org
2024-03-28 12:25 ` [Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled " cvs-commit at gcc dot gnu.org
2024-04-02  8:44 ` hubicka at ucw dot cz
2024-04-04 21:17 ` jamborm at gcc dot gnu.org
2024-04-08  9:33 ` sjames at gcc dot gnu.org
2024-04-08  9:38 ` rguenth at gcc dot gnu.org
2024-04-08 16:56 ` cvs-commit at gcc dot gnu.org
2024-04-08 17:04 ` jamborm at gcc dot gnu.org
2024-04-09  9:47   ` Jan Hubicka
2024-04-09  9:47 ` hubicka at ucw dot cz
2024-05-07  7:45 ` [Bug ipa/113907] [11/12/13/14/15 " rguenth at gcc dot gnu.org
2024-05-14 15:06 ` cvs-commit at gcc dot gnu.org
2024-05-28 13:45 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-113907-4-7ZAXqJbNet@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).