[Bug c/109708] New: [c, doc] wdangling-pointer example broken

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

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

Bug ID: 109708
   Summary: [c, doc] wdangling-pointer example broken
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I ran into a Wdangling-pointer warning and decided to read the docs and try out
an example.

The first one listed is:
...
int f (int c1, int c2, x)
{
  char *p = strchr ((char[]){ c1, c2 }, c3);
  // warning: dangling pointer to a compound literal
  return p ? *p : 'x';
}
...

It's not a complete example, x is missing a declared type and c3 is undeclared. 

After fixing that (and adding the implicit "#include "), we have an
example that compiles:
...
#include 

int f (int c1, int c2, int c3)
{
  char *p = strchr ((char[]){ c1, c2 }, c3);
  return p ? *p : 'x';
}
...
but no warning, not at O0, O1, O2 or O3:
...
$ gcc test.c -Wdangling-pointer=1 -c
$
...

After reading the description of the warning, I managed to come up with:
...
char
f (char c1, char c2)
{
  char *p;

  {
p = (char[]) { c1, c2 };
  } 

  return *p;
}
...
which does manage to trigger the warning for O0-O3:
...
$ gcc test.c -Wdangling-pointer=1 -c
test.c: In function ‘f’:
test.c:10:10: warning: using dangling pointer ‘p’ to an unnamed temporary
[-Wdangling-pointer=]
   10 |   return *p;
  |  ^~
test.c:7:18: note: unnamed temporary defined here
7 | p = (char[]) { c1, c2 };
  |  ^
$
...

It might be worth mentioning that it's a C example, when using g++ we have:
...
$ g++ test.c -Wdangling-pointer=1 -c
test.c: In function ‘char f(char, char)’:
test.c:7:18: error: taking address of temporary array
7 | p = (char[]) { c1, c2 };
  |  ^~
...

BTW, note that the warning can be fixed by doing:
...
 char
 f (char c1, char c2)
 {
   char *p;
+  char c;

  {
p = (char[]) { c1, c2 };
+   c = *p;
  }

-  return *p;
+  return c;
}
...

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #8 from Mikael Morin  ---
(In reply to Andrew Macleod from comment #7)
> 
> diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
> index 49e9d6b4de6..74afaaf2989 100644
> --- a/gcc/gimple-range.cc
> +++ b/gcc/gimple-range.cc
> @@ -394,7 +394,9 @@ gimple_ranger::prefill_stmt_dependencies (tree ssa)
> Value_Range tmp (TREE_TYPE (name));
> m_cache.get_global_range (tmp, name);
> r.intersect (tmp);
> -   m_cache.set_global_range (name, r);
> +   // Only update the global range if it changes.
> +   if (r != tmp)
> + m_cache.set_global_range (name, r);
>   }
> continue;
>   }

Maybe the result of intersect could be used to check for changes?

if (tmp.intersect(r))
  ...

[Bug c/109708] [c, doc] wdangling-pointer example broken

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Warning-Options.html#index-Wdangling-pointer

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
vect_long_mult has
 || (([istarget powerpc*-*-*]
  && ![istarget powerpc-*-linux*paired*])
  && [check_effective_target_ilp32])
which does not know that p10 has 64x64->64 mult in vectors (and has weird
parens
as well :-P )  The linux*paired* case can be removed of course.

Confirmed.  Should we open a separate bug for this Power problem, or handle it
here?

[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).

