[Bug testsuite/112376] [14 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c was not adjusted for aarch64 case

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug testsuite/112376] New: [14 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c was not adjusted for aarch64 case

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

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

Bug ID: 112376
   Summary: [14 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c was
not adjusted for aarch64 case
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

So after r13-1998-g409978d58dafa689c5b3f85013, the !aarch64 case was updated
but the aarch64 was not. I suspect the testcase just needs to be updated.

The testcase has:
```
/* aarch64 has the highest CASE_VALUES_THRESHOLD in GCC.  It's high enough
   to change decisions in switch expansion which in turn can expose new
   jump threading opportunities.  Skip the later tests on aarch64.  */
/* { dg-final { scan-tree-dump-not "Jumps threaded"  "dom3" { target { !
aarch64*-*-* } } } } */
/* { dg-final { scan-tree-dump "Jumps threaded: 9"  "thread2" { target { !
aarch64*-*-* } } } } */
/* { dg-final { scan-tree-dump "Jumps threaded: 18"  "thread2" { target {
aarch64*-*-* } } } } */
```

[Bug target/112375] [14 Regression] vget_set_lane_1.c fails

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

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

--- Comment #2 from Andrew Pinski  ---
This simple patch fixes the issue but I have not tested it yet, basically it
moves the ins case before the zip:
```
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 5fd7063663c..8a9b89807e3 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -24890,6 +24890,8 @@ aarch64_expand_vec_perm_const_1 (struct
expand_vec_perm_d *d)
return true;
  else if (aarch64_evpc_dup (d))
return true;
+ else if (aarch64_evpc_ins (d))
+   return true;
  else if (aarch64_evpc_zip (d))
return true;
  else if (aarch64_evpc_uzp (d))
@@ -24898,8 +24900,6 @@ aarch64_expand_vec_perm_const_1 (struct
expand_vec_perm_d *d)
return true;
  else if (aarch64_evpc_sel (d))
return true;
- else if (aarch64_evpc_ins (d))
-   return true;
  else if (aarch64_evpc_reencode (d))
return true;

```

But maybe this needs some better cost mechanism because right now even though
we might be able to do ins because of reencoding zip might be detected first.

[Bug target/112375] [14 Regression] vget_set_lane_1.c fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|vget_set_lane_1.c fails |[14 Regression]
   ||vget_set_lane_1.c fails
   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
I almost positive it was caused by r14-3381-g27de9aa15214 Where the the
back-end decides to use zip1 instead of ins here for the vec_perm.

[Bug target/112375] New: vget_set_lane_1.c fails

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

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

Bug ID: 112375
   Summary: vget_set_lane_1.c fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

FAIL: gcc.target/aarch64/vget_set_lane_1.c scan-assembler-times
instv0.s[1], v1.s[0] 3


We expected ins here but currently get:
zip1v0.2s, v0.2s, v1.2s
3 times.

[Bug tree-optimization/112272] suboptimal zero-initialization of struct of mixed pointer and integer types

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-04
 Blocks||53947
 Status|UNCONFIRMED |NEW

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

I don't know why the SLP vectorizer rejects it.

Though I wonder why store merging also rejects it for a cost reason ...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
I think we can mark this as confirmed since there is a patch submitted and the
duplicated bug confirmed that patch fixes the issue.

[Bug preprocessor/111953] stringify operator # rejects an odd number "\" but not "\ \" (or any even # of them with spaces) as input

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|stringify operator #|stringify operator #
   |rejects "\" but not "\ \"   |rejects an odd number "\"
   |as input|but not "\ \" (or any even
   ||# of them with spaces) as
   ||input
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-04

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

[Bug target/111930] aarch64: SME should be supported

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|aarch64: SME is still not   |aarch64: SME should be
   |supported.  |supported
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-04

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

[Bug middle-end/112367] wrong rounding of sum of floating-point constants

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |12.0
  Component|c   |middle-end
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
Fixed for GCC 12 via  r12-4764-ga84b9d5373c7e67fd0ab2a412 (aka PR 57245). Since
this is not a regression it was not backported to earlier versions.


Also GCC 6 is definitely no longer supported and a newer version should be
used/tried before reporting a bug.

[Bug target/112108] [aarch64] Some intrinsics are not correctly enabled when using 'target' attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid, wrong-code
 CC||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-04
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.
One example is:
```
#include 

#pragma GCC push_options
#pragma GCC target ("+nothing+memtag")

void *f(void *ptr, unsigned long long mask)
{
  return __arm_mte_create_random_tag(ptr, mask);
}

#pragma GCC pop_options
```
Currently this fails with C++ due to __builtin_aarch64_memtag_irg not being
defined.

[Bug tree-optimization/112361] [14 Regression] avx512f-reduce-op-1.c miscompiled since r14-5076

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

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

--- Comment #5 from Andrew Pinski  ---
The patch that caused this one, also causes a bootstrap comparison failure with
--with-arch=skylake-avx512, see PR 112374 .

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Ok, it is `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` that fails.
> I am 75% sure it was caused by r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec
> .

I can confirm, it was working right before this patch.

And since it was failing after r14-5081 and r14-5076 is the only patch that
touches code that might change code gen, it is that patch.

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host||x86_64-linux-gnu
   Severity|normal  |major
Summary|[14 Regression] |[14 Regression]
   |--with-arch=native  |`--with-arch=skylake-avx512
   |bootstrap is broken on  |--with-cpu=skylake-avx512`
   |`Xeon(R) D-2166NT`  |causes a comparison failure
  Build||x86_64-linux-gnu

--- Comment #3 from Andrew Pinski  ---
Ok, it is `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` that fails.  I
am 75% sure it was caused by r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec .

[Bug target/112374] [14 Regression] --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Testing with `--with-arch=skylake`, if that works will try with
> `skylake-avx512`.

`--with-arch=skylake` worked.

[Bug target/112374] [14 Regression] --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|--with-arch=native  |[14 Regression]
   |bootstrap is broken on  |--with-arch=native
   |`Xeon(R) D-2166NT`  |bootstrap is broken on
   ||`Xeon(R) D-2166NT`
   Target Milestone|--- |14.0

[Bug target/112374] --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

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

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

--- Comment #1 from Andrew Pinski  ---
Testing with `--with-arch=skylake`, if that works will try with
`skylake-avx512`.

[Bug target/112374] New: --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

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

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

Bug ID: 112374
   Summary: --with-arch=native bootstrap is broken on `Xeon(R)
D-2166NT`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux-gnu

Part of the log:

```
make[3]: Leaving directory '/bajas/pinskia/src/upstream-gcc-git/gcc/objdir'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/i386-expand.o differs
make[2]: *** [Makefile:29937: compare] Error 1
make[2]: Leaving directory '/bajas/pinskia/src/upstream-gcc-git/gcc/objdir'
make[1]: *** [Makefile:29917: stage3-bubble] Error 2
make[1]: Leaving directory '/bajas/pinskia/src/upstream-gcc-git/gcc/objdir'
make: *** [Makefile:29980: bootstrap] Error 2
gcc_build: error: Could not bootstrap the compiler
```

Also noticed here:
https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078409.html

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -mavx

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[14 regression] ICE when|[14 regression] ICE when
   |building webkit-gtk with|building webkit-gtk with
   |-march=raptorlake   |-mavx

--- Comment #7 from Andrew Pinski  ---
`-O2 -mavx` is enough to reproduce the failure too.

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking
 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
Oh yes this is introduced by Richi's extra checking for TYPE_PRECISION .

>From tree.cc:

  if (TYPE_PRECISION (subt) > TYPE_PRECISION (expt))
return exp;

Maybe type_element_precision here ...

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords|needs-reduction |ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-03

--- Comment #5 from Andrew Pinski  ---
Reduced C (and C++) code:
```
struct GdkRGBA2 {
  double a[4];
};
struct GdkRGBA3 {
  float a[4];
};
struct GdkRGBA3 f(struct GdkRGBA2 *color) {
  struct GdkRGBA3 t1;
  for(int i = 0; i < 4; i++)
t1.a[i] = color->a[i];
  struct GdkRGBA3 t2;
  for(int i = 0; i < 4; i++)
  {
float tmp = t1.a[i];
if (__builtin_isnan(tmp))
t2.a[i] = tmp;
  }
  return t2;
}

```

It is related to unord folding with convert on a vector type.

[Bug c/98541] warning with -Wnonnull for array parameter with bound > 0

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:6e9ee44d96e5bda8808dd9d8ccf58d2525383f6b

commit r14-5115-g6e9ee44d96e5bda8808dd9d8ccf58d2525383f6b
Author: Martin Uecker 
Date:   Thu Apr 13 19:35:15 2023 +0200

Reduce false positives for -Wnonnull for VLA parameters [PR98541]

This patch limits the warning about NULL arguments to VLA
parameters declared [static n].

PR c/98541

gcc/
* gimple-ssa-warn-access.cc
(pass_waccess::maybe_check_access_sizes): For VLA bounds
in parameters, only warn about null pointers with 'static'.

gcc/testsuite:
* gcc.dg/Wnonnull-4.c: Adapt test.
* gcc.dg/Wstringop-overflow-40.c: Adapt test.

[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #5 from Edwin Lu  ---
(In reply to seurer from comment #3)

This also appears in GCC 14 for riscv64 targets with the same output pattern
above. After a quick comparison with the expected output, this output is
missing

> contract violation in function G3::f at
> g++.dg/contracts/contracts-tmpl-spec2.C:147: t > 2
> [continue:on]
> contract violation in function G3::f at
> g++.dg/contracts/contracts-tmpl-spec2.C:148: s > 2
> [continue:on]
> G3 full int double
contract violation in function G3::f at .*:124: t > 0
[continue:on]
contract violation in function G3::f at .*:125: s > 0
[continue:on]
> G3 general T S
> contract violation in function G3::f at
> g++.dg/contracts/contracts-tmpl-spec2.C:139: t > 1
> [continue:on]
contract violation in function G3::f at .*:140: s > 1
[continue:on]
> G3 partial int S
> G3 full int C
> G3 full int C
> contract violation in function G4::G4 at
> g++.dg/contracts/contracts-tmpl-spec2.C:173: t > 0

[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:5340f48b7639fcc874f64aac214f9ef9ae43d43e

commit r14-5114-g5340f48b7639fcc874f64aac214f9ef9ae43d43e
Author: Harald Anlauf 
Date:   Fri Nov 3 19:41:54 2023 +0100

Fortran: fix issue with multiple references of a procedure pointer
[PR97245]

gcc/fortran/ChangeLog:

PR fortran/97245
* match.cc (gfc_match_call): If a procedure pointer has already
been
resolved, do not create a new symbol in a procedure reference of
the same name shadowing the first one if it is host-associated.

gcc/testsuite/ChangeLog:

PR fortran/97245
* gfortran.dg/proc_ptr_53.f90: New test.

[Bug ipa/104320] Maybe a thinko in ctor_for_folding

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
I don't see a fix committed for this.

[Bug c++/50755] [avr] ICE: tree check: expected class 'constant', have 'unary' (convert_expr)

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #4 from Roger Sayle  ---
This appears to be fixed on mainline.  G-J can you confirm this is resolved?

[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14.

[Bug c/105660] [12 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from uecker at gcc dot gnu.org ---
fixed for 12.4 (and 13)

[Bug c/110703] Incorrect "-Wfloat-conversion" diagnostic with _Generic

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||uecker at gcc dot gnu.org
  Known to fail||4.9.0
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #4 from uecker at gcc dot gnu.org ---
fixed on trunk.

[Bug c/109450] VLA struct definition vs use in the function declaration

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from uecker at gcc dot gnu.org ---
fixed on trunk.

[Bug c/109450] VLA struct definition vs use in the function declaration

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org
   Target Milestone|--- |14.0

--- Comment #5 from uecker at gcc dot gnu.org ---
fixed on trunk.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 109970 Summary: -Wstringop-overflow should work with parameter forward 
declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c/109970] -Wstringop-overflow should work with parameter forward declarations

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||uecker at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from uecker at gcc dot gnu.org ---
fixed on trunk.

[Bug c/112373] cppcheck: libcpp/charset.cc: 3 * obvious performance issue

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-03

--- Comment #1 from Jonathan Wakely  ---
The struct is:

struct cset_converter
{
  convert_f func;
  iconv_t cd;
  int width;
  const char* from;
  const char* to;
};

So it's not too expensive to copy, but const cset_converter& would indeed be
cheaper.

[Bug c/112373] New: cppcheck: libcpp/charset.cc: 3 * obvious performance issue

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 112373
   Summary: cppcheck: libcpp/charset.cc: 3 * obvious performance
issue
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

A recent run of static analyser cppcheck over the source code
of gcc trunk produces the following:

libcpp/charset.cc:1908:56: performance: Function parameter 'cvt' should be
passed by const reference. [passedByValue]
libcpp/charset.cc:1962:55: performance: Function parameter 'cvt' should be
passed by const reference. [passedByValue]
libcpp/charset.cc:2063:55: performance: Function parameter 'cvt' should be
passed by const reference. [passedByValue]

The first one is

tatic void
emit_numeric_escape (cpp_reader *pfile, cppchar_t n,
 struct _cpp_strbuf *tbuf, struct cset_converter cvt)

Suggest code rework.

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |14.0
 Status|NEW |RESOLVED
  Known to fail||6.0

--- Comment #10 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/91038] ICE with VLA type and statement expression (gimplify_var_or_parm_decl)

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||10.0
 CC||uecker at gcc dot gnu.org
   Target Milestone|--- |12.4
 Status|NEW |RESOLVED

--- Comment #5 from uecker at gcc dot gnu.org ---
Fixed.

[Bug target/112368] Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces

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

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

--- Comment #2 from Francois-Xavier Coudert  ---
Could have been fixed by 8c40b72036c967fbb1d1150515cf70aec382f0a2
But the set of failures on Linux and Darwin are not exactly the same, so we
will see in the next regtest.

[Bug c/68193] _Generic -Woverflow false alarm

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||uecker at gcc dot gnu.org
  Known to fail||4.9.0
   Target Milestone|--- |14.0
 Status|NEW |RESOLVED

--- Comment #9 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |14.0
  Known to fail||4.9.0
 CC||uecker at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/101604] [meta-bug] bogus/missing -Wvla-parameter

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

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

Bug 98536 Summary: warning  with  -Wvla-parameter for unspecified bound getting 
specified later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98536

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c/98536] warning with -Wvla-parameter for unspecified bound getting specified later

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||11.1.0
   Target Milestone|--- |14.0
 CC||uecker at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug debug/112372] GCC omits function location in DWARF at higher optimisation levels

[gprocida at google dot com via Gcc-bugs]

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

--- Comment #4 from Giuliano Procida  ---
The provided example was exactly my original test case.

It's part of our test suite for
https://android.googlesource.com/platform/external/stg/.

I'm currently running multiple versions of GCC and Clang over 100s of tests,
looking for discrepancies. There will probably be more bug reports.

[Bug c/84510] C front-end does not utilise -Wuseless-cast

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 CC||uecker at gcc dot gnu.org
  Known to fail||5.4.0

--- Comment #4 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/111708] Calling external global function instead of local static function.

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||uecker at gcc dot gnu.org
  Known to work||14.0
 Resolution|--- |FIXED
   Target Milestone|--- |14.0
  Known to fail||4.1.2

--- Comment #10 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c++/101027] Short-circuit behavior not respected with co_await in while head

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-03
 Ever confirmed|0   |1

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

[Bug c++/101027] Short-circuit behavior not respected with co_await in while head

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||oremanj at mit dot edu

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

[Bug c++/112360] [coroutines] unreachable 'co_await' still can suspend the coroutine

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 101027.

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

[Bug ipa/96503] attribute alloc_size effect lost after inlining

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-03

[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-November/059892.html

[Bug debug/112372] GCC omits function location in DWARF at higher optimisation levels

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Giuliano Procida from comment #2)
> The symbols are not aliased (which is what I thought might have happened
> with very aggressive optimisations). If they had been aliased, it would be
> much harder to give the symbols types.

They can't alias for language reasons that is `&y != &x` (and `&x != &z`) has
to be true. Anyways as mentioned in PR 65797, a thunk is being created and
going wrong. 

Yes maybe ICF should not touch empty functions ... But I doubt that was your
original testcase.

[Bug target/112368] Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces

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

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

--- Comment #1 from Andrew Pinski  ---
I was getting similar failures on x86_64-linux-gnu for the last week of October
too. I wonder if this is now fixed.

[Bug debug/112372] GCC omits function location in DWARF at higher optimisation levels

[gprocida at google dot com via Gcc-bugs]

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

--- Comment #2 from Giuliano Procida  ---
The symbols are not aliased (which is what I thought might have happened with
very aggressive optimisations). If they had been aliased, it would be much
harder to give the symbols types.

 T x
0010 T y
0020 T z

Also:

Disassembly of section .text:

 :
   0:   c3  ret
   1:   66 66 2e 0f 1f 84 00data16 cs nopw 0x0(%rax,%rax,1)
   8:   00 00 00 00 
   c:   0f 1f 40 00 nopl   0x0(%rax)

0010 :
  10:   c3  ret
  11:   66 66 2e 0f 1f 84 00data16 cs nopw 0x0(%rax,%rax,1)
  18:   00 00 00 00 
  1c:   0f 1f 40 00 nopl   0x0(%rax)

0020 :
  20:   c3  ret

So it should have been entirely possible to assign the correct byte ranges
(low/high PC) to the 3 functions.

[Bug debug/112372] GCC omits function location in DWARF at higher optimisation levels

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Most likely a dup of bug 65797.

[Bug debug/112372] New: GCC omits function location in DWARF at higher optimisation levels

[gprocida at google dot com via Gcc-bugs]

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

Bug ID: 112372
   Summary: GCC omits function location in DWARF at higher
optimisation levels
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gprocida at google dot com
  Target Milestone: ---

Source:

void x(signed char c) { (void) c; }
void y(char c) { (void) c; }
void z(unsigned char c) { (void) c; } // not needed

GCC versions tested: 11.4.0, 12.3.0, 13.2.0
DWARF versions tested: 3, 4, 5
Optimisation levels tests: 0, 1, g (all good); 2, 3, fast, s (all bad)

At lower levels of optimisation, the 3 functions are described with
straightforward DIEs.

At higher levels of optimisation, they are... a mess.

x has abstract origin
y is missing location (PC)
z looks normal

The missing location means that binary analysis tools, like libabigail, cannot
associated the symbol y with its type.

FWIW, Clang does not have this issue.

Remove x: issue disappears.
Remove y: issue disappears.
Remove z: issue persists.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-4'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-oyarai/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-oyarai/gcc-13-13.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=28
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Debian 13.2.0-4) 

gcc -Wall -Wextra -o x.o -O2 -c -g x.c

[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2675-gef28aadad6e

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Shaohua Li from comment #5)
> I probably bisected to the wrong commit. I bisected it again and it should
> be r14-2675-gef28aadad6e

Right, but that does not mean the underlying issue is not the same.

[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Potential fix:

diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index f848e52be4c..9e3571d3dbe 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5064,6 +5064,7 @@ gfc_match_call (void)
  right association is made.  They are thrown out in resolution.)
  ...  */
   if (!sym->attr.generic
+   && !sym->attr.proc_pointer
&& !sym->attr.subroutine
&& !sym->attr.function)
 {

Regtests OK.

[Bug tree-optimization/110903] [12/13/14 Regression] Dead Code Elimination Regression

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Thomas Koenig from comment #3)
> The code from comment#2 and from comment#3 no longer calls foo
> with current trunk, r14-5108-g751fc7bcdcdf25 .
> 
> Now, to see which commit fixed it...

My bet is on r14-4089-gd45ddc2c04e471 .

[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:413ac2c8608cd0378955af27f69e45274b025b32

commit r14-5111-g413ac2c8608cd0378955af27f69e45274b025b32
Author: Harald Anlauf 
Date:   Wed Nov 1 22:55:36 2023 +0100

Fortran: passing of allocatable/pointer arguments to OPTIONAL+VALUE
[PR92887]

gcc/fortran/ChangeLog:

PR fortran/92887
* trans-expr.cc (conv_cond_temp): Helper function for creation of a
conditional temporary.
(gfc_conv_procedure_call): Handle passing of allocatable or pointer
actual argument to dummy with OPTIONAL + VALUE attribute.  Actual
arguments that are not allocated or associated are treated as not
present.

gcc/testsuite/ChangeLog:

PR fortran/92887
* gfortran.dg/value_optional_1.f90: New test.

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sam James from comment #3)
> (In reply to Sam James from comment #2)
> > Created attachment 56504 [details]
> > Hti5.cpp.ii
> > 
> > Kostadin started a reduction earlier and got this. It needs some cleaning 
> > up.
> 
> btw, his was reduced from the same original problem but using a unity build
> file

My reduction so far looks very similar.

[Bug tree-optimization/110903] [12/13/14 Regression] Dead Code Elimination Regression

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

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

--- Comment #3 from Thomas Koenig  ---
The code from comment#2 and from comment#3 no longer calls foo
with current trunk, r14-5108-g751fc7bcdcdf25 .

Now, to see which commit fixed it...

[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861 since r6-6830-g20a0c6f9bdbd78

[falemagn at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Fabio Alemagna  ---
(In reply to Patrick Palka from comment #8)
> The issue was probably latent before r6-6830.  The testcase is kind of
> strange,

It's the "friend injection" technique. In this case, it's used to create a
compile-time counter. The specific test case uses templates in such a way as to
try and circumvent a diagnostic-related bug (bug #112267), which however
triggered this other bug.

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

--- Comment #3 from Sam James  ---
(In reply to Sam James from comment #2)
> Created attachment 56504 [details]
> Hti5.cpp.ii
> 
> Kostadin started a reduction earlier and got this. It needs some cleaning up.

btw, his was reduced from the same original problem but using a unity build
file

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

--- Comment #2 from Sam James  ---
Created attachment 56504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56504&action=edit
Hti5.cpp.ii

Kostadin started a reduction earlier and got this. It needs some cleaning up.

[Bug tree-optimization/111766] Missed optimization with __builtin_unreachable and ands

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861 since r6-6830-g20a0c6f9bdbd78

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

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

--- Comment #8 from Patrick Palka  ---
The issue was probably latent before r6-6830.  The testcase is kind of strange,
e.g. 'slot_allocated' is defined within 'allocate_slot' instead of within
'slot', which would arguably be more natural given that its 'slot' function
parameter.  And consecutive equivalent calls to 'next' apparently resolve to
different overloads due to 'slot_allocated' being defined only after we
instantiate the second 'next' overload.

Reduced:

template
struct slot {
  template
  friend constexpr bool slot_allocated(slot, U);
};

template
struct allocate_slot {
  template
  friend constexpr bool slot_allocated(slot, U) { return true; }
};

template{}, 0)>
constexpr int next(int) { return 0; }

template
constexpr int next(...) { allocate_slot s; return 42; }

// slot_allocated, int>() not defined yet
static_assert(next(0) == 42);
// now it's defined
static_assert(next(0) == 0);

[Bug libfortran/112364] calloc used incorrectly

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #11 from Martin Uecker  ---
This is one possible way to read it.  But as written, I think one can easily
understand it the other way, because calloc never mentions requested total size
but only about space for an array of objects of size 'size'. And then also
7.24.3 continues with "It may then be used to access such an object or an array
of such objects.." which would also imply that the "size" in the sentence
before refers to the size of an individual object.

Anyway, I think it does not really matter for us...  IMHO it is still useful to
make the code have the logical order as documented for calloc. And if it turns
out that the warning annoys too many people in this way, we can still tweak it
before the release.

[Bug libfortran/112364] calloc used incorrectly

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug libfortran/112364] calloc used incorrectly

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #10 from joseph at codesourcery dot com  ---
The wording refers to "the size requested", which I consider to be the 
product of two arguments in the case of calloc - not a particular argument 
to calloc.

[Bug tree-optimization/111766] Missed optimization with __builtin_unreachable and ands

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Macleod  ---
oops. fixed

[Bug tree-optimization/111766] Missed optimization with __builtin_unreachable and ands

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
fixed

[Bug tree-optimization/111766] Missed optimization with __builtin_unreachable and ands

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r14-5110-g7ab79a40b546a1470abaf76bec74c63e9990fe47
Author: Andrew MacLeod 
Date:   Wed Oct 25 09:46:50 2023 -0400

Adjust operators equal and not_equal to check bitmasks against constants

Check to see if a comparison to a constant can be determined to always
be not-equal based on the bitmask.

PR tree-optimization/111766
gcc/
* range-op.cc (operator_equal::fold_range): Check constants
against the bitmask.
(operator_not_equal::fold_range): Ditto.
* value-range.h (irange_bitmask::member_p): New.

gcc/testsuite/
* gcc.dg/pr111766.c: New.

[Bug libfortran/112364] calloc used incorrectly

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #9 from Martin Uecker  ---
(In reply to jos...@codesourcery.com from comment #7)
> I believe "size requested" refers to the product nmemb * size in the case 
> of calloc, so getting the arguments the "wrong" way round does not affect 
> the required alignment.  The point of the change was to override DR#075 
> and stop requiring e.g. 1-byte allocations to be suitably aligned for 
> larger types, not to make alignment for calloc depend on more than the 
> product of the two arguments.

This may have been the intention but the wording now refers explicitly to the
size.
To me this also makes sense as calloc talks about allocating an array of
objects of size 'size'. The required alignment of the array would not depend on
the number of elements but only their size.

[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #9 from Jonathan Wakely  ---
*** Bug 111315 has been marked as a duplicate of this bug. ***

[Bug libbacktrace/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Great, let's close it as a dup then.

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

[Bug libbacktrace/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Rimvydas (RJ)  ---
(In reply to Xi Ruoyao from comment #5)
> Maybe related to PR112263 but I'm not sure.

Can confirm that with patch posted at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263#c7 the stacktrace.cc
testsuite testcases (for both -std=gnu++23 and -std=gnu++26) now able to pass
execution tests when gcc is built with ./configure --enable-bootstrap
--enable-default-pie

--- libstdc++-v3/src/libbacktrace/Makefile.orig
+++ libstdc++-v3/src/libbacktrace/Makefile
@@ -232,3 +232,3 @@
 AWK = gawk
-BACKTRACE_CPPFLAGS =  -DHAVE_ATOMIC_FUNCTIONS=1 -DHAVE_SYNC_FUNCTIONS=1
-DHAVE_FCNTL=1 -DBACKTRACE_ELF_SIZE=64
+BACKTRACE_CPPFLAGS = -D_GNU_SOURCE -DHAVE_ATOMIC_FUNCTIONS=1
-DHAVE_SYNC_FUNCTIONS=1 -DHAVE_DL_ITERATE_PHDR=1 -DHAVE_FCNTL=1
-DBACKTRACE_ELF_SIZE=64
 BACKTRACE_SUPPORTED = 1

[Bug libfortran/112364] calloc used incorrectly

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org ---
7 comments?

diff --git a/libgfortran/io/async.c b/libgfortran/io/async.c
index 57097438e89..8fa1f0d4ce0 100644
--- a/libgfortran/io/async.c
+++ b/libgfortran/io/async.c
@@ -262,7 +262,7 @@ init_async_unit (gfc_unit *u)
 void
 enqueue_transfer (async_unit *au, transfer_args *arg, enum aio_do type)
 {
-  transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+  transfer_queue *tq = calloc (1, sizeof (transfer_queue));
   tq->arg = *arg;
   tq->type = type;
   tq->has_id = 0;
@@ -284,7 +284,7 @@ int
 enqueue_done_id (async_unit *au, enum aio_do type)
 {
   int ret;
-  transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+  transfer_queue *tq = calloc (1, sizeof (transfer_queue));

   tq->type = type;
   tq->has_id = 1;
@@ -308,7 +308,7 @@ enqueue_done_id (async_unit *au, enum aio_do type)
 void
 enqueue_done (async_unit *au, enum aio_do type)
 {
-  transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+  transfer_queue *tq = calloc (1, sizeof (transfer_queue));
   tq->type = type;
   tq->has_id = 0;
   LOCK (&au->lock);
@@ -328,7 +328,7 @@ enqueue_done (async_unit *au, enum aio_do type)
 void
 enqueue_close (async_unit *au)
 {
-  transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+  transfer_queue *tq = calloc (1, sizeof (transfer_queue));

   tq->type = AIO_CLOSE;
   LOCK (&au->lock);

[Bug libfortran/112364] calloc used incorrectly

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #7 from joseph at codesourcery dot com  ---
I believe "size requested" refers to the product nmemb * size in the case 
of calloc, so getting the arguments the "wrong" way round does not affect 
the required alignment.  The point of the change was to override DR#075 
and stop requiring e.g. 1-byte allocations to be suitably aligned for 
larger types, not to make alignment for calloc depend on more than the 
product of the two arguments.

[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c

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

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

--- Comment #9 from Tamar Christina  ---
Right, I've tried to apply that patch to my early break patch series and many
of the tests fail, all the same way in compute_live_loop_exits.

I guess we'll have a conflict here. So I'll post my patches without taking this
change into account and we can sort it out upstream,

[Bug fortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty

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

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

--- Comment #3 from Mikael Morin  ---
Possible culprit:
ifunction.m4 has this code:

  retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
  if (alloc_size == 0)
{
  /* Make sure we have a zero-sized array.  */
  GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
  return;

}

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

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

[Bug c++/112370] -Wfree-nonheap-object in std::vector dtor on sapphirerapids with -O3

[alexander.grund--- via Gcc-bugs]

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

--- Comment #1 from Alexander Grund  ---
Created attachment 56503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56503&action=edit
Preprocessed source

[Bug fortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty

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

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

--- Comment #2 from Mikael Morin  ---
If dim == 3, the ubound and shape are (/ 9, 3, 7 /) as expected.
That is, the problem only arises if the resulting array is empty.

[Bug fortran/112371] Wrong upper bound for the result of reduction intrinsics if the array is empty

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

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

--- Comment #1 from Mikael Morin  ---
(In reply to Mikael Morin from comment #0)
> i = 1
> (...)
> r = sum(a, dim=i)

If i is inlined, that is
  r = sum(a, dim=1)
the shape and ubound are (/ 3, 0, 7 /) as expected.
The difference is probably caused by inline vs library implementation.

[Bug fortran/112371] New: Wrong upper bound for the result of reduction intrinsics if the array is empty

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

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

Bug ID: 112371
   Summary: Wrong upper bound for the result of reduction
intrinsics if the array is empty
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

In the following example, I expect the ubound to be (/ 3, 0, 7 /), but the
printed values are (/ 0, 0, 7 /).


program p
  implicit none
  call check_iparity
  call check_sum
  call check_minloc
contains
  subroutine check_iparity
integer :: a(9,3,0,7)
integer :: i
integer, allocatable :: r(:,:,:)
i = 1
a = reshape((/ integer:: /), shape(a))
r = iparity(a, dim=i)
print *, shape(r)
print *, ubound(r)
!if (any(shape(r) /= (/ 3, 0, 7 /))) stop 11
!if (any(ubound(r) /= (/ 3, 0, 7 /))) stop 13
  end subroutine
  subroutine check_sum
integer :: a(9,3,0,7)
integer :: i
integer, allocatable :: r(:,:,:)
i = 1
a = reshape((/ integer:: /), shape(a))
r = sum(a, dim=i)
print *, shape(r)
print *, ubound(r)
!if (any(shape(r) /= (/ 3, 0, 7 /))) stop 21
!if (any(ubound(r) /= (/ 3, 0, 7 /))) stop 23
  end subroutine
  subroutine check_minloc
integer :: a(9,3,0,7)
integer :: i
integer, allocatable :: r(:,:,:)
i = 1
a = reshape((/ integer:: /), shape(a))
r = minloc(a, dim=i)
print *, shape(r)
print *, ubound(r)
!if (any(shape(r) /= (/ 3, 0, 7 /))) stop 31
!if (any(ubound(r) /= (/ 3, 0, 7 /))) stop 33
  end subroutine
end program

[Bug c++/112370] New: -Wfree-nonheap-object in std::vector dtor on sapphirerapids with -O3

[alexander.grund--- via Gcc-bugs]

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

Bug ID: 112370
   Summary: -Wfree-nonheap-object in std::vector dtor on
sapphirerapids with -O3
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.gr...@tu-dresden.de
  Target Milestone: ---

I have some code (from PTorch) which shows a bogus -Wfree-nonheap-object
warning when compiled with `-O3 -march=sapphirerapids`:

In file included from
/software/GCCcore/12.2.0/include/c++/12.2.0/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/allocator.h:46,
 from /software/GCCcore/12.2.0/include/c++/12.2.0/memory:64,
 from
/src/third_party/ideep/mkl-dnn/src/utils/compatible.hpp:23,
 from
/src/third_party/ideep/mkl-dnn/src/backend/dnnl/dnnl_backend.cpp:19:
In member function 'void std::__new_allocator<_Tp>::deallocate(_Tp*, size_type)
[with _Tp = long int]',
inlined from 'static void std::allocator_traits
>::deallocate(allocator_type&, pointer, size_type) [with _Tp = long int]' at
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/alloc_traits.h:496:23,
inlined from 'void std::_Vector_base<_Tp, _Alloc>::_M_deallocate(pointer,
std::size_t) [with _Tp = long int; _Alloc = std::allocator]' at
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/stl_vector.h:387:19,
inlined from 'std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp =
long int; _Alloc = std::allocator]' at
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/stl_vector.h:366:15,
inlined from 'std::vector<_Tp, _Alloc>::~vector() [with _Tp = long int;
_Alloc = std::allocator]' at
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/stl_vector.h:733:7,
inlined from 'virtual void
dnnl::graph::impl::dnnl_impl::bn_folding_t::execute(const dnnl::stream&, const
std::unordered_map&) const' at
/src/third_party/ideep/mkl-dnn/src/backend/dnnl/op_executable.hpp:1060:63:
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/new_allocator.h:158:26: error:
'void operator delete(void*, std::size_t)' called on pointer '' with
nonzero offset [1, 9223372036854775800] [-Werror=free-nonheap-object]
  158 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p, __n));
  | ~^~~~
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = long int]',
inlined from 'static _Tp* std::allocator_traits
>::allocate(allocator_type&, size_type) [with _Tp = long int]' at
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/alloc_traits.h:464:28,
inlined from 'std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = long int;
_Alloc = std::allocator]' at
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/stl_vector.h:378:33,
inlined from 'void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = const long int*; _Tp = long
int; _Alloc = std::allocator]' at
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/stl_vector.h:1687:25,
inlined from 'std::vector<_Tp, _Alloc>::vector(_InputIterator,
_InputIterator, const allocator_type&) [with _InputIterator = const long int*;
 = void; _Tp = long int; _Alloc = std::allocator]' at /software/GCCcore/12.2.0/include/c++/12.2.0/bits/stl_vector.h:706:23,
inlined from 'dnnl::memory::dims dnnl::memory::desc::dims() const' at
/src/third_party/ideep/mkl-dnn/third_party/oneDNN/include/oneapi/dnnl/dnnl.hpp:2677:66,
inlined from 'virtual void
dnnl::graph::impl::dnnl_impl::bn_folding_t::execute(const dnnl::stream&, const
std::unordered_map&) const' at
/src/third_party/ideep/mkl-dnn/src/backend/dnnl/op_executable.hpp:1060:63:
/software/GCCcore/12.2.0/include/c++/12.2.0/bits/new_allocator.h:137:48: note:
returned from 'void* operator new(std::size_t)'
  137 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
  |  ~~^~~

Command used: g++ -O3 -march=sapphirerapids -Wall -Werror -std=gnu++17 -c -o
a.o pre.cpp

Preprocessed source is attached (rather large, sorry)

The bug does not show when using another optimization level or arch. E.g.
`-march=cooperlake` works.

[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c

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

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #56500|0   |1
is obsolete||

--- Comment #8 from Richard Biener  ---
Created attachment 56502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56502&action=edit
patch

Remaining and polished patch.  Will ICE the following testcases I added:

FAIL: gfortran.dg/20231103-1.f90   -O  (internal compiler error: verify_gimple
failed)
FAIL: gfortran.dg/20231103-1.f90   -O   2 blank line(s) in output
FAIL: gfortran.dg/20231103-1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/20231103-2.f90   -O  (internal compiler error: verify_gimple
failed)
FAIL: gfortran.dg/20231103-2.f90   -O   2 blank line(s) in output
FAIL: gfortran.dg/20231103-2.f90   -O  (test for excess errors)


ICE like the following, investigation pending.

Error: incompatible types in 'PHI' argument 1
real(kind=4)

integer(kind=8)

prephitmp_91 = PHI <_21(56), S.4_130(55)>
during GIMPLE pass: vect

[Bug c++/112365] [12/13/14 Regression] ICE on invalid C++

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P5
 Ever confirmed|0   |1
Summary|ICE on invalid C++  |[12/13/14 Regression] ICE
   ||on invalid C++
   Last reconfirmed||2023-11-03
 Status|UNCONFIRMED |NEW
   Target Milestone|14.0|12.4
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r12-3324:

commit e902136b310ee17d4b49eb42d9d5e487d5dcf4a1
Author: Jakub Jelinek 
Date:   Fri Sep 3 09:46:32 2021 +0200

c++, abi: Set DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD on C++ zero width
bitfields [PR102024]

[Bug c++/112365] ICE on invalid C++

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||ice-checking
Summary|[14 regression] ICE on  |ICE on invalid C++
   |invalid C++ |

--- Comment #1 from Sam James  ---
It looks like this is actually present for 13+12 at the very least, just needs
checking.

[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||needs-reduction

[Bug c++/112335] missed optimization on reset and assign unique_ptr

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

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

--- Comment #10 from Jonathan Wakely  ---
Ah, now I understand what you've been saying about the postcondition.

Yes, but the compiler doesn't know the postcondition, it's just words in the
standard, so not visible to the optimization passes.

It might be possible to add some optimization hints to the std::unique_ptr
implementation to make the postcondition visible to the optimizer.

[Bug tree-optimization/112369] New: [14 regression] ICE when building webkit-gtk with -march=raptorlake

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

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

Bug ID: 112369
   Summary: [14 regression] ICE when building webkit-gtk with
-march=raptorlake
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: kocelfc at tutanota dot com
  Target Milestone: ---

Created attachment 56501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56501&action=edit
ColorGtk.cpp.ii.xz

Originally reported downstream by Kostadin Shishmanov at
https://bugs.gentoo.org/916734.

Hit this with building webkit-gtk with -march=raptorlake.

```
# g++ -c -std=c++20 -march=raptorlake -O2 ColorGtk.cpp.ii
during GIMPLE pass: forwprop
/var/tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/WebCore/platform/graphics/gtk/ColorGtk.cpp:
In constructor ‘WebCore::Color::Color(const GdkRGBA&)’:
/var/tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/WebCore/platform/graphics/gtk/ColorGtk.cpp:28:1:
internal compiler error: tree check: expected none of vector_type, have
vector_type in strip_float_extensions, at tree.cc:12141
   28 | Color::Color(const GdkRGBA& color)
  | ^
0x56341e952ffd tree_not_check_failed(tree_node const*, char const*, int, char
const*, ...)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree.cc:8986
0x56341d8bcd08 tree_not_check(tree_node*, char const*, int, char const*,
tree_code)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree.h:3607
0x56341d8bcd08 strip_float_extensions(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree.cc:12141
0x56341f1da729 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/fold-const.cc:12852
0x56341f5d9005 combine_cond_expr_cond
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-forwprop.cc:388
0x56341f55be0b forward_propagate_into_comparison_1
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-forwprop.cc:447
0x56341f4a6d11 forward_propagate_into_comparison
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-forwprop.cc:494
0x56341f4a6d11 execute
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-forwprop.cc:3978
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.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231029/work/gcc-14-20231029/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
14.0.0_pre20231029 p7' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --with-build-config='bootstrap-O3 bootstrap-lto
bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231029 (experimental) (Gentoo Hardened 14.0.0_pre20231029
p7)
```

[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c

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

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

--- Comment #7 from Richard Biener  ---
Bootstrap & regtest is fine but CPU 2017 has two ICEs I'm reducing right now. 
Testing the vectorizable_live_operation simplification right now, will push new
test-coverage and defer the rest until next week (or later).

[Bug target/112368] Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Host||x86_64-apple-darwin21
   Last reconfirmed||2023-11-03
 CC||hjl.tools at gmail dot com,
   ||iains at gcc dot gnu.org
 Target||x86_64-apple-darwin21
 Status|UNCONFIRMED |NEW
   Keywords||testsuite-fail
  Build||x86_64-apple-darwin21

[Bug target/112368] New: Darwin failures for avx256_move_by_pieces and avx256_store_by_pieces

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

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

Bug ID: 112368
   Summary: Darwin failures for avx256_move_by_pieces and
avx256_store_by_pieces
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

Seeing many failures on x86_64-apple-darwin21 related to
TARGET_AVX256_MOVE_BY_PIECES:

FAIL: g++.target/i386/pr80566-2.C  -std=gnu++98  scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 4
FAIL: g++.target/i386/pr80566-2.C  -std=gnu++14  scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 4
FAIL: g++.target/i386/pr80566-2.C  -std=gnu++17  scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 4
FAIL: g++.target/i386/pr80566-2.C  -std=gnu++20  scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 4
FAIL: gcc.target/i386/eh_return-1.c scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 4
FAIL: gcc.target/i386/pieces-memcpy-12.c scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 4
FAIL: gcc.target/i386/pieces-memcpy-13.c scan-assembler-times vmovdqu64[
t]+[^\\n]*%zmm 2
FAIL: gcc.target/i386/pieces-memcpy-15.c scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memcpy-16.c scan-assembler-times vmovdqu[
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memcpy-17.c scan-assembler-times vmovdqu64[
t]+[^\\n]*%zmm 2
FAIL: gcc.target/i386/pieces-memcpy-18.c scan-assembler-times vmovdqu64[
t]+[^\\n]*%zmm 2
FAIL: gcc.target/i386/pieces-memcpy-20.c scan-assembler-times vmovdqu(?:64|)[
t]+[^\\n]*%ymm 4
FAIL: gcc.target/i386/pieces-memcpy-21.c scan-assembler-times vmovdqu(?:64|)[
t]+[^\\n]*%ymm 4
FAIL: gcc.target/i386/pr90773-26.c scan-assembler-times vmovdqu[t
]%ymm[0-9]+, (%[^,]+) 1
FAIL: gcc.target/i386/pr90773-26.c scan-assembler-times vmovdqu[t
]%ymm[0-9]+, 32(%[^,]+) 1

They were not present on 20230909
(https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795615.html) and
first appeared on test results in 20231023
(https://gcc.gnu.org/pipermail/gcc-testresults/2023-October/799220.html).

Taking the example of gcc.target/i386/pieces-memcpy-12.c, the asm generated is:


.build_version macos,  12, 0
.text
.p2align 4
.globl _foo
_foo:
LFB0:
movq_src@GOTPCREL(%rip), %rdx
movq_dst@GOTPCREL(%rip), %rax
movq(%rdx), %rdx
movq(%rax), %rax
vmovdqu (%rdx), %xmm0
vmovdqu %xmm0, (%rax)
vmovdqu 16(%rdx), %xmm1
vmovdqu %xmm1, 16(%rax)
vmovdqu 32(%rdx), %xmm2
vmovdqu %xmm2, 32(%rax)
vmovdqu 48(%rdx), %xmm3
vmovdqu %xmm3, 48(%rax)
ret
LFE0:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long   0
.byte   0x3
.ascii "zR\0"
.uleb128 0x1
.sleb128 -8
.uleb128 0x10
.uleb128 0x1
.byte   0x10
.byte   0xc
.uleb128 0x7
.uleb128 0x8
.byte   0x90
.uleb128 0x1
.align 3
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long   LASFDE1-EH_frame1
.quad   LFB0-.
.set L$set$2,LFE0-LFB0
.quad L$set$2
.uleb128 0
.align 3
LEFDE1:
.subsections_via_symbols

[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c

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

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

--- Comment #6 from Richard Biener  ---
Created attachment 56500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56500&action=edit
patch

Some of the "fixup"s done earlier get in the way of simplifying things. 
Specifically

  /* If the PHI node dominates the loop then we shouldn't create
  a new LC-SSSA PHI for it in the intermediate block.  Unless the
  the loop has been versioned.  If it has then we need the PHI
  node such that later when the loop guard is added the original
  dominating PHI can be found.  */
  basic_block def_bb = gimple_bb (SSA_NAME_DEF_STMT (new_arg));
  if (loop == scalar_loop
  && (!def_bb || !flow_bb_inside_loop_p (loop, def_bb)))
{
  auto gsi = gsi_for_stmt (phi);
  remove_phi_node (&gsi, true);
}

gets the LC PHI nodes out-of-sync where we usually expect a 1:1 mapping
across all loop copies (also for the removed virtual PHI, but that's way
easier to detect as missing).  I wonder if the above is still needed.
At least vect.exp succeeds without it (not that this means much).

I'm giving the attached some more testing (I'll split out the
vectorizable_live_operation changes, they are not required for fixing this bug)

[Bug testsuite/111066] g++.dg/special/initpri3.C fails on darwin

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #4 from Francois-Xavier Coudert  ---
Fixed on mainline (14).

[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

  Build||x86_64-apple-darwin21
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 Target||x86_64-apple-darwin21
   Host||x86_64-apple-darwin21

--- Comment #6 from Francois-Xavier Coudert  ---
Fixed on mainline.

[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2674-gd0de3bf9175

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #5 from Shaohua Li  ---
(In reply to Shaohua Li from comment #3)
> I tried to bisect it and it was bisected to r14-2674-gd0de3bf9175, which is
> different from the bisection point in bug110641

I probably bisected to the wrong commit. I bisected it again and it should be
r14-2675-gef28aadad6e

[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #20 from Martin Uecker  ---
Ah, this is how it works. Thanks!