[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 CC||xry111 at gcc dot gnu.org
 Resolution|MOVED   |---

--- Comment #2 from Xi Ruoyao  ---
Jan Beulich believe the issue is in GCC.  Reopen as "waiting".

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

  Attachment #57874|0   |1
is obsolete||

--- Comment #16 from Martin Uecker  ---
Created attachment 57885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57885=edit
patch


New version. This should work with and without the flag_isoc23 guards.

[Bug c++/49395] Non-class prvalues seem to have cv-qualification with GCC

[hstong at ca dot ibm.com via Gcc-bugs]

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

Hubert Tong  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Hubert Tong  ---
A().i on line 8 is specified to be an xvalue of type "volatile int" nowadays.

[Bug c/114598] [GCC-14] Miscompilation of `#pragma omp parallel for`

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

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

wierton <141242068 at smail dot nju.edu.cn> changed:

   What|Removed |Added

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

--- Comment #1 from wierton <141242068 at smail dot nju.edu.cn> ---
Seems invalid, as `j` is not private within the openmp region

[Bug ipa/114599] New: ICE: SIGSEGV in bitmap_set_bit(bitmap_head*, int) (bitmap.cc:975) with -O2 -fcondition-coverage

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114599
   Summary: ICE: SIGSEGV in bitmap_set_bit(bitmap_head*, int)
(bitmap.cc:975) with -O2 -fcondition-coverage
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fcondition-coverage testcase.c -wrapper
valgrind,-q
==26792== Invalid write of size 4
==26792==at 0xF3D16E: bitmap_set_bit(bitmap_head*, int) (bitmap.cc:975)
==26792==by 0xFB61F3: symtab_node::check_ifunc_callee_symtab_nodes()
(symtab.cc:1449)
==26792==by 0xFCF454: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2320)
==26792==by 0xFD2797: compile (cgraphunit.cc:2315)
==26792==by 0xFD2797: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2589)
==26792==by 0x1513631: compile_file() (toplev.cc:476)
==26792==by 0xDE845B: do_compile (toplev.cc:2154)
==26792==by 0xDE845B: toplev::main(int, char**) (toplev.cc:2310)
==26792==by 0xDE9C3A: main (main.cc:39)
==26792==  Address 0x527a330 is 32 bytes inside a block of size 65,536 alloc'd
==26792==at 0x483E804: malloc (vg_replace_malloc.c:442)
==26792==by 0x2AA5B4B: xmalloc (xmalloc.c:149)
==26792==by 0x2AA2384: call_chunkfun (obstack.c:94)
==26792==by 0x2AA2384: _obstack_begin_worker (obstack.c:141)
==26792==by 0xFD0EDE: analyze_functions(bool) (cgraphunit.cc:1172)
==26792==by 0xFD272D: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2560)
==26792==by 0x1513631: compile_file() (toplev.cc:476)
==26792==by 0xDE845B: do_compile (toplev.cc:2154)
==26792==by 0xDE845B: toplev::main(int, char**) (toplev.cc:2310)
==26792==by 0xDE9C3A: main (main.cc:39)
...
during IPA pass: profile
testcase.c: In function 'do_all_fn_LHASH_DOALL_ARG_arg2':
testcase.c:16:1: internal compiler error: Segmentation fault
   16 | }
  | ^
0x151314f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:319
0x15fba9a hash_table_mod1(unsigned int, unsigned int)
/repo/gcc-trunk/gcc/hash-table.h:344
0x15fba9a hash_table, unsigned int> >::hash_entry,
false, xcallocator>::find_with_hash(gcond* const&, unsigned int)
/repo/gcc-trunk/gcc/hash-table.h:985
0x15f9c9b hash_map, unsigned int> >::get(gcond*
const&)
/repo/gcc-trunk/gcc/hash-map.h:191
0x15f9c9b condition_uid
/repo/gcc-trunk/gcc/tree-profile.cc:370
0x15f9c9b find_conditions(function*)
/repo/gcc-trunk/gcc/tree-profile.cc:877
0x140dc23 branch_prob(bool)
/repo/gcc-trunk/gcc/profile.cc:1549
0x15f92f4 tree_profiling
/repo/gcc-trunk/gcc/tree-profile.cc:1917
0x15f92f4 execute
/repo/gcc-trunk/gcc/tree-profile.cc:2046
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-9799-20240405035546-g4c8b3600c48-checking-yes-rtl-df-extra-nobootstrap-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
--disable-bootstrap --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-9799-20240405035546-g4c8b3600c48-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240405 (experimental) (GCC)

[Bug c/114598] New: [GCC-14] Miscompilation of `#pragma omp parallel for`

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

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

Bug ID: 114598
   Summary: [GCC-14] Miscompilation of `#pragma omp parallel for`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/MPzrsv17v

```
#include 

#define N 2000
int a[N][N];

int main (void)
{
  int i = 0, j = 0;
  for (i = 0; i < N; i++)
#pragma omp parallel for
for (j = 0; j < N; j++)
  a[i][j] = i + j;
  return 0;
}
```

This program will crash if compiled with `gcc-14 -fopenmp-simd`, while clang
can correctly compile it.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

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

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

--- Comment #3 from wierton <141242068 at smail dot nju.edu.cn> ---
Thanks a lot, I have checked it out.

I'm still somewhat confused. Does the difference in compilation stem from GCC
interpreting "=m" and "=r" differently, leading it to assume that once "n.p" is
declared as an output operand without matched input declaration (eg. "=m"
expects "m", "=r" expects "r"), its value is expected to change?

```
asm("":"=m"(n.p):"r"(n.p)); // n.p is expected to change
asm("":"=r"(n.p):"r"(n.p)); // n.p can retain its value
asm("":"=m"(n.p):"m"(n.p)); // n.p can retain its value
```

Thanks in advance for any further explanation you can provide.

