Re: [RFC PATCH] tree-ssa-sink: do not sink to in front of setjmp
On Mon, Jan 3, 2022 at 5:35 PM Alexander Monakov wrote: > > On Mon, 3 Jan 2022, Richard Biener wrote: > > > > @@ -5674,6 +5675,14 @@ gimple_verify_flow_info (void) > > >err = 1; > > > } > > > > > > + if (prev_stmt && stmt_starts_bb_p (stmt, prev_stmt)) > > > > stmt_starts_bb_p is really a helper used during CFG build, I'd rather > > test explicitely for a GIMPLE call with ECF_RETURNS_TWICE, or maybe, > > verify that iff a block has abnormal predecessors it starts with such > > a call (because IIRC we in some cases elide abnormal edges and then > > it's OK to move "down" the calls). So yes, if a block has abnormal preds > > it should start with a ECF_RETURNS_TWICE call, I think we cannot > > verify the reverse reliably - abnormal edges cannot easily be re-built > > in late stages (it's a bug that we do so during RTL expansion). > > Thanks, I could rewrite the patch along those lines, but I'm not sure where > this is going: the ~100 extra FAILs will still be there. What would the next > steps be for this patch and the initial tree-ssa-sink patch? I approved the initial sink patch (maybe not clearly enough). Can you open a bugreport about the missing CFG verification and list the set of FAILs (all errors in some passes similar to the one you fixed in sinking I guess)? It indeed sounds like something to tackle during next stage1 (unless you already narrowed down the culprit to a single offender...) Richard. > > Alexander
Re: [PATCH] Support ld.mold linker.
On Mon, Jan 3, 2022 at 4:23 PM Martin Liška wrote:
>
> On 1/3/22 15:48, Richard Biener wrote:
> > On Tue, Dec 28, 2021 at 2:10 PM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> The mold linker is getting quite popular and I think we should support it:
> >> https://github.com/rui314/mold
> >
> > Does it support the gold plugin API/ABI and thus proper LTO?
>
> No, but it's planned to be added:
> https://github.com/rui314/mold/issues/181
>
> > If not
> > I'm not sure we should encourage use. For example using
> > -flto -fuse-ld=lld will report strange
> >
> > ld.lld: error: undefined symbol: main
> referenced by start.S:104 (../sysdeps/x86_64/start.S:104)
> /usr/lib/../lib64/crt1.o:(_start)
> > collect2: error: ld returned 1 exit status
> >
> > on a simple test with a main() unless I manually add -fno-use-linker-plugin.
>
> Yep, that's consequence of the fact a compiler is not built with such linker.
> Maybe we can add a documentation note, what do you think?
Since we have a fixed set of supported linkers and we know their implementation
status with respect to linker plugin support we can maybe auto-add
-fno-use-linker-plugin
(via specs?) when -fuse-ld=lld or -fuse-ld=mold is used? But yes,
adding a note to
the documentation that for lld and mold LTO support is severely
restricted compared to
GNU ld or gold on platforms that support the linker plugin and thus
their use is discouraged
there might be a good idea.
Richard.
>
> Cheers,
> Martin
>
> >
> > Richard.
> >
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> >> Thanks,
> >> Martin
> >>
> >> ---
> >>gcc/collect2.c | 10 +++---
> >>gcc/common.opt | 4
> >>gcc/gcc.c | 4
> >>gcc/opts.c | 1 +
> >>4 files changed, 16 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/gcc/collect2.c b/gcc/collect2.c
> >> index d47fe3f9195..b322527847c 100644
> >> --- a/gcc/collect2.c
> >> +++ b/gcc/collect2.c
> >> @@ -776,6 +776,7 @@ main (int argc, char **argv)
> >> USE_GOLD_LD,
> >> USE_BFD_LD,
> >> USE_LLD_LD,
> >> + USE_MOLD_LD,
> >> USE_LD_MAX
> >>} selected_linker = USE_DEFAULT_LD;
> >> static const char *const ld_suffixes[USE_LD_MAX] =
> >> @@ -784,7 +785,8 @@ main (int argc, char **argv)
> >> PLUGIN_LD_SUFFIX,
> >> "ld.gold",
> >> "ld.bfd",
> >> - "ld.lld"
> >> + "ld.lld",
> >> + "ld.mold"
> >>};
> >> static const char *const real_ld_suffix = "real-ld";
> >> static const char *const collect_ld_suffix = "collect-ld";
> >> @@ -957,6 +959,8 @@ main (int argc, char **argv)
> >>selected_linker = USE_GOLD_LD;
> >> else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
> >>selected_linker = USE_LLD_LD;
> >> + else if (strcmp (argv[i], "-fuse-ld=mold") == 0)
> >> + selected_linker = USE_MOLD_LD;
> >> else if (startswith (argv[i], "-o"))
> >>{
> >> /* Parse the output filename if it's given so that we can make
> >> @@ -1048,7 +1052,7 @@ main (int argc, char **argv)
> >> ld_file_name = 0;
> >>#ifdef DEFAULT_LINKER
> >> if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
> >> - selected_linker == USE_LLD_LD)
> >> + selected_linker == USE_LLD_LD || selected_linker == USE_MOLD_LD)
> >>{
> >> char *linker_name;
> >># ifdef HOST_EXECUTABLE_SUFFIX
> >> @@ -1283,7 +1287,7 @@ main (int argc, char **argv)
> >>else if (!use_collect_ld
> >> && startswith (arg, "-fuse-ld="))
> >> {
> >> - /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
> >> + /* Do not pass -fuse-ld={bfd|gold|lld|mold} to the
> >> linker. */
> >>ld1--;
> >>ld2--;
> >> }
> >> diff --git a/gcc/common.opt b/gcc/common.opt
> >> index 2ed818d6057..dba3fa886f9 100644
> >> --- a/gcc/common.opt
> >> +++ b/gcc/common.opt
> >> @@ -3046,6 +3046,10 @@ fuse-ld=lld
> >>Common Driver Negative(fuse-ld=lld)
> >>Use the lld LLVM linker instead of the default linker.
> >>
> >> +fuse-ld=mold
> >> +Common Driver Negative(fuse-ld=mold)
> >> +Use the Modern linker (MOLD) linker instead of the default linker.
> >> +
> >>fuse-linker-plugin
> >>Common Undocumented Var(flag_use_linker_plugin)
> >>
> >> diff --git a/gcc/gcc.c b/gcc/gcc.c
> >> index b75b50b87b2..06e18a75b52 100644
> >> --- a/gcc/gcc.c
> >> +++ b/gcc/gcc.c
> >> @@ -4282,6 +4282,10 @@ driver_handle_option (struct gcc_options *opts,
> >> use_ld = ".gold";
> >> break;
> >>
> >> +case OPT_fuse_ld_mold:
> >> + use_ld = ".mold";
> >> + break;
> >> +
> >>case OPT_fcompare_debug_second:
> >> compare_debug_second = 1;
> >> break;
> >> diff --git a/gcc/opts.c b/gcc/opts.c
> >> index c
RE: [PATCH] x86: Update model value for Alderlake and Rocketlake
> -Original Message-
> From: Cui, Lili
> Sent: Tuesday, January 4, 2022 1:20 PM
> To: gcc-patches@gcc.gnu.org
> Cc: ubiz...@gmail.com; Liu, Hongtao ;
> hjl.to...@gmail.com
> Subject: [PATCH] x86: Update model value for Alderlake and Rocketlake
>
> Hi Uros,
>
> This patch is to update model value for Alderlake and Rocketlake.
Just note the update is according to latest
https://www.intel.com/content/dam/develop/public/us/en/documents/325462-sdm-vol-1-2abcd-3abcd.pdf
>
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master?
>
> gcc/ChangeLog
>
> * common/config/i386/cpuinfo.h (get_intel_cpu): Add new model
> values
> to Alderlake and Rocketlake.
> ---
> gcc/common/config/i386/cpuinfo.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/common/config/i386/cpuinfo.h
> b/gcc/common/config/i386/cpuinfo.h
> index 2d8ea201ab5..61b1a0f291c 100644
> --- a/gcc/common/config/i386/cpuinfo.h
> +++ b/gcc/common/config/i386/cpuinfo.h
> @@ -415,6 +415,7 @@ get_intel_cpu (struct __processor_model
> *cpu_model,
>cpu_model->__cpu_subtype = INTEL_COREI7_SKYLAKE;
>break;
> case 0xa7:
> +case 0xa8:
>/* Rocket Lake. */
>cpu = "rocketlake";
>CHECK___builtin_cpu_is ("corei7"); @@ -487,6 +488,7 @@ get_intel_cpu
> (struct __processor_model *cpu_model,
>break;
> case 0x97:
> case 0x9a:
> +case 0xbf:
>/* Alder Lake. */
>cpu = "alderlake";
>CHECK___builtin_cpu_is ("corei7");
> --
> 2.17.1
>
> Thanks,
> Lili.
[PATCH] x86: Update model value for Alderlake and Rocketlake
Hi Uros,
This patch is to update model value for Alderlake and Rocketlake.
Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
OK for master?
gcc/ChangeLog
* common/config/i386/cpuinfo.h (get_intel_cpu): Add new model values
to Alderlake and Rocketlake.
---
gcc/common/config/i386/cpuinfo.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/common/config/i386/cpuinfo.h b/gcc/common/config/i386/cpuinfo.h
index 2d8ea201ab5..61b1a0f291c 100644
--- a/gcc/common/config/i386/cpuinfo.h
+++ b/gcc/common/config/i386/cpuinfo.h
@@ -415,6 +415,7 @@ get_intel_cpu (struct __processor_model *cpu_model,
cpu_model->__cpu_subtype = INTEL_COREI7_SKYLAKE;
break;
case 0xa7:
+case 0xa8:
/* Rocket Lake. */
cpu = "rocketlake";
CHECK___builtin_cpu_is ("corei7");
@@ -487,6 +488,7 @@ get_intel_cpu (struct __processor_model *cpu_model,
break;
case 0x97:
case 0x9a:
+case 0xbf:
/* Alder Lake. */
cpu = "alderlake";
CHECK___builtin_cpu_is ("corei7");
--
2.17.1
Thanks,
Lili.
PING^5 [PATCH v4 0/2] Implement indirect external access
On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu wrote: > > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu wrote: > > > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu wrote: > > > > > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu wrote: > > > > > > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu wrote: > > > > > > > > > > Changes in the v4 patch. > > > > > > > > > > 1. Add nodirect_extern_access attribute. > > > > > > > > > > Changes in the v3 patch. > > > > > > > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been > > > > > added to > > > > > GNU binutils 2.38. But the -z indirect-extern-access linker option is > > > > > only available for Linux/x86. However, the --max-cache-size=SIZE > > > > > linker > > > > > option was also addded within a day. --max-cache-size=SIZE is used to > > > > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > > > > > > > Changes in the v2 patch. > > > > > > > > > > 1. Rename the option to -fdirect-extern-access. > > > > > > > > > > --- > > > > > On systems with copy relocation: > > > > > * A copy in executable is created for the definition in a shared > > > > > library > > > > > at run-time by ld.so. > > > > > * The copy is referenced by executable and shared libraries. > > > > > * Executable can access the copy directly. > > > > > > > > > > Issues are: > > > > > * Overhead of a copy, time and space, may be visible at run-time. > > > > > * Read-only data in the shared library becomes read-write copy in > > > > > executable at run-time. > > > > > * Local access to data with the STV_PROTECTED visibility in the shared > > > > > library must use GOT. > > > > > > > > > > On systems without function descriptor, function pointers vary > > > > > depending > > > > > on where and how the functions are defined. > > > > > * If the function is defined in executable, it can be the address of > > > > > function body. > > > > > * If the function, including the function with STV_PROTECTED > > > > > visibility, > > > > > is defined in the shared library, it can be the address of the PLT > > > > > entry > > > > > in executable or shared library. > > > > > > > > > > Issues are: > > > > > * The address of function body may not be used as its function > > > > > pointer. > > > > > * ld.so needs to search loaded shared libraries for the function > > > > > pointer > > > > > of the function with STV_PROTECTED visibility. > > > > > > > > > > Here is a proposal to remove copy relocation and use canonical > > > > > function > > > > > pointer: > > > > > > > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > > > > use GOT. > > > > > a. Linker may optimize out GOT access if the data is defined in PIE > > > > > or > > > > > non-PIE. > > > > > 2. Read-only data in the shared library remain read-only at run-time > > > > > 3. Address of global data with the STV_PROTECTED visibility in the > > > > > shared > > > > > library is the address of data body. > > > > > a. Can use IP-relative access. > > > > > b. May need GOT without IP-relative access. > > > > > 4. For systems without function descriptor, > > > > > a. All global function pointers of undefined functions in PIE and > > > > > non-PIE must use GOT. Linker may optimize out GOT access if the > > > > > function is defined in PIE or non-PIE. > > > > > b. Function pointer of functions with the STV_PROTECTED visibility > > > > > in > > > > > executable and shared library is the address of function body. > > > > >i. Can use IP-relative access. > > > > >ii. May need GOT without IP-relative access. > > > > >iii. Branches to undefined functions may use PLT. > > > > > 5. Single global definition marker: > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED: > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > > > > > > > to indicate the needed properties by the object file. > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > > > > > > > to indicate that the object file requires canonical function pointers > > > > > and > > > > > cannot be used with copy relocation. This bit should be cleared in > > > > > executable when there are non-GOT or non-PLT relocations in > > > > > relocatable > > > > > input files without this bit set. > > > > > > > > > > a. Protected symbol access within the shared library can be treated > > > > > as > > > > > local. > > > > > b. Copy relocation should be disallowed at link-time and run-time. > > > > > c. GOT function pointer reference is required at link-time and > > > > > run-time. > > > > > > > > > > The indirect external access marker can be used in the following ways: > > > > > > > > > > 1. Linker can decide the best way to resolve a relocation against a > > > > > protected symbol before seeing all relocations against the symbol. > > > > > 2. Dynamic linker can decide if it is an error to have a copy >
[PATCH] [i386] Force_reg operand 1.
Avoid ICE of move pattern from memory to memory.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Pushed to trunk.
gcc/ChangeLog:
PR target/103895
* config/i386/sse.md (*bit_and_float_vector_all_ones):
Force_reg operand 1 to avoid ICE.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr103895.c: New test.
---
gcc/config/i386/sse.md | 3 ++-
gcc/testsuite/gcc.target/i386/pr103895.c | 16
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr103895.c
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 033b60d9aa2..fa1d56ae3e3 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -4750,7 +4750,8 @@ (define_insn_and_split "*bit_and_float_vector_all_ones"
"TARGET_SSE && ix86_pre_reload_split ()"
"#"
"&& 1"
- [(set (match_dup 0) (match_dup 1))])
+ [(set (match_dup 0) (match_dup 1))]
+ "operands[1] = force_reg (mode, operands[1]);")
(define_expand "copysign3"
[(set (match_dup 4)
diff --git a/gcc/testsuite/gcc.target/i386/pr103895.c
b/gcc/testsuite/gcc.target/i386/pr103895.c
new file mode 100644
index 000..40b827806e7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr103895.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -ffloat-store" } */
+
+#include
+typedef float vFloat __attribute__((__vector_size__(16)));
+float bar_dr;
+vFloat bar_f1;
+void bar() {
+ static vFloat m0;
+ vFloat fa1 = _mm_andnot_ps(m0, bar_f1);
+ __attribute__((__vector_size__(2 * sizeof(double double v3 =
+ _mm_cvtps_pd(fa1);
+ vFloat r1 = _mm_cvtpd_ps(v3);
+ _mm_storeu_ps(&bar_dr, r1);
+}
+
--
2.18.1
[PING][PATCH v5 0/4] __builtin_dynamic_object_size
Happy new year, and ping! On 12/18/21 18:05, Siddhesh Poyarekar wrote: This patchset enhances the __builtin_dynamic_object_size builtin to produce dynamic expressions for object sizes to improve coverage of _FORTIFY_SOURCE. Testing: This series has been tested with build and test for i686, bootstrap with ubsan and full bootstrap and test with x86_64. I also tested the toolchain with a glibc build and testsuite run for x86_64 and i686 with _FORTIFY_SOURCE=3 enabled for gcc12. Additional testing plans (i.e. I've already started to do some of this): - Build packages to compare values returned by __builtin_object_size with the older pass and this new one. Also compare with __builtin_dynamic_object_size. - Expand the list of packages to get more coverage metrics. - Explore performance impact on applications on building with _FORTIFY_SOURCE=3. Siddhesh Poyarekar (4): tree-object-size: Support dynamic sizes in conditions tree-object-size: Handle function parameters tree-object-size: Handle GIMPLE_CALL tree-object-size: Dynamic sizes for ADDR_EXPR gcc/builtins.c| 6 +- .../gcc.dg/builtin-dynamic-object-size-0.c| 495 + .../gcc.dg/builtin-dynamic-object-size-10.c | 2 + .../builtin-dynamic-object-size-5-main.c | 32 + .../gcc.dg/builtin-dynamic-object-size-5.c| 7 +- gcc/testsuite/gcc.dg/builtin-object-size-1.c | 154 +++- gcc/testsuite/gcc.dg/builtin-object-size-2.c | 133 gcc/testsuite/gcc.dg/builtin-object-size-3.c | 151 gcc/testsuite/gcc.dg/builtin-object-size-4.c | 93 +++ gcc/testsuite/gcc.dg/builtin-object-size-5.c | 22 +- gcc/tree-object-size.c| 670 +++--- 11 files changed, 1677 insertions(+), 88 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c create mode 100644 gcc/testsuite/gcc.dg/builtin-dynamic-object-size-5-main.c
Re: [PATCH] libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]
Hi, David! One question below as I'm still not done with using this patch in rustc_codegen_gcc. Le jeudi 20 mai 2021 à 15:25 -0400, David Malcolm a écrit : > On Tue, 2021-05-18 at 14:53 +0200, Jakub Jelinek via Jit wrote: > > On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc- > > patches wrote: > > > Hello. > > > This patch add support for sized integer types. > > > Maybe it should check whether the size of a byte for the current > > > platform is 8 bits and do other checks so that they're only > > > available > > > when it makes sense. > > > What do you think? > > > > Not a review, just a comment. The 128-bit integral types are > > available > > only on some targets, the test e.g. the C/C++ FE do for those is > > targetm.scalar_mode_supported_p (TImode) > > and so even libgccjit shouldn't provide those types > > unconditionally. > > Similarly for the tests (though it could be guarded with e.g > > #ifdef __SIZEOF_INT128__ > > in that case). > > Also, while currently all in tree targets have BITS_PER_UNIT 8 and > > therefore QImode is 8-bit, HImode 16-bit, SImode 32-bit and DImode > > 64- > > bit, > > in the past and maybe in he future there can be targets that could > > have > > e.g. 16-bit or 32-bit QImode and then there wouldn't be any > > uint8_t/int8_t > > and int16_t would be intQImode_type_node etc. > > uint16_type_node = make_or_reuse_type (16, 1); > > uint32_type_node = make_or_reuse_type (32, 1); > > uint64_type_node = make_or_reuse_type (64, 1); > > if (targetm.scalar_mode_supported_p (TImode)) > > uint128_type_node = make_or_reuse_type (128, 1); > > are always with the given precisions, perhaps jit should use > > signed_type_for (uint16_type_node) etc.? > > I seem to have mislaid Antoni's original email (sorry), so I'll reply > to Jakub's. > > > 2021-05-18 Antoni Boucher > > > > gcc/jit/ > > PR target/95325 > > * jit-playback.c: Add support for the sized integer > > types. > > * jit-recording.c: Add support for the sized integer > > types. > > * libgccjit.h (GCC_JIT_TYPE_UINT8_T, > > GCC_JIT_TYPE_UINT16_T, > > GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, > > GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, > > GCC_JIT_TYPE_INT16_T, > > GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, > > GCC_JIT_TYPE_INT128_T): > > New enum variants for gcc_jit_types. > > gcc/testsuite/ > > PR target/95325 > > * jit.dg/test-types.c: Add tests for sized integer > > types. > > First a high-level question, why not use (or extend) > gcc_jit_context_get_int_type instead? > > Do we really need to extend enum gcc_jit_types? Is this a quality- > of- > life thing for users of the library? > > That said, recording::context::get_int_type is currently a bit of a > hack, and maybe could probably be improved by using the new enum > values > the patch adds. > > IIRC, libgccjit.c does type-checking by comparing recording::type > pointer values; does this patch gives us multiple equivalent types > that > ought to compare as equal? > > If a user gets a type via GCC_JIT_TYPE_INT and gets "another" type > via > GCC_JIT_TYPE_INT32_T and they happen to be the same on the current > target, should libgccjit complain if you use "int" when you meant > "int32_t", or accept it? > > Various comments inline below... > > > diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c > > index c6136301243..40630aa1ab8 100644 > > --- a/gcc/jit/jit-playback.c > > +++ b/gcc/jit/jit-playback.c > > @@ -193,6 +193,27 @@ get_tree_node_for_type (enum gcc_jit_types > > type_) > > case GCC_JIT_TYPE_UNSIGNED_INT: > > return unsigned_type_node; > > > > + case GCC_JIT_TYPE_UINT8_T: > > + return unsigned_intQI_type_node; > > + case GCC_JIT_TYPE_UINT16_T: > > + return uint16_type_node; > > + case GCC_JIT_TYPE_UINT32_T: > > + return uint32_type_node; > > + case GCC_JIT_TYPE_UINT64_T: > > + return uint64_type_node; > > + case GCC_JIT_TYPE_UINT128_T: > > + return uint128_type_node; > > + case GCC_JIT_TYPE_INT8_T: > > + return intQI_type_node; > > + case GCC_JIT_TYPE_INT16_T: > > + return intHI_type_node; > > + case GCC_JIT_TYPE_INT32_T: > > + return intSI_type_node; > > + case GCC_JIT_TYPE_INT64_T: > > + return intDI_type_node; > > + case GCC_JIT_TYPE_INT128_T: > > + return intTI_type_node; > > + > > Jakub has already commented that 128 bit types might not be > available. > > Ideally we'd report that they're not available as soon as the user > tries to use them, in gcc_jit_context_get_type, but unfortunately it > looks like the test requires us to use > targetm.scalar_mode_supported_p, > and that requires us to hold the jit mutex and thus be at playback > time. I'd need a way to check if 128-bit integers are supported and if not, use something else. The fact that this check is only available at playback
[PATCH] [COMMITTED] c++: [PR90782] Add testcase
From: Andrew Pinski
This testcase was fixed by r12-1744-g3eecc1 as it make
sense it fixed a few other class deduction issues.
So I thought I would add a testcase for this PR and close
it as fixed.
Committed after a quick test of the testcase.
PR c++/90782
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/class-deduction100.C: New test.
---
gcc/testsuite/g++.dg/cpp1z/class-deduction100.C | 13 +
1 file changed, 13 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction100.C
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction100.C
b/gcc/testsuite/g++.dg/cpp1z/class-deduction100.C
new file mode 100644
index 000..9fa307ffb77
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction100.C
@@ -0,0 +1,13 @@
+// PR c++/90782
+// { dg-do compile { target c++17 } }
+
+template
+struct bar {
+template
+bar(B& obj, void(B::*f)(A...)const=&B::operator()){}
+};
+int main() {
+const auto f1 = [](){};
+bar f8(f1);
+}
+
--
2.17.1
Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O
Hi Jakub, clearly there is still work to fix (but seems e.g. most of the lto tests are related to the gnu attributes stuff:( ). This is looking better than what I expected. Apart from LTO, I expect that a couple of files still do not have the correct flags set when compiling, or maybe some types are wrong. This is now something that can be debugged in detail. Ok? OK. And thanks! Best regards Thomas
Re: [PATCH v2] c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]
On Mon, Jan 03, 2022 at 03:55:51PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
LGTM, thanks.
> Can I backport it to GCC 11 too?
Not immediately, but say after 2 weeks sure.
>
> -- >8 --
> I'm tired of seeing
>
> cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use
> 'declaration' instead [-Wformat-diag]
> cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use
> 'declaration' instead [-Wformat-diag]
>
> every time I compile cp/parser.c, which happens...a lot. I'd like my
> compilation to be free of warnings, otherwise I'm going to miss some
> important ones.
>
> "decl-specifiers" is a C++ grammar term; it is not actual code, so
> should not be wrapped with %< %>. I hope we can accept it as an exception
> in check_tokens.
>
> It was surrounded by %< %> in cp_parser_decl_specifier_seq, so fix that.
>
> In passing, fix a misspelling in missspellings.
>
> PR c++/103758
>
> gcc/c-family/ChangeLog:
>
> * c-format.c (check_tokens): Accept "decl-specifier*".
>
> gcc/cp/ChangeLog:
>
> * parser.c (cp_parser_decl_specifier_seq): Replace %
> with %qD.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp0x/constexpr-condition.C: Adjust dg-error.
> ---
> gcc/c-family/c-format.c | 8 +++-
> gcc/cp/parser.c | 2 +-
> gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C | 2 +-
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
> index 7d3b3117ee2..afa77810a5c 100644
> --- a/gcc/c-family/c-format.c
> +++ b/gcc/c-family/c-format.c
> @@ -3194,7 +3194,7 @@ check_tokens (const token_t *tokens, unsigned ntoks,
> wlen, format_chars);
>else
> {
> - /* Diagnose some common missspellings. */
> + /* Diagnose some common misspellings. */
>for (unsigned i = 0; i != sizeof badwords / sizeof *badwords; ++i)
> {
> unsigned badwlen = strspn (badwords[i].name, " -");
> @@ -3215,6 +3215,12 @@ check_tokens (const token_t *tokens, unsigned ntoks,
> plural = "s";
> }
>
> + /* As an exception, don't warn about "decl-specifier*" since
> + it's a C++ grammar production. */
> + if (badwords[i].name[0] == 'd'
> + && startswith (format_chars, "decl-specifier"))
> + continue;
> +
> format_warning_substr (format_string_loc, format_string_cst,
>fmtchrpos, fmtchrpos + badwords[i].len,
>opt,
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 4475f792916..6b91a0ce491 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -15821,7 +15821,7 @@ cp_parser_decl_specifier_seq (cp_parser* parser,
>if (found_decl_spec
> && (flags & CP_PARSER_FLAGS_ONLY_TYPE_OR_CONSTEXPR)
> && token->keyword != RID_CONSTEXPR)
> - error ("% invalid in condition");
> + error ("%qD invalid in condition", ridpointers[token->keyword]);
>
>if (found_decl_spec
> && (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR)
> diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
> b/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
> index 733d494c4d7..e81acba68ae 100644
> --- a/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
> +++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
> @@ -5,5 +5,5 @@ constexpr int something() { return 3; }
>
> int main() {
>if (constexpr long v = something()) {}
> - if (static long v = something()) { } // { dg-error "'decl-specifier'
> invalid" }
> + if (static long v = something()) { } // { dg-error "'static' invalid" }
> }
>
> base-commit: 1096ab1775636f35de9c6661f8f71f03299af998
> --
> 2.33.1
Jakub
[PATCH v2] c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]
On Mon, Dec 20, 2021 at 09:53:25PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 20, 2021 at 03:21:04PM -0500, Jason Merrill via Gcc-patches wrote:
> > > @@ -3215,6 +3215,14 @@ check_tokens (const token_t *tokens, unsigned
> > > ntoks,
> > > plural = "s";
> > > }
> > > + /* As an exception, don't warn about "decl-specifier*" since
> > > + it's a C++ grammar production. */
> > > + {
> > > + const size_t l = strlen ("decl-specifier");
> > > + if (!strncmp (format_chars, "decl-specifier", l))
> > > + return format_chars + l - 1;
> > > + }
> >
> > I'd prefer to avoid repeating the string literal, but OK.
>
> We have the startswith inline function that allows to avoid the repetition.
> It wouldn't work in the above case due to the return format_chars + l - 1,
> but that in itself looks quite weird to me, I'd think better would be
> continue; instead of the return ...;, i.e. whenever we see decl-specifier
> in the text pretend we haven't seen decl.
> So
> /* As an exception, don't warn about "decl-specifier*" since
>it's a C++ grammar production. */
> if (startswith (format_chars, "decl-specifier"))
> continue;
> ?
> Or perhaps even optimize and don't compare uselessly everything with
> "decl-specifier" and do it only for the "decl" badword if it matches,
> so
> if (badwords[i].name[0] == 'd'
> && startswith (format_chars, "decl-specifier"))
> continue;
> ?
Works for me, thanks.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Can I backport it to GCC 11 too?
-- >8 --
I'm tired of seeing
cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
every time I compile cp/parser.c, which happens...a lot. I'd like my
compilation to be free of warnings, otherwise I'm going to miss some
important ones.
"decl-specifiers" is a C++ grammar term; it is not actual code, so
should not be wrapped with %< %>. I hope we can accept it as an exception
in check_tokens.
It was surrounded by %< %> in cp_parser_decl_specifier_seq, so fix that.
In passing, fix a misspelling in missspellings.
PR c++/103758
gcc/c-family/ChangeLog:
* c-format.c (check_tokens): Accept "decl-specifier*".
gcc/cp/ChangeLog:
* parser.c (cp_parser_decl_specifier_seq): Replace %
with %qD.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-condition.C: Adjust dg-error.
---
gcc/c-family/c-format.c | 8 +++-
gcc/cp/parser.c | 2 +-
gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C | 2 +-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 7d3b3117ee2..afa77810a5c 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -3194,7 +3194,7 @@ check_tokens (const token_t *tokens, unsigned ntoks,
wlen, format_chars);
else
{
- /* Diagnose some common missspellings. */
+ /* Diagnose some common misspellings. */
for (unsigned i = 0; i != sizeof badwords / sizeof *badwords; ++i)
{
unsigned badwlen = strspn (badwords[i].name, " -");
@@ -3215,6 +3215,12 @@ check_tokens (const token_t *tokens, unsigned ntoks,
plural = "s";
}
+ /* As an exception, don't warn about "decl-specifier*" since
+it's a C++ grammar production. */
+ if (badwords[i].name[0] == 'd'
+ && startswith (format_chars, "decl-specifier"))
+ continue;
+
format_warning_substr (format_string_loc, format_string_cst,
fmtchrpos, fmtchrpos + badwords[i].len,
opt,
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 4475f792916..6b91a0ce491 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15821,7 +15821,7 @@ cp_parser_decl_specifier_seq (cp_parser* parser,
if (found_decl_spec
&& (flags & CP_PARSER_FLAGS_ONLY_TYPE_OR_CONSTEXPR)
&& token->keyword != RID_CONSTEXPR)
- error ("% invalid in condition");
+ error ("%qD invalid in condition", ridpointers[token->keyword]);
if (found_decl_spec
&& (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR)
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
index 733d494c4d7..e81acba68ae 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-condition.C
@@ -5,5 +5,5 @@ constexpr int something() { return 3; }
int main() {
if (constexpr long v = something()) {}
- if (static long v = something()) { } // {
[PATCH] i386: Always enable mov patterns [PR103894]
Middle end tries to generate V4QImode moves to implement V2QImode inserts
and calls emit_move_multi_word when V4QImode moves are unavailable, as is
the case with 32-bit vector moves, constrainted with TARGET_SSE2.
However, this triggers
gcc_assert (mode_size >= UNITS_PER_WORD);
in emit_move_multi_word, since mode_size of V4QImode operand is less than
UNITS_PER_WORD of 64-bit targets.
The patch unconditionally enables 32-bit vector moves to match 16-bit
vector moves. This also enables implementation of 32-bit vector logic
operations with GPR in a follow-up patch.
2022-01-03 Uroš Bizjak
gcc/ChangeLog:
PR target/103894
* config/i386/mmx.md (mov): Remove TARGET_SSE2 constraint.
(mov_internal): Ditto.
(*push_rex64): Ditto.
(movmisalign): Ditto.
(*push_rex64 splitter): Enable for
TARGET_64BIT && TARGET_SSE.
(*push2): Remove insn pattern.
gcc/testsuite/ChangeLog:
PR target/103894
* gcc.target/i386/pr103894.c: New test.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to master.
Uros.
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 67b02661243..5b33d3cfc1c 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -250,7 +250,7 @@
(define_expand "mov"
[(set (match_operand:V_32 0 "nonimmediate_operand")
(match_operand:V_32 1 "nonimmediate_operand"))]
- "TARGET_SSE2"
+ ""
{
ix86_expand_vector_move (mode, operands);
DONE;
@@ -261,8 +261,7 @@
"=r ,m ,v,v,v,m,r,v")
(match_operand:V_32 1 "general_operand"
"rmC,rC,C,v,m,v,v,r"))]
- "TARGET_SSE2
- && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
+ "!(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
switch (get_attr_type (insn))
{
@@ -321,29 +320,19 @@
(define_insn "*push2_rex64"
[(set (match_operand:V_32 0 "push_operand" "=X,X")
(match_operand:V_32 1 "nonmemory_no_elim_operand" "rC,*v"))]
- "TARGET_SSE2 && TARGET_64BIT"
+ "TARGET_64BIT"
"@
push{q}\t%q1
#"
[(set_attr "type" "push,multi")
(set_attr "mode" "DI")])
-(define_insn "*push2"
- [(set (match_operand:V_32 0 "push_operand" "=<,<")
- (match_operand:V_32 1 "general_no_elim_operand" "rC*m,*v"))]
- "TARGET_SSE2 && !TARGET_64BIT"
- "@
- push{l}\t%1
- #"
- [(set_attr "type" "push,multi")
- (set_attr "mode" "SI")])
-
(define_split
[(set (match_operand:V_32 0 "push_operand")
(match_operand:V_32 1 "sse_reg_operand"))]
- "TARGET_SSE2 && reload_completed"
+ "TARGET_64BIT && TARGET_SSE && reload_completed"
[(set (reg:P SP_REG) (plus:P (reg:P SP_REG) (match_dup 2)))
-(set (match_dup 0) (match_dup 1))]
+ (set (match_dup 0) (match_dup 1))]
{
operands[2] = GEN_INT (-PUSH_ROUNDING (GET_MODE_SIZE (mode)));
/* Preserve memory attributes. */
@@ -353,7 +342,7 @@
(define_expand "movmisalign"
[(set (match_operand:V_32 0 "nonimmediate_operand")
(match_operand:V_32 1 "nonimmediate_operand"))]
- "TARGET_SSE2"
+ ""
{
ix86_expand_vector_move (mode, operands);
DONE;
diff --git a/gcc/testsuite/gcc.target/i386/pr103894.c
b/gcc/testsuite/gcc.target/i386/pr103894.c
new file mode 100644
index 000..69c81046930
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr103894.c
@@ -0,0 +1,13 @@
+/* PR target/103894 */
+/* { dg-do compile } */
+/* { dg-options "-msse -mno-sse2" } */
+
+typedef unsigned char __attribute__((__vector_size__ (32))) V;
+typedef unsigned char __attribute__((__vector_size__ (2))) W;
+
+V v;
+
+W foo (W w)
+{
+ return __builtin_shufflevector (v, w, 3, 4);
+}
[power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O
On Mon, Jan 03, 2022 at 06:03:41PM +0100, Thomas Koenig wrote:
> On 03.01.22 17:26, Jakub Jelinek wrote:
>
> > so we could similarly have something like:
> > #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > && __SIZEOF_LONG_DOUBLE__ == 16)
> > _gfortran_transfer_complex128;
> > _gfortran_transfer_complex128_write;
> > #endif
> > ...
> > #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > && __SIZEOF_LONG_DOUBLE__ == 16)
> > _gfortran_transfer_real128;
> > _gfortran_transfer_real128_write;
> > #endif
> > ...
> > #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ &&
> > __SIZEOF_LONG_DOUBLE__ == 16
> >_gfortran_transfer_complex128;
> >_gfortran_transfer_complex128_write;
> >_gfortran_transfer_real128;
> >_gfortran_transfer_real128_write;
> > #endif
>
> That would also work for me.
>
> > or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable
> > includes that only define macros and not actual C code).
>
> With my most recent commit, HAVE_GFC_REAL_17 can now be found in
> kinds.inc if all of the macros above are defined, that should
> be suitable.
>
> I found that __powerpc64__ is not defined when compiling *.F90 files
> (which is why I added them by hand). Not sure how the preprocessor is
> invoked on gfortran.map, but if things don't work, this could be
> related :-)
>
> So, it's OK either way with me. What do others think?
Here is an updated patch that does that (and now includes also the
gcc/fortran part, since it makes no sense to split the two).
I've run make check-fortran both normally and with
RUNTESTFLAGS='--target_board=unix\{-mabi=ieeelongdouble\}'
The former has:
FAIL: gfortran.dg/reshape_shape_2.f90 -O (internal compiler error)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for errors, line 6)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for excess errors)
FAIL: gfortran.dg/vector_subscript_1.f90 -O1 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O2 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -g execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -Os execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O0 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O1 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O2 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O3 -g execution test
FAIL: gfortran.dg/ieee/large_2.f90 -Os execution test
and the latter has:
FAIL: gfortran.dg/dec_math.f90 -O0 execution test
FAIL: gfortran.dg/dec_math.f90 -O1 execution test
FAIL: gfortran.dg/dec_math.f90 -O2 execution test
FAIL: gfortran.dg/dec_math.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/dec_math.f90 -O3 -g execution test
FAIL: gfortran.dg/dec_math.f90 -Os execution test
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_pf.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O1 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_pf.f90 -O2 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_en_rd.f90 -O3 -g 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_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_en_rd.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_g0_7.f08 -Os execution test
FAIL: gfortran.dg/fmt_en_rn.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_e
[PATCH] PR fortran/101762 - ICE on non-constant pointer initialization targets
Dear all,
the initial-data-target for a pointer initialization can be either
NULL() or a non-constant target. In the latter case subscripts of
the target specification (or substring starting and ending points)
must be constant expressions. The patch adds corresponding checks.
I have verified that current Intel and Cray compilers generate similar
errors for the testcase.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From db7562ef764564560fcc59c192df5c00269382ac Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 3 Jan 2022 20:31:10 +0100
Subject: [PATCH] Fortran: reject invalid non-constant pointer initialization
targets
gcc/fortran/ChangeLog:
PR fortran/101762
* decl.c (match_pointer_init): Check that subscripts and substring
indices in specifications of pointer initialization targets are
constant expressions.
gcc/testsuite/ChangeLog:
PR fortran/101762
* gfortran.dg/pr101762.f90: New test.
---
gcc/fortran/decl.c | 34 ++
gcc/testsuite/gfortran.dg/pr101762.f90 | 23 +
2 files changed, 57 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr101762.f90
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 4e510cc72ef..4a52a908ac8 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2525,6 +2525,40 @@ match_pointer_init (gfc_expr **init, int procptr)
"initialization at %C"))
return MATCH_ERROR;
+ gfc_ref *ref = (*init)->ref;
+ for (; ref; ref = ref->next)
+{
+ switch (ref->type)
+ {
+ case REF_ARRAY:
+ for (int n = 0; n < ref->u.ar.dimen; n++)
+ if (!gfc_is_constant_expr (ref->u.ar.start[n])
+ || !gfc_is_constant_expr (ref->u.ar.end[n])
+ || !gfc_is_constant_expr (ref->u.ar.stride[n]))
+ {
+ gfc_error ("Every subscript of target specification "
+ "at %L must be a constant expression",
+ &ref->u.ar.where);
+ return MATCH_ERROR;
+ }
+ break;
+
+ case REF_SUBSTRING:
+ if (!gfc_is_constant_expr (ref->u.ss.start)
+ || !gfc_is_constant_expr (ref->u.ss.end))
+ {
+ gfc_error ("Substring starting and ending points of target "
+ "specification at %L must be constant expressions",
+ &ref->u.ss.start->where);
+ return MATCH_ERROR;
+ }
+ break;
+
+ default:
+ break;
+ }
+}
+
return MATCH_YES;
}
diff --git a/gcc/testsuite/gfortran.dg/pr101762.f90 b/gcc/testsuite/gfortran.dg/pr101762.f90
new file mode 100644
index 000..14bcee9ec00
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr101762.f90
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! PR fortran/101762 - ICE on non-constant pointer initialization targets
+! Contributed by G.Steinmetz
+
+program p
+ integer, target :: a(3) = [7, 8, 9]
+ integer, pointer :: x=> a(3)
+ integer, pointer :: y=> a(n()) ! { dg-error "constant expression" }
+ integer, pointer :: z=> a(:n()) ! { dg-error "constant expression" }
+ character(7), target :: c= "abcdefg"
+ character(3), pointer :: c0 => c(2:4)
+ character(3), pointer :: c1 => c(m():) ! { dg-error "constant expression" }
+ character(3), pointer :: c2 => c(:m()) ! { dg-error "constant expression" }
+ print *, x
+contains
+ pure integer function k ()
+k = 2
+ end function k
+ subroutine s ()
+integer, pointer :: yy => a(k()) ! { dg-error "constant expression" }
+print *, yy
+ end subroutine s
+end
--
2.31.1
Re: [PATCH] c++: Avoid narrowing in make_char_string_pack
On Sat, Dec 18, 2021 at 07:43:55PM -0500, Eric Gallager wrote:
> On Fri, Dec 17, 2021 at 5:59 PM Marek Polacek via Gcc-patches
> wrote:
> >
> > This fixes
> >
> > gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str +
> > ((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarrowing]
> > 4618 | unsigned char s[3] = { '\'', str[i], '\'' };
> > |~^
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
>
> Hi, I thought that GCC was built with -Wno-narrowing; has that changed
> since I last checked?
No, I noticed that warning when compiling parser.i manually.
Here's a thread I found which led to -Wno-narrowing:
.
> I'd support a move to officially switch from
> disabling -Wnarrowing to enabling it instead if that's possible and
> hasn't been done yet.
I don't know if the issues above have been fixed. Maybe they have; it's
been a while...
> Also the '(char)(*(str + ((sizetype)i)))' looks
> like some implementation details leaking; is there a bug against
> -Wnarrowing (or the diagnostics system in general) open about that?
Dunno.
> > gcc/cp/ChangeLog:
> >
> > * parser.c (make_char_string_pack): Add a cast to const unsigned
> > char *.
> > ---
> > gcc/cp/parser.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> > index 44eed7ea638..56232ab029f 100644
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -4607,7 +4607,8 @@ make_char_string_pack (tree value)
> > {
> >tree charvec;
> >tree argpack = make_node (NONTYPE_ARGUMENT_PACK);
> > - const char *str = TREE_STRING_POINTER (value);
> > + const unsigned char *str
> > += (const unsigned char *) TREE_STRING_POINTER (value);
> >int i, len = TREE_STRING_LENGTH (value) - 1;
> >tree argvec = make_tree_vec (1);
> >
> >
> > base-commit: d7ca2a79b82c6500ead6ab983d14c609e2124eee
> > --
> > 2.33.1
> >
>
Marek
Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
On 1/3/22 08:43, Indu Bhagat wrote:
On 12/30/21 8:59 AM, Palmer Dabbelt wrote:
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Format) is the metadata format which encodes the debug
info related to BPF program/map, more details on:
https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target support.
Is the goal here to get the variable "d" out of the small data section
and into the standard data section? It's not clear from your
description .
Neither an ACK nor a NAK at this point. I need to understand better
what you're trying to accomplish.
IIUC that's what this is doing, though the commit message isn't clear at
all. That saind, it might be better to do something like
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index dbb236bbda1..c0ad77d40aa 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -22,9 +22,9 @@
/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset"
7 } } */
/* Check that strings for each DATASEC have been added to the BTF
string table. */
-/* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
int a;
long long b;
as whether specific symbols end up in .data or .sdata is really just an
optimization and either should be sufficiently correct.
Yes, I would agree that the test case can be adapted as mentioned. The
purpose of the test case is to check that BTF is correctly generated for
whatever section the symbols end up in.
Adding David Faust in CC for ACK.
Thanks Indu
I concur. This looks like a good improvement to me. If any of the
existing target-specific options in the test could eventually be dropped
as a result, then all the better IMO.
David
Thanks
Indu
IIRC some targets have other flavors of these, PPC's .sdata2 comes to
mind. Not sure if we'd need that to drop their -msdata=none flag.
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
On 03.01.22 17:26, Jakub Jelinek wrote: so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif ... #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif That would also work for me. or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable includes that only define macros and not actual C code). With my most recent commit, HAVE_GFC_REAL_17 can now be found in kinds.inc if all of the macros above are defined, that should be suitable. I found that __powerpc64__ is not defined when compiling *.F90 files (which is why I added them by hand). Not sure how the preprocessor is invoked on gfortran.map, but if things don't work, this could be related :-) So, it's OK either way with me. What do others think? Best regards Thomas
Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
On 12/30/2021 9:59 AM, Palmer Dabbelt wrote:
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Format) is the metadata format which encodes the debug
info related to BPF program/map, more details on:
https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target support.
Is the goal here to get the variable "d" out of the small data section
and into the standard data section? It's not clear from your
description .
Neither an ACK nor a NAK at this point. I need to understand better
what you're trying to accomplish.
IIUC that's what this is doing, though the commit message isn't clear
at all. That saind, it might be better to do something like
It might. My only real hesitation would be if where was some wonky BTF
dependency on having the symbols in the normal sections. But I'd
consider that unlikey.
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index dbb236bbda1..c0ad77d40aa 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -22,9 +22,9 @@
/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset"
7 } } */
/* Check that strings for each DATASEC have been added to the
BTF string table. */
-/* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
int a;
long long b;
as whether specific symbols end up in .data or .sdata is really just
an optimization and either should be sufficiently correct.
Probably missing some escapes in your variant (the brackets). Jiawei,
could you try Palmer suggestion to verify it works for you?
IIRC some targets have other flavors of these, PPC's .sdata2 comes to
mind. Not sure if we'd need that to drop their -msdata=none flag.
I'd expect them to continue to work as-is. We could potentially drop
those flags as a separate patch after suitable testing.
jeff
Re: [PING^4 PATCH v4 2/3] rs6000: Support SSE4.1 "round" intrinsics
On Thu, Nov 18, 2021 at 08:24:52PM -0600, Paul A. Clarke via Gcc-patches wrote: > On Mon, Nov 08, 2021 at 11:40:42AM -0600, Paul A. Clarke via Gcc-patches > wrote: > > On Tue, Oct 26, 2021 at 03:00:11PM -0500, Paul A. Clarke via Gcc-patches > > wrote: > > > Patches 1/3 and 3/3 have been committed. > > > This is only a ping for 2/3. > > > > Gentle re-ping. > > Gentle re-re-ping. and once more. :-) > > > On Mon, Oct 18, 2021 at 08:15:11PM -0500, Paul A. Clarke via Gcc-patches > > > wrote: > > > > Suppress exceptions (when specified), by saving, manipulating, and > > > > restoring the FPSCR. Similarly, save, set, and restore the > > > > floating-point > > > > rounding mode when required. > > > > > > > > No attempt is made to optimize writing the FPSCR (by checking if the new > > > > value would be the same), other than using lighter weight instructions > > > > when possible. Note that explicit instruction scheduling "barriers" are > > > > added to prevent floating-point computations from being moved before or > > > > after the explicit FPSCR manipulations. (That these are required has > > > > been reported as an issue in GCC: PR102783.) > > > > > > > > The scalar versions naively use the parallel versions to compute the > > > > single scalar result and then construct the remainder of the result. > > > > > > > > Of minor note, the values of _MM_FROUND_TO_NEG_INF and > > > > _MM_FROUND_TO_ZERO > > > > are swapped from the corresponding values on x86 so as to match the > > > > corresponding rounding mode values in the Power ISA. > > > > > > > > Move implementations of _mm_ceil* and _mm_floor* into _mm_round*, and > > > > convert _mm_ceil* and _mm_floor* into macros. This matches the current > > > > analogous implementations in config/i386/smmintrin.h. > > > > > > > > Function signatures match the analogous functions in > > > > config/i386/smmintrin.h. > > > > > > > > Add tests for _mm_round_pd, _mm_round_ps, _mm_round_sd, _mm_round_ss, > > > > modeled after the very similar "floor" and "ceil" tests. > > > > > > > > Include basic tests, plus tests at the boundaries for floating-point > > > > representation, positive and negative, test all of the parameterized > > > > rounding modes as well as the C99 rounding modes and interactions > > > > between the two. > > > > > > > > Exceptions are not explicitly tested. > > > > > > > > 2021-10-18 Paul A. Clarke > > > > > > > > gcc > > > > * config/rs6000/smmintrin.h (_mm_round_pd, _mm_round_ps, > > > > _mm_round_sd, _mm_round_ss, _MM_FROUND_TO_NEAREST_INT, > > > > _MM_FROUND_TO_ZERO, _MM_FROUND_TO_POS_INF, > > > > _MM_FROUND_TO_NEG_INF, > > > > _MM_FROUND_CUR_DIRECTION, _MM_FROUND_RAISE_EXC, > > > > _MM_FROUND_NO_EXC, > > > > _MM_FROUND_NINT, _MM_FROUND_FLOOR, _MM_FROUND_CEIL, > > > > _MM_FROUND_TRUNC, > > > > _MM_FROUND_RINT, _MM_FROUND_NEARBYINT): New. > > > > * config/rs6000/smmintrin.h (_mm_ceil_pd, _mm_ceil_ps, > > > > _mm_ceil_sd, > > > > _mm_ceil_ss, _mm_floor_pd, _mm_floor_ps, _mm_floor_sd, > > > > _mm_floor_ss): > > > > Convert from function to macro. > > > > > > > > gcc/testsuite > > > > * gcc.target/powerpc/sse4_1-round3.h: New. > > > > * gcc.target/powerpc/sse4_1-roundpd.c: New. > > > > * gcc.target/powerpc/sse4_1-roundps.c: New. > > > > * gcc.target/powerpc/sse4_1-roundsd.c: New. > > > > * gcc.target/powerpc/sse4_1-roundss.c: New. > > > > --- > > > > gcc/config/rs6000/smmintrin.h | 292 ++ > > > > .../gcc.target/powerpc/sse4_1-round3.h| 81 + > > > > .../gcc.target/powerpc/sse4_1-roundpd.c | 143 + > > > > .../gcc.target/powerpc/sse4_1-roundps.c | 98 ++ > > > > .../gcc.target/powerpc/sse4_1-roundsd.c | 256 +++ > > > > .../gcc.target/powerpc/sse4_1-roundss.c | 208 + > > > > 6 files changed, 1014 insertions(+), 64 deletions(-) > > > > create mode 100644 gcc/testsuite/gcc.target/powerpc/sse4_1-round3.h > > > > create mode 100644 gcc/testsuite/gcc.target/powerpc/sse4_1-roundpd.c > > > > create mode 100644 gcc/testsuite/gcc.target/powerpc/sse4_1-roundps.c > > > > create mode 100644 gcc/testsuite/gcc.target/powerpc/sse4_1-roundsd.c > > > > create mode 100644 gcc/testsuite/gcc.target/powerpc/sse4_1-roundss.c > > > > > > > > diff --git a/gcc/config/rs6000/smmintrin.h > > > > b/gcc/config/rs6000/smmintrin.h > > > > index 90ce03d22709..6bb03e6e20ac 100644 > > > > --- a/gcc/config/rs6000/smmintrin.h > > > > +++ b/gcc/config/rs6000/smmintrin.h > > > > @@ -42,6 +42,234 @@ > > > > #include > > > > #include > > > > > > > > +/* Rounding mode macros. */ > > > > +#define _MM_FROUND_TO_NEAREST_INT 0x00 > > > > +#define _MM_FROUND_TO_ZERO 0x01 > > > > +#define _MM_FROUND_TO_POS_INF 0x02 > > > > +#define _MM_FROUND_TO_NEG_INF 0x03 > > > > +#define _MM_FROUND_CUR_DIRECTION0x0
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
Hi Jakub,
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g._gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
My personal preference would be the ieee128 variant, it would be cleaner
that way, but I have no strong opinion either way.
So, that variant is OK from my side, but maybe you could wait for
a day or so for anybody else to chime in.
Best regards
Thomas
Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
On 12/30/21 8:59 AM, Palmer Dabbelt wrote:
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Format) is the metadata format which encodes the debug
info related to BPF program/map, more details on:
https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target support.
Is the goal here to get the variable "d" out of the small data section
and into the standard data section? It's not clear from your
description .
Neither an ACK nor a NAK at this point. I need to understand better
what you're trying to accomplish.
IIUC that's what this is doing, though the commit message isn't clear at
all. That saind, it might be better to do something like
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index dbb236bbda1..c0ad77d40aa 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -22,9 +22,9 @@
/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset"
7 } } */
/* Check that strings for each DATASEC have been added to the BTF
string table. */
-/* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
int a;
long long b;
as whether specific symbols end up in .data or .sdata is really just an
optimization and either should be sufficiently correct.
Yes, I would agree that the test case can be adapted as mentioned. The
purpose of the test case is to check that BTF is correctly generated for
whatever section the symbols end up in.
Adding David Faust in CC for ACK.
Thanks
Indu
IIRC some targets have other flavors of these, PPC's .sdata2 comes to
mind. Not sure if we'd need that to drop their -msdata=none flag.
Re: [PATCH RFA] tree-pretty-print: still indent unhandled codes
On 1/2/2022 11:08 AM, Jason Merrill via Gcc-patches wrote: It would be nice to handle language-specific codes in the tree pretty-printer, but until then we can at least indent them appropriately. Tested x86_64-pc-linux-gnu, ok for trunk? gcc/ChangeLog: * tree-pretty-print.c (do_niy): Add spc parameter. (NIY): Pass it. (print_call_name): Add spc local variable. OK jeff
Re: [RFC PATCH] tree-ssa-sink: do not sink to in front of setjmp
On Mon, 3 Jan 2022, Richard Biener wrote: > > @@ -5674,6 +5675,14 @@ gimple_verify_flow_info (void) > >err = 1; > > } > > > > + if (prev_stmt && stmt_starts_bb_p (stmt, prev_stmt)) > > stmt_starts_bb_p is really a helper used during CFG build, I'd rather > test explicitely for a GIMPLE call with ECF_RETURNS_TWICE, or maybe, > verify that iff a block has abnormal predecessors it starts with such > a call (because IIRC we in some cases elide abnormal edges and then > it's OK to move "down" the calls). So yes, if a block has abnormal preds > it should start with a ECF_RETURNS_TWICE call, I think we cannot > verify the reverse reliably - abnormal edges cannot easily be re-built > in late stages (it's a bug that we do so during RTL expansion). Thanks, I could rewrite the patch along those lines, but I'm not sure where this is going: the ~100 extra FAILs will still be there. What would the next steps be for this patch and the initial tree-ssa-sink patch? Alexander
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
On Mon, Jan 03, 2022 at 04:36:21PM +0100, Jakub Jelinek via Gcc-patches wrote: > The following patch adds the library side of -mabi=ieeelongdouble > I/O support. > > There is one issue to be resolved though, for the sake of libgfortran.a > built on an older powerpc64le-linux system (glibc older than 2.32) and > then deployed on glibc 2.32 or later, I believe we want to use > _gfortran_transfer_real128_write etc. APIs so that we force in libquadmath > in that case. The following patch does that, but unfortunately it means > that right now those >512: 001a31d056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_real128@@GFORTRAN_8 [: 8] >920: 001a321056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_real128_write@@GFORTRAN_8 [: 8] >487: 001a329056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_complex128_write@@GFORTRAN_8[: 8] >574: 001a325056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_complex128@@GFORTRAN_8 [: 8] > symbols. But those symbols weren't exported on powerpc64le-linux in > GCC 8, 9, 10 or 11, so they shouldn't be exported @@GFORTRAN_8, but > @@GFORTRAN_12. > > So, either we'd need to add e.g. preprocessing support for gfortran.map Note, an example of preprocessed version file is e.g. libgomp, in the Makefile it does: # -Wc is only a libtool option. comma = , PREPROCESS = $(subst -Wc$(comma), , $(COMPILE)) -E libgomp.ver: $(top_srcdir)/libgomp.map $(EGREP) -v '#(#| |$$)' $< | \ $(PREPROCESS) -P -include config.h - > $@ || (rm -f $@ ; exit 1) and in libgomp.map it has both: #ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT # If the assembler used lacks the .symver directive or the linker # doesn't support GNU symbol versioning, we have the same symbol in # two versions, which Sun ld chokes on. omp_init_lock; ... #endif so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif ... #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable includes that only define macros and not actual C code). Jakub
Re: [power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath
On 03.01.22 16:24, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK. Thanks! Best regards Thomas
[power-ieee128] fortran: trans-io.c side of -mabi=ieeelongdouble I/O support
Hi!
Here is the compiler side of those changes, but depends of course
on the decision what to do with those *real128* and *complex128* symbols.
With all the 4 patches e.g. print *, var for real(kind=16) var; var = 1.0;
works both with -mabi=ibmlongdouble and -mabi=ieeelongdouble.
2022-01-03 Jakub Jelinek
* trans-io.c (transfer_namelist_element): Use gfc_type_abi_kind,
formatting fixes.
(transfer_expr): Use gfc_type_abi_kind, use *REAL128* APIs even
for abi_kind == 17.
--- gcc/fortran/trans-io.c.jj 2021-12-31 11:00:15.052190585 +
+++ gcc/fortran/trans-io.c 2022-01-03 14:20:55.238159269 +
@@ -1765,18 +1765,17 @@ transfer_namelist_element (stmtblock_t *
else
tmp = build_int_cst (gfc_charlen_type_node, 0);
+ int abi_kind = gfc_type_abi_kind (ts);
if (dtio_proc == null_pointer_node)
-tmp = build_call_expr_loc (input_location,
- iocall[IOCALL_SET_NML_VAL], 6,
- dt_parm_addr, addr_expr, string,
- build_int_cst (gfc_int4_type_node, ts->kind),
- tmp, dtype);
+tmp = build_call_expr_loc (input_location, iocall[IOCALL_SET_NML_VAL], 6,
+ dt_parm_addr, addr_expr, string,
+ build_int_cst (gfc_int4_type_node, abi_kind),
+ tmp, dtype);
else
-tmp = build_call_expr_loc (input_location,
- iocall[IOCALL_SET_NML_DTIO_VAL], 8,
- dt_parm_addr, addr_expr, string,
- build_int_cst (gfc_int4_type_node, ts->kind),
- tmp, dtype, dtio_proc, vtable);
+tmp = build_call_expr_loc (input_location, iocall[IOCALL_SET_NML_DTIO_VAL],
+ 8, dt_parm_addr, addr_expr, string,
+ build_int_cst (gfc_int4_type_node, abi_kind),
+ tmp, dtype, dtio_proc, vtable);
gfc_add_expr_to_block (block, tmp);
/* If the object is an array, transfer rank times:
@@ -2298,7 +2297,7 @@ transfer_expr (gfc_se * se, gfc_typespec
ts->kind = gfc_index_integer_kind;
}
- kind = ts->kind;
+ kind = gfc_type_abi_kind (ts);
function = NULL;
arg2 = NULL;
arg3 = NULL;
@@ -2318,14 +2317,14 @@ transfer_expr (gfc_se * se, gfc_typespec
arg2 = build_int_cst (integer_type_node, kind);
if (last_dt == READ)
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_REAL128];
else
function = iocall[IOCALL_X_REAL];
}
else
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_REAL128_WRITE];
else
function = iocall[IOCALL_X_REAL_WRITE];
@@ -2337,14 +2336,14 @@ transfer_expr (gfc_se * se, gfc_typespec
arg2 = build_int_cst (integer_type_node, kind);
if (last_dt == READ)
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_COMPLEX128];
else
function = iocall[IOCALL_X_COMPLEX];
}
else
{
- if (gfc_real16_is_float128 && ts->kind == 16)
+ if ((gfc_real16_is_float128 && kind == 16) || kind == 17)
function = iocall[IOCALL_X_COMPLEX128_WRITE];
else
function = iocall[IOCALL_X_COMPLEX_WRITE];
Jakub
[power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
Hi!
The following patch adds the library side of -mabi=ieeelongdouble
I/O support.
There is one issue to be resolved though, for the sake of libgfortran.a
built on an older powerpc64le-linux system (glibc older than 2.32) and
then deployed on glibc 2.32 or later, I believe we want to use
_gfortran_transfer_real128_write etc. APIs so that we force in libquadmath
in that case. The following patch does that, but unfortunately it means
that right now those
512: 001a31d056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_real128@@GFORTRAN_8 [: 8]
920: 001a321056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_real128_write@@GFORTRAN_8 [: 8]
487: 001a329056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_complex128_write@@GFORTRAN_8 [: 8]
574: 001a325056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_complex128@@GFORTRAN_8[: 8]
symbols. But those symbols weren't exported on powerpc64le-linux in
GCC 8, 9, 10 or 11, so they shouldn't be exported @@GFORTRAN_8, but
@@GFORTRAN_12.
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g. _gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
2022-01-03 Jakub Jelinek
* libgfortran.h (__acoshieee128, __acosieee128, __asinhieee128,
__asinieee128, __atan2ieee128, __atanhieee128, __atanieee128,
__coshieee128, __cosieee128, __erfieee128, __expieee128,
__fabsieee128, __jnieee128, __log10ieee128, __logieee128,
__powieee128, __sinhieee128, __sinieee128, __sqrtieee128,
__tanhieee128, __tanieee128, __ynieee128): Formatting fixes.
(__strtoieee128, __snprintfieee128): Declare.
* io/io.h (default_width_for_float, default_precision_for_float):
Handle kind == 17.
* io/size_from_kind.c (size_from_real_kind, size_from_complex_kind):
Likewise.
* io/read.c (set_integer, si_max, convert_real, convert_infnan,
read_f): Likewise.
* io/write.c (extract_uint, size_from_kind, set_fnode_default):
Likewise.
* io/write_float.def (DTOA2Q, FDTOA2Q): Define for HAVE_GFC_REAL_17.
(determine_en_precision, get_float_string): Handle kind == 17.
* io/transfer128.c: Use also for HAVE_GFC_REAL_17, but don't drag in
libquadmath if POWER_IEEE128.
--- libgfortran/libgfortran.h.jj2021-12-31 11:45:06.121158716 +
+++ libgfortran/libgfortran.h 2022-01-03 14:32:45.063730903 +
@@ -1936,28 +1936,54 @@ internal_proto(cshift1_16_c17);
/* Prototypes for the POWER __ieee128 functions. */
#ifdef POWER_IEEE128
-extern __float128 __acoshieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __acosieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __asinhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __asinieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __atan2ieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __atanhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __atanieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __coshieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __cosieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __erfieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __expieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __fabsieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __jnieee128 (int, __float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __log10ieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __logieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __powieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __sinhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __sinieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __sqrtieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __tanhieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __tanieee128 (__float128) __attribute__ ((__nothrow__,
__leaf__));
-extern __float128 __ynieee128 (int , __float128) __attribute__ ((__nothrow__,
__leaf__));
+extern __float128 __acoshieee128 (__float128)
+ __attribute__ ((__nothrow__, __leaf__));
+extern __float128 __acosieee128 (__float128)
+ __attribute__ ((__nothrow__, __leaf__));
+extern __float128 __asinhieee128 (__
Re: [PATCH] c++: dependent bases and 'this' availability [PR103831]
On Tue, Dec 28, 2021 at 10:08 AM Patrick Palka wrote:
>
> Here during satisfaction of B's associated 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 bases, and so the
> any_dependent_bases_p check within build_new_method_call causes us to
> avoid rejecting the call.
>
> This patch fixes this by refining the any_dependent_bases_p check within
> build_new_method_call: dependent bases can't make a difference for
> resolving the implicit object parameter if we're in a conext where
> 'this' is unavailable, so let's check current_class_ptr too.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk and perhaps 11? The first testcase exhibits a regression
> introduced by r12-1937.
D'oh, never mind about the backport request since this is at worst a
12 regression.
>
> 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.
> ---
> gcc/cp/call.c | 2 +-
> gcc/testsuite/g++.dg/cpp2a/concepts-class3.C | 12
> .../g++.dg/template/non-dependent18.C | 19 +++
> 3 files changed, 32 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-class3.C
> create mode 100644 gcc/testsuite/g++.dg/template/non-dependent18.C
>
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index bee367f57d7..3da9e7a6284 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -11098,7 +11098,7 @@ build_new_method_call (tree instance, tree fns,
> vec **args,
> we know we really need it. */
> cand->first_arg = instance;
> }
> - else if (any_dependent_bases_p ())
> + else if (current_class_ptr && any_dependent_bases_p ())
> /* We can't tell until instantiation time whether we can use
>*this as the implicit object argument. */;
> else
> diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-class3.C
> b/gcc/testsuite/g++.dg/cpp2a/concepts-class3.C
> new file mode 100644
> index 000..68b50b71278
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-class3.C
> @@ -0,0 +1,12 @@
> +// PR c++/103831
> +// { dg-do compile { target c++20 } }
> +
> +struct A {
> + constexpr int size() { return 42; } // non-static
> +};
> +
> +template
> + requires (T::size() == 42) // { dg-error "without object" }
> +struct B : T { };
> +
> +template struct B; // { dg-error "constraint" }
> diff --git a/gcc/testsuite/g++.dg/template/non-dependent18.C
> b/gcc/testsuite/g++.dg/template/non-dependent18.C
> new file mode 100644
> index 000..7fe623d497f
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/non-dependent18.C
> @@ -0,0 +1,19 @@
> +// PR c++/103831
> +// { dg-do compile { target c++11 } }
> +
> +struct A {
> + constexpr int size() { return 42; } // non-static
> +};
> +
> +template
> +struct B : T {
> + static_assert(A::size() == 42); // { dg-error "without object" }
> +
> + static int f() {
> +static_assert(A::size() == 42, ""); // { dg-error "without object" }
> +return A::size(); // { dg-error "without object" }
> + }
> +
> + int n = A::size();
> + static const int m = A::size(); // { dg-error "without object" }
> +};
> --
> 2.34.1.390.g2ae0a9cb82
>
Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran
Hi Jakub, On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote: The idea behind this is that libstdc++ is written such that it can handle both IBM extended and IEEE quad long double, so its object files are compatible with both. Now tested on powerpc64le-linux (and together with the regenerated file), ok for power-ieee128? Since you posted it, I had already tested this and included it into the patch I pushed a couple of minutes ago. So, OK, and I already pushed it :-) Thanks a lot for your help in this! Best regards Thomas
Re: [PATCH] c++: CTAD within alias template [PR91911]
On Wed, 22 Dec 2021, Jason Merrill wrote:
> On 12/21/21 14:08, Patrick Palka wrote:
> > On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote:
> > >
> > > On Wed, Jun 30, 2021 at 4:23 PM Jason Merrill wrote:
> > > >
> > > > On 6/30/21 4:18 PM, Patrick Palka wrote:
> > > > > On Wed, Jun 30, 2021 at 3:51 PM Jason Merrill
> > > > > wrote:
> > > > > >
> > > > > > On 6/30/21 11:58 AM, Patrick Palka wrote:
> > > > > > > On Wed, 30 Jun 2021, Patrick Palka wrote:
> > > > > > >
> > > > > > > > On Fri, 25 Jun 2021, Jason Merrill wrote:
> > > > > > > >
> > > > > > > > > On 6/25/21 1:11 PM, Patrick Palka wrote:
> > > > > > > > > > On Fri, 25 Jun 2021, Jason Merrill wrote:
> > > > > > > > > >
> > > > > > > > > > > On 6/24/21 4:45 PM, Patrick Palka wrote:
> > > > > > > > > > > > In the first testcase below, during parsing of the alias
> > > > > > > > > > > > template
> > > > > > > > > > > > ConstSpanType, transparency of alias template
> > > > > > > > > > > > specializations means we
> > > > > > > > > > > > replace SpanType with SpanType's substituted
> > > > > > > > > > > > definition. But this
> > > > > > > > > > > > substitution lowers the level of the CTAD placeholder
> > > > > > > > > > > > for span(T()) from
> > > > > > > > > > > > 2 to 1, and so the later instantiantion of
> > > > > > > > > > > > ConstSpanType
> > > > > > > > > > > > erroneously substitutes this CTAD placeholder with the
> > > > > > > > > > > > template argument
> > > > > > > > > > > > at level 1 index 0, i.e. with int, before we get a
> > > > > > > > > > > > chance to perform the
> > > > > > > > > > > > CTAD.
> > > > > > > > > > > >
> > > > > > > > > > > > In light of this, it seems we should avoid level
> > > > > > > > > > > > lowering when
> > > > > > > > > > > > substituting through through the type-id of a dependent
> > > > > > > > > > > > alias template
> > > > > > > > > > > > specialization. To that end this patch makes
> > > > > > > > > > > > lookup_template_class_1
> > > > > > > > > > > > pass tf_partial to tsubst in this situation.
> > > > > > > > > > >
> > > > > > > > > > > This makes sense, but what happens if SpanType is a member
> > > > > > > > > > > template, so
> > > > > > > > > > > that
> > > > > > > > > > > the levels of it and ConstSpanType don't match? Or the
> > > > > > > > > > > other way around?
> > > > > > > > > >
> > > > > > > > > > If SpanType is a member template of say the class
> > > > > > > > > > template A (and
> > > > > > > > > > thus its level is greater than ConstSpanType):
> > > > > > > > > >
> > > > > > > > > > template
> > > > > > > > > > struct A {
> > > > > > > > > > template
> > > > > > > > > > using SpanType = decltype(span(T()));
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > template
> > > > > > > > > > using ConstSpanType = span > > > > > > > > > A::SpanType::value_type>;
> > > > > > > > > >
> > > > > > > > > > using type = ConstSpanType;
> > > > > > > > > >
> > > > > > > > > > then this case luckily works even without the patch because
> > > > > > > > > > instantiate_class_template now reuses the specialization
> > > > > > > > > > A::SpanType
> > > > > > > > > > that was formed earlier during instantiation of A,
> > > > > > > > > > where we
> > > > > > > > > > substitute only a single level of template arguments, so the
> > > > > > > > > > level of
> > > > > > > > > > the CTAD placeholder inside the defining-type-id of this
> > > > > > > > > > specialization
> > > > > > > > > > dropped from 3 to 2, so still more than the level of
> > > > > > > > > > ConstSpanType.
> > > > > > > > > >
> > > > > > > > > > This luck is short-lived though, because if we replace
> > > > > > > > > > A::SpanType with say A::SpanType then
> > > > > > > > > > the testcase
> > > > > > > > > > breaks again (without the patch) because we no longer can
> > > > > > > > > > reuse that
> > > > > > > > > > specialization, so we instead form it on the spot by
> > > > > > > > > > substituting two
> > > > > > > > > > levels of template arguments (U=int,T=T) into the
> > > > > > > > > > defining-type-id,
> > > > > > > > > > causing the level of the placeholder to drop to 1. I think
> > > > > > > > > > the patch
> > > > > > > > > > causes its level to remain 3 (though I guess it should
> > > > > > > > > > really be 2).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > For the other way around, if ConstSpanType is a member
> > > > > > > > > > template of
> > > > > > > > > > say the class template B (and thus its level is greater
> > > > > > > > > > than
> > > > > > > > > > SpanType):
> > > > > > > > > >
> > > > > > > > > > template
> > > > > > > > > > using SpanType = decltype(span(T()));
> > > > > > > > > >
> > > > > > > > > > template
> > > > > > > > > > struct B {
> > > > > > > > > > template
> > > > > > > > > > using ConstSpanType = span > > > > > > > > > SpanType::value_type>;
> > > > > > > > > >
[power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath
Hi!
Testing found that we also need libquadmath to be built with
-mno-gnu-attribute, otherwise -mabi=ieeelongdouble programs don't link.
Ok for power-ieee128?
2022-01-03 Jakub Jelinek
* configure.ac: Set XCFLAGS to -mno-gnu-attribute on
powerpc64le*-linux*.
* configure: Regenerated.
--- libquadmath/configure.ac
+++ libquadmath/configure.ac
@@ -352,6 +352,19 @@ fi
# Add CET specific flags if CET is enabled
GCC_CET_FLAGS(CET_FLAGS)
XCFLAGS="$XCFLAGS $CET_FLAGS"
+
+case x$target in
+ xpowerpc64le*-linux*)
+AC_PREPROC_IFELSE(
+ [AC_LANG_PROGRAM([[#if __SIZEOF_LONG_DOUBLE__ != 16
+ #error long double is double
+ #endif]],
+ [[(void) 0;]])],
+ [XCFLAGS="$XCFLAGS -mno-gnu-attribute"])
+;;
+ *)
+;;
+esac
AC_SUBST(XCFLAGS)
AC_CACHE_SAVE
--- libquadmath/configure
+++ libquadmath/configure
@@ -13096,6 +13096,30 @@ fi
XCFLAGS="$XCFLAGS $CET_FLAGS"
+case x$target in
+ xpowerpc64le*-linux*)
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+#if __SIZEOF_LONG_DOUBLE__ != 16
+ #error long double is double
+ #endif
+int
+main ()
+{
+(void) 0;
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_cpp "$LINENO"; then :
+ XCFLAGS="$XCFLAGS -mno-gnu-attribute"
+fi
+rm -f conftest.err conftest.i conftest.$ac_ext
+;;
+ *)
+;;
+esac
+
cat >confcache <<\_ACEOF
# This file is a shell script that caches the results of configure
Jakub
[patch, power-ieee128, committed] Make the library functions compile correctly
Hello world, the attached patch lets the library compile correctly, as far as I have been able to determine. Committed to the branch. Best regards Thomas Make sure the Fortran specifics have real(kind=16). This brings the library to compile with all specific functions. It also corrects the patsubst patterns so the right files get the flags. It was necessary to manually add -D__powerpc64__ because apparently this is not set for Fortran. libgfortran/ChangeLog: * Makefile.am: Correct files for compilation flags. Add -D__powerpc64__ for Fortran sources. Get kinds.inc from grep of kinds.h and kinds-override.h. * Makefile.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Add -mno-gnu-attribute to compile flags. * generated/_abs_c17.F90: Regenerate. * generated/_abs_r17.F90: Regenerate. * generated/_acos_r17.F90: Regenerate. * generated/_acosh_r17.F90: Regenerate. * generated/_aimag_c17.F90: Regenerate. * generated/_aint_r17.F90: Regenerate. * generated/_anint_r17.F90: Regenerate. * generated/_asin_r17.F90: Regenerate. * generated/_asinh_r17.F90: Regenerate. * generated/_atan2_r17.F90: Regenerate. * generated/_atan_r17.F90: Regenerate. * generated/_atanh_r17.F90: Regenerate. * generated/_conjg_c17.F90: Regenerate. * generated/_cos_c17.F90: Regenerate. * generated/_cos_r17.F90: Regenerate. * generated/_cosh_r17.F90: Regenerate. * generated/_dim_r17.F90: Regenerate. * generated/_exp_c17.F90: Regenerate. * generated/_exp_r17.F90: Regenerate. * generated/_log10_r17.F90: Regenerate. * generated/_log_c17.F90: Regenerate. * generated/_log_r17.F90: Regenerate. * generated/_mod_r17.F90: Regenerate. * generated/_sign_r17.F90: Regenerate. * generated/_sin_c17.F90: Regenerate. * generated/_sin_r17.F90: Regenerate. * generated/_sinh_r17.F90: Regenerate. * generated/_sqrt_c17.F90: Regenerate. * generated/_sqrt_r17.F90: Regenerate. * generated/_tan_r17.F90: Regenerate. * generated/_tanh_r17.F90: Regenerate. * kinds-override.h: Adjust to trunk. Change condition to single line so it can be grepped. * m4/specific.m4: Make sure that real=kind16 is used for _r17.F90 and _c17.F90 files. * m4/specific2.m4: Likewise. * mk-kinds-h.sh: Adjust to trunk. diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am index f3e358368cc..efc79d0d0b7 100644 --- a/libgfortran/Makefile.am +++ b/libgfortran/Makefile.am @@ -1075,15 +1075,16 @@ $(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src: AM selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore # Build *_r17.F90 and *_c17.F90 with additional -mabi=ieeelongdouble on powerpc64le-linux. + if HAVE_REAL_17 -$(patsubst %_r17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_r17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_c17.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_c17.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -$(patsubst %_r16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_r16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_c16.F90,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble -$(patsubst %_c16.c,%.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_r16.F90,%_r16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_c16.F90,%_c16.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ibmlongdouble +$(patsubst %_r17.F90,%_r17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__ +$(patsubst %_c17.F90,%_c17.lo,$(notdir $(gfor_specific_src))): AM_FCFLAGS += -mabi=ieeelongdouble -D__powerpc64__ +$(patsubst %_r16.c,%_r16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble +$(patsubst %_c16.c,%_c16.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ibmlongdouble +$(patsubst %_r17.c,%_r17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble +$(patsubst %_c17.c,%_c17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble endif if IEEE_SUPPORT @@ -1154,8 +1155,8 @@ I_M4_DEPS9=$(I_M4_DEPS) m4/ifindloc2.m4 kinds.h: $(srcdir)/mk-kinds-h.sh $(SHELL) $(srcdir)/mk-kinds-h.sh '@LIBGOMP_CHECKED_INT_KINDS@' '@LIBGOMP_CHECKED_REAL_KINDS@' '$(FCCOMPILE)' > $@ || rm $@ -kinds.inc: kinds.h - grep '^#' < kinds.h > $@ +kinds.inc: kinds.h $(srcdir)/kinds-override.h + cat kinds.h $(srcdir)/kinds-override.h | grep '^#' | grep -v include > $@ c99_
[power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran
On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote: > The idea behind this is that libstdc++ is written such that it can handle > both IBM extended and IEEE quad long double, so its object files are > compatible with both. Now tested on powerpc64le-linux (and together with the regenerated file), ok for power-ieee128? 2022-01-03 Jakub Jelinek * configure.ac (Use -mno-gnu-attribute together with -mabi=ibmlongdouble or -mabi=ieeelongdouble. * configure: Regenerated. --- libgfortran/configure.ac.jj 2021-12-31 11:08:19.032835533 + +++ libgfortran/configure.ac2022-01-03 10:32:16.927834682 + @@ -163,9 +163,9 @@ if test "x$GCC" = "xyes"; then #error long double is double #endif]], [[(void) 0;]])], -[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble"; -AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble"; -CFLAGS="$CFLAGS -mabi=ibmlongdouble"; +[AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; have_real_17=yes]) ;; *) --- libgfortran/configure.jj2021-12-31 11:08:19.032835533 + +++ libgfortran/configure 2022-01-03 13:55:38.684926082 + @@ -6025,9 +6025,9 @@ main () } _ACEOF if ac_fn_c_try_cpp "$LINENO"; then : - AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble"; -AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble"; -CFLAGS="$CFLAGS -mabi=ibmlongdouble"; + AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; +CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute"; have_real_17=yes fi rm -f conftest.err conftest.i conftest.$ac_ext Jakub
Re: [PATCH] Support ld.mold linker.
On 1/3/22 15:48, Richard Biener wrote:
On Tue, Dec 28, 2021 at 2:10 PM Martin Liška wrote:
Hello.
The mold linker is getting quite popular and I think we should support it:
https://github.com/rui314/mold
Does it support the gold plugin API/ABI and thus proper LTO?
No, but it's planned to be added:
https://github.com/rui314/mold/issues/181
If not
I'm not sure we should encourage use. For example using
-flto -fuse-ld=lld will report strange
ld.lld: error: undefined symbol: main
referenced by start.S:104 (../sysdeps/x86_64/start.S:104)
/usr/lib/../lib64/crt1.o:(_start)
collect2: error: ld returned 1 exit status
on a simple test with a main() unless I manually add -fno-use-linker-plugin.
Yep, that's consequence of the fact a compiler is not built with such linker.
Maybe we can add a documentation note, what do you think?
Cheers,
Martin
Richard.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
---
gcc/collect2.c | 10 +++---
gcc/common.opt | 4
gcc/gcc.c | 4
gcc/opts.c | 1 +
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/gcc/collect2.c b/gcc/collect2.c
index d47fe3f9195..b322527847c 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -776,6 +776,7 @@ main (int argc, char **argv)
USE_GOLD_LD,
USE_BFD_LD,
USE_LLD_LD,
+ USE_MOLD_LD,
USE_LD_MAX
} selected_linker = USE_DEFAULT_LD;
static const char *const ld_suffixes[USE_LD_MAX] =
@@ -784,7 +785,8 @@ main (int argc, char **argv)
PLUGIN_LD_SUFFIX,
"ld.gold",
"ld.bfd",
- "ld.lld"
+ "ld.lld",
+ "ld.mold"
};
static const char *const real_ld_suffix = "real-ld";
static const char *const collect_ld_suffix = "collect-ld";
@@ -957,6 +959,8 @@ main (int argc, char **argv)
selected_linker = USE_GOLD_LD;
else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
selected_linker = USE_LLD_LD;
+ else if (strcmp (argv[i], "-fuse-ld=mold") == 0)
+ selected_linker = USE_MOLD_LD;
else if (startswith (argv[i], "-o"))
{
/* Parse the output filename if it's given so that we can make
@@ -1048,7 +1052,7 @@ main (int argc, char **argv)
ld_file_name = 0;
#ifdef DEFAULT_LINKER
if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
- selected_linker == USE_LLD_LD)
+ selected_linker == USE_LLD_LD || selected_linker == USE_MOLD_LD)
{
char *linker_name;
# ifdef HOST_EXECUTABLE_SUFFIX
@@ -1283,7 +1287,7 @@ main (int argc, char **argv)
else if (!use_collect_ld
&& startswith (arg, "-fuse-ld="))
{
- /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
+ /* Do not pass -fuse-ld={bfd|gold|lld|mold} to the linker. */
ld1--;
ld2--;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index 2ed818d6057..dba3fa886f9 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3046,6 +3046,10 @@ fuse-ld=lld
Common Driver Negative(fuse-ld=lld)
Use the lld LLVM linker instead of the default linker.
+fuse-ld=mold
+Common Driver Negative(fuse-ld=mold)
+Use the Modern linker (MOLD) linker instead of the default linker.
+
fuse-linker-plugin
Common Undocumented Var(flag_use_linker_plugin)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index b75b50b87b2..06e18a75b52 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4282,6 +4282,10 @@ driver_handle_option (struct gcc_options *opts,
use_ld = ".gold";
break;
+case OPT_fuse_ld_mold:
+ use_ld = ".mold";
+ break;
+
case OPT_fcompare_debug_second:
compare_debug_second = 1;
break;
diff --git a/gcc/opts.c b/gcc/opts.c
index cdd6463e49b..60f1cf045c9 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -3094,6 +3094,7 @@ common_handle_option (struct gcc_options *opts,
case OPT_fuse_ld_bfd:
case OPT_fuse_ld_gold:
case OPT_fuse_ld_lld:
+case OPT_fuse_ld_mold:
case OPT_fuse_linker_plugin:
/* No-op. Used by the driver and passed to us because it starts with
f.*/
break;
--
2.34.1
Re: [PATCH, OpenMP, Fortran] PR103643: ICE in gimplify_omp_affinity
On Mon, Jan 03, 2022 at 10:51:49PM +0800, Chung-Lin Tang wrote: > After the PR90030 patch, which removes the universal casting of all Fortran > array pointers to 'c_char*', > a Fortran descriptor based array passed into an affinity() clause now looks > like: > > - #pragma omp task private(i) shared(b) affinity(*(c_char *) a.data) > + #pragma omp task private(i) shared(b) affinity(*(integer(kind=4)[0:] * > restrict) a.data) > > The 'integer(kind=4)[0:]' incomplete type appears to be causing ICE during > gimplify_expr() due to > is_gimple_val, fb_rvalue. The ICE appears to be fixed just by adjusting to > 'is_gimple_lvalue, fb_lvalue'. > Considering the use of the affinity() clause, which should be specifying the > location of a particular > object in memory, this probably makes sense. > > Tested without regressions, seeking approval for trunk. > > Thanks, > Chung-Lin > > 2022-01-03 Chung-Lin Tang > > gcc/ChangeLog: > > PR middle-end/103643 > * gimplify.c (gimplify_omp_affinity): Adjust gimplify_expr of entire > OMP_CLAUSE_DECL to use 'is_gimple_lvalue, fb_lvalue' > > gcc/testsuite/ChangeLog: > > * gfortran.dg/gomp/pr103643.f90: New test. Ok, thanks. Jakub
Re: [PATCH] Revamp documentation for _Complex types extension
On Mon, Jan 3, 2022 at 2:51 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> While cleaning up the bug database, I noticed there was a request
> to improve the documentation of the _Complex type extensions.
> So I rewrote part of the documentation to make things clearer on
> __real/__imag and even added documentation about casts between
> the scalar and the complex type.
> I moved the documentation of __builtin_complex under this section
> too because it makes more sense than having it in the other
> built-in section and reference it.
>
> OK? Built make info and make html and checked out the results to
> make sure the tables look decent.
OK.
> gcc/ChangeLog:
>
> PR c/33193
> * doc/extend.texi: Extend the documentation about Complex
> types for casting and also rewrite the __real__/__imag__
> expression portion to use tables.
> Move __builtin_complex to the Complex type section.
> ---
> gcc/doc/extend.texi | 73 +
> 1 file changed, 54 insertions(+), 19 deletions(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 9676a17406e..c7a43a79e16 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -986,22 +986,57 @@ The ISO C++14 library also defines the @samp{i} suffix,
> so C++14 code
> that includes the @samp{} header cannot use @samp{i} for the
> GNU extension. The @samp{j} suffix still has the GNU meaning.
>
> +GCC can handle both implicit and explicit casts between the @code{_Complex}
> +types and other @code{_Complex} types as casting both the real and imaginary
> +parts to the scalar type.
> +GCC can handle implicit and explicit casts from a scalar type to a
> @code{_Complex}
> +type and where the imaginary part will be considered zero.
> +The C front-end can handle implicit and explicit casts from a
> @code{_Complex} type
> +to a scalar type where the imaginary part will be ignored. In C++ code, this
> cast
> +is considered illformed and G++ will error out.
> +
> +GCC provides a built-in function @code{__builtin_complex} will can be used to
> +construct a complex value.
> +
> @cindex @code{__real__} keyword
> @cindex @code{__imag__} keyword
> -To extract the real part of a complex-valued expression @var{exp}, write
> -@code{__real__ @var{exp}}. Likewise, use @code{__imag__} to
> -extract the imaginary part. This is a GNU extension; for values of
> -floating type, you should use the ISO C99 functions @code{crealf},
> -@code{creal}, @code{creall}, @code{cimagf}, @code{cimag} and
> -@code{cimagl}, declared in @code{} and also provided as
> +
> +GCC has a few extensions which can be used to extract the real
> +and the imaginary part of the complex-valued expression. Note
> +these expressions are lvalues if the @var{exp} is an lvalue.
> +These expressions operands have the type of a complex type
> +which might get prompoted to a complex type from a scalar type.
> +E.g. @code{__real__ (int)@var{x}} is the same as casting to
> +@code{_Complex int} before @code{__real__} is done.
> +
> +@multitable @columnfractions .4 .6
> +@headitem Expression @tab Description
> +@item @code{__real__ @var{exp}}
> +@tab Extract the real part of @var{exp}.
> +@item @code{__imag__ @var{exp}}
> +@tab Extract the imaginary part of @var{exp}.
> +@end multitable
> +
> +For values of floating point, you should use the ISO C99
> +functions, declared in @code{} and also provided as
> built-in functions by GCC@.
>
> +@multitable @columnfractions .4 .2 .2 .2
> +@headitem Expression @tab float @tab double @tab long double
> +@item @code{__real__ @var{exp}}
> +@tab @code{crealf} @tab @code{creal} @tab @code{creall}
> +@item @code{__imag__ @var{exp}}
> +@tab @code{cimagf} @tab @code{cimag} @tab @code{cimagl}
> +@end multitable
> +
> @cindex complex conjugation
> The operator @samp{~} performs complex conjugation when used on a value
> with a complex type. This is a GNU extension; for values of
> floating type, you should use the ISO C99 functions @code{conjf},
> @code{conj} and @code{conjl}, declared in @code{} and also
> -provided as built-in functions by GCC@.
> +provided as built-in functions by GCC@. Note unlike the @code{__real__}
> +and @code{__imag__} operators, this operator will not do an implicit cast
> +to the complex type because the @samp{~} is already a normal operator.
>
> GCC can allocate complex automatic variables in a noncontiguous
> fashion; it's even possible for the real part to be in a register while
> @@ -1013,6 +1048,18 @@ If the variable's actual name is @code{foo}, the two
> fictitious
> variables are named @code{foo$real} and @code{foo$imag}. You can
> examine and set these two fictitious variables with your debugger.
>
> +@deftypefn {Built-in Function} @var{type} __builtin_complex (@var{real},
> @var{imag})
> +
> +The built-in function @code{__builtin_complex} is provided for use in
> +implementing the ISO C11 macros @code{CMPLXF}, @code{CMPLX} and
> +@cod
[PATCH, OpenMP, Fortran] PR103643: ICE in gimplify_omp_affinity
After the PR90030 patch, which removes the universal casting of all Fortran
array pointers to 'c_char*',
a Fortran descriptor based array passed into an affinity() clause now looks
like:
- #pragma omp task private(i) shared(b) affinity(*(c_char *) a.data)
+ #pragma omp task private(i) shared(b) affinity(*(integer(kind=4)[0:] *
restrict) a.data)
The 'integer(kind=4)[0:]' incomplete type appears to be causing ICE during
gimplify_expr() due to
is_gimple_val, fb_rvalue. The ICE appears to be fixed just by adjusting to
'is_gimple_lvalue, fb_lvalue'.
Considering the use of the affinity() clause, which should be specifying the
location of a particular
object in memory, this probably makes sense.
Tested without regressions, seeking approval for trunk.
Thanks,
Chung-Lin
2022-01-03 Chung-Lin Tang
gcc/ChangeLog:
PR middle-end/103643
* gimplify.c (gimplify_omp_affinity): Adjust gimplify_expr of entire
OMP_CLAUSE_DECL to use 'is_gimple_lvalue, fb_lvalue'
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/pr103643.f90: New test.diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index b118c72f62c..87cc01483dd 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -8123,7 +8123,7 @@ gimplify_omp_affinity (tree *list_p, gimple_seq *pre_p)
if (error_operand_p (OMP_CLAUSE_DECL (c)))
return;
if (gimplify_expr (&OMP_CLAUSE_DECL (c), pre_p, NULL,
- is_gimple_val, fb_rvalue) == GS_ERROR)
+ is_gimple_lvalue, fb_lvalue) == GS_ERROR)
return;
gimplify_and_add (OMP_CLAUSE_DECL (c), pre_p);
}
diff --git a/gcc/testsuite/gfortran.dg/gomp/pr103643.f90
b/gcc/testsuite/gfortran.dg/gomp/pr103643.f90
new file mode 100644
index 000..3b409f5f858
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/pr103643.f90
@@ -0,0 +1,19 @@
+! PR middle-end/103643
+! { dg-do compile }
+
+program test_task_affinity
+ implicit none
+ integer i
+ integer, allocatable :: A(:)
+
+ allocate (A(10))
+
+ !$omp target
+ !$omp task affinity(A)
+ do i = 1, 10
+ A(i) = 0
+ end do
+ !$omp end task
+ !$omp end target
+
+end program test_task_affinity
Re: [PATCH] Support ld.mold linker.
On Tue, Dec 28, 2021 at 2:10 PM Martin Liška wrote:
>
> Hello.
>
> The mold linker is getting quite popular and I think we should support it:
> https://github.com/rui314/mold
Does it support the gold plugin API/ABI and thus proper LTO? If not
I'm not sure we should encourage use. For example using
-flto -fuse-ld=lld will report strange
ld.lld: error: undefined symbol: main
>>> referenced by start.S:104 (../sysdeps/x86_64/start.S:104)
>>> /usr/lib/../lib64/crt1.o:(_start)
collect2: error: ld returned 1 exit status
on a simple test with a main() unless I manually add -fno-use-linker-plugin.
Richard.
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> ---
> gcc/collect2.c | 10 +++---
> gcc/common.opt | 4
> gcc/gcc.c | 4
> gcc/opts.c | 1 +
> 4 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/collect2.c b/gcc/collect2.c
> index d47fe3f9195..b322527847c 100644
> --- a/gcc/collect2.c
> +++ b/gcc/collect2.c
> @@ -776,6 +776,7 @@ main (int argc, char **argv)
> USE_GOLD_LD,
> USE_BFD_LD,
> USE_LLD_LD,
> + USE_MOLD_LD,
> USE_LD_MAX
> } selected_linker = USE_DEFAULT_LD;
> static const char *const ld_suffixes[USE_LD_MAX] =
> @@ -784,7 +785,8 @@ main (int argc, char **argv)
> PLUGIN_LD_SUFFIX,
> "ld.gold",
> "ld.bfd",
> - "ld.lld"
> + "ld.lld",
> + "ld.mold"
> };
> static const char *const real_ld_suffix = "real-ld";
> static const char *const collect_ld_suffix = "collect-ld";
> @@ -957,6 +959,8 @@ main (int argc, char **argv)
> selected_linker = USE_GOLD_LD;
> else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
> selected_linker = USE_LLD_LD;
> + else if (strcmp (argv[i], "-fuse-ld=mold") == 0)
> + selected_linker = USE_MOLD_LD;
> else if (startswith (argv[i], "-o"))
> {
> /* Parse the output filename if it's given so that we can make
> @@ -1048,7 +1052,7 @@ main (int argc, char **argv)
> ld_file_name = 0;
> #ifdef DEFAULT_LINKER
> if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
> - selected_linker == USE_LLD_LD)
> + selected_linker == USE_LLD_LD || selected_linker == USE_MOLD_LD)
> {
> char *linker_name;
> # ifdef HOST_EXECUTABLE_SUFFIX
> @@ -1283,7 +1287,7 @@ main (int argc, char **argv)
> else if (!use_collect_ld
>&& startswith (arg, "-fuse-ld="))
> {
> - /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
> + /* Do not pass -fuse-ld={bfd|gold|lld|mold} to the linker.
> */
> ld1--;
> ld2--;
> }
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 2ed818d6057..dba3fa886f9 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -3046,6 +3046,10 @@ fuse-ld=lld
> Common Driver Negative(fuse-ld=lld)
> Use the lld LLVM linker instead of the default linker.
>
> +fuse-ld=mold
> +Common Driver Negative(fuse-ld=mold)
> +Use the Modern linker (MOLD) linker instead of the default linker.
> +
> fuse-linker-plugin
> Common Undocumented Var(flag_use_linker_plugin)
>
> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index b75b50b87b2..06e18a75b52 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -4282,6 +4282,10 @@ driver_handle_option (struct gcc_options *opts,
> use_ld = ".gold";
> break;
>
> +case OPT_fuse_ld_mold:
> + use_ld = ".mold";
> + break;
> +
> case OPT_fcompare_debug_second:
> compare_debug_second = 1;
> break;
> diff --git a/gcc/opts.c b/gcc/opts.c
> index cdd6463e49b..60f1cf045c9 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -3094,6 +3094,7 @@ common_handle_option (struct gcc_options *opts,
> case OPT_fuse_ld_bfd:
> case OPT_fuse_ld_gold:
> case OPT_fuse_ld_lld:
> +case OPT_fuse_ld_mold:
> case OPT_fuse_linker_plugin:
> /* No-op. Used by the driver and passed to us because it starts with
> f.*/
> break;
> --
> 2.34.1
>
Re: [PATCH] disable aggressive_loop_optimizations until niter ready
On Wed, 22 Dec 2021, Jiufu Guo wrote:
> Hi,
>
> Normaly, estimate_numbers_of_iterations get/caculate niter first,
> and then invokes infer_loop_bounds_from_undefined. While in some case,
> after a few call stacks, estimate_numbers_of_iterations is invoked before
> niter is ready (e.g. before number_of_latch_executions returns).
>
> e.g. number_of_latch_executions->...follow_ssa_edge_expr-->
> --> estimate_numbers_of_iterations --> infer_loop_bounds_from_undefined.
>
> Since niter is still not computed, call to infer_loop_bounds_from_undefined
> may not get final result.
> To avoid infer_loop_bounds_from_undefined to be called with interim state
> and avoid infer_loop_bounds_from_undefined generates interim data, during
> niter's computing, we could disable flag_aggressive_loop_optimizations.
>
> Bootstrap and regtest pass on ppc64* and x86_64. Is this ok for trunk?
So this is a optimality fix, not a correctness one? I suppose the
estimates are computed/used from scev_probably_wraps_p via
loop_exits_before_overflow and ultimatively chrec_convert.
We have a call cycle here,
estimate_numbers_of_iterations -> number_of_latch_executions ->
... -> estimate_numbers_of_iterations
where the first estimate_numbers_of_iterations will make sure
the later call will immediately return.
I'm not sure what your patch tries to do - it seems to tackle
the case where we enter the cycle via number_of_latch_executions?
Why do we get "non-final" values? idx_infer_loop_bounds resorts
to SCEV and thus may recurse again - to me it would be more
logical to try avoid recursing in number_of_latch_executions by
setting ->nb_iterations to something early, maybe chrec_dont_know,
to signal we're using something we're just trying to compute.
Richard.
> BR,
> Jiufu
>
> gcc/ChangeLog:
>
> * tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
> Disable/restore flag_aggressive_loop_optimizations.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/scev-16.c: New test.
>
> ---
> gcc/tree-ssa-loop-niter.c | 23 +++
> gcc/testsuite/gcc.dg/tree-ssa/scev-16.c | 20
> 2 files changed, 39 insertions(+), 4 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
>
> diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
> index 06954e437f5..51bb501019e 100644
> --- a/gcc/tree-ssa-loop-niter.c
> +++ b/gcc/tree-ssa-loop-niter.c
> @@ -2534,18 +2534,31 @@ number_of_iterations_exit_assumptions (class loop
> *loop, edge exit,
>&& !POINTER_TYPE_P (type))
> return false;
>
> + /* Before niter is calculated, avoid to analyze interim state. */
> + int old_aggressive_loop_optimizations = flag_aggressive_loop_optimizations;
> + flag_aggressive_loop_optimizations = 0;
> +
>tree iv0_niters = NULL_TREE;
>if (!simple_iv_with_niters (loop, loop_containing_stmt (stmt),
> op0, &iv0, safe ? &iv0_niters : NULL, false))
> -return number_of_iterations_popcount (loop, exit, code, niter);
> +{
> + bool res = number_of_iterations_popcount (loop, exit, code, niter);
> + flag_aggressive_loop_optimizations = old_aggressive_loop_optimizations;
> + return res;
> +}
>tree iv1_niters = NULL_TREE;
>if (!simple_iv_with_niters (loop, loop_containing_stmt (stmt),
> op1, &iv1, safe ? &iv1_niters : NULL, false))
> -return false;
> +{
> + flag_aggressive_loop_optimizations = old_aggressive_loop_optimizations;
> + return false;
> +}
>/* Give up on complicated case. */
>if (iv0_niters && iv1_niters)
> -return false;
> -
> +{
> + flag_aggressive_loop_optimizations = old_aggressive_loop_optimizations;
> + return false;
> +}
>/* We don't want to see undefined signed overflow warnings while
> computing the number of iterations. */
>fold_defer_overflow_warnings ();
> @@ -2565,6 +2578,7 @@ number_of_iterations_exit_assumptions (class loop
> *loop, edge exit,
> only_exit_p, safe))
> {
>fold_undefer_and_ignore_overflow_warnings ();
> + flag_aggressive_loop_optimizations = old_aggressive_loop_optimizations;
>return false;
> }
>
> @@ -2608,6 +2622,7 @@ number_of_iterations_exit_assumptions (class loop
> *loop, edge exit,
> niter->may_be_zero);
>
>fold_undefer_and_ignore_overflow_warnings ();
> + flag_aggressive_loop_optimizations = old_aggressive_loop_optimizations;
>
>/* If NITER has simplified into a constant, update MAX. */
>if (TREE_CODE (niter->niter) == INTEGER_CST)
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> new file mode 100644
> index 000..708ffab88ca
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> @@ -0,0 +1,20 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -
[PATCH, OpenMP] PR103642 - Fix omp-low ICE for indirect references based off component access
This issue was triggered after the patch extending syntax for component access
in map clauses
(https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ab29cf0bb68960c)
In gimplify_scan_omp_clauses, the case for handling indirect accesses (which
creates
firstprivate ptr and zero-length array section map for such decls) was
erroneously
went into for non-pointer cases (here being the base struct decl), so added the
appropriate checks there.
Added new testcase is a compile only test for the ICE. The original omptests
t-partial-struct
test actually should not execute correctly, because for map(t.s->a[:N]),
map(t.s[:1])
is not implicitly mapped, thus the entire offloaded access does not work as is.
(fixing that omptests test is out of scope here)
Tested without regressions, okay for trunk?
Thanks,
Chung-Lin
2022-01-03 Chung-Lin Tang
gcc/ChangeLog:
PR middle-end/103642
* gimplify.c (gimplify_scan_omp_clauses): Do not do indir_p handling
for non-pointer or non-reference-to-pointer cases.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/pr103642.c: New test.
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index b118c72f62c..bdc8189c2a7 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -9543,7 +9543,10 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq
*pre_p,
== REFERENCE_TYPE))
decl = TREE_OPERAND (decl, 0);
}
- if (decl != orig_decl && DECL_P (decl) && indir_p)
+ if (decl != orig_decl && DECL_P (decl) && indir_p
+ && (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE
+ || (decl_ref
+ && TREE_CODE (TREE_TYPE (decl_ref)) == POINTER_TYPE)))
{
gomp_map_kind k
= ((code == OACC_EXIT_DATA || code == OMP_TARGET_EXIT_DATA)
diff --git a/gcc/testsuite/c-c++-common/gomp/pr103642.c
b/gcc/testsuite/c-c++-common/gomp/pr103642.c
new file mode 100644
index 000..c5451596b69
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/pr103642.c
@@ -0,0 +1,31 @@
+/* PR middle-end/103642 */
+/* { dg-do compile } */
+
+#include
+
+typedef struct
+{
+ int *a;
+} S;
+
+typedef struct
+{
+ S *s;
+ int *ptr;
+} T;
+
+#define N 10
+
+int main (void)
+{
+ T t;
+ t.s = (S *) malloc (sizeof (S));
+ t.s->a = (int *) malloc (sizeof(int) * N);
+
+ #pragma omp target map(from: t.s->a[:N])
+ {
+t.s->a[0] = 1;
+ }
+
+ return 0;
+}
Re: [GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193
On Fri, Dec 17, 2021 at 11:45 PM H.J. Lu via Gcc-patches
wrote:
>
> OK for release branches?
OK - I assume the size is not leaked as ABI detail?
>
> H.J.
> ---
> Cherry-pick from LLVM release/13.x branch:
>
> commit d96358a2819399a2abb60ad3b26444ab7b4409cf
> Author: Michał Górny
> Date: Mon Dec 13 22:28:26 2021 +0100
>
> [compiler-rt] Increase kDlsymAllocPoolSize to fix test failures
>
> Increase kDlsymAllocPoolSize on the release branch as discussed on bug
> 51620, as an alternative to backporting
> cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
> The minimum size is 8192, as needed for the following test to pass:
>
> AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp
>
> Fixes #51620
>
> PR sanitizer/102911
> * asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
> 8192 on Linux.
> ---
> libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libsanitizer/asan/asan_malloc_linux.cpp
> b/libsanitizer/asan/asan_malloc_linux.cpp
> index 9c3f0a5338e..7a5776b29ed 100644
> --- a/libsanitizer/asan/asan_malloc_linux.cpp
> +++ b/libsanitizer/asan/asan_malloc_linux.cpp
> @@ -31,7 +31,7 @@ using namespace __asan;
>
> static uptr allocated_for_dlsym;
> static uptr last_dlsym_alloc_size_in_words;
> -static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
> +static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
> static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
>
> static inline bool IsInDlsymAllocPool(const void *ptr) {
> --
> 2.33.1
>
Re: [RFC PATCH] tree-ssa-sink: do not sink to in front of setjmp
On Tue, Dec 14, 2021 at 12:10 PM Алексей Нурмухаметов
wrote:
>
> On 13.12.2021 18:20, Alexander Monakov wrote:
> > On Mon, 13 Dec 2021, Richard Biener wrote:
> >
> >> On December 13, 2021 3:25:47 PM GMT+01:00, Alexander Monakov
> >> wrote:
> >>> Greetings!
> >>>
> >>> While testing our patch that reimplements -Wclobbered on GIMPLE we found
> >>> a case where tree-ssa-sink moves a statement to a basic block in front
> >>> of a setjmp call.
> >>>
> >>> I am confident that this is unintended and should be considered invalid
> >>> GIMPLE.
> >> Does CFG validation not catch this? That is, doesn't setjmp force the
> >> start of
> >> a new BB?
> > Oh, good point. There's stmt_start_bb_p which returns true for setjmp, but
> > gimple_verify_flow_info doesn't check it. I guess we can try adding that
> > and collect the fallout on bootstrap/regtest.
>
> Bootstrap looks good, but testsuite has some regression (the applied
> patch is below).
>
> The overall number of unexpected failures and unresolved testcases is
> around 100. The diff is in attachment.
> >> I think sinking relies on dominance and post dominance here but post
> >> dominance
> >> may be too fragile with the abnormal cycles which are likely not backwards
> >> reachable from exit.
> >>
> >> That said, checking for abnormal preds is OK, I just want to make sure we
> >> detect the invalid CFG - do we?
> > As above, no, otherwise it would have been caught much earlier than ICE'ing
> > our -Wclobbered patch :)
> >
> > Thank you.
> > Alexander
>
> The patch for CFG validation:
>
> diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
> index ebbd894ae03..92b08d1d6d8 100644
> --- a/gcc/tree-cfg.c
> +++ b/gcc/tree-cfg.c
> @@ -5663,6 +5663,7 @@ gimple_verify_flow_info (void)
> }
>
> /* Verify that body of basic block BB is free of control flow. */
> + gimple *prev_stmt = NULL;
> for (; !gsi_end_p (gsi); gsi_next (&gsi))
> {
>gimple *stmt = gsi_stmt (gsi);
> @@ -5674,6 +5675,14 @@ gimple_verify_flow_info (void)
>err = 1;
> }
>
> + if (prev_stmt && stmt_starts_bb_p (stmt, prev_stmt))
stmt_starts_bb_p is really a helper used during CFG build, I'd rather
test explicitely for a GIMPLE call with ECF_RETURNS_TWICE, or maybe,
verify that iff a block has abnormal predecessors it starts with such
a call (because IIRC we in some cases elide abnormal edges and then
it's OK to move "down" the calls). So yes, if a block has abnormal preds
it should start with a ECF_RETURNS_TWICE call, I think we cannot
verify the reverse reliably - abnormal edges cannot easily be re-built
in late stages (it's a bug that we do so during RTL expansion).
> + {
> + error ("setjmp in the middle of basic block %d", bb->index);
> + err = 1;
> + }
> + if (!is_gimple_debug (stmt))
> + prev_stmt = stmt;
> +
>if (stmt_ends_bb_p (stmt))
> found_ctrl_stmt = true;
>
Re: [PATCH] shrink-wrapping: Don't call can_get_prologue unnecessarily [PR103860]
On Mon, 3 Jan 2022, Segher Boessenkool wrote: > Hi! > > On Mon, Jan 03, 2022 at 12:00:10PM +0100, Jakub Jelinek wrote: > > On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote: > > > > The following simple patch makes sure we call can_get_prologue even > > > > after > > > > the last former iteration when vec is already empty and only break from > > > > the loop afterwards (and only if the updating of pro done because of > > > > !can_get_prologue didn't push anything into vec again). > > > > During the development of the above patch I've noticed that in many cases > > we call can_get_prologue often on the same pro again and again and again, > > we can have many basic blocks pushed into vec and if most of those don't > > require pro updates, i.e. > > basic_block bb = vec.pop (); > > if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size)) > > while (!dominated_by_p (CDI_DOMINATORS, bb, pro)) > > isn't true, then pro is can_get_prologue checked for each bb in the vec. > > > > The following simple patch just remembers which bb we've verified already > > and verifies again only when pro changes. Most of the patch is just > > reindentation. > > I'd like it better if the code structure was changed so you do not need > this workaround. That will probably result in much clearer code. > > But it does look correct :-) > > This should make things O(n) again here. Thanks for fixing this! Btw, you can take that as approval. Richard.
Re: Patch ping
> Hi! > > I'd like to ping the > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html > symtab: Fold &a == &b to 0 if folding_initializer [PR94716] > > patch. Thanks. OK. Note that with LTO partitioning it may happen that alias is defined in one partition but used in another. We do take care to bring the symtab info with it so it should be safe. Honza > > Jakub >
Re: [PATCH] shrink-wrapping: Don't call can_get_prologue unnecessarily [PR103860]
Hi! On Mon, Jan 03, 2022 at 12:00:10PM +0100, Jakub Jelinek wrote: > On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote: > > > The following simple patch makes sure we call can_get_prologue even after > > > the last former iteration when vec is already empty and only break from > > > the loop afterwards (and only if the updating of pro done because of > > > !can_get_prologue didn't push anything into vec again). > > During the development of the above patch I've noticed that in many cases > we call can_get_prologue often on the same pro again and again and again, > we can have many basic blocks pushed into vec and if most of those don't > require pro updates, i.e. > basic_block bb = vec.pop (); > if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size)) > while (!dominated_by_p (CDI_DOMINATORS, bb, pro)) > isn't true, then pro is can_get_prologue checked for each bb in the vec. > > The following simple patch just remembers which bb we've verified already > and verifies again only when pro changes. Most of the patch is just > reindentation. I'd like it better if the code structure was changed so you do not need this workaround. That will probably result in much clearer code. But it does look correct :-) This should make things O(n) again here. Thanks for fixing this! Segher > PR rtl-optimization/103860 > * shrink-wrap.c (try_shrink_wrapping): Don't call can_get_prologue > uselessly for blocks for which it has been called already.
Re: Patch ping
On Mon, 3 Jan 2022, Jakub Jelinek wrote: > Hi! > > I'd like to ping the > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html > symtab: Fold &a == &b to 0 if folding_initializer [PR94716] OK. Thanks, Richard.
Re: Patch ping
On Mon, 3 Jan 2022, Jakub Jelinek wrote: > Hi! > > I'd like to ping the middle-end part of the > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586879.html > patch (which Uros approved the backend part for with a minor change > I have in my tree). OK for the middle-end parts if you properly amend md.texi Richard.
Re: [AArch64] Enable generation of FRINTNZ instructions
On Wed, 29 Dec 2021, Andre Vieira (lists) wrote:
> Hi Richard,
>
> Thank you for the review, I've adopted all above suggestions downstream, I am
> still surprised how many style things I still miss after years of gcc
> development :(
>
> On 17/12/2021 12:44, Richard Sandiford wrote:
> >
> >> @@ -3252,16 +3257,31 @@ vectorizable_call (vec_info *vinfo,
> >> rhs_type = unsigned_type_node;
> >> }
> >> - int mask_opno = -1;
> >> + /* The argument that is not of the same type as the others. */
> >> + int diff_opno = -1;
> >> + bool masked = false;
> >> if (internal_fn_p (cfn))
> >> -mask_opno = internal_fn_mask_index (as_internal_fn (cfn));
> >> +{
> >> + if (cfn == CFN_FTRUNC_INT)
> >> + /* For FTRUNC this represents the argument that carries the type of
> >> the
> >> + intermediate signed integer. */
> >> + diff_opno = 1;
> >> + else
> >> + {
> >> +/* For masked operations this represents the argument that carries
> >> the
> >> + mask. */
> >> +diff_opno = internal_fn_mask_index (as_internal_fn (cfn));
> >> +masked = diff_opno >= 0;
> >> + }
> >> +}
> > I think it would be cleaner not to process argument 1 at all for
> > CFN_FTRUNC_INT. There's no particular need to vectorise it.
>
> I agree with this, will change the loop to continue for argument 1 when
> dealing with non-masked CFN's.
>
> >>}
> >> […]
> >> diff --git a/gcc/tree.c b/gcc/tree.c
> >> index
> >> 845228a055b2cfac0c9ca8c0cda1b9df4b0095c6..f1e9a1eb48769cb11aa69730e2480ed5522f78c1
> >> 100644
> >> --- a/gcc/tree.c
> >> +++ b/gcc/tree.c
> >> @@ -6645,11 +6645,11 @@ valid_constant_size_p (const_tree size,
> >> cst_size_error *perr /* = NULL */)
> >> return true;
> >> }
> >>
> >> -/* Return the precision of the type, or for a complex or vector type the
> >> - precision of the type of its elements. */
> >> +/* Return the type, or for a complex or vector type the type of its
> >> + elements. */
> >> -unsigned int
> >> -element_precision (const_tree type)
> >> +tree
> >> +element_type (const_tree type)
> >> {
> >> if (!TYPE_P (type))
> >> type = TREE_TYPE (type);
> >> @@ -6657,7 +6657,16 @@ element_precision (const_tree type)
> >> if (code == COMPLEX_TYPE || code == VECTOR_TYPE)
> >> type = TREE_TYPE (type);
> >> - return TYPE_PRECISION (type);
> >> + return (tree) type;
> > I think we should stick a const_cast in element_precision and make
> > element_type take a plain “type”. As it stands element_type is an
> > implicit const_cast for many cases.
> >
> > Thanks,
> Was just curious about something here, I thought the purpose of having
> element_precision (before) and element_type (now) take a const_tree as an
> argument was to make it clear we aren't changing the input type. I understand
> that as it stands element_type could be an implicit const_cast (which I should
> be using rather than the '(tree)' cast), but that's only if 'type' is a type
> that isn't complex/vector, either way, we are conforming to the promise that
> we aren't changing the incoming type, what the caller then does with the
> result is up to them no?
>
> I don't mind making the changes, just trying to understand the reasoning
> behind it.
>
> I'll send in a new patch with all the changes after the review on the match.pd
> stuff.
I'm missing an updated patch after my initial review of the match.pd
stuff so not sure what to review. Can you re-post and updated patch?
Thanks,
Richard.
[PATCH] middle-end/103851 - ensure SSA names are released during OMP lowering
This makes sure to release moved & remapped SSA names during OMP
outlining which happens before going into SSA but with SSA names
created by gimplification around.
Boostrap & regtest running on x86_64-unknown-linux-gnu.
2022-01-03 Richard Biener
PR middle-end/103851
* tree-cfg.c (move_sese_region_to_fn): Always release SSA names.
* g++.dg/gomp/pr103851.C: New testcase.
---
gcc/testsuite/g++.dg/gomp/pr103851.C | 15 +++
gcc/tree-cfg.c | 20
2 files changed, 23 insertions(+), 12 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/gomp/pr103851.C
diff --git a/gcc/testsuite/g++.dg/gomp/pr103851.C
b/gcc/testsuite/g++.dg/gomp/pr103851.C
new file mode 100644
index 000..257e4059d59
--- /dev/null
+++ b/gcc/testsuite/g++.dg/gomp/pr103851.C
@@ -0,0 +1,15 @@
+// { dg-do compile }
+// { dg-options "-fopenmp -ftrivial-auto-var-init=pattern" }
+
+struct _Deque_base {
+long _M_map_size;
+int *_M_start;
+int *_M_finish;
+};
+void morphologicalFilter1D()
+{
+#pragma omp parallel
+ {
+struct _Deque_base vals[4];
+ }
+}
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index c436e590025..bb3779367fe 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -7947,18 +7947,14 @@ move_sese_region_to_fn (struct function *dest_cfun,
basic_block entry_bb,
if (eh_map)
delete eh_map;
- if (gimple_in_ssa_p (cfun))
-{
- /* We need to release ssa-names in a defined order, so first find them,
-and then iterate in ascending version order. */
- bitmap release_names = BITMAP_ALLOC (NULL);
- vars_map.traverse (release_names);
- bitmap_iterator bi;
- unsigned i;
- EXECUTE_IF_SET_IN_BITMAP (release_names, 0, i, bi)
- release_ssa_name (ssa_name (i));
- BITMAP_FREE (release_names);
-}
+ /* We need to release ssa-names in a defined order, so first find them,
+ and then iterate in ascending version order. */
+ bitmap release_names = BITMAP_ALLOC (NULL);
+ vars_map.traverse (release_names);
+ bitmap_iterator bi;
+ EXECUTE_IF_SET_IN_BITMAP (release_names, 0, i, bi)
+release_ssa_name (ssa_name (i));
+ BITMAP_FREE (release_names);
/* Rewire the entry and exit blocks. The successor to the entry
block turns into the successor of DEST_FN's ENTRY_BLOCK_PTR in
--
2.31.1
Re: [PATCH] testsuite: fix vect.exp ASAN errors
On 12/15/21 14:24, Martin Liška wrote: Ready to be installed? I'm going to install this as it's quite obvious. Martin
Re: [PATCH] testsuite: fix ASAN errors in i386.exp tests
On 12/14/21 16:28, Martin Liška wrote: Ready for master? I'm going to install this as it's quite obvious. Martin
Re: [PATCH] i386: simplify cpu_feature handling
PING: Jakub? On 12/15/21 10:57, Martin Liška wrote: On 12/14/21 17:12, Jakub Jelinek wrote: I'd use INT_TYPE_SIZE - 1 instead of 31. Otherwise LGTM. Installed with that change, thanks. Moreover, I'm suggesting a simplification: The patch removes unneeded loops for cpu_features2 and CONVERT_EXPR that can be simplified with NOP_EXPR. Survives i386.exp tests, may I install the patch after testing or is it a stage1 material? Thanks, Martin
[PATCH] shrink-wrapping: Don't call can_get_prologue unnecessarily [PR103860]
On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote:
> > The following simple patch makes sure we call can_get_prologue even after
> > the last former iteration when vec is already empty and only break from
> > the loop afterwards (and only if the updating of pro done because of
> > !can_get_prologue didn't push anything into vec again).
During the development of the above patch I've noticed that in many cases
we call can_get_prologue often on the same pro again and again and again,
we can have many basic blocks pushed into vec and if most of those don't
require pro updates, i.e.
basic_block bb = vec.pop ();
if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size))
while (!dominated_by_p (CDI_DOMINATORS, bb, pro))
isn't true, then pro is can_get_prologue checked for each bb in the vec.
The following simple patch just remembers which bb we've verified already
and verifies again only when pro changes. Most of the patch is just
reindentation.
Ok for trunk if it passes bootstrap/regtest?
2022-01-03 Jakub Jelinek
PR rtl-optimization/103860
* shrink-wrap.c (try_shrink_wrapping): Don't call can_get_prologue
uselessly for blocks for which it has been called already.
--- gcc/shrink-wrap.c.jj2022-01-03 10:40:41.758156451 +0100
+++ gcc/shrink-wrap.c 2022-01-03 11:43:36.200744640 +0100
@@ -781,14 +781,20 @@ try_shrink_wrapping (edge *entry_edge, r
unsigned max_grow_size = get_uncond_jump_length ();
max_grow_size *= param_max_grow_copy_bb_insns;
+ basic_block checked_pro = NULL;
+
while (pro != entry)
{
- while (pro != entry && !can_get_prologue (pro, prologue_clobbered))
+ if (pro != checked_pro)
{
- pro = get_immediate_dominator (CDI_DOMINATORS, pro);
+ while (pro != entry && !can_get_prologue (pro, prologue_clobbered))
+ {
+ pro = get_immediate_dominator (CDI_DOMINATORS, pro);
- if (bitmap_set_bit (bb_with, pro->index))
- vec.quick_push (pro);
+ if (bitmap_set_bit (bb_with, pro->index))
+ vec.quick_push (pro);
+ }
+ checked_pro = pro;
}
if (vec.is_empty ())
Jakub
Re: [2/2] PR96463 -- changes to type checking vec_perm_expr in middle end
On Fri, 17 Dec 2021, Richard Sandiford wrote:
> Prathamesh Kulkarni writes:
> > Hi,
> > The attached patch rearranges order of type-check for vec_perm_expr
> > and relaxes type checking for
> > lhs = vec_perm_expr
> >
> > when:
> > rhs1 == rhs2,
> > lhs is variable length vector,
> > rhs1 is fixed length vector,
> > TREE_TYPE (lhs) == TREE_TYPE (rhs1)
> >
> > I am not sure tho if this check is correct ? My intent was to capture
> > case when vec_perm_expr is used to "extend" fixed length vector to
> > it's VLA equivalent.
>
> VLAness isn't really the issue. We want the same thing to work for
> -msve-vector-bits=256, -msve-vector-bits=512, etc., even though the
> vectors are fixed-length in that case.
>
> The principle is that for:
>
> A = VEC_PERM_EXPR ;
>
> the requirements are:
>
> - A, B, C and D must be vectors
> - A, B and C must have the same element type
> - D must have an integer element type
> - A and D must have the same number of elements (NA)
> - B and C must have the same number of elements (NB)
>
> The semantics are that we create a joined vector BC (all elements of B
> followed by all element of C) and that:
>
> A[i] = BC[D[i] % (NB+NB)]
>
> for 0 ≤ i < NA.
>
> This operation makes sense even if NA != NB.
But note that we don't currently expect NA != NB and the optab just
has a single mode.
I'd rather go with the simpler patch I posted as reply to the earlier
mail rather such large refactoring at this point.
Richard.
> Thanks,
> Richard
>
> >
> > Thanks,
> > Prathamesh
> >
> > diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
> > index 672e384ef09..9f91878c468 100644
> > --- a/gcc/tree-cfg.c
> > +++ b/gcc/tree-cfg.c
> > @@ -4325,10 +4325,11 @@ verify_gimple_assign_ternary (gassign *stmt)
> >break;
> >
> > case VEC_PERM_EXPR:
> > - if (!useless_type_conversion_p (lhs_type, rhs1_type)
> > - || !useless_type_conversion_p (lhs_type, rhs2_type))
> > + if (TREE_CODE (rhs1_type) != VECTOR_TYPE
> > + || TREE_CODE (rhs2_type) != VECTOR_TYPE
> > + || TREE_CODE (rhs3_type) != VECTOR_TYPE)
> > {
> > - error ("type mismatch in %qs", code_name);
> > + error ("vector types expected in %qs", code_name);
> > debug_generic_expr (lhs_type);
> > debug_generic_expr (rhs1_type);
> > debug_generic_expr (rhs2_type);
> > @@ -4336,11 +4337,14 @@ verify_gimple_assign_ternary (gassign *stmt)
> > return true;
> > }
> >
> > - if (TREE_CODE (rhs1_type) != VECTOR_TYPE
> > - || TREE_CODE (rhs2_type) != VECTOR_TYPE
> > - || TREE_CODE (rhs3_type) != VECTOR_TYPE)
> > + if (TREE_CODE (TREE_TYPE (rhs3_type)) != INTEGER_TYPE
> > + || (TREE_CODE (rhs3) != VECTOR_CST
> > + && (GET_MODE_BITSIZE (SCALAR_INT_TYPE_MODE
> > + (TREE_TYPE (rhs3_type)))
> > + != GET_MODE_BITSIZE (SCALAR_TYPE_MODE
> > + (TREE_TYPE (rhs1_type))
> > {
> > - error ("vector types expected in %qs", code_name);
> > + error ("invalid mask type in %qs", code_name);
> > debug_generic_expr (lhs_type);
> > debug_generic_expr (rhs1_type);
> > debug_generic_expr (rhs2_type);
> > @@ -4348,15 +4352,18 @@ verify_gimple_assign_ternary (gassign *stmt)
> > return true;
> > }
> >
> > - if (maybe_ne (TYPE_VECTOR_SUBPARTS (rhs1_type),
> > - TYPE_VECTOR_SUBPARTS (rhs2_type))
> > - || maybe_ne (TYPE_VECTOR_SUBPARTS (rhs2_type),
> > - TYPE_VECTOR_SUBPARTS (rhs3_type))
> > - || maybe_ne (TYPE_VECTOR_SUBPARTS (rhs3_type),
> > - TYPE_VECTOR_SUBPARTS (lhs_type)))
> > + /* Accept lhs = vec_perm_expr if lhs is vector length
> > agnostic,
> > +and has same element type as v. */
> > + if (!TYPE_VECTOR_SUBPARTS (lhs_type).is_constant ()
> > + && operand_equal_p (rhs1, rhs2, 0)
> > + && TYPE_VECTOR_SUBPARTS (rhs1_type).is_constant ()
> > + && TREE_TYPE (lhs_type) == TREE_TYPE (rhs1_type))
> > + return false;
> > +
> > + if (!useless_type_conversion_p (lhs_type, rhs1_type)
> > + || !useless_type_conversion_p (lhs_type, rhs2_type))
> > {
> > - error ("vectors with different element number found in %qs",
> > -code_name);
> > + error ("type mismatch in %qs", code_name);
> > debug_generic_expr (lhs_type);
> > debug_generic_expr (rhs1_type);
> > debug_generic_expr (rhs2_type);
> > @@ -4364,21 +4371,21 @@ verify_gimple_assign_ternary (gassign *stmt)
> > return true;
> > }
> >
> > - if (TREE_CODE (TREE_TYPE (rhs3_type)) != INTEGER_TYPE
> > - || (TREE_CODE (rhs3) != VECTOR_CST
> > - && (GET_MODE_BITSIZE (SCALAR_INT_TYPE_MODE
> > - (TREE_TYPE (rhs3_type)))
> > - != GET_MODE_BITSIZE (SCALAR_TYPE_MODE
> > - (TREE_TYPE (rhs1_type))
> > + if (maybe_ne (TYPE_VECTOR_SUBPARTS (rhs1_type),
> > + TYPE_VE
Patch ping
Hi! I'd like to ping the middle-end part of the https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586879.html patch (which Uros approved the backend part for with a minor change I have in my tree). Thanks. Jakub
Patch ping
Hi! I'd like to ping the https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html symtab: Fold &a == &b to 0 if folding_initializer [PR94716] patch. Thanks. Jakub
Re: [SVE] PR96463 - Optimise svld1rq from vectors
On Tue, 14 Dec 2021, Prathamesh Kulkarni wrote:
> On Tue, 7 Dec 2021 at 19:08, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > On Thu, 2 Dec 2021 at 23:11, Richard Sandiford
> > > wrote:
> > >>
> > >> Prathamesh Kulkarni writes:
> > >> > Hi Richard,
> > >> > I have attached a WIP untested patch for PR96463.
> > >> > IIUC, the PR suggests to transform
> > >> > lhs = svld1rq ({-1, -1, ...}, &v[0])
> > >> > into:
> > >> > lhs = vec_perm_expr
> > >> > if v is vector of 4 elements, and each element is 32 bits on little
> > >> > endian target ?
> > >> >
> > >> > I am sorry if this sounds like a silly question, but I am not sure how
> > >> > to convert a vector of type int32x4_t into svint32_t ? In the patch, I
> > >> > simply used NOP_EXPR (which I expected to fail), and gave type error
> > >> > during gimple verification:
> > >>
> > >> It should be possible in principle to have a VEC_PERM_EXPR in which
> > >> the operands are Advanced SIMD vectors and the result is an SVE vector.
> > >>
> > >> E.g., the dup in the PR would be something like this:
> > >>
> > >> foo (int32x4_t a)
> > >> {
> > >> svint32_t _2;
> > >>
> > >> _2 = VEC_PERM_EXPR ;
> > >> return _2;
> > >> }
> > >>
> > >> where the final operand can be built using:
> > >>
> > >> int source_nelts = TYPE_VECTOR_SUBPARTS (…rhs type…).to_constant ();
> > >> vec_perm_builder sel (TYPE_VECTOR_SUBPARTS (…lhs type…), source_nelts,
> > >> 1);
> > >> for (int i = 0; i < source_nelts; ++i)
> > >> sel.quick_push (i);
> > >>
> > >> I'm not sure how well-tested that combination is though. It might need
> > >> changes to target-independent code.
> > > Hi Richard,
> > > Thanks for the suggestions.
> > > I tried the above approach in attached patch, but it still results in
> > > ICE due to type mismatch:
> > >
> > > pr96463.c: In function ‘foo’:
> > > pr96463.c:8:1: error: type mismatch in ‘vec_perm_expr’
> > > 8 | }
> > > | ^
> > > svint32_t
> > > int32x4_t
> > > int32x4_t
> > > svint32_t
> > > _3 = VEC_PERM_EXPR ;
> > > during GIMPLE pass: ccp
> > > dump file: pr96463.c.032t.ccp1
> > > pr96463.c:8:1: internal compiler error: verify_gimple failed
> > >
> > > Should we perhaps add another tree code, that "extends" a fixed-width
> > > vector into it's VLA equivalent ?
> >
> > No, I think this is just an extreme example of the combination not being
> > well-tested. :-) Obviously it's worse than I thought.
> >
> > I think accepting this kind of VEC_PERM_EXPR is still the way to go.
> > Richi, WDYT?
> Hi Richi, ping ?
We check
case VEC_PERM_EXPR:
if (!useless_type_conversion_p (lhs_type, rhs1_type)
|| !useless_type_conversion_p (lhs_type, rhs2_type))
{
error ("type mismatch in %qs", code_name);
and LHS is svint32_t while x_4 is int32x4_t (the permutation type
can indeed be different - it needs to be integer for example).
The test is indeed unnecessarily strict if there are two vector
types that are not compatible but have the same element mode and the
same number of elements.
I guess we could check sth like
if (!useless_type_conversion_p (TREE_TYPE (lhs_type), TREE_TYPE
(rhs1_type))
|| !types_compatible_p (rhs1_type, rhs2_type))
instead - we later check TYPE_VECTOR_SUBPARTS so they match. But
note that vec_perm_optab has a single mode only so I'm not sure
what mode we should pick at RTL expansion time for your quoted case
so I'm a bit nervous here. Richard?
Richard.
ChangeLog rotation, copyright year updates
Hi!
In
https://gcc.gnu.org/r12-6176-gd04ae83244d346b95c36c2e3d39918548310f142
https://gcc.gnu.org/r12-6177-g6123f29a18a77eb1a0597f403c4424ae375351fd
https://gcc.gnu.org/r12-6178-gabc1ac2d8d99b7b2846d06ac5a5298ca2f93aedf
https://gcc.gnu.org/r12-6179-g877e3c2abf7a29d746ffda6354d6f19855595905
https://gcc.gnu.org/r12-6180-g5d5db19630ff3b56c91a1c15d12c8167627f9ebe
https://gcc.gnu.org/r12-6181-g7adcbafe45f8001b698967defe682687b52c0007
I've done the usual ChangeLog files rotation (done in 2 steps as last year
due to commit hook restrictions) and copyright year updates.
The only non-standard change was below (due to
gcc/testsuite/gcc.dg/vect/tsvc/license.txt ).
Note, all the visible Copyrights still mention solely FSF and similarly
the copyright year updates were for FSF, with the DCO perhaps that could
change to The GNU Toolchain Authors or so, but I think we don't have any
such copyright notices in the tree at all.
Happy New Year to everyone!
Add University of Illinois as external author
* update-copyright.py: Add University of Illinois as external author.
--- contrib/update-copyright.py
+++ contrib/update-copyright.py
@@ -1,6 +1,6 @@
#!/usr/bin/env python3
#
-# Copyright (C) 2013-2021 Free Software Foundation, Inc.
+# Copyright (C) 2013-2022 Free Software Foundation, Inc.
#
# This script is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -726,6 +726,7 @@ class GCCCopyright (Copyright):
self.add_external_author ('The Regents of the University of
California.')
self.add_external_author ('Ulf Adams')
self.add_external_author ('Unicode, Inc.')
+self.add_external_author ('University of Illinois at
Urbana-Champaign.')
self.add_external_author ('University of Toronto.')
self.add_external_author ('Yoshinori Sato')
Jakub
[PATCH][hooks-bin] Port email_to.py to Python3.
The patch ports the script to Python3. Tested with: $ echo "libstdc++-v3/xx" | ./email_to.py gcc-...@gcc.gnu.org libstdc++-...@gcc.gnu.org May I install it? Thanks, Martin --- email_to.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/email_to.py b/email_to.py index 073b713..f47120c 100755 --- a/email_to.py +++ b/email_to.py @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env python3 import sys -- 2.34.1
[PATCH] tree-optimization/66502 - add testcase
This adds the second testcase which we now also handle eliminating
a redundant PHI node.
Tested on x86_64-unknown-linux-gu.
2022-01-03 Richard Biener
PR tree-optimization/66502
* gcc.dg/tree-ssa/ssa-fre-98.c: New testcase.
---
gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-98.c | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-98.c
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-98.c
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-98.c
new file mode 100644
index 000..3d286099b25
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-98.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-fre1-details" } */
+
+int foo (int a, int s, unsigned int k)
+{
+ int i = a, j = a;
+ do
+{
+ i += s;
+ j += j;
+ j -= a;
+}
+ while (k--);
+ return j+i;
+}
+
+/* We want the redundant PHI for j to disappear. */
+/* { dg-final { scan-tree-dump "Replaced redundant PHI node defining j" "fre1"
} } */
--
2.31.1
[PATCH] Add testcase for PR103615
This adds a testcase for a fixed wrong-code bug.
Tested on x86_64-unknown-linux-gnu, pushed.
2022-01-03 Richard Biener
PR tree-optimization/103615
* gcc.dg/torture/pr103615.c: New testcase.
---
gcc/testsuite/gcc.dg/torture/pr103615.c | 13 +
1 file changed, 13 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/torture/pr103615.c
diff --git a/gcc/testsuite/gcc.dg/torture/pr103615.c
b/gcc/testsuite/gcc.dg/torture/pr103615.c
new file mode 100644
index 000..2109245e622
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr103615.c
@@ -0,0 +1,13 @@
+/* { dg-do run } */
+
+int z = 5;
+int a[6] = { 0, 0, 0, 0, 0, 1 };
+int main()
+{
+ for (int x = 5; x; x--)
+for (int y = z; y >= x; y--)
+ a[y - x] += a[y];
+ if (a[0] != 7)
+__builtin_abort ();
+ return 0;
+}
--
2.31.1
