public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details
@ 2023-10-13 15:51 pinskia at gcc dot gnu.org
  2023-10-13 15:52 ` [Bug tree-optimization/111800] " pinskia at gcc dot gnu.org
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-13 15:51 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 111800
           Summary: [14 Regression] ICE with -fdump-tree-ccp1-details
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Testcase at -O3 -fdump-tree-ccp1-details:
```

void foo(void);
static struct d {
    short e;
} g = {205}, *h = &g;
static int i;
static int *j, *a = &i;
static int **k = &j;
static int ****l;
static int *****m;
static char(n)(char b, char c) { return b + c; }
static char(o)(char b, char c) { return b * c; }
static short(p)(short f) {
    if (!(((f) >= 1) && ((f) <= 65459))) {
        __builtin_unreachable();
    }
    return 0;
}
static int *q(short);
static void s(struct d) { *k = q(i); }
static int *q(short ad) {
    int b = *a;
    ad = -21;
    for (; ad; ad = n(ad, 7)) p((ad ^ b && *a) <= *a);
    return *k;
}
int main() {
    i = 0;
    for (;; i = 1) {
        q(3);
        char r = o(126 | 1, g.e);
        p(r);
        s(*h);
        if (i) break;
        m = &l;
    }
    if (m)
        ;
    else
        foo();
    ;
}
```

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
@ 2023-10-13 15:52 ` pinskia at gcc dot gnu.org
  2023-10-13 15:54 ` pinskia at gcc dot gnu.org
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-13 15:52 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |14.0

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
ICE:
```
during GIMPLE pass: ccp
dump file: /app/output.cpp.034t.ccp1
<source>: In function 'q':
<source>:42:1: internal compiler error: Segmentation fault
   42 | }
      | ^
0x22fdf0e internal_error(char const*, ...)
        ???:0
0x14e8779 print_hex(generic_wide_int<wide_int_ref_storage<false, true> >
const&, char*)
        ???:0
0x14e8beb print_hex(generic_wide_int<wide_int_ref_storage<false, true> >
const&, _IO_FILE*)
        ???:0
g++: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 4
```

Maybe related to some of Jakub's recent wide_int changes ...

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
  2023-10-13 15:52 ` [Bug tree-optimization/111800] " pinskia at gcc dot gnu.org
@ 2023-10-13 15:54 ` pinskia at gcc dot gnu.org
  2023-10-13 16:14 ` pinskia at gcc dot gnu.org
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-13 15:54 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Worked at r14-4561-ge8d418df3dc609f27 .

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
  2023-10-13 15:52 ` [Bug tree-optimization/111800] " pinskia at gcc dot gnu.org
  2023-10-13 15:54 ` pinskia at gcc dot gnu.org
@ 2023-10-13 16:14 ` pinskia at gcc dot gnu.org
  2023-10-13 16:27 ` pinskia at gcc dot gnu.org
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-13 16:14 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(gdb) p this->get_val()
$2 = (const long *) 0x3030303030306666

That seem wrong.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2023-10-13 16:14 ` pinskia at gcc dot gnu.org
@ 2023-10-13 16:27 ` pinskia at gcc dot gnu.org
  2023-10-13 16:28 ` jakub at gcc dot gnu.org
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-13 16:27 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There looks to be some stack corruption going on; valgrind didn't catch it
though.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2023-10-13 16:27 ` pinskia at gcc dot gnu.org
@ 2023-10-13 16:28 ` jakub at gcc dot gnu.org
  2023-10-13 18:27 ` jakub at gcc dot gnu.org
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-10-13 16:28 UTC (permalink / raw)
  To: gcc-bugs

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

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
   Last reconfirmed|                            |2023-10-13
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'll debug this.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2023-10-13 16:28 ` jakub at gcc dot gnu.org
@ 2023-10-13 18:27 ` jakub at gcc dot gnu.org
  2023-10-13 18:44 ` jakub at gcc dot gnu.org
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-10-13 18:27 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, I see what's going on.
tree-ssa-ccp.cc uses widest_int extensively (I believe it is a mistake and
should be using wide_int instead) and in this case has a widest_int with value
-30 (get_len () == 1, get_precision () before my changes 576, with those
changes 32640 bits).
Now, print_hex (but also print_decu/print_decs/print_dec as they always print
larger precision (and when get_len () > 1) using print_hex) prints all numbers
according to the precision, so my checks to ensure the buffer is big enough:
  char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
  unsigned len = wi.get_len ();
  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
    p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
are not correct, they'd need to check precision for wi::neg_p (wi) values.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2023-10-13 18:27 ` jakub at gcc dot gnu.org
@ 2023-10-13 18:44 ` jakub at gcc dot gnu.org
  2023-10-13 18:47 ` jakub at gcc dot gnu.org
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-10-13 18:44 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 56101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56101&action=edit
gcc14-pr111800.patch

Untested patch to avoid the buffer overflows when printing wide_int/widest_int.