[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[13/14 Regression] wrong|[13 Regression] wrong code
   |code with -Oz -fno-dce  |with -Oz -fno-dce
   |-fno-forward-propagate  |-fno-forward-propagate
   |-flive-range-shrinkage  |-flive-range-shrinkage
   |-fweb since r13-1826|-fweb since r13-1826

--- Comment #7 from Jeffrey A. Law  ---
Given the problems we've generally had in this space, it's probably quite
reasonable to treat modifications to the stack pointer as memory accesses.

It probably would have been enough to avoid the RISC-V bug I just fixed a week
or so ago.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=40988

--- Comment #2 from Andrew Pinski  ---
See PR 40988 for ways of fixing the inline-asm and even an expanded
explanation.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The value that goes into the second operand of the  inline-asm is correct.

But since you don't mark the inline-asm as reading the memory location,  gcc
thinks you are not reading it (which is correct based on the definition of how
inline-asm works).

So invalid.

[Bug c/114597] New: [GCC-14] Miscompilation of pointer assignment with inline assembly

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

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

Bug ID: 114597
   Summary: [GCC-14] Miscompilation of pointer assignment with
inline assembly
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/Pn4EG3zzj

```
struct node { void *p; } n;
struct head { struct node *n; } h;

int main () {
  n.p = 
  asm("":"=m"(n.p):"r"(n.p));
  if (n.p != )
__builtin_abort();
  return 0;
}
```

I sanitized this program with all sanitizers I know, they report nothing.
When compile this program with `gcc-14 -O2`, the compiled program aborts, while
`-O0` normally exits.

Any potential undefined behavior:
1. strict aliasing, I added option `-fno-strict-aliasing` to `-O2`, the abort
still exists.
2. If there is some other undefined behavior unknown to me cause this
compilation inconsistency, please let me know.

Regarding the inline assembly, it's important to note that even though `n.p` is
specified as an output operand with `=m`, this doesn't necessarily imply that
`n.p` will be altered. The inline assembly might simply reassign the original
value to `n.p`, leaving it effectively unchanged.

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Created attachment 57883
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57883=edit
patch to add instrumentation as diagnostic aid

[Bug middle-end/114596] New: [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

Bug ID: 114596
   Summary: [OpenMP] "declare variant" scoring seems incorrect for
construct selectors
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57882=edit
reduced test case

Background: I've been working on integrating the dynamic selector support added
for "metadirective" (patches previously submitted but not yet approved) with
the existing support for "declare variant", rewriting a bunch of code so that
they both share the same representations and functions for matching, scoring,
and sorting.  Those patches aren't yet ready to submit and are stage 1
material, but in comparing differences in test results between my new
implementation and the previous behavior, it looks to me like the scoring for
construct selectors in "declare variant" is pretty borked on mainline.

The attached testcase is a reduced version of
c-c++-common/gomp/declare-variant-12.c.  The "16+8+4" comment on f14 agrees
with what the code is doing, but it seems incorrect according to the spec.  By
my reading, the OpenMP context at the point of call to f17 is {teams, parallel,
for, parallel, for} with associated scores {1, 2, 4, 8, 16}, per sections 7.1
and 7.3 of the 5.2 spec, respectively.  My understanding of the latter part of
item (1) in 7.3

"if the traits that correspond to the construct selector set appear multiple
times in the OpenMP context, the highest valued subset of context traits that
contains all selectors in the same order are used"

is that the matching selectors don't have to appear contiguously, so the score
would be 1+8+16.  In discussion with Tobias, he thinks there is still some
ambiguity about which of the duplicates is preferred for the match, though.

I added some instrumentation to the code to try to figure out how it was coming
up with "16+8+4"; the patch is attached, and produced output 

$ install/bin/x86_64-linux-gnu-gcc declare-variant-12.c -fopenmp
-foffload=disable -S

codes[0] = omp_for
codes[1] = omp_parallel
codes[2] = omp_for
codes[3] = omp_parallel
codes[4] = omp_teams
constructs[0] = omp_for
constructs[1] = omp_parallel
constructs[2] = omp_teams
omp_teams, i = 2, j = 4, position = 4
omp_parallel, i = 1, j = 3, position = 3
omp_for, i = 0, j = 2, position = 2
constructs[0] = omp_for, scores[0] = 4, score = 16
constructs[1] = omp_parallel, scores[1] = 3, score = 8
constructs[2] = omp_teams, scores[2] = 2, score = 4

For selector construct = {teams, parallel, for}
  score1 = 29   score2 = 29

The "codes" array is the OpenMP context, "constructs" are the traits in the
construct selector, and the "scores" array does not contain scores, but rather
the positions of the elements of the "constructs" array in the "codes" array.

I believe there are at least three bugs here:

(1) The constructs array is being processed backwards from n-1 to 0, but the
scores array is indexed from 0 to n-1, and later it's assumed both arrays are
in the same order.

(2) The codes array is backwards and so are the position values, and there's no
adjustment to subtract the position from the length of the "codes" array in
computing the corresponding score.

(3) It's choosing the wrong subset from the duplicate traits, preferring the
should-be-lower-valued outer ones over the higher-valued inner ones.

I don't know if anybody wants to tackle a bug fix for this code for GCC 14.  As
I've said, I've got a complete rewrite I'm planning to submit early in stage 1,
which I hope will be an improvement from an engineering perspective in terms of
readability/maintainability, with cleaner and better-documented interfaces and
references to the spec to explain what it is doing.

[Bug target/114595] rtl-expand emit redundant store for bitwise-and expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Already fixed on the trunk. Most likely by r14-6420-g85c5efcffed19c .

We get now:
```
func_1:
movzbl  g1(%rip), %eax
andl$1, %eax
movb%al, g2(%rip)
movsbl  %al, %eax
movl%eax, g3(%rip)
```

There is a small extra zero extend but the extra load/store is gone

[Bug tree-optimization/114545] [11/12/13/14 Regression] Missed optimization for CSE

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug tree-optimization/114559] [11/12/13/14 Regression] After function inlining some optimizations missing

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug target/114591] [12/13/14 Regression] register allocators introduce an extra load operation since gcc-12

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug tree-optimization/114511] [11/12/13/14 Regression] Missed optimization: x = -y; x = c + x + y; ==> x=c;

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #26 from g.peterh...@t-online.de ---
must of course be "... / scale".
How can I still edit posts?

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #25 from g.peterh...@t-online.de ---
Hi Matthias,
to get good results on average (all FP-types: (B)FP16..FP128,
scalar/vectorized(SIMD)/parallel/...) this algorithm seems to me (so far) to be
suitable:

template 
inline constexpr Type   hypot_gp(Type x, Type y, Type z)noexcept
{
using limits = std::numeric_limits;

constexpr Type
sqrt_min= std::sqrt(limits::min()),
sqrt_max= std::sqrt(limits::max()),
scale_up= std::exp2( Type(limits::max_exponent/2)),
scale_down  = std::exp2(-Type(limits::max_exponent/2)),
zero= 0;

x = std::abs(x);
y = std::abs(y);
z = std::abs(z);

if (!(std::isnormal(x) && std::isnormal(y) && std::isnormal(z)))
[[unlikely]]
{
if (std::isinf(x) | std::isinf(y) | std::isinf(z))  return
limits::infinity();
else if (std::isnan(x) | std::isnan(y) | std::isnan(z)) return
limits::quiet_NaN();
else
{
const bool
xz{x == zero},
yz{y == zero},
zz{z == zero};

if (xz)
{
if (yz) return zz ? zero : z;
else if (zz)return y;
}
else if (yz && zz)  return x;
}
}

if (x > z) std::swap(x, z);
if (y > z) std::swap(y, z);

if ((z >= sqrt_min) && (z <= sqrt_max)) [[likely]]
{
//  no scale
return std::sqrt(__builtin_assoc_barrier(x*x + y*y) + z*z);
}
else
{
const Type
scale = (z >= sqrt_min) ? scale_down : scale_up;

x *= scale;
y *= scale;
z *= scale;
return std::sqrt(__builtin_assoc_barrier(x*x + y*y) + z*z);
}
}

[Bug target/114595] rtl-expand emit redundant store for bitwise-and expression

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

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

--- Comment #1 from absoler at smail dot nju.edu.cn ---
gcc-4's result:
```
func_1():
movlg1(%rip), %eax
andl$1, %eax
movb%al, g2(%rip)
movl%eax, g3(%rip)
ret
```

