[Bug tree-optimization/111168] New: a[0,1]|b[0,-1] == 0 is not reduced to a ==0 & b ==0 if a and b are defined by comparisons

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 68
   Summary: a[0,1]|b[0,-1] == 0 is not reduced to a ==0 & b ==0 if
a and b are defined by comparisons
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
static inline int comLG_(int a, int b)
{
int c = (a < b) * -1;
return (a > b) | c;
}


int f(int a, int b)
{
return comLG_(a,b) == 0;
}
```

This should be reduced down to just `(a < b) == 0 & (a > b) == 0` or rather
just `a == b`.

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[tg at mirbsd dot org via Gcc-bugs]

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

--- Comment #7 from Thorsten Glaser  ---
(but with this, I think it’s neither the GCC builtins, nor a change thereof,
nor anything about dietlibc that is at fault; feel free to adjust the title
accordingly)

Surrounding code:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l399

Would gcc-12‑ and ‑13-generated .s files from otherwise identical builds, for
comparison, help? (With -fverbose-asm I presume?) Or anything else?

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[tg at mirbsd dot org via Gcc-bugs]

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

--- Comment #6 from Thorsten Glaser  ---
dietlibc’s strlen is a horrid SSE nightmare that doesn’t call (f)emms, but it
has a switch global variable __valgrind, if setting that to 1 it uses a very
traditional loop instead, and the registers before/after strlen also match
(only rax has changed), so I’m at a loss.

Changing the line to…

sp += strlen(sp) + 1;

… doesn’t make the problem go away, for some reason. Replacing it with…

while (*sp++) ;

… however *does* make it go away.

I’ll paste a screenlog of single-stepping through the valgrind version of the
code below (http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/.gdbinit?rev=HEAD
has the helpful t macro):

Breakpoint 1, expand (ccp=, wp=wp@entry=0xcdf0, f=f@entry=0)
at eval.c:401
401 asm volatile("nop"); //401
(gdb) t
=> 0x40a63f :  nop

402 sp = cstrchr(sp, '\0') + 1;
rax0xf7ff790e  4160715022
rbx0x0 0
rcx0x0 0
rdx0xff81  4294967169
rsi0x98152
rdi0xcd5c  4294954332
rbp0xf7ff790c  4160715020
rsp0xcc90  4294954128
r8 0xa0160
r9 0x3 3
r100x0 0
r110x206   518
r120x2 2
r130xd1b4  4294955444
r140xf7ff510c  4160704780
r150x0 0
rip0x40a6404236864
eflags 0x287   [ CF PF SF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0

=> 0x40a640 :  movebx,DWORD PTR [rsp+0x48]
   0x40a644 :  movrdi,rbx
   0x40a647 :  call   0x42cc7e 
(gdb) t
=> 0x40a640 :  movebx,DWORD PTR [rsp+0x48]

0x0040a644  402 sp = cstrchr(sp, '\0')
+ 1;
rax0xf7ff790e  4160715022
rbx0xf7ff790e  4160715022
rcx0x0 0
rdx0xff81  4294967169
rsi0x98152
rdi0xcd5c  4294954332
rbp0xf7ff790c  4160715020
rsp0xcc90  4294954128
r8 0xa0160
r9 0x3 3
r100x0 0
r110x206   518
r120x2 2
r130xd1b4  4294955444
r140xf7ff510c  4160704780
r150x0 0
rip0x40a6444236868
eflags 0x287   [ CF PF SF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0

=> 0x40a644 :  movrdi,rbx
   0x40a647 :  call   0x42cc7e 
   0x40a64c :  movecx,DWORD PTR [rsp+0x48]
(gdb) t
=> 0x40a644 :  movrdi,rbx

0x0040a647  402 sp = cstrchr(sp, '\0')
+ 1;
rax0xf7ff790e  4160715022
rbx0xf7ff790e  4160715022
rcx0x0 0
rdx0xff81  4294967169
rsi0x98152
rdi0xf7ff790e  4160715022
rbp0xf7ff790c  4160715020
rsp0xcc90  4294954128
r8 0xa0160
r9 0x3 3
r100x0 0
r110x206   518
r120x2 2
r130xd1b4  4294955444
r140xf7ff510c  4160704780
r150x0 0
rip0x40a6474236871
eflags 0x287   [ CF PF SF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0

=> 0x40a647 :  call   0x42cc7e 
   0x40a64c :  movecx,DWORD PTR [rsp+0x48]
   0x40a650 :  lear12d,[rcx+rax*1+0x1]
(gdb) t
=> 0x40a647 :  call   0x42cc7e 

0x0042cc7e in strlen ()
rax0xf7ff790e  4160715022
rbx0xf7ff790e  4160715022
rcx0x0 0
rdx0xff81  4294967169
rsi0x98152
rdi0xf7ff790e  4160715022
rbp0xf7ff790c  4160715020
rsp0xcc88  4294954120
r8 0xa0 

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[tg at mirbsd dot org via Gcc-bugs]

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

--- Comment #5 from Thorsten Glaser  ---
I managed to isolate one specific strchr call changing which causes the
breakage to go away:

asm volatile("nop"); //401
sp = cstrchr(sp, '\0') + 1;
asm volatile("nop"); //403

where:

#define cstrchr(s,c)((const char *)strchr((s), (c)))

const char *sp;

I inserted NOPs around (see above) and set gdb breakpoints there, and
before/after those breakpoints, the callee-saved registers differ (only showing
callee-saved registers for amd64/x32):

(gdb) info r
rbx0x0 0
rbp0xf7ff790c  4160715020
r120x2 2
r130xd1b4  4294955444
r140xf7ff510c  4160704780
r150x0 0
(gdb) c
(gdb) info r
rbx0xf7ff790e  4160715022
rbp0xf7ff790c  4160715020
r120xf7ff7912  4160715026
r130xd1b4  4294955444
r140xf7ff510c  4160704780
r150x0 0

Corresponding disassembly of generated code between the NOPs:

=> 0x0040a635 <+1875>:  nop
   0x0040a636 <+1876>:  mov0x48(%rsp),%ebx
   0x0040a63a <+1880>:  mov%rbx,%rdi
   0x0040a63d <+1883>:  call   0x42cc6e 
   0x0040a642 <+1888>:  mov0x48(%rsp),%ecx
   0x0040a646 <+1892>:  lea0x1(%rcx,%rax,1),%r12d
   0x0040a64b <+1897>:  nop

or, in readable:

=> 0x0040a635 <+1875>:  nop
   0x0040a636 <+1876>:  movebx,DWORD PTR [rsp+0x48]
   0x0040a63a <+1880>:  movrdi,rbx
   0x0040a63d <+1883>:  call   0x42cc6e 
   0x0040a642 <+1888>:  movecx,DWORD PTR [rsp+0x48]
   0x0040a646 <+1892>:  lear12d,[rcx+rax*1+0x1]
   0x0040a64b <+1897>:  nop

OK, huh… no strchr involved here.

For comparison, with -fno-builtin-strchr:

=> 0x0040a632 <+1872>:  nop
   0x0040a633 <+1873>:  movebx,DWORD PTR [rsp+0x48]
   0x0040a637 <+1877>:  xoresi,esi
   0x0040a639 <+1879>:  movrdi,rbx
   0x0040a63c <+1882>:  call   0x42cba4 
   0x0040a641 <+1887>:  movr14d,eax
   0x0040a644 <+1890>:  inceax
   0x0040a646 <+1892>:  movDWORD PTR [rsp+0x3c],eax
   0x0040a64a <+1896>:  nop

I’ll dig into strlen in dietlibc/x32 next.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

[mikael at gcc dot gnu.org via Gcc-bugs]

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

Mikael Morin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #9 from Mikael Morin  ---
Created attachment 55801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55801=edit
Draft patch, to be cleaned up.

I need to clean up this, but it passes the fortran testsuite in its current
form.

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[tg at mirbsd dot org via Gcc-bugs]

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

--- Comment #4 from Thorsten Glaser  ---
Its {,sig}{set,long}jmp for x32 look good.

[Bug tree-optimization/111167] swapping around duplicated conditionals can produce better code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
In this case the problem seems to be jump threading related.

If we did:
```
void f(int);
void lookup_attribute1(const char *attr_ns, int list, int t) {
  short t1;
  if (attr_ns)  { if (list) {t1 = 0; goto L1;} return; }
  if (list){t1 = t;goto L1;} else return;
L1:
  f(t1);
}
```

I Notice clang does not do this either even though the original testcase seems
ok.

[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE

[mikael at gcc dot gnu.org via Gcc-bugs]

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

Mikael Morin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #8 from Mikael Morin  ---
Created attachment 55800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55800=edit
Draft patch

This seems to work on comment #0.
Not tested otherwise.

[Bug tree-optimization/111167] swapping around duplicated conditionals can produce better code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/111167] New: swapping around duplicated conditionals can produce better code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 67
   Summary: swapping around duplicated conditionals can produce
better code
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take reduced from GCC's sources for lookup_attribute:
```
void f(int);
inline void canonicalize_attr_name(const char *, int l) {
  if (l > 4 && s[0] == '_' && s[l - 1] == '_' ) 
s += 2;
}
void lookup_attribute(const char *attr_ns, int list, int t) {
  if (attr_ns && attr_ns[0] != '_') {
canonicalize_attr_name(attr_ns, 5);
  }
  if (list == 0)
  {
short attr_ns_len = attr_ns ? t : 0;
f(attr_ns_len);
  }
}

