date:20230923

[Bug c++/111455] [14 Regression] Using incorrect cast operator on integer_pack

2023-09-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

https://gcc.gnu.org/g:59d27cc55a0588ed7b03bef804662cb844e8a24d

commit r14-4236-g59d27cc55a0588ed7b03bef804662cb844e8a24d
Author: Jakub Jelinek 
Date:   Sat Sep 23 09:38:42 2023 +0200

testsuite: Add new test for already fixed PR111455

The following testcase has been fixed by r14-4231.

2023-09-23  Jakub Jelinek  

PR c++/111455
* g++.dg/ext/integer-pack8.C: New test.

[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context

2023-09-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
*** Bug 111455 has been marked as a duplicate of this bug. ***

[Bug c++/111455] [14 Regression] Using incorrect cast operator on integer_pack

2023-09-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Dup of PR111357, now fixed.

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

[Bug middle-end/111547] New: [OpenMP] -fopenmp omp::decl update missing

2023-09-23 Thread burnus at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111547
   Summary: [OpenMP] -fopenmp omp::decl update missing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

We need to add omp::decl to invoke.texi:

@item -fopenmp
Enable handling of OpenMP directives @code{#pragma omp} in C/C++,
@code{[[omp::directive(...)]]} and @code{[[omp::sequence(...)]]} in C++ and
@code{!$omp} in Fortran.

and

@item -fopenmp-simd
Enable handling of OpenMP's @code{simd}, @code{declare simd},
@code{declare reduction}, @code{assume}, @code{ordered}, @code{scan},
@code{loop} directives and combined or composite directives with
@code{simd} as constituent with @code{#pragma omp} in C/C++,
@code{[[omp::directive(...)]]} and @code{[[omp::sequence(...)]]} in C++
and @code{!$omp} in Fortran. 

How do we handle 'loop' for the here? It sounds either wrong or misleading; it
surely does not imply multiple threads here.

[Bug middle-end/110148] [14 Regression] TSVC s242 regression between g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8

2023-09-23 Thread jamborm at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Martin Jambor  ---
I believe this has been fixed?

[Bug middle-end/111548] New: RISC-V Vector: ICE in validate_change_or_fail (vsetvl pass)

2023-09-23 Thread jeremy.bennett at embecosm dot com via Gcc-bugs

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

Bug ID: 111548
   Summary: RISC-V Vector: ICE in validate_change_or_fail (vsetvl
pass)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremy.bennett at embecosm dot com
  Target Milestone: ---

Created attachment 55973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55973&action=edit
Reproducer source code

This issue was identified building SPEC CPU 2017 602.gcc_s.

Reproducer (test.c):

a, c, d;
*b;
h() {
  int e;
  i();
  for (;;) {
unsigned f;
char *g;
f = a;
for (; f; f--) {
  if (*g == '"')
e = !e;
  *b = g++;
}
if (c)
  break;
f = d;
for (; d;)
  if (e)
b++;
  }
}

Compile with:

riscv64-unknown-linux-gnu-gcc -w -march=rv64gcv -mabi=lp64d -c -Ofast \
-ftree-vectorize --param=riscv-autovec-preference=scalable test.c

Output is:
during RTL pass: vsetvl
test.c: In function 'h':
test.c:22:1: internal compiler error: in validate_change_or_fail, at
config/riscv/riscv-vsetvl.cc:788
   22 | }
  | ^
0xa6ef0b validate_change_or_fail
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:788
0xa6f0bb validate_change_or_fail
/home/jeremy/gittrees/mustang/gcc/gcc/hash-set.h:64
0xa6f0bb change_insn
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:804
0x165d292 pass_vsetvl::earliest_fusion()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3415
0x165da61 pass_vsetvl::vsetvl_fusion()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3457
0x165f950 pass_vsetvl::lazy_vsetvl()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4373
0x165fad1 pass_vsetvl::execute(function*)
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4413
0x165fad1 pass_vsetvl::execute(function*)
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4394
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

System information
==

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/mustang/install/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/jeremy/gittrees/mustang/gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/home/jeremy/gittrees/mustang/install
--with-sysroot=/home/jeremy/gittrees/mustang/install/sysroot
--with-pkgversion=g59d27cc55a0 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=/home/jeremy/gittrees/mustang/gcc --enable-multilib --with-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
   -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230923 (experimental) (g59d27cc55a0)

[Bug libstdc++/111549] New: _RangeAdaptorClosure's (adaptor | adaptor) operator is underconstrained

2023-09-23 Thread hewillk at gmail dot com via Gcc-bugs

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

Bug ID: 111549
   Summary: _RangeAdaptorClosure's (adaptor | adaptor) operator is
underconstrained
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

// Compose the adaptors __lhs and __rhs into a pipeline, returning
// another range adaptor closure object.
template
  requires __is_range_adaptor_closure<_Lhs>
&& __is_range_adaptor_closure<_Rhs>
  constexpr auto
  operator|(_Lhs __lhs, _Rhs __rhs)
  { return _Pipe<_Lhs, _Rhs>{std::move(__lhs), std::move(__rhs)}; }

User-defined range adapter closure is not necessarily movable, in which case we
may need to constrain the pipe operator to avoid hard errors inside the
function.

#include 

struct Closure : std::ranges::range_adaptor_closure {
  Closure() = default;
  Closure(Closure&&) = delete;
  auto operator()(std::ranges::range auto&&) const;
};

int main() {
  auto r = std::views::take(5) | Closure{};
}

https://godbolt.org/z/eqdvxxh3r

[Bug c++/104264] __is_trivially_copyable fails to report non-recursively trivially copyable classes

2023-09-23 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 CC||jason at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-23

[Bug libstdc++/111550] New: The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

2023-09-23 Thread hewillk at gmail dot com via Gcc-bugs

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

Bug ID: 111550
   Summary: The range adaptor closure object generated by
adaptor(args...) is not a perfect forwarding call
wrapper
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

The call operator of _Partial only handles the const& and && qualifiers, which
is missing the & and const&& and causes the following code to be rejected.

#include 

struct Five {
  operator int() &;
  operator int() && = delete;
};

int main() {
  auto take_five = std::views::take(Five{});
  auto r = take_five(std::views::iota(0));
}

https://godbolt.org/z/b19fsGceG

[Bug middle-end/111551] New: Fix for PR106081 is not working with profile feedback on imagemagick

2023-09-23 Thread hubicka at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111551
   Summary: Fix for PR106081 is not working with profile feedback
on imagemagick
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

As seen in
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=471.507.0&plot.1=473.507.0&plot.2=475.507.0&plot.3=477.507.0&;
Fix for PR106081 improved imagemagick significantly without FDO but not with
FDO.

[Bug middle-end/111552] New: 549.fotonik3d_r regression with -O2 -flto -march=native on zen between g:85d613da341b7630 (2022-06-21 15:51) and g:ecd11acacd6be57a (2022-07-01 16:07)

2023-09-23 Thread hubicka at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111552
   Summary: 549.fotonik3d_r regression with -O2 -flto
-march=native on zen between g:85d613da341b7630
(2022-06-21 15:51) and g:ecd11acacd6be57a (2022-07-01
16:07)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=297.527.0&plot.1=296.527.0&;

[Bug libstdc++/111553] New: Incorrect visibility of std::format

2023-09-23 Thread Richard1.Kellnberger at web dot de via Gcc-bugs

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

Bug ID: 111553
   Summary: Incorrect visibility of std::format
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Richard1.Kellnberger at web dot de
  Target Milestone: ---

Using
g++ a.cpp -std=c++20
the following compiles successfully even so it should not.

#include 

int main(int argc, char* argv[]) {
std::string a("a");
return format("a{}", a)!="aa";
}

Passing an int, float, bool or a string literal to format instead raises the
correct not declared error.

[Bug libstdc++/111553] Incorrect visibility of std::format

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is how the standard argument depedent lookup works ...

[Bug c/111554] New: Timeout with with "-O3 -fno-dse -fno-inline -fno-store-merging -fno-toplevel-reorder -fno-tree-dce -fno-tree-dse"

2023-09-23 Thread 19373742 at buaa dot edu.cn via Gcc-bugs

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

Bug ID: 111554
   Summary: Timeout with with "-O3 -fno-dse -fno-inline
-fno-store-merging -fno-toplevel-reorder -fno-tree-dce
-fno-tree-dse"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 19373742 at buaa dot edu.cn
  Target Milestone: ---

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

***
OS and Platform:
Ubuntu 20.04.4 LTS
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/cuisk/ctc/gcc-releases/gcc-14/bin/gcc
COLLECT_LTO_WRAPPER=/home/cuisk/ctc/gcc-releases/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/cuisk/ctc/gcc-releases/gcc-14
--disable-multilib --enable-language=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230917 (experimental) (GCC)
***
Command Lines:
$ (ulimit -t 60; gcc -I /home/csmith/include/csmith-2.3.0 -O3 -fno-dse
-fno-inline -fno-store-merging -fno-toplevel-reorder -fno-tree-dce
-fno-tree-dse a.c -o tle.o)

gcc: fatal error: Killed signal terminated program cc1
compilation terminated.

$ (ulimit -t 60; /home/cuisk/ctc/gcc-releases/gcc-14/bin/gcc -I
/home/cuisk/ctc/csmith/include/csmith-2.3.0 -save-temps /home/cuisk/gcc/tmp/a.c
-o tle2.o 2>tle.out)
$./tle2.o
checksum = 0

[Bug c/111554] Timeout with with "-O3 -fno-dse -fno-inline -fno-store-merging -fno-toplevel-reorder -fno-tree-dce -fno-tree-dse"

2023-09-23 Thread 19373742 at buaa dot edu.cn via Gcc-bugs

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

--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55975&action=edit
The compiler output

[Bug rtl-optimization/111554] Timeout with with "-O3 -fno-dse -fno-inline -fno-store-merging -fno-toplevel-reorder -fno-tree-dce -fno-tree-dse"

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization

--- Comment #2 from Andrew Pinski  ---
#0  sd_find_dep_between_no_cache (pro=pro@entry=0x777bb080,
con=con@entry=0x76a00c40, resolved_p=resolved_p@entry=false,
sd_it_ptr=sd_it_ptr@entry=0x7fffd680) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:867
#1  0x01e89a43 in add_or_update_dep_1 (new_dep=0x7fffd6e0,
resolved_p=, mem1=0x0, mem2=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:1260
#2  0x01e89e1a in haifa_note_dep (elem=, ds=) at /home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:1867
#3  0x01e80cd3 in note_dep (ds=, e=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:1902
#4  add_dependence_1 (insn=, elem=,
dep_type=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:4294
#5  0x01e82e2f in find_inc (mii=0x7fffd850, backwards=true) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:4844
#6  0x01e830c2 in find_mem (mii=0x7fffd850, address_of_x=) at /home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:4911
#7  0x01e82ffe in find_mem (mii=0x7fffd850, address_of_x=) at /home/apinski/src/upstream-gcc-git/gcc/gcc/sched-deps.cc:4928
#8  0x01e8a22f in find_modifiable_mems (head=,
tail=) at /home/apinski/src/upstream-gcc-git/gcc/gcc/rtl.h:1511
#9  0x01dc55f9 in schedule_block
(target_bb=target_bb@entry=0x7fffd9b8, init_state=0x31cf3c0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/haifa-sched.cc:6498
#10 0x00faf84b in schedule_region (rgn=0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-rgn.cc:3205
#11 schedule_insns () at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-rgn.cc:3532
#12 0x00fafb4e in schedule_insns () at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-rgn.cc:3518
#13 rest_of_handle_sched2 () at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-rgn.cc:3756
#14 (anonymous namespace)::pass_sched2::execute (this=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/sched-rgn.cc:3895

[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848

2023-09-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

https://gcc.gnu.org/g:767eea9ea22f0247be9a56fd2e1d460ddfbbf6d9

commit r14-4238-g767eea9ea22f0247be9a56fd2e1d460ddfbbf6d9
Author: Harald Anlauf 
Date:   Fri Sep 22 21:06:00 2023 +0200

fortran: error recovery on duplicate declaration of class variable
[PR95710]

gcc/fortran/ChangeLog:

PR fortran/95710
* class.cc (gfc_build_class_symbol): Do not try to build class
container for invalid typespec.
* resolve.cc (resolve_fl_var_and_proc): Prevent NULL pointer
dereference.
(resolve_symbol): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/95710
* gfortran.dg/pr95710.f90: New test.

[Bug target/111555] New: [AArch64] __ARM_FEATURE_UNALIGNED should be undefined with -mstrict-align

2023-09-23 Thread lasse.collin at tukaani dot org via Gcc-bugs

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

Bug ID: 111555
   Summary: [AArch64] __ARM_FEATURE_UNALIGNED should be undefined
with -mstrict-align
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lasse.collin at tukaani dot org
  Target Milestone: ---

On 32-bit ARM, the macro __ARM_FEATURE_UNALIGNED is defined when using
-munaligned-access and not defined when using -mno-unaligned-access. On AArch64
the macro is always defined with both -mno-strict-align and -mstrict-align. I
think the macro shouldn't be defined with -mstrict-align on AArch64.

For comparison, with Clang on AArch64 the definition of __ARM_FEATURE_UNALIGNED
is omitted with -mstrict-align and -mno-unaligned-access.

[Bug libgomp/111556] New: OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

2023-09-23 Thread silvio at traversaro dot it via Gcc-bugs

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

Bug ID: 111556
   Summary: OMP_* environment variables not read if libgomp is
loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the
process executable access the environ global variable
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: silvio at traversaro dot it
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55976&action=edit
Self-contained example demonstrating the problem, just execute the run script
to reproduce the problem.

I am not 100% sure if this is a problem in libgomp, but given this was
something that worked fine in libgomp <=12 and it was not trivial to understand
what was going on, I prefer to report it in the libgomp bugzilla, so that
future users encountering this problem have a reference.

If the following conditions occur:
* libgomp is loaded in a process via a call to dlopen([..], [..]|RTLD_DEEPBIND)
* the process executable access the environ global variable

then during libgomp's loading the OMP_* environment variables are ignored. 

The problem is demonstrated with the attached example. In the attached example
a main is loading a shared library lib.so, and lib.so links libgomp, and the
OMP_CANCELLATION env variable is set to true. If the main does not access the
environ global variable, then OMP_CANCELLATION env variable is correctly loaded
(i.e. omp_get_cancellation() returns 1), while if the main access the environ
global variable, the OMP_CANCELLATION variable is ignored  (i.e.
omp_get_cancellation() returns 0). Running the same example against libgomp <=
12, in both cases the OMP_CANCELLATION variable is correctly read (i.e.
omp_get_cancellation() returns 1).

Why is this happening? I am not an expert so I may be getting something wrong,
but what I understood in my debugging (see
https://github.com/conda-forge/casadi-feedstock/issues/93#issuecomment-1732344044
for the downstream issue), is that in the case in which the executable is
directly accessing the environ variable, a copy of the environ global variable
(that in all other cases is in the bss of glibc shared library, as  a weak
symbol) is placed in the bss of the executable, as strong symbol. That means
that in the process there are two different environ symbols. In normal
conditions, only the environ in executable's bss is accessed by all libraries,
while the one in glibc's bss remains NULL initialized. However if gomp is
loaded via RTLD_DEEPBIND, when gomp tries to access environ, it access the
glibc's environ, that was never initialized and so it is still NULL. I am not
sure if this is an intended behavior, see also the related glibc issue
https://sourceware.org/bugzilla/show_bug.cgi?id=9758 .

Interestingly, if one access the environment via glibc's functions such as
getenv or similar, everything works fine, as glibc for sure is not loaded via
RTLD_DEEPBIND, and so in its functions environ is resolved to the correct
environ, i.e. the one of the executable's bss. I think this is the reason why
everything works fine with gomp <= 12, as before gomp 13 the environ variable
was not directly accessed in gomp.

[Bug target/111555] [AArch64] __ARM_FEATURE_UNALIGNED should be undefined with -mstrict-align

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. Though the ACLE spec
(https://developer.arm.com/documentation/ihi0053/d/?lang=en) is not clear here
as this part was written as part of aarch32/thumb2 part rather than referencing
aarch64 ...

[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
  Component|libgomp |target

--- Comment #1 from Andrew Pinski  ---
As mentioned in the glibc bug report, it is only an issue on targets which use
copy relocs which means it is an x86_64 only issue as I think that is the only
target that uses copy relocs still ...

[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

2023-09-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Jakub Jelinek  ---
And I doubt there is anything we can do about this on the libgomp side. 
Because of the OpenMP standard changes, we simply need to scan all the
environmental variable names and check them for some cases, we can't just use
getenv anymore, because relevant variables can have just some prefix plus
numerical suffix and calling getenv 2G+ times for each prefix is not feasible.

[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848

2023-09-23 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14.

[Bug target/111557] New: [RISC-V] The macro __riscv_unaligned_fast should be __riscv_misaligned_fast

2023-09-23 Thread lasse.collin at tukaani dot org via Gcc-bugs

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

Bug ID: 111557
   Summary: [RISC-V] The macro __riscv_unaligned_fast should be
__riscv_misaligned_fast
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lasse.collin at tukaani dot org
  Target Milestone: ---

The RISC-V C API Specification[1] has __riscv_misaligned_fast,
__riscv_misaligned_slow, and __riscv_misaligned_avoid. The commit 6e23440b [2]
used "unaligned" instead of "misaligned" though. The spelling
__riscv_unaligned_* was mentioned in [3] but in [4] it was changed to
__riscv_misaligned_*.

Clang doesn't have these macros yet but there is a recent pull request[5] that
uses the __riscv_misaligned_* spelling.

[1] https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c-api.md
[2]
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6e23440b5df4011bbe1dbee74d47641125dd7d16
[3] https://github.com/riscv-non-isa/riscv-c-api-doc/issues/32
[4] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/40
[5] https://github.com/llvm/llvm-project/pull/65756

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

2023-09-23 Thread fdumont at gcc dot gnu.org via Gcc-bugs

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

--- Comment #20 from François Dumont  ---
I run make check-c++ before and after my patch and I see no regression. I even
have less failures with the patch even if I haven't check yet why.

So I think the patch is quite safe, just waiting for validation now.

[Bug tree-optimization/111543] `(a & b) & ~a` could be optimized before reassociation

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/631235.html

--- Comment #3 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631235.html

[Bug target/83409] arc: "internal compiler error: in extract_constrain_insn" with -O3

2023-09-23 Thread roger at nextmovesoftware dot com via Gcc-bugs

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #3 from Roger Sayle  ---
I'm unable to reproduce this with mainline gcc configured with
--target=arc-elf.  scatterlist.i (and the reduced test case in comment #1),
compile fine with -O2, -O3 and -O3 -fno-strict-aliasing.  I've also tried
-mcpu=em.  Can you confirm that this has been fixed for you (so we can close
the PR)?

[Bug target/91591] Arc: ICE in trunc_int_for_mode, at explow.c:60

2023-09-23 Thread roger at nextmovesoftware dot com via Gcc-bugs

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

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |8.4
 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Roger Sayle  ---
As reported by Giulio, this bug has now been fixed.

[Bug tree-optimization/111542] [11/12/13/14 Regression] (a==0)&(b==0) into `(a|b) == 0` optimization sometimes gets in the way of other optimizations

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
Note IOR with != 0 has the same issue.
Full testcase:
```
_Bool f_and(int x,int y)
{
  _Bool a = x == 0;
  _Bool b = y == 0;
  _Bool t = a & b;
  return t & !a;
}


_Bool f_or(int x,int y)
{
  _Bool a = x != 0;
  _Bool b = y != 0;
  _Bool t = a | b;
  return t | !a;
}
```

Match pattern:
```
(for bitop (bit_ior bit_and)
 cmp1  (eq  ne )
 cmp2  (ne  eq )
 (simplify
  (bitop:c
   (cmp1 @1 integer_zerop)
   (cmp2 (bit_ior:c @0 @1) integer_zerop))
  { constant_boolean_node (bitop == BIT_IOR_EXPR, type); }))
```

[Bug target/91251] Revision 272645 on top of 9.1.0 caused ICE: in extract_insn, at recog.c:2310

2023-09-23 Thread roger at nextmovesoftware dot com via Gcc-bugs

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #1 from Roger Sayle  ---
I'm unable to reproduce this with mainline gcc, the reduced testcase appears to
compile fine (without an ICE).  Can you confirm that this issue is also fixed
for you?

[Bug tree-optimization/111542] [11/12/13/14 Regression] (a==0)&(b==0) into `(a|b) == 0` optimization sometimes gets in the way of other optimizations

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2) 
> Match pattern:
> ```
> (for bitop (bit_ior bit_and)
>  cmp1  (eq  ne )
>  cmp2  (ne  eq )
>  (simplify
>   (bitop:c
>(cmp1 @1 integer_zerop)
>(cmp2 (bit_ior:c @0 @1) integer_zerop))
>   { constant_boolean_node (bitop == BIT_IOR_EXPR, type); }))
> ```

But this breaks generic-match building of the function:
tree
generic_simplify_92 (location_t ARG_UNUSED (loc), const tree ARG_UNUSED (type),
 tree ARG_UNUSED (_p0), tree ARG_UNUSED (_p1), tree *captures,
 const enum tree_code ARG_UNUSED (bitop),
 const enum tree_code ARG_UNUSED (cmp1),
 const enum tree_code ARG_UNUSED (cmp2))
{
  const bool debug_dump = dump_file && (dump_flags & TDF_FOLDING);
  if (TREE_SIDE_EFFECTS (_p0)) goto next_after_fail192;
  if (TREE_SIDE_EFFECTS (_p1)) goto next_after_fail192;
  if (UNLIKELY (!dbg_cnt (match))) goto next_after_fail192;
  {
tree _r;
_r =  constant_boolean_node (bitop == BIT_IOR_EXPR, type);
if (UNLIKELY (debug_dump)) generic_dump_logs ("match.pd", 136, __FILE__,
__LINE__, true);
return _r;
  }
next_after_fail192:;
  return NULL_TREE;
}


captures is not used .

I guess I could check TREE_SIDE_EFFECTS on @0/@1 to workaround that issue.

Like so:
```
(for bitop (bit_ior bit_and)
 cmp1  (eq  ne )
 cmp2  (ne  eq )
 (simplify
  (bitop:c
   (cmp1 @1 integer_zerop)
   (cmp2 (bit_ior:c @0 @1) integer_zerop))
  (if (GIMPLE || (!TREE_SIDE_EFFECTS (@0)
   && !TREE_SIDE_EFFECTS (@1)))
   { constant_boolean_node (bitop == BIT_IOR_EXPR, type); })))
```

I had assumed genmatch would generate that code that would use @0/@1 if they
had side effects.  Maybe because I match @0 twice, it assumed we would be using
the captures (I have not looked though).

[Bug c/111558] New: RISCV: shrink-wrapper optimization question

2023-09-23 Thread alexey.lapshin at espressif dot com via Gcc-bugs

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

Bug ID: 111558
   Summary: RISCV: shrink-wrapper optimization question
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexey.lapshin at espressif dot com
CC: manolis.tsamis at vrull dot eu
  Target Milestone: ---

Created attachment 55977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55977&action=edit
shrink-synthetic-example.c

When I was studying shrink-wrapping behavior, I discovered something strange
code generation.

See the code and assembly at https://godbolt.org/z/P3WfTszYn

Every branch has the same save/restore callee-saved registers.
Therefore, the shrink-wrapping optimization may reduce the speed of the
function when input parameters are not zero...

I understand that this is not a synthetic code snippet... 

But may this code generation be reproduced in real code (without asm inlining)?

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

2023-09-23 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Bug 25621 Summary: Missed optimization when unrolling the loop (splitting up 
the sum) (only with -ffast-math)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621

   What|Removed |Added

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

[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)

2023-09-23 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Biener  ---
We are generating the same vectorized loop for S31 and S32 now.

[Bug rtl-optimization/111558] RISCV: shrink-wrapper optimization question

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
>But may this code generation be reproduced in real code (without asm inlining)?


It could in theory but I highly doubt it since most of the time the code blocks
are not written in such a way they would happen this way where they are
independent and such. Maybe initialization code might be done this way but that
code is usually only executed once so the speed will not have a huge impact ...

[Bug other/111559] New: [14 regression] ICE when building Python with PGO

2023-09-23 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111559
   Summary: [14 regression] ICE when building Python with PGO
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: arsen at gcc dot gnu.org
  Target Milestone: ---

Unfortunately, Python PGO strikes again.

Originally reported downstream at
https://bugs.gentoo.org/show_bug.cgi?id=914578.

```
gcc-14 -c -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1
-DNDEBUG -O2 -pipe -march=native -fdiagnostics-color=always
-frecord-gcc-switches -Wreturn-type -ggdb3 -fwrapv -fno-semantic-interposition
-std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden
-fprofile-use -fprofile-correction -I./Include/internal  -I. -I./Include
-I/usr/include/ncursesw  -fPIC -DPy_BUILD_CORE -o Parser/parser.o
Parser/parser.c
Parser/parser.c: In function 'simple_stmt_rule':
Parser/parser.c:1706:1: error: probability of edge 613->614 not initialized
 1706 | simple_stmt_rule(Parser *p)
  | ^~~~
Parser/parser.c:1706:1: error: probability of edge 615->621 not initialized
during IPA pass: inline
Parser/parser.c:1706:1: internal compiler error: verify_flow_info failed
0x55c9cced2153 verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cfghooks.cc:287
0x55c9cd4da214 checking_verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cfghooks.h:214
0x55c9cd4da214 cleanup_tree_cfg_noloop
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/tree-cfgcleanup.cc:1154
0x55c9cd4da214 cleanup_tree_cfg(unsigned int)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/tree-cfgcleanup.cc:1205
0x55c9cd330924 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/passes.cc:2057
0x55c9cd330e10 execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/passes.cc:2142
0x55c9cd333bef execute_one_ipa_transform_pass
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/passes.cc:2336
0x55c9cd333bef execute_all_ipa_transforms(bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/passes.cc:2396
0x55c9ccf13238 cgraph_node::expand()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cgraphunit.cc:1834
0x55c9ccf13238 cgraph_node::expand()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cgraphunit.cc:1794
0x55c9ccf141dc expand_all_functions
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cgraphunit.cc:2000
0x55c9ccf141dc symbol_table::compile()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cgraphunit.cc:2398
0x55c9ccf17a0b symbol_table::compile()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cgraphunit.cc:2311
0x55c9ccf17a0b symbol_table::finalize_compilation_unit()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cgraphunit.cc:2583
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.
make[1]: *** [Makefile:2717: Parser/parser.o] Error 1
```

I can reproduce it manually, but still with a large reproducer:
* wget https://www.python.org/ftp/python/3.11.5/Python-3.11.5.tar.xz
* tar xvf Python-3.11.5.tar.xz
* ./configure CC=gcc-14 --enable-optimizations
* make -j$(nproc)

[Bug other/111559] [14 regression] ICE when building Python with PGO

2023-09-23 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Sam James  ---
I don't think I'm going to be able to get a minimal reproducer for this, but
trying to at least get something a bit smaller/precise.

If I take inspiration from PR79587, I can do a bit better:
* wget https://www.python.org/ftp/python/3.11.5/Python-3.11.5.tar.xz
* tar xvf Python-3.11.5.tar.xz
* ./configure CC=gcc-14 --enable-optimizations
* make clean
* make profile-removal
* make build_all_generate_profile
* make profile-removal
* make run_profile_task # unfortunately this runs something like 44 different
Python tests
* make build_all_merge_profile
* gcc-14 -c -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1
-DNDEBUG -O2 -pipe -march=native -fdiagnostics-color=always
-frecord-gcc-switches -Wreturn-type -ggdb3 -fwrapv -fno-semantic-interposition
-std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden
-fprofile-use -fprofile-correction -I./Include/internal  -I. -I./Include
-I/usr/include/ncursesw  -fPIC -DPy_BUILD_CORE -o Parser/parser.o
Parser/parser.c -save-temps


```
gcc-14 -c -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1
-DNDEBUG -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches
-Wreturn-type -ggdb3 -fwrapv -fno-semantic-interposition -std=c11 -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use
-fprofile-correction -I./Include/internal  -I. -I./Include
-I/usr/include/ncursesw  -fPIC -DPy_BUILD_CORE -o Parser/parser.o
Parser/parser.c -save-temps
gcc-14: warning: ‘-pipe’ ignored because ‘-save-temps’ specified
Parser/parser.c: In function ‘_tmp_28_rule’:
Parser/parser.c:25179:1: error: probability of edge 3->4 not initialized
25179 | _tmp_28_rule(Parser *p)
  | ^~~~
Parser/parser.c:25179:1: error: probability of edge 5->11 not initialized
during GIMPLE pass: fixup_cfg
Parser/parser.c:25179:1: internal compiler error: verify_flow_info failed
0x55b70ce37153 verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/cfghooks.cc:287
0x55b70d295897 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/passes.cc:2100
0x55b70d295e10 execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20230917/gcc-14-20230917/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

```
$ gcc-14 -v
Using built-in specs.
COLLECT_GCC=gcc-14
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230917/work/gcc-14-20230917/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
14.0.0_pre20230917 p2' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --with-build-config=bootstrap-cet
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230917 (experimental) (Gentoo Hardened 14.0.0_pre20230917
p2)
```

I've uploaded build dir after running that last command at
https://dev.gentoo.org/~sam/bugs/gcc/gcc-python-pgo-x86/Python-3.11.5-pgo-crash.tar.xz.

[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |14.0

[Bug tree-optimization/111560] New: Missed optimization of available expression

2023-09-23 Thread 652023330028 at smail dot nju.edu.cn via Gcc-bugs

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

Bug ID: 111560
   Summary: Missed optimization of available expression
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we found some optimizations (regarding Available Expression) that GCC
may have missed. We would greatly appreicate if you can take a look and let us
know what you think.
Here are three examples.


Example 1:
https://godbolt.org/z/eYcWocsPf

Given the following code: 
```c++
int test()
{
int a,b,c,d,e,f,g;
cin>>a>>b>>c>>d>>g;
e=a+b+c;  //line 5
f=d+b+c;  //"b+c" can be replaced with the value at line 5
cout<
>::operator>>(int&)
lea rsi, [rsp+16]
mov rdi, rax
callstd::basic_istream
>::operator>>(int&)
lea rsi, [rsp+20]
mov rdi, rax
callstd::basic_istream
>::operator>>(int&)
lea rsi, [rsp+24]
mov rdi, rax
callstd::basic_istream
>::operator>>(int&)
lea rsi, [rsp+28]
mov rdi, rax
callstd::basic_istream
>::operator>>(int&)
mov esi, DWORD PTR [rsp+16]
mov ebx, DWORD PTR [rsp+24]
mov edi, OFFSET FLAT:_ZSt4cout
mov eax, DWORD PTR [rsp+20]
add ebx, esi
add esi, DWORD PTR [rsp+12]
add esi, eax
add ebx, eax
callstd::basic_ostream
>::operator<<(int)
mov esi, ebx
mov rdi, rax
callstd::basic_ostream
>::operator<<(int)
add rsp, 32
xor eax, eax
pop rbx
ret
```


Example 2:
https://godbolt.org/z/o61sx6dGh

Given the following code: 
```c++
int var_13; int var_14;
void test(int var_0, int var_4, int var_5) {
var_13 = var_0 + var_4 + var_5;  //line 3
var_14 = var_4 + var_5;  //"var_4 + var_5" can be replaced with the value
at line 3
}
```

We note that `var_4 + var_5` at line 4 in the test code can be replaced with
the value at line 3, but gcc-trunk -O3 does not:
```asm
test(int, int, int):
add edi, esi
add esi, edx
add edi, edx
mov DWORD PTR var_14[rip], esi
mov DWORD PTR var_13[rip], edi
ret
var_14:
.zero   4
var_13:
.zero   4
```

Example 3:
https://godbolt.org/z/caYT9E6Mz

Similar to example 2, but this is an example that might involve shifting
operations:
```c++
int var_14,var_27;
void test(int var_1, int var_3) {
var_14 = var_1 + var_1;
var_27 = var_3 + var_1 + var_1;
}
```
```asm
test(int, int):
lea eax, [rdi+rdi]
mov DWORD PTR var_14[rip], eax
lea eax, [rsi+rdi*2]
mov DWORD PTR var_27[rip], eax
ret
var_27:
.zero   4
var_14:
.zero   4
```

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug tree-optimization/111561] New: Missed optimization of available expression in if condition

2023-09-23 Thread 652023330028 at smail dot nju.edu.cn via Gcc-bugs

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

Bug ID: 111561
   Summary: Missed optimization of available expression in if
condition
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we found some optimizations (regarding Available Expression in If
condition) that GCC may have missed. We would greatly appreicate if you can
take a look and let us know what you think.

Here are two examples:

Example 1:
https://godbolt.org/z/vjWM5c93j

Given the following code: 
```c++
extern int var_26;
extern int var_29;
void test(int var_1, int var_2, int var_3) {
var_29 = (var_1 + var_2) ? var_1 : var_2;  //line 4
var_26 = var_1 + (var_2 + var_3); //can be replaced with the value at line
4
}
```

We note that `var_1+var_2` at line 5 in the test code can be replaced with the
value at line 4, but gcc-trunk -O3 does not:
```asm
test(int, int, int):
mov eax, edi
add eax, esi
mov eax, edi
cmove   eax, esi
add esi, edx
add esi, edi
mov DWORD PTR var_29[rip], eax
mov DWORD PTR var_26[rip], esi
ret
```


Example 2:
https://godbolt.org/z/31d8v453v

Given the following code: 
```c++
extern int var_24;
extern int var_25;
void test(int var_0, int var_1, int var_12) {
var_24 = (var_1 + var_12 + var_0) ? 1 : 2;
var_25 = var_12 + var_0;
}
```

We note that `var_12+var_0` at line 5 in the test code can be replaced with the
value at line 4, but gcc-trunk -O3 does not:
```asm
test(int, int, int):
add esi, edx
xor eax, eax
add esi, edi
seteal
add edx, edi
add eax, 1
mov DWORD PTR var_25[rip], edx
mov DWORD PTR var_24[rip], eax
ret
```

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug tree-optimization/111560] Missed optimization of available expression

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
The problem is in this case:
e=a+b+c;  //line 5
f=d+b+c;  //"b+c" can be replaced with the value at line 5

at the gimple level, b+c could introduce an signed integer overflow. And we
don't want to introduce that.


If you had used unsigned, rather than int, the optimization would have been
done as we do reassociate unsigned integers just fine.

[Bug tree-optimization/111562] New: Missed optimization when the value of another variable can be used directly

2023-09-23 Thread 652023330028 at smail dot nju.edu.cn via Gcc-bugs

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

Bug ID: 111562
   Summary: Missed optimization when the value of another variable
can be used directly
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we found some optimizations that GCC may have missed. We would greatly
appreicate if you can take a look and let us know what you think.

Example 1:
https://godbolt.org/z/nPW7j1xvq

Given the following code: 
```c++
int var22=0;
int var23=0;
void test(int var7, int var9, int var11, int var12) {
var22 = var12 + var9 + var11;
var23 = var12 + (var9 + var7 + var11);
}
```

In fact, `var23` can be directly optimized to `var22+var7`, but gcc-trunk -O3
does not:
```asm
test(int, int, int, int):
lea eax, [rcx+rsi]
add esi, edi
add esi, edx
add eax, edx
add esi, ecx
mov DWORD PTR var22[rip], eax
mov DWORD PTR var23[rip], esi
ret
var23:
.zero   4
var22:
.zero   4
```

Example 2:
https://godbolt.org/z/8vE69WPc7

Given the following code: 
```c++
extern int var_15;
extern int var_16;
void test(int var_2, int var_3, int var_4, int var_6, int var_9) {
var_15 = var_9 - (var_2 + var_6 + var_3 + var_4);
var_16 = var_4 + var_6 + var_2;
}
```

By adjusting the calculation order, the `var_16` calculation can actually use
the intermediate result of the `var_15` calculation process directly, but
gcc-trunk -O3 does not:
```asm
test(int, int, int, int, int):
lea eax, [rdi+rcx]
add ecx, edx
add eax, esi
add ecx, edi
add eax, edx
mov DWORD PTR var_16[rip], ecx
sub r8d, eax
mov DWORD PTR var_15[rip], r8d
ret
```

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug tree-optimization/111563] New: Missed optimization of LICM

2023-09-23 Thread 652023330028 at smail dot nju.edu.cn via Gcc-bugs

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

Bug ID: 111563
   Summary: Missed optimization of LICM
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we found some optimizations (regarding Loop Invariant Code Motion) that
GCC may have missed. We would greatly appreicate if you can take a look and let
us know what you think.
Here are two examples.


Example 1:
https://godbolt.org/z/cn9v45vdh

Given the following code: 
```c++
extern int var_12;
extern int var_13;
extern int var_17;
void test(int var_0, int var_1, int var_5, int var_6, int var_9) {

for (int i_4 = 1; i_4 < var_0-2147483638; i_4 += 1) 
{
var_17 += 1774623354;
if (var_9)
{
var_13 += var_1;
var_17 += var_6 + var_0;
var_12 += var_5;
}
else
{
var_17 += var_6;
}
i_4+=i_4/3;;
}
}
```

In fact, `var_6 + var_0` is a loop invariant, but gcc-trunk -O3:
```asm
test(int, int, int, int, int):
cmp edi, 2147483639
jle .L15
mov r9d, DWORD PTR var_17[rip]
lea r10d, [rdi-2147483638]
testr8d, r8d
jne .L4
lea edi, [rcx+1774623354]
mov edx, 1
lea ecx, [r9+1774623354+rcx]
.L5:
movsx   rax, edx
mov esi, edx
imulrax, rax, 1431655766
sar esi, 31
shr rax, 32
sub eax, esi
lea edx, [rdx+1+rax]
mov eax, ecx
add ecx, edi
cmp r10d, edx
jg  .L5
mov DWORD PTR var_17[rip], eax
ret
.L15:
ret
.L4:
mov eax, edi
mov edi, DWORD PTR var_13[rip]
pushrbx
mov ebx, esi
mov r11d, edx
lea r8d, [rax+1774623354+rcx]
add edi, esi
mov esi, DWORD PTR var_12[rip]
add esi, edx
mov edx, 1
.L7:
movsx   rax, edx
mov ecx, edx
add r9d, r8d
imulrax, rax, 1431655766
sar ecx, 31
shr rax, 32
sub eax, ecx
mov ecx, esi
add esi, r11d
lea edx, [rax+1+rdx]
mov eax, edi
add edi, ebx
cmp edx, r10d
jl  .L7
mov DWORD PTR var_17[rip], r9d
pop rbx
mov DWORD PTR var_12[rip], ecx
mov DWORD PTR var_13[rip], eax
ret
```


Example 2:
https://godbolt.org/z/418K59eoE

Given the following code: 
```c++
extern int var_24;
void test(int var_2, int var_3, int var_8, int var_10, int var_14) {

for (int i_2 = -3247424; i_2 < 19; i_2 += var_3 + 1056714155) 
{
if(var_3){
var_24 += (-(200 / var_10)) + (-var_8);
var_24 += var_14 + var_2;
}

i_2+=i_2/3;
}
}
```

We note that `(-(200 / var_10)) + (-var_8) + var_14 + var_2` as a whole can be
treated as a loop invariant, but gcc-trunk -O3 does not:
```asm
test(int, int, int, int, int):
mov r10d, edi
mov r11d, edx
testesi, esi
je  .L1
mov eax, -200
mov edx, -1
mov edi, DWORD PTR var_24[rip]
add r8d, r10d
idivecx
lea r9d, [rsi+1056714155]
mov ecx, -3247424
sub eax, r11d
.L3:
movsx   rdx, ecx
mov esi, ecx
add edi, eax
imulrdx, rdx, 1431655766
sar esi, 31
add edi, r8d
shr rdx, 32
sub edx, esi
add ecx, edx
add ecx, r9d
cmp ecx, 18
jle .L3
mov DWORD PTR var_24[rip], edi
.L1:
ret
```

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug tree-optimization/111561] Missed optimization of available expression in if condition

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Same issue as PR 111560 really.

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

[Bug tree-optimization/111560] Missed optimization of available expression

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

[Bug tree-optimization/111562] Missed optimization when the value of another variable can be used directly

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Same issue as PR 111560 .

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

[Bug tree-optimization/111560] Missed optimization of available expression

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

[Bug tree-optimization/111564] New: Missed optimization of Loop Unswitch

2023-09-23 Thread 652023330028 at smail dot nju.edu.cn via Gcc-bugs

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

Bug ID: 111564
   Summary: Missed optimization of Loop Unswitch
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we found some optimizations (regarding Loop Unswitch) that GCC may have
missed. We would greatly appreicate if you can take a look and let us know what
you think.
Here are two examples.


Example 1:
https://godbolt.org/z/G3xGvGxq1

Given the following code: 
```c++
extern int var_21;
extern int var_25;
extern int var_28;
extern int var_29;

void test(int var_0, int var_1, int var_2, int var_3, int var_4, int var_5, int
var_6, int var_7, int var_8, int var_9, int var_10, int var_11, int var_12, int
var_13, int var_14, int var_15, int var_16, int var_17) {
for (int i_0 = 0/*0*/; i_0 < var_17)) ? (((819565140) + (var_9))) :
var_16)) ? (2141366111) : (var_17)) ? (((var_4)) ? (var_16) :
(var_17 ? (779921519) : (((var_1) + (var_8) : (((var_10)) ?
(var_12) : (var_5 ? var_15)) ? (var_16) : (var_12))) : var_3)) ?
(var_0) : (var_11))) - (779921500))/*19*/; i_0 += 4/*4*/) 
{
var_21 += var_17;
if (var_3)
{
var_25 += var_17 ? -212529188 : (((var_6) ? (var_5 ? 2029341098 :
var_13) : var_11));
var_28 += var_8 ? ((var_10 ? (var_13 - var_1) : var_14 ? var_17 :
var_8)) : (var_6 ? 942541005 : var_1 / var_9);
var_29 += var_2 ? var_6 : ((var_9 ? var_8 : (var_11 ? var_2 :
var_15)));
}

}
}