[thomas.meltzer1 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Thomas Meltzer  ---
Thanks adding map(max_diff) works for me but my guess is that this should not
be required and there is a potential bug.

[Bug tree-optimization/109473] [10 Regression] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize since r10-4076-g82e8e335f917b9

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

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

--- Comment #10 from Jakub Jelinek  ---
The testcase fails for me in gcc 11 on both x86_64-linux and i686-linux
(--enable-checking=yes,rtl,extra):
+FAIL: gcc.dg/vect/pr109473.c (internal compiler error)
+FAIL: gcc.dg/vect/pr109473.c (test for excess errors)
+FAIL: gcc.dg/vect/pr109473.c -flto -ffat-lto-objects (internal compiler error)
+FAIL: gcc.dg/vect/pr109473.c -flto -ffat-lto-objects (test for excess errors)
/usr/src/gcc-11/gcc/testsuite/gcc.dg/vect/pr109473.c:7:6: internal compiler
error: in build_vector_from_val, at tree.c:1970
0x7cd0c6 build_vector_from_val(tree_node*, tree_node*)
../../gcc/tree.c:1970
0xd77c26 gimple_build_vector_from_val(gimple**, unsigned int, tree_node*,
tree_node*)
../../gcc/gimple-fold.c:8719
0x12fc798 gimple_build_vector_from_val(gimple**, tree_node*, tree_node*)
../../gcc/gimple-fold.h:142
0x12fc798 get_initial_def_for_reduction
../../gcc/tree-vect-loop.c:4765
0x12fc798 vect_transform_cycle_phi(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-loop.c:7681
0x12ece28 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:11012
0x13053f5 vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop.c:9633
0x1336a3c try_vectorize_loop_1
../../gcc/tree-vectorizer.c:1104
0x13376a1 vectorize_loops()
../../gcc/tree-vectorizer.c:1243

[Bug tree-optimization/109573] [11 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Jakub Jelinek  ---
The testcase fails for me in gcc 11 on both x86_64-linux and i686-linux
(--enable-checking=yes,rtl,extra):
+FAIL: g++.dg/vect/pr109573.cc  -std=c++20 (internal compiler error)
+FAIL: g++.dg/vect/pr109573.cc  -std=c++20 (test for excess errors)
+FAIL: g++.dg/vect/pr109573.cc  -std=c++2b (internal compiler error)
+FAIL: g++.dg/vect/pr109573.cc  -std=c++2b (test for excess errors)
/usr/src/gcc-11/gcc/testsuite/g++.dg/vect/pr109573.cc:81:6: internal compiler
error: in vectorizable_live_operation, at tree-vect-loop.c:8876
0x89f86d vectorizable_live_operation(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool,
vec*)
../../gcc/tree-vect-loop.c:8876
0x1593097 can_vectorize_live_stmts
../../gcc/tree-vect-stmts.c:10663
0x15b86d8 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:11047
0x15e92fd vect_schedule_slp_node
../../gcc/tree-vect-slp.c:6391
0x15f6441 vect_schedule_scc
../../gcc/tree-vect-slp.c:6553
0x15f61cf vect_schedule_scc
../../gcc/tree-vect-slp.c:6534
0x15f6a17 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
../../gcc/tree-vect-slp.c:6669
0x15f80b4 vect_slp_region
../../gcc/tree-vect-slp.c:5074
0x15f92ba vect_slp_bbs
../../gcc/tree-vect-slp.c:5186
0x15f96c4 vect_slp_function(function*)
../../gcc/tree-vect-slp.c:5272
0x16000c2 execute
../../gcc/tree-vectorizer.c:1450

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 3 May 2023, segher at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
> 
> Segher Boessenkool  changed:
> 
>What|Removed |Added
> 
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2023-05-03
> 
> --- Comment #2 from Segher Boessenkool  ---
> vect_long_mult has
>  || (([istarget powerpc*-*-*]
>   && ![istarget powerpc-*-linux*paired*])
>   && [check_effective_target_ilp32])
> which does not know that p10 has 64x64->64 mult in vectors (and has weird
> parens
> as well :-P )  The linux*paired* case can be removed of course.
> 
> Confirmed.  Should we open a separate bug for this Power problem, or handle it
> here?

Handle it here - the testcase this PR is about clearly lacks a
vect_long_mult requirement on the dump scanning but both aarch64 and
power seem to get that wrong so the fix wouldn't work.

[Bug tree-optimization/109693] trivial: unused private field

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:348788b19f55ce3a614b5c1ca6d2c46e0605e6b2

commit r14-420-g348788b19f55ce3a614b5c1ca6d2c46e0605e6b2
Author: Martin Liska 
Date:   Wed May 3 11:16:30 2023 +0200

clang warning: warning: private field 'm_gc' is not used
[-Wunused-private-field]

PR tree-optimization/109693

gcc/ChangeLog:

* value-range-storage.cc (vrange_allocator::vrange_allocator):
Remove unused field.
* value-range-storage.h: Likewise.

[Bug tree-optimization/109693] trivial: unused private field

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug c++/53932] [10/11 Regression] C++ reference variable to member of anonymous union in global is error

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

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

--- Comment #16 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64

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

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows

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

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

--- Comment #22 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug target/105554] [10 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE: in  |[10 Regression] ICE: in
   |emit_block_move_hints, at   |emit_block_move_hints, at
   |expr.cc:1829 since  |expr.cc:1829 since
   |r9-5509-g5928bc2ec06dd4e7   |r9-5509-g5928bc2ec06dd4e7

--- Comment #26 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug ipa/105685] [10 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] Bogus|[10 Regression] Bogus
   |`-Wsuggest-attribute=cold`  |`-Wsuggest-attribute=cold`
   |on function already marked  |on function already marked
   |as `__attribute__((cold))`  |as `__attribute__((cold))`

--- Comment #10 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug middle-end/106190] [10 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |expand_builtin_eh_common|expand_builtin_eh_common
   |with -fnon-call-exceptions  |with -fnon-call-exceptions
   |-fsanitize=address,undefine |-fsanitize=address,undefine
   |d -fno-sanitize-recover=all |d -fno-sanitize-recover=all

--- Comment #14 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug rtl-optimization/106751] [10 Regression] internal compiler error: in purge_dead_edges with inline-asm goto

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] internal |[10 Regression] internal
   |compiler error: in  |compiler error: in
   |purge_dead_edges with   |purge_dead_edges with
   |inline-asm goto |inline-asm goto

--- Comment #17 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug debug/106719] [10 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression]
   |'-fcompare-debug' failure   |'-fcompare-debug' failure
   |w/ -O2 since|w/ -O2 since
   |r10-6038-ge5e07b68187b9a|r10-6038-ge5e07b68187b9a

--- Comment #9 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug target/106875] [11 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug tree-optimization/109573] [11 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #11)
> The testcase fails for me in gcc 11 on both x86_64-linux and i686-linux
> (--enable-checking=yes,rtl,extra):
> +FAIL: g++.dg/vect/pr109573.cc  -std=c++20 (internal compiler error)
> +FAIL: g++.dg/vect/pr109573.cc  -std=c++20 (test for excess errors)
> +FAIL: g++.dg/vect/pr109573.cc  -std=c++2b (internal compiler error)
> +FAIL: g++.dg/vect/pr109573.cc  -std=c++2b (test for excess errors)
> /usr/src/gcc-11/gcc/testsuite/g++.dg/vect/pr109573.cc:81:6: internal
> compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8876
> 0x89f86d vectorizable_live_operation(vec_info*, _stmt_vec_info*,
> gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool,
> vec*)
> ../../gcc/tree-vect-loop.c:8876

Yep, I decided to backport the assert -> checking-assert change.  There's
no "good" way to handle the case we are running into.  On the branch we
run into an ADDR_EXPR.

As said with the original patch to trunk an option would be to remove the
assert alltogether, but not sure how important that would be.  It's still
interesting to see other cases we run into with this "FIXME" code path
(but as said, there's no good way to capture this particular case within
the assert).

[Bug c/107127] [11 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug middle-end/107317] [10 Regression] ICE in emit_redzone_byte, at asan.cc:1508

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |emit_redzone_byte, at   |emit_redzone_byte, at
   |asan.cc:1508|asan.cc:1508

--- Comment #11 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c/107465] [10 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] Bogus|[10 Regression] Bogus
   |warning: promoted bitwise   |warning: promoted bitwise
   |complement of an unsigned   |complement of an unsigned
   |value is always nonzero |value is always nonzero

--- Comment #17 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c++/107558] [10 Regression] ICE in fld_incomplete_type_of with -fmerge-all-constants and openmp and LTO since r11-16-ga2f32550a085984f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |fld_incomplete_type_of with |fld_incomplete_type_of with
   |-fmerge-all-constants and   |-fmerge-all-constants and
   |openmp and LTO since|openmp and LTO since
   |r11-16-ga2f32550a085984f|r11-16-ga2f32550a085984f

--- Comment #8 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

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

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

--- Comment #16 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug tree-optimization/108068] [10 Regression] decimal floating point signed zero is not honored

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] decimal  |[10 Regression] decimal
   |floating point signed zero  |floating point signed zero
   |is not honored  |is not honored

--- Comment #16 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c++/108180] [OpenMP] Passing a class member variable to firstprivate() erroneously calls its dtor

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

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug middle-end/108264] [11 Regression] ICE compiling guacamole-server on s390x-linux

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c++/108365] [10 Regression] Wrong code with -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] Wrong|[10 Regression] Wrong code
   |code with -O0   |with -O0

--- Comment #12 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug sanitizer/109700] ICE with address sanitizer after declaring __builtin_alloca since r8-1884-ge3174bdf35c172f

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE with address sanitizer  |ICE with address sanitizer
   |after declaring |after declaring
   |__builtin_alloca|__builtin_alloca since
   ||r8-1884-ge3174bdf35c172f

