aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-12Docs: Fix typo in previous commitSandra Loosemore1-1/+1
gcc/ChangeLog: * doc/install.texi2html: Fix issue number typo in comment.
2023-03-12[PR modula2/109089] implementation of boolean should be C++/C boolGaius Mulley167-2369/+2667
[PR modula2/109089]. This patch implements BOOLEAN using bool (boolean_type_node) thoughout cc1gm2. The patch also includes a patched version of the bootstrap tool mc. gcc/ChangeLog: * doc/gm2.texi (Elementary data types): Equivalence BOOLEAN with bool. gcc/m2/ChangeLog: PR modula2/109089 * gm2-compiler/M2GCCDeclare.mod (DeclareKnownType): Import. * gm2-gcc/gcc-consolidation.h (stdbool.h): Include. * gm2-gcc/init.h (defined): Change block start. * gm2-gcc/m2block.cc: Change FALSE to false, change TRUE to true. * gm2-gcc/m2block.h: Change int to bool. * gm2-gcc/m2builtins.cc: Ditto. * gm2-gcc/m2builtins.h: Ditto. * gm2-gcc/m2convert.cc: Change FALSE to false, TRUE to true and int to bool. * gm2-gcc/m2convert.h: Change int to bool. * gm2-gcc/m2decl.cc: Change int to bool. * gm2-gcc/m2decl.h: Change int to bool. * gm2-gcc/m2expr.cc: Change FALSE to false, TRUE to true and int to bool. * gm2-gcc/m2expr.h: Change int to bool. * gm2-gcc/m2statement.cc: Change FALSE to false, TRUE to true and int to bool. * gm2-gcc/m2statement.h: Change int to bool. * gm2-gcc/m2top.cc: Change int to bool. * gm2-gcc/m2top.h: Change int to bool. * gm2-gcc/m2tree.cc: Change int to bool. * gm2-gcc/m2tree.h: Change int to bool. * gm2-gcc/m2type.cc: Change int to bool. * gm2-gcc/m2type.h: Change int to bool. * gm2-lang.cc (convert_loc): Call convert_to_integer for BOOLEAN_TYPE. * gm2-libs/Builtins.def (isfinitef): Change return value from BOOLEAN to INTEGER. (isfinite): Ditto. (isfinitel): Ditto. * gm2-libs/Builtins.mod (isfinitef): Change return value from BOOLEAN to INTEGER. (isfinite): Ditto. (isfinitel): Ditto. * mc-boot/GASCII.cc: Rebuild. * mc-boot/GASCII.h: Rebuild. * mc-boot/GArgs.cc: Rebuild. * mc-boot/GArgs.h: Rebuild. * mc-boot/GAssertion.cc: Rebuild. * mc-boot/GAssertion.h: Rebuild. * mc-boot/GBreak.cc: Rebuild. * mc-boot/GBreak.h: Rebuild. * mc-boot/GCOROUTINES.h: Rebuild. * mc-boot/GCmdArgs.cc: Rebuild. * mc-boot/GCmdArgs.h: Rebuild. * mc-boot/GDebug.cc: Rebuild. * mc-boot/GDebug.h: Rebuild. * mc-boot/GDynamicStrings.cc: Rebuild. * mc-boot/GDynamicStrings.h: Rebuild. * mc-boot/GEnvironment.cc: Rebuild. * mc-boot/GEnvironment.h: Rebuild. * mc-boot/GFIO.cc: Rebuild. * mc-boot/GFIO.h: Rebuild. * mc-boot/GFormatStrings.cc: Rebuild. * mc-boot/GFormatStrings.h: Rebuild. * mc-boot/GFpuIO.cc: Rebuild. * mc-boot/GFpuIO.h: Rebuild. * mc-boot/GIO.cc: Rebuild. * mc-boot/GIO.h: Rebuild. * mc-boot/GIndexing.cc: Rebuild. * mc-boot/GIndexing.h: Rebuild. * mc-boot/GM2Dependent.cc: Rebuild. * mc-boot/GM2Dependent.h: Rebuild. * mc-boot/GM2EXCEPTION.cc: Rebuild. * mc-boot/GM2EXCEPTION.h: Rebuild. * mc-boot/GM2LINK.h: Rebuild. * mc-boot/GM2RTS.cc: Rebuild. * mc-boot/GM2RTS.h: Rebuild. * mc-boot/GMemUtils.cc: Rebuild. * mc-boot/GMemUtils.h: Rebuild. * mc-boot/GNumberIO.cc: Rebuild. * mc-boot/GNumberIO.h: Rebuild. * mc-boot/GPushBackInput.cc: Rebuild. * mc-boot/GPushBackInput.h: Rebuild. * mc-boot/GRTExceptions.cc: Rebuild. * mc-boot/GRTExceptions.h: Rebuild. * mc-boot/GRTco.h: Rebuild. * mc-boot/GRTentity.h: Rebuild. * mc-boot/GRTint.cc: Rebuild. * mc-boot/GRTint.h: Rebuild. * mc-boot/GSArgs.cc: Rebuild. * mc-boot/GSArgs.h: Rebuild. * mc-boot/GSFIO.cc: Rebuild. * mc-boot/GSFIO.h: Rebuild. * mc-boot/GSYSTEM.h: Rebuild. * mc-boot/GSelective.h: Rebuild. * mc-boot/GStdIO.cc: Rebuild. * mc-boot/GStdIO.h: Rebuild. * mc-boot/GStorage.cc: Rebuild. * mc-boot/GStorage.h: Rebuild. * mc-boot/GStrCase.cc: Rebuild. * mc-boot/GStrCase.h: Rebuild. * mc-boot/GStrIO.cc: Rebuild. * mc-boot/GStrIO.h: Rebuild. * mc-boot/GStrLib.cc: Rebuild. * mc-boot/GStrLib.h: Rebuild. * mc-boot/GStringConvert.cc: Rebuild. * mc-boot/GStringConvert.h: Rebuild. * mc-boot/GSysExceptions.h: Rebuild. * mc-boot/GSysStorage.cc: Rebuild. * mc-boot/GSysStorage.h: Rebuild. * mc-boot/GTimeString.cc: Rebuild. * mc-boot/GTimeString.h: Rebuild. * mc-boot/GUnixArgs.h: Rebuild. * mc-boot/Galists.cc: Rebuild. * mc-boot/Galists.h: Rebuild. * mc-boot/Gdecl.cc: Rebuild. * mc-boot/Gdecl.h: Rebuild. * mc-boot/Gdtoa.h: Rebuild. * mc-boot/Gerrno.h: Rebuild. * mc-boot/Gkeyc.cc: Rebuild. * mc-boot/Gkeyc.h: Rebuild. * mc-boot/Gldtoa.h: Rebuild. * mc-boot/Glibc.h: Rebuild. * mc-boot/Glibm.h: Rebuild. * mc-boot/Glists.cc: Rebuild. * mc-boot/Glists.h: Rebuild. * mc-boot/GmcComment.cc: Rebuild. * mc-boot/GmcComment.h: Rebuild. * mc-boot/GmcComp.cc: Rebuild. * mc-boot/GmcComp.h: Rebuild. * mc-boot/GmcDebug.cc: Rebuild. * mc-boot/GmcDebug.h: Rebuild. * mc-boot/GmcError.cc: Rebuild. * mc-boot/GmcError.h: Rebuild. * mc-boot/GmcFileName.cc: Rebuild. * mc-boot/GmcFileName.h: Rebuild. * mc-boot/GmcLexBuf.cc: Rebuild. * mc-boot/GmcLexBuf.h: Rebuild. * mc-boot/GmcMetaError.cc: Rebuild. * mc-boot/GmcMetaError.h: Rebuild. * mc-boot/GmcOptions.cc: Rebuild. * mc-boot/GmcOptions.h: Rebuild. * mc-boot/GmcPreprocess.cc: Rebuild. * mc-boot/GmcPreprocess.h: Rebuild. * mc-boot/GmcPretty.cc: Rebuild. * mc-boot/GmcPretty.h: Rebuild. * mc-boot/GmcPrintf.cc: Rebuild. * mc-boot/GmcPrintf.h: Rebuild. * mc-boot/GmcQuiet.cc: Rebuild. * mc-boot/GmcQuiet.h: Rebuild. * mc-boot/GmcReserved.cc: Rebuild. * mc-boot/GmcReserved.h: Rebuild. * mc-boot/GmcSearch.cc: Rebuild. * mc-boot/GmcSearch.h: Rebuild. * mc-boot/GmcStack.cc: Rebuild. * mc-boot/GmcStack.h: Rebuild. * mc-boot/GmcStream.cc: Rebuild. * mc-boot/GmcStream.h: Rebuild. * mc-boot/Gmcflex.h: Rebuild. * mc-boot/Gmcp1.cc: Rebuild. * mc-boot/Gmcp1.h: Rebuild. * mc-boot/Gmcp2.cc: Rebuild. * mc-boot/Gmcp2.h: Rebuild. * mc-boot/Gmcp3.cc: Rebuild. * mc-boot/Gmcp3.h: Rebuild. * mc-boot/Gmcp4.cc: Rebuild. * mc-boot/Gmcp4.h: Rebuild. * mc-boot/Gmcp5.cc: Rebuild. * mc-boot/Gmcp5.h: Rebuild. * mc-boot/GnameKey.cc: Rebuild. * mc-boot/GnameKey.h: Rebuild. * mc-boot/GsymbolKey.cc: Rebuild. * mc-boot/GsymbolKey.h: Rebuild. * mc-boot/Gtermios.h: Rebuild. * mc-boot/Gtop.cc: Rebuild. * mc-boot/Gvarargs.cc: Rebuild. * mc-boot/Gvarargs.h: Rebuild. * mc-boot/Gwlists.cc: Rebuild. * mc-boot/Gwlists.h: Rebuild. * mc-boot/Gwrapc.h: Rebuild. * mc/decl.mod (doBoolC): New procedure. (doBaseC): Call doBoolC. * mc/keyc.mod: Import useBool. (genBool): New procedure. (genDefs): Call genBool. * mc/mcOptions.def (useBool): New procedure. * mc/mcOptions.mod (useBool): New procedure. (useBoolType): New variable. (optionIs): Assign useBoolType to TRUE. gcc/testsuite/ChangeLog: PR modula2/109089 * gm2/pimlib/run/pass/limittests.mod: Rewritten to reflect the external definitions of isfinite. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
2023-03-12libstdc++: Move www.graphviz.org to httpsGerald Pfeifer2-2/+2
libstdc++-v3/ChangeLog: * doc/xml/manual/documentation_hacking.xml: Move www.graphviz.org to https. * doc/html/manual/documentation_hacking.html: Regenerate.
2023-03-12Docs: Clean up description of asan-kernel-mem-intrinsic-prefix.Sandra Loosemore1-2/+4
gcc/ChangeLog: * doc/invoke.texi (Optimize Options): Add markup to description of asan-kernel-mem-intrinsic-prefix, and clarify wording slightly.
2023-03-12gcc/testsuite/gcc.dg: Fix LLP64 targetsJonathan Yong2-2/+3
gcc/testsuite/ChangeLog: * gcc.dg/builtins-69.c: Use (long )*regex pattern to allow long long instead of just long. * gcc.dg/pr80163.c: Use __INTPTR_TYPE__ for LLP64 tagets. Signed-off-by: Jonathan Yong <10walls@gmail.com>
2023-03-12gcc.c-torture/compile/103818.c: Enable for llp64 tooJonathan Yong1-1/+1
gcc/testsuite/ChangeLog: * gcc.c-torture/compile/103818.c: Enable test for llp64. Signed-off-by: Jonathan Yong <10walls@gmail.com>
2023-03-12Daily bump.GCC Administrator4-1/+38
2023-03-12doc: Drop a redundant link to AVR-LibCGerald Pfeifer1-1/+1
gcc/ChangeLog: * doc/extend.texi (Named Address Spaces): Drop a redundant link to AVR-LibC.
2023-03-11Fwd: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicitiesJeff Law1-1/+1
gcc/ PR web/88860 * doc/extend.texi: Clarify Attribute Syntax a bit.
2023-03-11Re: [PATCH 2/2] Corrected pr25521.c target matching.Cupertino Miranda2-3/+14
gcc/testsuite: * gcc.dg/pr25521.c: Skip for !const_volatile_readonly_section targets. Adjust expected output. * lib/target-supports.exp (check_effective_target_const_volatile_readonly_section): New
2023-03-11Fortran: fix bounds check for copying of class expressions [PR106945]Harald Anlauf2-0/+12
In the bounds check for copying of class expressions, the number of elements determined from a descriptor, returned as type gfc_array_index_type (i.e. a signed type), should be converted to the type of the passed element count, which is of type size_type_node (i.e. unsigned), for use in comparisons. gcc/fortran/ChangeLog: PR fortran/106945 * trans-expr.cc (gfc_copy_class_to_class): Convert element counts in bounds check to common type for comparison. gcc/testsuite/ChangeLog: PR fortran/106945 * gfortran.dg/pr106945.f90: New test.
2023-03-11Docs: Update documentation of Texinfo versions for building manuals.Sandra Loosemore2-22/+39
There has been recent discussion on updating the minimum required version of Texinfo from the current version 4.7. This patch does not do that, but it suggests that people use a more recent version to get better output. It also removes some other references to Texinfo 4.7 and fixes some related bit-rot in the installation manual. (Nobody really wants to print the GCC manual any more, and the GCC web site is a better place to get prebuilt manuals than the FSF store.) gcc/ChangeLog: * doc/install.texi (Prerequisites): Suggest using newer versions of Texinfo. (Final install): Clean up and modernize discussion of how to build or obtain the GCC manuals. * doc/install.texi2html: Update comment to point to the PR instead of "makeinfo 4.7 brokenness" (it's not specific to that version).
2023-03-11Daily bump.GCC Administrator12-1/+465
2023-03-10testsuite: Tweak check_fork_available for CRISHans-Peter Nilsson1-0/+6
This takes care of the failing gcc.dg/torture/ftrapv-1.c and -ftrapv-2.c for cris-elf. For simplicity, assume simulators are the GNU simulator (in the gdb repo). But cris-elf is newlib, so a newlib target forking? Yes: the I/O, etc. interface to the simulator uses the Linux/CRIS ABI. * lib/target-supports.exp (check_fork_available): Don't signal true for CRIS running on a simulator.
2023-03-10testsuite: gcc.dg/pr108117.c: Require effective-target schedulingHans-Peter Nilsson1-0/+1
Targets that don't support scheduling get a warning: cc1: warning: instruction scheduling not supported on this target machine Do like other target-generic tests unconditionally passing -fschedule-insns: require effective target scheduling. * gcc.dg/pr108117.c: Require effective-target scheduling.
2023-03-10testsuite: gcc.dg/pr106397.c: Add -w to optionsHans-Peter Nilsson1-1/+1
Targets that don't support prefetching get a warning: cc1: warning: '-fprefetch-loop-arrays' not supported for this target Align with other tests passing -fprefetch-loop-arrays for all targets: add "-w" to options. * gcc.dg/pr106397.c: Add -w to options.
2023-03-10c++ testsuite: Add test for PR107703Jakub Jelinek2-2/+586
This is on top of the https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html and https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html patches (to be precise, the latter isn't essential for it), I've realized that for the PR107703 bugfix in the first patch I haven't added some test coverage that the extended floating vs. integral or vice versa conversions work correctly. This new testcase adds such checks. And when writing it I've found that in ext-floating.h header in the testsuite I forgot back in November to remove #undef __STDCPP_BFLOAT16_T__ which was left there because the bfloat16 support wasn't in yet. The new testcase (and all older ext-floating*.C tests too) passes on vanilla trunk without the ext-floating.h change (x86_64-linux -m32/-m64) and with the PR107703 fix also with the ext-floating.h change. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR target/107703 * g++.dg/cpp23/ext-floating.h (__STDCPP_BFLOAT16_T__): Don't undefine it. (std::bfloat16_t): Use decltype (0.0bf16) like libstdc++, rather than __bf16. * g++.dg/cpp23/ext-floating14.C: New test.
2023-03-10libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf [PR107703]Jakub Jelinek5-3/+142
While DI <-> BF conversions can be handled (and are) through DI <-> XF <-> BF and for narrower integral modes even sometimes through DF or SF, because XFmode has 64-bit mantissa and so all the DImode values are exactly representable in XFmode. That is not the case for TImode, and while e.g. the HF -> TI conversions are IMHO useless in libgcc, because HFmode has -65504.0f16, 65504.0f16 range, all the integers will be already representable in SImode (or even HImode for unsigned) and so I think HF -> DI -> TI conversions are faster and valid, BFmode has roughly the same range as SFmode and so we absolutely need the TI -> BF conversions to avoid double rounding. As for BF -> TI conversions, they can be either also implemented in libgcc, or they can be implemented (as done in this commit) as BF -> SF -> TI conversions with the same code generation used elsewhere, just doing the 16-bit left shift of the bits - I think we don't need to handle sNaNs during the BF -> SF part because SF -> TI (which is already a libcall too) will handle that too. The BF -> SF -> TI path avoids wasting 32: 0000000000015e10 321 FUNC GLOBAL DEFAULT 13 __fixbfti@@GCC_13.0.0 89: 0000000000015f60 299 FUNC GLOBAL DEFAULT 13 __fixunsbfti@@GCC_13.0.0 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR target/107703 * optabs.cc (expand_fix): For conversions from BFmode to integral, use shifts to convert it to SFmode first and then convert SFmode to integral. * soft-fp/floattibf.c: New file. * soft-fp/floatuntibf.c: New file. * config/i386/libgcc-glibc.ver: Export __float{,un}tibf @ GCC_13.0.0. * config/i386/64/t-softfp (softfp_extras): Add floattibf and floatuntibf. (CFLAGS-floattibf.c, CFLAGS-floatunstibf.c): Add -msse2.
2023-03-10c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates ↵Jakub Jelinek2-2/+18
[PR107558] The following testcase ICEs, because OpenMP lowering for shared clause on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE. The reason is that the automatic variable has non-trivial construction (reference to a lambda) and -fmerge-all-constants is on and so TREE_READONLY isn't set - omp-low will handle automatic TREE_READONLY vars in shared specially and only copy to the construct and not back, while !TREE_READONLY are assumed to be changeable. The PR91529 change rationale was that the gimplification can change some non-addressable automatic variables to TREE_STATIC with -fmerge-all-constants and therefore TREE_READONLY on them is undesirable. But, the gimplifier does that only for aggregate variables: switch (TREE_CODE (type)) { case RECORD_TYPE: case UNION_TYPE: case QUAL_UNION_TYPE: case ARRAY_TYPE: and not for anything else. So, I think clearing TREE_READONLY for automatic integral or reference or pointer etc. vars for -fmerge-all-constants only is unnecessary. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR c++/107558 * decl.cc (cp_finish_decl): Don't clear TREE_READONLY on automatic non-aggregate variables just because of -fmerge-all-constants. * g++.dg/gomp/pr107558.C: New test.
2023-03-10c++, abi: Fix up class layout with bitfields [PR109039]Jakub Jelinek2-1/+42
The following testcase FAILs, because starting with r12-6028 the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit bitfield and one 8-bit char field. The reason is that when end_of_class attempts to compute dsize, it simply adds byte_position of the field and DECL_SIZE_UNIT (and uses maximum from those offsets). The problematic bit-field in question has bit_position 7, byte_position 0, DECL_SIZE 8 and DECL_SIZE_UNIT 1. So, byte_position + DECL_SIZE_UNIT is 1, even when the bitfield only has a single bit in the first byte and 7 further bits in the second byte, so per the Itanium ABI it should be 2: "In either case, update dsize(C) to include the last byte containing (part of) the bit-field, and update sizeof(C) to max(sizeof(C),dsize(C))." The following patch fixes it by computing bitsize of the end and using CEIL_DIV_EXPR division to round it to next byte boundary and convert from bits to bytes. While this is an ABI change, classes with such incorrect layout couldn't have worked properly, so I doubt anybody is actually running it often in the wild. Thus I think adding some ABI warning for it is unnecessary. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR c++/109039 * class.cc (end_of_class): For bit-fields, instead of computing offset as sum of byte_position (field) and DECL_SIZE_UNIT (field), compute it as sum of bit_position (field) and DECL_SIZE (field) divided by BITS_PER_UNIT rounded up. * g++.dg/abi/no_unique_address7.C: New test.
2023-03-10MAINTAINERS: add myself to write after approvalArsen Arsenović1-0/+1
ChangeLog: * MAINTAINERS (Write After Approval): Add myself.
2023-03-10c++: constrained lambda error-recovery [PR108972]Jason Merrill2-2/+6
Better not to ICE after various valid errors. PR c++/108972 gcc/cp/ChangeLog: * lambda.cc (compare_lambda_template_head): Check more for error_mark_node. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels, but expect errors.
2023-03-10ubsan: missed -fsanitize=bounds for compound ops [PR108060]Marek Polacek6-0/+100
In this PR we are dealing with a missing .UBSAN_BOUNDS, so the out-of-bounds access in the test makes the program crash before a UBSan diagnostic was emitted. In C and C++, c_genericize gets a[b] = a[b] | c; but in C, both a[b] are one identical shared tree (not in C++ because cp_fold/ARRAY_REF created two same but not identical trees). Since ubsan_walk_array_refs_r keeps a pset, in C we produce a[.UBSAN_BOUNDS (0B, SAVE_EXPR <b>, 8);, SAVE_EXPR <b>;] = a[b] | c; because the LHS is walked before the RHS. Since r7-1900, we gimplify the RHS before the LHS. So the statement above gets gimplified into _1 = a[b]; c.0_2 = c; b.1 = b; .UBSAN_BOUNDS (0B, b.1, 8); With this patch we produce: a[b] = a[.UBSAN_BOUNDS (0B, SAVE_EXPR <b>, 8);, SAVE_EXPR <b>;] | c; which gets gimplified into: b.0 = b; .UBSAN_BOUNDS (0B, b.0, 8); _1 = a[b.0]; therefore we emit a runtime error before making the bad array access. I think it's OK that only the RHS gets a .UBSAN_BOUNDS, as in few lines above: the instrumented array access dominates the array access on the LHS, and I've verified that b = 0; a[b] = (a[b], b = -32768, a[0] | c); works as expected: the inner a[b] is OK but we do emit an error for the a[b] on the LHS. For GCC 14, we could apply <https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613687.html> since the copy_node doesn't seem to be needed. PR sanitizer/108060 PR sanitizer/109050 gcc/c-family/ChangeLog: * c-gimplify.cc (ubsan_walk_array_refs_r): For a MODIFY_EXPR, instrument the RHS before the LHS. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/bounds-17.c: New test. * c-c++-common/ubsan/bounds-18.c: New test. * c-c++-common/ubsan/bounds-19.c: New test. * c-c++-common/ubsan/bounds-20.c: New test. * c-c++-common/ubsan/bounds-21.c: New test.
2023-03-10Fortran: fix ICE with bind(c) in block data [PR104332]Harald Anlauf2-2/+23
gcc/fortran/ChangeLog: PR fortran/104332 * resolve.cc (resolve_symbol): Avoid NULL pointer dereference while checking a symbol with the BIND(C) attribute. gcc/testsuite/ChangeLog: PR fortran/104332 * gfortran.dg/bind_c_usage_34.f90: New test.
2023-03-10Fix PR 108874: aarch64 code regression with shift and andsAndrew Pinski3-0/+84
After r6-2044-g98e30e515f184b, code like "((x & 0xff00ff00U) >> 8)" would be optimized like (x >> 8) & 0xff00ffU which is normally better except on aarch64, the shift right could be combined with another operation in some cases. So we need to add a few define_splits to the aarch64 backends that match "((x >> shift) & CST0) OP Y" and splits it to: TMP = X & CST1 (TMP >> shift) OP Y Note this also gets us to matching rev16 back too so I added a testcase to make sure we don't lose that matching any more. Note when the generic patch to recognize those as bswap ROT 16, we might regress again and need to add a few more patterns to the aarch64 backend but will deal with that once that happens. Committed as approved after a bootstrapp/test on aarch64-linux-gnu with no regressions. gcc/ChangeLog: * config/aarch64/aarch64.md: Add a new define_split to help combine. gcc/testsuite/ChangeLog: * gcc.target/aarch64/rev16_2.c: New test. * gcc.target/aarch64/shift_and_operator-1.c: New test.
2023-03-10Use 'GOMP_MAP_VARS_TARGET' for OpenACC compute constructs [PR90596]Thomas Schwinge5-238/+44
Thereby considerably simplify the device plugins' 'GOMP_OFFLOAD_openacc_exec', 'GOMP_OFFLOAD_openacc_async_exec' functions: in terms of lines of code, but in particular conceptually: no more device memory allocation, host to device data copying, device memory deallocation -- 'GOMP_MAP_VARS_TARGET' does all that for us. This depends on commit 2b2340e236c0bba8aaca358ea25a5accd8249fbd "Allow libgomp 'cbuf' buffering with OpenACC 'async' for 'ephemeral' data", where I said that "a use will emerge later", which is this one here. PR libgomp/90596 libgomp/ * target.c (gomp_map_vars_internal): Allow for 'param_kind == GOMP_MAP_VARS_OPENACC | GOMP_MAP_VARS_TARGET'. * oacc-parallel.c (GOACC_parallel_keyed): Pass 'GOMP_MAP_VARS_TARGET' to 'goacc_map_vars'. * plugin/plugin-gcn.c (alloc_by_agent, gcn_exec) (GOMP_OFFLOAD_openacc_exec, GOMP_OFFLOAD_openacc_async_exec): Adjust, simplify. (gomp_offload_free): Remove. * plugin/plugin-nvptx.c (nvptx_exec, GOMP_OFFLOAD_openacc_exec) (GOMP_OFFLOAD_openacc_async_exec): Adjust, simplify. (cuda_free_argmem): Remove. * testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c: Adjust.
2023-03-10analyzer: fix leak false +ve seen in haproxy's cfgparse.c [PR109059]David Malcolm6-18/+158
If a bound region gets overwritten with UNKNOWN due to being possibly-aliased during a write, that could have been the only region keeping its value live, in which case we could falsely report a leak. This is hidden somewhat by the "uncertainty" mechanism for cases where the write happens in the same stmt as the last reference to the value goes away, but not in the general case, which occurs in PR analyzer/109059, which falsely complains about a leak whilst haproxy updates a doubly-linked list. The whole "uncertainty_t" class seems broken to me now; I think we need to track (in the store) what values could have escaped to the external part of the program. We do this to some extent for pointers by tracking the region as escaped, though we're failing to do this for this case: even though there could still be other pointers to the region, eventually they go away; we want to capture the fact that the external part of the state is still keeping it live. Also, this doesn't work for non-pointer svalues, such as for detecting file-descriptor leaks. As both a workaround and a step towards eventually removing "class uncertainty_t" this patch updates the "mark_region_as_unknown" code called by possibly-aliased set_value so that when old values are removed, any base region pointed to them is marked as escaped, fixing the leak false positive. The patch has this effect on my integration tests of -fanalyzer: Comparison: GOOD: 129 (19.20% -> 20.22%) BAD: 543 -> 509 (-34) where there's a big improvement in -Wanalyzer-malloc-leak: -Wanalyzer-malloc-leak: GOOD: 61 (45.19% -> 54.95%) BAD: 74 -> 50 (-24) Known false positives: 25 -> 2 (-23) haproxy-2.7.1: 24 -> 1 (-23) Suspected false positives: 49 -> 48 (-1) coreutils-9.1: 32 -> 31 (-1) and some churn in the other warnings: -Wanalyzer-use-of-uninitialized-value: GOOD: 0 BAD: 81 -> 80 (-1) -Wanalyzer-file-leak: GOOD: 0 BAD: 10 -> 11 (+1) -Wanalyzer-out-of-bounds: GOOD: 0 BAD: 24 -> 22 (-2) gcc/analyzer/ChangeLog: PR analyzer/109059 * region-model.cc (region_model::mark_region_as_unknown): Gather a set of maybe-live svalues and call on_maybe_live_values with it. * store.cc (binding_map::remove_overlapping_bindings): Add new "maybe_live_values" param; add any removed svalues to it. (binding_cluster::clobber_region): Add NULL as new param of remove_overlapping_bindings. (binding_cluster::mark_region_as_unknown): Add "maybe_live_values" param and pass it to remove_overlapping_bindings. (binding_cluster::maybe_get_compound_binding): Add NULL for new param of binding_map::remove_overlapping_bindings. (binding_cluster::remove_overlapping_bindings): Add "maybe_live_values" param and pass to binding_map::remove_overlapping_bindings. (store::set_value): Capture a set of maybe-live svalues, and call on_maybe_live_values with it. (store::on_maybe_live_values): New. (store::mark_region_as_unknown): Add "maybe_live_values" param and pass it to binding_cluster::mark_region_as_unknown. (store::remove_overlapping_bindings): Pass NULL for new param of binding_cluster::remove_overlapping_bindings. * store.h (binding_map::remove_overlapping_bindings): Add "maybe_live_values" param. (binding_cluster::mark_region_as_unknown): Likewise. (binding_cluster::remove_overlapping_bindings): Likewise. (store::mark_region_as_unknown): Likewise. (store::on_maybe_live_values): New decl. gcc/testsuite/ChangeLog: PR analyzer/109059 * gcc.dg/analyzer/flex-with-call-summaries.c: Remove xfail. * gcc.dg/analyzer/leak-pr109059-1.c: New test. * gcc.dg/analyzer/leak-pr109059-2.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-03-10Allow libgomp 'cbuf' buffering with OpenACC 'async' for 'ephemeral' dataThomas Schwinge1-34/+36
This does *allow*, but under no circumstances is this currently going to be used: all potentially applicable data is non-'ephemeral', and thus not considered for 'gomp_coalesce_buf_add' for OpenACC 'async'. (But a use will emerge later.) Follow-up to commit r12-2530-gd88a6951586c7229b25708f4486eaaf4bf4b5bbe "Don't use libgomp 'cbuf' buffering with OpenACC 'async'", addressing this TODO comment: TODO ... but we could allow CBUF usage for EPHEMERAL data? (Open question: is it more performant to use libgomp CBUF buffering or individual device asyncronous copying?) Ephemeral data is small, and therefore individual device asyncronous copying does seem dubious -- in particular given that for all those, we'd individually have to allocate and queue for deallocation a temporary buffer to capture the ephemeral data. Instead, just let the 'cbuf' *be* the temporary buffer. libgomp/ * target.c (gomp_copy_host2dev, gomp_map_vars_internal): Allow libgomp 'cbuf' buffering with OpenACC 'async' for 'ephemeral' data.
2023-03-10Simplify OpenACC 'no_create' clause implementationThomas Schwinge5-27/+54
For 'OFFSET_INLINED', 'gomp_map_val' does the right thing, and we may then simplify the device plugins accordingly. This is a follow-up to Subversion r279551 (Git commit a6163563f2ce502bd4ef444bd5de33570bb8eeb1) "Add OpenACC 2.6's no_create", Subversion r279622 (Git commit 5bcd470bf0749e1f56d05dd43aa9584ff2e3a090) "Use gomp_map_val for OpenACC host-to-device address translation". libgomp/ * target.c (gomp_map_vars_internal): Use 'OFFSET_INLINED' for 'GOMP_MAP_IF_PRESENT'. * plugin/plugin-gcn.c (gcn_exec, GOMP_OFFLOAD_openacc_exec) (GOMP_OFFLOAD_openacc_async_exec): Adjust. * plugin/plugin-nvptx.c (nvptx_exec, GOMP_OFFLOAD_openacc_exec) (GOMP_OFFLOAD_openacc_async_exec): Likewise. * testsuite/libgomp.oacc-c-c++-common/no_create-1.c: Add 'async' testing. * testsuite/libgomp.oacc-c-c++-common/no_create-2.c: Likewise.
2023-03-10OpenACC: Remove 'acc_async_test' -> skip shortcut in ↵Thomas Schwinge1-3/+0
'libgomp/oacc-async.c:goacc_wait' We're not taking such a shortcut anywhere else, and (with future changes) it has potential to confuse things if synchronization in a libgomp plugin happens to have side effects even if an async queue currently is empty. libgomp/ * oacc-async.c (goacc_wait): Remove 'acc_async_test' -> skip shortcut.
2023-03-10Document/verify another aspect of OpenACC 'async' semantics in ↵Thomas Schwinge1-2/+2
'libgomp.oacc-c-c++-common/data-3.c' ... that I almost broke with later implementation changes. libgomp/ * testsuite/libgomp.oacc-c-c++-common/data-3.c: Document/verify another aspect of OpenACC 'async' semantics.
2023-03-10Speedup PTA solving for call constraint setsRichard Biener1-4/+11
With calls we now often get contraints like callarg = *callarg + UNKNOWN or similar cases. The important thing to note is that this complex constraint changes the node solution itself, so when solving the node is marked as changed immediately again. When that happens it's profitable to iterate that self-cycle immediately so we maximize cache reuse and build up the successor graph quickly to get better topological ordering and reduce the number of iterations of the solving. For a testcase derived from ceph this reduces the time spent in PTA solving from 453s to 92s which is quite significant. * tree-ssa-structalias.cc (solve_graph): Immediately iterate self-cycles.
2023-03-10Fix OpenACC/GCN 'acc_ev_enqueue_launch_end' positionThomas Schwinge2-30/+195
For an OpenACC compute construct, we've currently got: - [...] - acc_ev_enqueue_launch_start - launch kernel - free memory - acc_ev_free - acc_ev_enqueue_launch_end This confused another thing that I'm working on, so I adjusted that to: - [...] - acc_ev_enqueue_launch_start - launch kernel - acc_ev_enqueue_launch_end - free memory - acc_ev_free Correspondingly, verify 'acc_ev_alloc', 'acc_ev_free' in 'libgomp.oacc-c-c++-common/acc_prof-parallel-1.c'. libgomp/ * plugin/plugin-gcn.c (gcn_exec): Fix 'acc_ev_enqueue_launch_end' position. * testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c: Verify 'acc_ev_alloc', 'acc_ev_free'.
2023-03-10c++: class NTTP and nested anon union [PR108566]Jason Merrill2-1/+45
We were failing to come up with the name for the anonymous union. It seems like unfortunate redundancy, but the ABI does say that the name of an anonymous union is its first named member. PR c++/108566 gcc/cp/ChangeLog: * mangle.cc (anon_aggr_naming_decl): New. (write_unqualified_name): Use it. gcc/testsuite/ChangeLog: * g++.dg/abi/anon6.C: New test.
2023-03-10analyzer: fix deref-before-check false +ves seen in haproxy [PR108475,PR109060]David Malcolm4-37/+356
Integration testing showed various false positives from -Wanalyzer-deref-before-check where the expression that's dereferenced is different from the one that's checked, but the diagnostic is emitted because they both evaluate to the same symbolic value. This patch rejects such warnings, unless we have tree expressions for both and that both tree expressions are "spelled the same way" i.e. would be printed to the same user-facing string. gcc/analyzer/ChangeLog: PR analyzer/108475 PR analyzer/109060 * sm-malloc.cc (deref_before_check::deref_before_check): Initialize new field m_deref_expr. Assert that arg is non-NULL. (deref_before_check::emit): Reject cases where the spelling of the thing that was dereferenced differs from that of what is checked, or if the dereference expression was not found. Remove code to handle NULL m_arg. (deref_before_check::describe_state_change): Remove code to handle NULL m_arg. (deref_before_check::describe_final_event): Likewise. (deref_before_check::sufficiently_similar_p): New. (deref_before_check::m_deref_expr): New field. (malloc_state_machine::maybe_complain_about_deref_before_check): Don't warn if the diag_ptr is NULL. gcc/testsuite/ChangeLog: PR analyzer/108475 PR analyzer/109060 * gcc.dg/analyzer/deref-before-check-pr108475-1.c: New test. * gcc.dg/analyzer/deref-before-check-pr108475-haproxy-tcpcheck.c: New test. * gcc.dg/analyzer/deref-before-check-pr109060-haproxy-cfgparse.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-03-10range-op-float: Extend lhs by 0.5ulp rather than 1ulp if not -frounding-math ↵Jakub Jelinek1-2/+18
[PR109008] This patch, incremental to the just posted one, improves the reverse operation ranges significantly by widening just by 0.5ulp in each direction rather than 1ulp. Again, REAL_VALUE_TYPE has both wider exponent range and wider mantissa precision (160 bits) than any supported type, this patch uses the latter property. The patch doesn't do it if -frounding-math, because then the rounding can be +-1ulp in each direction depending on the rounding mode which we don't know, or for IBM double double because that type is just weird and we can't trust in sane properties. I've performed testing of these 2 patches on 300000 random tests as with yesterday's patch, exact numbers are in the PR, but I see very significant improvement in the precision of the ranges while keeping it conservatively correct. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109008 * range-op-float.cc (float_widen_lhs_range): If not -frounding-math and not IBM double double format, extend lhs range just by 0.5ulp rather than 1ulp in each direction.
2023-03-10libstdc++: Fix GDB Xmethod for std::shared_ptr::use_count() [PR109064]Jonathan Wakely2-1/+11
libstdc++-v3/ChangeLog: PR libstdc++/109064 * python/libstdcxx/v6/xmethods.py (SharedPtrUseCountWorker): Remove self-recursion in __init__. Add missing _supports. * testsuite/libstdc++-xmethods/shared_ptr.cc: Check use_count() and unique().
2023-03-10cygwin: Don't try to support multilibs [PR107998]Jakub Jelinek2-4/+1
As discussed in the PR, t-cygwin-w64 file has been introduced in 2013 and has one important problem, two different multilib options -m64 and -m32, but MULTILIB_DIRNAMES with just one word in it. Before the genmultilib sanity checking was added, my understanding is that this essentially resulted in effective --disable-multilib, $ gcc -print-multi-lib .; ;@m32 $ gcc -print-multi-directory . $ gcc -print-multi-directory -m64 . $ gcc -print-multi-directory -m32 $ gcc -print-multi-os-directory ../lib $ gcc -print-multi-os-directory -m64 ../lib $ gcc -print-multi-os-directory -m32 ../lib32 and because of the way e.g. config-ml.in operates multidirs= for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do dir=`echo $i | sed -e 's/;.*$//'` if [ "${dir}" = "." ]; then true else if [ -z "${multidirs}" ]; then multidirs="${dir}" else multidirs="${multidirs} ${dir}" fi fi done dir was . first time (and so nothing was done) and empty second time, multidirs empty too, so multidirs was set to empty like it would be with --disable-multilib. With the added sanity checking the build fails unless --disable-multilib is used in configure (dunno whether people usually configure that way on cygwin). >From what has been said in the PR, multilibs were not meant to be supported and e.g. cygwin headers probably aren't ready for it. So the following patch just removes the file with the (incorrect) multilib stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32). I have no way to test this though, no Windows around, can anyone please test this? I just would like to get some progress on the P1s we have... 2023-02-22 Jakub Jelinek <jakub@redhat.com> gcc/ChangeLog: PR target/107998 * config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into $tmake_file. * config/i386/t-cygwin-w64: Remove. Signed-off-by: Jonathan Yong <10walls@gmail.com>
2023-03-10tree: Use comdat tree_code_{type,length} even for C++11/14 [PR108634]Jakub Jelinek3-36/+35
The recent change to undo the tree_code_type/tree_code_length excessive duplication apparently broke building the Linux kernel plugin. While it is certainly desirable that GCC plugins are built with the same compiler as GCC has been built and with the same options (at least the important ones), it might be hard to arrange that, e.g. if gcc is built using a cross-compiler but the plugin then built natively, or GCC isn't bootstrapped for other reasons, or just as in the kernel case they were building the plugin with -std=gnu++11 while the bootstrapped GCC has been built without any such option and so with whatever the compiler defaulted to. For C++17 and later tree_code_{type,length} are UNIQUE symbols with those assembler names, while for C++11/14 they were _ZL14tree_code_type and _ZL16tree_code_length. The following patch uses a comdat var for those even for C++11/14 as suggested by Maciej Cencora. Relying on weak attribute is not an option because not all hosts support it and there are non-GNU system compilers. While we could use it unconditionally, I think defining a template just to make it comdat is weird, and the compiler itself is always built with the same compiler. Plugins, being separate shared libraries, will have a separate copy of the arrays if they are ODR-used in the plugin, so there is not a big deal if e.g. cc1plus uses tree_code_type while plugin uses _ZN19tree_code_type_tmplILi0EE14tree_code_typeE or vice versa. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR plugins/108634 * tree-core.h (tree_code_type, tree_code_length): For C++11 or C++14, don't declare as extern const arrays. (tree_code_type_tmpl, tree_code_length_tmpl): New types with static constexpr member arrays for C++11 or C++14. * tree.h (TREE_CODE_CLASS): For C++11 or C++14 use tree_code_type_tmpl <0>::tree_code_type instead of tree_code_type. (TREE_CODE_LENGTH): For C++11 or C++14 use tree_code_length_tmpl <0>::tree_code_length instead of tree_code_length. * tree.cc (tree_code_type, tree_code_length): Remove.
2023-03-10file-prefix-map: Fix up -f*-prefix-map= [PR108464]Jakub Jelinek8-16/+72
On Tue, Nov 01, 2022 at 01:46:20PM -0600, Jeff Law via Gcc-patches wrote: > > This does cause a change of behaviour if users were previously relying upon > > symlinks or absolute paths not being resolved. > > I'm not too worried about this scenario. As mentioned in the PR, this patch breaks e.g. ccache testsuite. I strongly doubt most of the users want such a behavior, because it makes all filenames absolute when -f*-prefix-map= options remap one absolute path to another one. Say if I'm in /tmp and /tmp is the canonical path and there is src/test.c file, with -fdebug-prefix-map=/tmp=/blah previously there would be DW_AT_comp_dir "/blah" and it is still there, but DW_AT_name which was previouly "src/test.c" (relative against DW_AT_comp_dir) is now "/blah/src/test.c" instead. Even worse, the canonicalization is only done on the remap_filename argument, but not on the old_prefix side. That is e.g. what breaks ccache. If there is /tmp/foobar1 directory and ln -sf foobar1 /tmp/foobar2 cd /tmp/foobar2 then -fdebug-prefix-map=`pwd`:/blah will just not work, while src/test.c will be canonicalized to /tmp/foobar1/src/test.c, old_prefix is still what the user provided which is /tmp/foobar2. User would need to change their uses to use -fdebug-prefix-map=`realpath $(pwd)`=/blah I've created 3 patches for this. The first patch just reverts the patch (and its follow-up patch). The second introduces a new option, -f{,no}-canon-prefix-map which affects the behavior of -f{file,macro,debug,profile}-prefix-map=, if on it canonicalizes the old path of the prefix map option and compares that against the canonicalized filename for absolute paths but not relative. And last is like the second, but does that also for relative paths except for filenames with no / (or / or \ on DOS based fs). So, the third patch gets an optional behavior of what has been on the trunk lately with the difference that the old_prefix is canonicalized by the compiler. Initially I've thought I'd just add some magic syntax to the OLD=NEW argument of those options (because there are 4 of them), but as noted in the comments, = is valid char in OLD (just not new), so it would be hard to figure out some syntax. So instead a new option, which one can turn on and off for different -f*-prefix-map= options if needed. -fdebug-prefix-map=/path1=/mypath1 -fcanon-prefix-map \ -fdebug-prefix-map=/path2=/mypath2 -fno-canon-prefix-map \ -fdebug-prefix-map=/path3=/mypath3 will use the old behavior for the /path1 and /path3 handling and the new one only for /path2 handling. This commit is the third patch described above. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR other/108464 * common.opt (fcanon-prefix-map): New option. * opts.cc: Include file-prefix-map.h. (flag_canon_prefix_map): New variable. (common_handle_option): Handle OPT_fcanon_prefix_map. (gen_command_line_string): Ignore OPT_fcanon_prefix_map. * file-prefix-map.h (flag_canon_prefix_map): Declare. * file-prefix-map.cc (struct file_prefix_map): Add canonicalize member. (add_prefix_map): Initialize canonicalize member from flag_canon_prefix_map, and if true canonicalize it using lrealpath. (remap_filename): Revert 2022-11-01 and 2022-11-07 changes, use lrealpath result only for map->canonicalize map entries. * lto-opts.cc (lto_write_options): Ignore OPT_fcanon_prefix_map. * opts-global.cc (handle_common_deferred_options): Clear flag_canon_prefix_map at the start and handle OPT_fcanon_prefix_map. * doc/invoke.texi (-fcanon-prefix-map): Document. (-ffile-prefix-map, -fdebug-prefix-map, -fprofile-prefix-map): Add see also for -fcanon-prefix-map. * doc/cppopts.texi (-fmacro-prefix-map): Likewise.
2023-03-10c, c++, cgraphunit: Prevent duplicated -Wunused-value warnings [PR108079]Jakub Jelinek4-1/+16
On the following testcase, we warn with -Wunused-value twice, once in the FEs and later on cgraphunit again with slightly different wording. The following patch fixes that by registering a warning suppression in the FEs when we warn and not warning in cgraphunit anymore if that happened. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR c/108079 gcc/ * cgraphunit.cc (check_global_declaration): Don't warn for unused variables which have OPT_Wunused_variable warning suppressed. gcc/c/ * c-decl.cc (pop_scope): Suppress OPT_Wunused_variable warning after diagnosing it. gcc/cp/ * decl.cc (poplevel): Suppress OPT_Wunused_variable warning after diagnosing it. gcc/testsuite/ * c-c++-common/Wunused-var-18.c: New test.
2023-03-10range-op-float: Fix up -ffinite-math-only range extension and don't extend ↵Jakub Jelinek2-4/+60
into infinities [PR109008] The following patch does two things (both related to range extension around the boundaries). The first part (in the 2 real_isfinite blocks) is to make the ranges narrower when the old boundaries are minimum and/or maximum representable finite number. In that case frange_nextafter gives -Inf or +Inf, but then the resulting computed reverse range is very far from the actually needed range, usually extends up to infinity or could even result in NaNs. While infinities are really the next representable numbers in the corresponding mode, REAL_VALUE_TYPE is actually a type with wider range for exponent and 160 bit precision, so the patch instead uses nextafter number in a hypothetical floating point format with the same mantissa precision but wider range of exponents. This significantly improves the actual ranges of the reverse operations, while still making them conservatively correct. The second part is a fix for miscompilation of the new testcase below. For -ffinite-math-only, without this patch we extend the minimum and/or maximum representable finite number to -Inf or +Inf, with the patch to some number outside of the normal exponent range of the mode, but then we use set which canonicalizes it and turns the boundaries back to the minimum and/or maximum representable finite numbers, but because in say [__DBL_MAX__, __DBL_MAX__] = op1 + [__DBL_MAX__, __DBL_MAX__] op1 can be larger than 0, up to the largest number which rounds to even down back to __DBL_MAX__ and there are still no infinities involved, it needs to work even with -ffinite-math-only. So, we really need to widen the lhs range a little bit even in that case. The patch does that through temporarily clearing -ffinite-math-only, such that the value with infinities or the outside of bounds values passes the setting and verification (the VR_VARYING case is needed because we get ICEs otherwise, but when lhs is VR_VARYING in -ffast-math, i.e. minimum to maximum representable finite and both signs of NaN, then set does all we need, we don't need to or in a NaN range). We don't really later use the range in a way that would become a problem that it is wider than varying, we actually just perform maths on the two boundaries. As I said in the PR, this doesn't fix the !MODE_HAS_INFINITIES case, I believe we actually need to treat the boundary values as infinities in that case because they (probably) work like that, but it is unclear if it is just the reverse operation lhs widening that is a problem there, or whether it is a general problem. I have zero experience with floating points without infinities (PDP11, some ARM half type?, what else?). 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109008 * range-op-float.cc (float_widen_lhs_range): If lb is minimum representable finite number or ub is maximum representable finite number, instead of widening it to -inf or inf widen it to negative or positive 0x0.8p+(EMAX+1). Temporarily clear flag_finite_math_only when canonicalizing the widened range. * gcc.dg/pr109008.c: New test.
2023-03-10RISC-V: Add fault first load C/C++ supportJu-Zhe Zhong18-312/+575
gcc/ChangeLog: * config/riscv/riscv-builtins.cc (riscv_gimple_fold_builtin): New function. * config/riscv/riscv-protos.h (riscv_gimple_fold_builtin): Ditto. (gimple_fold_builtin): Ditto. * config/riscv/riscv-vector-builtins-bases.cc (class read_vl): New class. (class vleff): Ditto. (BASE): Ditto. * config/riscv/riscv-vector-builtins-bases.h: Ditto. * config/riscv/riscv-vector-builtins-functions.def (read_vl): Ditto. (vleff): Ditto. * config/riscv/riscv-vector-builtins-shapes.cc (struct read_vl_def): Ditto. (struct fault_load_def): Ditto. (SHAPE): Ditto. * config/riscv/riscv-vector-builtins-shapes.h: Ditto. * config/riscv/riscv-vector-builtins.cc (rvv_arg_type_info::get_tree_type): Add size_ptr. (gimple_folder::gimple_folder): New class. (gimple_folder::fold): Ditto. (gimple_fold_builtin): New function. (get_read_vl_instance): Ditto. (get_read_vl_decl): Ditto. * config/riscv/riscv-vector-builtins.def (size_ptr): Add size_ptr. * config/riscv/riscv-vector-builtins.h (class gimple_folder): New class. (get_read_vl_instance): New function. (get_read_vl_decl): Ditto. * config/riscv/riscv-vsetvl.cc (fault_first_load_p): Ditto. (read_vl_insn_p): Ditto. (available_occurrence_p): Ditto. (backward_propagate_worthwhile_p): Ditto. (gen_vsetvl_pat): Adapt for vleff support. (get_forward_read_vl_insn): New function. (get_backward_fault_first_load_insn): Ditto. (source_equal_p): Adapt for vleff support. (first_ratio_invalid_for_second_sew_p): Remove. (first_ratio_invalid_for_second_lmul_p): Ditto. (first_lmul_less_than_second_lmul_p): Ditto. (first_ratio_less_than_second_ratio_p): Ditto. (support_relaxed_compatible_p): New function. (vector_insn_info::operator>): Remove. (vector_insn_info::operator>=): Refine. (vector_insn_info::parse_insn): Adapt for vleff support. (vector_insn_info::compatible_p): Ditto. (vector_insn_info::update_fault_first_load_avl): New function. (pass_vsetvl::transfer_after): Adapt for vleff support. (pass_vsetvl::demand_fusion): Ditto. (pass_vsetvl::cleanup_insns): Ditto. * config/riscv/riscv-vsetvl.def (DEF_INCOMPATIBLE_COND): Remove redundant condtions. * config/riscv/riscv-vsetvl.h (struct demands_cond): New function. * config/riscv/riscv.cc (TARGET_GIMPLE_FOLD_BUILTIN): New target hook. * config/riscv/riscv.md: Adapt for vleff support. * config/riscv/t-riscv: Ditto. * config/riscv/vector-iterators.md: New iterator. * config/riscv/vector.md (read_vlsi): New pattern. (read_vldi_zero_extend): Ditto. (@pred_fault_load<mode>): Ditto.
2023-03-10Extend nops num in "maybe_gen_insn" for RISC-V Vector intrinsicsJu-Zhe Zhong2-22/+7
Hi, current maybe_gen_insn can only expand 9 nops. For RVV intrinsics, I need to extend it as 10, otherwise I should use GEN_FCN. This patch is quite obvious change, Ok for trunk ? Thanks. gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc (function_expander::use_ternop_insn): Use maybe_gen_insn instead. (function_expander::use_widen_ternop_insn): Ditto. * optabs.cc (maybe_gen_insn): Extend nops handling.
2023-03-10RISC-V: Fine tune merge operand constraint for integer/load/storeJu-Zhe Zhong4-650/+1065
gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Split indexed load patterns according to RVV ISA. * config/riscv/vector-iterators.md: New iterators. * config/riscv/vector.md (@pred_indexed_<order>load<VNX1_QHSD:mode><VNX1_QHSDI:mode>): Remove. (@pred_indexed_<order>load<mode>_same_eew): New pattern. (@pred_indexed_<order>load<mode>_x2_greater_eew): Ditto. (@pred_indexed_<order>load<mode>_x4_greater_eew): Ditto. (@pred_indexed_<order>load<mode>_x8_greater_eew): Ditto. (@pred_indexed_<order>load<mode>_x2_smaller_eew): Ditto. (@pred_indexed_<order>load<mode>_x4_smaller_eew): Ditto. (@pred_indexed_<order>load<mode>_x8_smaller_eew): Ditto. (@pred_indexed_<order>load<VNX2_QHSD:mode><VNX2_QHSDI:mode>): Remove. (@pred_indexed_<order>load<VNX4_QHSD:mode><VNX4_QHSDI:mode>): Ditto. (@pred_indexed_<order>load<VNX8_QHSD:mode><VNX8_QHSDI:mode>): Ditto. (@pred_indexed_<order>load<VNX16_QHS:mode><VNX16_QHSI:mode>): Ditto. (@pred_indexed_<order>load<VNX32_QH:mode><VNX32_QHI:mode>): Ditto. (@pred_indexed_<order>load<VNX64_Q:mode><VNX64_Q:mode>): Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/merge_constraint-1.c: New test.
2023-03-10[PATCH v2] vect: Check that vector factor is a compile-time constantMichael Collison1-1/+1
* tree-vect-loop-manip.cc (vect_do_peeling): Use result of constant_lower_bound instead of vf for the lower bound of the epilog loop trip count.
2023-03-09c++: signed __int128_t [PR108099]Jason Merrill2-3/+12
The code for handling signed + typedef was breaking on __int128_t, because it isn't a proper typedef: it doesn't have DECL_ORIGINAL_TYPE. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Handle non-typedef typedef_decl. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-7.C: New test.
2023-03-09c++: overloaded fn in contract [PR108542]Jason Merrill2-0/+9
PR c++/108542 gcc/cp/ChangeLog: * class.cc (instantiate_type): Strip location wrapper. gcc/testsuite/ChangeLog: * g++.dg/contracts/contracts-err1.C: New test.
2023-03-10Daily bump.GCC Administrator6-1/+227
2023-03-09c++: allocator temps in list of arrays [PR108773]Jason Merrill3-21/+110
The optimization to reuse the same allocator temporary for all string constructor calls was breaking on this testcase, because the temps were already in the argument to build_vec_init, and replacing them with references to one slot got confused with calls at multiple levels (for the initializer_list backing array, and then again for the array member of the std::array). Fixed by reusing the whole TARGET_EXPR instead of pulling out the slot; gimplification ensures that it's only initialized once. I also moved the check for initializing a std:: class down into the tree walk, and handle multiple temps within a single array element initialization. PR c++/108773 gcc/cp/ChangeLog: * init.cc (find_allocator_temps_r): New. (combine_allocator_temps): Replace find_allocator_temp. (build_vec_init): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array18.C: New test. * g++.dg/cpp0x/initlist-array19.C: New test.
generated by cgit v1.1 at 2025-09-27 01:40:24 +0000