```

In optimized we have:
```
  if (attr_ns_25(D) != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 322122543]:
  if (list_10(D) == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 751619279]:
  if (list_10(D) == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

```

But we should really just have:
if (list_10(D) == 0) goto bb7;
if (attr_ns_25(D) != 0B) goto bb5; else bb6;

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[tg at mirbsd dot org via Gcc-bugs]

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

--- Comment #3 from Thorsten Glaser  ---
Not yet, given it’s been relatively clearly tracked down to a change in GCC.

I’ll have at its setjmp/longjmp myself now, will report back.

[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE

[mikael at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Mikael Morin  ---
(In reply to Mikael Morin from comment #6)
> Can't reproduce with a recent master (14.0.0 20230814).

Sorry, missed the -std=f95 flag.
Confirmed on recent master.

[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE

[mikael at gcc dot gnu.org via Gcc-bugs]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #6 from Mikael Morin  ---
Can't reproduce with a recent master (14.0.0 20230814).

[Bug tree-optimization/111166] New: gcc unnecessarily creates vector operations for packing 32 bit integers into struct (x86_64)

[gnu_bugzilla_gcc at catelyn dot tech via Gcc-bugs]

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

Bug ID: 66
   Summary: gcc unnecessarily creates vector operations for
packing 32 bit integers into struct (x86_64)
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu_bugzilla_gcc at catelyn dot tech
  Target Milestone: ---

Created attachment 55799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55799=edit
preprocessed file that triggers the bug, as requested

GCC version: gcc version 13.2.1 20230801 (GCC)

Target: x86_64-pc-linux-gnu

Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror

Command used: gcc -v -save-temps weird_gcc_behaviour.c -o weird_gcc_behaviour.s
-S -O3 -mtune=generic -march=x86-64
(same behaviour is observed with -O2)

Command gives no output to stdout nor stderr, and returns with exit code 0

When compiling the function `turn_into_struct`, a simple function that packs 4
32 bit unsigned integers arguments into a simple struct holding 4 such integers
and passes that along to `do_smth_with_4_u32`, at -O2 or -O3 the generated
assembly contains a couple vector operations (`punpckldq` and `punpcklqdq`), as
well as spilling onto the stack. This does not seem like a good idea to me,
performance wise

When compiled at -Os it instead uses `salq`, `movl` (to ensure the upper 32
bits are cleared) and `orq` to pack the data together, avoiding memory
altogether, which (intuitively to me) seems like a significantly faster
implementation as it doesn't need to touch SSE nor memory

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-08-26
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Did you report this to dietlibc too?

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
>  (which makes me think of register corruption occurring here)

>The codepath is a bit convoluted, setjmp/longjmp are involved.


Which could mean it is a bug in dietlibc's setjmp/longjmp since you said it
works with glibc.

[Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

[tg at mirbsd dot org via Gcc-bugs]

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

Bug ID: 65
   Summary: [13 regression] builtin strchr miscompiles on
Debian/x32 with dietlibc
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tg at mirbsd dot org
  Target Milestone: ---

Debian bug reported as:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050589

I’ve got no idea how to quickly reduce that down, but perhaps anyone has got an
idea.

In an x32 (amd64ilp32) environment, with dietlibc/x32 as packaged in Debian (no
shared libraries), building mksh and then running the command 'x=q; x=${ echo
a; typeset e=2; return 3; echo x$e;}; echo .$x.' with the resulting binary
results in the output “..” instead of “.a.”.

This does not occur when either
- giving -fno-builtin-strchr
- wrapping strchr as outlined below
  (which makes me think of register corruption occurring here)
- using amd64 instead of x32 (amd64ilp32)
- using glibc, klibc or musl (though klibc/x32 is in reality amd64 so it can be
discounted)
- using GCC 12.3.0

The codepath is a bit convoluted, setjmp/longjmp are involved.

Wrapping strchr by adding…

char *ucstrchr(char *, int);
const char *cstrchr(const char *, int);
#undef strchr
#define strchr  poisoned_strchr

… to a .h file that’s globally included, and adding the following…

#undef strchr
char *ucstrchr(char *s, int c)
{
return (strchr(s, c));
}
const char *cstrchr(const char *s, int c)
{
return (strchr(s, c));
}

… to one .c file *also* works around the bug, for some reason. (mksh is built
with -fno-lto because of other GCC issues I filed regarding this.)

IIRC the builtins are hidden within the LISPy machine definitions or something;
I’m afraid at this point this is beyond my own ability to reduce down, but do
ask me (ideally via eMail to both <1050589-submit...@bugs.debian.org> and
<1050...@bugs.debian.org> (to keep the bug in Cc), but
@mirabi...@toot.mirbsd.org on Fediverse is fine too) if you need any further
details.

(All testing has been done with GCC and dietlibc as packaged in Debian;
especially the latter has quite the deviation from upstream, but I have looked
at diffs and logs and don’t think those are relevant here.)

[Bug fortran/86657] ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor

[mikael at gcc dot gnu.org via Gcc-bugs]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #6 from Mikael Morin  ---
Can't reproduce with recent master (14.0.0 20230814).

[Bug fortran/68152] ICE on declaring array result for function and entry

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
  Known to fail||10.5.0, 11.4.0, 7.5.0,
   ||8.5.0, 9.5.0
  Known to work||12.3.0, 13.2.0, 14.0

--- Comment #4 from anlauf at gcc dot gnu.org ---
Yep, seems fixed during 12-development.

As it is not marked as a regression, I would be fine if it were closed as
fixed.

[Bug fortran/25095] Disallowed intrinsic in initialization statement

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement
   Keywords|accepts-invalid |diagnostic

--- Comment #9 from anlauf at gcc dot gnu.org ---
Intel will fix their compiler to accept the code:

https://community.intel.com/t5/Intel-Fortran-Compiler/Data-implied-do-rejected-for-non-trivial-subscript-expression/m-p/1517334#M167869

The code in comment#0 is valid since at least F2008, maybe F2003, and only
clearly invalid in F95.

I suggest to close this PR, possibly as WONTFIX, unless someone really wants
to implement a (IMHO) warning of little practical importance as of today.

[Bug rtl-optimization/111143] [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #7 from Paul Eggert  ---
(In reply to Alexander Monakov from comment #6)

> Are you binding the benchmark to some core in particular?

I did the benchmark on performance cores, which was my original use case. On
efficiency cores, adding the (unnecessary) 'mov eax, 1' doesn't change timing
much (0.9% speedup on one test).

> it is better to have 'add rbx, 1' instead of 'add rbx, rax' in this loop on 
> any CPU

Somewhat counterintuitively, that doesn't seem to be the case for the
efficiency cores on this platform, as the "38% faster" code is 7% slower on
E-cores. However, the use cases I'm concerned about are typically run on
performance cores.

[Bug libstdc++/111163] signed integer overflow in std::format("{:%S}",std::chrono::duration....)

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
We could also just have a "can_hh_mm_ss" check, as I think we use hh_mm_ss in
most places where we do these conversations. Then we would just check once, not
on every cast. I don't think we want to change the conversions inside the
hh_mm_ss constructor

[Bug fortran/68152] ICE on declaring array result for function and entry

[mikael at gcc dot gnu.org via Gcc-bugs]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
Seems to be accepted with recent master (14.0.0 20230814).

[Bug libstdc++/111163] signed integer overflow in std::format("{:%S}",std::chrono::duration....)

[gcc at pauldreik dot se via Gcc-bugs]

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

--- Comment #2 from Paul Dreik  ---
The fmt lib had the same problem. I wrote a safe duration cast which eventually
morphed into this:

https://github.com/fmtlib/fmt/blob/9b74160817f2bc63288d2111e823a35dd3dbf234/include/fmt/chrono.h#L57-L68

[Bug libstdc++/111163] signed integer overflow in std::format("{:%S}",std::chrono::duration....)

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jonathan Wakely  ---
This doesn't seem much different to:
  std::chrono::seconds s = std::chrono::duration{2314885530818453536};
Which we can't really do much about.

[Bug libstdc++/111163] signed integer overflow in std::format("{:%S}",std::chrono::duration....)

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2023-08-26

[Bug libstdc++/111162] signed integer overflow triggered by std::chrono::parse

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |13.3
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2023-08-26

[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:44bcb51eb0d5cac6eb2de54541ca8e6c2d738160

commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
Author: Paul Thomas 
Date:   Sat Aug 26 14:37:49 2023 +0100

Fortran: Supply a missing dereference [PR92586]

2023-08-26  Paul Thomas  

gcc/fortran
PR fortran/92586
* trans-expr.cc (gfc_trans_arrayfunc_assign): Supply a missing
dereference for the call to gfc_deallocate_alloc_comp_no_caf.

gcc/testsuite/
PR fortran/92586
* gfortran.dg/pr92586.f90 : New test

[Bug c++/111164] New: The error message for a literal operator accepting an argument of the wrong type is confusing

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 64
   Summary: The error message for a literal operator accepting an
argument of the wrong type is confusing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

template
int operator ""_x ();

int x = "abc"_x;

https://godbolt.org/z/aWjM3bx1j

The error message given by GCC includes:

:4:9: note:   expected a constant of type 'char', got 'char'

This is paradoxical.

[Bug libstdc++/111163] New: signed integer overflow in std::format("{:%S}",std::chrono::duration....)

[gcc at pauldreik dot se via Gcc-bugs]

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

Bug ID: 63
   Summary: signed integer overflow in
std::format("{:%S}",std::chrono::duration)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at pauldreik dot se
  Target Milestone: ---

The following program:

#include 
#include 
int main() {
[[maybe_unused]] auto blah = std::format(
"{:%S}", std::chrono::duration{2314885530818453536});
}

invokes signed integer overflow when compiled with the current gcc trunk. The
output is:
/opt/compiler-explorer/gcc-trunk-20230824/include/c++/14.0.0/bits/chrono.h:190:8:
runtime error: signed integer overflow: 2314885530818453536 * 5 cannot be
represented in type 'long int'
/opt/compiler-explorer/gcc-trunk-20230824/include/c++/14.0.0/bits/chrono.h:229:38:
runtime error: signed integer overflow: 2314885530818453536 * 5 cannot be
represented in type 'long int'

link to reproducer: https://godbolt.org/z/YWd9cx7o8

[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #12 from Paul Thomas  ---
Created attachment 55798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55798=edit
Fix for this PR

Once the offending location was found, this fix became 'obvious'.

I will be committing as such later on.

Paul

[Bug libstdc++/111162] New: signed integer overflow triggered by std::chrono::parse

[gcc at pauldreik dot se via Gcc-bugs]

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

Bug ID: 62
   Summary: signed integer overflow triggered by
std::chrono::parse
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at pauldreik dot se
  Target Milestone: ---

The following program:

#include 
#include 
#include 
int main() {
std::istringstream is("21474837");
std::chrono::minutes x;
is >> std::chrono::parse("%8C", x);
}

invokes undefined behaviour. If compiled with the current gcc trunk, one gets
this when executed:
/opt/compiler-explorer/gcc-trunk-20230824/include/c++/14.0.0/bits/chrono_io.h:3174:20:
runtime error: signed integer overflow: 21474837 * 100 cannot be represented in
type 'int'

link to reproducer (uses gcc trunk, may go stale quick):
https://godbolt.org/z/h617GT4EY

[Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jan Hubicka  ---
So here ipa-modref declares the field dead, while ipa-prop determines its value
even if it is unused and makes it used later?

I think dead argument is probably better than optimizing out one store, so I
think ipa-prop, however question is how to detect this reliably.

ipa-modref has update_signature which updates summaries after ipa-sra work, so
it is also place to erase the info about parameter being dead from the summary.
Other option would be to ask ipa-modref from FRE when considering propagation
of known value.

[Bug c++/85097] ICE in double parameter pack

[michal.staromiejski+gnu at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Michał Staromiejski  ---
In clang 16.0.0 it compiles w/o errors.

[Bug c++/85097] ICE in double parameter pack

[michal.staromiejski+gnu at gmail dot com via Gcc-bugs]

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

Michał Staromiejski  changed:

   What|Removed |Added

 CC||michal.staromiejski+gnu@gma
   ||il.com

--- Comment #4 from Michał Staromiejski  ---
Still does not work in gcc 13.2.0.

[Bug target/111161] New: [13 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4394 during build

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 61
   Summary: [13 Regression] ICE: RTL check: expected code
'const_int', have 'reg' in riscv_print_operand, at
config/riscv/riscv.cc:4394 during build
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: build, ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
 Build: x86_64-pc-linux-gnu

I am currently failing to build the riscv64-unknown-linux-gnu cross-compiler on
the gcc-13-branch with RTL checking enabled:

Configure command line:

/repo/gcc-13-branch//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64

Results in:

...
checking whether ln -s works... yes
checking for riscv64-unknown-linux-gnu-gcc...
/repo/build-gcc-riscv64/./gcc/xgcc -B/repo/build-gcc-riscv64/./gcc/
-B/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/bin/
-B/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/lib/
-isystem
/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/include
-isystem
/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/sys-include
 
checking for suffix of object files... configure: error: in
`/repo/build-gcc-riscv64/riscv64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
make[1]: *** [Makefile:14265: configure-target-libgcc] Error 1
make[1]: Leaving directory '/repo/build-gcc-riscv64'
make: *** [Makefile:1041: all] Error 2

And config.log shows:

configure:3576: /repo/build-gcc-riscv64/./gcc/xgcc
-B/repo/build-gcc-riscv64/./gcc/
-B/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/risc
v64-unknown-linux-gnu/bin/
-B/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/lib/
-isystem /repo/gcc-13-branch//
binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/include
-isystem
/repo/gcc-13-branch//binary-13-branch-20230826002206-gc1732638180-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/sys-include
   -o conftest -g -O2   conftest.c  >&5
during RTL pass: final
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: RTL check: expected code 'const_int',
have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4394
   16 | }
  | ^
