[Bug fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

https://gcc.gnu.org/g:51046e46ae66ca95bf2b93ae60f0c4d6b338f8af

commit r15-1090-g51046e46ae66ca95bf2b93ae60f0c4d6b338f8af
Author: Andre Vehreschild 
Date:   Wed Jul 19 11:57:43 2023 +0200

Fix returned type to be allocatable for user-functions.

The returned type of user-defined function returning a
class object was not detected and handled correctly, which
lead to memory leaks.

PR fortran/90072

gcc/fortran/ChangeLog:

* expr.cc (gfc_is_alloc_class_scalar_function): Detect
allocatable class return types also for user-defined
functions.
* trans-expr.cc (gfc_conv_procedure_call): Same.
(trans_class_vptr_len_assignment): Compute vptr len
assignment correctly for user-defined functions.

gcc/testsuite/ChangeLog:

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

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

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

commit r15-1091-g9ab90fc627301b1701cf19bf4ca220f02a93d894
Author: Rainer Orth 
Date:   Fri Jun 7 10:12:09 2024 +0200

testsuite: go: Require split-stack support for go.test/test/index0.go
[PR87589]

The index0-out.go test FAILs on Solaris (SPARC and x86, 32 and 64-bit),
as well as several others:

FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments

The test SEGVs because it tries a stack acess way beyond the stack
area.  As Ian analyzed in the PR, the testcase currently requires
split-stack support, so this patch requires just that.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.

2024-06-05  Rainer Orth  

gcc/testsuite:
PR go/87589
* go.test/go-test.exp (go-gc-tests): Require split-stack support
for index0.go.

[Bug target/115355] [12/13/14/15 Regression] vectorization exposes wrong code on P9 LE starting from r12-4496

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

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

--- Comment #11 from Kewen Lin  ---
(In reply to Jens Seifert from comment #10)
> Does this affect loop vectorize and slp vectorize ?
> 
> -fno-tree-loop-vectorize avoids loop vectorization to be performed and
> workarounds this issue. Does the same problems also affect SLP
> vectorization, which does not take place in this sample.
> 
> In other words, do I need
> -fno-tree-loop-vectorize
> or
> -fno-tree-vectorize
> to workaround this bug ?

Since it's an issue on vector merge insn patterns in target code and
vectorization just exposes it, it's hard to workaround this bug completely just
by disabling both loop and slp vectorization, as its related bug PR106069
shows, even without vectorization but using some vec merge built-ins, it's
still possible to hit this issue.  But I'd expect disabling both loop and slp
vectorization (-fno-tree-vectorize) can greatly reduce the possibility of
encountering it.

[Bug tree-optimization/115382] New: Wrong code with in-order conditional reduction and masked loops

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

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

Bug ID: 115382
   Summary: Wrong code with in-order conditional reduction and
masked loops
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

vectorize_fold_left_reduction does

  if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
mask = vect_get_loop_mask (loop_vinfo, gsi, masks, vec_num, vectype_in,
i);
  else if (is_cond_op)
mask = vec_opmask[i];

that doesn't work - both masks have to be combined.  This for example shows
in a runfail of gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
with -march=cascadelake --param vect-partial-vector-usage=2 on x86_64.

The len-masking code looks good.

[Bug target/111376] missed optimization of one bit test on MIPS32r1

[lis8215 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Siarhei Volkau  ---
Created attachment 58377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58377&action=edit
condmove testcase

Tested with current GCC master branch:

- Work with -Os confirmed.
- Condmove issue present in GCC 11 but not current master. Even for GCC 11 it
is very rare case, although found one relatively simple to reproduce: it is
excerpt from Python 3.8.x, reduced as much as I can.
Compilation flags tested: {-O2|-Os} -mips32 -DNDEBUG -mbranch-cost={1|10}

So, my opinion, the patch you propose is perfectly fine.
Condmove issue seems not relevant anymore.

[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-1093-ga47b1aaa7a76201da7e091d9f8d4488105786274
Author: Jakub Jelinek 
Date:   Fri Jun 7 10:32:08 2024 +0200

bitint: Fix up lower_addsub_overflow [PR115352]

The following testcase is miscompiled because of a flawed optimization.
If one changes the 65 in the testcase to e.g. 66, one gets:
...
  _25 = .USUBC (0, _24, _14);
  _12 = IMAGPART_EXPR <_25>;
  _26 = REALPART_EXPR <_25>;
  if (_23 >= 1)
goto ; [80.00%]
  else
goto ; [20.00%]

   :
  if (_23 != 1)
goto ; [80.00%]
  else
goto ; [20.00%]

   :
  _27 = (signed long) _26;
  _28 = _27 >> 1;
  _29 = (unsigned long) _28;
  _31 = _29 + 1;
  _30 = _31 > 1;
  goto ; [100.00%]

   :
  _32 = _26 != _18;
  _33 = _22 | _32;

   :
  # _17 = PHI <_30(9), _22(7), _33(10)>
  # _19 = PHI <_29(9), _18(7), _18(10)>
...
so there is one path for limbs below the boundary (in this case there are
actually no limbs there, maybe we could consider optimizing that further,
say with simply folding that _23 >= 1 condition to 1 == 1 and letting
cfg cleanup handle it), another case where it is exactly the limb on the
boundary (that is the bb 9 handling where it extracts the interesting
bits (the first 3 statements) and then checks if it is zero or all ones and
finally the case of limbs above that where it compares the current result
limb against the previously recorded 0 or all ones and ors differences into
accumulated result.

Now, the optimization which the first hunk removes was based on the idea
that for that case the extraction of the interesting bits from the limb
don't need anything special, so the _27/_28/_29 statements above aren't
needed, the whole limb is interesting bits, so it handled the >= 1
case like the bb 9 above without the first 3 statements and bb 10 wasn't
there at all.  There are 2 problems with that, for the higher limbs it
only checks if the the result limb bits are all zeros or all ones, but
doesn't check if they are the same as the other extension bits, and
it forgets the previous flag whether there was an overflow.
First I wanted to fix it just by adding the _33 = _22 | _30; statement
to the end of bb 9 above, which fixed the originally filed huge testcase
and the first 2 foo calls in the testcase included in the patch, it no
longer forgets about previously checked differences from 0/1.
But as the last 2 foo calls show, it still didn't check whether each
even (or each odd depending on the exact position) result limb is
equal to the first one, so every second limb it could choose some other
0 vs. all ones value and as long as it repeated in another limb above it
it would be ok.

So, the optimization just can't work properly and the following patch
removes it.

2024-06-07  Jakub Jelinek  

PR middle-end/115352
* gimple-lower-bitint.cc (lower_addsub_overflow): Don't disable
single_comparison if cmp_code is GE_EXPR.

* gcc.dg/torture/bitint-71.c: New test.

[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-10288-g0f616e75f32083e1bc6d08f31e3fbc3dea41fa0c
Author: Jakub Jelinek 
Date:   Fri Jun 7 10:32:08 2024 +0200

bitint: Fix up lower_addsub_overflow [PR115352]

The following testcase is miscompiled because of a flawed optimization.
If one changes the 65 in the testcase to e.g. 66, one gets:
...
  _25 = .USUBC (0, _24, _14);
  _12 = IMAGPART_EXPR <_25>;
  _26 = REALPART_EXPR <_25>;
  if (_23 >= 1)
goto ; [80.00%]
  else
goto ; [20.00%]

   :
  if (_23 != 1)
goto ; [80.00%]
  else
goto ; [20.00%]

   :
  _27 = (signed long) _26;
  _28 = _27 >> 1;
  _29 = (unsigned long) _28;
  _31 = _29 + 1;
  _30 = _31 > 1;
  goto ; [100.00%]

   :
  _32 = _26 != _18;
  _33 = _22 | _32;

   :
  # _17 = PHI <_30(9), _22(7), _33(10)>
  # _19 = PHI <_29(9), _18(7), _18(10)>
...
so there is one path for limbs below the boundary (in this case there are
actually no limbs there, maybe we could consider optimizing that further,
say with simply folding that _23 >= 1 condition to 1 == 1 and letting
cfg cleanup handle it), another case where it is exactly the limb on the
boundary (that is the bb 9 handling where it extracts the interesting
bits (the first 3 statements) and then checks if it is zero or all ones and
finally the case of limbs above that where it compares the current result
limb against the previously recorded 0 or all ones and ors differences into
accumulated result.

Now, the optimization which the first hunk removes was based on the idea
that for that case the extraction of the interesting bits from the limb
don't need anything special, so the _27/_28/_29 statements above aren't
needed, the whole limb is interesting bits, so it handled the >= 1
case like the bb 9 above without the first 3 statements and bb 10 wasn't
there at all.  There are 2 problems with that, for the higher limbs it
only checks if the the result limb bits are all zeros or all ones, but
doesn't check if they are the same as the other extension bits, and
it forgets the previous flag whether there was an overflow.
First I wanted to fix it just by adding the _33 = _22 | _30; statement
to the end of bb 9 above, which fixed the originally filed huge testcase
and the first 2 foo calls in the testcase included in the patch, it no
longer forgets about previously checked differences from 0/1.
But as the last 2 foo calls show, it still didn't check whether each
even (or each odd depending on the exact position) result limb is
equal to the first one, so every second limb it could choose some other
0 vs. all ones value and as long as it repeated in another limb above it
it would be ok.

So, the optimization just can't work properly and the following patch
removes it.

2024-06-07  Jakub Jelinek  

PR middle-end/115352
* gimple-lower-bitint.cc (lower_addsub_overflow): Don't disable
single_comparison if cmp_code is GE_EXPR.

* gcc.dg/torture/bitint-71.c: New test.

(cherry picked from commit a47b1aaa7a76201da7e091d9f8d4488105786274)

[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed, thanks for the report.

[Bug fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/86754] [meta-bug] Memory leaks at run time

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

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

Bug 90072 Summary: Polymorphic Dispatch to Polymophic Return Type Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90072

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/90068] Array Constructor Containing Function Call Leaks Memory

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

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

commit r15-1094-gc3190756487080a11e819746f00b6e30fd0a0c2e
Author: Andre Vehreschild 
Date:   Thu Jul 27 14:51:34 2023 +0200

Add finalizer creation to array constructor for functions of derived type.

PR fortran/90068

gcc/fortran/ChangeLog:

* trans-array.cc (gfc_trans_array_ctor_element): Eval non-
variable expressions once only.
(gfc_trans_array_constructor_value): Add statements of
final block.
(trans_array_constructor): Detect when final block is required.

gcc/testsuite/ChangeLog:

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

[Bug ada/115376] ICE with if expression in value setting of a constant declaration

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-07

--- Comment #1 from Eric Botcazou  ---
See https://gcc.gnu.org/bugs/#gnat for instructions on how to report a bug.

[Bug fortran/86754] [meta-bug] Memory leaks at run time

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

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

Bug 90068 Summary: Array Constructor Containing Function Call Leaks Memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90068

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/115383] New: ICE with TCVC_2 build

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

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

Bug ID: 115383
   Summary: ICE with TCVC_2 build
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

Patch [PATCH 1/4] Relax COND_EXPR reduction vectorization SLP restriction  seem
to cause ICE while building TSVC_2

Reduced test:

cat tsvc_vec.i
void dummy();
void s331() {
  int j;
  for (int i; i; i++)
if ((float)i < 00.)
  j = i;
  dummy(j);
}


gcc options used:
gcc  -std=c99 -O3 -march=native -flto -Wl,--sort-section=name -mcpu=neoverse-v2
-msve-vector-bits=128
gcc -v:
Using built-in specs.
COLLECT_GCC=/proj/grco/gcc/Linux_aarch64/upstream-main/latest/bin/gcc
COLLECT_LTO_WRAPPER=/proj/grco/gcc/Linux_aarch64/upstream-main/20240606024711346f33e2/libexec/gcc/aarch64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /var/jenkins/workspace/GCC_Nightly/configure
--enable-multiarch=yes --enable-languages=c,c++,fortran,lto
--prefix=/proj/grco/gcc/Linux_aarch64/upstream-main/20240606024711346f33e2
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240606 (experimental) (GCC)

[Bug fortran/90068] Array Constructor Containing Function Call Leaks Memory

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

[Bug c++/108438] [11/12/13/14/15 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.cc:7611

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #2 from Simon Martin  ---
Working on it

[Bug tree-optimization/115383] [15 Regression] ICE with TCVC_2 build

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-07
 CC||ktkachov at gcc dot gnu.org
 Target||aarch64
   Target Milestone|--- |15.0
Summary|[15 regression] ICE with|[15 Regression] ICE with
   |TCVC_2 build since  |TCVC_2 build
   |r15-1053-g28edeb1409a7b8|
  Known to fail||15.0
 Ever confirmed|0   |1
  Known to work||14.1.0
   Keywords||ice-on-valid-code

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. -O3 -msve-vector-bits=128 -mcpu=neoverse-v2 is enough to trigger it:
ice.c:2:6: internal compiler error: Segmentation fault
2 | void s331() {
  |  ^~~~
0xf4b59b crash_signal
$TOP/gcc/gcc/toplev.cc:319
0xb7f518 phi_nodes_ptr(basic_block_def*)
$TOP/gcc/gcc/gimple.h:4701
0xb7f518 gsi_start_phis(basic_block_def*)
$TOP/gcc/gcc/gimple-iterator.cc:937
0xb7f518 gsi_for_stmt(gimple*)
$TOP/gcc/gcc/gimple-iterator.cc:621
0x1fa982f vectorizable_condition
$TOP/gcc/gcc/tree-vect-stmts.cc:12577
0x1fc4627 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
$TOP/gcc/gcc/tree-vect-stmts.cc:13467
0x1261733 vect_schedule_slp_node
$TOP/gcc/gcc/tree-vect-slp.cc:9729
0x1276837 vect_schedule_slp_node
$TOP/gcc/gcc/tree-vect-slp.cc:9522
0x1276837 vect_schedule_scc
$TOP/gcc/gcc/tree-vect-slp.cc:10017
0x12776df vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
$TOP/gcc/gcc/tree-vect-slp.cc:10110
0x1244837 vect_transform_loop(_loop_vec_info*, gimple*)
$TOP/gcc/gcc/tree-vect-loop.cc:12114
0x1287d5f vect_transform_loops
$TOP/gcc/gcc/tree-vectorizer.cc:1007
0x12883e7 try_vectorize_loop_1
$TOP/gcc/gcc/tree-vectorizer.cc:1153
0x12883e7 try_vectorize_loop
$TOP/gcc/gcc/tree-vectorizer.cc:1183
0x128875b execute
$TOP/gcc/gcc/tree-vectorizer.cc:1299
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.

[Bug tree-optimization/115383] [15 Regression] ICE with TCVC_2 build

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Priority|P3  |P1

--- Comment #2 from Richard Biener  ---
I can reproduce.

[Bug tree-optimization/115383] [15 Regression] ICE with TCVC_2 build since r15-1053-g28edeb1409a7b8

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
So we're now doing a EXTRACT_LAST_REDUCTION with multiple stmt copies which
is disallowed for non-SLP (by accident?).  It shows it of course doesn't
work since we end up removing the scalar reduction stmt multiple times.

   [local count: 860067202]:
  # j_12 = PHI 
  # i_14 = PHI 
  # vect_vec_iv_.9_45 = PHI <_46(8), _47(28)>
  _46 = vect_vec_iv_.9_45 + { 16, 16, 16, 16 };
  _48 = vect_vec_iv_.9_45 + { 4, 4, 4, 4 };
  _49 = _48 + { 4, 4, 4, 4 };
  _50 = _49 + { 4, 4, 4, 4 };
  vect__1.10_51 = (vector(4) float) vect_vec_iv_.9_45;
  vect__1.10_52 = (vector(4) float) _48;
  vect__1.10_53 = (vector(4) float) _49;
  vect__1.10_54 = (vector(4) float) _50;
  mask__3.11_55 = vect__1.10_51 < { 0.0, 0.0, 0.0, 0.0 };
  mask__3.11_56 = vect__1.10_52 < { 0.0, 0.0, 0.0, 0.0 };
  mask__3.11_57 = vect__1.10_53 < { 0.0, 0.0, 0.0, 0.0 };
  mask__3.11_58 = vect__1.10_54 < { 0.0, 0.0, 0.0, 0.0 };
  j_2 = .FOLD_EXTRACT_LAST (j_12, mask__3.11_55, vect_vec_iv_.9_45);

and we removed the old

  j_2 = _3 ? i_14 : j_12;

we are about to insert

  j_2 = .FOLD_EXTRACT_LAST (j_12, mask__3.11_56, _48);

I think correct would be

  j_59 = .FOLD_EXTRACT_LAST (j_12, mask__3.11_55, vect_vec_iv_.9_45);
  j_60 = .FOLD_EXTRACT_LAST (j_59, mask__3.11_56, _48);
  j_61 = .FOLD_EXTRACT_LAST (j_60, mask__3.11_57, _49);
  j_2 = .FOLD_EXTRACT_LAST (j_61, mask__3.11_58, _50);

I'm testing a patch.

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

[torbjorn.svensson at foss dot st.com via Gcc-bugs]

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

Torbjörn SVENSSON  changed:

   What|Removed |Added

 CC||torbjorn.svensson at foss dot 
st.c
   ||om

--- Comment #4 from Torbjörn SVENSSON  ---
Patches sent that addresses both the Cortex-M23 and the Cortex-M55 fails.

M23 patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653882.html
M55 patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653884.html

[Bug tree-optimization/115383] [15 Regression] ICE with TCVC_2 build since r15-1053-g28edeb1409a7b8

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

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

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

I'm testing this, but I do not have hardware to test correctness (and qemu not
set up).

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

Torbjorn SVENSSON  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |azoff at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||azoff at gcc dot gnu.org
   Last reconfirmed||2024-06-07

[Bug rtl-optimization/115384] New: [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 115384
   Summary: [15 Regression] ICE: RTL check: expected code
'const_int', have 'const_wide_int' in
simplify_binary_operation_1, at simplify-rtx.cc:4088
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

This might need RTL checking enabled.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during RTL pass: dse1
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: RTL check: expected code 'const_int',
have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088
9 | }
  | ^
0x8132d6 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.cc:770
0x824c92 simplify_context::simplify_binary_operation_1(rtx_code, machine_mode,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.cc:4088
0x14fb9ad simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.cc:2682
0x14fc6fc simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:3493
0x14fc6fc simplify_rtx(rtx_def const*)
/repo/gcc-trunk/gcc/simplify-rtx.cc:8111
0xff4a2f cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.cc:2128
0xff4044 expand_loc
/repo/gcc-trunk/gcc/cselib.cc:1756
0xff48d4 cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.cc:1919
0xff5c86 cselib_expand_value_rtx(rtx_def*, bitmap_head*, int)
/repo/gcc-trunk/gcc/cselib.cc:1816
0x276ffe0 record_store
/repo/gcc-trunk/gcc/dse.cc:1511
0x277266b scan_insn
/repo/gcc-trunk/gcc/dse.cc:2691
0x277266b dse_step1
/repo/gcc-trunk/gcc/dse.cc:2808
0x277266b rest_of_handle_dse
/repo/gcc-trunk/gcc/dse.cc:3725
0x277266b execute
/repo/gcc-trunk/gcc/dse.cc:3798
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> 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-r15-1093-20240607103208-ga47b1aaa7a7-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/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-r15-1093-20240607103208-ga47b1aaa7a7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240607 (experimental) (GCC)

[Bug tree-optimization/115385] New: Peeling for gaps can be optimized more or needs to peel more than one iteration

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

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

Bug ID: 115385
   Summary: Peeling for gaps can be optimized more or needs to
peel more than one iteration
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Consider

void __attribute__((noipa)) foo(unsigned char * __restrict x,
unsigned char *y, int n)
{
  for (int i = 0; i < n; ++i)
{
  x[16*i+0] = y[3*i+0];
  x[16*i+1] = y[3*i+1];
  x[16*i+2] = y[3*i+2];
  x[16*i+3] = y[3*i+0];
  x[16*i+4] = y[3*i+1];
  x[16*i+5] = y[3*i+2];
  x[16*i+6] = y[3*i+0];
  x[16*i+7] = y[3*i+1];
  x[16*i+8] = y[3*i+2];
  x[16*i+9] = y[3*i+0];
  x[16*i+10] = y[3*i+1];
  x[16*i+11] = y[3*i+2];
  x[16*i+12] = y[3*i+0];
  x[16*i+13] = y[3*i+1];
  x[16*i+14] = y[3*i+2];
  x[16*i+15] = y[3*i+0];
}
}

and

void __attribute__((noipa)) bar(unsigned char * __restrict x,
unsigned char *y, int n)
{
  for (int i = 0; i < n; ++i)
{
  x[16*i+0] = y[5*i+0];
  x[16*i+1] = y[5*i+1];
  x[16*i+2] = y[5*i+2];
  x[16*i+3] = y[5*i+3];
  x[16*i+4] = y[5*i+4];
  x[16*i+5] = y[5*i+0];
  x[16*i+6] = y[5*i+1];
  x[16*i+7] = y[5*i+2];
  x[16*i+8] = y[5*i+3];
  x[16*i+9] = y[5*i+4];
  x[16*i+10] = y[5*i+0];
  x[16*i+11] = y[5*i+1];
  x[16*i+12] = y[5*i+2];
  x[16*i+13] = y[5*i+3];
  x[16*i+14] = y[5*i+4];
  x[16*i+15] = y[5*i+0];
}
}

for both loops we currently cannot reduce the access for the load from 'y' to
not touch extra elements so we force peeling for gaps.  But in both cases
peeling a single scalar iteration is not sufficient and we get

t.c:5:21: note:   ==> examining statement: _3 = y[_1];
t.c:5:21: missed:   peeling for gaps insufficient for access
t.c:7:20: missed:   not vectorized: relevant stmt not supported: _3 = y[_1];

we can avoid this excessive peeling for gaps if we narrow the load from 'y'
to the next power-of-two size where then it's always sufficient to just
peel a single scalar iteration.  When the target cannot construct a vector
with those elements we'd have to peel more than one iteration.

[Bug tree-optimization/115385] Peeling for gaps can be optimized more or needs to peel more than one iteration

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-06-07
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug target/115351] [14/15 regression] pointless movs when passing by value on x86-64

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r15-1101-gfb3e4c549d16d5050e10114439ad77149f33c597
Author: Roger Sayle 
Date:   Fri Jun 7 14:03:20 2024 +0100

i386: PR target/115351: RTX costs for *concatditi3 and *insvti_highpart.

This patch addresses PR target/115351, which is a code quality regression
on x86 when passing floating point complex numbers.  The ABI considers
these arguments to have TImode, requiring interunit moves to place the
FP values (which are actually passed in SSE registers) into the upper
and lower parts of a TImode pseudo, and then similar moves back again
before they can be used.

The cause of the regression is that changes in how TImode initialization
is represented in RTL now prevents the RTL optimizers from eliminating
these redundant moves.  The specific cause is that the *concatditi3
pattern, (zext(hi)<<64)|zext(lo), has an inappropriately high (default)
rtx_cost, preventing fwprop1 from propagating it.  This pattern just
sets the hipart and lopart of a double-word register, typically two
instructions (less if reload can allocate things appropriately) but
the current ix86_rtx_costs actually returns INSN_COSTS(13), i.e. 52.

propagating insn 5 into insn 6, replacing:
(set (reg:TI 110)
(ior:TI (and:TI (reg:TI 110)
(const_wide_int 0x0))
(ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ])
0))
(const_int 64 [0x40]
successfully matched this instruction to *concatditi3_3:
(set (reg:TI 110)
(ior:TI (ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8
]) 0))
(const_int 64 [0x40]))
(zero_extend:TI (subreg:DI (reg:DF 111 [ zD.2796 ]) 0
change not profitable (cost 50 -> cost 52)

This issue is resolved by having ix86_rtx_costs return more reasonable
values for these (place-holder) patterns.

2024-06-07  Roger Sayle  

gcc/ChangeLog
PR target/115351
* config/i386/i386.cc (ix86_rtx_costs): Provide estimates for
the *concatditi3 and *insvti_highpart patterns, about two insns.

gcc/testsuite/ChangeLog
PR target/115351
* g++.target/i386/pr115351.C: New test case.

[Bug c++/115378] [14/15 Regression] ICE with lambda function as a default template argument with variadic templates in some cases

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Started with r14-9943.

[Bug c++/109896] Missed optimisation: overflow detection in multiplication instructions for operator new

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > Created attachment 58374 [details]
> > Patch which I am testing
> 
> There were some regressions. I have to go back and figure out how to fix
> them.

I am will come back to this but maybe in a few months.

[Bug tree-optimization/115381] Missed deoptimization opportunity when comparing two different linker symbols

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=43565
   Severity|normal  |enhancement

[Bug tree-optimization/115381] Missed deoptimization opportunity when comparing two different linker symbols

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Yes this is a dup of bug 43565.

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

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||user202729 at protonmail dot 
com

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

[Bug target/115353] [14 regression] Missed thumb2 table branch instruction optimisations since r14-4946-g7006e5d2d7b5b2

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Ball
:

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

commit r14-10289-gca1924947b5bed8105ae020bef6950bddda448f3
Author: Richard Ball 
Date:   Thu Jun 6 16:10:14 2024 +0100

arm: Fix CASE_VECTOR_SHORTEN_MODE for thumb2.

The CASE_VECTOR_SHORTEN_MODE query is missing some equals signs
which causes suboptimal codegen due to missed optimisation
opportunities. This patch also adds a test for thumb2
switch statements as none exist currently.

gcc/ChangeLog:
PR target/115353
* config/arm/arm.h (enum arm_auto_incmodes):
Correct CASE_VECTOR_SHORTEN_MODE query.

gcc/testsuite/ChangeLog:

* gcc.target/arm/thumb2-switchstatement.c: New test.

(cherry picked from commit 2963c76e8e24d4ebaf2b1b4ac4d7ca44eb0a9025)

[Bug target/115353] [14 regression] Missed thumb2 table branch instruction optimisations since r14-4946-g7006e5d2d7b5b2

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

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

Richard Ball  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Ball  ---
Fixed

[Bug tree-optimization/115363] Missing loop vectorization due to loop bound load not being pulled out

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> Invariant motion doesn't do versioning for aliasing.  But in fact once the
> loop iterates array[k] can no longer alias this->size but this is difficult
> to exploit (peeling the loop once would help).

So I should mention that this was noticed from some code internally which is
optimized by LLVM's polly (graphite) infrastructure and yes it is an important
loop in this code.

[Bug target/115302] aarch64-w64-mingw32: wrong value into BUILD_SYSTEM_HEADER_DIR

[Evgeny.Karpov at microsoft dot com via Gcc-bugs]

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

Evgeny Karpov  changed:

   What|Removed |Added

 CC||Evgeny.Karpov at microsoft dot 
com

--- Comment #1 from Evgeny Karpov  ---
The issue has been discussed here.
https://github.com/Windows-on-ARM-Experiments/gcc-woarm64/issues/17

Resolution:
For now I would suggest to use --native-system-header-dir=/mingw/include with
--with-sysroot.

[Bug c/115386] New: ice with -g -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 115386
   Summary: ice with -g -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 58380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58380&action=edit
C source code

The attached code does this with recent gcc trunk:

foundBugs $ ../results/bin/gcc -c -w -g -O3 bug1034.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
foundBugs $ 

The bug first seems to occur sometime between git hash g:b6c6d5abf0d31c93
and g:30cfdd6ff56972d9, which is 37 commits.

[Bug c/115374] fmod() in x86_64 -O3 not using return value from the glibc's implementation if x87 FPU fprem returns NaN

[k3x-devel at outlook dot com via Gcc-bugs]

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

--- Comment #10 from Mario Hros  ---
That _.265t.optimized posted matches my observation. So the call into glibc
fmod() is made to set errno eventually, ok. But shouldn't the returned value
from the glibc call be used instead of returning NaN? I am not the one to
decide. If that works as expected, then it is not a bug and this issue can be
closed.

[Bug c/115374] fmod() in x86_64 -O3 not using return value from the glibc's implementation if x87 FPU fprem returns NaN

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
(In reply to Mario Hros from comment #10)
> That _.265t.optimized posted matches my observation. So the call into glibc
> fmod() is made to set errno eventually, ok. But shouldn't the returned value
> from the glibc call be used instead of returning NaN?

Why?  We know the result should be NaN and we have a NaN from the inline fmod
expansion.  The glibc call is purely to set errno.

[Bug debug/115386] ice with -g -O3

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
I think it runs out of stack.

[Bug debug/115386] ice with -g -O3

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

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

--- Comment #2 from Andrew Pinski  ---
expand is taking a lot of time but I can't get a stack overflow happening ...

[Bug debug/115386] ice with -g -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Sam James from comment #1)
> I think it runs out of stack.

I tried running it under gdb, and all I got were lots of stack frames,
so I agree with your best advice.

It doesn't seem all that reducible under cvise.
I only managed to get an 8% reduction after an hour's run.

[Bug c/115374] fmod() in x86_64 -O3 not using return value from the glibc's implementation if x87 FPU fprem returns NaN

[k3x-devel at outlook dot com via Gcc-bugs]

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

Mario Hros  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|WAITING |RESOLVED

--- Comment #12 from Mario Hros  ---
Because fmod() does not work when the FPU is in an invalid operation state,
despite the fact that it could if glibc's implementation had been used as a
"fallback". But maybe it's not worth it. I'll mark this as resolved. I am sorry
for bothering you.

[Bug c/115374] fmod() in x86_64 -O3 not using return value from the glibc's implementation if x87 FPU fprem returns NaN

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

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

--- Comment #13 from Jakub Jelinek  ---
The bug is mixing MMX with floating point and expecting it to work, it will
never work properly, you need manual emms in between, or better yet, avoid MMX
altogether, it really isn't worth it.  Just use SSE and higher.

[Bug debug/115386] ice with -g -O3

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

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

--- Comment #4 from Sam James  ---
meh:

==2441836== Warning: set address range perms: large range [0x59d5f040,
0x78483b50) (undefined) 
==2441836== Warning: set address range perms: large range [0x59d5f028,
0x78483b68) (noaccess)
==2441836== Stack overflow in thread #1: can't grow stack to 0x1ffe001000
==2441836== Stack overflow in thread #1: can't grow stack to 0x1ffe001000
==2441836== Can't extend stack to 0x1ffe0010b8 during signal delivery for
thread 1:
==2441836==   no stack segment
==2441836== 
==2441836== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==2441836==  Access not within mapped region at address 0x1FFE0010B8
==2441836== Stack overflow in thread #1: can't grow stack to 0x1ffe001000
==2441836==at 0x117FBE8: gt_ggc_mx_rtx_def(void*) (gtype-desc.cc:326)
==2441836==  If you believe this happened as a result of a stack
==2441836==  overflow in your program's main thread (unlikely but
==2441836==  possible), you can try to increase the size of the
==2441836==  main thread stack using the --main-stacksize= flag.
==2441836==  The main thread stack size used in this run was 16777216.

[Bug target/115353] [14 regression] Missed thumb2 table branch instruction optimisations since r14-4946-g7006e5d2d7b5b2

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |14.2

[Bug c++/115378] [14/15 Regression] ICE with lambda function as a default template argument with variadic templates in some cases

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

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

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

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

commit r15-1103-g5c761395402a730535983a5e49ef1775561ebc61
Author: Patrick Palka 
Date:   Fri Jun 7 12:12:30 2024 -0400

c++: lambda in pack expansion [PR115378]

Here find_parameter_packs_r is incorrectly treating the 'auto' return
type of a lambda as a parameter pack due to Concepts-TS specific logic
added in r6-4517, leading to confusion later when expanding the pattern.

Since we intend on removing Concepts TS support soon anyway, this patch
fixes this by restricting the problematic logic with flag_concepts_ts.
Doing so revealed that add_capture was relying on this logic to set
TEMPLATE_TYPE_PARAMETER_PACK for the 'auto' type of an pack expansion
init-capture, which we now need to do explicitly.

PR c++/115378

gcc/cp/ChangeLog:

* lambda.cc (lambda_capture_field_type): Set
TEMPLATE_TYPE_PARAMETER_PACK on the auto type of an init-capture
pack expansion.
* pt.cc (find_parameter_packs_r) :
Restrict TEMPLATE_TYPE_PARAMETER_PACK promotion with
flag_concepts_ts.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/decltype-auto-103497.C: Adjust expected diagnostic.
* g++.dg/template/pr95672.C: Likewise.
* g++.dg/cpp2a/lambda-targ5.C: New test.

Reviewed-by: Jason Merrill 

[Bug tree-optimization/101703] (bool0 + bool1) & 1 and (bool0 + bool1) == 1 can be optimized to bool0 ^ bool1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/94737

--- Comment #4 from Andrew Pinski  ---
Another one:
```
unsigned f(bool a, bool b)
{
return (a + b)>>1;
}
```

This is just `a & b`.
(this is from https://github.com/llvm/llvm-project/issues/94737 ).

[Bug rtl-optimization/115384] [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|14.0|15.0
   Target Milestone|--- |15.0

[Bug rtl-optimization/115384] [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088

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

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

--- Comment #1 from Andrew Pinski  ---
r15-1047-g7876cde25cbd2f

[Bug rtl-optimization/115384] [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
CONST_VECTOR_DUPLICATE_P (op1) does not check if the operand a CONST_INT or a
CONST_WIDE_INT.

(insn 6 5 7 2 (set (reg:V1TI 101 [ _2 ])
(ashiftrt:V1TI (reg:V1TI 102 [ wD.2793 ])
(const_int 4 [0x4]))) "/app/example.cpp":8:9 6884
{*ashrv1ti3_internal}
 (expr_list:REG_DEAD (reg:V1TI 102 [ wD.2793 ])
(nil)))
(insn 7 6 8 2 (set (reg:V1TI 104)
(mem/u/c:V1TI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0  S16 A128]))
"/app/example.cpp":8:14 2132 {movv1ti_internal}
 (expr_list:REG_EQUAL (const_vector:V1TI [
(const_wide_int 0x0fff0)
])
(nil)))
(insn 8 7 9 2 (set (reg:V1TI 103 [ _3 ])
(and:V1TI (reg:V1TI 101 [ _2 ])
(reg:V1TI 104))) "/app/example.cpp":8:14 7213 {andv1ti3}
 (expr_list:REG_DEAD (reg:V1TI 104)
(expr_list:REG_DEAD (reg:V1TI 101 [ _2 ])
(nil


Confirmed.

[Bug target/115387] New: [15] RISC-V: ICE in iovsprintf.c

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 115387
   Summary: [15] RISC-V: ICE in iovsprintf.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Created attachment 58381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58381&action=edit
freport-bug log

iovsprintf.c: In function '__vsprintf_internal':
iovsprintf.c:34:1: error: definition in block 5 follows the use
   34 | __vsprintf_internal (char *string, size_t maxlen,
  | ^~~
for SSA_NAME: _9 in statement:
prephitmp_36 = (char *) _9;
during GIMPLE pass: widening_mul
iovsprintf.c:34:1: internal compiler error: verify_ssa failed
0x15d36cd verify_ssa(bool, bool)
../../../gcc/gcc/tree-ssa.cc:1203
0x121d9b5 execute_function_todo
../../../gcc/gcc/passes.cc:2096
0x121de0b execute_todo
../../../gcc/gcc/passes.cc:2143
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

Found on all linux targets
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1067

[Bug tree-optimization/115387] [15 regression] RISC-V: ICE in iovsprintf.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15] RISC-V: ICE in |[15 regression] RISC-V: ICE
   |iovsprintf.c|in iovsprintf.c
   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code
  Component|target  |tree-optimization

[Bug c++/107575] [12/13/14/15 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in duplicate_decls, at cp/decl.cc:2605 since r12-8115-g791a968630b3846

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Simon Martin :

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

commit r15-1105-g0ce138694a6b40708a80691fa4003f6af1defa49
Author: Simon Martin 
Date:   Tue Jun 4 21:20:23 2024 +0200

c++: Handle erroneous DECL_LOCAL_DECL_ALIAS in duplicate_decls [PR107575]

We currently ICE upon the following because we don't properly handle local
functions with an error_mark_node as DECL_LOCAL_DECL_ALIAS in
duplicate_decls.

=== cut here ===
void f (void) {
  virtual int f (void) const;
  virtual int f (void);
}
=== cut here ===

This patch fixes this by checking for error_mark_node.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/107575

gcc/cp/ChangeLog:

* decl.cc (duplicate_decls): Check for error_mark_node
DECL_LOCAL_DECL_ALIAS.

gcc/testsuite/ChangeLog:

* g++.dg/parse/crash74.C: New test.

[Bug c++/107575] [12/13/14/15 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in duplicate_decls, at cp/decl.cc:2605 since r12-8115-g791a968630b3846

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

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

Simon Martin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|12.4|14.2
 Resolution|--- |FIXED

--- Comment #5 from Simon Martin  ---
Fixed in trunk

[Bug tree-optimization/115387] [15 regression] RISC-V: ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com,
   ||law at gcc dot gnu.org,
   ||pan2.li at intel dot com,
   ||patrick at rivosinc dot com
Summary|[15 regression] RISC-V: ICE |[15 regression] RISC-V: ICE
   |in iovsprintf.c |in iovsprintf.c since
   ||r15-1081-ge14afbe2d1c
 Target||riscv

--- Comment #1 from Edwin Lu  ---
Bisected to r15-1081-ge14afbe2d1c being the first bad commit

[Bug tree-optimization/115382] Wrong code with in-order conditional reduction and masked loops

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

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

--- Comment #1 from Robin Dapp  ---
Would something like this work?  The testcase ran successfully with Intel's SME
with that change (and aarch64 qemu with SVE).

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 028692614bb..f9bf6a45611 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -7215,7 +7215,21 @@ vectorize_fold_left_reduction (loop_vec_info loop_vinfo,
   tree len = NULL_TREE;
   tree bias = NULL_TREE;
   if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
-   mask = vect_get_loop_mask (loop_vinfo, gsi, masks, vec_num, vectype_in,
i);
+   {
+ tree mask_loop = vect_get_loop_mask (loop_vinfo, gsi, masks,
+  vec_num, vectype_in, i);
+ if (is_cond_op)
+   {
+ /* Merge the loop mask and the cond_op mask.  */
+ mask = make_ssa_name (TREE_TYPE (mask_loop));
+ gassign *and_stmt = gimple_build_assign (mask, BIT_AND_EXPR,
+  mask_loop,
+  vec_opmask[i]);
+ gsi_insert_before (gsi, and_stmt, GSI_SAME_STMT);
+   }
+ else
+   mask = mask_loop;
+   }
   else if (is_cond_op)
mask = vec_opmask[i];
   if (LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo))
-- 
2.45.1

[Bug tree-optimization/115388] New: wrong code at -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 115388
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression as it doesn't reproduce with 14.1 and
earlier.

Compiler Explorer: https://godbolt.org/z/dzbaj98PM

[515] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240607 (experimental) (GCC) 
[516] % 
[516] % gcctk -O2 small.c; ./a.out
[517] % gcctk -O3 small.c
[518] % ./a.out
Aborted
[519] % cat small.c
int printf(const char *, ...);
int a[10], b, c, d[0], h, i, j, k, l;
char e = -1, g;
volatile int f;
static void n() {
  while (e >= 0)
while (1)
  ;
  for (b = 2; b >= 0; b--) {
for (k = 0; k < 4; k++) {
  if (e || i)
continue;
  for (h = 0; h < 2; h++)
f;
}
for (l = 2; l >= 0; l--)
  g = 0;
for (; g < 1; g++)
  if (c)
d[l] = 1;
a[9] = 0;
a[b] = 1;
while (j)
  printf("\n");
  }
}
int main() {
  n();
  if (a[1] != 1)
__builtin_abort();
  return 0;
}

[Bug fortran/114019] allocation with source of deferred character length entity

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-07
   Keywords||ice-on-valid-code
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  Reduced testcase:

subroutine s
  character(1)  :: w = "4"
  character(:), pointer :: chr_pointer
  allocate (chr_pointer, source="123"//w   ) ! ICE at -O0,-Og
! allocate (chr_pointer, source=adjustl("123"//w)  ) ! ICE at -O0,-Og
! allocate (chr_pointer, source=trim   ("123"//w)  ) ! OK
! allocate (chr_pointer, source=repeat ("123"//w,1)) ! OK
end

In the indicated cases where we ICE at -O0 or -Og the length of source
is determined to be 4 at compile time, in the others it is an expression.
Setting a breakpoint in gfc_allocate_using_malloc:

(gdb) p debug_tree(size)
 
constant 4>

I do not see anything being obviously wrong with the dump-tree...

[Bug target/105719] RFE: fixincludes should handle Frameworks

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

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||fxcoudert at gcc dot gnu.org
   Assignee|egallager at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Iain Sandoe from comment #4)
> > Created attachment 55084 [details]
> > Implement the use of fixed framework headers
> > 
> > this was a proof-of-principle exercise while looking into issues caused by
> > implementing __has_feature () [PR60512].
> > 
> > This does not have any of the mechanism to *create* or *install* the fixed
> > headers (for my testing I just built a
> > CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the
> > problems found).
> > 
> > So, still plenty to do ;)
> 
> Remind me to test this patch later; I've kind of forgotten where I was with
> this... distracted with other stuff... (maybe I should unassign it from
> myself?)

Unassigning from myself due to being distracted by too many other things; maybe
FX would like to take over?

[Bug other/37036] fixincludes does not understand sysroot!

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to jayk123 from comment #6)
> I'll login later and put that in the bug once I reset password etc.

Any progress on this?

[Bug other/40789] fixincludes/fixincl.c: duplicate call to close ?

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

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> did you discover this with cppcheck or by looking manually?

Also does -fanalyzer catch this?

[Bug other/15694] fixincl.sh bugs

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

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

--- Comment #4 from Eric Gallager  ---
Also, there's a lot of `shellcheck` output for fixincl.sh, too; should I paste
it here?

[Bug bootstrap/54696] Makefile doesn't propagate CPPFLAGS to host libraries

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

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #5 from Tom Tromey  ---
This came up for gdb as well

https://sourceware.org/pipermail/gdb-patches/2024-June/209725.html

[Bug analyzer/105892] RFE: -fanalyzer could complain about pointer subtraction of pointers to different memory chunks

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:13dcaf1bb6d4f15665a47b14ac0c12cf454e38a2

commit r15-1107-g13dcaf1bb6d4f15665a47b14ac0c12cf454e38a2
Author: David Malcolm 
Date:   Fri Jun 7 16:14:28 2024 -0400

analyzer: new warning: -Wanalyzer-undefined-behavior-ptrdiff (PR
analyzer/105892)

Add a new warning to complain about pointer subtraction involving
different chunks of memory.

For example, given:

  #include 

  int arr[42];
  int sentinel;

  ptrdiff_t
  test_invalid_calc_of_array_size (void)
  {
return &sentinel - arr;
  }

this emits:

demo.c: In function âtest_invalid_calc_of_array_sizeâ:
demo.c:9:20: warning: undefined behavior when subtracting pointers
[CWE-469] [-Wanalyzer-undefined-behavior-ptrdiff]
9 |   return &sentinel - arr;
  |^
  events 1-2
â
â3 | int arr[42];
â  | ~~~
â  | |
â  | (2) underlying object for right-hand side of subtraction
created here
â4 | int sentinel;
â  | ^~~~
â  | |
â  | (1) underlying object for left-hand side of subtraction
created here
â
âââ> âtest_invalid_calc_of_array_sizeâ: event 3
   â
   â9 |   return &sentinel - arr;
   â  |^
   â  ||
   â  |(3) â ï¸  subtraction of
pointers has undefined behavior if they do not point into the same array object
   â

gcc/analyzer/ChangeLog:
PR analyzer/105892
* analyzer.opt (Wanalyzer-undefined-behavior-ptrdiff): New option.
* analyzer.opt.urls: Regenerate.
* region-model.cc (class undefined_ptrdiff_diagnostic): New.
(check_for_invalid_ptrdiff): New.
(region_model::get_gassign_result): Call it for POINTER_DIFF_EXPR.

gcc/ChangeLog:
* doc/invoke.texi: Add -Wanalyzer-undefined-behavior-ptrdiff.

gcc/testsuite/ChangeLog:
PR analyzer/105892
* c-c++-common/analyzer/out-of-bounds-pr110387.c: Add
expected warnings about pointer subtraction.
* c-c++-common/analyzer/ptr-subtraction-1.c: New test.
* c-c++-common/analyzer/ptr-subtraction-CWE-469-example.c: New
test.

Signed-off-by: David Malcolm 

[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Mikael Pettersson  ---
Since gcc-15 wouldn't build due to an unrelated issue, I applied the fmo patch
to gcc-14.1 (which also has this bug) and bootstrapped that. Alas it didn't
make any difference, same error in stage2 as in the initial report.

[Bug debug/115386] ice with -g -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
I tried a git bisect and got this:

$ git bisect good 6fa4b0135439d64c
30cfdd6ff56972d9d1b9dbdd43a8333c85618775 is the first bad commit
commit 30cfdd6ff56972d9d1b9dbdd43a8333c85618775
Author: Robin Dapp 
Date:   Fri May 17 12:48:52 2024 +0200

RISC-V: Remove dead perm series code and document.

which doesn't look very plausible ;-|

I think someone else ought to have a go at a bit bisect and a reduce.

[Bug analyzer/105892] RFE: -fanalyzer could complain about pointer subtraction of pointers to different memory chunks

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Implemented by the above patch for GCC 15.

[Bug analyzer/105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement

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

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

Bug 105892 Summary: RFE: -fanalyzer could complain about pointer subtraction of 
pointers to different memory chunks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105892

   What|Removed |Added

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

[Bug target/115389] New: Invalid ROP hashst offset is emitted when using -mabi=no-altivec

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

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

Bug ID: 115389
   Summary: Invalid ROP hashst offset is emitted when using
-mabi=no-altivec
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

We emit a hashst instruction with an invalid offset when compiling with
-mabi=no-altivec.

bergner@ltcd97-lp3:~/ROP$ cat bug.c 
extern void foo (void);
long
bar (void)
{
  foo ();
  return 0;
}
bergner@ltcd97-lp3:~/ROP$ gcc -c -O2 -mcpu=power10 -mrop-protect -mno-vsx
-mno-altivec -mabi=altivec bug.c
bergner@ltcd97-lp3:~/ROP$ gcc -c -O2 -mcpu=power10 -mrop-protect -mno-vsx
-mno-altivec -mabi=no-altivec bug.c 
/tmp/ccSzxbv5.s: Assembler messages:
/tmp/ccSzxbv5.s:15: Error: invalid offset: must be in the range [-512, -8] and
be a multiple of 8
/tmp/ccSzxbv5.s:25: Error: invalid offset: must be in the range [-512, -8] and
be a multiple of 8

The bug is we only compute the ROP hash save slot offset when
TARGET_ALTIVEC_ABI is true. If TARGET_ALTIVEC_ABI is false and we enable ROP
mitigation, then we use the initialized value of zero which is an illegal
offset value for hashst and hashchk.

This has been broken since the rs6000 ROP mitigation code was first added, so
not a regression.

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

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

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

Peter Bergner  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Target||powerpc64le-linux
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-07
 CC||linkw at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Peter Bergner  ---
I have a patch I'm testing.

[Bug fortran/115390] New: Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function

[daklishch at gmail dot com via Gcc-bugs]

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

Bug ID: 115390
   Summary: Bogus -Wuninitialized warning when using CHARACTER(*)
argument in BIND(C) function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daklishch at gmail dot com
  Target Milestone: ---

The following code produces -Wuninitialized warning when compiled with -Wall.

MODULE test
IMPLICIT NONE
CONTAINS
SUBROUTINE foo(s)
CHARACTER(*), INTENT(IN) :: s
END

SUBROUTINE bar(s) BIND(C)
CHARACTER(*), INTENT(IN) :: s
CALL foo(s)
END
END

Quick look at the tree right after the frontend reveals that indeed, something
fishy is going on.

Godbolt link: https://godbolt.org/z/TfnKb1fPT

[Bug tree-optimization/115383] [15 Regression] ICE with TCVC_2 build since r15-1053-g28edeb1409a7b8

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

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

--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Created attachment 58378 [details]
> patch
> 
> I'm testing this, but I do not have hardware to test correctness (and qemu
> not set up).

Thanks. I will test this on aarch64.

[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-07
   Keywords||diagnostic, wrong-code
 Ever confirmed|0   |1

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

[Bug middle-end/115388] [15 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-07
   Keywords||needs-bisection
  Component|tree-optimization   |middle-end
 Ever confirmed|0   |1
Summary|wrong code at -O3 on|[15 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/115383] [15 Regression] ICE with TCVC_2 build since r15-1053-g28edeb1409a7b8

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

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

--- Comment #6 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #5)
> (In reply to Richard Biener from comment #4)
> > Created attachment 58378 [details]
> > patch
> > 
> > I'm testing this, but I do not have hardware to test correctness (and qemu
> > not set up).
> 
> Thanks. I will test this on aarch64.

bootstrap and regression test passes. TSVC_2 also builds without any issues.

[Bug web/115391] New: Suggest add current size of git repository to git page

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 115391
   Summary: Suggest add current size of git repository to git page
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

On the web page for git (gcc.gnu.org/git.html),
it might be worth mentioning that the current git repository
for mainline is about 3 million objects and about 1.2 Gig in size.

This matters for those of us on slow internet connections when we do 

$ git clone  git://gcc.gnu.org/git/gcc.git trunk

when the messages from git get a bit cryptic and we have to start again
with a clean trunk.