[Bug libstdc++/114279] utc_clock does not support leap seconds

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

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

--- Comment #1 from Jonathan Wakely  ---
It certainly does take leap seconds into account, as demonstrated by the output
example below the text you quoted, which is reproduced in the testsuite:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/testsuite/std/time/clock/utc/io.cc;h=55c53dc4057fe90b8a0f7192cc38ffe313f5afd4;hb=HEAD

And also:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/testsuite/std/time/clock/utc/leap_second_info.cc;h=2fabda494234a48dc2920e291f5a92a8fe1d02fa;hb=HEAD

This seems to be just a bug in the from_stream overload, not utc_clock.

[Bug rtl-optimization/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g0

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

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

--- Comment #7 from Richard Biener  ---
IMO verify_flow_info on RTL should ICE with unreachable blocks.

[Bug rtl-optimization/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g0

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Richard Biener  ---
Ah, -march=x86-64 was it.  The ICE means that the entry block wasn't reachable
from EXIT_BLOCK which means there are unreachable blocks.

This usually means some pass lacks CFG cleanup or delete_unreachable_blocks ().

A simple fix is the following, but the proper thing to do is track down who
leaves unreachable blocks around in the IL.

diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc
index eb75d1bdb26..ff455ddd12e 100644
--- a/gcc/sched-rgn.cc
+++ b/gcc/sched-rgn.cc
@@ -65,6 +65,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "dbgcnt.h"
 #include "pretty-print.h"
 #include "print-rtl.h"
+#include "cfgcleanup.h"

 /* Disable warnings about quoting issues in the pp_xxx calls below
that (intentionally) don't follow GCC diagnostic conventions.  */
@@ -3707,6 +3708,7 @@ rest_of_handle_live_range_shrinkage (void)
 #ifdef INSN_SCHEDULING
   int saved;

+  delete_unreachable_blocks ();
   initialize_live_range_shrinkage ();
   saved = flag_schedule_interblock;
   flag_schedule_interblock = false;

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:0bd04d9ae2d5447fd11fa43db20371140e955eff

commit r14-9382-g0bd04d9ae2d5447fd11fa43db20371140e955eff
Author: Richard Biener 
Date:   Fri Mar 8 08:26:15 2024 +0100

testsuite/108355 - make gcc.dg/tree-ssa/ssa-fre-104.c properly XFAIL

The testcase only XFAILs on targets where int has an alignment
of sizeof(int).  Align the respective array this way to make it
XFAIL consistenlty.

PR testsuite/108355
* gcc.dg/tree-ssa/ssa-fre-104.c: Align e.

[Bug c/114266] No -pedantic diagnostic for zero-sized array in compound literals

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Daniel Lundin  ---
(In reply to Joseph S. Myers from comment #2)
> The relevant constraint here is "An array of unknown size shall not be
> initialized by an empty initializer.".

Indeed! I didn't realize it was also a constraint (C23 6.7.10). That probably
means that a diagnostic warning should always be given and not just in
-pedantic mode.

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Hans-Peter Nilsson from comment #10)
> > (In reply to Richard Biener from comment #9)
> > > gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.
> > 
> > Any obvious target-specific reason for this to XPASS on cris-elf, m68k-linux
> > and pru-elf?
> > 
> > (per recent gcc-testresults posts)
> 
> Most likely because
> int e[][1] = {0, 0, 0, 0, 0, 1};
> 
> Is done as a copy from a const static decl vs done via stores to e[i][0].
> 
> Maybe do s/5/2/ and change the number of elements down to 3 for the array
> and you will hit the issue again on those targets.

Huh, most likely, but I don't see how that would help ... that should
make it _fail_ to optimize this ...

So checking cris-elf I see

   :
  e[0][0] = 0;
  e[1][0] = 0;
  e[2][0] = 0;
  e[3][0] = 0;
  e[4][0] = 0;
  e[5][0] = 1;

   :
  bar25_ ();
  a.0_1 = a;
  _2 = e[5][a.0_1];
  if (_2 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  a.1_3 = a;
  e[a.1_3][0] = 0;
  foo ();
  goto ; [INV]

before FRE, the same IL as on x86_64.  A FRE dump diff reveals

 Setting value number of a.0_1 to a.0_1 (changed)
 Making available beyond BB3 a.0_1 for value a.0_1
 Value numbering stmt = _2 = e[5][a.0_1];
-Skipping possible redundant definition e[5][0] = 1;
-Setting value number of _2 to _2 (changed)
-Using extra use virtual operand .MEM_5
-Making available beyond BB3 _2 for value _2
+Setting value number of _2 to 1 (changed)

that's exactly the reason for the regression - we're now trying to skip
the definition on x86_64.  And we can do so there because of the alignment
of 'e' which on cris seems to be less than the size of 'int' (int is
aligned to 1 byte but its size is still 4 bytes).

So

int a;
int *b = 
int **c = 
int d;
void bar25_(void);
void foo(void);
int main() {
  int __attribute__((aligned(sizeof(int e[][1] = {0, 0, 0, 0, 0, 1};
  for (;;) {
bar25_();
/* We should optimistically treat a == 0 because of the bounds of
   the object.  */
if (e[5][a])
  break;
e[a][0] = 0;
foo();
  }
  *c = 
}

also fails on cris.  Let me update the testcase.

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

--- Comment #30 from john.harper at vuw dot ac.nz ---
Thank you!

On Fri, 8 Mar 2024, jvdelisle at gcc dot gnu.org wrote:

> Date: Fri, 8 Mar 2024 00:30:51 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/105473] semicolon allowed when list-directed read
> integer with decimal='point'
> Resent-Date: Fri, 8 Mar 2024 13:31:02 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
>
> --- Comment #29 from Jerry DeLisle  ---
> Backported to 13 and closing.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

[Bug rtl-optimization/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g0

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #5 from Zdenek Sojka  ---
(In reply to Richard Biener from comment #4)
> We've released with the bug so this cannot be P1.  Note the bisected to rev.
> likely just made this latent issue show up.
> 
> Btw, I can't reproduce - any implicit options missing?
> 
> > ./cc1plus -quiet t.ii -O2 -m32 -flive-range-shrinkage -fno-dce 
> > -fnon-call-exceptions

$
/repo/gcc-trunk/binary-trunk-20240305153615-g08ec4adb028-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/cc1plus
attachment.txt -m32 "-mtune=generic" "-march=x86-64" -O2 -flive-range-shrinkage
-fno-dce -fnon-call-exceptions
...
attachment.txt: In member function 'void SQVM::CallNative()':
attachment.txt:41:1: internal compiler error: in operator[], at vec.h:910
   41 | }
  | ^
...

[Bug rtl-optimization/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g0

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |WAITING
   Priority|P1  |P2

--- Comment #4 from Richard Biener  ---
We've released with the bug so this cannot be P1.  Note the bisected to rev.
likely just made this latent issue show up.

Btw, I can't reproduce - any implicit options missing?

> ./cc1plus -quiet t.ii -O2 -m32 -flive-range-shrinkage -fno-dce 
> -fnon-call-exceptions

[Bug libstdc++/114279] New: utc_clock does not support leap seconds

[gnaggnoyil at gmail dot com via Gcc-bugs]

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

Bug ID: 114279
   Summary: utc_clock does not support leap seconds
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnaggnoyil at gmail dot com
  Target Milestone: ---

When using current GCC trunk, the program

#include 
#include 
#include 

int main(){
std::stringstream stream;
stream << "20161231-23:59:60.035";
std::chrono::utc_time utc_tp;
(void)std::chrono::from_stream(stream, "%4Y%2m%2d-%2H:%2M:%S", utc_tp);
std::cout << utc_tp << std::endl;
return 0;
}

gives the following output:

2017-01-01 00:00:00.035

which does not seems to give leap seconds into consideration.

The current standard working draft [time.clock.utc.overview]#1 states

In contrast to sys_time, which does not take leap seconds into account,
utc_clock and its associated time_point, utc_time, count time, including leap
seconds, since 1970-01-01 00:00:00 UTC.

So I think the current libstdc++ implementation here is not conforming the
standard.

[Bug rtl-optimization/114278] New: ICE: in extract_bit_field_1, at expmed.cc:1838 with memmove, _BitInt() and -O2 -fno-tree-dce -fno-tree-dse -fno-tree-ccp -m32

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114278
   Summary: ICE: in extract_bit_field_1, at expmed.cc:1838 with
memmove, _BitInt() and -O2 -fno-tree-dce -fno-tree-dse
-fno-tree-ccp -m32
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu

Created attachment 57653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57653=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-dce -fno-tree-dse -fno-tree-ccp -m32
testcase.c -Wall -W
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:4:37: internal compiler error: in extract_bit_field_1, at
expmed.cc:1838
4 |   _BitInt(128) b = *(_BitInt(128) *)__builtin_memmove(, p, 16);
  | ^~~~
0x758082 extract_bit_field_1
/repo/gcc-trunk/gcc/expmed.cc:1838
0x10a868c extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
/repo/gcc-trunk/gcc/expmed.cc:2151
0x10c7654 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:12456
0x10d323d store_expr(tree_node*, rtx_def*, int, bool, bool)
/repo/gcc-trunk/gcc/expr.cc:6740
0x10d5e6f expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.cc:6461
0x10d5e6f expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.cc:5946
0xf8cfe9 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3998
0xf8cfe9 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4077
0xf8e677 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6133
0xf90cfe execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6872
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.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9346-20240306205443-g74e8cc28eda-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9346-20240306205443-g74e8cc28eda-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240306 (experimental) (GCC)

[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
   Last reconfirmed||2024-03-08
Summary|Missed optimization:|[11/12/13/14 Regression]
   |x*(x||b) => x   |Missed optimization:
   ||x*(x||b) => x
  Known to fail||8.1.0
  Known to work||7.5.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
In GCC 7, before PRE we had:
```
  # iftmp.0_3 = PHI <_8(3), 1(5)>
  _2 = iftmp.0_3 * x_4(D);
```

Which was able to optimized by PRE to:
```
  _9 = x_4(D) * _8;

   [100.00%]:
  # iftmp.0_3 = PHI <_8(3), 1(2)>
  # prephitmp_10 = PHI <_9(3), x_4(D)(2)>
  a = prephitmp_10;
```

Which is how GCC 7 was able to optimize it.

In GCC8+, reassociatation takes:
```
   [local count: 1073741825]:
  if (x_4(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  b.1_1 = b;
  _7 = b.1_1 != 0;
  _8 = (int) _7;

   [local count: 1073741825]:
  # iftmp.0_3 = PHI <_8(3), 1(2)>
  _2 = iftmp.0_3 * x_4(D);
```

Into:
```
  _9 = x_4(D) | b.1_1;
  _10 = _9 != 0;
  _7 = b.1_1 != 0;
  _11 = (int) _10;
  _8 = (int) _7;
  _2 = x_4(D) * _11;
```

Which no longer can be optimized to just x_4(D).

Maybe:
(simplify
 (mult:c @0 (convert? (ne (bit_ior:c @0 @1) integer_zero_p)))
 @0)

Like similarly was done for  `a * !a` just recently. Note this won't catch all
cases though as @0 be deep in the bit_ior chain but it will catch some.

[Bug tree-optimization/114277] New: Missed optimization: x*(x||b) => x

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 114277
   Summary: Missed optimization: x*(x||b) => x
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that the code below can be optimized as stated in the title
(x*(x||b) => x), but gcc -O3 missed it.

https://godbolt.org/z/W8xYrGdej

int a,b;
void func(int x){
a=x*(x||b);
}

GCC -O3:
func(int):
mov eax, edi
or  eax, DWORD PTR b[rip]
mov eax, 0
cmove   edi, eax
mov DWORD PTR a[rip], edi
ret

Expected code:
func(int):
mov DWORD PTR a[rip], edi
ret

Surprisingly, GCC optimizes as expected for the following slightly more complex
code:
int c;
void func2(int x){
a=x*(x||(b&));
}
func2(int):
mov DWORD PTR a[rip], edi
ret

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug c/99826] GIMPLE FE fails to grok pointer declarators

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-08
 Ever confirmed|0   |1
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
The first issue of the placement __GIMPLE(ssa) is still there.
The second issue of _2 was fixed in GCC 12.

Confirmed.

[Bug tree-optimization/113677] Missing `VEC_PERM_EXPR <{a, CST}, CST, {0, 1, 2, ...}>` optimization

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Note it is not just about constants either.

That is the same as what is mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94301#c2 even :).

[Bug target/114276] Trapping on aligned operations when using vector builtins + `-std=gnu++23 -fsanitize=address -fstack-protector-strong`

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup.

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

[Bug target/110027] Misaligned vector store on detect_stack_use_after_return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||elrodc at gmail dot com

--- Comment #8 from Andrew Pinski  ---
*** Bug 114276 has been marked as a duplicate of this bug. ***

[Bug target/114276] Trapping on aligned operations when using vector builtins + `-std=gnu++23 -fsanitize=address -fstack-protector-strong`

[elrodc at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Chris Elrod  ---
Created attachment 57652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57652=edit
assembly from adding `-S`

[Bug target/114276] New: Trapping on aligned operations when using vector builtins + `-std=gnu++23 -fsanitize=address -fstack-protector-strong`

[elrodc at gmail dot com via Gcc-bugs]

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

Bug ID: 114276
   Summary: Trapping on aligned operations when using vector
builtins + `-std=gnu++23 -fsanitize=address
-fstack-protector-strong`
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elrodc at gmail dot com
  Target Milestone: ---

Created attachment 57651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57651=edit
test file

I'm not sure how to categorize the issue, so I picked "target" as it occurs for
x86_64 when using aligned moves on 64-byte avx512 vectors.

`-std=c++23` also reproduces the problem.
I am using:

> g++ --version
> g++ (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6)
> Copyright (C) 2023 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The attached file is:

> #include 
> #include 
> 
> template 
> using Vec [[gnu::vector_size(W * sizeof(T))]] = T;
> 
> auto foo() {
>   Vec<8, int64_t> ret{};
>   return ret;
> }
> 
> int main() {
>   foo();
>   return 0;
> }

I have attached this file.

On a skylake-avx512 CPU, I get

> g++ -std=gnu++23 -march=skylake-avx512 -fstack-protector-strong -O0 -g 
> -mprefer-vector-width=512 -fsanitize=address,undefined -fsanitize-trap=all 
> simdvecalign.cpp && ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==36238==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x0040125c bp
0x7ffdf88a1cb0 sp 0x7ffdf88a1bc0 T0)
==36238==The signal is caused by a READ memory access.
==36238==Hint: this fault was caused by a dereference of a high value address
(see register values below).  Disassemble the provided pc to learn which
register was used.
#0 0x40125c in foo()
/home/chriselrod/Documents/progwork/cxx/experiments/simdvecalign.cpp:8
#1 0x4012d1 in main
/home/chriselrod/Documents/progwork/cxx/experiments/simdvecalign.cpp:13
#2 0x7f296b846149 in __libc_start_call_main (/lib64/libc.so.6+0x28149)
(BuildId: 7ea8d85df0e89b90c63ac7ed2b3578b2e7728756)
#3 0x7f296b84620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a)
(BuildId: 7ea8d85df0e89b90c63ac7ed2b3578b2e7728756)
#4 0x4010a4 in _start
(/home/chriselrod/Documents/progwork/cxx/experiments/a.out+0x4010a4) (BuildId:
765272b0173968b14f4306c8d4a37fcb18733889)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/home/chriselrod/Documents/progwork/cxx/experiments/simdvecalign.cpp:8 in foo()
==36238==ABORTING
fish: Job 1, './a.out' terminated by signal SIGABRT (Abort)

However, if I remove any of `-std=gnu++23`, `-fsantize=address`, or
`-fstack-protector-strong`, the code runs without a problem.

Using 32 byte vectors instead of 64 byte also allows it to work.

I also used `-S` to look at the assembly.

When I edit the two lines:
>   vmovdqa64   %zmm0, -128(%rdx)
>   .loc 1 9 10
>   vmovdqa64   -128(%rdx), %zmm0

swapping `vmovdqa64` for `vmovdqu64`, the code runs as intended.

> g++ -fsanitize=address simdvecalign.s # using vmovdqu64
> ./a.out
> g++ -fsanitize=address simdvecalign.s # reverted back to vmovdqa64
> ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==40364==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x0040125c bp
0x7ffd2e2dc240 sp 0x7ffd2e2dc140 T0)

so I am inclined to think that something isn't guaranteeing that `%rdx` is
actually 64-byte aligned (but it may be 32-byte aligned, given that I can't
reproduce with 32 byte vectors).

[Bug c/100535] ICE: tree check: expected function_type or method_type, have integer_type in gimplify_call_expr, at gimplify.c:3457

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |13.0

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 13:
```

: In function 'foo':
:6:1: error: invalid argument to gimple call
6 | }
  | ^
__builtin_abs ()
t1_1 = __builtin_abs (__builtin_abs ());
```

[Bug c/109619] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in fold_const_call_1, at fold-const-call.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
in fold_builtin_[123], replace `TREE_CODE (*) == ERROR_MARK` with
`error_operand_p (*)` will fix this.

[Bug c/102760] ICE: in decompose, at wide-int.h:984

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #9 from Andrew Pinski  ---
I can't reproduce this on the trunk any more.

[Bug c++/101790] [12/13/14 Regression] ICE on invalid in trunk: tree check: expected class 'type', have 'exceptional' (error_mark)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #5 from Andrew Pinski  ---
I can't reproduce it on the trunk any more ...

[Bug c/101630] [11/12/13 Regression] ICE with -Wall: in get_constant, at c-family/c-format.c:325

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE with -Wall: in  |with -Wall: in
   |get_constant, at|get_constant, at
   |c-family/c-format.c:325 |c-family/c-format.c:325
  Known to work||14.0
   Keywords||needs-bisection

--- Comment #5 from Andrew Pinski  ---
Looks to be fixed on the trunk ...

[Bug c/110682] [12/13/14 Regression] ICE: internal compiler error: in gimplify_expr after error

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

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

--- Comment #3 from Andrew Pinski  ---
This fixes the ICE:
```
[apinski@xeond2 gcc]$ git diff
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 6ebca964cb2..0f43324fb35 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -17681,7 +17681,11 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
   save_expr = *expr_p;

   /* Die, die, die, my darling.  */
-  if (error_operand_p (save_expr))
+  if (error_operand_p (save_expr)
+ /* The above strip useless type conversion might not strip out
+a conversion from an error so handle that case here.  */
+ || (TREE_CODE (save_expr) == NON_LVALUE_EXPR
+ && error_operand_p (TREE_OPERAND (save_expr, 0
{
  ret = GS_ERROR;
  break;

```

I will submit it tomorrow once I test it fully.

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-08

--- Comment #2 from Nathaniel Shead  ---
Minimised:


// m.cpp
module;

template  struct T;

template  struct T {
  template  friend struct T;
};

export module M;
export template  void fun() { T t; }


// main.cpp
import M;

int main() { fun(); }

[Bug target/114264] RISC-V: ICE in riscv-vector-costs.cc of gcc master branch

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Demin Han :

https://gcc.gnu.org/g:42187c6968af9907de1f9b7563d87de739857684

commit r14-9380-g42187c6968af9907de1f9b7563d87de739857684
Author: demin.han 
Date:   Wed Mar 6 17:34:34 2024 +0800

RISC-V: Fix ICE in riscv vector costs

The following code can result in ICE:
-march=rv64gcv --param riscv-autovec-lmul=dynamic -O3

char *jpeg_difference7_input_buf;
void jpeg_difference7(int *diff_buf) {
  unsigned width;
  int samp, Rb;
  while (--width) {
Rb = samp = *jpeg_difference7_input_buf;
*diff_buf++ = -(int)(samp + (long)Rb >> 1);
  }
}

One biggest_mode update missed in one branch and trigger assertion fail.
gcc_assert (biggest_size >= mode_size);

Tested On RV64 and no regression.

PR target/114264

gcc/ChangeLog:

* config/riscv/riscv-vector-costs.cc: Fix ICE

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/pr114264.c: New test.

Signed-off-by: demin.han 

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Andrew Pinski  ---
In file included from
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:39,
 from
/home/apinski/upstream-gcc-match/include/c++/14.0.1/stop_token:40,
 from
/home/apinski/upstream-gcc-match/include/c++/14.0.1/thread:42,
 from A.ixx:4,
of module A, imported at main.cpp:2:
/home/apinski/upstream-gcc-match/include/c++/14.0.1/tuple: In instantiation of
‘struct std::_Tuple_impl@A<0, fun@A(int&&):: >’:
/home/apinski/upstream-gcc-match/include/c++/14.0.1/tuple:834:11:   required
from ‘class std::tuple@A(int&&):: >’
  834 | class tuple : public _Tuple_impl<0, _Elements...>
  |   ^
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:280:9:  
required from ‘struct
std::thread@A::_Invoker(int&&):: > >’
  280 | _Tuple _M_t;
  |^~~~
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:236:13:  
required from ‘struct
std::thread@A::_State_impl(int&&)::
> > >’
  236 | _Callable   _M_func;
  | ^~~
/home/apinski/upstream-gcc-match/include/c++/14.0.1/bits/std_thread.h:164:29:  
required from ‘std::thread@A::thread(_Callable&&, _Args&& ...) [with _Callable
= fun@A(int&&)::; _Args = {};  = void]’
  164 | _M_start_thread(_State_ptr(new _State_impl<_Wrapper>(
  |^~
  165 |   std::forward<_Callable>(__f),
std::forward<_Args>(__args)...)),
  |  
~
A.ixx:10:8:   required from ‘void fun@A(auto:38&&) [with auto:38 = int]’
   10 | std::thread([]{}).join();
  |  ^~~~
main.cpp:6:6:   required from here
6 | fun(42);
  | ~~~^~~~
/home/apinski/upstream-gcc-match/include/c++/14.0.1/tuple:551:51: error:
conflicting declaration of template ‘template,
class ...> struct std::_Tuple_impl’
  551 |   template friend struct _Tuple_impl;
  |   ^~~

[Bug c++/114275] New: using std::thread within a templated function in a module fails to compile

[michael.kenzel at gmail dot com via Gcc-bugs]

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

Bug ID: 114275
   Summary: using std::thread within a templated function in a
module fails to compile
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.kenzel at gmail dot com
  Target Milestone: ---

The following example will reproduce the issue:

// A.ixx
module;

#include 

export module A;

export void fun(auto&&)
{
std::thread([]{}).join();
}

// main.cpp
import A;

int main()
{
fun(42);
}

build with

g++ -std=c++23 -fmodules-ts -c -x c++ A.ixx
g++ -std=c++23 -fmodules-ts main.cpp A.o

results in

‘
/usr/include/c++/13/tuple:491: confused by earlier errors, bailing out

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Hans-Peter Nilsson from comment #10)
> (In reply to Richard Biener from comment #9)
> > gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.
> 
> Any obvious target-specific reason for this to XPASS on cris-elf, m68k-linux
> and pru-elf?
> 
> (per recent gcc-testresults posts)

Most likely because
int e[][1] = {0, 0, 0, 0, 0, 1};

Is done as a copy from a const static decl vs done via stores to e[i][0].

Maybe do s/5/2/ and change the number of elements down to 3 for the array and
you will hit the issue again on those targets.

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #10 from Hans-Peter Nilsson  ---
(In reply to Richard Biener from comment #9)
> gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.

Any obvious target-specific reason for this to XPASS on cris-elf, m68k-linux
and pru-elf?

(per recent gcc-testresults posts)

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

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

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

--- Comment #29 from Jerry DeLisle  ---
Backported to 13 and closing.

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

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

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

--- Comment #28 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:7ecea49245bc6aeb6c889a4914961f94417f16e5

commit r13-8411-g7ecea49245bc6aeb6c889a4914961f94417f16e5
Author: Jerry DeLisle 
Date:   Sat Feb 17 09:24:58 2024 -0800

libgfortran: [PR105473] Fix checks for decimal='comma'.

PR libfortran/105473

libgfortran/ChangeLog:

* io/list_read.c (eat_separator): Reject comma as a
separator when it is being used as a decimal point.
(parse_real): Reject a '.' when it should be a comma.
(read_real): Likewise.
* io/read.c (read_f): Add more checks for ',' and '.'
conditions.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr105473.f90: New test.

(cherry picked from commit a71d87431d0c4e04a402ef6566be090c470b2b53)

[Bug libstdc++/114244] Need to use round when parsing fractional seconds

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

--- Comment #7 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/114244] Need to use round when parsing fractional seconds

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-9376-g5f9d7a5b6cf64639274e63051caf70fbc8418ea2
Author: Jonathan Wakely 
Date:   Thu Mar 7 13:15:41 2024 +

libstdc++: Fix parsing of fractional seconds [PR114244]

When converting a chrono::duration to a result type with an
integer representation we should use chrono::round<_Duration> so that we
don't truncate towards zero. Rounding ensures that e.g. 0.001999s
becomes 2ms not 1ms.

We can also remove some redundant uses of chrono::duration_cast to
convert from seconds to _Duration, because the _Parser class template
requires _Duration type to be able to represent seconds without loss of
precision.

This also fixes a bug where no fractional part would be parsed for
chrono::duration because its period is ratio<1>. We should
also consider treat_as_floating_point when deciding whether to skip
reading a fractional part.

libstdc++-v3/ChangeLog:

PR libstdc++/114244
* include/bits/chrono_io.h (_Parser::operator()): Remove
redundant uses of duration_cast. Use chrono::round to convert
long double value to durations with integer representations.
Check represenation type when deciding whether to skip parsing
fractional seconds.
* testsuite/20_util/duration/114244.cc: New test.
* testsuite/20_util/duration/io.cc: Check that a floating-point
duration with ratio<1> precision can be parsed.

[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin20   |*-darwin*
  Component|testsuite   |c++
   Last reconfirmed|2023-08-18 00:00:00 |2024-3-7
   Host|x86_64-apple-darwin20   |*-darwin*
  Build|x86_64-apple-darwin20   |*-darwin*

--- Comment #5 from Iain Sandoe  ---
I am shifting this to component C++, because the answer to comment #4 is really
what's important - if this is supposed to work for file scope entities, then it
needs to be a GCC extension (ISTM, anyway).

[Bug c/110682] [12/13/14 Regression] ICE: internal compiler error: in gimplify_expr after error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I will take a look

[Bug c++/110565] [11/12/13/14 Regression] Incomplete note on why initializing int& with int is ill-formed

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug c++/110584] [11/12/13/14 Regression] Constant is not visible in nested lambda with outer lambda having a default capture

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug middle-end/110586] [14 Regression] 10% fatigue2 regression on zen since r14-2369-g3a61ca1b925653 (bad LRA)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug target/110647] [14 Regression] 66% TSVC/s2712 regressoin on N1-neoverse between g:620a35b24a2b6edb (2023-07-01 07:24) and g:80ae426a195a0d03 (2023-07-02 01:37)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug middle-end/110694] [11/12/13/14 Regression] False Positive -Werror=free-nonheap-object

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen since g:r14-2369-g3a61ca1b925653 (2023-07-06)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug c/110682] [12/13/14 Regression] ICE: internal compiler error: in gimplify_expr after error

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P1

[Bug middle-end/110757] [14 Regression] 7% parest regression on zen3 -Ofast -march=native -flto between g:4dbb3af1efe55174 (2023-07-14 00:54) and g:a5088dc3f5ef73c8 (2023-07-17 03:24)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug middle-end/110764] [12/13/14 Regression] False positive -Warray-bounds warning swapping std::thread::id

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug rtl-optimization/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main (maybe fmodulo-sched related)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at gcc dot gnu.org

[Bug tree-optimization/110829] [13/14 Regression] FAIL: gcc.dg/pr56837.c scan-tree-dump-times optimized "memset ..c, 68, 16384.;" 1

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug sanitizer/110835] [13/14 Regression] -fsanitize=address causes huge runtime slowdown from std::rethrow_exception not called

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/110873] [14 Regression] Dead Code Elimination Regression at -O2 since r14-376-g47a76439911

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/110896] [12/13/14 Regression] gcc.dg/ubsan/pr81981.c is xfailed

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

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

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/110919] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug analyzer/110928] [14 Regression] ICE with -fanalyzer on -Wanalyzer-out-of-bounds checker

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P1

[Bug tree-optimization/110931] [14 Regression] Dead Code Elimination Regression since r14-2890-gcc2003cd875

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/110932] [14 Regression] Dead Code Elimination Regression since r14-2230-g7e904d6c7f2

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug bootstrap/111027] [11/12/13/14 Regression] `make install` touches the build directory; Install error "tmp-header-vars: Permission denied", build on NFS, improvement possible

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/111073] [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk with -D_GLIBCXX_ASSERTIONS

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug c++/111075] [14 Regression] ICE on g++.dg/torture/tail-padding1.C on darwin

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

