[Bug tree-optimization/109590] array-bounds does not warn about address 0x0 dereference

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
-Wnull-dereference is known to give false warnings in many cases (the doc says
"the precision of the warnings depends on the optimization options used" and I
remember there are several recent PRs complaining it).  So it's not suitable
for -Wall or -Wextra.

Maybe we can imply -Wnull-dereference with -Warray-bounds=2, but
-Warray-bounds=2 is not enabled by -Wall or -Wextra as well.

[Bug tree-optimization/109590] array-bounds does not warn about address 0x0 dereference

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

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

--- Comment #4 from Xi Ruoyao  ---
(In reply to Jonny Grant from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > There is -Wnull-dereference for this ...
> 
> I agree. I set that -Wnull-dereference in usual projects (it doesn't seem to
> get enabled by -Wall -Wextra)
> 
> I just expected -Warray-bounds to get the 0x0 address too

There is no reason to expect this.  There is no array at 0x0 address.  The
warning for *p in your case is already complained as false warning in another
PR (I cannot remember the number, but I'm sure there is such a PR).

[Bug middle-end/25186] (short)(((int)short_var) <<1) should be folded so that the shift is done in the short type

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||roger at nextmovesoftware dot 
com
  Known to work||13.0

--- Comment #10 from Roger Sayle  ---
This is now fixed (at the tree level) on mainline (and was fixed in GCC 13).
For those wondering, LSHIFT_EXPR is well defined (in this case) in GIMPLE,
hence the "optimized" dump currently looks like:
void f ()
{
  short int * a.0_1;
  short int _2;
  short int _3;

  a.0_1 = a;
  _2 = *a.0_1;
  _3 = _2 << 1;
  *a.0_1 = _3;
  return;

}

[Bug middle-end/19986] [meta-bug] fold missing optimizations (compared to RTL)

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Bug 25186 Summary: (short)(((int)short_var) <<1) should be folded so that the 
shift is done in the short type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25186

   What|Removed |Added

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

[Bug tree-optimization/109583] [13/14 Regression] ICE in related_vector_mode, at stor-layout.cc:537 since r14-22-g2349e69125335d

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-163-gc58c0771b7a3dbd2a00cd4b6ca2301d74b6cd4e2
Author: Jakub Jelinek 
Date:   Sat Apr 22 10:24:29 2023 +0200

match.pd: Fix fneg/fadd optimization [PR109583]

The following testcase ICEs on x86, foo function since my r14-22
improvement, but bar already since r13-4122.  The problem is the same,
in the if expression related_vector_mode is called and that starts with
  gcc_assert (VECTOR_MODE_P (vector_mode));
but nothing in the fneg/fadd match.pd pattern actually checks if the
VEC_PERM type has VECTOR_MODE_P (vec_mode).  In this case it has BLKmode
and so it ICEs.

The following patch makes sure we don't ICE on it.

2023-04-22  Jakub Jelinek  

PR tree-optimization/109583
* match.pd (fneg/fadd simplify): Don't call related_vector_mode
if vec_mode is not VECTOR_MODE_P.

* gcc.dg/pr109583.c: New test.

[Bug tree-optimization/109583] [13/14 Regression] ICE in related_vector_mode, at stor-layout.cc:537 since r14-22-g2349e69125335d

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

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

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

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

commit r13-7234-g9b6bf076c11cba0f9ccdace63e8b4044b1a858ea
Author: Jakub Jelinek 
Date:   Sat Apr 22 10:24:29 2023 +0200

match.pd: Fix fneg/fadd optimization [PR109583]

The following testcase ICEs on x86, foo function since my r14-22
improvement, but bar already since r13-4122.  The problem is the same,
in the if expression related_vector_mode is called and that starts with
  gcc_assert (VECTOR_MODE_P (vector_mode));
but nothing in the fneg/fadd match.pd pattern actually checks if the
VEC_PERM type has VECTOR_MODE_P (vec_mode).  In this case it has BLKmode
and so it ICEs.

The following patch makes sure we don't ICE on it.

2023-04-22  Jakub Jelinek  

PR tree-optimization/109583
* match.pd (fneg/fadd simplify): Don't call related_vector_mode
if vec_mode is not VECTOR_MODE_P.

* gcc.dg/pr109583.c: New test.

(cherry picked from commit c58c0771b7a3dbd2a00cd4b6ca2301d74b6cd4e2)

[Bug c/109593] New: valgrind error doing build of latest gcc trunk

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109593
   Summary: valgrind error doing build of latest gcc trunk
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried a valgrind build of gcc trunk. Configure line is

../trunk/configure  \
--disable-multilib \
--disable-bootstrap \
--enable-checking=valgrind \
--enable-languages=c,c++

I get:

/home/dcb36/gcc/working/./gcc/xgcc -B/home/dcb36/gcc/working/./gcc/
-B/home/dcb36/gcc/results.20230422.valgrind/x86_64-pc-linux-gnu/bin/
-B/home/dcb36/gcc/results.20230422.valgrind/x86_64-pc-linux-gnu/lib/ -isystem
/home/dcb36/gcc/results.20230422.valgrind/x86_64-pc-linux-gnu/include -isystem
/home/dcb36/gcc/results.20230422.valgrind/x86_64-pc-linux-gnu/sys-include-g
-O2 -O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../trunk.year/libgcc -I../../../trunk.year/libgcc/.
-I../../../trunk.year/libgcc/../gcc -I../../../trunk.year/libgcc/../include
-I../../../trunk.year/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS  -o _bswapdi2_s.o -MT _bswapdi2_s.o -MD -MP -MF
_bswapdi2_s.dep -DSHARED -DL_bswapdi2 -c ../../../trunk.year/libgcc/libgcc2.c
==2810006== Conditional jump or move depends on uninitialised value(s)
==2810006==at 0xB9FD91: real_identical(real_value const*, real_value
const*) (real.cc:1318)
==2810006==by 0xEBFAD4: frange::operator==(frange const&) const
(value-range.cc:685)
==2810006==by 0x18BCCC0: operator!= (value-range.h:101)
==2810006==by 0x18BCCC0: operator!= (value-range.h:646)
==2810006==by 0x18BCCC0: ranger_cache::propagate_cache(tree_node*)
(gimple-range-cache.cc:1097)

[Bug sanitizer/109594] New: [14 Regression] ICE verify_gimple failed since r14-67-g2c800ed8d59cff with ASAN

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

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

Bug ID: 109594
   Summary: [14 Regression] ICE verify_gimple failed since
r14-67-g2c800ed8d59cff with ASAN
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

The following newly causes an ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr70022.c -O2
-fsanitize=address
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr70022.c: In function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr70022.c:7:1: error:
conversion of ‘ssa_name’ on the left hand side of ‘view_convert_expr’
7 | foo (v4si v)
  | ^~~
VIEW_CONVERT_EXPR(v_1(D));

_4 = &VIEW_CONVERT_EXPR(v_1(D))[18446744073709551615];
during GIMPLE pass: asan
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr70022.c:7:1: internal
compiler error: verify_gimple failed
0x1ea6114 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1ea6d66 internal_error(char const*, ...)
???:0
0xf3244d verify_gimple_in_cfg(function*, bool, bool)
???:0
0xdfb8e0 execute_function_todo(function*, void*)
???:0
0xdfbe4e execute_todo(unsigned int)
???:0
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.
Simplify gimple_assign_load

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #9 from David Binderman  ---
I think this one might have returned. With today's gcc trunk:

$ ~/gcc/results/bin/gcc -c  ./gcc.dg/pr109410.c
$ ~/gcc/results/bin/gcc -c -g ./gcc.dg/pr109410.c
$ ~/gcc/results/bin/gcc -c -g -O1 ./gcc.dg/pr109410.c
./gcc.dg/pr109410.c: In function ‘foo’:
./gcc.dg/pr109410.c:14:1: error: returns_twice call is not first in basic block
2
   14 | foo (int x, int y)
  | ^~~
baz (x_7(D), y_8(D));
during GIMPLE pass: reassoc
./gcc.dg/pr109410.c:14:1: internal compiler error: verify_flow_info failed


$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb36/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb36/gcc/results.20230422/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.year/configure
--prefix=/home/dcb36/gcc/results.20230422 --disable-multilib
--disable-bootstrap --with-pkgversion=cda246f8b421ba85 --enable-checking=yes
--enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230422 (experimental) (cda246f8b421ba85) 
$

[Bug c/109593] valgrind error doing build of latest gcc trunk

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

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

Sam James  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
Could you try bisect to speed up things?

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

Sam James  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Sam James  ---
Reopening then.

[Bug c/109593] valgrind error doing build of latest gcc trunk

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
(In reply to Sam James from comment #1)
> Could you try bisect to speed up things?

I think my last valgrind build, dated 20230311, with
git hash 5de5e977aa0b653e was ok.

That's a range of 416 commits. Attempting a bisect.

[Bug tree-optimization/109590] array-bounds does not warn about address 0x0 dereference

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #5 from Jonny Grant  ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to Jonny Grant from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > There is -Wnull-dereference for this ...
> > 
> > I agree. I set that -Wnull-dereference in usual projects (it doesn't seem to
> > get enabled by -Wall -Wextra)
> > 
> > I just expected -Warray-bounds to get the 0x0 address too
> 
> There is no reason to expect this.  There is no array at 0x0 address.  The
> warning for *p in your case is already complained as false warning in
> another PR (I cannot remember the number, but I'm sure there is such a PR).



I get what you are saying, it's a pointer, not a zero-length array that
-Warray-bounds is designed to detect.

I tried these two, just for completeness. 
n[0] no warning, n[1] gives warning
https://godbolt.org/z/q4fbTofqM


https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html



This is another C example, with a struct, like the manual describes, but no
warning -O2 -Wall -Warray-bounds=2 -std=c2x


https://godbolt.org/z/W1G3Wrnoh



#include 

typedef struct foo
{
char buf[0];
} foo_t;

int main()
{
foo_t * n = NULL;
return n->buf[1];
}


https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

I did wonder what 'this_length' refers to in that example

[Bug target/95674] Unnecessary move when doing division-by-multiplication

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 CC||roger at nextmovesoftware dot 
com
  Known to work||12.0
 Status|NEW |RESOLVED

--- Comment #6 from Roger Sayle  ---
This (testcase) has now been fixed on mainline (and back in GCC 12 and 13).

[Bug c/109593] valgrind error doing build of latest gcc trunk

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> That's a range of 416 commits. Attempting a bisect.

Git range seems to be e6b050da8a4513ab..cbddd574a78529b9, which is 52 commits.

[Bug tree-optimization/109595] New: Missed upper bound on number of iterations

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

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

Bug ID: 109595
   Summary: Missed upper bound on number of iterations
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

The following loop can iterate only 0 times before hitting undefined behaviour.

struct foo {
  int a[3];
  int b;
} c;
test(int p)
{
  for (int i = 3; i < p; i++)
  {
  c.a[i]=0;
  }
}
but we miss this fact:
a-t.c.049t.profile_estimate:Loop 1 iterates at most 2147483644 times.
a-t.c.049t.profile_estimate:Loop 1 likely iterates at most 2147483644 times.
a-t.c.106t.cunrolli:Loop 1 iterates at most 2147483644 times.
a-t.c.106t.cunrolli:Loop 1 likely iterates at most 2147483644 times.
a-t.c.159t.ivcanon:Loop 1 iterates at most 2147483643 times.
a-t.c.159t.ivcanon:Loop 1 likely iterates at most 2147483643 times.

[Bug c/109593] valgrind error doing build of latest gcc trunk

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> Git range seems to be e6b050da8a4513ab..cbddd574a78529b9, which is 52
> commits.

Now downto 603fc926fee69ab3..10e481b154c5fc63, which is 13 commits.

[Bug bootstrap/109589] [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:195270d28a534cc1f08478c6e0136f4fc13d247a

commit r14-165-g195270d28a534cc1f08478c6e0136f4fc13d247a
Author: Jakub Jelinek 
Date:   Sat Apr 22 20:14:06 2023 +0200

Fix up bootstrap with GCC 4.[89] after RAII auto_mpfr and autp_mpz
[PR109589]

On Tue, Apr 18, 2023 at 03:39:41PM +0200, Richard Biener via Gcc-patches
wrote:
> The following adds two RAII classes, one for mpz_t and one for mpfr_t
> making object lifetime management easier.  Both formerly require
> explicit initialization with {mpz,mpfr}_init and release with
> {mpz,mpfr}_clear.

This unfortunately broke bootstrap when using GCC 4.8.x or 4.9.x as
it uses deleted friends which weren't supported until PR62101 fixed
them in 2014 for GCC 5.

The following patch adds an workaround, not deleting those friends
for those old versions.
While it means if people add those mp*_{init{,2},clear} calls on auto_mp*
objects they won't notice when doing non-bootstrap builds using
very old system compilers, people should be bootstrapping their changes
and it will be caught during bootstraps even when starting with those
old compilers, plus most people actually use much newer compilers
when developing.

2023-04-22  Jakub Jelinek  

PR bootstrap/109589
* system.h (class auto_mpz): Workaround PR62101 bug in GCC 4.8 and
4.9.
* realmpfr.h (class auto_mpfr): Likewise.

[Bug testsuite/109572] new test case gcc.dg/vect/pr109011-4.c from r14-108-g705b0d2b62318b fails

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-166-g7a0cbaf7f802df209840d78740ffc749dadd1ce3
Author: Jakub Jelinek 
Date:   Sat Apr 22 20:16:08 2023 +0200

testsuite: Fix up pr109011-*.c tests for powerpc [PR109572]

As reported, pr109011-{4,5}.c tests fail on powerpc.
I thought they should have the same counts as the corresponding -{2,3}.c
tests, the only difference is that -{2,3}.c are int while -{4,5}.c are
long long.  But there are 2 issues.  One is that in the foo
function the vectorization costs comparison triggered in, while in -{2,3}.c
we use vectorization factor 4 and it was found beneficial, when using
long long it was just vf 2 and the scalar cost of doing
p[i] = __builtin_ctzll (q[i]) twice looked smaller than the vectorizated
statements.  I could disable the cost model, but instead chose to add
some further arithmetics to those functions to make it beneficial even
with vf 2.
After that change, pr109011-4.c still failed; I was expecting 4 .CTZ calls
there on power9, 3 vectorized and one in scalar code, but for some reason
the scalar one didn't trigger.  As I really want to count just the
vectorized calls, I've added the vect prefix on the variables to ensure
I'm only counting vectorized calls and decreased the 4 counts to 3.

2023-04-22  Jakub Jelinek  

PR testsuite/109572
* gcc.dg/vect/pr109011-1.c: In scan-tree-dump-times regexps match
also
vect prefix to make sure we only count vectorized calls.
* gcc.dg/vect/pr109011-2.c: Likewise.  On powerpc* expect just
count 3
rather than 4.
* gcc.dg/vect/pr109011-3.c: In scan-tree-dump-times regexps match
also
vect prefix to make sure we only count vectorized calls.
* gcc.dg/vect/pr109011-4.c: Likewise.  On powerpc* expect just
count 3
rather than 4.
(foo): Add 2 further arithmetic ops to the loop to make it appear
worthwhile for vectorization heuristics on powerpc.
* gcc.dg/vect/pr109011-5.c: In scan-tree-dump-times regexps match
also
vect prefix to make sure we only count vectorized calls.
(foo): Add 2 further arithmetic ops to the loop to make it appear
worthwhile for vectorization heuristics on powerpc.

[Bug bootstrap/109589] [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Should be worked around now.

[Bug testsuite/109572] new test case gcc.dg/vect/pr109011-4.c from r14-108-g705b0d2b62318b fails

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Should be fixed now.

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

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

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

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

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

commit r14-167-geb385a4801c45a1c0574810b45fce9e712d34566
Author: Harald Anlauf 
Date:   Thu Apr 20 21:47:34 2023 +0200

Fortran: function results never have the ALLOCATABLE attribute [PR109500]

Fortran 2018 8.5.3 (ALLOCATABLE attribute) explains in Note 1 that the
result of referencing a function whose result variable has the ALLOCATABLE
attribute is a value that does not itself have the ALLOCATABLE attribute.

gcc/fortran/ChangeLog:

PR fortran/109500
* interface.cc (gfc_compare_actual_formal): Reject allocatable
functions being used as actual argument for allocable dummy.

gcc/testsuite/ChangeLog:

PR fortran/109500
* gfortran.dg/allocatable_function_11.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug c/109593] valgrind error doing build of latest gcc trunk

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

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

--- Comment #5 from Aldy Hernandez  ---
Huh.  I'm gonna guess:

commit 10e481b154c5fc63e6ce4b449ce86cecb87a6015
Author: Aldy Hernandez 
Date:   Thu Jan 26 04:46:54 2023 +0100

Return true from operator== for two identical ranges containing NAN.


-  if (known_isnan () || src.known_isnan ())
-   return false;
-
   return (real_identical (&m_min, &src.m_min)
  && real_identical (&m_max, &src.m_max)
  && m_pos_nan == src.m_pos_nan

If either operand is a NAN, m_min or m_max have garbage.  Can you verify that's
the commit?  Either way, I can take a look at it on Monday.

[Bug c/109593] valgrind error doing build of latest gcc trunk

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Aldy Hernandez from comment #5)
>  Can you verify that's the commit?  

git bisect says:

10e481b154c5fc63e6ce4b449ce86cecb87a6015 is the first bad commit.

[Bug tree-optimization/109593] valgrind error doing build of latest gcc trunk

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c   |tree-optimization

--- Comment #7 from Andrew Pinski  ---
(In reply to David Binderman from comment #6)
> (In reply to Aldy Hernandez from comment #5)
> >  Can you verify that's the commit?  
> 
> git bisect says:
> 
> 10e481b154c5fc63e6ce4b449ce86cecb87a6015 is the first bad commit.

r14-32-g10e481b154c5fc63

[Bug tree-optimization/109593] [14 Regression] valgrind error doing build of latest gcc trunk

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Version|13.0|14.0
Summary|valgrind error doing build  |[14 Regression] valgrind
   |of latest gcc trunk |error doing build of latest
   ||gcc trunk

[Bug c++/103909] coroutines: co_yield of aggregate-initialized temporaries leads to segmentation faults.

[StevenSun2021 at hotmail dot com via Gcc-bugs]

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

Steven Sun  changed:

   What|Removed |Added

 CC||StevenSun2021 at hotmail dot 
com

--- Comment #3 from Steven Sun  ---
seems that 103909, 104384, 107288 are related (probably the same bug)

[Bug c++/107288] coroutines: Double-free of temporaries created in statement following co_await

[StevenSun2021 at hotmail dot com via Gcc-bugs]

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

Steven Sun  changed:

   What|Removed |Added

 CC||StevenSun2021 at hotmail dot 
com

--- Comment #3 from Steven Sun  ---
seems that 103909, 104384, 107288 are related (probably the same bug)

[Bug c++/104384] coroutines: Heap corruption when initializing struct with co_await

[StevenSun2021 at hotmail dot com via Gcc-bugs]

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

Steven Sun  changed:

   What|Removed |Added

 CC||StevenSun2021 at hotmail dot 
com

--- Comment #1 from Steven Sun  ---
seems that 103909, 104384, 107288 are related (probably the same bug)

[Bug target/54816] [avr] shift is better than widening mul

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:911db256258004b2eec9a0ca3fa47f9bcb5c5856

commit r14-168-g911db256258004b2eec9a0ca3fa47f9bcb5c5856
Author: Roger Sayle 
Date:   Sat Apr 22 20:57:28 2023 +0100

[Committed] Move new test case to gcc.target/avr/mmcu/pr54816.c

AVR test cases that specify a specific -mmcu option need to be placed
in the gcc.target/avr/mmcu subdirectory.  Moved thusly.

2023-04-22  Roger Sayle  

gcc/testsuite/ChangeLog
PR target/54816
* gcc.target/avr/pr54816.c: Move to...
* gcc.target/avr/mmcu/pr54816.c: ... here.

[Bug target/109317] -Os generates bigger code than -O2 on 32-bit ARM

[pali at kernel dot org via Gcc-bugs]

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

--- Comment #2 from Pali Rohár  ---
Any idea what can be done with this?

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[achurch+gcc at achurch dot org via Gcc-bugs]

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

Andrew Church  changed:

   What|Removed |Added

 CC||achurch+gcc at achurch dot org

--- Comment #40 from Andrew Church  ---
Created attachment 54906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54906&action=edit
POC patch to add -Wunused-result=strict

In hopes of moving this along (after having run into it for the third or fourth
time myself), here's a proof-of-concept patch against GCC 12.2.0 which adds
"-Wunused-result=strict" for the current behavior and changes "-Wunused-result"
to ignore cases in which the result is discarded by casting to void.

My rationale for changing the default behavior is that the wider community
consensus, as evidenced by things like the C++ (and C2x) [[nodiscard]]
specification, the behavior of Clang, and the balance of comments on this bug,
seems to be that casting a discarded return value to void should suppress any
warning about the discarded value; and under the principle of least surprise,
GCC should follow that consensus by default even if it also provides
alternative behaviors.

[Bug rtl-optimization/109585] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #13 from Alexander Monakov  ---
The small repro from comment #5 is reproducible on x86_64 trunk as well with
-O2 -DNDEBUG (as well as on older x86_64 branches without -DNDEBUG).

sched2 is lifting

(insn:TI 295 100 101 12 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:DI (plus:DI (reg/v/f:DI 3 bx [orig:133 t ] [133])
(const_int 8 [0x8])) [2 MEM[(const struct ZixBTreeIter
*)t_3(D)].stack[0].node+0 S8 A64])
(const_int 0 [0]))) "/app/example.c":65:12 discrim 2 8
{*cmpdi_ccno_1}
 (nil))

above conflicting 

(insn 101 295 102 12 (set (mem/f:DI (reg/v/f:DI 0 ax [orig:96 f ] [96]) [2
f_69->node+0 S8 A64])
(const_int 0 [0])) "/app/example.c":86:14 88 {*movdi_internal}
 (nil))

[Bug testsuite/109596] New: [14 Regression] Lots of testcases fails on x86_64 after r14-162-gcda246f8b421ba

[haochen.jiang at intel dot com via Gcc-bugs]

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

Bug ID: 109596
   Summary: [14 Regression] Lots of testcases fails on x86_64
after r14-162-gcda246f8b421ba
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haochen.jiang at intel dot com
  Target Milestone: ---

Currently, we can see all the following testcases fail on x86_64:

https://gcc.gnu.org/pipermail/gcc-regression/2023-April/077654.html

>From my bisect script, I can confirm that at least for pr90074 and pr90716,
fail is casued by commit r14-162-gcda246f8b421ba.

It seems that we might need to modify those testcases.

Reproduce by:

make check RUNTESTFLAGS="guality.exp=gcc.dg/guality/pr90716.c
--target_board='unix{-m64\ -march=cascadelake,-m32\
-march=cascadelake,-m32,-m64}'"

[Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:0368d169492017cfab5622d38b15be94154d458c

commit r14-172-g0368d169492017cfab5622d38b15be94154d458c
Author: liuhongt 
Date:   Wed Feb 8 12:42:27 2023 +0800

Use NO_REGS in cost calculation when the preferred register class are not
known yet.

gcc/ChangeLog:

PR rtl-optimization/108707
* ira-costs.cc (scan_one_insn): Use NO_REGS instead of
GENERAL_REGS when preferred reg_class is not known.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr108707.c: New test.

[Bug rtl-optimization/109351] RA uses lowest cost for the mode of different reg_classes w/o considering hard_regno_mode_ok.

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #4 from Hongtao.liu  ---
Fixed in GCC14

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

--- Comment #11 from Sam James  ---
Broken for 13 again too:

$ gcc -c -g -O1 ./gcc/testsuite/gcc.dg/pr109410.c
./gcc/testsuite/gcc.dg/pr109410.c: In function ‘foo’:
./gcc/testsuite/gcc.dg/pr109410.c:14:1: error: returns_twice call is not first
in basic block 2
   14 | foo (int x, int y)
  | ^~~
baz (x_7(D), y_8(D));
during GIMPLE pass: reassoc
./gcc/testsuite/gcc.dg/pr109410.c:14:1: internal compiler error:
verify_flow_info failed
0x7a85a2 verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230421/gcc-13.1.0-RC-20230421/gcc/cfghooks.cc:285
0x19c3a82 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230421/gcc-13.1.0-RC-20230421/gcc/passes.cc:2110
0x192e2e6 do_per_function
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230421/gcc-13.1.0-RC-20230421/gcc/passes.cc:1694
0x192e2e6 execute_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230421/gcc-13.1.0-RC-20230421/gcc/passes.cc:2152
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/109597] New: ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c

[anbu1024.me at gmail dot com via Gcc-bugs]

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

Bug ID: 109597
   Summary: ICE: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in
useless_type_conversion_p, at gimple-expr.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

gcc (GCC) 13.0.1 20230219 snapshot ICEs when compiling the following testcase

$ cat 1.c 

extern int x[4];

extern int y[4];

void foo(void)
{
  void bar(int [4]);
}

void bar(void [x]);

void baz(void)
{
  bar(y);
}



$ gcc --version
gcc (GCC) 13.0.1 20230219 (experimental)
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.



$ gcc 1.c

error: declaration of type name as array of voids
   11 | void bar(void [x]);
  |   ^
1.c: In function ‘baz’:
1.c:15:7: error: type of formal parameter 1 is incomplete
   15 |   bar(y);
  |   ^
1.c:15:3: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.cc:259
   15 |   bar(y);
  |   ^~~
0x840637 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-13-20230219/gcc/tree.cc:8959
0x77c162 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-13-20230219/gcc/tree.h:3653
0x77c162 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc-13-20230219/gcc/gimple-expr.cc:259
0xc8e710 types_compatible_p(tree_node*, tree_node*)
../../gcc-13-20230219/gcc/gimple-expr.h:67
0xc8e710 gimplify_addr_expr
../../gcc-13-20230219/gcc/gimplify.cc:6584
0xc8805d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16408
0xc96b14 gimplify_call_expr
../../gcc-13-20230219/gcc/gimplify.cc:3711
0xc88500 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16333
0xc8a316 gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xc8aa47 gimplify_bind_expr
../../gcc-13-20230219/gcc/gimplify.cc:1430
0xc87c95 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16562
0xca912e gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xca912e gimplify_body(tree_node*, bool)
../../gcc-13-20230219/gcc/gimplify.cc:17623
0xca958a gimplify_function_tree(tree_node*)
../../gcc-13-20230219/gcc/gimplify.cc:17822
0xad7fa7 cgraph_node::analyze()
../../gcc-13-20230219/gcc/cgraphunit.cc:676
0xadaaf7 analyze_functions
../../gcc-13-20230219/gcc/cgraphunit.cc:1238
0xadb78d symbol_table::finalize_compilation_unit()
../../gcc-13-20230219/gcc/cgraphunit.cc:2545
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/109598] New: ICE: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.cc

[anbu1024.me at gmail dot com via Gcc-bugs]

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

Bug ID: 109598
   Summary: ICE: tree check: expected array_type, have error_mark
in array_ref_low_bound, at tree.cc
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

gcc (GCC) 13.0.1 20230219 snapshot ICEs when compiling the following testcase

$ gcc --version
gcc (GCC) 13.0.1 20230219 (experimental)
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.



$ cat 2.c

extern char g[];

char *foo(void)
{
  return &g[0];
}

char *g(void)
{
  return &g[1];
}



$ gcc 2.c 
2.c:9:7: error: ‘g’ redeclared as different kind of symbol
9 | char *g(void)
  |   ^
2.c:2:13: note: previous declaration of ‘g’ with type ‘char[]’
2 | extern char g[];
  | ^
2.c: In function ‘g’:
2.c:11:12: error: subscripted value is neither array nor pointer nor vector
   11 |   return &g[1];
  |^
2.c: In function ‘foo’:
2.c:6:12: internal compiler error: tree check: expected array_type, have
error_mark in array_ref_low_bound, at tree.cc:12782
6 |   return &g[0];
  |   ~^~~
0x840178 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-13-20230219/gcc/tree.cc:8909
0x8499ae tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-13-20230219/gcc/tree.h:3530
0x8499ae array_ref_low_bound(tree_node*)
../../gcc-13-20230219/gcc/tree.cc:12782
0xc8caf9 gimplify_compound_lval
../../gcc-13-20230219/gcc/gimplify.cc:3219
0xc875fe gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16313
0xc8e602 gimplify_addr_expr
../../gcc-13-20230219/gcc/gimplify.cc:6561
0xc8805d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16408
0xc9a465 gimplify_modify_expr
../../gcc-13-20230219/gcc/gimplify.cc:6153
0xc879e1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16361
0xc8a316 gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xc96670 gimplify_and_add(tree_node*, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:492
0xc96670 gimplify_return_expr
../../gcc-13-20230219/gcc/gimplify.cc:1680
0xc87d0a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16623
0xc8a316 gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xc8aa47 gimplify_bind_expr
../../gcc-13-20230219/gcc/gimplify.cc:1430
0xc87c95 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16562
0xca912e gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xca912e gimplify_body(tree_node*, bool)
../../gcc-13-20230219/gcc/gimplify.cc:17623
0xca958a gimplify_function_tree(tree_node*)
../../gcc-13-20230219/gcc/gimplify.cc:17822
0xad7fa7 cgraph_node::analyze()
../../gcc-13-20230219/gcc/cgraphunit.cc:676
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/109597] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c/100532] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:259

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

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

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

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

--- Comment #12 from Sam James  ---
Bisect gives a nonsensical result of r13-7156-g31eb8f18bbe646 with initial good
as r13-7155-g51856718a82ce60f067910d9037ca255645b37eb and bad as
releases/gcc-13.

I've checked out r13-7155-g51856718a82ce60f067910d9037ca255645b37eb and with
that commit, the test case still fails:
```
$ /tmp/bisect/bin/gcc -c -g -O1
/home/sam/git/gcc/gcc/testsuite/gcc.dg/pr109410.c
/home/sam/git/gcc/gcc/testsuite/gcc.dg/pr109410.c: In function ‘foo’:
/home/sam/git/gcc/gcc/testsuite/gcc.dg/pr109410.c:14:1: error: returns_twice
call is not first in basic block 2
   14 | foo (int x, int y)
  | ^~~
baz (x_7(D), y_8(D));
during GIMPLE pass: reassoc
/home/sam/git/gcc/gcc/testsuite/gcc.dg/pr109410.c:14:1: internal compiler
error: verify_flow_info failed
0x9c06ee verify_flow_info()
../.././gcc/cfghooks.cc:285
0xdb8077 execute_function_todo
../.././gcc/passes.cc:2110
0xdb85be execute_todo
../.././gcc/passes.cc:2152
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.
```

with:
```
gcc (GCC) 13.0.1 20230412 (experimental)
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.
```

so I don't think the original fix is complete?

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compare-debug-failure

--- Comment #13 from Andrew Pinski  ---
So the testcase gcc.dg/pr109410.c passes but if you add -g, the ICE will show
up still.

This also means there will be some compare-debug failure too as the IR/CFG will
be different with/without -g.

I suspect gsi_after_labels here should really be
gsi_start_nondebug_after_labels_bb .

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

--- Comment #14 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #13)
> So the testcase gcc.dg/pr109410.c passes but if you add -g, the ICE will
> show up still.
> 
> This also means there will be some compare-debug failure too as the IR/CFG
> will be different with/without -g.
> 
> I suspect gsi_after_labels here should really be
> gsi_start_nondebug_after_labels_bb .

That is:
diff --git a/gcc/tree-ssa-reassoc.cc b/gcc/tree-ssa-reassoc.cc
index 067a3f07f7e..c71780e6d54 100644
--- a/gcc/tree-ssa-reassoc.cc
+++ b/gcc/tree-ssa-reassoc.cc
@@ -1563,7 +1563,7 @@ build_and_add_sum (tree type, tree op1, tree op2, enum
tree_code opcode)
   if ((!op1def || gimple_nop_p (op1def))
   && (!op2def || gimple_nop_p (op2def)))
 {
-  gsi = gsi_after_labels (single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun)));
+  gsi = gsi_start_nondebug_after_labels_bb (single_succ
(ENTRY_BLOCK_PTR_FOR_FN (cfun)));
   if (!gsi_end_p (gsi)
  && is_gimple_call (gsi_stmt (gsi))
  && (gimple_call_flags (gsi_stmt (gsi)) & ECF_RETURNS_TWICE))

[Bug c/109599] New: Query for merging files in ar.exe

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

Bug ID: 109599
   Summary: Query for merging files in ar.exe
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukaszcz18 at wp dot pl
  Target Milestone: ---

Created attachment 54907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54907&action=edit
Added file object

I don't know how to get around the problem.
I add commands to ar.exe. GCC: (GNU) 13.0.1 20230421 (prerelease)
http://msystem.waw.pl/x265/mingw-gcc1301-20230421.7z
Codec directories
libxeve
libxeve/avx2
libxeve/sse2

cd libavcodec/libxeve
ar.exe rcs "../../lib/libxeve_x64.a" xeve_bsw.o xeve_df.o xeve_eco.o xeve_enc.o
xeve_fcst.o xeve_ipred.o xeve_itdq.o xeve_mc.o xeve_mode.o xeve_param_parse.o
xeve_picman.o xeve_pinter.o xeve_pintra.o xeve_port.o xeve_rc.o xeve_recon.o
xeve_sad.o xeve_tbl.o xeve_thread_pool.o xeve_tq.o xeve_util.o xevem.o
xevem_alf.o xevem_df.o xevem_dra.o xevem_eco.o xevem_ibc_hash.o xevem_ipred.o
xevem_itdq.o xevem_mc.o xevem_mode.o xevem_pibc.o xevem_picman.o xevem_pinter.o
xevem_pintra.o xevem_recon.o xevem_stat.o xevem_tbl.o xevem_tq.o xevem_util.o
cd ../..

The generated .a file contains GCC: (GNU) 11.3.1 20221227 in addition to the
sse2/avx2 files. Where did it come from and how do I get rid of it.

[Bug other/109599] Query for merging files in ar.exe

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
  Component|c   |other
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
I am trying to understand your question.
But first I should note ar is not part of GCC but rather in your case comes
from the project called GNU binutils.

Are you asking how to have ar understand object files which are named the same
name but have different pathes? Well archive files don't normally support that.
See the AR manual page and the option P too. BIG WARNING, you need to always
use the P option when modifing those archives too.

Or you asking how to chose at compile time the files between the different
subdirectories? That is not related to AR and needs more thinking on your part
really.

Anyways this is not the right location to ask questions about ar, try emailing
binut...@sourceware.org instead.

[Bug other/109599] Query for merging files in ar.exe

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

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

--- Comment #2 from Andrew Pinski  ---
Also if you asking where the comment: "GCC: (GNU) 11.3.1 20221227" comes from?
Well we have no idea really.

Also we don't support prebuilt GCC here. Please ask the place you got the
binary from why it displays that version.

[Bug other/109599] Query for merging files in ar.exe

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

--- Comment #3 from Jamaika  ---
I'm not referring to the GCC 11.3.1 comment itself. I meant why the .a file
automatically adds and compiles c files from the avx2 and sse2 directories that
I have not added.
I was surprised that ar.exe is not a gcc product. Who is the creator?

[Bug tree-optimization/109593] [14 Regression] Valgrind error doing build of latest gcc trunk since r14-32-g10e481b154c5fc63

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

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

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

Patch in testing.  Does this fix the problem on the reporter's side?

[Bug other/109599] Query for merging files in ar.exe

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jamaika from comment #3)
> I'm not referring to the GCC 11.3.1 comment itself. I meant why the .a file
> automatically adds and compiles c files from the avx2 and sse2 directories
> that I have not added.
I have no idea and I suspect you did mention the object files.
Since we have no idea the exact command lines being used either. Maybe there is
an update to the archive file while inside the avx2/sse2 directories that adds
those object files.
Note if you are using make, you should look into the makefiles to see what is
being done. you can use the -d option there. Also NOTE make is not part of the
GCC project either, but than the GNU make project.


> I was surprised that ar.exe is not a gcc product. Who is the creator?

I mentioned it in my comment:
"But first I should note ar is not part of GCC but rather in your case comes
from the project called GNU binutils."