```

Because `var_3` is a loop invariant so we can hoist the if condition out of the
loop, but gcc-trunk -O3 dose not (main parts):
```asm
test(int, int, int, int, int):

...

.L154:
cmp edx, ecx
jle .L9
testr10d, r10d
je  .L153

...

.L153:
add ecx, 4
mov eax, 1
jmp .L154
```


Example 2:
https://godbolt.org/z/WcMnz97jv

Given the following code: 
```c++
extern int var_13;
extern int var_15;
extern int var_17;
extern int var_19;
extern int var_20;
extern int var_24;

void test(int var_0, int var_1, int var_2, int var_3, int var_4, int var_5, int
var_6, int var_7, int var_8, int var_9, int var_10) {

for (int i_0 = ((var_9) + (1516547146))/*0*/; i_0 < (((-((-var_4)) ?
(var_6) : (var_8))) + (960893662))/*16*/; i_0 += ((var_0) +
(1994872666))/*1*/) 
{
if (var_1)
{
var_13 += (var_0 ? var_8 : var_7) ? (var_0 ? var_7 : var_4) :
((var_7 ? var_1 : var_2) ? 1 : 2);
}

var_15 += (var_0 ? var_9 : var_6) ? (var_4 ? !var_5 : (var_7 ? var_3 :
var_9)) : var_8;
var_17 += var_3 ? ((var_4 ? var_5 : var_8) ? var_3 : var_1) : (var_5 ?
var_8 : var_0);
var_19 += (var_1 ? var_8 : var_2) ? (var_1 ? (var_7 ? var_3 : var_9) :
!var_3) : var_9;
var_20 += var_10 ? var_3 : (var_4 ? var_10 : var_8);
var_24 += var_0 ? -var_5 : (var_8 ? (var_3 ? var_8 : var_1) : (var_6 ?
var_6 : var_5));
}
}
```

Similarly, `var_1` is an loop invariant and should be hoisted out of the loop
as well.
But gcc-trunk -O3 does not:
```asm
test(int, int, int, int, int):