[Bug rtl-optimization/114595] New: rtl-expand emit redundant store for bitwise-and expression

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

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

Bug ID: 114595
   Summary: rtl-expand emit redundant store for bitwise-and
expression
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: absoler at smail dot nju.edu.cn
  Target Milestone: ---

Hi, here's a weird case:
```
int g1, g3;
char g2;
void func_1() {
g3 = (g2 = (1 && 1 & g1)) ;
}

```
one store to `g2` is splted into two since gcc-5 under -O2:
```
func_1():
  401130:   mov0x2efe(%rip),%eax# 404034 
  401136:   mov%al,0x2ef0(%rip)# 40402c 
  40113c:   and$0x1,%eax
  40113f:   andb   $0x1,0x2ee6(%rip)# 40402c 
  401146:   mov%eax,0x2ee4(%rip)# 404030 
```

RTL-expand choose to do this and no other pass could optimize it.

```
;;
;; Full RTL generated for this function:
;;
1: NOTE_INSN_DELETED
3: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
5: r82:SI=[`g1']
6: [`g2']=r82:SI#0
7: {[`g2']=[`g2']&0x1;clobber flags:CC;}
8: {r86:SI=r82:SI&0x1;clobber flags:CC;}
9: [`g3']=r86:SI
```

[Bug c++/91079] [DR 1881] Standard-layout classes and unnamed bit-fields

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Keywords|needs-bisection |
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
Fixed by r12-2975:

commit 32c3a75390623a0470df52af13f78baddd562981
Author: Jakub Jelinek 
Date:   Tue Aug 17 21:06:39 2021 +0200

c++: Implement P0466R5 __cpp_lib_is_layout_compatible compiler helpers
[PR101539]


that patch doesn't have any __is_standard_layout tests so I'll add mine.

[Bug c++/91079] [DR 1881] Standard-layout classes and unnamed bit-fields

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||12.1.0
  Known to fail||11.4.0
   Keywords||needs-bisection, wrong-code

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed in GCC 12+.

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

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

[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to TC from comment #4)
> Dup of bug 55120?

Yes.

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

[Bug c++/91578] bool to size_t warning -Wsign-conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||9.5.0
   Keywords||needs-bisection
  Known to work||10.1.0

--- Comment #3 from Andrew Pinski  ---
Looks to be fixed in GCC 10+.

[Bug c++/12944] [meta-bug] C++ name-lookup problems

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

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

Bug 85570 Summary: Resolution of unqualified-id in member access involving 
templates fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85570

   What|Removed |Added

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

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed then.

[Bug c++/90691] [9 regression] -Wsign-compare false-positive with constant

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||karol.wozniak at linuxmail dot 
org

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

[Bug c++/91083] [9 Regression] inconsistent -Wsign-compare warnings

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/91083] [9 Regression] inconsistent -Wsign-compare warnings

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
  Known to work||10.1.0, 8.1.0, 8.5.0
Summary|inconsistent -Wsign-compare |[9 Regression] inconsistent
   |warnings|-Wsign-compare warnings
  Known to fail||9.5.0

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #4)
> I guess I should add the test.

Though cpp23/lookup2.C does look close to this testcase here.

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Compiles since r12-3643:

commit 18b57c1d4a8777bedfe4ed47166f033e71bc144b
Author: Jason Merrill 
Date:   Fri Sep 17 14:18:55 2021 -0400

c++: improve lookup of member-qualified names

I guess I should add the test.

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

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

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

--- Comment #5 from Andrew Pinski  ---
Note with checking enabled we get an ICE:
:23:17: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   23 | { return foo(); }
  | ^
_Z3foov.resolver/12 (_Z3foov.resolver)

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.4.0
   Keywords||needs-bisection
  Known to work||12.1.0

--- Comment #3 from Andrew Pinski  ---
Looks to be fixed in GCC 12+.

[Bug c++/88371] Gratuitous (?) warning regarding an implicit conversion in pointer arithmetic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed in GCC 10+.

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug c++/88266] nonsense warning about parentheses with all bool not equals

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-04
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1
Summary|nonsense warning about  |nonsense warning about
   |parentheses for comparison  |parentheses with all bool
   ||not equals

--- Comment #1 from Andrew Pinski  ---
Confirmed, != with all boolean types is definitely the only one corner case
where the order does not matter. In other cases (non-boolean or ==, <, etc.)
the order does make a difference.

[Bug c++/86748] Terminates abnormally without error messages

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2018-07-31 00:00:00 |2024-4-4

--- Comment #5 from Andrew Pinski  ---
Note clang has a similar issue here and it still fails.

[Bug c++/86748] Terminates abnormally without error messages

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #3)
> Richard: Can you please update Known to work?

Looks to be the wrong bug #.

[Bug c++/88221] Only restricted set of balanced token sequences allowed for attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 92648 and fixed for GCC 8.4.0, 9.3.0 and 10+.

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

[Bug c++/92648] Handling of unknown attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||o_kniemeyer at maxon dot net

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

[Bug c++/87713] single character underlined in an error message instead of the whole token

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-04
 Ever confirmed|0   |1

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

[Bug c++/86181] [DR 1839] static object mangling conflicts

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||94404
 Status|SUSPENDED   |NEW

--- Comment #5 from Andrew Pinski  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1839

[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to
DR at the February, 2021 meeting.]


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug c++/82475] GCC is unable to compile OpenACC with class fields

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.4.0
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
  Known to work||12.1.0

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 12+ most likely via PR 92120.

[Bug c++/82008] nonnull attribute and multiple inheritance

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98646
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #3 from Andrew Pinski  ---
Fxied in GCC 11 (most likely via the patch which fixed PR 98646 ).

[Bug analyzer/114594] Issues seen with -Wanalyzer-malloc-leak on htop/XUtils.c: String_split

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

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

--- Comment #1 from David Malcolm  ---
The "leak" was fixed in htop by
https://github.com/htop-dev/htop/commit/62c2d820add3dadea7569af051d2afd804f08432

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #8 from Patrick O'Neill  ---
Adjusted testcase:
union a {
  unsigned short b;
  int c;
  signed short d;
};
int e, f = 1, g;
long h;
const int **i;
void j(union a k, int l, unsigned m) {
  const int *a[100];
  i = [0];
  h = k.d;
}
static int o(union a k) {
  k.d = -1;
  while (1)
if (f)
  break;
  j(k, g, e);
  return 0;
}
int main() {
  union a n = {1};
  o(n);
  if (h != -1)
__builtin_abort();
}

Commands:
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -O2 test.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/qemu-riscv64 user-config.out

> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -O3 test.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/qemu-riscv64 user-config.out
zsh: IOT instruction (core dumped) 
/scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/qemu-riscv64 user-config.out

[Bug analyzer/114594] New: Issues seen with -Wanalyzer-malloc-leak on htop/XUtils.c: String_split

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

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

Bug ID: 114594
   Summary: Issues seen with -Wanalyzer-malloc-leak on
htop/XUtils.c: String_split
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
CC: BenBE at geshi dot org
  Target Milestone: ---

