Thomas Koenig [Mon, 10 Jan 2022 22:34:56 +0000 (23:34 +0100)]
Handle R16 conversion for POWER in the environment variables.
This patch handles the environment variables for the REAL(KIND=16)
variables like for the little/big-endian routines, so users without
who have no access to the source or are unwilling to recompile
can use this.
Thomas Koenig [Sun, 9 Jan 2022 15:35:21 +0000 (16:35 +0100)]
Implement CONVERT specifier for OPEN.
This patch, based on Jakub's work, implements the CONVERT
specifier for the power-ieee128 brach. It allows specifying
the conversion as r16_ieee,big_endian and the other way around,
based on a table. Setting the conversion via environment
variable and via program option does not yet work.
gcc/ChangeLog:
* flag-types.h (enum gfc_convert): Add flags for
conversion.
gcc/fortran/ChangeLog:
* libgfortran.h (unit_convert): Add flags.
libgfortran/ChangeLog:
* Makefile.in: Regenerate.
* io/file_pos.c (unformatted_backspace): Mask off
R16 parts for convert.
* io/inquire.c (inquire_via_unit): Add cases for
R16 parts.
* io/open.c (st_open): Add cases for R16 conversion.
* io/transfer.c (unformatted_read): Adjust for R16 conversions.
(unformatted_write): Likewise.
(us_read): Mask of R16 bits.
(data_transfer_init): Likewiese.
(write_us_marker): Likewise.
It seems all these come from f951 compiled sources.
For user code, I think the agreement was if you want to use successfully
-mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran
FE doesn't conditionalize on whether glibc 2.32 is available or not and just
emits __WHATEVERieee128 entrypoints.
But for Fortran compiled sources in libgfortran, we need to use
__WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from
libquadmath) otherwise.
The following patch implements that, adds -fbuilding-libgfortran option
similar to e.g. -fbuilding-libgcc used when building libgcc and if
that option is set and the TARGET_GLIBC_{MAJOR,MINOR} macros indicate
no glibc or glibc older than 2.32, it will use the libquadmath APIs
rather than glibc 2.32 APIs.
2022-01-07 Jakub Jelinek <jakub@redhat.com>
gcc/fortran/
* trans-types.c (gfc_init_kinds): When setting abi_kind to 17, if not
targetting glibc 2.32 or later and -fbuilding-libgfortran, set
gfc_real16_is_float128 and c_float128 in gfc_real_kinds.
(gfc_build_real_type): Don't set c_long_double if c_float128 is
already set.
* trans-intrinsic.c (builtin_decl_for_precision): Don't use
long_double_built_in if gfc_real16_is_float128 and
long_double_type_node == gfc_float128_type_node.
* lang.opt (fbuilding-libgfortran): New undocumented option.
libgfortran/
* Makefile.am (AM_FCFLAGS): Add -fbuilding-libgfortran after
-fallow-leading-underscore.
* Makefile.in: Regenerated.
Allow other languages to change long double format.
With Fortran adding support for changing the long double format, this
patch removes the code that only allowed C/C++ to change the long double
format for GLIBC 2.32 and later without a warning.
gcc/
2022-01-05 Michael Meissner <meissner@the-meissners.org>
* config/rs6000/rs6000.c (rs6000_option_override_internal): Remove
checks for only C/C++ front ends before allowing the long double
format to change without a warning.
Jakub Jelinek [Tue, 4 Jan 2022 21:36:57 +0000 (22:36 +0100)]
testsuite: Fix pr47614.f test
This test FAILs because
f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support
compiler exited with status 1
FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors)
As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't
be testing with that option.
2022-01-04 Jakub Jelinek <jakub@redhat.com>
* gfortran.dg/pr47614.f: Don't use -mcpu=power4 for
powerpc64le*-*-linux*.
Another patch, this fixes:
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O0 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O1 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O2 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -g execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -Os execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O0 execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O1 execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O2 execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -g execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -Os execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O0 execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O1 execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O2 execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -g execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -Os execution test
FAIL: gfortran.dg/quad_2.f90 -O0 execution test
FAIL: gfortran.dg/quad_2.f90 -O1 execution test
FAIL: gfortran.dg/quad_2.f90 -O2 execution test
FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/quad_2.f90 -O3 -g execution test
FAIL: gfortran.dg/quad_2.f90 -Os execution test
2022-01-04 Jakub Jelinek <jakub@redhat.com>
gcc/fortran/
* trans-io.c (transfer_array_desc): Pass abi kind instead of kind
to libgfortran.
libgfortran/
* io/read.c (convert_real): Add missing break; for the
HAVE_GFC_REAL_17 case.
Jakub Jelinek [Tue, 4 Jan 2022 14:54:22 +0000 (15:54 +0100)]
libgfortran: -mabi=ieeelongdouble I/O fix
The following patch fixes:
FAIL: gfortran.dg/fmt_en.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_en_ru.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_ru.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en_ru.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_en_ru.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_en_ru.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en_ru.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_en_rz.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_rz.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en_rz.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_en_rz.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_en_rz.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en_rz.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_g0_7.f08 -O0 execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -O1 execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -O2 execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -g execution test
FAIL: gfortran.dg/fmt_g0_7.f08 -Os execution test
FAIL: gfortran.dg/fmt_pf.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -Os output pattern test
FAIL: gfortran.dg/large_real_kind_1.f90 -O0 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O1 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O2 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -g execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -Os execution test
2022-01-04 Jakub Jelinek <jakub@redhat.com>
* io/write_float.def (CALCULATE_EXP): If HAVE_GFC_REAL_17, also use
CALCULATE_EXP(17).
(determine_en_precision): Use 17 instead of 16 as first EN_PREC
argument for kind 17.
(get_float_string): Use 17 instead of 16 as first FORMAT_FLOAT
argument for kind 17.
Jakub Jelinek [Fri, 31 Dec 2021 15:59:38 +0000 (16:59 +0100)]
gfortran: Introduce gfc_type_abi_kind
The following patch detects the powerpc64le-linux kind == 16 cases
and for the -mabi=ieeelongdouble case (no matter whether it is the
configured in default or just option used on the command line) uses
_r17 or _c17 instead of _r16 or _c17 in the library API names.
From what I can see, e.g. calls to sin on real(kind = 16) works fine
with or without this patch (we call __builtin_sinl and the backend
uses rs6000_mangle_decl_assembler_name which ensures __sinieee128
is called).
What is clearly still broken is IO, where for
real(kind=16) a
a = 1.0
print *, a
end
we call
_gfortran_transfer_real_write (&dt_parm.0, &a, 16);
for both -mabi=ibmlongdouble and -mabi=ieeelongdouble
I don't remember what was the agreement, do we want
_gfortran_transfer_real_write (&dt_parm.0, &a, 17);
for the ieeelongdouble case, or some new entrypoint for
the abi_kind == 17 real/complex IO?
Also, what about kind stored in array descriptors? Shall we use
there the abi_kind or kind?
I guess at least before the IO case is solved there is no point
in checking the testsuite, too many things will be majorly broken...
Jakub Jelinek [Fri, 31 Dec 2021 15:58:32 +0000 (16:58 +0100)]
libgfortran: Small progress on the library side
The following patch quiets
../../../libgfortran/generated/in_pack_r17.c:35:1: warning: no previous prototype for ‘internal_pack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_pack_c17.c:35:1: warning: no previous prototype for ‘internal_pack_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_unpack_r17.c:33:1: warning: no previous prototype for ‘internal_unpack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_unpack_c17.c:33:1: warning: no previous prototype for ‘internal_unpack_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/pack_r17.c:73:1: warning: no previous prototype for ‘pack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/pack_c17.c:73:1: warning: no previous prototype for ‘pack_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_r17.c:34:1: warning: no previous prototype for ‘unpack0_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_r17.c:178:1: warning: no previous prototype for ‘unpack1_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_c17.c:34:1: warning: no previous prototype for ‘unpack0_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_c17.c:178:1: warning: no previous prototype for ‘unpack1_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_r17.c:34:1: warning: no previous prototype for ‘spread_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_r17.c:230:1: warning: no previous prototype for ‘spread_scalar_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_c17.c:34:1: warning: no previous prototype for ‘spread_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_c17.c:230:1: warning: no previous prototype for ‘spread_scalar_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift0_r17.c:33:1: warning: no previous prototype for ‘cshift0_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift0_c17.c:33:1: warning: no previous prototype for ‘cshift0_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_4_r17.c:32:1: warning: no previous prototype for ‘cshift1_4_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_4_c17.c:32:1: warning: no previous prototype for ‘cshift1_4_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_8_r17.c:32:1: warning: no previous prototype for ‘cshift1_8_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_8_c17.c:32:1: warning: no previous prototype for ‘cshift1_8_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_16_r17.c:32:1: warning: no previous prototype for ‘cshift1_16_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_16_c17.c:32:1: warning: no previous prototype for ‘cshift1_16_c17’ [-Wmissing-prototypes]
warnings during libgfortran build and exports the new entrypoints.
Note, not all of them, clearly e.g. there are fewer *_r17* entrypoints than
*_r16* entrypoints, so more work is needed.
Thomas Koenig [Mon, 6 Dec 2021 18:57:32 +0000 (19:57 +0100)]
Prepare library for REAL(KIND=17).
This prepares the library side for REAL(KIND=17). It is
not yet tested, but at least compiles cleanly on POWER 9
and x86_64.
2021-10-19 Thomas Koenig <tkoenig@gcc.gnu.org>
* Makefile.am: Add _r17 and _c17 files. Build them
with -mabi=ieeelongdouble on POWER.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: New flag HAVE_REAL_17.
* kinds-override.h: (HAVE_GFC_REAL_17): New macro.
(HAVE_GFC_COMPLEX_17): New macro.
(GFC_REAL_17_HUGE): New macro.
(GFC_REAL_17_LITERAL_SUFFIX): New macro.
(GFC_REAL_17_LITERAL): New macro.
(GFC_REAL_17_DIGITS): New macro.
(GFC_REAL_17_RADIX): New macro.
* libgfortran.h (POWER_IEEE128): New macro.
(gfc_array_r17): Typedef.
(GFC_DTYPE_REAL_17): New macro.
(GFC_DTYPE_COMPLEX_17): New macro.
(__acoshieee128): Prototype.
(__acosieee128): Prototype.
(__asinhieee128): Prototype.
(__asinieee128): Prototype.
(__atan2ieee128): Prototype.
(__atanhieee128): Prototype.
(__atanieee128): Prototype.
(__coshieee128): Prototype.
(__cosieee128): Prototype.
(__erfieee128): Prototype.
(__expieee128): Prototype.
(__fabsieee128): Prototype.
(__jnieee128): Prototype.
(__log10ieee128): Prototype.
(__logieee128): Prototype.
(__powieee128): Prototype.
(__sinhieee128): Prototype.
(__sinieee128): Prototype.
(__sqrtieee128): Prototype.
(__tanhieee128): Prototype.
(__tanieee128): Prototype.
(__ynieee128): Prototype.
* m4/mtype.m4: Make a bit more readable. Add KIND=17.
* generated/_abs_c17.F90: New file.
* generated/_abs_r17.F90: New file.
* generated/_acos_r17.F90: New file.
* generated/_acosh_r17.F90: New file.
* generated/_aimag_c17.F90: New file.
* generated/_aint_r17.F90: New file.
* generated/_anint_r17.F90: New file.
* generated/_asin_r17.F90: New file.
* generated/_asinh_r17.F90: New file.
* generated/_atan2_r17.F90: New file.
* generated/_atan_r17.F90: New file.
* generated/_atanh_r17.F90: New file.
* generated/_conjg_c17.F90: New file.
* generated/_cos_c17.F90: New file.
* generated/_cos_r17.F90: New file.
* generated/_cosh_r17.F90: New file.
* generated/_dim_r17.F90: New file.
* generated/_exp_c17.F90: New file.
* generated/_exp_r17.F90: New file.
* generated/_log10_r17.F90: New file.
* generated/_log_c17.F90: New file.
* generated/_log_r17.F90: New file.
* generated/_mod_r17.F90: New file.
* generated/_sign_r17.F90: New file.
* generated/_sin_c17.F90: New file.
* generated/_sin_r17.F90: New file.
* generated/_sinh_r17.F90: New file.
* generated/_sqrt_c17.F90: New file.
* generated/_sqrt_r17.F90: New file.
* generated/_tan_r17.F90: New file.
* generated/_tanh_r17.F90: New file.
* generated/bessel_r17.c: New file.
* generated/cshift0_c17.c: New file.
* generated/cshift0_r17.c: New file.
* generated/cshift1_16_c17.c: New file.
* generated/cshift1_16_r17.c: New file.
* generated/cshift1_4_c17.c: New file.
* generated/cshift1_4_r17.c: New file.
* generated/cshift1_8_c17.c: New file.
* generated/cshift1_8_r17.c: New file.
* generated/findloc0_c17.c: New file.
* generated/findloc0_r17.c: New file.
* generated/findloc1_c17.c: New file.
* generated/findloc1_r17.c: New file.
* generated/in_pack_c17.c: New file.
* generated/in_pack_r17.c: New file.
* generated/in_unpack_c17.c: New file.
* generated/in_unpack_r17.c: New file.
* generated/matmul_c17.c: New file.
* generated/matmul_r17.c: New file.
* generated/matmulavx128_c17.c: New file.
* generated/matmulavx128_r17.c: New file.
* generated/maxloc0_16_r17.c: New file.
* generated/maxloc0_4_r17.c: New file.
* generated/maxloc0_8_r17.c: New file.
* generated/maxloc1_16_r17.c: New file.
* generated/maxloc1_4_r17.c: New file.
* generated/maxloc1_8_r17.c: New file.
* generated/maxval_r17.c: New file.
* generated/minloc0_16_r17.c: New file.
* generated/minloc0_4_r17.c: New file.
* generated/minloc0_8_r17.c: New file.
* generated/minloc1_16_r17.c: New file.
* generated/minloc1_4_r17.c: New file.
* generated/minloc1_8_r17.c: New file.
* generated/minval_r17.c: New file.
* generated/norm2_r17.c: New file.
* generated/pack_c17.c: New file.
* generated/pack_r17.c: New file.
* generated/pow_c17_i16.c: New file.
* generated/pow_c17_i4.c: New file.
* generated/pow_c17_i8.c: New file.
* generated/pow_r17_i16.c: New file.
* generated/pow_r17_i4.c: New file.
* generated/pow_r17_i8.c: New file.
* generated/product_c17.c: New file.
* generated/product_r17.c: New file.
* generated/reshape_c17.c: New file.
* generated/reshape_r17.c: New file.
* generated/spread_c17.c: New file.
* generated/spread_r17.c: New file.
* generated/sum_c17.c: New file.
* generated/sum_r17.c: New file.
* generated/unpack_c17.c: New file.
* generated/unpack_r17.c: New file.
The new IRA heuristics would need more work on old-reload targets,
since flattening needs to be able to undo the cost propagation.
It's doable, but hardly seems worth it.
This patch therefore makes all the new calls to
ira_subloop_allocnos_can_differ_p return false if !ira_use_lra_p.
The color_pass code that predated the new function (and that was
the source of ira_subloop_allocnos_can_differ_p) continues to
behave as before.
It's a hack, but at least it has the advantage that the new parameter
would become obviously unused if reload and (!)ira_use_lra_p were
removed. The hack should therefore disappear alongside reload.
gcc/
PR rtl-optimization/103974
* ira-int.h (ira_subloop_allocnos_can_differ_p): Take an
extra argument, default true, that says whether old-reload
targets should be excluded.
* ira-color.c (color_pass): Pass false.
Uros Bizjak [Tue, 11 Jan 2022 18:23:15 +0000 (19:23 +0100)]
i386: Introduce V2QImode vector cmove for -msse4.1 [PR103861]
This patch also moves V2HI and V4QImode vector conditional moves
to SSE4.1 targets. Vector cmoves are implemented with SSE logic functions
without -msse4.1, and they are hardly worthwile for narrow vector modes.
More important, we would like to keep vector logic functions for GPR
registers, and the current RTX description of 32-bit vector modes logic
insns does not include the necessary CC reg clobber. Solve these issues by
restricting vector cmove insns for these modes to -msse4.1, where logic
instructions are avoided, and pblend insn is used instead.
A follow-up patch will add clobbers and necessary splits to 32-bit
vector mode logic insns, and in a future patch, ix86_sse_movcc will be
improved to use expand_simple_{unop,binop} to emit logic insns, allowing
us to re-enable 16-bit and 32-bit narrow vector cmoves for -msse2.
2022-01-11 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/103861
* config/i386/mmx.md (vcond<mode><mode>):
Use VI_16_32 mode iterator. Enable for TARGET_SSE4_1.
(vcondu<mode><mode>): Ditto.
(vcond_mask_<mode><mode>): Ditto.
(mmx_pblendvb_v8qi): Rename from mmx_pblendvb64.
(mmx_pblendvb_<mode>): Rename from mmx_pblendvb32.
Use VI_16_32 mode iterator.
* config/i386/i386-expand.c (ix86_expand_sse_movcc):
Update for rename. Handle V2QImode.
(expand_vec_perm_blend): Update for rename.
gcc/testsuite/ChangeLog:
PR target/103861
* g++.target/i386/pr100637-1b.C (dg-options):
Use -msse4 instead of -msse2.
* g++.target/i386/pr100637-1w.C (dg-options): Ditto.
* g++.target/i386/pr103861-1.C: New test.
* gcc.target/i386/pr100637-4b.c (dg-options):
Use -msse4 instead of -msse2.
* gcc.target/i386/pr103861-4.c: New test.
Jakub Jelinek [Tue, 11 Jan 2022 18:21:30 +0000 (19:21 +0100)]
c++: Fix ICEs with OBJ_TYPE_REF pretty printing [PR101597]
The following testcase ICEs, because middle-end uses the C++ FE pretty
printing code through langhooks in the diagnostics.
The FE expects OBJ_TYPE_REF_OBJECT's type to be useful (pointer to the
class type it is called on), but in the middle-end conversions between
pointer types are useless, so the actual type can be some random
unrelated pointer type (in the testcase void * pointer). The pretty
printing code then ICEs on it.
The following patch fixes that by sticking the original
OBJ_TYPE_REF_OBJECT's also as type of OBJ_TYPE_REF_TOKEN operand.
That one must be an INTEGER_CST, all the current uses of
OBJ_TYPE_REF_TOKEN just use tree_to_uhwi or tree_to_shwi on it,
and because it is constant, there is no risk of the middle-end propagating
into it some other pointer type. So, approach similar to how MEM_REF
treats its second operand or a couple of internal functions (e.g.
IFN_VA_ARG) some of its parameters.
2022-01-11 Jakub Jelinek <jakub@redhat.com>
PR c++/101597
gcc/
* tree.def (OBJ_TYPE_REF): Document type of OBJ_TYPE_REF_TOKEN.
gcc/cp/
* class.c (build_vfn_ref): Build OBJ_TYPE_REF with INTEGER_CST
OBJ_TYPE_REF_TOKEN with type equal to OBJ_TYPE_REF_OBJECT type.
* error.c (resolve_virtual_fun_from_obj_type_ref): Use type of
OBJ_TYPE_REF_TOKEN rather than type of OBJ_TYPE_REF_OBJECT as
obj_type.
gcc/objc/
* objc-act.c (objc_rewrite_function_call): Build OBJ_TYPE_REF
with INTEGER_CST OBJ_TYPE_REF_TOKEN with type equal to
OBJ_TYPE_REF_OBJECT type.
* objc-next-runtime-abi-01.c (build_objc_method_call): Likewise.
* objc-gnu-runtime-abi-01.c (build_objc_method_call): Likewise.
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call,
build_v2_build_objc_method_call): Likewise.
gcc/testsuite/
* g++.dg/opt/pr101597.C: New test.
Jakub Jelinek [Tue, 11 Jan 2022 18:11:51 +0000 (19:11 +0100)]
c-family: Fix up -W*conversion on bitwise &/|/^ [PR101537]
The following testcases emit a bogus -Wconversion warning. This is because
conversion_warning function doesn't handle BIT_*_EXPR (only unsafe_conversion_p
that is called during the default: case, and that one doesn't handle
SAVE_EXPRs added because the unsigned char & or | operands promoted to int
have side-effects and =| or =& is used.
The patch handles BIT_IOR_EXPR/BIT_XOR_EXPR like the last 2 operands of
COND_EXPR by recursing on the two operands, if either of them doesn't fit
into the narrower type, complain. BIT_AND_EXPR too, but first it needs to
handle some special cases that unsafe_conversion_p does, namely when one
of the two operands is a constant.
This fixes completely the pr101537.c test and for C also pr103881.c
and doesn't regress anything in the testsuite, for C++ pr103881.c still
emits the bogus warnings.
This is because while the C FE emits in that case a SAVE_EXPR that
conversion_warning can handle already, C++ FE emits
TARGET_EXPR <D.whatever, ...>, something | D.whatever
etc. and conversion_warning handles COMPOUND_EXPR by "recursing" on the
rhs. To handle that case, we'd need for TARGET_EXPR on the lhs remember
in some hash map the mapping from D.whatever to the TARGET_EXPR and when
we see D.whatever, use corresponding TARGET_EXPR initializer instead.
2022-01-11 Jakub Jelinek <jakub@redhat.com>
PR c/101537
PR c/103881
gcc/c-family/
* c-warn.c (conversion_warning): Handle BIT_AND_EXPR, BIT_IOR_EXPR
and BIT_XOR_EXPR.
gcc/testsuite/
* c-c++-common/pr101537.c: New test.
* c-c++-common/pr103881.c: New test.
Patrick Palka [Tue, 11 Jan 2022 18:00:48 +0000 (13:00 -0500)]
c++: dependent bases and 'this' availability [PR103831]
Here during satisfaction of B's constraints we're failing to reject the
object-less call to the non-static member function A::size ultimately
because satisfaction is performed in the (access) context of the class
template B, which has a dependent base, and so the any_dependent_bases_p
check within build_new_method_call causes us to not reject the call.
(Subsequent constexpr evaluation of the call succeeds since the function
is effectively static.)
This patch fixes this by refining the any_dependent_bases_p check within
build_new_method_call: if we're in a context where 'this' is unavailable,
then we cannot resolve the implicit object regardless of the presence of
a dependent base. So let's also check current_class_ptr alongside a_d_b_p.
PR c++/103831
gcc/cp/ChangeLog:
* call.c (build_new_method_call): Consider dependent bases only
if 'this' is available.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-class3.C: New test.
* g++.dg/template/non-dependent18.C: New test.
Jonathan Wakely [Tue, 11 Jan 2022 14:11:46 +0000 (14:11 +0000)]
libstdc++: Make copyable-box completely constexpr (LWG 3572)
This LWG issue was approved at the October 2021 plenary and can be
implemented now that std::optional is fully constexpr.
libstdc++-v3/ChangeLog:
* include/std/ranges (ranges::__detail::__box): Add constexpr to
assignment operators (LWG 3572).
* testsuite/std/ranges/adaptors/filter.cc: Check assignment of a
view that uses copyable-box.
Allow returning dynamic expressions from ADDR_EXPR for
__builtin_dynamic_object_size and also allow offsets to be dynamic.
gcc/ChangeLog:
PR middle-end/70090
* tree-object-size.c (size_valid_p): New function.
(size_for_offset): Remove OFFSET constness assertion.
(addr_object_size): Build dynamic expressions for object
sizes and use size_valid_p to decide if it is valid for the
given OBJECT_SIZE_TYPE.
(compute_builtin_object_size): Allow dynamic offsets when
computing size at O0.
(call_object_size): Call size_valid_p.
(plus_stmt_object_size): Allow non-constant offset and use
size_valid_p to decide if it is valid for the given
OBJECT_SIZE_TYPE.
Handle non-constant expressions in GIMPLE_CALL arguments. Also handle
alloca.
gcc/ChangeLog:
PR middle-end/70090
* tree-object-size.c (alloc_object_size): Make and return
non-constant size expression.
(call_object_size): Return expression or unknown based on
whether dynamic object size is requested.
gcc/testsuite/ChangeLog:
PR middle-end/70090
* gcc.dg/builtin-dynamic-object-size-0.c: Add new tests.
* gcc.dg/builtin-object-size-1.c (test1)
[__builtin_object_size]: Alter expected result for dynamic
object size.
* gcc.dg/builtin-object-size-2.c (test1)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-3.c (test1)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-4.c (test1)
[__builtin_object_size]: Likewise.
tree-object-size: Support dynamic sizes in conditions
Handle GIMPLE_PHI and conditionals specially for dynamic objects,
returning PHI/conditional expressions instead of just a MIN/MAX
estimate.
This makes the returned object size variable for loops and conditionals,
so tests need to be adjusted to look for precise size in some cases.
builtin-dynamic-object-size-5.c had to be modified to only look for
success in maximum object size case and skip over the minimum object
size tests because the result is no longer a compile time constant.
I also added some simple tests to exercise conditionals with dynamic
object sizes.
gcc/ChangeLog:
PR middle-end/70090
* builtins.c (fold_builtin_object_size): Adjust for dynamic size
expressions.
* tree-object-size.c: Include gimplify-me.h.
(struct object_size_info): New member UNKNOWNS.
(size_initval_p, size_usable_p, object_sizes_get_raw): New
functions.
(object_sizes_get): Return suitable gimple variable for
object size.
(bundle_sizes): New function.
(object_sizes_set): Use it and handle dynamic object size
expressions.
(object_sizes_set_temp): New function.
(size_for_offset): Adjust for dynamic size expressions.
(emit_phi_nodes, propagate_unknowns, gimplify_size_expressions):
New functions.
(compute_builtin_object_size): Call gimplify_size_expressions
for OST_DYNAMIC.
(dynamic_object_size): New function.
(cond_expr_object_size): Use it.
(phi_dynamic_object_size): New function.
(collect_object_sizes_for): Call it for OST_DYNAMIC. Adjust to
accommodate dynamic object sizes.
gcc/testsuite/ChangeLog:
PR middle-end/70090
* gcc.dg/builtin-dynamic-object-size-0.c: New tests.
* gcc.dg/builtin-dynamic-object-size-10.c: Add comment.
* gcc.dg/builtin-dynamic-object-size-5-main.c: New file.
* gcc.dg/builtin-dynamic-object-size-5.c: Use it and change test
to dg-do run.
* gcc.dg/builtin-object-size-5.c [!N]: Define N.
(test1, test2, test3, test4) [__builtin_object_size]: Expect
exact result for __builtin_dynamic_object_size.
* gcc.dg/builtin-object-size-1.c [__builtin_object_size]: Expect
exact size expressions for __builtin_dynamic_object_size.
* gcc.dg/builtin-object-size-2.c [__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-3.c [__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-4.c [__builtin_object_size]:
Likewise.
tree-optimization/103961: Never compute offset for -1 size
Never try to compute size for offset when the object size is -1, which
is either unknown maximum or uninitialized minimum irrespective of the
osi->pass number.
David Malcolm [Fri, 7 Jan 2022 22:44:23 +0000 (17:44 -0500)]
analyzer: fix false +ve on bitwise binops (PR analyzer/102692)
PR analyzer/102692 reports a false positive at -O2 from
-Wanalyzer-null-dereference on:
if (!p || q || !p->next)
At the gimple level, -O2 has converted the first || into bitwise or
controlling a jump:
_4 = _2 | _3;
if (_4 != 0)
and a recursive call has been converted to iteration. The analyzer hits
the symbolic value complexity limit whilst analyzing the iteration and
hits a case where _2 is (_Bool)1 (i.e. true) and _3 (i.e. q) is
UNKNOWN(_Bool).
There are two issues leading to the false positive; fixing either issue
fixes the false positive; this patch fixes both for good measure:
(a) The analyzer erronously treats bitwise ops on UNKNOWN(_Bool) as UNKNOWN,
even for case like (1 | UNKNOWN) where we know the result, leading to
bogus edges in the exploded graph. The patch fixes these cases.
(b) The state-handling code creates "UNKNOWN" symbolic values, as a way
to give up when symbolic expressions get too complicated, and in various
other cases. This makes sense when building the exploded graph, since
we want the analysis to terminate, but doesn't make sense when checking
the feasibility along a specific path, where we want precision. The patch
prevents all use of "unknown" symbolic values when performing feasibility
checking of a path (before it merely stopped doing complexity-checking),
by creating a unique placeholder_svalue instead.
This fixes the -Wanalyzer-null-dereference false positive.
Unfortunately, with GCC 12 there's also a false positive from
-Wanalyzer-use-of-uninitialized-value on this code, which is a separate
issue that the patch does not fix.
gcc/analyzer/ChangeLog:
PR analyzer/102692
* diagnostic-manager.cc
(class auto_disable_complexity_checks): Rename to...
(class auto_checking_feasibility): ...this, updating
the calls accordingly.
(epath_finder::explore_feasible_paths): Update for renaming.
* region-model-manager.cc
(region_model_manager::region_model_manager): Update for change from
m_check_complexity to m_checking_feasibility.
(region_model_manager::reject_if_too_complex): Likewise.
(region_model_manager::get_or_create_unknown_svalue): Handle
m_checking_feasibility.
(region_model_manager::create_unique_svalue): New.
(region_model_manager::maybe_fold_binop): Handle BIT_AND_EXPR and
BIT_IOR_EXPRs on booleans where we know the result.
* region-model.cc (test_binop_svalue_folding): Add test coverage
for the above.
* region-model.h (region_model_manager::create_unique_svalue): New
decl.
(region_model_manager::enable_complexity_check): Replace with...
(region_model_manager::begin_checking_feasibility): ...this.
(region_model_manager::disable_complexity_check): Replace with...
(region_model_manager::end_checking_feasibility): ...this.
(region_model_manager::m_check_complexity): Replace with...
(region_model_manager::m_checking_feasibility): ...this.
(region_model_manager::m_managed_dynamic_svalues): New field.
gcc/testsuite/ChangeLog:
PR analyzer/102692
* gcc.dg/analyzer/pr102692.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jonathan Wakely [Mon, 10 Jan 2022 20:48:53 +0000 (20:48 +0000)]
libstdc++: Install <coroutine> header for freestanding [PR103726]
The standard says that <coroutine> should be present for freestanding.
That was intentionally left out of the initial implementation, but can
be done without much trouble. The header should be moved to libsupc++ at
some point in stage 1.
The standard also says that <coroutine> defines a std::hash
specialization, which was missing from our implementation. That's a
problem for freestanding (see LWG 3653) so only do that for hosted.
We can use concepts to constrain the __coroutine_traits_impl base class
when compiled with concepts enabled. In a pure C++20 implementation we
would not need that base class at all and could just use a constrained
partial specialization of coroutine_traits. But the absence of the
__coroutine_traits_impl<R, void> base would create an ABI difference
between the non-standard C++14/C++17 support for coroutines and the same
code compiled as C++20. If we drop support for <coroutine> pre-C++20 we
should revisit this.
libstdc++-v3/ChangeLog:
PR libstdc++/103726
* include/Makefile.am: Install <coroutine> for freestanding.
* include/Makefile.in: Regenerate.
* include/std/coroutine: Adjust headers and preprocessor
conditions.
(__coroutine_traits_impl): Use concepts when available.
[_GLIBCXX_HOSTED] (hash<coroutine_handle>): Define.
Jonathan Wakely [Mon, 10 Jan 2022 17:38:33 +0000 (17:38 +0000)]
libstdc++: Optimize std::ostream inserters for single characters
On the libsdc++ mailing list Lewis Hyatt pointed out the performance
overhead of using sputn in stream inserters, rather than writing
directly to the streambuf's put area:
https://gcc.gnu.org/pipermail/libstdc++/2021-July/052877.html
As Lewis noted, the standard explicitly requires a call to sputn for
inserting a std::basic_string_view or std::basic_string. But for
inserting single characters or null-terminated strings it is more vague,
and so we can improve performance by not using the __ostream_insert
function.
This is a minimal change that avoids __ostream_insert for single
characters. We can use the unformatted basic_ostream::put(charT)
function when we don't need the additional effects of a formatted output
function (i.e. padding and resetting the width). The put function will
insert into the buffer if possible, and only make a virtual call (to
overflow) if the buffer is full.
We could also avoid sputn when inserting null-terminated character
strings, but that would require using a new function for inserting
null-terminated strings, so the existing code using sputn is still used
for basic_string and basic_string_view. My preference is to leave that
for now, and try to improve the standard. We could either remove the
requirement to call sputn, or allow sputn to write directly to the
buffer instead of calling xsputn.
libstdc++-v3/ChangeLog:
* include/std/ostream (operator<<(basic_ostream&, charT)):
Use unformatted input if no padding is needed.
(operator<<(basic_ostream<char>&, char)): Likewise.
Yannick Moy [Wed, 5 Jan 2022 14:36:13 +0000 (14:36 +0000)]
[Ada] Adapt proof of System.Arith_Double
gcc/ada/
* libgnat/s-aridou.adb (Double_Divide): Adjust proof of lemma
Prove_Signs, call lemma for commutation of Big and
multiplication.
(Multiply_With_Ovflo_Check): Adjust postcondition of
Prove_Pos_Int.
(Scaled_Divide): Explicit commutation in the proof of lemma
Prove_Multiplication, add new lemma Prove_Shift_Progress for
congruence property that is not proved in a larger context, add
assertions at the end of the loop to state loop invariant
properties.
Eric Botcazou [Tue, 4 Jan 2022 12:39:45 +0000 (13:39 +0100)]
[Ada] Fix incomplete debug info for derived packed array type
gcc/ada/
* sem_ch3.adb (Analyze_Subtype_Declaration): In the case of an array
copy Packed_Array_Impl_Type manually here.
(Copy_Array_Subtype_Attributes): Do not copy it here.
Claire Dross [Wed, 15 Dec 2021 19:10:06 +0000 (20:10 +0100)]
[Ada] Proof of System.Val_Uns at gold level
gcc/ada/
* libgnat/a-tiinau.ads: Use a procedure for the Scan parameter
instead of a function with side-effects.
* libgnat/a-tiinau.adb: Idem.
* libgnat/a-wtinau.ads: Idem.
* libgnat/a-wtinau.adb: Idem.
* libgnat/a-ztinau.ads: Idem.
* libgnat/a-ztinau.adb: Idem.
* libgnat/s-valint.ads: Change the function with side-effects
Scan_Integer into a procedure
* libgnat/s-vallli.ads: Idem.
* libgnat/s-valllli.ads: Idem.
* libgnat/s-vallllu.ads: Add SPARK_Mode and pragma to ignore
assertions in instance.
* libgnat/s-valllu.ads: Idem.
* libgnat/s-valuns.ads: Idem.
* libgnat/s-valuei.ads: Use a procedure for the
Scan_Raw_Unsigned parameter instead of a function with
side-effects and change the function with side-effects
Scan_Integer into a procedure.
* libgnat/s-valuei.adb: Idem.
* libgnat/s-valuti.ads: Introduce a ghost function that scans an
exponent and complete the postcondition of Scan_Exponent to also
describe the value of Ptr after the call. Fix the postcondition
of Scan_Underscore. Simplify the definition of
Scan_Natural_Ghost.
* libgnat/s-valuti.adb: Idem.
* libgnat/s-valboo.ads, libgnat/s-valboo.adb: Update calls to
First_Non_Space_Ghost.
* libgnat/s-valueu.ads: Add functional contracts.
* libgnat/s-valueu.adb: Idem.
Gary Dismukes [Fri, 17 Dec 2021 23:41:01 +0000 (18:41 -0500)]
[Ada] Conformance error on protected subp with anonymous-access-to-tagged formal
gcc/ada/
* sem_disp.adb (Check_Controlling_Type): Add test for the case
where Subp is a subprogram associated with a protected
subprogram and return Empty, unless Tagged_Type is the
corresponding record type of the protected type.
Piotr Trojanek [Thu, 9 Dec 2021 16:57:16 +0000 (17:57 +0100)]
[Ada] Remove warnings-as-errors about constraints error in dead code
gcc/ada/
* erroutc.ads, erroutc.adb (Is_Runtime_Raise): Global flag to
connect status of initial messages and their continuation; we
already have several flags like this.
(Error_Msg_Object): Add field Warn_Runtime_Raise to connect
error reporting (when problematic code is found) and removal
(when problematic code is determined to be dead).
* errout.adb (Error_Msg_Internal): Handle new field when
recording a continuation message; propagate status from
continuation to the preceding messages.
(To_Be_Removed): For dead code remove both simple warnings and
warnings about constraint errors that have been escalated to
hard errors.
(Set_Msg_Text): Recognize warnings about constraint errors that
are escalated to hard errors.
* errutil.adb (Error_Msg): Handle added field when recording a
new message.
Jonathan Wakely [Mon, 10 Jan 2022 17:28:19 +0000 (17:28 +0000)]
libstdc++: Make std::variant work with Clang in C++20 mode [PR103891]
Clang has some bugs with destructors that use constraints to be
conditionally trivial, so disable the P2231R1 constexpr changes to
std::variant unless the compiler is GCC 12 or later.
If/when P2493R0 gets accepted and implemented by G++ we can remove the
__GNUC__ check and use __cpp_concepts >= 202002 instead.
libstdc++-v3/ChangeLog:
PR libstdc++/103891
* include/bits/c++config (_GLIBCXX_HAVE_COND_TRIVIAL_SPECIAL_MEMBERS):
Define.
* include/std/variant (__cpp_lib_variant): Only define C++20
value when the compiler is known to support conditionally
trivial destructors.
* include/std/version (__cpp_lib_variant): Likewise.
Jonathan Wakely [Mon, 10 Jan 2022 16:51:49 +0000 (16:51 +0000)]
libstdc++: Make std::common_iterator completely constexpr-able (LWG 3574)
This library issue was approved in the October 2021 plenary.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (common_iterator): Add constexpr
to all member functions (LWG 3574).
* testsuite/24_iterators/common_iterator/1.cc: Evaluate some
tests as constant expressions.
* testsuite/24_iterators/common_iterator/2.cc: Likewise.
Roger Sayle [Tue, 11 Jan 2022 12:30:44 +0000 (12:30 +0000)]
Recognize MULT_HIGHPART_EXPR in tree-ssa-math-opts pass.
This is the third iteration of a patch to perceive MULT_HIGHPART_EXPR
in the middle-end. As they say "the third time's a charm". The first
version implemented this in match.pd, which was considered too early.
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551316.html
The second version attempted to do this during RTL expansion, and was
considered to be too late in the middle-end.
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576922.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576923.html
This latest version incorporates Richard Biener's feedback/suggestion
to perceive MULT_HIGHPART_EXPR in one of the "instruction selection
passes", specifically tree-ssa-math-opts, where the recognition of
highpart multiplications takes place in the same pass as widening
multiplications.
With each rewrite, the patch is also getting more aggressive in the
set of widening multiplications that it recognizes as highpart multiplies.
Currently any widening multiplication followed by a right shift (either
signed or unsigned) by a bit count sufficient to eliminate the lowpart
is recognized. The result of this shift doesn't need to be truncated.
As previously, this patch confirms the target provides a suitable
optab before introducing the MULT_HIGHPART_EXPR. This is the reason
the testcase is restricted to x86_64, as this pass doesn't do anything
on some platforms, but x86_64 should be sufficient to confirm that the
pass is working/continues to work.
2022-01-11 Roger Sayle <roger@nextmovesoftware.com>
Richard Biener <rguenther@suse.de>
gcc/ChangeLog
* tree-ssa-math-opts.c (struct widen_mul_stats): Add a
highpart_mults_inserted field.
(convert_mult_to_highpart): New function to convert right shift
of a widening multiply into a MULT_HIGHPART_EXPR.
(math_opts_dom_walker::after_dom_children) [RSHIFT_EXPR]:
Call new convert_mult_to_highpart function.
(pass_optimize_widening_mul::execute): Add a statistics counter
for tracking "highpart multiplications inserted" events.
gcc/testsuite/ChangeLog
* gcc.target/i386/mult-highpart.c: New test case.
then split2 will split it to one rotate dot instruction (to save one
rotate back instruction) as shifted result doesn't matter when comparing
to 0 in CCEQmode.
Bootstrapped and regression tested pass on Power 8/9/10.
gcc/ChangeLog:
PR target/102239
* config/rs6000/rs6000-protos.h (rs6000_is_valid_rotate_dot_mask): New
declare.
* config/rs6000/rs6000.c (rs6000_is_valid_rotate_dot_mask): New
function.
* config/rs6000/rs6000.md (*branch_anddi3_dot): New.
gcc/testsuite/ChangeLog:
PR target/102239
* gcc.target/powerpc/pr102239.c: New test.
Olivier Hainque [Wed, 5 Jan 2022 09:07:33 +0000 (09:07 +0000)]
State --sysroot option as validated once processed
Since we now save the option in the "switches" table
to let specs use it more generally, we need to explicitly
state that the option was validated else the driver
will consider it "unrecognized".
2022-01-05 Olivier Hainque <hainque@adacore.com>
* gcc.c (driver_handle_option): State --sysroot as
validated.
Xionghu Luo [Tue, 11 Jan 2022 02:05:56 +0000 (20:05 -0600)]
testsuite: Fix regression on m32 by r12-6087 [PR103820]
r12-6087 will avoid move cold bb out of hot loop, while the original
intent of this testcase is to hoist divides out of loop and CSE them to
only one divide. So increase the loop count to turn the cold bb to hot
bb again. Then the 3 divides could be rewritten with same reciptmp.
Tested pass on Power-Linux {32,64}, x86 {64,32} and i686-linux.
Kewen Lin [Tue, 11 Jan 2022 02:39:33 +0000 (20:39 -0600)]
rs6000: Remove useless code related to -mno-power10
Option -mpower10 was made as "WarnRemoved" since commit r11-2318,
so -mno-power10 doesn't take effect any more. This patch is to
remove one line code which respects it.
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_disable_incompatible_switches): Remove
useless related to option -mno-power10.
Patrick Palka [Mon, 10 Jan 2022 19:57:54 +0000 (14:57 -0500)]
c++: constexpr base-to-derived conversion with offset 0 [PR103879]
r12-136 made us canonicalize an object/offset pair with negative offset
into one with a nonnegative offset, by iteratively absorbing the
innermost component into the offset and stopping as soon as the offset
becomes nonnegative.
This patch strengthens this transformation by making it keep on absorbing
even if the offset is already 0 as long as the innermost component is at
position 0 (and thus absorbing doesn't change the offset). This lets us
accept the two constexpr testcases below, which we'd previously reject
essentially because cxx_fold_indirect_ref would be unable to resolve
*(B*)&b.D123 (where D123 is the base A subobject at position 0) to just b.
PR c++/103879
gcc/cp/ChangeLog:
* constexpr.c (cxx_fold_indirect_ref): Split out object/offset
canonicalization step into a local lambda. Strengthen it to
absorb more components at position 0. Use it before both calls
to cxx_fold_indirect_ref_1.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-base2.C: New test.
* g++.dg/cpp1y/constexpr-base2a.C: New test.
Patrick Palka [Mon, 10 Jan 2022 19:57:51 +0000 (14:57 -0500)]
c++: "more constrained" vs staticness of memfn [PR103783]
Here we're rejecting the calls to g1 and g2 as ambiguous even though one
overload is more constrained than the other (and they're otherwise tied),
because the implicit 'this' parameter of the non-static overload causes
cand_parms_match to think the function parameter lists aren't equivalent.
This patch fixes this by making cand_parms_match skip over 'this'
appropriately. Note that this bug only affects partial ordering of
non-template member functions because for member function templates
more_specialized_fn seems to already skip over 'this' appropriately.
PR c++/103783
gcc/cp/ChangeLog:
* call.c (cand_parms_match): Skip over 'this' when given one
static and one non-static member function.
Jakub Jelinek [Mon, 10 Jan 2022 19:49:11 +0000 (20:49 +0100)]
c++: Ensure some more that immediate functions aren't gimplified [PR103912]
Immediate functions should never be emitted into assembly, the FE doesn't
genericize them and does various things to ensure they aren't gimplified.
But the following testcase ICEs anyway due to that, because the consteval
function returns a lambda, and operator() of the lambda has
decl_function_context of the consteval function. cgraphunit.c then
does:
/* Preserve a functions function context node. It will
later be needed to output debug info. */
if (tree fn = decl_function_context (decl))
{
cgraph_node *origin_node = cgraph_node::get_create (fn);
enqueue_node (origin_node);
}
which enqueues the immediate function and then tries to gimplify it,
which results in ICE because it hasn't been genericized.
When I try similar testcase with constexpr instead of consteval and
static constinit auto instead of auto in main, what happens is that
the functions are gimplified, later ipa.c discovers they aren't reachable
and sets body_removed to true for them (and clears other flags) and we end
up with a debug info which has the foo and bar functions without
DW_AT_low_pc and other code specific attributes, just stuff from its BLOCK
structure and in there the lambda with DW_AT_low_pc etc.
The following patch attempts to emulate that behavior early, so that cgraph
doesn't try to gimplify those and pretends they were already gimplified
and found unused and optimized away.
2022-01-10 Jakub Jelinek <jakub@redhat.com>
PR c++/103912
* semantics.c (expand_or_defer_fn): For immediate functions, set
node->body_removed to true and clear analyzed, definition and
force_output.
* decl2.c (c_parse_final_cleanups): Ignore immediate functions for
expand_or_defer_fn.
Uros Bizjak [Mon, 10 Jan 2022 19:39:35 +0000 (20:39 +0100)]
tree-optimization/103948 - detect vector vec_cmp in expand_vector_condition
Currently, expand_vector_condition detects only vcondMN and vconduMN
named RTX patterns. Teach it to also consider vec_cmpMN and vec_cmpuMN
RTX patterns when all ones vector is returned for true and all zeros vector
is returned for false.
2022-01-10 Richard Biener <rguenther@suse.de>
gcc/ChangeLog:
PR tree-optimization/103948
* tree-vect-generic.c (expand_vector_condition): Return true if
all ones vector is returned for true, all zeros vector for false
and the target defines corresponding vec_cmp{,u}MN named RTX pattern.
Paul A. Clarke [Thu, 21 Oct 2021 01:34:06 +0000 (20:34 -0500)]
rs6000: Add Power10 optimization for _mm_blendv*
Power10 ISA added `xxblendv*` instructions which are realized in the
`vec_blendv` instrinsic.
Use `vec_blendv` for `_mm_blendv_epi8`, `_mm_blendv_ps`, and
`_mm_blendv_pd` compatibility intrinsics, when `_ARCH_PWR10`.
Update original implementation of _mm_blendv_epi8 to use signed types,
to better match the function parameters. Realization is unchanged.
Also, copy a test from i386 for testing `_mm_blendv_ps`.
This should have come with commit ed04cf6d73e233c74c4e55c27f1cbd89ae4710e8,
but was inadvertently omitted.
2022-01-10 Paul A. Clarke <pc@us.ibm.com>
gcc
* config/rs6000/smmintrin.h (_mm_blendv_epi8): Use vec_blendv
when _ARCH_PWR10. Use signed types.
(_mm_blendv_ps): Use vec_blendv when _ARCH_PWR10.
(_mm_blendv_pd): Likewise.
gcc/testsuite
* gcc.target/powerpc/sse4_1-blendvps.c: Copy from gcc.target/i386,
adjust dg directives to suit.
Andre Vieira [Thu, 2 Dec 2021 14:34:15 +0000 (14:34 +0000)]
[vect] Re-analyze all modes for epilogues
gcc/ChangeLog:
* tree-vectorizer.c (better_epilogue_loop_than_p): Round factors up for
epilogue costing.
* tree-vect-loop.c (vect_analyze_loop): Re-analyze all modes for
epilogues, unless we are guaranteed that we can't have partial vectors.
* genopinit.c: (partial_vectors_supported): Generate new function.
Jakub Jelinek [Mon, 10 Jan 2022 16:43:23 +0000 (17:43 +0100)]
x86_64: Ignore zero width bitfields in ABI and issue -Wpsabi warning about C zero width bitfield ABI changes [PR102024]
For zero-width bitfields current GCC classify_argument does:
if (DECL_BIT_FIELD (field))
{
for (i = (int_bit_position (field)
+ (bit_offset % 64)) / 8 / 8;
i < ((int_bit_position (field) + (bit_offset % 64))
+ tree_to_shwi (DECL_SIZE (field))
+ 63) / 8 / 8; i++)
classes[i]
= merge_classes (X86_64_INTEGER_CLASS, classes[i]);
}
which I think means that if the zero-width bitfields are at bit-positions
(in the toplevel aggregate) which are multiples of 64 bits doesn't do
anything, (int_bit_position (field) + (bit_offset % 64)) / 64 and
(int_bit_position (field) + (bit_offset % 64) + 63) / 64 should be equal.
But for zero-width bitfields at other bit positions it will call
merge_classes once. Now, the typical case is that the zero width bitfield
is surrounded by some bitfields and in that case, it doesn't change
anything, but it can be sandwitched in between floats too as the testcases
show.
In C we had this behavior, in C++ previously the FE was removing the
zero-width bitfields and therefore they were ignored.
LLVM and ICC seems to ignore those bitfields both in C and C++ (== passing
struct S in SSE register rather than in GPR).
The x86-64 psABI has been recently clarified by
https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/1aa4398d26c250b252a0c4a0f777216c9a6789ec
that zero width bitfield should be always ignored.
This patch implements that and emits a warning for C for cases where the ABI
changed from GCC 11.
2022-01-10 Jakub Jelinek <jakub@redhat.com>
PR target/102024
* config/i386/i386.c (classify_argument): Add zero_width_bitfields
argument, when seeing DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD bitfields,
always ignore them, when seeing other zero sized bitfields, either
set zero_width_bitfields to 1 and ignore it or if equal to 2 process
it. Pass it to recursive calls. Add wrapper
with old arguments and diagnose ABI differences for C structures
with zero width bitfields. Formatting fixes.
* gcc.target/i386/pr102024.c: New test.
* g++.target/i386/pr102024.C: New test.
ira: Handle "soft" conflicts between cap and non-cap allocnos
This patch looks for allocno conflicts of the following form:
- One allocno (X) is a cap allocno for some non-cap allocno X2.
- X2 belongs to some loop L2.
- The other allocno (Y) is a non-cap allocno.
- Y is an ancestor of some allocno Y2 in L2.
- Y2 is not referenced in L2 (that is, ALLOCNO_NREFS (Y2) == 0).
- Y can use a different allocation from Y2.
In this case, Y's register is live across L2 but is not used within it,
whereas X's register is used only within L2. The conflict is therefore
only "soft", in that it can easily be avoided by spilling Y2 inside L2
without affecting any insn references.
In principle we could do this for ALLOCNO_NREFS (Y2) != 0 too, with the
callers then taking Y2's ALLOCNO_MEMORY_COST into account. There would
then be no "cliff edge" between a Y2 that has no references and a Y2 that
has (say) a single cold reference.
However, doing that isn't necessary for the PR and seems to give
variable results in practice. (fotonik3d_r improves slightly but
namd_r regresses slightly.) It therefore seemed better to start
with the higher-value zero-reference case and see how things go.
On top of the previous patches in the series, this fixes the exchange2
regression seen in GCC 11.
gcc/
PR rtl-optimization/98782
* ira-int.h (ira_soft_conflict): Declare.
* ira-color.c (max_soft_conflict_loop_depth): New constant.
(ira_soft_conflict): New function.
(spill_soft_conflicts): Likewise.
(assign_hard_reg): Use them to handle the case described by
the comment above ira_soft_conflict.
(improve_allocation): Likewise.
* ira.c (check_allocation): Allow allocnos with "soft" conflicts
to share the same register.
gcc/testsuite/
* gcc.target/aarch64/reg-alloc-4.c: New test.
ira: Consider modelling caller-save allocations as loop spills
If an allocno A in an inner loop L spans a call, a parent allocno AP
can choose to handle a call-clobbered/caller-saved hard register R
in one of two ways:
(1) save R before each call in L and restore R after each call
(2) spill R to memory throughout L
(2) can be cheaper than (1) in some cases, particularly if L does
not reference A.
Before the patch we always did (1). The patch adds support for
picking (2) instead, when it seems cheaper. It builds on the
earlier support for not propagating conflicts to parent allocnos.
gcc/
PR rtl-optimization/98782
* ira-int.h (ira_caller_save_cost): New function.
(ira_caller_save_loop_spill_p): Likewise.
* ira-build.c (ira_propagate_hard_reg_costs): Test whether it is
cheaper to spill a call-clobbered register throughout a loop rather
than spill it around each individual call. If so, treat all
call-clobbered registers as conflicts and...
(propagate_allocno_info): ...do not propagate call information
from the child to the parent.
* ira-color.c (move_spill_restore): Update accordingly.
* ira-costs.c (ira_tune_allocno_costs): Use ira_caller_save_cost.
gcc/testsuite/
* gcc.target/aarch64/reg-alloc-3.c: New test.
- an inner loop L contains an allocno A
- L clobbers hard register R while A is live
- A's parent allocno is AP
Previously, propagate_allocno_info would propagate conflict sets up the
loop tree, so that the conflict between A and R would become a conflict
between AP and R (and so on for ancestors of AP).
However, when IRA treats loops as separate allocation regions, it can
decide on a loop-by-loop basis whether to allocate a register or spill
to memory. Conflicts in inner loops therefore don't need to become
hard conflicts in parent loops. Instead we can record that using the
“conflicting” registers for the parent allocnos has a higher cost.
In the example above, this higher cost is the sum of:
- the cost of saving R on entry to L
- the cost of keeping the pseudo register in memory throughout L
- the cost of reloading R on exit from L
This value is also a cap on the hard register cost that A can contribute
to AP in general (not just for conflicts). Whatever allocation we pick
for AP, there is always the option of spilling that register to memory
throughout L, so the cost to A of allocating a register to AP can't be
more than the cost of spilling A.
To take an extreme example: if allocating a register R2 to A is more
expensive than spilling A to memory, ALLOCNO_HARD_REG_COSTS (A)[R2]
could be (say) 2 times greater than ALLOCNO_MEMORY_COST (A) or 100
times greater than ALLOCNO_MEMORY_COST (A). But this scale factor
doesn't matter to AP. All that matters is that R2 is more expensive
than memory for A, so that allocating R2 to AP should be costed as
spilling A to memory (again assuming that A and AP are in different
allocation regions). Propagating a factor of 100 would distort the
register costs for AP.
move_spill_restore tries to undo the propagation done by
propagate_allocno_info, so we need some extra processing there.
gcc/
PR rtl-optimization/98782
* ira-int.h (ira_allocno::might_conflict_with_parent_p): New field.
(ALLOCNO_MIGHT_CONFLICT_WITH_PARENT_P): New macro.
(ira_single_region_allocno_p): New function.
(ira_total_conflict_hard_regs): Likewise.
* ira-build.c (ira_create_allocno): Initialize
ALLOCNO_MIGHT_CONFLICT_WITH_PARENT_P.
(ira_propagate_hard_reg_costs): New function.
(propagate_allocno_info): Use it. Try to avoid propagating
hard register conflicts to parent allocnos if we can handle
the conflicts by spilling instead. Limit the propagated
register costs to the cost of spilling throughout the child loop.
* ira-color.c (color_pass): Use ira_single_region_allocno_p to
test whether a child and parent allocno can share the same
register.
(move_spill_restore): Adjust for the new behavior of
propagate_allocno_info.
gcc/testsuite/
* gcc.target/aarch64/reg-alloc-2.c: New test.
color_pass has two instances of the same code for propagating non-cap
assignments from parent loops to subloops. This patch adds a helper
function for testing when such propagations are required for correctness
and uses it to remove the duplicated code.
A later patch will use this in ira-build.c too, which is why the
function is exported to ira-int.h.
ira: Add comments and fix move_spill_restore calculation
This patch adds comments to describe each use of ira_loop_border_costs.
I think this highlights that move_spill_restore was using the wrong cost
in one case, which came from tranposing [0] and [1] in the original
(pre-ira_loop_border_costs) ira_memory_move_cost expressions. The
difference would only be noticeable on targets that distinguish between
load and store costs.
gcc/
PR rtl-optimization/98782
* ira-color.c (color_pass): Add comments to describe the spill costs.
(move_spill_restore): Likewise. Fix reversed calculation.
is the cost of loading a register on entry to a loop and
storing it back on exit from the loop. This is the cost to
use if the register is successfully allocated within the
loop but is spilled in the parent loop. Similarly:
is the cost of storing a register on entry to the loop and
restoring it on exit from the loop. This is the cost to
use if the register is spilled within the loop but is
successfully allocated in the parent loop.
The patch adds a helper class for calculating these values and
mechanically replaces the existing instances. There is no attempt to
editorialise the choice between using “spill inside” and “spill outside”
costs. (I think one of them is the wrong way round, but a later patch
deals with that.)
No functional change intended.
gcc/
PR rtl-optimization/98782
* ira-int.h (ira_loop_border_costs): New class.
* ira-color.c (ira_loop_border_costs::ira_loop_border_costs):
New constructor.
(calculate_allocno_spill_cost): Use ira_loop_border_costs.
(color_pass): Likewise.
(move_spill_restore): Likewise.
glibc strptime passes around some state, what fields in struct tm have been
set and what needs to be finalized through possibly recursive calls, and
at the end performs various finalizations, like applying %p so that it
works for both %I %p and %p %I orders, or applying century so that both
%C %y and %y %C works, or computation of missing fields from others
(e.g. from %Y and %j one can compute tm_mon, tm_mday and tm_wday,
from %Y %U %w, %Y %W %w, %Y %U %a, or %Y %W %w one can compute
tm_mon, tm_mday, tm_yday or e.g. from %Y %m %d one can compute tm_wday
and tm_yday.
As the finalization is quite large and doesn't need to be a template
(doesn't depend on any iterators or char types), I've put it into libstdc++,
and left some padding in the state struct, so that perhaps in the future we
can track some more state without changing ABI.
Unfortunately, there is an ugly problem that the standard mandates that
get method calls the do_get virtual method and I don't see how we can
cary on any state in between those calls (even if we did an ABI change
for the facets, the methods are const, so that I think multiple threads
could use the same time_get objects and we couldn't store state in there).
There is a hack for that for GCC (seems to work with ICC too, doesn't work
with clang++) if the do_get method isn't overriden we can pass the state
around.
For both do_get_year and per IRC discussions also for %y, the behavior is
if 1-2 digits are parsed, the year is treated according to POSIX 2008 %y
rules (0-68 is 2000-2068, 69-99 is 1969-1999), if 3-4 digits are parsed,
it is treated as %Y.
2022-01-10 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/77760
* include/bits/locale_facets_nonio.h (__time_get_state): New struct.
(time_get::_M_extract_via_format): Declare new method with
__time_get_state& as an extra argument.
* include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Add
__state argument, set various fields in it while parsing. Handle %j,
%U, %w and %W, fix up handling of %y, %Y and %C, don't adjust tm_hour
for %p immediately. Add a wrapper around the method without the
__state argument for backwards compatibility.
(_M_extract_num): Remove all __len == 4 special cases.
(time_get::do_get_time, time_get::do_get_date, time_get::do_get): Zero
initialize __state, pass it to _M_extract_via_format and finalize it
at the end.
(do_get_year): For 1-2 digit parsed years, map 0-68 to 2000-2068,
69-99 to 1969-1999. For 3-4 digit parsed years use that as year.
(get): If do_get isn't overloaded from the locale_facets_nonio.tcc
version, don't call do_get but call _M_extract_via_format instead to
pass around state.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_extract_via_format
with extra __time_get_state and __time_get_state::_M_finalize_state.
* src/c++98/locale_facets.cc (is_leap, day_of_the_week,
day_of_the_year): New functions in anon namespace.
(mon_yday): New var in anon namespace.
(__time_get_state::_M_finalize_state): Define.
* testsuite/22_locale/time_get/get/char/4.cc: New test.
* testsuite/22_locale/time_get/get/wchar_t/4.cc: New test.
* testsuite/22_locale/time_get/get_year/char/1.cc (test01): Parse 197
as year 197AD instead of error.
* testsuite/22_locale/time_get/get_year/char/5.cc (test01): Parse 1 as
year 2001 instead of error.
* testsuite/22_locale/time_get/get_year/char/6.cc: New test.
* testsuite/22_locale/time_get/get_year/wchar_t/1.cc (test01): Parse
197 as year 197AD instead of error.
* testsuite/22_locale/time_get/get_year/wchar_t/5.cc (test01): Parse
1 as year 2001 instead of error.
* testsuite/22_locale/time_get/get_year/wchar_t/6.cc: New test.
Jonathan Wakely [Thu, 6 Jan 2022 13:54:53 +0000 (13:54 +0000)]
libstdc++: Fix and simplify freestanding configuration [PR103866]
This fixes the --disable-hosted-libstdcxx build so that it works with
--without-headers. Currently you need to also use --with-newlib, which
is confusing for users who aren't actually using newlib.
The AM_PROG_LIBTOOL checks are currently skipped for --with-newlib and
--with-avrlibc builds, with this change they are also skipped when using
--without-headers. It would be nice if using --disable-hosted-libstdcxx
automatically skipped those checks, but GLIBCXX_ENABLE_HOSTED comes too
late to make the AM_PROG_LIBTOOL checks depend on $is_hosted.
The checks for EOF, SEEK_CUR etc. cause the build to fail if there is no
<stdio.h> available. Unlike most headers, which get a HAVE_FOO_H macro,
<stdio.h> is in autoconf's default includes, so every check tries to
include it unconditionally. This change skips those checks for
freestanding builds.
Similarly, the checks for <stdint.h> types done by GCC_HEADER_STDINT try
to include <stdio.h> and fail for --without-headers builds. This change
skips the use of GCC_HEADER_STDINT for freestanding. We can probably
stop using GCC_HEADER_STDINT entirely, since only one file uses the
gstdint.h header that is generated, and that could easily be changed to
use <stdint.h> instead. That can wait for stage 1.
We also need to skip the GLIBCXX_CROSSCONFIG stage if --without-headers
was used, since we don't have any of the functions it deals with.
The end result of the changes above is that it should not be necessary
for a --disable-hosted-libstdcxx --without-headers build to also use
--with-newlib.
Finally, compile libsupc++ with -ffreestanding when --without-headers is
used, so that <stdint.h> will use <gcc-stdint.h> instead of expecting it
to come from libc.
libstdc++-v3/ChangeLog:
PR libstdc++/103866
* acinclude.m4 (GLIBCXX_COMPUTE_STDIO_INTEGER_CONSTANTS): Do
nothing for freestanding builds.
(GLIBCXX_ENABLE_HOSTED): Define FREESTANDING_FLAGS.
* configure.ac: Do not use AC_LIBTOOL_DLOPEN when configured
with --without-headers. Do not use GCC_HEADER_STDINT for
freestanding builds.
* libsupc++/Makefile.am (HOSTED_CXXFLAGS): Use -ffreestanding
for freestanding builds.
* configure: Regenerate.
* Makefile.in: Regenerate.
* doc/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* libsupc++/Makefile.in: Regenerate.
* po/Makefile.in: Regenerate.
* python/Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.
* src/c++11/Makefile.in: Regenerate.
* src/c++17/Makefile.in: Regenerate.
* src/c++20/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* src/filesystem/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
projects / thirdparty / gcc.git / log
