[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368) since r15-80-g0ade358cd72ffa

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15 regression] ICE when|[15 regression] ICE when
   |building reiser4progs   |building reiser4progs
   |(propagate_updated_value,   |(propagate_updated_value,
   |at  |at
   |gimple-range-cache.cc:1368) |gimple-range-cache.cc:1368)
   ||since
   ||r15-80-g0ade358cd72ffa

--- Comment #8 from Sam James  ---
I went ahead and did it - r15-80-g0ade358cd72ffa.

[Bug lto/115223] [15 regression] ICE when building KDE kontrast with LTO (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)

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

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

--- Comment #1 from Sam James  ---
Reduced:
```
using type = void;
template  void checkSwap(T &t) noexcept(noexcept(t));
void qSwap(int value1) noexcept(noexcept(checkSwap(value1)));
type callDestructorIfNecessary(int &) noexcept {}
```

As usual, my C++ is lacking, so it might be possible to tidy this up.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #5 from Harald van Dijk  ---
I end up with a different reduced test case that does not involve unions:

template  _Tp declval() noexcept;

template 
inline constexpr bool is_nothrow_destructible_v = noexcept(declval<_Tp>());

struct A { ~A() noexcept(false) = delete; };
struct B : A { ~B(); };
static_assert(is_nothrow_destructible_v);

The assertion passes in GCC, fails in clang, but I think clang is right here.
It looks like GCC ignores the deleted destructor for determining whether B's
destructor should be implicitly noexcept, but the wording that Andrew Pinski
referenced in comment #2 says B's destructor is potentially throwing "if any of
the destructors for any of its potentially constructed subobjects has a
potentially-throwing exception specification" without regard to whether those
destructors are deleted.

[Bug tree-optimization/115225] New: [11/12/13/14 Regression] signed integer overflow check missing with optimization

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 115225
   Summary: [11/12/13/14 Regression] signed integer overflow check
missing with optimization
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

OS: Ubuntu 22.04.3 LTS

UBSAN missed checking signed integer overflow when compiling with gcc-11.4.0,
gcc-12.3.0, gcc-13.2.0, gcc-14.1.0 at optimization levels -O1, -O2, -O3, and
-Os.
With optimizer, does UBSAN check signed integer overflow?

$ ../compiler-builds/gcc-13.2.0_build/bin/gcc -fsanitize=undefined -g -lgcc_s
-I/home/csmith/include/csmith-2.3.0 -O0 testcase.c -o exec

$ timeout 1s ./exec 2>exec.err
testcase.c:7:5: runtime error: signed integer overflow: 1932174879 * 2 cannot
be represented in type 'int'

$ ../compiler-builds/gcc-12.3.0_build/bin/gcc -fsanitize=undefined -g -lgcc_s
-I/home/csmith/include/csmith-2.3.0 -O1 testcase.c -o exec

$ timeout 1s ./exec 2>exec.err

[Bug tree-optimization/115225] [11/12/13/14 Regression] signed integer overflow check missing with optimization

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

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

--- Comment #1 from Andrew Pinski  ---
The code is all dead. I can't remember for sure but I this is correct behavior
as the undefined code has no effects seen at all.

[Bug tree-optimization/115226] New: ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed

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

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

Bug ID: 115226
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
verify_ssa failed
   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: ---

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

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