[Bug analyzer/111099] [13/14 Regression] -fanalyzer -Os segmentation fault due to infinite recursion in ana::constraint_manager::eval_condition

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P1

[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug c++/111160] [11/12/13/14 Regression] ICE on assigning volatile through ternary operator

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

[Bug target/111170] [13/14 regression] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library) since r13-6552-gd11e088210a551

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #16 from Jeffrey A. Law  ---
Fixed and backported.

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug tree-optimization/111240] [12/13/14 Regression] Incorrect warning from -Wmaybe-uninitialized

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/111292] [14 Regression] Missed Dead Code Elimination since r14-2228-g02460c0b8c9

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug analyzer/111305] [13/14 Regression] GCC Static Analyzer -Wanalyzer-out-of-bounds FP and ICE problem

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P1

[Bug tree-optimization/111326] [14 Regression] Dead Code Elimination Regression since r14-376-g47a76439911

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug tree-optimization/111328] [14 Regression] ICE: verify_flow_info failed since r14-3459-g0c78240fd7d

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED
 CC||law at gcc dot gnu.org

--- Comment #2 from Jeffrey A. Law  ---
Fixed by:

commit cc50337215535e17f1caa5eae34eaa650223c96b (HEAD, refs/bisect/bad)
Author: Eugene Rozenfeld 
Date:   Fri Sep 15 18:12:47 2023 -0700

Fixes for profile count/probability maintenance

Verifier checks have recently been strengthened to check that
all counts and probabilities are initialized. The checks fired
during autoprofiledbootstrap build and this patch fixes it.

Tested on x86_64-pc-linux-gnu.

gcc/ChangeLog:
* auto-profile.cc (afdo_calculate_branch_prob): Fix count
comparisons
* tree-vect-loop-manip.cc (vect_do_peeling): Guard against zero
count
when scaling loop profile

[Bug libstdc++/114260] std::formatter> formats as the previous day

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jonathan Wakely  ---
Yup, I understand why that's the output. I just thought it seemed off that
something rounded to days didn't land at 00:00:00 and convinced myself that it
should be "corrected". But of course utc_time is not a year_month_day,
it's an exact time point, and it happens to not line up with 00:00:00 for the
reason you gave:

(In reply to Howard Hinnant from comment #2)
> Consequently, 2024-03-05 00:00:00 in utc_time is *not* a multiple of 86400s,
> but rather 27s greater than a multiple of 86400s.  And all
> round(udays) does is round the .time_since_epoch() to the nearest
> multiple of 86400s.  Which in utc_time is 27s earlier, or 2024-03-04
> 23:59:33.

So not a bug then. Thanks for talking me out of introducing a bug here!

[Bug c++/114229] [modules] duplicate vtable symbols when including stl in submodule

[nickbegg at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Nick Begg  ---
Looks good - my test code compiles ok.

[Bug libstdc++/114260] std::formatter> formats as the previous day

[howard.hinnant at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Howard Hinnant  ---
This:

2024-03-05 00:00:00
2024-03-04 23:59:33

looks like correct output to me.

sys_time and utc_time map to the same civil calendar date/time (except during a
leap second).  That is 2024-03-05 00:00:00 sys_time, converted to utc_time,
also should print out as 2024-03-05 00:00:00.

The only difference between sys_time and utc_time is that utc_time counts the
leap seconds since 1970 (27 at this point).  This means if you look at the
difference in .time_since_epoch(), utc_time will be 27 seconds longer, even
though it prints out as the same date and time.

Consequently, 2024-03-05 00:00:00 in utc_time is *not* a multiple of 86400s,
but rather 27s greater than a multiple of 86400s.  And all round(udays)
does is round the .time_since_epoch() to the nearest multiple of 86400s.  Which
in utc_time is 27s earlier, or 2024-03-04 23:59:33.

So in summary, if you make a change, and *don't* get this output, then you've
introduced a bug.

[Bug c++/111426] [11/12/13/14 Regression] "error: use of deleted function" printed twice

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug analyzer/111441] [14 Regression] ICE generating access diagram, in fold_binary_loc, at fold-const.cc:11580

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

[Bug tree-optimization/111472] [11/12/13 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Wrong
   |Wrong code at -Os on|code at -Os on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since
   |r11-4563-gd0d8b5d836|r11-4563-gd0d8b5d836

--- Comment #6 from Jeffrey A. Law  ---
Close.  It was the next revision my bisection landed on as the fix:

commit 9692309ed6b625f0fb358c0e230404b5603f69a6 (refs/bisect/bad)
Author: Richard Biener 
Date:   Fri Oct 20 15:08:49 2023 +0200

tree-optimization/111445 - simple_iv simplification fault

The following fixes a missed check in the simple_iv attempt
to simplify (signed T)((unsigned T) base + step) where it
allows a truncating inner conversion leading to wrong code.

PR tree-optimization/111445
* tree-scalar-evolution.cc (simple_iv_with_niters):
Add missing check for a sign-conversion.

* gcc.dg/torture/pr111445.c: New testcase.

[Bug target/67510] x86: Faster code is possible for integer absolute value

[pcordes at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Peter Cordes  ---
(In reply to Andrew Pinski from comment #2)
> Fixed by r10-5498 and r11-5429 .

Looks ok for -mtune=generic and non-Intel, but MOV/NEG isn't ideal on some
microarchitectures.

We still aren't using CMOV for -mtune=broadwell or later where it's single-uop
with 1 cycle latency, same as AMD.  https://uops.info/  (CMOVBE/CMOVA which
still 2 uops on Intel P-cores, since they read CF, and ZF from the SPAZO group,
so 4 total inputs.  But absolute value only uses signed conditions, which don't
involve CF.)

Intel E-cores (silvermont family) also have efficient CMOV.  Latency = 1 cycle
from one input, 2 cycles from the other, but single uop for the front-end.  It
looks like it uses two execution pipes like INC does, but often the front-end
is the bottleneck). So we should be using it there, too.  The non-CMOV code-gen
has even higher latency and worse throughput.

Earlier Intel SnB-family (Sandy / Ivy Bridge and Haswell) might be better with
CMOV, too, since the uop cache reduces the downside of a 2-uop instruction only
being able to decode in the first decoder (so maybe keep the current code-gen
on P6-family?), but it's 4 uops either way and smaller machine-code size, and
better on later CPUs.



The current CMOV code-gen has MOV on the latency critical path for
microarchitectures without mov-elimination.  (bdver* and earlier AMD where we
currently use CMOV, and Ice Lake, first-gen Sandybridge, and P6 family where we
currently don't.  I haven't checked on Zhaoxin.)

https://gcc.godbolt.org/z/Mbsqzhbfs
movl%edi, %eax
negl%eax
cmovs   %edi, %eax

This could be easily avoided, either with XOR/SUB like I suggested in my
original report, or by NEGating the original value instead of the copy, for
CMOVNS. CMOV would still be overwriting the MOV result so would still free up
mov-elimination resources promptly.
(https://stackoverflow.com/questions/75204302/how-do-move-elimination-slots-work-in-intel-cpu
).

But unlike XOR/SUB, that destroys the original value so isn't an option if the
input register is needed later.  And with APX available, NEG into a new
register is optimal.  So it might be easier to only consider patterns that
produce the negated value in a separate register, which should be easy to
peephole optimize with APX non-destructive operations.

XOR/SUB saves code-size for absolute value of 64-bit integers; the xor-zeroing
doesn't need a REX prefix if the destination is a low reg. e.g

# better version for most CPUs, especially for 64-bit operand-size
xor%eax, %eax   # off the critical path on all x86-64, eliminated on
recent uarches
sub%rdi, %rax   # REX prefix
cmovs  %rdi, %rax   # REX prefix

In terms of back-end execution-unit cost:

* Zen 3 and later eliminate both MOV and XOR-zeroing, so both should be equal
performance except for the code-size difference with 64-bit operands.
* Zen 1 and 2 eliminate MOV but not XOR-zeroing.  (XOR-zero is dep-breaking so
it's not on the critical path, but still needs an execution unit to write the
zero, so ~4 per clock throughput)
* Gracemont E-cores eliminates MOV but not XOR-zeroing, like Zen 1 and 2.  Its
front-end is probably more likely to be a bottleneck so this is even less of a
big deal.  
 https://chipsandcheese.com/2021/12/21/gracemont-revenge-of-the-atom-cores/ is
my source for this and Zen 1/2 vs. Zen 3.  

https://chipsandcheese.com/2022/11/05/amds-zen-4-part-1-frontend-and-execution-engine/
has Zen 4 numbers, although its Sunny Cove (Ice Lake) numbers don't seem to
reflect the microcode update that disabled mov-elim for GPRs
* Tremont and earlier Silvermont family: MOV is not eliminated, so XOR-zeroing
is better.
* Ice Lake (and first-gen Sandy Bridge) eliminate XOR-zeroing but not integer
MOV, so the current tune=generic code-gen has worse latency than necessary.  
(Thanks to Intel's microcode workarounds for CPU errata, there will be CPUs
with non-zero latency for  mov reg,reg  in service for many more years than
previously expected.)

* Ivy Bridge and later except Ice Lake family (Ice / Tiger / Rocket) eliminate
both so either way is fine, XOR / SUB being preferable because of Ice Lake
existing.


* P6-family doesn't eliminate either MOV or XOR.  P6-family is obsolete enough
that it's probably not worth anyone's time to update the tuning stuff for them.
 But XOR/NEG is clearly better if we're using CMOV at all.  (2-uop instructions
like CMOVS can be a problem depending on surrounding code, given their lack of
a uop cache.)

  Early P6-family (up to Pentium III) has a false dependency with xor-zeroing:
it's special in terms of marking the register as EAX=AL upper-bits-zero to
avoid partial register stalls, but isn't independent of the old value of EAX. 
-mtune=intel and -mtune=generic shouldn't care about this.  (Especially not
with -m64 since the affected CPUs are 32-bit only).  Despite the false
dependency, 

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 114229 Summary: [modules] duplicate vtable symbols when including stl in 
submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114229

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/114229] [modules] duplicate vtable symbols when including stl in submodule

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||nshead at gcc dot gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org