...

.L273:
testecx, ecx
je  .L87
mov r8d, DWORD PTR [rsp+64]
add DWORD PTR [rsp-28], r8d
testebp, ebp
jne .L120
add DWORD PTR [rsp-32], ecx
testedx, edx
jne .L271
.L121:
mov BYTE PTR [rsp-14], 1
.L89:
mov ebx, DWORD PTR [rsp-12]
testr12d, r12d
cmovne  ebx, ecx
.L92:
add r9d, ebx
testr10d, r10d
je  .L100
.L102:
cmp BYTE PTR [rsp-13], 0
mov ebx, edx
jne .L103
.L99:
mov ebx, ebp
.L103:
mov r8d, DWORD PTR [rsp+88]
add edi, ebx
testr8d, r8d
je  .L104
.L274:
mov ebx, r11d
add eax, r13d
add esi, edx
sub ebx, r12d
cmp r15d, eax
jle .L272
.L130:
mov r11d, ebx
testr10d, r10d
jne .L273

...

```

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug tree-optimization/111564] Missed optimization of Loop Unswitch

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
/app/example.cpp:8:51: note: not unswitching condition, cost too big (45 insns
copied to 43 and 45)

[Bug tree-optimization/111564] Missed optimization of Loop Unswitch

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
For example 2:
/app/example.cpp:11:55: note: not unswitching condition, cost too big (53 insns
copied to 51 and 49)


So this is based on a cost model which seems reasonible ...

[Bug tree-optimization/111563] Missed optimization of LICM

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
_5 = var_0_16(D) + var_6_18(D);
  invariant up to level 1, cost 1.

Basically because the cost is not high enough ...

If you use   --param=lim-expensive=1. then it will pull it out of the loop.

So the cost model is doing the correct thing here ...

[Bug tree-optimization/111560] Missed optimization of available expression

2023-09-23 Thread 652023330028 at smail dot nju.edu.cn via Gcc-bugs

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

--- Comment #4 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #1)
> The problem is in this case:
> e=a+b+c;  //line 5
> f=d+b+c;  //"b+c" can be replaced with the value at line 5
> 
> at the gimple level, b+c could introduce an signed integer overflow. And we
> don't want to introduce that.
> 
> 
> If you had used unsigned, rather than int, the optimization would have been
> done as we do reassociate unsigned integers just fine.


Thank you very much for your quick reply!
But example 1 in Bug 111561 does not seem to be well resolved.
https://godbolt.org/z/cM4n8qvrh
Given the following code: 
```c++
extern unsigned var_26;
extern unsigned var_29;
void test(unsigned var_1, unsigned var_2, unsigned var_3) {
var_29 = (var_1 + var_2) ? var_1 : var_2;
var_26 = var_1 + (var_2 + var_3);
}

