[Bug debug/106955] [13 Regression] '-fcompare-debug' failure w/ -std=c++20 -O1 -ftree-parallelize-loops=2 -fno-ipa-sra --param ggc-min-expand=55

2022-09-16 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106955

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||needs-bisection

[Bug fortran/106954] [12 Regression] compiler fail base on gfortran

2022-09-16 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106954

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
It works with 12.2

[Bug target/106952] Missed optimization: x < y ? x : y not lowered to minss

2022-09-16 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-09-17
 Target||x86_64-*-*

--- Comment #3 from Richard Biener  ---
The main issue is that combine is confused with the more complicated setup and
the x86 ieee min/max patterns and on the GIMPLE level we are not forming IEEE
compatible .FMIN and .FMAX plus the x86 backend doesn't announce any.

[Bug d/106832] Missing powerpc64le-linux support for D

2022-09-16 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832

--- Comment #25 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #24)
> I'd imagine all static asserts would be hit, so a lot more than that -
> floor, tan, sin, cos, pow, etc... - some of which are not exactly trivial to
> implement for the IBM format (I've looked at it on a couple occasions over
> the last decade).
Some could be helped along by just returning the result of libm functions
instead of implementing them inline, but then the C function declarations would
need the same attributes as std.math - notably many libm bindings in the
core.stdc.math module are not annotated with `pure`.

[Bug d/106832] Missing powerpc64le-linux support for D

2022-09-16 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832