--- Comment #5 from Nathaniel Shead  ---
Fixed for GCC 14.

[Bug c++/114229] [modules] duplicate vtable symbols when including stl in submodule

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:9ccd03dee4c35a24c6699a58a7251a5277a91cf5

commit r14-9375-g9ccd03dee4c35a24c6699a58a7251a5277a91cf5
Author: Nathaniel Shead 
Date:   Thu Mar 7 23:09:03 2024 +1100

c++: Redetermine whether to write vtables on stream-in [PR114229]

We currently always stream DECL_INTERFACE_KNOWN, which is needed since
many kinds of declarations already have their interface determined at
parse time.  But for vtables and type-info declarations we need to
re-evaluate on stream-in as whether they need to be emitted or not
changes in each TU, so this patch clears DECL_INTERFACE_KNOWN on these
kinds of declarations so that they can go through 'import_export_decl'
again.

Note that the precise details of the virt-2 tests will need to change
when we implement the resolution of [1], for now I just updated the test
to not fail with the new (current) semantics.

[1]: https://github.com/itanium-cxx-abi/cxx-abi/pull/171

PR c++/114229

gcc/cp/ChangeLog:

* module.cc (trees_out::core_bools): Redetermine
DECL_INTERFACE_KNOWN on stream-in for vtables and tinfo.
* decl2.cc (import_export_decl): Add fixme for ABI changes with
module vtables and tinfo.