0x7a2fcb rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-13-branch/gcc/rtl.cc:916
0x847f34 riscv_print_operand
/repo/gcc-13-branch/gcc/config/riscv/riscv.cc:4394
0xcd3fd8 output_operand(rtx_def*, int)
/repo/gcc-13-branch/gcc/final.cc:3632
0xcd4a38 output_asm_insn(char const*, rtx_def**)
/repo/gcc-13-branch/gcc/final.cc:3544
0xcd8e12 output_asm_insn(char const*, rtx_def**)
/repo/gcc-13-branch/gcc/final.cc:3421
0xcd8e12 final_scan_insn_1
/repo/gcc-13-branch/gcc/final.cc:2841
0xcd91ab final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-13-branch/gcc/final.cc:2887
0xcd93e4 final_1
/repo/gcc-13-branch/gcc/final.cc:1979
0xcda028 rest_of_handle_final
/repo/gcc-13-branch/gcc/final.cc:4240
0xcda028 execute
/repo/gcc-13-branch/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


This only affects gcc-13-branch, probably only with RTL checking enabled.

I can't find the conftest.c file that is failing to build.

[Bug rtl-optimization/111143] [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing

[amonakov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Alexander Monakov  ---
Thanks.

i5-1335U has two "performance cores" (with HT, four logical CPUs) and eight
"efficiency cores". They have different micro-architecture. Are you binding the
benchmark to some core in particular?

On the "performance cores", 'add rbx, 1' can be eliminated ("executed" with
zero latency), this optimization appeared in the Alder Lake generation with the
"Golden Cove" uarch and was found by Andreas Abel. There are limitations (e.g.
it works for 64-bit additions but not 32-bit, the addend must be an immediate
less than 1024).

Of course, it is better to have 'add rbx, 1' instead of 'add rbx, rax' in this
loop on any CPU ('mov eax, 1' competes for ALU ports with other instructions,
so when it's delayed due to contention the dependent 'add rbx, rax; movsx rax,
[rbx]' get delayed too), but ascribing the difference to compiler scheduling on
a CPU that does out-of-order dynamic scheduling is strange.

[Bug tree-optimization/102793] AArch64: sequential comparisons with equal conditional blocks don't use ccmp

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> basically ccmp expension is just ifcombine really.
> That is:
> cc = bar cmp 0
> cc = cc.eq ? ne : d1 cmp d2
> cset cc.ne
> So this is why doing a late pass ifcombine might be good for aarch64; I
> don't know if how much compile time it would cost though.

Or maybe isel can do this too ...

[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #5 from Andrew Pinski  ---
I have a patch for what I laid out in comment #3 and it solves the original
issue too because after ifcombine we have:
  _24 = _28 == 
  _18 = _28 == 
  _8 = _18 | _24;
  _25 = _28 == 
  _20 = _8 | _25;
  if (_20 != 0)
goto ; [99.98%]
  else
goto ; [0.02%]

   [local count: 210453]:
  __assert_fail ("", "", 4, &__PRETTY_FUNCTION__);

   [local count: 536765685]:
  _6 = _28 == 
  _13 = _28 == 
  _9 = _6 | _13;
  _27 = _28 == 
  _17 = _9 | _27;
  if (_17 != 0)
goto ; [99.98%]
  else
goto ; [0.02%]

Which then obviously gets optimized by DOM2.