The more important question is if we don't want to change how we print the
stuff.
As mentioned earlier, perhaps teach print_dec{s,u} to print even larger
constants decimally rather than hexadecimally.
And consider whether we shouldn't have print_hex with signop where we'd decide
whether to print negative values if SIGNED as -0x...... rather than some huge
0x..........................................................................
Because, -fdump-tree-ccp1-details on the testcase from this PR used to print
say -1 as
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
but now it prints it as
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2023-10-13 18:44 ` jakub at gcc dot gnu.org
@ 2023-10-13 18:47 ` jakub at gcc dot gnu.org
  2023-10-15 12:25 ` cvs-commit at gcc dot gnu.org
  2023-10-16  6:36 ` rguenth at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-10-13 18:47 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Even in the gcc 13 -fdump-tree-ccp1-details I see
PHI node value: CONSTANT
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe2
(0x19)
so that isn't exactly readable either, but my changes made it much worse.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
                   ` (7 preceding siblings ...)
  2023-10-13 18:47 ` jakub at gcc dot gnu.org
@ 2023-10-15 12:25 ` cvs-commit at gcc dot gnu.org
  2023-10-16  6:36 ` rguenth at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-10-15 12:25 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 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:3bcc10b98e9ffc1296d3d1aae16e85c6bdb09d1a

commit r14-4645-g3bcc10b98e9ffc1296d3d1aae16e85c6bdb09d1a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun Oct 15 14:23:14 2023 +0200

    wide-int: Fix estimation of buffer sizes for wide_int printing [PR111800]

    As mentioned in the PR, my estimations on needed buffer size for wide_int
    and especially widest_int printing were incorrect, I've used get_len ()
    in the estimations, but that is true only for !wi::neg_p (x) values.
    Under the hood, we have 3 ways to print numbers.
    print_decs which if
      if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
          || (wi.get_len () == 1))
    uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive or
    negative) and otherwise uses print_hex,
    print_decu which if
      if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
          || (wi.get_len () == 1 && !wi::neg_p (wi)))
    uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive
    only) and print_hex, which doesn't print most significant limbs which are
    zero and the first limb which is non-zero prints such that redundant 0
    hex digits aren't printed, while all limbs below that are printed with
    "%016" PRIx64.  For wi::neg_p (x) values, the first limb of the precision
    is always non-zero, so we print all the limbs for the precision.
    So, the current estimations are accurate if !wi::neg_p (x), or when
    print_decs will be used and x.get_len () == 1, otherwise we need to use
    estimation based on get_precision () rather than get_len ().

    I've introduced new inlines print_{dec{,s,u},hex}_buf_size which compute
the
    needed buffer length in bytes and return true if WIDE_INT_PRINT_BUFFER_SIZE
    isn't sufficient and caller should XALLOCAVEC the buffer.

    2023-10-15  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/111800
    gcc/
            * wide-int-print.h (print_dec_buf_size, print_decs_buf_size,
            print_decu_buf_size, print_hex_buf_size): New inline functions.
            * wide-int.cc (assert_deceq): Use print_dec_buf_size.
            (assert_hexeq): Use print_hex_buf_size.
            * wide-int-print.cc (print_decs): Use print_decs_buf_size.
            (print_decu): Use print_decu_buf_size.
            (print_hex): Use print_hex_buf_size.
            (pp_wide_int_large): Use print_dec_buf_size.
            * value-range.cc (irange_bitmask::dump): Use print_hex_buf_size.
            * value-range-pretty-print.cc
(vrange_printer::print_irange_bitmasks):
            Likewise.
            * tree-ssa-loop-niter.cc (do_warn_aggressive_loop_optimizations):
Use
            print_dec_buf_size.  Use TYPE_SIGN macro in print_dec call
argument.
    gcc/c-family/
            * c-warn.cc (match_case_to_enum_1): Assert w.get_precision ()
            is smaller or equal to WIDE_INT_MAX_INL_PRECISION rather than
            w.get_len () is smaller or equal to WIDE_INT_MAX_INL_ELTS.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
  2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
                   ` (8 preceding siblings ...)
  2023-10-15 12:25 ` cvs-commit at gcc dot gnu.org
@ 2023-10-16  6:36 ` rguenth at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-16  6:36 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed I assume.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-10-16  6:36 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-13 15:51 [Bug tree-optimization/111800] New: [14 Regression] ICE with -fdump-tree-ccp1-details pinskia at gcc dot gnu.org
2023-10-13 15:52 ` [Bug tree-optimization/111800] " pinskia at gcc dot gnu.org
2023-10-13 15:54 ` pinskia at gcc dot gnu.org
2023-10-13 16:14 ` pinskia at gcc dot gnu.org
2023-10-13 16:27 ` pinskia at gcc dot gnu.org
2023-10-13 16:28 ` jakub at gcc dot gnu.org
2023-10-13 18:27 ` jakub at gcc dot gnu.org
2023-10-13 18:44 ` jakub at gcc dot gnu.org
2023-10-13 18:47 ` jakub at gcc dot gnu.org
2023-10-15 12:25 ` cvs-commit at gcc dot gnu.org
2023-10-16  6:36 ` rguenth at gcc dot gnu.org

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).