--- Comment #7 from Martin Liška  ---
(In reply to Andrew Pinski from comment #4)
> Most likely started with r8-1884-ge3174bdf35c172f (just like PR 104449 ). PR
> 104449  was supposed to fix part of this but it seems like it didn't.

Yes, started with r8-1884-ge3174bdf35c172f.

[Bug tree-optimization/109473] [10 Regression] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize since r10-4076-g82e8e335f917b9

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10737-gffb092784fc2513c2944253efc57c27de068c8b9
Author: Richard Biener 
Date:   Wed May 3 11:06:28 2023 +0200

tree-optimization/109473 - fix type mismatch in reduction vectorization

When backporting the PR109473 fix I failed to realize its testcase
will run into an unrelated similar bug.  With GCC 12 the code has
seen substantial refactoring so the following applies a local fix
to make sure we are using the correct types when building initial
values for reductions.

PR tree-optimization/109473
* tree-vect-loop.c (get_initial_def_for_reduction):
Convert the scalar values to the vector component type
before using it to build the vector for the initial value.

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:1133cfab47258c147fcb2d453465d10e72acbfd9

commit r14-422-g1133cfab47258c147fcb2d453465d10e72acbfd9
Author: Kyrylo Tkachov 
Date:   Wed May 3 11:15:34 2023 +0100

aarch64: PR target/99195 annotate simple floating-point patterns for
vec-concat with zero

Continuing the, almost mechanical, series this patch adds annotation for
some of the simple
floating-point patterns we have, and adds testing to ensure that redundant
zeroing instructions
are eliminated.

Bootstrapped and tested on aarch64-none-linux-gnu and also
aarch64_be-none-elf.

gcc/ChangeLog:

PR target/99195
* config/aarch64/aarch64-simd.md (add3): Rename to...
(add3): ... This.
(sub3): Rename to...
(sub3): ... This.
(mul3): Rename to...
(mul3): ... This.
(*div3): Rename to...
(*div3): ... This.
(neg2): Rename to...
(neg2): ... This.
(abs2): Rename to...
(abs2): ... This.
(2): Rename to...
(2): ... This.
(3): Rename to...
(3): ... This.
(*sqrt2): Rename to...
(*sqrt2): ... This.

gcc/testsuite/ChangeLog:

PR target/99195
* gcc.target/aarch64/simd/pr99195_1.c: Add testing for some unary
and binary floating-point ops.
* gcc.target/aarch64/simd/pr99195_2.c: New test.

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:12fae1f7fbe4df554bb257f805d9d324e276ab57

commit r14-423-g12fae1f7fbe4df554bb257f805d9d324e276ab57
Author: Kyrylo Tkachov 
Date:   Wed May 3 11:17:28 2023 +0100

aarch64: PR target/99195 annotate HADDSUB patterns for vec-concat with zero

Further straightforward patch for the various halving intrinsics with or
without rounding, plus tests.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.

gcc/ChangeLog:

PR target/99195
* config/aarch64/aarch64-simd.md (aarch64_h):
Rename to...
(aarch64_h): ... This.

gcc/testsuite/ChangeLog:

PR target/99195
* gcc.target/aarch64/simd/pr99195_1.c: Add tests for halving and
rounding
add/sub intrinsics.

[Bug other/109709] New: List of prerequisites should include that tar is required (not only for unpacking the source).

[me at manueljacob dot de via Gcc-bugs]

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

Bug ID: 109709
   Summary: List of prerequisites should include that tar is
required (not only for unpacking the source).
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: me at manueljacob dot de
  Target Milestone: ---

When tar is not installed, building GCC under Linux will fail, at least with
the default configuration.


The documentation says

GNU tar version 1.14 (or later)

Necessary (only on some platforms) to untar the source code.  Many systems' tar
programs will also work, only try GNU tar if you have problems.


It could be argued that this prerequisite should be left implicit, similar to
how it is not mentioned that e.g. the "cp" and "file" commands should be
present.

[Bug other/109709] List of prerequisites should include that tar is required (not only for unpacking the source).

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

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

--- Comment #1 from Richard Biener  ---
Huh, can you post how it fails?

[Bug tree-optimization/108498] [11 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #30 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug rtl-optimization/108596] [10 Regression] error: EDGE_CROSSING missing across section boundary

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] error:   |[10 Regression] error:
   |EDGE_CROSSING missing   |EDGE_CROSSING missing
   |across section boundary |across section boundary

--- Comment #11 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug middle-end/108685] [10 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |verify_loop_structure, at   |verify_loop_structure, at
   |cfgloop.cc:1748 since   |cfgloop.cc:1748 since
   |r13-2388-ga651e6d59188da|r13-2388-ga651e6d59188da

--- Comment #12 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug tree-optimization/108692] [11 Regression] Miscompilation of orc_test.c since r11-5160

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug debug/108716] [10 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression] Incorrect
   |Incorrect   |DW_AT_decl_{line,column} in
   |DW_AT_decl_{line,column} in |DW_TAG_imported_decl
   |DW_TAG_imported_decl|

--- Comment #7 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug middle-end/108854] [10 Regression] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281 since r10-4511-g6cf67b62c8cda035dccac

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression]
   |tbb-2021.8.0 fails on   |tbb-2021.8.0 fails on
   |i686-linux (32-bit),|i686-linux (32-bit),
   |internal compiler error: in |internal compiler error: in
   |expand_expr_real_1, at  |expand_expr_real_1, at
   |expr.c:10281 since  |expr.c:10281 since
   |r10-4511-g6cf67b62c8cda035d |r10-4511-g6cf67b62c8cda035d
   |ccac|ccac

--- Comment #18 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.

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

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

--- Comment #10 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug debug/108967] [11 Regression] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug testsuite/108973] [10 Regression] Sufficiently narrow terminal window causes selftest failure

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression]
   |Sufficiently narrow |Sufficiently narrow
   |terminal window causes  |terminal window causes
   |selftest failure|selftest failure

--- Comment #11 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c++/109710] New: OS X Lio : make failed -> ld: can't open -reexported_symbols_list file

[bug-reports.delphin at laposte dot net via Gcc-bugs]

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

Bug ID: 109710
   Summary: OS X Lio : make failed -> ld: can't open
-reexported_symbols_list file
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bug-reports.delphin at laposte dot net
  Target Milestone: ---

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

Hi !

Thank you for studying my make process for GCC/G++ under Lion (OS X). SO,
hereafter the main details given to "configure".

Mac OS X : Lion (10.7.5)
Hardware : Intel Core 2 Duo (X86_64)
Compiler(s) used : the ones downloaded (and built) from your web site (ftp).
Versions : 4.9 or 7.5 (successfully compiled and installed, usually working
very well).

Last suceesful GCC/G++ version compiled and installed : 11.3.0 (NB Later
versions failed).

Expected result : everything OK (NB Before I buy a new Mac computer).

Result obtained :
1/ configure passed (seen the log file)
2/ configure dispalyed the appropriate messages (see the log file)
3/ make fails. The message dispalyed is the following one (see the log
file) : 

lipo -output libgcc_s.1.1.dylib \
  -create libgcc_s.1.1.dylib_T*
rm libgcc_s.1.1.dylib_T*
MLIBS=`/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir/./gcc/xgcc
-B/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir/./gcc/
-B/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/bin/
-B/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/lib/
-isystem
/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/include
-isystem
/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/sys-include
  -fno-checking --print-multi-lib | sed -e 's/;.*$//'` ; \
for mlib in $MLIBS ; do \
  cp ../${mlib}/libgcc/${mlib}/libgcc_s.dylib  \
./libgcc_s.1.1.dylib_T_${mlib} || exit 1 ; \
  arch=`lipo -info libgcc_s.1.1.dylib_T_${mlib} | sed -e 's/.*:\ //'` ; \
  /Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir/./gcc/xgcc
-B/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir/./gcc/
-B/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/bin/
-B/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/lib/
-isystem
/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/include
-isystem
/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/x86_64-apple-darwin11.4.2/sys-include
  -fno-checking -arch ${arch} -nodefaultlibs -dynamiclib \
-o libgcc_s.1.dylib_T_${mlib} \
-Wl,-reexport_library,libgcc_s.1.1.dylib_T_${mlib} \
-lSystem \
   
-Wl,-reexported_symbols_list,/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Source/_13,1,x/gcc-13.1.0/libgcc/config/darwin-unwind.ver
\
-install_name
/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/lib/libgcc_s.1.dylib \
-compatibility_version 1 -current_version 1 ; \
done
ld: can't open -reexported_symbols_list file:
/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Source/_13
collect2: error: ld returned 1 exit status
my-make[3]: ***
[/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Source/_13,1,x/gcc-13.1.0/libgcc/config/t-slibgcc-darwin:139:
libgcc_s.1.dylib] Error 1
my-make[3]: Leaving directory
'/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir/x86_64-apple-darwin11.4.2/libgcc'
my-make[2]: *** [Makefile:19390: all-stage1-target-libgcc] Error 2
my-make[2]: Leaving directory
'/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir'
my-make[1]: *** [Makefile:25216: stage1-bubble] Error 2
my-make[1]: Leaving directory
'/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir'
my-make: *** [Makefile:1077: all] Error 2

Or, simply : 
ld: can't open -reexported_symbols_list file:
/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Source/_13
collect2: error: ld returned 1 exit status

Thank you !

Encl. 3 log (text) files

[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield

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

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c/109151] UBsan misses a divide-by-zero

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

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c++/109710] OS X Lio : make failed -> ld: can't open -reexported_symbols_list file

[bug-reports.delphin at laposte dot net via Gcc-bugs]

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

--- Comment #1 from bug-reports.delphin at laposte dot net ---
Created attachment 54975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54975&action=edit
Display of ./configure

[Bug tree-optimization/109176] [11 Regression] internal compiler error: in to_constant, at poly-int.h:504

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #22 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug target/109276] [11 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #23 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug c++/109710] OS X Lio : make failed -> ld: can't open -reexported_symbols_list file

[bug-reports.delphin at laposte dot net via Gcc-bugs]

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

--- Comment #2 from bug-reports.delphin at laposte dot net ---
Created attachment 54976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54976&action=edit
The error(s) output by make

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #9 from Martin Liška  ---
I've got a pretty nice reduced test-case:

$ cat pr109695.C
struct basic_string {
  basic_string(char *);
  ~basic_string();
};
struct {
  basic_string short_opt;
  basic_string long_opt;
  basic_string parameter;
  basic_string description;
} flatc_options[]{
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", ""};

$ g++ pr109695.C -c -Wno-write-strings
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

$ g++-13 pr109695.C -c -Wno-write-strings

[Bug ipa/109711] New: [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4

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

 (error_mark) in verify_range, at
value-range.cc:1060
0x6b8ed7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.cc:8949
0x120adbf tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.h:3663
0x120adbf irange::verify_range()
[...]

$ gcc (Gentoo 14.0.0. p, commit 490c1c096ca1d3a1f4a84801a46231d64c07ba49)
14.0.0 20230503 (experimental) 6313b0457394172b13978b9772d49eea1d68d3a1
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed for 11.4 and 12.3 as well (gcc 10 didn't support asm goto with outputs).

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords|needs-reduction |
   Last reconfirmed||2023-05-03
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I reduced that to:

$ cat pr109711.i
void lspf2lpc();

int interpolate_lpc_q_0;

void
interpolate_lpc(int subframe_num) {
  float weight;
  if (interpolate_lpc_q_0)
weight = subframe_num;
  else
weight = 1.0;
  if (weight != 1.0)
lspf2lpc();
}

void
qcelp_decode_frame() {
  int i;
  for (;; i++)
interpolate_lpc(i);
}

$ /dev/shm/objdir2/gcc/xgcc -B/dev/shm/objdir2/gcc pr109711.i -c -O2
during IPA pass: inline
pr109711.i:21:1: internal compiler error: tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060
   21 | }
  | ^
0x84dfd7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.cc:8949
0x85baff tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/tree.h:3663
0x85baff irange::verify_range()
/home/marxin/Programming/gcc/gcc/value-range.cc:1060
0x1279d97 irange::operator=(irange const&)
/home/marxin/Programming/gcc/gcc/value-range.cc:923
0xcd61a7 int_range<2u>::operator=(int_range<2u> const&)
/home/marxin/Programming/gcc/gcc/value-range.h:817
0xcd61a7 evaluate_conditions_for_known_args
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.cc:517
0xcee9c5 do_estimate_edge_size(cgraph_edge*)
/home/marxin/Programming/gcc/gcc/ipa-inline-analysis.cc:335
0xcf1465 estimate_edge_size(cgraph_edge*)
/home/marxin/Programming/gcc/gcc/ipa-inline.h:79
0xcf1465 estimate_edge_growth(cgraph_edge*)
/home/marxin/Programming/gcc/gcc/ipa-inline.h:100
0xcefe15 do_estimate_growth_1
/home/marxin/Programming/gcc/gcc/ipa-inline-analysis.cc:434
0xcefef6 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
/home/marxin/Programming/gcc/gcc/cgraph.h:3412
0xcefef6 estimate_growth(cgraph_node*)
/home/marxin/Programming/gcc/gcc/ipa-inline-analysis.cc:472
0x1d972c4 inline_small_functions
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:2042
0x1d972c4 ipa_inline
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:2811
0x1d972c4 execute
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:3210
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 c++/109712] New: Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 109712
   Summary: Segmentation fault in linear_search_fdes
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Created attachment 54978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54978&action=edit
Reproducible example

Hi!

We are bumping our GCC installation from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
07c52d1eec9671af92b7ce977b469f13a87887ad and are now getting a segmentation
fault when an exception is thrown, gdb points at "linear_search_fdes". Here's
the backtrace:

Thread 1 "a.out" received signal SIGSEGV, Segmentation fault.
linear_search_fdes (ob=0x7fffd690, this_fde=0x0, pc=0x404248 ) at
../../../gcc/libgcc/unwind-dw2-fde.c:969
969 ../../../gcc/libgcc/unwind-dw2-fde.c: No such file or directory.
(gdb) bt
#0  linear_search_fdes (ob=0x7fffd690, this_fde=0x0, pc=0x404248
) at ../../../gcc/libgcc/unwind-dw2-fde.c:969
#1  0x777c1e11 in find_fde_tail (dbase=18446744073709383432,
bases=0x7fffd8e8, hdr=0x4aaa34, pc=4211272) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:519
#2  _Unwind_Find_FDE (pc=, bases=bases@entry=0x7fffd8e8) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:573
#3  0x777bd4aa in uw_frame_state_for (context=0x7fffd840,
fs=0x7fffd930) at ../../../gcc/libgcc/unwind-dw2.c:1005
#4  0x777beefd in _Unwind_RaiseException (exc=0xcfc390) at
../../../gcc/libgcc/unwind.inc:104
#5  0x77bced8a in __cxa_throw () from
/home/s069/src/src/bazel-src/external/gcc_trunk_x86_64_linux/usr/lib64/libstdc++.so.6
#6  0x00404249 in foo () at ../main.cpp:8
#7  0x004042a7 in main () at ../main.cpp:18

I attach a reproducible example that I have tested on Ubuntu 20.04, it will
download dependencies and build the example project. It expects a "GCC_BASE"
variable to be set pointing to the base GCC installation.

I have made the following observations, so I'm not sure the problem is GCC, but
I thought nevertheless to share it in case someone has a good intuition for
what could be happening. If this is not the right forum please let me know
where I should ask!

* The problem happens only when linking libcudart_static.a. If I think
libcudart.so it's fine. I have asked this question at the Nvidia forums as
well, awaiting reply.
* The problem happens only when throwing exceptions.
* The problem happens only when using the Gold linker.
* The problem happens only if I use the GCC trunk's libstdc++.so and
libgcc_s.so at runtime (via rpath). If I use the Ubuntu 20.04 system-installed
libraries, it runs fine.

Thank you for your time!

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
Summary|[14 regression] ICE (tree   |[14 regression] ICE (tree
   |check: expected class   |check: expected class
   |‘type’, have ‘exceptional’  |‘type’, have ‘exceptional’
   |(error_mark) in |(error_mark) in
   |verify_range, at|verify_range, at
   |value-range.cc:1060) when   |value-range.cc:1060) when
   |building ffmpeg-4.4.4   |building ffmpeg-4.4.4 since
   ||r14-377-gc92b8be9b52b7e

--- Comment #2 from Martin Liška  ---
Started with r14-377-gc92b8be9b52b7e and it's not related to aarch64, can
reproduce on x86_64-linux-gnu as well.

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Hm, on x86_64-linux-gnu, it started with r13-6616-g2246d576f922ba.

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