gcc/testsuite/ChangeLog:

* g++.dg/modules/virt-2_b.C: Update test to acknowledge that we
now emit vtables here too.
* g++.dg/modules/virt-3_a.C: New test.
* g++.dg/modules/virt-3_b.C: New test.
* g++.dg/modules/virt-3_c.C: New test.
* g++.dg/modules/virt-3_d.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug tree-optimization/111515] [14 Regression] Missed Dead Code Elimination since r14-4089-gd45ddc2c04e

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug ipa/111571] [13/14 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P1

[Bug c++/111592] [11/12/13/14 Regression] ICE on expanding argument pack into variadic constructor

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

[Bug tree-optimization/111671] [14 Regression] ICE in get_default_value, at tree-ssa-ccp.cc:312 since r14-2965-gc83528d2367

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
 CC||law at gcc dot gnu.org

--- Comment #4 from Jeffrey A. Law  ---
It was fixed by:

commit 171420fdc9208198f09ff258164fc4cc1fd4bf74 (refs/bisect/bad)
Author: Jakub Jelinek 
Date:   Fri Oct 6 08:54:42 2023 +0200

ipa: Remove ipa_bits

The following patch removes ipa_bits struct pointer/vector from ipa
jump functions and ipa cp transformations.
[ ... ]

[Bug c++/103994] Module ICE in write_var_def with global variable in global module fragment

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 14.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 103994 Summary: Module ICE in write_var_def with global variable in global 
module fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103994

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/103994] Module ICE in write_var_def with global variable in global module fragment

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-9374-gf5c1224708a0cf9cc2770c44bbbe7d0c883942be
Author: Patrick Palka 
Date:   Thu Mar 7 16:39:20 2024 -0500

c++/modules: member alias tmpl partial inst [PR103994]

Alias templates are weird in that their specializations can appear in
both decl_specializations and type_specializations.  They're always in
the decl table, and additionally appear in the type table only at parse
time via finish_template_type.  There seems to be no good reason for
them to appear in both tables, and the code paths end up stepping over
each other in particular for a partial instantiation such as
A::key_arg in the below modules testcase: the type code path
(lookup_template_class) wants to set TI_TEMPLATE to the most general
template whereas the decl code path (tsubst_template_decl called during
instantiation of A) already set TI_TEMPLATE to the partially
instantiated TEMPLATE_DECL.  This TI_TEMPLATE change ends up confusing
modules which decides to stream the logically equivalent TYPE_DECL and
TEMPLATE_DECL for this partial instantiation separately.

This patch fixes this by making lookup_template_class dispatch to
instantiate_alias_template early for alias template specializations.
In turn we now add such specializations only to the decl table.  This
admits some nice simplification in the modules code which otherwise has
to cope with such specializations appearing in both tables.

PR c++/103994

gcc/cp/ChangeLog:

* cp-tree.h (add_mergeable_specialization): Remove second
parameter.
* module.cc (depset::disc_bits::DB_ALIAS_TMPL_INST_BIT): Remove.
(depset::disc_bits::DB_ALIAS_SPEC_BIT): Remove.
(depset::is_alias_tmpl_inst): Remove.
(depset::is_alias): Remove.
(merge_kind::MK_tmpl_alias_mask): Remove.
(merge_kind::MK_alias_spec): Remove.
(merge_kind_name): Remove entries for alias specializations.
(trees_out::core_vals) : Adjust after
removing is_alias_tmpl_inst.
(trees_in::decl_value): Adjust add_mergeable_specialization
calls.
(trees_out::get_merge_kind) :
Use MK_decl_spec for alias template specializations.
(trees_out::key_mergeable): Simplify after MK_tmpl_alias_mask
removal.
(depset::hash::make_dependency): Adjust after removing
DB_ALIAS_TMPL_INST_BIT.
(specialization_add): Don't allow alias templates when !decl_p.
(depset::hash::add_specializations): Remove now-dead code
accomodating alias template specializations in the type table.
* pt.cc (lookup_template_class): Dispatch early to
instantiate_alias_template for alias templates.  Simplify
accordingly.
(add_mergeable_specialization): Remove alias_p parameter and
simplify accordingly.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr99425-1_b.H: s/alias/decl in dump scan.
* g++.dg/modules/tpl-alias-1_a.H: Likewise.
* g++.dg/modules/tpl-alias-2_a.H: New test.
* g++.dg/modules/tpl-alias-2_b.C: New test.

