[Bug tree-optimization/107323] [10/11 Regression] Loop distribute issue

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hahnjo at hahnjo dot de

--- Comment #12 from Richard Biener  ---
*** Bug 108008 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/108008] [12 Regression] wrong code with -O3 and posix_memalign since r12-4526-gd8edfadfc7a9795b

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #15 from Richard Biener  ---
Duplicate then.

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

[Bug target/108322] Using __restrict parameter with -ftree-vectorize (default with -O2) results in massive code bloat

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

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

--- Comment #5 from Alexander Monakov  ---
(In reply to Richard Biener from comment #4)
> 
> For the case at hand loading two vectors from the destination and then
> punpck{h,l}bw and storing them again might be the most efficient thing
> to do here.

I think such read-modify-write on the destination introduces a data race for
bytes that are not accessed in the original program, so that would be okay only
under -fallow-store-data-races?

[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero when CTZ_DEFINED_VALUE_AT_ZERO says it is undefined

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #7 from LIU Hao  ---
(In reply to Jakub Jelinek from comment #4)
> I think 0 argument for __builtin_c[lt]z{,l,ll,imax} is always undefined, 0
> argument
> to .C[LT]Z (internal calls) is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is
> not 2 and
> 0 argument to C[LT]Z RTL is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is not
> non-zero.

I agree with this.


#94801 mentioned the `if(value == 0) __builtin_unreachable();` trick, but it
isn't an option if the argument is really possibly a zero:

(https://gcc.godbolt.org/z/dePvcMhTr)
```
#include 

uint32_t
my_tzcnt(uint32_t value)
  {
return (value == 0) ? 32 : __builtin_ctz(value);
  }
```

This can be TZCNT if the CPU supports it.

[Bug libstdc++/108331] [13 Regression] ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292

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

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

--- Comment #3 from Kewen Lin  ---
There seem to be two alternatives to fix this, one is to raise error in
rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
something like mma_return_type_error to avoid re-erroring; the other is to
teach the function rs6000_opaque_type_invalid_use_p about function call
statement on arguments and return values. For now, the argument and return
value checking is against the modes directly rather than the types, maybe to
unique them into rs6000_opaque_type_invalid_use_p is better?

Hi @Segher and @Peter, what do you think of this?

[Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292

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

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

--- Comment #4 from Kewen Lin  ---
(In reply to Kewen Lin from comment #3)
> There seem to be two alternatives to fix this, one is to raise error in
> rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
> something like mma_return_type_error to avoid re-erroring; the other is to
> teach the function rs6000_opaque_type_invalid_use_p about function call
> statement on arguments and return values. For now, the argument and return
> value checking is against the modes directly rather than the types, maybe to
> unique them into rs6000_opaque_type_invalid_use_p is better?
> 
> Hi @Segher and @Peter, what do you think of this?


Ah, the later is a bad idea, as the current checking is for non MMA but the
function argument and return values checking should happen all the time. With
further thinking, the fix can be: (always return false for MMA modes, let
rs6000_function_arg to raise error msg.)

diff --git a/gcc/config/rs6000/rs6000-call.cc
b/gcc/config/rs6000/rs6000-call.cc
index 59c51fa3579..6767a1f541c 100644
--- a/gcc/config/rs6000/rs6000-call.cc
+++ b/gcc/config/rs6000/rs6000-call.cc
@@ -2013,6 +2013,11 @@ rs6000_pass_by_reference (cumulative_args_t, const
function_arg_info &arg)
 {
   if (TARGET_DEBUG_ARG)
 fprintf (stderr, "function_arg_pass_by_reference: AltiVec\n");
+  /* We do not allow MMA types being used as function arguments,
+ return false to avoid the ICE on the copying for passing by
+ reference.  */
+  if (TYPE_MODE (arg.type) == OOmode || TYPE_MODE (arg.type) == XOmode)
+return 0;
   return 1;
 }

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #13 from Richard Biener  ---
(In reply to Aldy Hernandez from comment #12)
> (In reply to Richard Biener from comment #6)
> > (In reply to Jakub Jelinek from comment #0)
> > > ... but then
> > > comes dom2 and happily replaces
> > >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> > >   return _1;
> > > with
> > >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> > >   return  Inf;
> > > (I think this is still correct)
> > 
> > Note this is also a pessimization code-generation wise since if we
> > preserve the multiplication the result is readily available in a
> > register but as optimized we have another constant pool entry and load.
> > 
> > So we might want to consider not propagating constants generated by
> > operations
> > we cannot eliminate.  If the only consumer is a compare-and-branch we
> > can of course still end up with a seemingly dead stmt, so this would be only
> > for the missed optimization.
> 
> [Sorry for the delayed response.  I've been on PTO.]
> 
> For the original testcase, the propagation happens in DOM:
> 
>[local count: 1073741824]:
>   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
>   return _1;
> 
> range_of_expr gets called on the return's _1 and correctly returns Inf,
> which allows cprop_operand to do the replacement.
> 
> If I understand correctly you're suggesting not propagating constants that
> were generated by an operation we can't eliminate.  In this case, it'd be
> easy to chase the DEF back to the offending _1 definition (from
> cprop_operand and every other places where we do propagations based on
> range_of_expr's result), but ranger doesn't keep track of how it got to an
> answer, so we'd have to chase all operands used to generate _1??  That'd get
> hairy pretty fast, unless I'm misunderstanding something.

Yes, the fact that ranger doesn't operate as a usual propagator with a lattice
makes things very difficult here.  Note that my comment referred to code
optimality, not correctness.

> It really looks like the problem here is DCE (and the gimplifier as you
> point out in comment #2), which is removing a needed statement.  Can't this
> be fixed there?

Sure it can, but the expense is that we'd do constant folding all the way
down and not remove dead code which will result in _tons_ of unnecessary
constant pool entries and loads.

The issue is also that -ftrapping-math is default on so we'd have to
do this by default.  Ugh.

Note that the constant folding routines generally refrain from folding
when that loses exceptions, it's just ranger when producing singleton
ranges and propagating from them that doesn't adhere to that implicit rule.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #14 from Richard Biener  ---
const_binop has

  /* Don't constant fold this floating point operation if
 the result has overflowed and flag_trapping_math.  */
  if (flag_trapping_math
  && MODE_HAS_INFINITIES (mode)
  && REAL_VALUE_ISINF (result)
  && !REAL_VALUE_ISINF (d1)
  && !REAL_VALUE_ISINF (d2))
return NULL_TREE;

[Bug middle-end/69482] Writing through pointers to volatile not always preserved

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

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

Richard Biener  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71793

--- Comment #13 from Richard Biener  ---
(In reply to Daniel Boles from comment #12)
> Is this the same cause as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71793
> ?

I think so but I found the testcase in that PR hard to validate with the fix,
so if you can confirm the issue is fixed there with the change that would be
great!

[Bug target/108322] Using __restrict parameter with -ftree-vectorize (default with -O2) results in massive code bloat

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 10 Jan 2023, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
> 
> --- Comment #5 from Alexander Monakov  ---
> (In reply to Richard Biener from comment #4)
> > 
> > For the case at hand loading two vectors from the destination and then
> > punpck{h,l}bw and storing them again might be the most efficient thing
> > to do here.
> 
> I think such read-modify-write on the destination introduces a data race for
> bytes that are not accessed in the original program, so that would be okay 
> only
> under -fallow-store-data-races?

Yes, obviously.

[Bug target/107843] error: incompatible type for argument in ___bpf_ctx_cast2

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #3 from Jose E. Marchesi  ---
clang/llvm confirms that clang 15 behaves like GCC, emitting the same error.
So I am closing this issue.

[Bug fortran/108349] New: LTO mismatch for __builtin_realloc between glibc and gfortran frontend

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 108349
   Summary: LTO mismatch for __builtin_realloc between glibc and
gfortran frontend
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

$ cat foo.f90
program foo
end program

module buffer
 integer,allocatable :: mpi_ids(:)
contains
 subroutine method(ids)
  integer,intent(in) :: ids(:)
  mpi_ids=ids
 end subroutine
end module

$ cat bar.c
#include "stdlib.h"
void bar(void *ptr){ptr = realloc(ptr,6);}

$ gfortran -flto foo.f90 bar.c # no warning given
$ gfortran -flto bar.c foo.f90
: warning: type of ‘__builtin_realloc’ does not match original
declaration [-Wlto-type-mismatch]
/usr/include/stdlib.h:564:14: note: type mismatch in parameter 1
  564 | extern void *realloc (void *__ptr, size_t __size)
  |  ^
/usr/include/stdlib.h:564:14: note: ‘realloc’ was previously declared here
/usr/include/stdlib.h:564:14: note: code may be misoptimized unless
‘-fno-strict-aliasing’ is used

Why diagnostic is given depending on sources (or objects) order?

No diagnostic is provided if type arguments are swapped in
gcc/fortran/f95-lang.cc:996

[Bug tree-optimization/108314] [13 Regression] Segfault in gimple-match-head.cc:do_valueize when vectorizing for SVE since r13-707-g68e0063397ba82

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

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

--- Comment #3 from Richard Biener  ---
(gdb) p debug_gimple_stmt (stmt)
t_5 = .FOLD_EXTRACT_LAST (t_14, _41, );

there's a missing call argument, the call is built here:

#0  vectorizable_condition (vinfo=0x3b67200, stmt_info=0x3c3d160, 
gsi=0x7fffcad0, vec_stmt=0x7fffc8a8, slp_node=0x0, cost_vec=0x0)
at /home/rguenther/src/trunk/gcc/tree-vect-stmts.cc:10763
10763 new_stmt = gimple_build_call_internal
(gdb) l
10758 gimple *new_stmt;
10759 if (reduction_type == EXTRACT_LAST_REDUCTION)
10760   {
10761 gimple *old_stmt = vect_orig_stmt (stmt_info)->stmt;
10762 tree lhs = gimple_get_lhs (old_stmt);
10763 new_stmt = gimple_build_call_internal
10764 (IFN_FOLD_EXTRACT_LAST, 3, else_clause, vec_compare,
10765  vec_then_clause);
10766 gimple_call_set_lhs (new_stmt, lhs);
10767 SSA_NAME_DEF_STMT (lhs) = new_stmt;
(gdb) p vec_then_clause
$13 = 

which is because we run into

  else if (bitop2 == BIT_NOT_EXPR)
{
  /* Instead of doing ~x ? y : z do x ? z : y.  */
  vec_compare = new_temp;
  std::swap (vec_then_clause, vec_else_clause);

but vec_else_clause isn't initialized for EXTRACT_LAST_REDUCTION.  Instead
we should swap with else_clause here?

It seems to me I've seen this before ...

Note that if we swap we fail to expand the internal function which seems to
want the scalar/vector args in specific places and _not_ support this
inversion.  So instead avoid doing this optimization.

[Bug driver/108350] New: Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm via Gcc-bugs]

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

Bug ID: 108350
   Summary: Windows: invoking gcc via symlink does not work
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu.org at billz dot fastmail.fm
  Target Milestone: ---

PROBLEM

On Windows if I invoke gcc via a symlink, then it is unable to work. This
appears to happen because it computes the wrong prefix.

The steps to reproduce are:

- Install mingw gcc from https://github.com/niXman/mingw-builds

- Open a powershell prompt.

- Execute: `cmd /c mklink gcc.exe \gcc.exe`. This command
creates a symlink on Windows, which requires Administrator or Developer mode to
be enabled.

- Execute: `ni a.c`. This command creates an empty file `a.c`.

- Execute: `.\gcc.exe a.c`. This command fails with "fatal error: cannot
execute 'cc1': CreateProcess: No such file or directory".

- Execute: `.\gcc.exe -print-search-dirs`. This command prints directories
relative to the location of the symlink, rather than the gcc installation path.

The expected behavior is for `gcc` to work regardless of whether it is invoked
via a symlink or not, because I did not supply the `-no-canonical-prefixes`
option.

This problem was originally reported against the mingw-builds repository, but
investigation showed that the problem is likely with gcc.


INVESTIGATION

Investigation showed that gcc prefixes are handled in `process_command`
(gcc/gcc.cc). When the `-no-canonical-prefixes` option is not supplied prefix
resolution happens in `make_relative_prefix` (libiberty/make-relative-prefix.c)
which calls `lrealpath` (libiberty/lrealpath.c).

On Windows `lrealpath` calls `GetFullPathName` which unfortunately does *not*
do symlink resolution.


FIX

The most straightforward fix is to change `lrealpath` to use
`GetFinalPathNameByHandle` instead of `GetFullPathName`.


For the original issue report and an alternative view of this issue please see
here: https://github.com/niXman/mingw-builds/issues/633

[Bug fortran/108349] LTO mismatch for __builtin_realloc between glibc and gfortran frontend

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-01-10
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code

--- Comment #1 from Richard Biener  ---
Confirmed - the Fortran frontend type is wrong (oops).

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

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

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

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

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

commit r13-5079-gb39f4333d18cc58b1a655c537a78fefe95b82609
Author: Jonathan Wakely 
Date:   Mon Jan 9 10:45:31 2023 +

libstdc++: Fix std::span constraint for sizeof(size_t) < sizeof(int)
[PR108221]

The default constructor has a constraint that is always false if
arithmetic on size_t values promotes to int. Rewrite the constraint
exactly as written in the standard, which works correctly.

libstdc++-v3/ChangeLog:

PR libstdc++/108221
* include/std/span (span::span()): Un-simplify constraint to
work for size_t of lesser rank than int.

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

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

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

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

https://gcc.gnu.org/g:769fae76dfd71045fe062e7b1edef0f59e50371d

commit r13-5080-g769fae76dfd71045fe062e7b1edef0f59e50371d
Author: Jonathan Wakely 
Date:   Mon Jan 9 10:45:31 2023 +

libstdc++: Fix some algos for 16-bit size_t [PR108221]

Some standard algorithms fail to compile when size_t or ptrdiff_t is
narrower than int. The __lg helper function is ambiguous if ptrdiff_t is
short or __int20, so replace it with a function template that works for
those types as well as signed/unsigned int/long/long long. The helpers
for stable_sort perform arithmetic on size values and assume the types
won't change, which isn't true if the type promotes to int.

libstdc++-v3/ChangeLog:

PR libstdc++/108221
* include/bits/stl_algobase.h (__lg): Replace six overloads with
a single function template for all integer types.
* include/bits/stl_algo.h (__merge_adaptive_resize): Cast
arithmetic results back to _Distance.

[Bug fortran/108349] LTO mismatch for __builtin_realloc between glibc and gfortran frontend

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Caused by r0-100026-gb64fca63690ad6042bea, before that it was
  tmp = tree_cons (NULL_TREE, pvoid_type_node, void_list_node);
  tmp = tree_cons (NULL_TREE, size_type_node, tmp);
  ftype = build_function_type (pvoid_type_node, tmp);
which is correct.  Let me eyeball the other changes in that commit.

[Bug fortran/108349] LTO mismatch for __builtin_realloc between glibc and gfortran frontend

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

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

--- Comment #3 from Jakub Jelinek  ---
Seems e.g. sincos* have wrong prototypes since that revision too.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #15 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #13)

> Note that the constant folding routines generally refrain from folding
> when that loses exceptions, it's just ranger when producing singleton
> ranges and propagating from them that doesn't adhere to that implicit rule.

We already have similar restrictions to avoid folding relational operators when
NANs are present.  I suppose we could add the same restriction to the generic
frange folder (range_operator_float::fold_range) as the const_binop snippet you
quoted down-thread.

Thanks for the explanation and the const_binop example.  This makes it much
clearer.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

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

Perhaps this would work.  It solves the testcase, though I think we should
probably audit the operators that don't use the generic
range_operator_float::fold_range to make sure they're not doing anything silly.

Note that we could add similar code whenever we drop to a NAN like const_binop
does:

  /* Don't constant fold this floating point operation if
 both operands are not NaN but the result is NaN, and
 flag_trapping_math.  Such operations should raise an
 invalid operation exception.  */
  if (flag_trapping_math
  && MODE_HAS_NANS (mode)
  && REAL_VALUE_ISNAN (result)
  && !REAL_VALUE_ISNAN (d1)
  && !REAL_VALUE_ISNAN (d2))
return NULL_TREE;

I avoided doing so because an frange of NAN does not count as a singleton so it
should never be propagated.  If this is a problem, I could add a similar tweak.

What do y'all think?

[Bug target/108140] ICE expanding __rbit

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Kyrylo Tkachov
:

https://gcc.gnu.org/g:849c3cf7b4189342b4a0df941afddf8327585570

commit r12-9037-g849c3cf7b4189342b4a0df941afddf8327585570
Author: Kyrylo Tkachov 
Date:   Mon Dec 19 11:16:47 2022 +

aarch64: PR target/108140 Handle NULL target in data intrinsic expansion

In this PR we ICE when expanding the __rbit builtin with a NULL target rtx.
I *think* that only happens when the result is unused and hence maybe we
shouldn't be expanding
any RTL at all, but the ICE here is easily fixed by deriving the mode from
the type of the expression
rather than the target.

This patch does that.
Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/ChangeLog:

PR target/108140
* config/aarch64/aarch64-builtins.cc
(aarch64_expand_builtin_data_intrinsic): Handle NULL target.

gcc/testsuite/ChangeLog:

PR target/108140
* gcc.target/aarch64/acle/pr108140.c: New test.

(cherry picked from commit 98756bcbe27647f263f2b312d1d933d70cf56ba9)

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #1 from niXman  ---

> FIX
> 
> The most straightforward fix is to change `lrealpath` to use
> `GetFinalPathNameByHandle` instead of `GetFullPathName`.

thanks for the investigation!
will do it now.

[Bug tree-optimization/108314] [13 Regression] Segfault in gimple-match-head.cc:do_valueize when vectorizing for SVE since r13-707-g68e0063397ba82

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #4 from Richard Biener  ---
patch posted

[Bug tree-optimization/108314] [13 Regression] Segfault in gimple-match-head.cc:do_valueize when vectorizing for SVE since r13-707-g68e0063397ba82

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

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

Richard Biener  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106476

--- Comment #5 from Richard Biener  ---
And PR106476 is the duplicate I was thinking of.

[Bug tree-optimization/106476] ICE generating FOLD_EXTRACT_LAST

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-10
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Richard Biener  ---
I've posted a patch.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #17 from Richard Biener  ---
(In reply to Aldy Hernandez from comment #16)
> Created attachment 54224 [details]
> untested patch
> 
> Perhaps this would work.  It solves the testcase, though I think we should
> probably audit the operators that don't use the generic
> range_operator_float::fold_range to make sure they're not doing anything
> silly.
> 
> Note that we could add similar code whenever we drop to a NAN like
> const_binop does:
> 
>   /* Don't constant fold this floating point operation if
>both operands are not NaN but the result is NaN, and
>flag_trapping_math.  Such operations should raise an
>invalid operation exception.  */
>   if (flag_trapping_math
> && MODE_HAS_NANS (mode)
> && REAL_VALUE_ISNAN (result)
> && !REAL_VALUE_ISNAN (d1)
> && !REAL_VALUE_ISNAN (d2))
>   return NULL_TREE;
> 
> I avoided doing so because an frange of NAN does not count as a singleton so
> it should never be propagated.  If this is a problem, I could add a similar
> tweak.
> 
> What do y'all think?

I suppose it's a good workaround for now and consistent with what CCP
would end up doing.  Ideally we wouldn't restrict lattice propagation
so we can perform simplification of uses (esp. in conditionals) but
just prevent folding the actual computation that causes the overflow
(thus catch it at propagation stage).  As you say how ranger works doesn't
easily allow that, unfortunately.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #18 from Jakub Jelinek  ---
See #c10, I think even with comparisons we need to be careful.  One thing is
whether we can prove one of the branches will be unreachable, we can do that
and replace that branch with __builtin_unreachable, but if trapping math is on,
if a comparison is possibly trapping (operands could be NAN as checked by
frange) or if it is the last use of some SSA_NAME that needs to be kept live
because its computation is possibly trapping, I think we need to preserve the
comparison.
One question is if the default -ftrapping-math should cover all exceptions or
just the some subset, invalid/overflow are the worst ones, then underflow and
least importance is inexact IMHO, pretty much anything can be inexact...

[Bug fortran/108349] LTO mismatch for __builtin_realloc between glibc and gfortran frontend

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54225&action=edit
gcc13-pr108349.patch

Untested fix.

[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute

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

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

--- Comment #12 from Eric Botcazou  ---
> How are the bits numbered in there, IOW is bit 0 always the LSB or not?

Answering to myself: no, they are numbered in memory order, which is
problematic because, in the implementation model, stand-alone scalars do not
have storage order and are only considered as values, so this breaks the model.

I think that Andreas' latest patch does not work in the opposite case, namely a
little-endian structure on a big-endian platform:

  dst$val_9 = _1;
  _2 = BIT_FIELD_REF ;

In this case BIT_FIELD_REF  would refer to the MSB, but the
assignment dst$val_9 = _1 assigns the interesting bit to the LSB as always for
stand-alone scalar, so we would need to preserve the swapping.

[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #13 from Eric Botcazou  ---
Fixing.

[Bug modula2/108182] gm2 driver mishandles target and multilib options

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

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

--- Comment #12 from Iain Sandoe  ---

unfortunately, neither this nor the v4.1 (WIP) is still quite right.

Using LIBDIR in the computation of the include paths means that the compiler
does not work when it is relocated .. the directory prefix needs to be computed
at runtime.

[Bug libstdc++/108331] [13 Regression] ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/108351] New: Dead Code Elimination Regression at -O3 (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108351
   Summary: Dead Code Elimination Regression at -O3 (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

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

cat case.c #51
struct a {
  int b;
} b;
static short c = 7, d, e, a, k;
int g;
struct a h;
int i;
int j;
void foo();
static struct a f(int l, unsigned short m) {
  a = e;
  k = d = j < i;
  if (m)
return h;
  foo();
  return b;
}
int main() {
  for (; g;)
f(1, c);
  f(7, 7);
  f(9, 7);
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O3` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O3` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O3 -S -o /dev/stdout
case.c`
- OUTPUT -
f.isra.0:
.LFB3:
.cfi_startproc
testw   %di, %di
je  .L4
ret
.p2align 4,,10
.p2align 3
.L4:
xorl%eax, %eax
jmp foo
.cfi_endproc
.LFE3:
.size   f.isra.0, .-f.isra.0
.section.text.startup,"ax",@progbits
.p2align 4
.globl  main
.type   main, @function
main:
.LFB1:
.cfi_startproc
movlg(%rip), %eax
testl   %eax, %eax
je  .L6
.L7:
jmp .L7
.p2align 4,,10
.p2align 3
.L6:
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$7, %edi
callf.isra.0
movl$7, %edi
callf.isra.0
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O3 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movlg(%rip), %eax
testl   %eax, %eax
je  .L4
.L5:
jmp .L5
.p2align 4,,10
.p2align 3
.L4:
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=feeb0d68f1c7085199c3734e6517a3a4b58309ef

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

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

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

--- Comment #17 from Jonathan Wakely  ---
Please try current master, I think the errors for h8300-elf and msp430-elf
should be fixed (but I still get the assembler errors for h8300-elf using
latest binutils).

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #19 from rguenther at suse dot de  ---
On Tue, 10 Jan 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
> 
> --- Comment #18 from Jakub Jelinek  ---
> See #c10, I think even with comparisons we need to be careful.  One thing is
> whether we can prove one of the branches will be unreachable, we can do that
> and replace that branch with __builtin_unreachable, but if trapping math is 
> on,
> if a comparison is possibly trapping (operands could be NAN as checked by
> frange) or if it is the last use of some SSA_NAME that needs to be kept live
> because its computation is possibly trapping, I think we need to preserve the
> comparison.
> One question is if the default -ftrapping-math should cover all exceptions or
> just the some subset, invalid/overflow are the worst ones, then underflow and
> least importance is inexact IMHO, pretty much anything can be inexact...

I suppose similar to -fdelete-dead-exceptions with EH we need some
-fdelete-dead-traps (that's bad wording) and at least have that on by
default.  I think the standard mandates #pragma FENV_ACCESS on if you
want to inspect the IEEE exception state, and our defaulting mix
(-ftrapping-math but -fno-rounding-math) doesn't make sense in this
respect and the documentation is not clear (or my english is bad) here:

"This command-line option
will be used along with @option{-frounding-math} to specify the
default state for @code{FENV_ACCESS}."

How does "along with" specify how the "default state for FENV_ACCESS"
is "computed"?

[Bug tree-optimization/108314] [13 Regression] Segfault in gimple-match-head.cc:do_valueize when vectorizing for SVE since r13-707-g68e0063397ba82

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:554bb9b61e2b76d4ace16a3f766b98ea887b17f4

commit r13-5089-g554bb9b61e2b76d4ace16a3f766b98ea887b17f4
Author: Richard Biener 
Date:   Tue Jan 10 10:42:21 2023 +0100

tree-optimization/108314 - avoid BIT_NOT optimization for extract-last

The extract-last reduction internal function expects the then and
else clause as vector and scalar and thus we cannot perform optimization
of the inversion of the condition by swapping the then/else clauses.

PR tree-optimization/108314
* tree-vect-stmts.cc (vectorizable_condition): Do not
perform BIT_NOT_EXPR optimization for EXTRACT_LAST_REDUCTION.

* gcc.dg/vect/pr108314.c: New testcase.

[Bug tree-optimization/108314] [13 Regression] Segfault in gimple-match-head.cc:do_valueize when vectorizing for SVE since r13-707-g68e0063397ba82

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/106476] ICE generating FOLD_EXTRACT_LAST

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Richard Biener  ---
Fixed by r13-5089-g554bb9b61e2b76d4ace16a3f766b98ea887b17f4 on trunk.

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.2.0)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O3 (trunk|Elimination Regression at
   |vs. 12.2.0) |-O3 (trunk vs. 12.2.0)

[Bug tree-optimization/106293] [13 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

[yann at ywg dot ch via Gcc-bugs]

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

Yann Girsberger  changed:

   What|Removed |Added

 CC||yann at ywg dot ch

--- Comment #6 from Yann Girsberger  ---
I found a DCE Regression in trunk that bisects to the same commit as in the
original report.
It seems to be present in -Ofast and -O2.
Let me know if this should be a new report. 

cat case.c #14
int a;
static long b = 4073709551612, d;
short c;
void foo();
static char e(int **f) {
  **f = 0;
  if (a) {
unsigned long *g = &b;
unsigned long **h = &g;
for (; d;) {
  foo();
  for (; c;) {
unsigned long ***i = &h;
  }
}
  }
  return 1;
}
int main() {
  int *j = &a;
  e(&j);
  if (b <= 0)
foo();
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
cmpq$0, b(%rip)
movl$0, a(%rip)
jle .L8
xorl%eax, %eax
ret
.L8:
pushq   %rax
.cfi_def_cfa_offset 16
xorl%eax, %eax
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movl$0, a(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d2a89809452ef79a14feae1cadc3538e4b45

[Bug tree-optimization/108352] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108352
   Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54227&action=edit
Code as file

cat case.c #30
long a;
int b;
void bar64_(void);
void foo();
int main() {
  char c = 0;
  unsigned d = 10;
  int e = 2;
  for (; d; d--) {
bar64_();
b = d;
e && (c = (e = 0) != 4) > 1;
  }
  if (c < 1)
foo();
  a = b;
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
pushq   %r13
.cfi_def_cfa_offset 16
.cfi_offset 13, -16
movl$1, %r13d
pushq   %r12
.cfi_def_cfa_offset 24
.cfi_offset 12, -24
movl$2, %r12d
pushq   %rbp
.cfi_def_cfa_offset 32
.cfi_offset 6, -32
xorl%ebp, %ebp
pushq   %rbx
.cfi_def_cfa_offset 40
.cfi_offset 3, -40
movl$10, %ebx
subq$8, %rsp
.cfi_def_cfa_offset 48
.p2align 4,,10
.p2align 3
.L3:
callbar64_
testl   %r12d, %r12d
movl%ebx, b(%rip)
cmovne  %r13d, %ebp
xorl%r12d, %r12d
subl$1, %ebx
jne .L3
movl$1, %eax
testb   %bpl, %bpl
je  .L10
.L4:
movq%rax, a(%rip)
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 40
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 32
popq%rbp
.cfi_def_cfa_offset 24
popq%r12
.cfi_def_cfa_offset 16
popq%r13
.cfi_def_cfa_offset 8
ret
.L10:
.cfi_restore_state
xorl%eax, %eax
callfoo
movslq  b(%rip), %rax
jmp .L4
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$10, %ebx
callbar64_
movl$10, %eax
jmp .L3
.p2align 4,,10
.p2align 3
.L6:
callbar64_
movl%ebx, %eax
.L3:
movl%eax, b(%rip)
subl$1, %ebx
jne .L6
movq$1, a(%rip)
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d86d81a449c03641e079f23a2b3e1b2279a162fe

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm via Gcc-bugs]

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

--- Comment #2 from Bill Zissimopoulos  ---
(In reply to niXman from comment #1)
> > The most straightforward fix is to change `lrealpath` to use
> > `GetFinalPathNameByHandle` instead of `GetFullPathName`.
> 
> thanks for the investigation!
> will do it now.

Thank you!

FYI `GetFinalPathNameByHandle` is known to fail on drives that are created via
`DefineDosDevice` (e.g. via the SUBST command). So I recommend using
`GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
fails.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #3 from niXman  ---
(In reply to Bill Zissimopoulos from comment #2)
> (In reply to niXman from comment #1)
> > > The most straightforward fix is to change `lrealpath` to use
> > > `GetFinalPathNameByHandle` instead of `GetFullPathName`.
> > 
> > thanks for the investigation!
> > will do it now.
> 
> Thank you!
> 
> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> fails.

got it, thanks!

[Bug tree-optimization/108353] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108353
   Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54228&action=edit
presented code as file

cat case.c #99
enum { a } b();
int d;
int e;
int f;
void foo();
void bar49_(void);
void(c)();
static short g(int h, int i) {
  int j = 2874288693, k = 1;
  if (h)
for (; j; j = j + 9) {
  f = 0;
  for (; f <= 1; c())
k = 90;
}
  i = k;
  for (; e; ++e) {
if (i)
  continue;
foo();
i = b();
  }
  return 4;
}
int l() {
  bar49_();
  return 1;
}
int main() { d = d || g(d, l()); }

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movld(%rip), %eax
testl   %eax, %eax
je  .L20
movl$1, d(%rip)
xorl%eax, %eax
ret
.L20:
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
callbar49_
cmpl$0, d(%rip)
jne .L12
movl$1, %eax
.L9:
cmpl$0, e(%rip)
je  .L5
.L7:
addl$1, e(%rip)
je  .L5
.L11:
testl   %eax, %eax
jne .L7
callfoo
xorl%eax, %eax
callb
addl$1, e(%rip)
jne .L11
.L5:
movl$1, d(%rip)
xorl%eax, %eax
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L12:
.cfi_restore_state
movl$1112290355, %ebx
.p2align 4,,10
.p2align 3
.L6:
movl$0, f(%rip)
.p2align 4,,10
.p2align 3
.L8:
xorl%eax, %eax
callc
cmpl$1, f(%rip)
jle .L8
subl$1, %ebx
jne .L6
movl$90, %eax
jmp .L9
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movld(%rip), %eax
testl   %eax, %eax
je  .L19
movl$1, d(%rip)
xorl%eax, %eax
ret
.L19:
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
callbar49_
cmpl$0, d(%rip)
je  .L11
movl$1112290355, %ebx
.p2align 4,,10
.p2align 3
.L7:
movl$0, f(%rip)
.p2align 4,,10
.p2align 3
.L10:
xorl%eax, %eax
callc
cmpl$1, f(%rip)
jle .L10
subl$1, %ebx
jne .L7
.L11:
cmpl$0, e(%rip)
je  .L6
movl$0, e(%rip)
.L6:
movl$1, d(%rip)
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=af96500eea72c674a5686b35c66202ef2bd9688f

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #4 from niXman  ---

> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> fails.

could you give me a hint, what should I use for `dwFlags` param for
`GetFinalPathNameByHandle()` ? (because for me all the options are
incomprehensible)

because according to your github profile it looks like you are Windows
developer :)

https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea#parameters


thanks!

[Bug tree-optimization/108354] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108354
   Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54229&action=edit
presented code as file

cat case.c #617
int b;
int *c;
int e;
static int *f = &e;
int g;
void foo();
short(a)(short h, short i) { return h - i; }
int(d)(int h) { return h == 83647 ? 0 : -h; }
int main() {
  short j;
  int *k = &e, *l = &b;
  *f = 0 == c;
  j = a(0 != 2, *k);
  if (d(j ^ (0 == l || *k)) != *k)
;
  else
foo();
  c = &g;
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
xorl%eax, %eax
cmpq$0, c(%rip)
setne   %dl
sete%al
movzbl  %dl, %edx
movl%eax, e(%rip)
orl %eax, %edx
je  .L12
movq$g, c(%rip)
xorl%eax, %eax
ret
.L12:
pushq   %rax
.cfi_def_cfa_offset 16
xorl%eax, %eax
callfoo
xorl%eax, %eax
movq$g, c(%rip)
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
xorl%eax, %eax
cmpq$0, c(%rip)
movq$g, c(%rip)
sete%al
movl%eax, e(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b3e98eb3396e16ae8b20c94916bc2bd7862d2c97

[Bug tree-optimization/106293] [13 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Interesting.  It seems that early DSE is hindered by the extra PHI, possibly
not
reaching the CLOBBER.

@@ -24,6 +24,8 @@
 goto ; [INV]

:
+  # .MEM_10 = VDEF <.MEM_9>
+  g = &b;
   goto ; [INV]

:
@@ -39,7 +41,7 @@
 goto ; [INV]

:
-  # .MEM_5 = PHI <.MEM_9(3), .MEM_14(5)>
+  # .MEM_5 = PHI <.MEM_10(3), .MEM_14(5)>
   # VUSE <.MEM_5>
   d.3_4 = d;
   if (d.3_4 != 0)
@@ -48,7 +50,8 @@
 goto ; [INV]

:
-  # .MEM_12 = VDEF <.MEM_5>
+  # .MEM_17 = PHI <.MEM_5(6)>
+  # .MEM_12 = VDEF <.MEM_17>
   g ={v} {CLOBBER(eol)};

[Bug tree-optimization/108355] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108355
   Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54230&action=edit
presented code as file

cat case.c #551
int a;
int *b = &a;
int **c = &b;
int d;
void bar25_(void);
void foo(void);
int main() {
  int e[][1] = {0, 0, 0, 0, 0, 1};
  for (;;) {
bar25_();
if (e[5][a])
  break;
e[a][0] = 0;
foo();
  }
  *c = &d;
}
`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movl$1, 20(%rsp)
jmp .L3
.p2align 4,,10
.p2align 3
.L6:
movl$0, (%rsp,%rax,4)
callfoo
.L3:
callbar25_
movslq  a(%rip), %rax
movl20(%rsp,%rax,4), %edx
testl   %edx, %edx
je  .L6
movqc(%rip), %rax
movq$d, (%rax)
xorl%eax, %eax
addq$40, %rsp
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callbar25_
movqc(%rip), %rax
movq$d, (%rax)
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9baee6181b4e427e0b5ba417e51424c15858dce7

[Bug tree-optimization/108356] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108356
   Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54231&action=edit
presented code as file

cat case.c #93
char a;
static char c = 3;
char d;
void foo();
short(b)(short e, short f) { return e + f; }
int main() {
  unsigned g = 0;
  if (c)
;
  else
foo();
  for (; g < 2; g = b(g, 2)) {
d = g ? 0 : a;
if (g)
  c = 0;
  }
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
cmpb$0, c(%rip)
je  .L6
.L4:
movzbl  a(%rip), %eax
movb%al, d(%rip)
xorl%eax, %eax
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L6:
.cfi_restore_state
xorl%eax, %eax
callfoo
jmp .L4
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movzbl  a(%rip), %eax
movb%al, d(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6b156044c12bc4582511fe270b10450c943476dd

[Bug tree-optimization/108357] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108357
   Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54232&action=edit
presented code as file

cat case.c #411
static char b;
static unsigned c;
void foo();
short(a)(short d, short e) { return d * e; }
static short f(short d) {
  b = 0;
  if ((d && 0 >= c < d) ^ d)
;
  else
foo();
  return d;
}
int main() {
  short g = a(5, b ^ 9854);
  f(g);
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movsbw  b(%rip), %ax
movb$0, b(%rip)
xorw$9854, %ax
leal(%rax,%rax,4), %eax
cmpw$1, %ax
movswl  %ax, %edx
setg%al
movzbl  %al, %eax
cmpl%eax, %edx
je  .L9
xorl%eax, %eax
ret
.L9:
pushq   %rax
.cfi_def_cfa_offset 16
xorl%eax, %eax
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movb$0, b(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2dc5d6b1e7ec8822f5bd78761962ca2c85d4a2b4

[Bug tree-optimization/108358] New: Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108358
   Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54233&action=edit
presented code as file

cat case.c #25
struct a {
  int b;
  int c;
  short d;
  int e;
  int f;
};
struct g {
  struct a f;
  struct a h;
};
int i;
void foo();
void bar31_(void);
int main() {
  struct g j, l = {2, 1, 6, 1, 1, 7, 5, 1, 0, 1};
  for (; i; ++i)
bar31_();
  j = l;
  struct g m = j;
  struct g k = m;
  if (k.h.b)
;
  else
foo();
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -Os` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -Os` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -Os -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$.LC0, %esi
movl$10, %ecx
subq$80, %rsp
.cfi_def_cfa_offset 96
leaq40(%rsp), %rdi
leaq40(%rsp), %rbx
rep movsl
.L2:
cmpl$0, i(%rip)
je  .L7
callbar31_
incli(%rip)
jmp .L2
.L7:
movq%rsp, %rdi
movl$10, %ecx
movq%rbx, %rsi
rep movsl
cmpl$0, 20(%rsp)
jne .L4
xorl%eax, %eax
callfoo
.L4:
addq$80, %rsp
.cfi_def_cfa_offset 16
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -Os -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
cmpl$0, i(%rip)
jne .L7
xorl%eax, %eax
ret
.L7:
pushq   %rax
.cfi_def_cfa_offset 16
.L3:
callbar31_
incli(%rip)
cmpl$0, i(%rip)
jne .L3
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f6c168f8c06047bfaa3005e570126831b8855dcc

[Bug tree-optimization/108359] New: Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108359
   Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54234&action=edit
presented code as file

cat case.c #864
int b = 10;
int c;
char e;
void foo();
static char(a)(char f, char g) { return f && g == 1 ? 0 : f % g; }
short(d)(short f, short g) { return f * g; }
int main() {
  short h;
  int i;
  unsigned j;
  h = d(b && c, 5);
  j = h;
  i = a(h, 237);
  unsigned k = i;
  e = i < 0 || k >= 32 ? 0 : i >> k;
  if (e) {
c = 0;
foo();
  }
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -Os` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -Os` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -Os -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movlb(%rip), %eax
testl   %eax, %eax
je  .L3
xorl%eax, %eax
cmpl$0, c(%rip)
setne   %al
.L3:
movb$5, %dl
imull   %edx, %eax
movsbl  %al, %edx
movl%eax, %ecx
sarl%cl, %edx
movb%dl, e(%rip)
testl   %edx, %edx
je  .L12
pushq   %rax
.cfi_def_cfa_offset 16
xorl%edx, %edx
xorl%eax, %eax
movl%edx, c(%rip)
callfoo
xorl%eax, %eax
popq%rcx
.cfi_def_cfa_offset 8
ret
.L12:
xorl%eax, %eax
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -Os -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movb$0, e(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9991d84d2a84355fd3fc9afc89a963f45991bfa9

[Bug tree-optimization/108360] New: Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 108360
   Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54235&action=edit
case.c as file

cat case.c #321
static short b, c;
unsigned char e;
char f;
void foo();
short(a)(short h, short i) { return h + i; }
static short(d)(short h, int i) { return h >= 32 || h > 7 >> i ? h : h << i; }
unsigned g(short h, short i) { return h + i; }
int main() {
  short j, k = -1;
  c = a(0 >= b, k);
  f = c <= 0xD315BEF1;
  e = f << 4;
  j = d(e, 5);
  if (3 >= g(j == b, k))
foo();
  b = 0;
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -Os` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -Os` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -Os -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB3:
.cfi_startproc
movwb(%rip), %cx
xorl%edx, %edx
testw   %cx, %cx
setle   %dl
movl%edx, %eax
movb%dl, f(%rip)
sall$4, %eax
movb%al, e(%rip)
movzbl  %al, %eax
testw   %dx, %dx
jne .L4
sall$5, %eax
.L4:
cmpw%ax, %cx
jne .L7
pushq   %rax
.cfi_def_cfa_offset 16
xorl%eax, %eax
callfoo
xorl%eax, %eax
movw$0, b(%rip)
popq%rdx
.cfi_def_cfa_offset 8
ret
.L7:
movw$0, b(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -


`gcc-releases/gcc-12.2.0 -Os -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB3:
.cfi_startproc
xorl%eax, %eax
cmpw$0, b(%rip)
movw$0, b(%rip)
setle   %al
movb%al, f(%rip)
sall$4, %eax
movb%al, e(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=418b71c0d535bf91df78bad2e198c57934682eaa

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm via Gcc-bugs]

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

--- Comment #5 from Bill Zissimopoulos  ---
(In reply to niXman from comment #4)
> > FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> > via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> > `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> > fails.
> 
> could you give me a hint, what should I use for `dwFlags` param for
> `GetFinalPathNameByHandle()` ? (because for me all the options are
> incomprehensible)

I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r13-5090-gc389991432da2bcc335a2b4fb7e502d28a6b3346
Author: Martin Jambor 
Date:   Tue Jan 10 14:18:22 2023 +0100

ipa: Sort ipa_param_body_adjustments::m_replacements (PR 108110)

The problem in PR 108110 is that elements describing the same base
parameter in ipa_param_body_adjustments::m_replacements are not
adjacent to each other, which is something that
ipa_param_body_adjustments::modify_call_stmt when it gathers all
replacements for a parameter.

One option would be to simply always keep looking until the end of the
vector (see bugzilla comment 15 for a one-line fix) but the correct
thing to do is to keep the elements of the vector sorted and thus make
such elements adjacent again.  This patch does that and then also
modifies the look-ups to take advantage of it.

Since the one user of ipa_param_body_adjustments that is not
tree-inline.cc, which is OpenMP declare SIMD cloning code, also
registers its own replacements and in theory pointers to elements of
the m_replacements vector can leak through public method
get_expr_replacement, I decided that in those cases it is the
responsibility of the user of the class to call the sorting method
between the replacement registrations and the first lookup.  That is
why the patch also adds a line to omp-simd-clone.cc.

gcc/ChangeLog:

2023-01-09  Martin Jambor  

PR ipa/108110
* ipa-param-manipulation.h (ipa_param_body_adjustments): New
members
sort_replacements, lookup_first_base_replacement and
m_sorted_replacements_p.
* ipa-param-manipulation.cc: Define INCLUDE_ALGORITHM.
(ipa_param_body_adjustments::register_replacement): Set
m_sorted_replacements_p to false.
(compare_param_body_replacement): New function.
(ipa_param_body_adjustments::sort_replacements): Likewise.
(ipa_param_body_adjustments::common_initialization): Call
sort_replacements.
(ipa_param_body_adjustments::ipa_param_body_adjustments):
Initialize
m_sorted_replacements_p.
(ipa_param_body_adjustments::lookup_replacement_1): Rework to use
std::lower_bound.
(ipa_param_body_adjustments::lookup_first_base_replacement): New
function.
(ipa_param_body_adjustments::modify_call_stmt): Use
lookup_first_base_replacement.
* omp-simd-clone.cc (ipa_simd_modify_function_body): Call
adjustments->sort_replacements.

gcc/testsuite/ChangeLog:

2023-01-04  Martin Jambor  

PR ipa/108110
* g++.dg/ipa/pr108110.C: New test.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Jambor  ---
Fixed.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #6 from niXman  ---

> I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.

together? OR'ed?

or should I try for the first, and for the second one? or...?

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm via Gcc-bugs]

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

--- Comment #7 from Bill Zissimopoulos  ---
(In reply to niXman from comment #6)
> > I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
> 
> together? OR'ed?
> 
> or should I try for the first, and for the second one? or...?

Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.

- `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
resolution.

- `VOLUME_NAME_DOS` is needed to translate the internal NT device name to the
familiar Win32 drives (X:). This may fail with `ERROR_UNRECOGNIZED_VOLUME`
which is why I recommended to use GetFullPathName as a fallback mechanism.

[Bug middle-end/106133] ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E

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

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

--- Comment #4 from Martin Liška  ---
Btw. it crashes also for:

gcc empty.c -fdiagnostics-format=sarif-file --save-temps -c
0xf02ebf crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:314
0x778b78df ???
   
/usr/src/debug/glibc-2.36/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x779e1cfd __strlen_avx2
../sysdeps/x86_64/multiarch/strlen-avx2.S:76
0x1fdbb61 xstrdup
/home/marxin/Programming/gcc/libiberty/xstrdup.c:33
0x1f4be5b diagnostic_output_format_init_sarif_file(diagnostic_context*, char
const*)
/home/marxin/Programming/gcc/gcc/diagnostic-format-sarif.cc:1585
0x1f2b395 common_handle_option(gcc_options*, gcc_options*, cl_decoded_option
const*, unsigned int, int, unsigned int, cl_option_handlers const*,
diagnostic_context*, void (*)())
/home/marxin/Programming/gcc/gcc/opts.cc:2866
0x1f2ff08 handle_option
/home/marxin/Programming/gcc/gcc/opts-common.cc:1248
0x1f3003e read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*)
/home/marxin/Programming/gcc/gcc/opts-common.cc:1578
0xe148e4 read_cmdline_options
/home/marxin/Programming/gcc/gcc/opts-global.cc:239
0xe148e4 decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*, void (*)())
/home/marxin/Programming/gcc/gcc/opts-global.cc:321
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 target/107714] MVE: Invalid addressing mode generated for VLD2

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Stam Markianos-Wright
:

https://gcc.gnu.org/g:08842ad274f5e2630994f7c6e70b2d31768107ea

commit r11-10461-g08842ad274f5e2630994f7c6e70b2d31768107ea
Author: Stam Markianos-Wright 
Date:   Fri Dec 30 11:25:22 2022 +

Fix memory constraint on MVE v[ld/st][2/4] instructions [PR107714]

In the M-Class Arm-ARM:

https://developer.arm.com/documentation/ddi0553/bu/?lang=en

these MVE instructions only have '!' writeback variant and at:

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

we found that the Um constraint would also allow through a
register offset writeback, resulting in an assembler error.

Here I have added a new constraint and predicate for these
instructions, which (uniquely, AFAICT), only support a `!` writeback
increment by the data size (inside the compiler this is a POST_INC).

No regressions in arm-none-eabi with MVE and MVE.FP.

gcc/ChangeLog:
PR target/107714
* config/arm/arm-protos.h (mve_struct_mem_operand): New protoype.
* config/arm/arm.c (mve_struct_mem_operand): New function.
* config/arm/constraints.md (Ug): New constraint.
* config/arm/mve.md (mve_vst4q): Change constraint.
(mve_vst2q): Likewise.
(mve_vld4q): Likewise.
(mve_vld2q): Likewise.
* config/arm/predicates.md (mve_struct_operand): New predicate.

gcc/testsuite/ChangeLog:
PR target/107714
* gcc.target/arm/mve/intrinsics/vldst24q_reg_offset.c: New test.

(cherry picked from commit 4269a6567eb991e6838f40bda5be9e3a7972530c)

[Bug target/107714] MVE: Invalid addressing mode generated for VLD2

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Stam Markianos-Wright
:

https://gcc.gnu.org/g:25edc76f2afba0b4eaf22174d42de042a6969dbe

commit r12-9038-g25edc76f2afba0b4eaf22174d42de042a6969dbe
Author: Stam Markianos-Wright 
Date:   Fri Dec 30 11:25:22 2022 +

Fix memory constraint on MVE v[ld/st][2/4] instructions [PR107714]

In the M-Class Arm-ARM:

https://developer.arm.com/documentation/ddi0553/bu/?lang=en

these MVE instructions only have '!' writeback variant and at:

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

we found that the Um constraint would also allow through a
register offset writeback, resulting in an assembler error.

Here I have added a new constraint and predicate for these
instructions, which (uniquely, AFAICT), only support a `!` writeback
increment by the data size (inside the compiler this is a POST_INC).

No regressions in arm-none-eabi with MVE and MVE.FP.

gcc/ChangeLog:
PR target/107714
* config/arm/arm-protos.h (mve_struct_mem_operand): New protoype.
* config/arm/arm.cc (mve_struct_mem_operand): New function.
* config/arm/constraints.md (Ug): New constraint.
* config/arm/mve.md (mve_vst4q): Change constraint.
(mve_vst2q): Likewise.
(mve_vld4q): Likewise.
(mve_vld2q): Likewise.
* config/arm/predicates.md (mve_struct_operand): New predicate.

gcc/testsuite/ChangeLog:
PR target/107714
* gcc.target/arm/mve/intrinsics/vldst24q_reg_offset.c: New test.

(cherry picked from commit 4269a6567eb991e6838f40bda5be9e3a7972530c)

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #8 from niXman  ---

> Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.
> 
> - `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
> resolution.
> 
> - `VOLUME_NAME_DOS` is needed to translate the internal NT device name to
> the familiar Win32 drives (X:). This may fail with
> `ERROR_UNRECOGNIZED_VOLUME` which is why I recommended to use
> GetFullPathName as a fallback mechanism.

done, thanks!

in building process... will report.

[Bug c++/108361] New: Assembly code that is never called emitted on x86_64

[eric-bugs at omnifarious dot org via Gcc-bugs]

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

Bug ID: 108361
   Summary: Assembly code that is never called emitted on x86_64
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric-bugs at omnifarious dot org
  Target Milestone: ---

Created attachment 54236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54236&action=edit
Preprocessed C++ code that generates unneeded assembly

The nature of this bug makes a concise test case hard to whittle down to
something minimal...

The attached code generates a whole bunch of assembly that isn't needed. This
assembly references external symbols as well, which creates unnecessary linker
errors.

Clang handles it just fine. :-)

Attached is both the preprocessed C++ code, and the assembly it generates. The
only needed assembly is the code for main and the static data main needs.

_start is defined as a global in a separate file, which is also attached.

The compile command I'm using:

g++ -std=c++20 -march=znver2 -static -O3 -nostartfiles -nostdlib
-I/usr/include/c++/12 -I/home/hopper/src/posixpp/pubincludes -Wl,-e_start
preprocessed.s x86_64_start.s

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[eric-bugs at omnifarious dot org via Gcc-bugs]

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

--- Comment #1 from eric-bugs at omnifarious dot org ---
Created attachment 54237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54237&action=edit
Assembly file containing _start

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[eric-bugs at omnifarious dot org via Gcc-bugs]

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

--- Comment #2 from eric-bugs at omnifarious dot org ---
Created attachment 54238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54238&action=edit
Assembly output from compiler

[Bug rtl-optimization/106421] [10/11/12/13 Regression] ICE with computed goto from a nested functon

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

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

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

https://gcc.gnu.org/g:851e1ba03f9de699a754dd8648fc151c3e26d697

commit r13-5091-g851e1ba03f9de699a754dd8648fc151c3e26d697
Author: Roger Sayle 
Date:   Tue Jan 10 14:05:46 2023 +

PR rtl-optimization/106421: ICE in bypass_block from non-local goto.

This patch fixes PR rtl-optimization/106421, an ICE-on-valid (but
undefined) regression.  The fix, as proposed by Richard Biener, is to
defend against BLOCK_FOR_INSN returning NULL in cprop's bypass_block.

2023-01-10  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/106421
* cprop.cc (bypass_block): Check that DEST is local to this
function (non-NULL) before calling find_edge.

gcc/testsuite/ChangeLog
PR rtl-optimization/106421
* gcc.dg/pr106421.c: New test case.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #20 from Jakub Jelinek  ---
(In reply to Aldy Hernandez from comment #16)
> Created attachment 54224 [details]
> untested patch
> 
> Perhaps this would work.  It solves the testcase, though I think we should
> probably audit the operators that don't use the generic
> range_operator_float::fold_range to make sure they're not doing anything
> silly.

Even as a workaround this seems to be quite a big hammer.
If we want to preserve overflow traps, all we need to arrange is that if
non-inf operands result in singleton inf we don't treat that result as
singleton.
Now, what result one gets in different rounding modes depends on the rounding
mode,
in round to nearest it should be +-inf, in round to zero +-max, in round to
+inf +inf or -max and in round to -inf -inf or +max.  But right now GCC doesn't
handle the separate rounding modes, it just differentiates between
-fno-rounding-math where we assume round to nearest and -frounding-math where
we should consider any rounding mode.
I think for -frounding-math we already don't treat such results as singletons,
as we
end up with ranges like [+max, +inf] or [-inf, -max].
So, one possible way for -fno-rounding-math -ftrapping-math could be instead of
making
the result VARYING just extend the range by one ulp towards 0, i.e. instead of
singleton
[+inf, +inf] use [+max, +inf] etc.
Another would be to add some bool flag to frange which would say this is never
a singleton and just take that flag into account, though perhaps it is too
risky right now.

As for invalid exceptions, that implies result maybe or known NAN, but we don't
treat
maybe or known NAN as singletons, do we?  After all, there isn't just a single
NAN and we don't know which one the result is.  That doesn't mean we handle all
cases right, say
if a result of something is only used in __builtin_isnan or similar, we can
still happily optimized it away.

As for underflow exceptions, I've tried to construct a testcase but seems we
didn't care already in older GCC versions.
Say for float foo (void) { float x = __FLT_MIN__; return x * x; } without
-frounding-math we already optimized it in ccp1 in GCC 12 and older, with
-frounding-math again we should be fine because the result isn't singleton.
Again with the problem that if the result is in the end used in some comparison
or test that will not care about details, like if (__builtin_fabsf (foo ()) <
1.0f) then again we optimize away the trapping operation and we didn't
previously.

And inexact exceptions I think is something we just basically didn't care at
all before, those can happen pretty much all the time.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #21 from Andrew Macleod  ---
(In reply to Richard Biener from comment #13)

> Yes, the fact that ranger doesn't operate as a usual propagator with a
> lattice
> makes things very difficult here.  Note that my comment referred to code
> optimality, not correctness.
> 
> > It really looks like the problem here is DCE (and the gimplifier as you
> > point out in comment #2), which is removing a needed statement.  Can't this
> > be fixed there?
> 
> Sure it can, but the expense is that we'd do constant folding all the way
> down and not remove dead code which will result in _tons_ of unnecessary
> constant pool entries and loads.
> 

I think I'm missing something, or not understanding what you are saying.

Why is the propagation or lack of lattice a problem?   Its DCE that is removing
that potentially trapping stmt because its no longer used in the IL?  THe
change would be to not kill off dead statements that may trap?  I guess this
may leave a bunch of feeding statements that are not dead.. but I fail to see
how thats different than not propagating and then not being able to delete
those stmts either?  


> The issue is also that -ftrapping-math is default on so we'd have to
> do this by default.  Ugh.
> 
> Note that the constant folding routines generally refrain from folding
> when that loses exceptions, it's just ranger when producing singleton
> ranges and propagating from them that doesn't adhere to that implicit rule.

I'm also not sure what this means.  I don't think ranger itself propagates
singleton constants.. VRP is still using the substitute_and_fold engine, so any
folding/propagation is still going through the same mechanisms we always did
when a singleton result is produced.  We just produce more of them now,
especially with floats.  I don't think ranger is doing anything different than
VRP ever did regarding propagation.   Its possible GCCs infrastructure for
dealing with float propagation isn't mature enough perhaps?

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #22 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Aldy Hernandez from comment #16)
> > Created attachment 54224 [details]
> > untested patch
> > 
> > Perhaps this would work.  It solves the testcase, though I think we should
> > probably audit the operators that don't use the generic
> > range_operator_float::fold_range to make sure they're not doing anything
> > silly.
> 
> Even as a workaround this seems to be quite a big hammer.
> If we want to preserve overflow traps, all we need to arrange is that if
> non-inf operands result in singleton inf we don't treat that result as
> singleton.
> Now, what result one gets in different rounding modes depends on the
> rounding mode,
> in round to nearest it should be +-inf, in round to zero +-max, in round to
> +inf +inf or -max and in round to -inf -inf or +max.  But right now GCC
> doesn't handle the separate rounding modes, it just differentiates between
> -fno-rounding-math where we assume round to nearest and -frounding-math
> where we should consider any rounding mode.

Note that we currently can't represent +-inf or +-max, as we only have two
endpoints.  So that would just be represented as VARYING.

> I think for -frounding-math we already don't treat such results as
> singletons, as we
> end up with ranges like [+max, +inf] or [-inf, -max].
> So, one possible way for -fno-rounding-math -ftrapping-math could be instead
> of making
> the result VARYING just extend the range by one ulp towards 0, i.e. instead
> of singleton
> [+inf, +inf] use [+max, +inf] etc.

This seems reasonable.  So instead of set_varying(), we could do [+max, +inf],
etc.

> Another would be to add some bool flag to frange which would say this is
> never a singleton and just take that flag into account, though perhaps it is
> too risky right now.

That seems easy to get wrong, especially this late in the cycle.

> 
> As for invalid exceptions, that implies result maybe or known NAN, but we
> don't treat
> maybe or known NAN as singletons, do we?  After all, there isn't just a
> single NAN and we don't know which one the result is.  That doesn't mean we
> handle all cases right, say
> if a result of something is only used in __builtin_isnan or similar, we can
> still happily optimized it away.

NANs are never singletons, and maybe_nans either.  See frange::singleton_p:

  if (m_kind == VR_RANGE && real_identical (&m_min, &m_max))
{
  // Return false for any singleton that may be a NAN.
  if (HONOR_NANS (m_type) && maybe_isnan ())
return false;
...
}

Also, all the conditional operators in frange fail to fold if maybe_isnan.  The
only things we fold for sure are:

a) One operand is a known NAN.

b) None of the operands can ever be a NAN *and* we know the answer to the
conditional.

For example, foperator_gt::fold_range:

...
...
  if (op1.known_isnan () || op2.known_isnan ())
r = range_false (type);
  else if (!maybe_isnan (op1, op2))
{
  if (real_compare (LE_EXPR, &op1.upper_bound (), &op2.lower_bound ()))
r = range_true (type);
  else if (!real_compare (LE_EXPR, &op1.lower_bound (), &op2.upper_bound
()))
r = range_false (type);
  else
r = range_true_and_false (type);
}

so... we're pretty careful about NOT folding relationals that have the
possibility of a NAN, and a singleton is only for a known range without a NAN.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #23 from Jakub Jelinek  ---
Sure, VRP and DOM etc. have been replacing operations with singleton results
for quite a while, but most of integer arithmetics don't cause exceptions which
one can test or handle through signals.  As has been said above, we have
-fdelete-dead-exceptions option and we might want to consider similar option
for the floating point traps.
Without VRP and similar optimizations, both have some chances to work fine, say
if I have:
void
foo (int *p, int *q)
{
  int r = *p + *q;
}
and -fdelete-dead-exceptions -fnon-call-exceptions, the *p and *q reads could
cause
an exception, but as user said -fdelete-dead-exceptions and nothing uses the
result,
it is fine not to dereference those.
A different question is:
int
bar (int *p, int *q)
{
  int pv = *p;
  int qv = *q;
  if (pv != 0) __builtin_unreachable ();
  if (qv != 0) __builtin_unreachable ();
  int r = pv + qv;
  return r;
}
Here we actually are using what has been read from the memory, so it is much
more fuzzy
if we can still claim the exceptions are dead.
And I think the frange vs. exceptions is exactly the same thing, though much
more often happening in real-world code.  So we'd need to figure out what the
definition for "contribute to the execution of the program" actually is...
With frange singleton folding, we could optimize tons of operations which each
could raise some exceptions, just because we could prove what the final result
would be.  Does that count as a use of those values or not?

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #24 from Aldy Hernandez  ---
(In reply to Andrew Macleod from comment #21)
> (In reply to Richard Biener from comment #13)
> 
> > Yes, the fact that ranger doesn't operate as a usual propagator with a
> > lattice
> > makes things very difficult here.  Note that my comment referred to code
> > optimality, not correctness.
> > 
> > > It really looks like the problem here is DCE (and the gimplifier as you
> > > point out in comment #2), which is removing a needed statement.  Can't 
> > > this
> > > be fixed there?
> > 
> > Sure it can, but the expense is that we'd do constant folding all the way
> > down and not remove dead code which will result in _tons_ of unnecessary
> > constant pool entries and loads.
> > 
> 
> I think I'm missing something, or not understanding what you are saying.
> 
> Why is the propagation or lack of lattice a problem?   Its DCE that is
> removing that potentially trapping stmt because its no longer used in the
> IL?  THe change would be to not kill off dead statements that may trap?  I
> guess this may leave a bunch of feeding statements that are not dead.. but I
> fail to see how thats different than not propagating and then not being able
> to delete those stmts either?  
> 
> 
> > The issue is also that -ftrapping-math is default on so we'd have to
> > do this by default.  Ugh.
> > 
> > Note that the constant folding routines generally refrain from folding
> > when that loses exceptions, it's just ranger when producing singleton
> > ranges and propagating from them that doesn't adhere to that implicit rule.
> 
> I'm also not sure what this means.  I don't think ranger itself propagates
> singleton constants.. VRP is still using the substitute_and_fold engine, so
> any folding/propagation is still going through the same mechanisms we always
> did when a singleton result is produced.  We just produce more of them now,
> especially with floats.  I don't think ranger is doing anything different
> than VRP ever did regarding propagation.   Its possible GCCs infrastructure
> for dealing with float propagation isn't mature enough perhaps?

Right, ranger isn't propagating anything.  It's the substitute_and_fold engine,
as it always has, but only if value_of_expr() is non-NULL.  Currently this
function will only return non-NULL for singletons:

tree
range_query::value_of_expr (tree expr, gimple *stmt)
{
  tree t;

  if (!Value_Range::supports_type_p (TREE_TYPE (expr)))
return NULL_TREE;

  Value_Range r (TREE_TYPE (expr));

  if (range_of_expr (r, expr, stmt))
{
  // A constant used in an unreachable block oftens returns as UNDEFINED.
  // If the result is undefined, check the global value for a constant.
  if (r.undefined_p ())
range_of_expr (r, expr);
  if (r.singleton_p (&t))
return t;
}
  return NULL_TREE;
}

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[13 Regression] Dead Code   |[13 Regression] Dead Code
   |Elimination Regression at   |Elimination Regression at
   |-O3 (trunk vs. 12.2.0)  |-O3 since
   ||r13-4240-gfeeb0d68f1c708
   Last reconfirmed||2023-01-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Thanks for the report. Please use the title as I've just modified and if
possible, CC people who are authors of such a revision.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to Aldy Hernandez from comment #22)
> Note that we currently can't represent +-inf or +-max, as we only have two
> endpoints.  So that would just be represented as VARYING.

By +-inf I meant either [+inf, +inf] or [-inf, -inf], sorry for the shorthand.
Sure, if we don't know if it is positive or negative infinity, right now it
will be VARYING or close to VARYING and so nothing close to singleton.

[Bug tree-optimization/108353] [13 Regression] Dead Code Elimination Regression at -O2 since r13-3898-gaf96500eea72c6

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-01-10
Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O2 (trunk|Elimination Regression at
   |vs. 12.2.0) |-O2 since
   ||r13-3898-gaf96500eea72c6
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/108352] Dead Code Elimination Regression at -O2 since r13-1960-gd86d81a449c036

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-01-10
Summary|Dead Code Elimination   |Dead Code Elimination
   |Regression at -O2 (trunk|Regression at -O2 since
   |vs. 12.2.0) |r13-1960-gd86d81a449c036
 Ever confirmed|0   |1
   Target Milestone|--- |13.0

[Bug tree-optimization/108354] [13 Regression] Dead Code Elimination Regression at -O2 since r13-89-gb3e98eb3396e16

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O2 (trunk|Elimination Regression at
   |vs. 12.2.0) |-O2 since
   ||r13-89-gb3e98eb3396e16
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org
   Last reconfirmed||2023-01-10

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O2 (trunk|Elimination Regression at
   |vs. 12.2.0) |-O2 since
   ||r13-2772-g9baee6181b4e42
   Target Milestone|--- |13.0
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-10

[Bug tree-optimization/108356] [13 Regression] Dead Code Elimination Regression at -O2 since r13-434-g6b156044c12bc4

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Last reconfirmed||2023-01-10
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O2 (trunk|Elimination Regression at
   |vs. 12.2.0) |-O2 since
   ||r13-434-g6b156044c12bc4
 CC||amacleod at redhat dot com,
   ||marxin at gcc dot gnu.org

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O2 (trunk|Elimination Regression at
   |vs. 12.2.0) |-O2 since
   ||r13-4607-g2dc5d6b1e7ec88
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
   Last reconfirmed||2023-01-10

[Bug tree-optimization/108358] [13 Regression] Dead Code Elimination Regression at -Os since r13-3378-gf6c168f8c06047

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -Os (trunk|Elimination Regression at
   |vs. 12.2.0) |-Os since
   ||r13-3378-gf6c168f8c06047
   Target Milestone|--- |13.0
   Last reconfirmed||2023-01-10
 Ever confirmed|0   |1
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/108359] [13 Regression] Dead Code Elimination Regression at -Os since r13-1162-g9991d84d2a8435

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -Os (trunk|Elimination Regression at
   |vs. 12.2.0) |-Os since
   ||r13-1162-g9991d84d2a8435
   Target Milestone|--- |13.0
   Last reconfirmed||2023-01-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org

[Bug tree-optimization/108360] [13 Regression] Dead Code Elimination Regression at -Os since r13-2048-g418b71c0d535bf

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -Os (trunk|Elimination Regression at
   |vs. 12.2.0) |-Os since
   ||r13-2048-g418b71c0d535bf
   Last reconfirmed||2023-01-10
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm via Gcc-bugs]

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

--- Comment #9 from Bill Zissimopoulos  ---
Thank you.

Let me know if you need any help from me.

[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand since r12-5253-g4df7f8c79835d569

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108219

--- Comment #9 from Patrick Palka  ---
(In reply to Steven Sun from comment #7)
> I got one simple idea as a workaround. I do not have the resources to do the
> tests.

FWIW that seems like the right idea, but it regresses
gcc/testsuite/g++.dg/DRs/dr2392.C:

$ cat gcc/testsuite/g++.dg/DRs/dr2392.C
// DR 2392
// { dg-do compile { target c++11 } }

template 
constexpr int
foo ()
{
  T t;
  return 1;
}

using V = decltype (new int[foo ()]);

$ gcc gcc/testsuite/g++.dg/DRs/dr2392.C
gcc/testsuite/g++.dg/DRs/dr2392.C: In instantiation of ‘constexpr int foo()
[with T = void]’:
gcc/testsuite/g++.dg/DRs/dr2392.C:12:33:   required from here
gcc/testsuite/g++.dg/DRs/dr2392.C:8:5: error: variable or field ‘t’ declared
void
8 |   T t;
  | ^

[Bug libstdc++/108362] New: views::istream is SFINAE-unfriendly

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 108362
   Summary: views::istream is SFINAE-unfriendly
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Similar issue with https://github.com/microsoft/STL/pull/3335.

#include 
#include 

template
concept can_istream_view = requires {
  std::views::istream(std::cin);
};

struct S { };
static_assert(!can_istream_view);

https://godbolt.org/z/b3W1KsPWd

[Bug tree-optimization/108137] [12 Regression] ICE: segfault during GIMPLE pass: warn-printf since r12-523-g2254b3233b5bfa69

[ucko at ncbi dot nlm.nih.gov via Gcc-bugs]

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

--- Comment #9 from ucko at ncbi dot nlm.nih.gov ---
Thanks!  I'm happy to confirm that the patch works for me too, even in the more
severely affected file I mentioned earlier.

[Bug tree-optimization/106293] [13 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-5092-g4e0b504f26f78ff02e80ad98ebbf8ded3aa6ffa1
Author: Richard Biener 
Date:   Tue Jan 10 13:48:51 2023 +0100

tree-optimization/106293 - missed DSE with virtual LC PHI

Degenerate virtual PHIs can break DSEs fragile heuristic as to what
defs it can handle for further processing.  The following enhances
it to look through degenerate PHIs by means of a worklist, processing
the degenerate PHI defs uses to the defs array.  The rewrite of
virtuals into loop-closed SSA caused this to issue appear more often.
The patch itself is mostly re-indenting the new loop body.

PR tree-optimization/106293
* tree-ssa-dse.cc (dse_classify_store): Use a worklist to
process degenerate PHI defs.

* gcc.dg/tree-ssa/ssa-dse-46.c: New testcase.

[Bug tree-optimization/106293] [13 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
The testcase in comment#6 is now fixed.

[Bug c++/108285] [13 Regression] error: conversion from ‘long double’ to ‘double’ may change value [-Werror=float-conversion] since r13-3291-g16ec267063c8ce60

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 54239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54239&action=edit
gcc13-pr108285.patch

Untested fix.

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

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

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

--- Comment #1 from Richard Biener  ---
The CCP hunk causes a condition to be optimized away which then results in
different jump threading and different VRP.  I didn't analyze further, but the
first difference is good:

@@ -253,31 +256,25 @@
   _9 = (short int) _8;
   _4 = (int) _9;
   b = 0;
-  if (_9 != 0)
-goto ; [67.00%]
-  else
-goto ; [33.00%]
-
-   [local count: 719407025]:
   _14 = (int) _9;
   if (_14 > 1)
-goto ; [50.00%]
-  else
 goto ; [50.00%]
+  else
+goto ; [50.00%]

-   [local count: 359703512]:
+   [local count: 359703512]:

-   [local count: 719407025]:
-  # iftmp.3_15 = PHI <1(3), 0(4)>
+   [local count: 719407025]:
+  # iftmp.3_15 = PHI <1(2), 0(3)>
   if (_14 != iftmp.3_15)
-goto ; [66.00%]
+goto ; [66.00%]
   else
-goto ; [34.00%]
+goto ; [34.00%]

-   [local count: 598933192]:
+   [local count: 598933192]:
   foo ();

-   [local count: 1073741825]:
+   [local count: 1073741825]:
   return 0;

[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors

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

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

--- Comment #7 from David Malcolm  ---
For reference, this article (by one of my colleagues) talks about how valgrind
can detect file descriptor leaks *dynamically*:
 
https://developers.redhat.com/articles/2023/01/09/how-use-valgrind-track-file-descriptors#

[Bug tree-optimization/108356] [13 Regression] Dead Code Elimination Regression at -O2 since r13-434-g6b156044c12bc4

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Andrew Macleod  ---
>From ccp2 :

Simulating block 2

Visiting statement:
c.2_1 = c;
which is likely CONSTANT
Lattice value changed to VARYING.  Adding SSA edges to worklist.


Whereas in GCC12 I see:

Simulating block 2

Visiting statement:
c.2_1 = c;
which is likely CONSTANT
Lattice value changed to CONSTANT 3.  Adding SSA edges to worklist.
marking stmt to be not simulated again


So we use to pick up that the memory load produces a 3 in CCP, but we no longer
do.   I'm not sure how that specified ranger cache patch causes this?ISTR
some other PR where we aren't picking up a constant from a memory load as well.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  We're doing

Value numbering stmt = _2 = e[5][a.0_1];
Skipping possible redundant definition e[5][0] = 1;
Setting value number of _2 to _2 (changed)

now, by skipping the def we're no longer then optimistically assuming
a.0_1 == 0 when formerly using the assignment-from-constant _3 trick.

That wasn't done by design - if we'd handle this optimistically by
design we'd have more canonical reference ops for e[5][a.0_1].

Not sure if worth fixing.

[Bug tree-optimization/108353] [13 Regression] Dead Code Elimination Regression at -O2 since r13-3898-gaf96500eea72c6

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

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

--- Comment #1 from Richard Biener  ---
The for (; j; j = j + 9) loop invokes undefined behavior:

t.c: In function 'g':
t.c:11:17: warning: iteration 396462472 invokes undefined behavior
[-Waggressive-loop-optimizations]
   11 | for (; j; j = j + 9) {
  |   ~~^~~
t.c:11:12: note: within this loop
   11 | for (; j; j = j + 9) {
  |^

[Bug tree-optimization/108356] [13 Regression] Dead Code Elimination Regression at -O2 since r13-434-g6b156044c12bc4

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

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

--- Comment #2 from Richard Biener  ---
(In reply to Andrew Macleod from comment #1)
> From ccp2 :
> 
> Simulating block 2
> 
> Visiting statement:
> c.2_1 = c;
> which is likely CONSTANT
> Lattice value changed to VARYING.  Adding SSA edges to worklist.
> 
> 
> Whereas in GCC12 I see:
> 
> Simulating block 2
> 
> Visiting statement:
> c.2_1 = c;
> which is likely CONSTANT
> Lattice value changed to CONSTANT 3.  Adding SSA edges to worklist.
> marking stmt to be not simulated again
> 
> 
> So we use to pick up that the memory load produces a 3 in CCP, but we no
> longer do.   I'm not sure how that specified ranger cache patch causes this?
> ISTR some other PR where we aren't picking up a constant from a memory load
> as well.

The store c = 0 needs to be eliminated before IPA for that to work (and c
promoted constant).  Possibly some change in jump-threading?

[Bug tree-optimization/108352] [13 Regression] Dead Code Elimination Regression at -O2 since r13-1960-gd86d81a449c036

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug other/89204] -floop-interchange has no effect on Fortran code

[mehdi.chinoune at hotmail dot com via Gcc-bugs]

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

Chinoune  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
Version|10.1.0  |4.0.0
  Component|fortran |other

--- Comment #7 from Chinoune  ---
لا أريد أن يكون لي

[Bug rtl-optimization/108273] Inconsistent dfa state between debug and non-debug

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||jskumari at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
Add Surya to the CC list for her input, since she has worked on similar issues.