--- Comment #4 from Sam James  ---
Slightly smaller:

```
void lspf2lpc();

void interpolate_lpc(int subframe_num) {
  float weight = 0.25 * subframe_num + 1;
  if (weight)
lspf2lpc();
}

void qcelp_decode_frame() {
  int i;
  for (;; i++)
interpolate_lpc(i);
}
```

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Can we either stop using int_range_max in functions which can be called
recursively, or invent some better representation for int_range_max (have first
8 or 16 ranges with wide_ints inline and rest dynamically allocated when really
needed)?
Because wide_int with wide_int_storage is not meant to have compact memory
footprint (e.g. for x86 target it is 80 bytes long) and having int_range_max
have 510 of these (40800 bytes) is simply too large on stack for one variable
even if no recursion is involved.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

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

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #7)
> The problem was exposed by the newly increased size of int_range_max.  (We
> may want to address that elsewhere)   It has grown an order of magnitude in
> size with wide-int.

Yes, 10 times.

[Bug target/109713] New: [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

Bug ID: 109713
   Summary: [14 Regression] gcc/config/riscv/sync.md:66:1: error:
control reaches end of non-void function
[-Werror=return-type] since r14-406-gbff7c773864479
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: patrick at rivosinc dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: riscv64-unknown-linux-gnu

Since the revision I see:

[ 5046s] ../../gcc/config/riscv/sync.md: In function 'const char*
output_479(rtx_def**, rtx_insn*)':
[ 5046s] ../../gcc/config/riscv/sync.md:66:1: error: control reaches end of
non-void function [-Werror=return-type]
[ 5046s]66 |   [(set (attr "length") (const_int 4))])
[ 5046s]   | ^
[ 5046s] cc1plus: some warnings being treated as errors

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

--- Comment #1 from Martin Liška  ---
The following generated code reports the warning:

static const char *
output_491 (rtx *operands ATTRIBUTE_UNUSED, rtx_insn *insn ATTRIBUTE_UNUSED)
{
#line 53 "/home/marxin/Programming/gcc/gcc/config/riscv/sync.md"
{
enum memmodel model = (enum memmodel) INTVAL (operands[1]);
model = memmodel_base (model);
if (model == MEMMODEL_SEQ_CST)
return "fence\trw,rw";
else if (model == MEMMODEL_ACQ_REL)
return "fence.tso";
else if (model == MEMMODEL_ACQUIRE)
return "fence\tr,rw";
else if (model == MEMMODEL_RELEASE)
return "fence\trw,w";
  }
}

[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-430-gcbf6c7a1d16490a1e63e9a5ce00e9a5c44c4c2f2
Author: Kefu Chai 
Date:   Mon May 1 21:24:26 2023 +0100

libstdc++: Set _M_string_length before calling _M_dispose() [PR109703]

This always sets _M_string_length in the constructor for ranges of input
iterators, such as stream iterators.

We copy from the source range to the local buffer, and then repeatedly
reallocate a larger one if necessary. When disposing the old buffer,
_M_is_local() is used to tell if the buffer is the local one or not (and
so must be deallocated). In addition to comparing the buffer address
with the local buffer, _M_is_local() has an optimization hint so that
the compiler knows that for a string using the local buffer, there is an
invariant that _M_string_length <= _S_local_capacity (added for PR109299
via r13-6915-gbf78b43873b0b7).  But we failed to set _M_string_length in
the constructor taking a pair of iterators, so the invariant might not
hold, and __builtin_unreachable() is reached. This causes UBsan errors,
and potentially misoptimization.

To ensure the invariant holds, _M_string_length is initialized to zero
before doing anything else, so that _M_is_local() doesn't see an
uninitialized value.

This issue only surfaces when constructing a string with a range of
input iterator, and the uninitialized _M_string_length happens to be
greater than _S_local_capacity, i.e., 15 for the std::string
specialization.

libstdc++-v3/ChangeLog:

PR libstdc++/109703
* include/bits/basic_string.h (basic_string(Iter, Iter, Alloc)):
Initialize _M_string_length.

Signed-off-by: Kefu Chai 
Co-authored-by: Jonathan Wakely 

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

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

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

--- Comment #12 from Jakub Jelinek  ---
Perhaps change int_range to have the wide_ints as auto_vec with reserved space
for a few (perhaps 3 (times 2))?

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

--- Comment #2 from Martin Liška  ---
So something like this can fix it:

diff --git a/gcc/config/riscv/sync.md b/gcc/config/riscv/sync.md
index ba132d8a1ce..206adcfec3c 100644
--- a/gcc/config/riscv/sync.md
+++ b/gcc/config/riscv/sync.md
@@ -61,6 +61,8 @@ (define_insn "mem_thread_fence_1"
return "fence\tr,rw";
 else if (model == MEMMODEL_RELEASE)
return "fence\trw,w";
+else
+gcc_unreachable ();
   }
   [(set (attr "length") (const_int 4))])

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-7282-gd50f2599d7b23bdba05a9102645d082ed9bcb05f
Author: Kefu Chai 
Date:   Mon May 1 21:24:26 2023 +0100

libstdc++: Set _M_string_length before calling _M_dispose() [PR109703]

This always sets _M_string_length in the constructor for ranges of input
iterators, such as stream iterators.

We copy from the source range to the local buffer, and then repeatedly
reallocate a larger one if necessary. When disposing the old buffer,
_M_is_local() is used to tell if the buffer is the local one or not (and
so must be deallocated). In addition to comparing the buffer address
with the local buffer, _M_is_local() has an optimization hint so that
the compiler knows that for a string using the local buffer, there is an
invariant that _M_string_length <= _S_local_capacity (added for PR109299
via r13-6915-gbf78b43873b0b7).  But we failed to set _M_string_length in
the constructor taking a pair of iterators, so the invariant might not
hold, and __builtin_unreachable() is reached. This causes UBsan errors,
and potentially misoptimization.

To ensure the invariant holds, _M_string_length is initialized to zero
before doing anything else, so that _M_is_local() doesn't see an
uninitialized value.

This issue only surfaces when constructing a string with a range of
input iterator, and the uninitialized _M_string_length happens to be
greater than _S_local_capacity, i.e., 15 for the std::string
specialization.

libstdc++-v3/ChangeLog:

PR libstdc++/109703
* include/bits/basic_string.h (basic_string(Iter, Iter, Alloc)):
Initialize _M_string_length.

Signed-off-by: Kefu Chai 
Co-authored-by: Jonathan Wakely 
(cherry picked from commit cbf6c7a1d16490a1e63e9a5ce00e9a5c44c4c2f2)

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
8 spaces -> tab.

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #3)
> 8 spaces -> tab.

May I commit it as obvious with the change?

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

--- Comment #5 from Jakub Jelinek  ---
Yes, preapproved.

[Bug other/109709] List of prerequisites should include that tar is required (not only for unpacking the source).

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-05-03
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Also the reason why it is listed explicitly for extraction is that the tar
files that are generated use gnu tar and use the gnu extensions for long file
names.

[Bug middle-end/106075] Wrong DSE with -fnon-call-exceptions

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

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

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

This patch fixes the testcase but it causes Ada and Go failures.  I've
isolated the Ada FAILs to the dse.cc change but then I'm not really into
this RTL optimization pass nor the pecularities of Ada (or Go).

=== acats tests ===
FAIL:   c37009a
FAIL:   c37208a
FAIL:   c41103a
FAIL:   c41103b
FAIL:   c41301a
FAIL:   c55c02b
FAIL:   c87b40a
FAIL:   cc1018a 

=== gnat tests ===


