[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #5 from LIU Hao  ---
Additional information:

I tried splitting the two class templates into two separate .cpp files, so the
explicit instantiation of `basic_shallow_string` should not be subject to
the instantiation of `basic_cow_string`. This made GCC emit the
constructor correctly (checked by examining assembly), but still failed to the
very same undefined reference.

At the moment, a temporary workaround is to mark the constructor of
`basic_shallow_string` as `always_inline`. This works for GCC 10, 11 and 12.
Haven't checked GCC 9 as it's no longer available from APT sources of my
current machine.

[Bug c++/109470] New: unexpected const & behavior

[johannes.kellner at wandelbots dot com via Gcc-bugs]

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

Bug ID: 109470
   Summary: unexpected const & behavior
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johannes.kellner at wandelbots dot com
  Target Milestone: ---

Hello, I am filing this ticket, as I had source code, where this funny Min
template created a seg fault when compiling release (optimized code).
I changed the this to an example - to check the behavior and the first to show
is this UNEXPECTED/INVALID? behavior:

#include 
#include 

template
const TYPE& Min(const TYPE& lhs, const TYPE& rhs)
{
   if (lhs < rhs) return lhs;
   return rhs;
}

int main()
{
   size_t lenght = 16;
   const int MAX = 32;

   const int& dst = Min(MAX, (int)lenght);
   assert(dst <= MAX);
   return dst;
}

Expected behavior: return 16

If compiled with gcc 12.2 and -O0: returns 16
If compiled with gcc 12.2 and -O1: returns 0  UNEXPECTED !!!

I assume, that something with the extension of lifetime, 
for the result of `(int)lenght` fails in the optimized code.

I found this unexpected behavior, because this Min function was used to
calculate the size for a memcpy. And if compiled with optimization, dst became
invalid (very large), just after the call to Min.

We tested with gcc10 but have the same problem with gcc12.

Please feel free to contact me for details.

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #5 from Sam James  ---
(In reply to Sam James from comment #4)
> This might be a dupe of PR108783 or PR109410 but I had to try reduce it to
> be relatively sure, so may as well file it here for completeness.

I thought it was interesting in this case that it happens even without a
definition of foo which was the main motivation for bothering here.

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #4 from Sam James  ---
This might be a dupe of PR108783 or PR109410 but I had to try reduce it to be
relatively sure, so may as well file it here for completeness.

[Bug tree-optimization/109469] New: [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Bug ID: 109469
   Summary: [13 regression] ICE: internal compiler error:
verify_flow_info failed (error: returns_twice call is
not first in basic block 2)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Hit this when building xdvik-22.87.06 with 13.0.1 20230409 w/ checking.

```
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.  -I./gui -DPS_GS 
-I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include   -Wimplicit -Wreturn-type -O2
-pipe -march=native -fdiagnostics-color=always -frecord-gcc-switches
-Wreturn-type  -ggdb3 -Werror=implicit-function-declaration
-Werror=implicit-int -Wformat -Waddress -Warray-bounds -Wfree-nonheap-object
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Wint-conversion -Wint-to-pointer-cast -Wmain -Wnonnull -Wodr -Wparentheses
-Wreturn-type -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstring-compare
-Wuninitialized -Wunused-value -Wvarargs -c -o util.o util.c
util.c: In function ‘fork_process’:
util.c:988:1: error: returns_twice call is not first in basic block 25
  988 | fork_process(const char *proc_name, Boolean redirect_stdout,
  | ^~~~
pid_96 = vfork ();
during GIMPLE pass: slp
util.c:988:1: internal compiler error: verify_flow_info failed
0x7aa668 verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/cfghooks.cc:285
0x151e50d execute_function_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:2110
0x1485fd1 do_per_function
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:1694
0x1485fd1 execute_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/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 tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #1 from Sam James  ---
Created attachment 54826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54826=edit
util.i.orig (unreduced)

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #2 from Sam James  ---
Created attachment 54827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54827=edit
util.i (reduced)

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

--- Comment #3 from Sam James  ---
Created attachment 54828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54828=edit
util2.i (reduced further, but check)

[Bug tree-optimization/109392] [12 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177 since r12-117-gb972e036f40c

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/109470] unexpected const & behavior

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

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

--- Comment #2 from Xi Ruoyao  ---
With "-Wall -O1" this is diagnosed properly, but with a spurious
maybe-uninitialized warning:

In file included from /usr/include/c++/12.2.0/cassert:44,
 from t.c:2:
t.c: In function 'int main()':
t.c:17:11: warning: dangling pointer 'dst' to an unnamed temporary may be used
[-Wdangling-pointer=]
   17 |assert(dst <= MAX);
  |   ^~~
t.c:16:24: note: unnamed temporary defined here
   16 |const int& dst = Min(MAX, (int)lenght);
  | ~~~^~
t.c:16:24: warning: '' may be used uninitialized
[-Wmaybe-uninitialized]

With "-Wall -O2" only the spurious maybe-uninitialized warning is emitted,
which is not very helpful.

With "-Wall -O0" no warning at all (diagnosing this issue at least needs some
IPA).

[Bug target/108722] gcc.dg/analyzer/file-CWE-1341-example.c fails on power 9 BE

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org

--- Comment #1 from Jiu Fu Guo  ---
The case only checkes [CWE-1341] which is `double-fclose`.
While on the BE machine, besides [CWE-1341], a message of [CWE-415] is also
reported. Because attribute `malloc` is attached on fopen:
```
# 258 "/usr/include/stdio.h" 3 4
extern FILE *fopen (const char *__restrict __filename,
  const char *__restrict __modes)   
  __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (fclose, 1))) ;

or say: __attribute_malloc__ __attr_dealloc_fclose __wur;
```

Because this case is not intended to test CWE-415, it may be ok to add
-Wno-analyzer-double-free for this case.

[Bug c++/109470] unexpected const & behavior

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
The function call in this case is Min.

So after the semicolon of the definition of dst, the temp is destroyed.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Costas Argyris  ---
Hi Huaqi,

This is building a larger project, which gcc is part of.I am not familiar
with that larger project and I have never built it.

Could we extract only the gcc-specific part out of the entire build process,
such that I can reproduce the gcc build failure on its own, just by using gcc's
configure?In other words, I would like to debug gcc's build process only,
not a larger project's build process which includes building gcc.If there
is indeed a problem with gcc due to that patch, it should be possible to
isolate it and reproduce it by building gcc only by itself.

[Bug sanitizer/109446] Possible destination array overflow without diagnosis in memcpy

[mohamed.selim at dxc dot com via Gcc-bugs]

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

--- Comment #1 from Mohamed  ---
correction to scenario II should pass by value as follows
//void test(Bar b) // scenario II

[Bug other/109398] libiberty/sha1.c:234:11: warning: defining a type within 'offsetof' is a Clang extension [-Wgnu-offsetof-extensions]

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |other
   Keywords||build

--- Comment #1 from Richard Biener  ---
Looks like a possible build issue with non-GCC host compilers (but nobody
complained since 2008 when it was introduced).  Should be easy to refactor
with a local type though, just not as nicely encapsulated in 'alignof'.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Costas Argyris  ---
Still can't do much without detailed info on how exactly you are building gcc,
what is your build setup, what is your cross-compiler version, OS, how you
configure etc etc...Ideally, solid reproduction steps would be optimal.   
Also, isolated logs from a single file are not that helpful, could you please
paste more context from the build log around the error?

Also, is this happening only for the 32-bit windows host, meaning that the
64-bit windows host is succeeding, or you haven't tried the 64-bit windows host
at all?

The patch you pointed at has been built successfully with some common build
setups, both cross and native, for both 32 and 64-bit windows hosts, so it
can't be completely broken - we just have to figure out what is different in
your particular build process and is causing problems, which is why I am asking
for more info and reproduction steps.

Also, as I said before, the fact that you ended up with this line:

utf8-mingw32.o: In function `WinMainCRTStartup':

indicates that something went horribly wrong because these object files have no
relation to any main function, and yet they were somehow attempted to be built
as executables.This should never have happened, so I am curious how exactly
you ended up in this situation.

[Bug driver/108241] [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658

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

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

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

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

commit r13-7136-gcb06a507073e4d6218a70a2d5b0738a0487d6d9a
Author: Martin Liska 
Date:   Fri Mar 31 14:28:15 2023 +0200

driver: drop flag_var_tracking_assignments flag

The revision r13-259-g76db543db88727 moved a condition from one
file to another, but now we do not drop x_flag_var_tracking_assignments
as it was done before the mentioned revision.

PR driver/108241

gcc/ChangeLog:

* opts.cc (finish_options): Drop also
x_flag_var_tracking_assignments.

gcc/testsuite/ChangeLog:

* gcc.dg/pr108241.c: New test.
* gcc.dg/pr79570.c: Add also -g option.

[Bug c++/109470] unexpected const & behavior

[johannes.kellner at wandelbots dot com via Gcc-bugs]

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

Johannes Kellner  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #3 from Johannes Kellner  
---
'A temporary object bound to a reference parameter in a function call persists
until the completion of the full-expression containing the call.'

So this does not mean, that the temporary object, (int)lenght, should life
until the end of main ??? As main() is the enclosing scope?

[Bug c++/109470] unexpected const & behavior

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Johannes Kellner from comment #3)
> 'A temporary object bound to a reference parameter in a function call
> persists until the completion of the full-expression containing the call.'
> 
> So this does not mean, that the temporary object, (int)lenght, should life
> until the end of main ??? As main() is the enclosing scope?

No, because it says "completion of the full-expression" not "end of the
enclosing scope".

The full-expression ends at the semi-colon.

[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |NEW
Version|unknown |13.0
  Component|tree-optimization   |c++
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=35269

--- Comment #6 from Richard Biener  ---
Well, but v.size () is not loop invariant.  As Andrew says 'v' is passed by
(const?) reference but the PTA solution doesn't exactly reflect this
so we do think the call clobbers it:

  # USE = nonlocal escaped
  # CLB = nonlocal escaped
  f (_1);
...
  # PT = nonlocal escaped null
  _10 = MEM[(const struct vector *)v_5(D)].D.35644._M_impl.D.34955._M_finish;
  # PT = nonlocal escaped null
  _11 = MEM[(const struct vector *)v_5(D)].D.35644._M_impl.D.34955._M_start;
  _12 = _10 - _11;
  _13 = _12 /[ex] 4;
  _14 = (long unsigned int) _13;
  if (i_8 < _14)
goto ; [89.00%]

so somehow the C++ handling of value-as-reference passing doesn't work (it
should set TYPE_RESTRICT on the argument type used.

[Bug c++/109470] unexpected const & behavior

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

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

--- Comment #8 from Jonathan Wakely  ---
No, "full-expression" is a formal term defined very precisely in the C++
standard. There is no opportunity for GCC to review that without failing to
conform to the C++ standard. Changing when temporary objects are destroyed
would be a massive breaking change to the C++ language that would break
assumptions made by correct code.

Just because you don't get a warning with other compilers, doesn't mean your
code is correct. The code accesses an object outside its lifetime, and so has
undefined behaviour. That is true with all compilers.

Clang gives a runtime error with -fsanitize=address e.g.
https://godbolt.org/z/dhcEhvzze

That's because the program has undefined behaviour. This is not just GCC's
interpretation of the C++ standard, it's a fact.

[Bug target/109436] AArch64: suboptimal codegen in 128 bit constant stores

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Confirmed.  In terms of internals, we should probably split
128-bit GPR stores into STP patterns after RA.  That should
allow post-RA passes to remove the zero move.

[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Alexander Monakov from comment #5)
> Indeed, sorry, __attribute__((used)) seems a much better solution for
> symbols that might be referenced implicitly, in a manner that LTO plugin
> cannot see.

OTOH if the linker(?) introduces such use then it should properly communicate
this via the resolution info.  That would hint at a binutils bug.

[Bug c/109393] Very trivial address calculation does not fold

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |c
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-11
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
It's probably a mismatch of GENERIC/GIMPLE folding.  In this case it's
pointer_int_sum prematurely distributing the multiplication:

/* Return a tree for the sum or difference (RESULTCODE says which)
   of pointer PTROP and integer INTOP.  */

tree  
pointer_int_sum (location_t loc, enum tree_code resultcode,
 tree ptrop, tree intop, bool complain)
{ 
...
  /* If what we are about to multiply by the size of the elements
 contains a constant term, apply distributive law
 and multiply that constant term separately.
 This helps produce common subexpressions.  */

but this kind of stuff shouldn't be done by the frontends these days.

Gating this fixes the issue.  I think this piece of code should be axed
(after careful evaluation of its effect)

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

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Priority|P3  |P2
   Last reconfirmed||2023-04-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
Confirmed.  ISTR we did have another issue like this Jakub fixed recently?

[local count: 1073741824]:
+  _4 = x_7(D) > 41;
   baz (x_7(D), y_8(D));
   goto ; [99.96%]

@@ -101,9 +141,8 @@
[local count: 1073312329]:
   _1 = y_8(D) != 0;
   _2 = x_7(D) == 42;
-  _3 = _1 | _2;
   _12 = x_7(D) > 42;
-  _10 = _3 | _12;
+  _10 = _4 | _1;
   _13 = (int) _10;
   return _13;

[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Hmm, we did fix such an issue already .. let me take a look.

[Bug middle-end/26724] __builtin_constant_p fails to recognise function with constant return

[matthijs at stdin dot nl via Gcc-bugs]

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

Matthijs Kooijman  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #5 from Matthijs Kooijman  ---
I also ran into this problem in an embedded project and the workaround also
works for me - thanks!

I had already made a short testcase in godbolt for this before I found this
report. I'll share it here just in case it is useful for testing this problem
later: https://godbolt.org/z/s1eK6a3Pf

Here's the code:

#include 
// I added always_inline to see if that would help - seems to make not
difference
//[[gnu::always_inline]] static inline bool always_true() 
__attribute__((always_inline));
static inline bool always_true() { return true; }

static constexpr inline bool constexpr_always_true() { return true; }

int main() {
printf("DIRECT: %d\n", __builtin_constant_p(always_true()));
bool var = always_true();
printf("VIAVAR: %d\n", __builtin_constant_p(var));
printf("CONSTEXPR: %d\n", __builtin_constant_p(constexpr_always_true()));
}

Gcc 12.2 outputs:

DIRECT: 0
VIAVAR: 1
CONSTEXPR: 1

Two additional observations:
 - clang seems to behave the same as gcc here
 - Adding constexpr to the function definition also fixes the problem without
the workaround (but might not always be useful - constexpr has more strict
requirements than a __builtin_constant_p test).
 - Adding always_inline attributes makes no difference.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Costas Argyris  ---
Are you building the cross-compiler itself or just using an existing
cross-compiler to build for the windows host?

You may have to build the cross-compiler first from the latest gcc sources, and
then use that newly-built cross-compiler to build the same gcc sources into a
windows-hosted compiler.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #9 from Huaqi  ---
Hi, Costas Argyris,

I am using this repo to help build toolchain, the repo link is here:

https://github.com/riscv-collab/riscv-gnu-toolchain

clone this source code and its submodule, and change gcc to upstream version

git clone https://github.com/riscv-collab/riscv-gnu-toolchain.git
git submodule update --init --recursive --depth 1
cd gcc
# fetch upstream gcc source code
git fetch --all
git checkout master
cd ..

Tested in Ubuntu 18.04, with packages binutils-mingw-w64-i686
gcc-mingw-w64-i686 g++-mingw-w64-i686 binutils-mingw-w64-i686 installed and
other requirements in
https://github.com/riscv-collab/riscv-gnu-toolchain#prerequisites.


build command:

mkdir build
cd build
../configure --prefix=$(pwd)/install --with-host=i686-w64-mingw32 
--enable-multilib
make -j16

Then you will be able to reproduce this issue.

Thanks

[Bug c++/109470] unexpected const & behavior

[johannes.kellner at wandelbots dot com via Gcc-bugs]

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

--- Comment #6 from Johannes Kellner  
---
Ok, Ok :)
It's not to me to argue this.

It's just an unexpected behavior (something I was unaware off/ something that
does not happen when doing the same code with other compilers clang/msvc).

And in my humble opinion - `full-expression containing the call` could be
understood as - until end of enclosing scope.
Or at least if understood this way, I would not have the uninitialized variable
:)

I just had a stupid error and found this as the reason. We discussed it and
even others in my team, assumed that it might be a bug. As we were not able to
reproduce this behavior in other compilers we tested.
Nor did see this as `invalid` code - `ugly` yes, but not `invalid`. And yes,
this code is 'not the best possible way'...

Well maybe you take this ticket as a reason to `review` the interpretation,
that `full-expression containing the call` does not mean until the `end of
enclosing scope`...

For me, I'm fine with current outcome.
Thank you anyway for the quick, very friendly and professional responses!

Best regards

[Bug c++/109470] unexpected const & behavior

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
You can use -fsanitize=address to get such bugs diagnosed at runtime:
g++ -fsanitize=address -o /tmp/pr109470{,.C} -g; /tmp/pr109470
=
==2466554==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7ffe08313d80 at pc 0x00401304 bp 0x7ffe08313d20 sp 0x7ffe08313d18
READ of size 4 at 0x7ffe08313d80 thread T0
#0 0x401303 in main /tmp/pr109470.C:17
#1 0x7f5b06f7958f in __libc_start_call_main (/lib64/libc.so.6+0x2958f)
#2 0x7f5b06f79648 in __libc_start_main@GLIBC_2.2.5
(/lib64/libc.so.6+0x29648)
#3 0x4010e4 in _start (/tmp/pr109470+0x4010e4)

Address 0x7ffe08313d80 is located in stack of thread T0 at offset 64 in frame
#0 0x4011b5 in main /tmp/pr109470.C:12

  This frame has 2 object(s):
[48, 52) 'MAX' (line 14)
[64, 68) '' <== Memory access at offset 64 is inside this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /tmp/pr109470.C:17 in main
Shadow bytes around the buggy address:
  0x10004105a760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7a0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 04 f2
=>0x10004105a7b0:[f8]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==2466554==ABORTING

C++ has always behaved like this and changing it would significantly penalize
all the code in the wild that uses C++ correctly.  There are some exceptions
where the lifetime is extended, but is certainly not one of them.

[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator

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

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

--- Comment #7 from Alexander Monakov  ---
Yes, ld should claim _pei386_runtime_relocator (even if later it becomes
unneeded due to zero relocations left to fix up) to make this work properly.
That's for Binutils to fix on their side.

[Bug tree-optimization/109441] missed optimization when all elements of vector are known

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Version|unknown |13.0
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Well, it doesn't need std::vector for this, a C testcase with a large enough
array (> 16 elements, the unroll limit) suffers from the same "problem".

But IMHO it's academic, right?

GCC only transforms loopy code like you suggest by complete peeling of the
loop, it doesn't attempt to "simulate" IL (and if, then it would only up
to some complexity limit).

[Bug tree-optimization/109442] Dead local copy of std::vector not removed from function

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jwakely.gcc at gmail dot com,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-04-11
Version|unknown |13.0

--- Comment #1 from Richard Biener  ---
So we're failing to DSE

  _13 = pretmp_25 - pretmp_63;
  if (_13 > 4)
goto ; [97.30%]
  else
goto ; [2.70%]

   [local count: 14278734]:
  if (_13 == 4)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 913536322]:
  _23 = (long unsigned int) _13;
  __builtin_memmove (_37, pretmp_63, _23);
  goto ; [100.00%]

   [local count: 34511373]:
  _24 = *pretmp_63;
  *_37 = _24;

   [local count: 542742079]:
  operator delete (_37, _49);

because I think the DTOR / overloaded global delete might inspect the vector
contents.  So I'm not sure it would be valid to elide the memmove/store.
When the stores would be elided we'd DCE the new/delete pair as well.

[Bug rtl-optimization/109370] Missed optimization for std::optional branchless unwrapping

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization

--- Comment #2 from Richard Biener  ---
Note we would need to know that dereferencing 'o' is OK (not sure if RTL knows
this), and this if-conversion is certainly RTL territorry because of costing. 
On x86 I'd expect the branchy version to be faster.

[Bug lto/109403] Alignment of common blocks not reported correctly

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed, not sure how well-defined "The symbol value" displayed is.  The
required info is probably also not available in the LTO symbol table entry.

[Bug tree-optimization/109440] Missed optimization of vector::at when a function is called inside the loop

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

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

--- Comment #2 from Richard Biener  ---
There's that other bug which would be basically a duplicate, so I leave this
one tree-optimization, not C++.

[Bug sanitizer/109446] Possible destination array overflow without diagnosis in memcpy

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #2 from Xi Ruoyao  ---
Should we disable __builtin_memcpy etc. with -fsanitize=address?

[Bug tree-optimization/109442] Dead local copy of std::vector not removed from function

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

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

--- Comment #2 from Jonathan Wakely  ---
Neither v nor v1 escapes the function, so I don't think operator delete can
inspect them.

The destructor doesn't inspect the contents, it just destroys the elements
(which is a no-op for int) and then calls operator delete to free the storage.

[Bug tree-optimization/108888] [13 Regression] error: definition in block 26 follows the use

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

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

commit r13-7135-g58c8c1b383bc3c286d6527fc6e8fb62463f9a877
Author: Andre Vieira 
Date:   Tue Apr 11 10:07:43 2023 +0100

if-conv: Restore MASK_CALL conversion [PR10]

The original patch to fix this PR broke the if-conversion of calls into
IFN_MASK_CALL.  This patch restores that original behaviour and makes sure
the
tests added earlier specifically test inbranch SIMD clones.

gcc/ChangeLog:

PR tree-optimization/10
* tree-if-conv.cc (predicate_statements): Fix gimple call check.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-simd-clone-16.c: Make simd clone inbranch only.
* gcc.dg/vect/vect-simd-clone-17.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18.c: Likewise.

[Bug driver/108241] [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed on master, not planning to backport that.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #44 from Richard Biener  ---
The larger testcase:

typedef struct __attribute__((__packed__)) _Atom { float x, y, z; int type; }
Atom;
typedef struct __attribute__((__packed__)) _FFParams { int hbtype; float
radius; float hphb; float elsc; } FFParams;

void
fasten_main (unsigned long group, unsigned long natlig, unsigned long natpro,
const Atom *protein, const Atom *ligand,
 const FFParams *forcefield, float *energies)
{
  float etot[64];
  float lpos_x[64];
  for (int l = 0; l < 64; l++) {
etot[l] = 0.f;
lpos_x[l] = 0.f;
  }
  for (int il = 0; il < natlig; il++) {
const Atom l_atom = ligand[il];
const FFParams l_params = forcefield[l_atom.type];
for (int ip = 0; ip < natpro; ip++) {
  const Atom p_atom = protein[ip];
  const FFParams p_params = forcefield[p_atom.type];
  const float radij = p_params.radius + l_params.radius;
  const float elcdst = (p_params.hbtype == 70 && l_params.hbtype == 70) ?
4.0f : 2.0f;
  const float elcdst1 = (p_params.hbtype == 70 && l_params.hbtype == 70) ?
0.25f : 0.5f;
  const int type_E = ((p_params.hbtype == 69 || l_params.hbtype == 69));
  const float chrg_init = l_params.elsc * p_params.elsc;
  for (int l = 0; l < 64; l++) {
const float x = lpos_x[l] - p_atom.x;
const float distij = (x * x);
const float distbb = distij - radij;
const int zone1 = (distbb < 0.0f);
float chrg_e = chrg_init * ((zone1 ? 1.0f : (1.0f - distbb * elcdst1))
* (distbb < elcdst ? 1.0f : 0.0f));
float neg_chrg_e = -__builtin_fabsf(chrg_e);
chrg_e = type_E ? neg_chrg_e : chrg_e;
etot[l] += chrg_e * 45.0f;
  }
}
  }
  for (int l = 0; l < 64; l++)
energies[group * 64 + l] = etot[l] * 0.5f;
}

[Bug c++/109471] New: Missing loop unrolling for small std::vector?

[stefano.d at posteo dot de via Gcc-bugs]

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

Bug ID: 109471
   Summary: Missing loop unrolling for small std::vector?
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefano.d at posteo dot de
  Target Milestone: ---

Hi,
I did some benchmarks where I wanted to bench a switch-case statement against a
small std::vector. In GCC 12.2 the result was as expected: The switch-case
statement was faster than the linear search in std::vector. But when I switched
to clang 13 or above, the std::vector implementation was much faster than the
switch-case statement!

You can the results here:
https://quick-bench.com/q/9DEDS7rQm0MnIFxwZt3A2iD86G0

Please switch here between GCC and clang.

Here an assembly output:

https://godbolt.org/z/j8oenP8x9

Kind regards
Stefano

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Costas Argyris  ---
As I said before, I think adding the "-o" flag to

$(COMPILER) -c $< -o $@

is a good and harmless change, but, as per your own report, it didn't solve
your issues because you still got that mysterious line:

utf8-mingw32.o: In function `WinMainCRTStartup':

which doesn't make sense to me.This makes me suspect that the problem is
something else and not the abscence of "-o".These object files have nothing
to do with such main functions that are associated with executables.So
unless you come up with gcc-specific reproduction steps for me to investigate,
you have to figure out why this object file even has a WinMainCRTStartup
function after adding the "-o" flag.

I also noticed you are using gcc 7.3 as the cross-compiler.Would it be
possible to use a more recent version, just to see if that makes a difference?

[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Waiting for a testcase, can you attach preprocessed source of the translation
unit exhibiting the issue (it's not clear from the build log which one that
is).

[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2

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

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

--- Comment #3 from Richard Biener  ---
So the issue is that clear_bytes_written_by doesn't handle exceptions properly
and that's thru initialize_ao_ref_for_dse.

[Bug c++/80883] Hardcoded null DSO handle parameter to __cxa_thread_atexit() on MinGW-w64 targets

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from LIU Hao  ---
I'm closing this. It looks like if mingw-w64 CRT doesn't define `__dso_handle`
then a null pointer is passed, but with more recent versions it is defined, and
the argument is no longer a null pointer.

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

--- Comment #2 from Jakub Jelinek  ---
Under debugger (trunk) what I see is that the block_result.intersect
(equiv_range)
in the code added by r13-1938 is only true in the VisitObjCMessageExpr function
twice, each time on the
  # Result$16_552 = PHI 
SSA_NAME, on the
 [local count: 251634481]:
if (p_count_732 == 1)
  goto ; [5.50%]
else
  goto ; [94.50%]
block (i.e. one guarded with _143 == 22 condition),
which has originally VARYING block_result, but equiv_name is strangely
_143 set by
  _143 = I.Kind;
earlier.  Obviously the range for _143 in that bb is [22, 22], that is correct,
what isn't correct is that it would be equivalent to Result$16_552.
The IL of the loop is:

   [local count: 740101405]:
  _143 = I.Kind;
  if (_143 == 21)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 251634481]:
  # RANGE [irange] int [-2147483647, +INF]
  p_count_87 = p_count_732 + 1;
  goto ; [100.00%]

   [local count: 488466924]:
  if (_143 == 22)
goto ; [70.13%]
  else
goto ; [29.87%]

   [local count: 251634481]:
  if (p_count_732 == 1)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 237794584]:
  # RANGE [irange] int [-INF, -1][1, 2147483646]
  p_count_88 = p_count_732 + -1;

   [local count: 726261510]:
  # p_count_45 = PHI 
  MEM  [(struct Token *)] = MEM 
[(struct Token *)];
  Result$UintData_449 = MEM  [(struct Token *) + 4B];
  Result$PtrData_172 = MEM  [(struct Token *) + 8B];
  Result$16_670 = MEM  [(struct Token *) + 16B];
  _439 = TheLexer.D.700857.LexingRawMode;
  if (_439 != 0)
goto ; [99.96%]
  else
goto ; [0.04%]

   [local count: 313395]:
  # USE = nonlocal escaped
  # CLB = nonlocal escaped
  __assert_fail ("LexingRawMode && \"Not already in raw mode!\"",
"/usr/src/llvm-project/clang/include/clang/Lex/Lexer.h", 237, "bool
clang::Lexer::LexFromRawLexer(clang::Token&)");

   [local count: 783176091]:
  # p_count_732 = PHI 
  # Result$UintData_591 = PHI 
  # Result$PtrData_270 = PHI 
  # Result$16_552 = PHI 
  # USE = nonlocal escaped { D.1224204 D.1224214 } (escaped)
  # CLB = nonlocal escaped { D.1224204 D.1224214 } (escaped)
  clang::Lexer::Lex (, );
  # PT = nonlocal escaped null { D.1224204 D.1224214 } (escaped)
  _440 = TheLexer.BufferPtr;
  # PT = nonlocal escaped null { D.1224204 D.1224214 } (escaped)
  _441 = TheLexer.BufferEnd;
  if (_440 == _441)
goto ; [5.50%]
  else
goto ; [94.50%]

with bb 146 the loop header (before dom2), so I believe Result$16_552 is never
equivalent to _143, it is equivalent to _143 from previous loop's iteration,
not the current one.

[Bug c++/109431] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field with static constexpr array inside a template constexpr function

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
Not a dup. Why is SLP emitting a vector construction in BB 2 and not BB 4?
(-fno-tree-slp-vectorize disables it):

 void dummy_write_proc ()
 {
+  void (*) () * vectp.4;
+  vector(2) long unsigned int * {ref-all} vectp_myproc.3;
+  long unsigned int _7;
+  long unsigned int _8;
+  vector(2) long unsigned int _9;
+
[local count: 1073741824]:
+  _7 = VIEW_CONVERT_EXPR(dummy_write_proc);
+  _8 = VIEW_CONVERT_EXPR(dummy_write_proc);
+  _9 = {_8, _7};
   # DEBUG BEGIN_STMT
   foo ();
   goto ; [99.96%]

[local count: 429496]:
   .ABNORMAL_DISPATCHER (0);

[local count: 1073312329]:
   # DEBUG BEGIN_STMT
-  myproc.write_proc = dummy_write_proc;
-  myproc.read_proc = dummy_write_proc;
+  MEM  [(void (*) () *)] = _9;
   return;

 }

[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Michael Meissner
:

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

commit r11-10618-g5a15a78b919c43954fbfcc90f53f34d7e2700c97
Author: Michael Meissner 
Date:   Tue Apr 11 10:11:53 2023 -0400

Backport from master

2023-04-11  Michael Meissner  

gcc/

PR target/109067
* config/rs6000/rs6000.c (create_complex_muldiv): Delete.
(init_float128_ieee): Delete code to switch complex multiply and
divide
for long double.  Backport from master, 3/20/2023.
(complex_multiply_builtin_code): New helper function.
(complex_divide_builtin_code): Likewise.
(rs6000_mangle_decl_assembler_name): Add support for mangling the
name
of complex 128-bit multiply and divide built-in functions.

gcc/testsuite/

PR target/109067
* gcc.target/powerpc/divic3-1.c: New test.  Backport from master,
3/20/2023.
* gcc.target/powerpc/divic3-2.c: Likewise.
* gcc.target/powerpc/mulic3-1.c: Likewise.
* gcc.target/powerpc/mulic3-2.c: Likewise.

[Bug ada/109472] New: [13 regression] False unread/unassigned warning for variable in local package

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 109472
   Summary: [13 regression] False unread/unassigned warning for
variable in local package
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54830=edit
Demonstrator

The compiler warns that a variable in a local package is not assigned and not
read, even though it is assigned and read in code outside the package.

GNAT 13.0.1 20230409 (experimental)
Copyright 1992-2023, Free Software Foundation, Inc.

Compiling: test_wu.adb
Source file time stamp: 2023-04-11 14:20:32
Compiled at: 2023-04-11 15:30:49

 1. procedure Test_Wu is
 2.
 3.   package P is
 4. X : Integer;
|
>>> warning: variable "X" is never read and never assigned [-gnatwu]

 5.   end;
 6.
 7.   Y : Integer;
 8.
 9. begin
10.   P.X := 5;
11.   Y := P.X;
12. end;

 12 lines: No errors, 1 warning

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

--- Comment #30 from maic  ---
This bug still exists for our project. To reproduce:


# g++ --version 
g++ (GCC) 13.0.1 20230404 (Red Hat 13.0.1-0)


# cat /tmp/2.cpp 
const int (const int , const bool ) { return i; }
int main() {
  int a;
  const auto {Select(a, true)};
}


# g++ -Wdangling-reference /tmp/2.cpp 
/tmp/2.cpp: In function ‘int main()’:
/tmp/2.cpp:4:15: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
4 |   const auto {Select(a, true)};
  |   ^
/tmp/2.cpp:4:23: note: the temporary was destroyed at the end of the full
expression ‘Select(a, true)’
4 |   const auto {Select(a, true)};
  | ~~^

[Bug libstdc++/108291] chunk_­by_­view::find-next/find-prev uses wrong lambda helper

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator

[pali at kernel dot org via Gcc-bugs]

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

--- Comment #8 from Pali Rohár  ---
So from the discussion, do I understand correctly that this is rather LD linker
issue?

[Bug target/109476] Missing optimization for 8bit/8bit multiplication / regression

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Wilhelm M  ---
Inetristingly changing the function to 


uint16_t mul(const uint8_t a, const uint16_t b) {
return static_cast((b >> 8) + 1) * a ;
}

produces optimal

mul(unsigned char, unsigned int):
subi r23,lo8(-(1))
mul r23,r24
movw r24,r0
clr __zero_reg__
ret

[Bug tree-optimization/109477] New: [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

Bug ID: 109477
   Summary: [13 regression] ICE: internal compiler error:
verify_flow_info failed (error: returns_twice call is
not first in basic block 8) when building busybox
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 54832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54832=edit
wget.i.orig

Hit this when building busybox-1.34.1 w/ 13.0.1 20230409 with checking.

```
x86_64-pc-linux-gnu-gcc -Wp,-MD,networking/.wget.o.d  -std=gnu99 -Iinclude
-Ilibbb  -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DBB_VER='"1.34.1"' -O2 -pipe
-march=native -fdiagnostics-color=always -frecord-gcc-switches -Wreturn-type
-fno-strict-aliasing -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes
-Wunused -Wunused-parameter -Wunused-function -Wunused-value
-Wmissing-prototypes -Wmissing-declarations -Wno-format-security
-Wdeclaration-after-statement -Wold-style-definition -finline-limit=0
-fno-builtin-strlen -ffunction-sections -fdata-sections
-fno-guess-branch-probability -funsigned-char -fno-unwind-tables
-fno-asynchronous-unwind-tables -fno-builtin-printf   
-DKBUILD_BASENAME='"wget"'  -DKBUILD_MODNAME='"wget"' -c -o networking/wget.o
networking/wget.c
networking/wget.c: In function ‘spawn_https_helper_openssl’:
networking/wget.c:666:12: error: returns_twice call is not first in basic block
8
  666 | static int spawn_https_helper_openssl(const char *host, unsigned port)
  |^~
bb__xvfork_pid_45 = vfork ();
during GIMPLE pass: slp
networking/wget.c:666:12: internal compiler error: verify_flow_info failed
0x7acafb verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/cfghooks.cc:285
0x1523abd execute_function_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:2110
0x1489c51 do_per_function
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:1694
0x1489c51 execute_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/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 tree-optimization/109477] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

--- Comment #1 from Sam James  ---
Created attachment 54833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54833=edit
wget.i (reduced)

[Bug fortran/104312] ICE with -ff2c in fold_convert_loc, at fold-const.cc:2451

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2023-April/059167.html

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

--- Comment #2 from Jorge Pinto Sousa  ---
> No in fact -Wformat-security is not enabled by default in the released 
> version of GCC from the FSF, the distro I know that enables it by default is 
> both Debian and Ubuntu.

Ah so the ones that come enabled by default are distro dependent. Can you point
me where, or by what option, when building from source are those enabled?

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

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

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

--- Comment #3 from Andrew Pinski  ---
>but then some warnings despite being listed there were not triggered:
https://godbolt.org/z/GGnjcjxKh


You get the trigraph warning if you don't supply any options. -std=c++14 option
enables -trigraphs option

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

Jorge Pinto Sousa  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #5 from Jorge Pinto Sousa  ---
> You get the trigraph warning if you don't supply any options. -std=c++14 
> option > enables -trigraphs option

Ok so to have it enabled again I need to -Wtrigraphs after.

So:
>  /usr/bin/gcc-8 -Q --help=warnings | grep enabled

This should give the list of warnings enabled for that specific gcc binary?

[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

[dcrocker at eschertech dot com via Gcc-bugs]

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

--- Comment #11 from David Crocker  ---
As the master branch was updated a year ago according to comment 10, does this
mean that there is now a stable release of gcc that incudes the patch?

[Bug other/109475] New: How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

Bug ID: 109475
   Summary: How to check for default compiler warnings in g++
8.4.0
   Product: gcc
   Version: 8.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jorge.pinto.sousa at proton dot me
  Target Milestone: ---

Hello,

I was trying to get the list of warnings enabled by default from gcc and where
to get that info from. Looked in to the manual and found that we could get a
list of the warnings enabled by doing:

>  /usr/bin/gcc-8 -Q --help=warnings | grep enabled
but then some warnings despite being listed there were not triggered:
https://godbolt.org/z/GGnjcjxKh

Like -Wtrigraphs for example:
> gcc -Q --help=warning | grep trigraph 
>   -Wtrigraphs   [enabled]

I then tried to compile that example locally by dumping all the flags:

>  gcc -Q -v foo.cpp
which (I think) dumps (all) the compilation and linking flags, and the only
warnings I got there are:

> options passed:  -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE foo.cpp
> -mtune=generic -march=x86-64 -Wctor-dtor-privacy
> -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
> -Wformat-security -fstack-clash-protection -fcf-protection
> options enabled:  -fPIC -fPIE -faggressive-loop-optimizations
> (...)


That is :
> -Wformat 
> -Wformat-security 

So we can say that these are the only two that are default enabled?
(I also looked into
https://gcc.gnu.org/onlinedocs/gcc-8.4.0/gcc/Option-Summary.html but could not
find any pointers).

Would like to know where one can get the correct list for these. Note that I am
not talking about -Wall or anything. Just the list of warnings that is enabled
by default, without adding any other flags.

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

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

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

--- Comment #1 from Andrew Pinski  ---
>So we can say that these are the only two that are default enabled?


No in fact -Wformat-security is not enabled by default in the released version
of GCC from the FSF, the distro I know that enables it by default is both
Debian and Ubuntu.

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
In DOM3 I see
901970   range_on_entry (Result$16_552) to BB 120
<...>
Equivalence update! :  _143 has range  :  [irange] TokenKind [22, 22] NONZERO
0x16 refining range to :[irange] TokenKind [22, 22] NONZERO 0x16
 TRUE : (901970) range_on_entry (Result$16_552) [irange] TokenKind [22,
22] NONZERO 0x16

Because it thinks they are equivlaence, its refining the range to [22,22] which
is the value of _143 on that edge
this traces back to evaluating :

# Result$16_552 = PHI <_143(160), Result$16_453(D)(158)>
where we create an equivalence between Result$16_552 and _143 from bb160.

The reason it is creating the equivalence  is because the value of
Result$16_453(D) is undefined.  It is a local automatic with no initial value. 
When evaluating PHIS, if an incoming range is UNDEFINED, we ignore that
edge/value as it can be anything we choose.
We choose to make it the same as the other argument which allows us to create
an equivlaence between the two.

unsigned short Result$16;

So this boils down to using an uninitialized value for Result$16.

Now the question is where did that come from.

void EmptyLocalizationContextChecker::MethodCrawler::VisitObjCMessageExpr
<...>
  Token Result;
  int p_count = 0;
  while (!TheLexer.LexFromRawLexer(I)) {
if (I.getKind() == tok::l_paren)
  ++p_count;
if (I.getKind() == tok::r_paren) {
  if (p_count == 1)
break;
  --p_count;
}
Result = I;
  }

IF the While loop does not execute, then result will be undefined on that edge.
 The code leading to this PHI node is 

 [local count: 488466924]:
  if (_143 == 22)
goto ; [70.13%]
  else
goto ; [29.87%]

   [local count: 251634481]:
  if (p_count_732 == 1)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 237794584]:
  p_count_88 = p_count_732 + -1;

   [local count: 726261510]:
  # p_count_45 = PHI 
  Result$UintData_449 = MEM  [(struct Token *) + 4B];
  Result$PtrData_172 = MEM  [(struct Token *) + 8B];
  _439 = TheLexer.D.700857.LexingRawMode;
  if (_439 != 0)
goto ; [99.96%]
  else
goto ; [0.04%]

   [local count: 725971006]:


So on the path to BB 160 comes from 122 which can come from 119,121 or 118.  It
seems to be using the path oracle and following a path which comes
119->120->121->122->160.And on that path, the range is indeed [22, 22],
when it ignores the undefined possibility.

Still unclear if this is wrong or not here, and if it is, whetehr ti went wrong
earlier or not.  still analyzing

[Bug tree-optimization/109477] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

--- Comment #2 from Sam James  ---
Created attachment 54834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54834=edit
wget.i (reduced further, cleaned up, check)

[Bug tree-optimization/109477] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

--- Comment #3 from Sam James  ---
See also PR109469 and PR109410.

[Bug libstdc++/109474] New: chunk_by doesn't work for ranges of proxy references

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

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

Bug ID: 109474
   Summary: chunk_by doesn't work for ranges of proxy references
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced example from Conor's tweet
(https://twitter.com/code_report/status/1645831980473282560):

#include 
#include 

void f(std::vector v) {
auto z = std::views::chunk_by(
v,
[](auto&& lhs, auto&& rhs){
return true;
});
auto i = z.begin();
}

This fails because the find_next implementation right now
(https://github.com/gcc-mirror/gcc/blob/0c5e64c4249322a178e1a0e843874e4d6b43b992/libstdc%2B%2B-v3/include/std/ranges#L6741-L6750)
passes a predicate into adjacent_find that requires both parameters be the same
type, but in this case indirect_binary_predicate is checking that it's
invocable with both value_type& (bool&) and reference
(vector::reference), which in this case are different types.

The original example was a zip_view of two ranges - which likewise would have
value_type& and reference be different.

[Bug libstdc++/108291] chunk_­by_­view::find-next/find-prev uses wrong lambda helper

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |ASSIGNED

[Bug libstdc++/108291] chunk_­by_­view::find-next/find-prev uses wrong lambda helper

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #1 from Patrick Palka  ---
*** Bug 109474 has been marked as a duplicate of this bug. ***

[Bug libstdc++/109474] chunk_by doesn't work for ranges of proxy references

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
D'oh, thanks for the bug report.  Looks like a dup of PR108291, which
unfortunately slipped through the cracks..

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

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
(In reply to Jorge Pinto Sousa from comment #2)
> Can you point me where, or by what option, when building from source are those
> enabled?

You should ask the distro for that support.


Also -Wctor-dtor-privacy is not enabled by default either.


apinski@xeond:~/src/upstream-gcc/gcc/gcc$ ~/upstream-gcc/bin/gcc -Q
--help=warning | grep ctor-dtor-privacy
  -Wctor-dtor-privacy   [available in C++, ObjC++]




https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wtrigraphs
Says:
If -Wall is not given, this option is still enabled unless trigraphs are
enabled. 

Which exactly what -std=c++14 does, it enables them.

[Bug c++/109476] New: Missing optimization for 8bit/8bit multiplication / regression

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

Bug ID: 109476
   Summary: Missing optimization for 8bit/8bit multiplication /
regression
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klaus.doldinger64 at googlemail dot com
  Target Milestone: ---

For avr-gcc > 4.6.4 the follwing function

uint16_t mul(const uint8_t a, const uint16_t b) {
return static_cast((b >> 8) + 0) * a ;
}

produces suboptimal

mul(unsigned char, unsigned int):
mov r18,r23
ldi r19,0
mov r20,r24
mul r20,r18
movw r24,r0
mul r20,r19
add r25,r0
clr __zero_reg__
ret

whereas avr-gcc 4.6.4 produces optimal

mul(unsigned char, unsigned int):
mul r23,r24
movw r24,r0
clr r1
ret

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

--- Comment #6 from Jorge Pinto Sousa  ---
Let me rephrase, Im sorry maybe I was too broad. For any specific gcc binary,

> /usr/bin/gcc-8 -Q --help=warnings | grep enabled

Will give me the list of warnings enabled by default?

[Bug tree-optimization/109471] Missing loop unrolling for small std::array?

[stefano.d at posteo dot de via Gcc-bugs]

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

--- Comment #4 from Stefano  ---
Created attachment 54829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54829=edit
source code

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

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

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

--- Comment #4 from Jakub Jelinek  ---
PR108783?
Anyway, will have a look now.

[Bug c++/109470] unexpected const & behavior

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Xi Ruoyao  ---
The standard says:

A temporary object bound to a reference parameter in a function call persists
until the completion of the full-expression containing the call.

So at the "assert" line the lifetime of the temporary object created by the
prvalue to glvalue materialization of (int)lenght has already ended.  Any
reference to the temporary is dangling and it's undefined behavior to use such
a reference.

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

--- Comment #3 from Jakub Jelinek  ---
I have tried
struct Token {
  unsigned char pad[4];
  unsigned int uintdata;
  unsigned long ptrdata;
  unsigned short kind;
  unsigned char pad2[6];
  Token () : uintdata (0), ptrdata (0), kind (0) {}
  unsigned short getKind () { return kind; }
  unsigned int getLength () { return uintdata; }
  unsigned long getLiteralData () { return ptrdata; }
};
bool bar (Token &);
bool baz (unsigned long, unsigned int);
void qux ();
static inline bool
isStringLiteral (unsigned short K)
{
  return ((unsigned short) (K + 65523U) <= 1 || K == 16 || (unsigned short) (K
+ 65519U) <= 1);
}

void
foo ()
{
  Token I;
  Token Result;
  int p_count = 0;
  while (!bar (I)) {
if (I.getKind () == 21)
  ++p_count;
if (I.getKind () == 22) {
  if (p_count == 1)
break;
  --p_count;
}
Result = I;
  }
  if (Result.getKind () == 5 || Result.getKind () == 6)
{
  if (baz (Result.getLiteralData (), Result.getLength ()))
{
  qux ();
  return;
}
}
  if (!isStringLiteral (Result.getKind ()))
return;
  baz (Result.getLiteralData (), Result.getLength ());
  __builtin_abort ();
}
but while that results in very similar IL, it doesn't reproduce that.

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-04-11
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/109473] New: ICE during GIMPLE pass: vect: verify_gimple failed with -m32

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

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

Bug ID: 109473
   Summary: ICE during GIMPLE pass: vect: verify_gimple failed
with -m32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arsen at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54831=edit
reduced reproducer

detected initially while building PipeWire, the attached code compiled with
-m32 -march=x86-64 -O1 -ftree-loop-vectorize produces an ICE:

~/gcc/scratch_build/gcc 4 $ ./cc1 -quiet ccGrpuMH.out -m32 -march=x86-64 -O1
-ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘unsigned int’ makes
pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_77 = stmp_endptr_23.18_76 + endptr_15;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0x142f352 verify_gimple_in_cfg(function*, bool, bool)
../../scratch/gcc/tree-cfg.cc:5648
0x12d1050 execute_function_todo
../../scratch/gcc/passes.cc:2098
0x12d15be execute_todo
../../scratch/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 <https://gcc.gnu.org/bugs/> for instructions.

~/gcc/scratch_build/gcc 4 $ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../scratch/configure --disable-bootstrap
--enable-checking=yes,rtl,tree --enable-languages=c,c++ --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230411 (experimental) (GCC)
~/gcc/scratch_build/gcc$ echo -n g:; git -C ../../scratch rev-parse HEAD^
g:b8e32978e3d9e3b88cd4f441edfdebfa395a5c26

(the commit applied on top of this is a maintainer-scripts/ edit)

I don't have a vanilla build of current releases/gcc-12, but it seems that it
is affected too:

~/gcc/scratch_build/gcc 1 $ gcc-12 --version
gcc-12 (Gentoo Hardened 12.2.1_p20230408 p14) 12.2.1 20230408
Copyright (C) 2022 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/scratch_build/gcc$ gcc-12 -x c -S -o - ccGrpuMH.out -m32 -march=x86-64
-O1 -ftree-loop-vectorize
.file   "ccGrpuMH.out"
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘unsigned int’ makes
pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
.text
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_77 = stmp_endptr_23.18_76 + endptr_15;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0xe96d34 verify_gimple_in_cfg(function*, bool)
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/tree-cfg.cc:5561
0xd5c927 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2085
0xd5ca51 execute_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2139
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.

but, earlier gcc-12 seems unaffected:
~/gcc/releases/gcc-12b/gcc$ ./cc1 -quiet ccGrpuMH.out -m32 -march=x86-64 -O1
-ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘unsigned int’ ma

[Bug tree-optimization/109473] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize

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

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

Arsen Arsenović  changed:

   What|Removed |Added

Summary|ICE during GIMPLE pass: |ICE during GIMPLE pass:
   |vect: verify_gimple failed  |vect: verify_gimple failed
   |with -m32   |with -O1
   ||-ftree-loop-vectorize

--- Comment #1 from Arsen Arsenović  ---
oh, actually, it seems that the reduced case no longer requires -m32:

~/gcc/scratch_build/gcc$ ./cc1 -quiet ccGrpuMH.out -O1 -ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘long unsigned int’
makes pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_110 = stmp_endptr_25.16_109 + endptr_17;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0x142f352 verify_gimple_in_cfg(function*, bool, bool)
../../scratch/gcc/tree-cfg.cc:5648
0x12d1050 execute_function_todo
../../scratch/gcc/passes.cc:2098
0x12d15be execute_todo
../../scratch/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.
~/gcc/scratch_build/gcc 4 $ gcc-12 -x c ccGrpuMH.out -O1 -ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘long unsigned int’
makes pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_108 = stmp_endptr_25.16_107 + endptr_17;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0xe96d34 verify_gimple_in_cfg(function*, bool)
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/tree-cfg.cc:5561
0xd5c927 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2085
0xd5ca51 execute_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2139
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++/98450] Inconsistent Wunused-variable warning for std::array

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

maic  changed:

   What|Removed |Added

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

--- Comment #3 from maic  ---
Fixed in 

# gcc --version 
gcc (GCC) 13.0.1 20230404 (Red Hat 13.0.1-0)

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

Bug 98450 Summary: Inconsistent Wunused-variable warning for std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98450

   What|Removed |Added

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

[Bug middle-end/82940] Suboptimal code for (a & 0x7f) | (b & 0x80) on powerpc

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/109471] Missing loop unrolling for small std::vector?

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c++ |tree-optimization

--- Comment #1 from Richard Biener  ---
I suppose both cases could be optimized the same, but we only do limited "IR
interpretation" and only as side-effect of optimizing scalarized code, not
simulated execution traces.

Needs some more investigation.

Can you please attach the source code?

[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
Trunk patched on March 20th, 2023.
Gcc 12 patched on April 10th, 2023.
Gcc 11 patched on April 11th, 2023.

[Bug tree-optimization/109473] [10/11/12/13 Regression] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |10.5
   Priority|P3  |P2
Summary|ICE during GIMPLE pass: |[10/11/12/13 Regression]
   |vect: verify_gimple failed  |ICE during GIMPLE pass:
   |with -O1|vect: verify_gimple failed
   |-ftree-loop-vectorize   |with -O1
   ||-ftree-loop-vectorize
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2023-04-11

--- Comment #2 from Jakub Jelinek  ---
Started with r10-4076-g82e8e335f917b9

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

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

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

--- Comment #13 from Alex Coplan  ---
Clang recognizes the "cxx_defaulted_functions" feature to detect whether "=
default" functions are supported.

It's clear that __has_feature (cxx_defaulted_functions) should evaluate to 1
for -std=c++11 and above. It's less clear whether GCC intends to support "=
default" functions in C++98 mode as an extension, and therefore whether
__has_extension (cxx_defaulted_functions) should evaluate to 1 with -std=c++98.

I noticed that e.g. we accept:

struct S {
int x;
S(int a) : x(a) {}
S() = default;
};
void f() {
S s;
}

with -std=c++98 and emit a -Wc++11-extensions warning. This suggests that "=
default" might be supported as an extension, but it's not clear. By contrast,
it seems that deleted functions (detected with "cxx_deleted_functions") aren't
supported in C++98 mode, since e.g.

struct S {
S() = delete;
};
void f() {
S s;
}

doesn't get rejected with -std=c++98. It would be good to get some input from
C++ maintainers on the cxx_defaulted_functions case.

[Bug target/65010] ppc backend generates unnecessary signed extension

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aagarwa at gcc dot gnu.org

[Bug target/103784] suboptimal code for returning bool value on target ppc

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

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

[Bug tree-optimization/109471] Missing loop unrolling for small std::vector?

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao  ---
(In reply to Richard Biener from comment #1)
> I suppose both cases could be optimized the same, but we only do limited "IR
> interpretation" and only as side-effect of optimizing scalarized code, not
> simulated execution traces.
> 
> Needs some more investigation.
> 
> Can you please attach the source code?

The code seems available in the godbolt link but it uses std::array, not
std::vector.

[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:40fc8e3d4f600d89e6b065d6f12db7a816269c8f

commit r13-7138-g40fc8e3d4f600d89e6b065d6f12db7a816269c8f
Author: Yanzhang Wang 
Date:   Tue Apr 11 19:37:48 2023 +0800

RISC-V: Fix regression of -fzero-call-used-regs=all [PR109104]

This patch registers a riscv specific function to
TARGET_ZERO_CALL_USED_REGS instead of default in targhooks.cc. It will
clean gpr and vector relevant registers.

gcc/ChangeLog:

PR target/109104
* config/riscv/riscv-protos.h (emit_hard_vlmax_vsetvl): New.
* config/riscv/riscv-v.cc (emit_hard_vlmax_vsetvl): New.
(emit_vlmax_vsetvl): Use emit_hard_vlmax_vsetvl.
* config/riscv/riscv.cc (vector_zero_call_used_regs): New.
(riscv_zero_call_used_regs): New.
(TARGET_ZERO_CALL_USED_REGS): New.

gcc/testsuite/ChangeLog:

PR target/109104
* gcc.target/riscv/zero-scratch-regs-1.c: New test.
* gcc.target/riscv/zero-scratch-regs-2.c: New test.
* gcc.target/riscv/zero-scratch-regs-3.c: New test.

Signed-off-by: Yanzhang Wang 
Co-authored-by: Pan Li 
Co-authored-by: Ju-Zhe Zhong 
Co-authored-by: Kito Cheng 

[Bug tree-optimization/81953] Code sinking increases register pressure

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Peter Bergner  ---
Ajit is going to start looking into this for us.

[Bug testsuite/109466] [13 regression] gfortran.dg/gomp/affinity-clause-1.f90 fails after r13-7120-g46fe32cb4d887d

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |13.0

[Bug tree-optimization/109442] Dead local copy of std::vector not removed from function

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

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

--- Comment #3 from Jonathan Wakely  ---
Ah, maybe the problem is that the library code manually elides destroying the
elements, precisely because it's a no-op. So we don't actually destroy the
elements, which means the compiler might think they're still initialized and so
could be inspected.

If the library explicitly does vec[i].~T() for every i then would that help?
The compiler would know there are no valid elements in the storage, and so
nothing operator delete could inspect.

We could continue to elide destroying the elements when !defined __OPTIMIZE__
so that we don't run a loop that does nothing, but with optimization enabled
rely on the compiler to remove that loop.

[Bug tree-optimization/109471] Missing loop unrolling for small std::array?

[stefano.d at posteo dot de via Gcc-bugs]

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

--- Comment #3 from Stefano  ---
(In reply to Xi Ruoyao from comment #2)
> The code seems available in the godbolt link but it uses std::array, not
> std::vector.

I'm sorry. I mean std::array of course. :-/

[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2023-April/059166.html

[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 CC||anlauf at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=61615
 Status|NEW |ASSIGNED

--- Comment #6 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2023-April/059166.html

[Bug middle-end/41742] Unnecessary zero-extension at -O2 but not -O1

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED