public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
@ 2024-06-09 10:40 slyfox at gcc dot gnu.org
  2024-06-09 11:00 ` [Bug target/115404] " ubizjak at gmail dot com
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: slyfox at gcc dot gnu.org @ 2024-06-09 10:40 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 115404
           Summary: [15 Regression] possibly wrong code on glibc-2.39
                    since r15-1113-gde05e44b2ad963
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

No minimal reproducer yet, filing in case it's an easy to notice bug from the
bisected r15-1113-gde05e44b2ad963:

  commit de05e44b2ad9638d04173393b1eae3c38b2c3864
  Author: Uros Bizjak <ubizjak@gmail.com>
  Date:   Sat Jun 8 12:17:11 2024 +0200

    i386: Implement .SAT_ADD for unsigned scalar integers [PR112600]

    ...

The bug manifests as a testsuite failure on mpfr-4.2.1 as:

  FAIL: tsprintf
  ==============

  Fatal glibc error: printf_buffer_as_file.c:31
(__printf_buffer_as_file_commit): assertion failed: file->stream._IO_write_ptr
<= file->next->write_end
  FAIL tsprintf (exit status: 134)

I think it's a `file->next->write_end` corruption around this code in glibc's
libio/iovsprintf.c:

```c
int
__vsprintf_internal (char *string, size_t maxlen,
                     const char *format, va_list args,
                     unsigned int mode_flags)
{
  struct __printf_buffer buf;

  if ((mode_flags & PRINTF_CHK) != 0)
    {
      string[0] = '\0';
      uintptr_t end;
      if (__builtin_add_overflow ((uintptr_t) string, maxlen, &end))
        end = -1;
      __printf_buffer_init_end (&buf, string, (char *) end,
                            __printf_buffer_mode_sprintf_chk);
    }
   ...
```

Could it be that dead store to `&end` somehow conflicts with a following `end =
-1`?

I'll try to extract self-contained example, but it will take some time.

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

* [Bug target/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
@ 2024-06-09 11:00 ` ubizjak at gmail dot com
  2024-06-09 22:04 ` slyfox at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ubizjak at gmail dot com @ 2024-06-09 11:00 UTC (permalink / raw)
  To: gcc-bugs

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pan2.li at intel dot com

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Sergei Trofimovich from comment #0)
> No minimal reproducer yet, filing in case it's an easy to notice bug from
> the bisected r15-1113-gde05e44b2ad963:
> 
>   commit de05e44b2ad9638d04173393b1eae3c38b2c3864
>   Author: Uros Bizjak <ubizjak@gmail.com>
>   Date:   Sat Jun 8 12:17:11 2024 +0200
> 
>     i386: Implement .SAT_ADD for unsigned scalar integers [PR112600]

The target implementation of .SAT_ADD is fairly simple, but the newly added
usadd{m}3 optab enables middle-end transformations to saturating add - you will
notice .SAT_ADD operation in _.265t.optimized dump.

My bet is on the middle-end transforming to .SAT_ADD in a wrong way. CC added.

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

* [Bug target/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
  2024-06-09 11:00 ` [Bug target/115404] " ubizjak at gmail dot com
@ 2024-06-09 22:04 ` slyfox at gcc dot gnu.org
  2024-06-10  6:07 ` ubizjak at gmail dot com
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: slyfox at gcc dot gnu.org @ 2024-06-09 22:04 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Thank you for the hints!

I did not yet fully extracted self-contained example but got a bit closer to
it.

Comparing glibc binary before and after r15-1113-gde05e44b2ad963 the only
function that changes is __vsprintf_internal.

Smaller reproducer (against glibc-2.39 built with affected compiler):

// $ cat over.c
#include <printf.h>
#include <stdio.h>

static int printf_e(FILE *fp, const struct printf_info *info, const void *const
*args) { return -2; }

static int size_type(const struct printf_info *info, size_t n, int *argtype,
int *size) {
    return -1;
}

int main(void) {
    char buf[255];
    register_printf_specifier('e', printf_e, size_type);

    sprintf(buf, "%e", -12.5);
    return 0;
}

$ gcc over.c -o over -O2 -D_FORTIFY_SOURCE=3 && ./over
Fatal glibc error: printf_buffer_as_file.c:31 (__printf_buffer_as_file_commit):
assertion failed: file->stream._IO_write_ptr <= file->next->write_end
Aborted (core dumped)

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

* [Bug target/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
  2024-06-09 11:00 ` [Bug target/115404] " ubizjak at gmail dot com
  2024-06-09 22:04 ` slyfox at gcc dot gnu.org
@ 2024-06-10  6:07 ` ubizjak at gmail dot com
  2024-06-10  6:42 ` rguenth at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ubizjak at gmail dot com @ 2024-06-10  6:07 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Sergei Trofimovich from comment #0)

>       if (__builtin_add_overflow ((uintptr_t) string, maxlen, &end))
>         end = -1;
>
> Could it be that dead store to `&end` somehow conflicts with a following
> `end = -1`?

FYI, this is not dead store, the two lines above are exactly what middle-end
now transforms to a .SAT_ADD. The function returns -1 (AKA INT_MAX) when
addition overflows.

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

* [Bug target/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2024-06-10  6:07 ` ubizjak at gmail dot com
@ 2024-06-10  6:42 ` rguenth at gcc dot gnu.org
  2024-06-10  7:47 ` [Bug tree-optimization/115404] " ubizjak at gmail dot com
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-06-10  6:42 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.0
             Target|                            |x86_64-*-* i?86-*-*

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

* [Bug tree-optimization/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2024-06-10  6:42 ` rguenth at gcc dot gnu.org
@ 2024-06-10  7:47 ` ubizjak at gmail dot com
  2024-06-10  7:53 ` pinskia at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ubizjak at gmail dot com @ 2024-06-10  7:47 UTC (permalink / raw)
  To: gcc-bugs

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-10
          Component|target                      |tree-optimization

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
I can hit ICE with the following testcase:

--cut here--
#include <stddef.h>
#include <stdint.h>

char *
test (char *string, size_t maxlen)
{
  string[0] = '\0';
  uintptr_t end;

  if (__builtin_add_overflow ((uintptr_t) string, maxlen, &end))
    end = -1;

  return (char *) end;
}
--cut here--

gcc -O2:

saddt.c: In function ‘test’:
saddt.c:18:1: error: definition in block 4 follows the use
   18 | test (char *string, size_t maxlen)
      | ^~~~
for SSA_NAME: _4 in statement:
prephitmp_13 = (char *) _4;
during GIMPLE pass: widening_mul
saddt.c:18:1: internal compiler error: verify_ssa failed
0x12850a0 verify_ssa(bool, bool)
        ../../git/gcc/gcc/tree-ssa.cc:1203
0xed8255 execute_function_todo
        ../../git/gcc/gcc/passes.cc:2096
0xed86be execute_todo
        ../../git/gcc/gcc/passes.cc:2143

xgcc (GCC) 15.0.0 20240610 (experimental) [master r15-1126-gc1429e3a8da]

Confirmed as a tree-optimization problem with the new .SAT_ADD conversion pass.

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

* [Bug tree-optimization/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2024-06-10  7:47 ` [Bug tree-optimization/115404] " ubizjak at gmail dot com
@ 2024-06-10  7:53 ` pinskia at gcc dot gnu.org
  2024-06-10 21:51 ` slyfox at gcc dot gnu.org
  2024-06-16 21:33 ` law at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-06-10  7:53 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #4)
> I can hit ICE with the following testcase:

Then it is most likely a dup of bug 115387 .

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

* [Bug tree-optimization/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2024-06-10  7:53 ` pinskia at gcc dot gnu.org
@ 2024-06-10 21:51 ` slyfox at gcc dot gnu.org
  2024-06-16 21:33 ` law at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: slyfox at gcc dot gnu.org @ 2024-06-10 21:51 UTC (permalink / raw)
  To: gcc-bugs

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

Sergei Trofimovich <slyfox at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #6 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Yeah, fixed by https://gcc.gnu.org/PR115387#c10. Declaring duplicate. Thanks
all!

*** This bug has been marked as a duplicate of bug 115387 ***

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

* [Bug tree-optimization/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963
  2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2024-06-10 21:51 ` slyfox at gcc dot gnu.org
@ 2024-06-16 21:33 ` law at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: law at gcc dot gnu.org @ 2024-06-16 21:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
Bug 115404 depends on bug 115387, which changed state.

Bug 115387 Summary: [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

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

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

end of thread, other threads:[~2024-06-16 21:33 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-09 10:40 [Bug target/115404] New: [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963 slyfox at gcc dot gnu.org
2024-06-09 11:00 ` [Bug target/115404] " ubizjak at gmail dot com
2024-06-09 22:04 ` slyfox at gcc dot gnu.org
2024-06-10  6:07 ` ubizjak at gmail dot com
2024-06-10  6:42 ` rguenth at gcc dot gnu.org
2024-06-10  7:47 ` [Bug tree-optimization/115404] " ubizjak at gmail dot com
2024-06-10  7:53 ` pinskia at gcc dot gnu.org
2024-06-10 21:51 ` slyfox at gcc dot gnu.org
2024-06-16 21:33 ` law 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).