Running target unix/
FAIL: gnat.dg/opt47.adb execution test

=== go tests ===


Running target unix/
FAIL: go.go-torture/execute/names-1.go execution,  -O1
FAIL: go.go-torture/execute/names-1.go execution,  -O2
FAIL: go.go-torture/execute/names-1.go execution,  -O2 -fbounds-check
FAIL: go.go-torture/execute/names-1.go execution,  -O2 -fomit-frame-pointer
-finline-functions
FAIL: go.go-torture/execute/names-1.go execution,  -O2 -fomit-frame-pointer
-finline-functions -funroll-loops
FAIL: go.go-torture/execute/names-1.go execution,  -O3 -g
FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments
FAIL: go.test/test/235.go execution,  -O2 -g
FAIL: go.test/test/chan/sieve1.go execution,  -O2 -g
FAIL: go.test/test/chan/sieve2.go execution,  -O2 -g
FAIL: go.test/test/cmp.go execution,  -O2 -g
FAIL: go.test/test/complit.go execution,  -O2 -g
FAIL: go.test/test/ddd.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/bug187.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/bug204.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/bug447.go execution
FAIL: go.test/test/fixedbugs/bug465.dir/b.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/bug483.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue10925.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue14553.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue15528.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue16095.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue19113.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue22881.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue27836.dir/Ã~Dfoo.go  -O -I. (test for excess
errors)
FAIL: go.test/test/fixedbugs/issue27836.dir/Ã~Dmain.go  -O -I. (test for excess
errors)
FAIL: go.test/test/fixedbugs/issue39505b.go execution,  -O2 -g
FAIL: go.test/test/fixedbugs/issue4909b.go execution
FAIL: go.test/test/fixedbugs/issue5162.go execution
FAIL: go.test/test/fixedbugs/issue9604b.go execution
FAIL: go.test/test/ken/range.go execution,  -O2 -g
FAIL: go.test/test/slice3.go execution
FAIL: go.test/test/stringrange.go execution,  -O2 -g 
FAIL: go.test/test/utf.go execution,  -O2 -g 

(also gotools and libgo fails)

[Bug middle-end/106075] Wrong DSE with -fnon-call-exceptions

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
Eric, maybe you can help with RTL DSE here?

[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #8 from Marek Polacek  ---
Patch: 

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

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

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

--- Comment #13 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #12)
> Perhaps change int_range to have the wide_ints as auto_vec with reserved
> space for a few (perhaps 3 (times 2))?

Our original implementation was exactly that, but we switched to the current
one years ago (maybe it coincided with our switch back to trees, I can't
remember).  But yes, we're discussing options.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

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

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

--- Comment #14 from Jakub Jelinek  ---
I think even 4080 bytes for int_range_max was quite a lot.  I know it perhaps
simplifies stuff a little bit and hopefully copy construction/assignments only
copy the actual ranges and not the whole thing, but still.

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/109712] Segmentation fault in linear_search_fdes

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

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

--- Comment #1 from Richard Biener  ---
Does libcudart_static.a by chance contain any symbols from the libgcc runtime
(of an old toolchain)?

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