[538] % 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 20240525 (experimental) (GCC) 
[539] % 
[539] % gcctk -O3 small.c 
small.c: In function ‘main’:
small.c:3:5: error: stmt with wrong VUSE
3 | int main() {
  | ^~~~
# .MEM_4 = VDEF <.MEM_15>
a = 0;
expected .MEM_2
during GIMPLE pass: unswitch
small.c:3:5: internal compiler error: verify_ssa failed
0x140b2be verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.cc:1203
0x102deb5 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2096
0x102e71e execute_todo
../../gcc-trunk/gcc/passes.cc:2143
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.
[540] % 
[540] % cat small.c
extern void c();
int a, b;
int main() {
  while (b) {
int d, e = 0, *f = &a;
*f = 1;
e = 1 >> d ? : 1 << d;
if (e)
  a = 0;
c();
  }
  return 0;
}

[Bug c++/115223] [15 regression] ICE when building KDE kontrast with LTO (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’) since r15-779-g3c98d06a9016a0

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15 regression] ICE when|[15 regression] ICE when
   |building KDE kontrast with  |building KDE kontrast with
   |LTO (error: |LTO (error:
   |‘TYPE_CANONICAL’ has|‘TYPE_CANONICAL’ has
   |different ‘TYPE_CANONICAL’) |different ‘TYPE_CANONICAL’)
   ||since
   ||r15-779-g3c98d06a9016a0
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
  Component|lto |c++

--- Comment #2 from Sam James  ---
r15-779-g3c98d06a9016a0

[Bug c/115227] New: [15 Regression] i686-linux fails frequently with cc1: out of memory allocating x bytes after a total of ~4GB

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

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

Bug ID: 115227
   Summary: [15 Regression] i686-linux fails frequently with cc1:
out of memory allocating x bytes after a total of ~4GB
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58286
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58286&action=edit
bug.c.c.xz

Initially noticed on libepoxy, doxygen, llvm, p11-kit. They all fail to build
by 32-bit gcc-15. The symptoms are similar: 4GB limit is hit and `gcc` fails on
allocation.

Attached preprocessed and compressed example of libepoxy:

$ gcc-15 -std=gnu99 -fno-strict-aliasing -fvisibility=hidden  -c bug.c.c -o
bug.o -O2
cc1: out of memory allocating 65536 bytes after a total of 3774660608 bytes

For comparison gcc-13 is able to survive:

$ gcc-13 -std=gnu99 -fno-strict-aliasing -fvisibility=hidden  -c bug.c.c -o
bug.o -O2


$ gcc-15 -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-15.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-15.0.0/libexec/gcc/i686-unknown-linux-gnu/15.0.0/lto-wrapper
Target: i686-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-15.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.39-52-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<>/gcc-15.0.0/include/c++/15.0.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--with-arch=i686 --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
--target=i686-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0  (experimental) (GCC)

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #5 from Andreas Schwab  ---
*** Bug 115227 has been marked as a duplicate of this bug. ***

[Bug c/115227] [15 Regression] i686-linux fails frequently with cc1: out of memory allocating x bytes after a total of ~4GB

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
dup

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

[Bug tree-optimization/115228] New: Suspicious code in tree-vect-data-refs.cc

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Bug ID: 115228
   Summary: Suspicious code in tree-vect-data-refs.cc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