--- Comment #24 from Iain Buclaw  ---
(In reply to Peter Bergner from comment #22)
> (In reply to Peter Bergner from comment #21)
> > For the record, this is what I'm testing with:
> 
> So we get farther, but ICE again at:
> /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.
> d:1104:9: error: static assert:  "Not implemented for this architecture"
>  1104 | static assert(0, "Not implemented for this architecture");
>   | ^
> /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.
> d:981:19: note: instantiated from here: ‘expImpl!real’
>   981 | return expImpl(x);
>   |   ^
> 
> Looking at expImpl(), it has implementations for all of the float types
> except for IBM128.  Maybe just need to add support for that???

I'd imagine all static asserts would be hit, so a lot more than that - floor,
tan, sin, cos, pow, etc... - some of which are not exactly trivial to implement
for the IBM format (I've looked at it on a couple occasions over the last
decade).

std/math/algebraic.d:696:static assert(0);
std/math/exponential.d:1104:static assert(0, "Not implemented for this
architecture");
std/math/exponential.d:1241:static assert(0, "No exp() tests for
real type!");
std/math/exponential.d:1514:static assert(0);
std/math/exponential.d:1590:static assert(0, "no coefficients for
expm1()");
std/math/exponential.d:1906:static assert(0);
std/math/exponential.d:1976:static assert(0, "no coefficients for
exp2()");
std/math/exponential.d:2804:else static assert(false, "Floating point type
real not supported");
std/math/hardware.d:764:static assert(false, "Not implemented for this
architecture");
std/math/hardware.d:879:static assert(false, "Not implemented for this
architecture");
std/math/hardware.d:896:static assert(false, "Not implemented for
this architecture");
std/math/operations.d:925:static assert(false, "Not implemented for
this architecture");
std/math/operations.d:1792:static assert(false, "Floating point
type `" ~ F.realFormat ~ "` not supported.");
std/math/package.d:418:static assert(false, "No traits support for
" ~ T.stringof);
std/math/package.d:482:static assert(false, "No traits support for " ~
T.stringof);
std/math/rounding.d:698:static assert(false, "real type not
supported by lrint()");
std/math/rounding.d:953:static assert(false, "Not implemented for this
architecture");
std/math/traits.d:305:static assert(false, "Not implemented for this
architecture");
std/math/trigonometry.d:305:static assert(0);
std/math/trigonometry.d:381:static assert(0, "no coefficients for
tan()");
std/math/trigonometry.d:758:static assert(0, "no coefficients for
atan()");

[Bug libstdc++/106953] C++23 add new headers for freestanding

2022-09-16 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106953

--- Comment #4 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #1)
> Yes, work has already started on this.

BTW TR1_STDINT is still not defined for freestanding without libc. cstdint does
not import any types like std::uint_least64_t.

[Bug libstdc++/106953] C++23 add new headers for freestanding

2022-09-16 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106953

--- Comment #3 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #1)
> Yes, work has already started on this.

https://github.com/cplusplus/draft/releases/download/n4917/n4917.pdf

I've tried but those headers are not installed. no utility etc.

[Bug d/106832] Missing powerpc64le-linux support for D

2022-09-16 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832

--- Comment #23 from Peter Bergner  ---
(In reply to Peter Bergner from comment #22)
> Looking at expImpl(), it has implementations for all of the float types
> except for IBM128.  Maybe just need to add support for that???

A few other places as well:

libphobos/src/std/math/exponential.d:
...
else // static if (F.realFormat == RealFormat.ibmExtended)
{
assert(0, "frexp not implemented");
}
...
else // static if (F.realFormat == RealFormat.ibmExtended)
{
assert(0, "ilogb not implemented");
}

and... libphobos/src/std/math/operations.d:
else // static if (F.realFormat == RealFormat.ibmExtended)
{
assert(0, "nextUp not implemented");
}

[Bug d/106832] Missing powerpc64le-linux support for D

2022-09-16 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832

--- Comment #22 from Peter Bergner  ---
(In reply to Peter Bergner from comment #21)
> For the record, this is what I'm testing with:

So we get farther, but ICE again at:
/home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.d:1104:9:
error: static assert:  "Not implemented for this architecture"
 1104 | static assert(0, "Not implemented for this architecture");
  | ^
/home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.d:981:19:
note: instantiated from here: ‘expImpl!real’
  981 | return expImpl(x);
  |   ^

Looking at expImpl(), it has implementations for all of the float types except
for IBM128.  Maybe just need to add support for that???

[Bug d/106832] Missing powerpc64le-linux support for D

2022-09-16 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832

--- Comment #21 from Peter Bergner  ---
(In reply to Peter Bergner from comment #20)
> So going back to my IBM128 build, I see that libphobos does have some code
> relating to mant_dig == 106 which is IBM128/IBM double-double, including in
> the file that's ICEing here due to the assert.  I've patched two asserts to
> allow IBM128 and I'm re-kicking off a bootstrap and regtest.  It might be
> that the only problem the asserts needed updating?  We'll see.

For the record, this is what I'm testing with:
diff --git a/libphobos/configure.tgt b/libphobos/configure.tgt
index 0063dd23249..e78688010ed 100644
--- a/libphobos/configure.tgt
+++ b/libphobos/configure.tgt
@@ -44,7 +44,6 @@ case "${target}" in
;;
   power*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
-   LIBDRUNTIME_ONLY=yes
;;
   riscv*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
diff --git a/libphobos/src/std/math/package.d
b/libphobos/src/std/math/package.d
index 19982ec216a..d0752032d1f 100644
--- a/libphobos/src/std/math/package.d
+++ b/libphobos/src/std/math/package.d
@@ -318,13 +318,14 @@ do
 version (LittleEndian)
 {
 static assert(real.mant_dig == 53 || real.mant_dig == 64
-   || real.mant_dig == 113,
+ || real.mant_dig == 106 || real.mant_dig == 113,
   "Only 64-bit, 80-bit, and 128-bit reals"~
   " are supported for LittleEndian CPUs");
 }
 else
 {
-static assert(real.mant_dig == 53 || real.mant_dig == 113,
+static assert(real.mant_dig == 53 || real.mant_dig == 106
+ || real.mant_dig == 113,
 "Only 64-bit and 128-bit reals are supported for BigEndian CPUs.");
 }

[Bug d/106832] Missing powerpc64le-linux support for D

2022-09-16 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #20 from Peter Bergner  ---
(In reply to Peter Bergner from comment #13)
> Ok, I see the following on a powerpc64le-linux build on a system that
> defaults to long double == IBM128.
> 
> /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/package.d:
> 320:5: error: static assert:  "Only 64-bit, 80-bit, and 128-bit reals are
> supported for LittleEndian CPUs"
>   320 | static assert(real.mant_dig == 53 || real.mant_dig == 64

So going back to my IBM128 build, I see that libphobos does have some code
relating to mant_dig == 106 which is IBM128/IBM double-double, including in the
file that's ICEing here due to the assert.  I've patched two asserts to allow
IBM128 and I'm re-kicking off a bootstrap and regtest.  It might be that the
only problem the asserts needed updating?  We'll see.

[Bug libstdc++/106953] C++23 add new headers for freestanding

2022-09-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106953

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

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

commit r13-2705-gcf0fded5d837bad590eb091d8a3dc4898872560f
Author: Jonathan Wakely 
Date:   Thu Sep 15 21:02:32 2022 +0100

libstdc++: Add preprocessor conditions for freestanding [PR106953]

This adds checks for _GLIBCXX_HOSTED to a number of headers which are
not currently installed for freestanding, but need to be for P1642R11
support. For example,  needs to be installed for C++23
freestanding mode, but without stream iterators and streambuf iterators.
Similarly,  needs to be installed, but without std::allocator
and std::shared_ptr. This change disables the non-freestanding parts of
those headers.

libstdc++-v3/ChangeLog:

PR libstdc++/106953
* include/backward/auto_ptr.h [!_GLIBCXX_HOSTED]: Do not define
shared_ptr members.
* include/bits/alloc_traits.h [!_GLIBCXX_HOSTED]: Do not declare
std::allocator_traits> specializations for
freestanding.
* include/bits/memoryfwd.h [!_GLIBCXX_HOSTED] (allocator): Do
not declare for freestanding.
* include/bits/stl_algo.h [!_GLIBCXX_HOSTED] (stable_partition):
Do not define for freestanding.
[!_GLIBCXX_HOSTED] (merge, stable_sort): Do not use temporary
buffers for freestanding.
* include/bits/stl_algobase.h [!_GLIBCXX_HOSTED]: Do not declare
streambuf iterators and overloaded algorithms using them.
* include/bits/stl_uninitialized.h [!_GLIBCXX_HOSTED]: Do not
define specialized overloads for std::allocator.
* include/bits/unique_ptr.h [!_GLIBCXX_HOSTED] (make_unique)
(make_unique_for_overwrite, operator<<): Do not define for
freestanding.
* include/c_global/cstdlib [!_GLIBCXX_HOSTED] (_Exit): Declare.
Use _GLIBCXX_NOTHROW instead of throw().
* include/debug/assertions.h [!_GLIBCXX_HOSTED]: Ignore
_GLIBCXX_DEBUG for freestanding.
* include/debug/debug.h [!_GLIBCXX_DEBUG]: Likewise.
* include/std/bit [!_GLIBCXX_HOSTED]: Do not use the custom
__int_traits if  is available.
* include/std/functional [!_GLIBCXX_HOSTED]: Do not include
headers that aren't valid for freestanding.
(boyer_moore_searcher, boyer_moore_horspool_searcher): Do not
define for freestanding.
* include/std/iterator [!_GLIBCXX_HOSTED]: Do not include
headers that aren't valid for freestanding.
* include/std/memory [!_GLIBCXX_HOSTED]: Likewise.
* include/std/ranges [!_GLIBCXX_HOSTED] (istream_view): Do not
define for freestanding.
(views::__detail::__is_basic_string_view) [!_GLIBCXX_HOSTED]:
Do not define partial specialization for freestanding.

[Bug tree-optimization/106958] [13 Regression] ICE in reassoc since r13-2658

2022-09-16 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106958

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

Untested fix.

[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240

2022-09-16 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287

--- Comment #9 from anlauf at gcc dot gnu.org ---
*** Bug 100025 has been marked as a duplicate of this bug. ***

[Bug fortran/100025] [10/11/12/13 Regression] ICE on subroutine missing explicit interface

2022-09-16 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100025

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||anlauf at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from anlauf at gcc dot gnu.org ---
The basic issue seems to have been fixed by the patch for PR103287,
and the present patch would collide with that one.

Marking as fixed & duplicate.

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

[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240

2022-09-16 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jrfsousa at gcc dot gnu.org

--- Comment #8 from anlauf at gcc dot gnu.org ---
*** Bug 100024 has been marked as a duplicate of this bug. ***

[Bug fortran/100024] [10/11/12/13 Regression] ICE on subroutine missing explicit interface

2022-09-16 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100024

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
The basic issue seems to have been fixed by the patch for PR103287,
and the present patch would collide with that one.

Marking as fixed & duplicate.

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

[Bug libstdc++/106932] [DR 3057] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Incorrect behavior of   |[DR 3057] Incorrect
   |std::filesystem::copy() |behavior of
   |with overwrite_existing or  |std::filesystem::copy()
   |update_existing options |with overwrite_existing or
   ||update_existing options
 Status|RESOLVED|SUSPENDED
   Last reconfirmed||2022-09-16
 Resolution|INVALID |---

--- Comment #9 from Jonathan Wakely  ---
Ah yes, thanks. I thought we'd resolved Davis's filesystem enum issues, but not
that one.
Let's suspend this bug then, pending a resolution from the committee.

[Bug libstdc++/103626] _GLIBCXX_HOSTED should respect -ffreestanding

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-16

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> Libstdc++ should not define _GLIBCXX_HOSTED to 1 when __STD_HOSTED__ == 0
> i.e. when -ffreestanding is used.

That should be as simple as:

> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index 9aa81e1ac13..1b404d7df22 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -2992,7 +2992,7 @@ AC_DEFUN([GLIBCXX_ENABLE_HOSTED], [
>  fi
>else
>  is_hosted=yes
> -hosted_define=1
> +hosted_define=__STDC_HOSTED__
>fi
>GLIBCXX_CONDITIONAL(GLIBCXX_HOSTED, test $is_hosted = yes)
>AC_DEFINE_UNQUOTED(_GLIBCXX_HOSTED, $hosted_define,
> diff --git a/libstdc++-v3/include/Makefile.am 
> b/libstdc++-v3/include/Makefile.am
> index 3eeb407a57f..3472e84f75c 100644
> --- a/libstdc++-v3/include/Makefile.am
> +++ b/libstdc++-v3/include/Makefile.am
> @@ -1326,7 +1326,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
>   ${CONFIG_HEADER} > /dev/null 2>&1 \
>   && ldbl_alt128_compat='s,^#undef 
> _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT$$,#define 
> _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT 1,' ;\
>   verbose_assert='s,g,g,' ; \
> - grep "^[ ]*#[]*define[   ][  ]*_GLIBCXX_HOSTED[ 
>  ][  ]*1[]*$$" \
> + grep "^[ ]*#[]*define[   ][  ]*_GLIBCXX_HOSTED[ 
>  ][  ]*__STDC_HOSTED__[  ]*$$" \
>   ${CONFIG_HEADER} > /dev/null 2>&1 \
>   && grep "^[  ]*#[]*define[   ][  ]*_GLIBCXX_VERBOSE[
>  ][  ]*1[]*$$" \
>   ${CONFIG_HEADER} > /dev/null 2>&1 \


> The --disable-hosted-libstdcxx configure option will still allow
> installation of a library that can never be used as hosted, but it will also
> be possible to use an existing hosted implementation in freestanding mode.

This would mean that a full set of library headers would be available for
inclusion in programs compiled with -ffreestanding, so to prevent the
non-freestanding ones being included we should add to them:

#if !_GLIBCXX_HOSTED
# error "This header is not supported in freestanding mode"
#endif

Then we can teach the testsuite to recognise that error and skip a test as
UNSUPPORTED. That will allow the full testsuite to be run without changing
thousands of individual tests with something like "{
dg-require-effective-target hosted }". The tests that aren't valid for
freestanding will just be UNSUPPORTED when -ffreestanding is in the
runtestflags.

We might need to also strip -ffreestanding from the flags when building the
libtestc++.a support lib used by the testsuite, because that lib requires
hosted features.

This all seems doable though.

[Bug tree-optimization/106958] [13 Regression] ICE in reassoc since r13-2658

2022-09-16 Thread jeffreyalaw at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106958

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||jeffreyalaw at gmail dot com

--- Comment #1 from Jeffrey A. Law  ---
Note this affects glibc builds on various targets.  For example, sh3-linux-gnu
with this reduced testcase:

int
fmtmsg (int severity, const char *text, const char *action)
{
  int do_severity = severity != 0;
  int do_text = text != ((char *) 0);
  int do_action = action != ((char *) 0);
  int need_colon = do_severity | do_text | do_action ;
  frob (need_colon);
}

[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79

2022-09-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

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

commit r12-8769-gf5023ce74f882b7f7c8cf41e70cc7380ba0eba06
Author: Harald Anlauf 
Date:   Thu Sep 15 22:39:24 2022 +0200

Fortran: catch NULL pointer dereferences while simplifying PACK [PR106857]

gcc/fortran/ChangeLog:

PR fortran/106857
* simplify.cc (gfc_simplify_pack): Check for NULL pointer
dereferences
while walking through constructors (error recovery).

gcc/testsuite/ChangeLog:

PR fortran/106857
* gfortran.dg/pr106857.f90: New test.

(cherry picked from commit 2b75d5f533b9d6b39f4055949aff64ed0d22dd24)

[Bug fortran/100245] ICE on automatic reallocation

2022-09-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245

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

https://gcc.gnu.org/g:9035eaaf028ca609660f1f55c0d9f22fb7d3b797

commit r12-8768-g9035eaaf028ca609660f1f55c0d9f22fb7d3b797
Author: José Rui Faustino de Sousa 
Date:   Fri Sep 2 21:35:22 2022 +0200

Fortran: Fix ICE with automatic reallocation [PR100245]

gcc/fortran/ChangeLog:

PR fortran/100245
* trans-expr.cc (trans_class_assignment): Add if clause to handle
derived type in the LHS.

gcc/testsuite/ChangeLog:

PR fortran/100245
* gfortran.dg/PR100245.f90: New test.

(cherry picked from commit 504424f33771be0405454e7845219d5df1bb88bb)

[Bug tree-optimization/106958] [13 Regression] ICE in reassoc since r13-2658

2022-09-16 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106958

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-09-16
   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Priority|P3  |P1
 Ever confirmed|0   |1

[Bug tree-optimization/106958] New: [13 Regression] ICE in reassoc since r13-2658

2022-09-16 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106958

Bug ID: 106958
   Summary: [13 Regression] ICE in reassoc since r13-2658
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

As reported privately to me, on armv7hl-linux-gnueabi my
r13-2658-g645ef01a463f15fc230e2155719c7a12cec89acf
change causes ICE on the following testcase at -O2:
int a;
void bar (int);

void
foo (char *x, char *y)
{
  int b = a != 0;
  int c = x != 0;
  int d = y != 0;
  bar (b | c | d);
}

[Bug d/106832] Missing powerpc64le-linux support for D

2022-09-16 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832

--- Comment #19 from Peter Bergner  ---
(In reply to Peter Bergner from comment #17)
> Bah, you are correct.  I forgot I needed to add an explicit configure option
> to get the IEEE128 default.  I'll kick it off again!  Thanks!

Ok, my Fedora36 (ie, a default IEEE128 system) bootstrap using
--with-long-double-format=ieee (and LIBDRUNTIME_ONLY=yes removed) completed
with no errors and this is my gdc testsuite results, which looks pretty good to
me (ie, vast majority of gdc tests pass).  I can look into the few errors here,
but after I look into the IBM128 default system build issue.

=== gdc tests ===


Running target unix
FAIL: gdc.dg/Wbuiltin_declaration_mismatch1.d(test for warnings, line 10)
FAIL: gdc.dg/torture/gdc309.d   -O0  execution test
FAIL: gdc.dg/torture/gdc309.d   -O0 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -O1  execution test
FAIL: gdc.dg/torture/gdc309.d   -O1 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -O2  execution test
FAIL: gdc.dg/torture/gdc309.d   -O2 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -O3  execution test
FAIL: gdc.dg/torture/gdc309.d   -O3 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -Os  execution test
FAIL: gdc.dg/torture/gdc309.d   -Os -g  execution test
UNRESOLVED: gdc.test/runnable/constfold.d   compilation failed to produce
executable
UNRESOLVED: gdc.test/runnable/constfold.d -shared-libphobos   compilation
failed to produce executable
FAIL: gdc.test/runnable/xtest46.d   execution test
FAIL: gdc.test/runnable/xtest46.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/xtest46_gc.d   execution test
FAIL: gdc.test/runnable/xtest46_gc.d -shared-libphobos   execution test

=== gdc Summary ===

# of expected passes11442
# of unexpected failures15
# of unresolved testcases   2
# of unsupported tests  442
/home/bergner/gcc/build/gcc-fsf-master-lang-D/gcc/gdc  version 13.0.0 20220916
(experimental) (GCC)

[Bug libstdc++/58628] Incorrect std::isalpha results with UTF-8 locale on illumos

2022-09-16 Thread alp at rsu dot ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58628

--- Comment #4 from Alexander Pyhalov  ---
If it helps, the last comment from illumos-gate bug report says

"From what I can tell ctype::_M_initialize_ctype() in
gcc-5.1.0/ibstdc++-v3/config/locale/generic/ctype_members.cc:248 is basically
just calling btowc(i) for all i <= 0 <= 255 and storing the result. If
std::locale::classic() is called before the setlocale() call in the test
program, things happen to work, but apparently the initialization uses whatever
the current locale is."

[Bug libstdc++/58628] Incorrect std::isalpha results with UTF-8 locale on illumos

2022-09-16 Thread alp at rsu dot ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58628

--- Comment #3 from Alexander Pyhalov  ---
I still see this behavior with gcc version 10.4.0.

[Bug c++/106654] [C++23] P1774 - Portable assumptions

2022-09-16 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654

--- Comment #6 from Jakub Jelinek  ---
(In reply to Pilar Latiesa from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Note, I think for [[assume(i == j)]]; we can just emit if (i == j) ; else
> > __builtin_unreachable ();
> 
> It would be great if the attribute were somewhat cleverer than that.

You've cut the second part of sentence, the above was meant for
!TREE_SIDE_EFFECTS conditions and the rest is about how to treat conditions
which do have side-effects (and that we should probably use more than just
TREE_SIDE_EFFECTS test, but watch for any expressions that could possibly raise
exceptions, or fault or trap).
For the simple cases, we already can handle it without actually invoking
anything at runtime and it will be cheaper compile time to handle it as before,
for the more complex expressions sure, we need to come up with something new
and make ranger and perhaps other optimizations be able to cope with it.
BTW, the C++ paper mentions clang __builtin_assume, but that one seems to do
roughly what our if (cond) ; else __builtin_unreachable (); does (which they I
think support too) only if the expression doesn't contain side-effects.  If it
does, it warns and doesn't do anything at all.

[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options

2022-09-16 Thread rs2740 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #8 from TC  ---
https://cplusplus.github.io/LWG/issue3057?

[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-09-16
 Ever confirmed|0   |1

--- Comment #13 from Jonathan Wakely  ---
(In reply to bug-reports.delphin from comment #11)
> Another compilation error with 12.2.0 (NB Please see bug n. 106956).
> Maybe Lion too old ? Bad compilers(s) (GCC, Python...) ?

No, still the same problem, you still have a comma in your path.

Please fix that and try again.

[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819

--- Comment #12 from Jonathan Wakely  ---
*** Bug 106956 has been marked as a duplicate of this bug. ***

[Bug regression/106956] GCC 12.2.0 & Mac OS X Lion : make failed

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106956

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
You're still using commas in your paths:

/Volumes/External_7/_Ze-Bins/_GNU-Compilers/_12,2.x/share/gcc-12.2.0/python
   ^
   here

So this is the same problem.

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

[Bug c++/106957] New: compiler error when calling lambda in decltype in trailing return type of function templated on T when passing T{} to the lambda

2022-09-16 Thread enricomaria.dean6elis at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106957

Bug ID: 106957
   Summary: compiler error when calling lambda in decltype in
trailing return type of function templated on T when
passing T{} to the lambda
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enricomaria.dean6elis at gmail dot com
  Target Milestone: ---

Created attachment 53586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53586=edit
the output/error upon compilation

Repro on godbolt (https://godbolt.org/z/9T5aEnzYa)

Question on stackoverlow with a comment sayint that the code would be illegal
anyway:
https://stackoverflow.com/questions/73747517/sfinae-ing-on-a-nullary-lambda-expression-calling-a-non-templated-function-on-a

Here's the code
```
#include 

constexpr auto f = [](int){};

template
auto canCallFOn(T) -> decltype([]{ f(T{}); }(), std::true_type{});

constexpr std::false_type canCallFOn(...) {
return {};
}

int main() {
static_assert(!canCallFOn(1));
static_assert(!canCallFOn(""));
}
```

[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I

2022-09-16 Thread bug-reports.delphin at laposte dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819

--- Comment #11 from bug-reports.delphin at laposte dot net ---
Another compilation error with 12.2.0 (NB Please see bug n. 106956).
Maybe Lion too old ? Bad compilers(s) (GCC, Python...) ?

Kind regards,

[Bug regression/106956] GCC 12.2.0 & Mac OS X Lion : make failed

2022-09-16 Thread bug-reports.delphin at laposte dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106956

--- Comment #2 from bug-reports.delphin at laposte dot net ---
Created attachment 53585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53585=edit
make.log

[Bug regression/106956] GCC 12.2.0 & Mac OS X Lion : make failed

2022-09-16 Thread bug-reports.delphin at laposte dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106956

--- Comment #1 from bug-reports.delphin at laposte dot net ---
Created attachment 53584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53584=edit
configure.log

[Bug regression/106956] New: GCC 12.2.0 & Mac OS X Lion : make failed

2022-09-16 Thread bug-reports.delphin at laposte dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106956

Bug ID: 106956
   Summary: GCC 12.2.0 & Mac OS X Lion : make failed
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bug-reports.delphin at laposte dot net
  Target Milestone: ---

Created attachment 53583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53583=edit
config.log

Summary : building GCC v. 12.2.0 under Mac OS X Lion (10.7.x) failed when Make,
although ./configure passed. Hereafter some details about the compilation
(make) process, with enclosed three log (text) files.

OS X : Lion (10.7.x : last version - combo downlaod and installation)
Compiler used : GCC v. 6.5.x (please read teh config.log file), built under OS
X Lion with YOUR code source.

Results :
- configure worked, but make failed ;
- regression compared to the last version of GCC compiled under the same
conditions (namely, 11.3.0) ;
- make error with GCC 12.1.0 : I issued an error for this).

Remark : GCC 12.2.0 (and 12.1.0) should be kindly reviewed why this is a
regression in the compilation process.

For all IT developers and scientists using GCC for their work.
Kind regards !

[Bug c++/92505] Using mutable in constexpr

2022-09-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:7107ea6fb933f1e928593c7e92edfd64ccf0df63

commit r13-2701-g7107ea6fb933f1e928593c7e92edfd64ccf0df63
Author: Patrick Palka 
Date:   Fri Sep 16 11:10:43 2022 -0400

c++: 'mutable' member within constexpr [PR92505]

This patch permits accessing 'mutable' members of local objects during
constexpr evaluation, while continuing to reject it for global objects
(as in the last line of cpp0x/constexpr-mutable1.C).  To distinguish
between the two cases, it looks like it suffices to just check
CONSTRUCTOR_MUTABLE_POSION in cxx_eval_component_reference before
deciding to reject a DECL_MUTABLE_P member access.

PR c++/92505

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_component_reference): Check non_constant_p
sooner.  In C++14 or later, reject a DECL_MUTABLE_P member access
only if CONSTRUCTOR_MUTABLE_POISION is also set.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-mutable3.C: New test.
* g++.dg/cpp1y/constexpr-mutable1.C: New test.

[Bug c++/106926] string_view construction from literal string containing null/zero should warn

2022-09-16 Thread jzwinck at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106926

--- Comment #4 from John Zwinck  ---
Jonathan, thank you for the discussion, I agree with your points and think
adding an attribute for this makes sense.

[Bug c++/106858] [12/13 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'baselink' in cp_ubsan_maybe_instrument_member_access, at cp/cp-ubsan.cc:172 since r12-58

2022-09-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106858

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:39dc66558e066e67fd40f21f53cee80989ae742d

commit r13-2696-g39dc66558e066e67fd40f21f53cee80989ae742d
Author: Jason Merrill 
Date:   Thu Sep 15 22:55:50 2022 +0200

c++: member fn in omp loc list [PR106858]

this-f names a member function, which isn't an addressable lvalue.  Give a
helpful error instead of crashing.  The first hunk makes the error range
cover the whole expression.

PR c++/106858

gcc/cp/ChangeLog:

* parser.cc (cp_parser_omp_var_list_no_open): Pass the
initial token location down.
* semantics.cc (finish_omp_clauses): Check
invalid_nonstatic_memfn_p.
* typeck.cc (invalid_nonstatic_memfn_p): Handle null TREE_TYPE.

gcc/testsuite/ChangeLog:

* g++.dg/gomp/map-3.C: New test.

[Bug debug/106955] New: [13 Regression] '-fcompare-debug' failure w/ -std=c++20 -O1 -ftree-parallelize-loops=2 -fno-ipa-sra --param ggc-min-expand=55

2022-09-16 Thread asolokha at gmx dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106955

Bug ID: 106955
   Summary: [13 Regression] '-fcompare-debug' failure w/
-std=c++20 -O1 -ftree-parallelize-loops=2 -fno-ipa-sra
--param ggc-min-expand=55
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 53582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53582=edit
gkd diff

g++ 13.0.0 20220911 snapshot (g:0ea5e3f4542832b8da016b152695e64a2a386309) fails
-fcompare-debug check when compiling the following testcase, reduced from
test/std/containers/sequences/forwardlist/forwardlist.ops/sort.pass.cpp from
the libc++ 14.0.6 test suite, w/ -std=c++20 -O1 -ftree-parallelize-loops=2
-fno-ipa-sra --param ggc-min-expand=55:

#include 
#include 
#include 
#include 

void
test_stable ()
{
  std::vector v;

  for (int i = 0; i < 1000; ++i)
v.push_back (i);

  for (int i = 0; i < 1000; ++i)
v[i] = i;
}

% g++-13.0.0 -std=c++20 -O1 -fcompare-debug -ftree-parallelize-loops=2
-fno-ipa-sra --param ggc-min-expand=55 -c dfptqjrz.cpp
g++-13.0.0: error: dfptqjrz.cpp: '-fcompare-debug' failure

gkd diff attached.

Preprocessed testcase is still being reduced, currently at
06:43:08 INFO (66.7%, 468334 bytes, 7781 lines)
I'll post it here once the reducer yields something meaningful under several
kilobytes in size.

[Bug fortran/106954] New: [12 Regression] compiler fail base on gfortran

2022-09-16 Thread zhongyunde at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106954

Bug ID: 106954
   Summary: [12 Regression] compiler fail base on gfortran
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

hi
  base on https://gcc.godbolt.org/z/9bonaW4eh, we can see that `aarch64
gfortran` 12  has some regression.
  * x86-x64 gfortran 12 -- pass
  * aarch64 gfortran 12 -- fail 
  * aarch64 gfortran 8  -- pass

[Bug c++/99243] [modules] ICE in set_filename, at cp/module.cc:19143

2022-09-16 Thread egor.pugin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99243

--- Comment #5 from Egor Pugin  ---
Possible naive fix is to change in module.cc (void module_state::set_filename
(const Cody::Packet )):

-  error_at (loc, "unknown Compiled Module Interface: %s",
packet.GetString ().c_str ());
+  fatal_error (loc, "unknown Compiled Module Interface: %s",
packet.GetString ().c_str ());

If we do not fail here, tons of ICEs come later because other code does not
expect such mismatches. (There can be communication error, so we do not get
same number of packets sent about querying modules, or another error.)

For example, the following function

static void
name_pending_imports (cpp_reader *reader)

iterates over responses and does not check for r_iter == response.end()

  module->set_filename (*r_iter);
  ++r_iter;

[Bug c++/99243] [modules] ICE in set_filename, at cp/module.cc:19143

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99243

Jonathan Wakely  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #4 from Jonathan Wakely  ---
*** Bug 98719 has been marked as a duplicate of this bug. ***

[Bug c++/98719] [modules] translating importable standard headers causes various ICEs

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98719

Jonathan Wakely  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
Looks like the same issue as PR 99243

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

[Bug c++/103524] [meta-bug] modules issue

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 98719, which changed state.

Bug 98719 Summary: [modules] translating importable standard headers causes 
various ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98719

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/99243] [modules] ICE in set_filename, at cp/module.cc:19143

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99243

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-16
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to Egor Pugin from comment #2)
> See explanation of this issue and the potential fix at the second part of
> the PR.
> https://github.com/urnathan/libcody/pull/27#issue-1132612910

Please provide that info here (separate from the whitespace change that was the
subject of that pull request).

[Bug c++/106654] [C++23] P1774 - Portable assumptions

2022-09-16 Thread pilarlatiesa at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654

Pilar Latiesa  changed:

   What|Removed |Added

 CC||pilarlatiesa at gmail dot com

--- Comment #5 from Pilar Latiesa  ---
(In reply to Jakub Jelinek from comment #4)
> Note, I think for [[assume(i == j)]]; we can just emit if (i == j) ; else
> __builtin_unreachable ();

It would be great if the attribute were somewhat cleverer than that. 

For example:

double my_sqrt(double const d)
{
[[assume(d >= 0.0)]];
return std::sqrt(d);
}

or even:

double my_sqrt(double const d)
{
[[assume(std::isfinite(std::sqrt(d)))]]
return std::sqrt(d);
}

[Bug libstdc++/106953] C++23 add new headers for freestanding

2022-09-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106953

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||106749

--- Comment #1 from Jonathan Wakely  ---
Yes, work has already started on this.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
[Bug 106749] Implement C++23 library features

[Bug libstdc++/106953] New: C++23 add new headers for freestanding

2022-09-16 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106953

Bug ID: 106953
   Summary: C++23 add new headers for freestanding
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1642r11.html

It now requires utility, tuple, ratio to be fully freestanding. memory,
functional, iterator and ranges to be partial freestanding.

https://en.cppreference.com/w/cpp/freestanding

Time to add them.

[Bug target/106910] roundss not vectorized

2022-09-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910

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

https://gcc.gnu.org/g:3e8c4b925a9825fdb8c81f47b621f63108894362

commit r13-2694-g3e8c4b925a9825fdb8c81f47b621f63108894362
Author: liuhongt 
Date:   Thu Sep 15 18:43:16 2022 +0800

Modernize ix86_builtin_vectorized_function with corresponding expanders.

For ifloor/lfloor/iceil/lceil/irint/lrint/iround/lround when size of
in_mode is not equal out_mode, vectorizer doesn't go to internal fn
way,still left that part in the ix86_builtin_vectorized_function.

Remove others builtins and add corresponding expanders.

gcc/ChangeLog:

PR target/106910
* config/i386/i386-builtins.cc
(ix86_builtin_vectorized_function): Modernized with
corresponding expanders.
* config/i386/sse.md (lrint2): New
expander.
(floor2): Ditto.
(lfloor2): Ditto.
(ceil2): Ditto.
(lceil2): Ditto.
(btrunc2): Ditto.
(lround2): Ditto.
(exp22): Ditto.