--- Comment #5 from Tamar Christina  ---
(In reply to Martin Liška from comment #3)
> Hm, on x86_64-linux-gnu, it started with r13-6616-g2246d576f922ba.

$ cat prtest2.c
void lspf2lpc();

int interpolate_lpc_q_0;

void
interpolate_lpc(int subframe_num) {
  float weight;
  if (interpolate_lpc_q_0)
weight = subframe_num;
  else
weight = 1.0;
  if (weight != 1.0)
lspf2lpc();
}

void
qcelp_decode_frame() {
  int i;
  for (;; i++)
interpolate_lpc(i);
}

$ ./install/bin/gcc --version
gcc (GCC) 13.0.1 20230312 (experimental)

$ git log -1
commit 2246d576f922bae3629da0fe1dbfcc6ff06769ad (HEAD)
Author: Tamar Christina 
Date:   Sun Mar 12 18:39:33 2023 +

middle-end: Revert can_special_div_by_const changes [PR108583]

This reverts the changes for the CAN_SPECIAL_DIV_BY_CONST hook.

gcc/ChangeLog:

PR target/108583
* doc/tm.texi (TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST): Remove.
* doc/tm.texi.in: Likewise.
* explow.cc (round_push, align_dynamic_address): Revert previous
patch.
* expmed.cc (expand_divmod): Likewise.
* expmed.h (expand_divmod): Likewise.
* expr.cc (force_operand, expand_expr_divmod): Likewise.
* optabs.cc (expand_doubleword_mod, expand_doubleword_divmod):
Likewise.
* target.def (can_special_div_by_const): Remove.
* target.h: Remove tree-core.h include
* targhooks.cc (default_can_special_div_by_const): Remove.
* targhooks.h (default_can_special_div_by_const): Remove.
* tree-vect-generic.cc (expand_vector_operation): Remove hook.
* tree-vect-patterns.cc (vect_recog_divmod_pattern): Remove hook.
* tree-vect-stmts.cc (vectorizable_operation): Remove hook.

$ ./install/bin/gcc -O2 -S -o - prtest2.c
.file   "prtest2.c"
.text
.p2align 4
.globl  interpolate_lpc
.type   interpolate_lpc, @function
interpolate_lpc:
.LFB0:
.cfi_startproc
movlinterpolate_lpc_q_0(%rip), %eax
testl   %eax, %eax
je  .L1
pxor%xmm0, %xmm0
cvtsi2ssl   %edi, %xmm0
ucomiss .LC0(%rip), %xmm0
jp  .L4
jne .L4
.L1:
ret
.p2align 4,,10
.p2align 3
...

Also that commit doesn't build because I forgot to cp tm.texi to the source
directory after the revert.

So I think the bisect probably didn't find it in that range.

https://godbolt.org/z/r44xGzarY indicates GCC 13.1 is fine.  So I don't think
this one is mine.

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |14.0

[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:04fbfafbd9657a36e8c3e80708a18fba08136854

commit r12-9508-g04fbfafbd9657a36e8c3e80708a18fba08136854
Author: Kefu Chai 
Date:   Mon May 1 21:24:26 2023 +0100

libstdc++: Set _M_string_length before calling _M_dispose() [PR109703]

This always sets _M_string_length in the constructor for ranges of input
iterators, such as stream iterators.

We copy from the source range to the local buffer, and then repeatedly
reallocate a larger one if necessary. When disposing the old buffer,
_M_is_local() is used to tell if the buffer is the local one or not (and
so must be deallocated). In addition to comparing the buffer address
with the local buffer, _M_is_local() has an optimization hint so that
the compiler knows that for a string using the local buffer, there is an
invariant that _M_string_length <= _S_local_capacity (added for PR109299
via r13-6915-gbf78b43873b0b7).  But we failed to set _M_string_length in
the constructor taking a pair of iterators, so the invariant might not
hold, and __builtin_unreachable() is reached. This causes UBsan errors,
and potentially misoptimization.

To ensure the invariant holds, _M_string_length is initialized to zero
before doing anything else, so that _M_is_local() doesn't see an
uninitialized value.

This issue only surfaces when constructing a string with a range of
input iterator, and the uninitialized _M_string_length happens to be
greater than _S_local_capacity, i.e., 15 for the std::string
specialization.

libstdc++-v3/ChangeLog:

PR libstdc++/109703
* include/bits/basic_string.h (basic_string(Iter, Iter, Alloc)):
Initialize _M_string_length.

Signed-off-by: Kefu Chai 
Co-authored-by: Jonathan Wakely 
(cherry picked from commit cbf6c7a1d16490a1e63e9a5ce00e9a5c44c4c2f2)

[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 12.3 and 13.2, thanks for the report.

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

--- Comment #6 from Tamar Christina  ---
my own bisect does indeed end up at r14-377-gc92b8be9b52b7e and cannot
reproduce it on GCC 13.

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #7 from Aldy Hernandez  ---
It looks like IPA is trying to set a range for a float even though value_range
does not support floats.  This worked before because legacy silently set a
range of error_mark_node.

[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b

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

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

--- Comment #8 from Aldy Hernandez  ---
Created attachment 54980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54980&action=edit
untested

This may fix it.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #41 from qinzhao at gcc dot gnu.org ---
my private gcc is able to use the element_count information in bound sanitizer
now:
[opc@qinzhao-ol8u3-x86 108896]$ cat t6.c
#include 
#include 
struct P {
  int k;
  int x[] __attribute__ ((element_count ("k")));
} *p;

void __attribute__ ((noinline)) store(int a, int b) 
{
  p = (struct P *)malloc (sizeof (struct P) + a * sizeof (int));
  p->k = a;
  return;
}

int main()
{
 store(7, 7);
 p->x[7] = 1;
}
[opc@qinzhao-ol8u3-x86 108896]$ sh t
/home/opc/Install/latest-d/bin/gcc -O -fsanitize=bounds-strict t6.c
t6.c:18:6: runtime error: index 7 out of bounds for type 'int [*]'
[opc@qinzhao-ol8u3-x86 108896]$

[Bug c/109714] New: bogus may be used uninitialized warning

[david at ixit dot cz via Gcc-bugs]

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

Bug ID: 109714
   Summary: bogus may be used uninitialized warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at ixit dot cz
  Target Milestone: ---
  Host: x86_64
Target: x86_64

Code: https://gitlab.freedesktop.org/mesa/mesa/ main branch
Compiler: 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb]
Compilation:
```
CC=/usr/lib/gcc-snapshot/bin/gcc CXX=/usr/lib/gcc-snapshot/bin/g++ meson setup
builddir-snapshot -D libdir=lib -D buildtype=release -D build-tests=false -D
enable-glcpp-tests=false -D libunwind=enabled -D glx=dri -D gbm=enabled -D
egl=enabled -D platforms=x11,wayland -D dri3=enabled -D gallium-extra-hud=true
-D gallium-vdpau=disabled -D gallium-omx=disabled -D gallium-va=disabled -D
gallium-xa=disabled -D gallium-nine=false -D gallium-opencl=disabled -D
gallium-rusticl=false -D llvm=enabled -D gallium-drivers=i915,iris,swrast -D
vulkan-drivers= -D video-codecs=h264dec,h264enc,h265dec,h265enc -D
spirv-to-dxil=false -D osmesa=true -D intel-clc=disabled -D
imagination-srv=false
```
```
[1110/1401] Compiling C object
src/gallium/auxiliary/libgallium.a.p/draw_draw_llvm.c.o
In function 'generate_clipmask',
inlined from 'draw_llvm_generate' at
../src/gallium/auxiliary/draw/draw_llvm.c:2163:24:
../src/gallium/auxiliary/draw/draw_llvm.c:1496:25: warning: 'sum' may be used
uninitialized [-Wmaybe-uninitialized]
 1496 |   sum = lp_build_fmuladd(builder, planes,
  | ^
 1497 |  (LLVMValueRef[]){cv_x, cv_y,
cv_z, cv_w}[i], sum);
  | 
~
../src/gallium/auxiliary/draw/draw_llvm.c: In function 'draw_llvm_generate':
../src/gallium/auxiliary/draw/draw_llvm.c:1343:44: note: 'sum' was declared
here
 1343 |LLVMValueRef plane1, planes, plane_ptr, sum;
  | 
```

The code (relevant to the sum variable):
```
...
   LLVMValueRef plane1, planes, plane_ptr, sum;
...
for (int i = 0; i < 4; ++i) {
   indices[2] = lp_build_const_int32(gallivm, i);
   plane_ptr = LLVMBuildGEP2(builder, planes_type, planes_ptr,
indices, 3, "");
   plane1 = LLVMBuildLoad2(builder, vs_elem_type, plane_ptr,
   (const char *[]){"plane_x", "plane_y",
"plane_z", "plane_w"}[i]);
   planes = lp_build_broadcast(gallivm, vs_type_llvm, plane1);
   if (i == 0) {
  sum = LLVMBuildFMul(builder, planes, cv_x, ""); // sum is set
always in first iteration
   } else {
  // we never get here without having sum already assigned
  sum = lp_build_fmuladd(builder, planes,
 (LLVMValueRef[]){cv_x, cv_y, cv_z,
cv_w}[i], sum);
   }
}
...
```

Thou the `sum` value is always assigned in first for interation.

I tried do simple test case, but it always works with simple c file.

[Bug c++/109715] New: abi_tag attribute is not applied to variable templates

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 109715
   Summary: abi_tag attribute is not applied to variable templates
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Given:

template 
[[gnu::abi_tag("ABI")]] inline int value = 0;

int get() {
return value;
}

gcc mangles the variable value as _Z5valueIiE, instead of
_Z5valueB3ABIIiE. That is, there is no "[abi:ABI]" tag.

clang does propagate this attribute as expected.

gcc does include the abi_tag in the mangling in other template cases (static
data member of a class template, static local variable of a function template,
etc.)

This is a related (but, I'm guessing, much easier) problem to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #15 from Andrew Macleod  ---
(In reply to Mikael Morin from comment #8)
> (In reply to Andrew Macleod from comment #7)
> > 
> > diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
> > index 49e9d6b4de6..74afaaf2989 100644
> > --- a/gcc/gimple-range.cc
> > +++ b/gcc/gimple-range.cc
> > @@ -394,7 +394,9 @@ gimple_ranger::prefill_stmt_dependencies (tree ssa)
> >   Value_Range tmp (TREE_TYPE (name));
> >   m_cache.get_global_range (tmp, name);
> >   r.intersect (tmp);
> > - m_cache.set_global_range (name, r);
> > + // Only update the global range if it changes.
> > + if (r != tmp)
> > +   m_cache.set_global_range (name, r);
> > }
> >   continue;
> > }
> 
> Maybe the result of intersect could be used to check for changes?
> 
> if (tmp.intersect(r))
>   ...

Yes, my next iteration of the patch did just that..  

however, its still not quite right, theres a ripple effect with the way we
handle timestamps. the first time a name is processed, we set an "always
current" timestamp until we resolve all the dependencies and get back to it to
calculate a real value.  If the initial value and the calculated value ends up
being the same, the current fix won't clear the always-current timestamp..

still working on it.

[Bug c/109716] New: bogus stringop-overread "reading 4 bytes from a region of size 0"

[david at ixit dot cz via Gcc-bugs]

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

Bug ID: 109716
   Summary: bogus stringop-overread "reading 4 bytes from a region
of size 0"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at ixit dot cz
  Target Milestone: ---
  Host: x86_64
Target: x86_64

Compiler: 12.2.0, 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb]
Sources: https://gitlab.freedesktop.org/mesa/mesa/ main branch, (commit
b59935e2e77ed6ccf210103b028d671ee277a607 )
Command: CC=/usr/lib/gcc-snapshot/bin/gcc CXX=/usr/lib/gcc-snapshot/bin/g++
meson setup builddir-snapshot -D libdir=lib -D buildtype=release -D
build-tests=false -D enable-glcpp-tests=false -D libunwind=enabled -D glx=dri
-D gbm=enabled -D egl=enabled -D platforms=x11,wayland -D dri3=enabled -D
gallium-extra-hud=true -D gallium-vdpau=disabled -D gallium-omx=disabled -D
gallium-va=disabled -D gallium-xa=disabled -D gallium-nine=false -D
gallium-opencl=disabled -D gallium-rusticl=false -D llvm=enabled -D
gallium-drivers=r300,i915,iris,swrast -D vulkan-drivers=panfrost -D
video-codecs=h264dec,h264enc,h265dec,h265enc -D spirv-to-dxil=false -D
osmesa=true -D intel-clc=disabled -D imagination-srv=false
```
[1447/1646] Compiling C object
src/gallium/drivers/r300/libr300.a.p/r300_state_derived.c.o
../src/gallium/drivers/r300/r300_state_derived.c: In function
'r300_get_border_color':
../src/gallium/drivers/r300/r300_state_derived.c:676:5: warning:
'util_format_unswizzle_4f' reading 4 bytes from a region of size 0
[-Wstringop-overread]
  676 | util_format_unswizzle_4f(border_swizzled, border, desc->swizzle);
  | ^~~~
../src/gallium/drivers/r300/r300_state_derived.c:676:5: note: referencing
argument 3 of type 'const unsigned char[4]'
In file included from ../src/compiler/nir/nir.h:43,
 from ../src/gallium/auxiliary/draw/draw_context.h:42,
 from ../src/gallium/drivers/r300/r300_state_derived.c:24:
../src/util/format/u_format.h:1684:6: note: in a call to function
'util_format_unswizzle_4f'
 1684 | void util_format_unswizzle_4f(float *dst, const float *src,
  |  ^~~~
```

Our project bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8651

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:4bd434fbfc7865961a8e10d7e9601b28765ce7be

commit r14-432-g4bd434fbfc7865961a8e10d7e9601b28765ce7be
Author: Martin Liska 
Date:   Wed May 3 16:35:26 2023 +0200

riscv: fix error: control reaches end of non-void function

Fixes:
gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void
function [-Werror=return-type]
66 |   [(set (attr "length") (const_int 4))])
   | ^

PR target/109713

gcc/ChangeLog:

* config/riscv/sync.md: Add gcc_unreachable to a switch.

[Bug target/109713] [14 Regression] gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] since r14-406-gbff7c773864479

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed now.

