[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #6 from Jakub Jelinek --- That doesn't make sense. -fsanitize=signed-integer-overflow also removes that undefined behavior by defining what happens on signed integer overflow, one can choose whether to get a non-fatal runtime diagnostic + wrapv behavior, or fatal runtime diagnostic, or just abort. So, when you use -fsanitize=signed-integer-overflow, you don't want -fwrapv or -fno-strict-overflow, unless you want the former to be basically a nop.
[Bug rtl-optimization/69689] gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689 Andrew Pinski changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 86744 has been marked as a duplicate of this bug. ***
[Bug target/86744] gcc.target/i386/addr-sel-1.c XPASSes on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86744 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 69689. *** This bug has been marked as a duplicate of bug 69689 ***
[Bug target/69274] [6 Regression] 435.gromacs performance regression after r231814 on x86 Haswell and bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274 Bug 69274 depends on bug 69689, which changed state. Bug 69689 Summary: gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/69689] gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- So allowing 2->2 combine before RA fixes this testcase, r9-2064 which is exactly as I had expected.
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 luoxhu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from luoxhu at gcc dot gnu.org --- Fixed on master and backported to gcc-11 and gcc-10.
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #21 from CVS Commits --- The releases/gcc-10 branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:68d525ee859041b21d87b23030d1e829a9cc3b6f commit r10-10116-g68d525ee859041b21d87b23030d1e829a9cc3b6f Author: Xionghu Luo Date: Mon Sep 6 20:22:50 2021 -0500 rs6000: Expand fmod and remainder when built with fast-math [PR97142] fmod/fmodf and remainder/remainderf could be expanded instead of library call when fast-math build, which is much faster. fmodf: fdivs f0,f1,f2 frizf0,f0 fnmsubs f1,f2,f0,f1 remainderf: fdivs f0,f1,f2 frinf0,f0 fnmsubs f1,f2,f0,f1 SPEC2017 Ofast P8LE: 511.povray_r +1.14%, 526.blender_r +1.72% gcc/ChangeLog: 2021-09-07 Xionghu Luo PR target/97142 * config/rs6000/rs6000.md (fmod3): New define_expand. (remainder3): Likewise. gcc/testsuite/ChangeLog: 2021-09-07 Xionghu Luo PR target/97142 * gcc.target/powerpc/pr97142.c: New test. (cherry picked from commit 546ecb0054af302acf0839c7f3eb78598f8c0672)
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #20 from CVS Commits --- The releases/gcc-11 branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:a87d7fbef55f72781905bffb298aab698fe6ed40 commit r11-8985-ga87d7fbef55f72781905bffb298aab698fe6ed40 Author: Xionghu Luo Date: Mon Sep 6 20:22:50 2021 -0500 rs6000: Expand fmod and remainder when built with fast-math [PR97142] fmod/fmodf and remainder/remainderf could be expanded instead of library call when fast-math build, which is much faster. fmodf: fdivs f0,f1,f2 frizf0,f0 fnmsubs f1,f2,f0,f1 remainderf: fdivs f0,f1,f2 frinf0,f0 fnmsubs f1,f2,f0,f1 SPEC2017 Ofast P8LE: 511.povray_r +1.14%, 526.blender_r +1.72% gcc/ChangeLog: 2021-09-07 Xionghu Luo PR target/97142 * config/rs6000/rs6000.md (fmod3): New define_expand. (remainder3): Likewise. gcc/testsuite/ChangeLog: 2021-09-07 Xionghu Luo PR target/97142 * gcc.target/powerpc/pr97142.c: New test. (cherry-picked from 546ecb0054af302acf0839c7f3eb78598f8c0672)
[Bug middle-end/102316] Unexpected stringop-overflow Warnings on POWER CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
Tee KOBAYASHI changed:
What|Removed |Added
CC||xtkoba at gmail dot com
--- Comment #2 from Tee KOBAYASHI ---
A workaround would be to __builtin_unreachable(), as usual:
@@ -9,6 +9,7 @@
char* b;
int p() {
+ if (a > LEN) __builtin_unreachable();
for (int i = 0; i < a; i++) {
d.c[i] = b[i];
}
[PATCH v3] c++: Fix cp_tree_equal for template value args using dependent sizeof/alignof/noexcept expressions
I reworked the fix today based on feedback from Jason and Jakub (thank
you), and the subject line is now outdated. I added another test for a
closely related bug that's also fixed here (dependent-expr11.C -- this one
would even fail without the second declaration). All the new tests in the
patch succeed with the change (only two of them succeed with trunk). On my
box, the bootstrap succeeds, the g++ test suite passes (matching today's
posted results anyway), and the libstdc++ test suite is looking good but is
still running after a long time. I'll leave the full "make check" running
overnight.
Some potentially controversial changes here:
1. Adding new bool member to cp_parser. I'd like to avoid this, any tips?
2. Relaxing an assert in tsubst_copy. This change feels correct to me, but
maybe I'm missing something.
3. Pushing a function scope in PARM_DECL case in tsubst_copy_and_build to
make process_outer_var_ref happy for trailing return types. I don't yet
fully appreciate the consequences of these changes, so this needs some eyes.
4. Traversing each template arg's tree in
any_template_arguments_need_structural_equality_p to identify dependent
expressions in trailing return types. This could probably be done better. I
check current_function_decl here as an optimization (since it's NULL in the
only place that "needs" this), but that seems brittle. Also, the new
find_dependent_parm_decl_r callback implementation may have the unintended
consequence of forcing structural comparison on member function trailing
return types that depend on class template parameters. I think I really
only want to force structural comparison for "arg tree has a dependent parm
decl and we're in a trailing return type" -- is there a better way to do
this?
Also note that I found another related bug which I have not yet solved:
template
struct foo {
constexpr operator int() { return i; }
};
void bar() {
[](auto i) -> foo {
return {};
}(foo<1>{});
}
With the attached patch, failure occurs at invocation, while trunk fails to
parse the return type. This seems like a step in the right direction, but
we should consider whether such an incomplete fix introduces more issues
than it solves (e.g. unfriendlier error messages, or perhaps something more
sinister).
Thanks,
Barrett
From 0470bdc5b2b4ddff2d2ee9db11a8c5895abda50f Mon Sep 17 00:00:00 2001
From: Barrett Adair
Date: Fri, 20 Aug 2021 15:37:36 -0500
Subject: [PATCH] Fix trailing return type bugs
---
gcc/cp/cp-tree.h | 2 +-
gcc/cp/parser.c | 13 -
gcc/cp/parser.h | 3 +
gcc/cp/pt.c | 58 +--
gcc/cp/semantics.c| 9 ++-
gcc/testsuite/g++.dg/template/canon-type-15.C | 7 +++
gcc/testsuite/g++.dg/template/canon-type-16.C | 6 ++
gcc/testsuite/g++.dg/template/canon-type-17.C | 5 ++
gcc/testsuite/g++.dg/template/canon-type-18.C | 6 ++
.../g++.dg/template/dependent-expr11.C| 6 ++
.../g++.dg/template/dependent-name15.C| 18 ++
.../g++.dg/template/dependent-name16.C| 14 +
12 files changed, 136 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/template/canon-type-15.C
create mode 100644 gcc/testsuite/g++.dg/template/canon-type-16.C
create mode 100644 gcc/testsuite/g++.dg/template/canon-type-17.C
create mode 100644 gcc/testsuite/g++.dg/template/canon-type-18.C
create mode 100644 gcc/testsuite/g++.dg/template/dependent-expr11.C
create mode 100644 gcc/testsuite/g++.dg/template/dependent-name15.C
create mode 100644 gcc/testsuite/g++.dg/template/dependent-name16.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index a82747ca627..b93455aebff 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7537,7 +7537,7 @@ extern tree process_outer_var_ref (tree, tsubst_flags_t, bool force_use = false
extern cp_expr finish_id_expression (tree, tree, tree,
cp_id_kind *,
bool, bool, bool *,
- bool, bool, bool, bool,
+ bool, bool, bool, bool, bool,
const char **,
location_t);
extern tree finish_typeof (tree);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e44c5c6b57c..4b95103eb2b 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6011,7 +6011,8 @@ cp_parser_primary_expression (cp_parser *parser,
parser->integral_constant_expression_p,
parser->allow_non_integral_constant_expression_p,
>non_integral_constant_expression_p,
- template_p, done, address_p,
+ template_p, parser->in_trailing_return_type_p,
+ done, address_p,
template_arg_p,
_msg,
id_expression.get_location ()));
@@ -11256,6 +11257,7 @@ cp_parser_lambda_introducer (cp_parser* parser, tree lambda_expr)
/*allow_non_integral_constant_expression_p=*/false,
/*non_integral_constant_expression_p=*/NULL,
/*template_p=*/false,
[Bug testsuite/21496] more flexible dg-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21496 --- Comment #2 from Andrew Pinski --- So I think this testcase was fixed in two different ways. First was by using dg-excess-errors for the testcase which was introduced by r0-98409 to testcase. And then fixed with r0-109419 for GCC 4.7.0 where the libstdc++ testsuite will prune all of "notes:" now unless you use dg-prune-output. Also it looks like a linenum of 0 will match all lines num now too. Also in the main GCC testsuite (I don't know if it applies to the libstdc++ testsuite) you can use relative line numbers now too.
Re: [PATCH 16/62] AVX512FP16: Add vsqrtph/vrsqrtph/vsqrtsh/vrsqrtsh.
i'm going to commit 8 patches:
[PATCH 16/62] AVX512FP16: Add vsqrtph/vrsqrtph/vsqrtsh/vrsqrtsh.
[PATCH 17/62] AVX512FP16: Add testcase for vsqrtph/vsqrtsh/vrsqrtph/vrsqrtsh.
[PATCH 18/62] AVX512FP16: Add vrcpph/vrcpsh/vscalefph/vscalefsh.
[PATCH 19/62] AVX512FP16: Add testcase for vrcpph/vrcpsh/vscalefph/vscalefsh.
[PATCH 20/62] AVX512FP16: Add vreduceph/vreducesh/vrndscaleph/vrndscalesh.
[PATCH 21/62] AVX512FP16: Add testcase for
vreduceph/vreducesh/vrndscaleph/vrndscalesh.
[PATCH 22/62] AVX512FP16: Add fpclass/getexp/getmant instructions.
[PATCH 23/62] AVX512FP16: Add testcase for fpclass/getmant/getexp instructions.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Newly added tests passed on SPR.
On Thu, Jul 1, 2021 at 2:17 PM liuhongt wrote:
>
> gcc/ChangeLog:
>
> * config/i386/avx512fp16intrin.h: (_mm512_sqrt_ph):
> New intrinsic.
> (_mm512_mask_sqrt_ph): Likewise.
> (_mm512_maskz_sqrt_ph): Likewise.
> (_mm512_sqrt_round_ph): Likewise.
> (_mm512_mask_sqrt_round_ph): Likewise.
> (_mm512_maskz_sqrt_round_ph): Likewise.
> (_mm512_rsqrt_ph): Likewise.
> (_mm512_mask_rsqrt_ph): Likewise.
> (_mm512_maskz_rsqrt_ph): Likewise.
> (_mm_rsqrt_sh): Likewise.
> (_mm_mask_rsqrt_sh): Likewise.
> (_mm_maskz_rsqrt_sh): Likewise.
> (_mm_sqrt_sh): Likewise.
> (_mm_mask_sqrt_sh): Likewise.
> (_mm_maskz_sqrt_sh): Likewise.
> (_mm_sqrt_round_sh): Likewise.
> (_mm_mask_sqrt_round_sh): Likewise.
> (_mm_maskz_sqrt_round_sh): Likewise.
> * config/i386/avx512fp16vlintrin.h (_mm_sqrt_ph): New intrinsic.
> (_mm256_sqrt_ph): Likewise.
> (_mm_mask_sqrt_ph): Likewise.
> (_mm256_mask_sqrt_ph): Likewise.
> (_mm_maskz_sqrt_ph): Likewise.
> (_mm256_maskz_sqrt_ph): Likewise.
> (_mm_rsqrt_ph): Likewise.
> (_mm256_rsqrt_ph): Likewise.
> (_mm_mask_rsqrt_ph): Likewise.
> (_mm256_mask_rsqrt_ph): Likewise.
> (_mm_maskz_rsqrt_ph): Likewise.
> (_mm256_maskz_rsqrt_ph): Likewise.
> * config/i386/i386-builtin-types.def: Add corresponding builtin types.
> * config/i386/i386-builtin.def: Add corresponding new builtins.
> * config/i386/i386-expand.c
> (ix86_expand_args_builtin): Handle new builtins.
> (ix86_expand_round_builtin): Ditto.
> * config/i386/sse.md (VF_AVX512FP16VL): New.
> (sqrt2): Adjust for HF vector modes.
> (_sqrt2): Likewise.
> (_vmsqrt2):
> Likewise.
> (_rsqrt2): New.
> (avx512fp16_vmrsqrtv8hf2): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/avx-1.c: Add test for new builtins.
> * gcc.target/i386/sse-13.c: Ditto.
> * gcc.target/i386/sse-23.c: Ditto.
> * gcc.target/i386/sse-14.c: Add test for new intrinsics.
> * gcc.target/i386/sse-22.c: Ditto.
> ---
> gcc/config/i386/avx512fp16intrin.h | 193 +
> gcc/config/i386/avx512fp16vlintrin.h | 93
> gcc/config/i386/i386-builtin-types.def | 4 +
> gcc/config/i386/i386-builtin.def | 8 +
> gcc/config/i386/i386-expand.c | 4 +
> gcc/config/i386/sse.md | 44 --
> gcc/testsuite/gcc.target/i386/avx-1.c | 2 +
> gcc/testsuite/gcc.target/i386/sse-13.c | 2 +
> gcc/testsuite/gcc.target/i386/sse-14.c | 6 +
> gcc/testsuite/gcc.target/i386/sse-22.c | 6 +
> gcc/testsuite/gcc.target/i386/sse-23.c | 2 +
> 11 files changed, 355 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/config/i386/avx512fp16intrin.h
> b/gcc/config/i386/avx512fp16intrin.h
> index ed8ad84a105..50db5d12140 100644
> --- a/gcc/config/i386/avx512fp16intrin.h
> +++ b/gcc/config/i386/avx512fp16intrin.h
> @@ -1235,6 +1235,199 @@ _mm_comi_round_sh (__m128h __A, __m128h __B, const
> int __P, const int __R)
>
> #endif /* __OPTIMIZE__ */
>
> +/* Intrinsics vsqrtph. */
> +extern __inline __m512h
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +_mm512_sqrt_ph (__m512h __A)
> +{
> + return __builtin_ia32_vsqrtph_v32hf_mask_round (__A,
> + _mm512_setzero_ph(),
> + (__mmask32) -1,
> + _MM_FROUND_CUR_DIRECTION);
> +}
> +
> +extern __inline __m512h
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +_mm512_mask_sqrt_ph (__m512h __A, __mmask32 __B, __m512h __C)
> +{
> + return __builtin_ia32_vsqrtph_v32hf_mask_round (__C, __A, __B,
> + _MM_FROUND_CUR_DIRECTION);
> +}
> +
> +extern __inline __m512h
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +_mm512_maskz_sqrt_ph (__mmask32 __A, __m512h __B)
> +{
> + return __builtin_ia32_vsqrtph_v32hf_mask_round (__B,
> +
[Bug middle-end/21132] gensupport mistreats match_code split with an ior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132 --- Comment #5 from Andrew Pinski --- (In reply to Hans-Peter Nilsson from comment #4) > (In reply to Andrew Pinski from comment #2) > > >1. While working on this I noticed that genpreds treats > > > > Fixed/changed with r6-1344. > > > > > > I think that is the only ask in this bug report, is that correct? > > (Yes, AFAIR.) > > (In reply to Andrew Pinski from comment #3) > > (In reply to Andrew Pinski from comment #2) > > > >1. While working on this I noticed that genpreds treats > > > > > > Fixed/changed with r6-1344. > > > > https://gcc.gnu.org/pipermail/gcc-patches/2015-May/420317.html > > Wow, you should get some kind of prize for that archeology session! > Beer is offered as a consolation prize, if we ever meet in person again and > it's not banned by then or nonapplicable for other reasons. > > Thanks, closing this. You are welcome, I just trying to clean up old bug reports, especially ones which have not been touched in a while. This was one of the easier archeology sessions really.
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 9/13/21 11:07 AM, Tobias Burnus wrote:
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote: >>> Wouldn't it be better to use the
__LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type, but what the compiler knows about it.
I originally wrote the code to use the internal GCC __LDBL_* macros as
you suggest, but Tobias complained that then the gfortran-provided .h
file could not be used to compile the C parts of the program with some
other C compiler.
For instance, clang does not seem to provide those - and in some cases,
it can be useful to mix gfortran code with code complied by other
compilers (icc, clang, ...).
Maybe it needs to first check the internal macros and then look for
the float.h versions if it can't find them?
I think that makes sense. (Adding a comment that #include is
for non-GCC compilers, only.)
Here's a patch. Gerald, can you check that this fixes your bootstrap
problem on i586-unknown-freebsd11?
-Sandra
commit b8b19bca743ed678ef1b59f1a363c7fa7d155c43
Author: Sandra Loosemore
Date: Mon Sep 13 19:48:16 2021 -0700
Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h.
2021-09-13 Sandra Loosemore
libgfortran/
* ISO_Fortran_binding.h: Only include float.h if the C compiler
doesn't have predefined __LDBL_* and __DBL_* macros.
diff --git a/libgfortran/ISO_Fortran_binding.h b/libgfortran/ISO_Fortran_binding.h
index 9c42464..a3c6f80 100644
--- a/libgfortran/ISO_Fortran_binding.h
+++ b/libgfortran/ISO_Fortran_binding.h
@@ -32,7 +32,6 @@ extern "C" {
#include /* Standard ptrdiff_t tand size_t. */
#include /* Integer types. */
-#include /* Macros for floating-point type characteristics. */
/* Constants, defined as macros. */
#define CFI_VERSION 1
@@ -217,40 +216,82 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, const CFI_index_t []);
#endif
/* The situation with long double support is more complicated; we need to
- examine the type in more detail to figure out its kind. */
+ examine the type in more detail to figure out its kind.
+ GCC and some other compilers predefine the __LDBL* macros; otherwise
+ get the parameters we need from float.h. */
+
+#if (defined (__LDBL_MANT_DIG__) \
+ && defined (__LDBL_MIN_EXP__) \
+ && defined (__LDBL_MAX_EXP__) \
+ && defined (__DBL_MANT_DIG__) \
+ && defined (__DBL_MIN_EXP__) \
+ && defined (__DBL_MAX_EXP__))
+#define __CFI_LDBL_MANT_DIG__ __LDBL_MANT_DIG__
+#define __CFI_LDBL_MIN_EXP__ __LDBL_MIN_EXP__
+#define __CFI_LDBL_MAX_EXP__ __LDBL_MAX_EXP__
+#define __CFI_DBL_MANT_DIG__ __DBL_MANT_DIG__
+#define __CFI_DBL_MIN_EXP__ __DBL_MIN_EXP__
+#define __CFI_DBL_MAX_EXP__ __DBL_MAX_EXP__
+
+#else
+#include
+
+#if (defined (LDBL_MANT_DIG) \
+ && defined (LDBL_MIN_EXP) \
+ && defined (LDBL_MAX_EXP) \
+ && defined (DBL_MANT_DIG) \
+ && defined (DBL_MIN_EXP) \
+ && defined (DBL_MAX_EXP))
+#define __CFI_LDBL_MANT_DIG__ LDBL_MANT_DIG
+#define __CFI_LDBL_MIN_EXP__ LDBL_MIN_EXP
+#define __CFI_LDBL_MAX_EXP__ LDBL_MAX_EXP
+#define __CFI_DBL_MANT_DIG__ DBL_MANT_DIG
+#define __CFI_DBL_MIN_EXP__ DBL_MIN_EXP
+#define __CFI_DBL_MAX_EXP__ DBL_MAX_EXP
+
+#else
+#define CFI_no_long_double 1
+
+#endif /* Definitions from float.h. */
+#endif /* Definitions from compiler builtins. */
+
+/* Can't determine anything about long double support? */
+#if (defined (CFI_no_long_double))
+#define CFI_type_long_double -2
+#define CFI_type_long_double_Complex -2
/* Long double is the same kind as double. */
-#if (LDBL_MANT_DIG == DBL_MANT_DIG \
- && LDBL_MIN_EXP == DBL_MIN_EXP \
- && LDBL_MAX_EXP == DBL_MAX_EXP)
+#elif (__CFI_LDBL_MANT_DIG__ == __CFI_DBL_MANT_DIG__ \
+ && __CFI_LDBL_MIN_EXP__ == __CFI_DBL_MIN_EXP__ \
+ && __CFI_LDBL_MAX_EXP__ == __CFI_DBL_MAX_EXP__)
#define CFI_type_long_double CFI_type_double
#define CFI_type_long_double_Complex CFI_type_double_Complex
/* This is the 80-bit encoding on x86; Fortran assigns it kind 10. */
-#elif (LDBL_MANT_DIG == 64 \
- && LDBL_MIN_EXP == -16381 \
- && LDBL_MAX_EXP == 16384)
+#elif (__CFI_LDBL_MANT_DIG__ == 64 \
+ && __CFI_LDBL_MIN_EXP__ == -16381 \
+ && __CFI_LDBL_MAX_EXP__ == 16384)
#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift))
/* This is the 96-bit encoding on m68k; Fortran assigns it kind 10. */
-#elif (LDBL_MANT_DIG == 64 \
- && LDBL_MIN_EXP == -16382 \
- && LDBL_MAX_EXP == 16384)
+#elif (__CFI_LDBL_MANT_DIG__ == 64 \
+ && __CFI_LDBL_MIN_EXP__ == -16382 \
+ && __CFI_LDBL_MAX_EXP__ == 16384)
#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift))
/* This is the IEEE 128-bit
[Bug middle-end/21132] gensupport mistreats match_code split with an ior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #2) > >1. While working on this I noticed that genpreds treats > > Fixed/changed with r6-1344. > > > I think that is the only ask in this bug report, is that correct? (Yes, AFAIR.) (In reply to Andrew Pinski from comment #3) > (In reply to Andrew Pinski from comment #2) > > >1. While working on this I noticed that genpreds treats > > > > Fixed/changed with r6-1344. > > https://gcc.gnu.org/pipermail/gcc-patches/2015-May/420317.html Wow, you should get some kind of prize for that archeology session! Beer is offered as a consolation prize, if we ever meet in person again and it's not banned by then or nonapplicable for other reasons. Thanks, closing this.
PING^2: [RFC] Whole Program Devirtualization
Ping again. Thanks, Feng From: Feng Xue OS Sent: Wednesday, September 1, 2021 9:46 AM To: Martin Liška; Jan Hubicka; gcc@gcc.gnu.org Cc: JiangNing OS Subject: PING: [RFC] Whole Program Devirtualization Honza, How do you think about proposal in this RFC? Thanks a lot. Best Regards, Feng From: Martin Liška Sent: Friday, August 20, 2021 9:45 PM To: Feng Xue OS; gcc@gcc.gnu.org Cc: JiangNing OS; Jan Hubicka Subject: Re: [RFC] Whole Program Devirtualization ... adding Honza to CC who spent quite some time on devirtualization pass. Martin
Re: [PATCH] i386: Fix up @xorsign3_1 [PR102224]
On Tue, Sep 14, 2021 at 10:06 AM Hongtao Liu wrote:
>
> On Tue, Sep 14, 2021 at 8:58 AM Andrew Pinski wrote:
> >
> > On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
> > wrote:
> > >
> > > On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > > > >
> > > > > Patch LGTM.
> > > >
> > > > Thanks, committed.
> > > >
> > > > > PS:
> > > > > I'm curious why we need the post_reload splitter @xorsign3_1
> > > > > for scalar mode, can't we just expand them into and/xor operations in
> > > > > the expander, just like vector modes did.
> > > > > Let me do some experiments to see whether it is ok to remove the
> > > > > splitter.
> > > >
> > > > I bet it is the question how should the code look like before RA.
> > > > stv is somewhat related, but as that replaces whole chains, it can do:
> > > > (insn 14 5 6 2 (set (subreg:V2DI (reg:DI 92) 0)
> > > > (vec_concat:V2DI (mem/c:DI (symbol_ref:SI ("c") [flags 0x2]
> > > > ) [1 c+0 S8 A64])
> > > > (const_int 0 [0]))) "hohohou.c":6:9 -1
> > > > (nil))
> > > > on loads of memory.
> > > > But it stv still does use paradoxical subregs:
> > > > (insn 10 16 11 2 (set (subreg:V2DI (reg:DI 91) 0)
> > > > (minus:V2DI (subreg:V2DI (reg:DI 87) 0)
> > > > (subreg:V2DI (reg:DI 94) 0))) "hohohou.c":6:13 5003
> > > > {*subv2di3}
> > > > (expr_list:REG_DEAD (reg:DI 87)
> > > > (expr_list:REG_UNUSED (reg:CC 17 flags)
> > > > (nil
> > > > (insn 11 10 0 2 (set (mem/c:DI (symbol_ref:SI ("a") [flags 0x2]
> > > > ) [1 a+0 S8 A64])
> > > > (reg:DI 91)) "hohohou.c":6:5 76 {*movdi_internal}
> > > > (expr_list:REG_DEAD (reg:DI 91)
> > > > (nil)))
> > > > so perhaps just using paradoxical subregs everywhere would be ok?
> > > Yes, I think so.
> > > And I find paradoxical subreg like (subreg:V4SF (reg:SF)) are not
> > > allowed by validate_subreg until r11-621.
> > > That's why post_reload splitter is needed here.
> >
> > That is not exactly true. It has been around since before 2005. See
> > https://gcc.gnu.org/PR24436 which is referencing the fixme comment in
> > validate_subreg.
> We also have things like (subreg:V4SF(reg:V2SF) 0), the problem of
> defining post_reload splitter with V2SF is movv2sf is only defined
> under TARGET_64BIT if there's no mmx(so should we also enable 64-bit
> vector 32-bit mode?).
> And for xorsign w/o post_reload splitter, the code is cleaner and even
> more optimal.
And if we allow something like subreg:V4SF (reg:TI), it seems we could
have something like
mov reg:SI, subreg:SI (reg:SF)
mov reg:TI, subreg:TI (reg:SI)
mov reg:V4SF, subreg:V4SF (reg:TI)
> >
> > Thanks,
> > Andrew Pinski
> >
> > Thanks,
> > Andrew Pinski
> >
> > > > Jakub
> > > >
> > >
> > >
> > >
> > > --
> > > BR,
> > > Hongtao
>
>
>
> --
> BR,
> Hongtao
--
BR,
Hongtao
Re: [PATCH] i386: Fix up @xorsign3_1 [PR102224]
On Tue, Sep 14, 2021 at 8:58 AM Andrew Pinski wrote:
>
> On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> > >
> > > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > > >
> > > > Patch LGTM.
> > >
> > > Thanks, committed.
> > >
> > > > PS:
> > > > I'm curious why we need the post_reload splitter @xorsign3_1
> > > > for scalar mode, can't we just expand them into and/xor operations in
> > > > the expander, just like vector modes did.
> > > > Let me do some experiments to see whether it is ok to remove the
> > > > splitter.
> > >
> > > I bet it is the question how should the code look like before RA.
> > > stv is somewhat related, but as that replaces whole chains, it can do:
> > > (insn 14 5 6 2 (set (subreg:V2DI (reg:DI 92) 0)
> > > (vec_concat:V2DI (mem/c:DI (symbol_ref:SI ("c") [flags 0x2]
> > > ) [1 c+0 S8 A64])
> > > (const_int 0 [0]))) "hohohou.c":6:9 -1
> > > (nil))
> > > on loads of memory.
> > > But it stv still does use paradoxical subregs:
> > > (insn 10 16 11 2 (set (subreg:V2DI (reg:DI 91) 0)
> > > (minus:V2DI (subreg:V2DI (reg:DI 87) 0)
> > > (subreg:V2DI (reg:DI 94) 0))) "hohohou.c":6:13 5003
> > > {*subv2di3}
> > > (expr_list:REG_DEAD (reg:DI 87)
> > > (expr_list:REG_UNUSED (reg:CC 17 flags)
> > > (nil
> > > (insn 11 10 0 2 (set (mem/c:DI (symbol_ref:SI ("a") [flags 0x2]
> > > ) [1 a+0 S8 A64])
> > > (reg:DI 91)) "hohohou.c":6:5 76 {*movdi_internal}
> > > (expr_list:REG_DEAD (reg:DI 91)
> > > (nil)))
> > > so perhaps just using paradoxical subregs everywhere would be ok?
> > Yes, I think so.
> > And I find paradoxical subreg like (subreg:V4SF (reg:SF)) are not
> > allowed by validate_subreg until r11-621.
> > That's why post_reload splitter is needed here.
>
> That is not exactly true. It has been around since before 2005. See
> https://gcc.gnu.org/PR24436 which is referencing the fixme comment in
> validate_subreg.
We also have things like (subreg:V4SF(reg:V2SF) 0), the problem of
defining post_reload splitter with V2SF is movv2sf is only defined
under TARGET_64BIT if there's no mmx(so should we also enable 64-bit
vector 32-bit mode?).
And for xorsign w/o post_reload splitter, the code is cleaner and even
more optimal.
>
> Thanks,
> Andrew Pinski
>
> Thanks,
> Andrew Pinski
>
> > > Jakub
> > >
> >
> >
> >
> > --
> > BR,
> > Hongtao
--
BR,
Hongtao
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 --- Comment #13 from Bart Van Assche --- Hi H.J. Lu, thank you for having taken a look. I would like to try your patch. However, I'm not a gcc developer so I don't have a gcc tree checked out on my development workstation. It may take some time before I can test the patch that you shared.
[Bug middle-end/21132] gensupport mistreats match_code split with an ior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > >1. While working on this I noticed that genpreds treats > > Fixed/changed with r6-1344. https://gcc.gnu.org/pipermail/gcc-patches/2015-May/420317.html
[Bug middle-end/21132] gensupport mistreats match_code split with an ior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132 --- Comment #2 from Andrew Pinski --- >1. While working on this I noticed that genpreds treats Fixed/changed with r6-1344. I think that is the only ask in this bug report, is that correct?
[Bug tree-optimization/102075] fill_always_executed_in_1 incomplete computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102075 luoxhu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from luoxhu at gcc dot gnu.org --- Fixed by Richard’s r12-3313, r12-3429 and r12-3430.
Re: [PATCH] tree-optimization/102155 - fix LIM fill_always_executed_in CFG walk
On 2021/9/13 16:17, Richard Biener wrote:
On Mon, 13 Sep 2021, Xionghu Luo wrote:
On 2021/9/10 21:54, Xionghu Luo via Gcc-patches wrote:
On 2021/9/9 18:55, Richard Biener wrote:
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 5d6845478e7..4b187c2cdaf 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -3074,15 +3074,13 @@ fill_always_executed_in_1 (class loop *loop,
sbitmap contains_call)
break;
if (bb->loop_father->header == bb)
- {
- if (!dominated_by_p (CDI_DOMINATORS, loop->latch, bb))
- break;
-
- /* In a loop that is always entered we may proceed anyway.
- But record that we entered it and stop once we leave it
- since it might not be finite. */
- inn_loop = bb->loop_father;
- }
+ /* Record that we enter into a subloop since it might not
+ be finite. */
+ /* ??? Entering into a not always executed subloop makes
+ fill_always_executed_in quadratic in loop depth since
+ we walk those loops N times. This is not a problem
+ in practice though, see PR102253 for a worst-case testcase. */
+ inn_loop = bb->loop_father;
Yes your two patches extracted the get_loop_body_in_dom_order out and
removed
the inn_loop break logic when it doesn't dominate outer loop. Confirmed the
replacement
could improve for saving ~10% build time due to not full DOM walker and
marked the previously
ignored ALWAYS_EXECUTED bbs.
But if we don't break for inner loop again, why still keep the *inn_loop*
variable?
It seems unnecessary and confusing, could we just remove it and restore the
original
infinte loop check in bb->succs for better understanding?
What's more, the refine of this fix is incorrect for PR78185.
commit 483e400870601f650c80f867ec781cd5f83507d6
Author: Richard Biener
Date: Thu Sep 2 10:47:35 2021 +0200
Refine fix for PR78185, improve LIM for code after inner loops
This refines the fix for PR78185 after understanding that the code
regarding to the comment 'In a loop that is always entered we may
proceed anyway. But record that we entered it and stop once we leave
it.' was supposed to protect us from leaving possibly infinite inner
loops. The simpler fix of moving the misplaced stopping code
can then be refined to continue processing when the exited inner
loop is finite, improving invariant motion for cases like in the
added testcase.
2021-09-02 Richard Biener
* tree-ssa-loop-im.c (fill_always_executed_in_1): Refine
fix for PR78185 and continue processing when leaving
finite inner loops.
* gcc.dg/tree-ssa/ssa-lim-16.c: New testcase.
3<---
||
6<---|
| \ | |
| \ | |
48 |
|--- |
| | |
5 7--
|
1
loop 2 is an infinite loop, it is only ALWAYS_EXECUTED for loop 2,
but r12-3313-g483e40087 sets it ALWAYS_EXECUTED for loop 1.
We need to restore it like this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579195.html
I don't understand - BB6 is the header block of loop 2 which is
always entered and thus BB6 is always executed at least once.
The important part is that BB4 which follows the inner loop is
_not_ always executed because we don't know if we will exit the
inner loop.
What am I missing?
Oh, I see. I only noticed the functionality change of the patch on the case
and no failure check of it, misunderstood it was a regression instead of an
improvement to also hoisting invariants from infinite loop, sorry about that.
Finally, the function fill_always_executed_in_1 could mark all ALWAYS_EXECUTED
bb both including and after all subloops' bb but break after exiting from
infinite subloops with better performance, thanks. The only thing to be
worried is replacing get_loop_body_in_dom_order makes the code a bit more
complicated for later readers as the loop depth and DOM order is not a problem
here any more? ;)
Richard.
--
Thanks,
Xionghu
Re: [PATCH] i386: Fix up @xorsign3_1 [PR102224]
On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> >
> > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > >
> > > Patch LGTM.
> >
> > Thanks, committed.
> >
> > > PS:
> > > I'm curious why we need the post_reload splitter @xorsign3_1
> > > for scalar mode, can't we just expand them into and/xor operations in
> > > the expander, just like vector modes did.
> > > Let me do some experiments to see whether it is ok to remove the splitter.
> >
> > I bet it is the question how should the code look like before RA.
> > stv is somewhat related, but as that replaces whole chains, it can do:
> > (insn 14 5 6 2 (set (subreg:V2DI (reg:DI 92) 0)
> > (vec_concat:V2DI (mem/c:DI (symbol_ref:SI ("c") [flags 0x2]
> > ) [1 c+0 S8 A64])
> > (const_int 0 [0]))) "hohohou.c":6:9 -1
> > (nil))
> > on loads of memory.
> > But it stv still does use paradoxical subregs:
> > (insn 10 16 11 2 (set (subreg:V2DI (reg:DI 91) 0)
> > (minus:V2DI (subreg:V2DI (reg:DI 87) 0)
> > (subreg:V2DI (reg:DI 94) 0))) "hohohou.c":6:13 5003 {*subv2di3}
> > (expr_list:REG_DEAD (reg:DI 87)
> > (expr_list:REG_UNUSED (reg:CC 17 flags)
> > (nil
> > (insn 11 10 0 2 (set (mem/c:DI (symbol_ref:SI ("a") [flags 0x2] > 0x7f65a131fc60 a>) [1 a+0 S8 A64])
> > (reg:DI 91)) "hohohou.c":6:5 76 {*movdi_internal}
> > (expr_list:REG_DEAD (reg:DI 91)
> > (nil)))
> > so perhaps just using paradoxical subregs everywhere would be ok?
> Yes, I think so.
> And I find paradoxical subreg like (subreg:V4SF (reg:SF)) are not
> allowed by validate_subreg until r11-621.
> That's why post_reload splitter is needed here.
That is not exactly true. It has been around since before 2005. See
https://gcc.gnu.org/PR24436 which is referencing the fixme comment in
validate_subreg.
Thanks,
Andrew Pinski
Thanks,
Andrew Pinski
> > Jakub
> >
>
>
>
> --
> BR,
> Hongtao
Delivery report
Hello, this is the mail server on server.hiteutomotive.com. I am sending you this message to inform you on the delivery status of a message you previously sent. Immediately below you will find a list of the affected recipients; also attached is a Delivery Status Notification (DSN) report in standard format, as well as the headers of the original message. delivery failed; will not continue trying Reporting-MTA: dns;server.hiteutomotive.com X-PowerMTA-VirtualMTA: pmta-vmta1 Received-From-MTA: dns;mindspring.com (77.247.110.186) Arrival-Date: Mon, 13 Sep 2021 20:46:27 -0400 Final-Recipient: rfc822;gcc@gcc.gnu.org Action: failed Status: 5.7.1 (delivery not authorized) Remote-MTA: dns;gcc.gnu.org (8.43.85.97) Diagnostic-Code: smtp;550 5.7.1 Blocked by SpamAssassin X-PowerMTA-BounceCategory: spam-related DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=dkim; d=gcc.gnu.org; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; i=gcc@gcc.gnu.org; bh=w8YYKsLrBIudZmmePUMxUaCMxuha37vzNQ/S5fE5zOU=; b=GI6vMhZ1o3+EEs3iRLaItEoL3He8KGiPtTdE0xfX/LJpX7voMuj7WY19/DpXRwcy0Tm8kV/qXHEi U6l6l8Rgz2wXsZzDaZTJWxWqVgbfYLC7JwqHlR+owfwU08ubpKvESZeo52l/4wbLdR+SxTnZujBu lIE78YFWzaJwXzAQcjE= From: gcc.gnu.org Support To: gcc@gcc.gnu.org Subject: Important: gcc@gcc.gnu.org You have a new package. Date: 14 Sep 2021 02:46:26 +0200 Message-ID: <20210914024626.db98fc06c31ff...@gcc.gnu.org> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
[Bug bootstrap/102278] [12 regression] Bootstrap fails with LLVM 11.0.1 on powerpc-unknown-freebsd: libgcov-interface.c:201:1: internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102278 --- Comment #5 from Piotr Kubaj --- Still the same issue: /wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/ -B/usr/local/powerpc-portbld-freebsd13.0/bin/ -B/usr/local/powerpc-portbld-freebsd13.0/lib/ -isystem /usr/local/powerpc-portbld-freebsd13.0/include -isystem /usr/local/powerpc-portbld-freebsd13.0/sys-include -fno-checking -g -O2 -O2 -g -O2 -DIN_GCC -fPIC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fPIC -pthread -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread -I. -I. -I../.././gcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/. -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/../gcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/../include -DHAVE_CC_TLS -o _gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep -DL_gcov_execl -c /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/libgcov-interface.c during GIMPLE pass: ldist /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/libgcov-interface.c: In function '__gcov_execl': /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/libgcov-interface.c:201:1: internal compiler error: Segmentation fault 201 | __gcov_execl (const char *path, char *arg, ...)
Re: [PATCH] rs6000: Disable optimizing multiple xxsetaccz instructions into one xxsetaccz
On Mon, Sep 13, 2021 at 05:10:42PM -0500, Peter Bergner wrote: > >>* config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_XXSETACCZ. > >>(unspecv): Add UNSPECV_MMA_XXSETACCZ. > > > > Unrelated to this patch, but I have been wondering this for years: > > should we have an unspecv enum at all? It causes some churn, and you > > can name the volatile ones UNSPECV_ in either case. > > I assumed it was needed, but if not, yeah, one enum would seem to be > better than two. These enums are not so very old (from 2010 only). Before that we used define_constant for all. Some backends used separate numbering for unspec and for unspec_volatile, some didn't. The enum scheme supported both the existing practices. It is easier and prettier to have only one namespace for this (when you want to look something up for example, or just reading stuff even). I did however think it quite useful to have the "V" in the name still. But there is nothing forcing us to have any particular naming scheme for the enumeration constants, so that is no blocker :-) Since it is perfectly fine to have multiple define_enum's for the same enumeration, too, converting to this will be pretty easy :-) > >>(mma_xxsetaccz): Change to define_insn. Remove match_operand. > >>Use UNSPECV_MMA_XXSETACCZ. > > > > It still has the match_operand. > > -(define_insn_and_split "*mma_xxsetaccz" > +(define_insn "mma_xxsetaccz" >[(set (match_operand:XO 0 "fpr_reg_operand" "=d") > - (unspec:XO [(match_operand 1 "const_0_to_1_operand" "O")] > -UNSPEC_MMA_XXSETACCZ))] > + (unspec_volatile:XO [(const_int 0)] > + UNSPECV_MMA_XXSETACCZ))] > > > It still has "a" match_operand...for operand 0. The match_operand > for operand 1 was what was removed. Want me to reword that as > "Remove source match_operand." or "Remove match_operand 1." or ??? Ah I see, I looked with my eyes close apparently. "Remove operand 1"? > >> ;; We can't have integer constants in XOmode so we wrap this in an UNSPEC. > > > > Does the comment need updating? It may help to point out here that itr > > needs to be volatile. > > I think the comment was referring to the unneeded operand which I have > now removed. I could either remove the comment altogether or change it > to: > > ;; We can't have integer constants in XOmode so we wrap this in an > ;; UNSPEC_VOLATILE. > > ...to refer to the dummy zero for the source. Let me know what you want. No strong opinion, the existing comment looked out of place, that's all. The latter option adds information, so if you think that is useful to have here, let's go with that? Cheers, Segher
[PATCH] Remove unused function make_unique_name.
Signed-off-by: Benjamin Peterson
gcc/
* attribs.c (make_unique_name): Delete.
* attribs.h (make_unique_name): Delete.
---
gcc/attribs.c | 34 --
gcc/attribs.h | 1 -
2 files changed, 35 deletions(-)
diff --git a/gcc/attribs.c b/gcc/attribs.c
index 0d22c20a35e..83fafc98b7d 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -1022,40 +1022,6 @@ common_function_versions (tree fn1, tree fn2)
return result;
}
-/* Return a new name by appending SUFFIX to the DECL name. If make_unique
- is true, append the full path name of the source file. */
-
-char *
-make_unique_name (tree decl, const char *suffix, bool make_unique)
-{
- char *global_var_name;
- int name_len;
- const char *name;
- const char *unique_name = NULL;
-
- name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
-
- /* Get a unique name that can be used globally without any chances
- of collision at link time. */
- if (make_unique)
-unique_name = IDENTIFIER_POINTER (get_file_function_name ("\0"));
-
- name_len = strlen (name) + strlen (suffix) + 2;
-
- if (make_unique)
-name_len += strlen (unique_name) + 1;
- global_var_name = XNEWVEC (char, name_len);
-
- /* Use '.' to concatenate names as it is demangler friendly. */
- if (make_unique)
-snprintf (global_var_name, name_len, "%s.%s.%s", name, unique_name,
- suffix);
- else
-snprintf (global_var_name, name_len, "%s.%s", name, suffix);
-
- return global_var_name;
-}
-
/* Make a dispatcher declaration for the multi-versioned function DECL.
Calls to DECL function will be replaced with calls to the dispatcher
by the front-end. Return the decl created. */
diff --git a/gcc/attribs.h b/gcc/attribs.h
index 87231b954c6..138c509bce1 100644
--- a/gcc/attribs.h
+++ b/gcc/attribs.h
@@ -44,7 +44,6 @@ extern struct scoped_attributes* register_scoped_attributes
(const struct attrib
extern char *sorted_attr_string (tree);
extern bool common_function_versions (tree, tree);
-extern char *make_unique_name (tree, const char *, bool);
extern tree make_dispatcher_decl (const tree);
extern bool is_function_default_version (const tree);
--
2.30.2
Re: [PATCH 01/18] rs6000: Handle overloads during program parsing
On Wed, Sep 01, 2021 at 11:13:37AM -0500, Bill Schmidt wrote:
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is duplicating the large function that does the overload
> resolution using the automatically generated data structures instead of
> the old hand-generated ones. This doesn't make the patch terribly easy to
> review, unfortunately. Just be aware that generally we aren't changing
> the logic and functionality of overload handling.
> (altivec_build_new_resolved_builtin): New function.
> (altivec_resolve_new_overloaded_builtin): Likewise.
A new function of 973 lines (plus the function comment). Please factor
that (can be in a later patch, but please do, you know what it all means
and does currently, now is the time :-) ).
> +static bool
> +rs6000_new_builtin_type_compatible (tree t, tree u)
This needs a function comment. Are t and u used symmetrically at all?
> +{
> + if (t == error_mark_node)
> +return false;
(not here)
> + if (POINTER_TYPE_P (t) && POINTER_TYPE_P (u))
> +{
> + t = TREE_TYPE (t);
> + u = TREE_TYPE (u);
> + if (TYPE_READONLY (u))
> + t = build_qualified_type (t, TYPE_QUAL_CONST);
> +}
Esp. here. And it still creates junk trees where those are not needed
afaics, and that is not a great idea for functions that are called so
often.
> +static tree
> +altivec_build_new_resolved_builtin (tree *args, int n, tree fntype,
> + tree ret_type,
> + rs6000_gen_builtins bif_id,
> + rs6000_gen_builtins ovld_id)
> +{
> + tree argtypes = TYPE_ARG_TYPES (fntype);
> + tree arg_type[MAX_OVLD_ARGS];
> + tree fndecl = rs6000_builtin_decls_x[bif_id];
> + tree call;
Don't declare things so far ahead please. Declare them right before
they are assigned to, ideally.
> + for (int i = 0; i < n; i++)
> +arg_type[i] = TREE_VALUE (argtypes), argtypes = TREE_CHAIN (argtypes);
Please do not use comma operators where you could use separate
statements.
> + /* The AltiVec overloading implementation is overall gross, but this
Ooh you spell "AltiVec" correctly here ;-)
You can do
for (int j = 0; j < n; j++)
args[j] = fully_fold_convert (arg_type[j], args[j]);
here and then the rest becomes simpler.
> + switch (n)
> +{
> +case 0:
> + call = build_call_expr (fndecl, 0);
> + break;
> +case 1:
> + call = build_call_expr (fndecl, 1,
> + fully_fold_convert (arg_type[0], args[0]));
> + break;
> +case 2:
> + call = build_call_expr (fndecl, 2,
> + fully_fold_convert (arg_type[0], args[0]),
> + fully_fold_convert (arg_type[1], args[1]));
> + break;
> +case 3:
> + call = build_call_expr (fndecl, 3,
> + fully_fold_convert (arg_type[0], args[0]),
> + fully_fold_convert (arg_type[1], args[1]),
> + fully_fold_convert (arg_type[2], args[2]));
> + break;
> +case 4:
> + call = build_call_expr (fndecl, 4,
> + fully_fold_convert (arg_type[0], args[0]),
> + fully_fold_convert (arg_type[1], args[1]),
> + fully_fold_convert (arg_type[2], args[2]),
> + fully_fold_convert (arg_type[3], args[3]));
> + break;
> +default:
> + gcc_unreachable ();
> +}
> + return fold_convert (ret_type, call);
> +}
> +static tree
> +altivec_resolve_new_overloaded_builtin (location_t loc, tree fndecl,
> + void *passed_arglist)
> +{
> + vec *arglist = static_cast *>
> (passed_arglist);
> + unsigned int nargs = vec_safe_length (arglist);
> + enum rs6000_gen_builtins fcode
> += (enum rs6000_gen_builtins) DECL_MD_FUNCTION_CODE (fndecl);
> + tree fnargs = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
> + tree types[MAX_OVLD_ARGS], args[MAX_OVLD_ARGS];
Two separate lines please, they are very different things, and very
important things, too.
> + unsigned int n;
You use this var first 792 lines later. Please don't.
Oh well, this will become much better once this is more properly
factored. Who knows, some of it may become readable / understandable
even! :-)
> + arg = (*arglist)[0];
> + type = TREE_TYPE (arg);
> + if (!SCALAR_FLOAT_TYPE_P (type)
> + && !INTEGRAL_TYPE_P (type))
> + goto bad;
And all gotos still scream "FACTOR ME".
> + case E_TImode:
> + type = (unsigned_p ? unsigned_V1TI_type_node : V1TI_type_node);
> + size = 1;
> + break;
type = signed_or_unsigned_type_for (unsigned_p, V1TI_type_node);
etc.
> + arg2 = build_binary_op (loc, BIT_AND_EXPR, arg2,
> + build_int_cst (TREE_TYPE (arg2),
> +TYPE_VECTOR_SUBPARTS (arg1_type)
> +
[Bug target/27791] assert() without -ansi doesnt print the failing condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27791 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |9.0 Resolution|--- |WONTFIX --- Comment #3 from Andrew Pinski --- AIX 5.2 and AIX 5.3 support was removed in GCC 9 (r9-2371) so closing as won't fix. Also Don't see how GCC would fixincludes the header assert.h in GCC 4.1 either.
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 --- Comment #7 from Antoni --- Since then, I found a workaround to fix the similar segfault in my other feature. It might work for solving this and goes like this: instead of trying to access the rvalue when first replaying the asm, create an intermediate memento that does the work of add_output_operand (and most likely the other actions like add_input_operand). It works since this memento will necessarily be created after both the asm and the variable and thus, both will have been replayed when it's time to replay the new 'add_output_operand' memento.
Re: [PATCH] c++: fix wrong fixit hints for misspelled typedef [PR77565]
On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via Gcc-patches wrote:
> Hi,
>
> PR77565 reports that, with the code `typdef int Int;`, GCC emits
> "did you mean 'typeof'?" instead of "did you mean 'typedef'?".
>
> This happens because the typo corrector determines that `typeof` is a
> candidate for suggestion (through
> `cp_keyword_starts_decl_specifier_p`),
> but `typedef` is not.
>
> This patch fixes the issue by adding `typedef` as a candidate. The
> patch
> additionally adds the `inline` specifier and cv-specifiers as a
> candidate.
> Here is a patch (tests `make check-gcc` pass on darwin):
Thanks for this patch (and for reporting the bug in the first place).
I notice that, as well as being used for fix-it hints by
lookup_name_fuzzy (indirectly via suggest_rid_p),
cp_keyword_starts_decl_specifier_p is also used by
cp_lexer_next_token_is_decl_specifier_keyword, which is used by
cp_parser_lambda_declarator_opt and cp_parser_constructor_declarator_p.
So I'm not sure if this fix is exactly correct - hopefully one of the
C++ frontend maintainers can chime in. If
cp_keyword_starts_decl_specifier_p isn't quite the right place for
this, the fix could probably go in suggest_rid_p instead, which *is*
specific to spelling corrections.
Hope this is constructive; thanks again for the patch
Dave
>
>
> c++: add typo corrections for typedef/inline/cv-qual [PR77565]
>
> PR c++/77565
>
> gcc/cp/ChangeLog:
>
> * parser.c (cp_keyword_starts_decl_specifier_p): Handle
> typedef/inline specifiers and cv-qualifiers.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/spellcheck-typenames.C: Add tests for decl-specs.
>
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -1051,6 +1051,12 @@ cp_keyword_starts_decl_specifier_p (enum rid
> keyword)
> case RID_FLOAT:
> case RID_DOUBLE:
> case RID_VOID:
> + /* CV qualifiers. */
> + case RID_CONST:
> + case RID_VOLATILE:
> + /* typedef/inline specifiers. */
> + case RID_TYPEDEF:
> + case RID_INLINE:
> /* GNU extensions. */
> case RID_ATTRIBUTE:
> case RID_TYPEOF:
> --- a/gcc/testsuite/g++.dg/spellcheck-typenames.C
> +++ b/gcc/testsuite/g++.dg/spellcheck-typenames.C
> @@ -76,3 +76,38 @@ singed char ch; // { dg-error "1: 'singed' does
> not
> name a type; did you mean 's
> ^~
> signed
> { dg-end-multiline-output "" } */
> +
> +typdef int my_int; // { dg-error "1: 'typdef' does not name a type;
> did you mean 'typedef'?" }
> +/* { dg-begin-multiline-output "" }
> + typdef int my_int;
> + ^~
> + typedef
> + { dg-end-multiline-output "" } */
> +
> +inlien int inline_func(); // { dg-error "1: 'inlien' does not name a
> type; did you mean 'inline'?" }
> +/* { dg-begin-multiline-output "" }
> + inlien int inline_func();
> + ^~
> + inline
> + { dg-end-multiline-output "" } */
> +
> +coonst int ci = 0; // { dg-error "1: 'coonst' does not name a type;
> did you mean 'const'?" }
> +/* { dg-begin-multiline-output "" }
> + coonst int ci = 0;
> + ^~
> + const
> + { dg-end-multiline-output "" } */
> +
> +voltil int vi; // { dg-error "1: 'voltil' does not name a type; did
> you mean 'volatile'?" }
> +/* { dg-begin-multiline-output "" }
> + voltil int vi;
> + ^~
> + volatile
> + { dg-end-multiline-output "" } */
> +
> +statik int si; // { dg-error "1: 'statik' does not name a type; did
> you mean 'static'?" }
> +/* { dg-begin-multiline-output "" }
> + statik int si;
> + ^~
> + static
> + { dg-end-multiline-output "" } */
>
>
> --
> Regards,
> Michel
Re: [PATCH] rs6000: Disable optimizing multiple xxsetaccz instructions into one xxsetaccz
On 9/12/21 2:26 PM, Segher Boessenkool wrote: >> I also removed the mma_xxsetaccz define_expand and >> define_insn_and_split and replaced it with a simple define_insn. > > In the future pleaase do that in a separate patch. That makes it *much* > easier to read and review this. Will do. >> * config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_XXSETACCZ. >> (unspecv): Add UNSPECV_MMA_XXSETACCZ. > > Unrelated to this patch, but I have been wondering this for years: > should we have an unspecv enum at all? It causes some churn, and you > can name the volatile ones UNSPECV_ in either case. I assumed it was needed, but if not, yeah, one enum would seem to be better than two. >> (mma_xxsetaccz): Change to define_insn. Remove match_operand. >> Use UNSPECV_MMA_XXSETACCZ. > > It still has the match_operand. -(define_insn_and_split "*mma_xxsetaccz" +(define_insn "mma_xxsetaccz" [(set (match_operand:XO 0 "fpr_reg_operand" "=d") - (unspec:XO [(match_operand 1 "const_0_to_1_operand" "O")] -UNSPEC_MMA_XXSETACCZ))] + (unspec_volatile:XO [(const_int 0)] + UNSPECV_MMA_XXSETACCZ))] It still has "a" match_operand...for operand 0. The match_operand for operand 1 was what was removed. Want me to reword that as "Remove source match_operand." or "Remove match_operand 1." or ??? >> ;; We can't have integer constants in XOmode so we wrap this in an UNSPEC. > > Does the comment need updating? It may help to point out here that itr > needs to be volatile. I think the comment was referring to the unneeded operand which I have now removed. I could either remove the comment altogether or change it to: ;; We can't have integer constants in XOmode so we wrap this in an ;; UNSPEC_VOLATILE. ...to refer to the dummy zero for the source. Let me know what you want. >> (set_attr "length" "4")]) > > Not new of course: the default length is 4, most insns have that, it > helps to be less verbose. I'll remove that before pushing, thanks! Peter
[r12-3495 Regression] FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess errors) on Linux/x86_64
On Linux/x86_64,
76b75018b3d053a890ebe155e47814de14b3c9fb is the first bad commit
commit 76b75018b3d053a890ebe155e47814de14b3c9fb
Author: Jason Merrill
Date: Thu Jul 15 15:30:17 2021 -0400
c++: implement C++17 hardware interference size
caused
FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess
errors)
FAIL: g++.dg/ext/sync-4.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ext/sync-4.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/ext/sync-4.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/ext/sync-4.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/opt/inline9.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/inline9.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/inline9.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/inline9.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/opt/longbranch2.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/longbranch2.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/longbranch2.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/longbranch2.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/opt/pr52727.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/pr52727.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/pr52727.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/pr52727.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/opt/pr58864.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/pr58864.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/pr58864.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/pr58864.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/opt/pr69570.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/pr69570.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/pr69570.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/pr69570.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/opt/reg-stack4.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/reg-stack4.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/reg-stack4.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/reg-stack4.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/other/pr39496.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/other/pr39496.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/other/pr39496.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/other/pr39496.C -std=gnu++98 (test for excess errors)
FAIL: libitm.c++/dropref.C (test for excess errors)
FAIL: libitm.c++/eh-1.C (test for excess errors)
FAIL: libitm.c++/eh-2.C (test for excess errors)
FAIL: libitm.c++/eh-3.C (test for excess errors)
FAIL: libitm.c++/eh-4.C (test for excess errors)
FAIL: libitm.c++/eh-5.C (test for excess errors)
FAIL: libitm.c++/libstdc++-pr91488.C (test for excess errors)
FAIL: libitm.c++/libstdc++-safeexc.C (test for excess errors)
FAIL: libitm.c++/newdelete.C (test for excess errors)
FAIL: libitm.c++/throwdown.C (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-3495/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=29_atomics/atomic_flag/test_and_set/explicit-hle.cc
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=29_atomics/atomic_flag/test_and_set/explicit-hle.cc
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/ext/sync-4.C
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/ext/sync-4.C
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/opt/inline9.C
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/opt/inline9.C
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/opt/longbranch2.C --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/opt/longbranch2.C --target_board='unix{-m32\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/opt/pr52727.C
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/opt/pr52727.C
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/opt/pr58864.C
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/opt/pr58864.C
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/opt/pr69570.C
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 Andrew Pinski changed: What|Removed |Added CC||dealer4587 at yahoo dot com --- Comment #18 from Andrew Pinski --- *** Bug 12691 has been marked as a duplicate of this bug. ***
[Bug target/12691] bug building with option with-cpu with AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12691 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- aix 4.3 support was removed in GCC 9. But the problem here was fixed for GCC 10 with r10-2132 which makes this an exact dup of bug 91050. *** This bug has been marked as a duplicate of bug 91050 ***
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #5 from Qing Zhao --- > On Sep 13, 2021, at 4:45 PM, pinskia at gcc dot gnu.org > wrote: > >> is it possible to make -fsanitize=signed-integer-overflow work with -fwrapv? > > Why would it? they conflict. This is a feature that is requested by Kees Cook for kernel security usage. "the kernel builds with -fno-strict-overflow which removes possible undefined behavior, but I still want the sanitizer to catch this case.”
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jakub Jelinek --- Well, -fwrapv says that signed integer overflow is well defined, therefore there is nothing for -fsanitize=signed-integer-overflow to diagnose. It is like if you've done all the arithmetics that could overflow in unsigned types...
[Bug c/45881] bit offset of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45881 --- Comment #3 from Jan Waclawek --- Thanks for the comments and the link. Small embedded is generally frowned upon. The proposal is characteristically heavyweight and unwieldy. Maybe in C5x.
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #3 from Andrew Pinski --- (In reply to qinzhao from comment #2) > (In reply to Andrew Pinski from comment #1) > > -fno-strict-overflow maps directly to -fwrapv . > > > > If you want to use -fsanitize=signed-integer-overflow, you can just remove > > both -fno-strict-overflow -fwrapv. -fwrapv is implied for code later on. > > is it possible to make -fsanitize=signed-integer-overflow work with -fwrapv? Why would it? they conflict.
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) > -fno-strict-overflow maps directly to -fwrapv . > > If you want to use -fsanitize=signed-integer-overflow, you can just remove > both -fno-strict-overflow -fwrapv. -fwrapv is implied for code later on. is it possible to make -fsanitize=signed-integer-overflow work with -fwrapv?
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #1 from Andrew Pinski --- -fno-strict-overflow maps directly to -fwrapv . If you want to use -fsanitize=signed-integer-overflow, you can just remove both -fno-strict-overflow -fwrapv. -fwrapv is implied for code later on.
[Bug sanitizer/102317] New: signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
Bug ID: 102317
Summary: signed integer overflow sanitizer cannot work well
with -fno-strict-overflow
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
with the latest gcc12:
$ cat wrap.c
#include
#include
/* volatile to avoid optimization */
volatile int val;
int main(void)
{
val = INT_MAX;
val += 1;
printf("%d\n", val);
return 0;
}
$ gcc -Wall -O2 -fsanitize=signed-integer-overflow -o wrap wrap.c
$ ./wrap
wrap.c:10:9: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
-2147483648
Things work as expected: the overflow is detected and in this warning
mode, the result is a wrap-around.
However, the kernel builds with -fno-strict-overflow which removes
possible undefined behavior, but I still want the sanitizer to catch
this case. Currently it doesn't:
$ gcc -Wall -O2 -fsanitize=signed-integer-overflow -fno-strict-overflow -o wrap
wrap.c
$ ./wrap
-2147483648
[Bug middle-end/58748] %n asm output template with symbol references should not be permitted?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58748
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-13
Component|inline-asm |middle-end
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, the current code does:
{
putc ('-', asm_out_file);
output_addr_const (asm_out_file, operands[opnum]);
}
I think it should do:
{
fputs ("-(", asm_out_file);
output_addr_const (asm_out_file, operands[opnum]);
putc (')', asm_out_file);
}
Instead.
Listing deprecated targets in changes.html
Hi, I see that a number of targets are going to be deprecated for GCC 12:
- m32r{,le}-linux:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579265.html
- cr16: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579280.html
- m68k-openbsd:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579298.html
- vax-openbsd:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579299.html
However, none of these targets are listed in the changes page for GCC 12 yet:
https://gcc.gnu.org/gcc-12/changes.html
I would encourage people involved with these patches to list these
deprecations on the changes page ASAP, so that people can have time to
prepare for the impending deprecations.
Thanks,
Eric Gallager
[Bug c/33451] Collapsing of offsetable memory operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33451 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-09-13 Ever confirmed|0 |1 Keywords||diagnostic Component|inline-asm |c
[Bug target/82701] RFE: x86: double word operands in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82701 Andrew Pinski changed: What|Removed |Added Component|inline-asm |target Severity|normal |enhancement
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
We need to wrap the deallocation of INTENT(out) allocatable components into
a test for presence, like:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 18d665192f0..076cffdd77f 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6548,6 +6548,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
// deallocate the components first
tmp = gfc_deallocate_alloc_comp (fsym->ts.u.derived,
parmse.expr, e->rank);
+ /* But check whether dummy argument is optional. */
+ if (tmp != NULL_TREE
+ && fsym->attr.optional
+ && e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->attr.optional)
+ {
+ tree present, notpres;
+ present = gfc_conv_expr_present (e->symtree->n.sym);
+ notpres = build_empty_stmt (input_location);
+ tmp = fold_build3_loc (input_location, COND_EXPR,
+ void_type_node,
+ present, tmp, notpres);
+ }
if (tmp != NULL_TREE)
gfc_add_expr_to_block (>pre, tmp);
}
[Bug c/45881] bit offset of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45881 --- Comment #2 from Andrew Pinski --- http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf It seems like they did not add this ... But they do have _Bitwidthof now ...
[Bug middle-end/61893] Constant folding inhibits trapping with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893 Andrew Pinski changed: What|Removed |Added CC||john at mcfarlane dot name --- Comment #6 from Andrew Pinski --- *** Bug 102303 has been marked as a duplicate of this bug. ***
[Bug c++/102303] optimizer elides -ftrapv overflow detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102303 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- This is a dup of bug 61893. *** This bug has been marked as a duplicate of bug 61893 ***
[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #4 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #3)
> Note, we have other issues, consider:
> struct A
> {
> float a;
> int b[];
> };
>
> int x[4];
> struct A c = { 42.0f, { ++x[0], ++x[1], ++x[2], ++x[3] } };
Right that is PR 88578 .
[Bug middle-end/102316] Unexpected stringop-overflow Warnings on POWER CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316 --- Comment #1 from Andrew Pinski --- Looks like it is unrolling ...
[Bug c/102316] New: Unexpected stringop-overflow Warnings on POWER CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
Bug ID: 102316
Summary: Unexpected stringop-overflow Warnings on POWER CPU
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drc at linux dot vnet.ibm.com
Target Milestone: ---
Building DPDK with gcc (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3) on a POWER9
host and powerpc64le-linux-gnu-gcc (GCC) 11.2.1 20210802 (Advance-Toolchain
15.0-0) [ebcfb7a665c2] on an x86_64 cross-compile host, generates the warning:
In function ‘i40e_flow_parse_fdir_pattern’,
inlined from ‘i40e_flow_parse_fdir_filter’ at
../drivers/net/i40e/i40e_flow.c:3274:8:
../drivers/net/i40e/i40e_flow.c:3052:69: warning: writing 1 byte into a region
of size 0 [-Wstringop-overflow=]
3052 | filter->input.flow_ext.flexbytes[j] =
| ^
3053 | raw_spec->pattern[i];
|
In file included from ../drivers/net/i40e/i40e_flow.c:25:
../drivers/net/i40e/i40e_flow.c: In function ‘i40e_flow_parse_fdir_filter’:
../drivers/net/i40e/i40e_ethdev.h:630:17: note: at offset 16 into destination
object ‘flexbytes’ of size 16
630 | uint8_t flexbytes[RTE_ETH_FDIR_MAX_FLEXLEN];
| ^
See https://bugs.dpdk.org/show_bug.cgi?id=743 for additional details on DPDK
build failure.
Running cvise to reduce the failing code yields the following simplified test
failure:
#include
#define LEN 16
struct {
char c[LEN]
} d;
int a = LEN;
char* b;
int p() {
for (int i = 0; i < a; i++) {
d.c[i] = b[i];
}
return 0;
}
int main () {
int r = 0;
b = malloc(sizeof(char) * (LEN + 1));
r = p();
return r;
}
$ gcc -O3 test.c
test.c:6:1: warning: no semicolon at end of struct or union
6 | } d;
| ^
test.c: In function 'p':
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 16 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 17 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 18 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 19 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 20 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 21 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 22 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 23 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 24 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 25 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 26 into destination object 'c' of size 16
5 | char c[LEN]
|^
test.c:13:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
13 | d.c[i] = b[i];
| ~~~^~
test.c:5:8: note: at offset 27 into
[PATCH] c++: empty union member activation during constexpr [PR102163]
Here, the union's constructor is defined to activate its empty data
member _M_rest, but during constexpr evaluation of this constructor the
subobject constructor call to O::O(&_M_rest, 42) produces no side
effects that actually activates the member, so the union still appears
uninitialized after the fact. This patch fixes this by faking up a
dummy MODIFY_EXPR in this situation, whose evaluation ensures the member
gets activated.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
PR c++/102163
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_call_expression): After evaluating a
constructor call for an empty union member, produce a side
effect that makes sure the member is activated.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-empty17.C: New test.
---
gcc/cp/constexpr.c| 34 +++
.../g++.dg/cpp0x/constexpr-empty17.C | 21
2 files changed, 49 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 7772fe62d95..40b0b80b438 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2787,12 +2787,34 @@ cxx_eval_call_expression (const constexpr_ctx *ctx,
tree t,
_target);
if (DECL_CONSTRUCTOR_P (fun))
- /* This can be null for a subobject constructor call, in
- which case what we care about is the initialization
- side-effects rather than the value. We could get at the
- value by evaluating *this, but we don't bother; there's
- no need to put such a call in the hash table. */
- result = lval ? ctx->object : ctx->ctor;
+ {
+ /* This can be null for a subobject constructor call, in
+which case what we care about is the initialization
+side-effects rather than the value. We could get at the
+value by evaluating *this, but we don't bother; there's
+no need to put such a call in the hash table. */
+ result = lval ? ctx->object : ctx->ctor;
+
+ if (!result && new_obj
+ && TREE_CODE (new_obj) == COMPONENT_REF
+ && TREE_CODE (TREE_TYPE
+ (TREE_OPERAND (new_obj, 0))) == UNION_TYPE
+ && is_really_empty_class (TREE_TYPE (new_obj),
+ /*ignore_vptr*/false))
+ {
+ /* This constructor call for an empty union member might not
+have produced a side effect that actually activated the
+member. So produce such a side effect now to ensure the
+union appears initialized. */
+ tree activate = build2 (MODIFY_EXPR, TREE_TYPE (new_obj),
+ new_obj,
+ build_constructor (TREE_TYPE
(new_obj),
+NULL));
+ cxx_eval_constant_expression (ctx, activate, lval,
+ non_constant_p, overflow_p);
+ ggc_free (activate);
+ }
+ }
else if (VOID_TYPE_P (TREE_TYPE (res)))
result = void_node;
else
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C
new file mode 100644
index 000..9d753a3bb69
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C
@@ -0,0 +1,21 @@
+// PR c++/102163
+// { dg-do compile { target c++11 } }
+
+struct O {
+ constexpr O(int) { }
+};
+
+union _Variadic_union {
+ constexpr _Variadic_union(int __arg) : _M_rest(__arg) { }
+
+ int _M_first;
+ O _M_rest;
+};
+
+
+struct _Variant_storage {
+ constexpr _Variant_storage() : _M_u(42) {}
+ _Variadic_union _M_u;
+};
+
+constexpr _Variant_storage w;
--
2.33.0.328.g8b7c11b866
Merge from trunk to gccgo branch
I merged trunk revision 104c05c5284b7822d770ee51a7d91946c7e56d50 to the gccgo branch. Ian
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-13 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
Re: [PATCH 05/18] rs6000: Support for vectorizing built-in functions
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This patch just duplicates a couple of functions and adjusts them to use the
> new builtin names. There's no logical change otherwise.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000.c (rs6000-builtins.h): New include.
> (rs6000_new_builtin_vectorized_function): New function.
> (rs6000_new_builtin_md_vectorized_function): Likewise.
> (rs6000_builtin_vectorized_function): Call
> rs6000_new_builtin_vectorized_function.
> (rs6000_builtin_md_vectorized_function): Call
> rs6000_new_builtin_md_vectorized_function.
ok
> ---
> gcc/config/rs6000/rs6000.c | 253 +
> 1 file changed, 253 insertions(+)
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index b7ea1483da5..52c78c7500c 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -78,6 +78,7 @@
> #include "case-cfn-macros.h"
> #include "ppc-auxv.h"
> #include "rs6000-internal.h"
> +#include "rs6000-builtins.h"
> #include "opts.h"
>
> /* This file should be included last. */
> @@ -5501,6 +5502,251 @@ rs6000_loop_unroll_adjust (unsigned nunroll, struct
> loop *loop)
>return nunroll;
> }
>
> +/* Returns a function decl for a vectorized version of the builtin function
> + with builtin function code FN and the result vector type TYPE, or
> NULL_TREE
> + if it is not available. */
> +
> +static tree
> +rs6000_new_builtin_vectorized_function (unsigned int fn, tree type_out,
> + tree type_in)
> +{
> + machine_mode in_mode, out_mode;
> + int in_n, out_n;
> +
> + if (TARGET_DEBUG_BUILTIN)
> +fprintf (stderr, "rs6000_new_builtin_vectorized_function (%s, %s, %s)\n",
> + combined_fn_name (combined_fn (fn)),
> + GET_MODE_NAME (TYPE_MODE (type_out)),
> + GET_MODE_NAME (TYPE_MODE (type_in)));
> +
> + if (TREE_CODE (type_out) != VECTOR_TYPE
> + || TREE_CODE (type_in) != VECTOR_TYPE)
> +return NULL_TREE;
> +
> + out_mode = TYPE_MODE (TREE_TYPE (type_out));
> + out_n = TYPE_VECTOR_SUBPARTS (type_out);
> + in_mode = TYPE_MODE (TREE_TYPE (type_in));
> + in_n = TYPE_VECTOR_SUBPARTS (type_in);
> +
> + switch (fn)
> +{
> +CASE_CFN_COPYSIGN:
> + if (VECTOR_UNIT_VSX_P (V2DFmode)
> + && out_mode == DFmode && out_n == 2
> + && in_mode == DFmode && in_n == 2)
> + return rs6000_builtin_decls_x[RS6000_BIF_CPSGNDP];
> + if (VECTOR_UNIT_VSX_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_CPSGNSP];
> + if (VECTOR_UNIT_ALTIVEC_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_COPYSIGN_V4SF];
> + break;
> +CASE_CFN_CEIL:
> + if (VECTOR_UNIT_VSX_P (V2DFmode)
> + && out_mode == DFmode && out_n == 2
> + && in_mode == DFmode && in_n == 2)
> + return rs6000_builtin_decls_x[RS6000_BIF_XVRDPIP];
> + if (VECTOR_UNIT_VSX_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_XVRSPIP];
> + if (VECTOR_UNIT_ALTIVEC_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_VRFIP];
> + break;
> +CASE_CFN_FLOOR:
> + if (VECTOR_UNIT_VSX_P (V2DFmode)
> + && out_mode == DFmode && out_n == 2
> + && in_mode == DFmode && in_n == 2)
> + return rs6000_builtin_decls_x[RS6000_BIF_XVRDPIM];
> + if (VECTOR_UNIT_VSX_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_XVRSPIM];
> + if (VECTOR_UNIT_ALTIVEC_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_VRFIM];
> + break;
> +CASE_CFN_FMA:
> + if (VECTOR_UNIT_VSX_P (V2DFmode)
> + && out_mode == DFmode && out_n == 2
> + && in_mode == DFmode && in_n == 2)
> + return rs6000_builtin_decls_x[RS6000_BIF_XVMADDDP];
> + if (VECTOR_UNIT_VSX_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_XVMADDSP];
> + if (VECTOR_UNIT_ALTIVEC_P (V4SFmode)
> + && out_mode == SFmode && out_n == 4
> + && in_mode == SFmode && in_n == 4)
> + return rs6000_builtin_decls_x[RS6000_BIF_VMADDFP];
> + break;
> +CASE_CFN_TRUNC:
> + if (VECTOR_UNIT_VSX_P (V2DFmode)
> + && out_mode == DFmode && out_n == 2
> + && in_mode == DFmode && in_n == 2)
> + return
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
Potential fix:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 8e5ed1c032c..30b96b2f597 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -811,7 +811,7 @@ resolve_entries (gfc_namespace *ns)
gfc_error ("Function %s at %L has entry %s with mismatched "
"characteristics", ns->entries->sym->name,
>entries->sym->declared_at, el->sym->name);
- return;
+ goto cleanup;
}
else if (ts->type == BT_CHARACTER && ts->u.cl && fts->u.cl
&& (((ts->u.cl->length && !fts->u.cl->length)
@@ -917,6 +917,8 @@ resolve_entries (gfc_namespace *ns)
}
}
}
+
+cleanup:
proc->attr.access = ACCESS_PRIVATE;
proc->attr.entry_master = 1;
Re: [PATCH][v2] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS
On 9/13/2021 10:52 AM, Koning, Paul wrote: On Sep 13, 2021, at 3:31 AM, Richard Biener wrote: This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE is not specified by the target and NO_DEBUG if DWARF is not supported. It also makes us warn when STABS is enabled and removes the corresponding diagnostic from the Ada frontend. The warnings are pruned from the testsuite output via prune_gcc_output. This leaves the following targets without debug support: pdp11-*-* pdp11 is a.out, dwarf support is difficult I'll admit that I don't know much about debug formats. It is definitely the case that pdp11 output is a.out (it may be BSD 2.x style a.out -- which I think is somewhat different though it's been many years since I looked at that, and then only briefly). I guess that constrains which debug formats can be used, but I don't know any details. My recollection of aout stabs is mostly lost. IIRC we'd emit .stabs directives to the assembler which would turn into symbol table entries. Embedded stabs used the same underlying stab strings, but instead put the information into a special section. That requires an object format that supports named sections, so it's a non-starter for a.out. dwarf also requires named sections. While in theory one could probably do something hackish like dwarf embedded in .stab directives, that just seems just awful. pdp11-elf was done as an experiment by someone else, in binutils. I'll ask about the status of that. If it's possible to deliver that, it would presumably enable DWARF support. Is that all common code so it's a matter of enabling it, or would "DWARF machine details for pdp11" have to be defined? That's going to be the best path forward. Get the pdp11-elf bits working and the dwarf2 debugging stuff should come along for free. Jeff
Re: [PATCH] Remove DARWIN_PREFER_DWARF and dead code
Hi Folks > On 10 Sep 2021, at 16:16, Jeff Law wrote: > On 9/10/2021 1:19 AM, Richard Biener via Gcc-patches wrote: >> This removes the always defined DARWIN_PREFER_DWARF and the code >> guarded by it being not defined, removing the possibility to >> default some i386 darwin configurations to STABS when it would >> not be defined. >> >> OK for trunk? >> >> Thanks, >> Richard. >> >> 2021-09-10 Richard Biener >> >> * config/darwin.h (DARWIN_PREFER_DWARF): Do not define. >> * config/i386/darwin.h (PREFERRED_DEBUGGING_TYPE): Do not >> change based on DARWIN_PREFER_DWARF not being defined. Sorry, was OOO and without sensible connection. As you saw I was part way through ripping out stabs for Darwin (I disabled it on the last cycle, but with an easy route to re-enabling should there be any fallout) - no one has complained - so the patch ought to be fine. > OK. I'm not too worried about supporting 32bit darwin 8 and earlier. That's > got to be at least a decade out of service at this point The Darwin maintainers have had a policy of not breaking older versions on purpose (and I have gone along with that for now) - but if you want to build on anything older than Darwin8 expect to have to build a whole bunch of supporting tools first to support the bootstrap… For the record, Darwin8 works fine for GCC11 - and I’d not expect a problem with GCC12 (so far) - there will come a point that we want to default to using embedded rpaths, which it doesn’t support so we shall see what options there are then. Iain
Re: [PATCH 04/18] rs6000: Handle some recent MMA builtin changes
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
> __builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
> I had been using to automate gimple folding of MMA builtins. Previously,
> every MMA function that could be folded had an associated internal function
> that it was folded into. The LXVP/STXVP builtins are just folded directly
> into memory operations.
>
> Instead of relying on this pattern, this patch adds a new attribute to
> builtins called "mmaint," which is set for all MMA builtins that have an
> associated internal builtin. The naming convention that adds _INTERNAL to
> the builtin index name remains.
>
> The rest of the patch is just duplicating Peter's patch, using the new
> builtin infrastructure.
>
> 2021-08-23 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-builtin-new.def (ASSEMBLE_ACC): Add mmaint flag.
> (ASSEMBLE_PAIR): Likewise.
> (BUILD_ACC): Likewise.
> (DISASSEMBLE_ACC): Likewise.
> (DISASSEMBLE_PAIR): Likewise.
> (PMXVBF16GER2): Likewise.
> (PMXVBF16GER2NN): Likewise.
> (PMXVBF16GER2NP): Likewise.
> (PMXVBF16GER2PN): Likewise.
> (PMXVBF16GER2PP): Likewise.
> (PMXVF16GER2): Likewise.
> (PMXVF16GER2NN): Likewise.
> (PMXVF16GER2NP): Likewise.
> (PMXVF16GER2PN): Likewise.
> (PMXVF16GER2PP): Likewise.
> (PMXVF32GER): Likewise.
> (PMXVF32GERNN): Likewise.
> (PMXVF32GERNP): Likewise.
> (PMXVF32GERPN): Likewise.
> (PMXVF32GERPP): Likewise.
> (PMXVF64GER): Likewise.
> (PMXVF64GERNN): Likewise.
> (PMXVF64GERNP): Likewise.
> (PMXVF64GERPN): Likewise.
> (PMXVF64GERPP): Likewise.
> (PMXVI16GER2): Likewise.
> (PMXVI16GER2PP): Likewise.
> (PMXVI16GER2S): Likewise.
> (PMXVI16GER2SPP): Likewise.
> (PMXVI4GER8): Likewise.
> (PMXVI4GER8PP): Likewise.
> (PMXVI8GER4): Likewise.
> (PMXVI8GER4PP): Likewise.
> (PMXVI8GER4SPP): Likewise.
> (XVBF16GER2): Likewise.
> (XVBF16GER2NN): Likewise.
> (XVBF16GER2NP): Likewise.
> (XVBF16GER2PN): Likewise.
> (XVBF16GER2PP): Likewise.
> (XVF16GER2): Likewise.
> (XVF16GER2NN): Likewise.
> (XVF16GER2NP): Likewise.
> (XVF16GER2PN): Likewise.
> (XVF16GER2PP): Likewise.
> (XVF32GER): Likewise.
> (XVF32GERNN): Likewise.
> (XVF32GERNP): Likewise.
> (XVF32GERPN): Likewise.
> (XVF32GERPP): Likewise.
> (XVF64GER): Likewise.
> (XVF64GERNN): Likewise.
> (XVF64GERNP): Likewise.
> (XVF64GERPN): Likewise.
> (XVF64GERPP): Likewise.
> (XVI16GER2): Likewise.
> (XVI16GER2PP): Likewise.
> (XVI16GER2S): Likewise.
> (XVI16GER2SPP): Likewise.
> (XVI4GER8): Likewise.
> (XVI4GER8PP): Likewise.
> (XVI8GER4): Likewise.
> (XVI8GER4PP): Likewise.
> (XVI8GER4SPP): Likewise.
> (XXMFACC): Likewise.
> (XXMTACC): Likewise.
> (XXSETACCZ): Likewise.
> (ASSEMBLE_PAIR_V): Likewise.
> (BUILD_PAIR): Likewise.
> (DISASSEMBLE_PAIR_V): Likewise.
> (LXVP): New.
> (STXVP): New.
ok
> * config/rs6000/rs6000-call.c
> (rs6000_gimple_fold_new_mma_builtin): Handle RS6000_BIF_LXVP and
> RS6000_BIF_STXVP.
> * config/rs6000/rs6000-gen-builtins.c (attrinfo): Add ismmaint.
> (parse_bif_attrs): Handle ismmaint.
> (write_decls): Add bif_mmaint_bit and bif_is_mmaint.
> (write_bif_static_init): Handle ismmaint.
ok
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 145 ---
> gcc/config/rs6000/rs6000-call.c | 38 +-
> gcc/config/rs6000/rs6000-gen-builtins.c | 38 +++---
> 3 files changed, 135 insertions(+), 86 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
> b/gcc/config/rs6000/rs6000-builtin-new.def
> index a8c6b9e988f..1966516551e 100644
> --- a/gcc/config/rs6000/rs6000-builtin-new.def
> +++ b/gcc/config/rs6000/rs6000-builtin-new.def
> @@ -129,6 +129,7 @@
> ; mma Needs special handling for MMA
> ; quad MMA instruction using a register quad as an input operand
> ; pair MMA instruction using a register pair as an input operand
> +; mmaint MMA instruction expanding to internal call at GIMPLE time
> ; no32bit Not valid for TARGET_32BIT
> ; 32bitRequires different handling for TARGET_32BIT
> ; cpu This is a "cpu_is" or "cpu_supports" builtin
> @@ -3584,415 +3585,421 @@
>
> [mma]
>void __builtin_mma_assemble_acc (v512 *, vuc, vuc, vuc, vuc);
> -ASSEMBLE_ACC nothing {mma}
> +ASSEMBLE_ACC nothing {mma,mmaint}
>
>v512 __builtin_mma_assemble_acc_internal (vuc, vuc, vuc, vuc);
> ASSEMBLE_ACC_INTERNAL mma_assemble_acc {mma}
>
>void __builtin_mma_assemble_pair (v256 *, vuc, vuc);
> -ASSEMBLE_PAIR nothing {mma}
> +
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-09-13
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
(gdb) l symbol.c:4278
4273
4274void
4275gfc_enforce_clean_symbol_state(void)
4276{
4277 enforce_single_undo_checkpoint ();
4278 gcc_assert (latest_undo_chgset->syms.is_empty ());
4279}
For some reason we fail to clean up when the function is contained in a module.
Re: [PATCH 03/18] rs6000: Handle gimple folding of target built-ins
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This is another patch that looks bigger than it really is. Because we
> have a new namespace for the builtins, allowing us to have both the old
> and new builtin infrastructure supported at once, we need versions of
> these functions that use the new builtin namespace. Otherwise the code is
> unchanged.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_gimple_fold_new_builtin):
> New forward decl.
> (rs6000_gimple_fold_builtin): Call rs6000_gimple_fold_new_builtin.
> (rs6000_new_builtin_valid_without_lhs): New function.
> (rs6000_gimple_fold_new_mma_builtin): Likewise.
> (rs6000_gimple_fold_new_builtin): Likewise.
> ---
> gcc/config/rs6000/rs6000-call.c | 1165 +++
> 1 file changed, 1165 insertions(+)
>
> diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
> index 2c68aa3580c..eae4e15df1e 100644
> --- a/gcc/config/rs6000/rs6000-call.c
> +++ b/gcc/config/rs6000/rs6000-call.c
> @@ -190,6 +190,7 @@ static tree builtin_function_type (machine_mode,
> machine_mode,
> static void rs6000_common_init_builtins (void);
> static void htm_init_builtins (void);
> static void mma_init_builtins (void);
> +static bool rs6000_gimple_fold_new_builtin (gimple_stmt_iterator *gsi);
>
>
> /* Hash table to keep track of the argument types for builtin functions. */
> @@ -12024,6 +12025,9 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator
> *gsi)
> bool
> rs6000_gimple_fold_builtin (gimple_stmt_iterator *gsi)
> {
> + if (new_builtins_are_live)
> +return rs6000_gimple_fold_new_builtin (gsi);
> +
>gimple *stmt = gsi_stmt (*gsi);
>tree fndecl = gimple_call_fndecl (stmt);
>gcc_checking_assert (fndecl && DECL_BUILT_IN_CLASS (fndecl) ==
> BUILT_IN_MD);
ok
> @@ -12971,6 +12975,35 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator
> *gsi)
>return false;
> }
>
> +/* Helper function to sort out which built-ins may be valid without having
> +a LHS. */
> +static bool
> +rs6000_new_builtin_valid_without_lhs (enum rs6000_gen_builtins fn_code,
> + tree fndecl)
> +{
> + if (TREE_TYPE (TREE_TYPE (fndecl)) == void_type_node)
> +return true;
Is that a better or improved version of the code as seen in
rs6000_builtin_valid_without_lhs ?
That is
> if (rs6000_builtin_info[fn_code].attr & RS6000_BTC_VOID)
>return true;
ok either way.
> +
> + switch (fn_code)
> +{
> +case RS6000_BIF_STVX_V16QI:
> +case RS6000_BIF_STVX_V8HI:
> +case RS6000_BIF_STVX_V4SI:
> +case RS6000_BIF_STVX_V4SF:
> +case RS6000_BIF_STVX_V2DI:
> +case RS6000_BIF_STVX_V2DF:
> +case RS6000_BIF_STXVW4X_V16QI:
> +case RS6000_BIF_STXVW4X_V8HI:
> +case RS6000_BIF_STXVW4X_V4SF:
> +case RS6000_BIF_STXVW4X_V4SI:
> +case RS6000_BIF_STXVD2X_V2DF:
> +case RS6000_BIF_STXVD2X_V2DI:
> + return true;
> +default:
> + return false;
> +}
> +}
> +
> /* Check whether a builtin function is supported in this target
> configuration. */
> bool
> @@ -13024,6 +13057,1138 @@ rs6000_new_builtin_is_supported (enum
> rs6000_gen_builtins fncode)
>gcc_unreachable ();
> }
>
> +/* Expand the MMA built-ins early, so that we can convert the
> pass-by-reference
> + __vector_quad arguments into pass-by-value arguments, leading to more
> + efficient code generation. */
> +static bool
> +rs6000_gimple_fold_new_mma_builtin (gimple_stmt_iterator *gsi,
> + rs6000_gen_builtins fn_code)
> +{
> + gimple *stmt = gsi_stmt (*gsi);
> + size_t fncode = (size_t) fn_code;
> +
> + if (!bif_is_mma (rs6000_builtin_info_x[fncode]))
> +return false;
> +
> + /* Each call that can be gimple-expanded has an associated built-in
> + function that it will expand into. If this one doesn't, we have
> + already expanded it! */
> + if (rs6000_builtin_info_x[fncode].assoc_bif == RS6000_BIF_NONE)
> +return false;
> +
> + bifdata *bd = _builtin_info_x[fncode];
> + unsigned nopnds = bd->nargs;
> + gimple_seq new_seq = NULL;
> + gimple *new_call;
> + tree new_decl;
> +
> + /* Compatibility built-ins; we used to call these
> + __builtin_mma_{dis,}assemble_pair, but now we call them
> + __builtin_vsx_{dis,}assemble_pair. Handle the old versions. */
> + if (fncode == RS6000_BIF_ASSEMBLE_PAIR)
> +fncode = RS6000_BIF_ASSEMBLE_PAIR_V;
> + else if (fncode == RS6000_BIF_DISASSEMBLE_PAIR)
> +fncode = RS6000_BIF_DISASSEMBLE_PAIR_V;
> +
> + if (fncode == RS6000_BIF_DISASSEMBLE_ACC
> + || fncode == RS6000_BIF_DISASSEMBLE_PAIR_V)
> +{
> + /* This is an MMA disassemble built-in function. */
> + push_gimplify_context (true);
> + unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
> + tree dst_ptr = gimple_call_arg (stmt, 0);
> + tree src_ptr = gimple_call_arg
[PATCH] c++: fix wrong fixit hints for misspelled typedef [PR77565]
Hi,
PR77565 reports that, with the code `typdef int Int;`, GCC emits
"did you mean 'typeof'?" instead of "did you mean 'typedef'?".
This happens because the typo corrector determines that `typeof` is a
candidate for suggestion (through `cp_keyword_starts_decl_specifier_p`),
but `typedef` is not.
This patch fixes the issue by adding `typedef` as a candidate. The patch
additionally adds the `inline` specifier and cv-specifiers as a candidate.
Here is a patch (tests `make check-gcc` pass on darwin):
c++: add typo corrections for typedef/inline/cv-qual [PR77565]
PR c++/77565
gcc/cp/ChangeLog:
* parser.c (cp_keyword_starts_decl_specifier_p): Handle
typedef/inline specifiers and cv-qualifiers.
gcc/testsuite/ChangeLog:
* g++.dg/spellcheck-typenames.C: Add tests for decl-specs.
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -1051,6 +1051,12 @@ cp_keyword_starts_decl_specifier_p (enum rid keyword)
case RID_FLOAT:
case RID_DOUBLE:
case RID_VOID:
+ /* CV qualifiers. */
+case RID_CONST:
+case RID_VOLATILE:
+ /* typedef/inline specifiers. */
+case RID_TYPEDEF:
+case RID_INLINE:
/* GNU extensions. */
case RID_ATTRIBUTE:
case RID_TYPEOF:
--- a/gcc/testsuite/g++.dg/spellcheck-typenames.C
+++ b/gcc/testsuite/g++.dg/spellcheck-typenames.C
@@ -76,3 +76,38 @@ singed char ch; // { dg-error "1: 'singed' does not
name a type; did you mean 's
^~
signed
{ dg-end-multiline-output "" } */
+
+typdef int my_int; // { dg-error "1: 'typdef' does not name a type;
did you mean 'typedef'?" }
+/* { dg-begin-multiline-output "" }
+ typdef int my_int;
+ ^~
+ typedef
+ { dg-end-multiline-output "" } */
+
+inlien int inline_func(); // { dg-error "1: 'inlien' does not name a
type; did you mean 'inline'?" }
+/* { dg-begin-multiline-output "" }
+ inlien int inline_func();
+ ^~
+ inline
+ { dg-end-multiline-output "" } */
+
+coonst int ci = 0; // { dg-error "1: 'coonst' does not name a type;
did you mean 'const'?" }
+/* { dg-begin-multiline-output "" }
+ coonst int ci = 0;
+ ^~
+ const
+ { dg-end-multiline-output "" } */
+
+voltil int vi; // { dg-error "1: 'voltil' does not name a type; did
you mean 'volatile'?" }
+/* { dg-begin-multiline-output "" }
+ voltil int vi;
+ ^~
+ volatile
+ { dg-end-multiline-output "" } */
+
+statik int si; // { dg-error "1: 'statik' does not name a type; did
you mean 'static'?" }
+/* { dg-begin-multiline-output "" }
+ statik int si;
+ ^~
+ static
+ { dg-end-multiline-output "" } */
--
Regards,
Michel
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f9c2c8ac3a7..5295911eb82 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -1051,6 +1051,12 @@ cp_keyword_starts_decl_specifier_p (enum rid keyword)
case RID_FLOAT:
case RID_DOUBLE:
case RID_VOID:
+ /* CV qualifiers. */
+case RID_CONST:
+case RID_VOLATILE:
+ /* typedef/inline specifiers. */
+case RID_TYPEDEF:
+case RID_INLINE:
/* GNU extensions. */
case RID_ATTRIBUTE:
case RID_TYPEOF:
diff --git a/gcc/testsuite/g++.dg/spellcheck-typenames.C
b/gcc/testsuite/g++.dg/spellcheck-typenames.C
index ff53ecc6303..75f80480e16 100644
--- a/gcc/testsuite/g++.dg/spellcheck-typenames.C
+++ b/gcc/testsuite/g++.dg/spellcheck-typenames.C
@@ -76,3 +76,38 @@ singed char ch; // { dg-error "1: 'singed' does not name a
type; did you mean 's
^~
signed
{ dg-end-multiline-output "" } */
+
+typdef int my_int; // { dg-error "1: 'typdef' does not name a type; did you
mean 'typedef'?" }
+/* { dg-begin-multiline-output "" }
+ typdef int my_int;
+ ^~
+ typedef
+ { dg-end-multiline-output "" } */
+
+inlien int inline_func(); // { dg-error "1: 'inlien' does not name a type; did
you mean 'inline'?" }
+/* { dg-begin-multiline-output "" }
+ inlien int inline_func();
+ ^~
+ inline
+ { dg-end-multiline-output "" } */
+
+coonst int ci = 0; // { dg-error "1: 'coonst' does not name a type; did you
mean 'const'?" }
+/* { dg-begin-multiline-output "" }
+ coonst int ci = 0;
+ ^~
+ const
+ { dg-end-multiline-output "" } */
+
+voltil int vi; // { dg-error "1: 'voltil' does not name a type; did you mean
'volatile'?" }
+/* { dg-begin-multiline-output "" }
+ voltil int vi;
+ ^~
+ volatile
+ { dg-end-multiline-output "" } */
+
+statik int si; // { dg-error "1: 'statik' does not name a type; did you mean
'static'?" }
+/* { dg-begin-multiline-output "" }
+ statik int si;
+ ^~
+ static
+ { dg-end-multiline-output "" } */
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, Sep 13, 2021 at 05:56:53PM +0200, Gerald Pfeifer wrote: > % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ > /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 > /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) > /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 > > This looks like it matches existing Linux case already in place? Those are indeed the same. But perhaps the FreeBSD float.h header guards those defines with some preprocessor condition? Jakub
Error message from push to branch
Hi, I tried to merge trunk to into the coarray_native branch in preparation of some further work. After some problems, it seems that the commit worked. However, pushing it resulted in an error message, and it seems there was no e-mail to the gcc-cvs mailing list. The commit is commit b18a97e5dd0935e1c4a626c230f21457d0aad3d5 (HEAD -> devel/coarray_native, origin/devel/coarray_native) Author: Thomas Koenig Date: 2021-09-13 19:49:49 +0200 Merged current trunk to branch. The error message was: Enumerating objects: 50426, done. Counting objects: 100% (50425/50425), done. Delta compression using up to 8 threads Compressing objects: 100% (11769/11769), done. Writing objects: 100% (31082/31082), 15.75 MiB | 2.09 MiB/s, done. Total 31082 (delta 22396), reused 25675 (delta 18417) remote: Resolving deltas: 100% (22396/22396), completed with 15476 local objects. remote: Traceback (most recent call last): remote: File "hooks/post_receive.py", line 118, in remote: post_receive(refs_data, args.submitter_email) remote: File "hooks/post_receive.py", line 65, in post_receive remote: submitter_email) remote: File "hooks/post_receive.py", line 47, in post_receive_one remote: update.send_email_notifications() remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 189, in send_email_notifications remote: self.__email_new_commits() remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 1031, in __email_new_commits remote: commit, self.get_standard_commit_email(commit)) remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 1011, in __send_commit_email remote: default_diff=email.diff) remote: File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 946, in __maybe_get_email_custom_contents remote: hook_input=json.dumps(hooks_data), remote: File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps remote: return _default_encoder.encode(obj) remote: File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode remote: chunks = self.iterencode(o, _one_shot=True) remote: File "/usr/lib64/python2.7/json/encoder.py", line 270, in iterencode remote: return _iterencode(o, 0) remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0xf6 in position 84253770: invalid start byte To git+ssh://gcc.gnu.org/git/gcc.git e76a53644c9..b18a97e5dd0 devel/coarray_native -> devel/coarray_native Regards Thomas
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #5 from Michel Morin --- Confirmed the fix. Will send a patch to ML. > I had use -std=c++98 This comment helps me a lot to understand what's going on. Thanks!
[Bug c++/102307] [10/11/12 Regression] internal compiler error: in reshape_init_r since r10-6388-ge98ebda074bf8fc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102307
--- Comment #7 from jyhgekyfbkjsyebf at protonmail dot ch ---
Note that:
* based on repro: if I add constexpr to the first ctor and provide body, it
will compile without error. Like this:
constexpr Matrix(double const ()[N][M]) {}
* based on repro: if I comment out the second ctor declaration, compiler will
produce an error (instead of a crash). Like this:
// constexpr Matrix(std::array, N> const );
* based on repro: if I add a data member, and
* provide body to the first ctor, and
* inside use std::copy to fill the member
the compiler will crash. Like this:
```
#include
#include
template struct Matrix {
std::array mat;
Matrix(double const ()[N][M]) {
std::copy([0][0], [0][0] + N * M, std::begin(mat));
}
constexpr Matrix(std::array, N> const );
};
int main() { constexpr Matrix<2, 3> mat{{{1.0, 2.0, 3.0}, {4.0, 5.0, 6.0}}}; }
```
* based on last case: if I replace std::copy call with 2 for loops, and
* add constexpr to first ctor, and
* add -std=c++20 flag
the code will compile. Like this:
```
constexpr Matrix(double const ()[N][M]) {
for (auto n{0U}; n < N; ++n) {
for (auto m{0U}; m < M; ++m)
mat[n * M + m] = arr[n][m];
}
}
```
As you can see, the results due to slight changes are all over the place. I
leave it up to you to interpret them. All of the above is reproducible on
godbolt. I only used local gcc to generate backtrace, everything else was
tinkered with there.
Re: [PATCH 02/18] rs6000: Move __builtin_mffsl to the [always] stanza
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> I over-restricted use of __builtin_mffsl, since I was unaware that it
> automatically uses mffs when mffsl is not available. Paul Clarke
> pointed
> this out in discussion of his SSE 4.1 compatibility patches.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-call.c (__builtin_mffsl): Move from
> [power9]
> to [always].
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
> b/gcc/config/rs6000/rs6000-builtin-new.def
> index 6a28d5189f8..a8c6b9e988f 100644
> --- a/gcc/config/rs6000/rs6000-builtin-new.def
> +++ b/gcc/config/rs6000/rs6000-builtin-new.def
> @@ -208,6 +208,12 @@
>double __builtin_mffs ();
> MFFS rs6000_mffs {}
>
> +; Although the mffsl instruction is only available on POWER9 and
> later
> +; processors, this builtin automatically falls back to mffs on older
> +; platforms. Thus it appears here in the [always] stanza.
> + double __builtin_mffsl ();
> +MFFSL rs6000_mffsl {}
> +
> ; This thing really assumes long double == __ibm128, and I'm told it
> has
> ; been used as such within libgcc. Given that __builtin_pack_ibm128
> ; exists for the same purpose, this should really not be used at
> all.
> @@ -2784,9 +2790,6 @@
>signed long long __builtin_darn_raw ();
> DARN_RAW darn_raw {}
>
> - double __builtin_mffsl ();
> -MFFSL rs6000_mffsl {}
> -
>const signed int __builtin_dtstsfi_eq_dd (const int<6>,
> _Decimal64);
> TSTSFI_EQ_DD dfptstsfi_eq_dd {}
>
Looks reasonable,
Thanks
-Will
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #2 from Alexander Monakov --- That -ftrivial-auto-var-init places an initialization at the point of the declaration is an implementation detail: there's no initializer in the testcase itself, so it is valid C and C++ (spelling this out for the avoidance of doubt).
[Bug target/102211] [12 regression] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211 --- Comment #10 from Jim Wilson --- I attached a patch which is my proposed solution to the RISC-V backend. It adds a new f_register_operand predicate and modifies patterns that use the f constraint to use it instead of register_operand. This was tested with an default language gcc build, glibc build, and glibc check on an unmatched running OpenEmbedded. And an all language gcc build, glibc build, and glibc check on an unleashed running Fedora with an old 4.15 kernel. Both succeeded as well as expected. I'll be trying gcc check next. Meanwhile, the validate_subregs patch was reverted, so we don't immediately need this to fix build errors. But it still might be useful if validate_subregs changes again. Or if it happens to give better code, though I think it won't do anything if validate_subregs is rejecting the subregs we are checking for in f_register_operand.
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Sep 13 2021, Gerald Pfeifer wrote: > % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ > /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 > /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) > /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 > > This looks like it matches existing Linux case already in place? gcc has its own , see gcc/include/float.h in the build directory. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[Bug target/102211] [12 regression] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211 --- Comment #9 from Jim Wilson --- Created attachment 51456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51456=edit proposed RISC-V backend solution
[Bug fortran/102315] New: ICE tree check: expected integer_cst, have save_expr in gfc_trans_array_constructor_value, at fortran/trans-array.c:2056
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102315 Bug ID: 102315 Summary: ICE tree check: expected integer_cst, have save_expr in gfc_trans_array_constructor_value, at fortran/trans-array.c:2056 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- This ICE affects versions down to at least r5 : (gcc configured with --enable-checking=yes) $ cat z1.f90 program p character(4) :: x = '123' character(8) :: y(5) y = [[character(8) :: 'a'//trim(x), 'b', 'c', 'd', 'e']] print *, y end $ gfortran-12-20210905 -c z1.f90 z1.f90:4:59: 4 |y = [[character(8) :: 'a'//trim(x), 'b', 'c', 'd', 'e']] | 1 internal compiler error: tree check: expected integer_cst, have save_expr in gfc_trans_array_constructor_value, at fortran/trans-array.c:2056 0x67e390 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:8688 0x86acd9 tree_int_cst_elt_check(tree_node*, int, char const*, int, char const*) ../../gcc/tree.h:3618 0x86acd9 gfc_trans_array_constructor_value ../../gcc/fortran/trans-array.c:2056 0x86b678 trans_array_constructor ../../gcc/fortran/trans-array.c:2769 0x86b678 gfc_add_loop_ss_code ../../gcc/fortran/trans-array.c:3049 0x86bdd5 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/fortran/trans-array.c:5294 0x8aa21d gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11273 0x8599d7 trans_code ../../gcc/fortran/trans.c:1918 0x88ca85 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6918 0x803e96 translate_all_program_units ../../gcc/fortran/parse.c:6569 0x803e96 gfc_parse_file() ../../gcc/fortran/parse.c:6838 0x8510ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 qinzhao at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-09-13 Status|UNCONFIRMED |ASSIGNED
[Bug fortran/102314] New: [11/12 Regression] ICE in verify_ssa, at tree-ssa.c:1076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102314 Bug ID: 102314 Summary: [11/12 Regression] ICE in verify_ssa, at tree-ssa.c:1076 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20210606 and 20210613 : $ cat z1.f90 program p character(:), allocatable :: y call s(y) !$omp target y = 'abc' !$omp end target contains subroutine s(x) character(:), allocatable :: x x = '123' end end $ gfortran-12-20210905 -c z1.f90 -fopenmp -O0 $ $ gfortran-12-20210905 -c z1.f90 -fopenmp -O2 during GIMPLE pass: ccp z1.f90:4:15: 4 |!$omp target | ^ internal compiler error: Segmentation fault 0xd09e4f crash_signal ../../gcc/toplev.c:328 0xde9ef1 gimple_code ../../gcc/gimple.h:1803 0xde9ef1 gimple_nop_p ../../gcc/gimple.h:6673 0xde9ef1 get_default_value ../../gcc/tree-ssa-ccp.c:283 0xdea60a get_value ../../gcc/tree-ssa-ccp.c:376 0xdea60a ccp_finalize ../../gcc/tree-ssa-ccp.c:992 0xdeac64 do_ssa_ccp ../../gcc/tree-ssa-ccp.c:2960 0xdeac64 execute ../../gcc/tree-ssa-ccp.c:3003 --- $ gfortran-12-20210905 -c z1.f90 -fopenmp # with --enable-checking=yes during GIMPLE pass: ssa z1.f90:4:15: 4 |!$omp target | ^ internal compiler error: Segmentation fault 0xeace0f crash_signal ../../gcc/toplev.c:328 0x11327f0 verify_ssa(bool, bool) ../../gcc/tree-ssa.c:1076 0xdb3187 execute_function_todo ../../gcc/passes.c:2049 0xdb3ef2 execute_todo ../../gcc/passes.c:2096
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 --- Comment #10 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:104c05c5284b7822d770ee51a7d91946c7e56d50 commit r12-3500-g104c05c5284b7822d770ee51a7d91946c7e56d50 Author: Harald Anlauf Date: Mon Sep 13 19:28:10 2021 +0200 Fortran - ensure simplification of bounds of array-valued named constants gcc/fortran/ChangeLog: PR fortran/82314 * decl.c (add_init_expr_to_sym): For proper initialization of array-valued named constants the array bounds need to be simplified before adding the initializer. gcc/testsuite/ChangeLog: PR fortran/82314 * gfortran.dg/pr82314.f90: New test.
[Bug fortran/102313] New: [12 Regression] ICE in gfc_ascii_statement(): Bad statement code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102313 Bug ID: 102313 Summary: [12 Regression] ICE in gfc_ascii_statement(): Bad statement code Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Not really a regression, but changed between 20210808 and 20210822 : $ cat z1.f90 !$omp end scope end $ gfortran-12-20210801 -c z1.f90 -fopenmp f951: internal compiler error: gfc_ascii_statement(): Bad statement code 0x75faa9 gfc_report_diagnostic ../../gcc/fortran/error.c:874 0x761617 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1494 0x7bd910 gfc_ascii_statement(gfc_statement) ../../gcc/fortran/parse.c:2729 0x7bda98 unexpected_statement ../../gcc/fortran/parse.c:2871 0x7c10ba parse_progunit ../../gcc/fortran/parse.c:6161 0x7c24dc gfc_parse_file() ../../gcc/fortran/parse.c:6703 0x80f57f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102312] New: [12 Regression] ICE in gfc_get_dtype_rank_type, at fortran/trans-types.c:1558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102312 Bug ID: 102312 Summary: [12 Regression] ICE in gfc_get_dtype_rank_type, at fortran/trans-types.c:1558 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20210530 and 20210606 : $ cat z1.f90 program p print *, f(null()) contains integer function f(x) bind(c) use iso_c_binding integer(kind=c_int), pointer, intent(in) :: x(..) f = 0 end end $ cat z3.f90 recursive function f(x) result(z) bind(c) use iso_c_binding integer(kind=c_int), pointer, intent(in) :: x(..) real :: z z = f(null()) end $ gfortran-11 -c z1.f90 $ $ gfortran-12-20210905 -c z1.f90 z1.f90:2:21: 2 |print *, f(null()) | 1 internal compiler error: in gfc_get_dtype_rank_type, at fortran/trans-types.c:1558 0x89872f gfc_get_dtype_rank_type(int, tree_node*) ../../gcc/fortran/trans-types.c:1558 0x83f65a gfc_conv_scalar_to_descriptor(gfc_se*, tree_node*, symbol_attribute) ../../gcc/fortran/trans-expr.c:126 0x849ae8 gfc_conv_gfc_desc_to_cfi_desc ../../gcc/fortran/trans-expr.c:5577 0x84d9a7 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:6009 0x8445ea gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9020 0x84b402 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool) ../../gcc/fortran/trans-expr.c:9166 0x875597 gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.c:2582 0x816527 trans_code ../../gcc/fortran/trans.c:2138 0x87307e build_dt ../../gcc/fortran/trans-io.c:2026 0x816507 trans_code ../../gcc/fortran/trans.c:2110 0x83cb64 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6918 0x7c2ee6 translate_all_program_units ../../gcc/fortran/parse.c:6569 0x7c2ee6 gfc_parse_file() ../../gcc/fortran/parse.c:6838 0x80f57f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/85130] Substrings out of range are not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130 --- Comment #7 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8d93ba93d3b13ac3d3c34404cad87732c809605b commit r12-3499-g8d93ba93d3b13ac3d3c34404cad87732c809605b Author: Harald Anlauf Date: Mon Sep 13 19:26:35 2021 +0200 Fortran - fix handling of substring start and end indices gcc/fortran/ChangeLog: PR fortran/85130 * expr.c (find_substring_ref): Handle given substring start and end indices as signed integers, not unsigned. gcc/testsuite/ChangeLog: PR fortran/85130 * gfortran.dg/substr_6.f90: Revert commit r8-7574, adding again test that was erroneously considered as illegal.
[Bug fortran/102311] New: [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 Bug ID: 102311 Summary: [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20210822 and 20210905 : (gcc configured with --enable-checking=yes) $ cat z1.f90 module m contains function f() character(:), allocatable :: f character(1) :: g entry g() end end $ cat z2.f90 module m contains function f() character(:), allocatable :: f character(1) :: g f = 'f' entry g() g = 'g' end end $ gfortran-12-20210822 -c z1.f90 z1.f90:8:3: 8 | end | 1 Error: Entity 'master.0.f' at (1) has a deferred type parameter and requires either the POINTER or ALLOCATABLE attribute $ gfortran-12-20210905 -c z1.f90 z1.f90:3:3: 3 |function f() | 1 Error: Function f at (1) has entry g with mismatched characteristics z1.f90:3:3: 3 |function f() | 1 Error: Function f at (1) has entry g with mismatched characteristics f951: internal compiler error: in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278 0x8422f0 gfc_enforce_clean_symbol_state() ../../gcc/fortran/symbol.c:4278 0x7fd9bc next_statement ../../gcc/fortran/parse.c:1589 0x8034e4 gfc_parse_file() ../../gcc/fortran/parse.c:6638 0x8510ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, Sep 13, 2021 at 07:07:01PM +0200, Tobias Burnus wrote: > Regarding FreeBSD: Does this output different values? – If yes, we know > what to do, otherwise – hmm. > > [...] > > > > Wouldn't it be better to use the __LDBL_* macros anyway and not rely on > > > float.h? The header doesn't want to test what float.h tells about the > > > long double type, but what the compiler knows about it. > > I originally wrote the code to use the internal GCC __LDBL_* macros as > > you suggest, but Tobias complained that then the gfortran-provided .h > > file could not be used to compile the C parts of the program with some > > other C compiler. > For instance, clang does not seem to provide those - and in some cases, > it can be useful to mix gfortran code with code complied by other > compilers (icc, clang, ...). > > Maybe it needs to first check the internal macros and then look for > > the float.h versions if it can't find them? > > I think that makes sense. (Adding a comment that #include is > for non-GCC compilers, only.) At least according to godbolt and my tests, both clang and icc predefine those macros too. But there are other C compilers, sure. So we'd need #if defined (__LDBL_MAX__) && defined (__LDBL_*_) // whatever we need #else #include ... #endif or so. Jakub
Re: [PATCH 01/18] rs6000: Handle overloads during program parsing
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
Hi,
Just a couple cosmetic nits noted below, the majority if which is also in
the original code this is based on.
THanks
-Will
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is duplicating the large function that does the overload
> resolution using the automatically generated data structures instead of
> the old hand-generated ones. This doesn't make the patch terribly easy to
> review, unfortunately. Just be aware that generally we aren't changing
> the logic and functionality of overload handling.
ok
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-c.c (rs6000-builtins.h): New include.
> (altivec_resolve_new_overloaded_builtin): New forward decl.
> (rs6000_new_builtin_type_compatible): New function.
> (altivec_resolve_overloaded_builtin): Call
> altivec_resolve_new_overloaded_builtin.
> (altivec_build_new_resolved_builtin): New function.
> (altivec_resolve_new_overloaded_builtin): Likewise.
> * config/rs6000/rs6000-call.c (rs6000_new_builtin_is_supported):
> Likewise.
> * config/rs6000/rs6000-gen-builtins.c (write_decls): Remove _p from
> name of rs6000_new_builtin_is_supported.
ok
> ---
> gcc/config/rs6000/rs6000-c.c| 1088 +++
> gcc/config/rs6000/rs6000-call.c | 53 ++
> gcc/config/rs6000/rs6000-gen-builtins.c |2 +-
> 3 files changed, 1142 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> index afcb5bb6e39..aafb4e6a98f 100644
> --- a/gcc/config/rs6000/rs6000-c.c
> +++ b/gcc/config/rs6000/rs6000-c.c
> @@ -35,6 +35,9 @@
> #include "langhooks.h"
> #include "c/c-tree.h"
>
> +#include "rs6000-builtins.h"
> +
> +static tree altivec_resolve_new_overloaded_builtin (location_t, tree, void
> *);
>
>
> /* Handle the machine specific pragma longcall. Its syntax is
> @@ -811,6 +814,30 @@ is_float128_p (tree t)
> && t == long_double_type_node));
> }
>
> +static bool
> +rs6000_new_builtin_type_compatible (tree t, tree u)
> +{
> + if (t == error_mark_node)
> +return false;
> +
> + if (INTEGRAL_TYPE_P (t) && INTEGRAL_TYPE_P (u))
> +return true;
> +
> + if (TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
> + && is_float128_p (t) && is_float128_p (u))
> +return true;
> +
> + if (POINTER_TYPE_P (t) && POINTER_TYPE_P (u))
> +{
> + t = TREE_TYPE (t);
> + u = TREE_TYPE (u);
> + if (TYPE_READONLY (u))
> + t = build_qualified_type (t, TYPE_QUAL_CONST);
> +}
> +
> + return lang_hooks.types_compatible_p (t, u);
> +}
> +
ok
> static inline bool
> rs6000_builtin_type_compatible (tree t, int id)
> {
> @@ -927,6 +954,10 @@ tree
> altivec_resolve_overloaded_builtin (location_t loc, tree fndecl,
> void *passed_arglist)
> {
> + if (new_builtins_are_live)
> +return altivec_resolve_new_overloaded_builtin (loc, fndecl,
> +passed_arglist);
> +
>vec *arglist = static_cast *>
> (passed_arglist);
>unsigned int nargs = vec_safe_length (arglist);
>enum rs6000_builtins fcode
ok
> @@ -1930,3 +1961,1060 @@ altivec_resolve_overloaded_builtin (location_t loc,
> tree fndecl,
> return error_mark_node;
>}
> }
> +
> +/* Build a tree for a function call to an Altivec non-overloaded builtin.
> + The overloaded builtin that matched the types and args is described
> + by DESC. The N arguments are given in ARGS, respectively.
> +
> + Actually the only thing it does is calling fold_convert on ARGS, with
> + a small exception for vec_{all,any}_{ge,le} predicates. */
> +
> +static tree
> +altivec_build_new_resolved_builtin (tree *args, int n, tree fntype,
> + tree ret_type,
> + rs6000_gen_builtins bif_id,
> + rs6000_gen_builtins ovld_id)
> +{
> + tree argtypes = TYPE_ARG_TYPES (fntype);
> + tree arg_type[MAX_OVLD_ARGS];
> + tree fndecl = rs6000_builtin_decls_x[bif_id];
> + tree call;
> +
> + for (int i = 0; i < n; i++)
> +arg_type[i] = TREE_VALUE (argtypes), argtypes = TREE_CHAIN (argtypes);
> +
> + /* The AltiVec overloading implementation is overall gross, but this
> + is particularly disgusting. The vec_{all,any}_{ge,le} builtins
> + are completely different for floating-point vs. integer vector
> + types, because the former has vcmpgefp, but the latter should use
> + vcmpgtXX.
> +
> + In practice, the second and third arguments are swapped, and the
> + condition (LT vs. EQ, which is recognizable by bit 1 of the first
> + argument) is reversed. Patch the arguments here before building
> + the resolved CALL_EXPR. */
> + if (n == 3
> + && ovld_id == RS6000_OVLD_VEC_CMPGE_P
> + && bif_id !=
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 13.09.21 18:59, Sandra Loosemore wrote: On 9/13/21 10:51 AM, Jakub Jelinek wrote: On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote: On 13.09.21 17:56, Gerald Pfeifer wrote: This broke bootstrap on i586-unknown-freebsd11: % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 This looks like it matches existing Linux case already in place? Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo | ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output? Regarding FreeBSD: Does this output different values? – If yes, we know what to do, otherwise – hmm. [...] Wouldn't it be better to use the __LDBL_* macros anyway and not rely on float.h? The header doesn't want to test what float.h tells about the long double type, but what the compiler knows about it. I originally wrote the code to use the internal GCC __LDBL_* macros as you suggest, but Tobias complained that then the gfortran-provided .h file could not be used to compile the C parts of the program with some other C compiler. For instance, clang does not seem to provide those - and in some cases, it can be useful to mix gfortran code with code complied by other compilers (icc, clang, ...). Maybe it needs to first check the internal macros and then look for the float.h versions if it can't find them? I think that makes sense. (Adding a comment that #include is for non-GCC compilers, only.) Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[Bug middle-end/102310] New: ICE in visit_ref_for_mod_analysis with OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310 Bug ID: 102310 Summary: ICE in visit_ref_for_mod_analysis with OpenACC Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ygribov at gcc dot gnu.org Target Milestone: --- Created attachment 51455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51455=edit Reprocase Attached code crashes with kernel.f90:30:11: internal compiler error: in visit_ref_for_mod_analysis, at ipa-prop.c:2846 30 | END PROGRAM | ^ 0xa2ea60 visit_ref_for_mod_analysis /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2846 0xa2ea60 visit_ref_for_mod_analysis /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2837 0x992861 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*)) /home/y.gribov/src/gcc-11/gcc/gimple-walk.c:806 0xa3c1a2 ipa_analyze_params_uses_in_bb /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2870 0xa3c1a2 analysis_dom_walker::before_dom_children(basic_block_def*) /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:2953 0x14eb815 dom_walker::walk(basic_block_def*) /home/y.gribov/src/gcc-11/gcc/domwalk.c:309 0xa3786d ipa_analyze_node(cgraph_node*) /home/y.gribov/src/gcc-11/gcc/ipa-prop.c:3024 0x156d357 ipcp_generate_summary /home/y.gribov/src/gcc-11/gcc/ipa-cp.c:6001 0xb45f6c execute_ipa_summary_passes(ipa_opt_pass_d*) /home/y.gribov/src/gcc-11/gcc/passes.c:2248 0x83b68b ipa_passes /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2181 0x83b68b symbol_table::compile() /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2291 0x83d91b symbol_table::compile() /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2271 0x83d91b symbol_table::finalize_compilation_unit() /home/y.gribov/src/gcc-11/gcc/cgraphunit.c:2539 when compiled with OpenACC-accelerated toolchain targeting GCN. It crashes on master and releases/gcc-11 branches. Compile flags: gfortran -ffree-form -ffree-line-length-none -O2 -fopenacc kernel.f90 Target compiler has been built with configure --target=amdgcn-amdhsa --enable-languages=c,lto,fortran --disable-sjlj-exceptions --with-newlib --enable-as-accelerator-for=x86_64-pc-linux-gnu --with-build-time-tools=/home/y.gribov/install/amdgcn-amdhsa-9.0/bin --disable-libquadmath Host compiler has been build with configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-offload-targets=amdgcn-amdhsa=/home/y.gribov/install/gcc-master/usr/local --disable-bootstrap --disable-multilib
Re: Regression with recent change
On 9/13/21 4:18 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
>
>>> So it looks like there's some undefined behavior going on, even before
>>> my patch. I'd like to get some feedback, because this is usually the
>>> type of problems I see in the presence of a smarter threader... things
>>> get shuffled around, problematic code gets isolated, and warning
>>> passes have an easier time (or sometimes harder time) diagnosing
>>> things.
>> The original issue was PRE hanging, so I'd lean towards keeping the test
as-is
>> and instead twiddling any warning flags we can to make the diagnostics go
>> away.
>
> Or use this changed test avoiding the issues that I see with -W -Wall on
> this testcase. I've verified that it still hangs before r194358 and is
> fixed by that revision.
>
> Generally I think, our testsuite, even for ICEs or these kinds of hangs,
> should make an effort to try to write conforming code; if at all possible.
> Here it is possible.
>
> (I don't know if the new threader causes additional warnings, of course,
> but at least the problems with sequence points and uninitialized use of
> 'j' aren't necessary to reproduce the bug)
>
>
> Ciao,
> Michael.
>
> /* { dg-do compile } */
> /* { dg-additional-options "-fno-split-loops" } */
>
> typedef unsigned short uint16_t;
>
> uint16_t a, b;
>
> int *j_global;
> uint16_t f(void)
> {
>int c, **p;
>short d = 2, e = 4;
>
>for (;; b++)
> {
>int *j = j_global, k = 0;
>
>for (; *j; j++)
> {
> for(; c; c++)
> for(; k < 1; k++)
> {
> short *f =
>
> if(b)
> return *f;
> }
> }
>
>if(!c)
> d *= e;
>
>a = d;
>if ((a ? b = 0 : (**p ? : 1) != (d != 1 ? 1 : (b = 0))) != ((k ? a
: 0)
> < (a * (c = k
> **p = 0;
> }
> }
>
Thanks for getting rid of the noise here.
I've simplified the above to show what's going on in the warning on
nds32-elf:
int george, *global;
int stuff(), readme();
int
f (void)
{
int store;
for (;;)
{
int k = 0;
while (global)
{
for (; store; ++store)
{
for (; k < 1; k++)
{
if (readme())
return 0;
}
}
}
store = k;
if (george)
stuff();
}
}
The -Waggressive-loop-optimizations pass is complaining because of an
undefined iteration in the for(;store;++store) loop. But this looks
like it's getting confused by threader having isolated an undefined path.
At the warning, the IL looks like this on entry:
[local count: 55807730]:
goto ; [100.00%]
[local count: 57254340]:
# store_4 = PHI
global.0_25 = global;
if (global.0_25 != 0B)
goto ; [94.50%]
else
goto ; [5.50%]
...
...
[local count: 54105352]:
if (store_4 != 0)
goto ; [99.64%]
else
goto ; [0.36%]
If global.0_25 was true on entry, the read from store_4 would be
undefined. Presumably the warning pass is assuming this path always
gets executed.
This looks like a latent bug. For that matter, the above snippet warns
with -fdisable-tree-thread2, even on x86-64 (and before my
patch).
Aldy
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
error: #error "Can't determine kind of long double"
255 | #error "Can't determine kind of long double"
| ^
Does this work on i586-*-linux?
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
/usr/include/x86/float.h:#define LDBL_MANT_DIG 64
/usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
/usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
This looks like it matches existing Linux case already in place?
Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
It might be that /usr/include/x86/float.h is not used; e.g. there is
$(gcc-src)/ginclude/float.h which undef's the LDBL_MAX_EXP to replace it
by a #define using __LDBL_MAX_EXP. Thus, if those are different from the
values under /usr/include, it might be the reason for the fail?
I think it works under Linux, at least the "x86-64 -m32"
libgfortran.{so,a} build and the -m32 testsuite runs do work.
Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type, but what the compiler knows about it.
I originally wrote the code to use the internal GCC __LDBL_* macros as
you suggest, but Tobias complained that then the gfortran-provided .h
file could not be used to compile the C parts of the program with some
other C compiler. (I guess there are people out in the real world who
want to mash up clang-compiled C code with gfortran programs). Maybe it
needs to first check the internal macros and then look for the float.h
versions if it can't find them?
-Sandra
Re: [PATCH][v2] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS
> On Sep 13, 2021, at 3:31 AM, Richard Biener wrote: > > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE > is not specified by the target and NO_DEBUG if DWARF is not supported. > > It also makes us warn when STABS is enabled and removes the corresponding > diagnostic from the Ada frontend. The warnings are pruned from the > testsuite output via prune_gcc_output. > > This leaves the following targets without debug support: > > pdp11-*-* pdp11 is a.out, dwarf support is difficult I'll admit that I don't know much about debug formats. It is definitely the case that pdp11 output is a.out (it may be BSD 2.x style a.out -- which I think is somewhat different though it's been many years since I looked at that, and then only briefly). I guess that constrains which debug formats can be used, but I don't know any details. pdp11-elf was done as an experiment by someone else, in binutils. I'll ask about the status of that. If it's possible to deliver that, it would presumably enable DWARF support. Is that all common code so it's a matter of enabling it, or would "DWARF machine details for pdp11" have to be defined? paul
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
> On 13.09.21 17:56, Gerald Pfeifer wrote:
> > This broke bootstrap on i586-unknown-freebsd11:
> >
> >In file included from
> > .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
> >.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
> >error: #error "Can't determine kind of long double"
> >255 | #error "Can't determine kind of long double"
> >| ^
> >
> > Does this work on i586-*-linux?
> >
> >
> > % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
> > /usr/include/x86/float.h:#define LDBL_MANT_DIG 64
> > /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
> > /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
> >
> > This looks like it matches existing Linux case already in place?
>
> Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
> ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
>
> It might be that /usr/include/x86/float.h is not used; e.g. there is
> $(gcc-src)/ginclude/float.h which undef's the LDBL_MAX_EXP to replace it
> by a #define using __LDBL_MAX_EXP. Thus, if those are different from the
> values under /usr/include, it might be the reason for the fail?
>
> I think it works under Linux, at least the "x86-64 -m32"
> libgfortran.{so,a} build and the -m32 testsuite runs do work.
Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type, but what the compiler knows about it.
Jakub
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Thomas Schwinge --- This specific issue here has now been fixed -- and in fact was not (or, at least not directly) related to GCC's garbage collector. (Regarding that, PR101292 remains open, however.)
[Bug bootstrap/101574] gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574 --- Comment #10 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:6c79057fae6bbb36c4a4fd61c5b7107a16b71b17 commit r12-3498-g6c79057fae6bbb36c4a4fd61c5b7107a16b71b17 Author: Thomas Schwinge Date: Mon Aug 30 22:36:47 2021 +0200 Don't maintain a warning spec for 'UNKNOWN_LOCATION'/'BUILTINS_LOCATION' [PR101574] This resolves PR101574 "gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]", as (bogusly) reported at commit a61f6afbee370785cf091fe46e2e022748528307: In file included from [...]/source-gcc/gcc/lra-lives.c:43: [...]/source-gcc/gcc/lra-lives.c: In function âvoid make_hard_regno_dead(int)â: [...]/source-gcc/gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] 215 |&& (((ITER) = sparseset_iter_elm (SPARSESET)) || 1); \ |^ [...]/source-gcc/gcc/lra-lives.c:304:3: note: in expansion of macro âEXECUTE_IF_SET_IN_SPARSESETâ 304 | EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, i) | ^~~ gcc/ PR bootstrap/101574 * diagnostic-spec.c (warning_suppressed_at, copy_warning): Handle 'RESERVED_LOCATION_P' locations. * warning-control.cc (get_nowarn_spec, suppress_warning) (copy_warning): Likewise.
[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #3 from Jakub Jelinek ---
Note, we have other issues, consider:
struct A
{
float a;
int b[];
};
int x[4];
struct A c = { 42.0f, { ++x[0], ++x[1], ++x[2], ++x[3] } };
When splitting the init into DECL_INITIAL constant initializer and runtime
initialization, the flexible array member initialization is moved completely
into runtime initialization and nothing remains in DECL_INITIAL from it. For
initializers of fields other than flexible array members that is ok, but by
getting rid of the flex array member initializer the size emitted for the var
in assembly doesn't include the flexible array member at all. That is worse
than having too small .size, in this case it means overwriting whatever is
after the variable. Small .size actually isn't wrong-code...
[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-09-13 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 51454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51454=edit gcc12-pr102295.patch
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
Hi Gerald,
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
error: #error "Can't determine kind of long double"
255 | #error "Can't determine kind of long double"
| ^
Does this work on i586-*-linux?
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
/usr/include/x86/float.h:#define LDBL_MANT_DIG 64
/usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
/usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
This looks like it matches existing Linux case already in place?
Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
It might be that /usr/include/x86/float.h is not used; e.g. there is
$(gcc-src)/ginclude/float.h which undef's the LDBL_MAX_EXP to replace it
by a #define using __LDBL_MAX_EXP. Thus, if those are different from the
values under /usr/include, it might be the reason for the fail?
I think it works under Linux, at least the "x86-64 -m32"
libgfortran.{so,a} build and the -m32 testsuite runs do work.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
[Bug testsuite/102282] New test cases in r12-3320 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102282 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- The UNRESOLVEDs are showing up because these execution tests are currently throwing out bogus compile-time errors (which are properly xfailed with reference to PR92482). Tobias has a patch that has not yet been reviewed or committed that I think addresses the underlying bug. The other FAILs you report should have been fixed by commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7. That's PR100917.
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Wed, 18 Aug 2021, Sandra Loosemore wrote: > I realized last week that having multilib-specific versions of > ISO_Fortran_binding.h (generated by running the compiler to ask what kinds it > supports) was still broken outside of the test support; the directory where > it's being installed isn't on GCC's normal search path. It seemed to me that > it was better to try to find some other solution for this problem than to > venture down what appears to be a rat hole. > > I've come up with this patch to return to a single ISO_Fortran_binding.h file > that uses preprocessor magic to identify the Fortran kind corresponding to the > standard C long double type and the GCC extension types __float128 and > int128_t. : > 2021-08-18 Sandra Loosemore > > libgfortran/ > * ISO_Fortran_binding-1-tmpl.h: Deleted. > * ISO_Fortran_binding-2-tmpl.h: Deleted. > * ISO_Fortran_binding-3-tmpl.h: Deleted. > * ISO_Fortran_binding.h: New file to replace the above. > * Makefile.am (gfor_cdir): Remove MULTISUBDIR. > (ISO_Fortran_binding.h): Simplify to just copy the file. > * Makefile.in: Regenerated. > * mk-kinds-h.sh: Revert pieces no longer needed for > ISO_Fortran_binding.h. This broke bootstrap on i586-unknown-freebsd11: In file included from .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30: .../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2: error: #error "Can't determine kind of long double" 255 | #error "Can't determine kind of long double" | ^ Does this work on i586-*-linux? % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 This looks like it matches existing Linux case already in place? Hmm, I wonder whether this may be related to the bootstrap compiler, which is clang 10.0.1 on FreeBSD 11 and 12. Apparently not, since even setting CC and CXX to recent GCC builds the same issue occurs. (Note this happens after stage 3, so in hindsight not too surprising that it's independent of the bootstrap compiler.) Gerald
Re: [PATCH][v2] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS
On 9/13/2021 9:44 AM, John David Anglin wrote: On 2021-09-13 11:05 a.m., Jeff Law wrote: On 9/13/2021 8:58 AM, John David Anglin wrote: On 2021-09-13 9:53 a.m., Jeff Law wrote: It is in fact also hpux11*, thus all 32bit pa configs that do not support DWARF (for whatever reasons). We used embedded stabs for SOM (the native format for 32bit PA). SOM is a variant of COFF and could easily support dwarf I would think since it had support for fairly arbitrary sections. Hell, it was already supporting embedded stabs as well as HP's proprietary debugging format. But I'd consider 32bit SOM on hpux11 dead too :-) I don't disagree but 32bit SOM still builds on hpux11: https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html Suspect the change will cause a lot of warnings. It might, but with stabs going away something needs to be done with these legacy systems. Either they need to move into the modern world, deal with the diagnostic or get dropped. I believe the 32-bit SOM target should be deprecated. I'm the only one maintaining it and I had some health issues earlier this year. The current versions should suffice for several years. Seems quite reasonable. My main interest is the Debian parisc-linux target. It's fully up to date and thousands of packages are available. Most kernels are 64-bit. Since there's no 64-bit runtime for Linux, we still need the 64-bit hpux target for 64-bit compile testing. Agreed. Given that the 32bit linux and 64bit hpux targets both use ELF + dwarf, they're not in danger of significant fallout from the stabs removal effort. DWARF isn't supported because we lack named sections. That could be worked around but probably the gdb versions that work on 32-bit hpux11 wouldn't support DWARF. I'd be a bit surprised if that were true. dwarf support has been around a long long time in GDB. Hell, it was around when I did the original 64bit PA work back in the 90s. There's a chance it might work with the right section names. However dwarf 5 wouldn't be supported. That's an issue that I noticed recently. Yea, without a modern gdb, 32bit SOM would be stuck back in the dwarf2 era. But even that's better than embedded stabs. jeff
[Bug c++/102300] [10/11/12 Regression] Qualified name of same template in class template is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102300 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||11.1.0, 11.2.0, 12.0 CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Summary|[11/12 Regression] |[10/11/12 Regression] |Qualified name of same |Qualified name of same |template in class template |template in class template |is rejected |is rejected Target Milestone|11.3|10.4 Status|UNCONFIRMED |NEW Known to work||10.3.0 Last reconfirmed||2021-09-13 --- Comment #1 from Patrick Palka --- Started with r11-8035 (which was also backported to the 10 branch as r10-9851)
Re: [PATCH][v2] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS
On 2021-09-13 11:05 a.m., Jeff Law wrote: > > > On 9/13/2021 8:58 AM, John David Anglin wrote: >> On 2021-09-13 9:53 a.m., Jeff Law wrote: It is in fact also hpux11*, thus all 32bit pa configs that do not support DWARF (for whatever reasons). >>> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a >>> variant of COFF and could easily support dwarf I would think since >>> it had support for fairly arbitrary sections. Hell, it was already >>> supporting embedded stabs as well as HP's proprietary debugging format. >>> >>> But I'd consider 32bit SOM on hpux11 dead too :-) >> I don't disagree but 32bit SOM still builds on hpux11: >> https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html >> >> Suspect the change will cause a lot of warnings. > It might, but with stabs going away something needs to be done with these > legacy systems. Either they need to move into the modern world, > deal with the diagnostic or get dropped. I believe the 32-bit SOM target should be deprecated. I'm the only one maintaining it and I had some health issues earlier this year. The current versions should suffice for several years. My main interest is the Debian parisc-linux target. It's fully up to date and thousands of packages are available. Most kernels are 64-bit. Since there's no 64-bit runtime for Linux, we still need the 64-bit hpux target for 64-bit compile testing. > >> >> There is some support for hpux10/11 in qemu but it takes a lot of work to >> provide the build infrastructure needed for gcc. > I would think so. Recently had to move my build infrastructure to a "new" machine, so I'm fully aware that it's not easy. > >> >> DWARF isn't supported because we lack named sections. That could be worked >> around >> but probably the gdb versions that work on 32-bit hpux11 wouldn't support >> DWARF. > I'd be a bit surprised if that were true. dwarf support has been around a > long long time in GDB. Hell, it was around when I did the original > 64bit PA work back in the 90s. There's a chance it might work with the right section names. However dwarf 5 wouldn't be supported. That's an issue that I noticed recently. Dave -- John David Anglin dave.ang...@bell.net