```

```asm
test(unsigned int, unsigned int, unsigned int):
mov eax, edi
add eax, esi
mov eax, edi
cmove   eax, esi
add esi, edx
add esi, edi
mov DWORD PTR var_29[rip], eax
mov DWORD PTR var_26[rip], esi
ret
```

So does Bug 111562 .

[Bug tree-optimization/111560] Missed optimization of available expression

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Yi from comment #4)
Right there is another issue which this is a dup of though but I can't find it
right now. The problem is reassociation only partly solves the issues.

[Bug tree-optimization/107887] (bool0 > bool1) | bool1 is not optimized to bool0 | bool1

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
The bigger question on this is canonical form here, is it `a < b` or `~a & b`.
If it is `a < b` then we need the ability to match `a < b` as `~a < b` but that
might get complex with bitwise_inverted_equal_p ...

[Bug middle-end/111551] Fix for PR106081 is not working with profile feedback on imagemagick

2023-09-23 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Blocks||26163
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
we don't know yet whether it's the vectorization?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/111543] `(a & b) & ~a` could be optimized before reassociation

2023-09-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:1bf0cd05cb30889cae4b6cf06e80b7f3a13c40c1

commit r14-4241-g1bf0cd05cb30889cae4b6cf06e80b7f3a13c40c1
Author: Andrew Pinski 
Date:   Sat Sep 23 04:38:02 2023 +

MATCH: Add `(X & ~Y) & Y` and `(X | ~Y) | Y`

Even though this gets optimized by reassociation, catching it more often
will always be better.

Note the reason why I didn't add `(X ^ ~Y) ^ Y` is that it gets caught
by prefering `~(X ^ Y)` to `(X ^ ~Y)` which then it is caught by the
the pattern for `(X ^ Y) ^ Y` already.

PR tree-optimization/111543

gcc/ChangeLog:

* match.pd (`(X & ~Y) & Y`, `(X | ~Y) | Y`): New patterns.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/bitops-4.c: New test.

[Bug tree-optimization/111543] `(a & b) & ~a` could be optimized before reassociation

2023-09-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |14.0
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/111560] Missed optimization of available expression

2023-09-23 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-24

--- Comment #6 from Richard Biener  ---
Confirmed.  Simpler testcase:

int e,f;
void test(int a, int b, int c, int d)
{
e=a+b+c;  //line 5
f=d+b+c;  //"b+c" can be replaced with the value at line 5
}

it's as Andrew says plus re-associating for global optimal CSE is difficult,
imagine adding

g = a + b + d;

to the above.  There's either a + b in common with e but then that breaks
commoning b + c in e and f or there is b + d in common with f also breaking
the other CSE.

Our re-association only produces a canonical order within a single expression. 
That doesn't by design allow CSE of common subexpressions in other expressions.

I don't know of any work (paper) describing how to attack this global
optimization problem.

[Bug tree-optimization/111564] Missed optimization of Loop Unswitch

2023-09-23 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
   Keywords||missed-optimization

--- Comment #3 from Richard Biener  ---
You can alter --param max-unswitch-insns to get these cases unswitched.

59 matches

Mail list logo