Reviewed-by: Jason Merrill 

[Bug debug/113519] [14 Regression] ICE: in replace_child, at dwarf2out.cc:5704 with -g -fdebug-types-section -fsso-struct=big-endian (or little-endian if the target is big-endian)

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
P1 for an artificial test with exotic options is probably an oversight, but I'm
going to have a look in any case.

[Bug target/113618] [14 Regression] AArch64: memmove idiom regression

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:19b23bf3c32df3cbb96b3d898a1d7142f7bea4a0

commit r14-9373-g19b23bf3c32df3cbb96b3d898a1d7142f7bea4a0
Author: Wilco Dijkstra 
Date:   Wed Feb 21 23:33:58 2024 +

AArch64: memcpy/memset expansions should not emit LDP/STP [PR113618]

The new RTL introduced for LDP/STP results in regressions due to use of
UNSPEC.
Given the new LDP fusion pass is good at finding LDP opportunities, change
the
memcpy, memmove and memset expansions to emit single vector loads/stores.
This fixes the regression and enables more RTL optimization on the standard
memory accesses.  Handling of unaligned tail of memcpy/memmove is improved
with -mgeneral-regs-only.  SPEC2017 performance improves slightly. 
Codesize
is a bit worse due to missed LDP opportunities as discussed in the PR.