[Bug target/108270] un-optimal vsetvl for multi-loop if avl is 0 ~ 31 immediate

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #3 from JuzheZhong  ---
Fixed

[Bug libstdc++/105844] [10/11 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-10739-g7c31a9c66269805d57591549edb031f84d84f9b0
Author: Jonathan Wakely 
Date:   Fri Jun 10 14:39:13 2022 +0100

libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]

When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(5, 4) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.

To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(50u, 49u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.

libstdc++-v3/ChangeLog:

PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.

(cherry picked from commit 671970a5621e18e7079b4ca113e56434c858db66)

[Bug libstdc++/92978] std::gcd mishandles mixed-signedness

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-10739-g7c31a9c66269805d57591549edb031f84d84f9b0
Author: Jonathan Wakely 
Date:   Fri Jun 10 14:39:13 2022 +0100

libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]

When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(5, 4) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.

To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(50u, 49u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.

libstdc++-v3/ChangeLog:

PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.

(cherry picked from commit 671970a5621e18e7079b4ca113e56434c858db66)

[Bug modula2/109675] GCC 13.1: the Modula-2 front-end fails to build on some platforms

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 54981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54981&action=edit
Proposed fix

Here is a proposed patch, writeAddress is re-implemented and as a result the
support tools mc and pge have been rebuilt.  I'm currently bootstrapping on
multiple targets - once complete and if no problems develop the patch will be
applied.  Thanks for the bug report!

[Bug libstdc++/105844] [10/11 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-10740-gad076469c00af1fbe2f848844ab5937587772a70
Author: Jonathan Wakely 
Date:   Wed May 3 16:05:23 2023 +0100

libstdc++: Fix broken backport for std::lcm [PR105844]

The backport for gcc-11 was incomplete and should have replaced all uses
of std::__is_constant_evaluated with __builtin_is_constant_evaluated.

We also need to prune some additional output for the new tests, because
the r12-4425-g1595fe44e11a96 change to always prune those lines is not
present on the branch.

libstdc++-v3/ChangeLog:

PR libstdc++/105844
* include/experimental/numeric (lcm): Use built-in instead of
__is_constant_evaluated.
* include/std/numeric (__abs_r, lcm): Likewise.
* testsuite/26_numerics/gcd/105844.cc: Add dg-prune-output.
* testsuite/26_numerics/lcm/105844.cc: Likewise.

[Bug libgomp/106045] Incorrect testcase in libgomp.c/target-31.c at -O0

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

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

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

https://gcc.gnu.org/g:58c396a2ce4f8f66e6c379d74e834e3c8d93f36b

commit r10-11331-g58c396a2ce4f8f66e6c379d74e834e3c8d93f36b
Author: Jakub Jelinek 
Date:   Tue Jun 21 17:51:08 2022 +0200

libgomp: Fix up target-31.c test [PR106045]

The i variable is used inside of the parallel in:
  #pragma omp simd safelen(32) private (v)
  for (i = 0; i < 64; i++)
{
  v = 3 * i;
  ll[i] = u1 + v * u2[0] + u2[1] + x + y[0] + y[1] + v + h[0] +
u3[i];
}
where i is predetermined linear (so while inside of the body
it is safe, private per SIMD lane var) the final value is written to
the shared variable, and in:
  for (i = 0; i < 64; i++)
if (ll[i] != u1 + 3 * i * u2[0] + u2[1] + x + y[0] + y[1] + 3 * i +
13 + 14 + i)
  #pragma omp atomic write
err = 1;
which is a normal loop and so it isn't in any way privatized there.
So we have a data race, fixed by adding private (i) clause to the
parallel.

2022-06-21  Jakub Jelinek  
Paul Iannetta  

PR libgomp/106045
* testsuite/libgomp.c/target-31.c: Add private (i) clause.

(cherry picked from commit 85d613da341b76308edea48359a5dbc7061937c4)

[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:89741783f6e7127d4d8be5a5e8e4fb7d5785f8a6

commit r10-11332-g89741783f6e7127d4d8be5a5e8e4fb7d5785f8a6
Author: Jakub Jelinek 
Date:   Tue Jun 21 11:38:59 2022 +0200

expand: Fix up expand_cond_expr_using_cmove [PR106030]

If expand_cond_expr_using_cmove can't find a cmove optab for a particular
mode, it tries to promote the mode and perform the cmove in the promoted
mode.

The testcase in the patch ICEs on arm because in that case we pass temp
which
has the promoted mode (SImode) as target to expand_operands where the
operands have the non-promoted mode (QImode).
Later on the function uses paradoxical subregs:
  if (GET_MODE (op1) != mode)
op1 = gen_lowpart (mode, op1);

  if (GET_MODE (op2) != mode)
op2 = gen_lowpart (mode, op2);
to change the operand modes.

The following patch fixes it by passing NULL_RTX as target if it has
promoted mode.

2022-06-21  Jakub Jelinek  

PR middle-end/106030
* expr.c (expand_cond_expr_using_cmove): Pass NULL_RTX instead of
temp to expand_operands if mode has been promoted.

* gcc.c-torture/compile/pr106030.c: New test.

(cherry picked from commit 2df1df945fac85d7b3d084001414a66a2709d8fe)