Does the below condition code miss the case of "SAD_EXPR", in function
vect_get_smallest_scalar_type():

  if (assign)
{
  scalar_type = TREE_TYPE (gimple_assign_lhs (assign));
  if (gimple_assign_cast_p (assign)
  || gimple_assign_rhs_code (assign) == DOT_PROD_EXPR
  || gimple_assign_rhs_code (assign) == WIDEN_SUM_EXPR
  || gimple_assign_rhs_code (assign) == WIDEN_MULT_EXPR
  || gimple_assign_rhs_code (assign) == WIDEN_LSHIFT_EXPR
  || gimple_assign_rhs_code (assign) == FLOAT_EXPR)

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

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

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

--- Comment #6 from YunQiang Su  ---
The attached patch cannot work now.

It is not correct, and it happened work due to good luck that the same register
was allocated for these 2 instructions.

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Andrew Macleod  ---
Created attachment 58287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58287&action=edit
proposed patch

I'm testing this patch, does it resolve your problem?

I forgot to free the gori_nmap object when the companion gori object was freed.
 doh.

[Bug preprocessor/88424] Inserts newlines when preserving comments for a file using Windows newlines

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #3 from Peter Damianov  ---
Looking in a hex editor, what gcc is doing is changing the CRLF to LFLF, there
is no CR in the output.

  /* If the file is using old-school Mac line endings (\r only),
 terminate with another \r, not an \n, so that we do not mistake
 the \r\n sequence for a single DOS line ending and erroneously
 issue the "No newline at end of file" diagnostic.  */
  if (to.len && to.text[to.len - 1] == '\r')
to.text[to.len] = '\r';
  else
to.text[to.len] = '\n';

I noticed this code, but commenting it out makes the compiler fail selftests.

I'll keep looking to see if I can find the code responsible for doing that.

[Bug preprocessor/88424] Inserts newlines when preserving comments for a file using Windows newlines

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #4 from Peter Damianov  ---
All of the non-commments are turned to LF line endings.

So it must be something specifically to do with comment processing.

[Bug c++/115229] New: inconsistent `error: possibly dangling reference to a temporary`

[pobrn at protonmail dot com via Gcc-bugs]

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

Bug ID: 115229
   Summary: inconsistent `error: possibly dangling reference to a
temporary`
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pobrn at protonmail dot com
  Target Milestone: ---

Consider the following piece of C++ code:

```
struct A {
int q;
int *p;
};

struct B {
A value_or() {
return A {};
}
};

B f();

void test() {
const auto& x = f().value_or();
}
```

gcc 15, 14 show the following diagnostic:

```
: In function 'void test()':
:15:21: error: possibly dangling reference to a temporary
[-Werror=dangling-reference]
   15 | const auto& x = f().value_or();
  | ^
:15:37: note: the temporary was destroyed at the end of the full
expression 'f().B::value_or()'
   15 | const auto& x = f().value_or();
  | ^~
```

while gcc 13 does not.

Could someone help me understand why this warning is even shown? I would assume
lifetime extension should extend the lifetime of the returned value as needed.

Note that removing `int *p` from `A` makes the warning go away, so I am not
sure if this warning has anything to do with the lifetime of the returned
value, but then I am confused why the error points to `x`.

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

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

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

--- Comment #23 from Alexander Monakov  ---
(In reply to Sergei Trofimovich from comment #22)
> Here `pcmpeqd %xmm2,%xmm1` is a problematic instruction. Why does `gcc` use
> `%xmm2` (result of `cvttps2dq`) instead of, say `%xmm0` which contains
> `0x` pattern?

%xmm0 contains the first all-ones argument to assert_eq. The comparison needs
to happen against a register that contains 0x7fff_ (x4), and GCC "thinks"
that %xmm2 contains that value. At -O1, the optimization is done by the RTL CSE
pass (you can confirm by switching it off with -fdisable-rtl-cse1 along -O1),
it sees

(insn 6 5 7 2 (set (reg:V4SF 97)
(mem/u/c:V4SF (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0  S16 A128]))
"/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/xmmintrin.h":386:19 1335
{movv4sf_internal}
 (expr_list:REG_EQUAL (const_vector:V4SF [
(const_double:SF 4.294967296e+9 [0x0.8p+33]) repeated x4
])
(nil)))

(insn 10 9 11 2 (set (reg:V4SI 98)
(fix:V4SI (reg:V4SF 97)))
"/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/emmintrin.h":832:19 2635
{fix_truncv4sfv4si2}
 (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 2147483647 [0x7fff]) repeated x4
])
(expr_list:REG_DEAD (reg:V4SF 99)
(nil

Note the incorrect REG_EQUAL caused by inappropriate use of fix:V4SI where the
source code had cvttps2dq.

[Bug ipa/109914] --suggest-attribute=pure misdiagnoses static functions

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #4 from Paul Eggert  ---
(In reply to Jan Hubicka from comment #2)
> The reason why gcc warns is that it is unable to prove that the function is
> always finite.

I don't see why finiteness matters. If a pure function returns the first time
it's called, and if there's no change to visible state after that, it should
return the second time with the same value. And if the pure function didn't
return the first time evaluation won't even get to the second time. So common
subexpression elimination (which is the point of 'pure') will work even if a
pure function does not return.

C23 has standardized this stuff with the [[reproducible]] attribute, and as far
as I can see (the wording is admittedly murky) C23 does not impose a finiteness
constraint on reproducible functions. If my reading of C23 is correct, GCC
should not impose finiteness constraints on reproducible functions when it gets
around to implementing [[reproducible]], and if [[reproducible]] and
__attribute__((pure)) are supposed to be the same thing then GCC should drop
the  finiteness constraint on pure functions as well.


I agree with Bruno's main point that none of this stuff should matter for
static functions. --suggest-attribute=* warnings are useless chatter for static
functions.


(I ran into this GCC bug when building recent versions of the TZDB code, which
is why I found this bug report.)

[Bug preprocessor/88424] Inserts newlines when preserving comments for a file using Windows newlines

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #5 from Peter Damianov  ---
I checked clang's behavior, and it does CRLF -> LF from non-comments, but it
leaves them intact in comments. I'm not really sure if this behavior is worth
emulating or not. I think it would be better to remove the CR from the CRLF in
comments too.

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

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

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

--- Comment #24 from Sergei Trofimovich  ---
Thank you, Alexander! Tricky `REG_EQUAL` makes sense.

[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components

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

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

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

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

commit r14-10244-gb0b21d5bdfbc7d417b70010a11354b44968bb184
Author: Harald Anlauf 
Date:   Mon May 13 22:06:33 2024 +0200

Fortran: fix bounds check for assignment, class component [PR86100]

gcc/fortran/ChangeLog:

PR fortran/86100
* trans-array.cc (gfc_conv_ss_startstride): Use abridged_ref_name
to generate a more user-friendly name for bounds-check messages.
* trans-expr.cc (gfc_copy_class_to_class): Fix bounds check for
rank>1 by looping over the dimensions.

gcc/testsuite/ChangeLog:

PR fortran/86100
* gfortran.dg/bounds_check_25.f90: New test.

(cherry picked from commit 93765736815a049e14d985b758a213cfe60c1e1c)

[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314

[natalie.perlin at noaa dot gov via Gcc-bugs]

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

--- Comment #15 from Natalie Perlin  ---
Quick update: 

Software stack and model build with gnu/13.3.0 was clear from all previous
issues! So issue with the gnu/13.x.0 compiler could be considered as fixed,
thank you so much for the help here. 


Build with gnu/14.1.0 generated more ICEs, however. 
FYI, the compiler errors looked as following:

-
...register_variable_attribute.inc:56:60:

internal compiler error: in gfc_walk_array_ref, at fortran/trans-array.cc:11870
0x75dffb gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*)
../../gcc/fortran/trans-array.cc:11870
0x8d5f90 gfc_walk_expr(gfc_expr*)
../../gcc/fortran/trans-array.cc:12232
0x75dffb gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*)
../../gcc/fortran/trans-array.cc:11870
0x8d5f90 gfc_walk_expr(gfc_expr*)
../../gcc/fortran/trans-array.cc:12232
0x8fb2c8 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:6578
0x8fb2c8 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:6578
0x90c46a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9979
0x8fd2f4 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:6756
0x90f4b8 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.cc:12287
0x90c46a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9979
0x8fd2f4 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:6756
0x90f4b8 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.cc:12287
0x8c3897 trans_code
...
... (more diagnostic prints)
...
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.
0x8657ad translate_all_program_units
../../gcc/fortran/parse.cc:7086
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-15, and backported to 14-branch.  Closing.

Thanks for the report, and sorry that it took so long to fix.

[Bug fortran/27766] [meta-bug] -fbounds-check related bugs

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

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

Bug 86100 Summary: Spurious error with -fcheck=bounds and allocatable class(*) 
array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100

   What|Removed |Added

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

[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-15.

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

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

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

--- Comment #7 from Sergei Trofimovich  ---
(In reply to Andrew Macleod from comment #6)
> Created attachment 58287 [details]
> proposed patch
> 
> I'm testing this patch, does it resolve your problem?
> 
> I forgot to free the gori_nmap object when the companion gori object was
> freed.  doh.

At least for me that fixed the crash when building libepoxy, doxygen and
p11-kit on i686-linux. Thank you!

[Bug c++/115229] inconsistent `error: possibly dangling reference to a temporary`

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

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

--- Comment #1 from Andrew Pinski  ---
>Could someone help me understand why this warning is even shown?

The lifetime of the temporary (of type B) returned from f is at the end of the
full expression. B::value_or's return in theory could have a reference to this
(in this case it is not but GCC does not do any analaysis of B::value_or to see
that).

[Bug c++/115229] inconsistent `error: possibly dangling reference to a temporary`

[pobrn at protonmail dot com via Gcc-bugs]

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

--- Comment #2 from Barnabás Pőcze  ---
So because `A::p` might point into the temporary of type `B` returned by `f()`,
the warning is shown? If so, why don't I get a warning if `x` is not a
reference? The same potential issue is possible in that case, no?

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

[mschiffer--- via Gcc-bugs]

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

--- Comment #7 from Matthias Schiffer  ---
(In reply to YunQiang Su from comment #6)
> The attached patch cannot work now.
> 
> It is not correct, and it happened work due to good luck that the same
> register was allocated for these 2 instructions.

I believe this is not the case. The gp init sequence is inserted very late, and
no register allocation is involved - the use of registers $2 and $3 is
hardcoded:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/mips/mips.cc;h=b63d40a357b7c1f294e2c82062f0ef75fc307ba8;hb=HEAD#l12164

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r15-833-gf9810728cf42ea7c3d84198aa582e53cfb2302d1
Author: Andrew MacLeod 
Date:   Sat May 25 12:28:52 2024 -0400

Delete gori_map during destruction of GORI.

Forgot to free the gori_mpa object when a gori object is freed.

PR tree-optimization/115208
* value-query.cc (range_query::create_gori): Confirm gori_map is
NULL.
(range_query::destroy_gori): Free gori_map if one was allocated.

[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop

[jonathan.leffler at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Jonathan Leffler  ---
GCC 14.1.0 seems to produce "error: writing 8 bytes into a region of size 5
[-Werror=stringop-overflow=]" for two extra occurrences of almost the same code
in the original source file.  It still generates the original 4 warnings that
triggered this bug report.  The code now has 6 comments (instead of just 4)
pointing out that the warning is probably incorrect and probably due to GCC bug
106757.  I have not reduced the new situations to a bug like I did for the
"error: writing 1 byte into a region of size 0" version of the message.

[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop

[jonathan.leffler at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Jonathan Leffler  ---
I beg your pardon — I thought I was using GCC 14.1.0 when I was actually using
GCC 13.2.0.  My previous comment applies to GCC 13.2.0, with the spec.

$ /usr/gcc/v13.2.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/gcc/v13.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0
CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
$

Now to build 14.1.0 for this machine too and see whether there's still a
problem.  On another machine with 14.1.0 installed, the code compiles cleanly.

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

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

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

--- Comment #8 from YunQiang Su  ---
Ohh, In fact we should use $28 if TARGET_USE_GOT.

Can you help to test this patch?

```
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index b63d40a357b..fe8641d3916 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -3342,7 +3342,7 @@ mips16_gp_pseudo_reg (void)
 rtx
 mips_pic_base_register (rtx temp)
 {
-  if (MIPS16_GP_LOADS ||!TARGET_MIPS16)
+  if (MIPS16_GP_LOADS || TARGET_USE_GOT ||!TARGET_MIPS16)
 return pic_offset_table_rtx;

   if (currently_expanding_to_rtl)
```

[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

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

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

--- Comment #9 from YunQiang Su  ---
(In reply to Matthias Schiffer from comment #7)
> (In reply to YunQiang Su from comment #6)
> > The attached patch cannot work now.
> > 
> > It is not correct, and it happened work due to good luck that the same
> > register was allocated for these 2 instructions.
> 
> I believe this is not the case. The gp init sequence is inserted very late,
> and no register allocation is involved - the use of registers $2 and $3 is
> hardcoded:

Here $6(a2) is hardcoded, while $3(v1) is not.

[Bug c++/109283] Destructor of co_yield conditional argument called twice

[accelerator0099 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from accelerator0099 at gmail dot com ---
Still ICEs in truck
commit 28b508233a12c13295f960a2cb8a4864879acfb4
May 25 2024
version 15.0.0

Output:
co_yield_bug.cc:197:31: error: redefinition of default argument for ‘class
_Alloc’
  197 | template >
  |   ^
In file included from /build/gcc/include/c++/15.0.0/ranges:72,
 from co_yield_bug.cc:17:
/build/gcc/include/c++/15.0.0/bits/elements_of.h:55:26: note: original
definition appeared here
   55 |   template>
  |  ^~~~
co_yield_bug.cc:204:9: error: redefinition of ‘template std::ranges::elements_of(_Rng&&, _Alloc)-> elements_of<_Range&&,
_Alloc>’
  204 | elements_of(_Rng&&, _Alloc = {}) -> elements_of<_Rng&&,
_Alloc>;
  | ^~~
/build/gcc/include/c++/15.0.0/bits/elements_of.h:63:5: note: ‘template std::ranges::elements_of(_Range&&, _Alloc)->
elements_of<_Range&&, _Alloc>’ previously declared here
   63 | elements_of(_Range&&, _Alloc = _Alloc())
  | ^~~
co_yield_bug.cc: In function ‘std::generator >
source(int&, std::string)’:
co_yield_bug.cc:513:1: internal compiler error: in flatten_await_stmt, at
cp/coroutines.cc:2875
  513 | }
  | ^
0x76fd99 flatten_await_stmt
/build/git/gcc/gcc/cp/coroutines.cc:2875
0xac4833 flatten_await_stmt
/build/git/gcc/gcc/cp/coroutines.cc:2904
0xac67d0 maybe_promote_temps
/build/git/gcc/gcc/cp/coroutines.cc:3087
0xac67d0 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3726
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468
0xac74e1 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3546
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468
0xac6528 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3397
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468
0xac69d0 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3386
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468
0xac69d0 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3386
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468
0xac6528 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3397
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468
0x1693464 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11702
0xac6528 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3397
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468
0xac69d0 await_statement_walker
/build/git/gcc/gcc/cp/coroutines.cc:3386
0x169330c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/build/git/gcc/gcc/tree.cc:11468

[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop

[jonathan.leffler at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Jonathan Leffler  ---
I can confirm that GCC 14.1.0 does not report the problems, after all.

GCC 13.2.0 and GCC 12.1.0 and 12.2.0 do.

Apologies for the confusion.

Re: [Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

[lorena feirer via Gcc-bugs]

[Bug tree-optimization/113433] [12/13/14/15 Regression] Missed optimization for redundancy computation elimination

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 58288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58288&action=edit
Patch which works

Just need to add testcases.

[Bug tree-optimization/113265] [11/12/13/14/15 Regression] Missed optimization for redundancy computation elimination may be due to constant propagation about 0 too late

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

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

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

[Bug tree-optimization/113433] [12/13/14/15 Regression] Missed optimization for redundancy computation elimination

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Andrew Pinski  ---
Dup of bug 113265 really. No reason to keep both open.

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

[Bug tree-optimization/113265] [11/12/13/14/15 Regression] Missed optimization for redundancy computation elimination may be due to constant propagation about 0 too late

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 58289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58289&action=edit
Patch without testcase

Just need to add testcases but the patch was able to bootstrap/test without any
regressions.

[Bug tree-optimization/115226] [15 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-26
   Keywords||ice-on-valid-code
Version|unknown |15.0
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |15.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. One of the sinking changes looks like exposed this latent bug in
unswitch.