gcc/ChangeLog:
PR target/113618
* config/aarch64/aarch64.cc (aarch64_copy_one_block): Remove.
(aarch64_expand_cpymem): Emit single load/store only.
(aarch64_set_one_block): Emit single stores only.

gcc/testsuite/ChangeLog:
PR target/113618
* gcc.target/aarch64/pr113618.c: New test.

[Bug c++/105512] compilation with -fmodules-ts and std=c++20 leads to segfault

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14, thanks for the bug reports.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 105512 Summary: compilation with -fmodules-ts and std=c++20 leads to 
segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105512

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 110730 Summary: STL internal allocation/deallocation might lead to core 
dump in the use of header units of the modules feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110730

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/110730] STL internal allocation/deallocation might lead to core dump in the use of header units of the modules feature

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 14, thanks for the bug report.

[Bug c++/105512] compilation with -fmodules-ts and std=c++20 leads to segfault

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:0552560f6d2eaa1ae6df5c80660b489de1d5c772

commit r14-9372-g0552560f6d2eaa1ae6df5c80660b489de1d5c772
Author: Patrick Palka 
Date:   Thu Mar 7 16:23:22 2024 -0500

c++/modules: inline namespace abi_tag streaming [PR110730]

The unreduced testcase from PR110730 crashes at runtime ultimately
because we don't stream the abi_tag attribute on inline namespaces and
so the filesystem::current_path() call resolves to the non-C++11 ABI
version even though the C++11 ABI is active, leading to a crash when
destroying the path temporary (which contains an std::string member).
Similar story for the PR105512 testcase.

While we do stream the DECL_ATTRIBUTES of all decls that go through
the generic tree streaming routines, it seems namespaces are streamed
separately from other decls and we don't use the generic routines for
them.  So this patch makes us stream the abi_tag manually for (inline)
namespaces.

PR c++/110730
PR c++/105512

gcc/cp/ChangeLog:

* module.cc (module_state::write_namespaces): Stream the
abi_tag attribute of an inline namespace.
(module_state::read_namespaces): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/hello-2_a.C: New test.
* g++.dg/modules/hello-2_b.C: New test.
* g++.dg/modules/namespace-6_a.H: New test.
* g++.dg/modules/namespace-6_b.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/110730] STL internal allocation/deallocation might lead to core dump in the use of header units of the modules feature

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:0552560f6d2eaa1ae6df5c80660b489de1d5c772

commit r14-9372-g0552560f6d2eaa1ae6df5c80660b489de1d5c772
Author: Patrick Palka 
Date:   Thu Mar 7 16:23:22 2024 -0500

c++/modules: inline namespace abi_tag streaming [PR110730]

The unreduced testcase from PR110730 crashes at runtime ultimately
because we don't stream the abi_tag attribute on inline namespaces and
so the filesystem::current_path() call resolves to the non-C++11 ABI
version even though the C++11 ABI is active, leading to a crash when
destroying the path temporary (which contains an std::string member).
Similar story for the PR105512 testcase.

While we do stream the DECL_ATTRIBUTES of all decls that go through
the generic tree streaming routines, it seems namespaces are streamed
separately from other decls and we don't use the generic routines for
them.  So this patch makes us stream the abi_tag manually for (inline)
namespaces.

PR c++/110730
PR c++/105512

gcc/cp/ChangeLog:

* module.cc (module_state::write_namespaces): Stream the
abi_tag attribute of an inline namespace.
(module_state::read_namespaces): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/hello-2_a.C: New test.
* g++.dg/modules/hello-2_b.C: New test.
* g++.dg/modules/namespace-6_a.H: New test.
* g++.dg/modules/namespace-6_b.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/111790] [12/13/14 Regression] Unwarranted missing template keyword warning

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P1

[Bug fortran/109157] -fbound-check: false positive

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from anlauf at gcc dot gnu.org ---
Indeed a dup and fixed by the commit for pr104908.

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