Re: [PATCH 02/11] riscv: xtheadmempair: Fix CFA reg notes
On 3/17/24 2:22 PM, Christoph Müllner wrote: On Fri, Apr 28, 2023 at 8:12 AM Christoph Muellner wrote: From: Christoph Müllner The current implementation triggers an assertion in dwarf2out_frame_debug_cfa_offset() under certain circumstances. The standard code uses REG_FRAME_RELATED_EXPR notes instead of REG_CFA_OFFSET notes when saving registers on the stack. So let's do this as well. gcc/ChangeLog: * config/riscv/thead.cc (th_mempair_save_regs): Emit REG_FRAME_RELATED_EXPR notes in prologue. Signed-off-by: Christoph Müllner This patch applies cleanly on GCC 13. Ok to backport to GCC 13 (fixing PR114160)? Yes. Please go ahead. Thanks, jeff
Re: [PATCH V3] rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di built-in [PR113950]
Hi, on 2024/3/16 04:34, Peter Bergner wrote: > On 3/6/24 3:27 AM, Kewen.Lin wrote: >> on 2024/3/4 02:55, jeevitha wrote: >>> The following patch has been bootstrapped and regtested on >>> powerpc64le-linux. >>> >>> When we expand the __builtin_vsx_splat_2di function, we were allowing >>> immediate >>> value for second operand which causes an unrecognizable insn ICE. Even >>> though >>> the immediate value was forced into a register, it wasn't correctly assigned >>> to the second operand. So corrected the assignment of op1 to operands[1]. > [snip] >> As the discussions in the thread of the previous versions, I think >> Segher agreed this approach, so OK for trunk with the above nits >> tweaked, thanks! > > The bogus vsx_splat_ code goes all the way back to GCC 8, so we > should backport this fix. Segher and Ke Wen, can we get an approval > to backport this to all the open release branches (GCC 13, 12, 11)? > Thanks. Sure, okay for backporting this to all active branches, thanks! > > Jeevitha, once we get approval, please perform the backports. > > Peter > > BR, Kewen
[committed] hppa: Improve handling of REG+D addresses when generating PA 2.0 code
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
hppa: Improve handling of REG+D addresses when generating PA 2.0 code
In looking at PR 112415, it became clear that improvements could be
made in the handling of loads and stores using REG+D addresses. A
change in 2002 conflated two issues:
1) We can't generate insns with 14-bit displacements before reload
completes when generating PA 1.x code since floating-point loads and
stores only support 5-bit offsets in PA 1.x.
2) The GNU ELF 32-bit linker lacks relocation support for PA 2.0
floating point instructions with 14-bit displacements. These
relocations affect instructions with symbolic references.
The result of the change was to block creation of PA 2.0 instructions
with 14-bit REG_D displacements for SImode, DImode, SFmode and DFmode
on the GNU linux target before reload. This was unnecessary as these
instructions don't need relocation.
This change revise the INT14_OK_STRICT define to allow creation
of instructions with 14-bit REG+D addresses before reload when
generating PA 2.0 code.
2024-03-17 John David Anglin
gcc/ChangeLog:
PR rtl-optimization/112415
* config/pa/pa.cc (pa_emit_move_sequence): Revise condition
for symbolic memory operands.
(pa_legitimate_address_p): Revise LO_SUM condition.
* config/pa/pa.h (INT14_OK_STRICT): Revise define. Move
comment about GNU linker to predicates.md.
* config/pa/predicates.md (floating_point_store_memory_operand):
Revise condition for symbolic memory operands. Update
comment.
diff --git a/gcc/config/pa/pa.cc b/gcc/config/pa/pa.cc
index 129289f8e62..d7666103de8 100644
--- a/gcc/config/pa/pa.cc
+++ b/gcc/config/pa/pa.cc
@@ -2039,7 +2039,8 @@ pa_emit_move_sequence (rtx *operands, machine_mode mode,
rtx scratch_reg)
op1 = replace_equiv_address (op1, scratch_reg);
}
}
- else if ((!INT14_OK_STRICT && symbolic_memory_operand (op1, VOIDmode))
+ else if (((TARGET_ELF32 || !TARGET_PA_20)
+ && symbolic_memory_operand (op1, VOIDmode))
|| IS_LO_SUM_DLT_ADDR_P (XEXP (op1, 0))
|| IS_INDEX_ADDR_P (XEXP (op1, 0)))
{
@@ -2088,7 +2089,8 @@ pa_emit_move_sequence (rtx *operands, machine_mode mode,
rtx scratch_reg)
op0 = replace_equiv_address (op0, scratch_reg);
}
}
- else if ((!INT14_OK_STRICT && symbolic_memory_operand (op0, VOIDmode))
+ else if (((TARGET_ELF32 || !TARGET_PA_20)
+ && symbolic_memory_operand (op0, VOIDmode))
|| IS_LO_SUM_DLT_ADDR_P (XEXP (op0, 0))
|| IS_INDEX_ADDR_P (XEXP (op0, 0)))
{
@@ -11032,18 +11040,22 @@ pa_legitimate_address_p (machine_mode mode, rtx x,
bool strict, code_helper)
&& (strict ? STRICT_REG_OK_FOR_BASE_P (y)
: REG_OK_FOR_BASE_P (y)))
{
+ y = XEXP (x, 1);
+
/* Needed for -fPIC */
if (mode == Pmode
- && GET_CODE (XEXP (x, 1)) == UNSPEC)
+ && GET_CODE (y) == UNSPEC)
return true;
- if (!INT14_OK_STRICT
- && (strict || !(reload_in_progress || reload_completed))
+ /* Before reload, we need support for 14-bit floating
+point loads and stores, and associated relocations. */
+ if ((TARGET_ELF32 || !INT14_OK_STRICT)
+ && !reload_completed
&& mode != QImode
&& mode != HImode)
return false;
- if (CONSTANT_P (XEXP (x, 1)))
+ if (CONSTANT_P (y))
return true;
}
return false;
diff --git a/gcc/config/pa/pa.h b/gcc/config/pa/pa.h
index 7abaeae269e..403f16c5cb5 100644
--- a/gcc/config/pa/pa.h
+++ b/gcc/config/pa/pa.h
@@ -828,19 +828,8 @@ extern int may_call_alloca;
/* Nonzero if 14-bit offsets can be used for all loads and stores.
This is not possible when generating PA 1.x code as floating point
- accesses only support 5-bit offsets. Note that we do not forbid
- the use of 14-bit offsets prior to reload. Instead, we use secondary
- reloads to fix REG+D memory addresses for floating-point accesses.
-
- FIXME: the GNU ELF linker clobbers the LSB of the FP register number
- in PA 2.0 floating-point insns with long displacements. This is
- because R_PARISC_DPREL14WR and other relocations like it are not
- yet supported by GNU ld. For now, we reject long displacements
- on this target. */
-
-#define INT14_OK_STRICT \
- (TARGET_SOFT_FLOAT \
- || (TARGET_PA_20 && !TARGET_ELF32 && !TARGET_ELF64))
+ accesses only support 5-bit offsets. */
+#define INT14_OK_STRICT (TARGET_SOFT_FLOAT || TARGET_PA_20)
/* The macros REG_OK_FOR..._P assume that the arg is a REG rtx
and check its validity for a certain class.
diff --git a/gcc/config/pa/predicates.md b/gcc/config/pa/predicates.md
index
[PATCH] Add missing hf/bf patterns.
It fixes ICE of unrecognized logic operation insn which is generated by
lroundmn2 expanders.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/114334
* config/i386/i386.md (mode): Add new number V8BF,V16BF,V32BF.
(MODEF248): New mode iterator.
(ssevecmodesuffix): Hanlde BF and HF.
* config/i386/sse.md (andnot3): Extend to HF/BF.
(3): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr114334.c: New test.
---
gcc/config/i386/i386.md | 13 +
gcc/config/i386/sse.md | 22 +++---
gcc/testsuite/gcc.target/i386/pr114334.c | 8
3 files changed, 28 insertions(+), 15 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr114334.c
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index df97a2d6270..11fdc6af3fa 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -543,8 +543,9 @@ (define_attr "type"
;; Main data type used by the insn
(define_attr "mode"
- "unknown,none,QI,HI,SI,DI,TI,OI,XI,HF,BF,SF,DF,XF,TF,V32HF,V16HF,V8HF,
- V16SF,V8SF,V4DF,V4SF,V2DF,V2SF,V1DF,V8DF,V4HF,V4BF,V2HF,V2BF"
+ "unknown,none,QI,HI,SI,DI,TI,OI,XI,HF,BF,SF,DF,XF,TF,
+ V32HF,V16HF,V8HF,V4HF,V2HF,V32BF,V16BF,V8BF,V4BF,V2BF,
+ V16SF,V8SF,V4DF,V4SF,V2DF,V2SF,V1DF,V8DF"
(const_string "unknown"))
;; The CPU unit operations uses.
@@ -1323,6 +1324,8 @@ (define_mode_attr ashl_input_operand
;; SSE and x87 SFmode and DFmode floating point modes
(define_mode_iterator MODEF [SF DF])
+(define_mode_iterator MODEF248 [BF HF SF (DF "TARGET_SSE2")])
+
;; SSE floating point modes
(define_mode_iterator MODEFH [(HF "TARGET_AVX512FP16") SF DF])
@@ -1347,7 +1350,8 @@ (define_mode_attr ssemodesuffix
(V64QI "b") (V32HI "w") (V16SI "d") (V8DI "q")])
;; SSE vector suffix for floating point modes
-(define_mode_attr ssevecmodesuffix [(SF "ps") (DF "pd")])
+;; BF HF use same suffix as SF for logic operations.
+(define_mode_attr ssevecmodesuffix [(BF "ps") (HF "ps") (SF "ps") (DF "pd")])
;; SSE vector mode corresponding to a scalar mode
(define_mode_attr ssevecmode
@@ -1357,7 +1361,8 @@ (define_mode_attr ssevecmodelower
;; AVX512F vector mode corresponding to a scalar mode
(define_mode_attr avx512fvecmode
- [(QI "V64QI") (HI "V32HI") (SI "V16SI") (DI "V8DI") (SF "V16SF") (DF
"V8DF")])
+ [(QI "V64QI") (HI "V32HI") (SI "V16SI") (DI "V8DI")
+ (HF "V32HF") (BF "V32BF") (SF "V16SF") (DF "V8DF")])
;; Instruction suffix for REX 64bit operators.
(define_mode_attr rex64suffix [(SI "{l}") (DI "{q}")])
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 1bc614ab702..3286d3a4fac 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -5125,12 +5125,12 @@ (define_expand "signbit2"
;; because the native instructions read the full 128-bits.
(define_insn "*andnot3"
- [(set (match_operand:MODEF 0 "register_operand" "=x,x,v,v")
- (and:MODEF
- (not:MODEF
- (match_operand:MODEF 1 "register_operand" "0,x,v,v"))
- (match_operand:MODEF 2 "register_operand" "x,x,v,v")))]
- "SSE_FLOAT_MODE_P (mode)"
+ [(set (match_operand:MODEF248 0 "register_operand" "=x,x,v,v")
+ (and:MODEF248
+ (not:MODEF248
+ (match_operand:MODEF248 1 "register_operand" "0,x,v,v"))
+ (match_operand:MODEF248 2 "register_operand" "x,x,v,v")))]
+ "TARGET_SSE"
{
char buf[128];
const char *ops;
@@ -5257,11 +5257,11 @@ (define_insn "*andnot3"
(const_string "TI")))])
(define_insn "3"
- [(set (match_operand:MODEF 0 "register_operand" "=x,x,v,v")
- (any_logic:MODEF
- (match_operand:MODEF 1 "register_operand" "%0,x,v,v")
- (match_operand:MODEF 2 "register_operand" "x,x,v,v")))]
- "SSE_FLOAT_MODE_P (mode)"
+ [(set (match_operand:MODEF248 0 "register_operand" "=x,x,v,v")
+ (any_logic:MODEF248
+ (match_operand:MODEF248 1 "register_operand" "%0,x,v,v")
+ (match_operand:MODEF248 2 "register_operand" "x,x,v,v")))]
+ "TARGET_SSE"
{
char buf[128];
const char *ops;
diff --git a/gcc/testsuite/gcc.target/i386/pr114334.c
b/gcc/testsuite/gcc.target/i386/pr114334.c
new file mode 100644
index 000..8e38e24cd16
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr114334.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast -mavx512fp16" } */
+
+long
+foo(_Float16 f)
+{
+ return __builtin_lroundf16(f);
+}
--
2.31.1
Re: [PATCH, v2] Fortran: fix for absent array argument passed to optional dummy [PR101135]
Hi Mikael, On 3/17/24 22:04, Mikael Morin wrote: diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index 3673fa40720..a7717a8107e 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -7526,6 +7526,17 @@ gfc_get_dataptr_offset (stmtblock_t *block, tree parm, tree desc, tree offset, /* Set the target data pointer. */ offset = gfc_build_addr_expr (gfc_array_dataptr_type (desc), tmp); + + /* Check for optional dummy argument being present. Arguments of BIND(C) + procedures are excepted here since they are handled differently. */ + if (expr->expr_type == EXPR_VARIABLE + && expr->symtree->n.sym->attr.dummy + && expr->symtree->n.sym->attr.optional + && !is_CFI_desc (NULL, expr)) I think the condition could additionally check the lack of subreferences. But it's maybe not worth the trouble, and the patch is conservatively correct as is, so OK. I have thought about the conditions here for some time and did not find better ones. They need to be broad enough to catch the case in gfortran.dg/missing_optional_dummy_6a.f90 that (according to the tree-dump) was not properly handled previously and would have triggered ubsan at some point in the future when someone tried to change that testcase from currently dg-do compile to dg-do run... (After the patch it would pass, but I didn't dare to change the dg-do). I have pushed the patch as-is, but feel free to post testcases not covered (or improperly covered) to narrow this down further... Thanks for the patch. Thanks for the review! Harald + offset = build3_loc (input_location, COND_EXPR, TREE_TYPE (offset), + gfc_conv_expr_present (expr->symtree->n.sym), offset, + fold_convert (TREE_TYPE (offset), gfc_index_zero_node)); + gfc_conv_descriptor_data_set (block, parm, offset); }
Re: [PATCH v2 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]
Le 17/03/2024 à 21:57, Harald Anlauf a écrit :
Hi Mikael,
thanks for the patch!
Regarding the first part of the patch, I think that fixing bad testcases
can be done at any time. Retaining identified, broken testcases means
that one may hit bogus regressions, hindering progress.
The second part of the patch looks at first glance fine to me. And as
the patch changes less than its size suggests, in particular due to
code refactoring, I don't see a reason to postpone it to stage 1.
What worries me a bit is the changes of gfc_current_ns.
It's the kind of change that has broad impact and can uncover weird
behaviors.
(On the contrary, deferring it to stage 1 might make future backports
from 15 for later patches on top of that code harder.
This is my opinion, and others might see this differently.)
To be honest, I posted it now in the hope that someone would be willing
to push it before stage 1 so that I can get rid of it sooner.
On 3/17/24 17:57, Mikael Morin wrote:
* expr.cc (check_restricted): Remove the case where symbol is dummy
and declared in the current ns. Use gfc_get_spec_ns to get the
right namespace.
Looking at the original and new code, I don't fully understand
that part of the commit message: the changed check comes into play
when the symbol is *not* in_common, ..., a dummy, ...
So technically, we didn't access the (now removed) formal_arg_flag
here in those cases.
Or am I missing something?
Oh, do you really read all of my prose?
I wrote it from vague memories of debugging the problem weeks ago,
without thinking very much about it.
Actually, there are two dummy arguments here.
There is the one we are checking, and its bounds should be a
specification expression, so could possibly be another dummy variable
(the "sym" variable in this context).
The condition was allowing variables declared in the same scope to
appear in specification expression of dummy arguments.
I will try to rephrase the sentence, as it sounds more clear (and
sensible) as expressed here.
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 82a642b01f7..0852bc5f493 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3509,19 +3509,13 @@ check_restricted (gfc_expr *e)
if (!check_references (e->ref, _restricted))
break;
- /* gfc_is_formal_arg broadcasts that a formal argument list is
being
- processed in resolve.cc(resolve_formal_arglist). This is done so
- that host associated dummy array indices are accepted (PR23446).
- This mechanism also does the same for the specification expressions
- of array-valued functions. */
if (e->error
|| sym->attr.in_common
|| sym->attr.use_assoc
|| sym->attr.dummy
|| sym->attr.implied_index
|| sym->attr.flavor == FL_PARAMETER
- || is_parent_of_current_ns (sym->ns)
- || (gfc_is_formal_arg () && (sym->ns == gfc_current_ns)))
+ || is_parent_of_current_ns (gfc_get_spec_ns (sym)))
{
t = true;
break;
diff --git a/gcc/testsuite/gfortran.dg/spec_expr_8.f90
b/gcc/testsuite/gfortran.dg/spec_expr_8.f90
new file mode 100644
index 000..5885810d421
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/spec_expr_8.f90
@@ -0,0 +1,24 @@
+! { dg-do compile }
+!
+! PR fortran/111781
+! We used to reject the example below because the dummy procedure g was
+! setting the current namespace without properly restoring it, which
broke
+! the specification expression check for the dimension of A later on.
+!
+! Contributed by Markus Vikhamar-Sandberg
Is the reporter's first name Markus or Rasmus?
Rasmus.
Reviews are sometimes helpful, more often than not.
I don't know where the Markus name comes from.
Thanks for the review.
Re: [PATCH, v2] Fortran: fix for absent array argument passed to optional dummy [PR101135]
Le 15/03/2024 à 20:32, Harald Anlauf a écrit : Dear all, as there has been some good progress in the handling of optional dummy arguments, I looked again at this PR and a patch for it that I withdrew as it turned out incomplete. It turned out that it now needs only a minor adjustment for optional dummy arguments of procedures with bind(c) attribute so that ubsan checking does not trigger. Along this way I extended the previous testcase to exercise to some extent combinations of bind(c) and non-bind(c) procedures and found one failure (since at least gcc-9) that is genuine: passing a missing optional from a bind(c) procedure to an assumed-rank dummy, see PR114355. The corresponding test is commented in the testcase. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald (...) From b3079a82a220477704f8156207239e4af4103ea9 Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Fri, 15 Mar 2024 20:14:07 +0100 Subject: [PATCH] Fortran: fix for absent array argument passed to optional dummy [PR101135] gcc/fortran/ChangeLog: PR fortran/101135 * trans-array.cc (gfc_get_dataptr_offset): Check for optional arguments being present before dereferencing data pointer. gcc/testsuite/ChangeLog: PR fortran/101135 * gfortran.dg/missing_optional_dummy_6a.f90: Adjust diagnostic pattern. * gfortran.dg/ubsan/missing_optional_dummy_8.f90: New test. --- gcc/fortran/trans-array.cc| 11 ++ .../gfortran.dg/missing_optional_dummy_6a.f90 | 2 +- .../ubsan/missing_optional_dummy_8.f90| 108 ++ 3 files changed, 120 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gfortran.dg/ubsan/missing_optional_dummy_8.f90 diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index 3673fa40720..a7717a8107e 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -7526,6 +7526,17 @@ gfc_get_dataptr_offset (stmtblock_t *block, tree parm, tree desc, tree offset, /* Set the target data pointer. */ offset = gfc_build_addr_expr (gfc_array_dataptr_type (desc), tmp); + + /* Check for optional dummy argument being present. Arguments of BIND(C) + procedures are excepted here since they are handled differently. */ + if (expr->expr_type == EXPR_VARIABLE + && expr->symtree->n.sym->attr.dummy + && expr->symtree->n.sym->attr.optional + && !is_CFI_desc (NULL, expr)) I think the condition could additionally check the lack of subreferences. But it's maybe not worth the trouble, and the patch is conservatively correct as is, so OK. Thanks for the patch. +offset = build3_loc (input_location, COND_EXPR, TREE_TYPE (offset), +gfc_conv_expr_present (expr->symtree->n.sym), offset, +fold_convert (TREE_TYPE (offset), gfc_index_zero_node)); + gfc_conv_descriptor_data_set (block, parm, offset); }
Re: [PATCH v2 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]
Hi Mikael,
thanks for the patch!
Regarding the first part of the patch, I think that fixing bad testcases
can be done at any time. Retaining identified, broken testcases means
that one may hit bogus regressions, hindering progress.
The second part of the patch looks at first glance fine to me. And as
the patch changes less than its size suggests, in particular due to
code refactoring, I don't see a reason to postpone it to stage 1.
(On the contrary, deferring it to stage 1 might make future backports
from 15 for later patches on top of that code harder.
This is my opinion, and others might see this differently.)
On 3/17/24 17:57, Mikael Morin wrote:
* expr.cc (check_restricted): Remove the case where symbol is dummy
and declared in the current ns. Use gfc_get_spec_ns to get the
right namespace.
Looking at the original and new code, I don't fully understand
that part of the commit message: the changed check comes into play
when the symbol is *not* in_common, ..., a dummy, ...
So technically, we didn't access the (now removed) formal_arg_flag
here in those cases.
Or am I missing something?
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 82a642b01f7..0852bc5f493 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3509,19 +3509,13 @@ check_restricted (gfc_expr *e)
if (!check_references (e->ref, _restricted))
break;
- /* gfc_is_formal_arg broadcasts that a formal argument list is being
-processed in resolve.cc(resolve_formal_arglist). This is done so
-that host associated dummy array indices are accepted (PR23446).
-This mechanism also does the same for the specification expressions
-of array-valued functions. */
if (e->error
|| sym->attr.in_common
|| sym->attr.use_assoc
|| sym->attr.dummy
|| sym->attr.implied_index
|| sym->attr.flavor == FL_PARAMETER
- || is_parent_of_current_ns (sym->ns)
- || (gfc_is_formal_arg () && (sym->ns == gfc_current_ns)))
+ || is_parent_of_current_ns (gfc_get_spec_ns (sym)))
{
t = true;
break;
diff --git a/gcc/testsuite/gfortran.dg/spec_expr_8.f90
b/gcc/testsuite/gfortran.dg/spec_expr_8.f90
new file mode 100644
index 000..5885810d421
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/spec_expr_8.f90
@@ -0,0 +1,24 @@
+! { dg-do compile }
+!
+! PR fortran/111781
+! We used to reject the example below because the dummy procedure g was
+! setting the current namespace without properly restoring it, which broke
+! the specification expression check for the dimension of A later on.
+!
+! Contributed by Markus Vikhamar-Sandberg
Is the reporter's first name Markus or Rasmus?
Thanks,
Harald
Re: [PATCH 02/11] riscv: xtheadmempair: Fix CFA reg notes
On Fri, Apr 28, 2023 at 8:12 AM Christoph Muellner wrote: > > From: Christoph Müllner > > The current implementation triggers an assertion in > dwarf2out_frame_debug_cfa_offset() under certain circumstances. > The standard code uses REG_FRAME_RELATED_EXPR notes instead > of REG_CFA_OFFSET notes when saving registers on the stack. > So let's do this as well. > > gcc/ChangeLog: > > * config/riscv/thead.cc (th_mempair_save_regs): > Emit REG_FRAME_RELATED_EXPR notes in prologue. > > Signed-off-by: Christoph Müllner This patch applies cleanly on GCC 13. Ok to backport to GCC 13 (fixing PR114160)? > --- > gcc/config/riscv/thead.cc | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc > index 75203805310..d7e3cf80d9b 100644 > --- a/gcc/config/riscv/thead.cc > +++ b/gcc/config/riscv/thead.cc > @@ -368,8 +368,12 @@ th_mempair_save_regs (rtx operands[4]) >rtx set2 = gen_rtx_SET (operands[2], operands[3]); >rtx insn = emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, set1, > set2))); >RTX_FRAME_RELATED_P (insn) = 1; > - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set1)); > - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set2)); > + > + REG_NOTES (insn) = alloc_EXPR_LIST (REG_FRAME_RELATED_EXPR, > + copy_rtx (set1), REG_NOTES (insn)); > + > + REG_NOTES (insn) = alloc_EXPR_LIST (REG_FRAME_RELATED_EXPR, > + copy_rtx (set2), REG_NOTES (insn)); > } > > /* Similar like riscv_restore_reg, but restores two registers from memory > -- > 2.40.1 >
New Swedish PO file for 'gcc' (version 14.1-b20240218)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-14.1-b20240218.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]
I was a little bit too confident below. After review of all _M_singular
usages I found another necessary fix.
After this one for sure we will be able to define
__cpp_lib_null_iterators even in Debug mode.
libstdc++: Fix N3344 behavior on _Safe_iterator::_M_can_advance
We shall be able to advance from a 0 offset a value-initialized
iterator.
libstdc++-v3/ChangeLog:
* include/debug/safe_iterator.tcc
(_Safe_iterator<>::_M_can_advance):
Accept 0 offset advance on value-initialized iterator.
* testsuite/23_containers/vector/debug/n3644.cc: New test case.
Ok to commit ?
François
On 17/03/2024 17:52, François Dumont wrote:
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macro for
debug mode?
After this fix of local_iterator I think we can indeed.
In fact the added 11316.cc was already passing for
unordered_set<>::local_iterator but simply because we were missing the
singular check. Both issues solved with this patch.
I found the version.def file to cleanup but no idea how to regenerate
version.h from it so I'll let you do it, ok ?
libstdc++: Fix _Safe_local_iterator<>::_M_valid_range
Unordered container local_iterator range shall not contain any
singular
iterator unless both iterators are value-initialized.
libstdc++-v3/ChangeLog:
* include/debug/safe_local_iterator.tcc
(_Safe_local_iterator::_M_valid_range): Add
_M_value_initialized and
_M_singular checks.
* testsuite/23_containers/unordered_set/debug/114316.cc:
New test case.
Ok to commit ?
Françoisdiff --git a/libstdc++-v3/include/debug/safe_iterator.tcc
b/libstdc++-v3/include/debug/safe_iterator.tcc
index 4b2baf2980e..deaa84d0a1f 100644
--- a/libstdc++-v3/include/debug/safe_iterator.tcc
+++ b/libstdc++-v3/include/debug/safe_iterator.tcc
@@ -86,6 +86,9 @@ namespace __gnu_debug
_Safe_iterator<_Iterator, _Sequence, _Category>::
_M_can_advance(difference_type __n, bool __strict) const
{
+ if (this->_M_value_initialized() && __n == 0)
+ return true;
+
if (this->_M_singular())
return false;
diff --git a/libstdc++-v3/testsuite/23_containers/vector/debug/n3644.cc
b/libstdc++-v3/testsuite/23_containers/vector/debug/n3644.cc
new file mode 100644
index 000..052c52f26b7
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/vector/debug/n3644.cc
@@ -0,0 +1,16 @@
+// { dg-do run { target c++11 } }
+// { dg-require-debug-mode "" }
+
+#include
+#include
+
+#include
+
+int main()
+{
+ std::vector::iterator it{};
+ auto cpy = it;
+ std::advance(it, 0);
+ VERIFY( it == cpy );
+ return 0;
+}
Re: [PATCH] testsuite: Define _POSIX_C_SOURCE for test
On Mar 10, 2024, at 10:26 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk?
Ok.
> As the tests assume that strndup() is visible (only part of
> POSIX.1-2008) define the guard to ensure that it's visible. Currently,
> glibc appears to always have this defined in C++, newlib does not.
>
> Without this patch, fails like this can be seen:
>
> Testing analyzer/strndup-1.c, -std=c++98
> .../strndup-1.c: In function 'void test_1(const char*)':
> .../strndup-1.c:11:13: error: 'strndup' was not declared in this scope; did
> you mean 'strncmp'?
> .../strndup-1.c: In function 'void test_2(const char*)':
> .../strndup-1.c:16:13: error: 'strndup' was not declared in this scope; did
> you mean 'strncmp'?
> .../strndup-1.c: In function 'void test_3(const char*)':
> .../strndup-1.c:21:13: error: 'strndup' was not declared in this scope; did
> you mean 'strncmp'?
>
> Patch has been verified on Linux.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/analyzer/strndup-1.c: Define _POSIX_C_SOURCE.
>
> Signed-off-by: Torbjörn SVENSSON
> ---
> gcc/testsuite/c-c++-common/analyzer/strndup-1.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> b/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> index 85ccae85d83..577ece0cfba 100644
> --- a/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> +++ b/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> @@ -1,4 +1,5 @@
> /* { dg-skip-if "no strndup in libc" { *-*-darwin[789]* *-*-darwin10*
> hppa*-*-hpux* *-*-mingw* *-*-vxworks* } } */
> +/* { dg-additional-options "-D_POSIX_C_SOURCE=200809L" } */
>
> #include
> #include
Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64
On Feb 15, 2024, at 6:08 AM, Jonathan Yong <10wa...@gmail.com> wrote:
>
> Attached patch OK?
Ok.
> Copy/pasted for review convenience.
>
> diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c
> b/gcc/testsuite/c-c++-common/Wrestrict.c
> index 4d005a618b3..57a3f67e21e 100644
> --- a/gcc/testsuite/c-c++-common/Wrestrict.c
> +++ b/gcc/testsuite/c-c++-common/Wrestrict.c
> @@ -381,14 +381,14 @@ void test_memcpy_range_exceed (char *d, const char *s)
> T (d + i, s + 1, 3); /* { dg-warning "accessing 3 bytes at offsets
> \\\[\[0-9\]+, \[0-9\]+] and 1 overlaps 1 byte" "memcpy" } */
> #if __SIZEOF_SIZE_T__ == 8
> - /* Verfiy the offset and size computation is correct. The overlap
> - offset mentioned in the warning plus sthe size of the access must
> + /* Verify the offset and size computation is correct. The overlap
> + offset mentioned in the warning plus the size of the access must
> not exceed DIFF_MAX. */
> - T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target lp64 } } */
> - T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target lp64 } } */
> + T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> + T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> - T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target lp64 } } */
> - T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target lp64 } } */
> + T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> + T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> #elif __SIZEOF_SIZE_T__ == 4
> T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[2147483645, 2147483647] overlaps 3 bytes at offset 2147483642" "ILP32" {
> target ilp32 } } */
> T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[2147483645, 2147483647] and 0 overlaps 3 bytes at offset 2147483642"
> "ILP32" { target ilp32 } }
> */<0001-c-c-common-Wrestrict.c-fix-some-typos-and-enable-for.patch>
[PATCH v2 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]
This fixes a spurious invalid variable in specification expression error.
The problem is caused by improper restoration of formal_arg_flag to false
(instead of restoring it to its previous value). This happens with the
testcase from the PR where a dummy argument is itself a procedure with dummy
arguments. At the time that dummy procedure has been resolved, its dummy
arguments have been resolved and the flag has been reset to false. The
condition checking that flag when resolving the array spec expressions of
the next dummy then triggers the error.
The fix removes a condition disabling proper check of specification
expressions, together with the formal_arg_flag global variable associated
with it. As the specification expression checking code is dependent on the
current namespace, the latter is set before array spec resolution (and
restored after). Two new functions are introduced to select the right
namespace for that.
PR fortran/111781
gcc/fortran/ChangeLog:
* symbol.cc (gfc_get_procedure_ns, gfc_get_spec_ns): New functions.
* gfortran.h (gfc_get_procedure_ns, gfc_get_spec ns): Declare them.
(gfc_is_formal_arg): Remove.
* expr.cc (check_restricted): Remove the case where symbol is dummy
and declared in the current ns. Use gfc_get_spec_ns to get the
right namespace.
* resolve.cc (gfc_is_formal_arg, formal_arg_flag): Remove.
(gfc_resolve_formal_arglist): Set gfc_current_ns. Quit loop and
restore gfc_current_ns instead of early returning.
(resolve_symbol): Factor common array spec resolution code to...
(resolve_symbol_array_spec): ... this new function. Additionnally
set and restore gfc_current_ns.
gcc/testsuite/ChangeLog:
* gfortran.dg/spec_expr_8.f90: New test.
* gfortran.dg/spec_expr_9.f90: New test.
---
gcc/fortran/expr.cc | 8 +--
gcc/fortran/gfortran.h| 4 +-
gcc/fortran/resolve.cc| 77 +++
gcc/fortran/symbol.cc | 58 +
gcc/testsuite/gfortran.dg/spec_expr_8.f90 | 24 +++
gcc/testsuite/gfortran.dg/spec_expr_9.f90 | 19 ++
6 files changed, 140 insertions(+), 50 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_8.f90
create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_9.f90
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 82a642b01f7..0852bc5f493 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3509,19 +3509,13 @@ check_restricted (gfc_expr *e)
if (!check_references (e->ref, _restricted))
break;
- /* gfc_is_formal_arg broadcasts that a formal argument list is being
-processed in resolve.cc(resolve_formal_arglist). This is done so
-that host associated dummy array indices are accepted (PR23446).
-This mechanism also does the same for the specification expressions
-of array-valued functions. */
if (e->error
|| sym->attr.in_common
|| sym->attr.use_assoc
|| sym->attr.dummy
|| sym->attr.implied_index
|| sym->attr.flavor == FL_PARAMETER
- || is_parent_of_current_ns (sym->ns)
- || (gfc_is_formal_arg () && (sym->ns == gfc_current_ns)))
+ || is_parent_of_current_ns (gfc_get_spec_ns (sym)))
{
t = true;
break;
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 32b792f85fb..f954b7a8802 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3605,6 +3605,9 @@ bool gfc_is_associate_pointer (gfc_symbol*);
gfc_symbol * gfc_find_dt_in_generic (gfc_symbol *);
gfc_formal_arglist *gfc_sym_get_dummy_args (gfc_symbol *);
+gfc_namespace * gfc_get_procedure_ns (gfc_symbol *);
+gfc_namespace * gfc_get_spec_ns (gfc_symbol *);
+
/* intrinsic.cc -- true if working in an init-expr, false otherwise. */
extern bool gfc_init_expr_flag;
@@ -3813,7 +3816,6 @@ bool gfc_resolve_iterator (gfc_iterator *, bool, bool);
bool find_forall_index (gfc_expr *, gfc_symbol *, int);
bool gfc_resolve_index (gfc_expr *, int);
bool gfc_resolve_dim_arg (gfc_expr *);
-bool gfc_is_formal_arg (void);
bool gfc_resolve_substring (gfc_ref *, bool *);
void gfc_resolve_substring_charlen (gfc_expr *);
gfc_expr *gfc_expr_to_initialize (gfc_expr *);
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 02acc4aef31..6bdb56038bb 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -72,9 +72,6 @@ static bool first_actual_arg = false;
static int omp_workshare_flag;
-/* True if we are processing a formal arglist. The corresponding function
- resets the flag each time that it is read. */
-static bool formal_arg_flag = false;
/* True if we are resolving a specification expression. */
static bool specification_expr = false;
@@ -89,12 +86,6 @@ static bitmap_obstack labels_obstack;
static bool
[PATCH v2 1/2] testsuite: Declare fortran array bound variables
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90: Likewise.
* gfortran.dg/pr78061.f: Likewise.
* gfortran.dg/pr79315.f90: Likewise.
* gfortran.dg/vect/pr90681.f: Likewise.
* gfortran.dg/vect/pr97761.f90: Likewise.
* gfortran.dg/vect/pr99746.f90: Likewise.
---
gcc/testsuite/gfortran.dg/graphite/pr107865.f90 | 2 +-
gcc/testsuite/gfortran.dg/pr101267.f90 | 2 +-
gcc/testsuite/gfortran.dg/pr112404.f90 | 2 +-
gcc/testsuite/gfortran.dg/pr78061.f | 2 +-
gcc/testsuite/gfortran.dg/pr79315.f90 | 6 +-
gcc/testsuite/gfortran.dg/vect/pr90681.f| 2 +-
gcc/testsuite/gfortran.dg/vect/pr97761.f90 | 2 +-
gcc/testsuite/gfortran.dg/vect/pr99746.f90 | 2 +-
8 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
b/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
index 6bddb17a1be..323d8092ad2 100644
--- a/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-options "-O1 -floop-parallelize-all -ftree-parallelize-loops=2" }
- SUBROUTINE FNC (F)
+ SUBROUTINE FNC (F,N)
IMPLICIT REAL (A-H)
DIMENSION F(N)
diff --git a/gcc/testsuite/gfortran.dg/pr101267.f90
b/gcc/testsuite/gfortran.dg/pr101267.f90
index 12723cf9c22..99a6dcfa342 100644
--- a/gcc/testsuite/gfortran.dg/pr101267.f90
+++ b/gcc/testsuite/gfortran.dg/pr101267.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-options "-Ofast" }
! { dg-additional-options "-march=znver2" { target x86_64-*-* i?86-*-* } }
- SUBROUTINE sfddagd( regime, znt,ite ,jte )
+ SUBROUTINE sfddagd( regime, znt,ite ,jte, ime, IN )
REAL, DIMENSION( ime, IN) :: regime, znt
REAL, DIMENSION( ite, jte) :: wndcor_u
LOGICAL wrf_dm_on_monitor
diff --git a/gcc/testsuite/gfortran.dg/pr112404.f90
b/gcc/testsuite/gfortran.dg/pr112404.f90
index 573fa28164a..4508bbc8738 100644
--- a/gcc/testsuite/gfortran.dg/pr112404.f90
+++ b/gcc/testsuite/gfortran.dg/pr112404.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-options "-Ofast" }
! { dg-additional-options "-mavx2" { target avx2 } }
- SUBROUTINE sfddagd( regime, znt, ite, jte )
+ SUBROUTINE sfddagd( regime, znt, ite, jte, ime, IN )
REAL, DIMENSION( ime, IN) :: regime, znt
REAL, DIMENSION( ite, jte) :: wndcor_u
LOGICAL wrf_dm_on_monitor
diff --git a/gcc/testsuite/gfortran.dg/pr78061.f
b/gcc/testsuite/gfortran.dg/pr78061.f
index 7e4dd3de8b5..9061dea74da 100644
--- a/gcc/testsuite/gfortran.dg/pr78061.f
+++ b/gcc/testsuite/gfortran.dg/pr78061.f
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-options "-O3 -fsplit-loops" }
- SUBROUTINE SSYMM(C)
+ SUBROUTINE SSYMM(C,LDC)
REAL C(LDC,*)
LOGICAL LSAME
LOGICAL UPPER
diff --git a/gcc/testsuite/gfortran.dg/pr79315.f90
b/gcc/testsuite/gfortran.dg/pr79315.f90
index 8cd89691ce9..b754a2b3274 100644
--- a/gcc/testsuite/gfortran.dg/pr79315.f90
+++ b/gcc/testsuite/gfortran.dg/pr79315.f90
@@ -10,7 +10,11 @@ SUBROUTINE wsm32D(t, &
its,&
ite, &
kts, &
- kte &
+ kte, &
+ ims, &
+ ime, &
+ kms, &
+ kme &
)
REAL, DIMENSION( its:ite , kts:kte ), &
INTENT(INOUT) :: &
diff --git a/gcc/testsuite/gfortran.dg/vect/pr90681.f
b/gcc/testsuite/gfortran.dg/vect/pr90681.f
index 03d3987b146..49f1d50ab8f 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr90681.f
+++ b/gcc/testsuite/gfortran.dg/vect/pr90681.f
@@ -1,6 +1,6 @@
C { dg-do compile }
C { dg-additional-options "-march=armv8.2-a+sve" { target { aarch64*-*-* } } }
- SUBROUTINE HMU (H1)
+ SUBROUTINE HMU (H1,NORBS)
COMMON DD(107)
DIMENSION H1(NORBS,*)
DO 70 J1 = IA,I1
diff --git a/gcc/testsuite/gfortran.dg/vect/pr97761.f90
b/gcc/testsuite/gfortran.dg/vect/pr97761.f90
index 250e2bf016e..401ef06e422 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr97761.f90
+++ b/gcc/testsuite/gfortran.dg/vect/pr97761.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-additional-options "-O1" }
-subroutine ni (ps)
+subroutine ni (ps, inout)
type vector
real x, y
end type
diff --git a/gcc/testsuite/gfortran.dg/vect/pr99746.f90
b/gcc/testsuite/gfortran.dg/vect/pr99746.f90
index fe947ae7ccf..121d67d564d 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr99746.f90
+++ b/gcc/testsuite/gfortran.dg/vect/pr99746.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-additional-options "-march=armv8.3-a" { target aarch64-*-* } }
-SUBROUTINE CLAREF(A, WANTZ, Z, ICOL1, ITMP1, ITMP2, T1, T2, V2)
+SUBROUTINE CLAREF(A, WANTZ, Z, ICOL1, ITMP1, ITMP2, T1, T2, V2, LDA)
[PATCH v2 0/2] fortran: Fix specification checks [PR111781]
Meh, the first version contained out-of-date patches. these patches correct diagnostics dealing with variables in specification expressions. The first patch is a testsuite change, which fixes invalid specification expressions that the second patch would diagnose. The second patch removes a spurious diagnostic when a dummy procedure is involved, and enables more valid ones, as visible in the testcases from the first patch. The patch is not completely trivial, and fix what is not really a regression, so it is more for stage1, I think. Tested for regression on x86_64-pc-linux-gnu. Ok for master when stage1 opens? Mikael v1 -> v2 changes: - Fix condition guarding sym->result access. Mikael Morin (2): testsuite: Declare fortran array bound variables fortran: Fix specification expression error with dummy procedures [PR111781] gcc/fortran/expr.cc | 8 +- gcc/fortran/gfortran.h| 4 +- gcc/fortran/resolve.cc| 77 +-- gcc/fortran/symbol.cc | 58 ++ .../gfortran.dg/graphite/pr107865.f90 | 2 +- gcc/testsuite/gfortran.dg/pr101267.f90| 2 +- gcc/testsuite/gfortran.dg/pr112404.f90| 2 +- gcc/testsuite/gfortran.dg/pr78061.f | 2 +- gcc/testsuite/gfortran.dg/pr79315.f90 | 6 +- gcc/testsuite/gfortran.dg/spec_expr_8.f90 | 24 ++ gcc/testsuite/gfortran.dg/spec_expr_9.f90 | 19 + gcc/testsuite/gfortran.dg/vect/pr90681.f | 2 +- gcc/testsuite/gfortran.dg/vect/pr97761.f90| 2 +- gcc/testsuite/gfortran.dg/vect/pr99746.f90| 2 +- 14 files changed, 152 insertions(+), 58 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_8.f90 create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_9.f90 -- 2.43.0
Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macro for
debug mode?
After this fix of local_iterator I think we can indeed.
In fact the added 11316.cc was already passing for
unordered_set<>::local_iterator but simply because we were missing the
singular check. Both issues solved with this patch.
I found the version.def file to cleanup but no idea how to regenerate
version.h from it so I'll let you do it, ok ?
libstdc++: Fix _Safe_local_iterator<>::_M_valid_range
Unordered container local_iterator range shall not contain any singular
iterator unless both iterators are value-initialized.
libstdc++-v3/ChangeLog:
* include/debug/safe_local_iterator.tcc
(_Safe_local_iterator::_M_valid_range): Add
_M_value_initialized and
_M_singular checks.
* testsuite/23_containers/unordered_set/debug/114316.cc:
New test case.
Ok to commit ?
François
diff --git a/libstdc++-v3/include/debug/safe_local_iterator.tcc
b/libstdc++-v3/include/debug/safe_local_iterator.tcc
index 90e60e37c32..6d546ec040c 100644
--- a/libstdc++-v3/include/debug/safe_local_iterator.tcc
+++ b/libstdc++-v3/include/debug/safe_local_iterator.tcc
@@ -78,7 +78,13 @@ namespace __gnu_debug
_M_valid_range(const _Safe_local_iterator& __rhs,
std::pair& __dist) const
{
- if (!_M_can_compare(__rhs))
+ if (_M_value_initialized() && __rhs._M_value_initialized())
+ {
+ __dist = { 0, __dp_exact };
+ return true;
+ }
+
+ if (_M_singular() || __rhs._M_singular() || !_M_can_compare(__rhs))
return false;
if (bucket() != __rhs.bucket())
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_set/debug/114316.cc
b/libstdc++-v3/testsuite/23_containers/unordered_set/debug/114316.cc
new file mode 100644
index 000..41b649a9cbd
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_set/debug/114316.cc
@@ -0,0 +1,28 @@
+// { dg-do run { target c++11 } }
+// { dg-require-debug-mode "" }
+
+// PR libstdc++/114316
+
+#include
+#include
+
+#include
+
+void test01()
+{
+ std::unordered_set::iterator it{};
+ VERIFY( std::find(it, it, 0) == it );
+}
+
+void test02()
+{
+ std::unordered_set::local_iterator it{};
+ VERIFY( std::find(it, it, 0) == it );
+}
+
+int main()
+{
+ test01();
+ test02();
+ return 0;
+}
[committed] hppa: Fix complaint about non-delegitimized UNSPEC UNSPEC_TP
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
hppa: Fix complaint about non-delegitimized UNSPEC UNSPEC_TP
2024-03-17 John David Anglin
gcc/ChangeLog:
* config/pa/pa.cc (pa_delegitimize_address): Delegitimize UNSPEC_TP.
diff --git a/gcc/config/pa/pa.cc b/gcc/config/pa/pa.cc
index 129289f8e62..d7666103de8 100644
--- a/gcc/config/pa/pa.cc
+++ b/gcc/config/pa/pa.cc
@@ -10707,7 +10709,13 @@ pa_trampoline_adjust_address (rtx addr)
static rtx
pa_delegitimize_address (rtx orig_x)
{
- rtx x = delegitimize_mem_from_attrs (orig_x);
+ rtx x;
+
+ if (GET_CODE (orig_x) == UNSPEC
+ && XINT (orig_x, 1) == UNSPEC_TP)
+orig_x = XVECEXP (orig_x, 0, 0);
+
+ x = delegitimize_mem_from_attrs (orig_x);
if (GET_CODE (x) == LO_SUM
&& GET_CODE (XEXP (x, 1)) == UNSPEC
signature.asc
Description: PGP signature
[PATCH 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]
This fixes a spurious invalid variable in specification expression error.
The problem is caused by improper restoration of formal_arg_flag to false
(instead of restoring it to its previous value). This happens with the
testcase from the PR where a dummy argument is itself a procedure with dummy
arguments. At the time that dummy procedure has been resolved, its dummy
arguments have been resolved and the flag has been reset to false. The
condition checking that flag when resolving the array spec expressions of
the next dummy then triggers the error.
The fix removes a condition disabling proper check of specification
expressions, together with the formal_arg_flag global variable associated
with it. As the specification expression checking code is dependent on the
current namespace, the latter is set before array spec resolution (and
restored after). Two new functions are introduced to select the right
namespace for that.
PR fortran/111781
gcc/fortran/ChangeLog:
* symbol.cc (gfc_get_procedure_ns, gfc_get_spec_ns): New functions.
* gfortran.h (gfc_get_procedure_ns, gfc_get_spec ns): Declare them.
(gfc_is_formal_arg): Remove.
* expr.cc (check_restricted): Remove the case where symbol is dummy
and declared in the current ns. Use gfc_get_spec_ns to get the
right namespace.
* resolve.cc (gfc_is_formal_arg, formal_arg_flag): Remove.
(gfc_resolve_formal_arglist): Set gfc_current_ns. Quit loop and
restore gfc_current_ns instead of early returning.
(resolve_symbol): Factor common array spec resolution code to...
(resolve_symbol_array_spec): ... this new function. Additionnally
set and restore gfc_current_ns.
gcc/testsuite/ChangeLog:
* gfortran.dg/spec_expr_8.f90: New test.
* gfortran.dg/spec_expr_9.f90: New test.
---
gcc/fortran/expr.cc | 8 +--
gcc/fortran/gfortran.h| 4 +-
gcc/fortran/resolve.cc| 77 +++
gcc/fortran/symbol.cc | 57 +
gcc/testsuite/gfortran.dg/spec_expr_8.f90 | 24 +++
gcc/testsuite/gfortran.dg/spec_expr_9.f90 | 19 ++
6 files changed, 139 insertions(+), 50 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_8.f90
create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_9.f90
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 82a642b01f7..0852bc5f493 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3509,19 +3509,13 @@ check_restricted (gfc_expr *e)
if (!check_references (e->ref, _restricted))
break;
- /* gfc_is_formal_arg broadcasts that a formal argument list is being
-processed in resolve.cc(resolve_formal_arglist). This is done so
-that host associated dummy array indices are accepted (PR23446).
-This mechanism also does the same for the specification expressions
-of array-valued functions. */
if (e->error
|| sym->attr.in_common
|| sym->attr.use_assoc
|| sym->attr.dummy
|| sym->attr.implied_index
|| sym->attr.flavor == FL_PARAMETER
- || is_parent_of_current_ns (sym->ns)
- || (gfc_is_formal_arg () && (sym->ns == gfc_current_ns)))
+ || is_parent_of_current_ns (gfc_get_spec_ns (sym)))
{
t = true;
break;
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 32b792f85fb..f954b7a8802 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3605,6 +3605,9 @@ bool gfc_is_associate_pointer (gfc_symbol*);
gfc_symbol * gfc_find_dt_in_generic (gfc_symbol *);
gfc_formal_arglist *gfc_sym_get_dummy_args (gfc_symbol *);
+gfc_namespace * gfc_get_procedure_ns (gfc_symbol *);
+gfc_namespace * gfc_get_spec_ns (gfc_symbol *);
+
/* intrinsic.cc -- true if working in an init-expr, false otherwise. */
extern bool gfc_init_expr_flag;
@@ -3813,7 +3816,6 @@ bool gfc_resolve_iterator (gfc_iterator *, bool, bool);
bool find_forall_index (gfc_expr *, gfc_symbol *, int);
bool gfc_resolve_index (gfc_expr *, int);
bool gfc_resolve_dim_arg (gfc_expr *);
-bool gfc_is_formal_arg (void);
bool gfc_resolve_substring (gfc_ref *, bool *);
void gfc_resolve_substring_charlen (gfc_expr *);
gfc_expr *gfc_expr_to_initialize (gfc_expr *);
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 02acc4aef31..6bdb56038bb 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -72,9 +72,6 @@ static bool first_actual_arg = false;
static int omp_workshare_flag;
-/* True if we are processing a formal arglist. The corresponding function
- resets the flag each time that it is read. */
-static bool formal_arg_flag = false;
/* True if we are resolving a specification expression. */
static bool specification_expr = false;
@@ -89,12 +86,6 @@ static bitmap_obstack labels_obstack;
static bool
[PATCH 1/2] testsuite: Declare fortran array bound variables
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90: Likewise.
* gfortran.dg/pr78061.f: Likewise.
* gfortran.dg/pr79315.f90: Likewise.
* gfortran.dg/vect/pr90681.f: Likewise.
* gfortran.dg/vect/pr97761.f90: Likewise.
* gfortran.dg/vect/pr99746.f90: Likewise.
---
gcc/testsuite/gfortran.dg/graphite/pr107865.f90 | 2 +-
gcc/testsuite/gfortran.dg/pr101267.f90 | 2 +-
gcc/testsuite/gfortran.dg/pr112404.f90 | 2 +-
gcc/testsuite/gfortran.dg/pr78061.f | 2 +-
gcc/testsuite/gfortran.dg/pr79315.f90 | 6 +-
gcc/testsuite/gfortran.dg/vect/pr90681.f| 2 +-
gcc/testsuite/gfortran.dg/vect/pr97761.f90 | 2 +-
gcc/testsuite/gfortran.dg/vect/pr99746.f90 | 2 +-
8 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
b/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
index 6bddb17a1be..323d8092ad2 100644
--- a/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/pr107865.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-options "-O1 -floop-parallelize-all -ftree-parallelize-loops=2" }
- SUBROUTINE FNC (F)
+ SUBROUTINE FNC (F,N)
IMPLICIT REAL (A-H)
DIMENSION F(N)
diff --git a/gcc/testsuite/gfortran.dg/pr101267.f90
b/gcc/testsuite/gfortran.dg/pr101267.f90
index 12723cf9c22..99a6dcfa342 100644
--- a/gcc/testsuite/gfortran.dg/pr101267.f90
+++ b/gcc/testsuite/gfortran.dg/pr101267.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-options "-Ofast" }
! { dg-additional-options "-march=znver2" { target x86_64-*-* i?86-*-* } }
- SUBROUTINE sfddagd( regime, znt,ite ,jte )
+ SUBROUTINE sfddagd( regime, znt,ite ,jte, ime, IN )
REAL, DIMENSION( ime, IN) :: regime, znt
REAL, DIMENSION( ite, jte) :: wndcor_u
LOGICAL wrf_dm_on_monitor
diff --git a/gcc/testsuite/gfortran.dg/pr112404.f90
b/gcc/testsuite/gfortran.dg/pr112404.f90
index 573fa28164a..4508bbc8738 100644
--- a/gcc/testsuite/gfortran.dg/pr112404.f90
+++ b/gcc/testsuite/gfortran.dg/pr112404.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-options "-Ofast" }
! { dg-additional-options "-mavx2" { target avx2 } }
- SUBROUTINE sfddagd( regime, znt, ite, jte )
+ SUBROUTINE sfddagd( regime, znt, ite, jte, ime, IN )
REAL, DIMENSION( ime, IN) :: regime, znt
REAL, DIMENSION( ite, jte) :: wndcor_u
LOGICAL wrf_dm_on_monitor
diff --git a/gcc/testsuite/gfortran.dg/pr78061.f
b/gcc/testsuite/gfortran.dg/pr78061.f
index 7e4dd3de8b5..9061dea74da 100644
--- a/gcc/testsuite/gfortran.dg/pr78061.f
+++ b/gcc/testsuite/gfortran.dg/pr78061.f
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-options "-O3 -fsplit-loops" }
- SUBROUTINE SSYMM(C)
+ SUBROUTINE SSYMM(C,LDC)
REAL C(LDC,*)
LOGICAL LSAME
LOGICAL UPPER
diff --git a/gcc/testsuite/gfortran.dg/pr79315.f90
b/gcc/testsuite/gfortran.dg/pr79315.f90
index 8cd89691ce9..b754a2b3274 100644
--- a/gcc/testsuite/gfortran.dg/pr79315.f90
+++ b/gcc/testsuite/gfortran.dg/pr79315.f90
@@ -10,7 +10,11 @@ SUBROUTINE wsm32D(t, &
its,&
ite, &
kts, &
- kte &
+ kte, &
+ ims, &
+ ime, &
+ kms, &
+ kme &
)
REAL, DIMENSION( its:ite , kts:kte ), &
INTENT(INOUT) :: &
diff --git a/gcc/testsuite/gfortran.dg/vect/pr90681.f
b/gcc/testsuite/gfortran.dg/vect/pr90681.f
index 03d3987b146..49f1d50ab8f 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr90681.f
+++ b/gcc/testsuite/gfortran.dg/vect/pr90681.f
@@ -1,6 +1,6 @@
C { dg-do compile }
C { dg-additional-options "-march=armv8.2-a+sve" { target { aarch64*-*-* } } }
- SUBROUTINE HMU (H1)
+ SUBROUTINE HMU (H1,NORBS)
COMMON DD(107)
DIMENSION H1(NORBS,*)
DO 70 J1 = IA,I1
diff --git a/gcc/testsuite/gfortran.dg/vect/pr97761.f90
b/gcc/testsuite/gfortran.dg/vect/pr97761.f90
index 250e2bf016e..401ef06e422 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr97761.f90
+++ b/gcc/testsuite/gfortran.dg/vect/pr97761.f90
@@ -1,7 +1,7 @@
! { dg-do compile }
! { dg-additional-options "-O1" }
-subroutine ni (ps)
+subroutine ni (ps, inout)
type vector
real x, y
end type
diff --git a/gcc/testsuite/gfortran.dg/vect/pr99746.f90
b/gcc/testsuite/gfortran.dg/vect/pr99746.f90
index fe947ae7ccf..121d67d564d 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr99746.f90
+++ b/gcc/testsuite/gfortran.dg/vect/pr99746.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-additional-options "-march=armv8.3-a" { target aarch64-*-* } }
-SUBROUTINE CLAREF(A, WANTZ, Z, ICOL1, ITMP1, ITMP2, T1, T2, V2)
+SUBROUTINE CLAREF(A, WANTZ, Z, ICOL1, ITMP1, ITMP2, T1, T2, V2, LDA)
[PATCH 0/2] fortran: Fix specification checks [PR111781]
Hello, these patches correct diagnostics dealing with variables in specification expressions. The first patch is a testsuite change, which fixes invalid specification expressions that the second patch would diagnose. The second patch removes a spurious diagnostic when a dummy procedure is involved, and enables more valid ones, as visible in the testcases from the first patch. The patch is not completely trivial, and fix what is not really a regression, so it is more for stage1, I think. Tested for regression on x86_64-pc-linux-gnu. Ok for master when stage1 opens? Mikael Morin (2): testsuite: Declare fortran array bound variables fortran: Fix specification expression error with dummy procedures [PR111781] gcc/fortran/expr.cc | 8 +- gcc/fortran/gfortran.h| 4 +- gcc/fortran/resolve.cc| 77 +-- gcc/fortran/symbol.cc | 57 ++ .../gfortran.dg/graphite/pr107865.f90 | 2 +- gcc/testsuite/gfortran.dg/pr101267.f90| 2 +- gcc/testsuite/gfortran.dg/pr112404.f90| 2 +- gcc/testsuite/gfortran.dg/pr78061.f | 2 +- gcc/testsuite/gfortran.dg/pr79315.f90 | 6 +- gcc/testsuite/gfortran.dg/spec_expr_8.f90 | 24 ++ gcc/testsuite/gfortran.dg/spec_expr_9.f90 | 19 + gcc/testsuite/gfortran.dg/vect/pr90681.f | 2 +- gcc/testsuite/gfortran.dg/vect/pr97761.f90| 2 +- gcc/testsuite/gfortran.dg/vect/pr99746.f90| 2 +- 14 files changed, 151 insertions(+), 58 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_8.f90 create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_9.f90 -- 2.43.0
Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]
On Sat, 16 Mar 2024, 12:16 François Dumont, wrote:
> With the patch, sorry.
>
> On 14/03/2024 22:49, François Dumont wrote:
> > Hi
> >
> > This is what I started to do.
> >
> > For now I haven't touch to __cpp_lib_null_iterators definition as
> > _Safe_local_iterator still need some work.
> >
> > libstdc++: Implement N3644 on _Safe_iterator<> [PR114316]
> >
> > Consider range of value-initialized iterators as valid and empty.
> >
> > libstdc++-v3/ChangeLog:
> >
> > PR libstdc++/114316
> > * include/debug/safe_iterator.tcc
> > (_Safe_iterator<>::_M_valid_range):
> > First check if both iterators are value-initialized before
> > checking if
> > singular.
> > * testsuite/23_containers/set/debug/114316.cc: New test case.
> > * testsuite/23_containers/vector/debug/114316.cc: New test case.
> >
> > Tested under Linux x86_64, ok to commit ?
>
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macro for debug
mode?
>
> > François
> >
> >
> > On 12/03/2024 10:52, Jonathan Wakely wrote:
> >> On Tue, 12 Mar 2024 at 01:03, Jonathan Wakely
> >> wrote:
> >>> On Tue, 12 Mar 2024 at 00:55, Maciej Miera
> >>> wrote:
>
>
> Wiadomość napisana przez Jonathan Wakely w
> dniu 11.03.2024, o godz. 21:40:
>
> On Mon, 11 Mar 2024 at 20:07, Maciej Miera
> wrote:
>
>
> Hello,
>
> I have tried to introduce an extra level of safety to my codebase
> and utilize _GLIBCXX_DEBUG in my test builds in order to catch
> faulty iterators.
> However, I have encountered the following problem: I would like to
> utilize singular, value-initialized iterators as an arbitrary "null
> range”.
> However, this leads to failed assertions in std:: algorithms taking
> such range.
>
> Consider the following code sample with find_if:
>
> #include
> #include
> #include
>
> #ifndef __cpp_lib_null_iterators
> #warning "Not standard compliant"
> #endif
>
> int main()
> {
> std::multimap::iterator it1{};
> std::multimap::iterator it2{};
>
> (void) (it1==it2); // OK
> (void) std::find_if(
> it1, it2, [](const auto& el) { return el.second == 8;});
> }
>
> Compiled with -std=c++20 and -D_GLIBCXX_DEBUG it produces the
> warning "Not standard compliant"
> and the execution results in the following assert failure:
>
>
> /opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algo.h:3875:
>
> In function:
> constexpr _IIter std::find_if(_IIter, _IIter, _Predicate) [with
> _IIter =
> gnu_debug::_Safe_iterator<_Rb_tree_iterator >,
> debug::multimap, bidirectional_iterator_tag>;
> _Predicate =
> main()::]
>
> The question is though: is it by design, or is it just a mere
> oversight? The warning actually suggest the first option.
> If it is an intentional design choice, could you provide some
> rationale behind it, please?
>
>
> The macro was not defined because the C++14 rule wasn't implemented
> for debug mode, but that should have been fixed for GCC 11, according
> to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98466 and
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70303
> So we should be able to define macro now, except maybe it wasn't fixed
> for the RB tree containers.
>
>
>
> Just to make sure there are no misunderstandings: comparison via ==
> works fine. The feature check macro without _GLIBCXX_DEBUG and with
> included is also fine. Maybe the need to include a
> header is the issue, but that’s not the core of the problem anyway.
> >>> No, it has nothing to do with the headers included. The feature test
> >>> macro is defined like so:
> >>>
> >>> # if (__cplusplus >= 201402L) && (!defined(_GLIBCXX_DEBUG))
> >>> # define __glibcxx_null_iterators 201304L
> >>>
> >>> It's a very deliberate choice to not define it when _GLIBCXX_DEBUG is
> >>> defined. But as I said, I think we should have changed that.
> >>>
> The actual question is though, whether passing singular iterators
> to std algorithms (like find_if) should make the asserts at the
> beginning of the algo function fail when compiled with
> _GLIBCXX_DEBUG. IMHO, intuitively it should not, as comparing
> iterators equal would just ensure early exit and return of the same
> singular iterator.
> This seems not to be the case though. The actual message is this:
> Error: the function requires a valid iterator range [first, last).
> What bothers me is whether the empty virtual range limited by two
> same singular iterators is actually valid or not.
> >>> Yes, it's valid. So the bug is in the __glibcxx_requires_valid_range
> >>>
[committed] d: Merge upstream dmd, druntime 855353a1d9
Hi,
This patch merges the D front-end and runtime library with upstream dmd
855353a1d9.
D front-end changes:
- Import dmd v2.108.0-rc.1.
- Add support for Named Arguments for functions.
- Hex strings now convert to integer arrays.
D runtime changes:
- Import druntime v2.108.0-rc.1.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd 855353a1d9.
* dmd/VERSION:
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime 855353a1d9.
---
gcc/d/dmd/MERGE | 2 +-
gcc/d/dmd/VERSION | 2 +-
gcc/d/dmd/cxxfrontend.d | 10 +++
gcc/d/dmd/dcast.d | 31 ---
gcc/d/dmd/dinterpret.d| 2 +-
gcc/d/dmd/dsymbolsem.d| 7 +-
gcc/d/dmd/dtemplate.d | 48 +--
gcc/d/dmd/enum.h | 6 ++
gcc/d/dmd/expression.h| 15
gcc/d/dmd/expressionsem.d | 9 +-
gcc/d/dmd/hdrgen.d| 3 +-
gcc/d/dmd/lexer.d | 1 -
gcc/d/dmd/mtype.d | 17 ++--
gcc/d/dmd/mtype.h | 5 +-
gcc/d/dmd/root/filename.d | 2 +-
gcc/d/dmd/root/filename.h | 2 +-
gcc/d/dmd/template.h | 16 +---
gcc/d/dmd/templatesem.d | 85 ---
gcc/d/dmd/typesem.d | 16 +++-
.../compilable/named_arguments_auto_ref.d | 39 +
.../compilable/named_arguments_ifti.d | 27 ++
.../gdc.test/fail_compilation/hexstring.d | 5 +-
.../fail_compilation/named_arguments_error.d | 11 ++-
.../named_arguments_ifti_error.d | 20 +
gcc/testsuite/gdc.test/runnable/literal.d | 10 ++-
libphobos/libdruntime/MERGE | 2 +-
.../core/internal/gc/impl/conservative/gc.d | 4 +-
.../core/internal/gc/impl/manual/gc.d | 2 +-
.../core/internal/gc/impl/proto/gc.d | 2 +-
29 files changed, 294 insertions(+), 107 deletions(-)
create mode 100644 gcc/testsuite/gdc.test/compilable/named_arguments_auto_ref.d
create mode 100644 gcc/testsuite/gdc.test/compilable/named_arguments_ifti.d
create mode 100644
gcc/testsuite/gdc.test/fail_compilation/named_arguments_ifti_error.d
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index 4c0a0bc2aac..a00872ef864 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-f8bae0455851a1dfc8113d69323415f6de549e39
+855353a1d9e16d43e85b6cf2b03aef388619bd16
The first line of this file holds the git revision number of the last
merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/VERSION b/gcc/d/dmd/VERSION
index 416807683f5..8ca452f8912 100644
--- a/gcc/d/dmd/VERSION
+++ b/gcc/d/dmd/VERSION
@@ -1 +1 @@
-v2.108.0-beta.1
+v2.108.0-rc.1
diff --git a/gcc/d/dmd/cxxfrontend.d b/gcc/d/dmd/cxxfrontend.d
index 8c046343468..a0432d2e1b4 100644
--- a/gcc/d/dmd/cxxfrontend.d
+++ b/gcc/d/dmd/cxxfrontend.d
@@ -14,6 +14,7 @@ import dmd.aggregate : AggregateDeclaration;
import dmd.arraytypes;
import dmd.astenums;
import dmd.common.outbuffer : OutBuffer;
+import dmd.denum : EnumDeclaration;
import dmd.dmodule /*: Module*/;
import dmd.dscope : Scope;
import dmd.dstruct /*: StructDeclaration*/;
@@ -213,6 +214,15 @@ void genCppHdrFiles(ref Modules ms)
return dmd.dtoh.genCppHdrFiles(ms);
}
+/***
+ * enumsem.d
+ */
+Expression getDefaultValue(EnumDeclaration ed, const ref Loc loc)
+{
+import dmd.enumsem;
+return dmd.enumsem.getDefaultValue(ed, loc);
+}
+
/***
* expression.d
*/
diff --git a/gcc/d/dmd/dcast.d b/gcc/d/dmd/dcast.d
index a49bd575f4b..8a713f424d6 100644
--- a/gcc/d/dmd/dcast.d
+++ b/gcc/d/dmd/dcast.d
@@ -629,7 +629,7 @@ MATCH implicitConvTo(Expression e, Type t)
TY tyn = e.type.nextOf().ty;
-if (!tyn.isSomeChar)
+if (!tyn.isSomeChar && !e.hexString)
return visit(e);
switch (t.ty)
@@ -703,6 +703,11 @@ MATCH implicitConvTo(Expression e, Type t)
return MATCH.nomatch;
m = MATCH.constant;
}
+if (e.hexString && tn.isintegral && (tn.size == e.sz ||
(!e.committed && (e.len % tn.size) == 0)))
+{
+m = MATCH.convert;
+return m;
+}
if (!e.committed)
{
switch (tn.ty)
@@ -719,9 +724,6 @@ MATCH implicitConvTo(Expression e, Type t)
if (e.postfix != 'd')
m = MATCH.convert;
return m;
-case Tint8:
-
Re: [PATCH] Predefine __STRICT_ALIGN__ if STRICT_ALIGNMENT
Sam James 于2024年3月17日周日 14:04写道： > > YunQiang Su writes: > > > Arm32 predefines __ARM_FEATURE_UNALIGNED if -mno-unaligned-access, > > and RISC-V predefines __riscv_misaligned_avoid, while other ports > > that support -mstrict-align/-mno-unaligned-access don't have such > > macro, and these backend macros are only avaiable for c-family. > > Note: Arm64 always predefine __ARM_FEATURE_UNALIGNED: See #111555. > > I would say tag the bug even if you're not fixing it, as it was related > enough for you to cite it. > I am not sure that it is a bug for aarch64. This macro may be used to determine whether hardware can support misaligned access, and maybe all of Aarch64 CPUs can support it. It should be determined by ARM people.
Re: [PATCH] Predefine __STRICT_ALIGN__ if STRICT_ALIGNMENT
YunQiang Su writes: > Arm32 predefines __ARM_FEATURE_UNALIGNED if -mno-unaligned-access, > and RISC-V predefines __riscv_misaligned_avoid, while other ports > that support -mstrict-align/-mno-unaligned-access don't have such > macro, and these backend macros are only avaiable for c-family. > Note: Arm64 always predefine __ARM_FEATURE_UNALIGNED: See #111555. I would say tag the bug even if you're not fixing it, as it was related enough for you to cite it. > > Let's add a generic one. > > __STRICT_ALIGN__ is used instead of __STRICT_ALIGNMENT__, due to that > the later is used by some softwares, such as lzo2, syslinux etc. > > gcc > * cppbuiltin.cc: Predefine __STRICT_ALIGNMENT__ if > STRICT_ALIGNMENT. > --- > gcc/cppbuiltin.cc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gcc/cppbuiltin.cc b/gcc/cppbuiltin.cc > index c4bfc2917dc..d32efdf9a07 100644 > --- a/gcc/cppbuiltin.cc > +++ b/gcc/cppbuiltin.cc > @@ -123,6 +123,9 @@ define_builtin_macros_for_compilation_flags (cpp_reader > *pfile) > >cpp_define_formatted (pfile, "__FINITE_MATH_ONLY__=%d", > flag_finite_math_only); > + > + if (STRICT_ALIGNMENT) > +cpp_define (pfile, "__STRICT_ALIGNMENT__"); > }