Created attachment 57881
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57881=edit
Reduced reproducer

User "BenBE2" on #gcc on IRC noted some issues with the attached file; see also
at https://godbolt.org/z/vKbhqMq4T

The analyzer reports a leak, arguably falsely:

: In function 'xRealloc':
:32:7: warning: leak of '' [CWE-401] [-Wanalyzer-malloc-leak]
   32 |   free(ptr);
  |   ^
  'String_split': events 1-2
|
|   38 | char** String_split(const char* s, char sep, size_t* n) {
|  |^~~~
|  ||
|  |(1) entry to 'String_split'
|   39 |const size_t rate = 10;
|   40 |char** out = xCalloc(rate, sizeof(char*));
|  | 
|  | |
|  | (2) calling 'xCalloc' from 'String_split'
|
+--> 'xCalloc': event 3
   |
   |   15 | void* xCalloc(size_t nmemb, size_t size) {
   |  |   ^~~
   |  |   |
   |  |   (3) entry to 'xCalloc'
   |
 'xCalloc': event 4
   |
   |   16 |assert(nmemb > 0);
   |  |^~
   |  ||
   |  |(4) following 'true' branch (when 'nmemb != 0')...
   |
 'xCalloc': event 5
   |
   |   17 |assert(size > 0);
   |  |^~
   |  ||
   |  |(5) ...to here
   |
 'xCalloc': event 6
   |
   |   17 |assert(size > 0);
   |  |^~
   |  ||
   |  |(6) following 'true' branch (when 'size != 0')...
   |
 'xCalloc': events 7-11
   |
   |   18 |if (SIZE_MAX / nmemb < size) {
   |  |   ~ ^
   |  |   | |
   |  |   | (7) ...to here
   |  |   (8) following 'false' branch...
   |..
   |   21 |void* data = calloc(nmemb, size);
   |  | ~~~
   |  | |
   |  | (9) ...to here
   |   22 |if (!data) {
   |  |   ~  
   |  |   |
   |  |   (10) following 'false' branch (when 'data' is
non-NULL)...
   |..
   |   25 |return data;
   |  |      
   |  |   |
   |  |   (11) ...to here
   |
<--+
|
  'String_split': events 12-13
|
|   40 |char** out = xCalloc(rate, sizeof(char*));
|  | ^~~~
|  | |
|  | (12) returning to 'String_split' from 'xCalloc'
|..
|   44 |while ((where = strchr(s, sep)) != NULL) {
|  |~~
|  ||
|  |(13) when 'strchr' returns non-NULL
|
  'String_split': events 14-16
|
|   44 |while ((where = strchr(s, sep)) != NULL) {
|  |^
|  ||
|  |(14) following 'true' branch
(when 'where' is non-NULL)...
|   45 |   size_t size = (size_t)(where - s);
|  | ~~~
|  ||
|  |(15) ...to here
|   46 |   out[ctr] = xStrndup(s, size);
|  |  ~  
|  |  |
|  |  (16) calling 'xStrndup' from 'String_split'
|
+--> 'xStrndup': events 17-21
   |
   |   67 | char* xStrndup(const char* str, size_t len) {
   |  |   ^~~~
   |  |   |
   |  |   (17) entry to 'xStrndup'
   |   68 |char* data = strndup(str, len);
   |  | ~
   |  | |
   |  | (18) allocated here
   |   69 |if (!data) {
   |  |   ~
   |  |   |
   |  |   (19) assuming 'data' is 

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

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

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

--- Comment #7 from Martin Jambor  ---
Thanks, I will bootstrap and test the patch on x86_64 and submit it
for review then.

Can I ask you, can you please modify the testcase so that it does not
use printf but simply calls __builtin_abort in the miscompiled case
and just returns zero from main if it is OK?  That way we could
include it in our test suite.  Thanks a lot.

[Bug c++/70667] SFINAE error disambiguating using alignas

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

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

--- Comment #4 from Andrew Pinski  ---
If we had:
```
int i = f<3>(nullptr);
```
clang, edg and MSVC also rejects it for the same reason as GCC.

[Bug c++/70667] SFINAE error disambiguating using alignas

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

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

--- Comment #3 from Andrew Pinski  ---
So if we have (note the extra f which has no arguments):
```
template  struct A { alignas (N) int a; };
template  struct B { char c; };

template  int f (int (*)[sizeof (A)]) { return 0; }
template  int f (int (*)[sizeof (B)]) { return 1; }
template  int f () { return 2; }

int i = f<3>();

```
This started to get accepted in GCC 12.

[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl or if ifunc support is disabled (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

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

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

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

https://gcc.gnu.org/g:27b6d081f68528435066be2234c7329e31e0e84f

commit r14-9796-g27b6d081f68528435066be2234c7329e31e0e84f
Author: Wilco Dijkstra 
Date:   Tue Mar 26 15:08:02 2024 +

libatomic: Fix build for --disable-gnu-indirect-function [PR113986]

Fix libatomic build to support --disable-gnu-indirect-function on AArch64.
Always build atomic_16.S, add aliases to the __atomic_ functions if
!HAVE_IFUNC.
Include auto-config.h in atomic_16.S to avoid having to pass defines via
makefiles.  Fix build if HWCAP_ATOMICS/CPUID are not defined.

libatomic:
PR target/113986
* Makefile.in: Regenerated.
* Makefile.am: Make atomic_16.S not depend on HAVE_IFUNC.
Remove predefine of HAVE_FEAT_LSE128.
* acinclude.m4: Remove ARCH_AARCH64_HAVE_LSE128.
* configure: Regenerated.
* config/linux/aarch64/atomic_16.S: Add __atomic_ alias if
!HAVE_IFUNC.
* config/linux/aarch64/host-config.h: Correctly handle !HAVE_IFUNC.
Add defines for HWCAP_ATOMICS and HWCAP_CPUID.

[Bug ipa/113359] [13/14 Regression] LTO miscompilation of ceph on aarch64 and x86_64

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

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

--- Comment #24 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #23)
> I however wonder if we really guarantee to copy the paddings everywhere else
> then the total scalarization part?
> (i.e. in all paths through the RTL expansion)

I wanted that we sometimes don't do that in PR 80689 and the idea was
refused.  And as far as I can recall the code I don't think we do.

Anyway, I have sent the patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6jzlc25db@virgil.suse.cz/T/#u

[Bug c++/114377] [13/14 Regression] GCC crashes on an example of CTAD for alias templates

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:801e82acd6b4f0cf863529875947e394899ea7b9

commit r14-9795-g801e82acd6b4f0cf863529875947e394899ea7b9
Author: centurion 
Date:   Wed Mar 27 18:36:37 2024 +

c++: alias CTAD and template template parm [PR114377]

To match all the other places that pull a _TEMPLATE_PARM out of a
_DECL (get_template_parm_index, etc.).

This change is too small to be legally significant for copyright.

PR c++/114377

gcc/cp/ChangeLog:

* pt.cc (find_template_parameter_info::found): Use TREE_TYPE for
TEMPLATE_DECL instead of DECL_INITIAL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias19.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105863

--- Comment #5 from Andrew Pinski  ---
Someone should report this issue to the QT folks to see if they could
reimplement this to use `#embed` (though GCC needs to add #embed support still
but that is PR 105863)

[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled on x86 since r14-5109-ga291237b628f41

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

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

--- Comment #71 from Martin Jambor  ---
I have sent the patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6le5s25kl@virgil.suse.cz/T/#u

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

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

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

Martin Jambor  changed:

   What|Removed |Added

Summary|[13/14 Regression] ICE in   |[13 Regression] ICE in
   |modify_call, at |modify_call, at
   |ipa-param-manipulation.cc:6 |ipa-param-manipulation.cc:6
   |56  |56

--- Comment #6 from Martin Jambor  ---
Fixed on master, fix queued for backporting to gcc 13 branch.

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

--- Comment #4 from Andrew Pinski  ---
The code has 3 huge arrays which is definitely a canidate for  `#embed` usage.

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

--- Comment #3 from Andrew Pinski  ---
The real way to fix this is to have `#embed` supported for both C++ and C and
move this code over to use that instead.

[Bug c++/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host||arm-linux-gnueabihf
 Target|arm-linux-gnueabihf |
  Component|target  |c++

--- Comment #2 from Andrew Pinski  ---
Though 111MB preprocessed source makes this a huge one in general but if we say
on average a token is 3 characters and a token takes ~16 bytes each. that does
expand to over 500 MB of memory since we do up front lexing for C++.

[Bug target/114578] [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

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

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

--- Comment #1 from Andrew Pinski  ---
Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.03 (  0%)   0.10 (  0%)
 1903k (  0%)
 phase parsing  : 114.74 ( 95%)  45.79 (100%) 160.53 ( 95%)
 6159M (100%)
 phase lang. deferred   :   0.07 (  0%)   0.00 (  0%)   0.07 (  0%)
 9312  (  0%)
 phase opt and generate :   6.36 (  5%)   0.10 (  0%)   6.46 (  4%)
  293k (  0%)
 phase finalize :   0.00 (  0%)   0.06 (  0%)   1.72 (  1%)
0  (  0%)
 |name lookup   :   0.00 (  0%)   0.01 (  0%)   0.00 (  0%)
  109k (  0%)
 garbage collection :   1.89 (  2%)   0.00 (  0%)   1.89 (  1%)
0  (  0%)
 callgraph construction :   6.35 (  5%)   0.09 (  0%)   6.44 (  4%)
   13k (  0%)
 preprocessing  :  30.74 ( 25%)  24.93 ( 54%)  55.53 ( 33%)
 2047M ( 33%)
 parser (global):  81.10 ( 67%)  20.86 ( 45%) 102.10 ( 60%)
 4111M ( 67%)
 constant expression evaluation :   1.08 (  1%)   0.00 (  0%)   1.08 (  1%)
  304  (  0%)
 post expand cleanups   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 2728  (  0%)
 initialize rtl :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 9032  (  0%)
 rest of compilation:   0.01 (  0%)   0.01 (  0%)   0.00 (  0%)
   16k (  0%)
 TOTAL  : 121.17 45.98168.88   
 6161M
Extra diagnostic checks enabled; compiler may run slowly.


For x86_64-linux-gnu (but with checking enabled). Definitely a front-end issue.
Preprocessing takes 2G is even more shocking.

[Bug fortran/89925] [11/12/13/14 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #14)
> (In reply to anlauf from comment #13)
> > Original testcase is fixed for allocate with mold as well as for allocate
> > with source, and some test coverage is in r12-5767.
> > 
> > There are remaining issues for allocatable character arrays, but these
> > are tracked elsewhere, e.g. pr113793.
> > 
> > I suggest to close this one with target milestone 12.x
> 
> Seems like a good idea.  Do you believe that original
> testcase should be converted to a testcase and committed?

Only if something reasonable is tested *beyond* those added/modified
in r12-5767:

gcc/testsuite/gfortran.dg/allocate_with_source_26.f90
gcc/testsuite/gfortran.dg/allocate_with_mold_4.f90

So what is missing here?

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

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r14-9794-gca56b43105fc09021ec445f1978a17cd85ae5e0c
Author: Martin Jambor 
Date:   Thu Apr 4 22:46:16 2024 +0200

ipa: Avoid duplicate replacements in IPA-SRA transformation phase

When the analysis part of IPA-SRA figures out that it would split out
a scalar part of an aggregate which is known by IPA-CP to contain a
known constant, it skips it knowing that the transformation part looks
at IPA-CP aggregate results too and does the right thing (which can
include doing the propagation in GIMPLE because that is the last
moment the parameter exists).

However, when IPA-SRA wants to split out a smaller aggregate out
of an aggregate, which happens to be of the same size as a known
scalar constant at the same offset, the transformation bit fails to
recognize the situation, tries to do both splitting and constant
propagation and in PR 111571 testcase creates a nonsensical call
statement on which the call redirection then ICEs.

Fixed by making sure we don't try to do two replacements of the same
part of the same parameter.

The look-up among replacements requires these are sorted and this
patch just sorts them if they are not already sorted before each new
look-up.  The worst number of sortings that can happen is number of
parameters which are both split and have aggregate constants times
param_ipa_max_agg_items (default 16).  I don't think complicating the
source code to optimize for this unlikely case is worth it but if need
be, it can of course be done.

gcc/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::common_initialization): Avoid creating
duplicate replacement entries.

gcc/testsuite/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* gcc.dg/ipa/pr111571.c: New test.

[Bug fortran/89925] [11/12/13/14 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #14 from kargls at comcast dot net ---
(In reply to anlauf from comment #13)
> Original testcase is fixed for allocate with mold as well as for allocate
> with source, and some test coverage is in r12-5767.
> 
> There are remaining issues for allocatable character arrays, but these
> are tracked elsewhere, e.g. pr113793.
> 
> I suggest to close this one with target milestone 12.x

Seems like a good idea.  Do you believe that original
testcase should be converted to a testcase and committed?

[Bug c++/66053] openmp target data mappings containing this pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |12.0
 Resolution|--- |FIXED

--- Comment #3 from Andrew Pinski  ---
Fixed for GCC 12 via the patch which fixed PR 92120 .

[Bug middle-end/92120] OpenMP 5 – implicit mapping of this->member variable access – "this[:1]" shall be mapped

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug c++/66124] AIX 5.3 - greg_month.cpp from boost date_time shows internal compiler error: Segmentation fault

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

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

--- Comment #2 from Andrew Pinski  ---
This preprocessed source works on the trunk on x86_64 with a small change.
Replace:
typedef char *va_list;
with
typedef __builtin_va_list va_list;

[Bug fortran/89925] [11/12/13/14 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||12.3.0, 13.2.1, 14.0
  Known to fail||10.5.0, 11.4.1
 Status|NEW |WAITING

--- Comment #13 from anlauf at gcc dot gnu.org ---
Original testcase is fixed for allocate with mold as well as for allocate
with source, and some test coverage is in r12-5767.

There are remaining issues for allocatable character arrays, but these
are tracked elsewhere, e.g. pr113793.

I suggest to close this one with target milestone 12.x

[Bug ada/114593] New: Failed type conversion on non-tagged derived type inside a generic unit

[jhb.chat at gmail dot com via Gcc-bugs]

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

Bug ID: 114593
   Summary: Failed type conversion on non-tagged derived type
inside a generic unit
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhb.chat at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57880
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57880=edit
use gnatchop on file to get all example files separated

When converting from a System.Address type to a new type derived off of
System.Address inside a generic, the compiler fails with:

core-first-third.ads:6:04: error: instantiation error at
core-first-second.ads:15
core-first-third.ads:6:04: error: invalid conversion, not compatible with
private type "System.Address"

Doing the same in a basic example without generics involved compiles fine.

GCC version info:
gcc version 13.2.0 (Rev3, Built by MSYS2 project)

Platform is msys2 on Windows 10 home (up to date on all patches).

I also tested on godbolt and it fails starting with version 11.1 up to trunk as
of today.  Last working version was 10.5

Example shows both a working type conversion in example.adb and a failed
compile example using generics.  Simply commenting out the line 'with
Core.First.Third;` in example.adb will allow the program to compile as it
removes the generics.

[Bug rtl-optimization/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r14-9793-ga24476422ba311b83737cf8bdc5892a7fc7514eb
Author: Vladimir N. Makarov 
Date:   Thu Apr 4 16:04:04 2024 -0400

[PR114415][scheduler]: Fixing wrong code generation

  For the test case, the insn scheduler (working for live range
shrinkage) moves insns modifying stack memory before an insn reserving
the stack memory. Comments in the patch contains more details about
the problem and its solution.

gcc/ChangeLog:

PR rtl-optimization/114415
* sched-deps.cc (add_insn_mem_dependence): Add memory check for mem
argument.
(sched_analyze_1): Treat stack pointer modification as memory read.
(sched_analyze_2, sched_analyze_insn): Add memory guard for
processing pending_read_mems.
* sched-int.h (deps_desc): Add comment to pending_read_mems.

gcc/testsuite/ChangeLog:

PR rtl-optimization/114415
* gcc.target/i386/pr114415.c: New test.

[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Bill Long from comment #2)
> Bug 102369 was closed as a duplicate of THIS bug. 
> 
> Has this been fixed in a more recent version of gfortran?

No.  We need only one entry for a bug.

[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header

[longb at cray dot com via Gcc-bugs]

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

--- Comment #12 from Bill Long  ---
Has this been fixed in a more recent version of gfortran?

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

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

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

--- Comment #31 from anlauf at gcc dot gnu.org ---
I've just checked the various comments.

What's left:

- comment#2 : the testcase still fails.  See also comment#7 about the invalid
  partial initialization

- lack of diagnostics of overlapping initialization

There is also some overlap with pr50410.

The ICEs appear fixed, in particular the one in comment#31.

[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes

[longb at cray dot com via Gcc-bugs]

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

Bill Long  changed:

   What|Removed |Added

 CC||longb at cray dot com

--- Comment #2 from Bill Long  ---
Bug 102369 was closed as a duplicate of THIS bug. 

Has this been fixed in a more recent version of gfortran?

[Bug c++/114592] New: Bogus `maybe-uninitialized` on std::variant with std::string with -O3

[janisozaur+gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 114592
   Summary: Bogus `maybe-uninitialized` on std::variant with
std::string with -O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janisozaur+gcc at gmail dot com
  Target Milestone: ---

Created attachment 57879
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57879=edit
minimized reproducer

When trying to compile source file which creates a std::variant which holds
std::string and push it to std::vector, I get bogus warning about string's
internals being left uninitialized. This only happens when using -O3, lower
optimisations do not exhibit this issue.

$ g++ --version
g++ (GCC) 14.0.1 20240404 (experimental)
Copyright (C) 2024 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.

$ g++ -Werror=maybe-uninitialized -O3 -std=gnu++20 -c
test-maybe-uninitialized-gcc14.cpp
<...snip...>
/path/gcc-install-master/include/c++/14.0.1/bits/basic_string.h:271:17: error:
‘*(const std::__cxx11::basic_string,
std::allocator >*)((char*)& + offsetof(std::value_type,
std::variant, std::allocator >
>::.std::__detail::__variant::_Variant_base,
std::allocator >
>::.std::__detail::__variant::_Move_assign_base, std::allocator >
>::.std::__detail::__variant::_Copy_assign_base, std::allocator >
>::.std::__detail::__variant::_Move_ctor_base, std::allocator >
>::.std::__detail::__variant::_Copy_ctor_base, std::allocator >
>::.std::__detail::__variant::_Variant_storage, std::allocator >
>::_M_u)).std::__cxx11::basic_string::_M_string_length’ may be used
uninitialized [-Werror=maybe-uninitialized]
  271 | if (_M_string_length > _S_local_capacity)
  | ^~~~
test-maybe-uninitialized-gcc14.cpp: In function ‘void
BuildAnyArgListFromLegacyArgBuffer(std::vector, std::allocator > > >&, const void*&)’:
test-maybe-uninitialized-gcc14.cpp:20:22: note: ‘’ declared here
   20 | anyArgs.push_back(sz);
  | ~^~~~


It seems to be present in GCC 12 already, last working version is GCC 11

Original code:
https://github.com/OpenRCT2/OpenRCT2/blob/318bff1eac9a51b49ce20029d7a552efdd18e1cd/src/openrct2/localisation/Formatting.cpp#L795

godbolt reproducer with minimized test case: https://godbolt.org/z/9GT9PKTxG

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #9 from Avi Kivity  ---
At least, on 13.2.1. Maybe a backport is required.

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #8 from Avi Kivity  ---
Congratulations on getting the account!

The bug is fixed though.

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

[vipcxj at 126 dot com via Gcc-bugs]

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

vipcxj at 126 dot com changed:

   What|Removed |Added

 CC||vipcxj at 126 dot com

--- Comment #7 from vipcxj at 126 dot com ---
Today I got an account here to report a bug, and realized that the bug was
reported 3 years ago. The version of gcc I'm using is 12.3.0, and it looks like
this bug hasn't been fixed in 3 years~

[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=31606

--- Comment #1 from H.J. Lu  ---
An assembler bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=31606

[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |REOPENED

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #5)
> (In reply to anlauf from comment #4)
> > This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 
> > .
> 
> Not here. As far as I can tell the results remain exactly the same for both
> character and numeric results from 'foo'.

Oops, I only checked that comment#0 is fixed (-> gfortran.dg/associate_66.f90)
and overlooked the other case in comment#1.

Reopening.

Regarding ALLOCATE with SOURCE and CHARACTER, I have a partial patch
for pr113793.  Need to look again into that one.

[Bug target/114591] [12/13/14 Regression] rtl-reload introduce an extra load operation since gcc-12

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
Summary|rtl-reload introduce an |[12/13/14 Regression]
   |extra load operation since  |rtl-reload introduce an
   |gcc-12  |extra load operation since
   ||gcc-12

[Bug target/114591] rtl-reload introduce an extra load operation since gcc-12

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-04
 Target||x86_64
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|rtl-optimization|target

--- Comment #1 from Andrew Pinski  ---
IRA in GCC 12+ has:
```
  Loop 0 (parent -1, header bb2, depth 0)
bbs: 2
all: 0r85 1r82
modified regnos: 82 85
border:
Pressure: GENERAL_REGS=1
Hard reg set forest:
  0:( 0-6 8-15 20-51)@0
1:( 0-6 36-43)@26000
  Spill a1(r82,l0)
  Allocno a0r85 of GENERAL_REGS(15) has 15 avail. regs  0-6 36-43, node: 
0-6 36-43 (confl regs =  7-35 44-75)
  Forming thread from colorable bucket:
Forming thread by copy 0:a0r85-a1r82 (freq=1000):
  Result (freq=5000): a0r85(2000) a1r82(3000)
  Pushing a0(r85,l0)(cost 0)
  Popping a0(r85,l0)  -- assign reg 0
Disposition:
1:r82  l0   mem0:r85  l0 0
New iteration of spill/restore move
+++Costs: overall 1000, reg -1000, mem 2000, ld 0, st 0, move 0
+++   move loops 0, new jumps 0
```

While before it was:
```
  Loop 0 (parent -1, header bb2, depth 0)
bbs: 2
all: 0r85 1r82
modified regnos: 82 85
border:
Pressure: GENERAL_REGS=1
Hard reg set forest:
  0:( 0-6 8-15 20-51)@0
1:( 0-6 36-43)@46000
  Allocno a0r85 of GENERAL_REGS(15) has 15 avail. regs  0-6 36-43, node: 
0-6 36-43 (confl regs =  7-35 44-75)
  Allocno a1r82 of GENERAL_REGS(15) has 15 avail. regs  0-6 36-43, node: 
0-6 36-43 (confl regs =  7-35 44-75)
  Forming thread from colorable bucket:
Forming thread by copy 0:a0r85-a1r82 (freq=1000):
  Result (freq=5000): a0r85(2000) a1r82(3000)
  Pushing a0(r85,l0)(cost 0)
  Pushing a1(r82,l0)(cost 0)
  Popping a1(r82,l0)  -- assign reg 0
  Popping a0(r85,l0)  -- assign reg 0
Disposition:
1:r82  l0 00:r85  l0 0
New iteration of spill/restore move
+++Costs: overall 5000, reg 5000, mem 0, ld 0, st 0, move 0
+++   move loops 0, new jumps 0
```

Notice: `  Spill a1(r82,l0)` in GCC 12+

[Bug rtl-optimization/114591] New: rtl-reload introduce an extra load operation since gcc-12

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

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

Bug ID: 114591
   Summary: rtl-reload introduce an extra load operation since
gcc-12
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: absoler at smail dot nju.edu.cn
  Target Milestone: ---

Hi, I found such a case:
```
unsigned v1;
long long v2;

short func_1() {
v2 = v1;
return v2;
}
```
gcc-12 and gcc-13 would produce under -O2:
```
func_1:
 mov0x0(%rip),%eax# v1
 mov%rax,0x0(%rip)# v2
 movzwl 0x0(%rip),%eax# v1

```
and gcc-11's:

```
func_1:
 mov0x0(%rip),%edx# v1
 mov%rdx,0x0(%rip)# v2
 mov%rdx,%rax
```

I guess the latter is better? the second load of `v1` was introduced in
RTL-reload pass, maybe this pessimize the performance.

[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-04

[Bug target/114590] New: [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 114590
   Summary: [14 Regression] FAIL:
gcc.target/i386/apx-ndd-ti-shift.c (test for excess
errors)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: x86-64

On x86-64, r14-9788-gb7bd2ec73d66f7 gave

Executing on host:
/export/build/gnu/tools-build/gcc-x32-gitlab/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-x32-gitlab/build-x86_64-linux/gcc/ 
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/apx-ndd-ti-shift.c
   -fdiagnostics-plain-output   -O2  -lm  -o ./apx-ndd-ti-shift.exe(timeout
= 300)
spawn -ignore SIGHUP
/export/build/gnu/tools-build/gcc-x32-gitlab/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-x32-gitlab/build-x86_64-linux/gcc/
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/apx-ndd-ti-shift.c
-fdiagnostics-plain-output -O2 -lm -o ./apx-ndd-ti-shift.exe
/tmp/ccVIKjlx.s: Assembler messages:
/tmp/ccVIKjlx.s:13: Error: operand type mismatch for `shld'
/tmp/ccVIKjlx.s:50: Error: operand type mismatch for `shrd'
/tmp/ccVIKjlx.s:91: Error: operand type mismatch for `shrd'
compiler exited with status 1
FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.

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

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

--- Comment #20 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:753d7e4edf63c4ff690858da11bf0d59aa24e1bb

commit r12-10311-g753d7e4edf63c4ff690858da11bf0d59aa24e1bb
Author: Iain Sandoe 
Date:   Wed Jan 18 19:58:33 2023 +

Darwin, fixincludes: Handle MacOS13 SDK Apple-specific deprecations
[PR107568].

The SDK for MacOS13 includes Apple-specific deprecations of some functions
that
are not deprecated in Posix, C or C++ and widely used in GCC.

The fix makes the deprecation conditional on __APPLE_LOCAL_DEPRECATIONS so
that
end users may still observe them but they are hidden from normal
compilations.

Signed-off-by: Iain Sandoe 

PR target/107568

fixincludes/ChangeLog:

* fixincl.x: Regenerate.
* inclhack.def: Add a fix for MacOS13 SDK function deprecations
in stdio.h.
* tests/base/stdio.h (__deprecated_msg): New test.

(cherry picked from commit 442d2bdc1d2a98aba0b18aeaa3e87fa946ac8031)

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:

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

commit r12-10310-ga17f5a03e93d2cc6fd40cef6ab3930ba019f804a
Author: Iain Sandoe 
Date:   Thu Jul 13 07:36:51 2023 +0100

Darwin: Use -platform_version when available [PR110624].

Later versions of the static linker support a more flexible flag to
describe the OS, OS version and SDK used to build the code.  This
replaces the functionality of '-mmacosx_version_min' (which is now
deprecated, leading to the diagnostic described in the PR).

We now use the platform_version flag when available which avoids the
diagnostic.

Signed-off-by: Iain Sandoe 

PR target/110624

gcc/ChangeLog:

* config/darwin.h (DARWIN_PLATFORM_ID): New.
(LINK_COMMAND_A): Use DARWIN_PLATFORM_ID to pass OS, OS version
and SDK data to the static linker.

(cherry picked from commit 032b5da1fc781bd3c23d9caa72fb09439e7f6f3a)

[Bug d/103944] [12/13/14 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:

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

commit r12-10309-g5a72912f9b0a5aa3c5a726ec499137c189921f9b
Author: Iain Sandoe 
Date:   Sun Feb 26 13:53:52 2023 +

libphobos, testsuite: Disable forkgc2 on Darwin [PR103944]

It hangs the testsuite (requiring manual intervention to kill the
spawned processes) which breaks CI.  The reason for the hang id not
clear.  This skips the test for now (xfail does not work).

Signed-off-by: Iain Sandoe 

PR d/103944

libphobos/ChangeLog:

* testsuite/libphobos.gc/forkgc2.d: Skip for Darwin.

(cherry picked from commit fca6d9c12f5bf06469cf9f7db8c42f66ef792fd2)

[Bug target/114587] -mapxf should define a macro

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:1df56719bd868c58466a549b25d7064dac3eb456

commit r14-9791-g1df56719bd868c58466a549b25d7064dac3eb456
Author: H.J. Lu 
Date:   Thu Apr 4 08:05:58 2024 -0700

x86: Define __APX_F__ for -mapxf

Define __APX_F__ when APX is enabled.

gcc/

PR target/114587
* config/i386/i386-c.cc (ix86_target_macros_internal): Define
__APX_F__ when APX is enabled.

gcc/testsuite/

PR target/114587
* gcc.target/i386/apx-2.c: New test.

[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

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

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

--- Comment #20 from Alexander Monakov  ---
(note that if you uninclude the testcase and compile with -fno-exceptions it's
much faster)

On the smaller testcase from comment 14, prune_unused_phi_nodes invokes
gcc_qsort 53386 times. There are two distinct phases.

In the first phase, the count of struct dom_dfsnum to sort grows in a roughly
linear fashion up to 23437 on the 12294'th invocation. Hence this first phase
is quadratic in the overall number of processed dom_dfsnum-s.

In the second phase, it almost always sorts exactly 7 elements for the
remaining ~41000 invocations.

The number of pairwise comparisons performed by gcc_qsort is approximately
(n+1)*(log_2(n)-1), which results in 1.8e9 comparisons overall for the 53386
invocations. perf shows 10.9e9 cycles spent under gcc_qsort, i.e. 6 cycles per
comparison, which looks about right. It's possible to reduce that further by
switching from classic to bidirectional merge, and using cmovs instead of
bitwise arithmetic for branchless selects.

> I'll note the swapping of 8 bytes is a bit odd and it seems to be
> if-converted, thus always doing a write.

That is not a swap. That's the merge step of a mergesort, we are taking the
smaller element from the heads of two arrays and moving it to the tail of a
third array.

Basically there's quadratic behavior in tree-into-ssa, gcc_qsort shows
relatively higher on the profile because the log_2(n) factor becomes
noticeable.

Hope that helps!

[Bug target/114036] Test failure of gcov-14.c on darwin

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:02a1d49da8f95a128d131747546921b67818d144

commit r13-8586-g02a1d49da8f95a128d131747546921b67818d144
Author: Iain Sandoe 
Date:   Sun Mar 31 11:27:53 2024 +0100

testsuite, Darwin: Allow for an undefined symbol [PR114036].

Darwin's linker defaults to requiring all symbols to be defined at
static link time (unless specifically noted or dynamic lookuo is
enabled).

For this test, we just need to note that the symbol is expected to
be undefined.

PR testsuite/114036

gcc/testsuite/ChangeLog:

* gcc.misc-tests/gcov-14.c: Allow for 'Foo' to be undefined
on Darwin link lines.

Signed-off-by: Iain Sandoe 
(cherry picked from commit ad8e34eaa870608e2b07b4e7147e6ef2944bb8b5)

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

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

commit r13-8584-gb03827b261d3c8351f9c208fe2d89ca987a25bee
Author: Iain Sandoe 
Date:   Mon Mar 18 10:06:44 2024 +

testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].

The intent of the test is to show that we find a framework that
is installed in /System/Library/Frameworks when the user has added
a '-F' option.  The trick is to choose some header that is present
for all the Darwin versions we support and that does not contain any
content we cannot parse.  We had been using the Kernel framework for
this, but recent SDK versions have revealed that this is not suitable.

Replacing with a use of IOKit.

PR target/114049

gcc/testsuite/ChangeLog:

* gcc.dg/framework-1.c: Use an IOKit header instead of a
Kernel one.

Signed-off-by: Iain Sandoe 
(cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)

[Bug c++/45431] specify the field for initializer-string for array of chars is too long

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed for GCC 9 by r9-4974-gdfd7fdca2ac17d .

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

[giuliano.belinassi at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Giuliano Belinassi  
---
With your patch we have:

> .LPFE0:
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   nop
>   .type   function, @function
> function:
> .LFB0:
>   .cfi_startproc
> .LCF0:
> 0:addis 2,12,.TOC.-.LCF0@ha
>   addi 2,2,.TOC.-.LCF0@l
>   .localentry function,.-function
>   nop
>   nop
>   mflr %r0

Which seems what is expected.

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

[sainan+gcc.bugzilla at calamity dot gg via Gcc-bugs]

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

--- Comment #9 from Sainan  ---
(In reply to Wilco from comment #8)
> So it's unaligned then, and that's not supported. And you're lucky your
> specific alignment happens to work on v8.4 cores - it would fail for other
> offsets.

I'd say unlucky rather because I was going crazy about not being able to
reproduce this on the Windows ARM machine.

[Bug tree-optimization/114589] missed optimization: losing bool range information

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
> 
> Why didn't sink1 push _10, _13, _12, and _11 past the conditional here ...
> If it did that I think it might have optimized correctly.

Because then _12 would be 1, _13 would be 4 and _10 would be come `_11 + 4` and
the loop induction variable would be going from _11 to `_11 + 4` then:
```
  # __for_begin_15 = PHI <__for_begin_8(6), _11(5)>
  # .MEM_16 = PHI <.MEM_7(6), .MEM_4(D)(5)>
  # VUSE <.MEM_16>
  i_6 = *__for_begin_15;
  # .MEM_7 = VDEF <.MEM_16>
  # USE = nonlocal escaped 
  # CLB = nonlocal escaped 
  _Z1fiD.2782 (i_6);
  # PT = nonlocal 
  __for_begin_8 = __for_begin_15 + 4;
  if (__for_begin_8 != _10)
goto ; [89.00%]
  else
goto ; [11.00%]
```

And we could figure out this loop is only gone through once only.

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

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

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

--- Comment #8 from Wilco  ---
(In reply to Sainan from comment #7)
> (In reply to Wilco from comment #6)
> > That does not make any sense. The only thing I think might happen is that
> > your structure is not correctly aligned (for example by using a custom
> > memory allocator). Can you check the address of count when it fails? (should
> > be in the crash logs, or you can see it in gdb or just printf it).
> 
> I feel silly for not thinking of printing the address, but now that I did, I
> see the final hexit is '9' and so it just so happens this CPU can't deal
> with that...

So it's unaligned then, and that's not supported. And you're lucky your
specific alignment happens to work on v8.4 cores - it would fail for other
offsets.

[Bug tree-optimization/114589] missed optimization: losing bool range information

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|middle-end  |tree-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-04
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

Why didn't sink1 push _10, _13, _12, and _11 past the conditional here ...
If it did that I think it might have optimized correctly.

   [local count: 118111600]:
  _11 = _3(D)->val;
  _5 = o_3(D)->has_val;
  _12 = (sizetype) _5;
  _13 = _12 << 2;
  _10 = _11 + _13;
  if (_5 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119324]: